[Mpls-interop] Local and Remote
"Adrian Farrel" <adrian@olddog.co.uk> Wed, 06 May 2009 12:19 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 10AA53A6F18 for <mpls-interop@core3.amsl.com>; Wed, 6 May 2009 05:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.936
X-Spam-Level:
X-Spam-Status: No, score=-0.936 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_40=-0.185]
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 P0IzlS58orDS for <mpls-interop@core3.amsl.com>; Wed, 6 May 2009 05:19:21 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 0ADCF3A71C9 for <mpls-interop@ietf.org>; Wed, 6 May 2009 05:15:06 -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 n46CGVc1004309 for <mpls-interop@ietf.org>; Wed, 6 May 2009 13:16:32 +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 n46CGSDL004219 for <mpls-interop@ietf.org>; Wed, 6 May 2009 13:16:30 +0100
Message-ID: <73632CCC731C496AACD41C4DEA306288@your029b8cecfe>
From: Adrian Farrel <adrian@olddog.co.uk>
To: mpls-interop@ietf.org
References: <077E41CFFD002C4CAB7DFA4386A53264AB4B6B@DEMUEXC014.nsn-intra.net> <4A0157B1.5050408@chello.nl>
Date: Wed, 06 May 2009 13:16:17 +0100
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="Windows-1252"; reply-type="response"
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: [Mpls-interop] Local and Remote
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: Wed, 06 May 2009 12:19:22 -0000
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] 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