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

 From: Ralph Droms <rdroms.ietf at gmail.com> Date: Wed, 23 Oct 2013
 09:05:36 -0400



 > peter van der Stok <stokcons at xs4all.nl> wrote:
 >
 > Looking at the discussion there seem to be two issues:
 > -1 tunnelling MC messages through MPL domain
 > -2 Sending multicast to all members of a mesh
 >...
 >
 > This also works for a message leaving the MPL domain.
 >
 > Any mistakes in my reasoning? Putting this text in section 5.1, and
 removing the text in section 4.1 can help the progress of MPL draft.

 This idea is interesting.  I don't know if the WG considered it.

 However, I'm not sure it's a simplification.  There are two functions in a
 MPL forwarding node: forwarding multicast traffic on to other nodes in the
 MPL domain and delivering traffic to local applications.  The former
 function requires that the node stack receive and forward all multicast
 traffic while the latter function uses the list of locally subscribed
 multicast addresses for local delivery.

 I suppose there's no difference between a node accepting all multicast
 traffic for forwarding rather than using ALL_MPL_FORWARDERS in the outer
 header, and then delivering only subscribed traffic based on the inner
 header.



 >
 > Ad 2)
 > ...
 > Identifying the MC address with the PAN-ID (given the PAN-ID does not
 change in spite of coordinator failures) of the mesh seems logical for
 IEEE802.15.4.

 If I've got it right, you support publication of a very short RFC that
 gives the definition of IEEE802.15.4 scope 3 as the list of all interfaces
 that share the same PAN ID.

 >
 > Sending a multicast to all members to a heterogeneous multi-link network
 looks like a different problem to me.

 Agreed.

 - Ralph

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

 From: Michael Richardson <mcr+ietf at sandelman.ca> Date: Wed, 23 Oct 2013
 14:19:38 -0400

 > Ticket #132:

     > draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 -
     > subnet-local

 I really don't understand the dispute, and it's gonna take some in-person
 discussion.  Not clear to me that it's going to be an edit to this
 document.
 ----------------------------------------------------------------------------------------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08284.html

 From: Ralph Droms <rdroms.ietf at gmail.com> Date: Wed, 23 Oct 2013
 14:36:38 -0400

 “...
 In my opinion, the problem is pretty clear:

  draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-scopes-00
  are in conflict with each other.

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

 Part of the solution will require either a change in either draft-ietf-
 roll-trickle-mcast or draft-ietf-6man-multicast-scopes.  I think we have
 WG support, if not consensus, to edit draft-ietf-roll-trickle-mcast-05:

 OLD:

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

 NEW:

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

 One additional bit of text is needed, but not necessarily in draft-ietf-
 roll-trickle-mcast, to define explicitly the meaning of scop 3 in an
 IEEE802.15.4 network (which is the definition to be cited in the NEW text
 above):

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

 As a further refinement, I suggest text be added to draft-ietf-roll-
 trickle-mcast-05 to the effect of (this refinement has seen less WG
 discussion, in my opinion):

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

 >  Not clear to me that it's going to be an edit to this document.draft-
 ietf-roll-trickle-mcast-05

 I'm pretty sure *something* has to be changed in draft-ietf-roll-trickle-
 mcast unless the definition of scop 3 is changed in draft-ietf-6man-
 multicast-scopes.

 - Ralph ”

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

 From: Kerry Lynn <kerlyn at ieee.org> Date: Wed, 23 Oct 2013 15:01:08
 -0400

 >... draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-
 scopes-00
 > are in conflict with each other….

 Note the above requirement (albeit with slightly different wording) comes
 from RFC 4291.

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

 +1
  > OLD:...
  > NEW:...

 I agree with draft-ietf-6man-multicast-scopes that the proper place for
 this definition is in
 an IP-over-foo RFC.  Specifically, any new 6lo drafts that desire to use
 an automatically
 configured scop 3 must define the link-layer technology specific attribute
 used to identify
 the scope zone.  So I think the proper way to set the precedent is to
 issue a short RFC
 in 6lo (given that 6LoWPAN is shutting down) to update RFC 4944.
 Otherwise, future
 protocols that wish to make use of scop 3 will have to reference Ralph's
 RFC plus the
 MPL RFC.

 >As a further refinement, I suggest text be added to draft-ietf-roll-
 trickle-mcast-05 to the >effect of (this refinement has seen less WG
 discussion, in my opinion):

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

 The place for this would be section 4.1, which currently says:
   An MPL Forwarder MAY participate in additional MPL Domains identified
    by other multicast addresses.  An MPL Interface MUST subscribe to the
    MPL Domain Addresses for the MPL Domains that it participates in.
    The assignment of other multicast addresses is out of scope.

 >>  Not clear to me that it's going to be an edit to this document.draft-
 ietf-roll-trickle-mcast-05

 >I'm pretty sure *something* has to be changed in draft-ietf-roll-trickle-
 mcast unless the >definition of scop 3 is changed in draft-ietf-6man-
 multicast-scopes.

 And, by extension, in RFC 4291.

 -K-

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

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

 From: Ralph Droms <rdroms.ietf at gmail.com> Date: Wed, 23 Oct 2013
 15:56:46 -0400


 >On Oct 21, 2013, at 3:00 PM 10/21/13, çæéå <jinmei at wide.ad.jp> wrote:

 > At Thu, 17 Oct 2013 09:10:50 -0700,
 > Ralph Droms <rdroms.ietf at gmail.com> wrote:
 >
 >> Noting this conflict, I propose adding a bit of text to
 >> draft-ietf-6man-multicast-scopes to update RFC 4007 for consistency
 >> with RFC 4291:
 >
 > I think making these consistent is a good idea.
 >
 >> OLD:
 >>
 >>   o  The boundaries of zones of a scope other than interface-local,
 >>      link-local, and global must be defined and configured by network
 >>      administrators.
 >>
 >> NEW:
 >>
 >>   o  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.
 >
 > I'm okay with the proposed text, but on a closer look I've noticed
 > a couple of subtle points you may want to consider:
 >
 > - I see a slight difference between the OLD (RFC 4007) and NEW (RFC
 >  4291) even after fixing the obvious inconsistency, in that the NEW
 >  version does not necessarily say how the scopes larger than
 >  admin-local scope is configured; technically it only states
 >  interface-local and link-local (and "Realm-Local" if assigned)
 >  would not be automatically configured.  In fact, the global scope
 >  shouldn't be "administratively" configured, which is crystal clear
 >  from the OLD version, but not necessarily in the NEW version.
 >
 > - should we worry about possible future updates to the addressing
 >  architecture and scope architecture documents?  If we keep these
 >  documents separately and have a copy of the text in both, we may need
 >  to update both copies when we need to make a change on this point as
 >  more "currently reserved" scopes are assigned.

 Both good points.  As long as we have to make an update to RFC 4007, let's
 make sure the update is correct.

 >
 > These are probably too minor and maybe we can simply ignore the
 > subtlety.  If that's our consensus I'm okay with that.  But if we want
 > to address these points, maybe:
 >
 > OLD:
 >
 >   o  The boundaries of zones of a scope other than interface-local,
 >      link-local, and global must be defined and configured by network
 >      administrators.
 >
 > NEW:
 >
 >   o  The boundaries of zones of an interface-local, link-local, or
 >      global scope automatically derived from physical connectivity.
 >      For zones of other types of scopes, the IPv6 addressing
 >      architecture specification defines how their boundaries must be
 >      determined, whether automatically derived or administratively
 >      configured.

 Perhaps we want to go a step farther and take the zone boundary text out
 of RFC 4007 altogether?

 OLD:

   o  The boundaries of zones of a scope other than interface-local,
      link-local, and global must be defined and configured by network
      administrators

 NEW:

   o  The boundaries of zones of a scope are defined by the IPv6
      addressing architecture.

 - Ralph

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

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

 From: Kerry Lynn <kerlyn at ieee.org> Date: Wed, 23 Oct 2013 17:38:07
 -0400

 >On Wed, Oct 23, 2013 at 5:21 PM, ¿ 癆 明達哉 <jinmei at wide.ad.jp>
 wrote:
 >At Wed, 23 Oct 2013 15:56:46 -0400,
 >Ralph Droms <rdroms.ietf at gmail.com> wrote:

 >> Perhaps we want to go a step farther and take the zone boundary text
 >> out of RFC 4007 altogether?

 >Basically works for me.

 >> OLD:
 >>
 >>   o  The boundaries of zones of a scope other than interface-local,
 >>      link-local, and global must be defined and configured by network
 >>      administrators
 >>
 >> NEW:
 >>
 >>   o  The boundaries of zones of a scope are defined by the IPv6
 >>      addressing architecture.

 >With a reference (it's currently RFC 4291)?

 >I'd also note that not all points described in the RFC 4007 text are
 >described in RFC 4291 (at least not very clearly).  So, not just
 >remove the text from RFC 4007, I'd like to unify it in the address
 >architecture, e.g. update the following part of RFC 4291:

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

 >as follows:

  >        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.  For all non-reserved scopes except the global
 >         scope, the zone boundaries must also be administratively
 >         configured.

 I think this statement is self-contradictory.  When automatic
 configuration is
 discussed, it is in relation to zone boundaries.  Here's an attempt to
 explain
 this without negations:

     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.

 BTW, just my opinion, but "Realm-Local" might be more meaningfully named
 "Multilink-Local"

 -K-

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

 From: Robert Cragie <robert.cragie at gridmerge.com> Date: Thu, 24 Oct
 2013 07:59:05 +0100


 >On 23 October 2013 22:38, Kerry Lynn <kerlyn at ieee.org> wrote:

 >> Perhaps we want to go a step farther and take the zone boundary text
 >> out of RFC 4007 altogether?

 >Basically works for me.
 <RCC>Me too</RCC>


 >> OLD:
 >With a reference (it's currently RFC 4291)?
 >  ...
  >   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.

 <RCC>
 That makes it clear. IMO RFC4007 should be changed to something like:

 o  Each interface on a node comprises a single zone of interface-local
 scope (for multicast only).

 o  Each link and the interfaces attached to that link comprise a single
 zone of link-local scope (for both unicast and multicast).

 o  Multiple links and the interfaces attached to those links may form a
 multilink-local scope based on underlying network technology; for example,
 [cite the IP-over-IEEE802.15.4 definition].

 o  There is a single zone of global scope (for both unicast and multicast)
 comprising all the links and interfaces in the Internet.

 o  The boundaries of zones of a scope other than interface-local, link-
 local, multilink-local and global must be defined and configured by
 network administrators.

 Either that or just remove the text as Ralph suggested earlier.
 </RCC>

 >BTW, just my opinion, but "Realm-Local" might be more meaningfully named
 >"Multilink-Local"
 <RCC> I agree - it is more meaningful</RCC>

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08289.html
 From: peter van der Stok <stokcons at xs4all.nl> Date: Fri, 25 Oct 2013
 11:52:38 +0200

 I like the consensus that seems to emerge.


 It should be clear that the realm-local specification concerns a
 homogeneous multi-link network
 For example:


 o Multiple links, following the same IP over Foo specification, and the
 interfaces attached to those links may form a multilink-local scope based
 on underlying network technology; for example, [cite the IP-over-
 IEEE802.15.4 definition].
 Peter

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08290.html
 From: "Popa, Daniel" <Daniel.Popa at itron.com> Date: Fri, 25 Oct 2013
 11:35:13 +0000

 Hi Peter,

 By "homogeneous multi-link network" do you refer to "homogeneous link-
 layer technology" ?

 If this is the case, I suggest we do not correlate the scope of the
 multicast to the use of a specific link-layer technology... We should be
 able to deploy systems where all nodes in a multi-link network can be
 members of the same "multilink-local multicast scope", independently of
 the link-layer technology they use (homogeneous or heterogeneous) to
 communicate with each other.

 Regards,
 Daniel


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

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

 From: Robert Cragie <robert.cragie at gridmerge.com> Date: Fri, 25 Oct
 2013 17:39:40 +0100

 Hi Daniel,
 I think the conclusion in that case was that scope 4 would have to be used
 as it would be difficult to imagine anything other than administrative
 configuration for a scope which spans multiple links on different link
 layer technologies.
 Robert

-- 
---------------------------------------+------------------------------
 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:11>
roll <http://tools.ietf.org/wg/roll/>