Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

From: Loa Andersson <[email-masked]>
Date: Fri, 4 Dec 2015 00:34:18 +0800

Folks,

On 2015-11-25 01:19, Acee Lindem (acee) wrote:
<snip>

There is a non-converged discussion going on on draft-ietf-i2rs-
rib-data-model, the key statement seems to be:

>
> I believe the intention of the model is clearly to dynamically create
> the tunnels.
>
<snip>

I think that was is going on is (something like) this:

The authors intend to create a model that can be used to add, remove
and find information about the routes in the RIB (read series of RIBs).

Acee see is that adding this type of information to the RIB may very
well be used create (add) tunnels. After all the information manipulated
in both cases are very much the same.

If this very rudimentary analysis is correct, it should not be
impossible to add text to the document explaining what the intention is.

On one had I don't think it is motivated to not allow what the model is
intended for, on the other hand it should be perfectly what the
intention is (and what is is not).

/Loa

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 3 Dec 2015 12:42:14 -0500

Loa: 

<WG chair hat on> 

Thank you for your note.  The rudimentary analysis was incorrect.  The I2RS
RIB Information Model (RIB IM) and RIB Data Model (RIB DM) is a pair of
documents that explain the I2RS RIB. The authors of these models will need
to improve the text to indicate tunnels are not being created. 

Since RIB IM has passed WG LC,  anyone wishes to propose that the RIB IM/DM
create tunnels should send me an indication they wish to create such a
proposal by 10/9/2015.  Otherwise, we will start the WG LC the RIB IM and
RIB DM have improved their text to indicate tunnels are not being created,
only used).     

Sue 

Details: 

The RIB Info Model(IM)/RIB Data Model(DM) is a pair of documents.   My
understanding of the WG Agreement (early 2015) is that we would keep the RIM
IM in sync with the for the first revision of the I2RS RIB.   (Unless the AD
for I2RS (Alia) provides me with the feedback these documents should merge).

The actions in the I2RS RIB are add/delete RIB, add/delete/update route, and
add/delete nexthop.  The I2RS RIB does not provide an add/delete tunnel.  

My understanding of the WG agreement which is distilled in the
draft-ietf-i2rs-rib-info-model-08.txt, is that the I2RS data models are not
creating tunnels.  The I2RS data models are referring to tunnels which are
created by other "hard" or "soft" provisioning.  My recollection is that the
WG felt other WG groups (such as rtgwg and MPLS) where charter to provision
these models.   This is similar to the interface yang creation.  Interface
configuration is created by the interfaces yang module.  

<WG Chair hat off> 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, December 03, 2015 11:34 AM
To: Acee Lindem (acee); Alia Atlas
Cc: Jeffrey Haas; [email-masked]; Susan Hares; Jeff Tantsura
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Folks,

<snip>

There is a non-converged discussion going on on draft-ietf-i2rs-
rib-data-model, the key statement seems to be:

<snip>

The authors intend to create a model that can be used to add, remove and
find information about the routes in the RIB (read series of RIBs).

Acee see is that adding this type of information to the RIB may very well be
used create (add) tunnels. After all the information manipulated in both
cases are very much the same.

If this very rudimentary analysis is correct, it should not be impossible to
add text to the document explaining what the intention is.

On one had I don't think it is motivated to not allow what the model is
intended for, on the other hand it should be perfectly what the intention is
(and what is is not).

/Loa

_______________________________________________

i2rs mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 3 Dec 2015 12:48:57 -0500

Loa: 

Sorry - it is appears I dropped one word in the email below.  It is inserted
in order to reduce confusion. 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Thursday, December 03, 2015 12:42 PM
To: 'Loa Andersson'; 'Acee Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email-masked]; 'Jeff Tantsura'
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Loa: 

<WG chair hat on> 

Since RIB IM has passed WG LC,  anyone wishes to propose that the RIB IM/DM
create tunnels should send me an indication they wish to create such a
proposal by 10/9/2015.  Otherwise, we will start the WG LC after the RIB IM
and RIB DM have improved their text to indicate tunnels are not being
created, only used.     

Sue 

Details: 

 

<WG Chair hat off> 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, December 03, 2015 11:34 AM
To: Acee Lindem (acee); Alia Atlas
Cc: Jeffrey Haas; [email-masked]; Susan Hares; Jeff Tantsura
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Folks,

<snip>

There is a non-converged discussion going on on draft-ietf-i2rs-
rib-data-model, the key statement seems to be:

<snip>

 

/Loa

i2rs mailing list

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 3 Dec 2015 13:12:42 -0500

I wonder if part of the problem here is the difference between the 
ingress and egress sides of tunnels, and the various degrees of 
dynamicity that tunnels support.

On the side where a packet is injected into a tunnel (ingress), almost 
the only state one needs is the encapsulation state.  So there is 
tendency to view the creation of this encapsulation state as equivalent 
to the creation of a tunnel.
And for the sending end of a unidirectional tunnel, it is.
In that sense, I think the RIB model can (whether intended or not) 
"create" a tunnel.

However, decapsulation state (on the egress side) frequently requires 
more state, that is note described by such RIB entries.  So this aspects 
tends to lead to the conclusion that creating RIB entries does not 
create tunnels.

And if one is thinking in terms of bi-directional tunnels (common for 
some technologies, uncommon for others), one tends to want to configure 
the two aspects together.  Which does not match what we are doing with 
the RIB model handling of tunnel encapsulation.

Trying to discuss all of this under the rubrik of "tunnel creation" 
tends to induce confusion.

