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

[Nitin Bahadur <[e-mail]>]

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" <[e-mail]> wrote:

>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
>
>> -----Original Message-----
>> From: Chris Bowers [mailto:[e-mail]]
>> Sent: Sunday, November 15, 2015 12:38 AM
>> To: Mach Chen; Nitin Bahadur; [e-mail]
>> Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03
>> 
>> 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:[e-mail]]
>> Sent: Friday, November 13, 2015 3:37 AM
>> To: Chris Bowers <[e-mail]>; Nitin Bahadur
>> <[e-mail]>; [e-mail]
>> Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03
>> 
>> 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:[e-mail]]
>> > Sent: Thursday, November 12, 2015 11:28 AM
>> > To: Nitin Bahadur; [e-mail]; 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:[e-mail]]
>> > Sent: Monday, November 09, 2015 5:53 PM
>> > To: Chris Bowers <[e-mail]>; [e-mail]; Mach Chen
>> > <[e-mail]>
>> > 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.
>> > NB> 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