[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Tsvwg] multiple-working group last call ondraft-ietf-mpls-cosfield-def-04.txt
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: l2vpn-bounces at ietf.org [mailto:l2vpn-bounces at ietf.org] On Behalf Of
Bob Briscoe
Sent: 17 July 2008 21:16
To: Loa Andersson
Cc: L2VPN; mpls at ietf.org; tsvwg at ietf.org; ccamp; pwe3; ahtmpls at itu.int
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.
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