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) < [email protected]> 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:* [email protected] [email protected] *Cell:* (+39) 347 9821 467 --------------------------------------------------------------------------------------------------
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
