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) < [email protected]> 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 >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
