Robert Raszuk <[email protected]> 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. 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. 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
