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

From: "Malcolm Betts" <[email-masked]>
Date: Fri, 1 May 2009 15:46:03 -0400

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. 

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. 

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.

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 2 May 2009 18:26:05 +0100

Hi Malcolm,

> To address the comments from Adrian I suggest the following
> text for sections 2.2.7 and 2.2.8:
>

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.

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

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.
>
> 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

---

From: Martin Vigoureux <[email-masked]>
Date: Sun, 03 May 2009 20:21:56 +0200

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 :
> _______________________________________________
> Mpls-interop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-interop
>

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 04 May 2009 00:59:03 +0200

Bonsoir Martin,

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

What should happen if the CP and MP are separated, i.e the
ingress point and egress poinr belong to different SP domains?

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

What do you mean by "its direction", the direction from "the
other end point" back to the "source point"?

> commands

This requires that both end points can be reached via the MP.

> we (I hope) can safely assume that:

Snip -- I will answer the next in a separate email--

Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 04 May 2009 01:09:19 +0200

Bonsoir Martin,

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

The answer was no.

> nodes of nested LSPs. 

To be more exact, the sink side of a locked LSP, PW, Section, has to
inform its clients.

> This is a Fowrward Indication and if we do

Isn't this notification already caused by the locking at the
far end?
Or is the locking only applied in one direction of a bi-directional
path? If yes, then the notification is not required.

Cheers, Huub.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 4 May 2009 08:09:55 +0200

Huub, 
I do not understand why you say that the separation of a CP and MP
indicates that the ingress and the egress point belong to different SP
domains?  
Best regards,
Nurit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Huub van
Helvoort
Sent: Monday, May 04, 2009 1:59 AM
To: Martin Vigoureux
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and
notification of lock

Bonsoir Martin,

Regards, Huub.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 4 May 2009 08:18:01 +0200

You say " To be more exact, the sink side of a locked LSP, PW, Section,
has to inform its clients.", BUT the client is not necessarily an
endpoint but may be an intermediate point, and it needs to notify its
endpoints, that means that a MIP generates an OAM message.
Long ago I discussed this point with Italo and he indicated to me that
it is not a generation of a message by a MIP BUT it is a variation of an
adaptation function at the client intermediate point. Although we are
talking here about a way to implement it, this is a conceptual issue
that we need to agree on.
Also, I think we should generalize the discussion instead of talking
every time about LSP, PW, section, etc. we should really talk about
client/server layers to cover cases of LSP hierarchies, etc. 
Best regards,
Nurit

-----Original Message-----
Sent: Monday, May 04, 2009 2:09 AM

Bonsoir Martin,

The answer was no.

Cheers, Huub.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 4 May 2009 08:22:04 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext Martin Vigoureux
Sent: Sunday, May 03, 2009 9:22 PM
To: Adrian Farrel; Malcolm Betts
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock

Adrian, Malcolm, all,

I'll come back to this).

its direction.

is needed:

Opinions are welcomed.

Therefore I propose:

2.2.x.  Lock

or Section.

 

2.2.y.  Lock Notification

or Section.

-comment:

Any suggestion welcomed.

See also my e-mail:

OAM messages ?

-question:

notify whom?

I would tend to say:

regards,

-m

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

>> week.

[email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 04 May 2009 09:14:26 +0200

Hi Nurit,

[hvh] because I should have used e.g. instead of i.e (it was late).
So there are cases that the lock in dication can only be transferred
via the DP.

Regards, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 04 May 2009 09:26:42 +0200

Hello Nurit,

You say " To be more exact, the sink side of a locked LSP, PW, Section,
has to inform its clients.",

[hvh] it should inform its client transport entities in the
server/client relation

BUT the client is not necessarily an
endpoint but may be an intermediate point, and it needs to notify its
endpoints, that means that a MIP generates an OAM message.

[hvh this requires that a MIP has the capability to
send OAM messages based on management command or based on
an indication of a MEP in a different layer.
This also requires that at every MEP location there are also
MIPs for every client entity serviced by that MEP.

[hvh] I agree with Italo.

[hvh] then I use server/client path/trail the next time, OK?

Regards, Huub.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 4 May 2009 09:47:27 +0200

Huub, 
You say " this requires that a MIP has the capability to send OAM
messages based on management command or based on an indication of a MEP
in a different layer. This also requires that at every MEP location
there are also
MIPs for every client entity serviced by that MEP."
This looks more as an implementation description. What is actually
required is that the endpoints of the client layer are informed of this
event. 
The way you describe it seems a little bit "against" the framework in
which it is specified that OAM messages cannot be initiated by MIPs.
That is why we actually say that this is an adaptation function, that
means that the message is initiated by the MEP of the server to the MEP
of the client.......
Best regards,
NUrit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Huub van
Helvoort
Sent: Monday, May 04, 2009 10:27 AM
To: [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and
notification of lock

Hello Nurit,

Regards, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 04 May 2009 11:27:23 +0200

Hi Nurit,

> there are also MIPs for every client entity serviced by that MEP."

 > endpoints, that means that a MIP generates an OAM message.

This is the disadvantage of top-posting. All your replies are
out of context and very difficult to follow.

> required is that the endpoints of the client layer are informed of this

Agreed.

> which it is specified that OAM messages cannot be initiated by MIPs.

Due to the top-posting you reversed the meaning of my description.

It is my opinion (which is in line with current standards) that a
MIP *cannot* initiate OAM messages.

> means that the message is initiated by the MEP of the server to the MEP

That is why I answered that I agree with Italo, who said the same......
(read my reply below).

Regards, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 04 May 2009 11:31:08 +0200

Huub,

please see inline,

regards,
-m

> ingress point and egress poinr belong to different SP domains?

[mvx] please se my other e-mail.

> other end point" back to the "source point"?

[mvx] in case of bidir, both nodes are sources points.
What I mean is that a node (A) should have the means to ask its
associated end point (Z) to Lock the direction of the LSP that
goes from Z to A.

> This requires that both end points can be reached via the MP.

[mvx] indeed but that does not contradict the above.

>> 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.
>>

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 04 May 2009 11:31:14 +0200

Huub,

I still do not understand how the context you mention impacts
what is written in the paragraph. Thanks.

regards,
-m

Huub van Helvoort a écrit :
>> the

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 04 May 2009 11:38:33 +0200

Dear Huub,

please see in-line.

regards,
martin

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

[mvx] well, I am not sure about this.

> To be more exact, the sink side of a locked LSP, PW, Section, has to

[mvx] Indeed but that is not precise enough, in my view.
Who are the clients? Both end points or only the one downstream?

> path? If yes, then the notification is not required.

It appear to me that you are mixing the notification at the same
layer and notification at the impacted client layers.
My question was:
in case a Lock is performed at one point I suppose we need to inform
the other end point of that status (same layer)
But then what do these two nodes do? Which node of the locked server
layer inform which node of the impacted clients layer?

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 04 May 2009 11:59:58 +0200

Nurit,

this is faithfull to the text I proposed.
regards,
-m

Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit :
> ·         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?
> 
>  
> 
>  
> 
> [mailto:[email-masked]] On Behalf Of ext Martin Vigoureux

---

From: "Malcolm Betts" <[email-masked]>
Date: Mon, 4 May 2009 08:27:26 -0400

Martin,

The key point is that the lock action is implemented locally.  e.g. at the sending end of a LSP the traffic can be blocked.  One example of the use of this is to allow a test source to be connected (vs. client traffic).  Even on a unidirectional LSP it is useful to have a notification sent to the receiving end of the LSP so that it is aware that it is not receiving "valid" client traffic.

On a bidirectional LSP this notification may be used to activate a lock in the reverse direction.

Hope this clears up the confusion.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Martin Vigoureux [mailto:[email-masked]] 
Sent: Sunday, May 03, 2009 2:22 PM
To: Adrian Farrel; Betts, Malcolm (CAR:X632)
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock

Adrian, Malcolm, all,

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 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

See also my e-mail:

-question:

regards,
-m

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 04 May 2009 14:31:30 +0200

Hi Martin,

> [mvx] please se my other e-mail.

[hvh] OK, I will.

> [mvx] indeed but that does not contradict the above.

OK, I was confused by the added *conditionally*

Cheers, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 04 May 2009 14:37:25 +0200

Hello Martin,

> what is written in the paragraph. Thanks.

Now that I am fully awake and re-read the text a few times
I understand the intention.
I just wanted to have some clarification.

Cheers, Huub.

================
>>>> Note that administratively shutting down corresponds to stopping 
>>>> user traffic being sent on the PW, LSP or Section.
>>>>
>>>>
>>>> 2.2.y.  Lock Notification

---

From: "Malcolm Betts" <[email-masked]>
Date: Mon, 4 May 2009 08:42:26 -0400

All,

I think you are making this far too complicated...  I see no need to
propagate the locked indication across layers.

If the operator decides to lock a LSP (for example to run a test) then
the clients of that LSP should be taken out of service before the lock
is applied.

When a server LSP detects the locked notification it informs the client
adaptation that it is no longer receiving valid traffic.  If the client
has already been taken out of service then this is a "don't care".  If
the client has not been taken out of service then it should raise an
alarm.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN
- IL/Hod HaSharon)
Sent: Monday, May 04, 2009 3:47 AM
To: [email-masked]; [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and
notificationof lock

Huub,

-----Original Message-----

Hello Nurit,

[hvh this requires that a MIP has the capability to send OAM messages
based on management command or based on an indication of a MEP in a
different layer.
This also requires that at every MEP location there are also MIPs for
every client entity serviced by that MEP.

Regards, Huub.

>> This is a Fowrward Indication and if we do so then receiving points 
>> MUST indeed be informed of a Lock (c.f.
> Isn't this notification already caused by the locking at the far end?

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 04 May 2009 14:45:17 +0200

cool :-)

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 04 May 2009 14:45:51 +0200

ok, perfect.

-m

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 04 May 2009 14:50:26 +0200

Malcolm,

I fully agree that the lock is performed locally.
I also agree that the other end point must be aware of this lock.
This is exactly what I have written below.

On bidir LSP the notification may be used to request the lock
at the far end but this is for me an implementation decision.
We should, as agreed during the call, stick to elementary
functionalities.
Therefore we need two distinct functionalities:
inform the far end that lock has been performed
request the far end to perform lock

do we agree on that?

one functionality I believe we also need is to inform client
layers of the lock condition of a server, but I'll discuss
this in the other e-mail you sent.

regards,
-m

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 04 May 2009 14:55:19 +0200

Bonjour Martin,

> please see in-line.

ditto

> [mvx] well, I am not sure about this.

[hvh] The definition used in ITU-T is:

MEG Intermediate Point (MIP) is an intermediate point in a MEG which
is capable of reacting to some OAM frames. A MIP does not initiate
OAM frames. A MIP takes no action on the transit packet flows.

> Who are the clients? Both end points or only the one downstream?

[hvh] only the downstream (sink) end points (MEPs).

> the other end point of that status (same layer)

[hvh] I agree

> layer inform which node of the impacted clients layer?

[hvh] the sink MEP of the server layer should inform
the sink MEPs of the client layer.

Cheers, Huub.

---

From: "Malcolm Betts" <[email-masked]>
Date: Mon, 4 May 2009 09:20:35 -0400

Martin,

I am tempted to simplify still further, just notify the far end that the lock is in place and allow the decision to lock the reverse direction to be a locally configured option.

I cannot think of a case where you would only want to lock one direction of a bidirectional LSP, so this would be the default behaviour.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Martin Vigoureux [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 8:50 AM
To: Betts, Malcolm (CAR:X632)
Cc: Adrian Farrel; [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock

Malcolm,

On bidir LSP the notification may be used to request the lock at the far end but this is for me an implementation decision.
We should, as agreed during the call, stick to elementary functionalities.
Therefore we need two distinct functionalities:
inform the far end that lock has been performed request the far end to perform lock

do we agree on that?

one functionality I believe we also need is to inform client layers of the lock condition of a server, but I'll discuss this in the other e-mail you sent.

regards,
-m

Malcolm Betts a écrit :
> 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
> this needs to be rephrased as the notifying end points may not be the 
> same nodes than the notified end points.
> 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:
> 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.
>>> 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.
>>>
>>> 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.
>>>
>>> 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 
>>> The MPLS-TP OAM toolset MUST allow for the distinction between a 
>>> fault condition and an administrative locking action.
>> Works for me.
>>
>> A
>>
>>
>>

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 04 May 2009 20:58:46 +0200

Malcolm,

it appears that we agree on the need for the two functionalities:
- notification to the receiving end point of lock having been
   performed at the source point.
- request from an end point that the other far end performs a lock.

What I do not understand is why do you want to force the piggybacking
of the latter on the former.
We should stick to required elementary functionalities and not impose
a given protocol implementation.

regards,
martin

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 04 May 2009 23:27:05 +0200

Hi Malcolm,

> the clients of that LSP should be taken out of service before the lock

That should be the proper procedure.

> the client has not been taken out of service then it should raise an

But shouldn't the client layer be able to determine whether
the fault cause is in its own layer or in the server layer?

This is similar to the notification server trail failure to
its client layer.

So in fact the same notification can be used for both cases.

Regards, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 04 May 2009 23:35:58 +0200

Hello Martin,

> request the far end to perform lock

Not replying for Malcolm, but sharing my own opinion:
Yes, I agree.

> this in the other e-mail you sent.

Is it necessary to be so  specific?
It should be sufficient to notify the client layer that
the path/trail is not usable, without telling the reason.
The only purpose of the notification is that the client
layer need not to take any fault locating actions.

(This is the same as my answer to Malcolm some minutes ago)

Best reagrds, Huub.

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Tue, 5 May 2009 00:51:05 -0500

Dear all,

See inline below. I am addressing the issue of notification across
layers, not addressing notifying the sink (egress) points.

Regards,

Kam

> From: [email-masked]
[mailto:[email-masked]]

> On Behalf Of Malcolm Betts

> Sent: Monday, May 04, 2009 8:42 AM

> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked];
mpls-

> [email-masked]

> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock

> andnotificationof lock

> propagate the locked indication across layers.

[Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected
interruption to the client services so that to reduce unnecessary alarm
being raised from the client layer.

> is applied.

[Lam, Hing-Kam (Kam)] This is a reasonable assumption and a good
practice. It will be helpful to explicitly say so in the document. The
reason is that now we are using the "LOCKED" state and "Lock" event of
the X.731 Administrative state model. There are additional state values
and events in the model. We need to be precise and accurate, in
particular if we support only a subset of the model. Otherwise it may
cause unnecessary confusion and inconsistence in the future. The
Administrative State model in X.731 defines three state values (namely:
UNLOCKED, LOCKED, and SHUTTING DOWN) and events as shown below. 

If you administratively lock a server, the server will enter the
"locked" state. Therefore the server will no longer be able to provide
its intended service (of supporting all its clients). The effect (i.e.
impact) on the clients is no different than a server failure. Usually
you don't want to do this. Instead, you would like to gracefully take
the server out of service, i.e. administratively shut down the server,
and by doing so the server will enter the "shutting down" state. The
"shutting down" state is a transition state. When the last user (in this
case the last client service) quit, then the server will automatically
enter the "locked" state. If we are not going to support the Shutting
Down state of the model, then you better either (1) take the clients of
the server LSP out of service before the lock is applied or (2) notify
the clients in advance, otherwise alarms will be raised against the
supported client services because of the unexpected interruption.

> >> the receiving node of a locked direction, informs downstream

> receiving

> >> notify the source points of the LSPs that are nested in the locked

> > LSP?

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Tue, 5 May 2009 11:44:20 +0200

Hi Lam,

I agree with you.

Besides, as many mails were sent on this issue,  I'd like to check with all of us where we are with Lock (2.2.x) and Lock Notification(2.2.y) requirements. 

I know we are dealing with requirements and not with solutions, but please let's consider the following example:

topology is A <---> B <---> C <---> D 

LSP1 goes A-B-C-D

- The operator decides to set in A LSP1 administratevly down , due for example to an out of service test on the path. 

The Lock requirement (2.2.x ) requires that A is able to set its peer MEP D in administratevly lock state. As Lam reported , we are using the "LOCKED" state and "Lock" event of the X.731 Administrative state model. This implies that when LSP1 in D enters in the administrative lock state, all traffic on the path MUST be blocked; but MEP D must notify the clients , otherwise alarms will be raised against the supported client services because of the unexpected interruption; i.e. D should send Lock Notification(2.2.y) to its own clients.

- In case of bidirectional path even in MEP A the LSP1 (rx direction ) enters in administrative lock state and even MEP A should notify the client(s) transported by the path ( i.e. In the backward direction; req. 2.2.y)

- My understanding is that the client to which the Lock Notification is sent are always MEPs as MIP are transparent to Lock and Lock Notification 

- When a MEP receives a Lock Notification it can in turn notify  its MPLS-TP client MEPs or map it into an equivalent signal for whatever client layer is then being carried.

- Lock Notification functionality (req 2.2.y ) applies to all scenarios where server enters the "locked" state ; for instance if a port in LSR B is set administratevly down (" Lock" event of the X.731 Administrative state model) LSR B, as Server MEP of paths transimitted and received on the port , should generate Lock Notification on all these paths, for example towards D and A , MEPs of LSP1. 

Are we all agree on these ?

Best regards,

Annamaria 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lam, Hing-Kam (Kam)
Sent: martedì 5 maggio 2009 7.51
To: Malcolm Betts; Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; [email-masked]; Martin Vigoureux
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock

Dear all,

See inline below. I am addressing the issue of notification across layers, not addressing notifying the sink (egress) points.

Regards,

Kam

> From: [email-masked] [mailto:[email-masked]]

> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; mpls-

> propagate the locked indication across layers.

[Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected interruption to the client services so that to reduce unnecessary alarm being raised from the client layer.

> is applied.

[Lam, Hing-Kam (Kam)] This is a reasonable assumption and a good practice. It will be helpful to explicitly say so in the document. The reason is that now we are using the "LOCKED" state and "Lock" event of the X.731 Administrative state model. There are additional state values and events in the model. We need to be precise and accurate, in particular if we support only a subset of the model. Otherwise it may cause unnecessary confusion and inconsistence in the future. The Administrative State model in X.731 defines three state values (namely: UNLOCKED, LOCKED, and SHUTTING DOWN) and events as shown below. 

If you administratively lock a server, the server will enter the "locked" state. Therefore the server will no longer be able to provide its intended service (of supporting all its clients). The effect (i.e. impact) on the clients is no different than a server failure. Usually you don't want to do this. Instead, you would like to gracefully take the server out of service, i.e. administratively shut down the server, and by doing so the server will enter the "shutting down" state. The "shutting down" state is a transition state. When the last user (in this case the last client service) quit, then the server will automatically enter the "locked" state. If we are not going to support the Shutting Down state of the model, then you better either (1) take the clients of the server LSP out of service before the lock is applied or (2) notify the clients in advance, otherwise alarms will be raised against the supported client services because of the unexpected interruption.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 May 2009 11:01:54 +0100

Am I missing something?
Does notification across layers take place within a node or on the wire?

Thanks,
Adrian

----- Original Message ----- 
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: "Malcolm Betts" <[email-masked]>; "Sprecher, Nurit (NSN - IL/Hod
HaSharon)" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Martin Vigoureux"
<[email-masked]>
Sent: Tuesday, May 05, 2009 6:51 AM
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof
lock

Dear all,

Regards,

Kam

> [email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 05 May 2009 12:10:42 +0200

Ciao Annamaria,

You wrote:

> Besides, as many mails were sent on this issue,  I'd like to check with 
> all of us where we are with Lock (2.2.x) and Lock Notification(2.2.y) 
> requirements.
> 
> I know we are dealing with requirements and not with solutions, but 
> please let's consider the following example:
> 

[hvh] so the LSP1 MEPs are located in LSR A and LSR D

> - The operator decides to set in A LSP1 administratevly down , due for 
> example to an out of service test on the path.
> 
> The Lock requirement (2.2.x ) requires that A is able to set its peer 
> MEP D in administratevly lock state. As Lam reported , we are using the 
> "LOCKED" state and "Lock" event of the X.731 Administrative state model. 
> This implies that when LSP1 in D enters in the administrative lock 
> state, all traffic on the path MUST be blocked; but MEP D must notify 
> the clients , otherwise alarms will be raised against the supported 
> client services because of the unexpected interruption; i.e. D should 
> send Lock Notification(2.2.y) to its own clients.

[hvh] agree

> - In case of bidirectional path even in MEP A the LSP1 (rx direction ) 
> enters in administrative lock state and even MEP A should notify the 
> client(s) transported by the path ( i.e. In the backward direction; req. 
> 2.2.y)

[hvh] OK

> - My understanding is that the client to which the Lock Notification is 
> sent are always MEPs as MIP are transparent to Lock and Lock Notification

[hvh] yes indeed

> - When a MEP receives a Lock Notification it can in turn notify  its 
> MPLS-TP client MEPs or map it into an equivalent signal for whatever 
> client layer is then being carried.

[hvh] correct

> - Lock Notification functionality (req 2.2.y ) applies to all scenarios 
> where server enters the "locked" state ; for instance if a port in LSR B 
> is set administratevly down (" Lock" event of the X.731 Administrative 
> state model) LSR B, as Server MEP of paths transimitted and received on 
> the port , should generate Lock Notification on all these paths, for 
> example towards D and A , MEPs of LSP1.

[hvh] note that LSR B does not have a MEP on LSP1.
The scenario you describe only works if e.g. between LSR B and
LSR C there is a tunnel (LSP2) carrying LSP1 and LSR B and C have
MEPs on LSP2. Now locking MEP on LSP2 in B will cconsequently cause
that (lock) notifications will inserted in the MEPs of LSP2 to
notify the MEPs in LSP1 (its client).

> Are we all agree on these ?

[hvh] if you agree on the last comment...

Cheers, Huub.

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Tue, 5 May 2009 14:17:15 +0200

Hi Huub,

about last comment  yes, I agree!  Another example could be if B is a MEP of a Section ME, i.e among A and B.
Thank you.
Cheers, 
Annamaria

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]] 
Sent: martedì 5 maggio 2009 12.11
To: Annamaria Fulignoli
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock

Ciao Annamaria,

You wrote:

> Besides, as many mails were sent on this issue,  I'd like to check 
> with all of us where we are with Lock (2.2.x) and Lock 
> Notification(2.2.y) requirements.
> 

> MEP D in administratevly lock state. As Lam reported , we are using 
> the "LOCKED" state and "Lock" event of the X.731 Administrative state model.

[hvh] agree

[hvh] OK

> - My understanding is that the client to which the Lock Notification 
> is sent are always MEPs as MIP are transparent to Lock and Lock 
> Notification

[hvh] yes indeed

[hvh] correct

> - Lock Notification functionality (req 2.2.y ) applies to all 
> scenarios where server enters the "locked" state ; for instance if a 
> port in LSR B is set administratevly down (" Lock" event of the X.731 
> Administrative state model) LSR B, as Server MEP of paths transimitted 
> and received on the port , should generate Lock Notification on all 
> these paths, for example towards D and A , MEPs of LSP1.

[hvh] note that LSR B does not have a MEP on LSP1.
The scenario you describe only works if e.g. between LSR B and LSR C there is a tunnel (LSP2) carrying LSP1 and LSR B and C have MEPs on LSP2. Now locking MEP on LSP2 in B will cconsequently cause that (lock) notifications will inserted in the MEPs of LSP2 to notify the MEPs in LSP1 (its client).

Cheers, Huub.

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Tue, 5 May 2009 08:30:58 -0500

Notification across layers takes place within a node. This is the
context that my email was responding to.

In a separate email from Malcolm, he mentioned "just notify the far end
that the lock is in place and allow the decision ..." This is not what
my email was responding to.

I hope I understand your first question correctly.

Regards,
Kam

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, May 05, 2009 6:02 AM
> To: Lam, Hing-Kam (Kam)

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 05 May 2009 15:33:40 +0200

Kam,

does this give the complete view?
in other word does the notification stop at the MEP of the Locked
LSP or is it propagated to MEPs of clients layers?

-m

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 5 May 2009 09:39:15 -0400

Hi Huub, think we agree, see inline. 

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Huub van Helvoort [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 5:27 PM
To: Betts, Malcolm (CAR:X632)
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and
notificationof lock

Hi Malcolm,

> When a server LSP detects the locked notification it informs the 
> client adaptation that it is no longer receiving valid traffic.  If 
> the client has already been taken out of service then this is a "don't

> care".  If the client has not been taken out of service then it should

> raise an alarm.

But shouldn't the client layer be able to determine whether the fault
cause is in its own layer or in the server layer?

This is similar to the notification server trail failure to its client
layer.

MB> Agree, I had made that assumption, but it should be an explicit
statement (in the NM requirements?).

Regards, Huub.

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 5 May 2009 09:42:06 -0400

Martin, 

I agree.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Martin Vigoureux [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 2:59 PM
To: Betts, Malcolm (CAR:X632)
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock

Malcolm,

What I do not understand is why do you want to force the piggybacking of the latter on the former.
We should stick to required elementary functionalities and not impose a given protocol implementation.

regards,
martin

Malcolm Betts a écrit :
>> 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.
>>>> To address the comments from Adrian I suggest the following text 
>>>> for sections 2.2.7 and 2.2.8:
>>>>
>>>> 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.
>>>>
>>>> the End Points at the egress that the lock function is active.  
>>>> This function SHOULD be performed pro-actively.
>>>>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 May 2009 14:50:20 +0100

Hi,

Thanks Kam,

> Notification across layers takes place within a node. This is
> the context that my email was responding to.

This is the answer I was hoping to see as it coincides with my view of the 
world.

Doesn't that make inter-layer notificaiton an implementation issue?
Or, in terms of which douments we have, it is an architecture/framework 
item, not a requirements item.

Thanks,
Adrian

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 5 May 2009 09:56:13 -0400

Kam,
 
Thank you for the description of the NM aspects of Lock.  Just to
clarify one point when I stated:
I see no need to propagate the locked indication across layers.
I was think only of the direct data path.  I fully agree that management
notifications should be passed between layers as you have described.
 
I think that most of the material in you email should be in the NM
requirements document.

Malcolm Betts 
Nortel Networks 

From: Lam, Hing-Kam (Kam) [mailto:[email-masked]] 
Sent: Tuesday, May 05, 2009 1:51 AM
To: Betts, Malcolm (CAR:X632); Sprecher, Nurit (NSN - IL/Hod HaSharon);
[email-masked]; [email-masked]; Martin Vigoureux
Subject: RE: [Mpls-interop] MPLS-TP OAM requirements - Lock
andnotificationof lock

Dear all,

Regards,

Kam

mpls-

> When a server LSP detects the locked notification it informs the
client

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Tue, 5 May 2009 08:57:20 -0500

Martin,

Within the context of notification across layers, the notification propagates from the MEP of the Locked LSP to the MEPs of the client layers. 

If the "Shutting Down" state is supported, one can "Shut down" the server LSP. The server LSP will enter the "Shutting Down" state and waiting for all the existing client services to quit. At this time, the MEP of the server LSP will notify the client layer. Action can then be taken on the client services (e.g. reroute or delete the service). 

If the "Shutting Down" state is not supported and there is no advance notification to the client layer, then the impact of "Lock" the server LSP on the supported client services is no difference than a server LSP failure. That is it will cause alarms to be raised against the client services.

Regards,
Kam

> Sent: Tuesday, May 05, 2009 9:34 AM
> To: Lam, Hing-Kam (Kam)

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 5 May 2009 10:00:10 -0400

Adrian,

By definition it can only take place within a node. 

Malcolm Betts
Nortel Networks

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, May 05, 2009 6:02 AM
To: Lam, Hing-Kam (Kam)
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements -
Lockandnotificationoflock

Am I missing something?

Thanks,
Adrian

----- Original Message -----
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: "Malcolm Betts" <[email-masked]>; "Sprecher, Nurit (NSN - IL/Hod
HaSharon)" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Martin Vigoureux"
<[email-masked]>
Sent: Tuesday, May 05, 2009 6:51 AM
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements -
Lockandnotificationof lock

Dear all,

Regards,

Kam

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 5 May 2009 10:35:48 -0400

Kam,

I am not too sure about this.  From a NM perspective you are correct, however how would this work in the data plane.

Consider the case of a client LSP A-B-C-D-E-F that uses a server layer LSP C-D.

If the OSS sets the C-D (server) LSP to shutting down: 
- How does the C-D (server) LSP know that the A-F (Client) LSP has shut down; 
   - Nodes C & D on LSP A-F can only have MIPs and they cannot
     read the lock message (as currently defined).
- Also how can the C-D (server) LSP notify the A-F (client) LSP that it has shut down:
   - Nodes C & D on LSP A-F can only have MIPs and they cannot
     send spontaneous (locked) messages (as currently defined).   

Malcolm Betts
Nortel Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lam, Hing-Kam (Kam)
Sent: Tuesday, May 05, 2009 9:57 AM
To: Martin Vigoureux
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationoflock

Martin,

Regards,
Kam

> in other word does the notification stop at the MEP of the Locked LSP 
> or is it propagated to MEPs of clients layers?
> 
> -m
> 
> > In a separate email from Malcolm, he mentioned "just notify the far 
> > end that the lock is in place and allow the decision ..." This is 
> > not what my email was responding to.
> >
> >>> I think you are making this far too complicated...  I see no need 
> >>> to propagate the locked indication across layers.
> >>>

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Tue, 5 May 2009 10:16:08 -0500

Malcolm,

How this would work is a solution issue or even an implementation issue.

Fortunately the MIP of LSP A-F at Node C and the MEP of LSP CD at Node C are in the same node (Node C).

Similarly the MIP of LSP A-F at Node D and the MEP of LSP CD at Node D are in the same node (Node D).

This may help in finding a solution.

But I think it is reasonable to have a requirement to avoid unnecessary alarm against the client services due to the server LSP's entering the Locked state.

Regards,

Kam 

> From: Malcolm Betts [mailto:[email-masked]]

> Sent: Tuesday, May 05, 2009 10:36 AM

> To: Lam, Hing-Kam (Kam); VIGOUREUX, MARTIN (MARTIN)

> Subject: RE: [Mpls-interop] MPLS-TP OAM requirements -

> I am not too sure about this.  From a NM perspective you are correct,

> however how would this work in the data plane.

> Consider the case of a client LSP A-B-C-D-E-F that uses a server layer LSP

> C-D.

> - How does the C-D (server) LSP know that the A-F (Client) LSP has shut

> down;

> - Also how can the C-D (server) LSP notify the A-F (client) LSP that it

> has shut down:

> On Behalf Of Lam, Hing-Kam (Kam)

> Within the context of notification across layers, the notification

> propagates from the MEP of the Locked LSP to the MEPs of the client layers.

> If the "Shutting Down" state is supported, one can "Shut down" the server

> LSP. The server LSP will enter the "Shutting Down" state and waiting for

> all the existing client services to quit. At this time, the MEP of the

> server LSP will notify the client layer. Action can then be taken on the

> client services (e.g. reroute or delete the service).

> If the "Shutting Down" state is not supported and there is no advance

> notification to the client layer, then the impact of "Lock" the server LSP

> on the supported client services is no difference than a server LSP

> failure. That is it will cause alarms to be raised against the client

> services.

> > >> Does notification across layers take place within a node or on the

> > > wire?

> > >> To: "Malcolm Betts" <[email-masked]>; "Sprecher, Nurit (NSN -

> > > IL/Hod

> > >>> interruption to the client services so that to reduce unnecessary

> > > alarm