Re: [6lo] I-D Action: draft-ietf-6lo-prefix-registration-01.txt

[Pascal Thubert (pthubert)]

Dear all:

I moved the F flag to avoid conflicts with PASA. It seems to be useful in some 
scenarios, so I'm not inclined to remove it now. Also clarifications on prefix 
overlaps.

All the best

Pascal

> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of internet-dra...@ietf.org
> Sent: Monday, August 14, 2023 6:30 PM
> To: i-d-annou...@ietf.org
> Cc: 6lo@ietf.org
> Subject: [6lo] I-D Action: draft-ietf-6lo-prefix-registration-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the IPv6 over Networks
> of Resource-constrained Nodes (6LO) WG of the IETF.
> 
>Title   : IPv6 Neighbor Discovery Prefix Registration
>Author  : Pascal Thubert
>Filename: draft-ietf-6lo-prefix-registration-01.txt
>Pages   : 24
>Date: 2023-08-14
> 
> Abstract:
>This document updates IPv6 Neighbor Discovery [RFC4861] and the
>6LoWPAN extensions [RFC8505][RFC8928] to enable a node that owns or
>is directly connected to a prefix to register that prefix to neighbor
>routers.  The registration indicates that the registered prefix can
>be reached via the advertising node without a loop.  The prefix
>registration also provides a protocol-independent interface for the
>node to request neighbor router(s) to redistribute the prefix to the
>larger routing domain using their specific routing protocols.  This
>document extends RPL [RFC6550][RFC6553][RFC9010] to enable the 6LR to
>inject the registered prefix in RPL.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-prefix-registration/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-6lo-prefix-registration-01.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-6lo-prefix-
> registration-01
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-
> drafts
> 
> 
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] SCHC HC over IEEE 802.15.4: 2. Multihop route-over approaches

[Pascal Thubert (pthubert)]

Hello Michael 

Case 2 RPL is hopefully RFC 8138. Else it’s the non storing tunnel as in RFC 
9008, the SCHC always encapsulating to the root and back.


Regards,

Pascal

> Le 13 juil. 2023 à 17:36, Michael Richardson  a écrit :
> 
> 
> {I haven't read your draft, but I'll get to it}
> 
> Carles Gomez Montenegro  wrote:
>> - “Straightforward Route-Over” incurs the lowest header overhead, as it
>> only requires the SCHC Dispatch (1 byte). However, it is the most
>> demanding approach in terms of memory usage, since all network nodes
>> (including intermediate nodes) need to store all the Rules in use in
> 
> At this point all constrained networks are purpose-built, usually for a
> single application.  (This is not how many thought it would work, if you go
> back to 2007ish...)
> As I understand SCHC, the Rules are not dynamic, and so a network built using
> this method would be provisioned correctly.
> 
>> - “Tunneled, RPL-based Route-Over” incurs greater header overhead (with
>> some cases in the order of 12-16 bytes, although it may be more
> 
> I'm guessing that this overhead is in the RH3, and that in the absense of
> SCHC, that we'd still have to spend that overhead?
> 
>> - “Pointer-based Route-Over approach” also only requires the endpoints
>> to store the Rules they will need to communicate with other
> 
> This feels like some kind of new optimized source routing mechanism?
> 
>> A question that has been raised is whether we might want to keep all
>> three route-over approaches in the document or reduce the number of
>> such approaches. As authors we are in favor of enabling all of them,
>> since they may be complementary, and the most suitable one can be
>> chosen for each deployment.
> 
> I don't object to multiple methods in theory, if there is a way to clearly
> articulate (at build time), which one will be used.  But it would be better
> for mindshare and debugging, and code maintenance to have fewer methods.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-thubert-6lo-prefix-registration-03

[Pascal Thubert (pthubert)]

Just to steer traffic:

As an author, I support adoption. This is the logical continuation of the 
current 6lo work including the multicast registration.
It is also much needed as the missing link between prefix delegation and the 
router being aware that a prefix was delegated.

regards,

Pascal

De : 6lo <6lo-boun...@ietf.org> de la part de Carles Gomez Montenegro 

Envoyé : jeudi 13 juillet 2023 09:11
À : 6lo@ietf.org <6lo@ietf.org>
Objet : Re: [6lo] Call for WG adoption of 
draft-thubert-6lo-prefix-registration-03

Dear 6lo WG,

This is a gentle reminder of the currently open call for adoption of
draft-thubert-6lo-prefix-registration-03.

As stated in our initial message (below), the call will end on the
20th of July, EOB.

Thanks,

Shwetha and Carles

On Thu, 6 Jul 2023 at 11:44, Carles Gomez Montenegro
 wrote:
>
> Dear 6lo WG,
>
> This message starts a call for WG adoption of 
> draft-thubert-6lo-prefix-registration-03.
>
> (Link below:
> https://datatracker.ietf.org/doc/draft-thubert-6lo-prefix-registration)
>
> The call will end on the 20th of July, EOB.
>
> Please state whether you are in favor of adopting this document.
>
> Also, any comments you may have, and/or expressions of interest to review
> the document, will be very much appreciated.
>
> Thanks,
>
> Shwetha and Carles

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] SCHC HC over IEEE 802.15.4: 1. Generic vs IEEE 802.15.4-specific document

[Pascal Thubert (pthubert)]

Hello Carles:

I have an item (against the architecture) about the information that SCHC needs 
in the packets (some of which being implicit could be elided)

My bottom line is that once we have that we should be able to define the use 
cases for which a separate spec is desirable vs on that covers multiple L2s.

Same as for IPv6 over foo I guess…

Let’s talk in SF!


Regards,

Pascal

Le 13 juil. 2023 à 11:35, Carles Gomez Montenegro  a 
écrit :


Dear 6lo WG,

We would like to receive feedback about two potential discussion items 
regarding the document on transmission of SCHC-compressed packets over IEEE 
802.15.4 networks [1]. We will send one separate message for each item.

1. Generic vs IEEE 802.15.4-specific document

One question that has been raised on occasion is whether the document should be 
written specifically to enable the use of SCHC header compression over IEEE 
802.15.4 networks (i.e., the current approach) or in a generic way, independent 
of a specific underlying technology.

We (authors) followed the current IEEE 802.15.4-specific approach as it seemed 
more straightforward, and focusing on IEEE 802.15.4 entailed interesting 
opportunities. Coincidentally, this approach is similar to the original 6LoWPAN 
approach, which was designed to enable IPv6 over, mostly, IEEE 802.15.4. 
6LoWPAN has been reused/adapted in 6lo to enable IPv6 over several other 
technologies, by means of a technology-specific document for each technology. 
Perhaps a similar approach could be followed if there is interest to enable the 
use of SCHC header compression over other technologies.

Notes:

- If we write a generic document, there will still need to be a 
technology-specific document for each intended underlying technology.

- The document uses only the SCHC header compression component (i.e., 
6LoWPAN/6lo functionality is used for fragmentation).

Thoughts? Would you have any particular preference on this matter?

Thanks,

Carles and Ana (document authors)

[1] https://datatracker.ietf.org/doc/draft-ietf-6lo-schc-15dot4/
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] New Version Notification for draft-thubert-6lo-prefix-registration-03.txt

[Pascal Thubert (pthubert)]

Dear all

This document provides a simple update to RFC 8505 and 
draft-ietf-6lo-multicast-registration to enabling the registration of prefixes 
as well.
While the change in the signaling is limited,  the potential is large.
This draft solves a missing link issue between DHCP-PD handing over a prefix to 
a host and the visibility of that prefix in the subnet for routing purposes.
It also enables an autoconfigured secondary gateway to expose is ULA prefix 
inside a home network, could be handy for SLAAC.
All in all I believe it is ripe for adoption.

Dear chairs: It would be neat to call for the adoption around now so we can 
discuss the doc in IETF 117 as a WG doc, or else discuss rasied issues about 
adoption there.

all the best;

Pascal

De : internet-dra...@ietf.org 
Envoyé : lundi 26 juin 2023 11:33
À : Pascal Thubert (pthubert) 
Objet : New Version Notification for 
draft-thubert-6lo-prefix-registration-03.txt


A new version of I-D, draft-thubert-6lo-prefix-registration-03.txt
has been successfully submitted by Pascal Thubert and posted to the
IETF repository.

Name:   draft-thubert-6lo-prefix-registration
Revision:   03
Title:  IPv6 Neighbor Discovery Prefix Registration
Document date:  2023-06-26
Group:  Individual Submission
Pages:  23
URL:
https://www.ietf.org/archive/id/draft-thubert-6lo-prefix-registration-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-thubert-6lo-prefix-registration/
Html:   
https://www.ietf.org/archive/id/draft-thubert-6lo-prefix-registration-03.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thubert-6lo-prefix-registration
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-thubert-6lo-prefix-registration-03

Abstract:
   This document updates the 6LoWPAN extensions to IPv6 Neighbor
   Discovery (RFC 8505) to enable a node that owns or is directly
   connected to a prefix to register that prefix to neighbor routers.
   The registration indicates that the registered prefix can be reached
   via the advertising node without a loop.  The prefix registration
   also provides a protocol-independent interface for the node to
   request neighbor router(s) to redistribute the prefix to the larger
   routing domain using their specific routing protocols.  As an
   example, this document extends RFC 9010 to enable the 6LR to inject
   the registered prefix in RPL.




The IETF Secretariat


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] New Version Notification for draft-ietf-6lo-path-aware-semantic-addressing-01.txt

[Pascal Thubert (pthubert)]

Hello Luigi:

I was thinking; maybe we can use the I-Field defined in RFC 8505. It signals 
what the opaque field is about, see fig 1 of RFC 8505.
So if we pick one value of the I-Field (say I=1) to mean PASA, we have the 
whole opaque field to indicate whatever PASA needs to pass.
OTOH, if we do not need 8 bies, then we can define I=1 to "more flags", in 
which case the Opaque can be a extended bit field of 8 bits.
So what do we need exactly?

All the best

Pascal



> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Luigi IANNONE
> Sent: Wednesday, May 24, 2023 9:02 AM
> To: Pascal Thubert (pthubert) ;
> 6lo@ietf.org
> Subject: Re: [6lo] New Version Notification for draft-ietf-6lo-path-aware-
> semantic-addressing-01.txt
> 
> Hi Pascal,
> 
> I hear you.
> I just moved the bits to avoid direct conflict with your drafts.
> This revision focuses on the security consideration part and I invite folks
> to send feedback on that part.
> 
> Future revisions will tackle the EARO bits part.
> 
> Ciao
> 
> L.
> 
> > -Original Message-
> > From: Pascal Thubert (pthubert) 
> > Sent: Tuesday, 23 May 2023 16:12
> > To: Luigi IANNONE ; 6lo@ietf.org
> > Subject: RE: New Version Notification for draft-ietf-6lo-path-aware-
> > semantic-addressing-01.txt
> >
> > Hello Luigi:
> >
> > I see that you moved the EARO bits. But moving, or even reducing to
> > one bit, will not work. EARO is aiming at applicability to all types
> > of environments, and PASA is a very specific tech. Considering that we
> > are really running out of bits, we have to find something else.
> >
> > All the best;
> >
> > Pascal
> >
> > > -Original Message-
> > > From: 6lo <6lo-boun...@ietf.org> On Behalf Of Luigi IANNONE
> > > Sent: Tuesday, May 23, 2023 3:26 PM
> > > To: 6lo@ietf.org
> > > Subject: [6lo] FW: New Version Notification for
> > > draft-ietf-6lo-path-aware- semantic-addressing-01.txt
> > >
> > > Hello 6lo,
> > >
> > > We just submitted an update of the PASA main spec.
> > > This revision focuses on the security and privacy aspects.
> > > These two section have been added to the document and some content
> > > in the middle of the document has also be re-worked to be consistent.
> > >
> > > All feedback welcome. Please let us know if we missed something.
> > >
> > > Ciao
> > >
> > > L.
> > >
> > >
> > > > -Original Message-
> > > > From: internet-dra...@ietf.org 
> > > > Sent: Tuesday, 23 May 2023 15:23
> > > > To: Zhe Lou ; Liguangpeng (Roc, Network
> > > > Technology
> > > > Laboratory) ; Kiran Makhijani
> > > > ; Luigi IANNONE ;
> > > > Pascal Thubert ; Peng Liu
> > > > ; Rong Long
> > ;
> > > > Zhe Lou 
> > > > Subject: New Version Notification for
> > > > draft-ietf-6lo-path-aware-semantic-
> > > > addressing-01.txt
> > > >
> > > >
> > > > A new version of I-D,
> > > > draft-ietf-6lo-path-aware-semantic-addressing-01.txt
> > > > has been successfully submitted by Luigi Iannone and posted to the
> > > > IETF repository.
> > > >
> > > > Name:   draft-ietf-6lo-path-aware-semantic-addressing
> > > > Revision:   01
> > > > Title:  Path-Aware Semantic Addressing (PASA) for Low
> > power and
> > > > Lossy Networks
> > > > Document date:  2023-05-23
> > > > Group:  6lo
> > > > Pages:  32
> > > > URL:https://www.ietf.org/archive/id/draft-ietf-6lo-path-
> aware-
> > > > semantic-addressing-01.txt
> > > > Status: https://datatracker.ietf.org/doc/draft-ietf-6lo-path-
> aware-
> > > > semantic-addressing/
> > > > Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
> path-
> > > > aware-semantic-addressing
> > > > Diff:   https://author-tools.ietf.org/iddiff?url2=draft-ietf-
> 6lo-
> > > path-aware-
> > > > semantic-addressing-01
> > > >
> > > > Abstract:
> > > >This document specifies a topological addressing scheme, Path-Aware
> > > >Semantic Addressing (PASA), that enables IP packet stateless
> > > >forwarding.
> > > >No routing table needs to be built, rather, the forwarding decision
> > > >  

Re: [6lo] towards adoption of draft-thubert-6lo-prefix-registration

[Pascal Thubert (pthubert)]

Hello Michael:

> 
> I agree that we need a specification. But, I think don't think either of the
> documents you cited contain that what we need.
> Or maybe, I have mis-understood.
> 

Agreed on all. This is why I'm asking reviews for 
draft-thubert-6lo-prefix-registration, which aims at providing that missing 
link.

I guess that was missing in the text of the mail (though it was the title). 
Sorry for that!

So yes, reviews of draft-thubert-6lo-prefix-registration would be very welcome!

Pascal




> -Original Message-
> From: Michael Richardson 
> Sent: Wednesday, May 24, 2023 1:35 PM
> To: Pascal Thubert (pthubert) ; 6lo@ietf.org
> Subject: Re: [6lo] towards adoption of draft-thubert-6lo-prefix-registration
> 
> 
> Pascal Thubert \(pthubert\)  wrote:
> > At the moment there is magic (read proprietary code) that ties, say,
> > the DHCP server that delegates a prefix and the routers that install a
> > route for the delegated prefix via the delegated node. With this draft,
> > the delegated node can advertise the prefix to the routers in a
> > standard/interoperable fashion.
> 
> Yes, the DHCP relay has to snoop the replies.
> I've complained about this at DHCwg some years ago in the past, and been told
> that vendors X,Y,Z already have snooping code, and it would take so long to
> deploy new things, so what would be the point.
> 
> I disagree: had we done this ages ago, today, we would have working code.
> 
> > Bottom line is that it is getting more urgent to complete the work and
> > I intend to ask for adoption at IETF 117.
> 
> > To progress on this, reviews would be much appreciated between now and
> > the next IETF.
> 
> I agree that we need a specification. But, I think don't think either of the
> documents you cited contain that what we need.
> Or maybe, I have mis-understood.
> 
> (Waiting for Ole to say "OSPF"... and there are some arguments for doing it
> this way, and it would be nice to figure out what's in the way here)
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] towards adoption of draft-thubert-6lo-prefix-registration

[Pascal Thubert (pthubert)]

Dear all;

We seeing a number of situation (e.g., draft-collink-v6ops-ent64pd and 
draft-ietf-snac-simple) where there's a need for a node to advertise that it 
owns a prefix to neighbor routers, and that packets sourced at (in case of 
multihoming) or destinated to (in case of a stub) that prefix should be passed 
to this node.

At the moment there is magic (read proprietary code) that ties, say, the DHCP 
server that delegates a prefix and the routers that install a route for the 
delegated prefix via the delegated node. With this draft, the delegated node 
can advertise the prefix to the routers in a standard/interoperable fashion.

Bottom line is that it is getting more urgent to complete the work and I intend 
to ask for adoption at IETF 117. 

To progress on this, reviews would be much appreciated between now and the next 
IETF.

Many thanks in advance 

Pascal
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] New Version Notification for draft-ietf-6lo-path-aware-semantic-addressing-01.txt

[Pascal Thubert (pthubert)]

Hello Luigi:

I see that you moved the EARO bits. But moving, or even reducing to one bit, 
will not work. EARO is aiming at applicability to all types of environments, 
and PASA is a very specific tech. Considering that we are really running out of 
bits, we have to find something else.

All the best;

Pascal

> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Luigi IANNONE
> Sent: Tuesday, May 23, 2023 3:26 PM
> To: 6lo@ietf.org
> Subject: [6lo] FW: New Version Notification for draft-ietf-6lo-path-aware-
> semantic-addressing-01.txt
> 
> Hello 6lo,
> 
> We just submitted an update of the PASA main spec.
> This revision focuses on the security and privacy aspects.
> These two section have been added to the document and some content in the
> middle of the document has also be re-worked to be consistent.
> 
> All feedback welcome. Please let us know if we missed something.
> 
> Ciao
> 
> L.
> 
> 
> > -Original Message-
> > From: internet-dra...@ietf.org 
> > Sent: Tuesday, 23 May 2023 15:23
> > To: Zhe Lou ; Liguangpeng (Roc, Network Technology
> > Laboratory) ; Kiran Makhijani
> > ; Luigi IANNONE ;
> > Pascal Thubert ; Peng Liu
> > ; Rong Long ;
> > Zhe Lou 
> > Subject: New Version Notification for
> > draft-ietf-6lo-path-aware-semantic-
> > addressing-01.txt
> >
> >
> > A new version of I-D,
> > draft-ietf-6lo-path-aware-semantic-addressing-01.txt
> > has been successfully submitted by Luigi Iannone and posted to the
> > IETF repository.
> >
> > Name:   draft-ietf-6lo-path-aware-semantic-addressing
> > Revision:   01
> > Title:  Path-Aware Semantic Addressing (PASA) for Low power and
> > Lossy Networks
> > Document date:  2023-05-23
> > Group:  6lo
> > Pages:  32
> > URL:https://www.ietf.org/archive/id/draft-ietf-6lo-path-aware-
> > semantic-addressing-01.txt
> > Status: https://datatracker.ietf.org/doc/draft-ietf-6lo-path-aware-
> > semantic-addressing/
> > Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-6lo-path-
> > aware-semantic-addressing
> > Diff:   https://author-tools.ietf.org/iddiff?url2=draft-ietf-6lo-
> path-aware-
> > semantic-addressing-01
> >
> > Abstract:
> >This document specifies a topological addressing scheme, Path-Aware
> >Semantic Addressing (PASA), that enables IP packet stateless
> >forwarding.
> >No routing table needs to be built, rather, the forwarding decision
> >is based solely on the destination address structure.  This document
> >focuses on carrying IP packets across an LLN (Low power and Lossy
> >Network), in which the topology is static, the location of the nodes
> >is fixed, and the connection between the nodes is also rather stable.
> >This specifications describes the PASA architecture, along with PASA
> >address allocation, forwarding mechanism, header format design, and
> >IPv6 interconnection support.
> >
> >This document updates RFC 8505.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> 
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Transmission of SCHC-compressed packets (draft-ietf-6lo-schc-15dot4)

[Pascal Thubert (pthubert)]

Hello Kiran:

On paper I'm all for it. Now, WRT to charter matching, I would suggest to 
consider moving the draft to the SCHC WG if that's the path this is taking.

All the best;

Pascal

From: 6lo <6lo-boun...@ietf.org> On Behalf Of Kiran Makhijani
Sent: mardi 4 avril 2023 7:20
To: 6lo@ietf.org
Subject: [6lo] Transmission of SCHC-compressed packets 
(draft-ietf-6lo-schc-15dot4)

Hello, Carles, and other authors
Thank you for presenting this work and presentation last Friday. I am repeating 
here what we discussed in the hallway after the meeting.

I am wondering is it possible to generalize the spec for any layer 2 not just 
15dot4, since there will be more commonalities than differences as we consider 
nuances over different types of media. I work in industrial IoT which is a mix 
of radio and wireless IoT devices and I can see that SCHC can be beneficial for 
both type of field devices (both are resource constrained). What do you think?

If you accept that then, it will be possible to pick one approach. I felt that 
right now 4 options are too many and a bit confusing. Perhaps, we can evaluate 
them to produce requirements, then see if one solution can satisfy those? To be 
honest I still have not finished reading the entire document so must have 
misunderstood your presentation, but will be happy to help improve it, however 
possible.

Thanks
Kiran
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] FW: I-D Action: draft-ietf-6lo-multicast-registration-13.txt

[Pascal Thubert (pthubert)]

Dear all

I published a refresher, while the document is pending shepherd write up.
The change clarifies the use of EDAR/EDAC, which was missing in the 
description, and adds a useful figure for the flow.

All the best

Pascal

-Original Message-
From: 6lo <6lo-boun...@ietf.org> On Behalf Of internet-dra...@ietf.org
Sent: mardi 7 mars 2023 11:27
To: i-d-annou...@ietf.org
Cc: 6lo@ietf.org
Subject: [6lo] I-D Action: draft-ietf-6lo-multicast-registration-13.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This Internet-Draft is a work item of the IPv6 over Networks of 
Resource-constrained Nodes WG of the IETF.

Title   : IPv6 Neighbor Discovery Multicast and Anycast Address 
Listener Subscription
Author  : Pascal Thubert
  Filename: draft-ietf-6lo-multicast-registration-13.txt
  Pages   : 38
  Date: 2023-03-07

Abstract:
   This document updates the 6LoWPAN extensions to IPv6 Neighbor
   Discovery (RFC 8505) to enable a listener to subscribe to an IPv6
   anycast or multicast address; the document updates RPL (RFC 6550) to
   add a new Non-Storing Multicast Mode and a new support for anycast
   addresses in Storing and Non-Storing Modes.  This document extends
   RFC 9010 to enable the 6LR to inject the anycast and multicast
   addresses in RPL.


The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-6lo-multicast-registration/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-6lo-multicast-registration-13.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-6lo-multicast-registration-13


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-path-aware-semantic-addressing-01

[Pascal Thubert (pthubert)]

Hi Kerry and Michael

> Kerry Lynn  wrote:
> > My main reason is that the draft has no Security Considerations
> section,
> > and I am not sure the
> > scheme can be made secure. I believe the WG should always consider the
> 
> I don't think that the lack of a SC section is a reason not to adopt.
> (They are *drafts* and do not need to be complete. This is not WGLC)
> 
> If you think that the scheme can never be secured, then that would be
> different.

Yes, this is WG adoption not IETF last call. For the use cases I have in mind, 
this scheme is actually a lot safer than more dynamic stuff.

> 
> > Second, the fact that routing is based on addressing makes me wonder
> > whether this effort
> > would encroach on Routing Area's charter.
> 
> I don't think that they want it.

There's no routing. Think of a network that's an array or a matrix of sensors, 
hard wired, like a ccd. Say you want to reach each sensor in the ccd with 
IPv6/6LoWPAN. 

You could index them x, y, and encode x, y in an IP address so the addressing 
is automatic and predictable. No need of ND, all usable addresses known in 
advance so you can block a number of well-known attacks.

Now, say that instead of being organized as an array, the sensors are organized 
as an hard wired tree (possibly with redundancy depending on the application). 
Just like you may be doing with a few switches at home today, no meshing, no 
need for STP. Should that make a difference? Couldn't we automatically and 
predictably assign an address to each of these sensors?

The application I have in mind uses hard wired devices and switches and 
everything is done at L2. There's a L2 form of L2 learning that feels like 
transparent bridging. It's over complicated for the need, and prone to bugs. 
With the proposed scheme, the address embeds the structure of the last hop 
which can be more complex than x or x,y and still as predictable. From the IP 
perspective it's still one hop, no routing.


> 
> > Third, one potential application that has been suggested is low-cost
> > sensors in server racks,
> > yet I have seen no suggested wired MAC for this application. RFC 8163
> > covers this base.
> 
> I don't buy this solution either, btw.

You need a good use case for that I guess. Once the WG owns the draft, we can 
improve the encoding and possibly extend it to more classical physical 
structure. Note that x and x,y are very simple trees and already supported.


All the best

Pascal


> --
> Michael Richardson , Sandelman Software Works  -= IPv6
> IoT consulting =-
> 
> 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-path-aware-semantic-addressing-01

[Pascal Thubert (pthubert)]

I also support adoption (as coauthor).

A number of IoT use case with fixed wiring were brought up that justify the 
need for this smart automated numbering.
The proposed solution is tightly integrated in the 6LoRH family which is 
enriched in the process.

All the best,

Pascal

From: 6lo <6lo-boun...@ietf.org> On Behalf Of Galis, Alex
Sent: mardi 31 janvier 2023 11:44
To: carles.go...@upc.edu; 6lo <6lo@ietf.org>
Cc: Galis, Alex 
Subject: Re: [6lo] Call for WG adoption of 
draft-li-6lo-path-aware-semantic-addressing-01

+1 agreed (i.e. WG adopting this document)
Best Regards
Prof Alex Galis


On 25 Jan 2023, at 13:49, Carles Gomez Montenegro 
mailto:carles.go...@upc.edu>> wrote:


⚠ Caution: External sender

Dear 6lo WG,

As you may recall, the work formerly known as 'NSA' has been modified based on 
the feedback provided by the WG. The work has also been renamed as Path-Aware 
Semantic Addressing (PASA).

The initial version of the PASA draft was presented in IETF 115. The draft has 
been updated to address the comments received. After that, the authors have 
requested a call for adoption of the draft.

This message starts a call for WG adoption for
draft-li-6lo-path-aware-semantic-addressing-01.

(Link below:
https://datatracker.ietf.org/doc/html/draft-li-6lo-path-aware-semantic-addressing-01)

The call will end on the 8th of February 23:59 (UTC).

Please state whether you are in favor of adopting this document.

Also, any comments you may have, and/or expressions of interest to review
the document, will be very much appreciated.

Thanks,

Shwetha and Carles
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for 6lo wg adoption - draft-gomez-6lo-schc-15dot4

[Pascal Thubert (pthubert)]

Dear all

As individual I support adoption this useful work. As LPWAN chair, I’d like to 
point out that we are rechartering and that the document may be better fit in 
LPWAN once the rechartering is done 

All the best;

Pascal

From: 6lo <6lo-boun...@ietf.org> On Behalf Of Shwetha
Sent: mercredi 7 décembre 2022 7:48
To: 6lo@ietf.org
Cc: 6lo-cha...@ietf.org
Subject: [6lo] Call for 6lo wg adoption - draft-gomez-6lo-schc-15dot4

Dear 6lo wg,


As per discussion during IETF 115, this message initiates a 2 week 
call-for-adoption for: 
https://datatracker.ietf.org/doc/draft-gomez-6lo-schc-15dot4/

(currently at rev 5)

Please send your opinion (for or against) to the mailing list on adopting

this  document as a 6lo WG document.



This call for adoption will end at 00:00 UTC on December 21, 2022.



Thanks,

Shwetha (as Carles is the co-author of the draft)
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] New Version Notification for draft-ietf-6lo-multicast-registration-12.txt

[Pascal Thubert (pthubert)]

Dear all

I published though the WGLC is not complete, so the next reviewers can look at 
the text with the current changes incorporated.
This version might be the one that Wi-Sun (FAN WG cc) refer in their 
specification.

All the best,

Pascal

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: mardi 22 novembre 2022 17:46
> To: Pascal Thubert (pthubert) 
> Subject: New Version Notification for draft-ietf-6lo-multicast-
> registration-12.txt
> 
> 
> A new version of I-D, draft-ietf-6lo-multicast-registration-12.txt
> has been successfully submitted by Pascal Thubert and posted to the
> IETF repository.
> 
> Name: draft-ietf-6lo-multicast-registration
> Revision: 12
> Title:IPv6 Neighbor Discovery Multicast and Anycast Address
> Listener Subscription
> Document date:2022-11-22
> Group:6lo
> Pages:36
> URL:https://www.ietf.org/archive/id/draft-ietf-6lo-
> multicast-registration-12.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-6lo-
> multicast-registration/
> Html:   https://www.ietf.org/archive/id/draft-ietf-6lo-
> multicast-registration-12.html
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-6lo-
> multicast-registration
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-
> multicast-registration-12
> 
> Abstract:
>This document updates the 6LoWPAN extensions to IPv6 Neighbor
>Discovery (RFC 8505) to enable a listener to subscribe to an IPv6
>anycast or multicast address; the document updates RPL (RFC 6550) to
>add a new Non-Storing Multicast Mode and a new support for anycast
>addresses in Storing and Non-Storing Modes.  This document extends
>RFC 9010 to enable the 6LR to inject the anycast and multicast
>addresses in RPL.
> 
> 
> 
> 
> The IETF Secretariat
> 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11

[Pascal Thubert (pthubert)]

Published as -12. Enjoy Thanksgiving !

