Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

[Robert Raszuk <[e-mail]>]

> I have stated that “IF” additional functionality is required from BFD

No one says so, It would be not realistic to require for BFD to come up in
a hidden mode, operate for timer X then when timer X expires signal that to
clients. And this is precisely what you are suggesting as a push back.

It is client thing to delay their action according to the operational
needs.

Many thx,
R.

On Mon, Jan 31, 2022 at 8:48 PM Les Ginsberg (ginsberg) <[e-mail]>
wrote:

> Jeff –
>
>
>
> I appreciate that you have been pulled into reading a very lengthy thread
> and then commenting  on it – which is a difficult/time consuming  thing to
> do accurately.
>
> And I certainly welcome your input and agree with your input.
>
>
>
> I have not asked for BFD extensions.
>
> I have stated that “IF” additional functionality is required from BFD that
> the proper place to discuss that is in the BFD WG – and such discussions
> are definitely not in scope of this draft.
>
>
>
> The main content of this lengthy thread is Robert asking for additional
> specification in this draft and other folks (myself, Albert, Ketan) saying
> it doesn’t belong in this draft. Which is why I agree with everything you
> say below except for your perception that you are agreeing with Robert. You
> are actually agreeing with myself, Albert, Ketan. 😊
>
>
>
> Thanx for your participation.
>
>
>
>     Les
>
>
>
> *From:* Jeffrey Haas <[e-mail]>
> *Sent:* Monday, January 31, 2022 11:28 AM
> *To:* Robert Raszuk <[e-mail]>
> *Cc:* Ketan Talaulikar <[e-mail]>; Les Ginsberg (ginsberg) <
> [e-mail]>; [e-mail]; Acee
> Lindem (acee) <[e-mail]>; Albert Fu <[e-mail]>; lsr <
> [e-mail]>
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> [Note that I read the LSR mailing list infrequently, but this thread was
> brought to my attention.]
>
>
>
> I wish to largely support Robert's point here.  BFD is not intended as a
> link quality protocol.  It's a very simple hello protocol that can operate
> quite quickly and provide simple edge transition events of Up and Down.
>
>
>
> There has been work in the BFD Working Group over the years to attempt to
> bring more of "link quality" behaviors to the protocol.  One, of interest
> to this thread, is the BFD for Large Packets work, which can support MTU
> probes as part of BFD operation.
>
>
>
> draft-ietf-bfd-stability discusses leveraging BFD internal state to help
> look at link instability issues as BFD sees them.
>
>
>
> And, of course, Greg Mirsky had several times he wanted to get BFD to do
> more active behaviors.  He was encouraged to leverage the BFD machinery in
> his own non-BFD draft if he found it helpful.  I suspect he'll respond to
> this thread with comments on his thinking here.
>
>
>
> That said, the BFD strict work is about removing control-plane protocol
> ambiguity with regards to how it uses BFD and how the state machines
> interact with each other.  I think that work has been reasonably done.
>
>
>
> The thing that BFD isn't about in such contexts is being more than a
> simple proxy for the link being of bad enough quality for BFD to go down
> taking the client protocols down with it.  It's important for those client
> protocols and the operators to set the timers and Detection Multiplier
> (number of lost packets) to speeds they think support their needs.  If you
> have a noisy link that can drop several packets in succession and that's
> what you want to be your trigger, BFD is your protocol.  If you want it to
> take an apparently continuous loss over most of a second, BFD can do that
> too if you tune your timers appropriately.
>
>
>
> But, as you say Robert, it's not intended to be a general IPPM style
> tool.  I don't believe the BFD strict drafts should try to treat BFD as if
> it is one.
>
>
>
> -- Jeff
>
>
>
>
>
>
>
> On Jan 31, 2022, at 5:31 AM, Robert Raszuk <[e-mail]> wrote:
>
>
>
> HI Ketan & Les,
>
>
>
> To finish this topic I would like to observe that IMHO you have it quite
> backwords.
>
>
>
> *Comment #1*
>
>
>
> The tone of your expressions is trying to illustrate that there can be
> many clients for given link probing tool (here BFD). In reality the
> situation is vastly different. There is usually one link state IGP running
> on the node and given set of probing protocols are associated with it.
> Moreover, the world does not end on BFD. BFD is just one possible tool, but
> more and more path probing tools are emerging or are already deployed.
> Asking for each of them to introduce into their state machine a new
> behaviour to delay reporting UP state on a per client basis is nothing else
> then just pushing the problem aways and not caring for the cost associated
> with it.
>
>
>
> *Comment #2 *
>
>
>
> BFD is a great tool to tell you if the end to end path is UP or DOWN. It
> was not designed to give you any characteristics or metrics for the path
> quality.
>
>
>
> So all assertions of that notion in your draft are simply wrong. While
> sure there are proposals to extend BFD probe packets with arbitrary large
> payload to tell you if at some packet size you can still reach the other
> end they are still nothing close to measure any form of link performance or
> detect "A degraded or poor quality link"
>
>
>
> Thx a lot,
>
> R.
>
>
>
> On Mon, Jan 31, 2022 at 5:48 AM Ketan Talaulikar <[e-mail]>
> wrote:
>
> Hi Les,
>
>
>
> I agree with you that mechanisms like dampening and hold-down are best
> achieved at the lowest levels (in this case in the monitoring protocol like
> BFD) instead of in each routing protocol on the top.
>
>
>
> Now whether this means we include/support the signaling of the parameters
> for these mechanisms in BFD or whether they are achieved by provisioning
> (as done currently by some implementations) is best discussed in the BFD WG.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Mon, Jan 31, 2022 at 1:08 AM Les Ginsberg (ginsberg) <
> [e-mail]> wrote:
>
> Robert –
>
>
>
> Here is what you said (emphasis added):
>
>
>
> <snip>
>
> But the timer I am suggesting is not related to BFD operation, but to OSPF
> (and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about *allowing
> BFD for more testing (with various parameters (for example increasing test
> packet size in some discrete steps)* before OSPF is happy to bring the
> adj. up.
>
> <end snip>
>
>
>
> Point #1: If you want BFD to do more testing (such as MTU testing) then
> clearly you need extensions to BFD (such as
> https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/ )
>
>
>
> Point #2: The existing timers (as Ketan points out are mentioned in
> Section 5) are applied today at the OSPF level precisely because OSPF does
> not currently have strict-mode operation. So in a flapping scenario you
> could see the following behavior:
>
>
>
> a)BFD goes down
>
> b)OSPF goes down in response to BFD
>
> c)OSPF comes back up
>
> d)Link is still unstable – so traffic is being dropped some of the time –
> but perhaps OSPF adjacency stays up (i.e., OSPF hellos get through often
> enough to keep the OSPF adjacency up)
>
>
>
> So some implementations have chosen to insert a delay following “b”. This
> doesn’t guarantee stability, but hopefully makes it less likely. And
> because OSPF today does NOT wait for BFD to come up, the delay has to be
> implemented at the OSPF level.
>
>
>
> Once you have strict mode support, the sequence becomes:
>
>
>
> a)BFD goes down
>
> b)OSPF goes down in response to BFD
>
> c)BFD comes back up
>
> d)OSPF comes back up
>
>
>
> Now, if the concern is that BFD comes back up while the link is still
> unstable, the way to address that is to put a delay either before BFD
> attempts to bring up a new session or a delay after achieving UP state
> before it signals UP to its clients – such as OSPF. This is a better
> solution because all BFD clients benefit from this. Ad if the link is still
> unstable, it is more likely that the BFD session will go down during the
> delay period than it would be for OSPF because the BFD timers are
> significantly more aggressive.
>
> (BTW, this behavior can be done w/o a BFD protocol extension – it is
> purely an implementation choice.)
>
>
>
> From a design perspective, dampening is always best done at the lowest
> layer possible. In most cases, interface layer dampening is best. If that
> is not reliable for some reason, then move one layer up – not two layers up.
>
>
>
>    Les
>
>
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Sunday, January 30, 2022 10:05 AM
> *To:* Ketan Talaulikar <[e-mail]>
> *Cc:* Les Ginsberg (ginsberg) <[e-mail]>; Acee Lindem (acee) <
> [e-mail]>; [e-mail]; Albert Fu <
> [e-mail]>; lsr <[e-mail]>
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Ketan,
>
>
>
> I would like to point out that the draft discusses the BFD "dampening" or
> "hold-down" mechanism in Sec 5. We are aware of BFD implementations that
> include such mechanisms in a protocol-agnostic manner.
>
>
>
> BFD dampening or hold-time are completely orthogonal to my point. Both
> have nothing to do with it.
>
>
>
> Those timers only fire when BFD goes down. In my example BFD does not go
> down. But we want to bring up the client adj. only after X ms/sec/min etc
> ...of normal BFD operation if no failure is detected during that timer.
>
>
>
> This draft indicates that OSPF adjacency will "advance" in the neighbor
> FSM only after BFD reports UP.
>
>
>
> And that is exactly too soon. In fact if you do that today without waiting
> some time (if you retire the current OSPF timer) you will not help at all
> in the case you are trying to address.
>
>
>
> Reason being that perhaps 200 ms after BFD UP it will go down, but OSPF
> adj. will get already established. It is really pretty simple.
>
>
>
> Thx,
>
> Robert.
>
>
>
> PS. And yes I think ISIS should also get fixed in that respect.
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
>
>