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

[Martin Vigoureux <[e-mail]>]

ok, perfect.

-m

Huub van Helvoort a écrit :
> 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.
>