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

From: Charlie Perkins <[email-masked]>
Date: Wed, 6 Jun 2018 23:10:46 -0700

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 7 Jun 2018 09:44:55 +0000

Hello Charlie :

I disagree, quite strongly. Your proposal makes full sense and is the way specs build on others and  this progress historically. Our effort here is different. We build this spec in order to enable the other 2, AP-ND and 6BBR. The key point is to allow a node that implement only this spec to interact with a node that implements AP ND or 6BBR or both. This is why, here, we provide the abstract ‘interface’ to those, while the other docs provide the ‘implementation’.

Note that thanks to Samita, we already did a good clean up removing extraneous 6BBR details. I’m not saying that we did not miss things, but that there is a design point overall that we want to preserve, and that is different from the one you acted upon.

Please see below for more, if that helps refine the thinking, but the above is the core of it:

From: Charlie Perkins <[email-masked]>
Sent: jeudi 7 juin 2018 08:11
To: [email-masked]
Cc: Pascal Thubert (pthubert) <[email-masked]>; Suresh Krishnan <[email-masked]>
Subject: BBR versus rfc6775-update document

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.

[PT>] disagree, This is a motivation for the work, it is good to list it.

[PT>] Untrue in the current state of the doc which is a effectively where the concept of a 6BBR is introduced though its operation is abstracted. This spec does not need to know the gory details of how 6BBRs work, but it imposes things that any 6BBR would be doing, like meaning/use of the “moved” code. This must be treated correctly but 6LR/6LRs regardless of a whether they have a deeper knowledge of the 6BBR. This is why it is all there. IOW, this spec introduces an abstract 6BBR and proposes an “Interface” to it, and the 6BBR spec proposes an implementation for it.

                                                                   In a

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

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.

[PT>] that would work, but is not the way this document was designed. Not that the code itself could be added with AP ND. But the reason we structured all this this way is that any compliant node (with this spec only) can coexist with another that implements one of the 2 other specs on top. This is a key design point here: we want to benefit from the fact that the 3 specs are designed together to avoid backward compatibilities issues.

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

[PT>] In a flat network, a 6LN (say a Wi-Fi node) can register directly with a 6BBR (in an AP) using this spec only, and get reachability back. Since there is no proxy operation registering on behalf of the 6LN (like a 6LBR would) there is nothing special to do. This would probably work if the abstract 6BBR is implemented using a routing protocol as opposed to proxy ND with the backbone.
                     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:

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.
[PT>]
[PT>] The spec would live fine with these 2 changes, they were borderline in the change we did with Samita. It looks like good information though.

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

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.

[PT>] It is accurate, since the term is intended to mean the 6BBR “client” and only that. The object we want to define is a guy that performs the registration whether it is for itself or for someone else as a proxy, as opposed to the guy for whom the registration is done. The only case of proxy registration is to a 6BBR, so for now the definition is sufficient and accurate. We could extend the definition to any registrar as you propose and that would not hurt here. But that makes the writing of the 6BBR more complex because in a flow both the 6LN and the 6LBR would be registering nodes, opening to ambiguity in the text. The text you cite below, for instance, become unreadable.

                             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

[PT>] Nope. This is about what the 6BBR with a log on the Ethernet side does with a packet. There might be an Ethernet link between the 6LBR and the 6BBR. This is how we made our demos, a Cisco proto 6BBR and an openWSN 6LBR based on a raspberry PI. There could also be a Wi-Fi mesh between those 2, we actually deploy industrial protocols like that.

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

[PT>] As above, the Wi-Fi 6LN talks to a 6BBR using this spec only. This is useful.

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.

[PT>] Agreed. What about “The LLN nodes depend on a 6LBR and may depend on a 6BBR for their operation.”

It’s true that for link local traffic only, a node can live without a 6LBR but that’s extreme.

[PT>] I think by now it is clear that the goal of this spec is effectively to do exactly what’s written there…

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.

[PT>] Yep, thanks you so much, I’m on it now!

[PT>] Did, deeply. But as I said this doc is meant for a node interacting with a 6BBR.

[PT>] Take care,

Pascal

Hello folks,

Over the last month I've been reviewing and making editorial suggestions for the following three documents:

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

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 7 Jun 2018 14:30:26 -0700

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

> This bullet point would fit well in BBR and does not need to be in 

Better to retain the bullet and reword as follows:

  * Registration to an IPv6 ND proxy

>>          required so that multiple LLNs can operate as a single IPv6

This definition will be reworked as needed for the idea of routing 
registrar.

> "Registration", regardless of BBR.

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

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

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

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.

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

>>    the 6BBR and route them over the LLN to the Registered Node.

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

>>    was transferred to another 6BBR as the consequence of a movement of

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.

> true (i.e., a lot "more true") and depicts the security point just as 

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

>>    effectively providing a solution to the requirements expressed in

This will be reworded to be aligned with the abovementioned passages.

Regards,
Charlie P.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Jun 2018 06:30:31 +0000

I agree with Charlie below but maybe for non-blocking tiny details.

The bottom line is that RFC 6775 update defines the interface that the 6LN will use to get routing services. This interface was initially designed for the sole use of the 6BBR spec. As it goes it is good enough to get routing services from RPL (https://tools.ietf.org/html/draft-thubert-roll-unaware-leaves) and RIFT (https://tools.ietf.org/html/draft-ietf-rift-rift) so the pointer to the 6BBR should be maintained but generalized.

This is why the change is mostly to define the routing proxy, indicate that the 6BBR is a routing proxy, and in a number of places change 6BBR to routing proxy.

The tiny details that we still need to agree upon are places like fig4 where the flow all the way to the 6BBR is shown. It is not needed for this spec. Everything on the right could be abstracted to the work by either the 6LR, or the routing proxy if the 6LN attaches directly to the routing proxy. I still liked to maintain that picture, to help the reader that does not need/want to look at the BBR spec to get a glance at the big picture in the specific case of the 6BBR. I’d like to hear other voice(s).

Please see below:

From: Charlie Perkins <[email-masked]>
Sent: jeudi 7 juin 2018 23:30
To: [email-masked]
Cc: Pascal Thubert (pthubert) <[email-masked]>; Suresh Krishnan <[email-masked]>
Subject: Re: [6lo] BBR versus rfc6775-update document

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.

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.

[PT>] This become registration to a routing registrar, of which 6BBR doing IPv6 ND proxy is an example.

This definition will be reworked as needed for the idea of routing registrar.

[PT>] Not sure we need to rework it much. We can define the routing registrar above and here just add that the 6BBR is a routing registrar.

                                                                   In a

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 "P" flag will be redefined to signal the presence of a routing registrar, and retained in 6775bis.

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.

[PT>] I still like to show the overall flow for a real 6BBR as is there for information. But the doc lives well without it.

Old in 6775bis:

New in 6775bis:

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

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

[PT>] I agree you point on something valid here and that it should not be about disallowing. It is about the distinction between the node that performs the registration and the node for whom it is performed. In the full 6BBR flow, with all the components, 6LN, 6LR, 6LBR and 6BBR involved,  the 6LBR is the registering node in the registration to the 6BBR, and the 6LN is the registered node. We can avoid the “6BBR” if we make the text very crisp when there are 2 registrations in the same flow, one 6LN to the 6LR at the edge, and one 6LBR to 6BBR at the root.
This can be very confusing and is where fig 4 as it stands now becomes very useful.

and

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.

[PT>] yes, isn’t that done yet? We mention it even in the abstract, and serve requirements in appendix B1.

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

[PT>] WFM

[PT>] Then again, I’d like to 1) generalize as you indicate and still maintain the text above as an example.
For instance, likewise:
   This specification can be used by any wireless node to register its IPv6
    addresses with a routing registrar to obtain routing services
    such as proxy-ND operations over a Backbone Link by a 6BBR,
     effectively providing a solution to the requirements expressed in
   Appendix B.4.

[PT>] all the best,
Pascal