On Nov 14, 2013, at 6:58 PM 11/14/13, "Pascal Thubert (pthubert)" <pthubert@cisco.com> wrote:

> 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.

I consider a PAN ID to be equivalent to an address ... both are configured administratively but are part of the 
> 
> A RPL domain (that is an 03) that may span multiple PAN IDs.

Pascal - RPL domains are, in my opinion, completely unrelated to MPL scopes.  RPL is only mentioned obliquely, as an example of a protocol that accommodates the memory constraints in highly constrained devices.  So, I don't think there is any reason to say "A RPL domain (that is an 03)".

> 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? 

No ... RPL domain is independent of MPL scope.

As a practical matter, a "RPL domain" is a little tricky to define, and even trickier to tie into a multicast scope.  There is nothing in the multicast address or the MPL header to tie it to a DODAG or some other RPL domain identifier.  In a mesh where multiple DODAGS and RPL domains may be interleaved, there doesn't seem to be a way to identify a MPL scope.

> 
> 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.

I think you're confusing the use of "scop 3" for carrying multicast traffic via MPL across a single mesh network and the use of, e.g., "scop 4" for the scope of, say, mDNS for DNS-SD across a federation of subnets.

I won't attempt the ASCII art here ... but here's an example scenario as I understand it: SEP2.0 DNS-SD/mDNS queries intended to span a federation of subnets is sent to (working from memory) FC04::FB.  When delivered to an LBR at the border of a 6LoWPAN mesh, that query would be encapsulated in FC03::<ALL_MPL_FORWARDERS> to carry it across the mesh. Similarly, a query from a mesh node would have an inner header with dst FC04::FB and encapsulated by the source with outer header dst FC03::<ALL_MPL_FORWARDERS>; then the MPL outer header would be taken off by the LBR and inner DNS-SD/mDNS query would be forwarded out any other interfaces based on the dst FC04::FB.

> 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."

OK, but I don't think draft-ietf-6man-multicast-scopes contradicts RFC 4007 in any way.

> Cheers;
> Pascal

- Ralph

> 
> 
> -----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
>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------