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:
>
> 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
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> [EMAIL PROTECTED]
>
>
>--------------------------------------------------------------------------------------------------------------------------------
>
> Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes
> Date: Fri, 08 Nov 2002 20:51:38 +0900
> From: JINMEI Tatuya / 神明達哉 <[EMAIL PROTECTED]>
> Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
> To: Thomas Narten <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> References: <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
>
> >>>>> On Wed, 06 Nov 2002 13:44:49 -0500,
> >>>>> Thomas Narten <[EMAIL PROTECTED]> said:
>
> > 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).
>
> 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.
>
> > 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?
>
> 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.
>
> > 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.
>
> (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 X-Mozilla-Status: 0009rp.
> [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]
--------------------------------------------------------------------
