Hi Jeff,
On Thursday, May 23, 2024, 01:50:45 PM EDT, Jeffrey Haas <jh...@pfrc.org>
wrote:
Reshad,
On May 23, 2024, at 12:47 PM, Reshad Rahman <res...@yahoo.com> wrote:
On Wednesday, May 22, 2024, 06:21:50 PM EDT, Jeffrey Haas <jh...@pfrc.org>
wrote: 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.
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.
The headache here is we have conflicting priorities.
If the implementation picks the large values, as we desire here, and fails to
come up, then no clients get what they want. Perhaps that's a win, perhaps it
isn't.
If the implementation for some strange reason only brings up a session with a
smaller value, it works, then the implementation probably also shouldn't report
BFD Up to the client that needs the larger value. We don't regulate the API
behaviors for BFD sessions in our RFCs, so this is out of scope. But it's what
should make sense in this circumstance.
<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.
I'm fine moving this to SHOULD if that addresses the point. MUST is
inappropriate.
<RR2> SHOULD addresses the point, good with me.
<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).
Yeah, we can do that.
Please check text here:https://github.com/jhaas-pfrc/bfd-large-packets/pull/4
<RR2>Good with me, I'll approve the PR.
Regards,Reshad.
| <t> |
|
| Further, this YANG module augments the YANG modules for single-hop, |
|
| multi-hop, LAG and MPLS to add the "padded-pdu-size" |
|
| parameter to those session types to configure Large BFD packets. |
|
| </t> |
|
|
|
|
| <t> |
|
| Finally, similar to the grouping "client-cfg-parms" defined in |
|
| <xref section="2.1" target="RFC9314"/>, this YANG module defines a grouping
|
|
| "bfd-large-common" that may be utilized by BFD clients using |
|
| "client-cfg-params" to uniformly add support for the feature |
|
| defined in this RFC. |
|
</t>
-- Jeff
