Hi Margaret,
I will take a crack at answering these questions.
See below.
Margaret Wasserman wrote:
>
> > 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)?
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.
>
> > 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...
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.
>
> 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.
That is correct.
>
> The IPv6 routing table MIB should probably be updated to include this
> new field.
Good point.
>
> 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.
Yes.
>
> Should this also be reflected in a MIB?
Yes.
>
> 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?
Yes, a router could move between those two "states".
>
> 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?
Yes.
Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
