Dan, On Fri, Dec 06, 2024 at 01:21:33AM -0800, Dan Romascanu via Datatracker wrote: > This is a clear, well-written document. It is almost Ready with one minor issue > (which may be just a clarification issue) and a couple of editorial nits. > > Major issues: > > Minor issues: > > 1. Section 4.2 > > 'In the case multiple BFD clients desire to test the same BFD > endpoints using different bfd.PaddedPduSize parameters, > implementations SHOULD select the largest bfd.PaddedPduSize parameter > from the configured sessions. ' > > Why a SHOULD and not a MUST? Partially addressed the following thread: https://mailarchive.ietf.org/arch/msg/rtg-bfd/fwNNL6-KhPfbsJiaGQn0hbLomqo/ Tersely, the general use case and common implementation is that the most aggressive parameters are chosen for shared sessions when there is conflicting provisioning information. For base BFD timers, the most aggressive timers. For MTU, we similarly have a motivation for the largest MTU. Implementations that allow for such inconsistent provisioning are free to take several actions that make operational sense for the use case for their implementation. Examples might include: - If you start with a lower MTU, a second client requests a higher MTU but the session is already up, you may fail the client setup because of the previously established sesssion. I.e., choose stability. - Similarly, the implementation is free to just start using the higher MTU, which may cause the session to go Down and impacts the prior clients. - Even if nothing is Up, competing provisioning might let the session go to Up only for clients that can be accommodated. This is perhaps preferable for services/clients that do not share fate. In other words, the implementations know the use cases best for their deployments.. > Nits/editorial comments: > > 1. Section 4.2 > > 'Since the consideration is path MTU, BFD sessions using this feature > only need to use a bfd.PaddedPduSize appropriate to exercise the path > MTU for the desired application. [...] > This sentence seems to need some syntax clean-up. FWIW, this looks clear to me. Did you have a specific bit of rewrite you thought appropriate? If not, I suspect this is something the RFC editor will help with as part of the final editing process. > 2. I am not sure about Appendix A. If this is useful information, why not > include it in the body of the document. If not, eliminate it. It's information. It has been previously useful. It's been left in because a regular occurence during this work is "this existing padding feature exists and solves your problem". It doesn't, but it's related. While I'm fine deleting it, the fact that this has conversational point has recurred so many times leaves me inclined to at least nod towards the related functionality. -- Jeff -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
