Skip to main content

Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field
draft-ietf-mpls-cosfield-def-08

Revision differences

Document history

Date Rev. By Action
2020-01-21
08 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-12-20
08 (System)
Received changes through RFC Editor sync (changed abstract to 'The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. …
Received changes through RFC Editor sync (changed abstract to 'The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".

Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field.

To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK]')
2017-05-16
08 (System) Changed document authors from "Loa Andersson" to "Loa Andersson, Rajiv Asati"
2015-10-14
08 (System) Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-cosfield-def@ietf.org to (None)
2009-03-18
08 (System) IANA Action state changed to No IC from In Progress
2009-02-25
08 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2009-02-25
08 Cindy Morgan [Note]: 'RFC 5462' added by Cindy Morgan
2009-02-25
08 (System) RFC published
2008-12-23
08 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2008-12-22
08 (System) IANA Action state changed to In Progress
2008-12-22
08 Amy Vezza IESG state changed to Approved-announcement sent
2008-12-22
08 Amy Vezza IESG has approved the document
2008-12-22
08 Amy Vezza Closed "Approve" ballot
2008-12-19
08 (System) Removed from agenda for telechat - 2008-12-18
2008-12-18
08 Cindy Morgan State Changes to Approved-announcement to be sent from IESG Evaluation by Cindy Morgan
2008-12-18
08 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded by Mark Townsley
2008-12-18
08 David Ward [Ballot Position Update] New position, Yes, has been recorded by David Ward
2008-12-17
08 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-12-17
08 Dan Romascanu [Ballot Position Update] New position, Yes, has been recorded by Dan Romascanu
2008-12-17
08 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2008-12-17
08 Tim Polk
[Ballot comment]
Abstract

s/current use of the EXP this field/current use of this field/

Section 1. Introduction

s/after the work on the document were started/after …
[Ballot comment]
Abstract

s/current use of the EXP this field/current use of this field/

Section 1. Introduction

s/after the work on the document were started/after the work on the document was started/

Section 3. Use of the TC field

s/have different TF fields from the rest/have different TC fields from the rest/
2008-12-17
08 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-12-17
08 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica
2008-12-17
08 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-12-16
08 Lars Eggert
[Ballot comment]
Section 1.2, paragraph 7:
>          The EXP field has been renamed to the TC field, and thus all
>  …
[Ballot comment]
Section 1.2, paragraph 7:
>          The EXP field has been renamed to the TC field, and thus all
>          references in RFC 3270 to EXP field SHOULD be taken to refer
>          to the TC field.

  I think the "SHOULD" here needs to be a "MUST" - otherwise it leaves
  the option of not using the new name. (And I don't believe an RFC2119
  term is appropriate here, so it should be a lowercase "must".) Similar
  phrasings occur in Sections 2.3 and 2.4, and they should be changed
  accordingly.
2008-12-16
08 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2008-12-15
08 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2008-12-15
08 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-12-14
08 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2008-12-06
08 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Radia Perlman.
2008-12-05
08 Ross Callon [Ballot Position Update] New position, Yes, has been recorded for Ross Callon
2008-12-05
08 Ross Callon Ballot has been issued by Ross Callon
2008-12-05
08 Ross Callon Created "Approve" ballot
2008-12-05
08 Ross Callon State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ross Callon
2008-12-05
08 Ross Callon Placed on agenda for telechat - 2008-12-18 by Ross Callon
2008-12-05
08 (System) New version available: draft-ietf-mpls-cosfield-def-08.txt
2008-12-04
08 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-12-01
08 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand
this document to have NO IANA Actions.
2008-11-25
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Radia Perlman
2008-11-25
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Radia Perlman
2008-11-20
08 Cindy Morgan Last call sent
2008-11-20
08 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2008-11-20
08 Ross Callon Last Call was requested by Ross Callon
2008-11-20
08 (System) Ballot writeup text was added
2008-11-20
08 (System) Last call text was added
2008-11-20
08 (System) Ballot approval text was added
2008-11-20
08 Ross Callon State Changes to Last Call Requested from Publication Requested by Ross Callon
2008-11-20
08 Ross Callon
PROTO write-up by George Swallow:


draft-ietf-mpls-cosfield-def-07.txt be published as an IETF stream RFC on the Standards Track.

(1.a) Who is the Document Shepherd for this …
PROTO write-up by George Swallow:


draft-ietf-mpls-cosfield-def-07.txt be published as an IETF stream RFC on the Standards Track.

(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

      George Swallow is the document shepherd.

(1.b) Has the document had adequate review both from key WG members
      and from key non-WG members? Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?
         
      The document is well reviewed it has been wg last called in
      the mpls, ccamp, pwe3, l2vpn and tsvwg as well as in the ITU-T
      ad-hoc team on mpls-tp. We have freceived a positive response
      from the ITU-T ad-hoc team

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

      no

(1.d) Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of? For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it. In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here. Has an IPR disclosure related to this document
      been filed? If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.

      no

(1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

      very solid

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director. (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)
       
      no

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/). Boilerplate checks are
      not enough; this check needs to be thorough. Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

      yes - there is four informational RFCs (RFC 3272, RFC 3469,
      RFC 3564 and RFC 3985) that are listed as ormative references.
      This is because this document makes manadatory changes to these
      RFCs, the working group, the working group chairs and the authors
      are uncertain of the correct way to handle this, but will have
      no problem moving these to informative referenceds by a
      RFC Editor note.

(1.h) Has the document split its references into normative and
      informative? Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state? If such normative references exist, what is the
      strategy for their completion? Are there normative references
      that are downward references, as described in [RFC3967]? If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

      the references are split into normative and informative
      references, however see 1.g above

(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document? If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries? Are the IANA registries clearly identified? If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations? Does it suggest a
      reasonable name for the new registry? See [RFC5226]. If the
      document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

      The IANA considerations section exists, but there are no requests
      for IANA allocations.

(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

      The documents is text document written in plain ascii.

(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up. Please provide such a Document
      Announcement Write-Up? Recent examples can be found in the
      "Action" announcements for approved documents. The approval
      announcement contains the following sections:

      Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

      The early MPLS documents defined the form of the MPLS Label Stack
      entry.  This include a three bit field called the "EXP field". The
      exact use of this field was not defined by these documents, except
      to state that it was to be "reserved for experimental use".

      Although the intended use of the EXP field was as a "Class of
      Service" field, it was not named the "Class of Service" (CoS) field
      by these early documents because the use of such a CoS field was
      not considered to be sufficiently defined.  Today a number of
      standards documents define its usage as a CoS field.

      To avoid misunderstanding about how this field may be used, it has
      become increasingly necessary to rename this field.  This document
      changes the name of the field to the "Traffic Class field" ("TC
      field".)  In doing so it also updates documents that define the
      current use of the EXP this field.

      Comment:
      The document addresses a problem that we been aware for a long
      time, but that has become urgent only when we started work closely
      with ITU-T on MPLS-TP.
      At the core the document is a simple name change, but also contains
      some consequent updates to existing RFCs.

      Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

      No controversies other than what name to chose for the field,
      at the final wg last call we had 100% backing of the choosen
      name . Traffic Class (TC).

      Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

      Since this is basically a name change of one of the fields in
      a MPLS Label Stack entry. The question abotu implementaions are
      out of scope.
2008-11-20
08 Ross Callon
PROTO write-up by George Swallow:


draft-ietf-mpls-cosfield-def-07.txt be published as an IETF stream RFC on the Standards Track.

(1.a) Who is the Document Shepherd for this …
PROTO write-up by George Swallow:


draft-ietf-mpls-cosfield-def-07.txt be published as an IETF stream RFC on the Standards Track.

(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

      George Swallow is the document shepherd.

(1.b) Has the document had adequate review both from key WG members
      and from key non-WG members? Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?
         
      The document is well reviewed it has been wg last called in
      the mpls, ccamp, pwe3, l2vpn and tsvwg as well as in the ITU-T
      ad-hoc team on mpls-tp. We have freceived a positive response
      from the ITU-T ad-hoc team

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

      no

(1.d) Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of? For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it. In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here. Has an IPR disclosure related to this document
      been filed? If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.

      no

(1.e) How solid is the WG consensus behind this document? Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?

      very solid

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director. (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)
       
      no

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/). Boilerplate checks are
      not enough; this check needs to be thorough. Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

      yes - there is four informational RFCs (RFC 3272, RFC 3469,
      RFC 3564 and RFC 3985) that are listed as ormative references.
      This is because this document makes manadatory changes to these
      RFCs, the working group, the working group chairs and the authors
      are uncertain of the correct way to handle this, but will have
      no problem moving these to informative referenceds by a
      RFC Editor note.

(1.h) Has the document split its references into normative and
      informative? Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state? If such normative references exist, what is the
      strategy for their completion? Are there normative references
      that are downward references, as described in [RFC3967]? If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

      the references are split into normative and informative
      references, however see 1.g above

(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document? If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries? Are the IANA registries clearly identified? If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations? Does it suggest a
      reasonable name for the new registry? See [RFC5226]. If the
      document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG
      can appoint the needed Expert during the IESG Evaluation?

      The IANA considerations section exists, but there are no requests
      for IANA allocations.

(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

      The documents is text document written in plain ascii.

(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up. Please provide such a Document
      Announcement Write-Up? Recent examples can be found in the
      "Action" announcements for approved documents. The approval
      announcement contains the following sections:

      Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

      The early MPLS documents defined the form of the MPLS Label Stack
      entry.  This include a three bit field called the "EXP field". The
      exact use of this field was not defined by these documents, except
      to state that it was to be "reserved for experimental use".

      Although the intended use of the EXP field was as a "Class of
      Service" field, it was not named the "Class of Service" (CoS) field
      by these early documents because the use of such a CoS field was
      not considered to be sufficiently defined.  Today a number of
      standards documents define its usage as a CoS field.

      To avoid misunderstanding about how this field may be used, it has
      become increasingly necessary to rename this field.  This document
      changes the name of the field to the "Traffic Class field" ("TC
      field".)  In doing so it also updates documents that define the
      current use of the EXP this field.

      Comment:
      The document addresses a problem that we been aware for a long
      time, but that has become urgent only when we started work closely
      with ITU-T on MPLS-TP.
      At the core the document is a simple name change, but also contains
      some consequent updates to existing RFCs.

      Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

      No controversies other than what name to chose for the field,
      at the final wg last call we had 100% backing of the choosen
      name . Traffic Class (TC).

      Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

      Since this is basically a name change of one of the fields in
      a MPLS Label Stack entry. The question abotu implementaions are
      out of scope.
2008-11-20
08 Ross Callon Draft Added by Ross Callon in state Publication Requested
2008-11-18
07 (System) New version available: draft-ietf-mpls-cosfield-def-07.txt
2008-11-17
06 (System) New version available: draft-ietf-mpls-cosfield-def-06.txt
2008-10-17
05 (System) New version available: draft-ietf-mpls-cosfield-def-05.txt
2008-07-07
04 (System) New version available: draft-ietf-mpls-cosfield-def-04.txt
2008-07-04
03 (System) New version available: draft-ietf-mpls-cosfield-def-03.txt
2008-06-11
02 (System) New version available: draft-ietf-mpls-cosfield-def-02.txt
2008-06-04
01 (System) New version available: draft-ietf-mpls-cosfield-def-01.txt
2008-05-19
00 (System) New version available: draft-ietf-mpls-cosfield-def-00.txt