Yours,
Joel

On 12/3/15 12:42 PM, Susan Hares wrote:
> Loa:
>
> <WG chair hat on>
>
> Thank you for your note.  The rudimentary analysis was incorrect.  The
> I2RS RIB Information Model (RIB IM) and RIB Data Model (RIB DM) is a
> pair of documents that explain the I2RS RIB. The authors of these models
> will need to improve the text to indicate tunnels are not being created.
>
> Since RIB IM has passed WG LC,  anyone wishes to propose that the RIB
> IM/DM create tunnels should send me an indication they wish to create
> such a proposal by 10/9/2015.  Otherwise, we will start the WG LC the
> RIB IM and RIB DM have improved their text to indicate tunnels are not
> being created, only used).
>
> Sue
>
> *Details: *
>
> understanding of the WG Agreement (early 2015) is that we would keep the
> RIM IM in sync with the for the first revision of the I2RS RIB.
> (Unless the AD for I2RS (Alia) provides me with the feedback these
> documents should merge).
>
> The actions in the I2RS RIB are add/delete RIB, add/delete/update route,
> and add/delete nexthop.  The I2RS RIB does not provide an add/delete
> tunnel.
>
> draft-ietf-i2rs-rib-info-model-08.txt, is that the I2RS data models are
> not creating tunnels.  The I2RS data models are referring to tunnels
> which are created by other "hard" or "soft" provisioning.  My
> recollection is that the WG felt other WG groups (such as rtgwg and
> MPLS) where charter to provision these models.   This is similar to the
> interface yang creation.  Interface configuration is created by the
> interfaces yang module.
>
> <WG Chair hat off>
>
> [email-masked] <mailto:[email-masked]>
>
> [email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 3 Dec 2015 22:21:27 +0000

I tend to agree with what Joel said. 

It worth noting that 
1. there is "Pre-established Tunnel" as in LSPs or PW and 
2. there is "Ingress node encapsulating outer address for overlay environment" as in TRILL or NVO3. 

Do we call both "tunnels"? or only the first one? 

Linda

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, December 03, 2015 12:13 PM
To: Susan Hares; 'Loa Andersson'; 'Acee Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email-masked]; 'Jeff Tantsura'
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

I wonder if part of the problem here is the difference between the ingress and egress sides of tunnels, and the various degrees of dynamicity that tunnels support.

On the side where a packet is injected into a tunnel (ingress), almost the only state one needs is the encapsulation state.  So there is tendency to view the creation of this encapsulation state as equivalent to the creation of a tunnel.
And for the sending end of a unidirectional tunnel, it is.
In that sense, I think the RIB model can (whether intended or not) "create" a tunnel.

However, decapsulation state (on the egress side) frequently requires more state, that is note described by such RIB entries.  So this aspects tends to lead to the conclusion that creating RIB entries does not create tunnels.

And if one is thinking in terms of bi-directional tunnels (common for some technologies, uncommon for others), one tends to want to configure the two aspects together.  Which does not match what we are doing with the RIB model handling of tunnel encapsulation.

Yours,
Joel

On 12/3/15 12:42 PM, Susan Hares wrote:
> pair of documents that explain the I2RS RIB. The authors of these 
> models will need to improve the text to indicate tunnels are not being created.
>
> understanding of the WG Agreement (early 2015) is that we would keep 
> the RIM IM in sync with the for the first revision of the I2RS RIB.
> The actions in the I2RS RIB are add/delete RIB, add/delete/update 
> route, and add/delete nexthop.  The I2RS RIB does not provide an 
> add/delete tunnel.
>
> draft-ietf-i2rs-rib-info-model-08.txt, is that the I2RS data models 
> are not creating tunnels.  The I2RS data models are referring to 
> tunnels which are created by other "hard" or "soft" provisioning.  My 
> well be used create (add) tunnels. After all the information 
> manipulated in both cases are very much the same.
>
> On one had I don't think it is motivated to not allow what the model 
> is intended for, on the other hand it should be perfectly what the

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 3 Dec 2015 20:31:18 -0500

Joel, Linda, Loa, and Acee: 

<wg chair hat off> 

You are right - the I2RS initial work considered the encapsulation
differently than the decapsulation.   

Do you think I2RS RIB needs to:
a) create the tunnel if it is not there, 
b) specification the encapsulation (currently specified) linked to a tunnel
interface, 
c) specify the decapsulation (somewhat specified) linked to a tunnel
interface,  
d) some of the above (a-c),
e) all of a-c? 

<wg chair hat on>
Acee - if this is the whole issue you were pointing to rather than just want
the I2RS RIB to link to specific tunnel creations, then I really
misunderstood your post.  For that, I apologize I misunderstood your post. I
want to thank you for raising the issue now - rather than in the next step
of the approval process. 
<wg chair hat off> 

Sue 

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]] 
Sent: Thursday, December 03, 2015 5:21 PM
To: Joel M. Halpern; Susan Hares; 'Loa Andersson'; 'Acee Lindem (acee)';
'Alia Atlas'
Cc: 'Jeffrey Haas'; [email-masked]; 'Jeff Tantsura'
Subject: RE: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

It worth noting that
1. there is "Pre-established Tunnel" as in LSPs or PW and 2. there is
"Ingress node encapsulating outer address for overlay environment" as in
TRILL or NVO3. 

Linda

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, December 03, 2015 12:13 PM
To: Susan Hares; 'Loa Andersson'; 'Acee Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email-masked]; 'Jeff Tantsura'
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

I wonder if part of the problem here is the difference between the ingress
and egress sides of tunnels, and the various degrees of dynamicity that
tunnels support.

On the side where a packet is injected into a tunnel (ingress), almost the
only state one needs is the encapsulation state.  So there is tendency to
view the creation of this encapsulation state as equivalent to the creation
of a tunnel.
And for the sending end of a unidirectional tunnel, it is.
In that sense, I think the RIB model can (whether intended or not) "create"
a tunnel.

However, decapsulation state (on the egress side) frequently requires more
state, that is note described by such RIB entries.  So this aspects tends to
lead to the conclusion that creating RIB entries does not create tunnels.

And if one is thinking in terms of bi-directional tunnels (common for some
technologies, uncommon for others), one tends to want to configure the two
aspects together.  Which does not match what we are doing with the RIB model
handling of tunnel encapsulation.

Yours,
Joel

---

From: Mach Chen <[email-masked]>
Date: Fri, 4 Dec 2015 02:12:55 +0000

Hi Sue,

Regarding a, for those non-pre-established tunnels, as Joel said, it could be considered that the tunnel-encap "creates" the tunnels. But someone can also thinks that we just use those tunnels although they are not created in advance (and actually no need to be created at all). For those pre-established tunnels, the tunnel-encap/decap really does not create the tunnels.

So, I think the key point should not be about whether the tunnel-encap/decap creates a tunnel, we should focus on the use cases. I think that the IM model did a great job on describing the use cases that are the motivations of the design of the model.

Best regards,
Mach

> Sent: Friday, December 04, 2015 9:31 AM
> To: Linda Dunbar; 'Joel M. Halpern'; 'Loa Andersson'; 'Acee Lindem (acee)'; 'Alia
> Atlas'
> c) specify the decapsulation (somewhat specified) linked to a tunnel interface,
> Acee - if this is the whole issue you were pointing to rather than just want the
> I2RS RIB to link to specific tunnel creations, then I really misunderstood your
> post.  For that, I apologize I misunderstood your post. I want to thank you for
> raising the issue now - rather than in the next step of the approval process.
> <wg chair hat off>
> 
> Sue
> 
> To: Joel M. Halpern; Susan Hares; 'Loa Andersson'; 'Acee Lindem (acee)'; 'Alia
> Atlas'
> 1. there is "Pre-established Tunnel" as in LSPs or PW and 2. there is "Ingress
> node encapsulating outer address for overlay environment" as in TRILL or
> NVO3.
> 
> I wonder if part of the problem here is the difference between the ingress and
> egress sides of tunnels, and the various degrees of dynamicity that tunnels
> support.
> 
> On the side where a packet is injected into a tunnel (ingress), almost the only
> state one needs is the encapsulation state.  So there is tendency to view the
> creation of this encapsulation state as equivalent to the creation of a tunnel.
> aspects together.  Which does not match what we are doing with the RIB
> model handling of tunnel encapsulation.
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 3 Dec 2015 22:02:17 -0500

Mach: 

I agree that the IM model did a great job of focusing on the use cases and
motivation.  However, it appears we have two cases: 

1) some people think the tunnel encap creates the tunnel if not established,

2) some people (like me) thought we were only using pre-established tunnels.
3) some people thought (like me) encap/decapsulation created a tunnel 

Since there is a debate among knowledgeable people, we need to go through
the use cases and clearly state what is happening per use cases.   And then
go through this and make it clear at each step. 

Perhaps you and other IM/DM can send me offline your view on each of the use
cases?  We can come back to the mail list with a proposal. 

Sue 
-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Mach Chen
Sent: Thursday, December 03, 2015 9:13 PM
To: Susan Hares; Linda Dunbar; 'Joel M. Halpern'; 'Loa Andersson'; 'Acee
Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email-masked]; 'Jeff Tantsura'
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Hi Sue,

Regarding a, for those non-pre-established tunnels, as Joel said, it could
be considered that the tunnel-encap "creates" the tunnels. But someone can
also thinks that we just use those tunnels although they are not created in
advance (and actually no need to be created at all). For those
pre-established tunnels, the tunnel-encap/decap really does not create the
tunnels.

So, I think the key point should not be about whether the tunnel-encap/decap
creates a tunnel, we should focus on the use cases. I think that the IM
model did a great job on describing the use cases that are the motivations
of the design of the model.

Best regards,
Mach

