Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-backbone-router-16: (with DISCUSS and COMMENT)

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

Hello Benjamin:
 
> Sorry to make you interrupt your holiday!

Had to go back to hard unwork. But back now : )


> > > --------------------------------------------------------------------
> > > --
> > > DISCUSS:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > Thanks for this -- it was a good read.  I just have a few
> > > super-boring poitns of apparent internal inconsistency to fix before
> publication.
> > >
> > > There seems to be an internal inconsistency relating to the handling
> > > of link- local addresses by a Bridging Proxy: Section 8
> > > descriptively says that such addresses are (always) registered
> > > ("[t]he Bridging Proxy registers any Binding including for a
> > > Link-Local address to the 6LBR"), but Section 9 has this behavior as
> > > optional ("[a] Bridging Link Proxy MAY register Local addresses at the 6BBR
> and proxy ND for these addresses over the backbone").
> >
> > For one thing the bridging proxy knows about LL addresses iff they are
> registered to it, which may only happen if the bridging proxy is the 6LR for the
> node, which is typical of hub and spoke (Wi-Fi) but not meshed wireless. In the
> Wi-Fi game you really want to extend the connectivity to the wireless guy, and
> that's possible because of the mac layer continuity (the AP is a L3 bridge). This
> text is already in a section that discusses the node being a 6LR so all I need to
> do s turn this into a SHOULD/MUST like this:
> > "
> >       A Bridging Proxy SHOULD register Link Local addresses at the 6BBR and
> >         MUST proxy ND for these addresses over the backbone.
> > "
> > The SHOULD is because the 6LBR on the backbone is optional and the proxy
> operation will work without it.
> 
> I think I'm confused about how this proposal fits in to the changes in the -17,
> though what's in the -17 itself does look like it resolves the inconsistency.

Yes that was a side thing and badly worded. I ended up with the following in published 17:
"
        Acting as Bridging Proxy the 6LR MUST proxy ND over the backbone for registered Link-Local addresses.
"
Happy that -17 overall solves the issue


> >    *  When an NS(DAD) is received for a tentative address, which means
> >       that 2 nodes form the same address at nearly the same time,
> >       section 5.4.3 of [RFC4862] cannot sort out the first come and the
> >       address is abandoned.
> 
> (Perhaps a bit more wordsmithing to do on this one re "cannot detect which
> node first claimed the address")

Applied. It was a reference to "first come first serve".

> 
> >    *  In any fashion, [RFC4862] indicates that a node never responds to
> >       a Neighbor Solicitation for a tentative address.
> 
> maybe s/fashion/case/?  Or just "In all cases".

Applied

> 
> >    This specification adds information about proxied addresses that
> >    helps sort out a duplication (different ROVR) from a movement (same
> >    ROVR, different TID), and in the latter case the older registration
> >    from the fresher one (by comparing TIDs).
> >
> >    When a Registering Node moves from one 6BBR to the next, the new 6BBR
> >    sends NA messages to update the NCE in node over the backbone.  The
> 
> nit: "nodes" (and maybe "on" vs. "over", or "NA messages over the backbone
> to update [...]"?)

I favor your second proposal:

 "
    When a Registering Node moves from one 6BBR to the next, the new 6BBR sends
    NA messages over the backbone to update existing NCEs.
"
> 
> >    6BBR may set the Override flag in the NA messages if it is known that
> >    the Registering Node will not connect directly to the backbone (e.g.,
> >    the Registering Node is attached using a different type of
> >    interface).
> 
> [obligatory "how would the 6BBR know that?"]

Sadly we do not have signaling for a 6LN that is attached on the backbone to tell the 6BBR that but will always delegate 6ND operation and will not take over until further notice.
That's one of the things we could do at 6MAN I guess if 6MAN takes over the next phase - that's hopeful thinking but any help / support would be strongly appreciated.
For now, we can only provide example cases like a non-bridgeable LLN interface, or configuration. Let me reword.
"
   The 6BBR may set the Override flag in the NA messages if it does not
   compete with the Registering Node for the NCE in backbone nodes.
   This is assured if the Registering Node is attached via an interface
   that can not be bridged onto the backbone, making it impossible for
   the Registering Node to defend its own addresses there.  This may
   also be signaled by the Registering Node through a protocol extension
   that is not in scope for this specification.
"

> >    When the Binding is no more in Tentative state:
> 
> "no longer", I think.

Done


> >    *  an NS or an NA with an EARO that denotes an older registration
> >       (same ROVR) is answered with an NA message that carries an EARO
> >       with a status of 3 (Moved) to ensure that the stale state is
> >       removed rapidly.
> >
> >    This behavior is specified in more details in Section 9.
> > "
> 
> s/details/detail/ (this is a weird quirk of English).

: )

> 
> > In 9.1 (Binding in Tentative state)
> >
> > "
> > The Tentative state covers a DAD period over the backbone during
> >    which an address being registered is checked for duplication using
> >    procedures defined in [RFC4862].
> >
> >    For a Binding in Tentative state:
> >
> >    *  The Binding MUST be removed if an NA message is received over the
> >       Backbone for the Registered Address with no EARO, or containing an
> >       EARO that indicates an existing registration owned by a different
> >       Registering Node (different ROVR).  An NA MUST be sent back to the
> >       Registering Node with a status of 1 (Duplicate).  This behavior
> 
> I'd suggest adding "to indicate that the binding has been [removed|rejected]".
> (My adversarial parser is claiming that "NA MUST be sent back" could be
> misread to apply always, not just when a qualifying NA message was received.)
> Though prepending  "In that case" as is done in the next bullet would work,
> too, and has the benefit of being consistent between items.

Doing both.
"
                                                            In that case, an NA MUST be
      sent back to the Registering Node with a status of 1 (Duplicate)
      to indicate that the binding has been rejected. "


> >    *  The Binding MUST be removed if an NA or an NS(DAD) message is
> >       received over the Backbone for the Registered Address containing
> >       an EARO with a that indicates a fresher registration ([RFC8505])
> 
> Don't we have to assume that an NA/NS(DAD) with no EARO is fresher than
> the local registration?

Yes, this is what we do in the first 2 bullets.  Changing text to "in that case..."

> >
> > Please let me know if that works for you;
> 
> That works for me, yes.
> 

Cool then. I understand that the DISCUSS is behind us now. I'll reply to the original thread for the COMMENTs.

Many thanks!

Pascal