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

[Martin Vigoureux <[e-mail]>]

Nurit,

this is faithfull to the text I proposed.
regards,
-m

Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit :
> Would not it be fair to say the following?
> 
> ·         lock is sent between endpoints (at the same layer) to 
> synchronizes the lock status (either when the configuration is performed 
> at one end, or to ensure that it was configured consistently at both ends).
> 
> ·         Lock indication is sent by an endpoint of a server layer to 
> its clients' endpoints to inform of the administrative lock status?
> 
>  
> 
>  
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of ext Martin Vigoureux
> Sent: Sunday, May 03, 2009 9:22 PM
> To: Adrian Farrel; Malcolm Betts
> Cc: [e-mail]
> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and 
> notification of lock
> 
>  
> 
> Adrian, Malcolm, all,
> 
>  
> 
> 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).
> 
> 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.
> 
>  
> 
> 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 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.
> 
>  
> 
> See also my e-mail:
> 
> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited"
> 
> OAM messages ?
> 
>  
> 
> -question:
> 
> More generally to the comment above, who should notify and who should
> 
> notify whom?
> 
> I would tend to say:
> 
> the receiving node of a locked direction, informs downstream receiving
> 
> nodes of nested LSPs. This is a Fowrward Indication and if we do
> 
> so then receiving points MUST indeed be informed of a Lock (c.f.
> 
> discussion at the beginning of the e-mail).
> 
> Should source points (locking points) do some reverse indication and
> 
> notify the source points of the LSPs that are nested in the locked LSP?
> 
> (but this maybe falls in the RDI functionality).
> 
>  
> 
> I guess that is all, sorry for this long e-mail.
> 
>  
> 
> regards,
> 
> -m
> 
>  
> 
>  
> 
> Adrian Farrel a écrit :
> 
>>  Hi Malcolm,
> 
>>
> 
>> > To address the comments from Adrian I suggest the following
> 
>> > text for sections 2.2.7 and 2.2.8:
> 
>> > 
> 
>> > Note that this proposal assumes that the text related to local/remote
> 
>> > faults is moved from section 2.2.8 to section 2.2.2 as proposed in my
> 
>> > previous email.
> 
>> > 
> 
>> > We probably need to discuss this text on the MEAD team call next
> 
>> > week.
> 
>> > 
> 
>> > 2.2.7.  Lock
> 
>> > 
> 
>> > The OAM toolset SHOULD provide a function enabling a network operator to
> 
>> > administratively shut down a PW, LSP or Section; that is, to stop user
> 
>> > traffic being sent over that PW, LSP or Section.
> 
>>
> 
>>  This is great.
> 
>>  Does it mean that we do not need to add the (similar) text on CV fault
> 
>>  behavior in section 2.2.3?
> 
>>  It would seem so.
> 
>>
> 
>> > The lock function MAY be applied to a unidirectional or a bidirectional
> 
>> > PW, LSP or Section.  If the lock function is activated at the head end
> 
>> > of one direction of a bidirectional PW, LSP or Section then it SHOULD be
> 
>> > possible to cause the lock function to be activated at the head end of
> 
>> > the other direction.
> 
>> > 
> 
>> > This function SHOULD be performed on-demand i.e. in response to an
> 
>> > operator command.
> 
>>
> 
>>  Or also in response to configured automatic behavior?
> 
>>
> 
>>  But this is not a protocol requirement.
> 
>>
> 
>> > This function SHOULD be performed between End Points of PWs, LSPs
> 
>> > and Sections.
> 
>> > 
> 
>> > 2.2.8 Notification of Lock
> 
>> > 
> 
>> > If the lock function is supported the MPLS-TP OAM toolset MUST
> 
>> > provide a function to enable the End Point at the ingress to notify the
> 
>> > End Points at the egress that the lock function is active.  This
> 
>> > function SHOULD be performed pro-actively.
> 
>> > 
> 
>> > The MPLS-TP OAM toolset MUST allow for the distinction between
> 
>> > a fault condition and an administrative locking action.
> 
>>
> 
>>  Works for me.
> 
>>
> 
>>  A
> 
>>
> 
>>
> 
>>
> 
>>  _______________________________________________
> 
>>  Mpls-interop mailing list
> 
>>  [e-mail]
> 
>>  https://www.ietf.org/mailman/listinfo/mpls-interop
> 
>>
> 
> _______________________________________________
> 
> Mpls-interop mailing list
> 
> [e-mail]
> 
> https://www.ietf.org/mailman/listinfo/mpls-interop
>