Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554

From: Dario Tedeschi <[email-masked]>
Date: Fri, 01 Jun 2012 19:21:22 -0700

Yes, I noticed this as well. It is unfortunate because as you say, there 
is now no way to identify which instance a Error in SRH is for, and 
subsequently the root node can't just remove that routing entry in a 
specific instance. Instead it must either remove that entry from all 
instances or do nothing and wait for the next DAO to update the entry.

Dario

On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote:
>
> Hello,
>
> I have observed that the RPLInstanceID field from Source Routing 
> header (present in  draft-ietf-6man-rpl-routing-header-07) was removed 
> in RFC6554.
>
> Are there particular reasons for this? This field is necessary at the 
> DODAG Root when it receives a Destination Unreachable with code "Error 
> in Source Routing Header" to identify the instance with the problem 
> (only if there are two instances with the same prefix and if the node 
> is Root in both of them).
>
> *Andreea Tecuceanu*
> (Freescale Semiconductor)
>
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 1 Jun 2012 19:46:59 -0700

I don't understand the need for knowing the RPLInstanceID when handling an ICMP Destination Unreachable error.  The SRH does not follow any RPL Instance, just the IPv6 addresses listed in the SRH.  Receiving an ICMP Destination Unreachable error from a node S simply means that S could not forward to the next IPv6 address in the SRH.  The inability of S to forward to the specified next hop would be true regardless of what RPL Instance the SRH was constructed from.

--
Jonathan Hui

On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote:

> Yes, I noticed this as well. It is unfortunate because as you say, there is now no way to identify which instance a Error in SRH is for, and subsequently the root node can't just remove that routing entry in a specific instance. Instead it must either remove that entry from all instances or do nothing and wait for the next DAO to update the entry.
> 
> Dario
> 
>> I have observed that the RPLInstanceID field from Source Routing header (present in  draft-ietf-6man-rpl-routing-header-07) was removed in RFC6554.
>> Are there particular reasons for this? This field is necessary at the DODAG Root when it receives a  Destination Unreachable with code "Error in Source Routing Header" to identify the instance with the problem (only if there are two instances with the same prefix and if the node is Root in both of them).
>>  
>>  
>> Andreea Tecuceanu

---

From: Dario Tedeschi <[email-masked]>
Date: Thu, 21 Jun 2012 09:05:09 -0700

Hi Jonathan

Sorry, for late response to your email.

Consider the scenario where a DODAG root node supports two or more RPL 
instances under one prefix. Each instance providing different routing 
objectives (i.e. different objective functions). Potentially, the 
source-route to a destination under one instance can be different to the 
source-route to the same destination under a different instance. For 
example: Instance 1 could have a source-route R-->X-->Y-->D, while 
instance 2 could have a source-route R-->X-->Z-->D. Lets say node Y sent 
a Destination Unreachable ("Error in source-route") back to R, because D 
was unreachable from Y. How would R know which source-route needed 
repair and, consequently, which instance needed a DTSN update?

Regards
Dario

On 01/06/2012 7:46 PM, Jonathan Hui wrote:
>
> I don't understand the need for knowing the RPLInstanceID when 
> handling an ICMP Destination Unreachable error.  The SRH does not 
> follow any RPL Instance, just the IPv6 addresses listed in the SRH. 
>  Receiving an ICMP Destination Unreachable error from a node S simply 
> means that S could not forward to the next IPv6 address in the SRH. 
>  The inability of S to forward to the specified next hop would be true 
> regardless of what RPL Instance the SRH was constructed from.
>
> --
> Jonathan Hui
>
>> Yes, I noticed this as well. It is unfortunate because as you say, 
>> there is now no way to identify which instance a Error in SRH is for, 
>> and subsequently the root node can't just remove that routing entry 
>> in a specific instance. Instead it must either remove that entry from 
>> all instances or do nothing and wait for the next DAO to update the 
>> entry.
>>
>> Dario
>>
>>> header (present in  draft-ietf-6man-rpl-routing-header-07) was 
>>> removed in RFC6554.
>>>
>>> Are there particular reasons for this? This field is necessary at 
>>> the DODAG Root when it receives a Destination Unreachable with code 
>>> "Error in Source Routing Header" to identify the instance with the 
>>> problem (only if there are two instances with the same prefix and if 
>>> the node is Root in both of them).
>>>
>>> *Andreea Tecuceanu*
>> [email-masked] <mailto:[email-masked]>

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 21 Jun 2012 11:51:10 -0500 (CDT)

Could the answer be: all the instances that have Y in the source route to D?

Thanks
Mukul

