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

[Dario Tedeschi <[e-mail]>]

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
>
> 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
>>
>>
>> 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
>>>
>>> On Jun 21, 2012, at 9:05 AM, Dario Tedeschi wrote:
>>>
>>>> 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
>>>>>
>>>>> 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
>>>>>>
>>>>>> 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>>>
>>>>>> _______________________________________________
>>>>>> Roll mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>>
>>>>
>>>
>>
>