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

Timothy Winters <> Wed, 02 October 2019 00:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CD94120807 for <>; Tue, 1 Oct 2019 17:18:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R-4uLp7javWB for <>; Tue, 1 Oct 2019 17:18:53 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9732F12009E for <>; Tue, 1 Oct 2019 17:18:53 -0700 (PDT)
Received: by with SMTP id i16so5188029wmd.3 for <>; Tue, 01 Oct 2019 17:18:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Timothy Winters <>
Date: Tue, 1 Oct 2019 20:18:40 -0400
Message-ID: <>
To: "Pascal Thubert (pthubert)" <>
Cc: "Shwetha Bhandari (shwethab)" <>, Bob Hinden <>, =?UTF-8?Q?Ole_Tr=C3=B8an?= <>, "" <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000e244180593e269da"
Archived-At: <>
Subject: Re: [6lo] Review of [draft-ietf-6lo-backbone-router-11 - IPv6 Backbone Router]
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


On Fri, Sep 20, 2019 at 9:41 AM Pascal Thubert (pthubert) <>; 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
> 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