Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03

From: Mach Chen <[email-masked]>
Date: Fri, 13 Nov 2015 09:36:58 +0000

Hi Chris,

Thanks for raising the issue and putting it on the I2RS wiki!

The current data model is aligned with the info model. Regarding the tunnel encap and decap, the info model is defined as is.

Regarding GRE, NvGRE or VxLAN decapsulation, in my understanding, they are actually IP tunnels, and the current model has already support IPv4/IPv6 IP tunnel decapsulation. Or maybe I missed something?

Best regards,
Mach

> From: Chris Bowers [mailto:[email-masked]]
> Sent: Thursday, November 12, 2015 11:28 AM
> To: Nitin Bahadur; [email-masked]; Mach Chen
> Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03
> 
> Nitin and Mach,
> 
> Thanks for your responses. Jeff Haas suggested to me that we keep track of
> issues for this on the I2RS wiki at:
> 
> http://trac.tools.ietf.org/wg/i2rs/trac/wiki/IssuesRibDataModel
> 
> So far, I posted one issue that I think needs more discussion.  I copied it
> below.  Please feel free to edit the Wiki as part of the discussion as well.
> Issue 1: Should we define tunnel encapsulation and tunnel decapsulation as
> next-hops in the RIB data model?
> The RIB data model can model some types of encapsulation and decapsulation
> by treating encapsulation and decapsulation as next-hops. For encapsulation, a
> route is paired with a tunnel-encap-nexthop. For decapsulation, an initial route
> match condition is paired with a next-hop chain which consists of a
> tunnel-decap-nexthop and another nexthop such as rib-name-nexthop or an
> egress-interface-nexthop.
> 1) It is not clear if this model for decapsulation supports all useful encapsulation
> types. For example, it is not clear that the route-match-types currently in
> draft-ietf-i2rs-rib-data-model-03 can be used to select traffic for GRE, NVGRE,
> and VXLAN decapsulation. 
> One could consider extending the route-match-types
> to include the header information needed to identify other encapsulation types.
> However, this may also be a sign that the basic approach should be
> re-evaluated.
> 2) Does treating tunnel-encap and tunnel-decap as next-hops result in a data
> model that is easy to use for someone trying to program network forwarding
> behavior? From the point-of-view of a user of the data model, modeling tunnels
> as interfaces seems more useful. Treating tunnel decapsulation as a type of
> ingress interface and tunnel encapsulation as a type of egress interface would
> fit with the current RIB model (which already has the concept of an
> interface-route and an interface-nexthop.) And it would reduce the amount of
> next-hop chaining that is required to make tunnels work compared to the
> current model.
> Thanks,
> Chris
> 
> 
> From: Nitin Bahadur [mailto:[email-masked]]
> Sent: Monday, November 09, 2015 5:53 PM
> To: Chris Bowers <[email-masked]>; [email-masked]; Mach Chen
> <[email-masked]>
> Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03
> 
> Hi Chris,
> 
>       Thanks for spending time on the spec. Please see NB> below for some
> of the issues you have raised.
> 
> ------------------------
> The description of the nexthop-preference-def (see below) is confusing.  First,
> I assume there is an error in the text since the example of downloading
> primary/standby/tertiary nexthops to the FIB should presumably select three
> nexthops, but the text refers to selecting the two resolved nexthops with the
> highest preference .
> 
> NB> That is a typo IMO.
> 
> More fundamentally, this example seems to  imply that only two next-hops
> will get downloaded to the FIB, whereas  one could imagine an
> implementation that uses three, four, five or more nexthops of different
> preferences.  If hardware supports more than two next-hop preferences
> being installed in the FIB, then what is the mechanism for the client to learn
> how many preference values are supported?  This should all be made clearer
> in the text.
> 
>     typedef nexthop-preference-def {
>        type uint8 {
>          range "1..99";
>        }
>        description
>          "Nexthop-preference is used for protection schemes.
>           It is an integer value between 1 and 99.  A lower
>           value indicates higher preference.  To download a
>           primary/standby/tertiary group to the FIB, the
>           nexthops that are resolved and have two highest
>           preferences are selected.";
>      }
> 
> NB> Would something like this be preferable
> "To download N nexthops to the FIB, the N nexthops with the lowest value
> are selected".
> 
> 
> ------------------------
> If I understand the yang syntax and semantics correctly, the "nh-add" RPC
> creates a nexthop in a given RIB that is not associated with any match
> condition on a route.  I assume the intention is to create a nexthop with a
> nexthop-id but not associated with any prefix that can then be referenced by
> multiple other route match conditions.   This seems like a reasonable thing to
> do.  However, I can see two possible issues with this.
> 
> The first issue is that the structure of the data model doesn't seem to not
> allow this.   "grouping route" uses "grouping route-prefix"  next to
> "container next-hop".  It appears to me that as currently written "container
> match" in  "grouping route-prefix" is a mandatory node based on section 3.1
> of RFC6020 , since the "mandatory" statements below choice/cases cascade
> up to the container.    So the current form of the "nh-add" RPC may not be
> consistent with the data model as currently defined.
> 
> The second issue is that creating a next-hop without an associated match
> appears to differ from the RIB grammar defined in section 6 of
> draft-ietf-i2rs-rib-info-model-08. In the RIB info model, it seems that the only
> way for a <nexthop> to appear is together with a <match>.
> 
>   <route> ::= <match> <nexthop>
>               [<route-attributes>]
>               [<route-vendor-attributes>]
> 
> 
> NB> I'm not sure if I agree with the creation of nexthop discrepancy. A nexthop
> can be created independently and then in the <route>, you can reference the
> relevant nexthop-id.
> 
> <route> ::= <match> <nexthop>
>                   = <match> <nexthop-base>
>                   = <match> <NEXTHOP_ID>
> 
> 
> ------------------------
> Treating tunnel-decap as a type of next-hop doesn't make sense to me. I
> assume the desire to include tunnel-decap as well as tunnel-encap is to have a
> usable stand-alone data model module which to deal with some use cases
> without having to rely on another module that defines
> tunnel-decap.  However, the result doesn't make sense.  I think the most
> common scenario involving routers would be to install a route on router A for
> prefix P whose nexthop is a tunnel-encap whose destination is router B.   One
> router B one would need to install a corresponding tunnel-decap whose source
> is router A.  The most common scenario is then that router B does a normal
> route lookup on the decapsulated packet independent of the interface it
> entered on.
> 
> I don't see how this most common use case would be handled with the
> tunnel-decap next-hop in this document.
> 
> NB> On router B, <match> condition would be the incoming label and the
> "action" to be taken on that would be "decap" the MPLS label. And you can
> chain that with <RIB_NAME> to say continue the route lookup in say "inet.0".
> The draft says, "RIB_NAME: A nexthop pointing to a RIB indicates that the
> route
>       lookup needs to continue in the specified RIB."
> 
> NB> Does that address your concern?
> 
> 
> Section 7.2.5. of draft-ietf-i2rs-rib-info-model-08 gives an example usage for
> tunnel-decap where the tunnel-decap nexthop is used to pop an MPLS label and
> send the traffic out an egress interface next-hop.  This example is not the
> most common scenario. And if we want to accomplish this scenario
> of  decapsulating and sending to a particular nexthop, it makes more sense to
> treat tunnel-decap as a route match condition similar to an interface-route in
> the existing data model.  However, I think the model should be able to handle
> the more common scenario described above when traffic needs to be
> decapsulated and routed based on a normal route lookup.
> 
> Treating tunnel-decap as a next-hop type really makes no sense to me.  I think
> this aspect of the model should be changed.
> 
> NB> See above comment.
> 
> Thanks
> Nitin

