Subject: [Roll] dinner consensus on trickle-mcast and multicast-scoopes

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Nov 2013 15:44:52 -0500

(I didn't have time to write a shorter note)
(Resending because I got the 6man list address wrong. Wish there was an alias)

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-

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 8 Nov 2013 18:25:08 -0800

Michael,

Thank you for transcribing the Scopes Trial.  I have added some
comments below.  <kel/>

On Fri, Nov 8, 2013 at 12:44 PM, Michael Richardson <[email-masked]>wrote:

> Please also consider adding encapsulation of data in scope 2 messages
so that MPL can be used in environments where scopes 3 - 5 are not
defined.  <kel/>

> across the entire RPL LLN (mesh-over).

Can we limit this to "must use"?  It is for draft-ietf-6man-multicast-scopes
to define scope 3.  <kel/>

> The current multicast-scopes
> SEP2.0 is now IEEE 2030.5  <kel/>

> The paragraph above from RFC 4291 continues:

     from physical connectivity or other, non-multicast-related
     configuration.

So draft-ietf-6man-multicast-scopes may require some adjustments
to *allow* automatic determination of boundaries of scope >= 4
based on non-multicast-related configuration.  <kel/>

> I think you mean that boundaries for scopes <= 3 *are* automatically
derived from some physical connectivity relation whereas for scopes
>= 4 they are not?  <kel/>

> Just to summarize to this point, boundaries of scopes >= 4 may be
determined by configuration under certain circumstances.  However, the
constraints imposed by RFC 4007 cannot be violated.  So the definition
example above is only applicable if the DODAG completely contains
any and all scope 3 zones that fall within its borders.  In situations where
multiple DODAGs are defined over a connected topology satisfying the
scope 3 definition, a scope 4 boundary cannot be determined by the
DODAG definition.  Also, once defined, the zone boundary is the same
for all applications using that multicast scope.  <kel/>

> encapsulated into a scope 3 packet.

This behavior has been specified by SEP2 based on an expired experimental
draft.  It is beyond unlikely that dnssd WG will adopt this approach. Note
that homenet would have to adopt some multicast routing protocol in order
to forward scope 5 multicast if there are multiple non-LLN links.  <kel/>

While it is likely that dnssd will
> This raises an interesting question from the application perspective.
As I mentioned at the mic today in dnssd, RFC 6762 says:

     Any DNS query for a name ending with ".local." MUST be sent to the
     mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6
     equivalent FF02::FB).

draft-lynn-homenet-site-mdns took the same approach and designated
".site." as a special domain to signal the application's intent that the
query should be delivered to the site-local zone FF05::FB.  This is the
draft that helped precipitate the earlier gTLD discussion with ICANN
that was referred to in dnssd today.  We may need a more general
mechanism for applications that use Variable Scope Multicast
Addresses to signal the desired scope to the lower layer(s) (or perhaps
always default to the largest locally defined scope?)

-K-

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

---

From: Ralph Droms <[email-masked]>
Date: Sun, 10 Nov 2013 09:02:26 -0600

>   encapsulation in scopes 4 and 5 are appropriate for some use cases

Thanks, Michael, for writing up the discussion that led to the conclusions in your executive summary.

Here is my summary of what needs to be changed in draft-ietf-trickle-mcast:

In section 4.1:

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
   identified by the ALL_MPL_FORWARDERS multicast address with a scope
   value of 3 (Realm-Local) [I-D.ietf-6man-multicast-scopes].    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].

   Admin-Local scope (scop value 4) and Site-Local scope (scop value
   5) 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.

where "the IP-over-IEEE802.15.4 definition" is text to be published elsewhere (as determined by the 6man WG) as an update to RFC 4291 that defines scop 3 for IEEE802.15.4 mesh networks.

>   will be posted in a reply to this email.

To be precise, RFC 4291 and (in updating RFC 4291) both refer to "administratively configured" rather than "administratively defined".  RFC 4007 refers to "zones [...] defined and configured by network administrators".  If there is consensus in the 6man WG that "administratively configured" and the text from RFC 4007 needs to be clarified, the clarification should apply to RFC 4291 and RFC 4007.  That clarification could be included in draft-ietf-6man-multicast-scopes, as part of that document's updates to RFC 4291 and RFC 4007.

> [...]

- Ralph