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. 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. > ---------------------------------------------------------------------- > 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. -- Jeff
