[Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock

"Malcolm Betts" <betts01@nortel.com> Fri, 01 May 2009 19:44 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 469063A6B58 for <mpls-interop@core3.amsl.com>; Fri, 1 May 2009 12:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.15
X-Spam-Level:
X-Spam-Status: No, score=-6.15 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rta5aFTFPT5g for <mpls-interop@core3.amsl.com>; Fri, 1 May 2009 12:44:43 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id EF8243A68C7 for <mpls-interop@ietf.org>; Fri, 1 May 2009 12:44:42 -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 n41JjCB02384 for <mpls-interop@ietf.org>; Fri, 1 May 2009 19:45:12 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9CA95.76395FE8"
Date: Fri, 01 May 2009 15:46:03 -0400
Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D516FDAE56@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: MPLS-TP OAM requirements - Lock and notification of lock
Thread-Index: AcnKlXbxf2P6WIX7RfmgiUMmvqwy4Q==
From: Malcolm Betts <betts01@nortel.com>
To: mpls-interop@ietf.org
Subject: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of 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: Fri, 01 May 2009 19:44:44 -0000

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. 

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. 

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.
 



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