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

[Kyle Rose <[e-mail]>]

Changes look good to me. Thanks.

Kyle

On Sat, Feb 8, 2020 at 7:12 AM Pascal Thubert (pthubert) <[e-mail]>
wrote:

> Many thanks again, Kyle.
>
>
>
> I applied the updated text you proposed, migrated to xml2rfc v3 and posted
> -16.
>
> You may see it at
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-backbone-router-16
>
>
>
> All the best
>
>
>
> Pascal
>
>
>
>
>
>
>
>
>
> *From:* Kyle Rose <[e-mail]>
> *Sent:* vendredi 7 février 2020 23:34
> *To:* Pascal Thubert (pthubert) <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: Tsvart last call review of
> draft-ietf-6lo-backbone-router-13
>
>
>
> Let's try this again.
>
>
>
> On Fri, Feb 7, 2020 at 5:48 AM Pascal Thubert (pthubert) <
> [e-mail]> wrote:
>
> >     "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 6lo backbone
> routers, mostly based on a quick reading of 6550 and failure to find
> "multi-link" or "subnet" references that went anywhere. If this property
> has already achieved rough consensus for 6lo applications, I'm happy to
> leave it at that.
>
>
>
> 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.
>
>
>
> Well, that makes it not IPv6 in the strictest sense, right? Implemented in
> the mesh-under network, you couldn't simply dump the tiny fragments onto a
> non-6lo network and expect a node to reassemble them, could you? But this
> is a bit of a diversion, and falls under the same rough consensus category
> (IMO) as the multi-link subnet issue.
>
>
>
> 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.
>
>
>
> Stipulated. I agree this is a desirable property.
>
>
>
> 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.
>
>
>
> This might be a bit much. I think what would suffice is a sentence simply
> mentioning that "A key property of MultiLink subnets is that link-local
> traffic and traffic with a hop limit of 1 will not transit to nodes in the
> same subnet on a different link, something that may produce unexpected
> behavior in software that expects a subnet to be entirely contained within
> a single link."
>
>
>
> > 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.
> "
>
>
>
> Looks good, modulo some minor editorial nits.
>
>
>
> Hopefully this resolves everything.
>
>
>
> Thanks,
>
> Kyle
>