Re: [6lo] Review of [draft-ietf-6lo-backbone-router-11 - IPv6 Backbone Router]

Timothy Winters <twinters@iol.unh.edu> Wed, 02 October 2019 00:18 UTC

Return-Path: <twinters@iol.unh.edu>
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 4CD94120807 for <6lo@ietfa.amsl.com>; Tue, 1 Oct 2019 17:18:57 -0700 (PDT)
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=iol.unh.edu
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 R-4uLp7javWB for <6lo@ietfa.amsl.com>; Tue, 1 Oct 2019 17:18:53 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 9732F12009E for <6lo@ietf.org>; Tue, 1 Oct 2019 17:18:53 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id i16so5188029wmd.3 for <6lo@ietf.org>; Tue, 01 Oct 2019 17:18:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qeZyLhz9ZvypzN8+4u/VJbmxKuhL2uWLJFD6Ennm5CQ=; b=VHfNNuonxLFiFMwHZjilavk6FZ4nu3lzXzYn+p6w/TVjPdWmOn3qEVDtxm0375C50v CU2ezJcBy687CV2OcV1UeuQzOGHmfo8zDy5fxlPV5sDAEGJ1GbOWh6UCpVCqa7+j1IEh 84bOvzfN5Vmr5ld5+JBEVwa4iizl99HXf5DSo=
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=qeZyLhz9ZvypzN8+4u/VJbmxKuhL2uWLJFD6Ennm5CQ=; b=DY6BPpViELejrEwu/qvJwZSzjfDDYdRLZb/oVxTirRa0H4x31+onUp4Yw2YLtLpuHr SimbfDYqFaAhD5nhZOBMJP0N56PX384Gquz7CHXJvRm9EvrxYhRi+LTsTK17eQp1E5/4 8/BZBrJ88zMZ7lcy4E5CIdmkfzY6BsnqdJT/os9NVRWQ9XSa6zrOf8PL770f1ZLozZDf A3HAAxlu3rEaBdPNyqmrxHdboMpKJHIsTNrKmwvTmXEpZGxh25GqXTV2giiLlZtxVjZ9 a79/uXxPlLoFSm55dMwXDvt1RgezUtmxBaGlAKZIw9xzEIvmvoasqAICu/UgbsdKr7qd f5oQ==
X-Gm-Message-State: APjAAAUeKeSLVWZJ1MOaKiCI4ykUXyXX3iqkGnYAl0qUsP2n7yWbUG1G WXO0pXyxBA6XRWN0KgzIw6eN+POKOOWlW0/WPY+/Ng==
X-Google-Smtp-Source: APXvYqxmQT/M2vAWc+qIdDOzcpKvwc1aP7Oe/SXzdhRvlDocWw12mP6O+d6+C1B+HPLPsd97OBQ1g3rEVo/Zro6PgQY=
X-Received: by 2002:a1c:3281:: with SMTP id y123mr505427wmy.34.1569975531870; Tue, 01 Oct 2019 17:18:51 -0700 (PDT)
MIME-Version: 1.0
References: <A6C64C9E-DD8C-4C52-9066-78B040F4C3B0@gmail.com> <CAOSSMjVNMDR9usj_36x-HmyHbS1eGW0H6cg_TAtZdii9-qSYfg@mail.gmail.com> <BA079549-FD18-42D7-8046-D6A593D3833B@gmail.com> <598E0AA2-8765-4359-BB14-6BBA12BBF15B@cisco.com> <CAOSSMjVp83FPndYCnxFjkRrJLQ03sPJOz7dAQqdcCkSEyiM0PA@mail.gmail.com> <9381A27B-DE29-4949-A1CD-B60A6428C861@cisco.com> <CAOSSMjVKM8mRjqKWc0hUFd3V-wNwdFkXX0QvpXC8qrDuTB+_HQ@mail.gmail.com> <MN2PR11MB356509C740F75276D023AA97D8880@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB356509C740F75276D023AA97D8880@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Timothy Winters <twinters@iol.unh.edu>
Date: Tue, 1 Oct 2019 20:18:40 -0400
Message-ID: <CAOSSMjVVqXFN1kYyTfD6gY79pFGJ0+cEs7iQ05JqmpYCXLJ33g@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "Shwetha Bhandari (shwethab)" <shwethab@cisco.com>, Bob Hinden <bob.hinden@gmail.com>, =?UTF-8?Q?Ole_Tr=C3=B8an?= <otroan@employees.org>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "draft-ietf-6lo-backbone-router@ietf.org" <draft-ietf-6lo-backbone-router@ietf.org>, "int-ads@tools.ietf.org" <int-ads@tools.ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e244180593e269da"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/uTbjzNHNZ_7V2xn1e0caGlKo2W8>
Subject: Re: [6lo] Review of [draft-ietf-6lo-backbone-router-11 - IPv6 Backbone Router]
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: Wed, 02 Oct 2019 00:18:57 -0000

