Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationoflock

["Malcolm Betts" <[e-mail]>]

Kam,

I am not too sure about this.  From a NM perspective you are correct, however how would this work in the data plane.

Consider the case of a client LSP A-B-C-D-E-F that uses a server layer LSP C-D.

If the OSS sets the C-D (server) LSP to shutting down: 
- How does the C-D (server) LSP know that the A-F (Client) LSP has shut down; 
   - Nodes C & D on LSP A-F can only have MIPs and they cannot
     read the lock message (as currently defined).
- Also how can the C-D (server) LSP notify the A-F (client) LSP that it has shut down:
   - Nodes C & D on LSP A-F can only have MIPs and they cannot
     send spontaneous (locked) messages (as currently defined).   


Malcolm Betts
Nortel Networks
Phone: [phone] (ESN 393)
email: [e-mail]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Lam, Hing-Kam (Kam)
Sent: Tuesday, May 05, 2009 9:57 AM
To: Martin Vigoureux
Cc: [e-mail]
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationoflock

Martin,

Within the context of notification across layers, the notification propagates from the MEP of the Locked LSP to the MEPs of the client layers. 

If the "Shutting Down" state is supported, one can "Shut down" the server LSP. The server LSP will enter the "Shutting Down" state and waiting for all the existing client services to quit. At this time, the MEP of the server LSP will notify the client layer. Action can then be taken on the client services (e.g. reroute or delete the service). 

If the "Shutting Down" state is not supported and there is no advance notification to the client layer, then the impact of "Lock" the server LSP on the supported client services is no difference than a server LSP failure. That is it will cause alarms to be raised against the client services.

Regards,
Kam

> -----Original Message-----
> From: Martin Vigoureux [mailto:[e-mail]]
> Sent: Tuesday, May 05, 2009 9:34 AM
> To: Lam, Hing-Kam (Kam)
> Cc: Adrian Farrel; [e-mail]
> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - 
> Lockandnotificationof lock
> 
> Kam,
> 
> does this give the complete view?
> in other word does the notification stop at the MEP of the Locked LSP 
> or is it propagated to MEPs of clients layers?
> 
> -m
> 
> Lam, Hing-Kam (Kam) a écrit :
> > Notification across layers takes place within a node. This is the 
> > context that my email was responding to.
> >
> > In a separate email from Malcolm, he mentioned "just notify the far 
> > end that the lock is in place and allow the decision ..." This is 
> > not what my email was responding to.
> >
> > I hope I understand your first question correctly.
> >
> > Regards,
> > Kam
> >
> >> -----Original Message-----
> >> From: Adrian Farrel [mailto:[e-mail]]
> >> Sent: Tuesday, May 05, 2009 6:02 AM
> >> To: Lam, Hing-Kam (Kam)
> >> Cc: [e-mail]
> >> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - 
> >> Lockandnotificationof lock
> >>
> >> Am I missing something?
> >> Does notification across layers take place within a node or on the
> > wire?
> >> Thanks,
> >> Adrian
> >>
> >> ----- Original Message -----
> >> From: "Lam, Hing-Kam (Kam)" <[e-mail]>
> >> To: "Malcolm Betts" <[e-mail]>; "Sprecher, Nurit (NSN -
> > IL/Hod
> >> HaSharon)" <[e-mail]>; <[e-mail]>; 
> >> <[e-mail]>; "Martin Vigoureux"
> >> <[e-mail]>
> >> Sent: Tuesday, May 05, 2009 6:51 AM
> >> 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]; 
> >>> [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.
> >
> > _______________________________________________
> > 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