Hi Chris, > but I don't see how it is OSPF specific
I have brought this in the context of the waif-for-bfd OSPF proposal. This is the first time LSR WG is facing such a requirement so IMO it would be proper to at least discuss this in the draft. And if so all I merely suggested was to mention this in the draft and make sure readers understand what this draft should wait for to trigger OSPF adj, to come up. But as retrospect of this 100 mail thread I am drawing a conclusion that maybe I am asking for too much perfection in the spec. Maybe not many folks will even notice this. They will just spend hours on troubleshooting why packets got dropped and will blame telco for providing such a crappy circuit physical or an emulated one :) And you have seen a clear recommendation from Jeff that such change or delay is not likely going to happen on the BFD side and it is up to the client to change its FSM in that respect. I do not see why this should not be at least described in the draft. Anyhow enough time spent on this ... Many thx, Robert On Sun, Feb 6, 2022 at 11:29 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. > > 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 > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
