Skip to main content

The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)
draft-sprecher-mpls-tp-oam-considerations-03

Revision differences

Document history

Date Rev. By Action
2012-05-15
03 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2012-05-14
03 (System) IANA Action state changed to No IC from In Progress
2012-05-14
03 (System) IANA Action state changed to In Progress
2012-05-14
03 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2012-05-14
03 Amy Vezza IESG has approved the document
2012-05-14
03 Amy Vezza Closed "Approve" ballot
2012-05-13
03 Brian Carpenter Request for Telechat review by GENART Completed. Reviewer: Brian Carpenter.
2012-05-10
03 Amy Vezza State changed to Approved-announcement to be sent from IESG Evaluation
2012-05-10
03 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2012-05-09
03 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2012-05-09
03 Sean Turner [Ballot Position Update] New position, Yes, has been recorded for Sean Turner
2012-05-09
03 Adrian Farrel Ballot approval text was generated
2012-05-09
03 Adrian Farrel Ballot writeup was changed
2012-05-09
03 Adrian Farrel Ballot writeup was changed
2012-05-09
03 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms
2012-05-09
03 Adrian Farrel Ballot writeup was changed
2012-05-09
03 Adrian Farrel Ballot writeup was changed
2012-05-09
03 Adrian Farrel Ballot writeup was changed
2012-05-09
03 Adrian Farrel Ballot writeup was changed
2012-05-09
03 Adrian Farrel Ballot writeup was changed
2012-05-09
03 Adrian Farrel Ballot writeup was changed
2012-05-09
03 Adrian Farrel Ballot writeup was changed
2012-05-09
03 Adrian Farrel Ballot writeup was changed
2012-05-09
03 Benoît Claise
[Ballot comment]
Thanks for the document.

Three editorial points:
- Transport profile -> Transport Profile

- "It is possible to argue that using MPLS for …
[Ballot comment]
Thanks for the document.

Three editorial points:
- Transport profile -> Transport Profile

- "It is possible to argue that using MPLS for Transport is only a
  stepping stone in the middle of a longer transition."
Transport -> transport or Transport Profile?

-  "As we shall demonstrate, ..."
The RFC editor gave me in the past the advice to remove "we", "us", "our" from the future RFCs.
2012-05-09
03 Benoît Claise [Ballot Position Update] New position, Yes, has been recorded for Benoit Claise
2012-05-08
03 Adrian Farrel Ballot writeup was changed
2012-05-08
03 Stephen Farrell
[Ballot comment]

I fully support the conclusion here and the argument
varies from compelling at best to good enough at
worst.

typos:

s/documentationin/document in/?
s/viably/viability/ …
[Ballot comment]

I fully support the conclusion here and the argument
varies from compelling at best to good enough at
worst.

typos:

