Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12)

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 3 Aug 2013 18:56:02 +0000

Hi, Nitin,

Many thanks for the follow-up, please see inline.

On Jul 30, 2013, at 2:40 PM, Nitin Bahadur <[email-masked]> wrote:

> 
> Hi Carlos,
> 
> 
>  Thanks for the detailed review. Please see inline below.
> 
> On 7/29/13 12:05 AM, "Carlos Pignataro (cpignata)" <[email-masked]>
> wrote:
> 
>> Hi,
>> 
>> I have concerns with adopting this document.
>> 
>> As others have mentioned on the list, the concepts of RIB and routing
>> instance seem to be inverted.
> 
> Yes, I have removed "RIB" as a top-level container to avoid the
> confusion/inversion-issue.
> 
>> But in addition to that, there seem to be two other issues with the
>> document in its current shape:
>> 1. It's not clear the scope of what's within the Routing Information Base
>> information model. Specifically, elements defined seem to belong in the
>> FIB and not the RIB.
> 
> Besides the routing table, which other elements did you have in mind.
> 

There is a potential gray area between things that are clearly routing and others that are clearly forwarding. However, I do wonder if things like RPF (F for forwarding), matching on incoming MAC address, NO_DECREMENT_TTL, and others are outside the scope of what the RIB is.

> Regarding "routing tables" as an element of the FIB, then I think it's a
> terminology mis-understanding. A routing-table (as per this draft) is
> something that is local to the control plane and has nothing to do with
> the forwarding plane. A routing-table (as per this draft) is a database
> containing route information.

The draft talks about "MPLS Route" and "MAC Route". To me, it would be useful to further describe the scope of that is a route, a prefix, etc. LDP does not distribute "routes".

> Now if this terminology conflicts/confuses
> with how hardware vendors use the same term, I would be happy to change
> the name to something else (maybe call it a RIB). I hope you now
> understand why I did not think of it as a FIB construct.

I do, thanks. I do think that tighter terminology will certainly help. "the beginning of wisdom is the definition of terms". And I do believe that we can derive what should be included into the information model from scoped definitions.

> 
>> 2. The document structure seems to have gaps and overlaps, and lacks a
>> compiled set of definitions of RIB elements.
> 
> Compiled set of definitions of the elements is on my TODO list. I'll
> likely add an Appendix at the end.
> 

Ack -- thanks.

>> 
>> Please find below some additional questions and observations on the
>> document, marked with "CMP".
>> 
>> I hope these are clear and useful.
>> 
>>                 Routing Information Base Info Model
>>                 draft-nitinb-i2rs-rib-info-model-01
>> 
>> 1.  Introduction
>> 
>>  The rest of this document is organized as follows.  Section 2.1 goes
>>  into the details of what constitutes and can be programmed in a RIB.
>>  Section 5 provides a high-level view of the events and notifications
>>  going from a network device to an external entity, to update the
>>  external entity on asynchronous events.  The RIB grammar is specified
>>  in Section 6.  Examples of using the RIB grammar are shown in
>>  Section 7.
>> 
>> CMP: What about other Sections? From 2.1 it jumps to Section 5
> 
> 
> Will be cleaned up in next rev.

Thanks.

> 
>> 
>>  and not proactive push (from the router) mechanisms.  Screen scraping
>>  is error prone (since output can change) and vendor dependent.
>> 
>> CMP: A nit -- the output will change. I think "since the output format
>> can change" is what's meant.
> 
> Will fix.
> 

Ack.

> 
>> 2.1.  RIB definition
>> 
>>  A RIB is a logical construct controlled by an external entity.  A RIB
>>  contains one or more routing instances.  On a network device, a RIB
>>  is uniquely identified by its name.  A routing instance can be in
>>  only 1 RIB.  A routing instance, in the context of the RIB
>>  information model, is a collection of routing tables, interfaces, and
>>  routing parameters.  A routing instance creates a logical slice of
>>  the router and allows different logical slices; across a set of
>>  routers; to communicate with other each.
>> 
>> CMP: I think these set of definitions could use a visual to describe
>> what's a RIB, routing instance, routing tables and their high-level
>> elements, in addition to itemized definitions.
> 
> I have a UML diagram representing this, but there is no way to imbed
> images in IETF drafts (maybe time to change IETF draft format?). I'll add
> a text form of a diagram for readability.
> 
> 

Thank you.

>>  Layer 3 Virtual Private
>>  Networks (VPN), Layer 2 VPNs (L2VPN) and Virtual Private Lan Service
>>  (VPLS) can be modeled as routing instances.
>> 
>> CMP: It's not clear to me how an L2VPN or a VPLS can be modeled as
>> routing instances. Which L3 elements are there in an L2VPN?
> 
> There are no L3 elements in a L2VPN. However, one can (if one really
> wants) setup a static PW through the RIB model and then map MAC routes to
> that PW. You can argue that MAC routes shouldn't be a part of this draft
> and I'll be happy to remove it if there is consensus.
> 

Exactly. But this is a consequence of lack of precision in the definition and scope.
To me, it should follow the definition and agreed scope. I would also like to see which direction the WG wants to go.

