Re: [Roll] Error flows, which ICMP errors and to which root?: [extends] IETF 109 open Questions on P-DAO

["Li Zhao (liz3)" <[e-mail]>]

Hello Pascal,

Signal P route in the RPI looks better because we also need this flag to ignore SenderRank check in RPI for non-storing PDAO.
Can we update the RFC6553 easily? For example, add 1-bit flag in reserved field.


Best regards,
Li

From: Roll <[e-mail]>
Date: Friday, November 27, 2020 at 15:48
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: [Roll] Error flows, which ICMP errors and to which root?: [extends] IETF 109 open Questions on P-DAO
Hello Li

This is the wrong thread. I created a new one.

> Section 7.9 of pdao-draft defines a new code for  ICMPv6 error message "Error in Projected Route". Does it only work for ICMP errors sent to the main Root?

Section 5 says “


   In case of a forwarding error along a Projected Route, an ICMP error

   is sent to the Root with a new Code "Error in Projected Route" (See

   Section 7.9<https://tools.ietf.org/html/draft-ietf-roll-dao-projection-14#section-7.9>).  The Root can then modify or remove the Projected

   Route.  The "Error in Projected Route" message has the same format as

   the "Destination Unreachable Message", as specified in RFC 4443<https://tools.ietf.org/html/rfc4443>

   [RFC4443<https://tools.ietf.org/html/rfc4443>].

“

So yes the intention was to send the ICMP to the main Root. But as you point out the packet does not indicate it is following a P-route. This was related to storing mode P DAO. In non-storing the node does not know it’s a P-route.


> In non-storing PDAO, forwarder can’t recognize whether data packet is in PDAO instance. Forwarder should send ICMP Destination Unreachable error to root (the source of the packet), then root generates ICMPv6 error message with "Error in Projected Route” to main Root.  Is it correct?

That would work. Seems neat. The alternate would be to signal it is a P route in the RPI. That’s item 2) in the list in this thread. If we do that the current text works. What makes more sense to you?

> In storing PDAO, forwarder can recognize the PDAO instance from the RPI. It can send "Error in Projected Route” or  “Destination Unreachable error” to root. Maybe we need more claims for which code forwarder should use.

We have to decide if we send it to the main root as written in the current draft or to the Track Root. If the P route is reversible could be done that way. But that’s added complexity. I’m not very convinced either way. The Okham razor could be to do the simplest.

Keep safe!

Pascal


From: Roll <[e-mail]> On Behalf Of Li Zhao (liz3)
Sent: vendredi 27 novembre 2020 03:51
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO

Hello Pascal,

It looks good for me. Only one question about ICMP errors.

Section 7.9 of pdao-draft defines a new code for  ICMPv6 error message "Error in Projected Route". Does it only work for ICMP errors sent to the main Root?
In non-storing PDAO, forwarder can’t recognize whether data packet is in PDAO instance. Forwarder should send ICMP Destination Unreachable error to root (the source of the packet), then root generates ICMPv6 error message with "Error in Projected Route” to main Root.  Is it correct?
In storing PDAO, forwarder can recognize the PDAO instance from the RPI. It can send "Error in Projected Route” or  “Destination Unreachable error” to root. Maybe we need more claims for which code forwarder should use.


Best regards,
Li



From: Roll <[e-mail]<mailto:[e-mail]>>
Date: Thursday, November 26, 2020 at 18:48
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO
Hello Li

In the packet, there’s a bit in the RPI to say if the root is the source or the destination. That’s RFC 6550.
I guess the discussion is related to the PDR and P-DAO, not data packet, though it impacts the ICMP error reporting.

In a packet along the P-Route, the idea was so far that the DODAG is a convergecast to the destination so the destination is the root. If we say that there’s a single ingress and a single egress then the dodag is reversible and either can be the root. If we want to support multicast tracks in the future, then the ingress should be root.

If the Track has a single ingress and a single egress, then the DODAG is reversible into another DODAG and it does not matter which is root, so we can make it bidir as Huimin asked.
The storing mode P DAO would look a lot more like a DAO, as you pointed out, if it goes towards the root. If we want to take that path, a node could learn both directions with a single storing mode P DAO. To be continued…

For non-storing, making bidir is really hard. It seems easier to install a Track in both directions and couple them.

As a summary of the proposed changes:

General
- we make the root the ingress
- ICMP errors sent to the Root, using the main DODAG if the track is not reversible


Storing mode P DAO:
- we also make the root the ingress, P-DAO from egress to ingress are now more similar to RPL DAO operation
- the track could be made bi-directional, but that’s more code; if so:
  - the packet forwarding leverages the RPI to indicate the direction, from or to root
  - ICMP errors sent to the Root, could be source or destination.

Non storing mode P DAO:
- tracks remain directional, can be coupled, how is tbd
- the RPI is mostly useless since the intermediate nodes do not know the instance (they see neither the DIO nor the P-DAO); they have no idea of their Rank. Still, it is interesting to have is for error determination in an ICPMP error at eth root. It is also interesting if the SRH forwarding nodes have a state associated to the Track, e.g., reserved time slots or priority queues.
- the RPI is still a SHOULD when there’s no compression and a MUST when there is. We need to clarify what to do, that’s another of Huimin’s questions, taken separately.
- ICMP errors forwarding packets are sent to the root which is now the ingress, aka the source of the packet, and the encapsulator field if the packet is encapsulated and compressed. This is common to any non-storing operation, whether it is a main Instance, local Instance, or Track. The RPI therein is useful to indicate the Track in Error. So for that matter the forwarder does not need to make a difference Track vs. other form of RPL local instance.
- this impacts the discussion in SRH reloading we had at IETF 109, when a  N-S mode loose track is forwarded along a segment that is also NS mode. We’ll probably need to re-encapsulate now.  In case of re-encapsulation, the re-encapsulator becomes source and root of the segment, which now has to be considered as a serial Track; as tunnel headends do, it will have to decapsulate the tunneled packet to send the packet in error back to the ingress of the loose track


Doe that work?

Pascal

From: Roll <[e-mail]<mailto:[e-mail]>> On Behalf Of Li Zhao (liz3)
Sent: jeudi 26 novembre 2020 03:45
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO

Hello Pascal,

If either source or destination can be root, it’s better to identify when or in which case source or destination can be root. Otherwise, it’s hard to interop between different implement even though they both follow RFC standard.

E.g. for non-storing mode PDAO, if source is root, PCE only responses PDR-ACK after receiving PDR from source.
But if destination is root, PCE should also notify destination which trackid is used. Maybe we need bring new message for this notification?


Take care,
Li

From: Roll <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, November 25, 2020 at 21:54
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO
Hello Li;

Well noted. This was the original intent. The change was made to egress because the idea was that the track could enable multiple sources to reach the egress, like a tree rooted at the egress that flows traverse going down. But the idea of a bidirectional track kinda blocks that idea and the other issues like the one you point out seem to get us back to the original view. I recently made the change from ingress to egress in the 6TiSCH architecture, waiting in RFC editor queue. I could reverse back, or maybe say “either source or destination” so it can be egress or egress and we are covered for bidirectional.
What do you think?
Or should a reversable Track be really a pair of tracks?

Keep safe;

Pascal

From: Roll <[e-mail]<mailto:[e-mail]>> On Behalf Of Li Zhao (liz3)
Sent: mercredi 25 novembre 2020 05:57
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO

Hello Pascal,

Ingress as Root looks better because
1.  It is consistent with the way RPL usually works. RPL Local instance, aodv-rpl, p2p-rpl all use ingress as root.
2.  For non-storing-mode P-DAO, currently ingress sends upward traffic to egress(root) with SR header. But in RPL, only downward traffic carries SR header.
3.  Only ingress can send PDR makes sense. Behavior of TrackId is similar as Local Instance ID. Ingress as root can propose TrackId from its namespace.


And for storing-mode P-DAO, if we make ingress as root and ingress sends PDR, can PCE send P-DAO to egress then egress forwards it towards predecessor to ingress?
Maybe it helps to make P-DAO looks like a DAO message.


Best regards,
Li


From: Roll <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, November 24, 2020 at 21:39
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO
Dear all

Whether to make the P-DAO bidirectional is an intriguing question. It could be done, just like we can send packets DOWN a classical DODAG.
But if we take that path, we reopen the question of who is root and which direction the P-DAO flies.

Could we make either the ingress OR the egress root? How does it matter?

At the moment the Root is the egress and the storing-mode P-DAO flies from the Track egress to the track ingress, and the track egress is the root. This is not the way RPL usually works as the DAO flies towards the root. The reason was that we wanted a single egress for the Track, as we build unicast Track. If we wanted to build multicast Tracks the root should logically be the ingress. And for bidirectional Tracks it could be either.

Up to -24 the 6TiSCH Architecture expected the ingress to be root. I changed in the latest to map we do here, that it is the egress; maybe a flag in the DAO would indicate which direction the flow, from root, to root, or both?

Also if we build bidir Tracks in storing mode, the nodes that forward the DAO will have to build routes in both directions based on the P-DAO, both towards egress and ingress; but only the path from which the P-DAO comes has been validated by the P-DAO itself. Should we send a P-DAO to each end, each setting up one way?

Please let me know your thoughts

Pascal


From: Roll <[e-mail]<mailto:[e-mail]>> On Behalf Of Pascal Thubert (pthubert)
Sent: mardi 24 novembre 2020 14:22
To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
Subject: [Roll] IETF 109 open Questions on P-DAO

Dear all

The slides for the P-DAO discussion at IETF 109 are available here:

https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/

There are a number of open questions that we starting discussing, and would need to progress on the list.
Some of them were expressed on the list, e.g., from Huimin She. I’d like to progress on them all with individual threads.
The questions are:


  1.  Lifetime Unit: could we use a different unit for P-DAO?
  2.  How to differentiate a P-DAO from a normal DAO in a local instance; new flag?
  3.  Make P-DAO bidirectional?
  4.  Who sends the PDR? Does it have to be the ingress? If it was egress it could propose a TrackId from its namespace. Else could the ingress be the root?
  5.  Maintaining the sibling state. Should we have text on using RFC 8505 there?
  6.  Whether ingress and egress are listed in NPO? Today they are both, ingress to indicate the packet source in case of encapsulation and for SRH-6LoRH compression reference and egress to build the full SRH-6LoRH. Note that the ingress must consume the first entry and use it as source.
  7.  Track in Track vs. SR Header reload models, see slides

Let me open threads to follow up.

Keep safe

Pascal