(I didn't have time to write a shorter note)

glossary for 6man readers:
      RPL = ROLL RFC6550 mesh-over routing protocol.
      MPL = ROLL draft-ietf-trickle-mcast multicast distribution
            protocol.

This email is a bit long, but represents what I believe was the
consensus that was arrived at by a number of ROLL WG ID authors, some
Zigbee IP experts, and Ralph.  This consensus was arrived at slowly
over Tuesday night and Wednesday, and was brought to you by the letters
B and I.  

I will start with the executive summary:

1) there are some minor tweaks necessary to trickle-mcast to make
   it consistent with multicast-scopes, and to indicate that 
   encapsulation in scopes 4 and 5 are appropriate for some use cases

2) that the text in multicast-scopes that speaks of "administratively
   defined" is confusing to many, and a suggestion on different text
   will be posted in a reply to this email.

=== background and discussion

Trickle-mcast must use/define scope 3 in order to get traffic to flow
across the entire RPL LLN (mesh-over).   The current multicast-scopes
document makes scope 3 span all the interfaces of the nodes of a single
instance of a technology.  The intention was that IP-over-FOO documents
would explain how this is defined, with the understanding that for
802.15.4 it would span all interfaces which are in a single PAN-ID.

RPL, however, can and does run over many different link types, and there
are existing deployed systems that have mixes of
802.15.4/802.15.4G/802.11*/802.3(wired), in some cases, with the
technologies even alternating on a hop by hop basis.   Both Zigbee IP,
metering and home systems need to span multiple technologies for
multicast, and Zigbee IP SEP 2 specifies using multicast to do service
discovering using mDNS.  

Many want to automatically configure a multicast scope to cover all of
the interfaces which are part of an RPL DODAG and/or that an address in
the same (multi-link subnet) prefix.   There was many months of
confusing discussion about having this be the definition of scope 3, but
the alternate view was that MPL was not tied to RPL, and that neither the
DODAG nor the prefix were inherent physical properties of the network in
the way that a set of cables and a switch or a radio with a specific
PANID.

The origin of the second mis-understanding was that the text in
multicast-scopes (and rfc 4291) says:

         Admin-Local scope is the smallest scope that must be
         administratively configured, i.e., not automatically derived

The understanding of "administratively configured" for many people
implies truck rolls, or ssh logins or router CLI commands.  It was
only when this assumption was clearly articulated that the origin of the
conflict became clear to all parties.

The new understanding is that "administratively configured" is not
limited to the things that a human did it, but rather includes any
processes or operations that a human (including an IETF document) might
cause.   The intent of multicast-scopes is not to limit ways that 
scopes 4+ can be determined, but to clarify that scopes <=3 are *not*
intended to be defined by a physical (or physical-like) topologies.

To put it another way, a human, looking at some non-virtualized
equipement likely can determine the extent of scope 1,2,3 even if there
is no power connected.

The conclusion was that the group reached was that scope 3 can be
defined on a per-technology basis, and in wireless links such as
the 802.15.4 PANID.   Where exactly to define this is still an open
question, but we did conclude that the place is *not* in trickle-mcast.
We are undecided if we need another worlds-shortest-RFC on 805.15.4
(effectively a 6lowpan/6lo/6man document) vs in multicast-scopes, but
another RFC is preferred by most. (Perhaps; all) 

In another place, to be determined, possibly in applicability
statements, or possibly in an application specific document
(e.g. something like "mdns-over-lln"), a process by which a scope 4
multicast boundary could be defined to be something like the set of all
interfaces which are in at least one DODAG.

It should fall to homenet to define scope 5 for use in the home to cover
the set of interfaces which are in the inside of the homenet.  This
should be easy for homenet to articulate discover of the homenet
boundary is already a work item.    The LLN border router would be
speaking homenet routing protocol on the interface that connects it to
the homenet, and would include the LLN scope 4 zone as part of the scope
5 homenet.

This implies that LLNs will be using scope 5 to do mDNS resolution, and
that this packet will be carried through the LLNs various links
encapsulated into a scope 3 packet.   While it is likely that dnssd will
not solve the multi-subnet problem using straight multicast, but rather
using a proxy mechanism, use of scope 5 is agnostic to exactly how this
would be done.
A mote that wishes to resolve only within the LLN may use scope 3 or 4,
while one that wants to possibly find things in any place of the home
will use scope 5.  

Michael Richardson
-on the road-