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

From: Loa Andersson <[email-masked]>
Date: Thu, 10 Jul 2008 13:59:29 +0200

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:

[email-masked]

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:  [email-masked]
                                            [email-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 17 Jul 2008 20:16:24 +0100

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

>or directly to the mpls wg co-chairs before e.o.b. July 24.

____________________________________________________________________________
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

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 21 Jul 2008 09:24:02 +0200

Bob, Loa,

I expect that the EXP bits carry 'Priority' and 'Drop Eligible' information.
Is the term 'Class of Service' representing both elements?

For the case of VPLS, the 'PW label stack entry header' replaces the 'VLAN
Tag' and carries the 'vlan_identifier', 'priority' and 'drop_eligible'
parameter information of the 802.1Q (E)M_UNITDATA primitive signals. 

The EXP field in this PW label stack entry then carries the Priority Code
Point (PCP) information as specified in clause 6.7.3/802.1ad. I refer to
this EXP field often as M-PCP field, and to the PW label stack entry header
as 'MPLS label stack entry based VLAN (M-VLAN) Tag'. The 20-bit PW label
field carries a 20-bit M-VID.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bob Briscoe
Sent: 17 July 2008 21:16
To: Loa Andersson
Cc: L2VPN; [email-masked]; [email-masked]; ccamp; pwe3; [email-masked]
Subject: Re: [Tsvwg] multiple-working group last call
ondraft-ietf-mpls-cosfield-def-04.txt

Loa,

I believe this draft has no technical effect. However there is some truth in
the idea that names are important.

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.

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.

Thoughts?

Bob

---

From: Loa Andersson <[email-masked]>
Date: Mon, 21 Jul 2008 10:37:43 +0200

Bob,

thanks for useful comments :)

Bob Briscoe wrote:
> 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...
> 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 

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.

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

I'll do it.

> doesn't change or contradict anything in 3270. It complements it.

I tend to agree, but have a problem how to capture this. We have

obsoletes
obsoleted by
updates
updated by

Would the following change to the paragraph in the ID suffice:

                                    "We recommend this scheme, which we
       call `per-domain ECT checking', and define it more precisely in
       the following section.  Its chief drawback is that it can cause
       packets to be forwarded after encountering congestion only to be
       dropped at the egress of the MPLS domain.  The rationale for this
       decision is given in Section 8.1.  This scheme is an update to RFC
       3032 [RFC3032] and RFC 3270 [RFC3270] is extended to allow for
       CoS Field code points to encode ECN information."

and - yes if you agree and could improve on grammar that would be great.

"The problem" I have is that even with the changed version this is an
"updates/updated by" the way it is used by the RFC Editor. We want to
point to this extension from 3270 to give implementation context.

/Loa

PS
you helped me pick another nit alos 5219 should be 5129

-- 
Loa Andersson

---

From: John Kenney <[email-masked]>
Date: Mon, 21 Jul 2008 10:07:21 -0400

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 21 Jul 2008 16:14:43 +0100

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

---

From: <[email-masked]>
Date: Tue, 22 Jul 2008 17:33:57 +0100

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, <[email-masked]> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ben Niven-Jenkins
> Sent: 21 July 2008 16:15
> To: John Kenney; Loa Andersson
> Subject: Re: [Tsvwg] [mpls] multiple-working group last call 
> on draft-ietf-mpls-cosfield-def-04.txt
> 
> >>> field for ECN in MPLS), is it really appropriate now to 
> call this a
> >>> CoS field?
> >>> 
> >>> Thinking out loud...

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 22 Jul 2008 09:47:06 -0700

What about 'CoS'? 

>From: [email-masked] [mailto:[email-masked]] 
>Sent: Tuesday, July 22, 2008 9:34 AM
>To: [email-masked]; [email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]; [email-masked]
>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, <[email-masked]> Networks Research 
>Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734 
>
>
>> Subject: Re: [Tsvwg] [mpls] multiple-working group last call on 
>> 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
>> 
>> 
>>