---

From: Chris Bowers <[email-masked]>
Date: Sat, 14 Nov 2015 16:37:55 +0000

Mach,

I may be overlooking something, but I don't see how one can use the elements in the current data model to configure a router to decapsulate GRE, NVGRE or VxLAN in the following scenario.
  
Assume we have 4 types of tunneled traffic arriving at the router with the same source and destination IP address.  The decapsulated packets need to be processed by 4  different rib-name-nexthops depending on information in the encapsulation header.  In this example, the four different tunneled traffic types are IP-in-IP, IP in GRE, and VxLAN encapsulated traffic with two different VNIs, so the different packet headers look like this (only the relevant fields are shown):

1) ip src=1.1.1.1, ip dest=2.2.2.2,protocol number=4 , inner IP packet
2) ip src=1.1.1.1, ip dest=2.2.2.2,protocol number=47, inner IP packet
3) ip src=1.1.1.1, ip dest=2.2.2.2,protocol number=17, udp dest port= 4789, VNI=920, inner Ethernet frame
4) ip src=1.1.1.1, ip dest=2.2.2.2,protocol number=17, udp dest port= 4789, VNI=921, inner Ethernet frame

There are a few ways that one might think about accomplishing decapsulation of these packets into different rib-name-nexthops using the next-hop chaining in the data model.  However, regardless of the particular choice of how to chain next-hops and route matches, at some point one needs to be able to do a route match based on IP protocol number to distinguish between IP in IP, GRE, and UDP.  In addition, one needs to be able to match on UDP destination port to distinguish VxLAN from other UDP traffic with the same src/dest address.  Finally one needs to be able to match on VNI in order to be able to demultiplex the two streams of VxLAN traffic into different rib-name-nexthops.

