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

["Jakob Heitz (jheitz)" <[e-mail]>]

Paolo,

Thanks for letting me know about our squatting.
I was not aware of it.
I'm investigating now.

Regards,
Jakob.

-----Original Message-----
From: Paolo Lucente <[e-mail]> 
Sent: Monday, October 26, 2020 9:23 AM
To: Jakob Heitz (jheitz) <[e-mail]>
Cc: [e-mail]
Subject: Re: [GROW] Support for Enterprise-specific TLVs in BMP


Hi Jakob,

Surely - let me send you in a separate unicast email an actual example, 
taken from the Cisco bug tracker, of proprietary information elements 
squatted in public space.

That said, i rather wonder whether, from a protocol design perspective, 
the question you ask is the right one to raise.

Paolo

On 26/10/2020 16:43, Jakob Heitz (jheitz) wrote:
> What proprietary information elements are you thinking of?
> Maybe we can standardize them.
> 
> Regards,
> Jakob.
> 
> 
>> On Oct 26, 2020, at 6:16 AM, Paolo Lucente <[e-mail]> wrote:
>>
>> 
>> Dear GROW WG Rockstars,
>>
>> 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.
>>
>> Context: with the Loc-RIB (draft-ietf-grow-bmp-local-rib) and Adj-Rib-Out (RFC 8671) efforts we increased the possible vantage points where BGP can be monitored; then the goal of draft-ietf-grow-bmp-tlv is to make all BMP message types extensible with TLVs since by RFC 7854 only a subset of them do support TLVs.
>>
>> 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.
>>
>> Successful IETF-standardized telemetry protocols, ie. SNMP and IPFIX, do provision to extend standard data formats / models in order to pass enterprise-specific information - including the fact that not everything can be represented in a standard format, especially when data does touch upon internals (ie. states, structures, etc.) of an exporting device. This is also true, more recently, with the possibility to extend standard YANG models.
>>
>> In this context, in order to further foster adoption of the protocol, BMP should follow a similar path like the other telemetry protocols.
>>
>> 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.
>>
>> Current feedback: the only feedback that was received was last year in Singapore and it was along the lines of: we are at IETF and we should not open the backdoor for / facilitate insertion of non-standard elements.
>>
>> Thoughts? Opinions? Tomatoes?
>>
>> Paolo
>>
>> _______________________________________________
>> GROW mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/grow