> To: Linda Dunbar; 'Joel M. Halpern'; 'Loa Andersson'; 'Acee Lindem 
> (acee)'; 'Alia Atlas'
> b) specification the encapsulation (currently specified) linked to a 
> tunnel interface,
> Acee - if this is the whole issue you were pointing to rather than 
> just want the I2RS RIB to link to specific tunnel creations, then I 
> really misunderstood your post.  For that, I apologize I misunderstood 
> your post. I want to thank you for raising the issue now - rather than in
the next step of the approval process.
> To: Joel M. Halpern; Susan Hares; 'Loa Andersson'; 'Acee Lindem 
> (acee)'; 'Alia Atlas'
> "Ingress node encapsulating outer address for overlay environment" as 
> in TRILL or NVO3.
> 
> tendency to view the creation of this encapsulation state as equivalent to
the creation of a tunnel.
> In that sense, I think the RIB model can (whether intended or not)
"create"
> more state, that is note described by such RIB entries.  So this 
> aspects tends to lead to the conclusion that creating RIB entries does not
create tunnels.
> some technologies, uncommon for others), one tends to want to 
> configure the two aspects together.  Which does not match what we are 
> doing with the RIB model handling of tunnel encapsulation.
> 
> > Thank you for your note.  The rudimentary analysis was incorrect.  
> > The I2RS RIB Information Model (RIB IM) and RIB Data Model (RIB DM) 
> > is a pair of documents that explain the I2RS RIB. The authors of 
> > these models will need to improve the text to indicate tunnels are 
> > not being
> created.
> >
> > Since RIB IM has passed WG LC,  anyone wishes to propose that the 
> > RIB IM/DM create tunnels should send me an indication they wish to 
> > create such a proposal by 10/9/2015.  Otherwise, we will start the 
> > WG LC the RIB IM and RIB DM have improved their text to indicate 
> > tunnels are not being created, only used).
> >
> > Sue
> >
> > *Details: *
> >
> > tunnels which are created by other "hard" or "soft" provisioning.  
> > My recollection is that the WG felt other WG groups (such as rtgwg and

---

From: Loa Andersson <[email-masked]>
Date: Fri, 4 Dec 2015 18:45:10 +0800

Folks,

Yes, agree - maybe "use existing tunnels" ?

/Loa

On 2015-12-04 14:13, Mach Chen wrote:
> It makes sense to me.
>> From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
>> Sent: Friday, December 04, 2015 11:52 AM
>> To: Susan Hares; Mach Chen; Linda Dunbar; 'Joel M. Halpern'; 'Loa Andersson';
>> 'Acee Lindem (acee)'; 'Alia Atlas'
>> I think we can just state that the model only intends to use tunnels.
>>
>> As the name suggests, "encap nexthop" only put on the encapsulation for
>> transmitting the packets, just like putting on an Ethernet header.
>>
>> Jeffrey
>>
>>> Sent: Thursday, December 03, 2015 10:02 PM
>>> To: 'Mach Chen' <[email-masked]>; 'Linda Dunbar'
>>> <[email-masked]>; 'Joel M. Halpern' <[email-masked]>;
>>> 'Loa Andersson' <[email-masked]>; 'Acee Lindem (acee)' <[email-masked]>;
>>> 'Alia Atlas' <[email-masked]>
>>> Cc: 'Jeffrey Haas' <[email-masked]>; [email-masked]; 'Jeff Tantsura'
>>> <[email-masked]>
>>> I agree that the IM model did a great job of focusing on the use cases
>>> and motivation.  However, it appears we have two cases:
>>>
>>> Perhaps you and other IM/DM can send me offline your view on each of
>>> the use cases?  We can come back to the mail list with a proposal.
>>>
>>> Sue
>>> To: Susan Hares; Linda Dunbar; 'Joel M. Halpern'; 'Loa Andersson';
>>> 'Acee Lindem (acee)'; 'Alia Atlas'
>>> Regarding a, for those non-pre-established tunnels, as Joel said, it
>>> could be considered that the tunnel-encap "creates" the tunnels. But
>>> someone can also thinks that we just use those tunnels although they
>>> are not created in advance (and actually no need to be created at
>>> all). For those pre-established tunnels, the tunnel-encap/decap really
>>> does not create the tunnels.
>>>
>>> So, I think the key point should not be about whether the tunnel-
>>> encap/decap creates a tunnel, we should focus on the use cases. I
>>> think that the IM model did a great job on describing the use cases
>>> that are the motivations of the design of the model.
>>>
>>> Best regards,
>>> Mach
>>>
>>>> really misunderstood your post.  For that, I apologize I
>>>> misunderstood your post. I want to thank you for raising the issue
>>>> now - rather than
>>> in
>>>> 1. there is "Pre-established Tunnel" as in LSPs or PW and 2. there
>>>> is "Ingress node encapsulating outer address for overlay
>>>> environment" as in TRILL or NVO3.
>>>>
>>>> On the side where a packet is injected into a tunnel (ingress),
>>>> almost the only state one needs is the encapsulation state.  So
>>>> there is tendency to view the creation of this encapsulation state
>>>> as equivalent
>>> to
>>>> However, decapsulation state (on the egress side) frequently
>>>> requires more state, that is note described by such RIB entries.  So
>>>> this aspects tends to lead to the conclusion that creating RIB
>>>> entries does
>>> not
>>> create tunnels.
>>>>
>>>> And if one is thinking in terms of bi-directional tunnels (common
>>>> for some technologies, uncommon for others), one tends to want to
>>>> configure the two aspects together.  Which does not match what we
>>>> are doing with the RIB model handling of tunnel encapsulation.
>>>>
>>>>> The I2RS RIB Information Model (RIB IM) and RIB Data Model (RIB
>>>>> DM) is a pair of documents that explain the I2RS RIB. The authors
>>>>> of these models will need to improve the text to indicate tunnels
>>>>> are not being
>>>> created.
>>>>>
>>>>> understanding of the WG Agreement (early 2015) is that we would
>>>>> keep the RIM IM in sync with the for the first revision of the I2RS RIB.
>>>>> draft-ietf-i2rs-rib-info-model-08.txt, is that the I2RS data
>>>>> models are not creating tunnels.  The I2RS data models are
>>>>> referring to tunnels which are created by other "hard" or "soft"
>> provisioning.
>>>>> interface yang creation.  Interface configuration is created by
>>>>> the interfaces yang module.
>>>>>
>>>>> <WG Chair hat off>
>>>>>
>>>>> The authors intend to create a model that can be used to add,
>>>>> remove and find information about the routes in the RIB (read series of
>> RIBs).
>>>>>
>>>>> Acee see is that adding this type of information to the RIB may
>>>>> very well be used create (add) tunnels. After all the information
>>>>> impossible to add text to the document explaining what the
>>>>> intention
>>> is.
>>>>>
>>>>> On one had I don't think it is motivated to not allow what the
>>>>> model is intended for, on the other hand it should be perfectly
>>>>> what the intention is (and what is is not).
>>>>>
>>>>> /Loa
>>>>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 4 Dec 2015 11:59:30 +0000

Hi Sue, 

On 12/3/15, 8:31 PM, "Susan Hares" <[email-masked]> wrote:

>tunnel

I think there are some encapsulations, e.g., MPLS, where the dynamic LSP
creation is well understood and others, e.g., definitely L2TPv3, where
more specification may be required than the encap and decap rules. As for
the API, I would side towards what Chris Bowers suggested as where the
next-hop refers to the tunnel abstraction. This is more a RIB API while
specifying the tunnel encap/decap is more a FIB API.

Thanks,
Acee

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 4 Dec 2015 03:51:46 +0000

As the name suggests, "encap nexthop" only put on the encapsulation for transmitting the packets, just like putting on an Ethernet header.

Jeffrey

> <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; 'Loa
> Andersson' <[email-masked]>; 'Acee Lindem (acee)' <[email-masked]>; 'Alia
> Atlas' <[email-masked]>
> encap/decap

---

From: Mach Chen <[email-masked]>
Date: Fri, 4 Dec 2015 06:13:45 +0000

It makes sense to me.

Best regards,
Mach

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 4 Dec 2015 07:47:55 -0500

<wg chair hat off> 
If we just state, "Just use" - I'm happy with this as well. 
Sue

-----Original Message-----
From: Mach Chen [mailto:[email-masked]] 
Sent: Friday, December 04, 2015 1:14 AM
To: Jeffrey (Zhaohui) Zhang; Susan Hares; Linda Dunbar; 'Joel M. Halpern';
'Loa Andersson'; 'Acee Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email-masked]; 'Jeff Tantsura'
Subject: RE: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

It makes sense to me.

Best regards,
Mach

> To: Susan Hares; Mach Chen; Linda Dunbar; 'Joel M. Halpern'; 'Loa 
> Andersson'; 'Acee Lindem (acee)'; 'Alia Atlas'
> As the name suggests, "encap nexthop" only put on the encapsulation 
> for transmitting the packets, just like putting on an Ethernet header.
> 
> Jeffrey
> 
> > I agree that the IM model did a great job of focusing on the use 
> > cases and motivation.  However, it appears we have two cases:
> >
> > all). For those pre-established tunnels, the tunnel-encap/decap 
> > really does not create the tunnels.
> >
> > > b) specification the encapsulation (currently specified) linked to 
> > > a tunnel interface,
> > > just want the I2RS RIB to link to specific tunnel creations, then 
> > > I really misunderstood your post.  For that, I apologize I 
> > > requires more state, that is note described by such RIB entries.  
> > > So this aspects tends to lead to the conclusion that creating RIB 
> > > entries does
> > not
> > create tunnels.
> > >
> > > > DM) is a pair of documents that explain the I2RS RIB. The 
> > > > authors of these models will need to improve the text to 
> > > > indicate tunnels are not being
> > > created.
> > > >
> > > > Since RIB IM has passed WG LC,  anyone wishes to propose that 
> > > > the RIB IM/DM create tunnels should send me an indication they 
> > > > wish to create such a proposal by 10/9/2015.  Otherwise, we will 
> > > > start the WG LC the RIB IM and RIB DM have improved their text 
> > > > to indicate tunnels are not being created, only used).
> > > >
> > > > Sue
> > > >
> > > > *Details: *
> > > >
> > > > (Unless the AD for I2RS (Alia) provides me with the feedback 
> > > > these documents should merge).
> > > >
> > > > The actions in the I2RS RIB are add/delete RIB, 
> > > > add/delete/update route, and add/delete nexthop.  The I2RS RIB 
> > > > does not provide an add/delete tunnel.
> > > >
> > > > very well be used create (add) tunnels. After all the 
> > > > information manipulated in both cases are very much the same.
> > > >

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 4 Dec 2015 07:49:19 -0500

