RE: Ability to detect swapped/merged LSPs
richard.spencer@bt.com Tue, 01 March 2005 19:18 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00318; Tue, 1 Mar 2005 14:18:05 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Ctj-0003fH-Ch; Tue, 01 Mar 2005 14:19:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6CqG-0006nJ-Uw; Tue, 01 Mar 2005 14:15:36 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6CqG-0006nE-3P for rtg-bfd@megatron.ietf.org; Tue, 01 Mar 2005 14:15:36 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00016 for <rtg-bfd@ietf.org>; Tue, 1 Mar 2005 14:15:33 -0500 (EST)
From: richard.spencer@bt.com
Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6CrG-0003c1-Iu for rtg-bfd@ietf.org; Tue, 01 Mar 2005 14:16:38 -0500
Received: from i2km97-ukbr.domain1.systemhost.net ([193.113.197.30]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 1 Mar 2005 19:15:26 +0000
Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km97-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 1 Mar 2005 19:15:26 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 01 Mar 2005 19:15:25 -0000
Message-ID: <B5E87B043D4C514389141E2661D255EC0A8358D3@i2km41-ukdy.domain1.systemhost.net>
Thread-Topic: Ability to detect swapped/merged LSPs
thread-index: AcUeja0mV6WQ4yTtRm+h1P3WkrpmzgABI4cA
To: jhaas@nexthop.com
X-OriginalArrivalTime: 01 Mar 2005 19:15:26.0308 (UTC) FILETIME=[0634DA40:01C51E93]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: quoted-printable
Cc: rtg-bfd@ietf.org
Subject: RE: Ability to detect swapped/merged LSPs
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: quoted-printable
Jeff, Yes I agree, if BFD packets are being sent to the wrong place then we'll get a detection timeout and LSP ping can then be used to locate and diagnose the problem. Regards, Richard > -----Original Message----- > From: Jeffrey Haas [mailto:jhaas@nexthop.com] > Sent: 01 March 2005 17:56 > To: Spencer,R,Richard,XDE73 R > Cc: rtg-bfd@ietf.org > Subject: Re: Ability to detect swapped/merged LSPs > > > Richard, > > I wont claim to be a MPLS expert, but I'm struck by the following: > > On Tue, Mar 01, 2005 at 05:09:26PM -0000, > richard.spencer@bt.com wrote: > > If we get a swapped LSP (e.g. due to a corrupted forwarding > table or configuration error) then all BFD packets received > for the corresponding session will be dropped and the session > will be declared down as a detection timeout will occur. > However, if we get a merging defect where a node receives > both valid BFD packets in addition to invalid BFD packets > then this defect will not be detected. > > > > In both cases, traffic is being forwarded onto the wrong > destination and therefore these defects need to be detected > and appropriate actions taken, e.g. raise an alarm and inform > the LSP source (using the appropriate BFD status code) that a > defect has occurred so that the source can stop forwarding > packets or switch over to an alternative path if one exists. > > If we are receiving some other node's traffic due to forwarding > corruption in the network, then wouldn't: > a. The intended target of the session time out the session after the > appropriate interval? > b. The node that is accidentally receiving the traffic may be > potentially > unable to respond due to the inherent unidirectionality of an LSP? > (In other words, the case where we do not have an LSP that would > permit us to respond.) > > > By adding new processing rules and status codes, both of > these defects could be detected using BFD. An alternative > would be to use LSP ping but it would not provide the same > defect detection speed, i.e. an LSP might only get tested > using LSP pings every 30mins or maybe every hour in a large > network with hundreds of thousands of PWs/LSPs, as opposed to > BFD packets that can be sent every second. > > It's probably worth reminding people that a session for BFD for > MPLS LSPs must be bootstrapped using LSP-Ping. > > Upon failure of a BFD session, it's very reasonable to use > LSP-Ping not > only to reinitialize (or attempt to reinitialize) the BFD session, but > also do further troubleshooting. > > > Richard > > -- > Jeff Haas > NextHop Technologies >
- Ability to detect swapped/merged LSPs richard.spencer
- Re: Ability to detect swapped/merged LSPs Thomas D. Nadeau
- Re: Ability to detect swapped/merged LSPs Jeffrey Haas
- RE: Ability to detect swapped/merged LSPs richard.spencer
- RE: Ability to detect swapped/merged LSPs richard.spencer