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

From: Nitin Bahadur <[email-masked]>
Date: Mon, 09 Nov 2015 16:52:38 -0700

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: Thu, 12 Nov 2015 03:27:50 +0000

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<http://tools.ietf.org/html/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.

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>.

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.

------------------------
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."

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