Thanks, Ketan. Enough tweaking :-), I’ve requested it move to IETF last call.
—John > On Sep 3, 2022, at 5:03 AM, Ketan Talaulikar <[email protected]> wrote: > > > [External Email. Be cautious of content] > > > 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
