Thanks John.
On Sat, Sep 3, 2022 at 11:31 PM John Scudder <j...@juniper.net> wrote: > Thanks, Ketan. Enough tweaking :-), I’ve requested it move to IETF last > call. > > —John > > > On Sep 3, 2022, at 5:03 AM, Ketan Talaulikar <ketant.i...@gmail.com> > 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 <j...@juniper.net> wrote: > > Hi Ketan, > > > > My comments in line below. > > > > > On Sep 2, 2022, at 6:37 AM, Ketan Talaulikar <ketant.i...@gmail.com> > wrote: > > > > > > Hi John, > > > > > > Please check inline below for responses with KT2 > > > > > > > > > On Thu, Sep 1, 2022 at 10:42 PM John Scudder <j...@juniper.net> 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
