Hi John, Thanks for your quick response and clarifications. Please check inline below for responses with KT3.
We've also posted an update with the changes discussed below as well as the formal "updates RFC2328" point that was discussed earlier in this thread: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode-07 On Sat, Sep 3, 2022 at 2:06 AM John Scudder <[email protected]> wrote: > Hi Ketan, > > My comments in line below. > > > On Sep 2, 2022, at 6:37 AM, Ketan Talaulikar <[email protected]> > wrote: > > > > Hi John, > > > > Please check inline below for responses with KT2 > > > > > > On Thu, Sep 1, 2022 at 10:42 PM John Scudder <[email protected]> wrote: > > Hi Ketan, > > > > Thanks for the prompt update. I have one question about your edits. In > Section 6, I had suggested > > > > OLD: > > Implementations MAY > > provide a local configuration option to specifically enable BFD > > operation in OSPF BFD strict-mode only. > > > > NEW (my suggestion): > > Implementations MAY > > provide a local configuration option to require BFD strict-mode. > > > > NEW (your revision): > > Implementations MAY > > provide a local configuration option to require BFD operation in OSPF > > BFD strict-mode only. > > > > I’m wrestling with whether this option is supposed to mean “the > adjacency must not establish unless BFD comes up first” or “if the neighbor > supports BFD, then BFD must come up first before the adjacency is allowed > to establish”. > > > > KT2> I meant the former. So this is like "force" BFD strict-mode > operation. The default mode is negotiation when strict-mode is enabled. > > > > I.e., as written I can make the argument that if my neighbor doesn’t > advertise the B-bit, then it’s fine for the adjacency to come up as long as > BFD isn’t run at all. The former interpretation seems more operationally > useful, but the spec text is ambiguous. > > > > I’m not sure my proposed text even resolved that problem, on reflection. > In any case, I would be happier if the ambiguity were resolved somehow. > > > > KT2> How about the following? > > > > Implementations MAY provide a local configuration option to force BFD > operation only in > > OSPF BFD strict-mode (i.e, adjacency will not come up unless BFD session > is established). > > It gets the job done; good enough. KT3> Thanks. > > [snip] > > > > Whenever the neighbor state transitions to Down state, the removal > of > > > the BFD session associated with that neighbor SHOULD be requested > by > > > @@ -246,6 +281,14 @@ > > > result in the deletion and creation of the BFD session respectively > > > when OSPF is the only client interested in the BFD session with the > > > neighbor address. > > > + > > > +jgs: Please do a global search for the RFC 2119 keyword SHOULD and in > > > +each instance, consider whether it can be a MUST, or the normal > English > > > +word "should" (in lower or mixed case). If SHOULD is the appropriate > > > +keyword, please supply some detail about when it would be appropriate > > > +for an implementor to disregard the SHOULD. (The one place where I > > > +thought "should" might be the appropriate choice is in the Operations > & > > > +Management Considerations section.) > > > > > > KT> In this specific case, we are discussing implementation specifics > that are also applicable without the strict-mode, and hence introducing a > MUST here was not appropriate. We could change it to "should" if that would > be more appropriate. Looking for feedback if this change is required. > > > > This actually motivates the question, why does that paragraph need to be > there at all? Was the base behavior underspecified and in need of update? > > > > KT2> Yes, I believe has been underspecified in RFC5882. > > > > Is this just a nota bene for the implementor? Should you more clearly > signal that’s what it is? But this is in any case tangential to the main > point; we can return to it later perhaps. I did note the peculiar nature of > the paragraph on my first read-through, and figured it did no harm to > clarify that this is how implementations should be done regardless — but in > any case I don’t see why that makes MUST inappropriate. > > > > KT2> This is at the end and internal behavior between OSPF and BFD > within a system. It may be possible to do this differently and yet exhibit > the same external behavior. That is why either SHOULD or should seem more > appropriate. > > If I understand the situation correctly (and I haven’t gone and re-checked > what RFC 5882 says), that sounds like a case for “should”. You can change > it (and the one subsequent SHOULD that’s in the same category, total three) > or not, at your discretion. > KT3> Removed the first two SHOULD. I am retaining the third one as SHOULD since it is related to the mixed operation of strict-mode and normal mode of BFD use (in the next sentence). > > > > In some other places, the behavior may be applicable and shared with > "base" BFD and hence we felt not appropriate to make it a MUST. However, we > have taken the opportunity to suggest a desirable behavior. We look for > feedback if any specific instance needs change or clarification. > > > > I have a different take on the appropriate use of SHOULD vs. MUST. Let’s > look at what RFC 2119 says about SHOULD: > > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > > may exist valid reasons in particular circumstances to ignore a > > particular item, but the full implications must be understood and > > carefully weighed before choosing a different course. > > > > I tend to think of SHOULD informally as a “MUST… UNLESS” pair. > > > > KT2> I am not sure if the "MUST ... UNLESS" is the only pair and we can > also have "SHOULD ... and if not then …" > > Sure. > > > or "SHOULD ... so that ... will be ensured" > > I don’t get why that construct would be a “SHOULD”. You can equally supply > an explanation with a MUST. The crucial difference would be whether the > thing represented by the ellipsis between “that” and “will” is mandatory or > a nice-to-have. KT3> Ack. The use of SHOULD implies nice-to-have and otherwise, MUST is used when mandatory. > > > > and such. In some cases, the consequences are obvious - therefore the > RECOMMENDED. > > Formally, RECOMMENDED is nothing more nor less than a stand-in for SHOULD, > which again, is not the same as the English word “should”, it has a defined > meaning (albeit not a precisely nailed-down and perfectly defined one). > It’s not just emphasis. > > > Regarding your point that the extension is optional, it’s my position > that in the case of a specification for an optional extension, MUST means > “if you choose to practice this extension to the protocol, i.e. if the > extension is both implemented and enabled by configuration, then you MUST”. > > > > KT2> Agree on this point. My point was that this interaction on when > OSPF should "delete" BFD session on down is applicable to the base BFD > behavior as well - not just this extension. > > As regards that particular case, we’ve discussed it above — your point > about it being a hint for implementors is persuasive, but it moves it out > of RFC 2119 territory altogether. > KT3> Ack > > > If you still feel uncertain about this, we can dig into it case-by-case > and discuss each occurrence, but possibly the context above will help? > (Note that I am not the only reviewer who’s likely to be triggered by > unqualified use of SHOULD…) > > > > KT2> The first 3 SHOULD are related to base OSPF BFD interactions. For > the 4th one, I'll add text to clarify (i.e., the reason is to avoid > disrupting routing). An explanation is already provided for the 5th one. > The final 6th one is related to authentication which is a SHOULD in the > base protocol. Please let me know if I've missed anything. > > OK, that works. > KT3> Thanks. > > > > An implementation MUST NOT wait for BFD session establishment in > Init > > > state unless OSPF BFD strict-mode is enabled on the interface and > the > > > @@ -268,6 +311,12 @@ > > > BFD sessions. Disabling BFD would result in the BFD session being > > > brought down due to Admin reason [RFC5882] and hence would not > bring > > > down the OSPF adjacency. > > > + > > > +jgs: Regarding the last sentence above, suppose the router is > configured > > > +as you permit in Section 6, such that strict mode is required in order > > > +to establish an adjacency. Would it then be appropriate to bring > > > +down the adjacency if the B-bit is cleared? If the B-bit is cleared > and > > > +the BFD session moves to admin down? > > > > > > KT> No. The OSPF adjacency would not be brought down. The checking for > B-bit and BFD session UP dependency check is only while in the INIT state. > > > > I’m going to defer this until we settle on what exactly the “local > configuration option” text is trying to say (the discussion at the > beginning of this note). > > > > KT2> Ack > > That having been settled… > > … if my implementation has a knob to say “don’t let the adjacency come up > until BFD comes up”, it seems fairly perverse if the BFD session is > subsequently allowed to go away without having that affect the session. > Seems like it violates the principle of least astonishment. I would think > the expectation of the operator would be “I set this knob, so I know that > if OSPF is up, BFD must be up”. But no, it turns out there is an asterisk > and that it only means “if OSPF is up, BFD must have been up at some point > in the past”. KT3> One can look at this differently as well. There are config changes that get applied on the next reload of the system, bring-up of a link/session, etc. This is to avoid disruption of ongoing operations. We have past examples of this. > I’m somehow reminded of the old Roadrunner cartoon where the coyote steps > out into thin air and as long as he doesn’t look down, he doesn’t fall. > > I do acknowledge that the spec is cleaner this way, because all you have > to do is modify the Init state description… and Init doesn’t affect things > once you’re in Full. But I question whether the cost of making the spec > cleaner, is making a compliant implementation’s behavior worse from the > operator’s point of view. > KT3> While keeping the spec clean was one consideration, it was not the main one. We need to look at the objective of this extension which is to avoid adjacency flaps on noisy links due to intermittent packet losses due to BFD flaps or bring-up issues. If an adjacency is already UP, there are two possibilities - it is operating well or it may be in trouble. We are now looking at the scenario when the operator is turning ON this feature and we don't know the operator's intent. What the spec is recommending (hence the SHOULD NOT) is to not bring the adjacency into INIT state to enter the BFD wait. If there is a problem then the BFD session would go down and result in an adjacency flap anyway - so we are talking only about the case where the BFD session cannot be established in the first place. The operator has the choice to bring down the adjacency immediately if they are really dealing with a known/suspected link issue. Note that the spec does not have a time limit on how long to wait for the BFD session to come up - this would be required for the behavior that you were looking for. We've updated the text slightly to clarify. Please let us know your feedback. Thanks, Ketan > > —John > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
