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

[Huub van Helvoort <[e-mail]>]

Hi Martin,

You replied:

> please see inline,
> 
> regards,
> -m
> 
> Huub van Helvoort a écrit :
>> Bonsoir Martin,
>>
>> You wrote:
>>
>>> 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).
>>
>> What should happen if the CP and MP are separated, i.e the
>> ingress point and egress poinr belong to different SP domains?
> 
> [mvx] please se my other e-mail.

[hvh] OK, I will.


>>> 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.
>>
>> What do you mean by "its direction", the direction from "the
>> 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.
> 
>>
>>> 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
>>
>> This requires that both end points can be reached via the MP.
> 
> [mvx] indeed but that does not contradict the above.

OK, I was confused by the added *conditionally*

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

Cheers, Huub.

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