On Thursday, 08/30/2001 at 02:06 ZE9, JINMEI Tatuya / 神明達哉 <[EMAIL PROTECTED]> 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 PROTECTED] --------------------------------------------------------------------
