Network Management Requirements for MPLS-based Transport Networks
RFC 5951
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
06 | (System) | Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-tp-nm-req@ietf.org to (None) |
|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2010-09-14
|
06 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue by Cindy Morgan |
|
2010-09-14
|
06 | Cindy Morgan | [Note]: changed to 'RFC 5951' by Cindy Morgan |
|
2010-09-14
|
06 | (System) | RFC published |
|
2009-11-09
|
06 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
|
2009-11-09
|
06 | (System) | IANA Action state changed to No IC from In Progress |
|
2009-11-09
|
06 | (System) | IANA Action state changed to In Progress |
|
2009-11-09
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2009-11-09
|
06 | Amy Vezza | IESG has approved the document |
|
2009-11-09
|
06 | Amy Vezza | Closed "Approve" ballot |
|
2009-11-09
|
06 | Adrian Farrel | State Changes to Approved-announcement to be sent from Waiting for AD Go-Ahead by Adrian Farrel |
|
2009-11-09
|
06 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
|
2009-10-26
|
06 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
|
2009-10-26
|
06 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
|
2009-10-26
|
06 | Amy Vezza | Last call sent |
|
2009-10-26
|
06 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2009-10-24
|
06 | Adrian Farrel | State Changes to Last Call Requested from IESG Evaluation::AD Followup by Adrian Farrel |
|
2009-10-24
|
06 | Adrian Farrel | Last Call was requested by Adrian Farrel |
|
2009-10-22
|
06 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
|
2009-10-22
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2009-10-22
|
06 | (System) | New version available: draft-ietf-mpls-tp-nm-req-06.txt |
|
2009-10-09
|
06 | (System) | Removed from agenda for telechat - 2009-10-08 |
|
2009-10-08
|
06 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Tobias Gondrom. |
|
2009-10-08
|
06 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
|
2009-10-08
|
06 | Ron Bonica | [Ballot comment] In section 2 I strongly recommend to used the conbination NETCONF/YANG as an example rather anything else. But Dan holds that point as … [Ballot comment] In section 2 I strongly recommend to used the conbination NETCONF/YANG as an example rather anything else. But Dan holds that point as part of his DISCUSS. |
|
2009-10-08
|
06 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2009-10-08
|
06 | Dan Romascanu | [Ballot comment] In the second paragraph of section 2 - the capitalization of the keywords is inconsistent. |
|
2009-10-08
|
06 | Dan Romascanu | [Ballot discuss] It's a well written document, with requirements expressed in a clear manner, with a good usage of solid references. The following comments if … [Ballot discuss] It's a well written document, with requirements expressed in a clear manner, with a good usage of solid references. The following comments if fixed would improved the document and dissipate a few unclarities: 1. Some text is missing concerning the operating model. An assumption is made about centralized management from a NMS (probably in a NOC) which has direct and indirect access to all NEs, this should be clearly articulated. It is less clear whether the assumption is made about what happens with the faults - are they logged locally, are alerts generated and sent to the NMS using some kinds of notification system, etc. ? 2. There is no discussion about the scalability of the management solutions. We are dealing with large scale deployments, with remote access required to all nodes, what are the requirements on this respect? 3. In section 2 I strongly recommend to used the conbination NETCONF/YANG as an example rather than NETCONF/XML. 4. Section 5.3.1 - I suggest that (also) RFC 3877 is mentioned as a reference for alarms severities 5. It is not clear to me what pro-active and on-demand modes refer to when it comes to performance monitoring. If pro-active mneans permanent reporting of performance information I do not see how this scales. |
|
2009-10-08
|
06 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
|
2009-10-08
|
06 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
|
2009-10-07
|
06 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
|
2009-10-07
|
06 | Amy Vezza | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Amy Vezza |
|
2009-10-07
|
06 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
|
2009-10-07
|
06 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
|
2009-10-07
|
06 | Lars Eggert | [Ballot comment] Section 7., paragraph 0: > 7. Performance Management Requirements Should this section refer to IETF or ITU-T metrics or is it OK … [Ballot comment] Section 7., paragraph 0: > 7. Performance Management Requirements Should this section refer to IETF or ITU-T metrics or is it OK to leave this open? |
|
2009-10-07
|
06 | Lars Eggert | [Ballot discuss] I hate to play downref police, however: Section 12.1., paragraph 2: > [2] Nadeau, T., et al, "Operations and Management (OAM) > … [Ballot discuss] I hate to play downref police, however: Section 12.1., paragraph 2: > [2] Nadeau, T., et al, "Operations and Management (OAM) > Requirements for Multi-Protocol Label Switched (MPLS) > Networks", RFC 4377, February 2006. DISCUSS: ** Downref: Normative reference to an Informational RFC: RFC 4377 (ref. '2') Section 12.1., paragraph 4: > [4] Jones, G., "Operational Security Requirements for Large > Internet Service Provider (ISP) IP Network > Infrastructure", RFC 3871, September 2004. DISCUSS: ** Downref: Normative reference to an Informational RFC: RFC 3871 (ref. '4') If the document had been shepherded according to PROTO, the shepherd would have had to check for downrefs and they could have been handled during IETF LC... |
|
2009-10-07
|
06 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
|
2009-10-06
|
06 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
|
2009-10-06
|
06 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
|
2009-10-06
|
06 | Russ Housley | [Ballot discuss] In the Gen-ART Review by Joel Halpern on 25-Sept-2009, asks some questions that ought to be answered before the document is approved. … [Ballot discuss] In the Gen-ART Review by Joel Halpern on 25-Sept-2009, asks some questions that ought to be answered before the document is approved. Is it reasonable for the references in the following sentence to be informational? Can one read this document and correctly understand it without reading these other documents? In writing this document, the authors assume the reader is familiar with references [12] and [15]. Will this document will be cited in other (solution or architecture) documents, which are explaining how they meet these requirements? If so, there are two loosely related issues: 1) There is some descriptive text which may be intended to also be providing requirements. 2) The actual requirements are not named or numbered, so it will be difficult for any other document to say "we provide A-Q, but we do not provide R for this reason ..." |
|
2009-10-06
|
06 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
|
2009-10-05
|
06 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
|
2009-10-01
|
06 | Amanda Baber | IANA comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2009-09-25
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
|
2009-09-25
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Tobias Gondrom |
|
2009-09-22
|
06 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
|
2009-09-22
|
06 | Adrian Farrel | Ballot has been issued by Adrian Farrel |
|
2009-09-22
|
06 | Adrian Farrel | Created "Approve" ballot |
|
2009-09-22
|
06 | Adrian Farrel | Placed on agenda for telechat - 2009-10-08 by Adrian Farrel |
|
2009-09-21
|
06 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
|
2009-09-21
|
06 | Adrian Farrel | Last Call was requested by Adrian Farrel |
|
2009-09-21
|
06 | Adrian Farrel | State Changes to Last Call Requested from Publication Requested by Adrian Farrel |
|
2009-09-21
|
06 | (System) | Ballot writeup text was added |
|
2009-09-21
|
06 | (System) | Last call text was added |
|
2009-09-21
|
06 | (System) | Ballot approval text was added |
|
2009-09-21
|
06 | Adrian Farrel | [Note]: 'Loa Andersson (loa@pi.nu) is the Document Shepherd.<br>Note that this document is a requirement document. For reasons that<br>have to do with how the … [Note]: 'Loa Andersson (loa@pi.nu) is the Document Shepherd.<br>Note that this document is a requirement document. For reasons that<br>have to do with how the ITU-T can reference RFCs we have opted to put<br>it on the Standards Track.' added by Adrian Farrel |
|
2009-09-21
|
06 | Cindy Morgan | [Note]: 'Loa Andersson (loa@pi.nu) is the Document Shepherd.' added by Cindy Morgan |
|
2009-09-21
|
06 | Cindy Morgan | The MPLS WG requests that: MPLS TP Network Management Requirements http://tools.ietf.org/html/draft-ietf-mpls-tp-nm-req-04 is published as an RFC on the standards track. Note that this document is … The MPLS WG requests that: MPLS TP Network Management Requirements http://tools.ietf.org/html/draft-ietf-mpls-tp-nm-req-04 is published as an RFC on the standards track. Note that this document is a requirement document. For reasons that have to do with how the ITU-T can reference RFCs we have opted to put it 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? Loa Andersson is the Document Shepherd. He has reviewed the codument and believes it is ready to be forwarded to the IESG for publication. > (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 review has been substantial. Considerable input to early revisions was received from MPLS WG participants and from a detailed review by members of ITU-T Study Group 15. The WG last call was liaised to the ITU-T and received a number of comments that were addressed in the final revision that was approved by the ITU-T in a liaison. The WG last call was notified to the PWE3 and CCAMP working groups. > (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. The document includes details of network management features, but was authored and reviewed by many people active in the Operations Area. > (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. One off-line comment that has been forwarded to the shepherd is that the style of the document is too much of an ITU-T document. This comment was not raised on the list and seems more related to the fact that the IETF is not familiar with requirements documents than based in any specific objections. > (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? Development of the document was performed within the MPLS-TP design team (c. 20 people) that strongly supports the work. There has also been some discussion on the MPLS-TP (open) mailing list, and there were no objections raised. > (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 threats or extreme discontent. > (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? All checks are clean. > (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]. References are correctly split. There are two normative references to I-Ds. draft-ietf-mpls-tp-oam-requirements has completed WG last call and will be ready for advancement soon. draft-ietf-mpls-tp-requirements is on the RFC Editor's Queue. There are two downrefs. These are deliberate. RFC 4377 Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks RFC 3871 Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure References to Informational RFC's 4377 and 3871 have to be made explicit in the IETF last call. > (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? There are no IANA actions associated with this document. A null IANA section is present. > (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? No such formal language. > (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 This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS transport profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports. Working Group Summary The document is part of the MPLS-TP project, the cooperation between IETF and ITU-T to specify an MPLS transport profile. There are no outstanding issues. It is put on the standards track to resolve issues around how the ITU-T references IETF documents. Document Quality The document is a requirements specification and will mainly be used as input to the network management solutions specifications that will be published shortly. |
|
2009-09-21
|
06 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
|
2009-09-18
|
05 | (System) | New version available: draft-ietf-mpls-tp-nm-req-05.txt |
|
2009-09-03
|
04 | (System) | New version available: draft-ietf-mpls-tp-nm-req-04.txt |
|
2009-08-31
|
03 | (System) | New version available: draft-ietf-mpls-tp-nm-req-03.txt |
|
2009-06-24
|
02 | (System) | New version available: draft-ietf-mpls-tp-nm-req-02.txt |
|
2009-04-16
|
01 | (System) | New version available: draft-ietf-mpls-tp-nm-req-01.txt |
|
2009-02-26
|
00 | (System) | New version available: draft-ietf-mpls-tp-nm-req-00.txt |