[Idr] Opsdir last call review of draft-ietf-idr-bgp-sendholdtimer-13

[Victor Kuarsingh via Datatracker <[e-mail]>]

Reviewer: Victor Kuarsingh
Review result: Ready

Reviewer: Victor Kuarsingh
Review Result: Ready

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

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.

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).

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).

Thanks,

Victor K