Re: [mpls] [Tsvwg] multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt

[Ben Niven-Jenkins <[e-mail]>]

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