Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local

"roll issue tracker" <> Tue, 26 November 2013 03:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6CF241AE148 for <>; Mon, 25 Nov 2013 19:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 32Y_E3ohV39f for <>; Mon, 25 Nov 2013 19:05:17 -0800 (PST)
Received: from ( [IPv6:2a01:3f0:1:2::30]) by (Postfix) with ESMTP id 629131AE147 for <>; Mon, 25 Nov 2013 19:05:17 -0800 (PST)
Received: from localhost ([]:52352 ident=www-data) by with esmtp (Exim 4.80) (envelope-from <>) id 1Vl8xY-0004vA-7L; Tue, 26 Nov 2013 04:05:08 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: roll issue tracker <>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
X-Trac-Project: roll
Date: Tue, 26 Nov 2013 03:05:07 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 132
In-Reply-To: <>
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Subject: Re: [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local
X-Mailman-Version: 2.1.15
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Nov 2013 03:05:19 -0000

#132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local

Comment (by

 '''Related to draft-ietf-6man-multicast-scopes-02


 >On 15/11/2013 00:31, Kerry Lynn wrote:
 >One could take that argument to the extreme and say that selecting SSID
 (802.11) or plugging into a wall socket (802.3) is an administrative act.
 Let's not be too literal and instead say that the "automatic" zone
 boundary definition applies to an existing LAN.  If you think about a
 Link-Local zone, it is defined as a set of physically connected interfaces
 and the zone boundary is defined by a *lack* of forwarding (see [RFC4291]
 section 2.5.6). I think if there is a need for scope value 3 it is to
 provide classic Link-Local multicast behavior vover a connected mesh.  I
 think the definition should be independent of RPL and instead depend on
 some "L2 instance" definition. PAN ID works for 802.15.4 networks.
 <RCC>+1 - how PAN ID is assigned does not constitute "administratively
 configured" as it is a layer 2 concept.</RCC>
 >draft-ietf-6man-multicast-scopes-02 defines a scop 3 zone boundary based
 on PAN ID.  The latest version makes no mention at all of RPL.
 <RCC>Agree that RPL should not be mentioned here.</RCC>

 >I think the understanding that was reached at dinner last week is that,
 under certain circumstances, policy can count as "administratively
 configured".  Thus, if a RPL instance contained several PAN IDs then the
 former could be used as the basis of a scop 4 zone as long as if fully
 enclosed the PANs (scop 3 zones).OTOH, if a given PAN contains multiple
 RPL instances then the latter cannot be used to define a scop 4 zone
 boundary because that would violate the RFC 4007 constraints that Brian
 <RCC>MPL is orthogonal to RPL DODAGs. If there is a requirement to reach
 all nodes in a RPL DODAG which spans multiple 802.15.4 PANs, then that
 would be administratively configured and scope 4. If a RPL DODAG is wholly
 contained within the PAN ID then there would need to be some additional
 discriminator to limit propagation among a node set smaller than that of
 all nodes with the same PAN ID. In other words, it cannot be limited by
 just scope, which is too coarse a measurement. MPL doesn't cater for this
 as MPL Domains are defined as scope zones.</RCC> <robertCragie>


 > On 15 Nov 2013, at 00:12, Samita Chakrabarti <samita.chakrabarti at> wrote:
 >> Hi Tim,
 >>> Are there use cases documented somewhere in a 6lo or 6lo-related
 >>> I'm interested as we're updating the homenet text about multicast
 scopes.  We have agreed some text in principle with Brian for that, but
 it's interesting because we may, indeed are likely to, have 6lo networks
 within future IPv6 home networks.
 >> [SC>] AFAIK,  6lo/6lowpan basic documents do not discuss the multicast
 scopes in details.
 >> [SC>] It'll be certainly helpful to document the scopes of 6lo within
 the scope of home networks or equivalent.
 >> In addition I think, it'd be really helpful for implementers if we
 provide some examples of scopes of different protocols in the 6man-
 multicast-scopes doc along with the pointer to RFC 4007.

 Samita - I don't understand what you're suggesting as "scopes of different
 protocols in the 6man-multicast-scopes".  Do you mean examples of the
 definition of scope 3 for various L2 technologies? - Ralph <ralph>

 Reporter:  |       Owner:
     Type:  defect                     |      Status:  reopened
 Priority:  major                      |   Milestone:
Component:  trickle-mcast              |     Version:
 Severity:  In WG Last Call            |  Resolution:
 Keywords:                             |

Ticket URL: <>
roll <>