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 |