Re: other comments for single-hop bfd [Re: I-D ACTION:draft-ietf-bfd-v4v6-1hop-01.txt]
Pekka Savola <pekkas@netcore.fi> Thu, 24 February 2005 07: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 CAA23787; Thu, 24 Feb 2005 02:10:02 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DVE-0004Xm-Ls; Thu, 24 Feb 2005 02:33:40 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4D5L-0007sM-Lq; Thu, 24 Feb 2005 02:06:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4D5I-0007ou-Ri for rtg-bfd@megatron.ietf.org; Thu, 24 Feb 2005 02:06:52 -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 CAA20960 for <rtg-bfd@ietf.org>; Thu, 24 Feb 2005 02:06:51 -0500 (EST)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DS8-0004B8-8y for rtg-bfd@ietf.org; Thu, 24 Feb 2005 02:30:28 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j1O76dE23613; Thu, 24 Feb 2005 09:06:39 +0200
Date: Thu, 24 Feb 2005 09:06:39 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Dave Katz <dkatz@juniper.net>
In-Reply-To: <0b49f300cadf3d470eaebe742db25983@juniper.net>
Message-ID: <Pine.LNX.4.61.0502240900260.22843@netcore.fi>
References: <200502222036.PAA16765@ietf.org> <Pine.LNX.4.61.0502232119530.6499@netcore.fi> <0b49f300cadf3d470eaebe742db25983@juniper.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: rtg-bfd@ietf.org
Subject: Re: other comments for single-hop bfd [Re: I-D ACTION:draft-ietf-bfd-v4v6-1hop-01.txt]
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.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
On Wed, 23 Feb 2005, Dave Katz wrote: > It does raise the question of whether we want to continue to add text into > this document for other protocols, or whether it would be worth having > additional documents to cover them so that this one can be put to bed. I > would prefer to avoid further significant technical changes to this doc and > to have additional stuff be put into a separate one, in order to advance this > stuff without too much more tinkering. This should probably be discussed in > Minneapolis. Right. Obviously, I'm a proponent of putting it here (well, I asked if I should make it a separate draft back in July or so, but then it was felt ok to include it here). >> .. in fact it would preclude the operation of the IGP in the particular >> BFD-enabled _interface_. The text seems to be implying that having BFD >> would be an IGP domain-wide toggle like IS-IS authentication. But in >> reality, it is an interface toggle, so this argument is irrelevant. > > It is not irrelevant on multipoint media. Perhaps it would more correctly > read "...preclude the *correct* operation of the IGP..." It's not that it > makes the IGP completely fail, but it can create large-scale black holes if > the topology is particularly unlucky. I could add the extra word if you feel > strongly about it. No, this clarification would also be misleading. It would prevent the correct operation of the IGP *on that particular interface*. So, you must enable BFD on all the systems you have adjacencies to on a multipoint link. I'm not sure how common those multipoint links are (we certainly have only one with more than 1 neighbor with which we would like to run BFD; the most common are probably Ethernet IX's but folks don't run IGP there), so unless our setup differs radically from what's out there, this shouldn't be a problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
- I-D ACTION:draft-ietf-bfd-v4v6-1hop-01.txt Internet-Drafts
- other comments for single-hop bfd [Re: I-D ACTION… Pekka Savola
- Re: other comments for single-hop bfd [Re: I-D AC… Dave Katz
- Re: other comments for single-hop bfd [Re: I-D AC… Pekka Savola
- Re: other comments for single-hop bfd [Re: I-D AC… Dave Katz