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
>