Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationoflock
"Malcolm Betts" <betts01@nortel.com> Tue, 05 May 2009 14:34 UTC
Return-Path: <BETTS01@nortel.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 7A28E28C168 for <mpls-interop@core3.amsl.com>; Tue, 5 May 2009 07:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.222
X-Spam-Level:
X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 5QFBEUBhAsSR for <mpls-interop@core3.amsl.com>; Tue, 5 May 2009 07:34:31 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 4267E3A6B91 for <mpls-interop@ietf.org>; Tue, 5 May 2009 07:34:31 -0700 (PDT)
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n45EYw628947 for <mpls-interop@ietf.org>; Tue, 5 May 2009 14:34:58 GMT
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 10:35:48 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D517038DB1@zcarhxm2.corp.nortel.com>
In-Reply-To: <A37753B7B7A3134F9366EE6B4052F43B02C8D471@ILEXC2U03.ndc.lucent.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationoflock
Thread-Index: AcnNhh1CxAOec+ikQXq+HDL+9rTiOAAAHXjQAAGSa+A=
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> <A37753B7B7A3134F9366EE6B4052F43B02C8D471@ILEXC2U03.ndc.lucent.com>
From: Malcolm Betts <betts01@nortel.com>
To: "Lam, Hing-Kam (Kam)" <hklam@alcatel-lucent.com>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>
Cc: mpls-interop@ietf.org
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lockandnotificationoflock
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 14:34:32 -0000
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: +1 613 763 7860 (ESN 393) email: betts01@nortel.com -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Lam, Hing-Kam (Kam) Sent: Tuesday, May 05, 2009 9:57 AM To: Martin Vigoureux Cc: mpls-interop@ietf.org 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: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 > > _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop
- [Mpls-interop] MPLS-TP OAM requirements - Lock an… Malcolm Betts
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Adrian Farrel
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Martin Vigoureux
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Huub van Helvoort
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Huub van Helvoort
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Huub van Helvoort
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Huub van Helvoort
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Huub van Helvoort
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Martin Vigoureux
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Martin Vigoureux
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Martin Vigoureux
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Martin Vigoureux
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Malcolm Betts
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Huub van Helvoort
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Huub van Helvoort
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Malcolm Betts
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Martin Vigoureux
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Martin Vigoureux
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Martin Vigoureux
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Huub van Helvoort
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Malcolm Betts
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Martin Vigoureux
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Huub van Helvoort
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Huub van Helvoort
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Lam, Hing-Kam (Kam)
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Annamaria Fulignoli
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Adrian Farrel
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Huub van Helvoort
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Annamaria Fulignoli
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Lam, Hing-Kam (Kam)
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Martin Vigoureux
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Malcolm Betts
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Malcolm Betts
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Adrian Farrel
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Malcolm Betts
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Lam, Hing-Kam (Kam)
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Malcolm Betts
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Malcolm Betts
- Re: [Mpls-interop] MPLS-TP OAM requirements - Loc… Lam, Hing-Kam (Kam)