Last Call Review of draft-ietf-6lo-backbone-router-13
review-ietf-6lo-backbone-router-13-tsvart-lc-rose-2020-02-03-00
| Request | Review of | draft-ietf-6lo-backbone-router |
|---|---|---|
| Requested rev. | no specific revision (document currently at 20) | |
| Type | Last Call Review | |
| Team | Transport Area Review Team (tsvart) | |
| Deadline | 2020-02-06 | |
| Requested | 2020-01-23 | |
| Authors | Pascal Thubert, Charles Perkins, Eric Levy-Abegnoli | |
| Draft last updated | 2020-02-03 | |
| Completed reviews |
Iotdir Last Call review of -13 by Dominique Barthel
(diff)
Genart Last Call review of -14 by Elwyn Davies (diff) Tsvart Last Call review of -13 by Kyle Rose (diff) |
|
| Assignment | Reviewer | Kyle Rose |
| State | Completed | |
| Review | review-ietf-6lo-backbone-router-13-tsvart-lc-rose-2020-02-03 | |
| Posted at | https://mailarchive.ietf.org/arch/msg/tsv-art/XFwQl0vr4PBHsQ_AOfCBH1IqOCw | |
| Reviewed rev. | 13 (document currently at 20) | |
| Review result | Almost Ready | |
| Review completed: | 2020-02-03 |
Review
review-ietf-6lo-backbone-router-13-tsvart-lc-rose-2020-02-03
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.
This document describes a mechanism for efficient neighbor discovery across links sharing a common IPv6 prefix, i.e., a multi-link subnet.
I see no specifically transport-related issues in this draft, but I note a few nits as well as unaddressed issues raised by RFC 4903.
Potential issues: The draft addresses ND, DAD, and to some extent link-scoped multicast and broadcast (sections 2.3 and 2.4 of 4903), but does not address either the IP Model (section 2.1) or hop limit issue (2.2). For the first, does the presumption that a multi-link subnet exists as a recognized and supportable network configuration require update of RFC 4291, which AFAICT is still authoritative for the statement that:
"Currently, IPv6 continues the IPv4 model in that a subnet prefix is
associated with one link."
For the second, since I'm assuming something called a "router" will in fact decrement the hop limit when forwarding a packet (I couldn't find the answer in a brief perusal of the references that seemed relevant), for completeness it might be helpful to mention something about how multicast traffic e.g. with hop limit 1 will not successfully transit to hosts in the same subnet but on a different link. In general, making clear that the issues raised in 4903 are systematically addressed with respect to the unique requirements of 6lo traffic would be useful to the reader.
Nit: This text is confusing:
Either respond using NA messages as a proxy or bridge as a unicast
frame the IPv6 ND messages (multicast DAD and Address Lookup, and
unicast NUD) received for the Registered Address over the
Backbone.
In particular, I'm struggling with what the second option here is. Is it that a 6BBR could bridge incoming ND messages to other links? Is it an option in lieu of the first, or are NA messages always to be proxied and all other messages to be bridged?
Nit: Please use a single form to specify a multi-link subnet: I see "MultiLink" and "Multi-Link" used in different places.