> 
>>  Note that modeling a
>>  Layer 2 VPN using a routing instance only models the Layer-3 (RIB)
>>  aspect and does not model any layer-2 information (like ARP) that
>>  might be associated with the L2VPN.

The question I still have on this is how you are associating "Layer-3" to "RIB". That is self-contradicting with other parts of the draft (MAC routes).

>> 
>> CMP: DOes this mean that ARP should be out of the RIB model?
> 
> ARP should be out of the RIB model. ARP is a network-device local function.
> 
> 
>> 2.2.  Routing tables
>> 
>>  A routing table is an entity that contains routes.  A routing table
>>  is identified by its name.  The name MUST be unique within a RIB.
>>  All routes in a given routing table MUST be of the same type (e.g.
>>  IPv4).  Each routing table MUST belong to some routing instance.
>> 
>> CMP: Should you also differentiate, in addition to the AF, by unicast
>> versus multicast?
> 
> It would be good if someone kept unicast & mcast in different tables, but
> the model does not enforce
> that.
> 
> 
>>  Each route table can be optionally associated with a
>>  ENABLE_IP_RPF_CHECK attribute that enables Reverse path forwarding
>>  (RPF) checks on all IP routes in that table.  Reverse path forwarding
>> 
>> CMP: Is RPF an attribute of the routing table?
> 
> In reality, RPF is an attribute of the route. But it's simpler if it is
> associated with the entire table..so you do an RPF check for all routes in
> that table. It is possible to move this as an attribute of the route and
> if folks prefer that, it's an easy change.
> 

My question was slightly different -- is RPF an attribute of forwarding or of routing? Is it in the context of multicast, or uRPF (loose or strict?)?

> 
>> 2.3.  Route
>> 
>>  A route is essentially a match condition and an action following the
>>  match.  The match condition specifies the kind of route (IPv4, MPLS,
>>  etc.) and the set of fields to match on.  This document specifies the
>>  following match types:
>> 
>> CMP: What is an "MPLS Route" in the context of a routing table?
> 
> MPLS route is nothing but a mpls label match.

See please below the next comment.

> 
>> 
>>  o  IPv4: Match on destination IP in IPv4 header
>>  o  IPv6: Match on destination IP in IPv6 header
>>  o  MPLS: Match on a MPLS tag
>>  o  MAC: Match on ethernet destination addresses
>> 
>> CMP: Is the MAC address a match element within routing?
> 
> MAC address is really not a routing concept. But given that we have mac
> addresses being passed around in E-VPN and that VPLS deals with MAC
> addresses, there was sufficient motive to add MAC address match.
> 
> 

This is a key comment. Scope of what's a "route" or a "RIB" or "route-table" entry is not clear. 

> 
> 
>> Or what types of address families and identifiers are input to defining
>> the elements included?
> 
> I'm not sure if I understand the above question. AF_IP, AF_IPV6, AF_MPLS?
> 

Sorry I was not clear -- the real question is about "MAC routes", "MPLS routes", or frankly the question is to which attributes define a RIB/route-table: a network-layer protocol address family? plus uni/multicast? Anything that is distributed by a routing protocol?

> 
> 
>> 2.4.1.  Nexthop types
>> 
>>  o  Special nexthops - for performing specific well-defined functions
>> 
>> CMP: Are things like the drop/null route fitting here? Are there many
>> different kinds of specials, or should they be listed explicitly?
> 
> They should be called out explicitly someplace but not here. This is more
> of an overview of the info model and putting in all the details in this
> section would disturb the overall flow.
> 
> 
>> 6.  RIB grammar
>> 
>>  <table-family> ::= <IPV4_TABLE_FAMILY> | <IPV6_TABLE_FAMILY> |
>>                     <MPLS_TABLE_FAMILY> | <IEEE_MAC_TABLE_FAMILY>
>> 
>> CMP: Why these families?
> 
> It doesn't make sense to put IPv4 routes and IPv6 routes together.
> Currently, routing vendors have well-defined table names that implicitly
> identify the address family of routes in a given table. Intent here is to
> remove that implicit assumption.
> 

That (being explicit) sounds good -- the question is (again, sorry) about "IEEE MAC RIB".

> 
>> 
>> CMP: Do you need to separate IPv4 in unicast versus multicast? Or are you
>> modeling a single table with attributes for the uni/multicast?
> 
> As I said before, it's up to the I2RS server (controller)

Do you mean the I2RS server (agent) or the client (controller)?

> to create
> multiple tables (one for unicast and one for mcast). If the WG feel
> strongly, we can enforce that in the model.
> 
> 
>>  <ipv4-route> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>
>> 
>> CMP: SHould that be "IPv4_ADDRESS" or "IPv4_PREFIX"?
> 
> I don't know. Last I remember, in rBNF, all terminal stuff should be all
> CAPS.
> 

Sorry for not being clear, my comment is not about the RBNF.

An IPv4 route does not have "addresses", it contains "prefixes". I was wondering if "IPv4_PREFIX" should replace "IPV4_ADDRESS".

Thanks,

-- Carlos.

> Thanks
> Nitin