Hi Jeff,
Ack & yet again all agreed. I will add such a section to the draft.
Paolo
On 8/12/21 13:22, Jeffrey Haas wrote:
On Wed, Dec 08, 2021 at 11:57:08AM -0500, Jeffrey Haas wrote:
A final meta comment that probably belongs in an Error Handling section:
For a route monitoring message, the new TLVs follow an encoded BGP Update
message. BGP isn't a rigorous TLV protocol, as we know. And certainly, a
BMP implementation MUST know how to decode a BGP PDU in order to do its
work.
This also knocked loose an interesting issue that we don't have to worry
about for the short term but is applicable here:
RFC 8654 provides for an extended message length for BGP.
In pathological circumstances, an implementation with extended message
support being encapsulated in a BMP PDU might not be able to fit. This is
already a theoretical problem without the optional TLVs, but might become
more of one with the TLVs.
It might be worth one sentence of mention in Error Handling if such a
section is created. "RFC 8654 permits BGP Updates and other messages to
grow to a length of 65535 octets. This may cause a BMP PDU that attempts to
encapsulate such long messages to overflow."
-- Jeff
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
