Hi Chris
On Sun, Feb 6, 2022 at 5:30 PM Christian Hopps <cho...@chopps.org> wrote:
>
> Robert Raszuk <rob...@raszuk.net> writes:
>
> > Hi Les,
> >
> >
> >
> > There is nothing in RFC 5880 (nor in, what I consider to be even
> > more relevant, RFC 5882) that requires a BFD implementation to
> > signal UP state to a BFD client within a specific time following
> > transition of the BFD state machine to UP . An implementation is
> > free to introduce a delay (as you suggest) before such signaling.
> >
> >
> > My reading of section 6.2 of RFC5880 clearly indicates that BFD is
> > signalling UP state when BFD session has been established without any
> > delay.
> >
> > I am not sure if BFD implementation is free to introduce any delay
> > there yet still to claim full compliance to RFC5880 (even if
> > technically it would make sense to have such delay).
>
> If you publish an RFC that adds to or extends the BFD "UP" concept then it
> can simply "updates 5880", if required.
Gyan> I think the difficulty maybe in updating RFC 5882 is what Les
pointed out in section 3 signaling between BFD and local client is an
implementation issue out of scope. Reading section 3.1 session hysteresis
below maybe reasons why the signaling is out of scope below due to process
restart.
A BFD session can be tightly coupled to its client applications; for
example, any transition out of the Up state could cause signaling to
the clients to take failure action. However, in some cases, this may
not always be the best course of action.
“Implementors may choose to hide rapid Up/Down/Up transitions of the
BFD session from its clients. This is useful in order to support
process restarts without necessitating complex protocol mechanisms,
for example.
As such, a system MAY choose not to notify clients if a BFD session
transitions from Up to Down state, and returns to Up state, if it
does so within a reasonable period of time (the length of which is
outside the scope of this specification). If the BFD session does
not return to Up state within that time frame, the clients SHOULD be
notified that a session failure has occurred”
I think the only option is dampening delay.
>
> In any case, the delay concept you are talking about is not without merit,
> but I don't see how it is OSPF specific; it would also benefit IS-IS and
> other BFD clients as well, right? To me that says do this in BFD so
> everyone can benefit.
Gyan> Agreed the delay would benefit OSPF, ISIS and BGP.
>
>
> Thanks,
> Chris.
> [as wg member]
>
> >
> > Quote:
> >
> >
> > Up state means that the BFD session has successfully been
> > established, and implies that connectivity between the systems is
> > working. The session will remain in the Up state until either
> > connectivity fails or the session is taken down administratively.
> >
> >
> > Rgs,
> > Robert.
> >
> >
> >
> > _______________________________________________
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
--
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>*
*M 301 502-1347*
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