----- Original Message -----
From: "Dario Tedeschi" <[email-masked]>
To: "Jonathan Hui" <[email-masked]>
Cc: [email-masked]
Sent: Thursday, June 21, 2012 11:05:09 AM
Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554

Hi Jonathan 

Consider the scenario where a DODAG root node supports two or more RPL instances under one prefix. Each instance providing different routing objectives (i.e. different objective functions). Potentially, the source-route to a destination under one instance can be different to the source-route to the same destination under a different instance. For example: Instance 1 could have a source-route R-->X-->Y-->D, while instance 2 could have a source-route R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error in source-route") back to R, because D was unreachable from Y. How would R know which source-route needed repair and, consequently, which instance needed a DTSN update? 

Regards 
Dario 

-- 
Jonathan Hui 

Dario 

Hello, 

  

Andreea Tecuceanu 

_______________________________________________
Roll mailing list [email-masked] https://www.ietf.org/mailman/listinfo/roll 
_______________________________________________ 
Roll mailing list 
[email-masked] 
https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Jun 2012 17:08:55 +0000

Hi Dario:

The root might be using more than one path  to go to a target via a node Y. So even in a given instance there might be more than possible RH.
What the root needs to know is that connectivity from Y to child Z is broken. Then it can clean up all instances that use Y->Z.
Z can be found in the RH in the packet in error that should be passed with the ICMP. But that's not too practical.
It would be better if we had a new icmp error where Y could signal that connectivity to Z is lost.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dario Tedeschi
Sent: jeudi 21 juin 2012 18:05
To: Jonathan Hui
Cc: [email-masked]
Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554

Hi Jonathan

Regards
Dario

--
Jonathan Hui

Dario

Andreea Tecuceanu

Roll mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 21 Jun 2012 22:54:53 -0700

Hi Dario,

The ICMP Error message will contain the IPv6 header of the error-generating packet.  If link A -> B is broken, the IPv6 Destination Address will indicate B and the SRH will indicate A.

My point is that if you want to clean up routes, you need to clean up all routes that use A -> B, not just the particular Instance that you used to generate the route and discover the error.

--
Jonathan Hui

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 29 Jun 2012 08:48:53 -0700

Hi Jonathan

I would agree if link A -> B existed in more than one instance. In my 
example however, the source route for the first RPL instance has link Y 
-> D while the second instance has link Z -> D. How does R inform D to 
resend its DAO for only the first instance if only Y -> D is broken?

Dario

On 12-06-21 10:54 PM, Jonathan Hui wrote:
>
> Hi Dario,
>
> The ICMP Error message will contain the IPv6 header of the 
> error-generating packet.  If link A -> B is broken, the IPv6 
> Destination Address will indicate B and the SRH will indicate A.
>
> My point is that if you want to clean up routes, you need to clean up 
> all routes that use A -> B, not just the particular Instance that you 
> used to generate the route and discover the error.
>
> --
> Jonathan Hui
>
>> Consider the scenario where a DODAG root node supports two or more 
>> RPL instances under one prefix. Each instance providing different 
>> routing objectives (i.e. different objective functions). Potentially, 
>> the source-route to a destination under one instance can be different 
>> to the source-route to the same destination under a different 
>> instance. For example: Instance 1 could have a source-route 
>> R-->X-->Y-->D, while instance 2 could have a source-route 
>> R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error 
>> in source-route") back to R, because D was unreachable from Y. How 
>> would R know which source-route needed repair and, consequently, 
>> which instance needed a DTSN update?
>>
>> Regards
>> Dario
>>
>>>  Receiving an ICMP Destination Unreachable error from a node S 
>>> simply means that S could not forward to the next IPv6 address in 
>>> the SRH.  The inability of S to forward to the specified next hop 
>>> would be true regardless of what RPL Instance the SRH was 
>>> constructed from.
>>>
>>> --
>>> Jonathan Hui
>>>
>>>> there is now no way to identify which instance a Error in SRH is 
>>>> for, and subsequently the root node can't just remove that routing 
>>>> entry in a specific instance. Instead it must either remove that 
>>>> entry from all instances or do nothing and wait for the next DAO to 
>>>> update the entry.
>>>>
>>>> Dario
>>>>
>>>>> the DODAG Root when it receives a Destination Unreachable with 
>>>>> code "Error in Source Routing Header" to identify the instance 
>>>>> with the problem (only if there are two instances with the same 
>>>>> prefix and if the node is Root in both of them).
>>>>>
>>>>> *Andreea Tecuceanu*

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 29 Jun 2012 08:56:17 -0700

Hi Dario,

