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

["Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[e-mail]>]

Huub, 
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?  
Best regards,
Nurit

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of ext Huub van
Helvoort
Sent: Monday, May 04, 2009 1:59 AM
To: Martin Vigoureux
Cc: [e-mail]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and
notification of lock

Bonsoir Martin,

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?

> 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...
_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop