Reviewer: Kyle Rose
Review result: Almost Ready
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@xxxxxxxx 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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
