Subject: I-D ACTION:draft-ietf-bfd-v4v6-1hop-01.txt

From: [email-masked]
Date: Tue, 22 Feb 2005 15:36:41 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.

	Title		: BFD for IPv4 and IPv6 (Single Hop)
	Author(s)	: D. Katz, D. Ward
	Filename	: draft-ietf-bfd-v4v6-1hop-01.txt
	Pages		: 11
	Date		: 2005-2-22
	
This document describes the use of the Bidirectional Forwarding
   Detection protocol over IPv4 and IPv6 for single IP hops.  It further
   describes the use of BFD with OSPFv2, OSPFv3, and IS-IS.  Comments on
   this draft should be directed to [email-masked].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-bfd-v4v6-1hop-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-bfd-v4v6-1hop-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Feb 2005 21:25:05 +0200 (EET)

Hi,

A couple of other comments for the single hop bfd spec:

- the text for supporting single-hop static routes and eBGP was 
discussed previously on the list.  This is not included in -01. Was 
this just forgotten (as the draft was submitted at the last minute), 
or was there a particular reason for excluding these ?

- the last sentence of the following text is not factually correct:

    Note that it is possible in some failure scenarios for the network to
    be in a state such that the IGP comes up, but the BFD session cannot
    be established, and, more particularly, data cannot be forwarded.
    To avoid this situation, it would be beneficial to not allow the IGP
    to establish a neighbor/adjacency.  However, this would preclude the
    operation of the IGP in an environment in which not all systems
    support BFD.

.. 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.

Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Dave Katz <[email-masked]>
Date: Wed, 23 Feb 2005 22:50:45 -0700

> or was there a particular reason for excluding these ?

Brain fart;  I had forgotten (the discussion was in July, and I'm 
reaching the age of senility.)

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.

> authentication.  But in reality, it is an interface toggle, so this 

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.

--Dave

---

From: Pekka Savola <[email-masked]>
Date: Thu, 24 Feb 2005 09:06:39 +0200 (EET)

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.

--

---

From: Dave Katz <[email-masked]>
Date: Thu, 24 Feb 2005 01:22:30 -0700

On Feb 24, 2005, at 12:06 AM, Pekka Savola wrote:

>> 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.
>

I guess this was overtaken by my slothfulness.  The question at hand 
now should be whether this document should be stalled for however long 
is necessary to incorporate it.  Assuming that it would require another 
IETF meeting to approve moving the document along the standards track, 
then it would seem to me that we should separate it out (assuming that 
this version is otherwise acceptable, modulo editorial issues.)  
Perhaps the WG chairs can step in and outline the pros and cons here.  
My apologies for letting this stuff slip by.

> must enable BFD on all the systems you have adjacencies to on a 

Unfortunately, incorrect operation of the IGP on a single interface has 
network-wide implications (you can partition the network, for example.) 
  Network-wide correctness is predicated on node-by-node (and 
interface-by-interface) correctness.

> there, this shouldn't be a problem.

It seems likely that someone will have a setup that differs from yours, 
either now or sometime in the future.

--Dave

---

From: David Ward <[email-masked]>
Date: Thu, 24 Feb 2005 10:28:32 -0600

Dave, et al -

There should be a simple, 'how to bootstrap a BFD session and what to do
when you rx a BFD event' doc. The pros are that we don't have to increment
this doc every time we think about another protocol to interact w/ BFD, the
cons are that it is just about all contained in this doc. There are some 
nuances of IGP interaction but, for the most part  protocols/applications that
want to be dependent on  BFD as a forwarding failure detection, will have 
very generic interactions.

I am hoping that  the new draft will be  very, very short and not call out
each and every application, scenario or potential usage. If we keep it
generic, we can get it through the process much more quickly. If a protocol
or application actually has specific needs (e.g. LSPping), then it deserves
it's own draft/spec. I think Dave and I can crank this out very quickly.

-DWard