> -Original Message-
> From: Falendysz, Gene 
> Sent: mardi 22 novembre 2022 17:44
> To: Pascal Thubert (pthubert) ; fa...@wi-sun.org;
> 6lo@ietf.org
> Subject: RE: [6lo] WG Last Call on draft-ietf-6lo-multicast-
> registration-11
> 
> Looks good.
> 
> Gene Falendysz
> Office:(864)718-6676 / Mobile: (864)723-1395
> 
> -Original Message-
> From: Pascal Thubert (pthubert) 
> Sent: Tuesday, November 22, 2022 10:57 AM
> To: Falendysz, Gene ; fa...@wi-sun.org;
> 6lo@ietf.org
> Subject: RE: [6lo] WG Last Call on draft-ietf-6lo-multicast-
> registration-11
> 
> Hello Gene
> 
> I recrafted a bit changing the default to 252 so the try plus the 3
> retries ensure that the TID leaves the straight part of the lollipop.
> The meaning has not changed though, just clarification.
> 
> 
> Does the below still work? - I added surrounding text to get the
> complete
> picture:
> 
> "
>*  A new ARO Status is introduced to indicate a "Registration
> Refresh
>   Request" (see Table 9).
> 
>   This status is used in asynchronous NA(EARO) messages to indicate
>   to peer 6LNs that they are requested to reregister all addresses
>   that were previously registered to the originating node.  The NA
>   message may be sent to a unicast or a multicast link-scope
> address
>   and should be contained within the L2 range where nodes may
>   effectively have registered/subscribed to this router, e.g., a
>   radio broadcast domain.
>   A device that wishes to refresh its state, e.g., upon reboot if
> it
>   may have lost some registration state, SHOULD send an
> asynchronous
>   NA(EARO) with this new status value.  That asynchronous multicast
>   NA(EARO) SHOULD be sent to the all-nodes link scope multicast
>   address (FF02::1) and Target MUST be set to the link local
> address
>   that was exposed previously by this node to accept registrations.
> 
>   The TID field in the multicast NA(EARO) is the one associated to
>   the Target and follows the same rules as the TID in the NS(EARO)
>   for the same Target, see section 5.2 of [RFC8505].  It is
>   incremented by the sender each time it sends a new series of NS
>   and/or NA with the EARO about the Target.  By default the TID
>   initial setting is 252.  The TID indicates a reboot when it is in
>   the "straight" part of the lollipop, between the initial value
> and
>   255.  After that the TID remains below 128 as long as the device
>   is alive.  An asynchronous multicast NA(EARO) with a TID below
> 128
>   MUST NOT be considered as indicating a reboot.
> 
>   In an unreliable environment, the asynchronous multicast NA(EARO)
>   message MAY be resent in a fast sequence for reliability, in
> which
>   case the TID MUST be incremented each time.  If the sender is a
>   6LN that also registers the Target to one or more 6LR(s), then it
>   MUST reregister before the current value of the TID and the last
>   registered value are no more comparable, see section 7.2 of
>   [RFC6550].
> 
>   The multicast NA(EARO) SHOULD be resent enough times for the TID
>   to be issued with the value of 255 so the next NA(EARO) after the
>   initial series is outside the lollipop and not confused with a
>   reboot.  A 6LN that has recently processed the multicast NA(EARO)
>   indicating "Registration Refresh Request" ignores the next
>   multicast NA(EARO) with the same status and a newer TID received
>   within the duration of the initial series.
> 
>   By default, the duration of the initial series is 10 seconds, the
>   interval between retries is 1 second, and the number of retries
> is
>   3.  The best values for the duration, the number of retries and
>   the TID initial setting depend on the environment and SHOULD be
>   configurable.
> "
> 
> All the best
> 
> Pascal
> 
> > -Original Message-
> > From: Falendysz, Gene 
> > Sent: vendredi 18 novembre 2022 21:21
> > To: Pascal Thubert (pthubert) ;
> > Pascal Thubert (pthubert) ; 6lo@ietf.org
> > Subject: RE: [6lo] WG Last Call on draft-ietf-6lo-multicast-
> > registration-11
> >
> > That sounds like it will work. Thanks for addressing our use case.
> >
> > Gene Falendysz
> > Office:(864)718-6676 / Mobile: (864)723-1395
> >
> > -Original Message-
> > From: Pascal Thubert (pthubert) 
> > Sent: Friday, November 18, 2022 9:46 AM
> > To: Falendysz, Gene ; Pascal Thubert
> > (pt

Re: [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11

[Pascal Thubert (pthubert)]

Hello Gene

I recrafted a bit changing the default to 252 so the try plus the 3 retries
ensure that the TID leaves the straight part of the lollipop. The meaning 
has not changed though, just clarification. 


Does the below still work? - I added surrounding text to get the complete 
picture:

"
   *  A new ARO Status is introduced to indicate a "Registration Refresh
  Request" (see Table 9).

  This status is used in asynchronous NA(EARO) messages to indicate
  to peer 6LNs that they are requested to reregister all addresses
  that were previously registered to the originating node.  The NA
  message may be sent to a unicast or a multicast link-scope address
  and should be contained within the L2 range where nodes may
  effectively have registered/subscribed to this router, e.g., a
  radio broadcast domain.
  A device that wishes to refresh its state, e.g., upon reboot if it
  may have lost some registration state, SHOULD send an asynchronous
  NA(EARO) with this new status value.  That asynchronous multicast
  NA(EARO) SHOULD be sent to the all-nodes link scope multicast
  address (FF02::1) and Target MUST be set to the link local address
  that was exposed previously by this node to accept registrations.

  The TID field in the multicast NA(EARO) is the one associated to
  the Target and follows the same rules as the TID in the NS(EARO)
  for the same Target, see section 5.2 of [RFC8505].  It is
  incremented by the sender each time it sends a new series of NS
  and/or NA with the EARO about the Target.  By default the TID
  initial setting is 252.  The TID indicates a reboot when it is in
  the "straight" part of the lollipop, between the initial value and
  255.  After that the TID remains below 128 as long as the device
  is alive.  An asynchronous multicast NA(EARO) with a TID below 128
  MUST NOT be considered as indicating a reboot.

  In an unreliable environment, the asynchronous multicast NA(EARO)
  message MAY be resent in a fast sequence for reliability, in which
  case the TID MUST be incremented each time.  If the sender is a
  6LN that also registers the Target to one or more 6LR(s), then it
  MUST reregister before the current value of the TID and the last
  registered value are no more comparable, see section 7.2 of
  [RFC6550].

  The multicast NA(EARO) SHOULD be resent enough times for the TID
  to be issued with the value of 255 so the next NA(EARO) after the
  initial series is outside the lollipop and not confused with a
  reboot.  A 6LN that has recently processed the multicast NA(EARO)
  indicating "Registration Refresh Request" ignores the next
  multicast NA(EARO) with the same status and a newer TID received
  within the duration of the initial series.

  By default, the duration of the initial series is 10 seconds, the
  interval between retries is 1 second, and the number of retries is
  3.  The best values for the duration, the number of retries and
  the TID initial setting depend on the environment and SHOULD be
  configurable.
"

All the best

Pascal

> -Original Message-
> From: Falendysz, Gene 
> Sent: vendredi 18 novembre 2022 21:21
> To: Pascal Thubert (pthubert) ;
> Pascal Thubert (pthubert) ; 6lo@ietf.org
> Subject: RE: [6lo] WG Last Call on draft-ietf-6lo-multicast-
> registration-11
> 
> That sounds like it will work. Thanks for addressing our use case.
> 
> Gene Falendysz
> Office:(864)718-6676 / Mobile: (864)723-1395
> 
> -Original Message-
> From: Pascal Thubert (pthubert) 
> Sent: Friday, November 18, 2022 9:46 AM
> To: Falendysz, Gene ; Pascal Thubert
> (pthubert) ; 6lo@ietf.org
> Subject: [EXTERNAL] RE: [6lo] WG Last Call on draft-ietf-6lo-multicast-
> registration-11
> 
> Oh!
> 
> Well, at least there's text for that. The next paragraph is about
> incrementing the TID when resending, but not the way a real TID
> operates, quoting "
>   In an unreliable environment, the multicast NA(EARO) message may
>   be resent in a fast sequence, in which case the TID must be
>   incremented each time.  A 6LN that has recently processed the
>   NA(ARO) ignores the NA(EARO) with a newer TID received within the
>   duration of the fast sequence.  That duration depends on the
>   environent and has to be configured.  By default, it is of 10
>   seconds.
> "
> 
> Now that I think about it I should make it compliant with real TID
> operations (https://urldefense.com/v3/__https://www.rfc-
> editor.org/rfc/rfc6550*section-7.2__;Iw!!F7jv3iA!wbY9lpxIso9IuZ2-
> gm49L9zsnrsuNqF6IWpuxn6RpF57II9mE2Q78qSFX9D2MFMLzzuK5OFVpBEIDo6N8JdY2xr
> wNVr9LKz_KgE$ ) so the 6LN/LFN would figure it is no more in syn

Re: [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11

[Pascal Thubert (pthubert)]

Hello Gene

The new text now says:

"
  The TID field in the multicast NA(EARO) is the one associated to
  the Target and follows the same rules as the TID in the NS(EARO)
  for the same Target, see section 5.2 of [RFC8505].  It is
  incremented by the sender each time it sends a new sequence of NS
  and/or NA with the EARO about the Target.  By default the TID
  initial setting is 240.  In an unreliable environment, the
  multicast NA(EARO) message may be resent in a fast sequence, in
  which case the TID must be incremented each time.  If the sender
  is a 6LN that also registers the Target to one or more 6LR(s),
  then it MUST reregister before the current value of the TID and
  the last registered value are no more comparable, see section 7.2
  of [RFC6550].  By default multicast NA(EARO) is resent 3 times
  with a interval of 1 second.  A 6LN that has recently processed
  the multicast NA(EARO) indicating "Registration Refresh Request"
  ignores the next multicast NA(EARO) with the same status and a
  newer TID received within the duration of the fast sequence.  By
  default, it is of 10 seconds.  The best values for the duration,
  the number of retries and the TID initial setting depend on the
  environment and SHOULD be configurable.
"
The commit is 
https://github.com/pthubert/6lo-multicast-registration/commit/e83b75db397570fa435257324e0d9f0c92712cd5

Please let me know if I missed something and/or we need to craft it further.

All the best,

Pascal

> -Original Message-
> From: Falendysz, Gene 
> Sent: vendredi 18 novembre 2022 21:21
> To: Pascal Thubert (pthubert) ;
> Pascal Thubert (pthubert) ; 6lo@ietf.org
> Subject: RE: [6lo] WG Last Call on draft-ietf-6lo-multicast-
> registration-11
> 
> That sounds like it will work. Thanks for addressing our use case.
> 
> Gene Falendysz
> Office:(864)718-6676 / Mobile: (864)723-1395
> 
> -Original Message-
> From: Pascal Thubert (pthubert) 
> Sent: Friday, November 18, 2022 9:46 AM
> To: Falendysz, Gene ; Pascal Thubert
> (pthubert) ; 6lo@ietf.org
> Subject: [EXTERNAL] RE: [6lo] WG Last Call on draft-ietf-6lo-multicast-
> registration-11
> 
> Oh!
> 
> Well, at least there's text for that. The next paragraph is about
> incrementing the TID when resending, but not the way a real TID
> operates, quoting "
>   In an unreliable environment, the multicast NA(EARO) message may
>   be resent in a fast sequence, in which case the TID must be
>   incremented each time.  A 6LN that has recently processed the
>   NA(ARO) ignores the NA(EARO) with a newer TID received within the
>   duration of the fast sequence.  That duration depends on the
>   environent and has to be configured.  By default, it is of 10
>   seconds.
> "
> 
> Now that I think about it I should make it compliant with real TID
> operations (https://urldefense.com/v3/__https://www.rfc-
> editor.org/rfc/rfc6550*section-7.2__;Iw!!F7jv3iA!wbY9lpxIso9IuZ2-
> gm49L9zsnrsuNqF6IWpuxn6RpF57II9mE2Q78qSFX9D2MFMLzzuK5OFVpBEIDo6N8JdY2xr
> wNVr9LKz_KgE$ ) so the 6LN/LFN would figure it is no more in sync with
> the 6LR/FFN just because the two sequence numbers are determined not to
> be comparable.
> 
> If that fits your need I can update the text in that direction, say
> that the 6LR sets the TID field in the broadcast NA(EARO) like it would
> for NS(EARO), following section RPL 7.2, that there should be several
> in a short time after reboot, and that the 6LN keeps track of the 6LR
> TID, and considers that he needs to reregister if the TID in a new NA
> is not comparable.
> 
> Would that help?
> 
> Pascal
> 
> 
> > -Original Message-
> > From: 6lo <6lo-boun...@ietf.org> On Behalf Of Falendysz, Gene
> > Sent: vendredi 18 novembre 2022 15:16
> > To: Pascal Thubert (pthubert) ;
> > 6lo@ietf.org
> > Subject: Re: [6lo] WG Last Call on
> > draft-ietf-6lo-multicast-registration-11
> >
> > Hi Pascal,
> >   The problem I am trying to solve is that currently Wi-SUN FAN is
> > specifying that once a node responds to a NA(EARO) (request to
> > reregister) it ignores all others for 5 minutes. This is to minimize
> > flooding. The problem with that approach is that it is not uncommon
> > for a meter to experience several power cycles when reclosers are
> > trying to isolate a fault in the grid. The 5 minute ignore period
> > would mean that it is possible for a node to ignore a valid request.
> I
> > am hoping that the TID can be used to indicate when the request is
> new
> > and not a repeat of the previous request, incrementing with each
> power cycle.
> >
> > Best regar

Re: [6lo] [IPv6] WG Last Call on draft-ietf-6lo-multicast-registration-11

[Pascal Thubert (pthubert)]

Done  many thanks, Tom.

> -Original Message-
> From: tom petch 
> Sent: lundi 21 novembre 2022 18:08
> To: Pascal Thubert (pthubert) ; Mark Smith
> ; carles.go...@upc.edu
> Cc: 6lo@ietf.org; 6man WG 
> Subject: Re: [IPv6] WG Last Call on draft-ietf-6lo-multicast-
> registration-11
> 
> From: Pascal Thubert (pthubert) 
> Sent: 21 November 2022 13:11
> 
> Many thanks Tom.
> 
> As a reference for the reader since it is unpublished, the current
> title in github is:
> "
>  IPv6 Neighbor Discovery Multicast and Anycast Address Listener
>   Subscription "
> And the current abstract is as follows:
> "
>This document updates RFC 8505 to enable a listener to subscribe an
>IPv6 anycast or multicast address; the draft updates RFC 6550 (RPL)
>to add a new Non-Storing Multicast Mode and a new support for
> anycast
>addresses in Storing and Non-Storing Modes.  This document extends
>RFC 9010 to enable the 6LR to inject the anycast and multicast
>addresses in RPL.
> "
> >
> > Equally I found Multicast on its own adequate,  Yes the I-D caters
> for
> > Anycast and that is in the Abstract but I query the need for it in
> the
> > Title- a reader  might well wonder about the latter and find the
> > answer in the Abstract.
> 
> Pardon my non-native limitation here; I read this as:
>  "anycast is superfluous, find it in the abstract" is that correct?
> The source of confusion is that your initial proposal was "Subscribing
> to IPv6 Broadcast and Multicast Addresses in a 6LN Network"
> Which clearly was a typo so I read " IPv6 Broadcast" -> "IPv6 Anycast"
> and I applied that. Also, Mark recommended to place Anycast in the
> title.
> 
> > My thought remains that the Title should lead into the Abstract, as
> > the Abstract leads into the document but in neither case will the
> > former cover all that the latter does.
> 
> Makes full sense to me.
> 
> > So with no explicit mention of ND in the Abstract I query its
> > appearance in the Title.
> 
> I guess this calls for a change in the abstract to mention it.
> The tension here is that we need to list RFC 8505 in the abstract
> because we extend it. RFC 8505 is "Registration Extensions for IPv6
> over 6LoWPAN Neighbor Discovery" so using those words in full would be
> cumbersome.
> 
> > I think that the Title of the RFC needs to indicate the type of
> > network involved and did look at other RFC to see how this network is
> > referred to and see much usage of Low-Power Wireless Personal Area
> > Networks (6LoWPANs) which seems cumbersome to me but suggests that
> > there is no recognised, shorter tag which might be used:-(.
> 
> True; and even worse, LoWPAN in IEEE parlance is 802.15.4 only.
> But 6LoWPAN ND works on any link I'm aware of. So the term 6LoWPAN ND
> is Highly misleading.
> 
> >
> > As you gather, I think that titles matter, as do abstracts, that they
> > should be short enough to read, recognise or remember but should not
> > be overloaded with all the possible semantics.
> >
> > By contrast, I care little about the title of the I-D which almost
> > vanishes once the RFC is published; for me, many I-D titles are too
> > cumbersome although this one is just fine (no need for Anycast or ND
> in it:-).
> 
> I appreciate that, Tom.
> 
> From the discussion above I'm not sure I should take anycast out of the
> title.
> I made the changes below:
> 
>  IPv6 Neighbor Discovery Multicast and Anycast Address Listener
>   Subscription
> 
>This document updates the 6LoWPAN extensions to IPv6 Neighbor
>Discovery (RFC 8505) to enable a listener to subscribe an IPv6
>anycast or multicast address; the draft updates RPL (RFC 6550) to
> add
>a new Non-Storing Multicast Mode and a new support for anycast
>addresses in Storing and Non-Storing Modes.  This document extends
>RFC 9010 to enable the 6LR to inject the anycast and multicast
>addresses in RPL.
> 
> 
> Well, thank you for considering my suggestions.  I will shut up now
> about the Title but with a couple of editorial thoughts on the
> Abstract.   'the draft' might be better as 'the document'  and do you
> 'subscribe' addresses or 'subscribe to'?  I think the latter.
> 
> Tom petch
> 
> 
> Many thanks,
> 
> Pascal
> 
> 
> > -Original Message-
> > From: 6lo <6lo-boun...@ietf.org> On Behalf Of tom petch
> > Sent: samedi 19 novembre 2022 13:47
> > To: Pascal Thubert (pthubert) ; Mark Smith
> >

Re: [6lo] [IPv6] WG Last Call on draft-ietf-6lo-multicast-registration-11

[Pascal Thubert (pthubert)]

Many thanks Tom.

As a reference for the reader since it is unpublished, the current title in 
github is:
"
 IPv6 Neighbor Discovery Multicast and Anycast Address Listener
  Subscription
"
And the current abstract is as follows:
"
   This document updates RFC 8505 to enable a listener to subscribe an
   IPv6 anycast or multicast address; the draft updates RFC 6550 (RPL)
   to add a new Non-Storing Multicast Mode and a new support for anycast
   addresses in Storing and Non-Storing Modes.  This document extends
   RFC 9010 to enable the 6LR to inject the anycast and multicast
   addresses in RPL.
"


> 
> Equally I found Multicast on its own adequate,  Yes the I-D caters for
> Anycast and that is in the Abstract but I query the need for it in the
> Title- a reader  might well wonder about the latter and find the answer in
> the Abstract.

Pardon my non-native limitation here; I read this as:
 "anycast is superfluous, find it in the abstract" is that correct?
The source of confusion is that your initial proposal was
"Subscribing to IPv6 Broadcast and Multicast Addresses in a 6LN Network"
Which clearly was a typo so I read " IPv6 Broadcast" -> "IPv6 Anycast"
and I applied that. Also, Mark recommended to place Anycast in the title.

> My thought remains that the Title should lead into the Abstract, as the
> Abstract leads into the document but in neither case will the former cover
> all that the latter does.

Makes full sense to me.

> So with no explicit mention of ND in the Abstract I query its appearance in
> the Title.

I guess this calls for a change in the abstract to mention it.
The tension here is that we need to list RFC 8505 in the abstract because we 
extend it. RFC 8505 is "Registration Extensions for IPv6 over 6LoWPAN Neighbor
Discovery" so using those words in full would be cumbersome.


> I think that the Title of the RFC needs to indicate the type of network
> involved and did look at other RFC to see how this network is referred to
> and see much usage of Low-Power Wireless Personal Area Networks (6LoWPANs)
> which seems cumbersome to me but suggests that there is no recognised,
> shorter tag which might be used:-(.

True; and even worse, LoWPAN in IEEE parlance is 802.15.4 only. 
But 6LoWPAN ND works on any link I'm aware of. So the term 6LoWPAN ND is
Highly misleading.

> 
> As you gather, I think that titles matter, as do abstracts, that they
> should be short enough to read, recognise or remember but should not be
> overloaded with all the possible semantics.
> 
> By contrast, I care little about the title of the I-D which almost vanishes
> once the RFC is published; for me, many I-D titles are too cumbersome
> although this one is just fine (no need for Anycast or ND in it:-).

I appreciate that, Tom.

From the discussion above I'm not sure I should take anycast out of the title.
I made the changes below:

 IPv6 Neighbor Discovery Multicast and Anycast Address Listener
  Subscription

   This document updates the 6LoWPAN extensions to IPv6 Neighbor
   Discovery (RFC 8505) to enable a listener to subscribe an IPv6
   anycast or multicast address; the draft updates RPL (RFC 6550) to add
   a new Non-Storing Multicast Mode and a new support for anycast
   addresses in Storing and Non-Storing Modes.  This document extends
   RFC 9010 to enable the 6LR to inject the anycast and multicast
   addresses in RPL.

Many thanks,

Pascal


> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of tom petch
> Sent: samedi 19 novembre 2022 13:47
> To: Pascal Thubert (pthubert) ; Mark Smith
> ; carles.go...@upc.edu
> Cc: 6lo@ietf.org; 6man WG 
> Subject: Re: [6lo] [IPv6] WG Last Call on draft-ietf-6lo-multicast-
> registration-11
> 
> From: Pascal Thubert (pthubert) 
> Sent: 18 November 2022 10:56
> 
> Hello Tom:
> 
> I agree nunicast is weird and I'm not inclined to use it.
> 
> About your proposed "6LN network": we do not have that language so far. We
> have LLN but that does not imply 6LoWPAN ND, and RFC 8505 does not imply
> constrained networks. It is a stateful AAD operation, it consumes less
> resource so it works EVEN in constrained devices and networks. It's an EVEN
> not an ONLY. It makes ND greener. As an L3 function, stateful AAD should be
> abstract to the lower layers, to the network they are used in, to the
> hardware in general. And it is, more than SLAAC actually, since SLAAC is
> limited to certain abstract topologies (P2P and NBMA).
> 
> Also there's a semantic confusion between "constrained node" and "node that
> supports 6LoWPAN HC" or "node that supports 6LoWPAN ND". In this
> specification, we mean the latter, so we really refer to

Re: [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11

[Pascal Thubert (pthubert)]

Oh!

Well, at least there's text for that. The next paragraph is about incrementing 
the TID when resending, but not the way a real TID operates, quoting
"
  In an unreliable environment, the multicast NA(EARO) message may
  be resent in a fast sequence, in which case the TID must be
  incremented each time.  A 6LN that has recently processed the
  NA(ARO) ignores the NA(EARO) with a newer TID received within the
  duration of the fast sequence.  That duration depends on the
  environent and has to be configured.  By default, it is of 10
  seconds.
"

Now that I think about it I should make it compliant with real TID operations 
(https://www.rfc-editor.org/rfc/rfc6550#section-7.2) so the 6LN/LFN would 
figure it is no more in sync with the 6LR/FFN just because the two sequence 
numbers are determined not to be comparable.

If that fits your need I can update the text in that direction, say that the 
6LR sets the TID field in the broadcast NA(EARO) like it would for NS(EARO), 
following section RPL 7.2, that there should be several in a short time after 
reboot, and that the 6LN keeps track of the 6LR TID, and considers that he 
needs to reregister if the TID in a new NA is not comparable.

Would that help?

Pascal  


> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Falendysz, Gene
> Sent: vendredi 18 novembre 2022 15:16
> To: Pascal Thubert (pthubert) ;
> 6lo@ietf.org
> Subject: Re: [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11
> 
> Hi Pascal,
>   The problem I am trying to solve is that currently Wi-SUN FAN is
> specifying that once a node responds to a NA(EARO) (request to reregister)
> it ignores all others for 5 minutes. This is to minimize flooding. The
> problem with that approach is that it is not uncommon for a meter to
> experience several power cycles when reclosers are trying to isolate a
> fault in the grid. The 5 minute ignore period would mean that it is
> possible for a node to ignore a valid request. I am hoping that the TID can
> be used to indicate when the request is new and not a repeat of the
> previous request, incrementing with each power cycle.
> 
> Best regards,
> 
> Gene Falendysz
> Office:(864)718-6676 / Mobile: (864)723-1395
> 
> -Original Message-
> From: Pascal Thubert (pthubert) 
> Sent: Friday, November 18, 2022 6:09 AM
> To: Falendysz, Gene ; 6lo@ietf.org
> Subject: [EXTERNAL] RE: [6lo] WG Last Call on draft-ietf-6lo-multicast-
> registration-11
> 
> Hello Gene:
> 
> The intention in the TID is to sequence the mobility of the target address
> exposed in NS(EARO). NA (EARO) is supposed to respond unicast to the
> NS(EARO), or be used as an asynchronous response to that NS. IOW, this
> broadcast NA about target=self is new, and the fields have no specified
> meaning / behavior.
> 
> Certainly the expectation is that the TID field would still contain a TID
> associated with the target address, and I'll be happy to write that if you
> have a case. I did not see one so I just applied the "reserved" behaviour.
> 
> Is it your intention that the TID is the same as in NA(EARO) and reflects a
> counter that the router maintains for its LLA?
> 
> All the best;
> 
> Pascal
> 
> 
> > -Original Message-
> > From: 6lo <6lo-boun...@ietf.org> On Behalf Of Falendysz, Gene
> > Sent: jeudi 17 novembre 2022 15:44
> > To: Pascal Thubert (pthubert) ; 6lo@ietf.org
> > Subject: Re: [6lo] WG Last Call on
> > draft-ietf-6lo-multicast-registration-11
> >
> > Hi Pascal,
> >   In section 7.3 is this statement:
> > "That asynchronous NA(ARO) SHOULD be sent to the all-nodes link scope
> > multicast address (FF02::1) and Target MUST be set to the link local
> > address that was exposed previously by this node to accept
> > registrations, and the TID MUST be set to 0."
> > Why the "and the TID MUST be set to 0"? We need the TID to do
> > duplicate detection on the asynchronous NA(ARO).
> > In the metering world it is not uncommon for a node to power cycle
> > several times as reclosers try to isolate faults.
> >
> > Cheers,
> >
> > Gene Falendysz
> > Office:(864)718-6676 / Mobile: (864)723-1395
> >
> >
> > ___
> > 6lo mailing list
> > 6lo@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/6lo_
> > _;!!F7jv3iA!2dS7DeAq_Z8s7nFEQvpxqz9CB5Y0xD_qNKbFXdvDCZlojcAAwhaYzTc3xI
> > HLxzOK2fsFC0RdZQnaC06SZJTsmxKezgtL4lyvhas$
> 
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] [IPv6] WG Last Call on draft-ietf-6lo-multicast-registration-11

[Pascal Thubert (pthubert)]

Hello Michael:

What if we start like:

"
3.  Overview

   This specification extends [RFC8505] and inherits from [RFC8928] to
   provide a registration method - called subscription in this case -
   for anycast and multicast address.  [RFC8505] is agnostic to the
   routing protocol in which the address may be redistributed.

   In classical networks, [RFC8505] may be used for an ND proxy
   operation as specified in [RFC8929], or redistributed in a full-
   fledged routing protocol such as EVPN
   [I-D.thubert-bess-secure-evpn-mac-signaling] or RIFT
   [I-D.ietf-rift-rift].  The device mobility can be gracefully
   supported as long has the routers can exchange and make sense of the
   sequence counter in the TID field of the EARO.
"

Works?

I made this commit in prep:
https://github.com/pthubert/6lo-multicast-registration/commit/10ac63dcaae1f98d4cda1970e17747c445040763

To your question on PASA:

A PASA + RPL combo would use RPL MOP 0 since the routing down is signaled in 
the address so RPL does not play there.
The steps would be MOP 0 defines the DODAG and the default route. Normal 
6LoWPAN + RPL for packets up towards the root.
Then the nodes would form their own PASA based on the PASA of their preferred 
parent and register that address to their applications in the backend.
Then the application would speak directly to those addresses. The root would 
turn the address in a PASA-6LoRH which handles the routing down. 

To Luigi: we're probably missing the step where the parent advertises its PASA 
address to tell the child to form its own. Maybe a flag in the NA or something 
saying the target is a PASA address. Unless it's well known?

All the best

Pascal

> -Original Message-
> From: Michael Richardson 
> Sent: jeudi 17 novembre 2022 17:33
> To: Pascal Thubert (pthubert) 
> Cc: Esko Dijk ; carles.go...@upc.edu;
> 6lo@ietf.org; i...@ietf.org
> Subject: Re: [IPv6] [6lo] WG Last Call on draft-ietf-6lo-multicast-
> registration-11
> 
> 
> Pascal Thubert \(pthubert\)  wrote:
> > Makes sense to me. What about:
> 
> I'm mostly happy with this, but maybe:
> 
> >In the case of LLNs, RPL [RFC6550] is the routing protocol of
> choice
> > and [RFC9010] specifies how the unicast address advertised with
> 
> Maybe this could mention other choices somewhere?
> What about in the case of non-LLNs?  Would it work with OSPFv3?
> Would it work for /128 prefixes on un-bridged wifi?
> 
> Could PASA make use of this? (I'm genuinely unclear)
> 
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11

[Pascal Thubert (pthubert)]

Hello Gene:

The intention in the TID is to sequence the mobility of the target address 
exposed in NS(EARO). NA (EARO) is supposed to respond unicast to the NS(EARO), 
or be used as an asynchronous response to that NS. IOW, this broadcast NA about 
target=self is new, and the fields have no specified meaning / behavior.

Certainly the expectation is that the TID field would still contain a TID 
associated with the target address, and I'll be happy to write that if you have 
a case. I did not see one so I just applied the "reserved" behaviour.

Is it your intention that the TID is the same as in NA(EARO) and reflects a 
counter that the router maintains for its LLA?

All the best;

Pascal


> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Falendysz, Gene
> Sent: jeudi 17 novembre 2022 15:44
> To: Pascal Thubert (pthubert) ; 6lo@ietf.org
> Subject: Re: [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11
> 
> Hi Pascal,
>   In section 7.3 is this statement:
> "That asynchronous NA(ARO) SHOULD be sent to the all-nodes link scope
> multicast address (FF02::1) and Target MUST be set to the link local
> address that was exposed previously by this node to accept registrations,
> and the TID MUST be set to 0."
> Why the "and the TID MUST be set to 0"? We need the TID to do duplicate
> detection on the asynchronous NA(ARO).
> In the metering world it is not uncommon for a node to power cycle several
> times as reclosers try to isolate faults.
> 
> Cheers,
> 
> Gene Falendysz
> Office:(864)718-6676 / Mobile: (864)723-1395
> 
> 
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] [IPv6] WG Last Call on draft-ietf-6lo-multicast-registration-11

[Pascal Thubert (pthubert)]

Hello Tom:

I agree nunicast is weird and I'm not inclined to use it. 

About your proposed "6LN network": we do not have that language so far. We have 
LLN but that does not imply 6LoWPAN ND, and RFC 8505 does not imply constrained 
networks. It is a stateful AAD operation, it consumes less resource so it works 
EVEN in constrained devices and networks. It's an EVEN not an ONLY. It makes ND 
greener. As an L3 function, stateful AAD should be abstract to the lower 
layers, to the network they are used in, to the hardware in general. And it is, 
more than SLAAC actually, since SLAAC is limited to certain abstract topologies 
(P2P and NBMA).

Also there's a semantic confusion between "constrained node" and "node that 
supports 6LoWPAN HC" or "node that supports 6LoWPAN ND". In this specification, 
we mean the latter, so we really refer to the L3 function not a type of nodes. 
In other words, we use 6LN and 6LR as nodes that support the L3 functions that 
6LoWPAN defined as part of IPv6 ND for the host and the router side 
respectively to provide stateful AAD. Maybe we should have introduced new terms 
but at this point it makes sense reusing the language in RFC 8505 that we are 
extending.

Considering the number of ND broadcasts we observe it's probably time we sunset 
SLAAC in any large network. Our small contribution to the planet if you like. 
But dropping AAC with SLAAC would be throwing the baby with the water of the 
bath. RFC 8505 makes AAD greener and more deterministic by avoiding the 
broadcasts in SLAAC and providing a contract between the host and the router 
for address ownership and usability. As you've seen recently on v6ops ML, SLAAC 
has a huge issue there and we're now hitting that wall.

All the best,

Pascal



> -Original Message-
> From: tom petch 
> Sent: jeudi 17 novembre 2022 17:53
> To: Pascal Thubert (pthubert) ; Mark Smith
> ; carles.go...@upc.edu
> Cc: 6lo@ietf.org; 6man WG 
> Subject: Re: [IPv6] WG Last Call on draft-ietf-6lo-multicast-registration-
> 11
> 
> From: ipv6 <mailto:ipv6-boun...@ietf.org> on behalf of Pascal Thubert 
> (pthubert)
> <mailto:pthubert=40cisco@dmarc.ietf.org>
> Sent: 17 November 2022 12:02
> 
> Done 
> 
> 
> Piling nouns in a  heap often does not work well in English and may be
> ambiguous.  The Abstract seems clear but I would not have expected it from
> the title, old or new.
> 
> Neighbor Discovery is not in the Abstract and I do not think it adds to the
> Title.  The Abstract has subscribe as a verb and that seems to me spot on.
> 
> The Abstract has 6LR without expansion but it does narrow the scope from
> all aspects of ND.
> 
> Hence I suggest something along the lines of Subscribing to IPv6 Broadcast
> and Multicast Addresses in a 6LN Network.
> In passing, I saw recently the term 'nunicast' and thought it ugly and
> incomprehensible.  It got revised to non-unicast which I understood and
> then to multicast and broadcast.
> 
> Tom Petch
> 
> From: ipv6 <mailto:ipv6-boun...@ietf.org> On Behalf Of Mark Smith
> Sent: jeudi 17 novembre 2022 2:18
> 
> Hi,
> 
> I think the naming needs to change now that it is also doing anycast, to
> something like "IPv6 Neighbor Discovery Multicast and Anycast Address
> Listener Subscription".
> 
> I think anycast is a different and distinct type of communication to
> multicast, and is in the middle between unicast and multicast:
> 
> i.e. unicast = 1 to 1; anycast = 1 to 1 of any/many; multicast = 1 to many;
> 
> Regards,
> Mark.
> 
> 
> 
> On Thu, 17 Nov 2022, 00:23 Carles Gomez Montenegro,
> <mailto:carles.go...@upc.edu<mailto:carles.go...@upc.edu>> wrote:
> Dear 6lo WG,
> 
> (CC'ing 6man.)
> 
> This message initiates WG Last Call on the following document:
> 
> "IPv6 Neighbor Discovery Multicast Address Listener Subscription"
> https://datatracker.ietf.org/doc/html/draft-ietf-6lo-multicast-registration-11
> 
> The Last Call will end on Wednesday, 30th of November.
> 
> Please provide your feedback on this document on the mailing list.
> Short confirmation messages such as "it looks fine" are also welcome.
> 
> Thanks,
> 
> Shwetha and Carles
> 
> IETF IPv6 working group mailing list
> mailto:i...@ietf.org<mailto:i...@ietf.org>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] WG Last Call on draft-ietf-6lo-multicast-registration-11

[Pascal Thubert (pthubert)]

Hello Esko:

Much appreciated! I’m fixing the typos silently.
For the other issues please see below:
https://github.com/pthubert/6lo-multicast-registration/commit/799b3919ecfa9010a031e196ca47bf4ab14d878d

Let's see in details:

> Section 3 first paragraph mentions “RPL” as if RPL would be the only 
> routing protocol of choice.
> (Third paragraph on the other hand mentions RPL as being optional, 
> which is the better way probably. RFC 8505 also consistently describes
> RPL as one of the options here so as ‘example’.) 
> So we should make clear that can be a RPL case and a non-RPL case and 
> that the behavior of 6LBR being the RPL Root or having a RPL graph is
> only applicable in the RPL-case.

Makes sense to me. What about:

"
3.  Overview

   This specification extends [RFC8505] and inherits from [RFC8928] to
   provide a registration method - called subscription in this case -
   for anycast and multicast address.  As for the unicast address
   registration, the subscription to anycast and multicast addresses is
   agnostic to the routing protocol in which this information may be
   redistributed.

   In the case of LLNs, RPL [RFC6550] is the routing protocol of choice
   and [RFC9010] specifies how the unicast address advertised with
   [RFC8505] is redistributed in RPL.  This specification also provides
   RPL extensions for anycast and multicast address operation and
   redistribution.  In the RPL case and unless specified otherwise, the
   behavior of the 6LBR that acts as RPL Root, of the intermediate
   routers down the RPL graph, of the 6LR that act as access routers and
   of the 6LNs that are the RPL-unaware destinations, is the same as for
   unicast.  In particular, forwarding a packet happens as specified in
   section 11 of [RFC6550], including loop avoidance and detection,
   though in the case of multicast multiple copies might be generated.
"

> Section says “Wi-SUN and 6TiSCH meshes [Wi-SUN]” -> should the Wi-SUN 
> reference be placed after Wi-SUN, and 6TiSCH get its own reference?

Yes, fixed

> Table 1 has for value 3: “Reserved, MUST be set to 0 and ignored by the
> receiver” -> the following would be more clear I think: “Reserved, 
> MUST be ignored by the receiver”.  The part about “MUST be set to 0” is
> unclear – a receiver can’t do that, only a sender. And the sender when
> setting to ‘3’ obviously doesn’t set it to ‘0’ at the same time?

Fun and true. Done.

> Section 7.1 grammar issue in sentence “This specification adds a new P
> field to the EARO flags is set to 1 to signal that … “

Reshuffled to:

"
7.1.  Placing the New P field in the EARO

   Section 4.1 of [RFC8505] defines the EARO as an extension to the ARO
   option defined in [RFC6775].  This specification adds a new P field
   placed in the EARO flags that is set as follows:

   *  The P field is set to 1 to signal that the Registered Address is a
  multicast address.  When the P field is 1 and the R flag is set to
  1 as well, the 6LR that conforms to this specification joins the
  multicast stream, e.g., by injecting the address in the RPL
  multicast support that is extended in this specification for Non-
  Storing Mode.

   *  The P field is set to 2 to signal that the Registered Address is
  an anycast address.  When the P field is 2 and the R flag is 1,
  the 6LR that conforms to this specification injects the anycast
  address in the routing protocol(s) that it participates to, e.g.,
  in the RPL anycast support that is introduced in this
  specification for both Storing and Non-Storing Modes.
"

> Section 14 could augment the note to the RFC Editor a bit – since 
> there are some references in the main text to “IANA” that need to be
> removed by the editor also and these are not marked with a
> particular label. (Maybe just say to check any sentence that
> mentions “IANA”.)

Sure. 
"
14.  IANA Considerations

   Note to RFC Editor, to be removed: please replace "This RFC"
   throughout this document by the RFC number for this specification
   once it is allocated; also, requests to IANA must be edited to
   reflect the IANA actions once performed.

   Note to IANA, to be removed: the I Field is defined in [RFC9010] but
   is missing from the registry, so the bit positions must be added for
   completeness in conformance with the RFC.
"

> In 14.1 / 14.2 a new registry is requested but the desired allocation
> policy is missing. See rfc 8126, e.g. “Standards action”.

True, and yes, “Standards action” seems fit for the P field where we 
really want to lock value 3 for the prefix registration. For 6LoWPAN ND
we tend to use "IETF Review" or "IESG Approval" to avoid side effects 
with other ND specs. I used it for the New EDAR Message Flags Registry.

> Section 15 Acknowledgements is empty – If none it probably can be
> removed? Or maybe this is pending additions later on?

You're in now 


> Nit: Section 7.3 says “With [RFC8505]:” and Section 8 has a similar
> 

Re: [6lo] [IPv6] WG Last Call on draft-ietf-6lo-multicast-registration-11

[Pascal Thubert (pthubert)]

Done 

From: ipv6  On Behalf Of Mark Smith
Sent: jeudi 17 novembre 2022 2:18
To: carles.go...@upc.edu
Cc: 6lo@ietf.org; 6man WG 
Subject: Re: [IPv6] WG Last Call on draft-ietf-6lo-multicast-registration-11

Hi,

I think the naming needs to change now that it is also doing anycast, to 
something like "IPv6 Neighbor Discovery Multicast and Anycast Address Listener 
Subscription".

I think anycast is a different and distinct type of communication to multicast, 
and is in the middle between unicast and multicast:

i.e. unicast = 1 to 1; anycast = 1 to 1 of any/many; multicast = 1 to many;

Regards,
Mark.



On Thu, 17 Nov 2022, 00:23 Carles Gomez Montenegro, 
mailto:carles.go...@upc.edu>> wrote:
Dear 6lo WG,

(CC'ing 6man.)

This message initiates WG Last Call on the following document:

"IPv6 Neighbor Discovery Multicast Address Listener Subscription"
https://datatracker.ietf.org/doc/html/draft-ietf-6lo-multicast-registration-11

The Last Call will end on Wednesday, 30th of November.

Please provide your feedback on this document on the mailing list.
Short confirmation messages such as "it looks fine" are also welcome.

Thanks,

Shwetha and Carles

IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] draft-ietf-6lo-multicast-registration-08 replacing MLD

[Pascal Thubert (pthubert)]

Hello Alvaro;

I can buy that. The coexistence with MLD  extends the RFC 8929 proxy to answer 
MLD reports on behalf of the green device.

So the new document would say:


  *   RFC 8929 applies on a shared link where RFC 8505 and RFC 4862 coexist for 
address autoconf (this is implicit but not fully discussed)
  *   Discuss any issue that arises in that situation.
  *   If the MLD router is a different router than the RFC 8929 BBR then the 
BBR needs to do MLD proxy for registered multicast addresses
  *   Study if the MLD proxy behaviour is different from RFC 4605.

I’d be happy to work with you on that draft. Ready when you are.

All the best,

Pascal


From: Alvaro Retana 
Sent: lundi 12 septembre 2022 23:24
To: Pascal Thubert (pthubert) ; Stig Venaas 

Cc: p...@ietf.org; 6lo@ietf.org; draft-ietf-6lo-multicast-registrat...@ietf.org
Subject: Re: draft-ietf-6lo-multicast-registration-08 replacing MLD

Hi!

Sorry to jump in — consider my comments as a WG participant.

The proposal doesn’t really work for me.  Even if the intent is for 
draft-ietf-6lo-multicast-registration to be used only on “non-broadcast IoT 
links”, there’s nothing that prevents its use on “regular” links (just like all 
the other related enhancements) — which takes us back to what Stig is asking 
about: the need for interoperability.

I would prefer it if the “future document” mentioned below is started soon, and 
not at some indeterminate time in the future.  Also, it seems to me that 
separating the ND and MLD interoperability would be a good thing.  As an 
individual, I’m willing to help if needed.

Thanks!

Alvaro.


On September 11, 2022 at 9:56:30 PM, Stig Venaas 
(s...@venaas.com<mailto:s...@venaas.com>) wrote:
Hi Pascal

Yes, that works.

Thanks,
Stig

On Tue, Aug 9, 2022 at 3:30 AM Pascal Thubert (pthubert)
mailto:pthub...@cisco.com>> wrote:
>
> Hello Stig
>
> The rationale behind a new protocol is, same as all 6lo work, power 
> efficiency in IoT space. Now, IoT is a precursor to moving more device to the 
> green side. So your point stands. Either we are specific that in the target 
> space there is no MLD at all, or we talk interactions between the two.
>
> IoT devices will typically sleep more than even cats do. They cannot stay 
> awake at all times just in case they are be polled for a report. They cannot 
> store much code either. The proposal is a simple extension to existing code, 
> since the change we're doing here was already done for classical IPv6 ND with 
> RFC 8505, 8928 and 8929. RFC 8929 typically isolates the non-broadcast IoT 
> edge from the broadcast backbone. Note that with RFC 8505, IoT devices do not 
> use SNMA so no need for MLD there either.
>
> Now for both ND and MLD, there will be a time of coexistence in the same 
> link. The documents for ND is already long awaited. My suggestion is that 
> that a future document covers both, and the current draft is for 
> non-broadcast IoT links only, no coexistence.
>
> Works?
>
> Pascal
>
>
> > -Original Message-
> > From: Stig Venaas mailto:s...@venaas.com>>
> > Sent: lundi 8 août 2022 19:21
> > To: 6lo@ietf.org<mailto:6lo@ietf.org>; 
> > draft-ietf-6lo-multicast-registrat...@ietf.org<mailto:draft-ietf-6lo-multicast-registrat...@ietf.org>
> > Cc: Alvaro Retana mailto:aretana.i...@gmail.com>>; 
> > p...@ietf.org<mailto:p...@ietf.org>
> > Subject: draft-ietf-6lo-multicast-registration-08 replacing MLD
> >
> > Hi 6lo and draft authors
> >
> > I have some concerns about this draft replacing MLD for group
> > registration.
> >
> > Having 2 different protocols for the same thing can be problematic.
> > Hosts or routers may need to support both protocols. Is it clear which
> > one should be used in different environments? Is there a chance that
> > both may be used at the same time in a network? In particular, is there
> > a chance that a router may need to simultaneously support both protocols
> > on an L3 interface? In that case it must be considered how the two
> > protocols interoperate.
> >
> > Also, we have been pushing the use of SSM in the IETF for a very long
> > time, but this draft only supports ASM since only a group address is
> > provided.
> >
> > It would be good to have some more info on the need to replace MLD. I
> > understand there are concerns about packet loss, limited resources etc.
> >
> > Regards,
> > Stig
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Pascal Thubert (pthubert)]

Hello Guangpeng 

I tried and failed so far to convince you that NSA is not by nature an IP 
address as we are used to. In my book it sits at L2 or L2.5 (with BIER and 
MPLS).

Consider this:

- if it was an IID how many devices max could there be in a subnet ?

 This is very limited not at all the traditional order of IPv6. Also it seems 
to depend on the shape of the network. IP should not be impacted by L2 
considerations. 

- NSA expresses a source route path not a destination.

 In that it is akin to an MPLS stack.

- what if I swap the device at the end of the path? 

Traditional IP expects that a device can retain its address even if it is 
plugged on a different switch port.

- what if there are multiple paths to the same device (again the point on 
redundancy)?

So if you told me that you are shooting for IP in IP and that NSA is for the 
destination in the outer header I’d be rather easy to convince. That would 
become another variation of an SRv6 compression technique. I’d then suggest you 
present it at spring.

If you told me it is a L2 or L2.5 mesh under technique I’d also listen 
carefully. The debate would become whether 6lo is home for the work.

But sorry I cannot see that NSA matches an IP address. That would fuse the 
devices and the network together.

Regards,

Pascal

> Le 24 août 2022 à 06:36, Liguangpeng (Roc, Network Technology Laboratory) 
>  a écrit :
> 
> Hi Michael,
> 
> That's great. Considering NSA lives with IPv6 space, there is very low 
> probability for the new device cannot get an address. I think we are aligned 
> with each other on supporting IPv6 in the first place.
> 
> Cheers,
> Guangpeng
> 
>> -Original Message-
>> From: Michael Richardson 
>> Sent: Wednesday, August 24, 2022 12:00 AM
>> To: Liguangpeng (Roc, Network Technology Laboratory)
>> 
>> Cc: 6lo <6lo@ietf.org>
>> Subject: Re: [6lo] Call for WG adoption of 
>> draft-li-6lo-native-short-address-03
>> 
>> 
>> "Liguangpeng (Roc, Network Technology Laboratory)" wrote:
> No, as long as there is enough address for this new device.
 
 And if there isn't?
>> 
>>> What happens if you want add the 256th device to a subnet with /24
>> IPv4
>>> address block?
>> 
>> I was a fool to have no used IPv6 in the first place.
>> 
>> --
>> Michael Richardson. o O ( IPv6 IøT consulting )
>>   Sandelman Software Works Inc, Ottawa and Worldwide
>> 
>> 
>> 
> 
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Pascal Thubert (pthubert)]

All good, Guangpeng. 

I missed (or more probably forgot over time) the 0/1 technique. So adding new 
nodes would not cause renumbering whereas rewiring will.
That was good clarification. For hardwired networks (my sensor Xmas tree) the 
mechanism appears well-suited. A tree becomes as easy to use as a hub and spoke.

All the best,

Pascal

> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Liguangpeng (Roc, Network
> Technology Laboratory)
> Sent: mardi 23 août 2022 10:14
> To: Pascal Thubert (pthubert) ;
> Pascal Thubert (pthubert) 
> Cc: Michael Richardson ; 6lo <6lo@ietf.org>
> Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-
> address-03
> 
> Hi Pascal,
> 
> There is really misunderstanding here. I'll add explanation inline.
> 
> Best Regards,
> Guangpeng
> 
> > -Original Message-
> > From: Pascal Thubert (pthubert) 
> > Sent: Tuesday, August 23, 2022 3:15 PM
> > To: Liguangpeng (Roc, Network Technology Laboratory)
> > ; Pascal Thubert (pthubert)
> > 
> > Cc: Michael Richardson ; 6lo <6lo@ietf.org>
> > Subject: RE: [6lo] Call for WG adoption of
> > draft-li-6lo-native-short-address-03
> >
> > Hello again Guangpeng
> >
> > Seems that Michael and myself miss something in the address assignment
> then.
> > Maybe some text will help the next readers avoid that misunderstanding.
> >
> > Say you have this(fig 3 + some nodes)
> >
> >
> > root   +--+
> >  1 | append more bits to form
> > |
> >  O +   | brother's address
> > |
> >   /  |  \   \  +--+
> >  /   |   \\
> > /|\ \   \
> >  +-+  /  | \  \   \
> >  |forwarder| 10 /   11   110\   \  111 \ XXX
> >  |node |  O -O   OO  O
> >  +-+/ |\ \   | \  | \
> >   /   | \  \ |  \ |  \
> > / |  \\  O   OO   O
> >   /   |\\
> >   100/1010|   101   1011  +--+
> > O O  O  O  |Prefix is '10'|
> >/|/|+--+
> >   / |   / |
> >  O  O  O  O
> >   1001 10011 10101 101011
> >
> >
> > And you add a core switch attached to root (XXX in the picture). How
> > would you name it? I guessed 1110 because that's what would happen if
> > XXX was present at the very initial time.
> Yes, correct. As per Figure 4 in the draft.
> 
> > But when XXX is finally installed, 111 must already have a child,
> > otherwise why should it be there? That child is already 1110, and then
> there's  etc...
> 111 is a leaf address, which mean there cannot be child address at any
> time. In other words, nodes (except root) with address ending with '1'
> must have no subtree. So 1110 is must not child of 111, it only can be
> child of '1'(the root). We gave concrete example in the draft to explain
> how figure 4's algorithm works. See Page 8-9.
> 
> >
> > So we have a collision for 1110. I (and I suspect Michael too)
> > expected renumbering so you get the same addresses whether XXX is
> > plugged at T=0 or later in the life of the network.
> > If you have a different plan please document it.
> 
> As clarified as above, there wouldn't be collision any more.
> >
> > Now, say that for operational issues you need to unplug 1011 from 10
> > and plug it to 11. Again, from my reading that's renumbering. What's
> > the plan to avoid it?
> >
> This is a reasonable case, but the target new parent is surely not 11. But
> it may be 110. We have moved solution of this case to another draft, see
> section 3.2 in https://datatracker.ietf.org/doc/draft-li-nsa-reliability/
> . We expect people to input concrete requirements that cause topology
> change and make the solution work for that.
> 
> > All the best,
> >
> > Pascal
> >
> >
> >
> > > -Original Message-----
> > > From: 6lo <6lo-boun...@ietf.org> On Behalf Of Liguangpeng (Roc,
> > > Network Technology Laboratory)
> > > Sent: lundi 22 août 2022 11:04
> > > To: Pascal Thubert (pthubert) 
> > > Cc: Michael Richardson ; 6lo <6lo@ietf.org>
> > &g

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Pascal Thubert (pthubert)]

Hello again Guangpeng

Seems that Michael and myself miss something in the address assignment then.
Maybe some text will help the next readers avoid that misunderstanding.

Say you have this(fig 3 + some nodes)


root   +--+
 1 | append more bits to form |
 O +   | brother's address|
  /  |  \   \  +--+
 /   |   \\
/|\ \   \
 +-+  /  | \  \   \
 |forwarder| 10 /   11   110\   \  111 \ XXX
 |node |  O -O   OO  O
 +-+/ |\ \   | \  | \
  /   | \  \ |  \ |  \
/ |  \\  O   OO   O
  /   |\\
  100/1010|   101   1011  +--+
O O  O  O  |Prefix is '10'|
   /|/|+--+
  / |   / |
 O  O  O  O
  1001 10011 10101 101011


And you add a core switch attached to root (XXX in the picture). How would you 
name it? I guessed 1110 because that's what would happen if XXX was present at 
the very initial time.
But when XXX is finally installed, 111 must already have a child, otherwise why 
should it be there? That child is already 1110, and then there's  etc...

So we have a collision for 1110. I (and I suspect Michael too) expected 
renumbering so you get the same addresses whether XXX is plugged at T=0 or 
later in the life of the network.
If you have a different plan please document it.

Now, say that for operational issues you need to unplug 1011 from 10 and plug 
it to 11. Again, from my reading that's renumbering. What's the plan to avoid 
it?

All the best,

Pascal



> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Liguangpeng (Roc, Network
> Technology Laboratory)
> Sent: lundi 22 août 2022 11:04
> To: Pascal Thubert (pthubert) 
> Cc: Michael Richardson ; 6lo <6lo@ietf.org>
> Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-
> address-03
> 
> Hello Pascal,
> 
> Please see inline.
> 
> Best Regards,
> Guangpeng
> 
> > -Original Message-
> > From: Pascal Thubert (pthubert) 
> > Sent: Monday, August 22, 2022 2:18 PM
> > To: Liguangpeng (Roc, Network Technology Laboratory)
> > 
> > Cc: Michael Richardson ; 6lo <6lo@ietf.org>
> > Subject: Re: [6lo] Call for WG adoption of
> > draft-li-6lo-native-short-address-03
> >
> > Hello Guangpeng
> >
> > If we take the DC sensors as use case and racks are organized in
> > trees, and you add a new rack then there will be renumbering.
> 
> No, it doesn't. Just attach this new rack to existing racks and don't move
> existing racks to this new rack meanwhile. The latter action is weird and
> superfluous.
> 
> >
> > This is why it’s safer to use this tech at L2. For the better and the
> > worse IoT standards happen to use the IP address as a node ID. I was
> > there when ISA 100 made that decision and I understand why. I see the
> > same arguments applying in list constrained environments.
> >
> > Now say that NSA is an L2 address or an L2.5 address. You get
> > redundancy by allowing a node to have more than one L2 address.
> > Renumbering is OK by reassigning Mac/IP matches - though it has to be
> > done carefully/transactional my as MACs are reassigned.
> >
> This is why the NSA mechanism try hard to avoid renumbering even sacrifice
> the applicability of basic mechanism in wireless network. Here, NSA is
> part of IPv6, hence it indeed a L3 address. So, I can not understand why
> NSA would map to multiple L2 addresses.
> 
> > Do it at L3 and you’re screwed.
> >
> BTW, I think derive IPv6 from L2 is not a reliable assumption considering
> privacy issues and fake MAC problems. This is why we need develop a short
> L3 address in 6lo.
> >
> > Regards,
> >
> > Pascal
> >
> > > Le 22 août 2022 à 04:37, Liguangpeng (Roc, Network Technology
> > Laboratory)  a écrit :
> > >
> > > Hi Michael,
> > >
> > > Thanks for the clarification. Please see below:
> > >> If I insert a new device in the tree, then all of the tree below
> > >> that device has to renumber.
> > > Technically saying, it may exist but it seems weird to insert a new
> > > device in
> > the middle of the tree. When a user wants a new device, a normal way
> > is a

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Pascal Thubert (pthubert)]

Thanks Kiran;

My view is that IPv6 must smoothly / silently adapt to the network as it 
exists, which is something that SCHC can help happen. 6LoWPAN can implicitly 
derive the IPv6 address from the 8 or 16 bits address, that’s the base of the 
design, with a resulting very short header; in that case the IPv6 address can 
be fully elided.

OTOH, NSA forces 1) a tree structure and 2) the addresses along that structure. 
This places constraints on the OT network and that may deter adoption in some 
cases. So on paper, NSA has a lower adoption field than 6LoWPAN.

And the resulting L3 header is larger since the IP address is still not fully 
elided. So on paper, NSA yields larger IP headers.

This is why my view is that the proposed benefit is mostly the automatic 
routing. Which yields operational issues upon changes. So it’s a pro/cons. I 
see the pro winning in a very constrained / very specific type of wired 
sensors, like Xmas tree lights where you replace the lights with sensors. This 
is a very specific type of L2, and NSA could be the way that L2 operates mesh 
under.

Note that I do not oppose encoding a source route header in an IP address. SRv6 
might do that in some fashion. I’m just no convinced that it beats 6LoWPAN in 
the general case, and no inclined to add RFCs to the pile, so it’s only harder 
to converge on one. 6LoWPAN was successful in defining one protocol that 6lo 
could adapt to many networks. That’s the power of one. This is how we got 
adoption with Wi-Sun, Thread, ISA100.11a, you name it. With NSA, we’d dilute 
this power for a L2 network that is not even clearly identified?

All the best;

Pascal

From: Kiran M 
Sent: mardi 23 août 2022 7:02
To: Pascal Thubert (pthubert) ; carle...@entel.upc.edu; 
6lo@ietf.org
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

Hello Pascal,
My apologies for late reply (I am taking some time off). Since I last wrote, 
thread has progressed quite a bit. Anyways...·

What attracted my attention is the  header structure in Figure 6. It is often 
the case that field devices are smaller 8-bit or16-bit addresses connected to a 
PLC. The general practice today is to encapsulate device address and function 
code/command to an actuator over TCP. This is an indirect communication to the 
actuator.

I thought it would be interesting if we could directly address the device and 
send the command over. By having topological structure, one benefit is that 
association to PLC or controller will always be there due to parent/child 
relationship in this address structure. This gives us savings of bits on wire, 
on both address and payload, because if the actuator is directly addressed, the 
payload only contains the command. When an OT operator sees this device in an 
HMI or SCADA systems, they see direct actuator's address, without any mapping.

It is my personal opinion (I maybe wrong) that IPV6 as is will be an overkill 
for factory floors. Moreover, I like the asymmetry in the header that source 
and destination can be variable length -  the server above could be IPv6 in the 
IT world, and actuator could be NSA in OT world. I find NSA type of mechanisms 
give better fine-tuning of limited domain industrial networks.

With regards to SCHC, maybe it is a better approach but I do not know enough. 
Two potential benefits over SCHC maybe  that the operator need not assign an 
IPV6 address to actuators/field devices; second, since we know that the shop 
floor topology and actuator's location do not change, no need to maintain the 
state... but I am just guessing.

Having said that, many forwarding related questions came up, which I should be 
dealt separately and some are already raised.

- Kiran
On 8/16/2022 1:42 PM, Pascal Thubert (pthubert) wrote:
Hello Kiran

Note that the core of the work is an autoconfiguration model along a fixed tree 
structure, and the desired “side effects” are implicit routing and short 
addresses. For short addresses, we already have SCHC and 6LoWPAN so that would 
not be a sufficient argument.
Now, I do not see how your point on IIoT matches this specification. Since a 
main objection (though not the only one) is the lack of applicability, this may 
help. Could you please elaborate?
In particular, which industrial protocol would benefit from this automatic 
assignment of IP addresses (vs. Say, mapping the protocol address into an IID 
or something)?

Many thanks in advance;

Pascal

From: 6lo <6lo-boun...@ietf.org><mailto:6lo-boun...@ietf.org> On Behalf Of 
Kiran Makhijani
Sent: mardi 16 août 2022 2:08
To: carle...@entel.upc.edu<mailto:carle...@entel.upc.edu>; 
6lo@ietf.org<mailto:6lo@ietf.org>
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

Hello,
I have quickly skimmed through the document and would like to see this work 
progress.

I see that the focus is mainly on wireless constrained devices, however, in 
industrial networks with field devices it

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Pascal Thubert (pthubert)]

You read me wrong Guangpeng.

I’m advocating for multiple NSA L2 addresses to reflect redundancy in the 
network.

And a single IP address that remains even if the network changes and maps all 
the MAC addresses.

The consequence is that the IP must not derive from MAC. 


Though I agree with Michael that privacy for Ring’s case may not be an issue, 
the device needs a permanent address and that cannot be one that depends on the 
current topology.


Regards,

Pascal

> Le 22 août 2022 à 11:04, Liguangpeng (Roc, Network Technology Laboratory) 
>  a écrit :
> 
> Hello Pascal,
> 
> Please see inline.
> 
> Best Regards,
> Guangpeng
> 
>> -Original Message-----
>> From: Pascal Thubert (pthubert) 
>> Sent: Monday, August 22, 2022 2:18 PM
>> To: Liguangpeng (Roc, Network Technology Laboratory)
>> 
>> Cc: Michael Richardson ; 6lo <6lo@ietf.org>
>> Subject: Re: [6lo] Call for WG adoption of 
>> draft-li-6lo-native-short-address-03
>> 
>> Hello Guangpeng
>> 
>> If we take the DC sensors as use case and racks are organized in trees, and 
>> you
>> add a new rack then there will be renumbering.
> 
> No, it doesn't. Just attach this new rack to existing racks and don't move 
> existing racks to this new rack meanwhile. The latter action is weird and 
> superfluous. 
> 
>> 
>> This is why it’s safer to use this tech at L2. For the better and the worse 
>> IoT
>> standards happen to use the IP address as a node ID. I was there when ISA 100
>> made that decision and I understand why. I see the same arguments applying
>> in list constrained environments.
>> 
>> Now say that NSA is an L2 address or an L2.5 address. You get redundancy by
>> allowing a node to have more than one L2 address. Renumbering is OK by
>> reassigning Mac/IP matches - though it has to be done carefully/transactional
>> my as MACs are reassigned.
>> 
> This is why the NSA mechanism try hard to avoid renumbering even sacrifice 
> the applicability of basic mechanism in wireless network. Here, NSA is part 
> of IPv6, hence it indeed a L3 address. So, I can not understand why NSA would 
> map to multiple L2 addresses.
> 
>> Do it at L3 and you’re screwed.
>> 
> BTW, I think derive IPv6 from L2 is not a reliable assumption considering 
> privacy issues and fake MAC problems. This is why we need develop a short L3 
> address in 6lo.
>> 
>> Regards,
>> 
>> Pascal
>> 
>>> Le 22 août 2022 à 04:37, Liguangpeng (Roc, Network Technology
>> Laboratory)  a écrit :
>>> 
>>> Hi Michael,
>>> 
>>> Thanks for the clarification. Please see below:
>>>> If I insert a new device in the tree, then all of the tree below that
>>>> device has to renumber.
>>> Technically saying, it may exist but it seems weird to insert a new device 
>>> in
>> the middle of the tree. When a user wants a new device, a normal way is
>> append them to the network at the end of an existing rank. Totally, you
>> mentioned a topology change manually, for which we put a sentence in
>> Section 9 of the draft to hightlight this consideration.
>>> 
>>>> I also think that it can happen if I add a new device to an existing rank.
>>> No, as long as there is enough address for this new device.
>>> 
>>> Cheers,
>>> Guangpeng
>>> 
>>>> -Original Message-
>>>> From: Michael Richardson 
>>>> Sent: Monday, August 22, 2022 12:07 AM
>>>> To: Liguangpeng (Roc, Network Technology Laboratory)
>>>> 
>>>> Cc: Alexander Pelov ; 6lo <6lo@ietf.org>
>>>> Subject: Re: [6lo] Call for WG adoption of
>>>> draft-li-6lo-native-short-address-03
>>>> 
>>>> 
>>>> "Liguangpeng (Roc, Network Technology Laboratory)" wrote:
>>>>> Thanks for share of Carpenter's draft. I fully agree with the
>>>>> content of it after a quick read. I think it's for all adoption
>>>>> process, not only for this adoption call. I believe 6lo Chairs'
>>>>> professional actions.
>>>> 
>>>>> About the technical related concern:
>>>>>> One concern that I have with NSA is that I think the network can
>>>>>> get renumbered whenever there are new devices.
>>>> 
>>>>> Can you explain a little more on how this problem happens?
>>>> 
>>>> If I insert a new device in the tree, then all of the tree below that
>>>> device has to renumber.
>>>> I also think that it can happen if I add a new device to an existing rank.
>>>> 
>>>> 
>>>> --
>>>> Michael Richardson. o O ( IPv6 IøT
>> consulting )
>>>>  Sandelman Software Works Inc, Ottawa and Worldwide
>>>> 
>>>> 
>>>> 
>>> 
>>> ___
>>> 6lo mailing list
>>> 6lo@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6lo
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] 答复: Call for WG adoption of draft-li-6lo-native-short-address-03

