I will leave the implementation aspect to the experts.
I do agree with Les, as per our current network deployment, that most BFD use
cases for BGP are for single hop eBGP sessions. For multihop iBGP sessions, we
do not run BFD on the iBGP sessions, and will instead run BFD on the underlying
IGP.
I would also like to add that it will be good for BFD dampening implementation
to be "smart" in that the "Up" signal from BFD to the client (ISIS/OSPF/BGP)
should occur only if the BFD session remains up over the dampening/hold-up
period. This will avoid the client (ISIS/OSPF/BGP) from being prematurely being
established until the network status is proven stable. For example, if the
hardware fault causes the break-in-middle failure to occur every 5s
continuously, and the dampening/hold-up period if 10s, we would prefer not to
bring the client protocol up. This will help to reduce network churn and
improve stability.
Thanks
Albert
From: ginsb...@cisco.com At: 07/27/19 20:23:21To: gregimir...@gmail.com,
a...@cisco.com
Cc: Albert Fu (BLOOMBERG/ 120 PARK ) , i...@ietf.org, ket...@cisco.com,
l...@ietf.org, rtg-bfd@ietf.org, albert.f...@gmail.com, sha...@ndzh.com
Subject: RE: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode
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 <lsr-boun...@ietf.org> On Behalf Of Greg Mirsky
Sent: Thursday, July 25, 2019 3:41 PM
To: Acee Lindem (acee) <a...@cisco.com>
Cc: i...@ietf.org; Albert Bloomberg <af...@bloomberg.net>; Ketan Talaulikar
(ketant) <ket...@cisco.com>; l...@ietf.org; rtg-bfd@ietf.org; Albert F
<albert.f...@gmail.com>; Susan Hares <sha...@ndzh.com>
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) <a...@cisco.com> 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 <lsr-boun...@ietf.org> on behalf of Albert F <albert.f...@gmail.com>
Date: Thursday, July 25, 2019 at 5:14 PM
To: "Ketan Talaulikar (ketant)" <ket...@cisco.com>
Cc: IDR List <i...@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Albert
Bloomberg <af...@bloomberg.net>, Susan Hares <sha...@ndzh.com>,
"l...@ietf.org" <l...@ietf.org>
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) <ket...@cisco.com>
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.
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 <idr-boun...@ietf.org> On Behalf Of Susan Hares
Sent: 25 July 2019 16:21
To: 'Albert Fu' <af...@bloomberg.net>; i...@ietf.org
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:idr-boun...@ietf.org] On Behalf Of Albert Fu (BLOOMBERG/ 120
PARK)
Sent: Thursday, July 25, 2019 4:19 PM
To: i...@ietf.org
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
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr
