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

"Lam, Hing-Kam \(Kam\)" <hklam@alcatel-lucent.com> Tue, 05 May 2009 13:56 UTC

Return-Path: <hklam@alcatel-lucent.com>
X-Original-To: mpls-interop@core3.amsl.com
Delivered-To: mpls-interop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DBA63A7199 for <mpls-interop@core3.amsl.com>; Tue, 5 May 2009 06:56:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.464
X-Spam-Level:
X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ubnm1mz+NZ2 for <mpls-interop@core3.amsl.com>; Tue, 5 May 2009 06:56:37 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 6AE533A711F for <mpls-interop@ietf.org>; Tue, 5 May 2009 06:55:57 -0700 (PDT)
Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n45DvMjc019871; Tue, 5 May 2009 08:57:22 -0500 (CDT)
Received: from ILEXC2U03.ndc.lucent.com ([135.3.39.12]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 May 2009 08:57:22 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 05 May 2009 08:57:20 -0500
Message-ID: <A37753B7B7A3134F9366EE6B4052F43B02C8D471@ILEXC2U03.ndc.lucent.com>
In-Reply-To: <4A004034.8000101@alcatel-lucent.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock
Thread-Index: AcnNhh1CxAOec+ikQXq+HDL+9rTiOAAAHXjQ
References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com> <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe><49FDE0C4.7060807@alcatel-lucent.com><49FE241F.5080007@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A754E0@DEMUEXC014.nsn-intra.net><49FE98B2.5080801@chello.nl><077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net><0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com> <A37753B7B7A3134F9366EE6B4052F43B02C8D3AA@ILEXC2U03.ndc.lucent.com> <3EC3B42EADEE4472A1C0DEBFFFC22E27@your029b8cecfe> <A37753B7B7A3134F9366EE6B4052F43B02C8D43E@ILEXC2U03.ndc.lucent.com> <4A004034.8000101@alcatel-lucent.com>
From: "Lam, Hing-Kam (Kam)" <hklam@alcatel-lucent.com>
To: Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>
X-OriginalArrivalTime: 05 May 2009 13:57:22.0090 (UTC) FILETIME=[697EC8A0:01C9CD89]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: mpls-interop@ietf.org
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationof lock
X-BeenThere: mpls-interop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF MPLS Interoperability Design Team <mpls-interop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-interop>, <mailto:mpls-interop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-interop>
List-Post: <mailto:mpls-interop@ietf.org>
List-Help: <mailto:mpls-interop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-interop>, <mailto:mpls-interop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2009 13:56:38 -0000

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:martin.vigoureux@alcatel-lucent.com]
> Sent: Tuesday, May 05, 2009 9:34 AM
> To: Lam, Hing-Kam (Kam)
> Cc: Adrian Farrel; mpls-interop@ietf.org
> 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:adrian@olddog.co.uk]
> >> Sent: Tuesday, May 05, 2009 6:02 AM
> >> To: Lam, Hing-Kam (Kam)
> >> Cc: mpls-interop@ietf.org
> >> 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)" <hklam@alcatel-lucent.com>
> >> To: "Malcolm Betts" <betts01@nortel.com>; "Sprecher, Nurit (NSN -
> > IL/Hod
> >> HaSharon)" <nurit.sprecher@nsn.com>; <hhelvoort@chello.nl>;
> >> <mpls-interop@ietf.org>; "Martin Vigoureux"
> >> <martin.vigoureux@alcatel-lucent.com>
> >> 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: mpls-interop-bounces@ietf.org
> >> [mailto:mpls-interop-bounces@ietf.org]
> >>> On Behalf Of Malcolm Betts
> >>> Sent: Monday, May 04, 2009 8:42 AM
> >>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); hhelvoort@chello.nl;
> >>> mpls-interop@ietf.org
> >>> 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
> > Mpls-interop@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls-interop
> >