RIB Information Model
draft-ietf-i2rs-rib-info-model-17
Yes
(Martin Vigoureux)
No Objection
(Adam Roach)
(Deborah Brungard)
Note: This ballot was opened for revision 15 and is now closed.
Warren Kumari
No Objection
Comment
(2018-04-04 for -15)
Unknown
I think that this document would make a really nice introduction to how RIBs work for a University type class and / or required reading for new hires at many network vendors. I do have a large question, a comment, and a bunch of nits: 1: Question: o NEXTHOP_LB_WEIGHT: This is used for load-balancing. Each list member MUST be assigned a weight between 1 and 99. The weight determines the proportion of traffic to be sent over a nexthop used for forwarding as a ratio of the weight of this nexthop divided by the weights of all the nexthops of this route that are used for forwarding. To perform equal load-balancing, one MAY specify a weight of "0" for all the member nexthops. The value "0" is reserved for equal load-balancing and if applied, MUST be applied to all member nexthops. I'm confused what makes 0 special -- if I have e.g 17 links and I assign a weight of e.g 42 to each of them I'll still get equal load-balancing, yes? Why is 0 reserved? I get that having one link with a weigh of e.g 12 and another link with a weight of 0 that would cause issues, but perhaps 0 should simply be unusable? I a: really don't understand and b: thing the document should have some text answering this. 2: Comment: Section 7.1. Using route preference The entire "Route preference can also be used..." paragraph, while true, feels very out of place. I'd suggest jsut removing it. I do have a bunch of nits -- I took these while reading the document, most of them are truly nits... Section 1: O:"populate the Routing information base (RIB) " P:"populate the Routing Information Base (RIB)" C: If it is an acronym, might as make it clear... Section 2.1. RIB definition O: "even have two or more RIBs of the same rib family" P: "even have two or more RIBs of the same RIB family" C: Consistency Section 2.2. Routing instance O: "It allows different logical slices; across a set of routers; to communicate with each other." P: "It allows different logical slices, across a set of routers, to communicate with each other." C: I'm guessing the semicolons were from before this sentence was rewritten. O: "The RIBs specify how incoming traffic is to be forwarded. And the routing parameters control the information in the RIBs." P: "The RIBs specify how incoming traffic is to be forwarded, and the routing parameters control the information in the RIBs." C: Flow. O: "A routing instance MUST contain the following mandatory fields." P: "A routing instance MUST contain the following mandatory fields:" C: Colon instead (and below). O: "Future RIB events can cause an unresolved nexthop to get resolved (like that IP address being advertised by an IGP neighbor)." P: "Future RIB events can cause an unresolved nexthop to get resolved (for example that IP address being advertised by an IGP neighbor)." Section 2.4.2. Derived nexthops O: "Nexthop chains (See Section 7.2.5 for usage), is a way to perform" P: "Nexthop chains (See Section 7.2.5 for usage), are a way to perform" Section 2.4.2.1. Nexthop list attributes There is a random extra '*' between bullets.
Martin Vigoureux Former IESG member
Yes
Yes
(for -15)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(for -15)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2018-04-05 for -15)
Unknown
I don't see any response in email to the Gen-ART review, although some of the changes he proposed seemed to have been taken on board in the -15 version. These comments of his do not seem to have been addressed, however: Sec. 2.2, 1st paragraph after bullet list, last sentence: Routing instances are identified by ROUTER_IDs anyhow, so this sentence seems superfluous. Perhaps you are trying to get across the point that the ROUTER_ID (which is definitely present for the router) is not *used* by this routing instance. I think there's a discussion missing that may or may not be within scope of this document. RIBs appear to be typically divided according to the protocol for which they are providing routing (IPv4, MPLS, etc.) Section 7.1 discusses routing preferences, with an example of OSPF route and a route from some other protocol. When the OSPF route is withdrawn, the other route is installed in the FIB. What's not clear is what makes the decision to do this and cause a specific RIB to push its route into the FIB. Is that the routing instance or the RIB manager? A routing instance is described as a set of interfaces, RIBs, and routing parameters. It's description does not make it clear that it arbitrates among the RIBs or the routing protocols which are using the northbound interface to talk to the RIB manager. Figure 1 makes it seem like there is a RIB manger per RIB, in which case how can the RIB manager make decisions between multiple RIBs? Sec. 5: there are unstated assumptions about needing a subscription mechanism for subscribing to notifications, particularly notifications from RIBs that were not created by the entity. (This goes back to the concept on the previous page that entities may possibly read to or write from RIBs they did not create.) The discussion of notifications could use some fleshing out here.
Alvaro Retana Former IESG member
No Objection
No Objection
(2018-04-03 for -15)
Unknown
(1) Even if just Informative, it would be nice to have a reference to draft-ietf-i2rs-rib-data-model. (2) I think that the use of some Normative Language is not as expected. (2.1) For example, in S2.1 (RIB definition): "There MAY be many routing instances and each routing instance MAY contain RIBs." In both cases "MAY" seems to be a statement of fact, and not a normative statement to indicate that a routing instance can optionally include RIBs. Note that S2.2 (Routing instance) identifies a rib-list as a mandatory component of a routing instance, and there's no clear indication that the list may be empty. (2.2) S2.1: "A routing instance MAY even have two or more RIBs of the same rib family (e.g., IPv6)." This use of "MAY" also seems to be stating a fact. (2.3) "MAY be optionally", "MAY contain the following optional fields" are redundant phrases as MAY already means optional.
Ben Campbell Former IESG member
No Objection
No Objection
(2018-04-04 for -15)
Unknown
[I do not expect a change this late in the process due to the following comment; I make more in hopes it will be helpful in the future] I don't think the use of 2119/8174 in this draft adds value, and may even be counterproductive. Many of the instances use keywords to make definitions rather than normative requirements. For example, a statement of the form "Foo MUST contain these mandatory fields" is equivalent to "Foo contains these mandatory fields". In most cases, a draft of this nature is better off just using descriptive language.
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2018-04-04 for -15)
Unknown
I share Warren's question (and, IIRC, asked a similar one about the associated data-model document). Just one other minor question: in Section 4 Route programming in the RIB MUST result in a return code that contains the following attributes: o Installed - Yes/No (Indicates whether the route got installed in the FIB) o Active - Yes/No (Indicates whether a route is fully resolved and is a candidate for selection) o Reason - e.g., Not authorized Is the Reason only relevant when one of the other two is "No"?
Deborah Brungard Former IESG member
No Objection
No Objection
(for -15)
Unknown
Ignas Bagdonas Former IESG member
No Objection
No Objection
(2018-04-05 for -15)
Unknown
A few nits: Terminology: rib family vs address family. Address family term is more widely used in the industry. VPLS is a subset of L2VPN. ROUTER_ID usage is orthogonal to router virtualization. MUST restriction for the domain is factually incorrect - it is typically per source protocol, not per domain.
Suresh Krishnan Former IESG member
No Objection
No Objection
(2018-04-04 for -15)
Unknown
* Section 2.3. Regarding the OSPF route for 2001:DB8::1/32 Did you mean 2001:DB8::1/128 for the host route? If not, this example is wrong since 2001:DB8::1/32 expands to 2001:DB8:0000:0000:0000:0000:0000:1/32 -> 2001:DB8::/32 as the route * Figure 4. Shouldn't the tunnel-encap and tunnel-decap also loop the packet back into nexthop processing just like the derived nexthops do? * Section 6 I would have expected the match type to have some indication about whether it requires an exact match or LPM (e.g. A MAC route uses an exact match but an IPv6 route uses LPM). Has the WG discussed this?