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

[Martin Vigoureux <[e-mail]>]

cool :-)

Huub van Helvoort a écrit :
> Hello Martin,
> 
> You wrote:
> 
>> I still do not understand how the context you mention impacts
>> 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.
> 
> ================
>> Huub van Helvoort a écrit :
>>> Hi Nurit,
>>>
>>> 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?
>>>
>>> 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?
>>>
>>> [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.
>>>
>>>>> 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"?
>>>>
>>>>> 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.
>>>>
>>>>> 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.
>>>>
>>>> Snip -- I will answer the next in a separate email--
>>>>
>>>> Regards, Huub.
>>>>
>>>
>>
>