[Pascal Thubert (pthubert)]

Hello Rong

Please keep us tuned on the use case and what your final preference is. We 
could help you skim through possible solutions and do procons games. 


Regards,

Pascal

> Le 22 août 2022 à 11:59, longrong  a écrit :
> 
> Hi, Michael,
>
> 
>   As matter of fact, we are dealing with this problem right now, the smart 
> data center transformation cost a lot of money and additional power 
> consumptions because of those additional sensors. So, yes, we are looking for 
> such technologies that can reduce power consumption in this scenario, and 
> we'd like to verify and implement this solution in our data center for 
> improvement. Furthermore, we have some engineers also work on this kind of 
> technique issue, therefore, we hope NSA can enlighten us in some way, and 
> help solve this problem. 
> 
> 
> Thanks
> 
> 
> Research Institute of China Mobile
> 32 West XuanWuMen Ave, Xichen District,
> Beijing 100053, China
> 
> Mobile：13701354531 
> E-mail：longr...@chinamobile.com
> 
> 
> 
> -邮件原件-
> 发件人: Michael Richardson [mailto:mcr+i...@sandelman.ca] 
> 发送时间: 2022年8月19日 20:14
> 收件人: longrong
> 抄送: 6lo@ietf.org
> 主题: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03
> 
> 
> longrong  wrote:
>> for connection because of electromagnetic interference. Field
>> supervision unit(FSU) will connect to sensor by wired technology, such
>> as AI/DI/RS232/RS485/single pair ethernet. Multiple FSUs will connect
>> to hierarchical supervision centers and then make data communication
>> with supervision platform by IPv6.
> 
> This is a reasonable use case, thank you.
> Are you planning to build and/or buy products like this?
> If wired, you need at least three physical ports to make a tree :-)
> 
> The ability for installers to just wire these sensors together in any 
> topology and have them work is definitely a win.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
> 
> 
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Pascal Thubert (pthubert)]

I’m with you Michael

Though in the case of this proposal I would have one IP address per constrained 
Device and multiple L2NSA to account for the redundant networks.

I would thus not derive the IP from l2NSA but use a table eg a SCHC rule or a 
6LoWPAN context to map the IP from the MAC.

I’m still left to be convinced that someone wants to deploy a network that must 
be carefully updated (only attach extensions after the last leaf) lest 
renumbering happens. A network that can not heal and will necessitate restart 
from scratch when some physical changes happen.

I’m open to use cases like the DC sensors. Not sure that the simplicity of 
routing is worth the complexity in maintenance. Usually people prefer less 
human hassle and more protocol work than the other way around.

I’d probably deploy RPL there and possibly BIER too.

Keep safe;


Regards,

Pascal

Le 22 août 2022 à 17:44, Michael Richardson  a écrit :


"Liguangpeng (Roc, Network Technology Laboratory)" wrote:
-Original Message----- From: Pascal Thubert (pthubert)
 Sent: Monday, August 22, 2022
2:18 PM To: Liguangpeng (Roc, Network Technology Laboratory)
 Cc: Michael Richardson
; 6lo <6lo@ietf.org> Subject: Re: [6lo] Call
for WG adoption of draft-li-6lo-native-short-address-03

Hello Guangpeng

If we take the DC sensors as use case and racks are organized in
trees, and you add a new rack then there will be renumbering.

No, it doesn't. Just attach this new rack to existing racks and don't
move existing racks to this new rack meanwhile. The latter action is
weird and superfluous.

no, what you suggest is weird.
More cables and more tangles.
(I still operate systems in cabinets in data centres)

Do it at L3 and you’re screwed.

BTW, I think derive IPv6 from L2 is not a reliable assumption
considering privacy issues and fake MAC problems. This is why we need
develop a short L3 address in 6lo.

Given a wired situation of sensors in a data center, I have no privacy concerns.
If we are talking about 100baseT1, then I also have no concern with packet size.

--
Michael Richardson. o O ( IPv6 IøT consulting )
  Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: signature.asc
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Pascal Thubert (pthubert)]

Hello Guangpeng

If we take the DC sensors as use case and racks are organized in trees, and you 
add a new rack then there will be renumbering. 

This is why it’s safer to use this tech at L2. For the better and the worse IoT 
standards happen to use the IP address as a node ID. I was there when ISA 100 
made that decision and I understand why. I see the same arguments applying in 
list constrained environments. 

Now say that NSA is an L2 address or an L2.5 address. You get redundancy by 
allowing a node to have more than one L2 address. Renumbering is OK by 
reassigning Mac/IP matches - though it has to be done carefully/transactional 
my as MACs are reassigned.

Do it at L3 and you’re screwed.


Regards,

Pascal

> Le 22 août 2022 à 04:37, Liguangpeng (Roc, Network Technology Laboratory) 
>  a écrit :
> 
> Hi Michael,
> 
> Thanks for the clarification. Please see below:
>> If I insert a new device in the tree, then all of the tree below that device 
>> has to
>> renumber.
> Technically saying, it may exist but it seems weird to insert a new device in 
> the middle of the tree. When a user wants a new device, a normal way is 
> append them to the network at the end of an existing rank. Totally, you 
> mentioned a topology change manually, for which we put a sentence in Section 
> 9 of the draft to hightlight this consideration.
> 
>> I also think that it can happen if I add a new device to an existing rank.
> No, as long as there is enough address for this new device.
> 
> Cheers,
> Guangpeng
> 
>> -Original Message-
>> From: Michael Richardson 
>> Sent: Monday, August 22, 2022 12:07 AM
>> To: Liguangpeng (Roc, Network Technology Laboratory)
>> 
>> Cc: Alexander Pelov ; 6lo <6lo@ietf.org>
>> Subject: Re: [6lo] Call for WG adoption of 
>> draft-li-6lo-native-short-address-03
>> 
>> 
>> "Liguangpeng (Roc, Network Technology Laboratory)" wrote:
>>> Thanks for share of Carpenter's draft. I fully agree with the content
>>> of it after a quick read. I think it's for all adoption process, not
>>> only for this adoption call. I believe 6lo Chairs' professional
>>> actions.
>> 
>>> About the technical related concern:
 One concern that I have with NSA is that I think the network can get
 renumbered whenever there are new devices.
>> 
>>> Can you explain a little more on how this problem happens?
>> 
>> If I insert a new device in the tree, then all of the tree below that device 
>> has to
>> renumber.
>> I also think that it can happen if I add a new device to an existing rank.
>> 
>> 
>> --
>> Michael Richardson. o O ( IPv6 IøT consulting )
>>   Sandelman Software Works Inc, Ottawa and Worldwide
>> 
>> 
>> 
> 
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Pascal Thubert (pthubert)]

I agree about your point on BIER Michael. The cool thing with it is that it can 
do both unicast and multicast both with the short address. Also it will reroute 
on failure.

I’m still thinking about whether the model is relevant in IIoT as was claimed 
in this thread. I have not seen that any of the tenant of the listed protocols 
expressed interest in this work. Can someone want a network that cannot heal? 
This is against all we’ve done since arpanet. Which makes it mind boggling, and 
worth thinking twice.

In the typical IIoT case of a control loop (which typically requires a 
deterministic network) reroute must be real fast, faster than classical healing 
can happen anyway. So the various routing plans must be ready in advance and in 
case of a failure we’d need to instantly switch plan.

So on paper this draft could be a contender for IIoT use cases, though as you 
point out, not without the redundant plan. And so would BIER. Just walk a tree 
depth first assigning a bit at each step and you have the BIER version of the 
assignment.

Anyway I still see the proposed addresses as non IP, more like BIER or 15.4 
short addresses that have to be associated to real iP so the real IP is elided 
in the packet. And I do not see how this matches the 6lo charter.

Wherever this work finds a home (a new WG?), it will have to document  
requirements and show convincing uses cases, which has timidly started in this 
thread but with more handwaiving than actual facts - though I liked the DC 
sensor use case. And then confront with alternative solutions like ROLL/ BIER 
till the group selects the best match.


Regards,

Pascal

Le 20 août 2022 à 22:14, Michael Richardson  a écrit :


Alexander Pelov  wrote:
I'd be happy to discuss specific scenarios/use-cases that come from a
real-world need.

In any case, I think these are required before accepting the draft as a
WG item.

Well, there really aren't any formal requirements to adopt a draft as a WG
item.  It's a decision reserved for the WG chairs to make in any way that
they see fit. Typically, they observe a consensus that the WG wants to work
on it.
That means that the WG is willing to spend agenda time on the document.

But, over time the Adoption call has become overly bureaucratic due to the
belief that documents that are adopted MUST be published.  This has resulted
in the adoption call being overly litigated.

See https://datatracker.ietf.org/doc/draft-carpenter-gendispatch-rfc7221bis/ for
some opinions and of course RFC7221.

However, like you, I am not feeling very confident that there are real use
cases, and that this document it not simply the result of researchers who
looked at RFC6550, did a page count and decided it must be hard and that
it shouldn't be so difficult, so let's invent something new, even though we
have no actual use case.
That is the research institute way, where success is measured in papers
published, rather than products shipped.

This is not the IETF way.  The IETF way is to see that there is a problem
that can not be solved with existing technology, write a paper about the
failures of the existing things, having tried them, and then do some
experiments to see what else could be done.  Write some (running) code, do 
experiments
and then report on it in an attempt to get rough consensus.

I've actually seriously considered the datacenter situation.  It's a core use
for ANIMA's ACP.  I can unicast some presentations, but I'm not sure that I
want the links public yet.

I like the idea of an incrementally deployable swarm of management devices
powered by the network.  I have been thinking about how to do PoE in/out in a
daisy chain/tree. I hadn't thought about using the 100baseT1 that the
automotive industry likes.

One concern that I have with NSA is that I think the network can get renumbered
whenever there are new devices.

--
Michael Richardson. o O ( IPv6 IøT consulting )
  Sandelman Software Works Inc, Ottawa and Worldwide




___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo


signature.asc
Description: signature.asc
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] I-D Action: draft-ietf-6lo-multicast-registration-09.txt

[Pascal Thubert (pthubert)]

Dear all,

This addresses Klaus' comment that we Amend RFC 4861 by allowing a multicast 
address as target.

Note also that the new (RA and others) option is still there, waiting for Erik 
to advise whether it should be separated in a 6MAN draft.

My 2 cents here is that there's a need to express the behavior for any state 
that was installed in one of the peers before the other reboots or is updated 
in such a way that the previous state may be 
invalidated. In the context of the 6lo work, we are impacted by a 6LN reboot 
(router cleans state registrations), a router reboot (host reregisters if PIO 
is not changed), or a router prefix config changes (host deregisters addresses 
from old PIO and registers addresses for new PIO). 

This is as much as this spec is willing to mandate though more might be needed 
to clean up or renumber for other specifications.

Keep safe;

Pascal



> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of internet-dra...@ietf.org
> Sent: mardi 16 août 2022 18:05
> To: i-d-annou...@ietf.org
> Cc: 6lo@ietf.org
> Subject: [6lo] I-D Action: draft-ietf-6lo-multicast-registration-09.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over Networks of Resource-
> constrained Nodes WG of the IETF.
> 
> Title   : IPv6 Neighbor Discovery Multicast Address
> Listener Subscription
> Author  : Pascal Thubert
>   Filename: draft-ietf-6lo-multicast-registration-09.txt
>   Pages   : 33
>   Date: 2022-08-16
> 
> Abstract:
>This document updates RFC 8505 to enable a listener to subscribe an
>IPv6 anycast or and subscribe to an IPv6 multicast address; the draft
>updates RFC 6550 (RPL) to add a new Non-Storing Multicast Mode and a
>new support for anycast addresses in Storing and Non-Storing Modes.
>This document extends RFC 9010 to enable the 6LR to inject the
>anycast and multicast addresses in RPL.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-multicast-registration/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-6lo-multicast-registration-
> 09.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-multicast-registration-09
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-
> drafts
> 
> 
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Pascal Thubert (pthubert)]

Hello Kiran

Note that the core of the work is an autoconfiguration model along a fixed tree 
structure, and the desired “side effects” are implicit routing and short 
addresses. For short addresses, we already have SCHC and 6LoWPAN so that would 
not be a sufficient argument.
Now, I do not see how your point on IIoT matches this specification. Since a 
main objection (though not the only one) is the lack of applicability, this may 
help. Could you please elaborate?
In particular, which industrial protocol would benefit from this automatic 
assignment of IP addresses (vs. Say, mapping the protocol address into an IID 
or something)?

Many thanks in advance;

Pascal

From: 6lo <6lo-boun...@ietf.org> On Behalf Of Kiran Makhijani
Sent: mardi 16 août 2022 2:08
To: carle...@entel.upc.edu; 6lo@ietf.org
Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

Hello,
I have quickly skimmed through the document and would like to see this work 
progress.

I see that the focus is mainly on wireless constrained devices, however, in 
industrial networks with field devices it is useful to have short and variable 
addressing schemes on a factory floor. Variable addressing approach is more 
interesting here because, on one side the controllers may use IPv6 addresses 
and field-devices on the other end can very well be shorter addresses.

I support this document and wouldn't mind contributing to the alignment with 
above mentioned scenario.


Cheers,

Kiran


From: Carles Gomez Montenegro [mailto:carle...@entel.upc.edu]
Sent: Monday, August 1, 2022, 7:58 AM
To: 6lo@ietf.org
Subject: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03


Dear 6lo WG,



This message starts a call for WG adoption for

draft-li-6lo-native-short-address-03.



(Link below:

https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address-03)



Considering that some folks may be on vacation currently or in the next

few days, the call will end on the 22nd of August, EOB.



Please state whether you are in favor of adopting this document.



Also, any comments you may have, and/or expressions of interest to review

the document, will be very much appreciated.



Thanks,



Shwetha and Carles



___

6lo mailing list

6lo@ietf.org

https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] I-D Action: draft-ietf-6lo-multicast-registration-08.txt

[Pascal Thubert (pthubert)]

Hello Klaus:

I committed 
https://github.com/pthubert/6lo-multicast-registration/commit/a7bf315d9e2a760304035e9c505dbdad48f51a05
 to address your issue.

Again many thanks!

Pascal

> -Original Message-
> From: Pascal Thubert (pthubert)
> Sent: lundi 1 août 2022 21:56
> To: Klaus Hueske 
> Cc: 6lo@ietf.org
> Subject: Re: [6lo] I-D Action: draft-ietf-6lo-multicast-registration-
> 08.txt
> 
> Great point Klaus, thanks for catching this!
> 
> 
> Regards,
> 
> Pascal
> 
> > Le 1 août 2022 à 17:12, Klaus Hueske  a
> écrit :
> >
> > Hi Pascal,
> >
> > The draft specifies the usage of "target address" for multicast
> registration. To make this consistent, an update for the rules defined
> in Section 7.1 of RFC4861 would be required:
> >
> > --
> 
> > 7.1.  Message Validation
> >
> > 7.1.1.  Validation of Neighbor Solicitations
> >
> >   A node MUST silently discard any received Neighbor Solicitation
> >   messages that do not satisfy all of the following validity checks:
> >
> >  - The IP Hop Limit field has a value of 255, i.e., the packet
> >could not possibly have been forwarded by a router.
> >
> >  - ICMP Checksum is valid.
> >
> >  - ICMP Code is 0.
> >
> >  - ICMP length (derived from the IP length) is 24 or more octets.
> >
> >  - Target Address is not a multicast address.
> >
> > --
> 
> >
> > The last condition would be violated if multicast addresses are used
> as target address.
> >
> > I'd suggest that the draft updates RFC4861 Section 7.1 in a backward
> compatible way that would allow multicast target addresses if, and only
> if, the "A" or "M" flag is set.
> >
> > Best regards,
> >
> > Klaus
> >
> > -Original Message-
> > From: internet-dra...@ietf.org 
> > Sent: Montag, 25. Juli 2022 10:59
> > To: i-d-annou...@ietf.org
> > Cc: 6lo@ietf.org
> > Subject: [6lo] I-D Action: draft-ietf-6lo-multicast-registration-
> 08.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the IPv6 over Networks of Resource-
> constrained Nodes WG of the IETF.
> >
> >Title   : IPv6 Neighbor Discovery Multicast Address
> Listener Registration
> >Author  : Pascal Thubert
> >  Filename: draft-ietf-6lo-multicast-registration-08.txt
> >  Pages   : 31
> >  Date: 2022-07-25
> >
> > Abstract:
> >   This document updates RFC 8505 to enable a listener to register an
> >   IPv6 anycast or and subscribe to an IPv6 multicast address; the
> draft
> >   updates RFC 6550 (RPL) to add a new Non-Storing Multicast Mode and a
> >   new support for anycast addresses in Storing and Non-Storing Modes.
> >   This document extends RFC 9010 to enable the 6LR to inject the
> >   anycast and multicast addresses in RPL.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-6lo-multicast-
> registration/
> >
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-6lo-multicast-registration-
> 08.html
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-multicast-
> registration-08
> >
> >
> > Internet-Drafts are also available by rsync at
> rsync.ietf.org::internet-drafts
> >
> >
> >
> >
> >
> > Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten
> Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf,
> Arcadiastrasse 10, 40472 Duesseldorf, Germany,
> Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax
> identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE
> 14978647
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] draft-ietf-6lo-multicast-registration-08 replacing MLD

[Pascal Thubert (pthubert)]

Hello Stig

The rationale behind a new protocol is, same as all 6lo work, power efficiency 
in IoT space. Now, IoT is a precursor to moving more device to the green side. 
So your point stands. Either we are specific that in the target space there is 
no MLD at all, or we talk interactions between the two. 

IoT devices will typically sleep more than even cats do. They cannot stay awake 
at all times just in case they are be polled for a report. They cannot store 
much code either. The proposal is a simple extension to existing code, since 
the change we're doing here was already done for classical IPv6 ND with RFC 
8505, 8928 and 8929. RFC 8929 typically isolates the non-broadcast IoT edge 
from the broadcast backbone. Note that with RFC 8505, IoT devices do not use 
SNMA so no need for MLD there either.

Now for both ND and MLD, there will be a time of coexistence in the same link. 
The documents for ND is already long awaited. My suggestion is that that a 
future document covers both, and the current draft is for non-broadcast IoT 
links only, no coexistence.

Works?

 Pascal


> -Original Message-
> From: Stig Venaas 
> Sent: lundi 8 août 2022 19:21
> To: 6lo@ietf.org; draft-ietf-6lo-multicast-registrat...@ietf.org
> Cc: Alvaro Retana ; p...@ietf.org
> Subject: draft-ietf-6lo-multicast-registration-08 replacing MLD
> 
> Hi 6lo and draft authors
> 
> I have some concerns about this draft replacing MLD for group
> registration.
> 
> Having 2 different protocols for the same thing can be problematic.
> Hosts or routers may need to support both protocols. Is it clear which
> one should be used in different environments? Is there a chance that
> both may be used at the same time in a network? In particular, is there
> a chance that a router may need to simultaneously support both protocols
> on an L3 interface? In that case it must be considered how the two
> protocols interoperate.
> 
> Also, we have been pushing the use of SSM in the IETF for a very long
> time, but this draft only supports ASM since only a group address is
> provided.
> 
> It would be good to have some more info on the need to replace MLD. I
> understand there are concerns about packet loss, limited resources etc.
> 
> Regards,
> Stig
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Pascal Thubert (pthubert)]

Hello Tommaso:

Good to hear from you…

My first concern is related to the applicability of the idea. Do we have any 
standard L2 that will build a tree that will never change? This is not the case 
of Ethernet spanning tree as you know. I’ve met such an IoT case once in my 
life, in a very specific application network where numbering or frame size were 
the least of their problems.

The IETF is reaching 10K RFC. This obfuscates our work, even to ourselves, and 
doesn’t serve the end users. We need RFCs that solve problems in the real world 
and the first step for that is to demonstrate that the proposal applies to a 
real network. We need RFCs that apply the most generically possible. How is 
that the case here?

Take care,

Pascal

Le 4 août 2022 à 21:50, Tommaso Pecorella  a écrit :

 Hi all,

I had the opportunity to see this proposal from the beginning, and to talk 
extensively about it with the authors.

The present draft does not fully cover some essential parts, like the 
robustness of the methodology in case of link failure, but I think that these 
can - and should - be the subject of an extra document.

I do agree with Pascal about the fact that this proposal is “below” the IP 
level, but I disagree on his conclusions. The proposal, in my opinion, has 
enough interactions with the IPv6 address operations (e.g., neighbour 
discovery, scope of addresses, etc.) to be worth to be discussed in this group.

Moreover, despite the quite specific applicability scenarios, the risk to not 
standardise it in the IETF scope is to have (yet another) proprietary standard 
that directly impacts the IP layer, leading to interoperability nightmares 
(read: total lack of interoperability between devices).

Hence, I’m favourable for a WG adoption.

Best regards,

Tommaso Pecorella



On 1 Aug 2022, at 09:58, Carles Gomez Montenegro 
mailto:carle...@entel.upc.edu>> wrote:

Dear 6lo WG,

This message starts a call for WG adoption for
draft-li-6lo-native-short-address-03.

(Link below:
https://www.google.com/url?q=https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address-03=gmail-imap=165997063000=AOvVaw1wg_-bvDuMmSw50lPNMu5k)

Considering that some folks may be on vacation currently or in the next
few days, the call will end on the 22nd of August, EOB.

Please state whether you are in favor of adopting this document.

Also, any comments you may have, and/or expressions of interest to review
the document, will be very much appreciated.

Thanks,

Shwetha and Carles

___
6lo mailing list
6lo@ietf.org
https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/6lo=gmail-imap=165997063000=AOvVaw0i_toV1jgA4ThVjf5vBmqX

--

``It's not worth doing something unless you were doing something that someone, 
somewere, would much rather you weren't doing.''
-- Terry Pratchett

--

Tommaso Pecorella - Ph.D.

Associate professor
Dpt. Ingegneria dell'Informazione
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: tommaso.pecore...@unifi.it
   tommaso.pecore...@cnit.it

phone : +39-055-2758540
mobile: +39-320-4379803
fax   : +39-055-2758570









___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03

[Pascal Thubert (pthubert)]

Hello Carles

I have reviewed the work carefully.

I believe that we can achieve short packets with 6lo and SCHC so that piece is 
not an essential progress. So 6lo as an INT areaWg does not need it.The 
essential progress is meshing without routing. It’s probably hard to justify it 
at the routing area though the authors could try.

My feeling is that the idea is interesting but has a very narrow applicability, 
which is in essence the opposite of IP. The progress applies only to very 
specific L2 networks. This tells me that it is really an L2 technology and 
should be used for MAC not IP.

Bottom line is that I do not believe that the work belongs to the IETF.  I do 
not support adoption at 6lo.


Regards,

Pascal

Le 2 août 2022 à 18:01, Jing Wang  a écrit :


Hi WG,

I support the adoption call. In my opinion, this can help enlarge scope of 
IP network, considering it may consume less resource of constrained nodes.

BR,
Jing Wang

From: Carles Gomez Montenegro
Date: 2022-08-01 22:58
To: 6lo
Subject: [6lo] Call for WG adoption of draft-li-6lo-native-short-address-03
Dear 6lo WG,

This message starts a call for WG adoption for
draft-li-6lo-native-short-address-03.

(Link below:
https://datatracker.ietf.org/doc/html/draft-li-6lo-native-short-address-03)

Considering that some folks may be on vacation currently or in the next
few days, the call will end on the 22nd of August, EOB.

Please state whether you are in favor of adopting this document.

Also, any comments you may have, and/or expressions of interest to review
the document, will be very much appreciated.

Thanks,

Shwetha and Carles

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] I-D Action: draft-ietf-6lo-multicast-registration-08.txt

[Pascal Thubert (pthubert)]

Great point Klaus, thanks for catching this!


Regards,

Pascal

> Le 1 août 2022 à 17:12, Klaus Hueske  a écrit :
> 
> Hi Pascal,
> 
> The draft specifies the usage of "target address" for multicast registration. 
> To make this consistent, an update for the rules defined in Section 7.1 of 
> RFC4861 would be required:
> 
> --
> 7.1.  Message Validation
> 
> 7.1.1.  Validation of Neighbor Solicitations
> 
>   A node MUST silently discard any received Neighbor Solicitation
>   messages that do not satisfy all of the following validity checks:
> 
>  - The IP Hop Limit field has a value of 255, i.e., the packet
>could not possibly have been forwarded by a router.
> 
>  - ICMP Checksum is valid.
> 
>  - ICMP Code is 0.
> 
>  - ICMP length (derived from the IP length) is 24 or more octets.
> 
>  - Target Address is not a multicast address.
> 
> --
> 
> The last condition would be violated if multicast addresses are used as 
> target address.
> 
> I'd suggest that the draft updates RFC4861 Section 7.1 in a backward 
> compatible way that would allow multicast target addresses if, and only if, 
> the "A" or "M" flag is set.
> 
> Best regards,
> 
> Klaus
> 
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Montag, 25. Juli 2022 10:59
> To: i-d-annou...@ietf.org
> Cc: 6lo@ietf.org
> Subject: [6lo] I-D Action: draft-ietf-6lo-multicast-registration-08.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IPv6 over Networks of Resource-constrained 
> Nodes WG of the IETF.
> 
>Title   : IPv6 Neighbor Discovery Multicast Address Listener 
> Registration
>Author  : Pascal Thubert
>  Filename: draft-ietf-6lo-multicast-registration-08.txt
>  Pages   : 31
>  Date: 2022-07-25
> 
> Abstract:
>   This document updates RFC 8505 to enable a listener to register an
>   IPv6 anycast or and subscribe to an IPv6 multicast address; the draft
>   updates RFC 6550 (RPL) to add a new Non-Storing Multicast Mode and a
>   new support for anycast addresses in Storing and Non-Storing Modes.
>   This document extends RFC 9010 to enable the 6LR to inject the
>   anycast and multicast addresses in RPL.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-multicast-registration/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-6lo-multicast-registration-08.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-multicast-registration-08
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> 
> 
> 
> Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, 
> Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 
> 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, 
> HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE 
> reg. no.: DE 14978647
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] ROVR and TID in the 6lo multicast

