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<mailto: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

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to