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

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Nov 2013 17:46:25 -0400

Michael Richardson <[email-masked]> wrote:

> I would like to ask the WG to speak now if you object to this 
> solution, specifically with the the text going into mcast-05.

Please EMAIL/POST/COMMUNICATE before 2013-11-08 (next Friday).

--
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Nov 2013 16:44:42 -0400

Ralph wrote:
>  This text could be added to draft-ietf-roll-trickle-mcast-05, or to
>  draft-ietf-6man-multicast-scopes-00 or published separately in yet
>  another "world's shortest RFC".
> 
>  Second, draft-ietf-roll-trickle-mcast-05 should be changed to read:
> 
>     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].
> 
>  As a further refinement, I suggest text be added to
>  draft-ietf-roll-trickle-mcast-05 to the effect of:
> 
>     "scop 4" can also be used with MPL to cover deployments that use
>     administratively defined scopes that cover, for example, subnets
>     based on different underlying network technologies.
> 
>  - Ralph

---

From: Kerry Lynn <[email-masked]>
Date: Sat, 2 Nov 2013 11:54:12 -0400

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

> Here's a summary the situation:
- draft-ietf-roll-trickle-mcast ("MPL draft") defines a multicast transport
  protocol.  It refers to scop 3 which has up to now been reserved.
- draft-ietf-6man-multicast-scopes ("Scopes draft") defines scop 3 and
  states it must be automatically determined by data link connectivitiy.
  It recommends the proper place to define how the scope zone boundary
  is determined is in the "IP-over-Foo" draft for each data link that
defines
  scop 3.
- The MPL draft *must* reference the Scopes draft in order to utilize
  scop 3.  It must also agree with the Scopes draft on the issue of whether
  the scop 3 boundary is automatically determined.  This is included in
  issue #132 and REMAINS OPEN.
- Another open question is where to locate the definition of scop 3 for
  802.15.4 networks?

Going by the recommendation in the Scopes draft, one solution for the
latter is to issue a short update to RFC 4944.  However, this is not the
most expedient solution from the standpoint of finishing the MPL draft.

The next best solution in my opinion is to place the 802.15.4 definition of
scop 3 into the Scopes draft.  Future data links that define scop 3 in their
IP-over-Foo RFCs will then only need to reference the Scopes document
for the precedent and not the MPL document as well.  Since the MPL draft
must already reference the Scopes draft anyway, this also solves one
open issue for MPL.

I personally think it's a bad idea to bury the definition of an
automatically
determined scope boundary for a particular data link within a transport
protocol specification.

Regards, -K-

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

---

From: <[email-masked]>
Date: Sun, 3 Nov 2013 08:09:09 +0000

I prefer describing 802.15.4-specific realm-local scope boundary definition in another RFC so that both trickle-mcast and multicast-scopes drafts are fully independent of any link-layer.   

Regards,
Yoshihiro Ohba

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Saturday, November 02, 2013 5:45 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local

I would like to ask the WG to speak now if you object to this solution, specifically with the the text going into mcast-05.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Nov 2013 13:30:16 -0500

<[email-masked]> wrote:
    > I prefer describing 802.15.4-specific realm-local scope boundary
    > definition in another RFC so that both trickle-mcast and
    > multicast-scopes drafts are fully independent of any link-layer.

Are you willing to write this document?

---

From: Kerry Lynn <[email-masked]>
Date: Sun, 3 Nov 2013 17:30:41 -0500

On Sun, Nov 3, 2013 at 1:30 PM, Michael Richardson <[email-masked]>wrote:

> Let's scope the effort this week.  Ralph predicts it will be the World's
shortest RFC; maybe we can get it right the first time.

-K-

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Sun, 3 Nov 2013 23:16:31 +0000

On Nov 3, 2013, at 10:30 AM, "Michael Richardson" <[email-masked]<mailto:[email-masked]>> wrote:

