Skip to main content

Early Review of draft-ietf-i2rs-rib-info-model-11
review-ietf-i2rs-rib-info-model-11-rtgdir-early-rogge-2017-08-01-00

Request Review of draft-ietf-i2rs-rib-info-model-11
Requested revision 11 (document currently at 17)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-07-31
Requested 2017-07-17
Requested by Susan Hares
Authors Nitin Bahadur , Sriganesh Kini , Jan Medved
I-D last updated 2017-08-01
Completed reviews Rtgdir Early review of -08 by Ravi Singh (diff)
Rtgdir Early review of -11 by Henning Rogge (diff)
Opsdir Early review of -12 by Mahesh Jethanandani (diff)
Genart Last Call review of -14 by Peter E. Yee (diff)
Secdir Last Call review of -14 by Paul Wouters (diff)
Opsdir Last Call review of -12 by Mahesh Jethanandani (diff)
Comments
Please review this as a final QA review after WG LC and before publication.  This document should be check to see it abides with the current guidelines for a data model under the revised data store guidelines.
Assignment Reviewer Henning Rogge
State Completed
Request Early review on draft-ietf-i2rs-rib-info-model by Routing Area Directorate Assigned
Reviewed revision 11 (document currently at 17)
Result Has nits
Completed 2017-08-01
review-ietf-i2rs-rib-info-model-11-rtgdir-early-rogge-2017-08-01-00
Submitting on behalf of Henning Rogge:

Hi,

I was asked to do an early review of the i2rs-rib-info-model...

I liked the comprehensive approach describing the RIB, including tunnels,
multi-topology routing (by using multiple RIBs) and routing reactions (like
drop/icmp-error).

I found a few things in the draft that in my opinion need a bit more work...

First it seems that Section 2.3 (Route) is a bit out of sync with the BNF later
in the document, it should at least mention matching the source-IP address of
the IP headers.

Second (if I read the BNF in Section 6 correctly), the match for a route seems
to be one of the list "ip address, MPLS label, MAC address, interface". I think
it should be possible to combine "interface" or "mac address" with an IP
address to restrict the focus of a route, e.g. "match fe80::1 from interface X".

Last, I wonder if multicast routing needs more different types of matchers,
e.g. a match on the TTL of the IP packet to limit the range of a multicast
group.

There is also problem of multicast routing in MANETs (see RFC 6621) which can
use a hash-based duplicate detection to determine if it forwards or drops a
multicast packet. Would this be out of scope for the draft?

Henning Rogge