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

Dario Tedeschi <dat@exegin.com> Fri, 29 June 2012 16:33 UTC

Return-Path: <dat@exegin.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFB721F8780 for <roll@ietfa.amsl.com>; Fri, 29 Jun 2012 09:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjrEzer6agch for <roll@ietfa.amsl.com>; Fri, 29 Jun 2012 09:33:06 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5912421F86A8 for <roll@ietf.org>; Fri, 29 Jun 2012 09:33:06 -0700 (PDT)
Received: by dacx6 with SMTP id x6so4772759dac.31 for <roll@ietf.org>; Fri, 29 Jun 2012 09:33:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=c8UtHi7CZZ7umTT1l7z2TASus5Il4miUTerz+HFbbpM=; b=VK34YEdDefv11FprDse8CF9lUCOIBtLrlDPb8iizxPDjBY/9sHL7asQyoEQjaS0Tn4 iVSF5zX4GfH+nA9jwoE8i1Ygu4MUlD6q3x6jSOQTraYDDjWIHrVx9PwfG/x7KcuAjzSC Y03xD25TTMg+cw46h5sM2YCdRAvSybAxgxCWIne5hiwy/KBAtSiUeQfpnqJKEE+p4afa N0lIg1GGJb3f2+rkL2lpOdIIrM+QnRuneFMfJccN+wn2NpL0/qpo0twh6qkEMNfD/inr 3qEJEnOQxGBKiygxORAtsJXZvsoFvuD36wY/tw8d9MGBOnPk1ocLcPhw7YNiP7BKweep HJ8g==
Received: by 10.66.86.165 with SMTP id q5mr1777235paz.72.1340987586012; Fri, 29 Jun 2012 09:33:06 -0700 (PDT)
Received: from ?IPv6:2001:470:67:2cc:9c81:aaf0:67b6:e544? ([2001:470:67:2cc:9c81:aaf0:67b6:e544]) by mx.google.com with ESMTPS id tj4sm5886690pbc.33.2012.06.29.09.33.04 (version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 09:33:05 -0700 (PDT)
Message-ID: <4FEDD8BC.7070600@exegin.com>
Date: Fri, 29 Jun 2012 09:33:00 -0700
From: Dario Tedeschi <dat@exegin.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Jonathan Hui <jonhui@cisco.com>
References: <C4731EA2F8833047869F2B5DB5F72C262E3CD9@039-SN1MPN1-001.039d.mgd.msft.net> <4FC978A2.30202@exegin.com> <07C8A712-9390-4704-8823-5E38C9635DBC@cisco.com> <4FE34635.6080201@exegin.com> <65511524-625D-4F29-9228-C60FD12BFFCC@cisco.com> <4FEDCE65.2030208@exegin.com> <BC0AD6E0-1528-4393-992F-2AD85F5FF651@cisco.com>
In-Reply-To: <BC0AD6E0-1528-4393-992F-2AD85F5FF651@cisco.com>
Content-Type: multipart/alternative; boundary="------------080404000300050301070408"
X-Gm-Message-State: ALoCoQmMiylUpFkOILDRVY57Qd6Cp/E3nRRRnBDylxZVZVwFOVZHpxI8q01TIn9V38eY/vtfQrD7
Cc: "roll@ietf.org" <roll@ietf.org>
Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2012 16:33:08 -0000

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
>>>>>>> Roll@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>>>
>>>>>> _______________________________________________
>>>>>> Roll mailing list
>>>>>> Roll@ietf.org <mailto:Roll@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>>
>>>>
>>>
>>
>