Subject: I-D ACTION:draft-ietf-ipngwg-scoping-arch-01.txt

From: [email-masked]
Date: Wed, 28 Jun 2000 06:48:49 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPNG Working Group of the IETF.

	Title		: IP Version 6 Scoped Address Architecture
	Author(s)	: S. Deering, B. Haberman,  B. Zill
	Filename	: draft-ietf-ipngwg-scoping-arch-01.txt
	Pages		: 12
	Date		: 27-Jun-00
	
This document specifies the architectural characteristics, expected 
behavior, and usage of IPv6 addresses of different scopes

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipngwg-scoping-arch-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipngwg-scoping-arch-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 28 Jun 2000 13:35:21 -0400

I have comments/questions on the scoping architecture draft.  

First, I'd like to compliment the authors on writing such a 
straightforward explanation of a complex topic.

 >   Each interface belongs to one node-local zone, one link-local zone,
 >   one site-local zone, and the global zone.  Each link belongs to one
 >   link-local zone, one site-local zone, and the global zone.  An
 >   interface or link only belongs to additional (i.e., multicast) zones
 >   if it falls within the configured boundaries of such additional
 >   zones.

Is this a (relatively) new restriction?  I know that, in the past,
we had discussed the concept of overlapping sites.  Does this draft
intentionally invalidate the possibility of overlapping sites (where 
a single interface could be in more than one site)?

 >   Thus, the upper layer requires the
 >   ability, when sending a packet, to specify any zone of scope less
 >   than or equal to the scope of the destination address, including the
 >   case in which the destination address is of global scope.  For this
 >   reason, an implementation might find it useful to assign a distinct
 >   value for each zone index, so that they are unique across all zones,
 >   regardless of scope.

Why not require a unique value in the architecture?

I'm also interested to know if anyone has considered the implications
of this specification on routing table management...

If I understand correctly, this specification adds a "key" (the 
outbound zone ID) that is used for routing table lookups on both
hosts and routers (conceptually, to choose between routing tables).
The zone ID may identify a single interface or a group of interfaces.  

The IPv6 routing table MIB should probably be updated to include this 
new field.

If I understand correctly, this specification also requires that all
zone-boundary routers maintain information in each learned route entry 
to indicate the zone in which the information was learned.

Should this also be reflected in a MIB?

I also have a question regarding zone-boundary routers...  Is there
a distinction between zone-boundary and non-zone-boundary routers?  
Or can any router that is attached to more than one link dynamically 
become a zone boundary router due to reconfiguration or topology 
changes?

If the latter, then all routers should maintain zone information 
associated with their learned routes, in case they become a zone-
boundary router later on.  Right?

Margaret

--------------------------------------------------------------------
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: "Brian Haberman" <[email-masked]>
Date: Wed, 28 Jun 2000 15:17:53 -0400

Hi Margaret,
     I will take a crack at answering these questions.
See below.

> a single interface could be in more than one site)?

It is not THAT new.  The problem with overlapping sites is that there is
no way to determine which site the address belongs to.  Part of the past
confusion was that all these definitions had been talked about, but
never
documented together.

> of this specification on routing table management...

Well, actually I have.  Part of this draft is from my routing of scoped
addresses draft I wrote a year ago.  The idea is that each zone has a
routing table.  The tables are differentiated by the zone ids.  We
called it a conceptual table in the draft so that people could implement
the function as they see fit.

> The zone ID may identify a single interface or a group of interfaces.

That is correct.

> The IPv6 routing table MIB should probably be updated to include this

Good point.

> to indicate the zone in which the information was learned.

Yes.

> Should this also be reflected in a MIB?

Yes.

> become a zone boundary router due to reconfiguration or topology

Yes, a router could move between those two "states".

> boundary router later on.  Right?

Yes.

Brian

---

From: Steve Deering <[email-masked]>
Date: Thu, 29 Jun 2000 22:47:44 -0700

>straightforward explanation of a complex topic.

On behalf of all the authors, thanks!

>Does this draft intentionally invalidate the possibility of overlapping
>sites (where  a single interface could be in more than one site)?

Yes.  To add an example to Brian's early response, suppose you are
connected to two sites via a single interface, and each of those sites
has a node with site-local address X in the part of the site that does
not overlap the other site.  If you wanted to send a packet to X, there
is no way for you to say, or for the routers in the overlap area to
know, which of the two Xs you mean.

Steve

---

From: "Brian Haberman" <[email-masked]>
Date: Fri, 30 Jun 2000 10:26:22 -0400

Margaret,

Margaret Wasserman wrote:
> 
> Hi Brian,
> 
> Thanks for your quick and helpful response.

Sure.  Not a problem.

... snip ...
> I have another network management related question/issue...
> 
> If I understand correctly, a zone-boundary router could use
> the same site-local address within more than one site.  It
> would internally distinguish between these two addresses using
> the zone ID of each site.

Yes.

> 
> I think it would be useful for an SNMP manager (or possibly
> other applications) within a site-local zone to be able to
> determine which zone ID a zone-boundary router is using to
> identify the manager's local site.  Do we currently have a way
> to do this?  Is anyone working on something like this?
> 

Dave Thaler and I are planning on addressing the scope name
discovery item on the revised charter.  We are thinking that
an MZAP-like mechanism will work.  This will allow someone to
determine what the "scope names" are on a given device.

> A possible solution would be a new ICMP message that asks for
> the remote host to return the zone ID indicated by the interface
> on which the message was received.  A message sent to a link-local
> address would return a link-level zone ID; a message sent to a
> site-local address would return the site-level zone ID.

That may be a simple approach.  Let me digest it a little more.

Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 30 Jun 2000 10:03:52 -0400

Hi Brian,

>never documented together.

Well, it's new to me!  :-).

Actually, I fell out of the IPv6 discussions around the time that
we began to uncover the issues with overlapping sites -- I pass
my initial implementation and become more involved in management
(corporate management, not network management).  I'm just starting
to catch back up on the IPv6 front.

I agree with the restriction, I just wanted to make sure that is was
intentional.

What do you think?

Margaret

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 30 Jun 2000 18:53:37 -0700 (PDT)

> become a zone boundary router due to reconfiguration or topology 

A router connected to more than one link always have to deal
with multiple link-local scope zones.

For site-local scope zones it can presumably change dynamically.

  Erik