Return-Path: 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 147BD11E80BB for ; Fri, 1 Jun 2012 19:21:31 -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 3JQDTdXXd6iK for ; Fri, 1 Jun 2012 19:21:27 -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 95F8F11E808C for ; Fri, 1 Jun 2012 19:21:27 -0700 (PDT) Received: by dacx6 with SMTP id x6so3484742dac.31 for ; Fri, 01 Jun 2012 19:21:27 -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=voeHVM6sbcUvNIFZY8WKhYVjxdzlA2JHHkih/tLCLtU=; b=omCPqQKEYY9lMmIuzeO8Y3KqvcfhAyY04Fp6GJBv/70I1hgNOBEJhrBF5VD47cs3hk QZsqpDkhIPg2WVPAA+CHByqwNq1zrh8UOoejQTSywPVMS41HZwVQlgRyx+Mc3GRMs9pt K7nTPUmhOQV0rTGZfBic4YCjLo5YaR3+NWJ5e/gFbyQqa3fp5gmeqw++/gdDeZV5Z/To I1Hmzk8W13TBfAG2Dq8RlsIUJW4XxPrUGMVyOg7WcIpjfZ4C3cpKHntEaF7sPOHMMemn OXy7CY/4lO8+ZUXkEZtb+L6yiq1GzTpF5X1qstYMQg73H1IhSiqYYhnANKSsTV/7dvC4 PQnQ== Received: by 10.68.233.102 with SMTP id tv6mr15595151pbc.153.1338603687158; Fri, 01 Jun 2012 19:21:27 -0700 (PDT) Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id mt9sm4681593pbb.14.2012.06.01.19.21.25 (version=SSLv3 cipher=OTHER); Fri, 01 Jun 2012 19:21:26 -0700 (PDT) Message-ID: <4FC978A2.30202@exegin.com> Date: Fri, 01 Jun 2012 19:21:22 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Tecuceanu Andreea-Dana-B10623 References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010903090100090201060201" X-Gm-Message-State: ALoCoQlc6eQmB9fQCMKg2nEmO+loYjLJaYLB/qZxlw/hNWoaqJOwquHz6rJa6Q7C7chT1dMQL4n6 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 02:21:31 -0000 This is a multi-part message in MIME format. --------------010903090100090201060201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------010903090100090201060201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

--------------010903090100090201060201--