Skip to main content

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 revision 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 E. 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 B. 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 revision 13 (document currently at 20)
Result Almost Ready
Completed 2020-02-03
review-ietf-6lo-backbone-router-13-tsvart-lc-rose-2020-02-03-00
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.