Subject: Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 12 Nov 2013 14:32:56 +0000

This revision adds the definition of "scop 3" for IEEE 802.15.4 networks:

4.  Definition of Realm-Local Scope for IEEE 802.15.4

   When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to
   include all interfaces sharing a PAN ID.

I've cross-posted to 6lo to get review and comment from that WG.

- Ralph

Begin forwarded message:

> From: <[email-masked]>
> Subject: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt
> Date: November 12, 2013 8:16:26 AM EST
> To: Ralph Droms <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-6man-multicast-scopes-02.txt
> has been successfully submitted by Ralph Droms and posted to the
> IETF repository.
> 
> Filename:	 draft-ietf-6man-multicast-scopes
> Revision:	 02
> Title:		 IPv6 Multicast Address Scopes
> Creation date:	 2013-11-11
> Group:		 6man
> Number of pages: 5
> URL:             http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes-02.txt
> Status:          http://datatracker.ietf.org/doc/draft-ietf-6man-multicast-scopes
> Htmlized:        http://tools.ietf.org/html/draft-ietf-6man-multicast-scopes-02
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-multicast-scopes-02
> 
> Abstract:
>   This document updates the definitions of IPv6 multicast scopes.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 12 Nov 2013 22:00:54 +0000

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?

Cheers,
Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph Droms (rdroms)
Sent: mardi 12 novembre 2013 08:33
To: [email-masked] IPv6 List
Cc: Routing Lossy networks Over Low power and; [email-masked]
Subject: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt

- Ralph

Begin forwarded message:

> has been successfully submitted by Ralph Droms and posted to the IETF 
> repository.
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

_______________________________________________
6lo mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lo

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 12 Nov 2013 22:04:22 +0000

The document has been accepted as a WG work item.  Check out http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-scopes-02.txt

---

From: Brian Haberman <[email-masked]>
Date: Wed, 13 Nov 2013 08:21:40 -0500

Pascal,

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 14 Nov 2013 05:51:46 +0000

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:[email-masked]] 
Sent: mercredi 13 novembre 2013 07:22
To: Pascal Thubert (pthubert)
Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; [email-masked] IPv6 List; [email-masked]
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
> 
> 

Scopes are still nested.  See RFC 4007.  Are you saying that this document is changing that?

Regards,
Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 14 Nov 2013 09:20:39 +0000

> 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 certai…

Are there use cases documented somewhere in a 6lo or 6lo-related draft?

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.

Tim

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Thu, 14 Nov 2013 08:22:38 -0500

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 14 Nov 2013 23:52:25 +0000

Hello Tim;

The 6TiSCH architecture documents a use case whereby a large (RPL based) LLN is federated by an higher speed backbone such as Ethernet that mostly spans the LLN.
The LLN is partitioned by RPL in multiple DODAGs, and the roots of the DODAGs connect to the backbone to provide end to end connectivity over the formed multilink subnet.
The LLN probably forms a single RPL Domain though we have not discussed that yet. Discussing with Ralph, I understand that the RPL domain is 03 and the whole multilink subnet is 04.
It results that we cannot address a single RPL instance or a single DODAG as a scope. The intersection with 802.15.4 PAN-ID still troubles me a bit but that's another thread. 

Cheers,

Pascal

-----Original Message-----
From: Tim Chown [mailto:[email-masked]] 
Sent: jeudi 14 novembre 2013 03:21
To: Pascal Thubert (pthubert)
Cc: Brian Haberman; Routing Lossy networks Over Low power and; [email-masked]; [email-masked] IPv6 List; Ralph Droms (rdroms)
Subject: Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt

Tim

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 14 Nov 2013 23:58:35 +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:[email-masked]] 
Sent: jeudi 14 novembre 2013 07:23
To: Pascal Thubert (pthubert)
Cc: Ralph Droms (rdroms); Routing Lossy networks Over Low power and; [email-masked] IPv6 List; [email-masked]
Subject: Re: [6lo] Fwd: New Version Notification for draft-ietf-6man-multicast-scopes-02.txt

Pascal,

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.

Regards,
Brian

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 15 Nov 2013 00:01:56 +0000

Indeed, Section 4 talks about the realm-local scope for IEEE 802.15.4

"4.  Definition of Realm-Local Scope for IEEE 802.15.4

   When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to
   include all interfaces sharing a PAN ID."

In several places, I think there is a typo: s/scop /scope

How about adding one or two examples in the appendix section  to clarify the nested scope in the home-network  containing two types of networks (wifi and LLN) ? Perhaps, we expecting that LLN could have further division in scope -- ie, IEEE 802.15.4 or BT-le or MS/TP networks.

The example of mdns, rpl, and nd  possibly will fall in different scopes. 

Thanks,
-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 15 Nov 2013 00:12:26 +0000

Hi Tim,

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

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

Thanks,
-Samita

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Fri, 15 Nov 2013 00:22:17 +0000

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

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.

- Ralph

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 14 Nov 2013 19:31:24 -0500

Hi Pascal,

On Thu, Nov 14, 2013 at 6:58 PM, Pascal Thubert (pthubert) <
[email-masked]> 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.
>

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

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.

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

HTH, -K-

Cheers;
> zone has no boundary, and the boundary of an interface-local zone encloses
> just a single interface.)
>
> 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.
>
>
> > 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
> >
> >
> >>> 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?
> >>>
> >

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Nov 2013 10:26:13 -0500

> definition applies to an existing LAN.  If you think about a Link-Local

I offer this definition: an independant outside observer can determine the
boundaries of scope 3 (2, and 1) can be observed without knowledge of the
internal policies of a node.  That's why we can say that it is automatically
defined: there is no choice to make or policy to apply.

This is obvious with a wired network: you just follow the wires.
(The nodes/machines don't even need to be on.)
For a wireless network, you need to have a radio to sniff with, but given
that, you can mostly determine things.

scope 4 is the first scope where a policy *may* come into play.

The thing that broke up the log jam last week was the understanding that
policies may be administratively defined such that the device can make a
decision on it's own, but that this decision is not necessarily visible to an
external observer.

(insert reference to Heisenburg uncertainty principle, and Einstein's hidden
variables if you like)

(I need to follow up to Kerry's reply from last week. I'm not sure that
Pascal read it)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Nov 2013 13:22:59 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > The LLN probably forms a single RPL Domain though we have not discussed
    > that yet. Discussing with Ralph, I understand that the RPL domain is 03
    > and the whole multilink subnet is 04.

No, that's not quite right.

Scope-3 is each of the LLNs that have a single technology instance (e.g. 802.15.4 + PANID)

Scope-4 is the whole multilink subnet as defined by the span of the
collection of DODAGs (my suggestion)

The RPL DODAG instances would likely span the backbone, and would be the
basis for scope-4 configuration.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Tim Chown <[email-masked]>
Date: Sat, 16 Nov 2013 14:46:05 +0000

Hi,

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

That would be excellent.  A separate document targeted at homenet WG showing multicast scenarios might be nice, but perhaps overkill.

Tim

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Mon, 18 Nov 2013 16:06:43 +0000

> That would be excellent.  A separate document targeted at homenet WG showing multicast scenarios might be nice, but perhaps overkill.

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

> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll