Subject: [mpls] I-D Action: draft-ietf-mpls-tp-li-lb-04.txt

From: [email-masked]
Date: Fri, 02 Sep 2011 10:54:29 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title           : MPLS Transport Profile lock Instruct and Loopback Functions
	Author(s)       : Sami Boutros
                          Siva Sivabalan
                          Rahul Aggarwal
                          Martin Vigoureux
                          Xuehui Dai
	Filename        : draft-ietf-mpls-tp-li-lb-04.txt
	Pages           : 13
	Date            : 2011-09-02

     This document specifies one function and describes a second
     function which are applicable to MPLS transport networks. The first
     function enables an operator to lock a transport path while the
     second enables an operator to set, in loopback, a given node along
     a transport path. This document also defines the extension to MPLS
     operation, administration, and maintenance (OAM) to perform the
     lock function.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-li-lb-04.txt

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 2 Sep 2011 14:08:58 -0400

A few questions/concerns about this draft.

	First, there does not seem to be any consideration given to the expiry of the locking of a path. Once locked, there is no way to say set a timer to automatically reinstate the path.  This raises the concern that someone could close down one a path and then crash, never reenabling that path until someone notices that it is down. To this effect, I suggest that a path that is down either automatically reenable itself after some period of time, or triggers some sort of alarms that should be sent out.

	Second, this draft comes back to the concerns I raised recently regarding the use of the OAM channel to control (or provision) network nodes or paths, in this case, using a means that is adjacent to the typical management protocols used by management systems (i.e.: SNMP, Netconf, etc...).  So as I pointed out before, this could cause a discontinuity in the provisioning state of the network. For example, it is possible using this mechanism, for someone at one end of a network, to affect the provisioning state of many nodes elsewhere in the network.   Along this line, this also seems (to me) to violate the first tenant/requirement of MPLS-TP in that it should be able to run without a signaling protocol. Well, the more and more functions that are added to the OAM channel, the more and more this is starting to look like a control protocol.

	Finally, along the lines of the above points, I don't find the Security section very comforting given that this mechanism, if hi-jacked or just fat fingered, could disable an entire network of MPLS-TP paths (or at least change its configuration) based on gaining access via the authentication of a single node in that network. 

	--Tom

On Sep 2, 2011, at 1:54 PM, [email-masked] wrote:

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>