Subject: RE: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 25 Jul 2019 20:26:40 +0000

Hi Albert,

Thanks for your feedback from an operator perspective – it is valuable. This “BFD hold up” behaviour that you desire is best handled by BFD since I would expect that similar behaviour would be desired across routing protocols (OSPF, ISIS, BGP) and perhaps other clients.

IMHO this is not something that we should be tackling within the scope of this BGP draft. Would you agree?

That said, this seems like a local implementation aspect to me. We should however discuss within the BFD WG if there is value in documenting this.

Thanks,
Ketan

From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: 25 July 2019 16:21
To: 'Albert Fu' <[email-masked]>; [email-masked]
Subject: Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Albert:

To clarify, do you support WG adoption with the draft as is.

As a WG chair, I have to trust that all  drafts are improved during the WG process.  Can this small change be made after adoption or should it be made before the draft is considered for adoption.

Sue Hares

From: Idr [mailto:[email-masked]] On Behalf Of Albert Fu (BLOOMBERG/ 120 PARK)
Sent: Thursday, July 25, 2019 4:19 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

I am in support of this draft, and would like to request a small change to make this draft more operationally useful.

We have encountered several traffic blackhole problems in our production network without this feature. As such, we have deployed BGP with strict BFD mode on a proprietary vendor implementation for a while.

Since a lot of MetroE circuit failures occur with interfaces still up, ie. break in the middle issues, the traditional knobs like interface hold-time/debounce timer can not be used to dampen interface flaps.

We have observed that interface issues tend to occur in bursts and would like to request that an option be added in "Section 4 Operation:" to delay BGP from coming up until BFD is proven stable continuously for a period of time (i.e. BFD hold up feature).

This is a feature that we are currently using in the proprietary vendor deployment. In our case, since we have multiple redundant paths, we have some links where we delay BGP from coming up until BFD has been stable continuously for 60 seconds.

Thanks
Albert Fu
Bloomberg

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 25 Jul 2019 16:33:39 -0400

Sue,

I support progress of this draft, it addresses real problem.
On Redback side of things we have implemented this around 2013, logic (proprietary) kept in BFD indeed, so +1 Ketan. I’d document it as an informal feature, that is recommended (same for YANG)

Cheers,
Jeff
On Jul 25, 2019, 4:27 PM -0400, Ketan Talaulikar (ketant) <[email-masked]>, wrote:
> To: [email-masked]
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Albert F <[email-masked]>
Date: Thu, 25 Jul 2019 17:13:25 -0400

Hi Ketan,

I think it will be good to mention this in the doc, as I expect most large
networks concerned with network stability impacted by link flaps to enable
the BFD hold-up feature.

For example, if one side has BFD hold-up enabled (> BGP hold time) and the
other side does not, the BGP keepalive message from one side may be delayed
even if BFD is up. This may have implication on the BGP session
transitiining to established phase.

Thanks
Albert

On Thu, Jul 25, 2019, 4:27 PM Ketan Talaulikar (ketant) <[email-masked]>
wrote:

> Hi Albert,
>
>
>
> Thanks for your feedback from an operator perspective – it is valuable.
> This “BFD hold up” behaviour that you desire is best handled by BFD since I
> would expect that similar behaviour would be desired across routing
> protocols (OSPF, ISIS, BGP) and perhaps other clients.
>
>
>
> That said, this seems like a local implementation aspect to me. We should
> however discuss within the BFD WG if there is value in documenting this.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of *Susan Hares
> *Sent:* 25 July 2019 16:21
> *To:* 'Albert Fu' <[email-masked]>; [email-masked]
> *Subject:* Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
>
>
>
> Albert:
>
>
>
> As a WG chair, I have to trust that all  drafts are improved during the WG
> process.  Can this small change be made after adoption or should it be made
> before the draft is considered for adoption.
>
>
>
> Sue Hares
>
>
>
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Albert Fu (BLOOMBERG/ 120 PARK)
> *Sent:* Thursday, July 25, 2019 4:19 PM
> *To:* [email-masked]
> *Subject:* [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
>
>
>
> I am in support of this draft, and would like to request a small change to
> make this draft more operationally useful.
>
> We have encountered several traffic blackhole problems in our production
> network without this feature. As such, we have deployed BGP with strict BFD
> mode on a proprietary vendor implementation for a while.
>
> Since a lot of MetroE circuit failures occur with interfaces still up, ie.
> break in the middle issues, the traditional knobs like interface
> hold-time/debounce timer can not be used to dampen interface flaps.
>
>
> We have observed that interface issues tend to occur in bursts and would
> like to request that an option be added in "Section 4 Operation:" to delay
> BGP from coming up until BFD is proven stable continuously for a period of
> time (i.e. BFD hold up feature).
>
>
> This is a feature that we are currently using in the proprietary vendor
> deployment. In our case, since we have multiple redundant paths, we have
> some links where we delay BGP from coming up until BFD has been stable
> continuously for 60 seconds.
>
> Thanks
> Albert Fu
> Bloomberg
>
>
>
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 25 Jul 2019 22:22:20 +0000

Hi Albert, Ketan,
The authors will document dampening in the operational considerations. I’m also of the mind that the dampening should be done in BFD rather than the BFD clients (e.g., BGP).
Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Albert F <[email-masked]>
Date: Thursday, July 25, 2019 at 5:14 PM
To: "Ketan Talaulikar (ketant)" <[email-masked]>
Cc: IDR List <[email-masked]>, "[email-masked]" <[email-masked]>, Albert Bloomberg <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Hi Ketan,

I think it will be good to mention this in the doc, as I expect most large networks concerned with network stability impacted by link flaps to enable the BFD hold-up feature.

For example, if one side has BFD hold-up enabled (> BGP hold time) and the other side does not, the BGP keepalive message from one side may be delayed even if BFD is up. This may have implication on the BGP session transitiining to established phase.

Thanks
Albert

On Thu, Jul 25, 2019, 4:27 PM Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Albert,

Thanks,
Ketan

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Susan Hares
Sent: 25 July 2019 16:21
To: 'Albert Fu' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Albert:

Sue Hares

Thanks
Albert Fu
Bloomberg

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

---

From: "Mercia Zheng (merciaz)" <[email-masked]>
Date: Thu, 25 Jul 2019 22:35:44 +0000

Hi Albert,

Thanks for the support and valuable comments from a customer’s perspective.

This BFD ‘hold-up’ request actually applies to all BFD clients (e.g. control protocols).
I think that BFD would be a better component to apple this BFD hold-up as Ketan also mentioned.
However, some specification will be included in the next revision of the doc.

Thanks,
-Mercia

Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Albert Bloomberg <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>

Hi Ketan,

Thanks
Albert

Thanks,
Ketan

Albert:

Sue Hares

Thanks
Albert Fu
Bloomberg

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 25 Jul 2019 18:41:14 -0400

Hi Acee,
I imagine that there could be multiple clients of the same BFD session with
different requirements in regard to dampening behavior. For example, the
delay each client desires to use may be different for each client of the
BFD session. If that is a plausible use case, I think that placing
dampening to a client may be a better choice.

Regards,
Greg

On Thu, Jul 25, 2019 at 6:23 PM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Albert, Ketan,
>
> The authors will document dampening in the operational considerations. I’m
> also of the mind that the dampening should be done in BFD rather than the
> BFD clients (e.g., BGP).
>
> Thanks,
> Acee
>
>
>
> *From: *Lsr <[email-masked]> on behalf of Albert F <
> [email-masked]>
> *Date: *Thursday, July 25, 2019 at 5:14 PM
> *To: *"Ketan Talaulikar (ketant)" <[email-masked]>
> *Cc: *IDR List <[email-masked]>, "[email-masked]" <[email-masked]>,
> Albert Bloomberg <[email-masked]>, Susan Hares <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
>
>
>
> Hi Ketan,
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 26 Jul 2019 03:09:32 +0000

Hi Greg,
We’ll take your opinion under consideration.
Thanks,
Acee
From: Lsr <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Thursday, July 25, 2019 at 6:41 PM
To: Acee Lindem <[email-masked]>
Cc: IDR List <[email-masked]>, Albert Bloomberg <[email-masked]>, "Ketan Talaulikar (ketant)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Albert F <[email-masked]>, Susan Hares <[email-masked]>
Subject: Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Hi Acee,
I imagine that there could be multiple clients of the same BFD session with different requirements in regard to dampening behavior. For example, the delay each client desires to use may be different for each client of the BFD session. If that is a plausible use case, I think that placing dampening to a client may be a better choice.

Regards,
Greg

On Thu, Jul 25, 2019 at 6:23 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Albert, Ketan,
The authors will document dampening in the operational considerations. I’m also of the mind that the dampening should be done in BFD rather than the BFD clients (e.g., BGP).
Thanks,
Acee

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Albert F <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 25, 2019 at 5:14 PM
To: "Ketan Talaulikar (ketant)" <[email-masked]<mailto:[email-masked]>>
Cc: IDR List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Albert Bloomberg <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Hi Ketan,

Thanks
Albert

Thanks,
Ketan

Albert:

Sue Hares

Thanks
Albert Fu
Bloomberg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 28 Jul 2019 00:23:05 +0000

Greg –

I have a very different opinion.

Dampening should always be done at the lowest layer possible.
In most cases this argues for interface layer, but there are cases (switches in the path to the directly connected neighbor) where interface dampening doesn’t always tell you what you need to know.  So I acknowledge the usefulness of dampening at the BFD layer.
But doing it at the BFD client layer is wasteful. It forces the same logic to be implemented in multiple places and introduces race conditions where what BFD thinks and what the BFD client thinks about the same state differ.
I would argue against such an approach.

I have a related question:

In the case where the BGP neighbor is multiple hops away, what benefit does BFD dampening provide?
(Note that I am assuming that there likely would be single hop BFD sessions used by the IGPs (for example) along the path to the BGP neighbor and expecting that BFD dampening would be use for the single hop sessions when appropriate.)

   Les

From: Lsr <[email-masked]> On Behalf Of Greg Mirsky
Sent: Thursday, July 25, 2019 3:41 PM
To: Acee Lindem (acee) <[email-masked]>
Cc: [email-masked]; Albert Bloomberg <[email-masked]>; Ketan Talaulikar (ketant) <[email-masked]>; [email-masked]; [email-masked]; Albert F <[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Hi Acee,

Regards,
Greg

Hi Ketan,

Thanks
Albert

Thanks,
Ketan

Albert:

Sue Hares

Thanks
Albert Fu
Bloomberg