Re: [Mpls-interop] Local and Remote
"Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com> Wed, 06 May 2009 12:58 UTC
Return-Path: <nurit.sprecher@nsn.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 91D463A6F53 for <mpls-interop@core3.amsl.com>; Wed, 6 May 2009 05:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.418
X-Spam-Level:
X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_00=-2.599, HTML_MESSAGE=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 eR136cNv9-VP for <mpls-interop@core3.amsl.com>; Wed, 6 May 2009 05:58:04 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id D35123A6EC5 for <mpls-interop@ietf.org>; Wed, 6 May 2009 05:56:10 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n46Cvajo003279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 May 2009 14:57:36 +0200
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n46CvZqU021576; Wed, 6 May 2009 14:57:36 +0200
Received: from DEMUEXC014.nsn-intra.net ([10.150.128.26]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 14:57:35 +0200
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_01C9CE4A.38D6F2E5"
Date: Wed, 06 May 2009 14:57:31 +0200
Message-ID: <077E41CFFD002C4CAB7DFA4386A53264AB5129@DEMUEXC014.nsn-intra.net>
In-Reply-To: <73632CCC731C496AACD41C4DEA306288@your029b8cecfe>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mpls-interop] Local and Remote
Thread-Index: AcnORRlyJibQZu/1QUS+nytVL7Z/kAAAVKdg
References: <077E41CFFD002C4CAB7DFA4386A53264AB4B6B@DEMUEXC014.nsn-intra.net><4A0157B1.5050408@chello.nl> <73632CCC731C496AACD41C4DEA306288@your029b8cecfe>
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com>
To: Adrian Farrel <adrian@olddog.co.uk>, mpls-interop@ietf.org
X-OriginalArrivalTime: 06 May 2009 12:57:35.0567 (UTC) FILETIME=[3A2C8DF0:01C9CE4A]
Subject: Re: [Mpls-interop] Local and Remote
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: Wed, 06 May 2009 12:58:17 -0000
Hi, Thanks for the great clarification. I am sorry for bothering but I still have some questions: * We have a requirement in the document for "Remote Defect Indication" and it specifies that "The MPLS-TP OAM toolset MUST provide a function to enable an End Point to notify its associated End Point of the detection of a fault or defect that it detects on a PW, LSP or Section between them." I.e. in the requirement refers to remote as to the associated endpoint at the same layer! * I would like to refer to the last paragraph in your e-mail: "" When a server layer provides a connection that is used as a link in the client layer, a server layer fault (that is remote in the server layer) may be reported to the client layer as a fault in the client layer link (that is local in the client layer)...." Assuming that we have an LSP that traversed nodes A-B-C-D-E-F-G and we have a fault in the link between D and E. according to the above the server layer needs to notify the client layer. Is it to the client layer in nodes D and E or to the endpoints of the client layers, i.e. nodes A and G? If it is node D and E (this is local) they need now to notify nodes A and G, but according to the requirement document and to the framework they may be MIPs of the LSPs but they cannot initiate OAM messages. Therefore, it seems that the endpoint of the server layer needs to notify the endpoint of the client layers of the fault (remote). And IMO we need to be clear about the requirement. And also to extend the definition in the first bullet for remote (not necessarily endpoint). * Assuming that the failure is in the first (server) link. As a result we have loss of continuity in the LSPs that transmit over this failed link and in the PWs that are attached to these LSPs. As I understand from your definition, as these fault are detected by the endpoint (to which the link is attached), all these faults are considered locals!. Is there still a requirement to distinguish between these failures? Note that all of these are now local. I'll appreciate your further clarification. Best regards, Nurit -----Original Message----- From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Adrian Farrel Sent: Wednesday, May 06, 2009 3:16 PM To: mpls-interop@ietf.org Subject: [Mpls-interop] Local and Remote I know that Malcolm and Huub are going to work on the definition of local and remote. Huub usefully typed during the meeting yesterday that "remote" might be better stated as "non-local." Watching some emails this morning, I wonder whether part of the confusion arises from - where the fault is detected - where the fault exists A node can (IMHO) only be detected locally. That is local to the point of detection. A fault may be reported (to the management plane) from the node of detection (a local report), or may be signaled to another node (through the OAM or control plane) and reported (to the management plane) from that other node (a remote report). The fault that is detected may be in the detecting node, or in a resource directly connected to that node (such as a link). This is a local fault. But the fault may also exist in a node or resource that is not local to the detecting node. This is a remote fault. If an LSP continuity check fails, the fault is detected by an end point (local detection), but the fault might be somewhere out in the network (remote fault). When a server layer provides a connection that is used as a link in the client layer, a server layer fault (that is remote in the server layer) may be reported to the client layer as a fault in the client layer link (that is local in the client layer). The client layer does not know about the route or resources used in the server layer (we MUST assume clean layer separation) so the client layer does not need to know about the location of the server layer remote fault. If the client layer requests the server layer to repair the client layer link (i.e. to repair the server layer connection) the server layer may need to consider the location of the server layer fault. Am I wrong? Is this really so complicated? Thanks, Adrian _______________________________________________ Mpls-interop mailing list Mpls-interop@ietf.org https://www.ietf.org/mailman/listinfo/mpls-interop
- [Mpls-interop] Local and Remote Adrian Farrel
- Re: [Mpls-interop] Local and Remote Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] Local and Remote Huub van Helvoort
- Re: [Mpls-interop] Local and Remote Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] Local and Remote Adrian Farrel
- Re: [Mpls-interop] Local and Remote Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] Local and Remote Malcolm Betts
- Re: [Mpls-interop] Local and Remote Lam, Hing-Kam (Kam)
- Re: [Mpls-interop] Local and Remote Huub van Helvoort