Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notificationof lock

"Malcolm Betts" <betts01@nortel.com> Tue, 05 May 2009 13:39 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 C2AE13A6A0D for <mpls-interop@core3.amsl.com>; Tue, 5 May 2009 06:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.224
X-Spam-Level:
X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 BPAbU5Br2U3d for <mpls-interop@core3.amsl.com>; Tue, 5 May 2009 06:39:00 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C2B8F3A68BF for <mpls-interop@ietf.org>; Tue, 5 May 2009 06:38:59 -0700 (PDT)
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n45Ddam16989; Tue, 5 May 2009 13:39:37 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: Tue, 05 May 2009 09:39:15 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D517038C05@zcarhxm2.corp.nortel.com>
In-Reply-To: <49FF5DA9.4000807@chello.nl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mpls-interop] MPLS-TP OAM requirements - Lock and notificationof lock
Thread-Index: AcnM/xdqMNUaaij0TQKlGN8wYn1nugAh5Crw
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> <49FF5DA9.4000807@chello.nl>
From: Malcolm Betts <betts01@nortel.com>
To: hhelvoort@chello.nl
Cc: 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: Tue, 05 May 2009 13:39:00 -0000

Hi Huub, think we agree, see inline. 


Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: betts01@nortel.com

-----Original Message-----
From: Huub van Helvoort [mailto:hhelvoort@chello.nl] 
Sent: Monday, May 04, 2009 5:27 PM
To: Betts, Malcolm (CAR:X632)
Cc: mpls-interop@ietf.org
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and
notificationof lock

Hi Malcolm,

You wrote:

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

That should be the proper procedure.

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

But shouldn't the client layer be able to determine whether the fault
cause is in its own layer or in the server layer?

This is similar to the notification server trail failure to its client
layer.

So in fact the same notification can be used for both cases.

MB> Agree, I had made that assumption, but it should be an explicit
statement (in the NM requirements?).

Regards, Huub.

--
================================================================
Always remember that you are unique...just like everyone else...