Re: [6lo] Tsvart last call review of draft-ietf-6lo-backbone-router-13

[Kyle Rose <[e-mail]>]

On Fri, Feb 7, 2020 at 5:48 AM Pascal Thubert (pthubert) <[e-mail]>
wrote:

> > 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."
>
> True, but that's not a world premiere either. All the route-over LLNs that
> are deployed (that's millions of RFC 6550 nodes) defeat that definition,
> since with or without a federating backbones, a LLN is already a MLSN.
> None of the previous route-over work RFCs claims to extend RFC 4291. We
> could here but to what avail?
> Note that I do not mind either way.
> If you find the time, maybe you'd be interested in reading / commenting
> the subnet-related discussions in
> https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/


Ah, ok: I figured this was a new property provided by backbone routers,
mostly based on a


>
>
>
> > 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.
>
> 6lo traffic is not specific. It is IPv6. There is no special rights or
> format, though the packets may progress slowly, and be compressed or
> fragmented.
> But you're correct; link scope and HL=1 packets don't reach the entire
> subnet.
> This is actually the desired behavior to protect the wireless medium, in
> particular against broadcasts induced by the reactive ND operations.
>
> Proposal to augment the paragraph in the introduction that discusses MLSN
> as follows
> "
>
>    This specification defines the 6BBR as a Routing Registrar [RFC8505]
>    that provides proxy services for IPv6 Neighbor Discovery.  As
>    represented in Figure 1, Backbone Routers federate multiple LLNs over
>    a Backbone Link to form a MultiLink Subnet (MLSN).  The MLSN breaks
>    the Layer-2 continuity and splits the broadcast domain, in a fashion
>    that each Link, including the backbone, is its own broadcast domain.
>    This means that devices that rely on a link-scope multicast on the
>    backbone will only reach other nodes on the backbone but not LLN
>    nodes.  The same goes a packet that is sent with a hop limit of 1 or
>    using a Link-Local destination address.  This packet may reach other
>    nodes on the backbone but not LLN Nodes.  In order to enable the
>    continuity of IPv6 ND operations beyond the backbone, and enable
>    communication using Global or Unique Local Addresses between any node
>    in the MLSN, Backbone Routers placed along the LLN edge of the
>    Backbone handle IPv6 ND on behalf of Registered Nodes and forward
>    IPv6 packets back and forth.
>
>  "
>
>
>
> > 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?
>
> Yes, this text is really unclear, sorry for that. Proposal to clarify as
> follows:
>
> "
>
> The 6BBR may respond immediately as a Proxy in lieu of the
>       Registering Node, e.g., if the Registering Node has a sleeping
>       cycle that the 6BBR does not want to interrupt, and if the 6BR has
>       a recent state that is deemed fresh enough to permit the proxied
>       response.  It is preferred, though, that the 6BBR checks whether
>       the Registering Node is still responsive on the Registered
>       Address. to that effect:
>
>       *  as a Bridging Proxy, the 6BBR forwards a multicast DAD or an
>          Address Lookup message as a unicast MAC-Layer frame to the SLLA
>          of the Registering Node that matches the Target in the ND
>          message, and forwards as is the unicast NUD, so as to let the
>          Registering Node answer with the ND Message and options that it
>          sees fit;
>
>       *  as a Routing Proxy, the 6BBR checks the liveliness of the
>          Registering Node, e.g., using a NUD verification, before
>          answering on its behalf.
> "
>
>
>
>
> > Nit: Please use a single form to specify a multi-link subnet: I see
> "MultiLink"
> > and "Multi-Link" used in different places.
>
> Done : )
>
> Pleas let me know if the above fits your expectations. I plan to publish
> soon, incorporating nits from Elwyn Davies.
>
> Many thanks again, Kyle!
>
> Pascal
>
>