Subject: RE: rfc2553bis comments

From: Tim Hartrick <[email-masked]>
Date: Mon, 26 Jun 2000 20:30:24 -0700 (PDT)

Brian, Steve,

> 
> I agree completely.  As I see it, having to select an interface when sending
> a multicast packet in IPv4 is just a hack to get around the lack of the zone
> concept in IPv4.  This the architecturally clean and simple way to do it.
> We shouldn't propagate bad hacks forward from v4 into v6.
> 
> > Then, I think we could probably get rid of
> > IPV6_MULTICAST_IF altogether (i.e., deprecate it).
> 
> Yes.
> 
> > The scope/zone spec is not "still missing", though it 
> > certainly still needs work.
> 
> Well, the draft itself might need a little bit of cleanup, but the concepts
> contained therein are well understood, exist in multiple implementations,
> etc.
> 

I would prefer that we simply keep IPV6_MULTICAST_IF and use the sin6_-
scope_id for what it was originally intended, to identify the zone from
which a datagram was received and to identify the zone to which a datagram
should be sent.  To the extent that that overlaps with what IPV6_MULTICAST_IF
does that is unfortunate but it certainly isn't the only or even the worst
example of duplicated functionality in the API specifications.

Application writers are familiar and confortable with the notion of
specifying the outgoing interface to be used for multicast and I just don't
see the upside to obsoleting IPV6_MULTICAST_IF in an effort to make
application writers' lives easier.  Gratuitous changes to APIs piss
people off even if they are improvements.

I have been as guilty as anyone of beating the snot out of the dead horse
that is rfc2553 but I don't see any upside to making this change at this
late date.

Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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: Steve Deering <[email-masked]>
Date: Mon, 26 Jun 2000 23:15:56 -0700

>example of duplicated functionality in the API specifications.

Sure, there's a good backwards compatibility argument for keeping
IPV6_MULTICAST_IF, and I don't pretend to be able to judge how much
hassle it would be for anyone if it were to disappear, so it's not
something I want to argue strongly for.  But if it is indeed duplicated
functionality, we should perhaps at least point that out in one of the
API specs, so users don't have to scratch their heads wondering if it
is or it isn't.

>people off even if they are improvements.

Point taken and conceded.

>that is rfc2553 but I don't see any upside to making this change at this

Probably right.  I'm more interested in us all understanding and agreeing
on the architecture, so we can actually agree whether a particular API
function is redundant or not, than to produce a pristine API.

Steve

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Jun 2000 12:34:15 +0200

In your previous mail you wrote:

=> if the functionality is duplicated (and it is in this case) we have to
specify who has the precedence, ie. what happens when both are used.

[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 28 Jun 2000 02:28:52 +0900

>>>>> On Mon, 26 Jun 2000 20:30:24 -0700 (PDT), 
>>>>> Tim Hartrick <[email-masked]> said:

> people off even if they are improvements.

I agree with this.

We could implement Steve's proposal if we invented unique space of
identifiers that covers all scopes. And I admit it would be useful if
we can specify the outgoing interface by the sin6_scope_id field
without any other APIs (such as socket options), but it would be too
complecated for application programmers, especially on properly using
different type of sin6_scope_id values (i.e. sometimes use it as an
interface identifier, and sometimes use it as a zone identifier of a
larger scope).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Thu, 29 Jun 2000 10:17:46 +0200

=> do you believe we should use conditional? In fact the sin6_scope_id
space is not yet specified then in theory it is not too late.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 29 Jun 2000 18:12:32 +0900

>>>>> On Thu, 29 Jun 2000 10:17:46 +0200, 
>>>>> Francis Dupont <[email-masked]> said:

> space is not yet specified then in theory it is not too late.

I can't understand what you meant by "conditional" (sorry), but it is
correct that the semantics of sin6_scope_id is not yet defined. My
concern is possible confusion due to the complexity of the semantics
in the future.

By the way, do you intend to use the same approach for unicast
addresses?

					JINMEI, Tatuya

---

From: Francis Dupont <[email-masked]>
Date: Thu, 29 Jun 2000 12:07:45 +0200

> space is not yet specified then in theory it is not too late.
   
   I can't understand what you meant by "conditional" (sorry),

=> could in place of can, invented in place of invent, ...
For me this usage of past show you wouldn't like to support to
Steve's proposal...

   but it is
   
=> I understand your concern but powerful things are usually complex.
I'd like to get both a powerful and uniform thing, ie. something which
can be made simple to explain. Another question is do we need a very
powerful thing or should we stay with the current solution (sin6_scope_ids
are used only for link-locals).

=> I don't see any good reason to have different approaches for unicast
and multicast addresses. In IPv4 they are very different for historical
reasons and it is very hard for a beginner to program a multicast
application for this reason (the lack of documentation doesn't help too).

IMHO we should try to complete Steve's proposal and see if it works
reasonnably (look at the scope I-D thread about potential issues).

Thanks

---

From: Steve Deering <[email-masked]>
Date: Thu, 29 Jun 2000 21:37:33 -0700

>interface identifier, and sometimes use it as a zone identifier of a

Yes, I think I am coming to the same conclusion.

Steve

---

From: Francis Dupont <[email-masked]>
Date: Fri, 30 Jun 2000 11:54:11 +0200

=> what about both:
 - put the zone different from the address of the zone stuff into the
   new advanced API document (I've already seen this idea in Steve's answer,
   we should get the opinion of the new advanced API author(s) and of
   course change the name of this thread)
 - introduce a flag which allows the extension to different zones
   (with the default value, an error should be returned when zones don't
   match, a per-user sysctl() should make the job on BSDs)
By the way, I think the interface index confusion is the main problem,
then we should find solutions to this issue, pick one and re-evaluate
the model.

Regards