An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks
Note: This ballot was opened for revision 09 and is now closed.Search Mailarchive
(Ron Bonica) Yes
(Stewart Bryant) Yes
(Adrian Farrel) Yes
Muly Ilan raised the following points on the MPLS list. They should be looked at: > 1. Table 2, second row - only Lock Instruct is G-Ach based. Loopback > is a management command. > > 2. Table 2, second row - LSP Ping is not related to Lock Instruct or > loopback command. > > 3. Table 2, third row - Lock Instruct is not indicated by a flag in > AIS message and is not discussed in RFC6427. > > 4. Section 5.2, third paragraph - need rewriting, per RFC6435 > there's no loopback request message nor loopback response message.
(Gonzalo Camarillo) No Objection
Benoit Claise No Objection
- Thanks for this document, and specifically for the tables in section 4, as it's difficult to find his way in a world full of MPLS OAM RFCs (requirements, framework, Fault specific, Packet Loss and Delay, you name it ). Along the same lines, I welcome http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-06, which has got a broader scope. - o The OAM toolset developed for MPLS based transport networks needs to be fully inter-operable with existing MPLS OAM tools as documented in [RFC 5860]. Are you referring to http://tools.ietf.org/html/rfc5860#section-2.1.6 When MPLS-TP is run with IP routing and forwarding capabilities, it MUST be possible to operate any of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping , MPLS-BFD , VCCV , and VCCV-BFD ). The document would benefit from clearly identifying what you mean. This is even more confusing because you mention just below: The MPLS-TP OAM toolset is based on the following existing tools: o LSP-Ping as defined in [RFC 4379]. o Bidirectional Forwarding Detection (BFD) as defined in [RFC 5880] and refined in [RFC 5884]. o ITU-T OAM for Ethernet toolset as defined in [Y.1731]. This has been used for functionality guidelines for the performance measurement tools that were not previously supported in MPLS. It should be noted that certain extensions and adjustments have been specified relative to the existing MPLS tools, in order to conform to the transport environment and the requirements of MPLS-TP. However, compatibility with the existing tools has been maintained. "compatibility with the existing tools has been maintained" I guess that you meant the list above: LSP-Ping, BFD, Y.1731. So what about the delta from my previous point: VCCV, and VCCV-BFD?
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
(Stephen Farrell) No Objection
(Oops wrong button, I've no objection really:-) - draft-ietf-mpls-tp-security-framework-02, May 2011 was updated by a -03 in October 2011. - weird references, the spaces muck up tools: [MPLS TP ITU Idents] [MPLS-TP Security Frwk] - s/MPSL-TP/MPLS-TP/ maybe?
(Brian Haberman) No Objection
(Russ Housley) No Objection
(Barry Leiba) No Objection
-- Section 7 -- In addition to implement security protocol, tools, and mechanisms, following strict operation security procedures is very important, especially MPSL-TP static provisioning processes involve operator direct interactions with NMS and devices, its critical to prevent human errors and malicious attacks. This paragraph needs to be turned into more understandable English. I'd offer, but I don't understand what it's trying to say well enough to do it (hence, this comment). I suggest that it needs to be two or three sentences, rather than just one, and the grammar needs to be corrected so it's clear what it's saying. [I note that the rest of the document is fine to read; it's only this section that has any notable problem.] The next paragraph also has a couple of minor grammatical errors, but it's understandable: OLD Since MPLS-TP OAM uses G-ACh, the security risks and mitigation described in [RFC 5085] apply here. In short, the G-ACh could be intercepted, or false G-ACh packets could be inserted. DoS attack could happen by flooding G-ACh messages to peer devices. To mitigate this type of attacks, throttling mechanisms can be used. For more details, please see [RFC 5085]. NEW Since MPLS-TP OAM uses G-ACh, the security risks and mitigation described in [RFC 5085] apply here. In short, the G-ACh could be intercepted, or false G-ACh packets could be inserted. DoS attacks can be mounted by flooding G-ACh messages to peer devices. To mitigate this type of attack, throttling mechanisms can be used. For more details, please see [RFC 5085].
(Pete Resnick) No Objection
(Robert Sparks) No Objection
(Martin Stiemerling) No Objection
Section 8., paragraph 3: > Thanks to Rui Costa for his review and comments which helped improve > this doecument. s/doecument/document/