Re: [GROW] Support for Enterprise-specific TLVs in BMP

[Jeffrey Haas <[e-mail]>]

Paolo,

On Mon, Oct 26, 2020 at 02:15:45PM +0100, Paolo Lucente wrote:
> I would like to get some feedback / encourage some conversation
> around the topic of supporting Enterprise-specific TLVs in BMP (or
> draft-lucente-grow-bmp-tlv-ebit-01) so to see whether it is
> appropriate to ask the Chairs for WG adoption.
[...]
> Motivation: i would like to supplement what is already written in
> the Introduction section of the draft "Vendors need the ability to
> define proprietary Information Elements, because, for example, they
> are delivering a pre-standards product, or the Information Element
> is in some way commercially sensitive.", in short prevent TLV code
> point squatting.
[...]
> Approach: reserving the first bit of a TLV type to flag whether what
> follows is a private or a standard TLV and, if private, provide the
> PEN in the first 4-bytes of the TLV value is a simple and successful
> mechanism to achieve the motivation that was merely copied from
> IPFIX, a case of nothing new under the Sun.

Firstly, I'm supportive of adding enterprise specifc information into the
BMP protocol.  I'm also supportive of using PENs to create the necessary
code space.

I will, however, offer a bit of repetitive advice I'd given at one of the
last in-person GROW sessions we'd had: This information will in many cases
degrade the packing of information in BMP route monitoring messages.  This
will have specific impacts on the memory and CPU used in an implementation.

That said, as long as the features are optional - if it hurts, don't do
that.  But I'd offer advice that whatever document this goes into contains
an Operational Considerations section that notes the impact. A BMP
implementation should be able to disable such features to mitigate the
impact on the receiver.

With regard to the use of this to prevent squatting, I'll offer two prior
inputs I've given IETF on such things:

https://tools.ietf.org/html/draft-haas-idr-extended-experimental-01
https://www.ietf.org/proceedings/97/slides/slides-97-idr-code-point-management-02

The two salient points here are:
- If the thing should be standardized, don't stick it in your enterprise
  space.  This means that a FCFS registry should be available for the stuff.
- Stability of a feature is the awkward, even if you're using FCFS.  If you
  choose an encoding, changing it has impact.  If you don't want to move the
  code point, at least consider a versioning field.

-- Jeff