[Pascal Thubert (pthubert)]

Hello Adnan

RFC 8505 MUSTs the setting of the T bit. That’s how you now we have an RFC 8505 
registration instead of a RFC 6775 one.
“
   o  A node that supports this specification MUST provide a TID field
  in the EARO and set the T flag to indicate the presence of the TID
  (see Section 
5.2<https://datatracker.ietf.org/doc/html/rfc8505#section-5.2>).

“
Maybe one day we can deprecate the flag, once we are sure that the TID is 
always there…

All the best,

Pascal

From: Adnan Rashid 
Sent: mercredi 27 juillet 2022 17:05
To: Pascal Thubert (pthubert) 
Cc: ROLL WG (r...@ietf.org) ; 6lo@ietf.org
Subject: Re: ROVR and TID in the 6lo multicast

Hi Pascal,

Thanks for addressing my question.

Do you really think that the T flag is really important in EARO? As we already 
discussed the rfc6775 is obsoleted.


   T: 1-bit flag.  Set if the next octet is used as a TID.

The significance of TID is really important, so is there any case where TID 
octet is not available in EARO?




On Wed, Jul 27, 2022 at 4:08 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Dear all:

Yesterday at the mike, Adnan asked questions about the use of TID and ROVR.
In the general case today, the ROVR is not available in the DAO messages and
Since multiple nodes will register the same anycast or multicast address
With uncoordinated TODs, the TID freshness comparison that is used to remove
stale unicast routes cannot happen.

Now, RFC 9010 added the ROVR field in the DAO messages, enabling the routing
to determine the origin of the route and opening the door to zerotrust/ROV in
the future. When the ROVR is available either in NA(EARO) or DAO(RTO), the
origin can be determined, and the stale (mobility) or retired (lifetime=0)
routes can be removed.

I reread the text and that was not sufficiently documented. So I went on
with the following proposed clarification:

 5.  Updating RFC 6550



+   [RFC6550] uses the Path Sequence in the Transit Information Option
+   (TIO) to retain only the freshest unicast route and remove stale
+   ones, e.g., in the case of mobility.  [RFC9010] copies the TID from
+   the EARO into the Path Sequence, and the ROVR field into the
+   associated RPL Target Option (RTO).  This way, it is possible to
+   identify both the registering node and the order of registration in
+   RPL for each individual route advertisement, so the most recent path
+   and lifetime values are used.
+
+   For anycast and multicast advertisements (in NS or DAO messages),
+   multiple origins may subscribe to the same address, and multiple
+   advertisements from different origins are merged by the common parent
+   which becomes the origin of the merged advertisements.  The Path
+   Sequence is to be used between advertisements with the same ROVR
+   value, denoting an update from the same origin, but cannot apply if
+   the origin is not determined.  This is why this specification
+   requires the use of the ROVR field as the indication of the origin in
+   the RPL advertisements.
+
+   [RFC6550] uses the Path Lifetime in the TIO to indicate the remaining
+   time for which the advertisement is valid for unicast route
+   determination, and a Path Lifetime value of 0 invalidates that route.
+   [RFC9010] maps the Address Registration lifetime in the EARO and the
+   Path Lifetime in the TIO so they are comparable when both forms of
+   advertisements are received.
+
+   For anycast and multicast advertisements, the Path Sequence is to be
+   used between advertisements from the same origin only.  The RPL
+   router that merges multiple advertisement for the same anycast or
+   multicast addresses must use and advertise the longest remaining
+   lifetime across all the origins of the advertisements for that
+   address.  When the lifetime expires, the router sends a no-path DAO
+   (lifetime=0) using the same value for ROVR value as for the preceding
+   advertisements.

5.1.  Updating MOP 3

...


-   Though it was implicit in [RFC6550], this specification clarifies
-   that the freshness comparison based on the TID field is ignored for
-   RPL multicast operations.  A RPL router maintains a remaining Path
-   Lifetime for each DAO that it receives for a multicast target, and
-   sends it own DAO for that target with the longest remaining lifetime
-   across its listening children.

+   For anycast and multicast advertisements, including MOP 3, the ROVR
+   field is placed in the RPL Target Option as specified in [RFC9010]
+   for both MOP 3 and MOP 5 as it is for unicast advertisements.
+
+   Though it was implicit with [RFC6550], this specification clarifies
+   that the freshness comparison based on the Path Sequence is not used
+   when the origin cannot be determined, which is the case there.  The
+   comparison is to be used only between advertisements from the same
+   origin, which is either an individual subscriber, or a descendant
+   that aggregated multiple advertisements.
+
+   

[6lo] ROVR and TID in the 6lo multicast

[Pascal Thubert (pthubert)]

Dear all:

Yesterday at the mike, Adnan asked questions about the use of TID and ROVR. 
In the general case today, the ROVR is not available in the DAO messages and 
Since multiple nodes will register the same anycast or multicast address
With uncoordinated TODs, the TID freshness comparison that is used to remove 
stale unicast routes cannot happen.

Now, RFC 9010 added the ROVR field in the DAO messages, enabling the routing
to determine the origin of the route and opening the door to zerotrust/ROV in
the future. When the ROVR is available either in NA(EARO) or DAO(RTO), the 
origin can be determined, and the stale (mobility) or retired (lifetime=0) 
routes can be removed.

I reread the text and that was not sufficiently documented. So I went on
with the following proposed clarification:

 5.  Updating RFC 6550



+   [RFC6550] uses the Path Sequence in the Transit Information Option
+   (TIO) to retain only the freshest unicast route and remove stale
+   ones, e.g., in the case of mobility.  [RFC9010] copies the TID from
+   the EARO into the Path Sequence, and the ROVR field into the
+   associated RPL Target Option (RTO).  This way, it is possible to
+   identify both the registering node and the order of registration in
+   RPL for each individual route advertisement, so the most recent path
+   and lifetime values are used.
+
+   For anycast and multicast advertisements (in NS or DAO messages),
+   multiple origins may subscribe to the same address, and multiple
+   advertisements from different origins are merged by the common parent
+   which becomes the origin of the merged advertisements.  The Path
+   Sequence is to be used between advertisements with the same ROVR
+   value, denoting an update from the same origin, but cannot apply if
+   the origin is not determined.  This is why this specification
+   requires the use of the ROVR field as the indication of the origin in
+   the RPL advertisements.
+
+   [RFC6550] uses the Path Lifetime in the TIO to indicate the remaining
+   time for which the advertisement is valid for unicast route
+   determination, and a Path Lifetime value of 0 invalidates that route.
+   [RFC9010] maps the Address Registration lifetime in the EARO and the
+   Path Lifetime in the TIO so they are comparable when both forms of
+   advertisements are received.
+
+   For anycast and multicast advertisements, the Path Sequence is to be
+   used between advertisements from the same origin only.  The RPL
+   router that merges multiple advertisement for the same anycast or
+   multicast addresses must use and advertise the longest remaining
+   lifetime across all the origins of the advertisements for that
+   address.  When the lifetime expires, the router sends a no-path DAO
+   (lifetime=0) using the same value for ROVR value as for the preceding
+   advertisements.

5.1.  Updating MOP 3

...


-   Though it was implicit in [RFC6550], this specification clarifies
-   that the freshness comparison based on the TID field is ignored for
-   RPL multicast operations.  A RPL router maintains a remaining Path
-   Lifetime for each DAO that it receives for a multicast target, and
-   sends it own DAO for that target with the longest remaining lifetime
-   across its listening children.

+   For anycast and multicast advertisements, including MOP 3, the ROVR
+   field is placed in the RPL Target Option as specified in [RFC9010]
+   for both MOP 3 and MOP 5 as it is for unicast advertisements.
+
+   Though it was implicit with [RFC6550], this specification clarifies
+   that the freshness comparison based on the Path Sequence is not used
+   when the origin cannot be determined, which is the case there.  The
+   comparison is to be used only between advertisements from the same
+   origin, which is either an individual subscriber, or a descendant
+   that aggregated multiple advertisements.
+
+   A RPL router maintains a remaining Path Lifetime for each DAO that it
+   receives for a multicast target, and sends its own DAO for that
+   target with the longest remaining lifetime across its listening
+   children.  If the router has only one descendant listening, it
+   propagates the TID and ROVR as received.  Conversely, if the router
+   merges multiple advertisements (including possibly one for self as a
+   listener), the router uses its own ROVR and TID values.

5.2.  New Non-Storing Multicast MOP

...



-   As with MOP 3, the freshness comparison based on the TID field is
-   ignored for RPL MOP 5 multicast operations.  The Root maintains a
-   remaining Path Lifetime for each DAO that it receives, and the 6LRs
-   generate the DAO for multicast addresses with the longest remaining
-   lifetime across its registered 6LNs.

+   For anycast and multicast advertisements in NA (at the 6LR) and DAO
+   (at the Root) messages, as discussed in Section 5.1, the freshness
+   comparison based on the TID field is applied only between messages
+   from the same origin, as determined 

[6lo] FW: New Version Notification for draft-ietf-6lo-multicast-registration-08.txt

[Pascal Thubert (pthubert)]

Dear all;

This is a minor update to clean up the IANA section after a review by Amanda.

All the best; 

Pascal

-Original Message-
From: internet-dra...@ietf.org  
Sent: lundi 25 juillet 2022 10:59
To: Pascal Thubert (pthubert) 
Subject: New Version Notification for 
draft-ietf-6lo-multicast-registration-08.txt


A new version of I-D, draft-ietf-6lo-multicast-registration-08.txt
has been successfully submitted by Pascal Thubert and posted to the IETF 
repository.

Name:   draft-ietf-6lo-multicast-registration
Revision:   08
Title:  IPv6 Neighbor Discovery Multicast Address Listener Registration
Document date:  2022-07-25
Group:  6lo
Pages:  31
URL:
https://www.ietf.org/archive/id/draft-ietf-6lo-multicast-registration-08.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-6lo-multicast-registration/
Html:   
https://www.ietf.org/archive/id/draft-ietf-6lo-multicast-registration-08.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-6lo-multicast-registration
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-multicast-registration-08

Abstract:
   This document updates RFC 8505 to enable a listener to register an
   IPv6 anycast or and subscribe to an IPv6 multicast address; the draft
   updates RFC 6550 (RPL) to add a new Non-Storing Multicast Mode and a
   new support for anycast addresses in Storing and Non-Storing Modes.
   This document extends RFC 9010 to enable the 6LR to inject the
   anycast and multicast addresses in RPL.


  


The IETF Secretariat


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] [lp-wan] I-D Action: draft-ietf-lpwan-architecture-02.txt

[Pascal Thubert (pthubert)]

Hello Carles

Many thanks! Will you present your draft at the IETF 114 LPWAN meeting this 
time ? - I just posted a call for agenda item.
Anyway we'll chat at the WG meeting during the slot on architecture. Also, for 
mesh under, the connection can the pair of MACs (=> only one Instance per 
pair), but there is no implicit sense of direction. So it's not per se a 
solution.
I'll need to understand better how you want to install / use that " single Rule 
(also written beforehand) ".

Take care,

Pascal

> -Original Message-
> From: Carles Gomez Montenegro 
> Sent: jeudi 7 juillet 2022 12:59
> To: Pascal Thubert (pthubert) 
> Cc: 6lo@ietf.org; lp-...@ietf.org
> Subject: Re: [6lo] [lp-wan] I-D Action: draft-ietf-lpwan-architecture-02.txt
> 
> Hi Pascal,
> 
> Many thanks again for the discussion and your detailed insights!
> 
> Please find below my inline responses/comments:
> 
> > Hello Carles
> >
> >> -Original Message-
> >>
> >> Many thanks for updating the LPWAN architecture draft as per our
> >> discussion!
> >
> > Yep; many thanks for your hints and comments, your steering in the
> > right direction is really helpful.
> 
> :-)
> 
> >> In my opinion, the draft now provides the basis to generalize the use
> >> of the SCHC roles (Dev and App) or directions (Downlink and Uplink)
> >> for any networking environment or topology.
> >
> > Cool
> >
> >> (And other drafts, such as draft-gomez-6lo-schc-15dot4, can now refer
> >> to the LPWAN architecture draft to this end.)
> >>
> >> I have two further comments:
> >>
> >> - In section 5.1, when talking about the P2P SCHC Instance, an
> >> assumption seems to be that there is one link between the two peers.
> >> However, there could be several links (understood as radio hops)
> >> between the peers. For the sake of generality, perhaps the draft
> >> could also explicitly mention that there can be a link **or a path**
> >> between the two peers, perhaps also explicitly referring to 'mesh' or
> >> 'multihop' networks, which are now covered by the draft as well.
> >
> > We started that discussion but we're not there yet so I cannot turn
> > the result in words.
> > I'd say that there is the easy case and the hard case.
> >
> > * The easy case is RPL non-storing. RPL imposes a tunnel between the
> > Root and the device and that can serve as a P2P transport. So we can
> > do RFC
> > 8138 (really efficient) for the outer tunnel and then SCHC inside. For
> > this, we are almost all set, draft-gomez-6lo-schc-15dot4 could express
> > the details on how we find that it is SCHC inside as opposed to RFC
> > 6282 - willing to help here.
> 
> Great!
> 
> > Using the non-storing mode overlay, we're back to the hub and spoke
> > and the Root is naturally Uplink. Note that if the destination is
> > "external", which would probably be the case of a LFN (that's what
> > Wi-SUN does), then RFC 9008 is clear that the Non-Storing mode
> > signaling and tunneling applies as well, all set there too. And
> > nothing prevents also using the tunnel in storing mode when there's
> > SCHC inside, it's partially there anyway (e.g., for the root to add the
> RPI).
> 
> This sounds promising!
> 
> It would be nice to explore this approach.
> 
> > * The hard case is to make SCHC really multihop. It is not designed
> > for that.
> 
> Agreed. This is a challenge, but hopefully we might be able to find/create
> suitable techniques to support SCHC (or parts of SCHC) for multihop.
> 
> > E.g., fragmentation, either you reassemble at each hop and lose a lot
> > of the benefit, or you need to consider extending SCHC for things like
> > RFC 8931.
> 
> Actually, the current approach in draft-gomez-6lo-schc-15dot4 is to use just
> the header compression part of SCHC, and keep using 6LoWPAN/6lo
> fragmentation. In fact, I think that SCHC fragmentation is partly inspired by
> RFC 8931, so both fragmentation approaches share some of the main features
> anyway.
> 
> > Then there's the rules. If there are many and arbitrary destinations
> > then it's hard for the parent to maintain a state for all the
> > destinations of all the children and descendants.
> 
> Agreed. Route-over multihop with SCHC-compressed headers would be suitable
> "as is" rather for small networks (low number of nodes), or if node memory
> constraints are not too severe, and if context is relatively stable.
> 
> (Probably not suitable otherwise...)
> 
> > We're back to saying,

Re: [6lo] [lp-wan] I-D Action: draft-ietf-lpwan-architecture-02.txt

[Pascal Thubert (pthubert)]

Hello Carles

> -Original Message-
> 
> Many thanks for updating the LPWAN architecture draft as per our discussion!
 
Yep; many thanks for your hints and comments, your steering in the right 
direction is really helpful.


> In my opinion, the draft now provides the basis to generalize the use of the
> SCHC roles (Dev and App) or directions (Downlink and Uplink) for any
> networking environment or topology.

Cool

> (And other drafts, such as draft-gomez-6lo-schc-15dot4, can now refer to the
> LPWAN architecture draft to this end.)
> 
> I have two further comments:
> 
> - In section 5.1, when talking about the P2P SCHC Instance, an assumption
> seems to be that there is one link between the two peers. However, there
> could be several links (understood as radio hops) between the peers. For the
> sake of generality, perhaps the draft could also explicitly mention that
> there can be a link **or a path** between the two peers, perhaps also
> explicitly referring to 'mesh' or 'multihop' networks, which are now covered
> by the draft as well.

We started that discussion but we're not there yet so I cannot turn the result 
in words.
I'd say that there is the easy case and the hard case.

* The easy case is RPL non-storing. RPL imposes a tunnel between the Root and 
the device and that can serve as a P2P transport. So we can do RFC 8138 (really 
efficient) for the outer tunnel and then SCHC inside. For this, we are almost 
all set, draft-gomez-6lo-schc-15dot4 could express the details on how we find 
that it is SCHC inside as opposed to RFC 6282 - willing to help here. Using the 
non-storing mode overlay, we're back to the hub and spoke and the Root is 
naturally Uplink. Note that if the destination is "external", which would 
probably be the case of a LFN (that's what Wi-SUN does), then RFC 9008 is clear 
that the Non-Storing mode signaling and tunneling applies as well, all set 
there too. And nothing prevents also using the tunnel in storing mode when 
there's SCHC inside, it's partially there anyway (e.g., for the root to add the 
RPI).

* The hard case is to make SCHC really multihop. It is not designed for that. 
E.g., fragmentation, either you reassemble at each hop and lose a lot of the 
benefit, or you need to consider extending SCHC for things like RFC 8931. Then 
there's the rules. If there are many and arbitrary destinations then it's hard 
for the parent to maintain a state for all the destinations of all the children 
and descendants. We're back to saying, let the root do that, but then, why not 
tunnel to it like in the case above? 

So we have to decide whether we model for the H overlay like RPL, or opt for 
a complicated change in SCHC.

> 
> - The convention defined in 5.1 provides a default way to determine who is
> Dev and who is App (or what is understood by Uplink and Downlink).
> My interpretation is that:
> 
>o If it is possible to know beforehand which one of the two peers is Dev
>  or App, a single Rule (also written beforehand) may suffice to offer
>  the best header compression performance for both communication
>  directions (e.g., as in RFC 8724).
> 
>o In a less predictable scenario, where either one peer or the other
>  could be the first to transmit (e.g., if they are peers in a strict
>  sense), the convention still allows to determine the role of each
>  device, but two Rules (one for each direction) may need to be written
>  to achieve the best header compression performance for both
>  communication directions (one for each direction).
> 
>   Perhaps some comment about this (i.e., the amount of context may be
>   reduced if a scenario is predictable) could also be added to the draft.

Works for me, that was the intention. I like your wording. I'd like to 
elaborate in what you mean by " a single Rule (also written beforehand) ". 
Right now we say that the a priori knowledge (rule) is fully extrinsic to SCHC 
and has to do with the device (supports only 1 Instance), the network (the Hub 
is Uplink) or the supporting connection or tunnel (the node that starts it is 
Downlink). You seem to make it a SCHC Rule. Is that your meaning? If so, this 
may affect the model.

Keep safe, sad we cannot continue this conversation in Philly since I'll be 
remote.

Pascal

> 
> Cheers,
> 
> Carles
> 
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the IPv6 over Low Power Wide-Area
> > Networks WG of the IETF.
> >
> > Title   : LPWAN Static Context Header Compression (SCHC)
> > Architecture
> > Authors : Alexander Pelov
> >   Pascal Thubert
> >   Ana Minaburo
> >   Filename: draft-ietf-lpwan-architecture-02.txt
> >   Pages   : 14
> >   Date: 2022-06-30
> >
> > Abstract:
> >This document defines the LPWAN SCHC architecture.
> >
> >
> > The IETF datatracker 

Re: [6lo] [Roll] draft-ietf-6lo-multicast-registration: route cleanups and storing MOP handling

[Pascal Thubert (pthubert)]

Hello Rahul

> One more comment:  Section 5.2 says "non-storing Mode DAO to the Root may 
> contain multicast addresses in the RPL Target Option (RTO),"
> An RTO cannot contain multiple addresses. Is it meant to say that multiple 
> RTOs may contain the different multicast addresses within the same DAO?

Good catch, I used: “  the Root may advertise a multicast address in the RPL 
Target Option (RTO),”

> Ok. That's what I assumed but wanted an explicit response. Multicast/Anycast 
> proactive cleanup is not possible to handle and lifetime elapsing sounds fine 
> to me. Should this be explicitly stated?

You’re right. Added
“
   The route disappears when the associated path lifetime in the transit
   option times out, but the procedure to remove a unicast route based on TID
   cannot apply to multicast and anycast.
“

>> MOP is 1 but there’s storing mode DAO for multicast happening as well. Some 
>> out of band control would allow this to happen. We can remove that text if 
>> people think it is open ended…

> I feel it is open-ended.

Let’s work on it, from experience it is needed.

> I have raised a PR to your repo here.

I used it, many thanks!

Keep safe;

Pascal

From: 6lo <6lo-boun...@ietf.org> On Behalf Of Rahul Jadhav
Sent: dimanche 12 juin 2022 18:45
To: Routing Over Low power and Lossy networks 
Cc: lo <6lo@ietf.org>
Subject: Re: [6lo] [Roll] draft-ietf-6lo-multicast-registration: route cleanups 
and storing MOP handling

Thanks for the response.

PFA my comments inline.

One more comment:  Section 5.2 says "non-storing Mode DAO to the Root may 
contain multicast addresses in the RPL Target Option (RTO),"
An RTO cannot contain multiple addresses. Is it meant to say that multiple RTOs 
may contain the different multicast addresses within the same DAO?

Thanks,
Rahul

On Wed, 8 Jun 2022 at 21:23, Pascal Thubert (pthubert) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hello Rahul

Many thanks for your review!!

Please see below:

>  storing MOP handling: Even though the draft mentions that storing MOP should 
> also work, the details seem to be missing (or it might be an oversight on my 
> side).

This is effectively https://datatracker.ietf.org/doc/html/rfc6550#section-12; 
this is indicated in the introduction and the overview. Effectively the TID 
must be ignored and the RFC misses text to that effect. This oversight (of ours 
at the time of RFC 6550) is corrected in the cases covered by the draft though 
we do not specifically update RFC 6550 to clarify that it also applies to MOP3. 
I’m adding text to be more specific on this:

“
   Though it was implicit in [RFC6550], this specification
   clarifies that the freshness comparison based on the TID field is ignored
   for RPL multicast operations. A RPL router maintains a remaining Path
   Lifetime for each DAO that it receives for a multicast target, and sends it
   own DAO for that target with the longest remaining lifetime across its
   listening children.
“
Same for MOP 5
“
   As with MOP 3, the freshness comparison based on the TID field is ignored
   for RPL MOP 5 multicast operations. The Root maintains a remaining Path
   Lifetime for each DAO that it receives, and the 6LRs generate the DAO for
   multicast addresses with the longest remaining lifetime across its registered
   6LNs.
“

There is no route cleanup. There’s history of async clean up to do damage in 
race conditions. It’s hard enough for unicast, we do not attempt for multicast 
or anycast. So we leave it to lifetime elapsing.

Ok. That's what I assumed but wanted an explicit response. Multicast/Anycast 
proactive cleanup is not possible to handle and lifetime elapsing sounds fine 
to me. Should this be explicitly stated?



> This opens up a lot of possibilities and I am not sure how the hybrid mode 
> would work.

Well, the  announced MOP is 1 but there’s storing mode DAO for multicast 
happening as well. Some out of band control would allow this to happen. We can 
remove that text if people think it is open ended…

I feel it is open-ended.


> "MUST retain a routing table entry for each children", is a change from the 
> default behaviour and thus has impact on backward compatibility which is not 
> called out in the corresponding backward compatibility section.

This is described in section 12 of RFC 6550 for MOP 3:
“

   As a result, multicast routing states are installed in each router on
   the way from the listeners to the DODAG root, enabling the root to
   copy a multicast packet to all its children routers that had issued a
   DAO message including a Target option for that multicast group.

“

> What is the preferred mode for sending syntax fixes since I dont see this 
> draft on github?

The git is https://github.com/pthubert/6lo-multicast-registration; you’re very 
welcome to submit a pull request. I pushed the changes above in 
https://gith

Re: [6lo] [Roll] draft-ietf-6lo-multicast-registration: route cleanups and storing MOP handling

[Pascal Thubert (pthubert)]

Hello Rahul

Many thanks for your review!!

Please see below:

>  storing MOP handling: Even though the draft mentions that storing MOP should 
> also work, the details seem to be missing (or it might be an oversight on my 
> side).

This is effectively https://datatracker.ietf.org/doc/html/rfc6550#section-12; 
this is indicated in the introduction and the overview. Effectively the TID 
must be ignored and the RFC misses text to that effect. This oversight (of ours 
at the time of RFC 6550) is corrected in the cases covered by the draft though 
we do not specifically update RFC 6550 to clarify that it also applies to MOP3. 
I’m adding text to be more specific on this:

“
   Though it was implicit in [RFC6550], this specification
   clarifies that the freshness comparison based on the TID field is ignored
   for RPL multicast operations. A RPL router maintains a remaining Path
   Lifetime for each DAO that it receives for a multicast target, and sends it
   own DAO for that target with the longest remaining lifetime across its
   listening children.
“
Same for MOP 5
“
   As with MOP 3, the freshness comparison based on the TID field is ignored
   for RPL MOP 5 multicast operations. The Root maintains a remaining Path
   Lifetime for each DAO that it receives, and the 6LRs generate the DAO for
   multicast addresses with the longest remaining lifetime across its registered
   6LNs.
“

There is no route cleanup. There’s history of async clean up to do damage in 
race conditions. It’s hard enough for unicast, we do not attempt for multicast 
or anycast. So we leave it to lifetime elapsing.

> This opens up a lot of possibilities and I am not sure how the hybrid mode 
> would work.

Well, the  announced MOP is 1 but there’s storing mode DAO for multicast 
happening as well. Some out of band control would allow this to happen. We can 
remove that text if people think it is open ended…

> "MUST retain a routing table entry for each children", is a change from the 
> default behaviour and thus has impact on backward compatibility which is not 
> called out in the corresponding backward compatibility section.

This is described in section 12 of RFC 6550 for MOP 3:
“

   As a result, multicast routing states are installed in each router on
   the way from the listeners to the DODAG root, enabling the root to
   copy a multicast packet to all its children routers that had issued a
   DAO message including a Target option for that multicast group.

“

> What is the preferred mode for sending syntax fixes since I dont see this 
> draft on github?

The git is https://github.com/pthubert/6lo-multicast-registration; you’re very 
welcome to submit a pull request. I pushed the changes above in 
https://github.com/pthubert/6lo-multicast-registration/commit/02f5b9144f39f54e76ee2c8b480703449450ddf3
I suggest to move it to the ROLL git when we transfer focus to ROLL?

Many thanks again

Pascal



From: Roll  On Behalf Of Rahul Jadhav
Sent: vendredi 3 juin 2022 17:16
To: lo <6lo@ietf.org>; Routing Over Low power and Lossy networks 
Subject: [Roll] draft-ietf-6lo-multicast-registration: route cleanups and 
storing MOP handling

Hello Pascal, Authors,

Thank you for this work. We had discussions before where the ability to 
register anycast/multicast addresses for 6LN nodes spanning RPL (or even 
non-RPL) network was missing. This work fulfills that requirement.

Following is my review of the draft:
1. storing MOP handling: Even though the draft mentions that storing MOP should 
also work, the details seem to be missing (or it might be an oversight on my 
side). Consider following instances (for storing MOP):
   a. in the case where multiple 6LNs subscribe to the same multicast address 
in the same DODAG, how will the intermediate 6LR handle this situation? Is it 
expected that the 6LR maintains state for all DAOs? Note that the DAOs may come 
from different paths when the parent switching happens and thus bloat the 
state. The only new thing added in the context is the 'M' flag in the RTO. The 
path-sequence, TID seems to be getting mandatorily ignored as per the text.
  b. How would the route cleanup happen for multicast/anycast addresses?

From non-storing mode perspective, I realize that it will be much easier 
handling since the DAO from the 6LR is directly targeted to the root and thus 
the root would be able to handle all the complexity.
But the text seem to be loosely specified in the context of storing mode. For 
e.g., consider section 5.1 which talks about storing MOP handling... it states,
 "Though it is preferred to build separate RPL Instances,
   one in MOP 1 and one in MOP 3, this specification allows to hybrid
   the Storing Mode for multicast and Non-Storing Mode for unicast in
   the same RPL Instance, more in Section 10."
This opens up a lot of possibilities and I am not sure how the hybrid mode 
would work.

I see text in Section 5.3 that roughly handles some part by stating,
"Like the 6LR, a RPL router in 

[6lo] NEW in draft-ietf-6lo-multicast-registration-05

[Pascal Thubert (pthubert)]

Dear all:

Please note that the draft introduces a new ND option to be used in most ND 
messages, to enables the peers to detect a loss of state e.g., due to reboots, 
at the sender. This means that the draft will circulate through 6MAN to accept 
the option. 

The option has similarities with one that was proposed in the efficient ND 
draft. The goal is to pull the lost state when the node reboots, e.g., a 6LR 
pulls the registrations when it reboots. Compared to MLD reports which are 
periodic, this is an exceptional event.

The node uptime is expressed as exponent + mantissa to allow a wide range. In 
the github, I already tweaked the text to place the exponent first and enforce 
that it is only increased, so that 2 expressions of uptime by the same node can 
be compared by casting to U16.

The text in 05 also introduces an async NA upon reboot with a new status; that 
one compares to RFC9131 though the NA is directed to all L2 peers that may have 
registered state to this node. In the draft, there is no associated multicast 
address like a "solicitING node multicast address" that would be somehow the 
reverse of the classical SNMA and would address any node that leverages this 
node for whatever service and wishes to be aware of its state. This new mcast 
address could be useful in wireless / IoT so the 6LN can filter incoming NAs 
from a 6LR that it did not register addresses to, and in other environments 
where stateful link scope multicast is implemented, to avoid a full L2 
flooding. Should we add it?

Keep safe;

Pascal


> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Michael Richardson
> Sent: dimanche 15 mai 2022 1:56
> To: 6lo@ietf.org; r...@ietf.org
> Subject: [6lo] Review of draft-ietf-6lo-multicast-registration-04
> 
> 
> I have read draft-ietf-6lo-multicast-registration-04.
> I have perhaps too many relationships with various ROLL documents to
> honestly say if the document is comprehensible to outsiders.  I will say
> that the Introduction,
>   https://www.ietf.org/archive/id/draft-ietf-6lo-multicast-registration-
> 04.html#name-introduction-2
> is similar to the intros of other documents, and Pascal has really refined
> the history of RPL and ND and EARO to a very precise and to the point "how
> did we get here" description.  It's too bad we can just #include <6lo-
> history> and get this text.
> 
> In section 3, it says:
>_This specification inherits from [RFC6550], [RFC8505], and [RFC8505]_
> 
> maybe one of the RFC8505 is meant to be 6775?  or 7400?
> 
> Why is Wi-SUN mentioned in relation to 802.15.4.
> I understand that Wi-SUN is included, but I'm unclear why other 802.15.4
> verticals couldn't use this specification?
> 
>Note the use of the term "subscribe": using the EARO registration
>mechanism, a node registers the unicast addresses that it owns, but
>subscribes to the multicast addresses that it listens to.
> 
> This point is pretty important, and maybe deserves it's own section?
> This section explains the new flags, which I like, but hasn't really named
> them yet.
> 
> I suggest inserting text like:
> 
>   This specification introduces two new flags, detailed in section FOO.
>   The _A_ flag for Anycast, and the _M_ flag for Multicast.  The existing
> _R_ flag
>   gets new behaviour.
> 
> before:
>   With this specification, the 6LNs can now subscribe to the multicast
>   addresses they listen to, using a new M flag in the EARO to signal that
> the
>   registration is for a multicast address. Multiple 6LN may subscribe to
> the
>   same multicast address to the same 6LR. Note the use of the term
> 
> About:
>   It is also possible to leverage this specification between the 6LN and
> the
>   6LR for the registration of unicast, anycast and multicast IPv6
> addresses
>   in networks that are not necessarily LLNs, and/or where the routing
>   protocol between the 6LR and above is not necessarily RPL. In that case,
>   the distribution of packets between the 6LR and the 6LNs may effectively
>   rely on a broadcast or multicast support at the lower layer.
> 
> I think that the utility of doing this is for equipment which either does
> not have MLD, doesn't implement properly (common), or for which there are
> interoperability issues with MLD.  I think that in some high density/DC
> scenarios the ToR switch is often at it's limit TCAM entries, and when one
> attempts to turn on IPv6 and MLD for IPv6, that one runs out.  Being able
> to emulate multicast in such a situation would be a win, I think.
> But, in order for it to be a win, then I think that some document has to
> explain how to do things, and not just say, "support at the lower layer"
> 
> section 4: isn't the A flag also new? (I didn't check RFC7400, I am going
> on what section 3 said).  Or maybe the M/A are added to the RTO.
> Should we have two flags called M?  Well, section 12 cleared it all up for
> me.
> 
> section 5.1: updating MOP 3.  Not convinced we can do this, I 

Re: [6lo] Router reboot - loss of state

[Pascal Thubert (pthubert)]

Hello Chris:
I just published 05 with the diffs here 
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-multicast-registration-05.txt

You'll find 2 things:
- the capability to send an asynchronous (multicast to all nodes) NA(EARO, 
target= self) at reboot with a new status asking for reregistration.
- a new Node Uptime Option that allows (the peer 6LN) to discover that the node 
(e.g. 6LR)  rebooted since last seen. That option can be used in NS, NA, RS and 
RA.

Note that any new proposed option has to go through 6MAN and that's sometimes a 
huge step. So relying on it at this stage is a bet, and pressure to 6MAN if you 
do will be needed.

Please let me know if that flies with you.

Keep safe;

Pascal

From: Hett, Chris 
Sent: jeudi 12 mai 2022 16:47
To: Klaus Hueske ; 6lo@ietf.org
Cc: Pascal Thubert (pthubert) ; Paul Duffy (paduffy) 

Subject: RE: [6lo] Router reboot - loss of state

Hi Klaus, Pascal,

Yes, I agree that this is a gap that should be addressed.  It is not always 
practical to expect constrained devices to store - potentially hundreds of - 
neighbor cache details across a power cycle.  There should be a way for a 6LR 
implementing RFC 6775 to notify its neighbors that it has lost its neighbor 
cache and signal that its neighbors should reregister their addresses.

Since this is a Neighbor Discovery related issue, I think it makes sense to add 
some kind of sequence number option (similar to a DTSN) for NA messages.  If a 
neighbor detects the sequence number has incremented, they can reregister their 
addresses.

Best Regards,
Chris.

From: Klaus Hueske mailto:klaus.hue...@renesas.com>>
Sent: Thursday, May 12, 2022 4:56 AM
To: 6lo@ietf.org<mailto:6lo@ietf.org>
Cc: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>; 
Hett, Chris mailto:chris.h...@landisgyr.com>>; Paul 
Duffy mailto:padu...@cisco.com>>
Subject: RE: [6lo] Router reboot - loss of state

Hi Pascal, Thanks for pointing this out! Indeed, the problem is not limited to 
sleepy devices, but relevant for all nodes that expect address registration 
according to RFC6775 Section 3.3. The mechanism assumes that hosts actively 
register
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi Pascal,

Thanks for pointing this out! Indeed, the problem is not limited to sleepy 
devices, but relevant for all nodes that expect address registration according 
to RFC6775 Section 3.3. The mechanism assumes that hosts actively register 
their address with the router using NS with ARO and that the hosts are 
responsible for maintaining the registration depending on the configured 
lifetime. However, if the router is rebooted unexpectedly (e.g. due to a power 
outage) it will lose its neighbor cache information. This may not even be 
noticed by the connected hosts, so they will assume their address registration 
at the router is still okay, which is not the case. Considering the possible 
long registration lifetime, this would lead the connected nodes unreachable for 
a long period of time.

The DTSN present in DIO messages can be used to refresh routing information by 
triggering DAO transmissions, but it will not trigger any address 
re-registration. What we need then is kind of an advertisement issued by the 
router after reboot that asks the connected hosts to send another NS with ARO 
to refresh their neighbor cache registration at the router. Probably this could 
be done by creating a dedicated option to be used in an unsolicited NA send to 
link local multicast after reboot. This option could be conceptually similar to 
the DTSN, just for ARO.

The lack of such a feature has clearly been identified as a gap, especially 
when operating mains powered nodes in unstable grids. Hence, I'd prefer to 
extend the scope of the existing multicast draft to get this fixed as soon as 
possible. Happy to contribute to a new version of the draft if desired.

Best regards,

Klaus

From: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>
Sent: Freitag, 6. Mai 2022 11:11
To: 6lo@ietf.org<mailto:6lo@ietf.org>
Subject: [6lo] Router reboot - loss of state

Dear all :

There's one thing that was left unspecified in the RFC chain from RFC 6775, 
8505, and 9010.  That's the case where the 6LR reboots and the 6LN is not aware 
of the event, maybe it was sleeping. In that case the 6LR forgets the 
registration and the 6LN might become unreachable till it reregisters. A router 
that knows the event will happen  goes could send a final RA but the 6LN might 
not hear it either, so the result is not deterministic. Anyway that does not 
cover the unintended reboot.