Hi Pascal,

Sorry for the delay in responding.  I think the text you added was exactly
what I was thinking and resolves all my comments.

~Tim

On Fri, Sep 20, 2019 at 9:41 AM Pascal Thubert (pthubert) <
pthubert@cisco.com>; wrote:

> Hello Tim:
>
> (adding int-ads)
>
> > I've reviewed this document and overall I think it's a good shape.  I
> have a couple of nits and comments that I've included below. (Note I
> reviewed -12).
>
>
>  >  - I have a question about Backbone side and multicast snooping.   If
> there is a switch running multicast shopping between the IPv6 Node and 6BBR
> I'm wondering how I don't see any mention of the 6BBR sending the MLDv6
> Reports.  How would this work?
>
> Not sure what an MLD snoop below the 6BBR would do that could be harmful.
> It is supposed to be transparent on the way up and filtering on the way
> down, isn't it? But you raise interesting questions:
>
> It is not mentioned but as a proxy the 6BBR should send the MLD reports
> for the SNMA of the proxied addresses towards the backbone. It attracts the
> lookups and may respond for them. This would be true in both routing proxy
> and switching proxy modes. The RFC 8505 registering node probably does not
> need to send a MLD report because the router is aware of it by the
> registration and we operate in Not-Onlink on the wireless. So there should
> not be lookups though the node expects NUDs. I could add text, cc'ing the
> group if there's an issue there that I do not see.
>
> If the node sends a MLD report, and the 6BBR acts as a router, L3 stops
> there, all set. If the 6BBR acts a L3 switch and a switching proxy, then is
> should be classical MLD snooping box though it could be just transparent.
> It would let the report through and learn from it about the liveliness of
> the node. The L3 switch intercepts ND (punts). It could intercept the MLD
> report, if you think it' a good idea then we can add text as well.
>
> >   - Section 5 mentions "The EDAC message SHOULD carry the SLLAO used in
> NS messages by the  6BBR for that Binding, and the EDAR message SHOULD
> carry the TLLAO associated with the currently accepted registration"  Why
> is this SHOULD, is there a reason to not do this?
>
> There was an inversion of EDAR and EDAC apparently. The 6BBR sends an EDAR
> and the 6LBR on the backbone responds with EDAC. The 6BBR provides its MAC
> address to the 6LBR knows can answer a unicast address resolution.
> The current text says
>    "
>
>  This enables a 6BBR to locate
>     the new position of a mobile 6LN in the case of a Routing Proxy
> operation,
>     and opens the capability for the 6LBR to serve as a mapping server in
> the
>     future."
>
> The implicit reference is to
> https://tools.ietf.org/html/draft-thubert-6man-unicast-lookup-00 but
> since the draft is not even adopted, the forward reference may be
> optimistic. If you are interested in this work we could continue together?
>
>
> > NIT:
>
>  >  - Page 9 has mutlicastinto should multicast into.
>
>  >  - Section 7 " A Routing Proxy provides IPv6 ND proxy functions for
> Global and Unique Local addresses" should be "Section 7 " A Routing Proxy
> provides IPv6 ND proxy functions for Global including Unique Local
> addresses" due to Unique Local Addresses being a subset of Global address
>
> Both done in the repo : )
>
> Many thanks! Please let me know if I should add text on MLD or if we're ok
> leaving the implicit MLD as it comes naturally with the proxy advertising.
>
> All the best,
>
> Pascal
>