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