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 <[email protected]> Sent: vendredi 7 février 2020 23:34 To: Pascal Thubert (pthubert) <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] 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) <[email protected]<mailto:[email protected]>> 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
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