WG: 

Does anyone disagree with just "use"?

Sue

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Friday, December 04, 2015 4:00 AM
To: Mach Chen; Jeffrey (Zhaohui) Zhang; Susan Hares; Linda Dunbar; 'Joel M.
Halpern'; 'Acee Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email-masked]; 'Jeff Tantsura'
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Folks,

Yes agree - maybe "use existing tunnels" ?

/Loa

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 4 Dec 2015 16:51:01 +0000

IMHO, All a-c should be included. But it is better to have different names for a) and b). 

Linda

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Thursday, December 03, 2015 7:31 PM
To: Linda Dunbar; 'Joel M. Halpern'; 'Loa Andersson'; 'Acee Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email-masked]; 'Jeff Tantsura'
Subject: RE: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

<wg chair hat off> 

b) specification the encapsulation (currently specified) linked to a tunnel interface,

<wg chair hat on>
Acee - if this is the whole issue you were pointing to rather than just want the I2RS RIB to link to specific tunnel creations, then I really misunderstood your post.  For that, I apologize I misunderstood your post. I want to thank you for raising the issue now - rather than in the next step of the approval process. 
<wg chair hat off> 

Sue 

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, December 03, 2015 5:21 PM
To: Joel M. Halpern; Susan Hares; 'Loa Andersson'; 'Acee Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email-masked]; 'Jeff Tantsura'
Subject: RE: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

It worth noting that
1. there is "Pre-established Tunnel" as in LSPs or PW and 2. there is "Ingress node encapsulating outer address for overlay environment" as in TRILL or NVO3. 

Linda

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, December 03, 2015 12:13 PM
To: Susan Hares; 'Loa Andersson'; 'Acee Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email-masked]; 'Jeff Tantsura'
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Yours,
Joel

---

From: Chris Bowers <[email-masked]>
Date: Fri, 4 Dec 2015 22:52:08 +0000

I2RS-WG and draft authors,

I'd like to suggest the following text as a starting point to explain what the RIB data model does and does not cover with respect to tunnel encap and decap and some rationale for those choices.  

----------------------

The current model allows one to program several types of tunnel encapsulation as nexthop-chains in the RIB.  The current model supports encapsulation for MPLS, IP-in-IP, GRE, NVGRE, and VXLAN.  One will note however that for tunnel decapsulation, only MPLS is supported.   The rationale for this disparity is described below.
 
Programming tunnel encapsulations in the RIB can be modeled well using nexthop-chains.  In general, programming arbitrary forms of tunnel decapsulation in the RIB requires additional constructs beyond what is in the current model.   The current data model does include one form of tunnel decapsulation, which is popping a single MPLS label.  Popping a single MPLS label can be handled using an mpls-route match with an mpls tunnel-decap-nexthop and a nexthop-chain entry.  Making this exception allows the model to cover important additional use cases, without increasing the complexity of this model.  
 
This data model also supports the use of logical tunnel interfaces as both egress and ingress interfaces.  An egress logical tunnel  interface can be used as a next-hop using egress-interface-nexthop in nexthop-base.  Specific forwarding behavior for a particular ingress logical tunnel interface can be specified using an interface-route route match condition. 
 
This data model does not attempt to model the creation or deletion of logical tunnel interfaces.  This model only uses logical tunnel interfaces that have been created by other mechanisms.  Logical tunnel interface creation could involve a different YANG model, or it could involve some other mechanism unrelated to NETCONF, but that is not covered in this draft.

-----------------------
Thanks,
Chris

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, December 04, 2015 10:51 AM
To: Susan Hares <[email-masked]>; 'Joel M. Halpern' <[email-masked]>; 'Loa Andersson' <[email-masked]>; 'Acee Lindem (acee)' <[email-masked]>; 'Alia Atlas' <[email-masked]>
Cc: 'Jeffrey Haas' <[email-masked]>; [email-masked]; 'Jeff Tantsura' <[email-masked]>
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Linda

-----Original Message-----
From: Susan Hares [mailto:[email-masked]]
Sent: Thursday, December 03, 2015 7:31 PM
To: Linda Dunbar; 'Joel M. Halpern'; 'Loa Andersson'; 'Acee Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email-masked]; 'Jeff Tantsura'
Subject: RE: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

<wg chair hat off> 

<wg chair hat on>

Sue 

-----Original Message-----
From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, December 03, 2015 5:21 PM
To: Joel M. Halpern; Susan Hares; 'Loa Andersson'; 'Acee Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email-masked]; 'Jeff Tantsura'
Subject: RE: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

It worth noting that

Linda

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, December 03, 2015 12:13 PM
To: Susan Hares; 'Loa Andersson'; 'Acee Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email-masked]; 'Jeff Tantsura'
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

Yours,
Joel

---

From: Loa Andersson <[email-masked]>
Date: Sat, 5 Dec 2015 14:11:25 +0800

Sue,

I think it is fine - a bit on the underspecified side, but will wo9rk.

/Loa

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 9 Dec 2015 01:42:29 +0000

Since the logical tunnel interface provides the tunnel capabilities in the
traditional manner, I don’t see the need for the tunnel encap
specification by precise specification of the packet headers. I know it is
a feature, but does anyone plan to support it?

I'd keep the ILM (Incoming Label Map) as a separate model rather than
attempting to model it as a RIB. An label to be imposed on unlabeled
traffic can be specified in the RIB (See RFC 3031 for details).

I don’t even understand how the tunnel decap is done? Are you trying to
match on a packet based on dest or source and then decap? Is anyone going
to implement anything like this?

On 12/4/15, 5:52 PM, "Chris Bowers" <[email-masked]> wrote:

>I'd like to suggest the following text as a starting point to explain
>what the RIB data model does and does not cover with respect to tunnel
>encap and decap and some rationale for those choices.
>
>----------------------
>
>The current model allows one to program several types of tunnel
>encapsulation as nexthop-chains in the RIB.  The current model supports
>encapsulation for MPLS, IP-in-IP, GRE, NVGRE, and VXLAN.  One will note
>however that for tunnel decapsulation, only MPLS is supported.   The
>rationale for this disparity is described below.
> 
>Programming tunnel encapsulations in the RIB can be modeled well using
>nexthop-chains.  In general, programming arbitrary forms of tunnel
>decapsulation in the RIB requires additional constructs beyond what is in
>the current model.   The current data model does include one form of
>tunnel decapsulation, which is popping a single MPLS label.  Popping a
>single MPLS label can be handled using an mpls-route match with an mpls
>tunnel-decap-nexthop and a nexthop-chain entry.  Making this exception
>allows the model to cover important additional use cases, without
>increasing the complexity of this model.
> 
>This data model also supports the use of logical tunnel interfaces as
>both egress and ingress interfaces.  An egress logical tunnel  interface
>can be used as a next-hop using egress-interface-nexthop in nexthop-base.
> Specific forwarding behavior for a particular ingress logical tunnel
>interface can be specified using an interface-route route match
>condition. 
> 
>This data model does not attempt to model the creation or deletion of
>logical tunnel interfaces.  This model only uses logical tunnel
>interfaces that have been created by other mechanisms.  Logical tunnel
>interface creation could involve a different YANG model, or it could
>involve some other mechanism unrelated to NETCONF, but that is not
>covered in this draft.
>
>-----------------------
>Thanks,
>Chris
>
>To: Susan Hares <[email-masked]>; 'Joel M. Halpern'
><[email-masked]>; 'Loa Andersson' <[email-masked]>; 'Acee Lindem (acee)'
><[email-masked]>; 'Alia Atlas' <[email-masked]>
>Acee - if this is the whole issue you were pointing to rather than just
>want the I2RS RIB to link to specific tunnel creations, then I really
>misunderstood your post.  For that, I apologize I misunderstood your
>post. I want to thank you for raising the issue now - rather than in the
>next step of the approval process.
><wg chair hat off>
>
>Sue 
>
>tends to lead to the conclusion that creating RIB entries does not create
>tunnels.
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 9 Dec 2015 12:26:23 +0000

Hi Acee,

> From: i2rs [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
> Sent: Tuesday, December 08, 2015 8:42 PM
> To: Chris Bowers <[email-masked]>; [email-masked]; Linda Dunbar
> <[email-masked]>; Susan Hares <[email-masked]>; 'Joel M.
> Halpern' <[email-masked]>; 'Loa Andersson' <[email-masked]>; 'Alia Atlas'
> <[email-masked]>
> Cc: 'Jeffrey Haas' <[email-masked]>; 'Jeff Tantsura'

Logical tunnel interface is ONE way to do it, but it may be too much to require an interface for every label stack to be imposed, e.g. in case of SR.

> traffic can be specified in the RIB (See RFC 3031 for details).

ILM is essentially/actually a RIB where the match condition is just a /20 label value, right?

> to implement anything like this?

Chris text below proposes to only define mpls decap in this model. In this case, the match is based on a label and the nexthop is decap, to pop the label and send it to a routing table (e.g., a route lookup in another table like in vpn case) or egress interface (which could be a logical tunnel egress interface that is associated with a routing instance table).

Jeffrey

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 9 Dec 2015 12:43:28 +0000

Hi Jeffrey, 

On 12/9/15, 7:26 AM, "Jeffrey (Zhaohui) Zhang" <[email-masked]> wrote:

>Logical tunnel interface is ONE way to do it, but it may be too much to
>require an interface for every label stack to be imposed, e.g. in case of
>SR.

I agree for MPLS. I think it is fine to impose label(s) for Next-Hop Label
Forwarding Entries (NHLFEs). I’m using RFC 3031 terminology. It is
precisely programming the tunnel packet headers that I don’t feel belongs
in the base RIB (especially when a very small but vocal minority is
advocating that these constructs should be added to the base NETMOD
ietf-routing draft).

Do you intend to put all these packet headers in the JUNOS RIB?

>ILM is essentially/actually a RIB where the match condition is just a /20

I guess you could view it this way but why not just use the existing ILM
abstraction (see RFC 3031).

>Chris text below proposes to only define mpls decap in this model. In
>this case, the match is based on a label and the nexthop is decap, to pop
>the label and send it to a routing table (e.g., a route lookup in another
>table like in vpn case) or egress interface (which could be a logical
>tunnel egress interface that is associated with a routing instance table).

I still don’t think we should have a separate model for the ILM consistent
with the model in every MPLS implementation.

Thanks,
Acee 

>>(acee)';
>>aspects
>>create
>>The
>> >> models will need to improve the text to indicate tunnels are not
>>being
>> >created.
>> >>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 9 Dec 2015 13:27:11 +0000

Hi Acee,

> From: Acee Lindem (acee) [mailto:[email-masked]]
> Sent: Wednesday, December 09, 2015 7:43 AM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Chris Bowers
> <[email-masked]>; [email-masked]; Linda Dunbar

Not sure if I can comment on specific implementation plan yet, but I would push for allowing that (not that we'd deprecate the interface based method - just use whatever is the most appropriate in different scenarios) :-)

> abstraction (see RFC 3031).

It could be asked the other way as well - since we've already have the RIB model, why not just use it instead of introducing another model :-)

> with the model in every MPLS implementation.

"think" of "don't think"?

While Chris' text proposes not to include other decap NHs in the base model, the only reason is that for those other tunnels we don't yet have a good match condition in a RIB (we'd need to match a lot more fields, not just a label or destination address). Other than that, there is no real difference between an mpls decap nh and a vxlan decap nh, at least conceptually.

In the future or in a private augmentation, one may add some additional match conditions to a RIB and then it is all set with the same RIB/route/nh framework. Even if we/someone do not use RIB for that purpose, it allows the same NH model to be used with either RIB based implementation or else.

Jeffrey

> just
> configure
> RIB
> My

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 9 Dec 2015 14:17:12 +0000

Hi Jeffrey, 

On 12/9/15, 8:27 AM, "Jeffrey (Zhaohui) Zhang" <[email-masked]> wrote:

>> >> Since the logical tunnel interface provides the tunnel capabilities
>>in
>> >>the
>> >> specification by precise specification of the packet headers. I know
>>it
>> >>is
>Not sure if I can comment on specific implementation plan yet, but I
>would push for allowing that (not that we'd deprecate the interface based
>method - just use whatever is the most appropriate in different
>scenarios) :-)

>> >ILM is essentially/actually a RIB where the match condition is just a
>>/20
>> >label value, right?
>> 
>It could be asked the other way as well - since we've already have the
>RIB model, why not just use it instead of introducing another model :-)

Well, right now the model is extremely flexible as there is nothing in it
to prevent mixing RIB entry types and next-hops types of any variety.
Clearly, this will not be implemented or deployed. The ILM is a well-known
abstraction and it should be its own programmable model.

>"think" of "don't think"?

Yeah - this is a typo. I meant “think”.

>
>While Chris' text proposes not to include other decap NHs in the base
>model, the only reason is that for those other tunnels we don't yet have
>a good match condition in a RIB (we'd need to match a lot more fields,
>not just a label or destination address). Other than that, there is no
>real difference between an mpls decap nh and a vxlan decap nh, at least
>conceptually.
>
>In the future or in a private augmentation, one may add some additional
>match conditions to a RIB and then it is all set with the same
>RIB/route/nh framework. Even if we/someone do not use RIB for that
>purpose, it allows the same NH model to be used with either RIB based
>implementation or else.

Maybe all these encap/decap/NH-chaining features should go into a separate
augmentation in a separate draft.

Acee 

>> >> >decapsulation in the RIB requires additional constructs beyond what
>>is
>> >>in
>>is
>>almost
>>requires
>>for
>>keep
>>models
>> >> >> MPLS) where charter to provision these models.   This is similar
>>to
>> >>the
>>remove
>>very
>>model

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 9 Dec 2015 23:11:00 +0000

