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