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]):

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


 From: Kerry Lynn <kerlyn at ieee.org> 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
 <[e-mail]>wrote:
 > ….
 > 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/>



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




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




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



 >...
 > 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?)<kel/>



 -K-

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

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



 From: Ralph Droms <rdroms.ietf at gmail.com>
 Date: Sun, 10 Nov 2013 09:02:26 -0600




 On Nov 8, 2013, at 2:44 PM 11/8/13, Michael Richardson <mcr at
 sandelman.ca> wrote:

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

 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.

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

 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

-- 
---------------------------------------+------------------------------
 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://tools.ietf.org/wg/roll/trac/ticket/132#comment:16>
roll <http://tools.ietf.org/wg/roll/>