I don't see that these values (IP protocol number, UDP dest port, or VNI) are currently included in the route match conditions in the model, so I don't see how the current data model can be used to configure a router to distinguish between these traffic types while performing decapsulation.

If the above analysis is correct, then one might consider adding additional route match conditions to cover these decapsulation cases.  However,  it may also make sense to consider other approaches to modeling tunnels.

Thanks,
Chris  

-----Original Message-----
From: Mach Chen [mailto:[email-masked]] 
Sent: Friday, November 13, 2015 3:37 AM
To: Chris Bowers <[email-masked]>; Nitin Bahadur <[email-masked]>; [email-masked]
Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03

Hi Chris,

Best regards,
Mach

> Thanks for your responses. Jeff Haas suggested to me that we keep 
> track of issues for this on the I2RS wiki at:
> 
> So far, I posted one issue that I think needs more discussion.  I 
> copied it below.  Please feel free to edit the Wiki as part of the discussion as well.
> Issue 1: Should we define tunnel encapsulation and tunnel 
> decapsulation as next-hops in the RIB data model?
> The RIB data model can model some types of encapsulation and 
> decapsulation by treating encapsulation and decapsulation as 
> next-hops. For encapsulation, a route is paired with a 
> tunnel-encap-nexthop. For decapsulation, an initial route match 
> condition is paired with a next-hop chain which consists of a 
> tunnel-decap-nexthop and another nexthop such as rib-name-nexthop or an egress-interface-nexthop.
> 1) It is not clear if this model for decapsulation supports all useful 
> encapsulation types. For example, it is not clear that the 
> route-match-types currently in
> draft-ietf-i2rs-rib-data-model-03 can be used to select traffic for 
> GRE, NVGRE, and VXLAN decapsulation.
> One could consider extending the route-match-types to include the 
> header information needed to identify other encapsulation types.
> 2) Does treating tunnel-encap and tunnel-decap as next-hops result in 
> a data model that is easy to use for someone trying to program network 
> forwarding behavior? From the point-of-view of a user of the data 
> model, modeling tunnels as interfaces seems more useful. Treating 
> tunnel decapsulation as a type of ingress interface and tunnel 
> encapsulation as a type of egress interface would fit with the current 
> RIB model (which already has the concept of an interface-route and an 
> interface-nexthop.) And it would reduce the amount of next-hop 
> chaining that is required to make tunnels work compared to the current model.
> Thanks,
> Chris
> 
> 
>       Thanks for spending time on the spec. Please see NB> below for 
> some of the issues you have raised.
> 
> ------------------------
> The description of the nexthop-preference-def (see below) is 
> confusing.  First, I assume there is an error in the text since the 
> example of downloading primary/standby/tertiary nexthops to the FIB 
> should presumably select three nexthops, but the text refers to 
> selecting the two resolved nexthops with the highest preference .
> 
> NB> That is a typo IMO.
> 
> More fundamentally, this example seems to  imply that only two 
> next-hops will get downloaded to the FIB, whereas  one could imagine 
> an implementation that uses three, four, five or more nexthops of 
> different preferences.  If hardware supports more than two next-hop 
> preferences being installed in the FIB, then what is the mechanism for 
> the client to learn how many preference values are supported?  This 
> should all be made clearer in the text.
> 
> "To download N nexthops to the FIB, the N nexthops with the lowest 
> value are selected".
> 
> 
> ------------------------
> If I understand the yang syntax and semantics correctly, the "nh-add" 
> RPC creates a nexthop in a given RIB that is not associated with any 
> match condition on a route.  I assume the intention is to create a 
> nexthop with a nexthop-id but not associated with any prefix that can 
> then be referenced by multiple other route match conditions.   This 
> seems like a reasonable thing to do.  However, I can see two possible issues with this.
> 
> The first issue is that the structure of the data model doesn't seem 
> to not allow this.   "grouping route" uses "grouping route-prefix"  
> next to "container next-hop".  It appears to me that as currently 
> written "container match" in  "grouping route-prefix" is a mandatory 
> node based on section 3.1 of RFC6020 , since the "mandatory" 
> statements below choice/cases cascade up to the container.    So the 
> current form of the "nh-add" RPC may not be consistent with the data model as currently defined.
> 
> The second issue is that creating a next-hop without an associated 
> match appears to differ from the RIB grammar defined in section 6 of 
> draft-ietf-i2rs-rib-info-model-08. In the RIB info model, it seems 
> that the only way for a <nexthop> to appear is together with a <match>.
> 
> NB> I'm not sure if I agree with the creation of nexthop discrepancy. 
> NB> A nexthop
> can be created independently and then in the <route>, you can 
> reference the relevant nexthop-id.
> 
> Treating tunnel-decap as a type of next-hop doesn't make sense to me. 
> I assume the desire to include tunnel-decap as well as tunnel-encap is 
> to have a usable stand-alone data model module which to deal with some 
> use cases without having to rely on another module that defines 
> tunnel-decap.  However, the result doesn't make sense.  I think the 
> most common scenario involving routers would be to install a route on 
> router A for prefix P whose nexthop is a tunnel-encap whose 
> destination is router B.   One router B one would need to install a 
> corresponding tunnel-decap whose source is router A.  The most common 
> scenario is then that router B does a normal route lookup on the 
> decapsulated packet independent of the interface it entered on.
> 
> "action" to be taken on that would be "decap" the MPLS label. And you 
> can chain that with <RIB_NAME> to say continue the route lookup in say "inet.0".
> The draft says, "RIB_NAME: A nexthop pointing to a RIB indicates that 
> the route
> Section 7.2.5. of draft-ietf-i2rs-rib-info-model-08 gives an example 
> usage for tunnel-decap where the tunnel-decap nexthop is used to pop 
> an MPLS label and send the traffic out an egress interface next-hop.  
> This example is not the most common scenario. And if we want to 
> accomplish this scenario of  decapsulating and sending to a particular 
> nexthop, it makes more sense to treat tunnel-decap as a route match 
> condition similar to an interface-route in the existing data model.  
> However, I think the model should be able to handle the more common 
> scenario described above when traffic needs to be decapsulated and routed based on a normal route lookup.
> 
> Treating tunnel-decap as a next-hop type really makes no sense to me.  
> I think this aspect of the model should be changed.
> 
> NB> See above comment.
> 
> Thanks
> Nitin

