Hi, Nitin, Many thanks for the follow-up, please see inline.
On Jul 30, 2013, at 2:40 PM, Nitin Bahadur <[email protected]> wrote: > > 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. > 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 > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