<[email-masked]<mailto:[email-masked]>> wrote:
I prefer describing 802.15.4-specific realm-local scope boundary
definition in another RFC so that both trickle-mcast and
multicast-scopes drafts are fully independent of any link-layer.

In my opinion, the roll WG gets to answer the question "should realm-specific scope for 802.15.4 be defined in draft-ietf-roll-trickle-mcast?"

If the consensus is no (which would be my answer), then, in my opinion, it's up to 6nan to decide between putting the definition in the multicast scopes doc or a separate RFC.

- Ralph

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works

---

From: <[email-masked]>
Date: Mon, 4 Nov 2013 00:31:54 +0000

If we choose to write another RFC, yes I can contribute to it.

Regards,
Yoshihiro Ohba

---

From: "Popa, Daniel" <[email-masked]>
Date: Mon, 4 Nov 2013 10:03:20 +0000

Hello all, 

I support the idea of having the definition of multicast scope boundary in another RFC so that trickle-mcast and multicast-scopes drafts specify such IP features independent of the link-layer. 

And I am willing to  contribute and help writing such RFC. 

I will unfortunately not be able to attend this IETF meeting, but I will be available via email.

Regards,
Daniel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 4 novembre 2013 01:32
À : [email-masked]
Cc : [email-masked]; [email-masked]; Cisco-Johnathan Hui; [email-masked]
Objet : Re: [Roll] Consensus Call -- resolution for #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local

Regards,
Yoshihiro Ohba

---

From: Robert Cragie <[email-masked]>
Date: Mon, 04 Nov 2013 15:21:54 +0000

On 03/11/2013 23:16, Ralph Droms (rdroms) wrote:
>
>
> On Nov 3, 2013, at 10:30 AM, "Michael Richardson" 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote:
> In my opinion, the roll WG gets to answer the question "should 
> realm-specific scope for 802.15.4 be defined in 
> draft-ietf-roll-trickle-mcast?"
>
> If the consensus is no (which would be my answer), then, in my 
> opinion, it's up to 6nan to decide between putting the definition in 
> the multicast scopes doc or a separate RFC.
+1 - my answer would also be no. I guess that should be 6man as well.
>
> - Ralph
>
>>
>> -- 
>> Michael Richardson <[email-masked] 
>> <mailto:[email-masked]>>, Sandelman Software Works
>>
>>
>
>

---

From: "roll issue tracker" <[email-masked]>
Date: Tue, 05 Nov 2013 12:32:39 -0000

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

Comment (by [email-masked]):

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

 From: JINMEI, Tatuya <jinmei at wide.ad.jp>
 Date: Mon, 28 Oct 2013 09:46:48 -0700

 At Fri, 25 Oct 2013 20:44:57 +0000,
 "Ralph Droms (rdroms)" <rdroms at cisco.com> wrote:

 > >>   NEW:
 > >>
 > >>         Interface-Local, Link-Local, and Realm-Local scope boundaries
 > >>         are automatically derived from physical connectivity or
 > >>         other, non-multicast related configuration.  Global scope has
 > >>         no boundary.  The boundaries of all other non-reserved scopes
 > >>         are administratively configured.
 > >
 > > I disagree with the last sentence above.  Specifically
 > > "non-reserved" should be removed.  That is, we should not start
 > > precluding admin configuration of reserved scopes, given we didn't
 > > before.  They just didn't have defined names or uses, but they could
 > > have been used within private environments.
 >
 > Good catch.  So the last sentence should read:
 >
 >   The boundaries of all other scopes are administratively configured.

 First off, whether we include "non-reserved" or not, we should clarify
 this only applies to admin-local or larger.  So, e.g.

    The boundaries of all other scopes of Admin-Local or larger are
    administratively configured.

 Secondly, I don't think the "NEW" text (necessarily) precludes admin
 configuration of reserved scopes (in this context it specifically
 means scope 15).  With "non-reserved", I meant it specifically means
 scopes # 5-13.  It intended to not say about scope #15, rather than
 preclude admin configuration for it.  On the other hand, the suggested
 revised version  explicitly states that the boundaries of scope #15
 are administratively configured.  I don't know if that's what this
 scope was supposed to be.  If it was, then this version is okay.  If
 not, and if the "NEW" version was confusing, I suggest:

   The boundaries of all other non-reserved scopes of Admin-Local or
   larger are administratively configured.  For reserved scopes, the
   way of configuring their boundaries will be defined when the
   semantics of the scope is defined.

 --
 JINMEI, Tatuya

 <stigVenaas> Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08322.htm

 I think this text might be fine. The main thing I want to say is that
 manual configuration of unassigned scopes is fine (as long as not
 reserved). But I don't think we want anyone to use reserved scopes in
 any way. Scope #14 is global and I don't think we have a meaningful
 way of using #15.

 </stigVenaas>

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

 Source:
 From: Michael Richardson <mcr+ietf at sandelman.ca>
 Date: Fri, 1 Nov 2013 16:41:55 -0400 (EDT)

 Robert Cragie <robert.cragie at gridmerge.com> wrote:

 > I would propose adding the language to
 > draft-ietf-roll-trickle-mcast. There doesn't seem much point to doing

 I agree.

 Michael Richardson

 <kerryLynn> Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08305.html

 I disagree, and think the text should be placed in draft-ietf-6man-
 multicast-scopes
 for reasons stated in the Issue #132 thread.

 -K-

 </kerryLynn>

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

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

