Hi Jeff,
On Wednesday, May 22, 2024, 06:21:50 PM EDT, Jeffrey Haas <jh...@pfrc.org>
wrote:
Reshad,
On Wed, May 22, 2024 at 08:12:47PM +0000, Reshad Rahman wrote:
> - Section 4.2: do we need 2119 language for the following paragraph and
> should the should be a MUST?
> 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.
I'm of strongly mixed opinions about such a change.
We know this is common practice. That is supportive of at least moving it
to a SHOULD.
Implementations may have motivations to NOT cause this behavior to happen.
One such example would be mixed configuration such that the session cannot
come up with the largest padded pdu size. The reasons for such things could
be limitations about specific BFD clients in the implementation, or the
implementation's calculations for encapsulation among competing
parameter inputs are irreconcilable.<RR> But if the session comes up with the
smallest pdu size, it's misleading for the client expecting the biggest pdu
size.
In such cases, I'd expect either that the implementation can know this won't
work, and could flag a commit failure, or can't know, and simply doesn't
come up.
Thus, I feel uncomfortable about trying to be overly proscriptive on this
point.
<RR> Does this mean that you'd rather leave the text as is, or you're ok with
changing it to SHOULD. I think we should have normative language here. I can
live with a SHOULD although I suspect this may come up in AD/IESG review.
> - Section 5.2: the YANG module addresses the cases where the BFD sessions are
> configured directly in BFD. Should we have some text in there which mentions
> that configuring the pdu-size in BFD clients is out of scope and requires the
> clients to use the new grouping "bfd-large-common"? Do you know anyone e.g.
> in IDR who could do that for BGP :-)
Speaking with the bgp yang author hat, IDR's implementation maturity
requirements probably means that bfd-large isn't in-scope for the base yang
module for the moment. But anyone that'd want to do the augmentation to
support it could use it.
Since I expect that part of this is "can we use it properly":
https://github.com/mjethanandani/ietf-bgp-yang/tree/jhaas/bfd-large-example1
https://github.com/mjethanandani/ietf-bgp-yang/tree/jhaas/bfd-large-example2
Example1 simply installs it into the module and adds to the unit tests for
bfd-large configuration.
Example2 instead creates an augmentation module to add it in the future.
<RR> Ack. Can we add a sentence in section 5.1 that the data model addresses
pdu-size for centralized BFD configuration (as per section 2.1 of RFC9314).
Regards,Reshad.
-- Jeff
