RE: [Tsvwg] [mpls] multiple-working group last call ondraft-ietf-mpls-cosfield-def-04.txt

["Drake, John E" <[e-mail]>]

What about 'CoS'? 

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>Sent: Tuesday, July 22, 2008 9:34 AM
>To: [e-mail]; [e-mail]; [e-mail]
>Cc: [e-mail]; [e-mail]; [e-mail]; 
>[e-mail]; [e-mail]; [e-mail]
>Subject: Re: [Tsvwg] [mpls] multiple-working group last call 
>ondraft-ietf-mpls-cosfield-def-04.txt
>
>I tend to agree with Ben - in effect whatever we end up 
>calling it there should be a clear explanation of what we 
>think it actually means.
>
>If you are still open to new suggestions how about "traffic 
>information field" as strictly using it for ECN still isn't 
>traffic management. Or even "traffic signalling field"
>
>Toby
>
>____________________________________________________________________
>Toby Moncaster, <[e-mail]> Networks Research 
>Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK.  [phone] 
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 
>On Behalf 
>> Of Ben Niven-Jenkins
>> Sent: 21 July 2008 16:15
>> To: John Kenney; Loa Andersson
>> Cc: L2VPN; [e-mail]; [e-mail]; ccamp; pwe3; 
>[e-mail]
>> Subject: Re: [Tsvwg] [mpls] multiple-working group last call on 
>> draft-ietf-mpls-cosfield-def-04.txt
>> 
>> I'm not precious about which term we use but if we use Traffic 
>> Management I think a paragraph should be added explaining what is 
>> meant to put it in context.
>> 
>> Ben
>> 
>> 
>> 
>> On 21/07/2008 15:07, "John Kenney" <[e-mail]> wrote:
>> 
>> > Hi Loa,
>> > 
>> > This is a good draft.  It's time to rename the EXP field.  
>While CoS 
>> > Field may have been a good choice at one time, we've now
>> heard from many
>> > who think it is too narrow for current usage of this field.
>> > 
>> > I suggest "Traffic Management Field".
>> > 
>> > Traffic management is a common, generic, and concise term.  
>> It covers
>> > all current uses of the field: scheduling class, drop 
>priority, and 
>> > congestion notification. CoS really only covers the first. 
> Traffic 
>> > management is well-scoped to this purpose, and clearly
>> preferable to CoS
>> > in my opinion.
>> > 
>> > In terms of the draft, I think a simple global substitution
>> of "traffic
>> > management" for "class of service" and of "TM" for "CoS" 
>> should suffice.
>> > 
>> > I think in the long run we'll be glad if we bite the bullet
>> now and make
>> > this change.
>> > 
>> > Best Regards,
>> > John
>> > 
>> > 
>> > Loa Andersson wrote:
>> >> 
>> >> Bob,
>> >> 
>> >> thanks for useful comments :)
>> >> 
>> >> Bob Briscoe wrote:
>> >>> Loa,
>> >>> 
>> >>> I believe this draft has no technical effect. However
>> there is some
>> >>> truth in the idea that names are important.
>> >>> 
>> >>> So, let's set aside a few clock cycles to consider this...
>> >>> 
>> >>> 1/ Is CoS a good description of ECN? Given RFC5129 
>(Using the EXP 
>> >>> field for ECN in MPLS), is it really appropriate now to
>> call this a
>> >>> CoS field?
>> >>> 
>> >>> Thinking out loud...
>> >>> - CoS is a signal from an ingress to the interior (a 
>request for a 
>> >>> certain class of service),
>> >>> - whereas ECN is a signal from the interior forwarding
>> plane to the
>> >>> egress (a response from the interior saying whether the class of 
>> >>> service requested was congested).
>> >>> 
>> >>> The way 5129 was done, two (or more) EXP codepoints can
>> be designated
>> >>> as the same CoS, but one can be used to say "this packet
>> experienced
>> >>> congestion when using this CoS", while the other says 
>"it didn't".
>> >>> So, I guess I could live with this field being called CoS, even 
>> >>> though it's not strictly correct. I can't think of
>> anything better.
>> >> 
>> >> We had the same discussion when we started to discuss this
>> draft, we
>> >> wanted to find a name the covered both cases. We just 
>couldn't come 
>> >> with a better name, so we said "Let us call it 'CoS
>> Field'" and change
>> >> it someone comes up with something better.
>> >> 
>> >> I'm still open to do that change, but time is kind of
>> running out, the
>> >> latest point in time we can do this change is an RFC
>> editor note, when
>> >> the IESG has approved the document.
>> > 
>> 
>> 
>