Usually the L2 detects a loss of association or something, that triggers the 
6LN to reparent.  But that is not guaranteed to be available in all networks.
RPL has a method, the DTSN in the DIO 
(https://datatracker.ietf.org/doc/html/rfc6550#section-6.3.

Re: [6lo] Review of draft-ietf-6lo-multicast-registration-04

[Pascal Thubert (pthubert)]

Hello Michael

Many thanks for your kind review! Please see the new 05 and the diffs at 
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-multicast-registration-05.txt

Let's see below:

> I have read draft-ietf-6lo-multicast-registration-04.
> I have perhaps too many relationships with various ROLL documents to
> honestly say if the document is comprehensible to outsiders.  I will say
> that the Introduction,
>   https://www.ietf.org/archive/id/draft-ietf-6lo-multicast-registration-
> 04.html#name-introduction-2
> is similar to the intros of other documents, and Pascal has really refined
> the history of RPL and ND and EARO to a very precise and to the point "how
> did we get here" description.  It's too bad we can just #include <6lo-
> history> and get this text.
> 
> In section 3, it says:
>_This specification inherits from [RFC6550], [RFC8505], and [RFC8505]_
> 
> maybe one of the RFC8505 is meant to be 6775?  or 7400?

9010 : )

> 
> Why is Wi-SUN mentioned in relation to 802.15.4.

Wi-SUN alliance is the group that asks for this spec. It's worded as "such as" 
though. 

> I understand that Wi-SUN is included, but I'm unclear why other 802.15.4
> verticals couldn't use this specification?

Added "and 6TiSCH" to show there's more.

> 
>Note the use of the term "subscribe": using the EARO registration
>mechanism, a node registers the unicast addresses that it owns, but
>subscribes to the multicast addresses that it listens to.
> 
> This point is pretty important, and maybe deserves it's own section?
> This section explains the new flags, which I like, but hasn't really named
> them yet.
> 
> I suggest inserting text like:
> 
>   This specification introduces two new flags, detailed in section FOO.
>   The _A_ flag for Anycast, and the _M_ flag for Multicast.  The existing
> _R_ flag
>   gets new behaviour.
> 
> before:
>   With this specification, the 6LNs can now subscribe to the multicast
>   addresses they listen to, using a new M flag in the EARO to signal that
> the
>   registration is for a multicast address. Multiple 6LN may subscribe to
> the
>   same multicast address to the same 6LR. Note the use of the term
> 

Added:

   This specification updates the EARO with two new flags, the A flag
   for Anycast, and the M flag for Multicast, as detailed in
   Section 6.1.  


> About:
>   It is also possible to leverage this specification between the 6LN and
> the
>   6LR for the registration of unicast, anycast and multicast IPv6
> addresses
>   in networks that are not necessarily LLNs, and/or where the routing
>   protocol between the 6LR and above is not necessarily RPL. In that case,
>   the distribution of packets between the 6LR and the 6LNs may effectively
>   rely on a broadcast or multicast support at the lower layer.
> 
> I think that the utility of doing this is for equipment which either does
> not have MLD, doesn't implement properly (common), or for which there are
> interoperability issues with MLD.  I think that in some high density/DC
> scenarios the ToR switch is often at it's limit TCAM entries, and when one
> attempts to turn on IPv6 and MLD for IPv6, that one runs out.  Being able
> to emulate multicast in such a situation would be a win, I think.
> But, in order for it to be a win, then I think that some document has to
> explain how to do things, and not just say, "support at the lower layer"

Changed to

In that case, the distribution of packets between
   the 6LR and the 6LNs may effectively rely on a broadcast or multicast
   support at the lower layer, e.g., using this specification as a
   replacement to MLD in an Ethernet bridged domain and still using
   either plain MAC-layer broadcast or snooping this protocol to control
   the flooding.  It may also rely on overlay services to optimize the
   impact of Broadcast, Unknown and Multicast (BUM) over a fabric, e.g.
   registering with [I-D.thubert-bess-secure-evpn-mac-signaling] and
   forwarding with [I-D.ietf-bess-evpn-optimized-ir].
> 
> section 4: isn't the A flag also new? (I didn't check RFC7400, I am going
> on what section 3 said).  Or maybe the M/A are added to the RTO.
> Should we have two flags called M?  Well, section 12 cleared it all up for
> me.

There already was an A and the new flag in 7400 covers both multi and anycast.
I agree that the resulting M and A in 7400 can lead to errors. Let's rename to 
X for X in (uni, multi and any) XCasts 

> 
> section 5.1: updating MOP 3.  Not convinced we can do this, I guess I'll
> know when I read section 9.
> 
>5.2. New Non-Storing Multicast MOP
>This specification adds a "Non-Storing Mode of Operation with multicast
> support"
> 
> I feel that there needs to be an adjective inserted here.
> "Non-Storing Mode of Operation with  multicast support"

What about 
   Non-Storing Mode of Operation with ingress replication multicast support

> 
> maybe  is _emulated_, or _encapsulated_ or _registered_ or ???
> 
> I found section 

Re: [6lo] Router reboot - loss of state

[Pascal Thubert (pthubert)]

Makes sense to me Chris

So we probably want a sequence counter that is in every RA by the 6LR and an 
asynchronous broadcast NA upon reboot.

 The 6LR as a router mais do periodic RAs with capabilities etc. There’s no 
periodic NA though, so if we wanted regular broadcast NAs that would probably 
constitute an issue, to be validated by the list.

What do you think ?

Pascal

Le 12 mai 2022 à 16:47, Hett, Chris  a écrit :


Hi Klaus, Pascal,

Yes, I agree that this is a gap that should be addressed.  It is not always 
practical to expect constrained devices to store – potentially hundreds of – 
neighbor cache details across a power cycle.  There should be a way for a 6LR 
implementing RFC 6775 to notify its neighbors that it has lost its neighbor 
cache and signal that its neighbors should reregister their addresses.

Since this is a Neighbor Discovery related issue, I think it makes sense to add 
some kind of sequence number option (similar to a DTSN) for NA messages.  If a 
neighbor detects the sequence number has incremented, they can reregister their 
addresses.

Best Regards,
Chris.

From: Klaus Hueske 
Sent: Thursday, May 12, 2022 4:56 AM
To: 6lo@ietf.org
Cc: Pascal Thubert (pthubert) ; Hett, Chris 
; Paul Duffy 
Subject: RE: [6lo] Router reboot - loss of state

Hi Pascal, Thanks for pointing this out! Indeed, the problem is not limited to 
sleepy devices, but relevant for all nodes that expect address registration 
according to RFC6775 Section 3.3. The mechanism assumes that hosts actively 
register
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi Pascal,

Thanks for pointing this out! Indeed, the problem is not limited to sleepy 
devices, but relevant for all nodes that expect address registration according 
to RFC6775 Section 3.3. The mechanism assumes that hosts actively register 
their address with the router using NS with ARO and that the hosts are 
responsible for maintaining the registration depending on the configured 
lifetime. However, if the router is rebooted unexpectedly (e.g. due to a power 
outage) it will lose its neighbor cache information. This may not even be 
noticed by the connected hosts, so they will assume their address registration 
at the router is still okay, which is not the case. Considering the possible 
long registration lifetime, this would lead the connected nodes unreachable for 
a long period of time.

The DTSN present in DIO messages can be used to refresh routing information by 
triggering DAO transmissions, but it will not trigger any address 
re-registration. What we need then is kind of an advertisement issued by the 
router after reboot that asks the connected hosts to send another NS with ARO 
to refresh their neighbor cache registration at the router. Probably this could 
be done by creating a dedicated option to be used in an unsolicited NA send to 
link local multicast after reboot. This option could be conceptually similar to 
the DTSN, just for ARO.

The lack of such a feature has clearly been identified as a gap, especially 
when operating mains powered nodes in unstable grids. Hence, I’d prefer to 
extend the scope of the existing multicast draft to get this fixed as soon as 
possible. Happy to contribute to a new version of the draft if desired.

Best regards,

Klaus

From: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>
Sent: Freitag, 6. Mai 2022 11:11
To: 6lo@ietf.org<mailto:6lo@ietf.org>
Subject: [6lo] Router reboot - loss of state

Dear all :

There’s one thing that was left unspecified in the RFC chain from RFC 6775, 
8505, and 9010.  That’s the case where the 6LR reboots and the 6LN is not aware 
of the event, maybe it was sleeping. In that case the 6LR forgets the 
registration and the 6LN might become unreachable till it reregisters. A router 
that knows the event will happen  goes could send a final RA but the 6LN might 
not hear it either, so the result is not deterministic. Anyway that does not 
cover the unintended reboot.

Usually the L2 detects a loss of association or something, that triggers the 
6LN to reparent.  But that is not guaranteed to be available in all networks.
RPL has a method, the DTSN in the DIO 
(https://datatracker.ietf.org/doc/html/rfc6550#section-6.3.1<https://urldefense.com/v3/__https:/jpn01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc6550*23section-6.3.1=05*7C01*7Cklaus.hueske*40renesas.com*7Cc6095f0e524742e74d5108da2de3ab9f*7C53d82571da1947e49cb4625a166a4a2a*7C0*7C1*7C637872753125005927*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C=5PLxb2Vqb3sMtbjFx7onAM8eT1CP1Uqhf3Cc*2FmnpAEI*3D=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!EEzGOCEfvrF80k8sMoAmtYTD!Ij9D4FHBc4lj2Fedt1ezN7EOYbV-bYHbuEGX_DPRWVtrXiv0euhjwYv2zyTXlAfoCFRKo_V1shse3XKqov49jfVTzA$>).
 A new sequence indicates that the child that sees it

[6lo] Router reboot - loss of state

[Pascal Thubert (pthubert)]

Dear all :

There's one thing that was left unspecified in the RFC chain from RFC 6775, 
8505, and 9010.  That's the case where the 6LR reboots and the 6LN is not aware 
of the event, maybe it was sleeping. In that case the 6LR forgets the 
registration and the 6LN might become unreachable till it reregisters. A router 
that knows the event will happen  goes could send a final RA but the 6LN might 
not hear it either, so the result is not deterministic. Anyway that does not 
cover the unintended reboot.

Usually the L2 detects a loss of association or something, that triggers the 
6LN to reparent.  But that is not guaranteed to be available in all networks.
RPL has a method, the DTSN in the DIO 
(https://datatracker.ietf.org/doc/html/rfc6550#section-6.3.1).
 A new sequence indicates that the child that sees it needs to send its state, 
DAO in this case. The child will eventually see a DIO, and when it sees it, the 
child will know that the sequence was incremented. Though the text in RFC 6550 
does not list all the cases when that is useful, a reboot in storing mode is 
certainly one.

But this only requires resending  DAO messages and has no effect on ND. 
https://datatracker.ietf.org/doc/html/draft-chakrabarti-nordmark-6man-efficient-nd-07#section-6.3
 has the same operation with a new RA option, the RAO, which also has a 
sequence counter, the router epoch; but the draft was stalled at 6MAN and the 
function is still missing. My suggestion is to fix that gap sooner than later.

The fast path is to integrate the option in the multicast draft. The slow path 
is to make yet another RFC. What would you guys prefer?

Keep safe

Pascal

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] [EXTERNAL] FW: I-D Action: draft-ietf-6lo-multicast-registration-03.txt

[Pascal Thubert (pthubert)]

Great point Gene

Effectively FF02::1 is really a broadcast, and nodes do not expect to have to 
register. Membership is implicit.
So I'm willing to add text saying that the 6LR that generates a message to all 
nodes should send it to all the nodes that registered to it. 

If there's a reliable L2 broadcast, fine. But if not, finding all the 
individual nodes actually means going through all the active NCEs (BCE really) 
and send to all avoiding duplication. If all nodes have one and only one link 
local that would be relatively  easy. But if not, that means scanning the BCEs, 
send unicast to all the LLAO found there, avoiding duplicates. Not necessarily 
obvious!

What do others think?

Pascal


> -Original Message-
> From: Falendysz, Gene 
> Sent: mardi 8 février 2022 16:42
> To: Pascal Thubert (pthubert) ; '6lo@ietf.org'
> <6lo@ietf.org>
> Subject: RE: [EXTERNAL] [6lo] FW: I-D Action: draft-ietf-6lo-multicast-
> registration-03.txt
> 
> Hi Pascal,
>   The draft does not currently address the "All Nodes Addresses" discussed
> in RFC 4291. Because there is a requirement that a node accept the link
> local scope All Nodes address, this should not require the 6LN to register
> to have this address forwarded. The 6LR should forward these implicitly.
> Please add text addressing this exception.
> 
> Thanks,
> 
> Gene Falendysz
> 864-723-1395
> 
> -----Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Pascal Thubert (pthubert)
> Sent: Monday, December 13, 2021 5:31 AM
> To: '6lo@ietf.org' <6lo@ietf.org>
> Subject: [EXTERNAL] [6lo] FW: I-D Action: draft-ietf-6lo-multicast-
> registration-03.txt
> 
> This update indicates how RFC 892_ can be used to block unwanted
> subscribers to unicast and multicast addresses.
> 
> Comments welcome!
> 
> Pascal
> 
> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of internet-dra...@ietf.org
> Sent: lundi 13 décembre 2021 11:21
> To: i-d-annou...@ietf.org
> Cc: 6lo@ietf.org
> Subject: [6lo] I-D Action: draft-ietf-6lo-multicast-registration-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over Networks of Resource-
> constrained Nodes WG of the IETF.
> 
> Title   : IPv6 Neighbor Discovery Multicast Address
> Listener Registration
> Author  : Pascal Thubert
>   Filename: draft-ietf-6lo-multicast-registration-03.txt
>   Pages   : 26
>   Date: 2021-12-13
> 
> Abstract:
>This document updates RFC 8505 to enable a listener to register an
>IPv6 anycast or and subscribe to an IPv6 multicast address; the draft
>updates RFC 6550 (RPL) to add a new Non-Storing Multicast Mode and a
>new support for anycast addresses in Storing and Non-Storing Modes.
>This document extends RFC 9010 to enable the 6LR to inject the
>anycast and multicast addresses in RPL.
> 
> 
> The IETF datatracker status page for this draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-
> 6lo-multicast-
> registration/__;!!F7jv3iA!gcLBxDdzsapT6nQ7ORn7D7J1YItLwFd2TjTR9I4oAGt6zhc0
> iWSqLXXMc6WephdJNTY$
> 
> There is also an HTML version available at:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-
> 6lo-multicast-registration-
> 03.html__;!!F7jv3iA!gcLBxDdzsapT6nQ7ORn7D7J1YItLwFd2TjTR9I4oAGt6zhc0iWSqLX
> XMc6WeSMJWFIU$
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-
> 6lo-multicast-registration-
> 03__;!!F7jv3iA!gcLBxDdzsapT6nQ7ORn7D7J1YItLwFd2TjTR9I4oAGt6zhc0iWSqLXXMc6W
> eNKpVXrg$
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-
> drafts
> 
> 
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/6lo__;!!
> F7jv3iA!gcLBxDdzsapT6nQ7ORn7D7J1YItLwFd2TjTR9I4oAGt6zhc0iWSqLXXMc6We3y6gvZ
> 4$
> 
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/6lo__;!!
> F7jv3iA!gcLBxDdzsapT6nQ7ORn7D7J1YItLwFd2TjTR9I4oAGt6zhc0iWSqLXXMc6We3y6gvZ
> 4$

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] FW: I-D Action: draft-ietf-6lo-multicast-registration-03.txt

[Pascal Thubert (pthubert)]

This update indicates how RFC 892_ can be used to block unwanted subscribers to 
unicast and multicast addresses. 

Comments welcome!

Pascal

-Original Message-
From: 6lo <6lo-boun...@ietf.org> On Behalf Of internet-dra...@ietf.org
Sent: lundi 13 décembre 2021 11:21
To: i-d-annou...@ietf.org
Cc: 6lo@ietf.org
Subject: [6lo] I-D Action: draft-ietf-6lo-multicast-registration-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over Networks of Resource-constrained 
Nodes WG of the IETF.

Title   : IPv6 Neighbor Discovery Multicast Address Listener 
Registration
Author  : Pascal Thubert
Filename: draft-ietf-6lo-multicast-registration-03.txt
Pages   : 26
Date: 2021-12-13

Abstract:
   This document updates RFC 8505 to enable a listener to register an
   IPv6 anycast or and subscribe to an IPv6 multicast address; the draft
   updates RFC 6550 (RPL) to add a new Non-Storing Multicast Mode and a
   new support for anycast addresses in Storing and Non-Storing Modes.
   This document extends RFC 9010 to enable the 6LR to inject the
   anycast and multicast addresses in RPL.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6lo-multicast-registration/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-6lo-multicast-registration-03.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-multicast-registration-03


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Short Hierarchial IPv6 addresses

[Pascal Thubert (pthubert)]

Hello Haoyu

> -Original Message-
> From: Haoyu Song 
> Sent: mardi 9 novembre 2021 22:25
> To: Pascal Thubert (pthubert) 
> Cc: 6lo@ietf.org; int-a...@ietf.org
> Subject: RE: [6lo] Short Hierarchial IPv6 addresses
> 
> Copied to INTAREA WG because this was also discussed in it.
> 
> Hi Pascal,
> 
> Thank you very much for the suggestions which are very helpful! The
> high level idea is indeed drawn from PSTN and PNNI, the proven
> technologies.
> 
> Our P4 prototype evaluation shows that the extra router processing is
> doable with little impact on forwarding performance. Meanwhile, both
> data plane and control plane are significantly simplified (e.g.,
> smaller and regular FIB, simplified routing protocols) which actually
> leads to lower router cost. So from the implementation point of view, I
> have confidence on it.

I can believe you on that. I'm sure you did an excellent work. 

> 
> The scheme is applicable to other environments as well, for example,
> data center networks, where east-west low-latency communication is
> dominant. I agree with you that the discussion is more an IAB one, but
> some folks in INTAREA also suggest I may go to 6lo. This makes me a
> little confused. I need more advices on how to proceed with the work,
> and welcome people who are interested in this work to join me.

I can believe that too.

> I also have some questions for the 6lowpan and LPWAN header compression
> schemes. Aren't  the context  storage and compression/decompression
> computing a source for resource/energy consumption? Is there any
> evaluation results on their impact? If shorter addresses are introduced
> as an additional feature, it may improve the situation. Another issue
> I'm concerned is that in 6lowpan/LPWAN (maybe I'm wrong) it seems that
> an end node can only talk with a server through a gateway. I think it
> may be needed for end nodes to directly communicate with each other in
> many cases. If so, do we need some context-free compression schemes?

Small IoT devices may speak with a very narrow vocabulary may speak the 
compressed form for their transmission natively, and never see an uncompressed 
address.
The state and the work is on the router, and that's OK because it's powered and 
can be provisioned adequately automatically.
So they virtually have no cost associated. With RFC 8138, the Source Route 
header is optimized for forwarding in compressed form as well.

As you can see, it's very hard to position your solution (which is an 
architecture) vs. IPHC or SCHC (which are compression mechanisms). 

You can never win such a challenge on the basis of having short addresses. 
Because the compression mechanism can provide addresses of the same size as you 
do, and compress a lot more fields. Because that's their core business not a 
side effect. This is why 6lo is not the place for your work, sorry that INTAREA 
mislead you in that.


> Sorry for the lengthy email. I just wanted to gain a better
> understanding on the situation. Thanks!
> 

No worries; you did great stuff. I'm just not convinced that this is the right 
place and the right time. 
45 years ago, or 45 years in the future, such a revolution might have been 
easier to consider than 25 years into IPv6 deployment. 
That's why I suggested talking to IAB.

Keep safe,

Pascal


> Best regards,
> Haoyu
> 
> -Original Message-
> From: Pascal Thubert (pthubert) 
> Sent: Monday, November 8, 2021 10:08 PM
> To: Haoyu Song 
> Cc: 6lo@ietf.org
> Subject: Re: [6lo] Short Hierarchial IPv6 addresses
> 
> Hello Haoyu:
> 
> If I get your proposal well, this is a bottom up aggregation approach
> when IP has been traditionally top down. IP  extends the prefix length
> that the router looks into as we dive down the hierarchy as opposed to
> building the address as you extend the reach in this draft.
> 
> At a high level, there’s a bright and a dark side.
> 
> Bright side:
> 
> It can be made to work as proven by other similar mechanisms like
> domain name and PSTN. It simplifies the host knowledge of its domain.
> 
> There’s neat routing technology like PNNI that could possibly do a
> great job with bottom up aggregation.
> 
> Dark side:
> 
> 6lo does not need a new compression. We already have a simple mostly
> stateless one with 6282 and a more complex stateful with SCHC. Too many
> standards kill the standard.
> 
> The scheme moves the complexity from the hosts to the network and I’m
> not sure what kind of effort it would take to uplift that. In
> comparison going IPv6 looks a minor step. In any case this is not a 6lo
> discussion, more an IAB one.
> 
> In short I do not recommend to use 6lo as the forum. You need a larger
> audience with routing and operations involved.
> 
> Keep s

[6lo] Heads-up on draft-ietf-6lo-multicast-registration

[Pascal Thubert (pthubert)]

Dear all:

With draft-ietf-6lo-multicast-registration, 6lo is extending the IPv6 stateful 
address autoconfiguration (RFC 8505/8928) to express that the node is accepting 
traffic for an anycast address and to subscribe to multicast addresses.

The model is a proactive push from the device, compared to MLD reports that 
pulls from the router. There are a number for reasons for doing this that way 
in energy conscious networks, where multicast and broadcasts are mostly 
prohibited, and devices sleep most of their time. Also the incremental code on 
constrained devices that operate IPv6 ND as per RFC 8505 is very minimal.

The proactive model allows the router to inject the MAC and IP information in a 
network overlay routing or a proxy function in a fashion that is more reliable 
and economical than the classical snooping of MLD and ND. This is why it is 
used in RFC 8929 for proxy ND, and proposed for use in RIFT and now eVPN as the 
IGP-agnostic UNI between the host and the router. 

Since we are extending the registration from unicast to anycast and multicast, 
Erik and Alvaro suggested that we raise the topic on this list as well. 

I would certainly be happy to help folks are interesting in drafting how 
subscriptions learned from this new work can be injected in PIM as well.

Keep safe;

Pascal

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Short Hierarchial IPv6 addresses

[Pascal Thubert (pthubert)]

Hello Haoyu:

If I get your proposal well, this is a bottom up aggregation approach when IP 
has been traditionally top down. IP  extends the prefix length that the router 
looks into as we dive down the hierarchy as opposed to building the address as 
you extend the reach in this draft.

At a high level, there’s a bright and a dark side.

Bright side:

It can be made to work as proven by other similar mechanisms like domain name 
and PSTN. It simplifies the host knowledge of its domain.

There’s neat routing technology like PNNI that could possibly do a great job 
with bottom up aggregation.

Dark side:

6lo does not need a new compression. We already have a simple mostly stateless 
one with 6282 and a more complex stateful with SCHC. Too many standards kill 
the standard.

The scheme moves the complexity from the hosts to the network and I’m not sure 
what kind of effort it would take to uplift that. In comparison going IPv6 
looks a minor step. In any case this is not a 6lo discussion, more an IAB one.

In short I do not recommend to use 6lo as the forum. You need a larger audience 
with routing and operations involved.

Keep safe,

Pascal

> Le 9 nov. 2021 à 00:58, Haoyu Song  a écrit :
> 
> Hi WG,
> 
> In today's session  I don't have enough time to finish my presentation. I 
> think it's important to highlight the difference between our scheme (aka 
> SHIP) and the compression schemes used by 6LoPAN and  LPWAN. Please let me 
> know if you have further questions or suggestions. 
> 
> 1. SHIP is hierarchical, extending from edge to core
> 2. SHIP is applicable to all kinds of networks, in contrast to:
>- 6LoPAN: IEEE 802.15
> 3. SHIP is applicable on arbitrary network topology, in contrast to: 
>- HC is applicable on "point-to-point" channel only 
>- Compressed packet is not routable unless decompressed first
> 4. SHIP only concerns the IP addresses, orthogonal to the compression 
> technique on the other header fields
> 5. SHIP is solely determined by the subnetworks, needing no dynamic context 
> negotiation or static context configuration
> 6. SHIP allows communication between any Internet-addressable nodes
> 
> Best regards,
> Haoyu
> 
> -Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Haoyu Song
> Sent: Monday, October 18, 2021 12:11 PM
> To: Michael Richardson ; 6lo@ietf.org
> Subject: Re: [6lo] Short Hierarchial IPv6 addresses
> 
> Hi Michael,
> 
> Thank you very much for your comments! 
> I said it's orthogonal to RFC6282 due to the fact that this draft only 
> concerns about the address part. Since each edge node only needs to keep a 
> shorter address, the power and storage associated with it are both reduced. 
> It can be combined with shared context between two nodes (as described in 
> those context based compression schemes) to achieve further compression. In 
> this sense, I said they are "orthogonal". 
> 
> Having said that, I think it can also be a standalone scheme. If the 
> resulting overhead due to the short address  can already satisfy the 
> application need, then there are merits to use this scheme alone, for the 
> following reasons:
> 1. Because there is no need to maintain the context between peers, the 
> storage for context and the computing for compression/decompression can both 
> be optimized, which I think is critical in the low power and low capacity IoT 
> scenarios.
> 2. There would be no limitation to the network topology (e.g., star). Edge 
> nodes can talk to each other directly and communicate with Internet freely. I 
> think this is another advantage that the other compression schemes are 
> difficult to achieve but the application may desire to have.
> 
> Here are some other clarifications to your questions:
> 
> 1. Based on our evaluation, while retaining all IPv6 header information, our 
> scheme can reduce the IPv6 header overhead  from 60% to 70% (i.e., from 40B 
> to 12~16B). I'll add the evaluation in the future draft revisions. 
> 
> 2. Yes it can be seen as a static compression scheme, in which the most 
> compression benefit is from the size reduction of the IP addresses. Since 
> there will be an IPv6 gateway towards external world, some other header 
> fields within the edge network can also be reduced or simplified. 
> 
> 3. The edge network below the IPv6 gateway appears to be a subnetwork to the 
> Internet. Within the edge network, the network is hierarchical and the 
> routing in it is straightforward.  In the following paper, we described how 
> the conventional and yet simplified version of IGP and BGP can be used within 
> the edge network for routing. 
> 

Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02

[Pascal Thubert (pthubert)]

Hello Michael

Please see below; I skipped where we reached consensus

> > The 6LN registers the multicast address, the 6LR sends a unicast DAO
> > straight to the Root, the Root tunnels the multicast packet to the
> 6LR,
> > the 6LR decapsulates and finds a multicast packet. The 6LR
> distributes
> > the multicast packet to all 6LNs that registered to the address.
> Maybe
> > the draft should use "subscribe" instead of "register" when it's
> > multicast or anycast?
> 
> That might make it clearer.

OK I'll scan and fix in the next release.

> Can we do this with ethernet though? i.e. the tunnel is a unicast L2?

Well, the 6LR is one hop away, so that becomes the 6LBR passing the multicast 
IP packet as a unicast L2 frame to all the 6LRs one by one. No SRH no IP in IP. 
Then the 6LRs copy one by one to all subscribers. And

> Can we finally admit that ethernet is NBMA?

Yes, ethernet is often NBMA, think of eVPN, pseudowire ot Wi-Fi ESS. The make 
believe emulation that is getting heavier by the day, but no one complains, I 
guess that's the frog in boiling water syndrome. We just do more and more 
hideous patch over patch to maintain the illusion that we're still in the 
situation that justified the design of IPv4 ARP. Look at the BESS WG-Docs 
currently in IETF last call, e.g., draft-ietf-bess-evpn-igmp-mld-proxy. 


> I think that one thing that really hurt NBMA networks (like 25Mbs ATM to
> the desktop that I think IBM was pushing), back in the 1990s was the need
> to have that multicast-emulator as a network component.

My point about the BESS work, see 
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-optimized-ir/ which is in 
that same bucket of emulator and now emulator optimizer! At the same time, the 
APs copy the broadcast a N unicast which is more reliable and often faster.

> Meanwhile ethernet was p2p and adhoc/plug and play.  Just hook up the coax.

Probably still true at home and Starbucks.

> >> My second thought/question was about non-LLN operations.  RFC8505
> can
> >> obviously be deployed into non-LLNs, but there is not yet industry
> (or
> >> 6man/v6ops) consensus that we should do this.
> 
> > Clearly, yes. I never managed to raise awareness. If we could get a
> > linux client we'd make a great step.
> 
> If the (Linux) client could operate as a 6LR/6BBR, and if they could elect
> a leader... or defer to a switching device that had the 6BBR included.
> Maybe that's no better than MLD snooping.

I was thinking the linux client does the 6LN dance, and the routers or L3 
switches or APs would do the 6LR games. Then a server or a designated router 
would do the 6LBR. 


> 
> >> I *think*, but I could be wrong, that if I deploy RFC8505 in
> switched
> >> ethernet space that I no longer need MLD to work correctly in order
> to
> >> make IPv6 work.  {I have recently had to extend a busy R office
> LAN
> >> across to another building, using a fairly wide variety of L2
> >> switches, with QinQ trunk from a different enterprise.  I think it's
> >> broken MLD, and I think this is why IPv6 is flaky... }
> 
> > True. In fact, MLD is already not needed for link scope since it's
> all
> > turned to broadcast, one of the nice little lies that hide and the
> IETF
> 
> IPv6 link scope is all broadcast for ND?  I don't really understand why
> that is.

Because nobody turns on L2 multicast support though IEEE made 2 passes at 
getting it done. And that would just push the scalability issue of maintaining 
host routes / registration state one layer down. Think of it this way: a 
Solicited node multicast address (that's the SNMA) has the last same 3 bytes as 
the IP address. Collisions are rare in a normal network (yeah modulo birthday 
paradox). This means as we get close to as many groups as addresses. If the 
infra loses that state, ND fails. So that's as much state that we need to 
maintain in switches as the registration requires in the routers. There's just 
possibly more switches. It's because of that state that the router can live 
with only caching, which doubles the overall cost. So why not maintain just one 
state per address directly in the routers and be done?  

Note: MLD snooping creates equivalent state as L2 multicast support, just done 
in a more snoopy way, understand lossy with layer violation, thus less 
reliable; so MLD snooping is rarely available and even more rarely turned on 
for link scope multicast.

Bottom line: no multicast for Link scope, including ND. First bit in the air 
set to 1. Broadcast. Clearly vendors like us had to do something to serve large 
venues. And we do, but that's proprietary. Which in my book is a complete 
failure from the standardization perspective, specially 6MAN.


> That probably explains why I can patch parts of my broken network together
> by creating explicit routes over IPv6-LL.

He he. Turn MLD off, filter it, whatever, and it all still works. Very sad 
joke. 

> 

Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02

[Pascal Thubert (pthubert)]

Hello Michael:

Many thanks for your support! Bottom line is I agree throughout; let's see the 
details below:

> I have read draft-thubert-6lo-multicast-registration.
> 
> I think that it should be adopted.
> 
> As I read it, I began to wonder if 6lo is the right place!
> 6man? roll?
> 
> Clearly it will need a cross-WGLC into ROLL.  That's not hard.

Clearly, yes. I did not want to go through the hassle of splitting in 2 drafts 
because it makes the interaction and the completeness harder to grasp.
I'll be presenting the draft at both 6lo and ROLL at the next IETF.


> I think that we'll need to talk about the new MOP a fair bit in ROLL
> anyway.
> I don't quite understand the new MOP yet, but I will read deeper during
> the WG deliberations on the document in the next months.

Basically that's ingress replication at the Root. Easier to think of it as RFC 
9010 for multicast. 

The 6LN registers the multicast address, the 6LR sends a unicast DAO straight 
to the Root, the Root tunnels the multicast packet to the 6LR, the 6LR 
decapsulates and finds a multicast packet. The 6LR distributes the multicast 
packet to all 6LNs that registered to the address. Maybe the draft should use 
"subscribe" instead of "register" when it's multicast or anycast?
So the multicast tree is really 2 hops, one from the Root to N*6LRs over their 
usual source routed tunnel, one from each 6LR to the P*6LNs that subscribed, 
resulting in N*P copies. 

> 
> My second thought/question was about non-LLN operations.
> RFC8505 can obviously be deployed into non-LLNs, but there is not yet
> industry (or 6man/v6ops) consensus that we should do this.
 
Clearly, yes. I never managed to raise awareness. If we could get a linux 
client we'd make a great step.

> I *think*, but I could be wrong, that if I deploy RFC8505 in switched
> ethernet space that I no longer need MLD to work correctly in order to
> make IPv6 work.
> {I have recently had to extend a busy R office LAN across to another
> building, using a fairly wide variety of L2 switches, with QinQ trunk
> from a different enterprise.  I think it's broken MLD, and I think this
> is why IPv6 is flaky... }

True. In fact, MLD is already not needed for link scope since it's all turned 
to broadcast, one of the nice little lies that hide and the IETF / IEEE 
interface. 
The pendant is the 'proxy ARP' on the .11 side that claims that the AP replies 
NAs on behalf of the STA to avoid broadcast, but has no specification to 
support it.
We collectively prefer believing the lies that work on surface than facing the 
technical facts. 
So we keep doing useless MLD for SNMA and yet broadcast over radios - or use 
proprietary stuff that's bound to interfere with future standards. Interesting 
isn't it?

> 
> If I had RFC8505, then my IPv6 RA/RS/NA/NS infrastructure would not
> need as much L2-multicast to work.

None, effectively. This draft is a push model (like RFC 8505) vs. MLD, DAD, and 
Lookup, that are pull. Pull requires broadcast. Push requires a trustable and 
complete state in the routers.
=> push is adapted to NIC of the 80's where memory was scarce and broadcast 
cheap and reliable
=> pull was adapted to low power that's not necessarily awake to listen to 
broadcasts, overlays and radios that hate broadcast, and any route over 
operation. 

> But, if someone had some other multicast dependant system, (such as
> mDNS over IPv6), then RFC8505 alone would not help.  As I understand
> it, this document *would* help.

mDNS uses Link Local which is a proxy for the MAC and the scope of a L2 
broadcast domain. 
In a use case like a large campus, you might want to separate the scope of a L3 
Link (to be peer relationship like host to router), the L2 broadcast domain (so 
mDNS reaches the nearest printer), and the subnet (which spans the region where 
you do not want to renumber). Once you've done decoupled from IP subnets and 
links from L2 broadcast domain and made the L2 broadcast domain suitable for 
your physical world needs, it's OK to L2 broadcast the mDNS L3 multicast.

> 
> I'm unclear if having done a multicast registration, that the 6LBR is
> now expected to turn multicasts into unicasts.  

Yes, that's exactly the expectation, at least, per policy. For ND SNMA in 
particular, when the expectation is 0 (DAD) or 1 (Lookup) listener - arguably 
there can be SNMA collision but with 3 bytes random values that's birthday 
paradox - rare for you) -, turning to unicast is definitely the right thing to 
do on any type of network.

In route-over, ingress replication respects the idea of non-storing whereby 
there's no state in the intermediate routers, and is compatible with legacy 
routers that just forward the encapsulated packet (same as for RUL).

In mesh-under and Ethernet, the 6LR and 6LBR can be collapsed, and the 2 steps 
become one. The result is a complete state at the LBR with the list of all 
listeners, just like MLD would have built. From there, it's up to the 6LBR. It 
that 

Re: [6lo] Call for WG adoption: draft-thubert-6lo-multicast-registration-02

[Pascal Thubert (pthubert)]

Oups correct adoption call not WGLC


Regards,

Pascal

Le 19 oct. 2021 à 15:41, Rahul Jadhav  a écrit :


I support adoption of this draft. In general use of anycast addressing and non 
storing mode for multicast will be a good extension resulting in more resource 
optimised options for multicast.

On Mon, Oct 11, 2021 at 2:58 PM Carles Gomez Montenegro 
mailto:carle...@entel.upc.edu>> wrote:
Dear 6Lo WG,

Considering the need and the urgency for the functionality defined in
draft-thubert-6lo-multicast-registration-02, along with the interest from
the Wi-SUN Alliance, this message starts a 10-day call for WG adoption for
draft-thubert-6lo-multicast-registration-02.

(Link below:
https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration)

The call will end on the 21st of October, EOB.

Please state whether you are in favor of adopting this document.

Also, any comments you may have, and/or expressions of interest to review
the document, will be very much appreciated.

Thanks,

Shwetha and Carles


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] FW: Call for WG adoption: draft-thubert-6lo-multicast-registration-02

[Pascal Thubert (pthubert)]

Dear all:

As an author I support the adoption of the document by the 6lo WG. To 6lo, it 
saves the need for MLD on the constrained devices, and the related multicast no 
less expensive than the one related to ND procedures. To ROLL brings multicast 
to the non-storing mode using ingress replication at the Root. That was a long 
awaited feature since non storing is arch dominant in IOT networks.

The WGLC will end soon. Please chime in.

Keep safe;

Pascal

-Original Message-
From: 6lo <6lo-boun...@ietf.org> On Behalf Of Carles Gomez Montenegro
Sent: lundi 18 octobre 2021 16:20
To: 6lo@ietf.org
Cc: Paul Duffy (paduffy) 
Subject: Re: [6lo] Call for WG adoption: 
draft-thubert-6lo-multicast-registration-02

Dear all,

This is a gentle reminder that the call for adoption below is currently open 
(note: the call will end this Thursday, EOB).

Please state on the mailing list whether you are in favor of adopting the 
document.

Thanks,

Shwetha and Carles


> Dear 6Lo WG,
>
> Considering the need and the urgency for the functionality defined in 
> draft-thubert-6lo-multicast-registration-02, along with the interest 
> from the Wi-SUN Alliance, this message starts a 10-day call for WG 
> adoption for draft-thubert-6lo-multicast-registration-02.
>
> (Link below:
> https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registrat
> ion)
>
> The call will end on the 21st of October, EOB.
>
> Please state whether you are in favor of adopting this document.
>
> Also, any comments you may have, and/or expressions of interest to 
> review the document, will be very much appreciated.
>
> Thanks,
>
> Shwetha and Carles
>
>
> ___
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

[Pascal Thubert (pthubert)]

Just pushed that fix, many thanks Dario!


Regards,

Pascal

Le 12 oct. 2021 à 18:49, Dario Tedeschi  a écrit :

 Looks good.

I believe all my concerns have been adequately addressed. Thank you.


Just one typo, I think:

Using configuration, is it also possible to control

needs to change to:

Using configuration, it is also possible to control


Regards
Dario

On Oct 12, 2021, at 2:07 AM, Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:

Hello Dario:

The minor changes I made so far are visible from the repo at
https://www.ietf.org/rfcdiff?url1=draft-thubert-6lo-multicast-registration-02.txt=https://raw.githubusercontent.com/pthubert/6lo-multicast-registration/9761803d144bce35b985fdc0059fef832f9bf0e2/6lo-multicast-registration.txt

Please let me know if more is needed. I plan to publish near cutoff, hopefully 
with some more comments in.

Keep safe;

Pascal


From: 6lo <6lo-boun...@ietf.org<mailto:6lo-boun...@ietf.org>> On Behalf Of 
Dario Tedeschi
Sent: lundi 11 octobre 2021 22:09
To: Pascal Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
Cc: 6lo@ietf.org<mailto:6lo@ietf.org>
Subject: Re: [6lo] New Version Notification for 
draft-thubert-6lo-multicast-registration-02.txt

Thank you Pascal,

The new draft looks good. I only have two concerns:

--
It would be helpful if “RTO” was in the Glossary, since its full expansion is 
not seen anywhere.

