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

Kyle Rose <krose@krose.org> Fri, 07 February 2020 22:34 UTC

Return-Path: <krose@krose.org>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F42391200E6 for <tsv-art@ietfa.amsl.com>; Fri, 7 Feb 2020 14:34:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vV3sr7R8I1q for <tsv-art@ietfa.amsl.com>; Fri, 7 Feb 2020 14:34:06 -0800 (PST)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D591200F8 for <tsv-art@ietf.org>; Fri, 7 Feb 2020 14:34:06 -0800 (PST)
Received: by mail-yb1-xb30.google.com with SMTP id z125so488577ybf.9 for <tsv-art@ietf.org>; Fri, 07 Feb 2020 14:34:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hOLVfJxippX1/FE7KQlX5L7SfvVwt5unpsbHESeLZWM=; b=FyDWHIHQl9u0xHqTKW+/wX+5j3IxnZDJmVaMTKWSL9JREzs2EsbyPVovExo+0su5av 5RkrYBXM4nNRF/g8xo1Ad8vl8l8mqCdJl93ckH7/1JyTr+afbPpELkobFUXW79nP9drU i8t1fgPhDS0oCH2mGIjs0vnEAA2LAgkcW1BMY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hOLVfJxippX1/FE7KQlX5L7SfvVwt5unpsbHESeLZWM=; b=eSNmhRhQ2XJCZqdtsZPlh5eBEkUG2FSumjK2TC0qKA176Xaw1C7X1RA16PYnInW5lp ELnkVI5y8dB0Mkd4tuX2PaDwu0rP0WP7N8BULcPh6aI9k1lg0EL1KmwsE8KQb3jat7Wv OioywPYdeIx5kj3pzbKFkWy1LUc6jJu0C5QoCNJVy6WOSRnfq6kgds2bdDEEhPeWNM2F +gXsaDFO3baVTMeQKykEe+18mdG+ZewdBiGZuPQjbJBzGFxkkSOqO/s6+cfjSkx4qyaV MBqX5WjGEx+c1K0v3Xdwk0JuOfuwCtKTLJoLpRws9Nsv8gff4uWdv671Acx9o67h4JKn A+Iw==
X-Gm-Message-State: APjAAAVX0vGylUaqmQgQSN97iE/8Aequj/w7WNOg1ZvZvQ1yK+5CAQWL F6mUa0B90m9KMjNjCHbdeChSQ6xrSSM9Kn3aAQ+ENw==
X-Google-Smtp-Source: APXvYqzJ/5NuIB/H8q3ar5HvEQvWCpIFb807BGfLedJqOH7GO/WCR4ANopQVeubuSuPRInYxCiTOYay39jzsoJKR0SA=
X-Received: by 2002:a25:ba08:: with SMTP id t8mr1196204ybg.379.1581114845510; Fri, 07 Feb 2020 14:34:05 -0800 (PST)
MIME-Version: 1.0
References: <158075626468.28650.2983535903394534987@ietfa.amsl.com> <MN2PR11MB3565618E29F176F4619ED067D81C0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565618E29F176F4619ED067D81C0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Kyle Rose <krose@krose.org>
Date: Fri, 7 Feb 2020 17:33:54 -0500
Message-ID: <CAJU8_nXZZnYTOKsKxhadj8=57BBcRSFe7Q4uJB+gpV_fWuTexQ@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "tsv-art@ietf.org" <tsv-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-6lo-backbone-router.all@ietf.org" <draft-ietf-6lo-backbone-router.all@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b7538d059e03fcbe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/54LCPxGek7BUf3kvXW6B1X-Yomc>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-6lo-backbone-router-13
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2020 22:34:11 -0000

Let's try this again.

On Fri, Feb 7, 2020 at 5:48 AM Pascal Thubert (pthubert) <pthubert@cisco.com>
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