Re: [GROW] On LC for draft-ietf-grow-bmp-tlv (ends December 1st 2021)

[Jeffrey Haas <[e-mail]>]

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