Carlos,
> On Sep 12, 2019, at 10:56 PM, Carlos Pignataro (cpignata) > <cpign...@cisco.com> wrote: > > Thanks for the reminder, Reshad. I support publication of this document, > short and useful. > > I only have one comment in regards to: > > It is also worthy of note that even if an implementation can function > with larger transport PDUs, that additional packet size may have > impact on BFD scaling. Such systems may support a lower transmission > interval (bfd.DesiredMinTxInterval) when operating in large packet > mode. This interval may depend on the size of the transport PDU. > > Instead of (or in addition to) a lower transmission interval, why not add > flexibility to not *have* to send large packets every packet, and instead > send every n paks or so? Such a thing could be done. A form of this sort of thing for "probing" was discussed in a prior draft I did with Xiao Min, but that was for Echo mode. But since this in BFD async mode, the timers are likely chosen for the worst case. So, if we have the usual Detect Multiplier of 3 and we can support sending a large packet every (e.g.) 25ms, and our implementation would normally send smaller packets every 10ms, we'd need to negotiate for some range between 10 and 25 knowing that the occasional large packet may itself perturb timing enough it might be counted as loss. So, such a thing could be done by an implementation, but timing is messy. If you want something a bit more occasional, I suggest a reasonable set of timers in async mode and more clever procedures in Echo mode, if you support that. -- Jeff
