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

[Martin Vigoureux <[e-mail]>]

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