On Mon, Jan 13, 2025 at 6:53 PM Jeffrey Haas <[email protected]> wrote:
> Zahed, > > On Mon, Jan 13, 2025 at 02:05:19PM +0100, Zaheduzzaman Sarker wrote: > > On Wed, Jan 8, 2025 at 3:14 PM Jeffrey Haas <[email protected]> wrote: > > > > > On Jan 8, 2025, at 7:39 AM, Zaheduzzaman Sarker via Datatracker < > > > [email protected]> wrote: > > > The specification intentionally does not check the payload in the > padding. > > > > But this specification is enforcing it with normative text. > > No, Zahed. It enforces that the contents are set to a value. It currently > says nothing about checking that value. That is where I would like to get some guidance, even if that means don't check. Now, it is kind of open for interpretation and can cause confusion. > Only the procedures from RFC 5880 > apply. > > If you believe otherwise in the current text, please point out the section > you think applies to receive procedures. > > A large packet doesn't permit fragmentation that can't be transmitted end > to > end due to MTU issues is dropped. That's sufficient for BFD's purposes. > > > > Implementation experience has showed that it interferes with line rate > > > behaviors. The small CPUs attached the line cards basically end up > burning > > > precious resources doing memcmp. > > > > > > The Working Group and authors did discuss payloads that were non-zero > and > > > validated. For example, test patterns. > > > > > > The motivation to specify zeroed contents was: > > > - Useful for security to avoid the usual "I've leaked stuff in my > memory > > > onto the wire and it has security impact". > > > - Implementations effectively only need to buffer the very small BFD > PDU > > > as payload and can efficiently generate or drop the rest of the > contents. > > > The implementation thus can validate the usual IP stack checksums > without > > > having to keep the very large buffers around in line card "application" > > > space. > > > > > > > It would be useful to write these reasons in the specification as there > are > > security and computation complexities associated with it. > > As covered in prior threads, I'm happy to add the detail that zeroes are > being written to avoid having random data exposed in the PDU. Similarly, > I'm happy to add text clarifying the contents are not checked - effectively > John's suggestion. > Good. > > I object to embedding the implementation detail as it's relevant to some > environments on some platforms today. Doing otherwise is akin to writing > "640KB of memory is enough for anyone!" > No, I don't think we need such details here. > > > If the real intention is that the implementation just reads the BFD > payload > > and there is good motivation for putting Zeros then I would suggest > writing > > - the BFD endpoints/implementation MUST discard any non-zero values. > @John > > Scudder <[email protected]> had a better suggestion during the telechat. > > As noted, I'll use some form of the above. > Great!.. > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > > ---------------------------------------------------------------------- > > > > > > > > One more comment - if the intention is to have this bfd in large > packets > > > to > > > > discover the path MTU, why don't we say so in the abstract of this > > > document. > > > > > > Discover is never mentioned in the document - that is not the purpose. > > > BFD state machinery is inappropriate for that. > > > > > > > Good that you said BFD state machinery is inappropriate here. However, > > essentially we are trying to learn the PATH MTU here in a multihop BFD, > > aren't we? > > This is a binary test: The Path MTU is sufficient for the application. > From > the text in 4.4: > > "BFD for Large Packets only ensures that the minimally acceptable MTU for > the session is able to be used." > > "Learning" the Path MTU would involve probing the MTU without taking the > BFD > session down. We did discuss this use case for diganostic purposes, but > the > core value of this feature is that the end to end path is sufficient for > the > application protected by BFD. If the Path MTU is big enough, good. If it's > not big enough, bad. > > For BFD to generally do any sort of probe, the intention would have to be > generating packets that are expected to drop. Dropped packets beyond the > configured "Detect Mult" value in RFC 5880 cause the session to drop. > Session drops are signaled to one or more BFD clients and are used to drop > slower protocols from their established states. > > -- Jeff >
