Robert - From: Robert Raszuk <[email protected]> Sent: Saturday, January 29, 2022 12:20 PM To: Les Ginsberg (ginsberg) <[email protected]> Cc: Acee Lindem (acee) <[email protected]>; Ketan Talaulikar <[email protected]>; [email protected]; Albert Fu <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
Hi Les, > Discussion of how to make BFD failure detection more robust belongs in the > BFD WG > If you do not want the BFD session to come back up too quickly after a failure Nothing I suggested is related to any of the above. Let me perhaps provide a very simple example. BFD being used is *AS*IS*. All the operator wants is to run it for say X sec without ever going down before bringing OSPF adj up. That timer and its consistency on both ends clearly belongs to OSPF not to BFD. [LES:] I disagree. The definition of UP state belongs to the BFD protocol/implementation. If you don’t want BFD clients (like OSPF) to react “too quickly” then build additional config/logic into your BFD implementation so it does not signal UP state before additional criteria is met – do not make each BFD client (and there could be multiple for a given session) configure its own definition of BFD UP. Now what happens within those 30 sec, what BFD packets are formed and how they are exchanged is all BFD business - but I am not suggesting to include any of those in this draft. Do we have a common understanding so far ? Hint: Albert already stated that he needs that timer and that both vendors provided it via cfg. All that confirms is that timer is needed. All I am suggesting (even before being aware of the manual cfg for it) was to synchronize the value or pick lower configured between two peers. [LES:] I don’t know if Albert and I disagree. I am saying that the implementations I am familiar with have introduced this capability for OSPF precisely because OSPF did not have strict mode support as defined in this draft. There has been no need for this with IS-IS – which has had equivalent support (RFC 6213) for many years. And once OSPF strict-mode support becomes widely deployed there won’t be a need for such a timer for OSPF either. Les Kind regards, R. On Sat, Jan 29, 2022 at 9:08 PM Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> wrote: Robert – It is good that you take an active interest in this technology – but I think the suggestions you are making should not be targeted at IGP use of BFD. Discussion of how to make BFD failure detection more robust belongs in the BFD WG – and – as you know – that WG has taken an interest in such problems e.g., MTU. In regards to “dampening” = which I think is the relevant term for the timer related suggestions you are making - this also does not belong in the IGP. If you do not want the BFD session to come back up too quickly after a failure, the proper place to put timers is either at the interface layer or in the BFD implementation. I am familiar with implementations which apply this timer at the protocol level (AKA BFD client in this context) and this is done precisely because the protocol does NOT have the functionality being defined in this draft. Once you have implemented “wait-for-BFD” logic as defined in this draft you do not need additional delay timers in the protocol. I don’t think the suggestions you are making belong in this document. Les From: Lsr <[email protected]<mailto:[email protected]>> On Behalf Of Robert Raszuk Sent: Saturday, January 29, 2022 11:25 AM To: Acee Lindem (acee) <[email protected]<mailto:[email protected]>> Cc: Ketan Talaulikar <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Albert Fu <[email protected]<mailto:[email protected]>>; lsr <[email protected]<mailto:[email protected]>> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 Hi Acee, Can you suggest text which with you’d be happy? I’m sure the authors would add you to the acknowledgements. Actually instead of suggesting any new text I would suggest to delete the two below sentences and it will be fine: "In certain other scenarios, a degraded or poor quality link will allow OSPF adjacency formation to succeed but the BFD session establishment will fail or the BFD session will flap. In this case, traffic that gets forwarded over such a link may experience packet drops while the failure of the BFD session establishment would not enable fast routing convergence if the link were to go down or flap." This could be described but I don’t think it should be normative. This begs the question as to why a hold down timer is not a part of the BFD protocol itself. There is one - BFD calls it multiplier. But the timer I am suggesting is not related to BFD operation, but to OSPF (and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about allowing BFD for more testing (with various parameters (for example increasing test packet size in some discrete steps) before OSPF is happy to bring the adj. up. Thx, R.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
