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

[Timothy Winters <[e-mail]>]

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) <
[e-mail]> 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
>