[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mpls] [Tsvwg] 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" <johnkenney@alumni.nd.edu> 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.
>