Hi Jeff, Apologies for a bit late response.
On Wed, Jan 8, 2025 at 3:14 PM Jeffrey Haas <[email protected]> wrote: > Zahed, > > On Jan 8, 2025, at 7:39 AM, Zaheduzzaman Sarker via Datatracker < > [email protected]> wrote: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thanks for working on this specification. Thanks to Brian Trammell for > his > > TSVART review. > > > > As this specification says - "The contents of this additional payload > MUST be > > zero" for bfd.PaddedPduSize. I would like to discuss the consequences of > not > > having all zeros in the additional payload - shall this still be treated > as > > valid bfd payload and parsed but the MTU discovery would fail or shall > it raise > > some protocol violation error? I didn't find any error handling in this > > specification. > > The specification intentionally does not check the payload in the padding. > But this specification is enforcing it with normative text. > > 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. 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. > > > ---------------------------------------------------------------------- > > 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? //Zahed > > -- Jeff > >