---

From: "roll issue tracker" <[email-masked]>
Date: Tue, 05 Nov 2013 12:44:03 -0000

'''CONSENSUS CALL''' -- resolution for #132: draft-ietf-roll-trickle-
 mcast-04 - Clarify scope value of 3 - subnet-local

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

 From: Michael Richardson <mcr+ietf at sandelman.ca>
 Date: Fri, 01 Nov 2013 16:44:42 -0400

 --
 Michael Richardson <mcr+IETF at sandelman.ca>, Sandelman Software Works

 <kerryLynn>    Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08304.html

     Here's a summary the situation:
     - draft-ietf-roll-trickle-mcast ("MPL draft") defines a multicast
 transport
     protocol.  It refers to scop 3 which has up to now been reserved.
     - draft-ietf-6man-multicast-scopes ("Scopes draft") defines scop 3 and
     states it must be automatically determined by data link connectivitiy.
     It recommends the proper place to define how the scope zone boundary
     is determined is in the "IP-over-Foo" draft for each data link that
 defines
     scop 3.
     - The MPL draft *must* reference the Scopes draft in order to utilize
     scop 3.  It must also agree with the Scopes draft on the issue of
 whether
     the scop 3 boundary is automatically determined.  This is included in
     issue #132 and REMAINS OPEN.
     - Another open question is where to locate the definition of scop 3
 for
     802.15.4 networks?

     Going by the recommendation in the Scopes draft, one solution for the
     latter is to issue a short update to RFC 4944.  However, this is not
 the
     most expedient solution from the standpoint of finishing the MPL
 draft.

     The next best solution in my opinion is to place the 802.15.4
 definition of
     scop 3 into the Scopes draft.  Future data links that define scop 3 in
 their
     IP-over-Foo RFCs will then only need to reference the Scopes document
     for the precedent and not the MPL document as well.  Since the MPL
 draft
     must already reference the Scopes draft anyway, this also solves one
     open issue for MPL.

     I personally think it's a bad idea to bury the definition of an
 automatically
     determined scope boundary for a particular data link within a
 transport
     protocol specification.

     Regards, -K- </kerryLynn>

 <yoshihiroOhba>     Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08306.html

    Regards, Yoshihiro Ohba </yoshihioOhba>

 <michaelRichardson>    Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08308.html

    Are you willing to write this document? </michaelRichardson>

 <yoshihiroOhba>    Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08311.html

    Regards, Yoshihiro Ohba </yoshihiroOhba>

 <kerryLynn>     Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08309.html

     Let's scope the effort this week.  Ralph predicts it will be the
 World's
     shortest RFC; maybe we can get it right the first time.

    -K- </kerryLynn>

 <ralphDroms>     Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08310.html

    In my opinion, the roll WG gets to answer the question "should realm-
 specific scope for 802.15.4    be defined in draft-ietf-roll-trickle-
 mcast?"

    If the consensus is no (which would be my answer), then, in my opinion,
 it's up to 6nan to decide    between putting the definition in the
 multicast scopes doc or a separate RFC.

     Ralph </ralphDroms>

 <robertCragie>     Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08323.html

         +1 - my answer would also be no. I guess that should be 6man as
 well. </robertCragie>

 <danielPopa>    Source: http://www.ietf.org/mail-
 archive/web/roll/current/msg08312.html

    Hello all,

    I support the idea of having the definition of multicast scope boundary
 in another RFC so that   trickle-mcast and multicast-scopes drafts specify
 such IP features independent of the link-layer.

    I will unfortunately not be able to attend this IETF meeting, but I
 will be available via email.

    Regards,
    Daniel </danielPopa>

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

