Ability to detect swapped/merged LSPs
richard.spencer@bt.com Tue, 01 March 2005 17:10 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 MAA18040; Tue, 1 Mar 2005 12:10:45 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6AuR-0000Qc-6Z; Tue, 01 Mar 2005 12:11:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6AsL-00058G-V4; Tue, 01 Mar 2005 12:09:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6AsK-00057w-MF for rtg-bfd@megatron.ietf.org; Tue, 01 Mar 2005 12:09: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 MAA17854 for <rtg-bfd@ietf.org>; Tue, 1 Mar 2005 12:09:34 -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 1D6AtK-0000OB-2r for rtg-bfd@ietf.org; Tue, 01 Mar 2005 12:10:38 -0500
Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Tue, 1 Mar 2005 17:09:26 +0000
Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 1 Mar 2005 17:09: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 17:09:26 -0000
Message-ID: <B5E87B043D4C514389141E2661D255EC0A8358D0@i2km41-ukdy.domain1.systemhost.net>
Thread-Topic: Ability to detect swapped/merged LSPs
thread-index: AcUegUChKJrpkS1TSXOkt6KOkb4hjg==
To: rtg-bfd@ietf.org
X-OriginalArrivalTime: 01 Mar 2005 17:09:26.0539 (UTC) FILETIME=[6C3BA5B0:01C51E81]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: quoted-printable
Subject: 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: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: quoted-printable
>From the current base draft "If the Your Discriminator field is nonzero, it MUST be used to select the session with which this BFD packet is associated. If no session is found, the packet MUST be discarded." If a node receives a BFD packet with a Discriminator field that it doesn't have a session for then there is a problem somewhere in the network, so why is the packet simply dropped and no further action taken? 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. I know that the idea behind the BFD draft is to keep it as simple as possible, but speaking as an operator, I would consider these defects to be just as important as loss of connectivity defects. They might not occur as frequently but are potentially more dangerous, e.g. I don't want to unknowingly be sending packets from customer As network to customer Bs network. 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. Does anyone have any arguments for/against adding the ability to detect these defects into BFD? Thanks, Richard
- 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