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

From: Jeffrey Haas <[email-masked]>
Date: Thu, 28 Mar 2019 07:18:33 -0400

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 28 Mar 2019 13:04:15 +0100

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 <[email-masked]> wrote:

> doesn't help.  (However, see
> https://tools.ietf.org/html/draft-am-bfd-performance-00)
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 28 Mar 2019 13:23:14 +0100

Let's also observe that while strict mode works fine for IGPs for BGP in
general it may be cause of a bit of surprise.

Imagine this is used on IBGP side and sessions to RR are getting dropped
while there is nothing wrong with reachability and quality of paths to
actual next hops.

Therefor shouldn't this discussion be moved a bit up to enhance the way we
validate the quality of next hop reachability before using paths containg
them vs heavy hammer to put the actual session down ?

I am sure Rajiv can be happy to enhance his proposal along those lines.

Unless this is only for p2p ebgp session I am not sure this proposal of bgp
strict mode as presented today is actually a good idea.

Best,
R.

On Thu, Mar 28, 2019, 13:04 Robert Raszuk <[email-masked]> 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.
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 28 Mar 2019 13:45:46 +0000

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 <[email-masked]<mailto:[email-masked]>> 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.

Thx
R.

On Thu, Mar 28, 2019, 12:19 Jeffrey Haas <[email-masked]<mailto:[email-masked]>> 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.

-- Jeff

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 28 Mar 2019 13:52:00 +0000

Hi Robert,
As was discussed, manually configured BFD strict mode exist today. This is simply adding BGP signaling to these techniques.

From: Idr <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Thursday, March 28, 2019 at 8:06 AM
To: Jeff Haas <[email-masked]>
Cc: IDR List <[email-masked]>
Subject: Re: [Idr] ietf-104 responding to Rüdiger's comment about bfd strict mode

Hi,

We await your draft 😉

Thanks,
Acee

Thx
R.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 28 Mar 2019 15:26:09 +0100

Acee,

Yes you have bfd for bgp. Use case is for ebgp to bring bgp down as soon as
your peer goes down without cranking up bgp keepalives.

Well as it was presented today the scope of current proposal is much
broader. Hence the comments.

And as far as the draft here you go:

draft-ietf-idr-bgp-bestpath-selection-criteria-10

Each bgp implementation knows how to validate next hops quite efficiently
so if we extend it with proper criteria IMO overall we will be much better
off.

Said this I continue to believe that using BFD for liveness detection of
all bgp sessions (including ibgp) is not always a good idea.

Many thx,
R.

On Thu, Mar 28, 2019, 14:52 Acee Lindem (acee) <[email-masked]> wrote:

> Hi Robert,
>
> As was discussed, manually configured BFD strict mode exist today. This is
> simply adding BGP signaling to these techniques.
>
>
>
> *From: *Idr <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> *Date: *Thursday, March 28, 2019 at 8:06 AM
> *To: *Jeff Haas <[email-masked]>
> *Cc: *IDR List <[email-masked]>
> *Subject: *Re: [Idr] ietf-104 responding to Rüdiger's comment about bfd
> strict mode
>
>
>
> Hi,
>
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 28 Mar 2019 11:19:54 -0400

Robert,

> broader. Hence the comments.

I find it likely that the draft needs some clarity as to whether we'd want
this capability present (or not) when BFD is not intended to be used on the
link.

Your example of "we're doing ibgp, please don't use BFD for BGP":
- If we did want to use BFD, please use strict.
- If we didn't want to use BFD, we might still want to specify strict as a
  capability so that by not having it come up you didn't end up in one of
  your interop scenarios.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 28 Mar 2019 16:36:49 +0100

Hi Jeff,

Yes clarification of the scope is needed.

But my broader point also was to clarify which operational model fits best
to different scenarios.

We have clearny two options:

* keeping up/down of bgp session on say loosy links

vs

* extend the notion of valid/invalid next hop in the same env.

The latter seems much more universal and applies to various deployment
models.

Former can be used for specific use cases ex: directly connected ebgp peers
or in more general it can be used where bgp control plane is congruent with
data plane. That often for ibgp is not the case.

Thx,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 28 Mar 2019 11:51:44 -0400

> But my broader point also was to clarify which operational model fits best

While I agree it's a useful discussion, either in IDR or BFD, it's partially
orthogonal here.

The draft is not about whether we should run BFD.  The draft is about when
we run BFD how we should behave to do the Right Thing and interoperate.

> * keeping up/down of bgp session on say loosy links

In some cases a religious discussion.  There are scenarios where BGP
stability is more important than whether packets go over a lossy network or
not.

> * extend the notion of valid/invalid next hop in the same env.

Again, a religious discussion.  In environments where nexthop reachability
is intended to be highly reliable, things like rs-bfd nexthop behaviors may
be desirable.  For ibgp, it's generally more preferable to leverage BGP
protecting the underlying IGP.  In cases where there's no IGP, reliability
of connectivity will impact whether you want to do this or not.

-- Jeff