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