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

["roll issue tracker" <[e-mail]>]

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


Comment (by [e-mail]):

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

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

 From: "Michael Richardson" <mcr+ietf at sandelman.ca>[[BR]]

 Date: Fri, 08 Nov 2013 15:23:54 -0500[[BR]]


 glossary for 6man readers:
       RPL = ROLL RFC6550 mesh-over routing protocol.[[BR]]

       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-

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

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