Hi Carlos,
Thanks for the detailed review. Please see inline below. On 7/29/13 12:05 AM, "Carlos Pignataro (cpignata)" <[email protected]> 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. 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. 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. >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. > >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. > > 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. >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. > 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. > 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. > >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. >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. > > 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. >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? >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. > >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) 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. Thanks Nitin _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