The ICMPv6 Destination Unreachable error will come from Y and indicate Y -> D is broken.  Any RPL Path that utilizes Y -> D (again, regardless of the RPL Instance) will require repair.  The DAG Root can choose to issue a DTSN update for any RPL Instance that utilizes link Y -> D in a downward path.  It can even choose the RPL Instance that it uses to route the original packet.  Because the ICMPv6 Destination Unreachable message encapsulates the error-generating packet (both the SRH and original packet), it has all the information it needs.

--
Jonathan Hui

On Jun 29, 2012, at 8:48 AM, Dario Tedeschi wrote:

> Hi Jonathan
> 
> I would agree if link A -> B existed in more than one instance. In my example however, the source route for the first RPL instance has link Y -> D while the second instance has link Z -> D. How does R inform D to resend its DAO for only the first instance if only Y -> D is broken?
> 
> Dario
> 
>

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 29 Jun 2012 09:33:00 -0700

Ok, I think I've got it. That's similar to what Mukul suggested: "all 
the instances that have Y in the source route to D"

However, I still think it's a bit unfortunate from an implementation 
perspective.

Thank you for the explanation.

Dario

On 12-06-29 08:56 AM, Jonathan Hui wrote:
>
> Hi Dario,
>
> The ICMPv6 Destination Unreachable error will come from Y and indicate 
> Y -> D is broken.  Any RPL Path that utilizes Y -> D (again, 
> regardless of the RPL Instance) will require repair.  The DAG Root can 
> choose to issue a DTSN update for any RPL Instance that utilizes link 
> Y -> D in a downward path.  It can even choose the RPL Instance that 
> it uses to route the original packet.  Because the ICMPv6 Destination 
> Unreachable message encapsulates the error-generating packet (both the 
> SRH and original packet), it has all the information it needs.
>
> --
> Jonathan Hui
>
>> example however, the source route for the first RPL instance has link 
>> Y -> D while the second instance has link Z -> D. How does R inform D 
>> to resend its DAO for only the first instance if only Y -> D is broken?
>>
>> Dario
>>
>>
>>> My point is that if you want to clean up routes, you need to clean 
>>> up all routes that use A -> B, not just the particular Instance that 
>>> you used to generate the route and discover the error.
>>>
>>> --
>>> Jonathan Hui
>>>
>>>> routing objectives (i.e. different objective functions). 
>>>> Potentially, the source-route to a destination under one instance 
>>>> can be different to the source-route to the same destination under 
>>>> a different instance. For example: Instance 1 could have a 
>>>> source-route R-->X-->Y-->D, while instance 2 could have a 
>>>> source-route R-->X-->Z-->D. Lets say node Y sent a Destination 
>>>> Unreachable ("Error in source-route") back to R, because D was 
>>>> unreachable from Y. How would R know which source-route needed 
>>>>> follow any RPL Instance, just the IPv6 addresses listed in the 
>>>>> SRH.  Receiving an ICMP Destination Unreachable error from a node 
>>>>> S simply means that S could not forward to the next IPv6 address 
>>>>> in the SRH.  The inability of S to forward to the specified next 
>>>>> hop would be true regardless of what RPL Instance the SRH was 
>>>>> constructed from.
>>>>>
>>>>> --
>>>>> Jonathan Hui
>>>>>
>>>>>> Yes, I noticed this as well. It is unfortunate because as you 
>>>>>> say, there is now no way to identify which instance a Error in 
>>>>>> SRH is for, and subsequently the root node can't just remove that 
>>>>>> routing entry in a specific instance. Instead it must either 
>>>>>> remove that entry from all instances or do nothing and wait for 
>>>>>> the next DAO to update the entry.
>>>>>>
>>>>>> Dario
>>>>>>
>>>>>>> Are there particular reasons for this? This field is necessary 
>>>>>>> at the DODAG Root when it receives a Destination Unreachable 
>>>>>>> with code "Error in Source Routing Header" to identify the 
>>>>>>> instance with the problem (only if there are two instances with 
>>>>>>> the same prefix and if the node is Root in both of them).
>>>>>>>
>>>>>>> *Andreea Tecuceanu*

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Fri, 29 Jun 2012 09:50:06 -0700

It doesn't have to be all.  As mentioned in my previous mail, you can target the specific RPL Instance by inspecting the original packet header in the ICMP error payload.

--
Jonathan Hui

On Jun 29, 2012, at 9:33 AM, "Dario Tedeschi" <[email-masked]> wrote:

> Ok, I think I've got it. That's similar to what Mukul suggested: "all the instances that have Y in the source route to D"
>  
> However, I still think it's a bit unfortunate from an implementation perspective.
>