---

From: Mach Chen <[email-masked]>
Date: Mon, 16 Nov 2015 03:05:31 +0000

Hi Chris,

Much thanks for the detailed explanation!

In my understanding, the I2RS intends to leverage the existing RIB design. Regarding to tunnel decap, normally, the protocol number and udp port belong to the protocol stack process, they are not parts of the rib. As for the VNI and VSI, since they are new, the implementations may be different. But they may also not be necessary as part of a route to be installed in the rib. They can just be decapsulated by the VxLan/NvGRE protocol stack process and used as an identifier to find the next rib (e.g., the MAC rib), and then perform another rib lookup. If I am wrong, please correct me.

Regarding to the suggestion to change tunnel-decap to tunnel-interface, this will require not only to modify the current data model, but to modify the info model that has already passed the WG last call. I hope to hear the opinions of the WG.

Best regards,
Mach

> Sent: Sunday, November 15, 2015 12:38 AM
> To: Mach Chen; Nitin Bahadur; [email-masked]
> I may be overlooking something, but I don't see how one can use the elements
> in the current data model to configure a router to decapsulate GRE, NVGRE or
> VxLAN in the following scenario.
> 
> Assume we have 4 types of tunneled traffic arriving at the router with the same
> source and destination IP address.  The decapsulated packets need to be
> processed by 4  different rib-name-nexthops depending on information in the
> encapsulation header.  In this example, the four different tunneled traffic
> types are IP-in-IP, IP in GRE, and VxLAN encapsulated traffic with two different
> VNIs, so the different packet headers look like this (only the relevant fields are
> shown):
> 
> There are a few ways that one might think about accomplishing decapsulation
> of these packets into different rib-name-nexthops using the next-hop chaining
> in the data model.  However, regardless of the particular choice of how to
> chain next-hops and route matches, at some point one needs to be able to do a
> route match based on IP protocol number to distinguish between IP in IP, GRE,
> and UDP.  In addition, one needs to be able to match on UDP destination port
> to distinguish VxLAN from other UDP traffic with the same src/dest address.
> Finally one needs to be able to match on VNI in order to be able to demultiplex
> the two streams of VxLAN traffic into different rib-name-nexthops.
> 
> I don't see that these values (IP protocol number, UDP dest port, or VNI) are
> currently included in the route match conditions in the model, so I don't see
> how the current data model can be used to configure a router to distinguish
> between these traffic types while performing decapsulation.
> 
> If the above analysis is correct, then one might consider adding additional route
> match conditions to cover these decapsulation cases.  However,  it may also
> make sense to consider other approaches to modeling tunnels.
> 
> Thanks,
> Chris
> 
> The current data model is aligned with the info model. Regarding the tunnel
> encap and decap, the info model is defined as is.
> 
> Regarding GRE, NvGRE or VxLAN decapsulation, in my understanding, they are
> actually IP tunnels, and the current model has already support IPv4/IPv6 IP
> tunnel decapsulation. Or maybe I missed something?
> 
> Best regards,
> Mach
>

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 16 Nov 2015 09:56:34 -0800

