Re: [6lo] Link Local address and 6BBR

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

Hello Charlie

Please see below

> -----Original Message-----
> From: Charlie Perkins <[e-mail]>
> Sent: jeudi 10 janvier 2019 23:50
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [6lo] Link Local address and 6BBR
> 
> Hello Pascal,
> 
> I think that actually calling the 6BBRs to be an anycast group gets into matters
> about anycast operation and security that would represent an unnecessary
> burden.  For one thing, we would need an anycast address for the 6BBRs.  RFC
> 7094 lays out some considerations for anycast and if we wanted to go that way
> it would probably be appropriate to make a section of the draft about it.  Or, if
> you mean that every Registered Address would appear to be an anycast
> address on the backbone, then that seems to be a new use for anycast and
> might entail some unexpected consequences.
[PT>] Well, my answer to you would be what you just said below. We call them anycast and do nothing about it. It may be that more than one 6BBR answers? So what ?


> 
> Regarding nearly simultaneous registrations from the same Registering Node --
> is this really a problem?  If the 6LN sends out a NS and gets multiple answers,
> the 6LN should just pick one of them, and not register to all of them at the
> same time.
> 
[PT>] Exactly. Thus my conclusion to call that anycast and not do any arbitration : )
For now I left the primary text in as is...

I'll send you a new update before the week end,

Pascal


> Regards,
> Charlie P.
> 
> 
> On 1/9/2019 10:51 PM, Pascal Thubert (pthubert) wrote:
> > Hello Charlie
> >
> > When a node registers to multiple 6BBR the registered address is really like
> an anycast address on the backbone. Anycast handling is a bit under-specified
> in ND in general. And this is not the place to solve that problem, thus our
> current discussion.
> >
> > Note that first registration as you proposed is a bit hard to achieve. A node
> may move and register to more than one 6BBR at roughly the same instant.
> The TID will be the same. A race condition where the NS(DAD) cross on the
> backbone is likely and creates an anycast situation anyway.
> >
> > When present the 6LBR on the backbone may sort it out but the protocol
> elements for that resolution are missing.
> >
> > My suggestion is to mention that one can register to more than one 6BBR
> and that the address is to be treated as an anycast address on the backbone,
> the exact details out of scope - removing the concept of primary which would
> be a welcome simplification for the IESG review.
> >
> > The caveat is that the NA(EARO) will have to carry the real information as
> opposed to being obfuscated, to the different 6LBRs can recognize parallel
> registrations and ignore the conflict.
> >
> > Does that work for you ?
> >
> > Pascal
> >
> >> Le 10 janv. 2019 à 07:33, Pascal Thubert (pthubert) <[e-mail]> a
> écrit :
> >>
> >> Hello Michael
> >>
> >> I agree with the simplest, and I’m happy with the resolution to say that link
> local can be proxied in bridging mode but the scope for uniqueness is the
> collection of links covered by the 6LBR.
> >>
> >> I also agree that it is not necessarily the most common configuration but it
> appears to be needed for some .11 configurations.
> >>
> >> All the best!
> >>
> >> Pascal
> >>
> >>> Le 9 janv. 2019 à 20:27, Michael Richardson <[e-mail]> a
> écrit :
> >>>
> >>>
> >>> Pascal Thubert (pthubert) <[e-mail]> wrote:
> >>>> 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.
> >>> LL traffic is likely mDNS traffic and/or DNS-SD traffic.
> >>> I don't think it's useful to pretend it's a single subnet for the
> >>> purposes of making that work.
> >>>
> >>>> * Make the scope of uniqueness for a Link Local Address the
> >>>> collection of links covered by a 6LBR (easy, no change in the spec)
> >>> seems simplest.
> >>>
> >>>> What do people think?
> >>> I think it's too much thinking.
> >>>
> >>> --
> >>> Michael Richardson <[e-mail]>, Sandelman Software
> Works
> >>> -= IPv6 IoT consulting =-