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