Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notificationof lock
"Malcolm Betts" <betts01@nortel.com> Mon, 04 May 2009 12:41 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 CCDED28C16A for <mpls-interop@core3.amsl.com>; Mon, 4 May 2009 05:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.195
X-Spam-Level:
X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=0.404, 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 0hc15f7-2k67 for <mpls-interop@core3.amsl.com>; Mon, 4 May 2009 05:41:45 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D6A3D3A7010 for <mpls-interop@ietf.org>; Mon, 4 May 2009 05:41:04 -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 n44CfXo00086; Mon, 4 May 2009 12:41:33 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 04 May 2009 08:42:26 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516FDB24D@zcarhxm2.corp.nortel.com>
In-Reply-To: <077E41CFFD002C4CAB7DFA4386A53264A755C1@DEMUEXC014.nsn-intra.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lock and notificationof lock
Thread-Index: AcnMibd+2qVOSWcIR5GzbLZ+V24I5QAANxMQAAp1z8A=
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>
From: Malcolm Betts <betts01@nortel.com>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com>, hhelvoort@chello.nl, mpls-interop@ietf.org
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notificationof 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: Mon, 04 May 2009 12:41:46 -0000
All, I think you are making this far too complicated... I see no need to propagate the locked indication across layers. 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. 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: +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 Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Monday, May 04, 2009 3:47 AM To: hhelvoort@chello.nl; mpls-interop@ietf.org 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: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Huub van Helvoort Sent: Monday, May 04, 2009 10:27 AM To: mpls-interop@ietf.org 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 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)