[6lo] BBR versus rfc6775-update document

[Charlie Perkins <[e-mail]>]

Hello folks,

I still think it would be a significant improvement to refactor the 
specification of the 6BBR mandates to live entirely within 
draft-ietf-6lo-backbone-router (BBR).  For that reason, I have prepared 
a summary of the changes to draft-ietf-6lo-rfc6775-update (6775bis) that 
would be required.  I left out a few occurrences of the term 6BBR that 
could obviously be deleted.  All citations of 
I-D.ietf-6lo-backbone-router would also be deleted.  It might be argued 
that some of the current citations of the BBR document represent 
normative references.


>    o  Registration via an IPv6 ND proxy over a Backbone Link (6BBR)

This bullet point would fit well in BBR and does not need to be in 6775bis.


>    Backbone Router (6BBR):  A logical network function in an IPv6 router
>          that proxies the 6LoWPAN ND operations specified in this
>          document to assure address uniqueness and other functions
>          required so that multiple LLNs can operate as a single IPv6
>          network.

This definition already needs to be in BBR.


>                          In a
>          Route-Over network, a 6LBR may register the 6LN to the 6BBR.


This sentence should be deleted from 6775bis definition for 
"Registration", regardless of BBR.

>    |   5   | Validation Requested: The Registering Node is challenged  |
>    |       | for owning the Registered Address or for being an         |
>    |       | acceptable proxy for the registration.  A registrar (6LR, |
>    |       | 6LBR, 6BBR) MAY place this Status in asynchronous DAC or  |
>    |       | NA messages. |


Here, the list of registrars does not need to include 6BBR, and the BBR 
document would simply add 6BBR as a registrar.  By the way, "registrar" 
is an undefined term in 6775bis, and it does merit a definition.


>    The new "L", "B", and "P" flags, indicate whether a router is capable
>    of acting as 6LR, 6LBR, and 6BBR, respectively.  These flags are not
>    mutually exclusive; an updated node can advertise multiple collocated
>    functions.


Logically speaking, "L" and "B" should be defined in 6775bis, and "P" 
should be defined in BBR.


>                      Figure 4: (Re-)Registration Flow

Figure 4 in 6775bis should be modified so that the proxy NS and proxy NA 
are not shown in 6775bis, but the current Figure 4 should be situated 
within the BBR document with explanations about the proxy messages and 
NS(DAD) operation.

Old in 6775bis:

>    o  The Target Address in the NS containing the EARO is now the field
>       that indicates the address that is being registered, as opposed to
>       the Source Address field as specified in [RFC6775] (see
>       Section 5.5).  This change enables a 6LBR to use one of its
>       addresses as source of the proxy-registration of an address that
>       belongs to a LLN Node to a 6BBR.  This change also avoids in most
>       cases the use of an address as source address before it is
>       registered.


New in 6775bis:

>    o  The Target Address in the NS containing the EARO is now the field
>       that indicates the address that is being registered, as opposed to
>       the Source Address field as specified in [RFC6775] (see
>       Section 5.5).   This change avoids in most cases the use of an 
> address
>       as source address before it is registered.

------------------------------  continuing  ------------------

>    The Registering Node is the node that performs the registration to
>    the 6BBR.  As in [RFC6775], it may be the Registered Node as well ...

If there are multiple 6LRs in the routing path from 6LN to 6LBR, I don't 
think this statement is completely accurate.  It would be accurate if 
the words "to the 6BBR" were omitted.


>                              In that case, if the Registered Node is 
> reachable from the
>    6BBR over a Mesh-Under mesh, the Registering Node indicates the MAC
>    Address of the Registered Node as the SLLA in the NS(EARO).

and

>   This enables the Registering Node to attract the packets from
>    the 6BBR and route them over the LLN to the Registered Node.

I think these statements remain accurate if 6BBR is replaced by 6LBR.


>                        As described in [I-D.ietf-6lo-backbone-router], the
>    "Moved" status can be used by a 6BBR in an NA(EARO) message to
>    indicate that the ownership of the proxy state on the Backbone Link
>    was transferred to another 6BBR as the consequence of a movement of
>    the device.


This statement *really* belongs in the BBR draft and does not belong in 
6775bis.


>    The LLN nodes depend on the 6LBR and the 6BBR for their operation.


This statement cannot be true in networks that don't have any 6BBRs.  
And, it's not exactly true in LLNs that have peer-to-peer routing, 
either.  In any case, a modified version deleting 6BBR is pretty much 
true (i.e., a lot "more true") and depicts the security point just as well.


>    This specification can be used by any wireless node to associate at
>    Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing
>    services including proxy-ND operations over a Backbone Link,
>    effectively providing a solution to the requirements expressed in
>    Appendix B.4.


This statement should fit much better in the BBR draft.

===========================================================


If it were considered acceptable to make the changes indicated above, I 
would be very happy to supply a revised version of 6775bis by next 
Tuesday.  I have already provided a thorough review for the current BBR 
document and expect to be making additional discussion points after 
tomorrow.

Thanks in advance for your consideration of my proposal.

Regards,
Charlie P.







On 5/22/2018 3:15 PM, Charlie Perkins wrote:
>
> Hello folks,
>
> Over the last month I've been reviewing and making editorial 
> suggestions for the following three documents:
>
>  1. - draft-ietf-6lo-rfc6775-update
>
>  2. - draft-ietf-6lo-ap-nd
>
>  3. - draft-ietf-6lo-backbone-router
>
>
> During the reviews, I had a hard time keeping it straight in my mind 
> about which mandates belong where in the documents.  I eventually have 
> come to believe that the 6BBR stuff really belongs in document (3) and 
> the underlying parts of the extended registration specification 
> belongs in document (1) -- where they are now.
>
> So I asked Pascal about that, and Pascal said the ship had sailed.
>
> Then I asked Suresh about it, and Suresh said it was too late.
>
> So that's too bad.  But I had another idea.  Maybe we SHOULD anyway 
> locate all of the 6BBR material in document number 3, where it 
> belongs, and just arrange things so that document 3 *updates* document 
> 1 whenever document 3 can finally be published.
>
> Or, alternatively, my forlorn hope would be that I could rearrange the 
> text according to the suggestion above within the next week or so, and 
> avoid the temporary mislocation of the 6BBR mandates.  Before doing 
> so, it would be required for me to identify the texts to be moved on 
> this mailing list so as to be very specific about the task at hand.  
> Maybe a few more days detour in May, 2018, but maybe a lot easier time 
> for future implementers of these important specifications.
>
> Thanks for your consideration of my request!
>
> Regards,
> Charlie P.
>