Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 14 November 2013 23:58 UTC

Return-Path: <pthubert@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 26D4B11E814D; Thu, 14 Nov 2013 15:58:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.477
X-Spam-Level:
X-Spam-Status: No, score=-10.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 tuuV-9VmLziy; Thu, 14 Nov 2013 15:58:37 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8105E11E8149; Thu, 14 Nov 2013 15:58:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4214; q=dns/txt; s=iport; t=1384473517; x=1385683117; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HA69uJVdEGHFIe3twx2KyKTPKqRJxRCBJVwzzzLDczY=; b=fSOQGXkfxL2znTsR5YScctSIAwPu28O0KtZ10BDiAqygecUFR+UVhEko xL9ynO5Et+74Z+XBKD43dosKvz+2EFvCES+dUdcWG20rameouOPvAMH9g G0ALfqWl8CmNcVLALoDS7wvuYwDve+wdCLcH7IwC72Jg99E9EsZOU1BYV o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwFAGBjhVKtJXG//2dsb2JhbABagwc4U78egSAWdIIlAQEBBDo9AgwEAgEIEQQBAQEKFAkHMhQJCAIEDgUIAYd4DcB+jieBBzEHBoMagREDmT+QXYFqgT6CKg
X-IronPort-AV: E=Sophos;i="4.93,702,1378857600"; d="scan'208";a="282030612"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 14 Nov 2013 23:58:37 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAENwaCb020355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 23:58:36 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 17:58:36 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Brian Haberman <brian@innovationslab.net>
Thread-Topic: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt
Thread-Index: AQHO4TyWZ/MxlpffAEipYTllbECB/ZolX+Vg
Date: Thu, 14 Nov 2013 23:58:35 +0000
Deferred-Delivery: Thu, 14 Nov 2013 23:58:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD841597360@xmb-rcd-x01.cisco.com>
References: <20131112131626.28795.73885.idtracker@ietfa.amsl.com> <81B53491-ABF4-4E98-B249-9CC652899B4C@cisco.com> <E045AECD98228444A58C61C200AE1BD84158AE17@xmb-rcd-x01.cisco.com> <9683EB80-69F2-42CC-BD89-1A0CC6398700@cisco.com> <52837CE4.60304@innovationslab.net> <E045AECD98228444A58C61C200AE1BD841590CC4@xmb-rcd-x01.cisco.com> <5284CE9E.4060001@innovationslab.net>
In-Reply-To: <5284CE9E.4060001@innovationslab.net>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.92.43]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Routing Lossy networks Over Low power and <roll@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, "ipv6@ietf.org IPv6 List" <ipv6@ietf.org>, "Ralph Droms (rdroms)" <rdroms@cisco.com>
Subject: Re: [Roll] [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
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, 14 Nov 2013 23:58:44 -0000

I mostly agree Brian;

It's a bit touchy because in 802.15.4 a PAN ID is configured administratively and could lead to an 04 interpretation. 
A RPL domain (that is an 03) that may span multiple PAN IDs. If PAN ID was 04 that would have been reverse nesting. 
The draft now clarifies that this is also an 03 but now we still have a potential conflict between a RPL domain and a PAN.

Would a RPL domain be constrained by the PAN ID? 

In this case that would imply that all the LLN must always be a single PAN and constrain the size of a subnet to 64K.
There is a lot behind the sentence "care must be taken in the definition of those larger scopes to ensure that inclusion constraint is met." 

Cheers;
Pascal


-----Original Message-----
From: Brian Haberman [mailto:brian@innovationslab.net] 
Sent: jeudi 14 novembre 2013 07:23
To: Pascal Thubert (pthubert)
Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; ipv6@ietf.org IPv6 List; 6lo@ietf.org
Subject: Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt

Pascal,
    Scope 3 being contained within scope4 is mandated by RFC 4007.
Specifically, RFC 4007 describes the following properties:

o  Zone boundaries cut through nodes, not links.  (Note that the global zone has no boundary, and the boundary of an interface-local zone encloses just a single interface.)

o  Zones of the same scope cannot overlap; i.e., they can have no links or interfaces in common.

o  A zone of a given scope (less than global) falls completely within zones of larger scope.  That is, a smaller scope zone cannot include more topology than would any larger scope zone with which it shares any links or interfaces.

o  Each zone is required to be "convex" from a routing perspective; i.e., packets sent from one interface to any other in the same zone are never routed outside the zone.  Note, however, that if a zone contains a tunneled link (e.g., an IPv6-over-IPv6 tunnel link [8]), a lower layer network of the tunnel can be located outside the zone without breaking the convexity property.


I don't see anything in this draft that would change those properties.

Regards,
Brian

On 11/14/13 12:51 AM, Pascal Thubert (pthubert) wrote:
> Hello Brian:
> 
> 03 seems to derive from autonomic behavior, whereas 04 derives from admin. I do not see there a direct indication that 03 is contained in 04 though in the deployments I have in mind it would certainly be the case. Whether we want to enforce or on the contrary do not want to enforce the nesting is probably something we want to clarify.
> 
> Cheers
> 
> Pascal
> 
> 
> -----Original Message-----
> From: Brian Haberman [mailto:brian@innovationslab.net]
> Sent: mercredi 13 novembre 2013 07:22
> To: Pascal Thubert (pthubert)
> Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; 
> ipv6@ietf.org IPv6 List; 6lo@ietf.org
> Subject: Re: [6lo] Fwd: New Version Notification for 
> draft-ietf-6man-multicast-scopes-02.txt
> 
> Pascal,
> 
> On 11/12/13 5:04 PM, Ralph Droms (rdroms) wrote:
>> The document has been accepted as a WG work item.  Check out
>> http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes-
>> 0
>> 2.txt
>>
>>
>> On Nov 12, 2013, at 5:00 PM 11/12/13, "Pascal Thubert (pthubert)" <pthubert@cisco.com> wrote:
>>
>>> Hello Ralph:
>>>
>>> http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does not seem to contains the section you're inlining. The only diff I found was -specific going -local.
>>> As we are at it, would we be ahead of ourselves if that the draft also specifies that a collection of RPL DODAGs of a same instance federated over an isolated backbone (such as a VLAN) in an 04 ?.
>>>
>>> If I may add, there is kind of an habit that scopes are nested. Seems that we are going away from that assumption and maybe it would be good to have a sentence saying that?
>>>
> 
> Scopes are still nested.  See RFC 4007.  Are you saying that this document is changing that?
> 
> Regards,
> Brian
>