Subject: Re: Wrap up and last call: sin6_scope_id semantics

From: "Roy Brabson" <[email-masked]>
Date: Wed, 29 Aug 2001 13:29:30 -0400

On Thursday, 08/30/2001 at 02:06 ZE9, JINMEI Tatuya / 神明達哉
<[email-masked]> wrote:
> > True, if two interfaces are in the same link-local zone then the
interface
> > name will not uniquely identify the zone.  But the current scoping
> > architecture draft indicates that configuration is required to identify
> > that two interfaces are in the same zone, and the name used in this
> > configuration can be used for display of the zone name.
>
> I don't see such indication of the draft...which text of the draft do
> you really mean?

The text is in section 6, which covers zone indicies (cut and pasted
below):

 |  There is at present no way for a node to automatically determine
 |  which of its interfaces belong to the same zones, e.g., the same link
 |  or the same site.  In the future, protocols may be developed to
 |  determine that information.  In the absence of such protocols, an
 |  implementation must provide a means for manual assignment and/or
 |  reassignment of zone indices.  Furthermore, to avoid the need to
 |  perform manual configuration in most cases, an implementation should,
 |  by default, initially assign zone indices as follows, and only as
 |  follows:
 |
 |          o A unique interface index for each interface
 |
 |          o A unique link index for each interface
 |
 |          o A unique subnet (multicast "scop" value 3) index for each
 |             interface
 |
 |  Then, manual configuration would be necessary only for the less
 |  common cases of nodes with multiple interfaces to a single link or a
 |  single subnet, interfaces to different sites, or interfaces to zones
 |  of different (multicast-only) scopes.

The diagram which follows shows, as a default, what is described above:
that two interfaces on a single link are, by default, given unique
link-local scope IDs.  This doesn't address an automatic way to learn about
a link-local or site-local zone, but then again any such mechanism can be
made to include the appropriate zone name at the same time it configures
the zone.

> > I would prefer to use the textual representation which matches what is
used
> > in configuring the zones.  It just makes more sense to echo back what a
> > user placed in a configuration file instead of displaying an arbitrary
> > value dynamically created by a given stack.  How exactly would a user
> > correlate an arbitrary value such as "link1" or "site5" to the given
zone
> > which they want to use, anyway?  This would seem to be the equivalent
of
> > telling a user they need to "guess" the correct interface ID without
> > proving if_nametoindex() to perform the translation of the configured
> > interface name to the corresponding interface ID.
>
> I admit that "link1" is not user-friendly.  But please note that the
> textual representation described in the scoping architecture draft
> basically defines numerical zone IDs only, which are also
> "user-unfriendly".  But the draft also allows implementations to
> introduce more intuitive, more user-friendly format such as interface
> names for links, assuming one-to-one mapping between interfaces and
> links.
>
> Since the notion of "names" can be different among implementations, I
> don't think the architecture draft should define the details of
> "names".  The problem with the 4+28 split model, however, is that
> numerical identifiers would even annoy users (not just be
> user-unfriendly), because we'd see IDs like "1342177281" (which is
> 0x50000001, i.e. a site ID of site index 1).  So, "site1" is just a
> readable alias for "1342177281", which is a different kind of notion
> from "names".

The textual representation is more readable, but I don't find it
substantially more useful.  It still doesn't help anyone understand which
site or which link is being used.  How does someone using a zone such as
"site1" have any idea which zone the packet will be sent, or which
interfaces are defined to be within that zone?

The "names" used to configure zones is going to be platform-unique.  I
guess I'd just prefer to see the values used by and returned from the DNS
resolver incorporate those names vs. something like "link1" or "site1".  By
default, for link-local this is the interface name.

Roy Brabson

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 30 Aug 2001 12:08:52 +0900

>>>>> On Wed, 29 Aug 2001 13:29:30 -0400, 
>>>>> "Roy Brabson" <[email-masked]> said:

> made to include the appropriate zone name at the same time it configures

Correct, but the draft does not recommend nor suggest to introduce
such mechanism.  There is no reason to reject it, but there is no
reason to force it.  Anyway, I guess the point is the next discussion

> interfaces are defined to be within that zone?

As I have repeatedly said, the textual representation like "site1" is
as unusable as numeric identifiers.  It's just to improve readability,
and the draft does not reject using more intuitive "names"; the draft
does just not specify the concrete definition of names, which I think
is overspecification in an architecture draft.

> default, for link-local this is the interface name.

So I guess we should treat this issue in a related API discussion.
I'd like to propose the following approach:

- the scoping architecture draft only defines the numerical zone IDs
  and their aliases for readability (like "site1")
- the scoping architecture draft does NOT define the zone "names", but
  mentions that implementation can use intuitive names in the textual
  representation, and that interface names can be used as
  interface/link/subnet zone IDs by default.
- write a separate informational document, which talks about the API
  of the scoping issues, including possible representation of names,
  and mapping of numerical identifiers and names.

Is this okay for you?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 30 Aug 2001 15:29:11 +0200

In your previous mail you wrote:

   
=> what we need is a more general (than "site1") notion of names
and the way to translate names to zone IDs and the reverse.
The actual syntax and semantics of names are not very important if
some simple rules (no % in names for instance) are given.

Regards

[email-masked]

PS: I am waiting for a concrete proposal (i.e. a draft)
PPS: don't forget to update RFC 2732
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 31 Aug 2001 13:56:45 +0900

>>>>> On Thu, 30 Aug 2001 15:29:11 +0200, 
>>>>> Francis Dupont <[email-masked]> said:

> PS: I am waiting for a concrete proposal (i.e. a draft)

Yes, I guess we have reached (a sort of) consensus, and it's time to
revise the draft.

					JINMEI, Tatuya