Hi Steve,
I am just listening but your mail has caused me to respond.
>I'm sure I'm not following all the intricacies of the arguments, but
>maybe this is helpful (or maybe not, or maybe not even relevant):
Very relevant as you bring up important issue.
> When sending a multicast packet in IPv4, one has the choice of either
> identifying a specific outgoing interface or leaving it to the IP layer
> to choose an outgoing interface (the "default" multicast interface).
Exactly and this is all we should do for the basic API right now. Ergo
I have not heard compelling technical or better yet implementation real
world arguments to alter the behavior of the spec to something different
for today. It could be down the road when scopes (or zones) are better
understood and defined and in fact used in the "real world" we need an
adjunct to RFC 2553. But right now we are deploying regular old
interfaces and this is a regular old basic API.
But after all air their views on this we can put statement for future
direction and work. Just like you done with the flowlabel, anycast
addresses and a few others I can't think of off the top of my head. I
feel we need to do the same with this API and leave very very simple and
basic for the IPv6 ISV community for the intial ports to IPv6.
But on to your comments.
> For IPv6, with its scoped addresses, the analogous capabilities would
> be a choice among:
>
> - identifying a particular outgoing interface, or
Yes we can do this today as the spec is written.
>
> - identifying only the outgoing zone (for non-global destinations),
> and leaving it to the IP layer to choose an outgoing interface
> within that zone, or
There is not a concept of zone other than in drafts in mail discussions
and some prototype implementations. This is premature for a real world
API.
> - leaving it to the IP layer to choose both the outgoing zone (of
> the scope of the destination address) and the outgoing interface
> within that zone.
Its just an interface not a zone.
> All this could be done with the single sin6_scope_id field in the sending
> API, if the local indexes for the interfaces plus all zones (i.e., links,
> sites, and any additional multicast zones configured on the node) are
> given distinct values out of the same scope_id space, and if one index
> value (say, 0) is reserved to mean "unspecified". Then, I think we could
> probably get rid of IPV6_MULTICAST_IF altogether (i.e., deprecate it).
I would claim all this sounds good but not real. In fact I think things
will change again if we adopt global unique identifiers for site-local
addresses which will be presented at some point in time to the WG.
> On reception, the upper-layer should be told the arrival interface,
> from which it can also determine the arrival zones of each possible
> scope, since each interface can belong to only one zone of each scope.
What I would suggest is let implementations evolve. For now its simply
an interface in and out. If we want to deprecate it later that can be
done and in a friendly manner.
>At 10:20 PM +0200 6/26/00, Francis Dupont wrote:
>>PS: about the (still missing) scope/zone specs,...
>
>The scope/zone spec is not "still missing", though it certainly still needs
>work. draft-ietf-ipngwg-scoping-arch-00.txt was published before Adelaide,
>and an -01 revision was posted to the ipng mailing list by Brian Haberman
>on March 22. That -01 version never made it into the Internet Drafts
>directories (it was posted during the time just before Adelaide while
>ID submissions were being refused), but we will rectify that ASAP.
Still needs work is an under statement. But its not done and we cannot
base our API on work-in-progress and a very compelling argument for
leaving things alone for now.
regards,
/jim
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