Chris,

   I agree with Mach¹s comment. To actually decap VxLan and do something
intelligently, one needs something like a firewall rule. There is no
routing protocol that provides rules on decap of VxLan packets. So the RIB
in general does not contain this information in today¹s routers (AFAIK).

IMO, the content for this should go into
http://tools.ietf.org/id/draft-kini-i2rs-fb-rib-info-model-02.txt

Thanks
Nitin

On 11/15/15, 7:05 PM, "Mach Chen" <[email-masked]> wrote:

>In my understanding, the I2RS intends to leverage the existing RIB
>design. Regarding to tunnel decap, normally, the protocol number and udp
>port belong to the protocol stack process, they are not parts of the rib.
>As for the VNI and VSI, since they are new, the implementations may be
>different. But they may also not be necessary as part of a route to be
>installed in the rib. They can just be decapsulated by the VxLan/NvGRE
>protocol stack process and used as an identifier to find the next rib
>(e.g., the MAC rib), and then perform another rib lookup. If I am wrong,
>please correct me.
>
>Regarding to the suggestion to change tunnel-decap to tunnel-interface,
>this will require not only to modify the current data model, but to
>modify the info model that has already passed the WG last call. I hope to
>hear the opinions of the WG.
>
>Best regards,
>Mach
>
>> 3) ip src=1.1.1.1, ip dest=2.2.2.2,protocol number=17, udp dest port=
>>4789,
>> VNI=920, inner Ethernet frame
>> 4) ip src=1.1.1.1, ip dest=2.2.2.2,protocol number=17, udp dest port=
>>4789,
>> VNI=921, inner Ethernet frame
>> 
>> > copied it below.  Please feel free to edit the Wiki as part of the
>>discussion as
>> well.
>> > seems like a reasonable thing to do.  However, I can see two possible
>>issues
>> with this.
>> >
>> > current form of the "nh-add" RPC may not be consistent with the data
>>model
>> as currently defined.
>> >
>> > scenario described above when traffic needs to be decapsulated and
>>routed
>> based on a normal route lookup.
>> >

