Subject: RE: IPv6 w.g. Last Call on "IPv6 Flow Label Specification"

From: "Michel Py" <[email-masked]>
Date: Fri, 7 Mar 2003 13:01:22 -0800

> Brian E Carpenter wrote:
> Michel, can you respond to Pekka's comments? He and
> I simply don't see things the same, and we need a few
> more opinions to see where the consensus lies.

Two sides, one technical for some aspects and one more general.
Disclaimer: I do not consider myself a flow label specialist.

Technical: A lot is not directly related to Pekka's comments, my goal
here is to explain the reasons that lead me to my current positions.

> the source node MUST provide means for the applications and
> transport protocols to specify the Flow Label values to be
> used with their flows.

This makes sense to me. I do not feel the urge for the "API" nor for
case uses at this time.

> Packet classifiers use the triplet of Flow Label,
> Source Address, and Destination Address fields

When we discussed the interaction between MHAP and flow label in
Atlanta, this (vs. a random number) appeared to be the way to go. The
main concern I had at the time was that the source and destination
address needed to remain in the classifier.

Although this is somehow a guess derived from the limited set we have to
look at today, I do think that this type of classifier is a fundamental
requirement for dual-space systems, and dual-space system are currently
percept to be the way out that would provide PI-like advantages _and_
scalability.

In the case of MHAP, since the identifier space and the locator space
belong to the same name space which is the IPv6 Global Unicast address
space, the choice of which space (the locator or the identifier) is
going to be used for the classifier is a no-brainer as both could be,
depending if classification takes place before or after aliasing.

In other (future) dual-space systems, it might happen that the
identifier space is un-classifiable, and there I have a gut feeling that
building the classifier with the locator space will be a requirement.

About the 3-tuple vs. 5-tuple issue, I do prefer the 3-tuple way, for
the reasons mentioned in the text.

> The nodes certainly should be allowed (in the kernel level) to
> forge the source addresses: any model which forces this is broken.

I'm not hot at all about this in the context of a dual-space system.

General:

There are lots of things in this text that are speculations. In this
kind of situation, I tend to favor pushing out text even if nobody
really knows. There's only one way to find out, and that way is to try.

In terms of consensus, it is my reading of the ML that except Pekka's
concerns there is consensus over this text. Is this the right way?
Maybe, maybe not, all we have is opinions.

The way I approach this is that as long as it does not break what I want
to do and I don't hear any screams from other people that it breaks what
they want to do (with specifics) and when we have author consensus on
the text it's time to ship.

Michel.

--------------------------------------------------------------------
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]
--------------------------------------------------------------------