Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock

["Annamaria Fulignoli" <[e-mail]>]

Hi Huub,

about last comment  yes, I agree!  Another example could be if B is a MEP of a Section ME, i.e among A and B.
Thank you.
Cheers, 
Annamaria

-----Original Message-----
From: Huub van Helvoort [mailto:[e-mail]] 
Sent: martedì 5 maggio 2009 12.11
To: Annamaria Fulignoli
Cc: [e-mail]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock

Ciao Annamaria,

You wrote:

> Besides, as many mails were sent on this issue,  I'd like to check 
> with all of us where we are with Lock (2.2.x) and Lock 
> Notification(2.2.y) requirements.
> 
> I know we are dealing with requirements and not with solutions, but 
> please let's consider the following example:
> 
> topology is A <---> B <---> C <---> D
> 
> LSP1 goes A-B-C-D

[hvh] so the LSP1 MEPs are located in LSR A and LSR D

> - The operator decides to set in A LSP1 administratevly down , due for 
> example to an out of service test on the path.
> 
> The Lock requirement (2.2.x ) requires that A is able to set its peer 
> MEP D in administratevly lock state. As Lam reported , we are using 
> the "LOCKED" state and "Lock" event of the X.731 Administrative state model.
> This implies that when LSP1 in D enters in the administrative lock 
> state, all traffic on the path MUST be blocked; but MEP D must notify 
> the clients , otherwise alarms will be raised against the supported 
> client services because of the unexpected interruption; i.e. D should 
> send Lock Notification(2.2.y) to its own clients.

[hvh] agree

> - In case of bidirectional path even in MEP A the LSP1 (rx direction ) 
> enters in administrative lock state and even MEP A should notify the
> client(s) transported by the path ( i.e. In the backward direction; req. 
> 2.2.y)

[hvh] OK

> - My understanding is that the client to which the Lock Notification 
> is sent are always MEPs as MIP are transparent to Lock and Lock 
> Notification

[hvh] yes indeed

> - When a MEP receives a Lock Notification it can in turn notify  its 
> MPLS-TP client MEPs or map it into an equivalent signal for whatever 
> client layer is then being carried.

[hvh] correct

> - Lock Notification functionality (req 2.2.y ) applies to all 
> scenarios where server enters the "locked" state ; for instance if a 
> port in LSR B is set administratevly down (" Lock" event of the X.731 
> Administrative state model) LSR B, as Server MEP of paths transimitted 
> and received on the port , should generate Lock Notification on all 
> these paths, for example towards D and A , MEPs of LSP1.

[hvh] note that LSR B does not have a MEP on LSP1.
The scenario you describe only works if e.g. between LSR B and LSR C there is a tunnel (LSP2) carrying LSP1 and LSR B and C have MEPs on LSP2. Now locking MEP on LSP2 in B will cconsequently cause that (lock) notifications will inserted in the MEPs of LSP2 to notify the MEPs in LSP1 (its client).

> Are we all agree on these ?

[hvh] if you agree on the last comment...

Cheers, Huub.

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