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

[Paolo Lucente <[e-mail]>]

Hi Jeff,

Thanks very much for your support and your always valuable inputs. We 
will take all of them into account to improve the text of the document.

On the packing part, we are in-sync & indeed, yes: TLVs and E-bit 
support for TLVs are all optional. However, on the E-bit part, maybe not 
yet well-specified in the document and we should improve that, the 
"Stats Reports" message is itself a sequence of TLVs and we authors do 
see applicability of the E-bit there too. That is to say the E-bit 
applicability may transcend just the context of trailing TLVs in Route 
Monitoring messages: so perhaps the Operational Considerations section 
is more suited for the draft-ietf-grow-bmp-tlv-03 document.

Paolo

On 27/10/2020 20:50, Jeffrey Haas wrote:
> 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
>