Hi Acee,

<snipped some text>

> >method - just use whatever is the most appropriate in different

Yes we have done that for some, and are doing more.

> abstraction and it should be its own programmable model.

JUNOS does implement ILM as a RIB. It's not that the model is done that way just because we implemented it that way - logically ILM is no different from a RIB. The mapping between a RIB based model and an ILM based implementation should be straightforward so it makes sense to model it that way?

> augmentation in a separate draft.

To me, the currently defined tunnel encaps NHs, the reduced decap NH (just mpls), and NH-chaining are integral parts of the RIB model and they address many prevailing services. The concepts are not convoluted, and there are major implementations of the tables, routes, and NHs based on the concepts. Therefore, I think it's reasonable to keep them in the base model?

Thanks.
Jeffrey

> >> >> >IMHO, All a-c should be included. But it is better to have
> different
> >> >> >names for a) and b).
> >> >> >
> >> >> >Linda
> >> >> >
> a
> >> >> >post. I want to thank you for raising the issue now - rather than
> in
> >> >>the
> >> >> >> RIB IM and RIB DM have improved their text to indicate tunnels
> are
> >> >>not

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 15 Dec 2015 00:39:11 +0000

On 12/9/15, 6:11 PM, "Jeffrey (Zhaohui) Zhang" <[email-masked]> wrote:

>JUNOS does implement ILM as a RIB. It's not that the model is done that
>way just because we implemented it that way - logically ILM is no
>different from a RIB. The mapping between a RIB based model and an ILM
>based implementation should be straightforward so it makes sense to model
>it that way?
>
>To me, the currently defined tunnel encaps NHs, the reduced decap NH
>(just mpls), and NH-chaining are integral parts of the RIB model and they
>address many prevailing services. The concepts are not convoluted, and
>there are major implementations of the tables, routes, and NHs based on
>the concepts. Therefore, I think it's reasonable to keep them in the base
>model?

I think that, at best, the document is under-specified. At a minimum, the
following is needed:

    1. Pointers to RFCs describing the dynamic creation of the
corresponding tunnels of a description of the dynamic provisioning for
each type. This is not clear from the Information Model and I need not
remind you that this draft is past WG LC.
    2. The relationship between the specification of ephemeral labels,
tunnels, etc to the existing models in MPLS, RTG WG, etc.

Thanks,
Acee 

>> >> >> >encapsulation for MPLS, IP-in-IP, GRE, NVGRE, and VXLAN.  One
>>will
>> >> note
>> >> >> >single MPLS label can be handled using an mpls-route match with
>>an
>> >> mpls
>> >> >> >This data model also supports the use of logical tunnel
>>interfaces
>> >>as
>> >> >> >This data model does not attempt to model the creation or
>>deletion
>> >>of
>> >> >> >"Ingress node encapsulating outer address for overlay
>>environment"
>> >>as
>> >> >>in
>> >> >> >TRILL or NVO3.
>> >> >> >
>> >> >> >> such a proposal by 10/9/2015.  Otherwise, we will start the WG
>>LC
>> >> the
>> >> >> >> The RIB Info Model(IM)/RIB Data Model(DM) is a pair of
>>documents.
>> >> >>My
>>add/delete/update
>> >> >> >>  > I believe the intention of the model is clearly to
>>dynamically
>> >> >> >> create
>> >> >> >>
>> >> >> >>  > the tunnels.
>> >> >> >>
>> >> >> >>  >
>> >> >> >>
>> >> >> >> <snip>
>> >> >> >>
>> >> >> >> and find information about the routes in the RIB (read series
>>of
>> >> >>RIBs).
>> >> >> >>