Re: [Roll] definition of "RPL Domain"

Jonathan Hui <jonhui@cisco.com> Wed, 16 November 2011 13:37 UTC

Return-Path: <jonhui@cisco.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 A78E421F967D for <roll@ietfa.amsl.com>; Wed, 16 Nov 2011 05:37:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 DH5ADCJBnRxP for <roll@ietfa.amsl.com>; Wed, 16 Nov 2011 05:37:33 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id DFD8621F967C for <roll@ietf.org>; Wed, 16 Nov 2011 05:37:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=6270; q=dns/txt; s=iport; t=1321450653; x=1322660253; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=DJDNcjecRyUANyEim6q8YCLMcfwKvzD1A3gsNcOAD7o=; b=GTZOZVIFRg/TWpr8YL5ut4hXMsuX3KSayYEHuh2vwYFQPaZJ5gfrMNjx 5Uie/K7fYgs0HPPAjXAsntagIkpA+gsOg9/iu4Q/rTNL0Tnz0CQkhaV1S hUaIwDVwkgIgflfylYs8o6Ekrc/bDY4AcQmcCL8UFvUD//ju1axnB35Vs w=;
X-IronPort-AV: E=Sophos;i="4.69,521,1315180800"; d="scan'208";a="14616317"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 16 Nov 2011 13:37:33 +0000
Received: from sjc-vpn2-289.cisco.com (sjc-vpn2-289.cisco.com [10.21.113.33]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAGDbWpw029366; Wed, 16 Nov 2011 13:37:32 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Jonathan Hui <jonhui@cisco.com>
In-Reply-To: <687807886.312500.1321440357901.JavaMail.root@mail17.pantherlink.uwm.edu>
Date: Wed, 16 Nov 2011 05:37:32 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <99C9CB3F-6637-456F-AAD0-4C7474219CAE@cisco.com>
References: <687807886.312500.1321440357901.JavaMail.root@mail17.pantherlink.uwm.edu>
To: Mukul Goyal <mukul@uwm.edu>
X-Mailer: Apple Mail (2.1084)
Cc: roll <roll@ietf.org>
Subject: Re: [Roll] definition of "RPL Domain"
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: Wed, 16 Nov 2011 13:37:34 -0000

How about a definition derived from RFC 1629:
A "RPL domain" is a routing domain, as stated in Section 3.2 of RFC 1629, where the common routing protocol is RPL.

The above definition would unambiguously give the following answers to your questions:
1) Given the definition above, devices that do not operate RPL are not a part of the RPL domain.
2) Because RPL devices may support more than one instance, a RPL domain may contain any number of instances.

The term seems to be used most often in draft-ietf-roll-p2p-measurement.  I suggest going through and verifying whether "RPL Instance" or "RPL domain" was intended.

Happy to see any alternative definitions you may have in mind.

--
Jonathan Hui

On Nov 16, 2011, at 2:45 AM, Mukul Goyal wrote:

> Hi JP
> 
>> RPL domain: set of devices using RPL as a routing protocol.
> 
> I think this definition is little too vague. Some of the points that need clarification:
> 
> 1. It is clear that RPL hosts and routers (as defined towards the end of terminology section in RPL-19) are within an RPL domain but what about the RPL-unaware IPv6 hosts attached to an RPL router/host? I would imagine that such hosts are also within an RPL domain.
> 
> 2. Is an RPL domain same as an RPL instance? Or is an RPL domain a set of RPL instances in the LLN? Can multiple RPL domains exist within an LLN? Or is it that an RPL domain is same as an LLN using RPL as a routing protocol?
> 
> Thanks
> Mukul  
> 
> ----- Original Message -----
> From: "JP Vasseur" <jpv@cisco.com>
> To: "Mukul Goyal" <mukul@UWM.EDU>
> Cc: "roll" <roll@ietf.org>
> Sent: Wednesday, November 16, 2011 2:33:50 AM
> Subject: Re: definition of "RPL Domain"
> 
> Hi Mukul,
> 
> On Oct 18, 2011, at 3:05 AM, Mukul Goyal wrote:
> 
>> Hi JP
>> 
>> I was wondering if the term "RPL Domain" could be defined in the terminology draft. 
>> 
> 
> How about
> 
> RPL domain: set of devices using RPL as a routing protocol.
> 
> Thanks.
> 
> JP.
> 
>> Thanks
>> Mukul 
>> 
>> ----- Forwarded Message -----
>> From: "Joseph Reddy" <jreddy@ti.com>
>> To: ipv6@ietf.org
>> Sent: Friday, October 14, 2011 7:15:05 PM
>> Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt
>> 
>> 
>> Hi Jonathan,
>> 
>> The draft uses the term "RPL domain" in several places and this is not clearly defined. 
>> 
>> I would imagine that it includes all nodes that are downstream of the RPL border router. But can you clarify if Host nodes that are downstream of the border router but do not implement any part of RPL ( even as RPL Leaf nodes ) should be considered part of the "RPL domain" ?
>> 
>> In section 5, the draft now says "..Datagrams destined to nodes outside the RPL domain are dropped if the outer-most IPv6 header contains a RPL Option..."
>> 
>> This text would imply that any RPL node sending packets to nodes outside should always tunnel to the Root ? Is that the intention really or am I missing something here.. 
>> 
>> Also note that if non-RPL Host is not considered part of the RPL domain, then I am not sure that a forwarding router can know if the destination is inside the domain or not. 
>> 
>> 
>> -Regards, Joseph
>> 
>> 
>> ------------------------------
>> 
>> Message: 5
>> Date: Tue, 11 Oct 2011 22:23:10 -0700
>> From: Jonathan Hui <jonhui@cisco.com>
>> To: IETF IPv6 Mailing List <ipv6@ietf.org>
>> Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt
>> Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com>
>> Content-Type: text/plain; charset=us-ascii
>> 
>> 
>> This update is intended to address Jari Arkko's AD review.
>> 
>> Summary of changes:
>> - Clarify when the RPL Option is used.
>> - Updated text on recommendations for avoiding fragmentation.
>> - Specify skip-over-and-continue policy for unrecognized sub-TLVs.
>> - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST.
>> - Specify RPL Border Router operations in terms of forwarding decision outcomes.
>> - Expand security section.
>> 
>> --
>> Jonathan Hui
>> 
>> Begin forwarded message:
>> 
>>> From: internet-drafts@ietf.org
>>> Date: October 11, 2011 10:17:15 PM PDT
>>> To: i-d-announce@ietf.org
>>> Cc: ipv6@ietf.org
>>> Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
>>> 
>>> 	Title           : RPL Option for Carrying RPL Information in Data-Plane Datagrams
>>> 	Author(s)       : Jonathan W. Hui
>>>                        JP Vasseur
>>> 	Filename        : draft-ietf-6man-rpl-option-04.txt
>>> 	Pages           : 14
>>> 	Date            : 2011-10-11
>>> 
>>> The RPL protocol requires data-plane datagrams to carry RPL routing
>>> information that is processed by RPL routers when forwarding those
>>> datagrams.  This document describes the RPL Option for use within a
>>> RPL domain.
>>> 
>>> 
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> This Internet-Draft can be retrieved at:
>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll