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

Brian Haberman <brian@innovationslab.net> Thu, 14 November 2013 13:22 UTC

Return-Path: <brian@innovationslab.net>
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 AA7F721E80A9; Thu, 14 Nov 2013 05:22:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 JhCtJd2dTuPJ; Thu, 14 Nov 2013 05:22:46 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC7A21E8090; Thu, 14 Nov 2013 05:22:46 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 480E68809F; Thu, 14 Nov 2013 05:22:46 -0800 (PST)
Received: from 10252612.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id AFC4B13680F2; Thu, 14 Nov 2013 05:22:45 -0800 (PST)
Message-ID: <5284CE9E.4060001@innovationslab.net>
Date: Thu, 14 Nov 2013 08:22:38 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <pthubert@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>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD841590CC4@xmb-rcd-x01.cisco.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="rSJEo6mjTaftRL8RKGCuKIOvGibl3dlHQ"
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 13:22:51 -0000

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
>