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

[Kerry Lynn <[e-mail]>]

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 <[e-mail]>wrote:

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

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


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


> 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.
>
> SEP2.0 is now IEEE 2030.5  <kel/>


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

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


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

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.


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
> 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.
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>