Re: [6lo] 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: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A829E120105 for <6lo@ietfa.amsl.com>; Fri, 7 Feb 2020 14:34:09 -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 uuIcVfHoUxe9 for <6lo@ietfa.amsl.com>; Fri, 7 Feb 2020 14:34:06 -0800 (PST)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 899301200FE for <6lo@ietf.org>; Fri, 7 Feb 2020 14:34:06 -0800 (PST)
Received: by mail-yb1-xb2e.google.com with SMTP id k15so485980ybd.10 for <6lo@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=kU/2CL5J0TVwBPQccK9IdgmJMV06gF0s0dcS3njCBI+0Y5L0s9D5fAKuzaDPKuKpzK z58US/Y0AXg2/35KAUQqy7XiQHrclRBJUsKU6tjwPjqPtUM1Qtf9Nsss8wOoS9TQpwTs BNsACmesWC6AvUUuXN/cBIe65eP3Fr6EYCEahmQkA4MYUcUD/4Na9FDdLUDDtQelbhRl 0lweeumED7m0cwMIYVCZ17Nr6s4Sb11VE2LJ96Q2PAXVtyRdJJ2HOjSVL3oHRLWWBjLq S2afvGxiiwUyOal6wMTXs9UYAkJSSg+4IWhEhZpI3oSGu5OPGfdz6cTNpOTIZ/fQwulR 2lyg==
X-Gm-Message-State: APjAAAXQ/HjdSstT+NMvn9rfiIIXFEkDS5h7g/Jj2GtcFmNSO3o/wUxN 3WCeSQ+gd1ZHjRGSfxBehbTVla0qhSr0buOK3fCn9g==
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/6lo/BVszh5RmsuVfEM6-B3WUHjlJTZg>
Subject: Re: [6lo] Tsvart last call review of draft-ietf-6lo-backbone-router-13
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2020 22:34:10 -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