Subject: Re: [Roll] draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re: [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 - subnet-local)

From: 神明達哉 <[email-masked]>
Date: Mon, 21 Oct 2013 12:00:08 -0700

At Thu, 17 Oct 2013 09:10:50 -0700,
Ralph Droms <[email-masked]> 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.

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.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 23 Oct 2013 14:21:16 -0700

At Wed, 23 Oct 2013 15:56:46 -0400,
Ralph Droms <[email-masked]> wrote:

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

Basically works for me.

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

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Thu, 24 Oct 2013 09:33:26 -0700

At Wed, 23 Oct 2013 17:38:07 -0400,
Kerry Lynn <[email-masked]> wrote:

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

I'm not sure how it's self contradictory, but there was one clear
error: I meant "For all non-reserved scopes larger than admin-local
scope except the global scope".  But in any case,

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

This one works for me, and, I actually don't have a strong opinion of
the wording or where to state it.

--
JINMEI, Tatuya

---

From: Dave Thaler <[email-masked]>
Date: Fri, 25 Oct 2013 20:38:43 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ralph Droms (rdroms)
> Sent: Friday, October 25, 2013 1:21 PM
> To: [email-masked]
> Cc: Routing Over Low power and Lossy networks
> Subject: Re: draft-ietf-6man-multicast-scopes updates RFC 4007 (Was Re:
> [Roll] [roll] #132: draft-ietf-roll-trickle-mcast-04 - Clarify scope value of 3 -
> subnet-local)
> 
> I think I read consensus from the WG to make the following changes to draft-
> ietf-6man-multicast-scopes, and list the document as "Updates RFC 4007":
> 
> *** Add as a new last paragraph in section 2:
> 
>    The following change is applied to section 2.7 of RFC 4291:
> 
>    OLD:
> 
>          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

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.

-Dave

> 
> *** Add section 3 (and renumber current section 3-5):
> 
> 3.  Updates to RFC 4007, section 5
> 
>    Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the
>    way in which multicast scope 3 is configured.  To resolve that disagreement,
>    change the last bullet in the list in section 5 of RFC 4007 as follows:
> 
> OLD:
> 
>       addressing architecture [RFC4291].
> 
> I haven't seen any discussion of changing Realm-Local to Multilink-Local
> beyond Kerry's initial suggestion and Robert's support of the change.
> 
> - Ralph
> 
> On Oct 17, 2013, at 12:10 PM 10/17/13, Ralph Droms
> <[email-masked]> wrote:
> 
> > Kerry correctly points out that RFC 4007 and RFC 4291 are in conflict
> regarding the way in which multicast scope 3 is defined:
> >
> > RFC 4007, section 5:
> >
> > RFC 4291, section 2.7:
> > 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:
> >
> > Add section 3 (and renumber current section 3-5):
> >
> > 3.  Updates to RFC 4007, section 5
> >
> >   Section 5 of RFC 4007 and section 2.7 of RFC 4291 disagree about the
> >   way in which multicast scope 3 is configured.  To resolve that
> disagreement,
> >   change the last bullet in the list in section 5 of RFC 4007 as follows:
> >
> > OLD:
> >
> > Looking for consensus in the 6man WG before I make this change...
> >
> > - Ralph
> >
> > On Oct 16, 2013, at 10:04 AM 10/16/13, Kerry Lynn <[email-masked]>
> wrote:
> >
> >> [...]
> >
> >> I think Ralph's approach is the correct one.  His
> >> draft-droms-6man-multicast-scopes belongs in 6man as it re-defines a
> >> reserved code point in the IPv6 addressing architecture.  It
> >> nominally updates RFC 4291 but should probably also update RFC 4007 as
> these RFCs are in conflict regarding the automatic definition of scope 0x03.
> > [...]
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Dave Thaler <[email-masked]>
Date: Fri, 25 Oct 2013 20:49:14 +0000

Ralph wrote:
[...]
> > 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.
> 
> ?

Yes.

-Dave

---

From: 神明達哉 <[email-masked]>
Date: Mon, 28 Oct 2013 09:46:48 -0700

At Fri, 25 Oct 2013 20:44:57 +0000,

>   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

---

From: Stig Venaas <[email-masked]>
Date: Mon, 28 Oct 2013 12:49:38 -0700

Hi

>    semantics of the scope is defined.

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.

Stig