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

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

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

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