---

From: Chris Bowers <[email-masked]>
Date: Mon, 16 Nov 2015 18:30:51 +0000

Nitin and Mach,

I think we are in agreement that VXLAN decapsulation should NOT be included in the rib-data-model.

I think we disagree about whether or not we should include VXLAN _encapsulation_ (which is currently included in the draft) as part of the rib data model.  To be clear, I do not think that either VXLAN  encapsulation or decapsulation should be part of the rib data model.  

I find it odd that the current data model provides the ability to configure encap, but not decap, for VXLAN.  This would require the user of the data model to configure VXLAN tunnel-encap  using one data model and vxlan-decap using another data model.   I think this is perhaps an indication that VXLAN encap does not belong in the RIB data model either.

Thanks,
Chris

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Monday, November 16, 2015 11:57 AM
To: Mach Chen <[email-masked]>; Chris Bowers <[email-masked]>; [email-masked]
Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03

Chris,

   I agree with Mach¹s comment. To actually decap VxLan and do something intelligently, one needs something like a firewall rule. There is no routing protocol that provides rules on decap of VxLan packets. So the RIB in general does not contain this information in today¹s routers (AFAIK).

IMO, the content for this should go into http://tools.ietf.org/id/draft-kini-i2rs-fb-rib-info-model-02.txt

Thanks
Nitin

On 11/15/15, 7:05 PM, "Mach Chen" <[email-masked]> wrote:

