Hi, Thanks for the quick response.
Please see in-line. Regards, Dan On Fri, Dec 6, 2024 at 5:59 PM Jeffrey Haas <jh...@pfrc.org> wrote: > 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.. > Maybe a short text would clarify. It was not obvious for me, but it may be my lack of familiarity. > > > 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. > 'use a bfd.PaddedPduSize appropriate' sounds bad grammar to me. Do you mean 'use an appropriate value of bfd.PaddedPduSize'? > > 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. > If it's useful, why not include this in the Introduction Section? > > -- Jeff >
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
