Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock

["Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[e-mail]>]

Would not it be fair to say the following?

*         lock is sent between endpoints (at the same layer) to synchronizes the lock status (either when the configuration is performed at one end, or to ensure that it was configured consistently at both ends).

*         Lock indication is sent by an endpoint of a server layer to its clients' endpoints to inform of the administrative lock status? 

 

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of ext Martin Vigoureux
Sent: Sunday, May 03, 2009 9:22 PM
To: Adrian Farrel; Malcolm Betts
Cc: [e-mail]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock

 

Adrian, Malcolm, all,

 

here are my thoughts on this:

 

As far as I understand, strictly speaking the Lock function

does not make sense on a unidir LSP. Indeed locking is performed

at the source point and so there is no need to send any message

to perform that Lock. (the potentially needed message is to inform

the end-point(s) of the status but that is lock notification.

I'll come back to this).

Therefore Lock is only needed on a bidir entity and what is exactly

needed is the capability to request the other end point to admin lock

its direction.

 

Coming back to the notification, I believe the following requirement

is needed:

    The MPLS-TP OAM toolset MUST provide a functionality to enable an

    End Point of a PW, LSP or Section to inform the End Point(s) of that

    LSP, PW, or Section that the PW, LSP or Section has been

    administratively shutdown at this End Point.

But it is conditionally needed. This function is *only* needed if

locking is achieved via Lock, otherwise if it is achieved via NMS

commands we (I hope) can safely assume that:

for undir LSP there will be commands at both ends, one saying lock, the 

other saying you are notified of other end locking.

for bidir LSP there will be commands at both ends, both saying lock and 

you are notified of other end locking.

 

The MUST is needed because the egress must be aware of the Lock because

we expect him to then inform client MEPs that are "downstream". (see

question at the end of this e-mail).

 

The small problem I have is that this function is a notification

one but really tightly linked to the Lock. In other words, I do

not know where this reqs better fits (especially wrt to the conditional

issue): in Lock or in Lock Notification?

Opinions are welcomed.

 

Therefore I propose:

 

2.2.x.  Lock

The MPLS-TP OAM toolset SHOULD provide a functionality to enable an

End Point of a bidirectional PW, LSP or Section to request to its

associated End Point that it administratively shuts down the direction

of the PW, LSP or Section for which it is the head-end.

 

This function SHOULD be performed on-demand.

 

This function SHOULD be performed between the End Points of a PW, LSP

or Section.

 

Note that administratively shutting down corresponds to stopping user 

traffic being sent on the PW, LSP or Section.

 

 

2.2.y.  Lock Notification

The MPLS-TP OAM toolset MUST provide a function to enable End Points

of a (server) LSP or Section to notify, of its administrative locking

status, the End Points of (client) PWs or LSPs affected by this status.

 

This function SHOULD be performed on-demand.

 

This function SHOULD be performed between the End Points of a PW, LSP

or Section.

-comment:

this needs to be rephrased as the notifying end points may not be

the same nodes than the notified end points.

The general case is in fact a notification between end points of 

different e.g., LSPs while the sentence seems to say that it is between

the end-points of the same e.g., LSP.

Any suggestion welcomed.

 

See also my e-mail:

MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" 

OAM messages ?

 

-question:

More generally to the comment above, who should notify and who should

notify whom?

I would tend to say:

the receiving node of a locked direction, informs downstream receiving

nodes of nested LSPs. This is a Fowrward Indication and if we do

so then receiving points MUST indeed be informed of a Lock (c.f.

discussion at the beginning of the e-mail).

Should source points (locking points) do some reverse indication and

notify the source points of the LSPs that are nested in the locked LSP?

(but this maybe falls in the RDI functionality).

 

I guess that is all, sorry for this long e-mail.

 

regards,

-m

 

 

Adrian Farrel a écrit :

> Hi Malcolm,

> 

>> To address the comments from Adrian I suggest the following

>> text for sections 2.2.7 and 2.2.8:

>> 

>> Note that this proposal assumes that the text related to local/remote

>> faults is moved from section 2.2.8 to section 2.2.2 as proposed in my

>> previous email.

>> 

>> We probably need to discuss this text on the MEAD team call next

>> week.

>> 

>> 2.2.7.  Lock

>> 

>> The OAM toolset SHOULD provide a function enabling a network operator to

>> administratively shut down a PW, LSP or Section; that is, to stop user

>> traffic being sent over that PW, LSP or Section.

> 

> This is great.

> Does it mean that we do not need to add the (similar) text on CV fault 

> behavior in section 2.2.3?

> It would seem so.

> 

>> The lock function MAY be applied to a unidirectional or a bidirectional

>> PW, LSP or Section.  If the lock function is activated at the head end

>> of one direction of a bidirectional PW, LSP or Section then it SHOULD be

>> possible to cause the lock function to be activated at the head end of

>> the other direction.

>> 

>> This function SHOULD be performed on-demand i.e. in response to an

>> operator command.

> 

> Or also in response to configured automatic behavior?

> 

> But this is not a protocol requirement.

> 

>> This function SHOULD be performed between End Points of PWs, LSPs

>> and Sections.

>> 

>> 2.2.8 Notification of Lock

>> 

>> If the lock function is supported the MPLS-TP OAM toolset MUST

>> provide a function to enable the End Point at the ingress to notify the

>> End Points at the egress that the lock function is active.  This

>> function SHOULD be performed pro-actively.

>> 

>> The MPLS-TP OAM toolset MUST allow for the distinction between

>> a fault condition and an administrative locking action.

> 

> Works for me.

> 

> A

> 

> 

> 

> _______________________________________________

> Mpls-interop mailing list

> [e-mail]

> https://www.ietf.org/mailman/listinfo/mpls-interop

> 

_______________________________________________

Mpls-interop mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/mpls-interop