>design. Regarding to tunnel decap, normally, the protocol number and 
>udp port belong to the protocol stack process, they are not parts of the rib.
>(e.g., the MAC rib), and then perform another rib lookup. If I am 
>wrong, please correct me.
>
>modify the info model that has already passed the WG last call. I hope 
>to hear the opinions of the WG.
>
>Best regards,
>Mach
>
>> I may be overlooking something, but I don't see how one can use the 
>>elements  in the current data model to configure a router to 
>>decapsulate GRE, NVGRE or  VxLAN in the following scenario.
>> 
>> Assume we have 4 types of tunneled traffic arriving at the router 
>>with the same  source and destination IP address.  The decapsulated 
>>packets need to be  processed by 4  different rib-name-nexthops 
>>depending on information in the  encapsulation header.  In this 
>>example, the four different tunneled traffic  types are IP-in-IP, IP 
>>in GRE, and VxLAN encapsulated traffic with two different  VNIs, so 
>>the different packet headers look like this (only the relevant fields 
>>are
>> shown):
>> 
>>4789,  VNI=920, inner Ethernet frame
>>4789,  VNI=921, inner Ethernet frame
>> 
>> There are a few ways that one might think about accomplishing 
>>decapsulation  of these packets into different rib-name-nexthops using 
>>the next-hop chaining  in the data model.  However, regardless of the 
>>particular choice of how to  chain next-hops and route matches, at 
>>some point one needs to be able to do a  route match based on IP 
>>protocol number to distinguish between IP in IP, GRE,  and UDP.  In 
>>addition, one needs to be able to match on UDP destination port  to 
>>distinguish VxLAN from other UDP traffic with the same src/dest 
>>address.
>> Finally one needs to be able to match on VNI in order to be able to 
>>demultiplex  the two streams of VxLAN traffic into different 
>>rib-name-nexthops.
>> 
>> currently included in the route match conditions in the model, so I 
>>don't see  how the current data model can be used to configure a 
>>router to distinguish  between these traffic types while performing 
>>decapsulation.
>> 
>> If the above analysis is correct, then one might consider adding 
>>additional route  match conditions to cover these decapsulation cases.  
>>However,  it may also  make sense to consider other approaches to 
>>modeling tunnels.
>> 
>> Thanks,
>> Chris
>> 
>> The current data model is aligned with the info model. Regarding the 
>>tunnel  encap and decap, the info model is defined as is.
>> 
>> Regarding GRE, NvGRE or VxLAN decapsulation, in my understanding, 
>>they are  actually IP tunnels, and the current model has already 
>>support
>>IPv4/IPv6 IP
>> > tunnel-decap-nexthop and another nexthop such as rib-name-nexthop 
>> > or
>>an
>> > 1) It is not clear if this model for decapsulation supports all 
>> > useful encapsulation types. For example, it is not clear that the 
>> > 2) Does treating tunnel-encap and tunnel-decap as next-hops result 
>> > in a data model that is easy to use for someone trying to program 
>> > network forwarding behavior? From the point-of-view of a user of 
>> > the data model, modeling tunnels as interfaces seems more useful. 
>> > Treating tunnel decapsulation as a type of ingress interface and 
>> > tunnel encapsulation as a type of egress interface would fit with 
>> > the current RIB model (which already has the concept of an 
>> > interface-route and an
>> > chaining that is required to make tunnels work compared to the 
>> > current
>> model.
>> > Thanks,
>> > Chris
>> >
>> >
>> >       Thanks for spending time on the spec. Please see NB> below 
>> > for some of the issues you have raised.
>> >
>> > ------------------------
>> > next-hops will get downloaded to the FIB, whereas  one could 
>> > imagine an implementation that uses three, four, five or more 
>> > nexthops of different preferences.  If hardware supports more than 
>> > two next-hop preferences being installed in the FIB, then what is 
>> > the mechanism for the client to learn how many preference values 
>> > are supported?  This should all be made clearer in the text.
>> >
>> > RPC creates a nexthop in a given RIB that is not associated with 
>> > any match condition on a route.  I assume the intention is to 
>> > create a nexthop with a nexthop-id but not associated with any prefix that can
>> > written "container match" in  "grouping route-prefix" is a 
>> > mandatory node based on section 3.1 of RFC6020 , since the "mandatory"
>> > match appears to differ from the RIB grammar defined in section 6 
>> > of draft-ietf-i2rs-rib-info-model-08. In the RIB info model, it 
>> > seems that the only way for a <nexthop> to appear is together with 
>> > a
>><match>.
>> >
>> > I assume the desire to include tunnel-decap as well as tunnel-encap 
>> > is to have a usable stand-alone data model module which to deal 
>> > with some use cases without having to rely on another module that 
>> > defines tunnel-decap.  However, the result doesn't make sense.  I 
>> > think the most common scenario involving routers would be to 
>> > install a route on router A for prefix P whose nexthop is a tunnel-encap whose
>> > corresponding tunnel-decap whose source is router A.  The most 
>> > common scenario is then that router B does a normal route lookup on 
>> > the decapsulated packet independent of the interface it entered on.
>> >
>> > NB> On router B, <match> condition would be the incoming label and 
>> > NB> the
>> > "action" to be taken on that would be "decap" the MPLS label. And 
>> > you can chain that with <RIB_NAME> to say continue the route lookup 
>> > in say
>> "inet.0".
>> > The draft says, "RIB_NAME: A nexthop pointing to a RIB indicates 
>> > that the route
>> > Section 7.2.5. of draft-ietf-i2rs-rib-info-model-08 gives an 
>> > example usage for tunnel-decap where the tunnel-decap nexthop is 
>> > used to pop an MPLS label and send the traffic out an egress interface next-hop.
>> > accomplish this scenario of  decapsulating and sending to a 
>> > particular nexthop, it makes more sense to treat tunnel-decap as a 
>> > route match condition similar to an interface-route in the existing data model.

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 16 Nov 2015 11:55:05 -0800

>I find it odd that the current data model provides the ability to
>configure encap, but not decap, for VXLAN.  This would require the user
>of the data model to configure VXLAN tunnel-encap  using one data model
>and vxlan-decap using another data model.   I think this is perhaps an
>indication that VXLAN encap does not belong in the RIB data model either.

I¹ll buy that argument. And I believe we can extend that argument to GRE &
NVGRE as well.

Anyone on the list have comments related to this?

Thanks
Nitin

---

From: "Manish Kumar (manishkr)" <[email-masked]>
Date: Mon, 16 Nov 2015 20:17:47 +0000

Encap/Decap belong to a different layer (actually one that ties two layers
together) and RIB doesn’t look the right place for encap/decap to me.

Thanks,
Manish

On 17/11/15 1:25 am, "i2rs on behalf of Nitin Bahadur"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>i2rs mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i2rs

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 16 Nov 2015 20:58:08 +0000

+1, 

IMHO, Encap/Decap should be part of Tunnel. 

Linda 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Manish Kumar (manishkr)
Sent: Monday, November 16, 2015 2:18 PM
To: Nitin Bahadur; Chris Bowers; Mach Chen; [email-masked]
Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03

Encap/Decap belong to a different layer (actually one that ties two layers
together) and RIB doesn't look the right place for encap/decap to me.

Thanks,
Manish

On 17/11/15 1:25 am, "i2rs on behalf of Nitin Bahadur"
<[email-masked] on behalf of [email-masked]> wrote:

>>configure encap, but not decap, for VXLAN.  This would require the 
>>user of the data model to configure VXLAN tunnel-encap  using one data model
>I¹ll buy that argument. And I believe we can extend that argument to 
>GRE & NVGRE as well.
>

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 16 Nov 2015 13:16:16 -0800

We need a minimal tunnel encap for MPLS…so that mpls labels can be pushed
and popped. So I do want to keep basic (aka mpls) tunnel encap/decap in
this draft. This will also enable development of solutions based on
Segment routing (or whatever it’s called these days).

Nitin

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 16 Nov 2015 22:00:01 +0000

Current RIB has ieee-mac RIB, which could use vxlan encap nexthops.

BTW, mpls encap/decap is needed even for non-segmenting scenarios - plain old l3vpn, vpls, or evpn with mpls data plane.

Jeffrey

> From: i2rs [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> Sent: Monday, November 16, 2015 4:16 PM
> To: Manish Kumar (manishkr) <[email-masked]>; Chris Bowers
> <[email-masked]>; Mach Chen <[email-masked]>; [email-masked]
> We need a minimal tunnel encap for MPLS.so that mpls labels can be pushed
> Segment routing (or whatever it's called these days).
> 
> Nitin
>

---

From: Mach Chen <[email-masked]>
Date: Wed, 18 Nov 2015 08:36:34 +0000

Indeed, I agree with Jeffery here.

I'd suggest we keep the current model as is and address the vxlan/nvgre decap in other places. 

Best regards,
Mach

> From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
> Sent: Tuesday, November 17, 2015 6:00 AM
> To: Nitin Bahadur; Manish Kumar (manishkr); Chris Bowers; Mach Chen;
> [email-masked]
> BTW, mpls encap/decap is needed even for non-segmenting scenarios - plain
> old l3vpn, vpls, or evpn with mpls data plane.
> 
> Jeffrey
> 
> > We need a minimal tunnel encap for MPLS.so that mpls labels can be
> > pushed and popped. So I do want to keep basic (aka mpls) tunnel
> > encap/decap in this draft. This will also enable development of
> > solutions based on Segment routing (or whatever it's called these days).
> >
> > Nitin
> >

---

From: Alia Atlas <[email-masked]>
Date: Mon, 30 Nov 2015 15:32:29 -0500

<no-hat>

>From my perspective, adding encap for a next-hop in the RIB makes sense.
>From one perspective,
this is just putting, for instance, an MPLS label on.  However, the RIB
supports using additional
higher-level abstractions.  So - the RIB might use an interface that is to
a tunnel - but the RIB may
also have a next-hop that indicates adding the encap associated with an LSP
or a tunnel.  This
allows the RIB's next-hop to stay the same when the LSP or tunnel changes.

I don't see the same rationale for decap.  I'm most familiar with MPLS -
where the label has an
operation that is popping or swapping.  For VXLAN or GRE, the outer dest IP
address would
indicate the router and thus be decapsulated.

I see the role of the RIB as specifying what packets should go out what
interface with appropriate
encaps.  It's not creating the tunnel but merely putting packet(s) into the
tunnel (or LSP or MPLS label stack)
 at the desired level of abstraction.  The discussion about decapsulation
feels much more to me like it is creating the tunnel.

Obviously, I'm happy to listen to other perspectives.

Regards,
Alia
</no-hat>

On Wed, Nov 18, 2015 at 3:36 AM, Mach Chen <[email-masked]> wrote:

> > > >>>user of the data model to configure VXLAN tunnel-encap  using one
> data
> > model