Hey Albert, Ok now we are in sync as far as what is the topic.
I think such a delay is very useful and completely in the spirit of OSPF or ISIS strict-mode operation. So I do recommend that the draft should discuss it. The default can be 0 if you think that is the proper value. But the operational section of that draft IMO is exactly the place where such paragraph should be placed. Maybe I would not be so persistent in this little thread if Les wouldn't indicate that current timer will be removed (current timer acting as an artificial delay and being much longer then time needed for BFD to come UP). Author's choice. My mission is accomplished here for the WG mailing list records :) Cheers, Robert. On Mon, Jan 31, 2022 at 9:04 PM Albert Fu (BLOOMBERG/ 120 PARK) < af...@bloomberg.net> wrote: > Hi Robert, > > As mentioned in my previous email, I feel it is better not to specify in > the draft the timer for when OSPF should come up after BFD is up. > > The current implementation is for OSPF to come up as soon as BFD is up. A > user can change this behaviour via configuration, to delay when OSPF can > come up after BFD is up. Different customers may have different delay > requirements, and there may also be platform dependent limitation. > > Thanks > > Albert > > From: rob...@raszuk.net At: 01/31/22 14:52:43 UTC-5:00 > To: Albert Fu (BLOOMBERG/ 120 PARK ) <af...@bloomberg.net> > Cc: a...@cisco.com, draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org, > ginsb...@cisco.com, ketant.i...@gmail.com, lsr@ietf.org > Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" > - draft-ietf-lsr-ospf-bfd-strict-mode-04 > > Hi Albert, > > On Mon, Jan 31, 2022 at 8:38 PM Albert Fu (BLOOMBERG/ 120 PARK) < > af...@bloomberg.net> wrote: > >> Hi Robert, >> >> Do you mean we should make it mandatory in the draft to stipulate a delay >> time between when OSPF should wait for BFD to come up? >> > > No. > > The timer is for OSPF to bring adj up only after X timer expires from the > moment BFD session came up and stayed up (never went down). > > No changes to BFD needed at all. > > Trivial to implement on the client side and very useful operationally. > > Thx, > Robert > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
