Hello folks,
I think that the first 6BBR to create the Binding Cache entry for a
Registered Address should be the primary 6BBR for that address. This is
in contrast to the current specification, which says that the 6BBR with
the highest IP address should be the primary. I think that this could
lead to some bit of confusion or at least extra protocol actions, if a
new 6BBR with a higher address would try to take over the role of the
primary 6BBR.
Please take a look and consider which algorithm (first versus
highest-addressable BBR) you think is preferable.
Regards,
Charlie P.
On 1/9/2019 9:47 AM, Pascal Thubert (pthubert) wrote:
Dear all :
We are ready to publish draft 10 for the backbone router and ask for
WGLC, but for one pending issue that was raised during the internal
review between authors on the 6BBR draft.
The initial intention was not to cover Link Local addresses at all,
since the multilink subnet is made of different links and the 6BBR is
a L3 box that isolates them. This is true for a routing proxy, but not
exactly right for a bridging proxy, which is really a layer-3 switch
with MAC layer bridging continuity on the data path.
But doing so, we bar Link Local traffic that could have happened
between nodes attached to different 6BBRs, e.g., in a Wi-Fi
environment where the 6BBRs can be collocated with APs and maybe
operating as Bridging Proxies. The proposal on the table is thus to
proxy ND for Link Local addresses in the case of a bridging proxy. The
registration and proxy operation would be the same as for a Global
Address, but there’s at least one caveat.
Consider the flow in
https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-09#section-3.1.
The EDAR/EDAC exchange with the 6LBR would contain the Link Local
address as opposed to a Global Address, but the EDAR/ EDAC does not
give an indication of a link ID. If the 6LBR is on-link then that’s
not an issue but if we place it farther away, we could detect
collision that would be a false positive for link local addresses used
in different MLSNs served by a same 6LBR.
There are a number of possibilities to solve this:
* A new ND option in the DAR/DAC to indicate a Link ID (complex to
specify, setup and deploy)
* Make the scope of uniqueness for a Link Local Address the
collection of links covered by a 6LBR (easy, no change in the spec)
* Indicate the MLSN prefix (e.g., in the source address of the EDAR)
and make that MLSN the scope of uniqueness for a Link Local
Address (must force the 6BBR to source the DAR with an address in
the subnet)
What do people think?
Pascal
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
