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

Mukul Goyal <mukul@uwm.edu> Thu, 21 June 2012 16:51 UTC

Return-Path: <prvs=512d68e0d=mukul@uwm.edu>
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 501D921F875C for <roll@ietfa.amsl.com>; Thu, 21 Jun 2012 09:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 gDp-2fcSrq7z for <roll@ietfa.amsl.com>; Thu, 21 Jun 2012 09:51:11 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 908A521F866B for <roll@ietf.org>; Thu, 21 Jun 2012 09:51:11 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EAJ9Q409/AAAB/2dsb2JhbAA7CoVYsxkBAQEEAQEBIARHCwwPDgMEAQEDAg0ZAikoCAYTiAsLpxSJe4kABIEgig4QhHuBEgOIRoxkkAGCfYFB
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9D37E12E3BC; Thu, 21 Jun 2012 11:51:10 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu
Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESboU8fVvF+s; Thu, 21 Jun 2012 11:51:10 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 4676412E3BA; Thu, 21 Jun 2012 11:51:10 -0500 (CDT)
Date: Thu, 21 Jun 2012 11:51:10 -0500 (CDT)
From: Mukul Goyal <mukul@uwm.edu>
To: Dario Tedeschi <dat@exegin.com>
Message-ID: <1324724214.8004.1340297470152.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <4FE34635.6080201@exegin.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [99.20.249.193]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Cc: 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: Thu, 21 Jun 2012 16:51:12 -0000

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

Thanks
Mukul

----- Original Message -----
From: "Dario Tedeschi" <dat@exegin.com>
To: "Jonathan Hui" <jonhui@cisco.com>
Cc: roll@ietf.org
Sent: Thursday, June 21, 2012 11:05:09 AM
Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554


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 
https://www.ietf.org/mailman/listinfo/roll 



_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll