RIB Information Model
draft-ietf-i2rs-rib-info-model-17

Note: This ballot was opened for revision 15 and is now closed.

Martin Vigoureux Yes

Ignas Bagdonas No Objection

Comment (2018-04-05 for -15)
No email
send info
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.

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2018-04-04 for -15)
No email
send info
[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.

Alissa Cooper No Objection

Comment (2018-04-05 for -15)
No email
send info
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.

Benjamin Kaduk No Objection

Comment (2018-04-04 for -15)
No email
send info
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"?

Suresh Krishnan No Objection

Comment (2018-04-04 for -15)
No email
send info
* 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?

Warren Kumari No Objection

Comment (2018-04-04 for -15)
No email
send info
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.

Alvaro Retana No Objection

Comment (2018-04-03 for -15)
No email
send info
(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.

Adam Roach No Objection