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

[Dario Tedeschi <[e-mail]>]

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
>>>
>>
>