Dear Victor, Thank you for your time to review this document. On Sun, Jul 14, 2024 at 10:44:04AM -0700, Victor Kuarsingh via Datatracker wrote: > Reviewer: Victor Kuarsingh > Review result: Ready > > Reviewer: Victor Kuarsingh > Review Result: Ready > > In short, the document and updated specifications to be applied to RFC4271 > (BGP-4) to introduce a ‘SendHoldTimer’ seems well targeted, well defined and > generally desirable as a feature. It was good to see multiple early > implementations across OpenBGPD, FRR, neo-bgp and BIRD as noted in Appendix A. Thanks, yes, running code is king :-) > I do have a non-blocking comment for the authors which should be taken > as a question of interest from an operational perspective. Under the > operational considerations section, I did see it mention > considerations such as sending a ‘send hold timer expired’ code > irrespective if the remote peer may be able to process (that’s > fine/good, what I would expect to see in such a section). Indeed it is not relevant whether the remote peer can 'process' the specific 'send hold timer expired' error notification code; the remote peer will know the connection was brought down (because it being a NOTIFICATION error code). The remote peer might not be able to pretty print the error number as a human readable string, but that is cosmetic in nature any way. We do not expect actually expect 'send hold timer expired' error code messages to ever make it across the wire, because the error condition that prompts this message means the local system was unable to send a message to the remote side. An error code was requested to IANA to make it easier for implementers to 'hook this into existing frameworks', and also to facilitate giving this sendholdtimer concept a place in MIBs & auxiliary management tooling. > However, what I did not see, and may be available as output from > testing on the early implementations and inter-op, is if there are > conditions where the invoking of the timer expired by the local peer > creates an unneeded operational event (e.g. for example the remote > peer may seem to no be processing updates, but may actually be). So, > in such a case, although this feature is generally desirable, there > may be a condition where it is not desirable or optimal. I don’t see > this is a big deal per se, but wondering if there were such > observations in test (either yes, but not significant or no, we did > not detect such a situation). We did not detect such a situation. However, we did notice that the absence of this concept can lead to surprising outcomes outlined in Section 2, which led to authoring this document in this first place :-) Kind regards, Job -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
