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

From: "roll issue tracker" <[email-masked]>
Date: Fri, 11 Oct 2013 20:17:55 -0000

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

Comment (by [email-masked]):

 From: Ralph Droms <rdroms.ietf at gmail.com>
 Date: Fri, 11 Oct 2013 13:09:27 -0400

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08220.html

 " draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-scopes-00
 are in conflict with each other.

 From draft-ietf-roll-trickle-mcast-05:

    When
    used with MPL, Realm-Local scope is administratively defined and used
    to define the boundaries of multicast message dissemination by MPL.

 From draft-ietf-6man-multicast-scopes-00:

    Realm-Local scope is the largest scope that is automatically
    configured, i.e., automatically derived from physical
    connectivity or other, non-multicast-related configuration.

 Specifically, "administratively defined" seems to me to be in direct
 conflict with "automatically configured".

 I suggest fixing the problem with two updates.  First, the definition
 of "scop 3" in an IP-over-IEEE802.15.4 needs to be published, based on
 this text from draft-ietf-6man-multicast-scopes-00:

    The definition of any Realm-Local scope for a particular network
    technology should be published in an RFC.

 I suggest:

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

 This text could be added to draft-ietf-roll-trickle-mcast-05, or to
 draft-ietf-6man-multicast-scopes-00 or published separately in yet
 another "world's shortest RFC".

 Second, draft-ietf-roll-trickle-mcast-05 should be changed to read:

    When used with MPL, Realm-local scope is defined according to the
    underlying network technology; for example, [cite the
    IP-over-IEEE802.15.4 definition].

 As a further refinement, I suggest text be added to
 draft-ietf-roll-trickle-mcast-05 to the effect of:

    "scop 4" can also be used with MPL to cover deployments that use
    administratively defined scopes that cover, for example, subnets
    based on different underlying network technologies.

 - Ralph

 PS I originally posted about this issue to the rool WG mailing list:
 http://www.ietf.org/mail-archive/web/roll/current/msg08188.html.
 After a discussion with Kerry Lynn, I made a change to the definition
 of scop 3 for IEEE802.15.4. "

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

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/132#comment:7>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 14 Oct 2013 18:17:56 -0000

From: Robert Cragie <robert.cragie at gridmerge.com>
 Date: Mon, 14 Oct 2013 15:06:25 +0100

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08224.html

 "I would propose adding the language to draft-ietf-roll-trickle-mcast.
 There doesn't seem much point to doing another "world's shortest RFC".

 Here's an attempt at combining Ralph's text with the terminology in the
 draft:

 =================

 OLD

 By default, an MPL Forwarder SHOULD participate in an MPL Domain
 identified by the ALL_MPL_FORWARDERS multicast address with a scope value
 of 3 (Realm-Local) [I-D.droms-6man-multicast-scopes]. When used with MPL,
 Realm-Local scope is administratively defined and used to define the
 boundaries of multicast message dissemination by MPL.

 NEW

 By default, an MPL Forwarder SHOULD participate in an MPL Domain where the
 MPL Domain Address is the ALL_MPL_FORWARDERS multicast address with a
 scope value of 3 (Realm-Local) [I-D.droms-6man-multicast-scopes]. When
 used with MPL, Realm-Local scope is defined according to the underlying
 network technology; for example, when used in an IP-over-IEEE802.15.4
 network, Realm-Local scope is defined to include the set of MPL Interfaces
 sharing a PAN ID.

 An MPL Forwarder MAY participate in an MPL Domain where the MPL Domain
 Address uses a scope value of 4 (Admin-Local) [I-D.droms-6man-multicast-
 scopes]. When used with MPL, Admin-Local scope can be used in deployments
 that use administratively defined scopes that cover, for example, subnets
 based on different underlying network technologies.
 =================

 Robert "

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/132#comment:8>
roll <http://tools.ietf.org/wg/roll/>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Oct 2013 10:11:13 -0400

roll issue tracker <[email-masked]> wrote:
    > Address uses a scope value of 4 (Admin-Local)

Why do we need/want scope value 4 at all?

I don't agree with using the PAN ID as the automatically configured
criteria.  I think that subnet is the right thing.  RPL and MPL
is specifically designed to cross layer-2.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Don Sturek <[email-masked]>
Date: Tue, 15 Oct 2013 07:20:01 -0700

HI Michael,

At some point, I think it would be interesting to see multicast forwarding
rules in a mesh network where flooding is not used.  I would see that case
as the example of where scope 4 would be used.

I know that a lot of work is needed in defining the rules for forwarding
when flooding is not used but in a large mesh network, there would be a
lot of benefit to such a feature.

Don

On 10/15/13 7:11 AM, "Michael Richardson" <[email-masked]> wrote:

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

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 15 Oct 2013 14:57:47 +0000

> Why do we need/want scope value 4 at all?

There apparently was interest in an administratively defined MP domain.  scop 4 is available for that kind of domain.  If there is no interest, scop 4 need not be added.

> is specifically designed to cross layer-2.

What is your definition for "subnet" that is compatible with the definition from draft-ietf-6man-multicast-scopes:

  automatically

I chose PAN ID as a way of identifying a "subnet" within a distribution of MPL forwarders that might be within radio range of each other but should be in separate MPL domains.  For example, suppose I have MPL forwarders in my flat and you have MPL forwarders in your flat.  How do my forwarders know they belong to the MPL domain in my flat while your forwarders know they belong to the MPL domain in your flat.  PAN ID would be one way to make that differentation.

- Ralph

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Oct 2013 11:59:12 -0400

Don Sturek <[email-masked]> wrote:
    > At some point, I think it would be interesting to see multicast
    > forwarding rules in a mesh network where flooding is not used.  I would
    > see that case as the example of where scope 4 would be used.

okay, so when we write a new protocol, we can specify this.
Why have the code there to support scope-4 when there is no other behaviour?

    > I know that a lot of work is needed in defining the rules for
    > forwarding when flooding is not used but in a large mesh network, there
    > would be a lot of benefit to such a feature.

Do you agree with me about PANID vs Subnet or not?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Oct 2013 12:08:05 -0400

Ralph Droms (rdroms) <[email-masked]> wrote:
    > What is your definition for "subnet" that is compatible with the
    > definition from draft-ietf-6man-multicast-scopes:

    >   automatically configured, i.e., automatically derived from physical

    > I chose PAN ID as a way of identifying a "subnet" within a distribution
    > of MPL forwarders that might be within radio range of each other but
    > should be in separate MPL domains.  For example, suppose I have MPL
    > forwarders in my flat and you have MPL forwarders in your flat.  How do
    > my forwarders know they belong to the MPL domain in my flat while your
    > forwarders know they belong to the MPL domain in your flat.  PAN ID
    > would be one way to make that differentation.

PANID is too restrictive in my opinion.

I may well have a radio networks on the first floor of my (penthouse) flat,
and another radio network on the second floor of my flat, connected by any
number of wired (ethernet) or higher-powered wireless (wifi) layer-2
technologies.  There are good radio reasons to use different PANIDs,
because the isolation might be inconsistent.  The devices which connect my
two floors know they are supposed to do that at the RPL level, and so
subnet is the right thing.

This is where we need to be prescriptive.

---

From: Robert Cragie <[email-masked]>
Date: Tue, 15 Oct 2013 17:14:44 +0100

Yes, but your scenario is surely one where it cannot be automatically 
configured and therefore scope 4 is surely more applicable?

Robert

---

From: Don Sturek <[email-masked]>
Date: Tue, 15 Oct 2013 09:21:40 -0700

Hi Michael,

I don't see how scope 3 (automatically configured) fits with your example.

There would need to be some administrative configuration to let these
devices know that the two PANs you have should be linked in one domain.

Don

---

From: Ralph Droms <[email-masked]>
Date: Tue, 15 Oct 2013 09:22:38 -0700

> This is where we need to be prescriptive.

If I'm understanding your example correctly, I would say that the MPL domain you describe would use scop 4, administratively defined to cover the various radio domains.

I might also consider using scop 3 to simply forward across the mesh networks, with a broader scope and traditional multicast protocols to tie together the MPL domains with other links in the home network.

Suppose an application uses multicast address FF08::DB8:0:1234 in a network with RTR1 connected to MESH1 and some other links, and RTR2 connected to MESH2 and some other links.  RTR1 and RTR2 share at least on link.

One architecture would be to use traditional multicast protocols to connect the various links to which RTR1 and RTR2 are connected.  RTR1 and RTR2 then act as MPL encapsulators for MESH1 and MESH2.  Traffic on MESH1 looks like (hope the summarization is understandable)

   FF03:0:0:0:0:0:0:FC | MPL header | FF08::DB8:0:1234 | application payload

- Ralph

---

From: Don Sturek <[email-masked]>
Date: Tue, 15 Oct 2013 09:33:59 -0700

Hi Michael,

We should leave in scope 4 for use in administratively scoped domains.
This would allow applications to define specific multicast addresses using
scope 4 without having to go through the trouble to "un-reserve"
adminstrative scope.

Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope 3.
I don't see how any automatic configuration could take place if we can't
identify a concrete identifier for the scope.  The other alternative (and
to be honest the one I thought we were going to use) is DODAG ID.   This
would allow your scenario where a subnet of different link technologies
could support MPL domain 3.

Don

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 15 Oct 2013 16:37:23 +0000

> could support MPL domain 3.

Don - at present, MPL is, as far as I know, independent of RPL.  In particular, MPL can be used in a mesh that does not use RPL.  Therefore, there might not be a DODAG ID to use as a MPL domain identifier.

- Ralph

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Oct 2013 13:09:46 -0400

Don Sturek <[email-masked]> wrote:
    > Also, I am in favor of Ralph's proposal on using PAN ID for MPL scope
    > 3.  I don't see how any automatic configuration could take place if we
    > can't identify a concrete identifier for the scope.  The other
    > alternative (and to be honest the one I thought we were going to use)
    > is DODAG ID.  This would allow your scenario where a subnet of
    > different link technologies could support MPL domain 3.

I like DODAG ID. That suits me fine.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Oct 2013 13:16:20 -0400

> Don - at present, MPL is, as far as I know, independent of RPL.  In
    > particular, MPL can be used in a mesh that does not use RPL.
    > Therefore, there might not be a DODAG ID to use as a MPL domain
    > identifier.

While I agree with you, that MPL is separate from RPL in the same way that
HTTP can run over V32bis or ITU-T Rec. X.214 (OSI TPx) if we want it to,
if one want to use MPL in another environment one will have to specify
the boundaries somehow.

Using PANID limits one to 802.15.4-ish networks: what is the PANID of
ethernet?  ROLL is specifically chartered to work across a multitude of
different layer-2 protocols.

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 15 Oct 2013 13:17:35 -0400

On Tue, Oct 15, 2013 at 12:33 PM, Don Sturek <[email-masked]> wrote:

> If a host can be present simultaneously in more than one DODAG then
we run afoul of normative RFC 4007 behavior:

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

Link-local scope is essentially defined by a combination of link layer
connectivity and routing behavior.  I believe we need something similar
in order to automatically define scope 0x03.  To the extent that we need
scope 0x03 at all, I think it's to emulate classic link-local behavior in a
mesh.  There are only so many ways that meshes can be distinguished:
either by location, frequency, or code diversity (assuming any two of
three overlap).  In Ralph's example, he assumes location and frequency
overlap.  In Michael's example, I suspect he assumes location and PAN
ID overlap.

Finally, we may need to constrain Ralph's definition a bit further and
define an 802.15.4  scope 0x03 zone as a set of interfaces that share
a common PAN coordinator and PAN ID.

-K-

Don

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Oct 2013 13:17:56 -0400

> configured and therefore scope 4 is surely more applicable?

If the RPL can discover/build the network, then the MPL should automatically
use it.  Yes, I agree that I have to plug the cables in, and I probably
have to apply power.

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 15 Oct 2013 17:25:50 +0000

> overlap.  In Michael's example, I suspect he assumes location and PAN

Following up on Kerry's observation that a node can belong to more than one DODAG, how does such a node determine which DODAG to use for scop 3 forwarding, or which DODAG to use for filtering inbound scop 3 traffic?

- Ralph

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 15 Oct 2013 13:33:20 -0400

On Tue, Oct 15, 2013 at 1:16 PM, Michael Richardson
<[email-masked]>wrote:

> If MPL were defined in terms of scope 0x02 messages (as the Trickle
Algorithm is) we'd be done by now.  An MPL domain would then be the
set of links connected by  MPL forwarders, with the boundary set by
administratively opting out interfaces (a MPL domain boundary would
thus be defined as cutting through a node, not a link).

> Scope 0x03 is not defined on 802.3.  It is only needed at all on mesh
networks, therefore it is defined (or not) on a link layer basis.

-K-

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 15 Oct 2013 16:01:17 -0400

> Date: Tue, 15 Oct 2013 13:17:35 -0400
> From: Kerry Lynn <[email-masked]>
> 

I think you have to fall back on routing behavior.  Consider a
mixed-PHY mesh, such as a a combination of 802.15.4 and PLC
links.  If the routing layer considers it all one mesh, then it
is, regardless of whether or not there are any 802.15.4 nodes in
direct communication using the same PAN ID.  On the other hand,
the routing layer could take the same physical setup and treat it
as distinct 802.15.4 meshes with PLC interconnects, in which case
you would get multiple 0x03 scopes.

  I shall not today attempt further to define 0x03 scope; and
  perhaps I could never succeed in intelligibly doing so. But I
  know it when I see it.
                         (paraphrasing Justice Potter Stewart)

-Richard
This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product.  If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.  

Thank you.

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 15 Oct 2013 22:33:30 +0000

On Oct 15, 2013, at 1:01 PM 10/15/13, Richard Kelsey <[email-masked]> wrote:

> direct communication using the same PAN ID.

OK, but I don't think there is a good way to associate a specific MPL datagram with a DODAG ID, so a node can determine which scope 3 that MPL datagram is associated with.

And, using DODAG ID tightly couples MPL with RPL, when MPL as currently defined can be used without RPL.

I think scope 4 is a much better candidate for the "composite" subnet use case, while scope 3 is good for a single physical mesh.

- Ralph

>  On the other hand,

---

From: Robert Cragie <[email-masked]>
Date: Tue, 15 Oct 2013 23:50:49 +0100

Hi Kerry,

Comments inline.

I am in favour of using PAN ID as the basis for the MPL Domain Address 
with scope 3 for 802.15.4-based networks. The PAN ID is the fundamental 
identifier that groups nodes in a PAN and therefore forms a clear zone 
for multicast dissemination. Anything else is going to be an unclear 
superset or subset.

The language can get a bit circular so I think the statement for an 
802.15.4-based network is:

"An MPL Domain associated with an MPL Domain Address of 
ALL_MPL_FORWARDERS with a scope value of 3 (Realm-Local) is a scope zone 
within which the set of 802.15.4 MPL Interfaces subscribing to that MPL 
Domain Address all have the same PAN ID."

Compare with a similar statement for Admin-Local scope:

"An MPL Domain associated with an MPL Domain Address with a scope value 
of 4 (Admin-Local) is a scope zone within which the set of MPL 
Interfaces subscribing to that MPL Domain Address is administratively 
configured."

Robert

On 15/10/2013 18:17, Kerry Lynn wrote:
> On Tue, Oct 15, 2013 at 12:33 PM, Don Sturek <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Michael,
>
> connectivity and routing behavior.
<RCC>Link-local scope is defined by link layer connectivity only, 
surely? Where does routing behavior come into it?<.RCC>

