[i2rs] Alissa Cooper's No Objection on draft-ietf-i2rs-rib-info-model-15: (with COMMENT)

[Alissa Cooper <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-i2rs-rib-info-model-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-info-model/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.