Subject: Re: BFD WG charter

From: Alex Zinin <[email-masked]>
Date: Wed, 14 Apr 2004 18:41:41 -0700

>> > Nov 04    Submit BFD encapsulation and usage profile for Ethernet to the
>> >            IESG to be considered as a Proposed Standard

> Again, I'm not certain why this work wouldn't fall within the IEEE's
> domain?

I'm concerned about this too, actually...

Defining a standard on how to control Ethernet switches (including with BFD) is
not an IETF task. The only way I could see us doing something related is
documenting how the BFD framework defined in the IETF could be used in switched
Ethernet environment as an INFO RFC, and documenting the encapsulation.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Wed, 14 Apr 2004 18:50:52 -0700

>> > How about addressing multi-hop BFD operations for iBGP (and eBGP
>> > multihop)? Is there a specific reason why multi-hop for iBGP and OSPF
>> > VLs are not considered? (I am a little late in this game, so I dont
>> > know all the issues yet; just trying a getting a feel for things
>> > here).
>>
>> Aside from the crawl-before-you-walk aspect, the security issue has to be
>> dealt with before multihop can be used.

> I would also be concerned about false positives in the multihop cases--how
> would we actually handle these? In other words, we'll be taking neighbors
> down while the network reconverges under BFD.

> Isn't this something that should be considered? Or will we assume that all
> networks behave perfectly, and the BGD hello's will only fail when the link
> is gone forever?

Yes, this aspect will certainly need to be considered. We discussed it a bit
with Dave and Jeff a few days ago. I think if folks still find multi-hop useful,
timing considerations (don't configure a multi-hop BFD adjacency to go down
faster than the worst case convergence scenario) need to be spelled out at least
in the applicability statement. Some guidance in the spec would also be useful,
it seems.

Alex

---

From: Dave Katz <[email-masked]>
Date: Thu, 15 Apr 2004 10:24:20 -0700

> in the applicability statement. Some guidance in the spec would also 

There's no magic here;  if the path latency exceeds the detection time, 
then the session will go down.  The solution, which is true of any path 
whether it be single or multi hop, is to use timing sufficient to 
tolerate the path latencies.  This is no different than any other 
similar protocol (OSPF VLs, for example) except for a major advantage, 
which is that BFD timing is not fixed.

Given the facilities of the protocol, a halfway intelligent 
implementation should provide stability in spite of configuration 
attempts to the contrary.

I'm not sure what guidance to provide in the spec, besides "if it 
hurts, don't do that."