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

[Michael Richardson]

Pascal Thubert (pthubert)  wrote:
> What if we start like:

Good.

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

___
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

[Falendysz, Gene]

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-gm49L9zsnrsuNqF6IWpuxn6RpF57II9mE2Q78qSFX9D2MFMLzzuK5OFVpBEIDo6N8JdY2xrwNVr9LKz_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 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/6l
> > o_ 
> > _;!!F7jv3iA!2dS7DeAq_Z8s7nFEQvpxqz9CB5Y0xD_qNKbFXdvDCZlojcAAwhaYzTc3
> > xI 

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] WG Last Call on draft-ietf-6lo-multicast-registration-11

[Falendysz, Gene]

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

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  on behalf of Pascal Thubert 
> (pthubert)
> 
> 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  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,
> > 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
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo