Subject: [mpls] Lock Instruction functionality in MPLS OAM

From: Greg Mirsky <[email-masked]>
Date: Wed, 5 Oct 2011 12:55:29 -0700

Dear All,
the latest version of LI/LB in MPLS-TP OAM defines format only of Lock
Instruct. It is my understanding that unlocking can be done via the
management plane and will not be result of timed out LI OAM messages. I
think that since a transport path can be locked via OAM command it is
logical to have a way to unlock it through OAM as well. UnLock function can
be signaled by allocating one of Reserved bits in LI OAM message. Obviously
such change will require updates to the document.

Regards,
Greg

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 5 Oct 2011 16:01:16 -0400

I have made similar comments privately to the document's editors about a month ago, so I agree that these changes need to be made.   They need to implement some sort of default unlocking (timeout) mechanism.  I also suggested improving the security section to include some form of authentication since you do not want a) the obvious malicious cases to happen, but also b) the unauthorized (often mistaken) case to happen and lock-out a network path.

	--Tom

On Oct 5, 2011, at 3:55 PM, Greg Mirsky wrote:

> Dear All,
> the latest version of LI/LB in MPLS-TP OAM defines format only of Lock Instruct. It is my understanding that unlocking can be done via the management plane and will not be result of timed out LI OAM messages. I think that since a transport path can be locked via OAM command it is logical to have a way to unlock it through OAM as well. UnLock function can be signaled by allocating one of Reserved bits in LI OAM message. Obviously such change will require updates to the document.
> 
> Regards,
> Greg
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 5 Oct 2011 13:13:03 -0700

Hi Tom,
I think that originally LI message was serving as keepalive but it changed
when we realized that LI messages are not forwarded past MP set in the
Loopback mode. Because of the an intermediate node being in the Loopback it
is difficult to have meaningful dead timer associated with Lock state.
I completely agree with need of Authentication. Perhaps we can define an
Authentication TLV and specify its applicability in MPLS-TP OAM?

Regards,
Greg

On Wed, Oct 5, 2011 at 1:01 PM, Thomas Nadeau <[email-masked]>wrote:

>
>        I have made similar comments privately to the document's editors
> about a month ago, so I agree that these changes need to be made.   They
> need to implement some sort of default unlocking (timeout) mechanism.  I
> also suggested improving the security section to include some form of
> authentication since you do not want a) the obvious malicious cases to
> happen, but also b) the unauthorized (often mistaken) case to happen and
> lock-out a network path.
>
>        --Tom
>
>

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 5 Oct 2011 16:47:27 -0400

On Oct 5, 2011, at 4:13 PM, Greg Mirsky <[email-masked]> wrote:

> Hi Tom,
> I think that originally LI message was serving as keepalive but it changed when we realized that LI messages are not forwarded past MP set in the Loopback mode. Because of the an intermediate node being in the Loopback it is difficult to have meaningful dead timer associated with Lock state.
> I completely agree with need of Authentication. Perhaps we can define an Authentication TLV and specify its applicability in MPLS-TP OAM?

this is a good idea.

> 
> Regards,
> Greg
> 
> On Wed, Oct 5, 2011 at 1:01 PM, Thomas Nadeau <[email-masked]> wrote:
>