Robert – I am hoping to bring closure to the question of progressing the OSPF BFD strict mode draft. To that end I will not address each of your points in detail. I will say that what you have presented is NOT an accurate history.
Strict-mode behavior has been deployed for many years – first with IS-IS – later (with proprietary implementations) in OSPF. BFD Dampening was not in the picture. The issue BFD Dampening tries to address came later – and the mechanisms used to implement it have not been broadly agreed upon. There certainly is an argument to be made that the BFD Client is the worst possible choice if one were to implement a form of dampening. There may not be consensus on that point – but there is also not consensus against it either. If you are drawing a line and saying the draft should not go forward without discussing dampening/delay – I am decidedly on the other side of that line. Les From: Lsr <lsr-boun...@ietf.org> On Behalf Of Robert Raszuk Sent: Sunday, February 6, 2022 3:31 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Cc: lsr <lsr@ietf.org>; Christian Hopps <cho...@chopps.org> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 Les, Please kindly present the facts. The facts are that equivalent functionality in OSPF which has been approved for years uses a configurable timer which allows both - to wait for BFD as well to make sure that BFD stays UP till that timer expires. The point I even started this discussion was about your threat that this timer will be removed once this draft goes to RFC. So today without this timer when the interface goes UP both OSPF and BFD go in parallel and OSPF can win. That is bad as BFD when it comes UP and shortly goes down causes routing churn and packet drops. Note that can happen in the vast majority of cases when either links have problems with unicast (possible but pretty rare) or when BFD came up some time (say 100 ms) after OSPF brought adj. UP and then BFD declared failure during Echo packet exchange. So how does the situation above change with this draft ... When the interface goes UP OSPF will not bring adj UP till BFD comes UP. But then we are back in square one as OSPF adj comes UP and BFD after a full cycle of testing brings it back down. So what have we accomplished with this draft/RFC - nothing. In both cases you have to be pretty unlucky to get a link failure either between OSPF adj UP and BFD full cycle of Echo packets. But the entire purpose of this draft is to address that very unfortunate sequence of events. We all seem to agree we need to wait a bit longer. We have whatsoever no agreement across WGs who should take it on it's shoulder. Should this be BFD to delay UP notification to the client, should this be the client to take UP but only move on if no DOWN was seen within a timer or maybe this should be middlemen like RIB which is likely acting as a postman here. I still believe all of this should be at least reflected in the draft even if the conclusion is to leave it up to implementation choice. IMO refusing to even mention this is equal to proceeding with architecturally broken specification. Cheers, Robert. On Mon, Feb 7, 2022 at 12:14 AM Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote: Robert – I have brought this in the context of the waif-for-bfd OSPF proposal. This is the first time LSR WG is facing such a requirement so IMO it would be proper to at least discuss this in the draft. [LES:] Well – no – that statement isn’t true. The strict-mode drafts (OSPF and BGP) are specifying behavior which has long been deployed. IS-IS specified this in RFC 6213 many years ago. Proprietary implementations of the equivalent functionality in OSPF have been deployed for many years – but they lack a means to successfully interoperate with implementations which do not have the functionality and/or are not configured to enable it. All this draft is doing is defining protocol extensions for OSPF to support strict-mode as it has been deployed for many years. As such, most of the discussion is out of scope and we should simply approve the document. It is both understandable and potentially useful that the context here has revived other concerns that you may have had for a long time. But addressing those concerns is new work, outside the scope of this draft, and likely demands a broader audience than LSR WG provides. Let’s move on with this draft as is. If you or others want to pursue new work related to this functionality, please do so – but NOT in the context of this draft. Les
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
