Subject: RE: rfc2553bis-07 to rfc2553bis-08 changes

From: "Pitcher, Jeff R." <[email-masked]>
Date: Wed, 6 Nov 2002 14:02:01 -0500

Remove [email-masked]

 -----Original Message-----
From: 	Thomas Narten [mailto:[email-masked]] 
Sent:	Wednesday, November 06, 2002 1:45 PM
To:	Jack McCann
Cc:	[email-masked]
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-masked]> 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-masked]> 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-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: Jack McCann <[email-masked]>
Date: Tue, 12 Nov 2002 12:53:29 -0500 (EST)

One more try on sin6_flowinfo for 2553bis, adopting Brian's
verbage and laying the foundation for application compatibility 
with future use of the field:

    The sin6_flowinfo field is a 32-bit field intended to contain
    flow-related information.  The exact way this field is mapped
    to or from a packet is not currently specified.  Until such
    time as its use is specified, applications should set this field
    to zero when constructing a sockaddr_in6, and ignore this field
    in a sockaddr_in6 structure constructed by the system.

I also propose to change the comment next to the sin6_flowinfo
field in the sockaddr_in6 structure definition from:

      uint32_t        sin6_flowinfo;  /* IPv6 traffic class & flow info */

to:

      uint32_t        sin6_flowinfo;  /* IPv6 flow information */

Barring further objections, I'll plan to update the spec after 
tlanta IETF.

- Jack