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

From: "Bound, Jim" <[email-masked]>
Date: Tue, 19 Nov 2002 19:58:25 -0500

I agree.  We can have an addendum API spec specifically for this later.

/jim
[Honor, Commitment, Integrity]

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Tuesday, November 19, 2002 10:46 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Resend: Re: rfc2553bis-07 to rfc2553bis-08 changes
> 
> 
> 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-masked]
> > 
> >   
> > 
> ----------------------------------------------------------------------
> > ----------------------------------------------------------
> > 
> > Subject: Re: rfc2553bis-07 to rfc2553bis-08 changes
> > Date: Fri, 08 Nov 2002 20:51:38 +0900
> > From: JINMEI Tatuya / 神明達哉 <[email-masked]>
> > Organization: Research & Development Center, Toshiba Corp., 
> Kawasaki, 
> > Japan.
> > To: Thomas Narten <[email-masked]>
> > CC: [email-masked]
> > References: <[email-masked]>
> >      <[email-masked]>
> >      <[email-masked]>
> > 
> > >>>>> On Wed, 06 Nov 2002 13:44:49 -0500,
> > >>>>> Thomas Narten <[email-masked]> 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-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?
> > 
> > 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-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]
> --------------------------------------------------------------------
> 

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