Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks
Note: This ballot was opened for revision 07 and is now closed.
(Alex Zinin) Yes
(Brian Carpenter) No Objection
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Sam Hartman) (was Discuss) No Objection
(Scott Hollenbeck) (was Discuss) No Objection
draft-ietf-mpls-oam-requirements-06: Acronyms in the title should probably be expanded.
(Russ Housley) No Objection
Comment (2005-12-15 for -** No value found for 'p.get_dochistory.rev' **)
draft-ietf-mpls-oam-frmwk-04, Section 7: s/IP based tools/IP-based tools/
(Mark Townsley) (was Discuss) No Objection
(Bert Wijnen) (was Discuss, No Record, Discuss, No Objection) No Objection
---------- MIB Doctor comments Since new revisions are expected on both documents, let me just copy some MIB doctor review comments, so that the authors can take this into consideration for the new revisions. --- from Mike Heard: NITs in draft-ietf-mpls-oam-requirements-06.txt: abstract uses the imperative "MAY" in a context where the ordinary verb "may" is required (the same error occurs at other places in the document; I don't think imperatives belong here at all). Some acronyms in the abstract also may need to be expanded there (judgment call). Also replace "this draft" by "this document". In Section 2 please exand "LSP" and "TE" and all other acronyms on or prior to first use (reverse order of subsections if necessary). Eliminate one of the duplicate definitions of "Head-end Label Switch Router". More substantive: it is news to me that ICMP is part of the MPLS control plane (sec. 4.1) ... I thought it was part of the data plane, as far as MPLS was concerned. I stop here on minor things that should have been corrected before the doc went to the IESG (grumble). Having said all that, I would be OK to have it published once it got cleaned up (assuming that the responsible AD can vouch that the MPLS network operator community is happy with its content. Regarding draft-ietf-mpls-oam-frmwk-03.txt -- the title led me to expect some real content regarding how OAM would be carried out on MPLS networks. I didn't see any. I am not sure what purpose this document serves. I do not understand why it needs to be published. ---- from Dan Romascanu: draft-ietf-mpls-oam-requirements-06.txt 4.9 Standard Management Interfaces The wide-spread deployment of MPLS requires common information modeling of management and control of OAM functionality. This is reflected in the the integration of standard MPLS-related MIBs (e.g. [RFC3813][RFC3812][RFC3814]) for fault, statistics and configuration management. These standard interfaces provide operators with common programmatic interface access to operations and management functions and their status. ... Beyond the word repetition in the 3rd line ... What is (are) the requirement(s)? This is in a requirements section. A common information model? Which one, needs it be defined in the IETF, some other place? SNMP support? Define another MIB module for MPLS OAM? The listed MIB documents have no direct relation with MPLS OAM. I believe that this section needs clarification and re-wording ---- from Bert Wijnen: I actually reviewed a pre-copy of revision 4 for the frmwrk doc: - I do not see why there is thus MUST/SHOULD/etc in the Terminology section. Only MUST is used once in the Security Considerations, and even there, a lower case must makes much more sense - typos: section 1: the required the applicability of data plane OAM functions. Included s/the// at least once? figure 1: s/dignose/diagnose/ top of page 7: able to automatically remove the defective resources from and the s/and// ?? - Mmmm I wonder: sect 2: FCAPS Fault management, Configuration management, Administration management, Provisioning management, and Security management I thought that the P stands for Performance and not Provisioning. Anyway, if "Provisioning" is intended, then you may want to be consistent throughout your dopcument. sect 7, end of 2nd para: and authorization for OAM technologies is something that MUST be considered when designing network mechanism which satisfy the requirements presented in this document. I though "this document" is a "Framework" and not a "Requirements" document??