> >I'm warming up to Dave's proposal, but I would not invent
> new zone ids for
> >all the different multicast scope levels. (Or at least I'd leave this
> >optional for implementations.) I'd map the multicast scope
> levels into the
> >link-local/site-local/global unicast scopes.
>
> I don't think you have to create zone IDs for all multicast
> scope levels
> *nor* do I think you have to "map" those levels into the
> unicast levels.
> Rather, you only need zone IDs for those scopes for which you are a
> boundary (or in other words, only for those zones for which you are
> attached to more than one of the same scope). Whenever
> dealing with an
> address (multicast or unicast) of a scope for which you are
> not a boundary,
> the appropriate zone is unambiguous (all your interfaces
> belong to a single
> zone of that scope), so you can just use the "unspecified" (e.g., zero
> valued) zone id in the sin6_scope_id that accompanies that address.
I'm (mildly) concerned about how much state an implementation has to
maintain per interface. Right now in the interface structure we have fields
for an interface id and a site id. If our implementation might be used in
boundary situations for the different multicast scope levels, does that mean
the interface structure must grow to accommodate ~16 zone ids at the
different levels?
Of course this isn't the biggest space hit for an interface by far.
Rich
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
