Remove [EMAIL PROTECTED] -----Original Message----- From: Thomas Narten [mailto:narten@;us.ibm.com] Sent: Wednesday, November 06, 2002 1:45 PM To: Jack McCann Cc: [EMAIL PROTECTED] Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes
Hi Jack. > There was one change from rfc2553bis-07 to rfc2553bis-08. In response > to a comment from the IESG, the description of the sin6_flowinfo field > was changed from: > The sin6_flowinfo field is a 32-bit field that contains two pieces of > information: the traffic class and the flow label. The contents and > interpretation of this member is specified in [1]. > to: > The sin6_flowinfo field is a 32-bit field intended to contain > flow-related information. The exact use of this field is not > currently specified. > This in essence matches the IEEE spec, which is silent on the > subject of sin6_flowinfo. I think the change to this document is fine, and the best we can do for now. I think we also need to have a plan for how to deal with the flow label and traffic class field in other APIs, so that we avoid problems for when we actually get around to specifying those APIs in more detail. Specifically, we have: - 2553bis (basic API) - 2292bis (advanced API) - future API extensions, such as for temporary addresses, etc. It may well be a mistake to overload the flow label and traffic class stuff. But that is what we did in earlier APIs. As Bill Fenner points out: Bill Fenner <[EMAIL PROTECTED]> writes: > 2133 said: > The sin6_flowinfo field is a 32-bit field that contains two pieces of > information: the 24-bit IPv6 flow label and the 4-bit priority field. > The contents and interpretation of this member is unspecified at this > time. > 2553 said: > The sin6_flowinfo field is a 32-bit field that contains two pieces of > information: the traffic class and the flow label. The contents and > interpretation of this member is specified in [1]. The sin6_flowinfo > field SHOULD be set to zero by an implementation prior to using the > sockaddr_in6 structure by an application on receive operations. > Since [1] doesn't specify the contents and interpretation, and 2133 said > it was unspecified, I guess 2553bis can get away with saying > > The sin6_flowinfo field is a 32-bit field intended to contain > > flow-related information. The exact use of this field is not > > currently specified. > The two APIs that I have looked at (KAME and Linux) both copy the top 28 > bits of the sin6_flowinfo field (in network byte order) to the top 28 > bits of the packet. The above (with regards to to the Traffic Class) is arguable not what we want. With regards to the basic API: - Will we want the basic API to ever allow a way to specify the Traffic Class? If so, will it be better to define a new extension or to overload the Flow Label? - Should we point out that some previous versions of the basic API copied both traffic class and flow label info into packets and that this is now beleived to be wrong and should be fixed? I'm OK with either saying setting the Traffic Class through the basic API won't be done in the future, or saying it can be added but in a way that is completely backwards compatable and will work smoothly with 2292bis (assuming we need two ways of setting the bits). Then there is the Advanced API. Again, from Bill: Bill Fenner <[EMAIL PROTECTED]> writes: > I am still concerned about the interaction between 2292bis's IPV6_TCLASS > and these implementations, but perhaps we should let 2553bis go with the > "not currently specified" wording and make the interaction clear in > 2292bis? (Has the WG as a whole had a chance to see the suggesiton of > leaving sin6_flowinfo simply unspecified?) 2292 doesn't address the flow label. But it does have a way of setting the Traffic Class. But it doesn't mention how it interacts with Traffic Class settings via the (old) basic APIs. If the intention is that the old ways are invalid, and that one only sets traffic class through the advanced API, I think the current approach is fine. Is that what folks are thinking here? Finally, 2292bis seems to assume the Traffic Class is 8 bits in size. It's not any more. It's 6 bits, with the ECN bits explicitly a separate field. So perhaps 2292bis should be updated to reflect the new size and have separate way of setting the ECN bits? Or at least, the text should make it clear how one sets one and not the other, etc. Thomas -------------------------------------------------------------------- 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