--
The behaviour of MPL is confusing, when used in conjunction with “Non-Storing 
Mode of Operation with multicast". If I understand correctly Section 5.2 
defines the new mop behaviour as requiring 6LRs to send RTOs for multicast 
registrations. Yet the two MPL variations given at the end of section 3 
describe the R bit controlling that behaviour.

Given the two variations, it’s not clear how a root node (running MPL) would 
know when to flood a multicast. Does it base it’s decision on the current mop 
or wait for an RTO with multicast address. If it is the latter, how long does 
it wait for an RTO before deciding to a "flood all" scheme.

It would be clearer if the MOP alone determined what a root must do in regards 
to MPL:


  *   MOP “new": Only flood for multicast groups registered through DAO+RTO
  *   MOP 1: Flood all multicasts of scope 3 or higher


For MOP “new”, the R bit in the EARO instructs the 6LR to send a DAO+RTO to the 
root. However in MOP 1, the R bit can be ignored by a 6LR running MPL, because 
all multicasts are already flooded and “reachability service” is therefore 
implied.

------

Regards
Dario



On Oct 8, 2021, at 7:52 AM, Pascal Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
 wrote:

Dear all

Based on the conversations on the ML this version of the draft incorporates:

- anycast support in IPv6 ND and RPL
- non storing mode multicast in RPL
- alternate multicast operation (e.g., MPL)
- IANA suggestions
- proposed formats
- deployment and backward compatibility considerations

What's left is the detailed operations, to come soon.

Enjoy the week end!

Pascal

-Original Message-
From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Sent: vendredi 8 octobre 2021 16:45
To: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>
Subject: New Version Notification for 
draft-thubert-6lo-multicast-registration-02.txt


A new version of I-D, draft-thubert-6lo-multicast-registration-02.txt
has been successfully submitted by Pascal Thubert and posted to the IETF 
repository.

Name:  draft-thubert-6lo-multicast-registration
Revision:  02
Title: IPv6 Neighbor Discovery Multicast Address Registration
Document date:2021-10-08
Group:Individual Submission
Pages:   21
URL:
https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/
Html:   
https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-multicast-registration-02

Abstract:
  This document updates RFC 8505 to enable the address registration of
  IPv6 anycast and multicast addresses to a 6LR and updates RFC 6550
  (RPL) add a new Non-Storing multicast mode and support for anycast
  addresses.  This document also extends RFC 9010 to enable the 6LR to
  inject the anycast and multicast addresses in RPL.




The IETF Secretariat


___
6lo mailing list
6lo@ietf.org<mailto:6lo@ietf.org>
https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

[Pascal Thubert (pthubert)]

Hello Dario:

The minor changes I made so far are visible from the repo at
https://www.ietf.org/rfcdiff?url1=draft-thubert-6lo-multicast-registration-02.txt=https://raw.githubusercontent.com/pthubert/6lo-multicast-registration/9761803d144bce35b985fdc0059fef832f9bf0e2/6lo-multicast-registration.txt

Please let me know if more is needed. I plan to publish near cutoff, hopefully 
with some more comments in.

Keep safe;

Pascal


From: 6lo <6lo-boun...@ietf.org> On Behalf Of Dario Tedeschi
Sent: lundi 11 octobre 2021 22:09
To: Pascal Thubert (pthubert) 
Cc: 6lo@ietf.org
Subject: Re: [6lo] New Version Notification for 
draft-thubert-6lo-multicast-registration-02.txt

Thank you Pascal,

The new draft looks good. I only have two concerns:

--
It would be helpful if “RTO” was in the Glossary, since its full expansion is 
not seen anywhere.

--
The behaviour of MPL is confusing, when used in conjunction with “Non-Storing 
Mode of Operation with multicast". If I understand correctly Section 5.2 
defines the new mop behaviour as requiring 6LRs to send RTOs for multicast 
registrations. Yet the two MPL variations given at the end of section 3 
describe the R bit controlling that behaviour.

Given the two variations, it’s not clear how a root node (running MPL) would 
know when to flood a multicast. Does it base it’s decision on the current mop 
or wait for an RTO with multicast address. If it is the latter, how long does 
it wait for an RTO before deciding to a "flood all" scheme.

It would be clearer if the MOP alone determined what a root must do in regards 
to MPL:


  *   MOP “new": Only flood for multicast groups registered through DAO+RTO
  *   MOP 1: Flood all multicasts of scope 3 or higher

For MOP “new”, the R bit in the EARO instructs the 6LR to send a DAO+RTO to the 
root. However in MOP 1, the R bit can be ignored by a 6LR running MPL, because 
all multicasts are already flooded and “reachability service” is therefore 
implied.

--

Regards
Dario



On Oct 8, 2021, at 7:52 AM, Pascal Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
 wrote:

Dear all

Based on the conversations on the ML this version of the draft incorporates:

- anycast support in IPv6 ND and RPL
- non storing mode multicast in RPL
- alternate multicast operation (e.g., MPL)
- IANA suggestions
- proposed formats
- deployment and backward compatibility considerations

What's left is the detailed operations, to come soon.

Enjoy the week end!

Pascal

-Original Message-
From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Sent: vendredi 8 octobre 2021 16:45
To: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>
Subject: New Version Notification for 
draft-thubert-6lo-multicast-registration-02.txt


A new version of I-D, draft-thubert-6lo-multicast-registration-02.txt
has been successfully submitted by Pascal Thubert and posted to the IETF 
repository.

Name:  draft-thubert-6lo-multicast-registration
Revision:  02
Title: IPv6 Neighbor Discovery Multicast Address Registration
Document date:2021-10-08
Group:Individual Submission
Pages:   21
URL:
https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/
Html:   
https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-multicast-registration-02

Abstract:
  This document updates RFC 8505 to enable the address registration of
  IPv6 anycast and multicast addresses to a 6LR and updates RFC 6550
  (RPL) add a new Non-Storing multicast mode and support for anycast
  addresses.  This document also extends RFC 9010 to enable the 6LR to
  inject the anycast and multicast addresses in RPL.




The IETF Secretariat


___
6lo mailing list
6lo@ietf.org<mailto:6lo@ietf.org>
https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

[Pascal Thubert (pthubert)]

Hello Dario

Please see below


The new draft looks good. I only have two concerns:

--
It would be helpful if “RTO” was in the Glossary, since its full expansion is 
not seen anywhere.


Oops will fix that. Moving text around got me there.



--
The behavior of MPL is confusing, when used in conjunction with “Non-Storing 
Mode of Operation with multicast". If I understand correctly Section 5.2 
defines the new mop behavior as requiring 6LRs to send RTOs for multicast 
registrations. Yet the two MPL variations given at the end of section 3 
describe the R bit controlling that behavior.

Given the two variations, it’s not clear how a root node (running MPL) would 
know when to flood a multicast. Does it base it’s decision on the current mop 
or wait for an RTO with multicast address. If it is the latter, how long does 
it wait for an RTO before deciding to a "flood all" scheme.

It would be clearer if the MOP alone determined what a root must do in regards 
to MPL:


  *   MOP “new": Only flood for multicast groups registered through DAO+RTO
  *   MOP 1: Flood all multicasts of scope 3 or higher

I’m open if more voices speak in that direction, but my angle is different: The 
way I see it, multicast with MOP1 is for backward compatibility, for anything 
that’s already there. There’s a lot of brown field already using MOP 1.  Maybe 
some of the people who leverage that would also like to see the DAO, and some 
not. It’s really orthogonal and I’m not inclined to tie MOP 1 and “no DAO”.

At the moment we have 3 possible behaviors for MOP 1:

1) the Root floods everything which does not require the 6LN to set the R bit. 
It fact setting the R bit would cause a useless DAO to the Root so we’d better 
not do that and that’s what the draft says. This is true and doable 
independently of the MOP, even of storing vs non storing, and I could mention 
that fact.

2)  we leave it to configuration, the Root knows which groups to flood with 
MPL,  and the 6LR know to ignore the R flag, which is the more informed 
variation of the above. For this I do not need to spec anything in this 
protocol since it’s configuration but I could mention it more clearly as well.

3) the Root floods only if there’s listeners. That’s when we need signaling and 
want to leverage the new non storing signaling as opposed to spec’ing anything 
new / special. For this there’s no need to change the protocol, as in MOP “new” 
the 6LN sets the R flag and the 6LR tells the Root with a non-storing DAO. The 
constraint is that if a 6LN does not set the R flag then the multicast may not 
be flooded, it depends on others. This is why the draft says all the 6LNs MUST 
set the R flag.

What I can do is describe that a bit better, but I’d rather have a consistent 
behavior for everything protocol, which is what 1) and 3) give us, and allow 
configuration for tricks. You could also decide to distribute the said config 
in MPL, but that’s out of scope for this document.

Makes sense?

Pascal


For MOP “new”, the R bit in the EARO instructs the 6LR to send a DAO+RTO to the 
root. However in MOP 1, the R bit can be ignored by a 6LR running MPL, because 
all multicasts are already flooded and “reachability service” is therefore 
implied.



--

Regards
Dario



On Oct 8, 2021, at 7:52 AM, Pascal Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
 wrote:

Dear all

Based on the conversations on the ML this version of the draft incorporates:

- anycast support in IPv6 ND and RPL
- non storing mode multicast in RPL
- alternate multicast operation (e.g., MPL)
- IANA suggestions
- proposed formats
- deployment and backward compatibility considerations

What's left is the detailed operations, to come soon.

Enjoy the week end!

Pascal

-Original Message-
From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Sent: vendredi 8 octobre 2021 16:45
To: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>
Subject: New Version Notification for 
draft-thubert-6lo-multicast-registration-02.txt


A new version of I-D, draft-thubert-6lo-multicast-registration-02.txt
has been successfully submitted by Pascal Thubert and posted to the IETF 
repository.

Name:draft-thubert-6lo-multicast-registration
Revision:02
Title:   IPv6 Neighbor Discovery Multicast Address Registration
Document date:  2021-10-08
Group:Individual Submission
Pages: 21
URL:
https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/
Html:   
https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration
Diff:   
https://www.ietf.org/rfcdiff?url2

Re: [6lo] New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

[Pascal Thubert (pthubert)]

Many thanks Erik!


Regards,

Pascal

Le 9 oct. 2021 à 22:48, Erik Kline  a écrit :


It's up to the chairs, but as a reminder: RFC 7120 is an important resource.

On Sat, Oct 9, 2021 at 4:53 AM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
Dear chairs and ADs

The IANA section corrects a missing item from RFC 8505 and allocates new flag 
positions.

The Wi-Sun alliance is interested in this work but needs to see progress and 
will need the allocation of the multicast flag to start implementing.

What would be the earliest stage possible to get early assignments from IANA 
for this draft?


Regards,

Pascal

> Le 8 oct. 2021 à 16:54, Pascal Thubert (pthubert) 
> mailto:pthub...@cisco.com>> a écrit :
>
> Dear all
>
> Based on the conversations on the ML this version of the draft incorporates:
>
> - anycast support in IPv6 ND and RPL
> - non storing mode multicast in RPL
> - alternate multicast operation (e.g., MPL)
> - IANA suggestions
> - proposed formats
> - deployment and backward compatibility considerations
>
> What's left is the detailed operations, to come soon.
>
> Enjoy the week end!
>
> Pascal
>
> -Original Message-
> From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
> mailto:internet-dra...@ietf.org>>
> Sent: vendredi 8 octobre 2021 16:45
> To: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>
> Subject: New Version Notification for 
> draft-thubert-6lo-multicast-registration-02.txt
>
>
> A new version of I-D, draft-thubert-6lo-multicast-registration-02.txt
> has been successfully submitted by Pascal Thubert and posted to the IETF 
> repository.
>
> Name:draft-thubert-6lo-multicast-registration
> Revision:02
> Title:IPv6 Neighbor Discovery Multicast Address Registration
> Document date:2021-10-08
> Group:Individual Submission
> Pages:21
> URL:
> https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/
> Html:   
> https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.html
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-multicast-registration-02
>
> Abstract:
>   This document updates RFC 8505 to enable the address registration of
>   IPv6 anycast and multicast addresses to a 6LR and updates RFC 6550
>   (RPL) add a new Non-Storing multicast mode and support for anycast
>   addresses.  This document also extends RFC 9010 to enable the 6LR to
>   inject the anycast and multicast addresses in RPL.
>
>
>
>
> The IETF Secretariat
>
>
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

[Pascal Thubert (pthubert)]

Dear chairs and ADs

The IANA section corrects a missing item from RFC 8505 and allocates new flag 
positions. 

The Wi-Sun alliance is interested in this work but needs to see progress and 
will need the allocation of the multicast flag to start implementing.

What would be the earliest stage possible to get early assignments from IANA 
for this draft?


Regards,

Pascal

> Le 8 oct. 2021 à 16:54, Pascal Thubert (pthubert)  a 
> écrit :
> 
> Dear all
> 
> Based on the conversations on the ML this version of the draft incorporates:
> 
> - anycast support in IPv6 ND and RPL
> - non storing mode multicast in RPL
> - alternate multicast operation (e.g., MPL)
> - IANA suggestions 
> - proposed formats
> - deployment and backward compatibility considerations
> 
> What's left is the detailed operations, to come soon.
> 
> Enjoy the week end!
> 
> Pascal
> 
> -Original Message-
> From: internet-dra...@ietf.org  
> Sent: vendredi 8 octobre 2021 16:45
> To: Pascal Thubert (pthubert) 
> Subject: New Version Notification for 
> draft-thubert-6lo-multicast-registration-02.txt
> 
> 
> A new version of I-D, draft-thubert-6lo-multicast-registration-02.txt
> has been successfully submitted by Pascal Thubert and posted to the IETF 
> repository.
> 
> Name:draft-thubert-6lo-multicast-registration
> Revision:02
> Title:IPv6 Neighbor Discovery Multicast Address Registration
> Document date:2021-10-08
> Group:Individual Submission
> Pages:21
> URL:
> https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/
> Html:   
> https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.html
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-multicast-registration-02
> 
> Abstract:
>   This document updates RFC 8505 to enable the address registration of
>   IPv6 anycast and multicast addresses to a 6LR and updates RFC 6550
>   (RPL) add a new Non-Storing multicast mode and support for anycast
>   addresses.  This document also extends RFC 9010 to enable the 6LR to
>   inject the anycast and multicast addresses in RPL.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] FW: New Version Notification for draft-thubert-6lo-multicast-registration-02.txt

[Pascal Thubert (pthubert)]

Dear all

Based on the conversations on the ML this version of the draft incorporates:

- anycast support in IPv6 ND and RPL
- non storing mode multicast in RPL
- alternate multicast operation (e.g., MPL)
- IANA suggestions 
- proposed formats
- deployment and backward compatibility considerations

What's left is the detailed operations, to come soon.

Enjoy the week end!

Pascal

-Original Message-
From: internet-dra...@ietf.org  
Sent: vendredi 8 octobre 2021 16:45
To: Pascal Thubert (pthubert) 
Subject: New Version Notification for 
draft-thubert-6lo-multicast-registration-02.txt


A new version of I-D, draft-thubert-6lo-multicast-registration-02.txt
has been successfully submitted by Pascal Thubert and posted to the IETF 
repository.

Name:   draft-thubert-6lo-multicast-registration
Revision:   02
Title:  IPv6 Neighbor Discovery Multicast Address Registration
Document date:  2021-10-08
Group:  Individual Submission
Pages:  21
URL:
https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/
Html:   
https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-multicast-registration-02

Abstract:
   This document updates RFC 8505 to enable the address registration of
   IPv6 anycast and multicast addresses to a 6LR and updates RFC 6550
   (RPL) add a new Non-Storing multicast mode and support for anycast
   addresses.  This document also extends RFC 9010 to enable the 6LR to
   inject the anycast and multicast addresses in RPL.


  


The IETF Secretariat


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

[Pascal Thubert (pthubert)]

Makes sense Dario, will do.

I’m refining the draft right now; such details will probably only show in a few 
rounds, but they’ll be there.
01 to come out soon will:

- Cover Gene’s issues, mostly editorials, that he sent me in an offline file
- add anycast
- add non-storing multicast mode
- allow though not recommend mixed mode while signaling MOP 1 for backward 
compatibility
- update the DAO message with the ‘M’ and ‘A’ flags
- *not* provide the operation details

Keep safe;

Pascal

From: Dario Tedeschi 
Sent: vendredi 8 octobre 2021 1:41
To: Pascal Thubert (pthubert) 
Cc: 6lo@ietf.org
Subject: Re: [6lo] New Version Notification for 
draft-thubert-6lo-unicast-lookup-01.txt

I’m OK having the `M` bit, but I would like to see the error cases called out 
and what actions a node must take. E.g. one of:


  *   discard the packet
  *   send an ICMP Error ("Parameter Problem") or
  *   send an NA+EARO with error status.

Regards
Dario



On Oct 5, 2021, at 3:05 PM, Dario Tedeschi 
mailto:d...@exegin.com>> wrote:

Hi Pascal

See my comment  below.
On 10/5/21 12:40 PM, Pascal Thubert (pthubert) wrote:
Hello Dario

Please see below;


Le 5 oct. 2021 à 20:15, Dario Tedeschi 
<mailto:d...@exegin.com> a écrit :
 Hi Pascal,

Thank you for new draft. However I do have some comments/questions.

What benefit does the ‘M’ bit provide over simply detecting a multicast address 
in the Target Address field?

The IPv6 multicast address type is clearly defined in RFC 4291 (section 
2.4)<https://datatracker.ietf.org/doc/html/rfc4291#section-2.4>, and the 
detection of such an address is trivial. Most (if not all) Stacks have a simple 
function/macro to do that job and many existing protocols already use this 
mechanism to distinguish between unicast and multicast addresses.  It seems to 
me that a special bit to indicate multicast registration would be redundant and 
require handling for 4 different cases, 2 of which would be errors:


  *   M = 1, Target = multicast addr
  *   M = 1, Target= unicast addr  — ERROR
  *   M = 0, Target = multicast addr — ERROR
  *   M = 0, Target= unicast addr



True enough. Dario.

I’ve been pondering that too. On the one hand it seems cleaner to announce the 
service that the 6LN expects. Otoh as you point out it can be inferred from the 
address.

Another way of seeing this is that the error cases that you indicate can be 
detected if we have the bit otherwise they can’t.
[DT] I take your point about detecting the errors, assuming an implementation 
could do something useful with that knowledge, other than just discarding the 
message.



Then there’s anycast which is missing from both RPL and ND , which cannot be 
distinguished by the look of the address and thus requires a bit.
[DT] As for the anycast address, I suppose the question to ask is what would a 
router do differently knowing such information? I suspect we would have to 
define some new behavior along with the new bit.



Then there’s possibly the need of an IPv4 AF. All in all I tended to favor 
having the bit but that’s really not a strong position, happy to be convinced 
otherwise.
[DT] I presume you are talking of "IPv4-Compatible" and "IPv4-Mapped" IPv6 
addresses. If my presumption is correct, aren't these still easily identifiable 
through their unique prefixes (::/96 and ::/96, respectively)?



What do others think?
[DT] I have no strong opinion. The M bit just seemed redundant.





I also wonder about the requirement for non-storing RPL networks to propagate 
multicast membership up the DODAG. My understanding is that non-storing 
networks typically use MPL (RFC 
7731)<https://www.rfc-editor.org/rfc/rfc7731.html>  which does not need 
multicast memberships to be propagated throughout the DODAG. It uses a flooding 
mechanism to forward multicast datagrams, and does not unicast at L2. Could the 
new document accommodate non-storing networks using MPL?

Sure;

Bottom line here is that for MPL all the multicast packets of interest for the 
LLN are flooded throughout so I suspect that there is no need for the 6LR to 
signal to the root.
[DT] Yes, that's my understanding as well.




If that’s the case then there’s nothing to standardize.  All I need to clarify 
is that the RPL behavior in the spec is the one expected in a RPL domain that 
supports mop 3 otherwise what is done is out of scope for this doc.


 Do you see it otherwise?
[DT] I agree that only RPL mode 3 needs to be defined and other modes are left 
out of scope.




I mean should the 6LR signal unicast to the root like for unicast traffic when 
serving a RPL unaware leaf?
[DT] That certainly could be an optimization for non-storing mode so that a 
border-router might know what multicast groups to forward from outside the 
network. Unfortunately though there is no MOP that is "Non-storing with 
multicast", although one could argue semantics and simply use MOP 1.

[DT] If we were to opt f

Re: [6lo] New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

[Pascal Thubert (pthubert)]

Hello Dario





Le 6 oct. 2021 à 21:50, Dario Tedeschi  a écrit :

 Hi Pascal,

I think the 2nd and 4th cases can be merged, by allowing a root node to 
automatically propagate the following multicast messages, using MPL:

  *   All scope 3 (Realm-Local) multicast messages it either originates or 
receives on an MPL interface.
  *   All Unicast-Prefix-based IPv6 Multicast Addresses (RFC 3306) higher than 
scope 3, where the network prefix (given in the mulitcast destination address), 
matches the prefix of the DODAG ID (the RPL network's subnet).


WFM, conforms https://www.rfc-editor.org/rfc/rfc7346.html#section-5

Automatic forwarding of the 2nd address type could be optional and 
administratively configured.

If nodes are interested in other multicasts higher than scope 3, they must 
explicitly inform the root by sending DAO messages with appropriate Target 
Options.

-

The 3rd case, I think, needs its own mop code (i.e. "Non-storing mode with 
source-routed multicast").


Yes, but we have to look at backwards compatibility / brown field and allow 
though not recommend to use mop 1; same issue as already discussed with mop 3 
in the dread

For the 1st and 3rd cases, how do you envision multicasts propagating up the 
DODAG (towards the root)? Would a node simply L2 unicast to its preferred 
parent?


The 6 LN does. It know about RPL and registers the multicast address. Upon. The 
first registration The 6LR sends a unicast DAO to the Root as we do for RUL. 
This time though the address in the target is multicast. The root makes a copy 
per 6LR that shows as transit and sends along the unicast SR path to the 6 LR 
as it would for a RUL unicast. Less efficient that mop 3 that builds a real 
multicast tree, but backward compatible for for nodes on path…

Works?

Pascal



Regards
Dario


On 10/6/21 6:00 AM, Pascal Thubert (pthubert) wrote:
OK Dario, so we’d have 4 optional combinations:

unicast = mop 1 multicast = mop 3 (what the draft does today)
unicast = mop 1 multicast = MPL (that I believe the draft allows today but 
should clarify); in that mode, not message to the Root, the root floods all 
multicast messages with the idea that there’s always a listener somewhere
unicast = mop 1 multicast = mop 1 (to be added) in that mode the 6LR sends a 
DAO to the root for a multicast target, and the Root sends n messages that are 
unicast source routed to the n 6LR that have listeners, only the last address 
in the SRH is multicast
unicast = mop 1 multicast = MPL (that I believe the draft allows today but 
should clarify); in that mode, in that mode the 6LR sends a DAO to the root for 
a multicast target, and the root uses MPL only when there’s known listeners

Do we describe them all? Should we consume RPL MOPs?

I suggested that AODV RPL reuses MOP 4 to leave room…

Pascal

From: Dario Tedeschi <mailto:d...@exegin.com>
Sent: mercredi 6 octobre 2021 0:05
To: Pascal Thubert (pthubert) <mailto:pthub...@cisco.com>
Cc: 6lo@ietf.org<mailto:6lo@ietf.org>
Subject: Re: [6lo] New Version Notification for 
draft-thubert-6lo-unicast-lookup-01.txt

Hi Pascal

See my comment  below.
On 10/5/21 12:40 PM, Pascal Thubert (pthubert) wrote:
Hello Dario

Please see below;


Le 5 oct. 2021 à 20:15, Dario Tedeschi 
<mailto:d...@exegin.com> a écrit :
 Hi Pascal,

Thank you for new draft. However I do have some comments/questions.

What benefit does the ‘M’ bit provide over simply detecting a multicast address 
in the Target Address field?

The IPv6 multicast address type is clearly defined in RFC 4291 (section 
2.4)<https://datatracker.ietf.org/doc/html/rfc4291#section-2.4>, and the 
detection of such an address is trivial. Most (if not all) Stacks have a simple 
function/macro to do that job and many existing protocols already use this 
mechanism to distinguish between unicast and multicast addresses.  It seems to 
me that a special bit to indicate multicast registration would be redundant and 
require handling for 4 different cases, 2 of which would be errors:


  *   M = 1, Target = multicast addr
  *   M = 1, Target= unicast addr  — ERROR
  *   M = 0, Target = multicast addr — ERROR
  *   M = 0, Target= unicast addr



True enough. Dario.

I’ve been pondering that too. On the one hand it seems cleaner to announce the 
service that the 6LN expects. Otoh as you point out it can be inferred from the 
address.

Another way of seeing this is that the error cases that you indicate can be 
detected if we have the bit otherwise they can’t.
[DT] I take your point about detecting the errors, assuming an implementation 
could do something useful with that knowledge, other than just discarding the 
message.



Then there’s anycast which is missing from both RPL and ND , which cannot be 
distinguished by the look of the address and thus requires a bit.
[DT] As for the anycast address, I suppose the question to ask is what would a 
router do differently knowing such information? I suspect we

Re: [6lo] New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

[Pascal Thubert (pthubert)]

OK Dario, so we’d have 4 optional combinations:

unicast = mop 1 multicast = mop 3 (what the draft does today)
unicast = mop 1 multicast = MPL (that I believe the draft allows today but 
should clarify); in that mode, not message to the Root, the root floods all 
multicast messages with the idea that there’s always a listener somewhere
unicast = mop 1 multicast = mop 1 (to be added) in that mode the 6LR sends a 
DAO to the root for a multicast target, and the Root sends n messages that are 
unicast source routed to the n 6LR that have listeners, only the last address 
in the SRH is multicast
unicast = mop 1 multicast = MPL (that I believe the draft allows today but 
should clarify); in that mode, in that mode the 6LR sends a DAO to the root for 
a multicast target, and the root uses MPL only when there’s known listeners

Do we describe them all? Should we consume RPL MOPs?

I suggested that AODV RPL reuses MOP 4 to leave room…

Pascal

From: Dario Tedeschi 
Sent: mercredi 6 octobre 2021 0:05
To: Pascal Thubert (pthubert) 
Cc: 6lo@ietf.org
Subject: Re: [6lo] New Version Notification for 
draft-thubert-6lo-unicast-lookup-01.txt

Hi Pascal

See my comment  below.
On 10/5/21 12:40 PM, Pascal Thubert (pthubert) wrote:
Hello Dario

Please see below;


Le 5 oct. 2021 à 20:15, Dario Tedeschi 
<mailto:d...@exegin.com> a écrit :
 Hi Pascal,

Thank you for new draft. However I do have some comments/questions.

What benefit does the ‘M’ bit provide over simply detecting a multicast address 
in the Target Address field?

The IPv6 multicast address type is clearly defined in RFC 4291 (section 
2.4)<https://datatracker.ietf.org/doc/html/rfc4291#section-2.4>, and the 
detection of such an address is trivial. Most (if not all) Stacks have a simple 
function/macro to do that job and many existing protocols already use this 
mechanism to distinguish between unicast and multicast addresses.  It seems to 
me that a special bit to indicate multicast registration would be redundant and 
require handling for 4 different cases, 2 of which would be errors:


  *   M = 1, Target = multicast addr
  *   M = 1, Target= unicast addr  — ERROR
  *   M = 0, Target = multicast addr — ERROR
  *   M = 0, Target= unicast addr



True enough. Dario.

I’ve been pondering that too. On the one hand it seems cleaner to announce the 
service that the 6LN expects. Otoh as you point out it can be inferred from the 
address.

Another way of seeing this is that the error cases that you indicate can be 
detected if we have the bit otherwise they can’t.
[DT] I take your point about detecting the errors, assuming an implementation 
could do something useful with that knowledge, other than just discarding the 
message.



Then there’s anycast which is missing from both RPL and ND , which cannot be 
distinguished by the look of the address and thus requires a bit.
[DT] As for the anycast address, I suppose the question to ask is what would a 
router do differently knowing such information? I suspect we would have to 
define some new behavior along with the new bit.



Then there’s possibly the need of an IPv4 AF. All in all I tended to favor 
having the bit but that’s really not a strong position, happy to be convinced 
otherwise.
[DT] I presume you are talking of "IPv4-Compatible" and "IPv4-Mapped" IPv6 
addresses. If my presumption is correct, aren't these still easily identifiable 
through their unique prefixes (::/96 and ::/96, respectively)?



What do others think?
[DT] I have no strong opinion. The M bit just seemed redundant.





I also wonder about the requirement for non-storing RPL networks to propagate 
multicast membership up the DODAG. My understanding is that non-storing 
networks typically use MPL (RFC 
7731)<https://www.rfc-editor.org/rfc/rfc7731.html>  which does not need 
multicast memberships to be propagated throughout the DODAG. It uses a flooding 
mechanism to forward multicast datagrams, and does not unicast at L2. Could the 
new document accommodate non-storing networks using MPL?

Sure;

Bottom line here is that for MPL all the multicast packets of interest for the 
LLN are flooded throughout so I suspect that there is no need for the 6LR to 
signal to the root.
[DT] Yes, that's my understanding as well.




If that’s the case then there’s nothing to standardize.  All I need to clarify 
is that the RPL behavior in the spec is the one expected in a RPL domain that 
supports mop 3 otherwise what is done is out of scope for this doc.


 Do you see it otherwise?
[DT] I agree that only RPL mode 3 needs to be defined and other modes are left 
out of scope.




I mean should the 6LR signal unicast to the root like for unicast traffic when 
serving a RPL unaware leaf?
[DT] That certainly could be an optimization for non-storing mode so that a 
border-router might know what multicast groups to forward from outside the 
network. Unfortunately though there is no MOP that is "Non-storing

Re: [6lo] New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

[Pascal Thubert (pthubert)]

Hello Dario

Please see below;


Le 5 oct. 2021 à 20:15, Dario Tedeschi  a écrit :

 Hi Pascal,

Thank you for new draft. However I do have some comments/questions.

What benefit does the ‘M’ bit provide over simply detecting a multicast address 
in the Target Address field?

The IPv6 multicast address type is clearly defined in RFC 4291 (section 
2.4)<https://datatracker.ietf.org/doc/html/rfc4291#section-2.4>, and the 
detection of such an address is trivial. Most (if not all) Stacks have a simple 
function/macro to do that job and many existing protocols already use this 
mechanism to distinguish between unicast and multicast addresses.  It seems to 
me that a special bit to indicate multicast registration would be redundant and 
require handling for 4 different cases, 2 of which would be errors:


  *   M = 1, Target = multicast addr
  *   M = 1, Target= unicast addr  — ERROR
  *   M = 0, Target = multicast addr — ERROR
  *   M = 0, Target= unicast addr



True enough. Dario.

I’ve been pondering that too. On the one hand it seems cleaner to announce the 
service that the 6LN expects. Otoh as you point out it can be inferred from the 
address.

Another way of seeing this is that the error cases that you indicate can be 
detected if we have the bit otherwise they can’t.

Then there’s anycast which is missing from both RPL and ND , which cannot be 
distinguished by the look of the address and thus requires a bit.

Then there’s possibly the need of an IPv4 AF. All in all I tended to favor 
having the bit but that’s really not a strong position, happy to be convinced 
otherwise.

What do others think?

I also wonder about the requirement for non-storing RPL networks to propagate 
multicast membership up the DODAG. My understanding is that non-storing 
networks typically use MPL (RFC 
7731)<https://www.rfc-editor.org/rfc/rfc7731.html>  which does not need 
multicast memberships to be propagated throughout the DODAG. It uses a flooding 
mechanism to forward multicast datagrams, and does not unicast at L2. Could the 
new document accommodate non-storing networks using MPL?

Sure;

Bottom line here is that for MPL all the multicast packets of interest for the 
LLN are flooded throughout so I suspect that there is no need for the 6LR to 
signal to the root.

If that’s the case then there’s nothing to standardize.  All I need to clarify 
is that the RPL behavior in the spec is the one expected in a RPL domain that 
supports mop 3 otherwise what is done is out of scope for this doc.

 Do you see it otherwise?

I mean should the 6LR signal unicast to the root like for unicast traffic when 
serving a RPL unaware leaf?

 If so wouldn’t it be expected that the Root makes n unicast to all 6LRs that 
have listeners?

Should we describe that mode as well?

Pascal

Regards
Dario


On Sep 27, 2021, at 6:32 AM, Pascal Thubert (pthubert) 
mailto:pthubert=40cisco@dmarc.ietf.org>>
 wrote:

Dear all:

This draft is a continuation of our work on RFC 8505, 8928, and 8929.

Comments welcome!

Pascal

-Original Message-
From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
mailto:internet-dra...@ietf.org>>
Sent: lundi 27 septembre 2021 15:29
To: Eric Levy- Abegnoli (elevyabe) 
mailto:elevy...@cisco.com>>; Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>>
Subject: New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt


A new version of I-D, draft-thubert-6lo-unicast-lookup-01.txt
has been successfully submitted by Pascal Thubert and posted to the IETF 
repository.

Name: draft-thubert-6lo-unicast-lookup
Revision: 01
Title: IPv6 Neighbor Discovery Unicast Lookup
Document date: 2021-09-27
Group: Individual Submission
Pages: 15
URL:
https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/
Html:   
https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thubert-6lo-unicast-lookup
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-unicast-lookup-01

Abstract:
  This document updates RFC 8505 in order to enable unicast address
  lookup from a 6LoWPAN Border Router acting as an Address Registrar.




The IETF Secretariat


___
6lo mailing list
6lo@ietf.org<mailto:6lo@ietf.org>
https://www.ietf.org/mailman/listinfo/6lo

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] New Version Notification for draft-thubert-6lo-multicast-registration-00.txt

[Pascal Thubert (pthubert)]

Dear chairs

There’s effectively a clear and present need for this feature in a normative 
body with a quick deadline.

The cool thing is that we are on known grounds, just need to extend rfc 8505 
while retaining the general behavior.

What’s cool for the 6LN is that it will not do much special stuff vs a unicast 
address; refrain from sourcing packet from it, and set a multicast bit in the 
registration will do the trick.

For the 6LR it’s a bit more work but still we can largely inherit from rfc 9010.

I’ll produce the rev with Gene’s points addressed in the next 2 weeks. Due to 
the urgency of the situation, other comments to be addressed in that rev would 
be welcome this week…

Regards,

Pascal

> Le 4 oct. 2021 à 20:39, Falendysz, Gene  a écrit :
> 
> Hi Pascal,
>  Works for me! Thanks for addressing my issues. I agree that this needs to be 
> addressedquickly, we have an urgent need for this functionality.
> 
> Gene Falendysz
> 864-723-1395 
> 
> -Original Message-
> From: Pascal Thubert (pthubert)  
> Sent: Monday, October 4, 2021 2:20 PM
> To: Falendysz, Gene 
> Cc: 6lo@ietf.org
> Subject: Re: New Version Notification for 
> draft-thubert-6lo-multicast-registration-00.txt
> 
> Hello Gene
> 
> Many thanks for your review and comments!
> 
> And welcome to the list : )
> 
> Please see below 
> 
>> Le 4 oct. 2021 à 19:28, Falendysz, Gene  a écrit :
>> 
>> Ok everyone, please excuse the fumbling of the new guy. My previous 
>> comments were actually for this draft, not the one I indicated earlier. 
>> Please disregard my last email.
>> 
>> Repeated, now for the correct draft:
>> Hi Pascal,
>> This is a very good addition. It is needed for devices that have very 
>> limited resources. Battery devices in the utility industry sleep for periods 
>> of time and are not conducive to the discovery methods that require 
>> broadcast.
> 
> Yes, I understand that we underestimated the need of multicast when we did 
> RFC 8505 and 9010. We need to catch up quickly now.
> 
>> I do have  few comments:
>> -In the introduction it mentions that energy drain and then further 
>> qualifies it to transmissions. In reality listening is also a significant 
>> power consumer which is why many battery devices employ sampled listening.
> 
> Certainly, though in gory details that depends a lot on the MAC operation. I 
> wanted to pack all aspects in the word transmission. I’ll tweak to indicate 
> the power to turn the radio on.
> 
>> -In the third last paragraph of the introduction it talks about the 
>> registration of “a multicast address”. It should not be limited to 
>> registering a single multicast address. Constrained devices may need to 
>> receive from multiple multicast addresses.
> 
> There was no intent to restrict that; but I’ll clarify “one or more”.
> 
> 
>> -The last paragraph of section 3 indicates that the multicast frames are 
>> unicast to the each 6LN that registers for a multicast address. If the MAC 
>> supports it, why not allow broadcast?
>> 
> 
> For reliability. Broadcast is typically not acknowledged. Also sleeping 
> devices like to pull their packets on their own time. I can make it a SHOULD 
> when I specify that part and add “typically” to section 3.
> 
> Works?
> 
> Keep safe,
> 
> Pascal 
>> Best regards,
>> 
>> Gene Falendysz
>> 864-723-1395 
>> 
>> -Original Message-
>> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Pascal Thubert (pthubert)
>> Sent: Monday, October 4, 2021 12:45 PM
>> To: 6lo@ietf.org
>> Subject: [EXTERNAL] [6lo] FW: New Version Notification for 
>> draft-thubert-6lo-multicast-registration-00.txt
>> 
>> Dear all:
>> 
>> I published an early draft for the support of multicast address registration 
>> so that a 6LN that registers its unicast GUA/ULA addresses using RFC 8505 
>> can also register to multicast streams the same way. This makes the 6LN life 
>> a lot easier than MLDv2, which requires the host to listen to multicast 
>> queries from the router, same bottom line as with classical ND really. 
>> 
>> The draft has an overview and some deployment considerations that give a 
>> good idea of where it's going. It will also cover the equivalent of RFC 901à 
>> to inject the multicast registration into the RPL MOP 3 that is how RPL 
>> supports multicast.
>> 
>> Before I dive in the gory details, I'd appreciate feedback to unsure that 
>> the new operation as currently laid out in the draft is consistent with your 
>> expectations.
>> 
>> Please share your though

Re: [6lo] New Version Notification for draft-thubert-6lo-multicast-registration-00.txt

[Pascal Thubert (pthubert)]

Hello Gene

Many thanks for your review and comments!

And welcome to the list : )

Please see below 

> Le 4 oct. 2021 à 19:28, Falendysz, Gene  a écrit :
> 
> Ok everyone, please excuse the fumbling of the new guy. My previous comments 
> were actually for this draft, not the one I indicated earlier. Please 
> disregard my last email.
> 
> Repeated, now for the correct draft:
> Hi Pascal,
>  This is a very good addition. It is needed for devices that have very 
> limited resources. Battery devices in the utility industry sleep for periods 
> of time and are not conducive to the discovery methods that require broadcast.

Yes, I understand that we underestimated the need of multicast when we did RFC 
8505 and 9010. We need to catch up quickly now.

> I do have  few comments:
> -In the introduction it mentions that energy drain and then further 
> qualifies it to transmissions. In reality listening is also a significant 
> power consumer which is why many battery devices employ sampled listening.

Certainly, though in gory details that depends a lot on the MAC operation. I 
wanted to pack all aspects in the word transmission. I’ll tweak to indicate the 
power to turn the radio on.

> -In the third last paragraph of the introduction it talks about the 
> registration of “a multicast address”. It should not be limited to 
> registering a single multicast address. Constrained devices may need to 
> receive from multiple multicast addresses.

