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

["Pascal Thubert (pthubert)" <[e-mail]>]

Many thanks Tim!


Regards,

Pascal

Le 1 oct. 2019 à 17:19, Timothy Winters <[e-mail]> a écrit :


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]<mailto:[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