> I believe we need something similar
> mesh.
<RCC>I agree with this, however it is not always clear what constitutes 
"the mesh". There has to be one thing in common with all the interfaces 
which participate in the mesh; PAN ID is an obvious choice and clearly 
sets the zone of scope 3 in this case. DODAG ID is another possibility 
but MPL propagation through MPL forwarders is not rooted at a single 
node so it is more like RPL-P2P in some respects.</RCC>
> There are only so many ways that meshes can be distinguished:
<RCC>I think that statement is tautological as the PAN coordinator 
dictates the PAN ID therefore must share the PAN ID. Therefore this 
reduces to sharing a PAN ID.</RCC>
>
> -K-
>
>
>     Don
>
>
>     On 10/15/13 8:59 AM, "Michael Richardson" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     >
>     >
>     >Don Sturek <[email-masked] <mailto:[email-masked]>> wrote:
>     >    > forwarding rules in a mesh network where flooding is not
>     used.  I
>     >would
>     >    > forwarding when flooding is not used but in a large mesh
>     network,
>     >there
>     >Michael Richardson <[email-masked]
>     <mailto:[email-masked]>>, Sandelman Software Works
>     >
>     >
>     >[email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Robert Cragie <[email-masked]>
Date: Tue, 15 Oct 2013 23:51:49 +0100

+1 to Ralph's comments below.

Robert

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 15 Oct 2013 21:23:24 -0400

Hi Robert,

Comments inline...

On Tue, Oct 15, 2013 at 6:50 PM, Robert Cragie
<[email-masked]>wrote:

> identifier that groups nodes in a PAN and therefore forms a clear zone for
> multicast dissemination. Anything else is going to be an unclear superset
> or subset.
>
> "An MPL Domain associated with an MPL Domain Address of ALL_MPL_FORWARDERS
> with a scope value of 3 (Realm-Local) is a scope zone within which the set
> of 802.15.4 MPL Interfaces subscribing to that MPL Domain Address all have
> the same PAN ID."
>
> <kel>
I feel that MPL should be defined strictly in terms of how it handles
different scopes and that the
definition of scope 0x03 belongs in the appropriate IP-over-foo RFC or an
update to same.
There's always the outside possibility that another (non 15.4) mesh data
link may emerge in
the future.  Also, as I suggested in an earlier email, the PAN ID based
definition should make
it clear we're talking about a set of interfaces that share physical
connectivity as well as PAN ID.

It should be possible to create an MPL Domain from traditional links (e.g.
ethernet) that only uses
scope 0x02 messages.
</kel>

> "An MPL Domain associated with an MPL Domain Address with a scope value of
> 4 (Admin-Local) is a scope zone within which the set of MPL Interfaces
> subscribing to that MPL Domain Address is administratively configured."
>
> <kel>
With the definition of scope 0x03, RFC 4007 requires a scope 0x04 zone to
fully encompass any
scope 0x03 zones that fall within its boundaries.  It seems the best use of
Admin-Local scope by
MPL may be to aggregate mesh and traditional links into larger MPL Domains.
</kel>

Robert
> <RCC>Link-local scope is defined by link layer connectivity only, surely?
> Where does routing behavior come into it?<.RCC>
>
> <kel>
To be more accurate, the boundary of a link-local zone is defined by the
lack of
forwarding.  RFC 4291 states:

  Routers must not forward any packets with Link-Local source or
  destination addresses to other links.

Thus, Link-Local scope zones may exist on adjacent links but they will be
disjoint.
</kel>

> which participate in the mesh; PAN ID is an obvious choice and clearly sets
> the zone of scope 3 in this case. DODAG ID is another possibility but MPL
> propagation through MPL forwarders is not rooted at a single node so it is
> more like RPL-P2P in some respects.</RCC>
>
> <kel>
My concern here is the case of overlapping DODAGs.  We cannot have
overlapping
zones of the same scope.

In practice, I think the definition of scope 0x03 using PAN ID for 802.15.4
networks
is transparent at layer 3.  It's a requirement that the node must filter by
PAN ID at
layer 2 and again this definition should be part of the IP-over-foo
specification.
</kel>

> dictates the PAN ID therefore must share the PAN ID. Therefore this reduces
> to sharing a PAN ID.</RCC>
>
> <kel>
OK, I was trying to prevent the interpretation that two PANs on opposite
sides
of the earth with the same PAN ID will be in the same scope zone.  There's
no
doubt a better way to state it.

BTW, I hope there's a method for two PAN coordinators on opposite sides of
a wall to ensure that they pick different PAN IDs?
</kel>

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

---

From: Robert Cragie <[email-masked]>
Date: Wed, 16 Oct 2013 09:37:56 +0100

Hi Kerry,

More comments inline, bracketed by <RCC2></RCC2>. In summary - I 
generally agree with what you say. There needs to be a decision on where 
to write the IP-over-foo scope 3 definition, especially for 
IP-over-802.15.4.

Robert

On 16/10/2013 02:23, Kerry Lynn wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Kerry,
>
>     Comments inline.
>
>     I am in favour of using PAN ID as the basis for the MPL Domain
>     Address with scope 3 for 802.15.4-based networks. The PAN ID is
>     the fundamental identifier that groups nodes in a PAN and
>     therefore forms a clear zone for multicast dissemination. Anything
>     else is going to be an unclear superset or subset.
>
>     The language can get a bit circular so I think the statement for
>     an 802.15.4-based network is:
>
>     ALL_MPL_FORWARDERS with a scope value of 3 (Realm-Local) is a
>     scope zone within which the set of 802.15.4 MPL Interfaces
>     subscribing to that MPL Domain Address all have the same PAN ID."
>
> <kel>
> definition of scope 0x03 belongs in the appropriate IP-over-foo RFC or 
> an update to same.
<RCC2>
In principle, I agree. Practically, what is the best way to achieve this?

 1. A 6lo-led RFC for all IP-over-foo
 2. Updates to all the existing IP-over-foo RFCs
 3. Lots of short RFCs for each IP-over-foo
 4. Start with 802.15.4 example in MPL

I think all are reasonable and there are bound to be other approaches 
which are reasonable as well. I think as already discussed it comes down 
to (3) or (4) to get draft-ietf-roll-trickle-mcast finished as quickly 
as possible.
</RCC2>

> There's always the outside possibility that another (non 15.4) mesh 
> data link may emerge in
> the future.
<RCC2>In this case, it should be clear that a statement regarding scope 
3 is included in the corresponding IP-over-foo RFC</RCC2>
> Also, as I suggested in an earlier email, the PAN ID based definition 
> should make
<RCC2>See below</RCC2>
>
> It should be possible to create an MPL Domain from traditional links 
> (e.g. ethernet) that only uses
> scope 0x02 messages.
<RCC2>It is now, however the MPL Domain will only reach one hop. We did 
discuss at length some time ago in the ZigBee IP community the merits of 
using scope 2 vs. scope 3 for propagating multicasts. The outcome was 
that both are feasible solutions but using scope 2 conceptually means 
multiple overlapping one-hop MPL domains in some arbitrary zone. To 
propagate multicasts in this arbitrary zone would mean administratively 
configuring MPL forwarder behaviour to ensure propagation. In practice, 
the difference is minimal but architecturally it is quite different</RCC2>
>     "An MPL Domain associated with an MPL Domain Address with a scope
>     value of 4 (Admin-Local) is a scope zone within which the set of
>     MPL Interfaces subscribing to that MPL Domain Address is
>     administratively configured."
>
> <kel>
> With the definition of scope 0x03, RFC 4007 requires a scope 0x04 zone 
> to fully encompass any
> scope 0x03 zones that fall within its boundaries.  It seems the best 
> use of Admin-Local scope by
<RCC2>I agree</RCC>
> To be more accurate, the boundary of a link-local zone is defined by 
> the lack of
> Thus, Link-Local scope zones may exist on adjacent links but they will 
> be disjoint.
> </kel>
<RCC2>Exactly - see earlier description of link-local MPL Domain based 
on scope 2</RCC2>
>     <RCC>I agree with this, however it is not always clear what
>     constitutes "the mesh". There has to be one thing in common with
>     all the interfaces which participate in the mesh; PAN ID is an
>     obvious choice and clearly sets the zone of scope 3 in this case.
>     DODAG ID is another possibility but MPL propagation through MPL
>     forwarders is not rooted at a single node so it is more like
>     RPL-P2P in some respects.</RCC>
>
> <kel>
> In practice, I think the definition of scope 0x03 using PAN ID for 
> 802.15.4 networks
> is transparent at layer 3.  It's a requirement that the node must 
> filter by PAN ID at
<RCC2>It's a tricky one this. I can sort of see the sense in wanting to 
limit propagation of a multicast to those nodes which have something in 
common with regard to routing. So in this sense, a DODAG ID would make 
sense. In that case, we have to rethink the idea of a MPL Domain being a 
scope zone and I'm not sure we want to go down that road again? So I do 
agree that if we are using scope zones, it has to be transparent at 
layer 3.</RCC2?
>     dictates the PAN ID therefore must share the PAN ID. Therefore
>     this reduces to sharing a PAN ID.</RCC>
>
> <kel>
> OK, I was trying to prevent the interpretation that two PANs on 
> opposite sides
> of the earth with the same PAN ID will be in the same scope zone.  
> There's no
<RCC2>OK, I see where you are coming from and I have no problem with the 
extra text for clarity purposes. However, the definition of PAN and thus 
PAN ID should preclude this. It is not allowed for overlapping PANs to 
have the same PAN ID and 802.15.4 has mechanisms to prevent and fix 
this. Given the definition of a zone is a connected region of topology, 
this means that two PANs on opposite sides of the earth with the same 
PAN ID cannot be in the same scope zone as they are not connected.  </RCC2>
>
>>
>>     -K-
>>
>>
>>         Don
>>
>>
>>         On 10/15/13 8:59 AM, "Michael Richardson"
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         >
>>         >
>>         >    > forwarding rules in a mesh network where flooding is
>>         not used.  I
>>         >would
>>         >Why have the code there to support scope-4 when there is no
>>         other
>>         >behaviour?
>>         >
>>         >    > forwarding when flooding is not used but in a large
>>         mesh network,
>>         >there

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 16 Oct 2013 13:04:32 -0400

Hi Robert,

My responses bracketed by <kel2/>...

On Wed, Oct 16, 2013 at 4:37 AM, Robert Cragie
<[email-masked]>wrote:

>  Hi Kerry,
>
> More comments inline, bracketed by <RCC2></RCC2>. In summary - I generally
> agree with what you say. There needs to be a decision on where to write the
> IP-over-foo scope 3 definition, especially for IP-over-802.15.4.
>
> <kel2> See below </kel2>

> On Tue, Oct 15, 2013 at 6:50 PM, Robert Cragie <
> [email-masked]> wrote:
>
>>  Hi Kerry,
>>
>> Comments inline.
>>
> <kel2>
I think Ralph's approach is the correct one.  His
draft-droms-6man-multicast-scopes belongs in
6man as it re-defines a reserved code point in the IPv6 addressing
architecture.  It nominally
updates RFC 4291 but should probably also update RFC 4007 as these RFCs are
in conflict
regarding the automatic definition of scope 0x03.

Ralph's draft says that scope 0x03 is defined on a network technology basis
and should be
published in an RFC.  Since 6LoWPAN is trying to close down, I think a
(short)  update to RFC
4944 could be done in 6lo.

Other 6lo drafts should define scope 0x03 (or not) for their particular
technology.  I think
scope 0x03 is unnecessary for any technology that doesn't have a hidden
node issue and
probably not necessary for all wireless data links.

MPL should be clear of technology discussion and just define forwarding
behavior on a
scope-by-scope basis.  For example, *if* it is possible to create a MPL
"Super-Domain"
from scope 2 domains, I expect the behavior would be to retransmit (or not,
as determined
by the Trickle Algorithm) on all active MPL interfaces but use a new source
address at
each hop.  You then have a set of connected one-hop tunnels and the seed
and sequence
data is preserved in the inner header.

For scope > 2 I expect the MPL Data packet would be re-transmitted
(forwarded) using
the original (received) source address.  Is it sufficient to just reference
Ralph's draft when
scope 0x03 is discussed in MPL and thus decouple the two discussions?
</kel2>

I think all are reasonable and there are bound to be other approaches which
> are reasonable as well. I think as already discussed it comes down to (3)
> or (4) to get draft-ietf-roll-trickle-mcast finished as quickly as possible.
> </RCC2>
>
>
> <RCC2>In this case, it should be clear that a statement regarding scope 3
> is included in the corresponding IP-over-foo RFC</RCC2>
>
> <kel2> Ralph's draft makes this clear. </kel2>

> using scope 2 vs. scope 3 for propagating multicasts. The outcome was that
> both are feasible solutions but using scope 2 conceptually means multiple
> overlapping one-hop MPL domains in some arbitrary zone. To propagate
> multicasts in this arbitrary zone would mean administratively configuring
> MPL forwarder behaviour to ensure propagation. In practice, the difference
> is minimal but architecturally it is quite different</RCC2>
>

<kel2>
I think it would have been better to use the term "MPL zone", especially
since an MPL Domain is
currently defined to be an RFC 4007 scope zone.  Since scope zones cannot
overlap, the same
must be true for MPL Domains.  However, I see you point when considering
MPL Forwarders
that only have a single 802.15.4 interface.  It seems they must function
like a router-on-a-stick
that forwards between VLANs on an ethernet link.
</kel2>

>> of 4 (Admin-Local) is a scope zone within which the set of MPL Interfaces
> scope 0x03 zones that fall within its boundaries.  It seems the best use
> of Admin-Local scope by
> <snip>

> is transparent at layer 3.  It's a requirement that the node must filter
> by PAN ID at
> agree that if we are using scope zones, it has to be transparent at layer
> 3.</RCC2?
>
> <kel2>
In the case of scope 0x02, a zone is defined by physical connectivity and
the nodes need
not have anything in common w.r.t. routing.  I assume it is possible to
have multiple DODAGs
in the same PAN (please correct me if that is not the case) and that the BR
can route between
them.  When extending our scope 0x02 intuition to scope 0x03 it seems the
only dependence
on routing behavior is in enabling a response to reach a requester.  Put
another way, I don't
think that source address should be considered in the MPL Forwarder's
decision to re-transmit
a packet.
</kel2>

> PAN ID should preclude this. It is not allowed for overlapping PANs to have
> the same PAN ID and 802.15.4 has mechanisms to prevent and fix this. Given
> the definition of a zone is a connected region of topology, this means that
> two PANs on opposite sides of the earth with the same PAN ID cannot be in
> the same scope zone as they are not connected.  </RCC2>
>
> <kel2>
I think you are saying that "same PAN ID" is sufficient to automatically
define a
scope 0x03 zone and I agree with your reasoning.

Regards, -K-
</kel2>

<snip>

---

From: peter van der Stok <[email-masked]>
Date: Thu, 17 Oct 2013 14:21:51 +0200

Dear all,

Looking at the discussion there seem to be two issues:
-1 tunnelling MC messages through MPL domain
-2 Sending multicast to all members of a mesh

I suggest to separate them to make the progress of MPL draft independent 
of 0x3 scope definition

Ad 1)
I understand that on reception by a seed of a MC message without MPL 
option, the wish is to encapsulate the message with a header which 
contains the MPL option to distribute the message over the mesh using 
MPL.
At reception of the message each receiver still needs to check whether 
the MC address in the original message is destined to the receiving 
node.
Therefore I think that the encapsulating header does not need the 
ALL_MPL_FORWARDERS multicast address but can be equal to the MC address 
of the original message.
This means that receiving nodes need to enable their interfaces to the 
MC-address stored in the header of the original message.
Given that the node needs to know this address anyway, I don't think 
this complicates the use of MPL.

This also works for a message leaving the MPL domain.

Any mistakes in my reasoning? Putting this text in section 5.1, and 
removing the text in section 4.1 can help the progress of MPL draft.

Ad 2)
There is a clear wish to distribute a MC message to all members of a 
mesh network, for example to distribute mdns messages or to learn lowpan 
start-up information like address of border router.
Making that the subject of IP_over_Foo drafts seems very reasonable to 
me.
The 6lo WG can provide an addendum to the 6lowpan RFC to provide an 
algorithm that makes it possible that all mesh members learn the same 
0x3 scope address, and enable the address.
Although MPL forwarders need to forward the message, the destinations 
are not necessarily MPL forwarders.
Identifying the MC address with the PAN-ID (given the PAN-ID does not 
change in spite of coordinator failures) of the mesh seems logical for 
IEEE802.15.4.

Sending a multicast to all members to a heterogeneous multi-link network 
looks like a different problem to me.

Hope this may help.

Peter

---

From: Ralph Droms <[email-masked]>
Date: Thu, 17 Oct 2013 09:10:50 -0700

Kerry correctly points out that RFC 4007 and RFC 4291 are in conflict regarding the way in which multicast scope 3 is defined:

RFC 4007, section 5:

   o  The boundaries of zones of a scope other than interface-local,
      link-local, and global must be defined and configured by network
      administrators.

RFC 4291, section 2.7:

         Admin-Local scope is the smallest scope that must be
         administratively configured, i.e., not automatically derived
         from physical connectivity or other, non-multicast-related
         configuration.

Noting this conflict, I propose adding a bit of text to draft-ietf-6man-multicast-scopes to update RFC 4007 for consistency with RFC 4291:

Add section 3 (and renumber current section 3-5):

3.  Updates to RFC 4007, section 5

   Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the
   way in which multicast scope 3 is configured.  To resolve that disagreement,
   change the last bullet in the list in section 5 of RFC 4007 as follows:

OLD:

   o  The boundaries of zones of a scope other than interface-local,
      link-local, and global must be defined and configured by network
      administrators.

NEW:

   o  Admin-Local scope is the smallest scope that must be
      administratively configured, i.e., not automatically derived
      from physical connectivity or other, non-multicast-related
      configuration.

Looking for consensus in the 6man WG before I make this change...

- Ralph

On Oct 16, 2013, at 10:04 AM 10/16/13, Kerry Lynn <[email-masked]> wrote:

> [...]

> I think Ralph's approach is the correct one.  His draft-droms-6man-multicast-scopes belongs in
> 6man as it re-defines a reserved code point in the IPv6 addressing architecture.  It nominally
> updates RFC 4291 but should probably also update RFC 4007 as these RFCs are in conflict
[...]

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 17 Oct 2013 12:16:37 -0400

On Thu, Oct 17, 2013 at 12:10 PM, Ralph Droms <[email-masked]> wrote:

> Kerry correctly points out that RFC 4007 and RFC 4291 are in conflict
> regarding the way in which multicast scope 3 is defined:
>
> RFC 4007, section 5:
>
> Noting this conflict, I propose adding a bit of text to
> draft-ietf-6man-multicast-scopes to update RFC 4007 for consistency with
> RFC 4291:
>
> +1

-K-

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 18 Oct 2013 02:43:20 -0000

Previous comments on this topic

 Thread from [07/11/13-07/26/13]: http://www.ietf.org/mail-
 archive/web/roll/current/msg08020.html

 Thread from [09/13/13-09/24/13]: http://www.ietf.org/mail-
 archive/web/roll/current/msg08158.html

 On 10/15/13 Thread: http://www.ietf.org/mail-
 archive/web/roll/current/msg08225.html

 <mrichd>

 Why do we need/want scope value 4 at all?
 I don't agree with using the PAN ID as the automatically configured
 criteria.  I think that subnet is the right thing.  RPL and MPL
 is specifically designed to cross layer-2.</mrichd>

 <ralphd>

 There apparently was interest in an administratively defined MP domain.
 scop 4 is available for that kind of domain.  If there is no interest,
 scop 4 need not be added.
 What is your definition for "subnet" that is compatible with the
 definition from draft-ietf-6man-multicast-scopes:

   automatically

 I chose PAN ID as a way of identifying a "subnet" within a distribution of
 MPL forwarders that might be within radio range of each other but should
 be in separate MPL domains.  For example, suppose I have MPL forwarders in
 my flat and you have MPL forwarders in your flat.  How do my forwarders
 know they belong to the MPL domain in my flat while your forwarders know
 they belong to the MPL domain in your flat.  PAN ID would be one way to
 make that differentation.</ralphd>

 <mrichd>

 I may well have a radio networks on the first floor of my (penthouse)
 flat,

 This is where we need to be prescriptive.</mrichd>

 <rcragi>

 Yes, but your scenario is surely one where it cannot be automatically
 configured and therefore scope 4 is surely more applicable?</rcragi>

 <mrichd>

 If the RPL can discover/build the network, then the MPL should
 automatically
 use it.  Yes, I agree that I have to plug the cables in, and I probably
 have to apply power.</mrichd>

 <donstk>

 I don't see how scope 3 (automatically configured) fits with your example.
 There would need to be some administrative configuration to let these
 devices know that the two PANs you have should be linked in one
 domain.</donstk>

 <ralphd>

 If I'm understanding your example correctly, I would say that the MPL
 domain you describe would use scop 4, administratively defined to cover
 the various radio domains.

 I might also consider using scop 3 to simply forward across the mesh
 networks, with a broader scope and traditional multicast protocols to tie
 together the MPL domains with other links in the home network.

 Suppose an application uses multicast address FF08::DB8:0:1234 in a
 network with RTR1 connected to MESH1 and some other links, and RTR2
 connected to MESH2 and some other links.  RTR1 and RTR2 share at least on
 link.

 One architecture would be to use traditional multicast protocols to
 connect the various links to which RTR1 and RTR2 are connected.  RTR1 and
 RTR2 then act as MPL encapsulators for MESH1 and MESH2.  Traffic on MESH1
 looks like (hope the summarization is understandable)

    FF03:0:0:0:0:0:0:FC | MPL header | FF08::DB8:0:1234 | application
 payload </ralphd>

 <donstk>

 lot of benefit to such a feature. </donstk>

 <mrichd>

 okay, so when we write a new protocol, we can specify this.
 Why have the code there to support scope-4 when there is no other
 behaviour?
 Do you agree with me about PANID vs Subnet or not? </mrichd>

 <donstk>

 could support MPL domain 3. </donstk>

 <ralphd>

 Don - at present, MPL is, as far as I know, independent of RPL.  In
 particular, MPL can be used in a mesh that does not use RPL.  Therefore,
 there might not be a DODAG ID to use as a MPL domain identifier. </ralphd>

 <mrichd>

 While I agree with you (ralph), that MPL is separate from RPL in the same
 way that
 HTTP can run over V32bis or ITU-T Rec. X.214 (OSI TPx) if we want it to,
 if one want to use MPL in another environment one will have to specify
 the boundaries somehow.
 Using PANID limits one to 802.15.4-ish networks: what is the PANID of
 ethernet?  ROLL is specifically chartered to work across a multitude of
 different layer-2 protocols. </mrichd>

 <kerlyn>

 thus be defined as cutting through a node, not a link).[[BR]]

 </kerlyn>

 <mrichd>

 I like DODAG ID. That suits me fine.</mrichd>

 <kerlyn>

 scope 0x03 at all, I think it's to emulate classic link-local behavior in
 a
 a common PAN coordinator and PAN ID. </kerlyn>

 <ralphd>

 Following up on Kerry's observation that a node can belong to more than
 one DODAG, how does such a node determine which DODAG to use for scop 3
 forwarding, or which DODAG to use for filtering inbound scop 3 traffic?
 </ralphd>

 <rkelsy>

   I shall not today attempt further to define 0x03 scope; and
   perhaps I could never succeed in intelligibly doing so. But I
   know it when I see it.
                          (paraphrasing Justice Potter Stewart) </rkelsy>

 <ralphd>

 OK, but I don't think there is a good way to associate a specific MPL
 datagram with a DODAG ID, so a node can determine which scope 3 that MPL
 datagram is associated with.

 And, using DODAG ID tightly couples MPL with RPL, when MPL as currently
 defined can be used without RPL.

 I think scope 4 is a much better candidate for the "composite" subnet use
 case, while scope 3 is good for a single physical mesh. </ralphd>

 <rcragi>

 “...I am in favour of using PAN ID as the basis for the MPL Domain Address
 with scope 3 for 802.15.4-based networks. The PAN ID is the fundamental
 identifier that groups nodes in a PAN and therefore forms a clear zone for
 multicast dissemination. Anything else is going to be an unclear superset
 or subset.

 "An MPL Domain associated with an MPL Domain Address with a scope value of
 4 (Admin-Local) is a scope zone within which the set of MPL Interfaces
 subscribing to that MPL Domain Address is administratively
 configured."...”

 “...Link-local scope is defined by link layer connectivity only, surely?
 Where does routing behavior come into it?...”

 “...it is not always clear what constitutes "the mesh". There has to be
 one thing in common with all the interfaces which participate in the mesh;
 PAN ID is an obvious choice and clearly sets the zone of scope 3 in this
 case. DODAG ID is another possibility but MPL propagation through MPL
 forwarders is not rooted at a single node so it is more like RPL-P2P in
 some respects….”

 “...the PAN coordinator dictates the PAN ID therefore must share the PAN
 ID. Therefore this reduces to sharing a PAN ID…” </rcragi>

 <kerlyn>

 “...I feel that MPL should be defined strictly in terms of how it handles
 different scopes and that the definition of scope 0x03 belongs in the
 appropriate IP-over-foo RFC or an update to same. There's always the
 outside possibility that another (non 15.4) mesh data link may emerge in
 the future.  Also, as I suggested in an earlier email, the PAN ID based
 definition should make it clear we're talking about a set of interfaces
 that share physical connectivity as well as PAN ID.

 It should be possible to create an MPL Domain from traditional links (e.g.
 ethernet) that only uses scope 0x02 messages….”

 “...With the definition of scope 0x03, RFC 4007 requires a scope 0x04 zone
 to fully encompass any
 scope 0x03 zones that fall within its boundaries.  It seems the best use
 of Admin-Local scope by
 MPL may be to aggregate mesh and traditional links into larger MPL
 Domains….”

 “...To be more accurate, the boundary of a link-local zone is defined by
 the lack of
 forwarding.  RFC 4291 states:

 disjoint....”

 “...My concern here is the case of overlapping DODAGs.  We cannot have
 overlapping
 zones of the same scope.

 specification....”

 “....OK, I was trying to prevent the interpretation that two PANs on
 opposite sides
 of the earth with the same PAN ID will be in the same scope zone.  There's
 no
 doubt a better way to state it.

 BTW, I hope there's a method for two PAN coordinators on opposite sides of
 a wall to ensure that they pick different PAN IDs?...” </kerlyn>

 On 10/16/13

 <rcragi>

 “... There needs to be a decision on where to write the IP-over-foo scope
 3 definition, especially for IP-over-802.15.4…”
 “...In principle, I agree. Practically, what is the best way to achieve
 this?

 A 6lo-led RFC for all IP-over-foo
 Updates to all the existing IP-over-foo RFCs
 Lots of short RFCs for each IP-over-foo
 Start with 802.15.4 example in MPL

 I think all are reasonable and there are bound to be other approaches
 which are reasonable as well. I think as already discussed it comes down
 to (3) or (4) to get draft-ietf-roll-trickle-mcast finished as quickly as
 possible….”

 “...it should be clear that a statement regarding scope 3 is included in
 the corresponding IP-over-foo RFC...”

 “...It is now, however the MPL Domain will only reach one hop. We did
 discuss at length some time ago in the ZigBee IP community the merits of
 using scope 2 vs. scope 3 for propagating multicasts. The outcome was that
 both are feasible solutions but using scope 2 conceptually means multiple
 overlapping one-hop MPL domains in some arbitrary zone. To propagate
 multicasts in this arbitrary zone would mean administratively configuring
 MPL forwarder behaviour to ensure propagation. In practice, the difference
 is minimal but architecturally it is quite different…”

 “...I can sort of see the sense in wanting to limit propagation of a
 multicast to those nodes which have something in common with regard to
 routing. So in this sense, a DODAG ID would make sense. In that case, we
 have to rethink the idea of a MPL Domain being a scope zone and I'm not
 sure we want to go down that road again? So I do agree that if we are
 using scope zones, it has to be transparent at layer 3….”

 “...the definition of PAN and thus PAN ID should preclude this. It is not
 allowed for overlapping PANs to have the same PAN ID and 802.15.4 has
 mechanisms to prevent and fix this. Given the definition of a zone is a
 connected region of topology, this means that two PANs on opposite sides
 of the earth with the same PAN ID cannot be in the same scope zone as they
 are not connected...” </rcragi>

 <kerlyn>

 “...I think Ralph's approach is the correct one.  His draft-droms-6man-
 multicast-scopes belongs in
 6man as it re-defines a reserved code point in the IPv6 addressing
 architecture.  It nominally
 updates RFC 4291 but should probably also update RFC 4007 as these RFCs
 are in conflict
 regarding the automatic definition of scope 0x03.

 Ralph's draft says that scope 0x03 is defined on a network technology
 basis and should be
 published in an RFC.  Since 6LoWPAN is trying to close down, I think a
 (short)  update to RFC
 4944 could be done in 6lo.

 MPL should be clear of technology discussion and just define forwarding
 behavior on a
 scope-by-scope basis.  For example, *if* it is possible to create a MPL
 "Super-Domain"
 from scope 2 domains, I expect the behavior would be to retransmit (or
 not, as determined
 by the Trickle Algorithm) on all active MPL interfaces but use a new
 source address at
 each hop.  You then have a set of connected one-hop tunnels and the seed
 and sequence
 data is preserved in the inner header.

 For scope > 2 I expect the MPL Data packet would be re-transmitted
 (forwarded) using
 the original (received) source address.  Is it sufficient to just
 reference Ralph's draft when
 scope 0x03 is discussed in MPL and thus decouple the two discussions?
 ...”
 “...I think it would have been better to use the term "MPL zone",
 especially since an MPL Domain is
 currently defined to be an RFC 4007 scope zone.  Since scope zones cannot
 overlap, the same
 must be true for MPL Domains.  However, I see you point when considering
 MPL Forwarders
 that only have a single 802.15.4 interface.  It seems they must function
 like a router-on-a-stick
 that forwards between VLANs on an ethernet link....”
 “... In the case of scope 0x02, a zone is defined by physical connectivity
 and the nodes need
 not have anything in common w.r.t. routing.  I assume it is possible to
 have multiple DODAGs
 in the same PAN (please correct me if that is not the case) and that the
 BR can route between
 them.  When extending our scope 0x02 intuition to scope 0x03 it seems the
 only dependence
 on routing behavior is in enabling a response to reach a requester.  Put
 another way, I don't think that source address should be considered in the
 MPL Forwarder's decision to re-transmit a packet....”
 “...I think you are saying that "same PAN ID" is sufficient to
 automatically define a
 scope 0x03 zone and I agree with your reasoning...” </kerlyn>

 On 10/17/13

 <ralphd>

 RFC 4007, section 5:

 RFC 4291, section 2.7:

 Noting this conflict, I propose adding a bit of text to draft-ietf-6man-
 multicast-scopes to update RFC 4007 for consistency with RFC 4291:

    Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the
    way in which multicast scope 3 is configured.  To resolve that
 disagreement,
    change the last bullet in the list in section 5 of RFC 4007 as follows:

 OLD:

 NEW:

 </ralphd>

Ticket URL: <http://tools.ietf.org/wg/roll/trac/ticket/132#comment:9>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 18 Oct 2013 02:47:25 -0000

From: peter van der Stok <stokcons at xs4all.nl>
 Date: Thu, 17 Oct 2013 14:21:51 +0200

 Thread: http://www.ietf.org/mail-archive/web/roll/current/msg08250.html

 "Looking at the discussion there seem to be two issues:

 Ad 1)

 I understand that on reception by a seed of a MC message without MPL
 option, the wish is to encapsulate the message with a header which
 contains the MPL option to distribute the message over the mesh using MPL.
 At reception of the message each receiver still needs to check whether the
 MC address in the original message is destined to the receiving node.
 Therefore I think that the encapsulating header does not need the
 ALL_MPL_FORWARDERS multicast address but can be equal to the MC address of
 the original message. This means that receiving nodes need to enable their
 interfaces to the MC-address stored in the header of the original message.
 Given that the node needs to know this address anyway, I don't think this
 complicates the use of MPL.
 This also works for a message leaving the MPL domain.

 Ad 2)

 There is a clear wish to distribute a MC message to all members of a mesh
 network, for example to distribute mdns messages or to learn lowpan start-
 up information like address of border router. Making that the subject of
 IP_over_Foo drafts seems very reasonable to me. The 6lo WG can provide an
 addendum to the 6lowpan RFC to provide an algorithm that makes it possible
 that all mesh members learn the same 0x3 scope address, and enable the
 address. Although MPL forwarders need to forward the message, the
 destinations are not necessarily MPL forwarders. Identifying the MC
 address with the PAN-ID (given the PAN-ID does not change in spite of
 coordinator failures) of the mesh seems logical for IEEE802.15.4.

 Hope this may help."

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/132#comment:10>
roll <http://tools.ietf.org/wg/roll/>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Oct 2013 09:05:36 -0400

On Oct 17, 2013, at 8:21 AM 10/17/13, peter van der Stok <[email-masked]> wrote:

> I suggest to separate them to make the progress of MPL draft independent of 0x3 scope definition
> 
> Ad 1)
> I understand that on reception by a seed of a MC message without MPL option, the wish is to encapsulate the message with a header which contains the MPL option to distribute the message over the mesh using MPL.
> At reception of the message each receiver still needs to check whether the MC address in the original message is destined to the receiving node.
> Therefore I think that the encapsulating header does not need the ALL_MPL_FORWARDERS multicast address but can be equal to the MC address of the original message.
> This means that receiving nodes need to enable their interfaces to the MC-address stored in the header of the original message.
> Given that the node needs to know this address anyway, I don't think this complicates the use of MPL.
> 
> Any mistakes in my reasoning? Putting this text in section 5.1, and removing the text in section 4.1 can help the progress of MPL draft.

This idea is interesting.  I don't know if the WG considered it.  

However, I'm not sure it's a simplification.  There are two functions in a MPL forwarding node: forwarding multicast traffic on to other nodes in the MPL domain and delivering traffic to local applications.  The former function requires that the node stack receive and forward all multicast traffic while the latter function uses the list of locally subscribed multicast addresses for local delivery.

I suppose there's no difference between a node accepting all multicast traffic for forwarding rather than using ALL_MPL_FORWARDERS in the outer header, and then delivering only subscribed traffic based on the inner header.

> 
> Ad 2)
> There is a clear wish to distribute a MC message to all members of a mesh network, for example to distribute mdns messages or to learn lowpan start-up information like address of border router.
> Making that the subject of IP_over_Foo drafts seems very reasonable to me.
> The 6lo WG can provide an addendum to the 6lowpan RFC to provide an algorithm that makes it possible that all mesh members learn the same 0x3 scope address, and enable the address.
> Although MPL forwarders need to forward the message, the destinations are not necessarily MPL forwarders.
> Identifying the MC address with the PAN-ID (given the PAN-ID does not change in spite of coordinator failures) of the mesh seems logical for IEEE802.15.4.

If I've got it right, you support publication of a very short RFC that gives the definition of IEEE802.15.4 scope 3 as the list of all interfaces that share the same PAN ID.

> 
> Sending a multicast to all members to a heterogeneous multi-link network looks like a different problem to me.

Agreed.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Oct 2013 15:56:46 -0400

On Oct 21, 2013, at 3:00 PM 10/21/13, 神明達哉 <[email-masked]> wrote:

> At Thu, 17 Oct 2013 09:10:50 -0700,
> Ralph Droms <[email-masked]> wrote:
> 
>> draft-ietf-6man-multicast-scopes to update RFC 4007 for consistency
>> with RFC 4291:
> 
> I think making these consistent is a good idea.
> 
>> OLD:
>> 
> I'm okay with the proposed text, but on a closer look I've noticed
> a couple of subtle points you may want to consider:
> 
> - I see a slight difference between the OLD (RFC 4007) and NEW (RFC
>  4291) even after fixing the obvious inconsistency, in that the NEW
>  version does not necessarily say how the scopes larger than
>  admin-local scope is configured; technically it only states
>  interface-local and link-local (and "Realm-Local" if assigned)
>  would not be automatically configured.  In fact, the global scope
>  shouldn't be "administratively" configured, which is crystal clear
>  from the OLD version, but not necessarily in the NEW version.
> 
> - should we worry about possible future updates to the addressing
>  architecture and scope architecture documents?  If we keep these
>  documents separately and have a copy of the text in both, we may need
>  to update both copies when we need to make a change on this point as
>  more "currently reserved" scopes are assigned.

Both good points.  As long as we have to make an update to RFC 4007, let's make sure the update is correct.

> 
> These are probably too minor and maybe we can simply ignore the
> subtlety.  If that's our consensus I'm okay with that.  But if we want
> to address these points, maybe:
> 
> OLD:
> 
>   o  The boundaries of zones of an interface-local, link-local, or
>      global scope automatically derived from physical connectivity.
>      For zones of other types of scopes, the IPv6 addressing
>      architecture specification defines how their boundaries must be
>      determined, whether automatically derived or administratively
>      configured.

Perhaps we want to go a step farther and take the zone boundary text out of RFC 4007 altogether?

OLD:

     administrators

NEW:

  o  The boundaries of zones of a scope are defined by the IPv6
     addressing architecture.

- Ralph

> JINMEI, Tatuya

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 23 Oct 2013 17:38:07 -0400

On Wed, Oct 23, 2013 at 5:21 PM, 神明達哉 <[email-masked]> wrote:

> At Wed, 23 Oct 2013 15:56:46 -0400,
> Basically works for me.
> With a reference (it's currently RFC 4291)?
>
> I'd also note that not all points described in the RFC 4007 text are
> described in RFC 4291 (at least not very clearly).  So, not just
> remove the text from RFC 4007, I'd like to unify it in the address
> architecture, e.g. update the following part of RFC 4291:
>
> as follows:
>          configuration.  For all non-reserved scopes except the global
>          scope, the zone boundaries must also be administratively
>          configured.
>
> I think this statement is self-contradictory.  When automatic
configuration is
discussed, it is in relation to zone boundaries.  Here's an attempt to
explain
this without negations:

    Interface-Local, Link-Local, and Realm-Local scope boundaries are
automatically
    derived from physical connectivity or other, non-multicast related
configuration.
    Global scope has no boundary.  The boundaries of all other non-reserved
scopes
    are administratively configured.

BTW, just my opinion, but "Realm-Local" might be more meaningfully named
"Multilink-Local"

-K-

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

---

From: Robert Cragie <[email-masked]>
Date: Thu, 24 Oct 2013 07:59:05 +0100

On 23 October 2013 22:38, Kerry Lynn <[email-masked]> wrote:

> <RCC>Me too</RCC>

>     Global scope has no boundary.  The boundaries of all other
> non-reserved scopes
<RCC>
That makes it clear. IMO RFC4007 should be changed to something like:

o  Each interface on a node comprises a single zone of interface-local
scope (for multicast only).

o  Each link and the interfaces attached to that link comprise a single
zone of link-local scope (for both unicast and multicast).

o  Multiple links and the interfaces attached to those links may form a
multilink-local scope based on underlying network technology; for example,
[cite the IP-over-IEEE802.15.4 definition].

o  There is a single zone of global scope (for both unicast and multicast)
comprising all the links and interfaces in the Internet.

o  The boundaries of zones of a scope other than interface-local,
link-local, multilink-local and global must be defined and configured by
network administrators.

Either that or just remove the text as Ralph suggested earlier.
</RCC>

> BTW, just my opinion, but "Realm-Local" might be more meaningfully named
<RCC> I agree - it is more meaningful</RCC>

---

From: peter van der Stok <[email-masked]>
Date: Fri, 25 Oct 2013 11:52:38 +0200

I like the consensus that seems to emerge.

It should be clear that the realm-local specification concerns a 
homogeneous multi-link network
For example:

  o Multiple links, following the same IP over Foo specification, and the 
interfaces attached to those links may form a multilink-local scope 
based on underlying network technology; for example, [cite the 
IP-over-IEEE802.15.4 definition].

Peter

Robert Cragie schreef op 2013-10-24 08:59:
>>>> Perhaps we want to go a step farther and take the zone boundary
>>> text
>>>> out of RFC 4007 altogether?
>>> 
>>> Basically works for me.
> 
> <RCC>Me too</RCC>
> 
>>>> OLD:
>>>> 
>> discussed, it is in relation to zone boundaries. Here's an attempt
>> to explain
>> 
>> this without negations:
>> 
> multilink-local scope based on underlying network technology; for
> example, [cite the IP-over-IEEE802.15.4 definition].
> 
> o There is a single zone of global scope (for both unicast and
> multicast) comprising all the links and interfaces in the Internet.
> 
> link-local, multilink-local and global must be defined and configured
> by network administrators.
> 
>>> Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6 [1]
>>> 
>> https://www.ietf.org/mailman/listinfo/roll [2]
> 
> 
> 
> Links:
> ------
> [1] https://www.ietf.org/mailman/listinfo/ipv6
> [2] https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Popa, Daniel" <[email-masked]>
Date: Fri, 25 Oct 2013 11:35:13 +0000

Hi Peter, 

By "homogeneous multi-link network" do you refer to "homogeneous link-layer technology" ? 

If this is the case, I suggest we do not correlate the scope of the multicast to the use of a specific link-layer technology... We should be able to deploy systems where all nodes in a multi-link network can be members of the same "multilink-local multicast scope", independently of the link-layer technology they use (homogeneous or heterogeneous) to communicate with each other.

Regards,
Daniel  

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de peter van der Stok
Envoyé : vendredi 25 octobre 2013 11:53
À : [email-masked]
Objet : Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local)

It should be clear that the realm-local specification concerns a homogeneous multi-link network For example:

  o Multiple links, following the same IP over Foo specification, and the interfaces attached to those links may form a multilink-local scope based on underlying network technology; for example, [cite the
IP-over-IEEE802.15.4 definition].

Peter

Robert Cragie schreef op 2013-10-24 08:59:
>>> administratively configured, i.e., not automatically derived from 
>>> physical connectivity or other, non-multicast-related configuration.
>>> 
>>> as follows:
>>> 
>>> administratively configured, i.e., not automatically derived from 
>>> physical connectivity or other, non-multicast-related configuration. 
>>> For all non-reserved scopes except the global scope, the zone 
>>> boundaries must also be administratively configured.
>> 
>> configuration is discussed, it is in relation to zone boundaries. 
>> Here's an attempt to explain
>> 
>> this without negations:
>> 
>>> IETF IPv6 working group mailing list [email-masked] Administrative 
>>> Requests:

---

From: Robert Cragie <[email-masked]>
Date: Fri, 25 Oct 2013 17:39:40 +0100

Hi Daniel,

I think the conclusion in that case was that scope 4 would have to be used
as it would be difficult to imagine anything other than administrative
configuration for a scope which spans multiple links on different link
layer technologies.

Robert
On 25 Oct 2013 12:35, "Popa, Daniel" <[email-masked]> wrote:

> If this is the case, I suggest we do not correlate the scope of the
> multicast to the use of a specific link-layer technology... We should be
> able to deploy systems where all nodes in a multi-link network can be
> members of the same "multilink-local multicast scope", independently of the
> link-layer technology they use (homogeneous or heterogeneous) to
> communicate with each other.
>
> Regards,
> Daniel
>
> Objet : Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was
> Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of
> 3 - subnet-local)
>
> homogeneous multi-link network For example:
>
> interfaces attached to those links may form a multilink-local scope based
> on underlying network technology; for example, [cite the

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 25 Oct 2013 19:35:50 -0000

Source: http://www.ietf.org/mail-archive/web/roll/current/msg08282.html

 From: Ralph Droms <rdroms.ietf at gmail.com> Date: Wed, 23 Oct 2013
 09:05:36 -0400

 > peter van der Stok <stokcons at xs4all.nl> wrote:
 >
 >...

 However, I'm not sure it's a simplification.  There are two functions in a
 MPL forwarding node: forwarding multicast traffic on to other nodes in the
 MPL domain and delivering traffic to local applications.  The former
 function requires that the node stack receive and forward all multicast
 traffic while the latter function uses the list of locally subscribed
 multicast addresses for local delivery.

 I suppose there's no difference between a node accepting all multicast
 traffic for forwarding rather than using ALL_MPL_FORWARDERS in the outer
 header, and then delivering only subscribed traffic based on the inner
 header.

 > ...

 If I've got it right, you support publication of a very short RFC that
 gives the definition of IEEE802.15.4 scope 3 as the list of all interfaces
 that share the same PAN ID.

 Agreed.

 - Ralph

 -----------------------------------------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08283.html

 From: Michael Richardson <mcr+ietf at sandelman.ca> Date: Wed, 23 Oct 2013
 14:19:38 -0400

 > Ticket #132:

     > draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 -
     > subnet-local

 I really don't understand the dispute, and it's gonna take some in-person
 discussion.  Not clear to me that it's going to be an edit to this
 document.
 ----------------------------------------------------------------------------------------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08284.html

 From: Ralph Droms <rdroms.ietf at gmail.com> Date: Wed, 23 Oct 2013
 14:36:38 -0400

 “...
 In my opinion, the problem is pretty clear:

  draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-scopes-00
  are in conflict with each other.

     When

 Part of the solution will require either a change in either draft-ietf-
 roll-trickle-mcast or draft-ietf-6man-multicast-scopes.  I think we have
 WG support, if not consensus, to edit draft-ietf-roll-trickle-mcast-05:

 OLD:

     When

 NEW:

     When
     used with MPL, Realm-Local scope is defined according to
     the underlying network technology; for example, [cite the
     IP-over-IEEE802.15.4 definition].

 One additional bit of text is needed, but not necessarily in draft-ietf-
 roll-trickle-mcast, to define explicitly the meaning of scop 3 in an
 IEEE802.15.4 network (which is the definition to be cited in the NEW text
 above):

 As a further refinement, I suggest text be added to draft-ietf-roll-
 trickle-mcast-05 to the effect of (this refinement has seen less WG
 discussion, in my opinion):

     "scop 4" can also be used with MPL to cover deployments
     that use administratively defined scopes that cover, for
     example, subnets based on different underlying network
     technologies.

 >  Not clear to me that it's going to be an edit to this document.draft-
 ietf-roll-trickle-mcast-05

 I'm pretty sure *something* has to be changed in draft-ietf-roll-trickle-
 mcast unless the definition of scop 3 is changed in draft-ietf-6man-
 multicast-scopes.

 - Ralph ”

 -------------------------------------------------------------------------------------------------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08285.html

 From: Kerry Lynn <kerlyn at ieee.org> Date: Wed, 23 Oct 2013 15:01:08
 -0400

 >... draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-
 scopes-00
 > are in conflict with each other….

 Note the above requirement (albeit with slightly different wording) comes
 from RFC 4291.

 +1
  > OLD:...
  > NEW:...

 I agree with draft-ietf-6man-multicast-scopes that the proper place for
 this definition is in
 an IP-over-foo RFC.  Specifically, any new 6lo drafts that desire to use
 an automatically
 configured scop 3 must define the link-layer technology specific attribute
 used to identify
 the scope zone.  So I think the proper way to set the precedent is to
 issue a short RFC
 in 6lo (given that 6LoWPAN is shutting down) to update RFC 4944.
 Otherwise, future
 protocols that wish to make use of scop 3 will have to reference Ralph's
 RFC plus the
 MPL RFC.

 >As a further refinement, I suggest text be added to draft-ietf-roll-
 trickle-mcast-05 to the >effect of (this refinement has seen less WG
 discussion, in my opinion):

    > "scop 4" can also be used with MPL to cover deployments
   >  that use administratively defined scopes that cover, for
    > example, subnets based on different underlying network
    > technologies.

 The place for this would be section 4.1, which currently says:
   An MPL Forwarder MAY participate in additional MPL Domains identified
    by other multicast addresses.  An MPL Interface MUST subscribe to the
    MPL Domain Addresses for the MPL Domains that it participates in.
    The assignment of other multicast addresses is out of scope.

 >>  Not clear to me that it's going to be an edit to this document.draft-
 ietf-roll-trickle-mcast-05

 >I'm pretty sure *something* has to be changed in draft-ietf-roll-trickle-
 mcast unless the >definition of scop 3 is changed in draft-ietf-6man-
 multicast-scopes.

 And, by extension, in RFC 4291.

 -K-

 -------------------------------------------------------------------------------------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08286.html

 From: Ralph Droms <rdroms.ietf at gmail.com> Date: Wed, 23 Oct 2013
 15:56:46 -0400

 >On Oct 21, 2013, at 3:00 PM 10/21/13, çæéå <jinmei at wide.ad.jp> wrote:

 > Ralph Droms <rdroms.ietf at gmail.com> wrote:
 >

 Both good points.  As long as we have to make an update to RFC 4007, let's
 make sure the update is correct.

 >      determined, whether automatically derived or administratively

 Perhaps we want to go a step farther and take the zone boundary text out
 of RFC 4007 altogether?

 OLD:

 NEW:

 - Ralph

 -------------------------------------------------------------------------------------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08287.html

 From: Kerry Lynn <kerlyn at ieee.org> Date: Wed, 23 Oct 2013 17:38:07
 -0400

 >On Wed, Oct 23, 2013 at 5:21 PM, ¿ 癆 明達哉 <jinmei at wide.ad.jp>
 wrote:
 >Ralph Droms <rdroms.ietf at gmail.com> wrote:

     Interface-Local, Link-Local, and Realm-Local scope boundaries are
 automatically
         derived from physical connectivity or other, non-multicast related
 configuration.
         Global scope has no boundary.  The boundaries of all other non-
 reserved scopes
         are administratively configured.

 -K-

 -------------------------------------------------------------------------------------------------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08288.html

 From: Robert Cragie <robert.cragie at gridmerge.com> Date: Thu, 24 Oct
 2013 07:59:05 +0100

 >On 23 October 2013 22:38, Kerry Lynn <kerlyn at ieee.org> wrote:

 <RCC>Me too</RCC>

 >  ...
 automatically
 configuration.
 >       Global scope has no boundary.  The boundaries of all other non-
 reserved scopes

 <RCC>

 o  The boundaries of zones of a scope other than interface-local, link-
 local, multilink-local and global must be defined and configured by
 network administrators.

 -------------------------------------------------------------------------------------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08289.html
 From: peter van der Stok <stokcons at xs4all.nl> Date: Fri, 25 Oct 2013
 11:52:38 +0200

 o Multiple links, following the same IP over Foo specification, and the
 interfaces attached to those links may form a multilink-local scope based
 on underlying network technology; for example, [cite the IP-over-
 IEEE802.15.4 definition].
 Peter

 -------------------------------------------------------------------------------------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08290.html
 From: "Popa, Daniel" <Daniel.Popa at itron.com> Date: Fri, 25 Oct 2013
 11:35:13 +0000

 Hi Peter,

 By "homogeneous multi-link network" do you refer to "homogeneous link-
 layer technology" ?

 If this is the case, I suggest we do not correlate the scope of the
 multicast to the use of a specific link-layer technology... We should be
 able to deploy systems where all nodes in a multi-link network can be
 members of the same "multilink-local multicast scope", independently of
 the link-layer technology they use (homogeneous or heterogeneous) to
 communicate with each other.

 Regards,
 Daniel

 -------------------------------------------------------------------------------------------------------------------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08291.html

 From: Robert Cragie <robert.cragie at gridmerge.com> Date: Fri, 25 Oct
 2013 17:39:40 +0100

 Hi Daniel,

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/132#comment:11>
roll <http://tools.ietf.org/wg/roll/>

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Fri, 25 Oct 2013 20:21:15 +0000

I think I read consensus from the WG to make the following changes to draft-ietf-6man-multicast-scopes, and list the document as "Updates RFC 4007":

*** Add as a new last paragraph in section 2:

   The following change is applied to section 2.7 of RFC 4291:

   OLD:

   NEW:

         Interface-Local, Link-Local, and Realm-Local scope boundaries
         are automatically derived from physical connectivity or
         other, non-multicast related configuration.  Global scope has
         no boundary.  The boundaries of all other non-reserved scopes
         are administratively configured.

*** Add section 3 (and renumber current section 3-5):

OLD:

NEW:

   o  The boundaries of zones of a scope are defined by the IPv6
      addressing architecture [RFC4291].

I haven't seen any discussion of changing Realm-Local to Multilink-Local beyond Kerry's initial suggestion and Robert's support of the change.

- Ralph

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Fri, 25 Oct 2013 20:44:57 +0000

On Oct 25, 2013, at 4:38 PM 10/25/13, Dave Thaler <[email-masked]> wrote:

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Ralph Droms (rdroms)
>> Sent: Friday, October 25, 2013 1:21 PM
>> To: [email-masked]
>> Cc: Routing Over Low power and Lossy networks
>> Subject: Re: draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re:
>> [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 -
>> subnet-local)
>> 
>> I think I read consensus from the WG to make the following changes to draft-
>> ietf-6man-multicast-scopes, and list the document as "Updates RFC 4007":
>> 
> I disagree with the last sentence above.  Specifically
> "non-reserved" should be removed.  That is, we should not start
> precluding admin configuration of reserved scopes, given we didn't
> before.  They just didn't have defined names or uses, but they could
> have been used within private environments.

Good catch.  So the last sentence should read:

  The boundaries of all other scopes are administratively configured.

?

- Ralph

> -Dave
>> I haven't seen any discussion of changing Realm-Local to Multilink-Local
>> beyond Kerry's initial suggestion and Robert's support of the change.
>> 
>> - Ralph
>> 
>>>> draft-droms-6man-multicast-scopes belongs in 6man as it re-defines a
>>>> reserved code point in the IPv6 addressing architecture.  It
>>>> nominally updates RFC 4291 but should probably also update RFC 4007 as
>> these RFCs are in conflict regarding the automatic definition of scope 0x03.
>>> [...]
>>> 
>>

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 25 Oct 2013 17:06:26 -0400

On Fri, Oct 25, 2013 at 4:44 PM, Ralph Droms (rdroms) <[email-masked]>wrote:

> Logically, the last sentence above doesn't entail how the boundaries
of reserved scopes are configured (the inference is that they may be
administratively or automatically configured).

> This makes it clear that the boundary of 11 of the 15 scopes defined in
RFC 4291 sect 2.7 (including 0) are administratively configured.  So it
is not equivalent in meaning to the old text if that was the intention.

-K-

- Ralph
> draft-ietf-6man-

---

From: "roll issue tracker" <[email-masked]>
Date: Tue, 29 Oct 2013 12:52:32 -0000

-------------------------------------------------------------------------------------------------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08296.html

 From: "Ralph Droms (rdroms)" <rdroms at cisco.com> Date: Fri, 25 Oct 2013
 19:56:42 +0000

 There was a long discussion about this issue on the roll at ietf.org
 mailing list:

   When

 I think I've read consensus in the various discussion threads to make the
 following change to draft-ietf-roll-trickle-mcast-05:

 OLD:

    When

 NEW:

    When
    used with MPL, Realm-Local scope is defined according to the
    underlying network technology; for example, [cite the
    IP-over-IEEE802.15.4 definition].

 where "the IP-over-IEEE802.15.4 definition" is text to be published
 elsewhere (perhaps draft-ietf-6man-multicast-scopes) that defines scop 3
 for IEEE802.15.4 mesh networks.

 I read less strong consensus (less discussion) of the following proposed
 changes:

 NEW (to be added immediately following text describing the use of Realm-
 Local scope):

   Admin-Local scope (scop value 4) can also be used with MPL
   in deployments that use administratively defined scopes that
   cover, for example, multiple subnets based on different
   underlying network technologies.

 As a side note, there is a related discussion about draft-ietf-6man-
 multicast-scopes on the 6man at ietf.org mailing list.  The term "Realm-
 Local scope" may change (should be changed for consistency with) the final
 published version of draft-ietf-6man-multicast-scopes.

 - Ralph

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08294.html

 From: "Ralph Droms (rdroms)" <rdroms at cisco.com> Date: Fri, 25 Oct 2013
 20:21:15 +0000

 I think I read consensus from the WG to make the following changes to
 draft-ietf-6man-multicast-scopes, and list the document as "Updates RFC
 4007":

    OLD:

    NEW:

 OLD:

 NEW:

 - Ralph

 -------------------------------------------------------------------------------------------------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08295.html

 From: "Ralph Droms (rdroms)" <rdroms at cisco.com> Date: Fri, 25 Oct 2013
 20:44:57 +0000

 On Oct 25, 2013, at 4:38 PM 10/25/13, Dave Thaler <dthaler at
 microsoft.com> wrote:

 >> From: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On
 Behalf Of
 >> To: 6man at ietf.org

 ?

 - Ralph

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08296.html

 From: Kerry Lynn <kerlyn at ieee.org> Date: Fri, 25 Oct 2013 17:06:26
 -0400

 >On Fri, Oct 25, 2013 at 4:44 PM, Ralph Droms (rdroms) <rdroms at
 cisco.com> wrote:

 >>On Oct 25, 2013, at 4:38 PM 10/25/13, Dave Thaler <dthaler at

 -K-

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/132#comment:12>
roll <http://tools.ietf.org/wg/roll/>