Multi-hop BFD would be the mechanism that detects the failure on the path it happens to be using for the session. I wasn't thinking of another mechanism. Detection timer expiry would be the trigger for recovery which could be augmented with few other possible criteria like how long session hasn't been able to come back up or prolonged flapping.
Thanks Abhinav On Wed, 22 Mar, 2023, 3:05 pm Greg Mirsky, <[email protected]> wrote: > Hi Abhinav, > thank you for presenting an interesting scenario for a discussion. I have > several questions to better understand it: > > - How the network failure that triggers the recovery process is > detected? > - If the failure detection mechanism is not multi-hop BFD, what is the > relationship between the detection intervals of heat mechanism and the > multi-hop BFD session? > > Regards, > Greg > > On Wed, Mar 22, 2023 at 4:36 PM Abhinav Srivastava <[email protected]> > wrote: > >> Hi all, >> >> >> >> I needed clarification around whether source port can be changed for a >> BFD session in case of multi hop BFD. The ability to change BFD source >> port when BFD session goes down helps BFD session to recover if its stuck >> on a network path where there is some intermittent but significant packet >> loss. >> >> >> >> In such cases, normally without BFD, end to end application traffic would >> eventually settle down on a good path as applications typically change >> source port after experiencing disconnection or failures. But if BFD is >> being used to monitor some part of a path which is experiencing significant >> but not 100% packet loss, it will start causing next hop list of associated >> static route or the associated BGP sessions to start flapping forever, as >> BFD packets would be stuck to that partial lossy path forever (until BFD >> session is deleted and recreated by admin action). This may also hinder >> the typical application recovery strategy of changing source port on >> failure. >> >> >> >> Ability to dynamically change BFD source port can help BFD recover in >> such cases. Is this something that is allowed as per RFC? The RFC5881, >> section 4 (for single hop) case states that – >> >> *“The source port MUST be in the range 49152 through 65535. The same UDP >> source port number MUST be used for all BFD Control packets associated with >> a particular session”* >> >> >> >> Thanks >> >> Abhinav >> >
