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

From: "roll issue tracker" <[email-masked]>
Date: Wed, 04 Sep 2013 19:28:54 -0000

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

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

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

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

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 13 Sep 2013 13:46:32 -0000

* status:  closed => reopened
 * resolution:  fixed =>

Comment:

 Don Sturek writes:
 {{{
 2)  "- Section 4.1 states: "When used with MPL, Realm-Local scope is
 administratively
   defined and used to define the boundaries of multicast message
 dissemination
   by MPL."  This begs the question, why don't we just use scope = 0x04?
 We
   probably need more discussion on if and how a scope 0x03 zone boundary
   is automatically defined (i.e. without human intervention) and how
 forwarding
   works for scope 0x03.  One suggested definition is that Realm-Local
 applies
   to links where a single interface may belong to multiple Link-Local
 scopes."
 }}}

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

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Sep 2013 10:02:36 -0400

Actually, that was my comment.  It seems to me that the MPL draft and
draft-droms-6man-multicast-scopes-02 may be inconsistent in whether
Realm-Local scopes are administratively or automatically defined.

-K-

On Fri, Sep 13, 2013 at 9:46 AM, roll issue tracker <
[email-masked]> wrote:

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 13 Sep 2013 14:53:04 -0400

Kerry Lynn <[email-masked]> wrote:
    > Actually, that was my comment.

Oh, sorry for he confusion.

    > It seems to me that the MPL draft and

I believe that droms-6man-multicast-scopes-02 is supposed to say that
scope-3 is to be defined automatically by a process to be described by a user
of it.

And so trickle-mcast ought to define how to automatically define it.

I think that it ought to be defined to be the boundary of the DAG
that contains the same (/64) prefix.

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

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 13 Sep 2013 16:06:28 -0400

On Fri, Sep 13, 2013 at 2:53 PM, Michael Richardson
<[email-masked]>wrote:

> Correct me if I'm wrong, but in the case of all other multicast scopes
isn't the
zone boundary established by router configuration?  [RFC 4007, sect. 5] says
as much: "The boundaries of zones of a scope other than interface-local,
link-
local, and global must be defined and configured by network administrators."
Note this contradicts [RFC 4291, sect, 2.7], which states: "Admin-Local
scope
is the smallest scope that must be administratively configured, i.e., not
automatically
derived from physical connectivity or other, non-multicast-related
configuration."
This last statement is probably the reason for the "automatic configuration"
language in Ralph's draft.

>
> [RFC 4007] defines several attributes of a zone, including "Zones of the
same
scope cannot overlap; i.e., they can have no links or interfaces in common."
I think the upshot is that a scope zone is defined in terms of network
topology.

> This is probably a good working definition and *is* based on topology; I
would argue that this definition probably belongs in [RFC 4944] and not
in MPL.  As draft-droms-6man-multicast-scopes-02 says: "... a scope
definition would be appropriate for publication in an "IPv6-over-foo" RFC.

I don't know that we'll close this ticket today unless some greybeards
weigh in...

Regards, -K-

---

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Sep 2013 14:44:16 -0400

I realize I'm joining the conversation late.  I reviewed the document to see that "scop 3" was added, but I didn't read closely enough to notice that draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-scopes-00 are actually now in conflict with each other.

I'll explain why I think they are in conflict and then suggest how to fix the issue.

From draft-ietf-roll-trickle-mcast-05:

   When
   used with MPL, Realm-Local scope is administratively defined and used
   to define the boundaries of multicast message dissemination by MPL.

From draft-ietf-6man-multicast-scopes-00:

   Realm-Local scope is the largest scope that is automatically
   configured, i.e., automatically derived from physical
   connectivity or other, non-multicast-related configuration.

Specifically, "administratively defined" seems to me to be in direct conflict with "automatically configured".

I suggest fixing the problem with two updates.  First, the definition of "scop 3" in an IP-over-IEEE802.15.4 needs to be published, based on this text from draft-ietf-6man-multicast-scopes-00:

   The definition of any Realm-Local scope for a particular network
   technology should be published in an RFC.

I suggest:

   When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to include
   all interfaces participating in the IEEE802.15.4 multi-link subnet.

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: "roll issue tracker" <[email-masked]>
Date: Fri, 20 Sep 2013 14:32:31 -0000

Comment (by [email-masked]):

 As posted to the roll mailing list:

 I realize I'm joining the conversation late.  I reviewed the document to
 see that "scop 3" was added, but I didn't read closely enough to notice
 that draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-
 scopes-00 are actually now in conflict with each other.

 I'll explain why I think they are in conflict and then suggest how to fix
 the issue.

   When

 Specifically, "administratively defined" seems to me to be in direct
 conflict with "automatically configured".

 I suggest fixing the problem with two updates.  First, the definition of
 "scop 3" in an IP-over-IEEE802.15.4 needs to be published, based on this
 text from draft-ietf-6man-multicast-scopes-00:

 I suggest:

   When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined to
 include
   all interfaces participating in the IEEE802.15.4 multi-link subnet.

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

   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:

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 20 Sep 2013 15:02:22 -0400

>  I suggest fixing the problem with two updates.  First, the definition
    > of "scop 3" in an IP-over-IEEE802.15.4 needs to be published, based on
    > this text from draft-ietf-6man-multicast-scopes-00:

    > include all interfaces participating in the IEEE802.15.4 multi-link
    > subnet.

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

Jonathan, can you update trickle-mcast-05?
Ines, can you note in the Shepard write up? (on the datatracker site)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 24 Sep 2013 08:49:39 +0000

Inline...

> Jonathan, can you update trickle-mcast-05?

It would be good to get some discussion about the specific language and method of publishing the definition of "scop 3" an IEEE802.15.4 subnet.

I've done a little research and I can't find any definition that might be appropriate.  Anyone have a reference that might be used here?

If not, is the definition I suggested above OK?

Where should it be published?

- Ralph

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 Sep 2013 10:56:07 +0200

>>> include all interfaces participating in the IEEE802.15.4 multi-link

While this solves the special case of a 6LoWPAN (it might actually want to use the term 6LoWPAN for that), I always understood the RPL approach to go beyond networks delimited by the use of a specific link layer technology.

Wouldn't it be natural to have a MPL scope be congruent with the network covered by a RPL scope?
(Now, there may be several of those around in a network, but I'd at least try to start from there.)

Again, this is a natural thing to do in a 6LoWPAN, we just seem to lack the term for a scope that happens to include other than 802.15.4 radios.

Grüße, Carsten

---

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Sep 2013 10:04:04 +0100

> Again, this is a natural thing to do in a 6LoWPAN, we just seem to lack the term for a scope that happens to include other than 802.15.4 radios.

This point is where my suggestion for "scop 4" enters the picture.  I suggest "scop 3" for the L2-defined topology and "scop 4" for the administratively defined, RPL-congruent topology.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Sep 2013 10:08:54 +0100

> (Now, there may be several of those around in a network, but I'd at least try to start from there.)

Yeah, that issue came to mind when I thought about congruence between MPL and RPL scopes: how is some MPL message, marked as "scop 3", associated with a specific RPL scope when there are overlapping RPL scopes?

- Ralph