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

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

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