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

[Bob Briscoe <rbriscoe at jungle.bt.co.uk>]

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.


2/ BTW, Thanks for pointing out that the RFC Index doesn't identify 
RFC5129 or RFC3270 as updates to RFC3032.

According to a recent discussion on TSVWG with Bob Braden, the 
annotation of the RFC Index is the responsibility of the RFC Editor, 
and doesn't need to be driven by text in RFCs. So we can send an 
email to the RFC Editor  at any time asking for annotation to be 
added to the index.

If no-one objects on this thread, will you be doing that? If not, I can.

But does 5129 UPDATE 3270? I don't believe it does. 5129 deliberately 
doesn't change or contradict anything in 3270. It complements it.


Thoughts?


Bob

At 12:59 10/07/2008, Loa Andersson wrote:
> All,
>
> this mail initiates a two week multiple-working group last call on
>
> draft-ietf-mpls-cosfield-def-04.txt
>
> Background:
>
> The name "EXP field" of a three bit field in the MPLS shim header,
> and the statement in RFC3032 "For experimental use" has led other
> SDOs to believe that this field could be used for any type of
> experiments. The field has however from the start been intended to
> carry Class of Service (CoS) information.
>
> The draft therefore renames the field "Class of Service (CoS) Field".
>
> This is an update of RFC3032, and also of drafts that builds on
> RFC3032. This multiple-working group last call is therefore sent to
> working groups with RFCs that has been updated.
>
> The document has been through wg last call in the mpls working group,
> which I don't think will stop that wg producing new comments now,
> nor should it :) .
>
> This working group last call is for CCAMP, L2VPN, PWE3 and TSVWG.
>
> Since this is also of interest in the work we started on a
> Transport Profile for MPLS (MPLS-TP) we are also sending it to the
> Ad HoC Team on MPLS in the ITU-T.
>
> Please review and send comments to the mpls wg mailing list, or to
> the mailing list for mpls-tp discussion that just been set up:
>
> mpls-tp at ietf.org
>
> or directly to the mpls wg co-chairs before e.o.b. July 24.
>
> /Loa
>
> --
> Loa Andersson
>
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  loa.andersson at acreo.se
>                                            loa at pi.nu

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does 
not necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196