Re: other comments for single-hop bfd [Re: I-D ACTION:draft-ietf-bfd-v4v6-1hop-01.txt]

[Dave Katz <[e-mail]>]

On Feb 23, 2005, at 12:25 PM, Pekka Savola wrote:

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

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.

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

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