Subject: scoped-arch comments

From: Alain RITOUX <[email-masked]>
Date: Wed, 28 Jun 2000 17:57:02 +0200

Hi,

I have some comments about the scoped @ arch, about the scope_id.
- I definitly agree with E. Nordmark about storing all space names in a
single 32 bit box! This could be done using a quartet with same
signification as for multicast. Scope id could look like something as
0x 00 0S zone_id
with 16 bits for zone id, and S being set to 2 for link-id, 5 for
site-id ...
zone_id might be set to nul to let the default zone ot be taken. hence
0x00020000 being the default link.
- If we want to use litteral form of zone_id (assuming uniquiness of
names among all zone id of all scopes), conversion fct should be
provided in the API, such as scop2name and name2scope. if we want to
have links with multiple interface, link_scope_id should not be obtained
from an if_nametoindex.
- About using scope_id with a smaller scope than the @ : isn't it in
sometimes dangerous ? I mean the @ are unique in à zone, what if the
sub-zone provided isn't the good one ? for example a station with two
links (l#1 and l#2) belonging to the same site (s#1). The destination is
on link#1 and the application choses l#2 as scope_id because of its
source @!!!

Best regards.
Alain.

--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Thu, 29 Jun 2000 15:04:34 -0700 (PDT)

> 0x00020000 being the default link.

For compatibility with what we have in RFC 2553 I think you want to
still handle just an ifindex i.e. the high order bits being zero should
mean that the low order bits is an ifindex.

But I still think your general approach with using the defined (multicast)
scope values is a good idea. Of course, this can all be hidden in
the if_nametoindex type APIs.
Thus you'd get
	0	Interface ID
	1	-
	2	Link ID
	5	Site ID
	...

If we go this path (allowing different scope zones ids in sin6_scope_id)
it might make sense to add parallels to the if_nametoindex() etc APIs.
Either
	site_nametoindex(), site_indextoname(), site_nameindex()
	link_nametoindex(), ...
or a more general set of routines
	sz_nametoindex(char *name, int scope_level)

That way we can add protocol support (something like MZAP?) 
for advertising scope zone names in the future.

  Erik

---

From: "Brian Haberman" <[email-masked]>
Date: Fri, 30 Jun 2000 08:25:17 -0400

Erik,

Erik Nordmark wrote:
... major snip ...
> for advertising scope zone names in the future.

Dave Thaler and I are already looking into either an extension to
MZAP or an MZAP-like protocol for the scope name discovery work
item on the updated charter.

Brian