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

["Pascal Thubert (pthubert)" <[e-mail]>]

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]<mailto:[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