Re: [6lo] BBR versus rfc6775-update document

[Charlie Perkins <[e-mail]>]

Hello folks,

After a long discussion with Pascal about the proposed changes, we came 
to be much closer in our outlook on the material that is needed in 
6775bis (i.e., draft-ietf-6lo-rfc6775-update).  The least confusing and 
most straightforward way I can summarize the results is to revise my 
earlier email.

In 6775bis, we can define something called a "routing registrar" as a 
feature-rich node that is both a registrar and provides Internet 
reachability for the LLN multilink subnet.  The intention in 6775bis is, 
then, to specify registration signaling to meet the needs that are 
identified for such a routing registrar.  The BBR document, on the other 
hand, is intended to specify a particular kind of routing registrar, 
which is to be called a 6BBR.

My understanding is that this has actually been mostly the intention, 
especially given the opportunity to develop 6775bis and the BBR document 
in parallel.  The documents are intended to work well together (and also 
with the AP-ND document).  Yet it is also intended to have a clear 
separation between what the 6LNs, 6LRs, and 6LBRs expect from a routing 
registrar, versus the mandates and specification details as needed for 
the kind of routing registrar known as a 6BBR.

The intention is still to submit revision 
draft-ietf-6lo-rfc6775-update-21.txt by early next week.


On 6/6/2018 11:10 PM, Charlie Perkins wrote:
>
> 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.
>

Citations of I-D.ietf-6lo-backbone-router that might be taken to 
represent normative references would be deleted.

>
>>    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.
>

Better to retain the bullet and reword as follows:

  * Registration to an IPv6 ND proxy


>
>>    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 will be reworked as needed for the idea of routing 
registrar.


>
>>                          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.
>

The operation is described elsewhere and doesn't belong in the definition.

>
>>    |   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.
>

Definitions for "registrar" and "routing registrar" will be provided.  
The last sentence will make it clear that the list of example registrars 
is not intended to be exclusive of other possibilities.

>
>>    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.
>

The "P" flag will be redefined to signal the presence of a routing 
registrar, and retained in 6775bis.

>
>>                      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.
>

The revised figure 4 in 6775bis will attempt to clarify the above 
architectural considerations.  The Figure 4 currently in 6775bis will be 
introduced into the BBR document; it is already specialized to the case 
of 6BBRs.



> 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 enables a 6LBR to proxy the registration
       of an address that belongs to a 6LN to a routing registrar, and also
       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.
>

Here, "6BBR" can be replaced by "routing registrar".  I still have a 
concern about disallowing other kinds of registrations, though. More later.

>
>>                              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.
>

Here, "6BBR" can be replaced by "routing registrar".

>
>>                        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.
>
>

Within 6775bis it should be made clear that the registration procedure 
is being enhanced to enable mobility, and that the routing registrars 
have a crucial role to play.


>
>>    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.
>

The statement could be replaced by "The LLN nodes depend on a 6LBR and 
may need the services of a routing registrar for their operation."


>
>>    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 will be reworded to be aligned with the abovementioned passages.


Regards,
Charlie P.