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

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

Hi Lam,

I agree with you.

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

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

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

- 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 

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

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

Are we all agree on these ?

Best regards,

Annamaria 


________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf Of Lam, Hing-Kam (Kam)
Sent: martedì 5 maggio 2009 7.51
To: Malcolm Betts; Sprecher, Nurit (NSN - IL/Hod HaSharon); [e-mail]; [e-mail]; Martin Vigoureux
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock



Dear all,

 

See inline below. I am addressing the issue of notification across layers, not addressing notifying the sink (egress) points.

 

Regards,

Kam

 

> -----Original Message-----

> From: [e-mail] [mailto:[e-mail]]

> On Behalf Of Malcolm Betts

> Sent: Monday, May 04, 2009 8:42 AM

> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [e-mail]; mpls-

> [e-mail]

> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock

> andnotificationof lock

> 

> All,

> 

> I think you are making this far too complicated...  I see no need to

> propagate the locked indication across layers.

[Lam, Hing-Kam (Kam)] The bottom line is to avoid unexpected interruption to the client services so that to reduce unnecessary alarm being raised from the client layer.

> 

> If the operator decides to lock a LSP (for example to run a test) then

> the clients of that LSP should be taken out of service before the lock

> is applied.

[Lam, Hing-Kam (Kam)] This is a reasonable assumption and a good practice. It will be helpful to explicitly say so in the document. The reason is that now we are using the "LOCKED" state and "Lock" event of the X.731 Administrative state model. There are additional state values and events in the model. We need to be precise and accurate, in particular if we support only a subset of the model. Otherwise it may cause unnecessary confusion and inconsistence in the future. The Administrative State model in X.731 defines three state values (namely: UNLOCKED, LOCKED, and SHUTTING DOWN) and events as shown below. 

 

If you administratively lock a server, the server will enter the "locked" state. Therefore the server will no longer be able to provide its intended service (of supporting all its clients). The effect (i.e. impact) on the clients is no different than a server failure. Usually you don't want to do this. Instead, you would like to gracefully take the server out of service, i.e. administratively shut down the server, and by doing so the server will enter the "shutting down" state. The "shutting down" state is a transition state. When the last user (in this case the last client service) quit, then the server will automatically enter the "locked" state. If we are not going to support the Shutting Down state of the model, then you better either (1) take the clients of the server LSP out of service before the lock is applied or (2) notify the clients in advance, otherwise alarms will be raised against the supported client services because of the unexpected interruption.

 

> 

> When a server LSP detects the locked notification it informs the client

> adaptation that it is no longer receiving valid traffic.  If the client

> has already been taken out of service then this is a "don't care".  If

> the client has not been taken out of service then it should raise an

> alarm.

> 

> 

> Malcolm Betts

> Nortel Networks

> Phone: [phone] (ESN 393)

> email: [e-mail]

> 

> -----Original Message-----

> From: [e-mail]

> [mailto:[e-mail]] On Behalf Of Sprecher, Nurit (NSN

> - IL/Hod HaSharon)

> Sent: Monday, May 04, 2009 3:47 AM

> To: [e-mail]; [e-mail]

> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and

> notificationof lock

> 

> Huub,

> You say " this requires that a MIP has the capability to send OAM

> messages based on management command or based on an indication of a MEP

> in a different layer. This also requires that at every MEP location

> there are also MIPs for every client entity serviced by that MEP."

> This looks more as an implementation description. What is actually

> required is that the endpoints of the client layer are informed of this

> event.

> The way you describe it seems a little bit "against" the framework in

> which it is specified that OAM messages cannot be initiated by MIPs.

> That is why we actually say that this is an adaptation function, that

> means that the message is initiated by the MEP of the server to the MEP

> of the client.......

> Best regards,

> NUrit

> 

> -----Original Message-----

> From: [e-mail]

> [mailto:[e-mail]] On Behalf Of ext Huub van

> Helvoort

> Sent: Monday, May 04, 2009 10:27 AM

> To: [e-mail]

> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and

> notification of lock

> 

> Hello Nurit,

> 

> You wrote:

> 

> > To continue with the othe rquestion:

> >

> >> See also my e-mail:

> >> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited"

> 

> >> OAM messages ?

> >

> > The answer was no.

> >

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

> >

> > To be more exact, the sink side of a locked LSP, PW, Section, has to

> > inform its clients.

> 

> You say " To be more exact, the sink side of a locked LSP, PW, Section,

> has to inform its clients.",

> 

> [hvh] it should inform its client transport entities in the

> server/client relation

> 

> BUT the client is not necessarily an

> endpoint but may be an intermediate point, and it needs to notify its

> endpoints, that means that a MIP generates an OAM message.

> 

> [hvh this requires that a MIP has the capability to send OAM messages

> based on management command or based on an indication of a MEP in a

> different layer.

> This also requires that at every MEP location there are also MIPs for

> every client entity serviced by that MEP.

> 

> Long ago I discussed this point with Italo and he indicated to me that

> it is not a generation of a message by a MIP BUT it is a variation of an

> adaptation function at the client intermediate point. Although we are

> talking here about a way to implement it, this is a conceptual issue

> that we need to agree on.

> 

> [hvh] I agree with Italo.

> 

> Also, I think we should generalize the discussion instead of talking

> every time about LSP, PW, section, etc. we should really talk about

> client/server layers to cover cases of LSP hierarchies, etc.

> 

> [hvh] then I use server/client path/trail the next time, OK?

> 

> Regards, Huub.

> 

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

> >

> > Isn't this notification already caused by the locking at the far end?

> > Or is the locking only applied in one direction of a bi-directional

> > path? If yes, then the notification is not required.

> >

> > Cheers, 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

> _______________________________________________

> 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