Re: [EXTERNAL] Can a BFD session change its source port to facilitate auto recovery

m>> wrote: >> Abhinav, Jeff and all, >> >> FWIW I concur with Jeff. >> >> >> In my experience, MH IP BFD sessions are typically used to monitor peering >> between iBGP neighbors, and when the MH IP BFD session goes down, BGP treats >> thi

Re: [EXTERNAL] Re: Can a BFD session change its source port to facilitate auto recovery

ghbors, and when the MH IP BFD session goes down, BGP treats this as if its session has gone – and deletes the MH IP BFD session in question. I.e., fast recovery of such a session will not happen until BGP would not re-create it. Regards,Sasha From: Rtg-bfd <rtg-bfd-boun...@ietf.org> On Behalf Of J

Re: Can a BFD session change its source port to facilitate auto recovery

Abhinav,Let’s clarify a couple of points.What you are trying to do is to change entropy to change local hashing outcome, however for hashing to even be relevant there has to he either ECMP or LAG in the path to the destination otherwise shortest path will be he used regardless, so statistically,

RE: Working Group Last Call on BFD YANG model - round 2, RFC 9127-bis ending 14 January, 2022

Yes/support  Cheers,Jeff  From: Jeffrey HaasSent: Wednesday, January 5, 2022 11:17 AMTo: rtg-bfd@ietf.orgSubject: Working Group Last Call on BFD YANG model - round 2, RFC 9127-bis ending 14 January, 2022 Working Group, This begins a second round of Working Group Last Call on the RFC 9127-biswork. 

Re: MPLS wg aoption poll on on draft-mirsky-mpls-p2mp-bfd

Yes/support Cheers, Jeff > On Dec 13, 2021, at 14:53, Loa Andersson wrote: > > draft-mirsky-mpls-p2mp-bfd

Re: [mpls] Seeking suggestions on the next steps to progress draft-ietf-mpls-bfd-directed

Same view here, I believe the draft is ready to progress. Thanks! Cheers, Jeff > On Aug 8, 2021, at 01:08, Gyan Mishra wrote: > >  > Dear MPLS WG chairs, > > I believe this draft has matured and is clearly written and coherent and a > very helpful for operators to have this bidirectional

Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

ocol changes. So with 2 > documents, are you proposing that the BFD spec should be informational and > the YANG standards track? Or both informational? If it’s the latter, I’d > rather they be in the same doc. > > Regards, > Reshad ( no hat). > From: Jeff Tantsura > Date: Tu

Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

IMHO - It isn’t right that presence of YANG defines document’  designation track. The common practice is that if the draft in question doesn’t require any protocol changes it should aim for Informational track (or BCP). https://ietf.org/standards/process/informational-vs-experimental/ I’d

Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

I support this document with exactly same points Les’s made, it should progress as informational. Regards, Jeff > On Aug 17, 2020, at 20:36, Les Ginsberg (ginsberg) > wrote: > > Sorry to be tardy in responding... > > As I stated almost 2 years ago when this draft was introduced: > > a)The

Re: BFD chair response to presentation on draft-mirmin-bfd-extended

Jeff/Les, Point taken, thanks! Regards, Jeff > On Nov 22, 2019, at 15:44, Les Ginsberg (ginsberg) wrote: > > For the record, I agree with Jeff's summary and comments. > > I was really surprised that Greg did not wait until IETF 107 - which the BFD > chairs had already indicated would be

Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

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

Re: WG Adoption for draft-chen-bfd-unsolicted

Yes/support Makes sense, in Redback times we had a design to build it that way (never did though), not an IPR disclosure . Cheers, Jeff On Oct 29, 2018, 2:32 PM -0700, Naiming Shen (naiming) , wrote: > > Support as a co-author. > > Regards, > - Naiming > > > On Oct 29, 2018, at 8:52 AM, Jeffrey

Re: IPR call for draft-mirsky-bfd-p2mp-vrrp-use-case

Chris, I'm not aware of any IPR that applies to draft-mirsky-bfd-p2mp-vrrp-use-case, other, than already disclosed. Thanks! Jeff On 2/20/18, 11:37, "Rtg-bfd on behalf of Chris Bowers" wrote: RTGWG,

Re: WG adoption poll for draft-nitish-vrrp-bfd-p2p

Support as co-author Regards, Jeff > On Jan 10, 2018, at 13:23, Chris Bowers wrote: > > RTGWG, > > This email starts the two week WG adoption poll for draft-nitish-vrrp-bfd-p2p. > > https://datatracker.ietf.org/doc/draft-nitish-vrrp-bfd-p2p/ > > Please indicate

Re: BFD WG Call For Adoption draft-spallagatti-bfd-vxlan

Yes/support On Thu, Dec 28, 2017 at 00:24 Santosh P K wrote: > I support for WG adoption. > > On Thu, Dec 28, 2017 at 7:16 AM, Zhangmingui (Martin) < > zhangmin...@huawei.com> wrote: > >> The use case is meaningful and the document is neatly organized. Support >>

Re: Adoption call for draft-ashesh-bfd-stability (ends April 30, 2017)

yes/support Cheers, Jeff On 4/17/17, 14:39, "Rtg-bfd on behalf of Jeffrey Haas" wrote: Working Group, https://tools.ietf.org/html/draft-ashesh-bfd-stability-05 The authors of BFD Stability

Re: Adoption request for draft-tanmir-rtgwg-bfd-mc-lag

Support as co-author Regards, Jeff > On Mar 23, 2017, at 16:30, Jeffrey Haas wrote: > > We had presentations on draft-tanmir-rtgwg-bfd-mc-lag-(mpls|ip) during IETF > 96. > This work covers multi-chassis forms of BFD-on-LAG, similar to RFC 7130. > > After that presentation,

Re: WG adoption poll on draft-nitish-vrrp-bfd-04

Support as co-author Cheers, Jeff On Thu, Sep 29, 2016 at 9:14 PM, Chris Bowers wrote: RTGWG, This email starts a two week poll to gauge consensus on adopting draft-nitish-vrrp-bfd-04 as an RTGWG working group document. The BFD working group is also

Re: WGLC for draft-ietf-bfd-seamless-base

Yes/support Cheers, Jeff On Tue, May 5, 2015 at 1:50 AM, Jeffrey Haas jh...@pfrc.orgmailto:jh...@pfrc.org wrote: Working Group, This is to start a two week Working Group Last Call for draft-ietf-bfd-seamless-base, Seamless Bidirectional Forwarding Detection (S-BFD) [-base]. This WGLC ends on

Re: WGLC for draft-ietf-bfd-seamless-ip

Yes/support Cheers, Jeff On Tue, May 5, 2015 at 1:53 AM, Jeffrey Haas jh...@pfrc.orgmailto:jh...@pfrc.org wrote: Working Group, This begins a two week Working Group Last Call for draft-ietf-bfd-seamless-ip, Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS. This