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) <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 > > > _______________________________________________ > Lsr mailing list > l...@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
