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

From: Kyle Rose via Datatracker <[email-masked]>
Date: Mon, 03 Feb 2020 10:57:44 -0800

Reviewer: Kyle Rose
Review result: Almost Ready

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
[email-masked] 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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Feb 2020 10:48:26 +0000

Hello Kyle

Many thanks for your review!

Let's see below:

> 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.
> 
> 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

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/ 

> 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

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.

 "

> of the first, or are NA messages always to be proxied and all other messages to

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.
"

> 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

---

From: Kyle Rose <[email-masked]>
Date: Fri, 7 Feb 2020 17:18:10 -0500

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

> 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.
> 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

> 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.
> This is actually the desired behavior to protect the wireless medium, in
> particular against broadcasts induced by the reactive ND operations.
>
> 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
>
>

---

From: Kyle Rose <[email-masked]>
Date: Fri, 7 Feb 2020 17:33:54 -0500

Let's try this again.

> 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.

> format, though the packets may progress slowly, and be compressed or

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.

> particular against broadcasts induced by the reactive ND operations.

Stipulated. I agree this is a desirable property.

>    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."

>          Registering Node, e.g., using a NUD verification, before

Looks good, modulo some minor editorial nits.

Hopefully this resolves everything.

Thanks,
Kyle

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 8 Feb 2020 12:11:43 +0000

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-masked]>
Sent: vendredi 7 février 2020 23:34
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Tsvart last call review of draft-ietf-6lo-backbone-router-13

Let's try this again.

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.

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.

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."

"

Thanks,
Kyle

---

From: Kyle Rose <[email-masked]>
Date: Mon, 10 Feb 2020 12:26:52 -0500

Changes look good to me. Thanks.

Kyle

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

> 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-masked]>
> *Sent:* vendredi 7 février 2020 23:34
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *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-masked]> wrote:
>
> 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.
>
>
>