---

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

Michael Richardson <[email-masked]> wrote:
    mcr> I would like to ask the WG to speak now if you object to this 
    mcr> solution, specifically with the the text going into mcast-05.

    mcr> Please EMAIL/POST/COMMUNICATE before 2013-11-08 (next Friday).

The consensus call time is over this morning, thank you to all for the
comments you made.

The WG chairs found that there was sufficient disagreement early on that
there was no consensus for the specific solution proposed below, nor was
there consensus for the location suggested. 

I started a new discussion today on the basis of an alternate set of text
today. 

    >> based on different underlying network technologies.

    mcr> --
    mcr> Michael Richardson <[email-masked]>, Sandelman Software Works 
    mcr> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 08 Nov 2013 20:56:08 -0000

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-

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

---

From: "roll issue tracker" <[email-masked]>
Date: Sun, 10 Nov 2013 16:04:25 -0000

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

 > ...

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

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

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

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

 > ...

 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

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

---

From: "roll issue tracker" <[email-masked]>
Date: Sun, 17 Nov 2013 00:30:46 -0000

'''Related to draft-ietf-6man-multicast-scopes-02'''

 <ralph> http://www.ietf.org/mail-archive/web/roll/current/msg08342.html

 This revision adds the definition of "scop 3" for IEEE 802.15.4 networks:

 4.  Definition of Realm-Local Scope for IEEE 802.15.4

    When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to
    include all interfaces sharing a PAN ID.

 I've cross-posted to 6lo to get review and comment from that WG.</ralph>

 <pascal> http://www.ietf.org/mail-archive/web/roll/current/msg08343.html

 http://tools.ietf.org/html/draft-droms-6man-multicast-scopes-02 does not
 seem to contains the section you're inlining. The only diff I found was
 -specific going -local.
 As we are at it, would we be ahead of ourselves if that the draft also
 specifies that a collection of RPL DODAGs of a same instance federated
 over an isolated backbone (such as a VLAN) in an 04 ?.

 If I may add, there is kind of an habit that scopes are nested. Seems that
 we are going away from that assumption and maybe it would be good to have
 a sentence saying that? </pascal>

 <ralph>http://www.ietf.org/mail-archive/web/roll/current/msg08344.html

 The document has been accepted as a WG work item.  Check out
 http://www.ietf.org/internet-drafts/draft-ietf-6man-multicast-
 scopes-02.txt </ralph>

 <samita> http://www.ietf.org/mail-archive/web/6lo/current/msg00298.html

 Indeed, Section 4 talks about the realm-local scope for IEEE 802.15.4

 "4.  Definition of Realm-Local Scope for IEEE 802.15.4

    When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to
    include all interfaces sharing a PAN ID."

 In several places, I think there is a typo: s/scop /scope

 How about adding one or two examples in the appendix section  to clarify
 the nested scope in the home-network  containing two types of networks
 (wifi and LLN) ? Perhaps, we expecting that LLN could have further
 division in scope -- ie, IEEE 802.15.4 or BT-le or MS/TP networks.

 The example of mdns, rpl, and nd  possibly will fall in different scopes.
 </samita>

 <brian> http://www.ietf.org/mail-archive/web/roll/current/msg08345.html

 Scopes are still nested.  See RFC 4007.  Are you saying that this document
 is changing that? </brian>

 <pascal> http://www.ietf.org/mail-archive/web/roll/current/msg08346.html

 03 seems to derive from autonomic behavior, whereas 04 derives from admin.
 I do not see there a direct indication that 03 is contained in 04 though
 in the deployments I have in mind it would certainly be the case. Whether
 we want to enforce or on the contrary do not want to enforce the nesting
 is probably something we want to clarify. </pascal>

 <brian> http://www.ietf.org/mail-archive/web/roll/current/msg08348.html

 Pascal,
     Scope 3 being contained within scope4 is mandated by RFC 4007.
 Specifically, RFC 4007 describes the following properties:

 o  Zone boundaries cut through nodes, not links.  (Note that the global
 zone has no boundary, and the boundary of an interface-local zone
 encloses just a single interface.)

 o  Zones of the same scope cannot overlap; i.e., they can have no links
 or interfaces in common.

 o  A zone of a given scope (less than global) falls completely within
 zones of larger scope.  That is, a smaller scope zone cannot include
 more topology than would any larger scope zone with which it shares any
 links or interfaces.

 o  Each zone is required to be "convex" from a routing perspective;
 i.e., packets sent from one interface to any other in the same zone are
 never routed outside the zone.  Note, however, that if a zone contains a
 tunneled link (e.g., an IPv6-over-IPv6 tunnel link [8]), a lower layer
 network of the tunnel can be located outside the zone without breaking
 the convexity property.

 I don't see anything in this draft that would change those properties.
 </brian>

 <pascal> http://www.ietf.org/mail-archive/web/roll/current/msg08350.html

 I mostly agree Brian;

 It's a bit touchy because in 802.15.4 a PAN ID is configured
 administratively and could lead to an 04 interpretation.
 A RPL domain (that is an 03) that may span multiple PAN IDs. If PAN ID was
 04 that would have been reverse nesting.
 The draft now clarifies that this is also an 03 but now we still have a
 potential conflict between a RPL domain and a PAN.

 Would a RPL domain be constrained by the PAN ID?

 In this case that would imply that all the LLN must always be a single PAN
 and constrain the size of a subnet to 64K.
 There is a lot behind the sentence "care must be taken in the definition
 of those larger scopes to ensure that inclusion constraint is met."
 </pascal>

 <tim> http://www.ietf.org/mail-archive/web/roll/current/msg08347.html

 > 03 seems to derive from autonomic behavior, whereas 04 derives from
 admin. I do not see >there a direct indication that 03 is contained in 04
 though in the deployments I have in mind >it would certainly be the case.
 Whether we want to enforce or on the contrary do not want to >enforce the
 nesting is probably something we want to clarify.
 Are there use cases documented somewhere in a 6lo or 6lo-related draft?
 I'm interested as we're updating the homenet text about multicast scopes.
 We have agreed some text in principle with Brian for that, but it's
 interesting because we may, indeed are likely to, have 6lo networks within
 future IPv6 home networks. </tim>

 <pascal> http://www.ietf.org/mail-archive/web/roll/current/msg08349.html

 Hello Tim;
 The 6TiSCH architecture documents a use case whereby a large (RPL based)
 LLN is federated by an higher speed backbone such as Ethernet that mostly
 spans the LLN.
 The LLN is partitioned by RPL in multiple DODAGs, and the roots of the
 DODAGs connect to the backbone to provide end to end connectivity over the
 formed multilink subnet.
 The LLN probably forms a single RPL Domain though we have not discussed
 that yet. Discussing with Ralph, I understand that the RPL domain is 03
 and the whole multilink subnet is 04.
 It results that we cannot address a single RPL instance or a single DODAG
 as a scope. The intersection with 802.15.4 PAN-ID still troubles me a bit
 but that's another thread. </pascal>

 <michael> http://www.ietf.org/mail-archive/web/roll/current/msg08356.html

 >Pascal Thubert (pthubert) <pthubert at cisco.com> wrote:
     > The LLN probably forms a single RPL Domain though we have not
 discussed
     > that yet. Discussing with Ralph, I understand that the RPL domain is
 03
     > and the whole multilink subnet is 04.

 No, that's not quite right.

 Scope-3 is each of the LLNs that have a single technology instance (e.g.
 802.15.4 + PANID)

 Scope-4 is the whole multilink subnet as defined by the span of the
 collection of DODAGs (my suggestion)

 The RPL DODAG instances would likely span the backbone, and would be the
 basis for scope-4 configuration.</michael>

 <ralph> http://www.ietf.org/mail-archive/web/roll/current/msg08351.html

 >On Nov 14, 2013, at 6:58 PM 11/14/13, "Pascal Thubert (pthubert)"
 <pthubert at cisco.com> wrote:

 > I mostly agree Brian;
 >
 > It's a bit touchy because in 802.15.4 a PAN ID is configured
 administratively and could lead to an 04 interpretation.

 I consider a PAN ID to be equivalent to an address ... both are configured
 administratively but are part of the
 >
 > A RPL domain (that is an 03) that may span multiple PAN IDs.

 Pascal - RPL domains are, in my opinion, completely unrelated to MPL
 scopes.  RPL is only mentioned obliquely, as an example of a protocol that
 accommodates the memory constraints in highly constrained devices.  So, I
 don't think there is any reason to say "A RPL domain (that is an 03)".

 > If PAN ID was 04 that would have been reverse nesting.
 > The draft now clarifies that this is also an 03 but now we still have a
 potential conflict between a RPL domain and a PAN.
 >
 > Would a RPL domain be constrained by the PAN ID?

 No ... RPL domain is independent of MPL scope.

 As a practical matter, a "RPL domain" is a little tricky to define, and
 even trickier to tie into a multicast scope.  There is nothing in the
 multicast address or the MPL header to tie it to a DODAG or some other RPL
 domain identifier.  In a mesh where multiple DODAGS and RPL domains may be
 interleaved, there doesn't seem to be a way to identify a MPL scope.

 >
 > In this case that would imply that all the LLN must always be a single
 PAN and constrain the size of a subnet to 64K.

 I think you're confusing the use of "scop 3" for carrying multicast
 traffic via MPL across a single mesh network and the use of, e.g., "scop
 4" for the scope of, say, mDNS for DNS-SD across a federation of subnets.

 I won't attempt the ASCII art here ... but here's an example scenario as I
 understand it: SEP2.0 DNS-SD/mDNS queries intended to span a federation of
 subnets is sent to (working from memory) FC04::FB.  When delivered to an
 LBR at the border of a 6LoWPAN mesh, that query would be encapsulated in
 FC03::<ALL_MPL_FORWARDERS> to carry it across the mesh. Similarly, a query
 from a mesh node would have an inner header with dst FC04::FB and
 encapsulated by the source with outer header dst
 FC03::<ALL_MPL_FORWARDERS>; then the MPL outer header would be taken off
 by the LBR and inner DNS-SD/mDNS query would be forwarded out any other
 interfaces based on the dst FC04::FB.

 > There is a lot behind the sentence "care must be taken in the definition
 of those larger scopes to ensure that inclusion constraint is met."

 OK, but I don't think draft-ietf-6man-multicast-scopes contradicts RFC
 4007 in any way. </ralph>

 <kerry> http://www.ietf.org/mail-archive/web/roll/current/msg08352.html

 > I mostly agree Brian
 > It's a bit touchy because in 802.15.4 a PAN ID is configured
 administratively and could lead to an 04 interpretation.
 One could take that argument to the extreme and say that selecting SSID
 (802.11) or plugging into a wall socket (802.3) is an administrative act.
 Let's not be too literal and instead say that the "automatic" zone
 boundary definition applies to an existing LAN.  If you think about a
 Link-Local zone, it is defined as a set of physically connected interfaces
 and the zone boundary is defined by a *lack* of forwarding (see [RFC4291]
 section 2.5.6).  I think if there is a need for scope value 3 it is to
 provide classic Link-Local multicast behavior over a connected mesh.  I
 think the definition should be independent of RPL and instead depend on
 some "L2 instance" definition. PAN ID works for 802.15.4 networks.
 >A RPL domain (that is an 03) that may span multiple PAN IDs.
 draft-ietf-6man-multicast-scopes-02 defines a scop 3 zone boundary based
 on PAN ID.  The latest version makes no mention at all of RPL.
 >If PAN ID was 04 that would have been reverse nesting.
 > The draft now clarifies that this is also an 03 but now we still have a
 potential conflict between a RPL domain and a PAN.
 > Would a RPL domain be constrained by the PAN ID?
 > In this case that would imply that all the LLN must always be a single
 PAN and constrain the size of a >subnet to 64K. There is a lot behind the
 sentence "care must be taken in the definition of those larger >scopes to
 ensure that inclusion constraint is met."
  I think the understanding that was reached at dinner last week is that,
 under certain circumstances, policy can count as "administratively
 configured".  Thus, if a RPL instance contained several PAN IDs then the
 former could be used as the basis of a scop 4 zone as long as if fully
 enclosed the PANs (scop 3 zones). OTOH, if a given PAN contains multiple
 RPL instances then the latter cannot be used to define a scop 4 zone
 boundary because that would violate the RFC 4007 constraints that Brian
 enumerated. </kerry>

 <michael> http://www.ietf.org/mail-archive/web/roll/current/msg08353.html

 >Kerry Lynn <kerlyn at ieee.org> wrote:
     > I mostly agree Brian;

     > It's a bit touchy because in 802.15.4 a PAN ID is configured
     > administratively and could lead to an 04 interpretation.
     > One could take that argument to the extreme and say that selecting
 SSID
     > (802.11) or plugging into a wall socket
     > (802.3) is an administrative act.  Let's not be too literal and
 instead say
     > that the "automatic" zone boundary
     > definition applies to an existing LAN.  If you think about a Link-
 Local

 I offer this definition: an independant outside observer can determine the
 boundaries of scope 3 (2, and 1) can be observed without knowledge of the
 internal policies of a node.  That's why we can say that it is
 automatically
 defined: there is no choice to make or policy to apply.

 This is obvious with a wired network: you just follow the wires.
 (The nodes/machines don't even need to be on.)
 For a wireless network, you need to have a radio to sniff with, but given
 that, you can mostly determine things.

 scope 4 is the first scope where a policy *may* come into play.

 The thing that broke up the log jam last week was the understanding that
 policies may be administratively defined such that the device can make a
 decision on it's own, but that this decision is not necessarily visible to
 an
 external observer. </michael>

 <samita> http://www.ietf.org/mail-archive/web/6lo/current/msg00299.html

 Hi Tim,

  >Are there use cases documented somewhere in a 6lo or 6lo-related draft?

  >I'm interested as we're updating the homenet text about multicast
 scopes.  We have agreed  >some text in principle with Brian for that, but
 it's interesting because we may, indeed are  >likely to, have 6lo networks
 within future IPv6 home networks.

 [SC>] AFAIK,  6lo/6lowpan basic documents do not discuss the multicast
 scopes in details.
 [SC>] It'll be certainly helpful to document the scopes of 6lo within the
 scope of home networks or equivalent.
 In addition I think, it'd be really helpful for implementers if we provide
 some examples of scopes of different protocols in the 6man-multicast-
 scopes doc along with the pointer to RFC 4007. </samita>

 <tim> http://www.ietf.org/mail-archive/web/roll/current/msg08358.html

 >On 15 Nov 2013, at 00:12, Samita Chakrabarti
 <[email-masked]> wrote:
 > In addition I think, it'd be really helpful for implementers if we
 provide some examples of scopes of different >protocols in the 6man-
 multicast-scopes doc along with the pointer to RFC 4007.
 That would be excellent.  A separate document targeted at homenet WG
 showing multicast scenarios might be nice, but perhaps overkill. </tim>

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

---

From: "roll issue tracker" <[email-masked]>
Date: Tue, 26 Nov 2013 03:05:07 -0000

'''Related to draft-ietf-6man-multicast-scopes-02

 <robertCragie> http://www.ietf.org/mail-
 archive/web/6lo/current/msg00304.html

 >On 15/11/2013 00:31, Kerry Lynn wrote:
 >…
 (802.11) or plugging into a wall socket (802.3) is an administrative act.
 Let's not be too literal and instead say that the "automatic" zone
 boundary definition applies to an existing LAN.  If you think about a
 Link-Local zone, it is defined as a set of physically connected interfaces
 and the zone boundary is defined by a *lack* of forwarding (see [RFC4291]
 section 2.5.6). I think if there is a need for scope value 3 it is to
 provide classic Link-Local multicast behavior vover a connected mesh.  I
 think the definition should be independent of RPL and instead depend on
 some "L2 instance" definition. PAN ID works for 802.15.4 networks.
 <RCC>+1 - how PAN ID is assigned does not constitute "administratively
 configured" as it is a layer 2 concept.</RCC>
 on PAN ID.  The latest version makes no mention at all of RPL.
 <RCC>Agree that RPL should not be mentioned here.</RCC>

 under certain circumstances, policy can count as "administratively
 configured".  Thus, if a RPL instance contained several PAN IDs then the
 former could be used as the basis of a scop 4 zone as long as if fully
 enclosed the PANs (scop 3 zones).OTOH, if a given PAN contains multiple
 RPL instances then the latter cannot be used to define a scop 4 zone
 boundary because that would violate the RFC 4007 constraints that Brian
 enumerated.
 <RCC>MPL is orthogonal to RPL DODAGs. If there is a requirement to reach
 all nodes in a RPL DODAG which spans multiple 802.15.4 PANs, then that
 would be administratively configured and scope 4. If a RPL DODAG is wholly
 contained within the PAN ID then there would need to be some additional
 discriminator to limit propagation among a node set smaller than that of
 all nodes with the same PAN ID. In other words, it cannot be limited by
 just scope, which is too coarse a measurement. MPL doesn't cater for this
 as MPL Domains are defined as scope zones.</RCC> <robertCragie>

 <ralph> http://www.ietf.org/mail-archive/web/roll/current/msg08361.html

 > On 15 Nov 2013, at 00:12, Samita Chakrabarti <samita.chakrabarti at
 >>> I'm interested as we're updating the homenet text about multicast
 scopes.  We have agreed some text in principle with Brian for that, but
 it's interesting because we may, indeed are likely to, have 6lo networks
 within future IPv6 home networks.
 scopes in details.
 >> [SC>] It'll be certainly helpful to document the scopes of 6lo within
 the scope of home networks or equivalent.
 >> In addition I think, it'd be really helpful for implementers if we
 provide some examples of scopes of different protocols in the 6man-
 multicast-scopes doc along with the pointer to RFC 4007.

 Samita - I don't understand what you're suggesting as "scopes of different
 protocols in the 6man-multicast-scopes".  Do you mean examples of the
 definition of scope 3 for various L2 technologies? - Ralph <ralph>

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