Subject: Re: [Roll] Error flows, which ICMP errors and to which root

From: "Huimin She (hushe)" <[email-masked]>
Date: Mon, 30 Nov 2020 08:15:12 +0000

Hi Pascal,

RFC 6550 section 11.1 says the ICMPv6 error in SRH should be sent to the source of the packet.

Best regards,
Huimin

    Message: 2
    Date: Fri, 27 Nov 2020 07:47:22 +0000
    From: "Pascal Thubert (pthubert)" <[email-masked]>
    To: Routing Over Low power and Lossy networks <[email-masked]>
    Subject: [Roll] Error flows, which ICMP errors and to which root?:
    	[extends] IETF 109 open Questions on P-DAO
    Message-ID:
    	<[email-masked]>

    Content-Type: text/plain; charset="us-ascii"

    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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 30 Nov 2020 09:27:49 +0000

Yes Huimin

And this is the normal behavior.

With PDAO we created the unusual behavior to send the error in p-route to the root. This was to make things faster since the communication through the Track is directional so you cannot talk back. Also in non storing talking to the source is via the Root and ultimately the Root needs to update the P DAO.

With RAW we may want to to something faster but unclear for now.

Please note that after the discussion with you and Li I published a revision that has the flag in the RPI that indicates that the packet is forwarded on a P-route.

Do you want to change the error flow?

Pascal

> Le 30 nov. 2020 à 09:15, Huimin She (hushe) <hushe=[email-masked]> a écrit :
> 
> Hi Pascal,
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Tue, 1 Dec 2020 05:34:31 +0000

Hello Pascal,

One concern for section 4 “Extending RFC 6553”.
Are other fields “'O', 'R', 'F' flags, SenderRank ” necessary to be zero if ‘P’ flag is set?
For storing-PDAO, maybe we can leverage these fields for error-detection if need. So do we need replace “MUST” to “SHOULD” or “MAY” to keep the flexibility?

Best regards,
Li

From: Roll <[email-masked]>
Date: Monday, November 30, 2020 at 17:28
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] Error flows, which ICMP errors and to which root
Yes Huimin

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 1 Dec 2020 06:35:29 +0000

Hello Li

But P-DAO does not distribute a Rank. The new P-SRH-6LoRH elides it. So the ‘R’ flag does not make sense either.
For now the Track is not reversible, so the ‘O’ flag is useless as well.

I was wondering for the ‘F’ flag. We could still use it in both modes. But that is extra code, little value since the ICMP to the root is already there.

Finally, you’ll find that there is no room left in

                0                   1                   2
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |1|0|E| Length  | 6LoRH Type 7  | RPLInstanceID |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

That is because I want the P-RPI-6LoRH to be either elective or critical, which implies that buts 3..7 are a length, no room for the ‘F’ bit.
For memory, the RPI-6LoRH is critical, you HAVE to support it if it is in the packet, else you drop. In the above format, if the ‘E’ bit is set, the implementation can fully ignore the RPI (that’s one of the nice things about RFC 8138), which can be OK in some strict source routing situations.

So I thought, let us ignore all the bits and keep things simple.

Works?

Pascal

From: Roll <[email-masked]> On Behalf Of Li Zhao (liz3)
Sent: mardi 1 décembre 2020 06:35
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] Error flows, which ICMP errors and to which root

Hello Pascal,

Best regards,
Li

From: Roll <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 30, 2020 at 17:28
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] Error flows, which ICMP errors and to which root
Yes Huimin

Pascal

> Le 30 nov. 2020 à 09:15, Huimin She (hushe) <hushe=[email-masked]<mailto:hushe=[email-masked]>> a écrit :
>
> Hi Pascal,
>
>    From: "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
>    To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
>        <[email-masked]<mailto:[email-masked]>>
>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Tue, 1 Dec 2020 07:05:40 +0000

Hello Pascal,

Agree with you. As there is no room left in P-RPI-6LoRH, let’s ignore all the bits and keep things simple.

Best regards,
Li

From: Roll <[email-masked]>
Date: Tuesday, December 1, 2020 at 14:36
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] Error flows, which ICMP errors and to which root
Hello Li

                0                   1                   2

Works?

Pascal

Hello Pascal,

Best regards,
Li

Pascal