Hi,
Thanks for the quick response.
Please see in-line.
Regards,
Dan
On Fri, Dec 6, 2024 at 5:59 PM Jeffrey Haas <jhaas@xxxxxxxx> 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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
