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

Kyle Rose <krose@krose.org> Fri, 07 February 2020 22:18 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 925E9120103 for <6lo@ietfa.amsl.com>; Fri, 7 Feb 2020 14:18:24 -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=ham 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 V7rq8DhY0HyL for <6lo@ietfa.amsl.com>; Fri, 7 Feb 2020 14:18:22 -0800 (PST)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 374C01200E6 for <6lo@ietf.org>; Fri, 7 Feb 2020 14:18:22 -0800 (PST)
Received: by mail-yb1-xb2c.google.com with SMTP id l197so476332ybf.7 for <6lo@ietf.org>; Fri, 07 Feb 2020 14:18:22 -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=Tu7lga5CM1O+d/EF5wsptFnvdhkz+do8FFfD8ihHBY8=; b=rdDrCz9vG/NzfNO2dJF2Bi69VxVh5N8mUC2bLoR1jRD7bFd8YOMDdCa9sZCZ5pzgNI V5trvALDGPFxxkuglY3e1qag5ejYSVS3ChPZM7obRQJR61SIRgkWvqnmSsBwxFkS3rng 8Kn8w1Ai3HeO7ZrDTy1AESAaxdn+Vtbj6K4mM=
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=Tu7lga5CM1O+d/EF5wsptFnvdhkz+do8FFfD8ihHBY8=; b=Y9U7pIT8/HaNDsma4wIy046+tNSJ4/rhKMy1K7Z7fcmbb86Qzw/wSKdPnolocMIBwx 2aAsnqxSgD4tdq6l2LVi91Vggq+iTppvw/JquCjtxnllm8CgD9RUKBsi6IhcOnV4XDG7 UPJL27a6qM8fsVjtd+/2yOhZz2ZYnhFFbURX6eigONF5En9euf//IjI+771xzuyPiero X1duEx3ivKVWKfmFYvwm/J4RxWSjdmaYIR46Cu0Dehs2l3yoVsW2EOQIdDwiKMQ0sNbP FW9sEEHRwj53zEPJdFD+eNOgzfKQsHT1CrSRcLUHTiUIedq8Bqm6Q/gTbBv7AFze/tna +uZA==
X-Gm-Message-State: APjAAAVXJntL20KAX9pJXI7HRBuOJEOeDq3mUVou3kyGI+37Vk0fHnGN ey2Pj4FMi1gpv70V1mpDqdxee1HhHE+sarej3ppA0A==
X-Google-Smtp-Source: APXvYqxUy7P0bVEJh0WdSkq0wpjXTmM8QPawe06jD9x5oP8QxMDtrKPuYBaQKygA0+4xOIj8n10AqVxo28jaHKoSWDw=
X-Received: by 2002:a5b:7cf:: with SMTP id t15mr1155266ybq.127.1581113901205; Fri, 07 Feb 2020 14:18:21 -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:18:10 -0500
Message-ID: <CAJU8_nW3CkmcFkGe4HHgJcjW+3OWLTg=baOZgAD9T4EuzUyvPg@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="0000000000006e5cda059e03c42f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/aoAjD_NUi2p_jxzZE18wsCfmACg>
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:18:24 -0000

On Fri, Feb 7, 2020 at 5:48 AM Pascal Thubert (pthubert) <pthubert@cisco.com>
wrote:

> > 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."
>
> 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 backbone routers,
mostly based on a


>
>
>
> > 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.
>
> 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.
>
>  "
>
>
>
> > 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.
> "
>
>
>
>
> > Nit: Please use a single form to specify a multi-link subnet: I see
> "MultiLink"
> > 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
>
>