Re: [Idr] ietf-104 responding to Rüdiger's comment about bfd strict mode

["Rajiv Asati (rajiva)" <[e-mail]>]

Hi Robert,

Let me make sure that I get it right - Data plane liveness check (for 2 neighbors’ IP addresses) should be done and the result should be fed back into BGP.

The reason for not using BFD, and rather using non-BFD alternatives (such as TWAMP, IPSLA etc) is that the latter checks for neighbors IP reachability, not just link stability.

And the reason we don’t want to rely BGP initial packets (inc TCP 3-way) is that it wouldn’t detect the data plane failure for neighbor reach ability after the session has come up.

So far so good? Did I get that right?


However, Is there a broad () assumption that just because link is stable, BGP session is UP (neighbors can reach each other), then routes could be advertised and traffic would flow *through* them just fine?

As you know well, the assumption is not always valid, as we have observed in production networks. And if hooks in BGP are desired, then let’s do them to solve the broader set of issues as well.

Cheers,
Rajiv


On Mar 28, 2019, at 1:06 PM, Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:

Hi,

As commented on the mic for partially loosy links I would like to see hooks in BGP outside of BFD to determine if BGP session is to be established or torn down.

Specifically using existing tools like rpm or ip sla probes ...

Thx
R.

On Thu, Mar 28, 2019, 12:19 Jeffrey Haas <[e-mail]<mailto:[e-mail]>> wrote:
In IETF 104, Rüdiger responded that he'd like to see BFD in BGP be used to
prove that a link is "stable enough" before we even announce routes.

As I mentioned at the mic, the critical issue is that we have varying
implementations of when BFD must be up in differing implementations with
regard to the BGP FSM.  E.g. Up before we start the transport session
(Connect), or Up before we transition to Established, or Up after
Established.

The proposal from Mercia and Acee effective summ to "if BFD strict
negotiated, wait for BFD to come up before transition to Established".  This
provides a common point for implementations to interoperate.  There is still
potentially issue with older implementations that relied on BFD to be Up
before BGP starts its TCP session; however upon supporting this feature we
implicitly add an option where the behavior is changed.

Back to Rüdiger's point: He has a desire that the session is stable before
we start announcing routes.  In BGP RFC parlance, we do not exchange our
routes in the Update-Send process until stability is declared.

While this is doable, how do you negotiate what level of stability is
desired?  BFD, without extensions, mostly will simply declare the session
Down when enough packets are lost.  If the link quality is very bad, this
should happen quite quickly. If the link quality is partially lossy, BFD
doesn't help.  (However, see https://tools.ietf.org/html/draft-am-bfd-performance-00)

-- Jeff

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr