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

[Adnan Rashid <[e-mail]>]

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) <
[e-mail]> 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.
> +
> +   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 by the same value in the ROVR
> +   field.
>
> -   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.
>
> +   The Root maintains a remaining Path Lifetime for each advertisement
> +   it receives, and the 6LRs generate the DAO for multicast addresses
> +   with the longest remaining lifetime across its registered 6LNs, using
> +   its own ROVR and TID when multiple 6LNs subscribed, or if this 6LR is
> +   one of the subscribers.
>
> ...
>
> 5.3.  RPL Anycast Operation
>
> ...
>
>
>     With the A flag, this specification alleviates the issue of
>
> -   synchronizing the TIDs, and as for multicast, the freshness
> -   comparison based on the TID field is ignored.  A target is routed as
> -   anycast by a parent (or the Root) that received at least one DAO
> -   message for that target with the A flag set to 1.
>
> +   synchronizing the TIDs and ROVR fields.  As for multicast, the
> +   freshness comparison based on the TID (in EARO) and the Path Sequence
> +   (in TIO) is ignored unless the messages have the same origin, as
> +   inferred by the same ROVR in RTO and/or EARO, and the latest value of
> +   the lifetime is retained for each origin.
> +
> +   A RPL router that propagates an advertisement from a single origin
> +   MUST use the ROVR and Path Sequence from that origin, whereas a
> +   router that merges multiple subscriptions MUST use its own ROVR and
> +   Path Sequence and the longest lifetime over the different
> +   advertisements.  A target is routed as anycast by a parent (or the
> +   Root) that received at least one DAO message for that target with the
> +   A flag set to 1.
>
> Also added missing terminology...
>
> The full commit is here:
> https://github.com/pthubert/6lo-multicast-registration/commit/3fa57412a565731ab73b90ca49fb79115fb5919b
>
> I refrain from publishing till Erik indicates the fate of the proposed
> IPv6 ND Node Uptime option.
>
> All the best;
>
> Pascal
>


-- 


Regards,



ADNAN RASHID (Ph.D. Research Scholar)
Dpt. Ingegneria dell'Informazione

Università di Firenze​, via di S.Marta-3,
50139, Florence​, Italy.

*email:* [e-mail]
       [e-mail]
*Cell:* ([phone]​ ​467

--------------------------------------------------------------------------------------------------