There was no intent to restrict that; but I’ll clarify “one or more”.


> -The last paragraph of section 3 indicates that the multicast frames are 
> unicast to the each 6LN that registers for a multicast address. If the MAC 
> supports it, why not allow broadcast?
> 

For reliability. Broadcast is typically not acknowledged. Also sleeping devices 
like to pull their packets on their own time. I can make it a SHOULD when I 
specify that part and add “typically” to section 3.

Works?

Keep safe,

Pascal 
> Best regards,
> 
> Gene Falendysz
> 864-723-1395 
> 
> -----Original Message-
> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Pascal Thubert (pthubert)
> Sent: Monday, October 4, 2021 12:45 PM
> To: 6lo@ietf.org
> Subject: [EXTERNAL] [6lo] FW: New Version Notification for 
> draft-thubert-6lo-multicast-registration-00.txt
> 
> Dear all:
> 
> I published an early draft for the support of multicast address registration 
> so that a 6LN that registers its unicast GUA/ULA addresses using RFC 8505 can 
> also register to multicast streams the same way. This makes the 6LN life a 
> lot easier than MLDv2, which requires the host to listen to multicast queries 
> from the router, same bottom line as with classical ND really. 
> 
> The draft has an overview and some deployment considerations that give a good 
> idea of where it's going. It will also cover the equivalent of RFC 901à to 
> inject the multicast registration into the RPL MOP 3 that is how RPL supports 
> multicast.
> 
> Before I dive in the gory details, I'd appreciate feedback to unsure that the 
> new operation as currently laid out in the draft is consistent with your 
> expectations.
> 
> Please share your thoughts;
> 
> Pascal
> 
> -Original Message-
> From: internet-dra...@ietf.org  
> Sent: jeudi 30 septembre 2021 11:46
> To: Pascal Thubert (pthubert) 
> Subject: New Version Notification for 
> draft-thubert-6lo-multicast-registration-00.txt
> 
> 
> A new version of I-D, draft-thubert-6lo-multicast-registration-00.txt
> has been successfully submitted by Pascal Thubert and posted to the IETF 
> repository.
> 
> Name:draft-thubert-6lo-multicast-registration
> Revision:00
> Title:IPv6 Neighbor Discovery Multicast Address Registration
> Document date:2021-09-30
> Group:Individual Submission
> Pages:14
> URL:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-00.txt__;!!F7jv3iA!ln-6xp6O6lT5yo8nqyBDoS_x1WzcdItAPZzGs5ALHK4BjvnH0qp-MdyGEFKIb640aV8$
>  
> Status: 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/__;!!F7jv3iA!ln-6xp6O6lT5yo8nqyBDoS_x1WzcdItAPZzGs5ALHK4BjvnH0qp-MdyGEFKI2d-DpU8$
>  
> Html:   
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-00.html__;!!F7jv3iA!ln-6xp6O6lT5yo8nqyBDoS_x1WzcdItAPZzGs5ALHK4BjvnH0qp-MdyGEFKIn2-lpWc$
>  
> Htmlized:   
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration__;!!F7jv3iA!ln-6xp6O6lT5yo8nqyBDoS_x1WzcdItAPZzGs5ALHK4BjvnH0qp-MdyGEFKIklkF1BY$
>  
> 
> 
> Abstract:

[6lo] FW: New Version Notification for draft-thubert-6lo-multicast-registration-00.txt

[Pascal Thubert (pthubert)]

Dear all:

I published an early draft for the support of multicast address registration so 
that a 6LN that registers its unicast GUA/ULA addresses using RFC 8505 can also 
register to multicast streams the same way. This makes the 6LN life a lot 
easier than MLDv2, which requires the host to listen to multicast queries from 
the router, same bottom line as with classical ND really. 

The draft has an overview and some deployment considerations that give a good 
idea of where it's going. It will also cover the equivalent of RFC 901à to 
inject the multicast registration into the RPL MOP 3 that is how RPL supports 
multicast.

Before I dive in the gory details, I'd appreciate feedback to unsure that the 
new operation as currently laid out in the draft is consistent with your 
expectations.

Please share your thoughts;

Pascal

-Original Message-
From: internet-dra...@ietf.org  
Sent: jeudi 30 septembre 2021 11:46
To: Pascal Thubert (pthubert) 
Subject: New Version Notification for 
draft-thubert-6lo-multicast-registration-00.txt


A new version of I-D, draft-thubert-6lo-multicast-registration-00.txt
has been successfully submitted by Pascal Thubert and posted to the IETF 
repository.

Name:   draft-thubert-6lo-multicast-registration
Revision:   00
Title:  IPv6 Neighbor Discovery Multicast Address Registration
Document date:  2021-09-30
Group:  Individual Submission
Pages:  14
URL:
https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-thubert-6lo-multicast-registration/
Html:   
https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-00.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thubert-6lo-multicast-registration


Abstract:
   This document updates RFC 8505 in order to enable the registration by
   a 6LN of an IPv6 multicast address to a 6LR.  This document also
   extends RFC 9010 to enable the 6LR to inject the address in the RPL
   multicast support.


  


The IETF Secretariat


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] FW: New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt

[Pascal Thubert (pthubert)]

Dear all:

This draft is a continuation of our work on RFC 8505, 8928, and 8929.

Comments welcome!

Pascal

-Original Message-
From: internet-dra...@ietf.org  
Sent: lundi 27 septembre 2021 15:29
To: Eric Levy- Abegnoli (elevyabe) ; Pascal Thubert 
(pthubert) 
Subject: New Version Notification for draft-thubert-6lo-unicast-lookup-01.txt


A new version of I-D, draft-thubert-6lo-unicast-lookup-01.txt
has been successfully submitted by Pascal Thubert and posted to the IETF 
repository.

Name:   draft-thubert-6lo-unicast-lookup
Revision:   01
Title:  IPv6 Neighbor Discovery Unicast Lookup
Document date:  2021-09-27
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-thubert-6lo-unicast-lookup/
Html:   
https://www.ietf.org/archive/id/draft-thubert-6lo-unicast-lookup-01.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thubert-6lo-unicast-lookup
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-unicast-lookup-01

Abstract:
   This document updates RFC 8505 in order to enable unicast address
   lookup from a 6LoWPAN Border Router acting as an Address Registrar.


  


The IETF Secretariat


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] [IANA #1200929] expert review for draft-irtf-icnrg-icnlowpan-10

[Pascal Thubert (pthubert)]

Hello Cenk

Superb!

This leaves unallocated space for future work. We can still write somewhere 
that this page is reserved for NDN so you can add stuff in the future with no 
page switch.

Very cool.

Pascal

Le 23 sept. 2021 à 12:42, Cenk Gündoğan 
 a écrit :

Hello Pascal,

thanks for your helpful input.  I was able to squeeze out a bit for CCNx
messages by not encoding the version field and always relying on the
version number to be "1" (as mandated by RFC8609 [1]).  6LoWPAN follows
a similar philosophy [2].  I guess any serious protocol update may
require big changes on the compression scheme anyways.

If you are okay with the current allocations (diff: [3]), then I would
carry this change back to the icnrg mail list and initiate a version
update on positive feedback.

Cheers,
Cenk

[1] https://datatracker.ietf.org/doc/html/rfc8609#section-3.2
[2] https://datatracker.ietf.org/doc/html/rfc6282#section-3
[3] 
https://tools.ietf.org//rfcdiff?url1=draft-irtf-icnrg-icnlowpan-10=https://inet.haw-hamburg.de/tmp/draft-irtf-icnrg-icnlowpan-11.txt/@@download/file/draft-irtf-icnrg-icnlowpan-11.txt

On Thu, Sep 23 2021 at 10:19 +0200, Cenk Gündoğan wrote:

[[PGP Signed Part:Undecided]]
Hello Pascal,

the compressed NDN Interest + compressed NDN Data message dispatches
have a few RSV bits.  Fixing the prefix on 4 bits might work for them.
For the compressed CCNx Content Object message it already works since we
removed the RSV bit in the proposed solution.

Currently, the compressed CCNx Interest message dispatch consumes two
full octets and has no RSV bits left.  That's the source of the
asymmetry.  I'll have a look at that particular section to see if we can
optimize something there and will report again.

Thanks,
Cenk

On Thu, Sep 23 2021 at 07:31 +0000, Pascal Thubert (pthubert) wrote:

Hello Amanda;

The current draft has this:

   +-+--+---+
   | Bit Pattern | Page | Header Type   |
   +-+--+---+
   |  00 00  | TBD1 | Uncompressed NDN Interest messages|
   |  00 10  | TBD1 | Uncompressed NDN Data messages|
   |  01 00  | TBD1 | Uncompressed CCNx Interest messages   |
   |  01 10  | TBD1 | Uncompressed CCNx Content Object messages |
   |  10 0x  | TBD1 | Compressed NDN Interest messages  |
   |  10 1x  | TBD1 | Compressed NDN Data messages  |
   |  11 0x  | TBD1 | Compressed CCNx Interest messages |
   |  11 1x  | TBD1 | Compressed CCNx Content Object messages   |
   +-+--+---+

The Uncompressed form has the 4 rightmost bits set to 0 while the compressed 
has them x.
Which leaves lots of unassigned space un the Uncompressed range.

This simple proposal seems to break the symmetry of compressed forms.


   |  10 0x  | TBD1 | Compressed NDN Interest messages  |
   |  10 1x  | TBD1 | Compressed NDN Data messages  |
   |  10 0x  | TBD1 | Compressed CCNx Interest messages |
   |  11 10  | TBD1 | Compressed CCNx Content Object messages   |

Maybe 4 bits is sufficient in all compressed forms? If so we can do better:

   +-+--+---+
   | Bit Pattern | Page | Header Type   |
   +-+--+---+
   |  00 00  | TBD1 | Uncompressed NDN Interest messages|
   |  00 01  |  |   |
   |...  |  |  Unassigned   |
   |  00 00  |  |   |
   |  00 01  | TBD1 | Compressed NDN Interest messages  |
   |  00 10  | TBD1 | Uncompressed NDN Data messages|
   |  00 11  |  |   |
   |...  |  |  Unassigned   |
   |  00 10  |  |   |
   |  00 11  | TBD1 | Compressed NDN Data messages  |
   |  01 00  | TBD1 | Uncompressed CCNx Interest messages   |
   |  01 01  |  |   |
   |...  |  |  Unassigned   |
   |  01 00  |  |   |
   |  01 01  | TBD1 | Compressed CCNx Interest messages |
   |  01 10  | TBD1 | Uncompressed CCNx Content Object messages |
   |  01 11  |  |   |
   |...  |  |  Unassigned   |
   |  01 10  |  |   |
   |  01 11  | TBD1 | Compressed CCNx Content Object messages   |
   +-+--+---+

Works?

Pascal

T

Re: [6lo] [IANA #1200929] expert review for draft-irtf-icnrg-icnlowpan-10

[Pascal Thubert (pthubert)]

Hello Amanda;

The current draft has this:

+-+--+---+
| Bit Pattern | Page | Header Type   |
+-+--+---+
|  00 00  | TBD1 | Uncompressed NDN Interest messages|
|  00 10  | TBD1 | Uncompressed NDN Data messages|
|  01 00  | TBD1 | Uncompressed CCNx Interest messages   |
|  01 10  | TBD1 | Uncompressed CCNx Content Object messages |
|  10 0x  | TBD1 | Compressed NDN Interest messages  |
|  10 1x  | TBD1 | Compressed NDN Data messages  |
|  11 0x  | TBD1 | Compressed CCNx Interest messages |
|  11 1x  | TBD1 | Compressed CCNx Content Object messages   |
+-+--+---+

The Uncompressed form has the 4 rightmost bits set to 0 while the compressed 
has them x.
Which leaves lots of unassigned space un the Uncompressed range.

This simple proposal seems to break the symmetry of compressed forms.


|  10 0x  | TBD1 | Compressed NDN Interest messages  |
|  10 1x  | TBD1 | Compressed NDN Data messages  |
|  10 0x  | TBD1 | Compressed CCNx Interest messages |
|  11 10  | TBD1 | Compressed CCNx Content Object messages   |

Maybe 4 bits is sufficient in all compressed forms? If so we can do better:

+-+--+---+
| Bit Pattern | Page | Header Type   |
+-+--+---+
|  00 00  | TBD1 | Uncompressed NDN Interest messages|
|  00 01  |  |   |
|...  |  |  Unassigned   |
|  00 00  |  |   |
|  00 01  | TBD1 | Compressed NDN Interest messages  |
|  00 10  | TBD1 | Uncompressed NDN Data messages|
|  00 11  |  |   |
|...  |  |  Unassigned   |
|  00 10  |  |   |
|  00 11  | TBD1 | Compressed NDN Data messages  |
|  01 00  | TBD1 | Uncompressed CCNx Interest messages   |
|  01 01  |  |   |
|...  |  |  Unassigned   |
|  01 00  |  |   |
|  01 01  | TBD1 | Compressed CCNx Interest messages |
|  01 10  | TBD1 | Uncompressed CCNx Content Object messages |
|  01 11  |  |   |
|...  |  |  Unassigned   |
|  01 10  |  |   |
|  01 11  | TBD1 | Compressed CCNx Content Object messages   |
+-+--+---+

Works?

Pascal

This leaves unassigned space 

> -Original Message-
> From: Amanda Baber via RT 
> Sent: mercredi 22 septembre 2021 19:30
> Cc: Eric Vyncke (evyncke) ; ek.i...@gmail.com;
> carle...@entel.upc.edu; shwetha.bhand...@gmail.com; Pascal Thubert
> (pthubert) ; robert.cra...@gridmerge.com; 6lo@ietf.org
> Subject: [IANA #1200929] expert review for draft-irtf-icnrg-icnlowpan-10
> 
> Hi,
> 
> IANA has been asked to notify the 6lo group and the authors of RFC 8025 as
> well as the IESG-designated experts that the authors of draft-irtf-icnrg-
> icnlowpan-10 (and the RG) have accepted a proposed change to an assignment
> in that document.
> 
> Carles and Shwetha, can you confirm that we can move forward with this
> registry update?
> 
> The issue is that Table 2 in https://datatracker.ietf.org/doc/html/draft-
> irtf-icnrg-icnlowpan is currently instructing IANA to make this
> registration in the Dispatch Type Field registry (we understand that this
> "TBD1" should be page 14):
> 
> 11 1x | TBD1 | Compressed CCNx Content Object messages
> 
> However, 11 11 has already been assigned to "Page switch" for pages 0-
> 15:
> 
> https://www.iana.org/assignments/_6lowpan-parameters
> 
> This is the solution suggested by the experts and accepted by the authors:
> 
> =
> 
> One simple solution could be as follows:
> 
> OLD:
> 11 1x | TBD1 | Compressed CCNx Content Object messages
> 
> NEW:
> 11 10 | TBD1 | Compressed CCNx Content Object messages
> 
> A drawback of this solution is that it reduces the space of this type of
> messages (from 32 options to 16 options, for this specific type of
>

Re: [6lo] 2nd WGLC for draft-ietf-6lo-use-cases

[Pascal Thubert (pthubert)]

Dear chair and authors

Please find some WG LC comments below on draft-ietf-6lo-use-cases-09:

I feel there should be a pass on grammar by a native speaker before the IETF 
last call. Some things, mostly at the beginning,  sound strange to my hear but 
being non-native I do not feel entitled / capable to comment on that.




There are occurrences of mis-typing 6LoWPAN as below:


The IETF 6LoPWAN (IPv6 over Low powerWPAN)
>>

The IETF 6LoWPAN (IPv6 over Low-Power WPAN)

See also

   Neighbor Discovery Optimization for 6LoPWAN 
[RFC6775].
>>



   Neighbor Discovery Optimization for 6LoWPAN 
[RFC6775][RFC8505].


Not sure you need section 2 with the BCP 14 language. This is an informational 
draft



Section 3.2: the Bluetooth SIG is mostly done with the effort named "IP Link" 
within the Internet Workgroup, to provide an optimized transport over BLE 5 
Extended Advertisements for 6LoWPAN HC and above it Thread. I believe that is 
worth mentioning? Contacts, if you need more, would be Martin Turon 
mtu...@google.com and Himanshu Bhalla 
himanshu.bha...@intel.com.


Section 3.6 . G3 PLC uses an escaped 6LoWPAN, and you discuss it in 4.1. Why 
not a word with a forward reference here?


Section 4 has G9903 and Netricity but IMHO it’s missing Wi-SUN 
(https://wi-sun.org/). This looks like an unfair omission. Wi-SUN combines 
6LoWPAN and RPL, and arguably uses a different 802.15.4 since it is SubGig 
15.4g, without the frame size constraint and multiple PHY rates. You may use 
https://tools.ietf.org/html/rfc8376#section-2.4 as a reference.

The major application is smartgrid AMI, but due to its slow channel hopping 
method, it is close ot 6TiSCH and provides a similar applicability, e.g., grid 
and factory automation.


Section 4 is also missing Thread https://www.threadgroup.org/. Arguably that is 
classical 802.15.4 but in fact since Thread is route-over, links of various 
MAC/PHY technologies could be integrated, think Wi-Fi or BLE. This is a better 
story for IPv6 than a home IoT networking technology like those listed in 6.1 
or 6.3 which stick to a single MAC/PHY. Applicability includes home networks 
and building, e.g., for lighting.



Section 5 is really neat and useful. I’d love to see it earlier, why is it 
between 4 and 6???

One crucial point is the use of broadcast. Together with L3-routing, 6LoWPAN ND 
reduces that a lot vs. classical ND. Could you add words or a bullet on this, 
maybe splitting “o  Address Assignment:” into “o  Address Assignment:”, which 
is a bit long as is, and something like  “o broadcast avoidance:”




Section 5 mentions RPL several times; it also mentions 6LoWPAN ND (all good!). 
There was indeed a special effort integrating those two, and more.

* This effort shows in RFC 8138 (and 
https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/), which 
extends 6LoWPAN HC to compress also the RPL artifacts used when forwarding 
packets in the route-over mesh. This could be mentioned in the “
   o  Header Compression:” bullet.

* This effort also  shows in 
https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ that allows a 
6LoWPAN node, called a RUL, to benefit from routing-over services in a RPL 
network without speaking RPL per se; instead, RFC 8505 is used as a 
protocol-independent registration to obtain routing services from RPL. The 
bottom line is that 6LoWPAN provides a rich host-to-router interface for 
constrained network, that is now leverage to enable router-to-router protocols 
(including RPL and RIFT). Maybe you could have a “o Host-to-Router abstract 
interface:” bullet?

* RFC 8505 is also used to request proxy ND services in case of a backbone, see 
https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/; you mention 
the backbone but not the backbone router.  Maybe that’s another bullet?


By the time you publish the next version AP-ND will probably be published as 
RFC 8928 (and 6BBR as RFC 8929)


6lo working group is working on address

  authentication 
[I-D.ietf-6lo-ap-nd]
 a



->



Address Protection for 6LoWPAN ND (AP-ND) [RFC8928] enables

Source Address Validation [RFC6620] and protects the

Address Ownership against impersonation attacks.




Section 6.3: the big thing with DECT is that the you get something like 20MHz 
of spectrum (and 10 channels) around the 1900MHz that is reserved for the usage 
of “cordless phones”. It is much easier to control its usage in a given area 
such as a factory or a hospital, so it is more suitable for critical 
applications than, say, Zigbee; I’d have loved a healthcare use case. But OK.


I hope this helps!

Keep safe,

Pascal




From: 6lo <6lo-boun...@ietf.org> On Behalf Of Shwetha
Sent: dimanche 4 octobre 2020 09:03
To: 6lo@ietf.org

Re: [6lo] AP-ND 22

[Pascal Thubert (pthubert)]

Hello Abdussalam:

I added the suggested IANA 
https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-22#section-8.4 .
I trust the IESG on the meaning of updating.

Stay safe,

Pascal

From: 6lo <6lo-boun...@ietf.org> On Behalf Of Abdussalam Baryun
Sent: lundi 27 avril 2020 14:00
To: Benjamin Kaduk 
Cc: 6lo-cha...@ietf.org; Pascal Thubert (pthubert) 
; Mohit Sethi 
; Rene Struik ; Shwetha 
Bhandari (shwethab) ; 6lo@ietf.org; Erik Kline 
; Jim Schaad 
Subject: Re: [6lo] AP-ND 22



On Mon, Apr 27, 2020 at 5:52 AM Benjamin Kaduk 
mailto:ka...@mit.edu>> wrote:
On Sun, Apr 26, 2020 at 09:10:33AM +0200, Abdussalam Baryun wrote:
>   The draft should indicated on top first page that it updates RFC6775,
> 7400, and 8505, it only shows updating RFC8505.

The 6775 case was discussed extensively during IESG Evaluation.
Note that 8505 itself Updates 6775, and the changes in this document affect
only what 8505 does (IIRC).  I'm not sure why you want this document to
update 7400 -- it seems to just be allocating some bits from the "6LoWPAN
capability Bits" registry established by 7400.

IMO it updates section 3.4 in RFC7400, it is not only adding bits, it is adding 
the way of using 6CIO, we would not add bits only to add tasks in protocols,

(Well, it would be if the
IANA considerations were updated to state that, at least.)  Allocating bits
from a registry is usually not seen to need an Updates relationship.

yes IMO it should include also the IANA considerations

best regards

AB


-Ben
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] AP-ND 22

[Pascal Thubert (pthubert)]

Ok I’ll keep that.

Many thanks Michael!


Regards,

Pascal

> Le 26 avr. 2020 à 00:43, Michael Richardson  a écrit :
> 
> 
> Pascal Thubert \(pthubert\)  wrote:
>> On the side, It appears that the key representations are typically of
>> length 8n +1. Considering that IPv6 ND aligns its options at 8n bytes,
>> it would make sense to start a byte ahead like this, don't you think?
> 
> I think it's a good idea if the content would otherwise be padding.
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] AP-ND 22

[Pascal Thubert (pthubert)]

On the side, It appears that the key representations are typically of length 8n 
+1. Considering that IPv6 ND aligns its options at 8n bytes, it would make 
sense to start a byte ahead like this, don't you think?

0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type  |Length |Reserved1|  Public Key Length  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Crypto-Type  | Modifier  |  EARO Length  |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +
  |   |
  .   .
  .  Public Key (variable length) .
  .   .
  |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   |
  .   Padding .
  |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: Crypto-ID Parameters Option

From: Pascal Thubert (pthubert)
Sent: vendredi 24 avril 2020 15:54
To: 'Benjamin Kaduk' ; Rene Struik ; 
Mohit Sethi 
Cc: 6lo-cha...@ietf.org; Shwetha Bhandari (shwethab) ; Jim 
Schaad ; Erik Kline ; 6lo@ietf.org
Subject: AP-ND 22

Hello Benjamin (and 6lo)

We are soliciting your help on AP ND for hopefully the last time, about the 
last step, that was supposed to be the IANA section that was missing for JOSE 
and Crypto Type 2.

Rene worked quite a bit with Jim and the conclusion that I made from that is 
that the formats that we already discussed in appendix B (SEC1) were better 
suited than JOSE (or COSE) and avoided both the registry issue and gaps in the 
existing specifications.

We had a conversation yesterday with our AD (Erik) and Shepherd (Shwetha) and 
we agreed to give a try at using those formats for -22. The conclusion that it 
looked OK but we need a validation that the new key and signature formats do 
not alter the security of the spec.

So there we go; 20 being the version that made it through IESG, and 21 the 
increments that you already reviewed and provides encoding agility, please find 
the proposed 22 attached and the diff between the proposed 22 and either 20 or 
21.

The main diffs from 21 are
 - the removal of JWK,
 - a discussion on brown field that basically indicates that a back level 6LR 
constitutes a breach in the perimeter, meaning that all 6LRs need to be 
upgraded.
 - the J flag from 21 is gone, since we dropped JWK and dismissed the idea of 
operating AP ND in a brown field.

Can you please have a look and validate that we did OK?

Many, many thanks for all your help throughout!

Pascal, Rene and Mohit


[cid:image001.png@01D61A53.AE322D20]
Pascal Thubert
PRINCIPAL ENGINEER.ENGINEERING
pthub...@cisco.com<mailto:pthub...@cisco.com>
Tel: +33 49 723 2634
 cisco.com
Cisco Systems, Inc.
45 All Des Ormes Regus Centre
BP1200
06250 MOUGINS CEDEX
France
[cid:image002.gif@01D61A53.AE322D20]
Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here<http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html>
 for Company Registration Information.


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] FW: New Version Notification for draft-ietf-6lo-ap-nd-21.txt

[Pascal Thubert (pthubert)]

Dear WG

We are still fighting with the IANA section but at least fixed the other topics 
that we found working in it, namely:
- use the full CIPO in the signature
- use JWS to encode the signature in the NDPSO
- Extend the 6CIO to expose support of AP-ND by the 6LR using the formats in 
this document (JSON-based)

We'll keep you tuned on the progress on the IANA. Apparently we have 2 choices:
- get the IANA section straight or
- remove Crypto-type 2 for now, reintroduce it later e.g., using René's LWIG 
draft

Please recheck the diffs, this doc is soon in the RFC editor's hand.

Keep safe

Pascal

-Original Message-
From: internet-dra...@ietf.org  
Sent: lundi 20 avril 2020 16:00
To: Pascal Thubert (pthubert) ; Mohit Sethi 
; Rene Struik ; Behcet Sarikaya 

Subject: New Version Notification for draft-ietf-6lo-ap-nd-21.txt


A new version of I-D, draft-ietf-6lo-ap-nd-21.txt has been successfully 
submitted by Pascal Thubert and posted to the IETF repository.

Name:   draft-ietf-6lo-ap-nd
Revision:   21
Title:  Address Protected Neighbor Discovery for Low-power and Lossy 
Networks
Document date:  2020-04-20
Group:  6lo
Pages:  32
URL:https://www.ietf.org/internet-drafts/draft-ietf-6lo-ap-nd-21.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/
Htmlized:   https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-21
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-6lo-ap-nd
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-21

Abstract:
   This document updates the 6LoWPAN Neighbor Discovery (ND) protocol
   defined in RFC 6775 and RFC 8505.  The new extension is called
   Address Protected Neighbor Discovery (AP-ND) and it protects the
   owner of an address against address theft and impersonation attacks
   in a low-power and lossy network (LLN).  Nodes supporting this
   extension compute a cryptographic identifier (Crypto-ID) and use it
   with one or more of their Registered Addresses.  The Crypto-ID
   identifies the owner of the Registered Address and can be used to
   provide proof of ownership of the Registered Addresses.  Once an
   address is registered with the Crypto-ID and a proof-of-ownership is
   provided, only the owner of that address can modify the registration
   information, thereby enforcing Source Address Validation.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

[6lo] Attracting attention on a last minute change in AP-ND

[Pascal Thubert (pthubert)]

Dear WG:

Since we do not meet this IETF, there's no chance to present the proposed 
update to Ap ND in person.
The below changes 2 things in AP ND and asks an additional question.

ADDITIONAL QUESTION:
- The representation of the key is from the JSON space (JWK). Since LLNs are in 
scope, should we all the COSE Key object as an alternative?

CHANGE 1
- The full CIPO is included to the signed material, instead of the tuple ( JWK 
key , crypto ID ) both fields being taken from the CIPO as is in the current 
spec. This is done to enable other formats than JWK in the future by removing 
the term JWK from the text on the signature. Other fields may be added to the 
CIPO in the future, the signature would now protect those automagically. Note 
that this change was already done for the Crypto-ID during Benjamin's review.

CHANGE 2
- We add the way for the 6LR to signal its support JWK encoding. We use only a 
bit and do not advertise the list of Crypto-types that the 6LR supports, 
leaving the 6LN to trial and error, with a fall back to Crypto ID 0 that MUST 
be supported. 

SIDE question

About CHANGE 2, Should we do more? We could at an extreme list the supported 
Crypto IDs, or at the other support only Crypto ID 0 for now.

Please let us know what think, and the rationale associated

Many thanks

Pascal
-Original Message-
From: 6lo <6lo-boun...@ietf.org> On Behalf Of Pascal Thubert (pthubert)
Sent: mercredi 15 avril 2020 14:04
To: Benjamin Kaduk ; 6lo@ietf.org; Mohit Sethi M 
; Rene Struik 
Cc: draft-ietf-6lo-ap...@ietf.org; 6lo-cha...@ietf.org; The IESG 
; Shwetha Bhandari (shwethab) 
Subject: Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with 
DISCUSS and COMMENT)

Hello Benjamin and 6lo:

Just to let you know and the group that we are still chewing the IANA section 
on this draft.
Doing that we found 2 important things.

1) JWK may not be the favored format for the key representation in LLNs (vs... 
COSE's Key Object)
2) We are lacking the signal to tell the 6LN that the 6LR supports AP-ND.

For 1)

We'll poll the list if we can live with JWK only for this version. We have 
prepared candidate text if not.

In the meantime, and to be opened to the future where more key representations 
come in, I believe we should extend a change we made for your review in the 
crypto-id computation and add the whole CIPO to the signed material, as opposed 
to selected fields from the CIPO (JWK-encoded public key and Crypto-Type 
value). Doing that, we'll be able to add different encodings, new flags that 
signal it, and have all that protected in the signature.

The text in "6.2.  NDPSO generation and verification" becomes:
"
*  Concatenate the following in the order listed:

  1.  The 128-bit Message Type tag [RFC3972] (in network byte
  order).  For this specification the tag is 0x8701 55c8 0cca
  dd32 6ab7 e415 f148 84d0.  (The tag value has been generated
  by the editor of this specification on random.org).
  2.  the CIPO
  3.  the 16-byte Target Address (in network byte order) sent in the
  Neighbor Solicitation (NS) message.  It is the address which
  the 6LN is registering with the 6LR and 6LBR.
  4.  NonceLR received from the 6LR (in network byte order) in the
  Neighbor Advertisement (NA) message.  The nonce is at least 6
  bytes long as defined in [RFC3971].
  5.  NonceLN sent from the 6LN (in network byte order).  The nonce
  is at least 6 bytes long as defined in [RFC3971].
  6.  1-byte Option Length of the EARO containing the Crypto-ID.
"
Which is echoed in the signature validation "
it tries to verify the
   signature in the NDPSO option using the following:

   *  Concatenate the following in the order listed:

  1.  The 128-bit Message Type tag specified above (in network byte
  order)
  2.  the CIPO
  3.  the 16-byte Target Address (in network byte order) received in
  the Neighbor Solicitation (NS) message.  It is the address
  which the 6LN is registering with the 6LR and 6LBR.
  4.  NonceLR sent in the Neighbor Advertisement (NA) message.  The
  nonce is at least 6 bytes long as defined in [RFC3971].
  5.  NonceLN received from the 6LN (in network byte order) in the
  NS message.  The nonce is at least 6 bytes long as defined in
  [RFC3971].
  6.  1-byte EARO Length received in the CIPO.
"
Is that OK?

2) is an easy change, we can extend the 6CIO as we do in RFC 8505 already:


"
4.5.  Extensions to the Capability Indication Option

   This specification defines 2 new capability bits in the 6CIO, defined
   by [RFC7400] for use by the 6LR and 6LBR in IPv6 ND RA messages.

   The "A" flag indicates that AP-ND is enabled in the network.  It is
   set by the 6LBR that serves the network and propagated by the 6LRs.

   The "J" flag indicates that the 6L

Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Benjamin and 6lo:

Just to let you know and the group that we are still chewing the IANA section 
on this draft.
Doing that we found 2 important things.

1) JWK may not be the favored format for the key representation in LLNs (vs.. 
COSE's Key Object)
2) We are lacking the signal to tell the 6LN that the 6LR supports AP-ND.

For 1)

We'll poll the list if we can live with JWK only for this version. We have 
prepared candidate text if not.

In the meantime, and to be opened to the future where more key representations 
come in, I believe we should extend a change we made for your review in the 
crypto-id computation and add the whole CIPO to the signed material, as opposed 
to selected fields from the CIPO (JWK-encoded public key and Crypto-Type 
value). Doing that, we'll be able to add different encodings, new flags that 
signal it, and have all that protected in the signature.

The text in "6.2.  NDPSO generation and verification" becomes:
"
*  Concatenate the following in the order listed:

  1.  The 128-bit Message Type tag [RFC3972] (in network byte
  order).  For this specification the tag is 0x8701 55c8 0cca
  dd32 6ab7 e415 f148 84d0.  (The tag value has been generated
  by the editor of this specification on random.org).
  2.  the CIPO
  3.  the 16-byte Target Address (in network byte order) sent in the
  Neighbor Solicitation (NS) message.  It is the address which
  the 6LN is registering with the 6LR and 6LBR.
  4.  NonceLR received from the 6LR (in network byte order) in the
  Neighbor Advertisement (NA) message.  The nonce is at least 6
  bytes long as defined in [RFC3971].
  5.  NonceLN sent from the 6LN (in network byte order).  The nonce
  is at least 6 bytes long as defined in [RFC3971].
  6.  1-byte Option Length of the EARO containing the Crypto-ID.
"
Which is echoed in the signature validation
"
it tries to verify the
   signature in the NDPSO option using the following:

   *  Concatenate the following in the order listed:

  1.  The 128-bit Message Type tag specified above (in network byte
  order)
  2.  the CIPO
  3.  the 16-byte Target Address (in network byte order) received in
  the Neighbor Solicitation (NS) message.  It is the address
  which the 6LN is registering with the 6LR and 6LBR.
  4.  NonceLR sent in the Neighbor Advertisement (NA) message.  The
  nonce is at least 6 bytes long as defined in [RFC3971].
  5.  NonceLN received from the 6LN (in network byte order) in the
  NS message.  The nonce is at least 6 bytes long as defined in
  [RFC3971].
  6.  1-byte EARO Length received in the CIPO.
"
Is that OK?

2) is an easy change, we can extend the 6CIO as we do in RFC 8505 already:


"
4.5.  Extensions to the Capability Indication Option

   This specification defines 2 new capability bits in the 6CIO, defined
   by [RFC7400] for use by the 6LR and 6LBR in IPv6 ND RA messages.

   The "A" flag indicates that AP-ND is enabled in the network.  It is
   set by the 6LBR that serves the network and propagated by the 6LRs.

   The "J" flag indicates that the 6LR supports JWK-encoded keys in the
   CIPO option.


   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type  |   Length = 1  |   Reserved|J|A|D|L|B|P|E|G|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Reserved|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 4: New Capability Bits in the 6CIO

   New Option Fields:

   J:  1-bit flag.  This 6LR supports AP-ND with JWK encoding

   A:  1-bit flag.  This network supports AP-ND
"
And
"
   This specification protects the ownership of the address.  Its use in
   a network is signaled by the 6LBR by setting the 'A' flag in the
   6CIO.  This is echoed by the 6LRs, that also indicate the key
   encoding format that they support in another 6CIO flag, currently the
   'J' flag for JWK.

   When using a ROVR that is a Crypto-ID, a 6LN MUST use a 6LR that
   supports the key encoding used in the CIPO.  If the 6LR does not
   support the Crypto-Type, it MUST reply with an EARO Status 10
   "Validation Failed" without a challenge.  In that case, the 6LN may
   try another Crypto-Type until it falls back to Crypto-Type 0 that
   MUST be supported by all 6LRs.
"

Does that work for you?

You all keep safe;

Pascal



> -Original Message-
> From: Benjamin Kaduk 
> Sent: vendredi 7 février 2020 01:10
> To: Rene Struik 
> Cc: Pascal Thubert (pthubert) ; The IESG
> ; draft-ietf-6lo-ap...@ietf.org; Shwetha Bhanda

Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Aïe, true!

Can we leave it to the RFC editor?

Be safe!

Pascal

> Le 23 mars 2020 à 23:03, Suresh Krishnan  a écrit :
> 
> Hi Pascal,
>  I went through the latest rev and found an off-by-one error on the Fragment 
> size.
> 
> * Section 5.1.
> 
>   Fragment_Size:  10-bit unsigned integer; the size of this fragment in
>  a unit that depends on the Link-Layer technology.  Unless
>  overridden by a more specific specification, that unit is the
>  byte, which allows fragments up to 1024 bytes.
> 
> Shouldn’t this be fragments upto *1023* bytes instead of 1024 bytes?
> 
> Thanks
> Suresh
> 
>> On Mar 23, 2020, at 9:54 AM, Pascal Thubert (pthubert) 
>>  wrote:
>> 
>> Hello Again Mirja : )
>> 
>> 
>>> Thanks for this additional text. I just cleared my discuss.
>> Very cool; again and again, many thanks for your deep reviews.
>> 
>>> 
>>> A couple of nits you/Suresh maybe want to add as RFC editor note:
>> 
>> 
>> Happy to republish:   
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-21 
>> 
>>> 
>>> OLD
>>> Note that the action upon detecting a congestion only applies till the end 
>>> of
>>> the datagram 
>>> NEW Note that the action upon detecting congestion only
>>> applies till the end of the datagram.
>>> MAYBE EVEN
>>> Note that any action that has been performed upon detection of congestion
>>> only applies for the transmission of one datagram
>> 
>> Picked the latter
>> 
>>> 
>>> OLD
>>> an inter-frame gap can be as a flow control or a congestion control measure
>>> NEW The inter-frame gap can be used as a flow control or a congestion
>>> control measure
>> 
>> done
>> 
>>> OLD
>>> a conservative Window_Size of, say, 3, will be the gating factor that 
>>> starves
>>> the sender 
>>> MAYBE a conservative Window_Size of, say, 3, will be the gating
>>> factor that limits the transmission rate of the sender
>>> 
>> 
>> 
>> Again and again, many thanks;
>> all the best with the IAB,
>> 
>> Pascal
>> 
> 
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Again Mirja : )


> Thanks for this additional text. I just cleared my discuss.
Very cool; again and again, many thanks for your deep reviews.

> 
> A couple of nits you/Suresh maybe want to add as RFC editor note:


Happy to republish:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-21 

> 
> OLD
> Note that the action upon detecting a congestion only applies till the end of
> the datagram 
> NEW Note that the action upon detecting congestion only
> applies till the end of the datagram.
> MAYBE EVEN
> Note that any action that has been performed upon detection of congestion
> only applies for the transmission of one datagram

Picked the latter

> 
> OLD
> an inter-frame gap can be as a flow control or a congestion control measure
> NEW The inter-frame gap can be used as a flow control or a congestion
> control measure

done

> OLD
> a conservative Window_Size of, say, 3, will be the gating factor that starves
> the sender 
> MAYBE a conservative Window_Size of, say, 3, will be the gating
> factor that limits the transmission rate of the sender
> 


Again and again, many thanks;
all the best with the IAB,

Pascal

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

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

[Pascal Thubert (pthubert)]

Hello again, Benjamin

> > Again and again, many thanks for your arch-fantastic reviews!


> > "
> >   Each Backbone Router (6BBR) maintains a data structure for its
> >Registered Addresses called a Binding Table.  The abstract data that
> >is stored in the Binding Table includes the Registered Address,
> >anchor information on the Registering Node such as connecting
> >interface, Link-Local Address and Link-Layer Address of the
> >Registering Node on that interface, the EARO including ROVR and TID,
> >a state that can be either REACHABLE, TENTATIVE, or STALE, and other
> >information such as a trust level that may be configured, e.g., to
> >protect a server.  The combined Binding Tables of all the 6BBRs on a
> >backbone form a distributed database of 6LNs that reside in the LLNs
> >or on the IPv6 Backbone.
> > "
> 
> This is nice!  I am still not sure about how much a deployment needs to care
> about concurrency and/or consistency issues for the "distributed database";
> given that lossy radio technologies are involved I mostly assume that things
> will be self-healing in the face of a bit of delayed update propagation, but 
> it
> would be nice to have that confirmed.

To do care and this is why we have the ROVR and the TID included in the 
exchange on the backbone.
The point is to ensure that the database is maintained up to date with the 
right state at the right place.
This db becomes a core functionality for a modern switch and router as it is 
the point where the hosts are observed.
This is injected in many features, such as LISP MS/MR, SD-stuff, network 
management and security tools.




> > > Section 9
> > >
> > >even for a duplicate address.  Consequently, and unless
> > >administratively overridden, the 6BBR still needs to perform IPv6 ND
> > >DAD over the backbone after an EDAC with a status code of 0 or 9.
> > >
> > > I'd be curious to see a pointer to the discussions that caused
> > > "unless administratively overridden" to be introduced, as naively
> > > that note does not seem necessary.
> >
> > The idea behind it is that if all nodes register to the 6LBR then the DAD 
> > can
> be avoided.
> > But the only way to know is administrative. I wanted to leave that door
> open. But I guess it is implicitly.
> > Removed the text.
> >
> > >
> > >If a registration is received for an existing Binding with a non-null
> > >Registration Lifetime and the registration is fresher (same ROVR,
> > >fresher TID), then the Binding is updated, with the new Registration
> > >Lifetime, TID, and possibly Registering Node.  In Tentative state
> > >(see Section 9.1), the current DAD operation continues unaltered.  In
> > >other states (see Section 9.2 and Section 9.3 ), the Binding is
> > >placed in Reachable state for the Registration Lifetime, and the 6BBR
> > >returns an NA(EARO) to the Registering Node with a status of 0
> > >(Success).
> > >
> > > Does this mean we don't re-do DAD for registrations already in a
> > > Stale state when we receive an updated registration for them?
> >
> > Correct. If a sign of reuse of the address had been seen the Binding would
> have been removed in 9.3. That's the point actually of keeping the address in
> Stale state.
> 
> I guess I wasn't sure if those mechanisms would be 100% reliable to avoid two
> nodes thinking they have the same address, but it's been too long since I
> wrote this for me to be sure what I was thinking.  If you say they are 100%
> reliable, that is good enough for me.

Classical IPv6 ND DAD is NOT 100% reliable. It is in fact very unreliable on 
large wireless deployments.
Anything that happens on the backbone that is based on multicast may have 
misses. 
What makes IPv6 work is that the collisions actually do not happen with 
pseudo-random, crypto-based or MAC-seeded IIDs.
The next spec on having a 6LBR on the backbone will make it reliable, provided 
that the 6LBR itself is. But getting 6MAN to endorse it will be an interesting 
time, help appreciated.



> > >
> > > It might be worth a brief preface that since we're modifying the ND
> > > and DAD processes, the attacks in scope are basically limited to
> > > blocking discovery of taking over addresses from other nodes (which,
> > > to be fair, can in some cases have substantial consequences in terms of
> reading the "stolen" traffic!).
> >
> > Argl, I cannot parse that. Would you kindly suggest text?
> 
> I was thinking something like:
> 
>   The procedures in this document modify the mechanisms used for IPv6 ND
>   and DAD and should not affect other aspects of IPv6 or
>   higher-level-protocol operation.  As such, the main classes of attacks
>   that are in play are those which week to block neighbor discovery or to
>   forcibly claim an address that another node is attempting to use.  In the
>   absence of cryptographic protection at higher layers, the latter class of
>   attacks can have significant 

Re: [6lo] Roman Danyliw's Discuss on draft-ietf-6lo-backbone-router-16: (with DISCUSS)

[Pascal Thubert (pthubert)]

Hello again Benjamin:

Just to make sure you're kept busy ; )

> > Proposed changes in 3.5.  Primary and Secondary 6BBRs
> >
> > "
> >A Registering Node MAY register the same address to more than one
> >6BBR, in which case the Registering Node uses the same EARO in all
> >the parallel registrations.  On the other hand, there is no provision
> >in 6LoWPAN ND for a 6LN (acting as Registered Node) to select its
> 
> I'm assuming that "6LoWPAN ND" here means "stuff currently published as
> RFCs, excluding this document, AP-ND, etc."

That is correct in -20 but AP-ND does not either. 

In the terminology section (2.4) we say


   6LoWPAN ND:  Neighbor Discovery Optimization for Low-Power and Lossy
  Networks [RFC6775] and "Registration Extensions for 6LoWPAN
  Neighbor Discovery" [RFC8505].

But then, I believe that it should include AP-ND.
Note that both this are in C310, held by the same docs

"
   6LoWPAN ND:  Neighbor Discovery Optimization for Low-Power and Lossy
  Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor
  Discovery" [RFC8505], and " Address Protected Neighbor Discovery
  for Low-power and Lossy Networks" [I-D.ietf-6lo-ap-nd].
"
Note that AP-ND is mentioned several times later;  Is that OK? (more below)


> 
> >6LBR (acting as Registering Node), so it cannot select more than one
> >either.  To allow for this, ND(DAD) and NA messages with an EARO
> > that
> 
> (in particular with respect to "cannot select more than one".)

I guess you're confused between 6LR and 6LBR. The 6LN can attached to multiple 
6LRs but it is the 6LRs that select the 6LBR, not the 6LN.

Are we in sync?


> > 11.  Security Considerations
> >
> >This specification applies to LLNs and a backbone in which the
> >individual links are protected against rogue access, by
> >authenticating a node that attaches to the network and encrypting at
> >the MAC layer the transmissions so packets may neither be overheard
> >or nor forged.  In particular, the LLN MAC is required to provide
> 
> I think that the "authenticating a node that attaches [...]" is meant to 
> apply to
> the LLN links, and perhaps the backbone provides the protection against rogue
> access by physical access protection?  Maybe we need two clauses after the
> comma, e.g., "on the LLN by [...], and on the backbone by [...]".

Yes, as discussed in the next block, the attacks on the backbone are a lot 
easier if backwards compatibility has to be maintained. There's the discussion 
on who should win when a legacy fights with an LLN node, the current text has 
the legacy win to enable a smooth incremental deployment.

Proposed change:
"
  This specification applies to LLNs and a backbone in which the
   individual links are protected against rogue access, on the LLN by
   authenticating a node that attaches to the network and encrypting at
   the MAC layer the transmissions, and on the backbone side using the
   physical security and access control measures that are typically
   applied there, so packets may neither be overheard or nor forged.

"


> 
> >If the classical ND is disabled on the backbone and the use of
> >[I-D.ietf-6lo-ap-nd] and a 6LBR are mandated, the network will
> >benefit from the following new advantages:
> >
> >Zero-trust security for ND flows within the whole subnet:  the
> 
> (I'm tempted to try to work "non-router" in here somehow, but not sure it's
> worth the effort.)

Sorry I'm not sure I see the point. The duplication may be with a router.

More answering your own review 

Pascal
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Benjamin Kaduk's No Objection on draft-ietf-6lo-minimal-fragment-14: (with COMMENT)

[Pascal Thubert (pthubert)]

Hello again Benjamin:

I published -15 
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-minimal-fragment-15 with the 
changes.
I kept the Datagram_Tag uppercased but we can debate that with the RFC editor. 
The lowercase is used in RFC 4944.

Looking at the diffs, I found that I forgot to remove the old version of the 
text you changed, it is now removed in github.

Again, a great many thanks!!

I guess we're done with both fragment drafts : )

Keep safe,

Pascal

> -Original Message-
> From: Benjamin Kaduk via Datatracker 
> Sent: dimanche 22 mars 2020 00:39
> To: The IESG 
> Cc: draft-ietf-6lo-minimal-fragm...@ietf.org; 6lo-cha...@ietf.org;
> 6lo@ietf.org; Carles Gomez ;
> carle...@entel.upc.edu
> Subject: Benjamin Kaduk's No Objection on draft-ietf-6lo-minimal-fragment-14:
> (with COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-6lo-minimal-fragment-14: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-minimal-fragment/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for addressing my Discuss (and Comment) points!
> 
> In the security considerations, perhaps "fragment 1" would be better as 
> "first-
> fragment" to avoid questions of zero- vs. one-indexing.
> 
> 
I changed the intro to add " of the datagram" to define it more clearly in the 
first use:
 "
The routing decision is made on the first
   fragment of the datagram,

" 
and checked it is aligned the use of "first fragment" throughout.

The particular sentence you point out could become
"
The length of the packet is indicated in each fragment (the Datagram_Size 
field), so node B can allocate the buffer even if the fragment it receives 
first is not the first fragment.
"
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-minimal-fragment-12: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Benjamin:

Let's go then!

> >
> > So I suggest 'typically' instead of "if needed":
> > "
> >Typically, Node A starts with an uncompressed packet and compacts the
> >IPv6 packet using the header compression mechanism defined in
> >[RFC6282].
> > "
> 
> That seems reasonable.  IIRC, my understanding at the time was that this
> scenario would only arise when fragmentation was performed at a different
> node than the original sender of the IP packet, which I expect to be rare in
> homogeneous LPWANs.

Sorry I confused you. For a packet sourced in the Internet, the border router 
does the compression at the ingress of the 6LoWPAN network. So it is not the 
original sender. But it is both the 6LoWPAN endpoint and the fragmenting 
endpoint.




> > I would have appreciated a suggestion here : ) does this work?
> > "
> >*  Attacks based on predictable fragment identification values are
> >   also possible but can be avoided.  The datagram_tag SHOULD be
> >   assigned pseudo-randomly in order to defeat such attacks.  A
> >   larger size of the datagram_tag makes the guessing more difficult
> >   and reduces the chances of an accidental reuse while the original
> >   packet is still in flight, at the expense of more space in each
> >   frame.
> > "
> 
> Hmm, talking about a "larger size of the datagram_tag" (or wait, did we end up
> at "Datagram_Tag"?) feels odd since this document has fixed it at 16 bits.

Hum, not this doc but RFC 4944 which is described page 6. 
"
Section 5.3 of
   [RFC4944] defines the format of the header for the first and
   subsequent fragments.  All fragments are tagged with a 16-bit
   "Datagram_Tag", used to identify which packet each fragment belongs
"
This doc does not impose anything per se, e.g. fragment recovery inherits from 
this but uses a smaller tag.


> Maybe:
> 
>*  Attacks based on predictable fragment identification values are
>   also possible but can be avoided.  The datagram_tag SHOULD be
>   assigned pseudo-randomly in order to reduce the risk of such attacks.
>   Nonetheless, some level of risk remains that an attacker able to
>   authenticate to and send traffic on the network can guess a valid
>   Datagram_Tag value, since there are only 2^16 possible values.

Nice, I'd just change " only 2^16" with " a limited number of" to keep it 
generic

I'm continuing with your other mails based on -14.

Keep safe;

Pascal


___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Roman Danyliw's Discuss on draft-ietf-6lo-backbone-router-16: (with DISCUSS)

[Pascal Thubert (pthubert)]

Many thanks Roman!

> -Original Message-
> From: Roman Danyliw 
> Sent: dimanche 22 mars 2020 02:00
> To: Pascal Thubert (pthubert) ; The IESG
> ; Benjamin Kaduk 
> Cc: draft-ietf-6lo-backbone-rou...@ietf.org; Carles Gomez
> ; Samita Chakrabarti ;
> Shwetha Bhandari (shwethab) ; 6lo-cha...@ietf.org;
> 6lo@ietf.org
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-6lo-backbone-router-16:
> (with DISCUSS)
> 
> Hi Pascal!
> 
> The new language in -19 looks good to me and addresses my feedback.  Thanks
> for making these updates.
> 
> Roman
> 
> -Original Message-
> From: Pascal Thubert (pthubert) 
> Sent: Tuesday, March 3, 2020 11:03 AM
> To: Roman Danyliw ; The IESG ; Benjamin Kaduk
> 
> Cc: draft-ietf-6lo-backbone-rou...@ietf.org; Carles Gomez
> ; Samita Chakrabarti ;
> Shwetha Bhandari (shwethab) ; 6lo-cha...@ietf.org;
> 6lo@ietf.org
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-6lo-backbone-router-16:
> (with DISCUSS)
> 
> Dear Roman and Benjamin
> 
> Many thanks for your reviews!
> 
> I took the liberty to merge your comments on section 11 in a single thread,
> since they have commonalities.
> Also, I'll try to answer the questions with my own words as they come, and
> then propose a global change to section 11 at the end of the email.
> The overall changes are posted as -1ç but you may use the copied text below to
> propose amendments / additions, I hope that all works for you.
> 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-backbone-router-19
> 
> 
> Please see below:
> 
> >
> > --
> > DISCUSS (Roman):
> > --
> >
> > Section 11.  Can assumptions of the about the security properties of
> > the links be clarified.
> >
> > This specification applies to LLNs and a backbone in which the
> >individual links are protected against rogue access, e.g., by
> >authenticating a node that attaches to the network and encrypting at
> >the MAC layer the transmissions that may be overheard.  In
> >particular, the LLN MAC is required to provide secure unicast to/from
> >the Backbone Router and secure Broadcast from the Backbone Router in
> >a way that prevents tampering with or replaying the RA messages.
> >
> > -- what are the specific assumptions about the protections that will
> > be on the link.  Is the list of properties in the “e.g.” the full list?
> 
> For all I know it is the full list, let me remove the "e.g.,".
> 
> Compiling this question with Benjamin's below I'd say that this work inherits
> from ND, which allows any node that can access the link to do anything,
> appear as a router,  source traffic and attract traffic. ND can also be used 
> to
> DoS a network from a remote node by sending high volumes of packets, each
> to a different forged address, and each causing a temp state in the router 
> and a
> broadcast on the fabric.
> 
> We interwork with that on the backbone, and the draft gives precedence to the
> legacy operation, meaning that a node that can attack ND can attack us in the
> exact same way.
> 
> I can add words to say that. RFC 4861 section 11.1 tells us to "keep the bad
> guys out or all bets are off", IOW, Woodstock. Section 11.2 has the hopeful
> thinking that SeND will be deployed, and we know it will not happen. For info,
> this only implementation that shipped that I'm aware of is the router side by
> our co-author Eric in Cisco's IOS. We are well placed to know it's doomed and
> very motivated to give another chance to securing ND. Which lead us to AP-
> ND.
> And since ND does nothing for that, it means "do not let the bad guys access
> the network at L2" and "do not let the bad guys compromise any system on the
> network". I will not even try the Woodstock analogy there.
> 
> What changes:
> - nodes that are attached to the LLN cannot attack that easily (if AP-ND is
> enforced)
> - we have nodes that are more sensitive than others (the 6BBR and 6LBR are
> new targets that can impact many nodes, note that the default router already
> was one, and anybody could impersonate it).
> - when a policy enforces AP-ND to all nodes including the backbone then :
> * the increased security that we have on the LLN will also apply to the
> backbone (no impersonation or stealing address)
> * the complete list of addresses n the network will be known to the 
> default
> router which will block the remote DoS attacks
> * DAD and Lookups will be fast and without multicast, which again will 

Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Mirja:

I published 20 with this addition.

https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-20

I guess we're close to be done by now. In that case, I must thanks you again 
and deeply.

Be safe,

Pascal



> -Original Message-
> From: Mirja Kuehlewind 
> Sent: vendredi 20 mars 2020 18:12
> To: Pascal Thubert (pthubert) 
> Cc: 6lo-cha...@ietf.org; The IESG ; 6lo@ietf.org; 
> draft-ietf-6lo-
> fragment-recov...@ietf.org; Carles Gomez ; Martin
> Duke ; Benjamin Kaduk 
> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13:
> (with DISCUSS and COMMENT)
> 
> Hi Pascal,
> 
> The proposed text below and in your previous email look good! Thanks!
> 
> I would appreciate and recommend to add also a shorter version of your good
> explanation below to make the reader better understand which factor is the
> limiting one when using a certain parameter setting and respectively which
> factor could be tuned if any dynamic adaptation is implemented.
> 
> Thanks!
> Mirja
> 
> P.S.: Off for today but will check for an update tomorrow in order to clear my
> discuss!
> 
> 
> 
> > On 20. Mar 2020, at 17:15, Pascal Thubert (pthubert)
>  wrote:
> >
> > Hello Mirja
> >
> > I missed this while working on yesterday's message.
> >
> > Let's see below:
> >
> >
> >> Okay! :-)
> >>
> >> About the use of ECN, I agree as you say there should only be a few
> >> fragments and not increasing might be okay. However, you would need
> >> to clarify that the window is reset for each new datagram, I guess, right?
> >
> > Agreed. Let's change appendix C, more below;
> >
> >> Also I don’t think you
> >> necessarily need to reduce to 1 on CE marking but maybe halve the
> >> window or something. Or you leave this open like “If an E flag is
> >> received the window SHOULD be reduced, at least by 1 and at max to 1.
> >> Halving the window for each E flag received, could be a good
> >> compromise but needs further experimentation.”…
> >
> > Thanks for this text! Appendix C now becomes:
> > "
> >   Congestion on the forward path can also be indicated by an Explicit
> >   Congestion Notification (ECN) mechanism.  Though whether and how ECN
> >   [RFC3168] is carried out over the LoWPAN is out of scope, this draft
> >   provides a way for the destination endpoint to echo an ECN indication
> >   back to the fragmenting endpoint in an acknowledgment message as
> >   represented in Figure 4 in Section 5.2.  While the support of echoing
> >   the ECN at the reassembling endpoint is mandatory, this specification
> >   only provides a minimalistic behaviour on the fragmenting endpoint.
> >   If an E flag is received the window SHOULD be reduced, at least by 1
> >   and at max to 1.  Halving the window for each E flag received, could
> >   be a good compromise but needs further experimentation.  A very
> >   simple implementation may just reset the window to 1 so the fragments
> >   are sent and acknowledged one by one.  Note that the action on ECN
> >   only applies till the end of the datagram and the next datagram uses
> >   the configured Window_Size again.
> >
> > "
> >
> > I'd like to fully converge before I publish again
> >
> >> I wonder if it would be good to say a bit more about the recommended
> >> values for the window size, as I think 32 will usually in most
> >> network not limit transmission (and the limiting value will be IFG)
> >> while with a size of 3, that's very conservative to not overload the
> >> network (and will be slow than the limits induced by IFG). Is my
> understanding correct?
> >
> > I'd believe so:
> >
> > Note that the exact use of the ack and the window_size is left to
> implementation. The optimistic one could send all the fragments up to
> window_size and ask for an ack only on the last one, wait for the bitmap, 
> which
> means a gap of RTT/2, and resend the losses.
> > Then again we want to leave room for learning. The pessimistic
> implementation could set the bit on the first fragment to check that the path
> works and open the window only upon receiving the ack. It could then set an
> ack bit again on the second fragment and then use the window as a credit to
> send up to window_size before it is blocked. In that case, if the ack comes 
> back
> before the window starves, the gating factor is the IFG. If the ack does not
> arrive in time, the window_size is the gating factor.
> >
> > If the sender uses the window_size as a credit, t

Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Mirja

I missed this while working on yesterday's message.

Let's see below:


> Okay! :-)
> 
> About the use of ECN, I agree as you say there should only be a few fragments
> and not increasing might be okay. However, you would need to clarify that the
> window is reset for each new datagram, I guess, right? 

Agreed. Let's change appendix C, more below;

> Also I don’t think you
> necessarily need to reduce to 1 on CE marking but maybe halve the window or
> something. Or you leave this open like “If an E flag is received the window
> SHOULD be reduced, at least by 1 and at max to 1. Halving the window for
> each E flag received, could be a good compromise but needs further
> experimentation.”…

Thanks for this text! Appendix C now becomes:
"
   Congestion on the forward path can also be indicated by an Explicit
   Congestion Notification (ECN) mechanism.  Though whether and how ECN
   [RFC3168] is carried out over the LoWPAN is out of scope, this draft
   provides a way for the destination endpoint to echo an ECN indication
   back to the fragmenting endpoint in an acknowledgment message as
   represented in Figure 4 in Section 5.2.  While the support of echoing
   the ECN at the reassembling endpoint is mandatory, this specification
   only provides a minimalistic behaviour on the fragmenting endpoint.
   If an E flag is received the window SHOULD be reduced, at least by 1
   and at max to 1.  Halving the window for each E flag received, could
   be a good compromise but needs further experimentation.  A very
   simple implementation may just reset the window to 1 so the fragments
   are sent and acknowledged one by one.  Note that the action on ECN
   only applies till the end of the datagram and the next datagram uses
   the configured Window_Size again.

"

I'd like to fully converge before I publish again

> I wonder if it would be good to say a bit more about the recommended values
> for the window size, as I think 32 will usually in most network not limit
> transmission (and the limiting value will be IFG) while with a size of 3, 
> that's
> very conservative to not overload the network (and will be slow than the 
> limits
> induced by IFG). Is my understanding correct?

I'd believe so:

Note that the exact use of the ack and the window_size is left to 
implementation. The optimistic one could send all the fragments up to 
window_size and ask for an ack only on the last one, wait for the bitmap, which 
means a gap of RTT/2, and resend the losses.
Then again we want to leave room for learning. The pessimistic implementation 
could set the bit on the first fragment to check that the path works and open 
the window only upon receiving the ack. It could then set an ack bit again on 
the second fragment and then use the window as a credit to send up to 
window_size before it is blocked. In that case, if the ack comes back before 
the window starves, the gating factor is the IFG. If the ack does not arrive in 
time, the window_size is the gating factor.

If the sender uses the window_size as a credit, the window of 3 will be the 
gating factor that starves the sender and causes gaps longer than IFG as soon 
as you have more than 3 hops in a TSCH network and 5-6 hops in a single 
frequency mesh. I guess that's what you mean by slower. The more hops the more 
it will hurt.

I initially used nb_of_hops as a rule of a thumb. That was an approximation of 
RTT/(XMIT+IFG) in the case one fragment needs to progress only to the second 
hop before the next can be sent (case of TSCH). 

The assumptions behind are that an rfrag_ack takes the same path and the same 
time as the rfrag, which is mostly correct. So if we spread the fragments with 
IFG, keeping busy one hop out of 2 on both directions means aligning the 
window_size of the nb of hops. As you pointed out this is not a congestion 
control measure, it is just the window that is not "slower" than IFG, per your 
expression. The text that uses RTT/(XMIT+IFG) being equivalent I'm happy either 
way. Because knowing the RTT is the same problem as knowing the number of hops 
so we do not need to indicate both. 

3 is when you h ave no idea of either RTT or nb of hops. it is conservative and 
will starve the TSCH sender if we have more than 3 hops. It also protects the 
intermediate node that can be very constrained, to at most 3 fragments per 
datagram that it relays. Note that I'm not aware of any full duplex radio 
available in LLNs (though there are prototypes for 5G). So this is really a 
corner case.

As written 32 indicates the last fragment of the datagram, which is usually way 
less than 32. When used, as you understood well, the only protection is IFG, 
and I'm must say I'm quite happy with the progress we made on that text 
together.

Please let me know, should I change something more?

Pascal

___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo

Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Mirja:

Continuing from yesterday night.

I published 18 and then 19 for this discussion. 

So the total diff is 
https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-6lo-fragment-recovery-17.txt=https://tools.ietf.org/id/draft-ietf-6lo-fragment-recovery-19.txt
 

Based on the discussion below, 7.1 would become:

"
7.1.  Protocol Parameters

   The management system SHOULD be capable of providing the parameters
   listed in this section and an implementation MUST abide by those
   parameters and in particular never exceed the minimum and maximum
   configured boundaries.

   An implementation should consider the generic recommendations from
   the IETF in the matter of congestion control and rate management for
   IP datagrams in [RFC8085].  An implementation may perform a
   congestion control by using a dynamic value of the window size
   (Window_Size), adapting the fragment size (Fragment_Size), and may
   reduce the load by inserting an inter-frame gap that is longer than
   necessary.  In a large network where nodes contend for the bandwidth,
   a larger Fragment_Size consumes less bandwidth but also reduces
   fluidity and incurs higher chances of loss in transmission.

   This is controlled by the following parameters:

   inter-frame gap:  The inter-frame gap indicates the minimum amount of
  time between transmissions.  The inter-frame gap controls the rate
  at which fragments are sent, the ratio of air time, and the amount
  of memory in intermediate nodes that a particular datagram will
  use.  It can be used as a flow control, a congestion control, and/
  or a collision control measure.  It MUST be set at a minimum to a
  value that protects the propagation of one transmission against
  collision with next [FRAG-FWD].  In a wireless network that uses
  the same frequency along a path, this may represent the time for a
  frame to progress over multiple hops (more in Section 4.2).  It
  SHOULD be augmented beyond this as necessary to protect the
  network against congestion.
"

Where section 4.2 is where we indicate that the IFG is 
"inserted  between transmissions to the same next hop"




> -Original Message-
> From: Pascal Thubert (pthubert)
> Sent: jeudi 19 mars 2020 20:12
> To: Mirja Kuehlewind 
> Cc: Pascal Thubert (pthubert) ; 6lo-
> cha...@ietf.org; The IESG ; 6lo@ietf.org; draft-ietf-6lo-
> fragment-recov...@ietf.org; Carles Gomez ; Martin
> Duke ; Benjamin Kaduk 
> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13:
> (with DISCUSS and COMMENT)
> 
> Hello Mirja
> 
> 
> 
> >
> >>
> >>
> >> Please see below the discussion:
> >>
> >>>>> --
> >>>>> ---
> >>>>> -
> >>>>> DISCUSS:
> >>>>> -
> >
> >>
> >> Note that all classical wireless interfaces perform ARQ. On one hop, you 
> >> get
> the same effect of multiplying the traffic in the air vs. what the transport 
> see.
> The factor can be high, e.g., 64. On a mesh, we get the additional effect of
> multiple flows converging on a same node.
> >
> > Yes but with only “one hop”/the network you are connected to directly, and
> there is usually also some kind of back-off mechanism that reacts to
> congestion/collision/contention on that layer.
> >
> >
> >>
> >>>
> >>> To be clear the request of this discuss is to give a normative
> >>> recommendation for the default value of the window size and/or inter-
> frame gap.
> >>
> >> Yes, and since there is no great expectation that ECN will be implemented,
> that must be reasonable.
> >> Also we want to agree on the proposed mechanism to drop the window to 1
> in case of congestion notification, or is that behind us already?
> >
> > Dropping to 1 on CE mark is fine. However, when do you increase the window
> again? If you want to say something here, you have to specify that as well.
> 
> 
> If we keep things really simple it would not. Note that this applies to a 
> single
> data gram and that’s usually just a few fragments.
> 
> We could double at each round trip but by the time it takes effect the
> datagram will be done...
> 
> >
> >>
> >>
> >>>
> >>> Further note, as you allow to adapt both the window and the
> >>> inter-frame gap dynamically, you actually implement two control
> >>> mechanisms here. I actually recommend to only use the inter-frame
> >>> gap and don’t have window here. You say a couple

Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Mirja



> 
>> 
>> 
>> Please see below the discussion:
>> 
> -
> -
> DISCUSS:
> -
> 
>> 
>> Note that all classical wireless interfaces perform ARQ. On one hop, you get 
>> the same effect of multiplying the traffic in the air vs. what the transport 
>> see. The factor can be high, e.g., 64. On a mesh, we get the additional 
>> effect of multiple flows converging on a same node.
> 
> Yes but with only “one hop”/the network you are connected to directly, and 
> there is usually also some kind of back-off mechanism that reacts to 
> congestion/collision/contention on that layer.
> 
> 
>> 
>>> 
>>> To be clear the request of this discuss is to give a normative 
>>> recommendation
>>> for the default value of the window size and/or inter-frame gap.
>> 
>> Yes, and since there is no great expectation that ECN will be implemented, 
>> that must be reasonable.
>> Also we want to agree on the proposed mechanism to drop the window to 1 in 
>> case of congestion notification, or is that behind us already?
> 
> Dropping to 1 on CE mark is fine. However, when do you increase the window 
> again? If you want to say something here, you have to specify that as well.


If we keep things really simple it would not. Note that this applies to a 
single data gram and that’s usually just a few fragments.

We could double at each round trip but by the time it takes effect the datagram 
will be done...

> 
>> 
>> 
>>> 
>>> Further note, as you allow to adapt both the window and the inter-frame gap
>>> dynamically, you actually implement two control mechanisms here. I actually
>>> recommend to only use the inter-frame gap and don’t have window here. You
>>> say a couple of times in your reply below, that the window determines the 
>>> ask-
>>> rate, however, it is not clear to me because the ack rate should be a 
>>> parameter
>>> at the receiver and not at the sender (maybe I don’t remember things 
>>> correctly
>>> because it’s a while back since I read the draft and I couple find anything 
>>> about
>>> this in the draft quickly). If the window size however does define the ack 
>>> rate,
>>> then maybe you should rename that parameter respectively.
>> 
>> The ack is not for flow control (as we do not have it) but in support of 
>> ARQ. The possibility to use it for congestion control is a desirable side 
>> effect. The fragmenting endpoint FSM may want to wait and see how things 
>> went for the fragments that it already sent. E.g., there's the case where 
>> the fragmenting endpoint would use an ack on the first fragment for  a 
>> number of reasons such as check that a path is available, that the MTU is OK 
>> or assess an initial RTT. It may maximize the number of fragments in flight 
>> for congestion control. But whether to do any of that is left to 
>> implementation (so far).
>> 
>> 
>>> 
>>> However, if there is really a need for a window, I still recommend to talk 
>>> less
>>> about adapting this value dynamically and make clear that having a fixed 
>>> value
>>> is the recommended default. Therefore I recommend to remove the parameter
>>> MinWindowSize and MaxWindowSize because these should actually not be
>>> parameters than can be configured but are actual bounds. If someone decides
>>> to implement dynamic window adaption, they can decide to re-introduce these
>>> parameter again and make them configurable but it doesn’t need to be part of
>>> this spec.
>> 
>> I can see that, yes. I still like the idea to drop to 1 in case of ECN. 
>> Do you suggest to remove that as well?
>> If so, should we augment the inter-frame gap in case of ECN? 
>> That may be better though not simpler to specify or implement.
> 
> That’s an option as well. Again when you reduce something you might as well 
> need to specify when to increase it again and that means you are specifying 
> basically a congestion control scheme.

My goal for this doc was to keep it dead simple, build it so we have the 
necessary basis with ecn and windowing, and then play with it and learn from 
it. only then we can do a valuable spec.

can we keep it at what the doc has now?
> 
>> 
>> 
>> 
>>> 
>>> So it could be something like:
>>> 
>>> "Window_Size:  Window_Size MUST be at least 1 and less than 33. If the 
>>> inter-
>>> frame gap is selected large enough to not overload the path and the one-way
>> 
>> I see the IFG as more efficient for flow control than for congestion 
>> control: Increasing IFG slows down the packets but as long as the result is 
>> faster than the bottleneck, it does not help much does it? So I'm still  
>> unsatisfied on how to characterize an IFG that does not overload a path. But 
>> I'm not sure we can do better. I moved that piece to the IFG definition if 
>> that's OK?
> 
> So how do you currently set the IFG? Both IFG and window_size can be used for 
> both flow as well as congestion control, it 

Re: [6lo] Mirja Kühlewind's Discuss on draft-ietf-6lo-fragment-recovery-13: (with DISCUSS and COMMENT)

[Pascal Thubert (pthubert)]

Hello Mirja

> Thanks for you updates. Sorry for my late reply. I unfortunately have some
> more comments. Please see below.

More comments => more thanks, you'll have to live with it 

As usual I published for your convenience so you can observe the global effect 
of your review.
Please see 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-18.txt 
(and as usual also I found a typo there that I fixed, this time the duplication 
of "reduce the")

Please see below the discussion:

> >> -
> >> -
> >> DISCUSS:
> >> -


> > 4.3.  Flow Control
> >
> >   The inter-frame gap is the only protection that [FRAG-FWD] imposes by
> >   default.  This document enables to group fragments in windows and
> >   request intermediate acknowledgements so the number of in-flight
> >   fragments can be bounded.  This document also adds an ECN mechanism
> >   that can be used to adapt the size of the window, the size of the
> >   fragments, and/or the inter-frame gap to protect the network.
> >
> >   This specification enables the source endpoint to apply a flow
> >   control mechanism to tune those parameters, but the mechanism itself
> >   is out of scope.  In most cases, the expectation is that most
> >   datagrams will represent only a few fragments, and that only the last
> >   fragment will be acknowledged.  A basic implementation of the source
> >   endpoint is NOT REQUIRED to variate the size of the window, the
> >   duration of the inter-frame gap or the size of a fragment in the
> >   middle of the transmission of a datagram, and it MAY ignore the ECN
> >   signal or simply reset the window to 1 (see Appendix C for more) till
> >   the end of this datagram upon detecting a congestion.
> >
> >   The size of the fragments is typically computed from the Link MTU to
> >   maximize the size of the resulting frames.  The size of the window
> >   and the duration of the inter-frame gap SHOULD be configurable, to
> >   roughly adapt the size of the window to the number of hops in an
> >   average path, and to follow the general recommendations in
> >   [FRAG-FWD], respectively.
> > “
> >
> Thanks for adding this. However, as I said a couple of times in my discuss 
> there
> must be more guidance. This is not only about flow control but also about
> congestion control and it is not okay to declare congestion control out of
> scope. If you only do fragmentation but no retransmission, you don’t need to
> care about congestion control (but only flow control) as you don’t increase 
> the
> actual network load by this. However, if you retransmit you are sending more
> data than the original sender (that hopefully is congestion controlled) and
> therefore you increase the load on the network and you MUST implement your
> own congestion control or some fixed rate limiting for that additional load.
> Saying this is out of scope and you want to do experimentation is not
> acceptable for a Proposed Standard.

I agree. I should be a lot more careful with my wording. 

Understanding that the flow control is pacing from the receiver to protect the 
receiver and congestion control is protecting the network (ECN etc...); stricto 
sensu  we are not doing any flow control since the receiver is expected to have 
a buffer for the whole datagram and he does not need to be protected. All we do 
is congestion control.

=> I should change "flow control" to "congestion control" throughout, and add 
text about the above, is that correct?

Note that all classical wireless interfaces perform ARQ. On one hop, you get 
the same effect of multiplying the traffic in the air vs. what the transport 
see. The factor can be high, e.g., 64. On a mesh, we get the additional effect 
of multiple flows converging on a same node.

> 
> To be clear the request of this discuss is to give a normative recommendation
> for the default value of the window size and/or inter-frame gap.

Yes, and since there is no great expectation that ECN will be implemented, that 
must be reasonable.
Also we want to agree on the proposed mechanism to drop the window to 1 in case 
of congestion notification, or is that behind us already?


> 
> Further note, as you allow to adapt both the window and the inter-frame gap
> dynamically, you actually implement two control mechanisms here. I actually
> recommend to only use the inter-frame gap and don’t have window here. You
> say a couple of times in your reply below, that the window determines the ask-
> rate, however, it is not clear to me because the ack rate should be a 
> parameter
> at the receiver and not at the sender (maybe I don’t remember things correctly
> because it’s a while back since I read the draft and I couple find anything 
> about
> this in the draft quickly). If the window size however does define the ack 
> rate,
> then maybe you should rename that parameter 

Re: [6lo] Benjamin Kaduk's No Objection on draft-ietf-6lo-fragment-recovery-16: (with COMMENT)

[Pascal Thubert (pthubert)]

Hello again Benjamin:

Continuing based on rev 16...

As usual, the state of both of today's threads is published as 
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-fragment-recovery-17 for your 
convenience 


> --
> COMMENT:
> --
> 
> Thank you for addressing my comments!
> Just a few minor notes from reading the diff from -13 to -16:
> 
> Section 1
> 
>each hop, more in Section 6.  This specification encodes the
>Datagram_Tag in one byte, which will saturate if more than 256
>datagram transit in the fragmented form over a same hop at the same
>time.  This is not realistic at the time of this writing.  Should
> 
> Some grammar nit(s) here, maybe: "datagrams transit in fragmented form over
> a single hop at the same time"

Applied

> 
> Section 4.3
> 
>is out of scope.  In most cases, the expectation is that most
>datagrams will represent only a few fragments, and that only the last
> 
> Maybe s/represent/require/?

Applied

> 
>fragment will be acknowledged.  A basic implementation of the
>fragmenting endpoint is NOT REQUIRED to variate the size of the
> 
> nit: s/variate/vary/

Applied.
Guess what, I actually looked it up and could not find a clear definition of 
the difference so I picked one.


> 
>the ECN signal or simply reset the window to 1 (see Appendix C for
>more) till the end of this datagram upon detecting a congestion.
> 
> nit: s/till/until/
> 

Applied

> Section 5
> 
>This document specifies an alternate to the 6LoWPAN fragmentation
> 
> nit: s/alternate/alternative/

Applied

> 
> Section 5.1
> 
> It just occurred to me now that with the change in response to my initial
> review of "never reuse a sequence number for a fragment with different size",
> there may be special considerations for the initial fragment (Sequence 0) that
> gets some special handling.  I suspect there are not any real problems here,


Let's see:  If the fragment seq=0 is too big the path is never built. Retrying 
it will fail. 
It's actually a good idea not to subfragment with the samle datagram tag. 
Seems a good idea to allow to form a whole new path with a new datagram tag.

What about relooking 6.1. ?

"

6.1.  Forwarding Fragments

   This specification inherits from [FRAG-FWD] and proposes a Virtual
   Reassembly technique to forward fragments with no intermediate
   reconstruction of the entire datagram.

   The IPv6 Header MUST be placed in full in the first fragment to
   enable the routing decision.  The first fragment is routed and
   creates an LSP from the fragmenting endpoint to the reassembling
   endpoint.  The next fragments are label-switched along that LSP.  As
   a consequence, the next fragments can only follow the path that was
   set up by the first fragment and cannot follow an alternate route.
   The Datagram_Tag is used to carry the label, which is swapped in each
   hop.

   If the first fragment is too large for the path MTU, it will
   repeatedly fail and never establish an LSP.  In that case, the
   fragmenting endpoint MAY retry the same datagram with a smaller
   Fragment_Size, in which case it MUST abort the original attempt and
   use a new Datagram_Tag for the new attempt.
"

Note: This is a first step into the PMTU that I did not want to specify here. 


> and in any case the datagram itself could be re-sent, but mention it just in 
> case
> there are some new problems (e.g., we get stuck in a case where we have to
> send something that gets treated as a reset even if we don't want it to).

In which case the offset, not the sequence, is 0. Does the last paragraph above 
clarify?

> 
> Appendix C
> 
>represented in Figure 4 in Section 5.2.  While the support of echoing
>the ECN at the reassembling endpoint in mandatory, this specification
>does not provide the flow control mechanism that react to the
>congestion at the fragmenting endpoint.  A minimalistic behaviour
>could be to reset the window to 1 so the fragments are sent and
>acknowledged one by one till the end of the datagram.
> 
> I think we may be suffering from a bit of skew here, since Section 1 specifies
> the "UseECN=yes" behavior (for this document) as "reset the window to 1".

True:

What about :

"
  While the 
support of echoing
   the ECN at the reassembling endpoint is mandatory, this specification
   only provides a minimalistic behaviour on the fragmenting endpoint,
   that is to reset the window to 1 so the fragments are sent and
   acknowledged one by one till the end of the datagram.
"

Many =
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo