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. [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. > > 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. > 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. > 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. > > 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”. 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. —John _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
