Subject: rfc2553bis-07 to rfc2553bis-08 changes

From: Jack McCann <[email-masked]>
Date: Tue, 5 Nov 2002 14:03:58 -0500 (EST)

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.

- Jack

--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Nov 2002 17:54:01 +0100

I understand the problem with the old language, but the new language
is a bit disturbing too. RFC 2474 and RFC 3168 do specify 8 of these
bits, and 4 of them are inoperative in the API (the version number bits).

   Brian

---

From: Thomas Narten <[email-masked]>
Date: Wed, 06 Nov 2002 13:44:49 -0500

Hi Jack.

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 08 Nov 2002 20:51:38 +0900

>>>>> On Wed, 06 Nov 2002 13:44:49 -0500, 
>>>>> Thomas Narten <[email-masked]> said:

> with 2292bis (assuming we need two ways of setting the bits).

I personally prefer to deprecate the access to Traffic Class by the
sin6_flowinfo field (i.e. by the basic API), because

- it (of course) makes the (future) API simple.
- as far as I know, there should be very few (or even no) applications
  that rely on the feature.  so the backward compatibility issue
  should be not so serious.

I know opinions on the compatibility often varies, and I'm open to
others' opinions.

> that what folks are thinking here?

Excuse me, what do you mean by "the current approach"?  Do you mean
that "2292bis has a way of setting the traffic class but it doesn't
mention the interaction with the (old) basic API"?

If so, and assuming we agree on deprecating this part of the basic
API, I agree.

However, if our consensus is that some backward compatibility should
be provided, I guess 2292bis needs to talk about the interaction.

> the text should make it clear how one sets one and not the other, etc.

(this was discussed before at least partly, but)
I believe 2292bis clearly separates the notion of (6-bit) traffic
class and 2-bit ECN.  For example, section 6.5 contains the following
sentences:

   Returning the received traffic class is useful for
   programs such as a diffserv debugging tool and for user level ECN
   (explicit congestion notification) implementation.

   An example is an implementation of ECN in the kernel,
   setting 2 bits of the traffic class value.

The confusing part would be wording such as "traffic class" (assuming
8 bits) or the socket option name IPV6_TCLASS.  In this sense, the
comment for the ip6_un1_flow field of the ip6_hdr structure would also
be confusing:

             uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC, 20 bits flow-ID */

As I responded before, I personally think the current wording is
okay.  However, if there's a strong demand to clarify this much more,
I'd propose to add a note like this:

  [RFC-3260] separates an 8-bit field of the IPv6 header, which was
  originally called a single "traffic class" field, into a 6-bit DS
  field and a 2-bit ECN field.  However, since this API only provides a
  single way to get access to the whole 8 bits, the previous terminology
  "traffic class" will be used to specify the whole bits within this
  document.

Does this make sense?

					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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 19 Nov 2002 07:50:41 +0900

Unless I've missed something, I've not received any responses to the
attached message.  I interpreted the silence as a sign that there is
no need to update 2292bis wrt the issues in this thread.  Otherwise,
please let me know.

Thanks,

					JINMEI, Tatuya

Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes
From: JINMEI Tatuya / 神明達哉 <[email-masked]>
To: Thomas Narten <[email-masked]>
Cc: [email-masked]
Date: Fri, 08 Nov 2002 20:51:38 +0900

Does this make sense?

					JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Nov 2002 16:46:17 +0100

I'm reluctant to reach any conclusion about this until
we have complete clarity about the flow label, which as
we concluded yesterday still needs more work. So I think
that the current (ambiguous) text is probably OK for now.
I'm afraid it will need revisiting at some time in the future.

    Brian

JINMEI Tatuya / 神明達哉 wrote:
>   --------------------------------------------------------------------------------------------------------------------------------
> 
> Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
> CC: [email-masked]
> References: <[email-masked]>
>      <[email-masked]>
>      <[email-masked]>
> 
>                                         Corporate X-Mozilla-Status: 0009rp.