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
