Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification oflock

"Adrian Farrel" <adrian@olddog.co.uk> Sat, 02 May 2009 17:26 UTC

Return-Path: <adrian@olddog.co.uk>
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 3BE8A3A6E3A for <mpls-interop@core3.amsl.com>; Sat, 2 May 2009 10:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.135
X-Spam-Level:
X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
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 8aE56Y5-hYIX for <mpls-interop@core3.amsl.com>; Sat, 2 May 2009 10:26:39 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 08ECB3A6D57 for <mpls-interop@ietf.org>; Sat, 2 May 2009 10:25:49 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n42HRC6V016316; Sat, 2 May 2009 18:27:12 +0100
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n42HRAFv016310; Sat, 2 May 2009 18:27:12 +0100
Message-ID: <42D4A33F1EAE420289ED4EFCA24D19BB@your029b8cecfe>
From: Adrian Farrel <adrian@olddog.co.uk>
To: Malcolm Betts <betts01@nortel.com>, mpls-interop@ietf.org
References: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com>
Date: Sat, 02 May 2009 18:26:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification oflock
X-BeenThere: mpls-interop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
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: Sat, 02 May 2009 17:26:40 -0000

Hi Malcolm,

> To address the comments from Adrian I suggest the following
> text for sections 2.2.7 and 2.2.8:
>
> Note that this proposal assumes that the text related to local/remote
> faults is moved from section 2.2.8 to section 2.2.2 as proposed in my
> previous email.
>
> We probably need to discuss this text on the MEAD team call next
> week.
>
> 2.2.7.  Lock
>
> The OAM toolset SHOULD provide a function enabling a network operator to
> administratively shut down a PW, LSP or Section; that is, to stop user
> traffic being sent over that PW, LSP or Section.

This is great.
Does it mean that we do not need to add the (similar) text on CV fault 
behavior in section 2.2.3?
It would seem so.

> The lock function MAY be applied to a unidirectional or a bidirectional
> PW, LSP or Section.  If the lock function is activated at the head end
> of one direction of a bidirectional PW, LSP or Section then it SHOULD be
> possible to cause the lock function to be activated at the head end of
> the other direction.
>
> This function SHOULD be performed on-demand i.e. in response to an
> operator command.

Or also in response to configured automatic behavior?

But this is not a protocol requirement.

> This function SHOULD be performed between End Points of PWs, LSPs
> and Sections.
>
> 2.2.8 Notification of Lock
>
> If the lock function is supported the MPLS-TP OAM toolset MUST
> provide a function to enable the End Point at the ingress to notify the
> End Points at the egress that the lock function is active.  This
> function SHOULD be performed pro-actively.
>
> The MPLS-TP OAM toolset MUST allow for the distinction between
> a fault condition and an administrative locking action.

Works for me.

A