s/documentationin/document in/?
s/viably/viability/
s/a E1 only/an E1 only/
2012-05-08
03 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2012-05-08
03 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2012-05-08
03 Martin Stiemerling [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling
2012-05-07
03 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2012-05-07
03 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2012-05-06
03 Russ Housley
[Ballot comment]

  Section 7 should be removed before publication as an RFC.

  The Gen-ART Review by Brian Carpenter reported one editorial problem.
  …
[Ballot comment]

  Section 7 should be removed before publication as an RFC.

  The Gen-ART Review by Brian Carpenter reported one editorial problem.
  There is duplicated text in section 1.2:

  ...
  be managed using tools with similar look and feel.  The requirements
  specifications [RFC5654] and [RFC5860] specifications [RFC5654] and
  [RFC5860] capture the essential issues that must be resolved to allow
  ...
2012-05-06
03 Russ Housley [Ballot Position Update] New position, Yes, has been recorded for Russ Housley
2012-05-03
03 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2012-05-03
03 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2012-05-02
03 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2012-05-02
03 Barry Leiba
[Ballot comment]
Excellently written, clear document.

Just a few minor editorial things; no need to reply to them:

-- Section 3.4 --
OLD
  In …
[Ballot comment]
Excellently written, clear document.

Just a few minor editorial things; no need to reply to them:

-- Section 3.4 --
OLD
  In an isolated system this may be the
  case, however when, as is usually case with communications
  technologies, simplification in one element of the system introduces
  a (possibly non-linear) increase in complexity elsewhere.
NEW
  In an isolated system this may be the
  case; however, as is usually case with communications
  technologies, simplification in one element of the system introduces
  a (possibly non-linear) increase in complexity elsewhere.

OLD
  the cost of increased complexity at a peer network element we loose
  out economically
NEW
  the cost of increased complexity at a peer network element we lose
  out economically

-- Section 3.6 --
OLD
  At the very least, the evaluation of these questions constitute a
  cost and introduce delay for the operator.
COMMENT
The subject is "evaluation", not "questions", so it's singular.
NEW
  At the very least, the evaluation of these questions constitutes a
  cost and introduces delay for the operator.

-- Section 4.3.2.2 --
"straightforward" is one word, not hyphenated.  (Also in Appendix A.5)
2012-05-02
03 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2012-04-30
03 Stewart Bryant [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant
2012-04-30
03 Adrian Farrel State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2012-04-30
03 Adrian Farrel Ballot writeup was changed
2012-04-30
03 Nurit Sprecher New version available: draft-sprecher-mpls-tp-oam-considerations-03.txt
2012-04-30
02 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-04-30
02 Nurit Sprecher New version available: draft-sprecher-mpls-tp-oam-considerations-02.txt
2012-04-29
01 Adrian Farrel Ballot writeup was changed
2012-04-29
01 Adrian Farrel Placed on agenda for telechat - 2012-05-10
2012-04-29
01 Adrian Farrel Stream changed to IETF from None
2011-11-02
01 Adrian Farrel State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead.
2011-10-28
01 Adrian Farrel Removed from agenda for telechat
2011-10-24
01 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-10-19
01 Amanda Baber We understand that this document doesn't require any IANA actions.
2011-10-10
01 Samuel Weiler Request for Last Call review by SECDIR is assigned to Jeffrey Hutzelman
2011-10-10
01 Samuel Weiler Request for Last Call review by SECDIR is assigned to Jeffrey Hutzelman
2011-10-06
01 David Harrington Request for Last Call review by TSVDIR is assigned to Martin Stiemerling
2011-10-06
01 David Harrington Request for Last Call review by TSVDIR is assigned to Martin Stiemerling
2011-09-26
01 Amy Vezza Last call sent
2011-09-26
01 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'The Reasons for Selecting a Single Solution for MPLS-TP OAM'
  as an Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology
  for use in transport network deployments. That is, MPLS-TP is a set
  of functions and features selected from the wider MPLS toolset and
  applied in a consistent way to meet the needs and requirements of
  operators of packet transport networks.

  During the process of development of the profile, additions to the
  MPLS toolset have been made to ensure that the tools available met
  the requirements. These additions were motivated by MPLS-TP, but form
  part of the wider MPLS toolset such that any of them could be used in
  any MPLS deployment.

  One major set of additions provides enhanced support for Operations,
  Administration, and Maintenance (OAM). This enables fault management
  and performance monitoring to the level needed in a transport
  network. Many solutions and protocol extensions have been proposed to
  address these OAM requirements, and this document sets out the
  reasons for selecting a single, coherent set of solutions for
  standardization.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/


No IPR declarations have been submitted directly on this I-D.
2011-09-26
01 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2011-09-26
01 Adrian Farrel Ballot has been issued
2011-09-26
01 Adrian Farrel Created "Approve" ballot
2011-09-26
01 Adrian Farrel Placed on agenda for telechat - 2011-11-03
2011-09-26
01 Adrian Farrel Last Call was requested
2011-09-26
01 Adrian Farrel State changed to Last Call Requested from Publication Requested.
2011-09-26
01 Adrian Farrel Last Call text changed
2011-09-26
01 (System) Ballot writeup text was added
2011-09-26
01 (System) Last call text was added
2011-09-26
01 Adrian Farrel Ballot writeup text changed
2011-09-26
01 Cindy Morgan
(1.a) Who is the Document Shepherd for this document? Has the
      Document Shepherd personally reviewed this version of the document
    …
(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?

      Ross Callon (rcallon@juniper.net) is the document shepherd.
      He has personally reviewed the document and believes it is ready
      for forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key members of
      the interested community and others? Does the Document Shepherd
      have any concerns about the depth or breadth of the reviews that
      have been performed?

      The document has been reviewed by key experts in the IETF process
      and individuals with in-depth understanding of the MPLS-TP project.

      As an AD-sponsored document, the work will be subject to a four
      week IETF last call during which it will explicitly be drawn to
      the attention of the MPLS and PWE3 working groups to ensure full
      review.

      After that review, the document shepherd believes there will have
      been ample review.

(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?

      There is no special requirement for additional review.

(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 interested community has discussed those issues and has
      indicated that it still wishes to advance the document, detail
      those concerns here.

      The document shepherd has no concerns.

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

      It is hard to measure consensus of the "interested community" for
      an individual submission. There is certainly strong concurrence
      of a large number of key individuals. In general there has been
      silence from the wider community, but the IETF last call and poll
      of the working groups described in 1.b will measure consensus.

(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 appeal or discontent has been mentioned.

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits? (See the Internet-Drafts Checklist
      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?

      The Document Shepherd has verified that the document passes
      idnits.

      The document contains no formal language needing additional
      review.

(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 correctly and all normative references
      are already RFCs. There are no downward references.

(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 suggested a reasonable name for the new registry? See
      [I-D.narten-iana-considerations-rfc2434bis]. 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 document contains a null IANA considerations section which is
      consistent with the body of the document.

(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 document contains no formal language.

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

Technical Summary

  The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology
  for use in transport network deployments. That is, MPLS-TP is a set
  of functions and features selected from the wider MPLS toolset and
  applied in a consistent way to meet the needs and requirements of
  operators of packet transport networks.

  During the process of development of the profile, additions to the
  MPLS toolset have been made to ensure that the tools available met
  the requirements. These additions were motivated by MPLS-TP, but form
  part of the wider MPLS toolset such that any of them could be used in
  any MPLS deployment.

  One major set of additions provides enhanced support for Operations,
  Administration, and Maintenance (OAM). This enables fault management
  and performance monitoring to the level needed in a transport
  network. Many solutions and protocol extensions have been proposed to
  address these OAM requirements, and this document sets out the
  reasons for selecting a single, coherent set of solutions for
  standardization.

Working Group Summary

  This document is an individual submission via AD sponsorship aiming
  to gain IETF consensus. It is not the product of a working group.

  The work is a description of why it would be a bad idea to have two
  solutions for MPLS-TP OAM. MPLS-TP OAM was developed by the IETF in
  the MPLS and PWE3 working groups, so clearly this document is
  relevant to those working groups.

  However, this document does not contain technical details of MPLS-TP
  OAM, and does not make any comment on the judgement of the working
  groups in their technical decisions. The document is more of an
  analysis of wider IETF policy and process.

  It is the opinion of the document shepherd and sposoring AD that
  discussion of this document on the working group lists would be a
  distraction from the techncial protocol work that the working groups
  need to do.

Document Quality

  This is an Informational I-D with nothing to implement. IETF
  consensus in this document is important in its applicability to
  the wider IETF community.
2011-09-26
01 Cindy Morgan Draft added in state Publication Requested
2011-09-26
01 Cindy Morgan [Note]: 'Ross Callon (rcallon@juniper.net) is the document shepherd.' added
2011-09-23
01 (System) New version available: draft-sprecher-mpls-tp-oam-considerations-01.txt
2011-08-03
00 (System) New version available: draft-sprecher-mpls-tp-oam-considerations-00.txt