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

[[e-mail]]

Hi Paolo and Jeffrey,

First of all I am in support of Enterprise-specific TLVs in BMP. It's important to be equal to other data-collection protocol such as IPFIX and YANG push.

Jeffrey slide on "Code Point Management" describe perfectly the problem space and need this draft addresses.

I like to bring some additional context in this discussion which hopefully help to clarify the need and reason for enterprise registry. About the different kind of registry types.

As done with bmp-loc-rib
https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml

code points can be assigned temporarily as described in section 2 of RFC 7120
https://tools.ietf.org/html/rfc7120#section-2

In order to be eligible, the draft needs to be adopted at a working group and in a stable condition. That means the applicability of ebit is in early development where interop ability among vendors is tested and shipped to network operators to be tested there as well.  I suggest to clearly described this in the ebit draft and maybe consider also RFC 8126 section 4.1 which describes the differences between enterprise and experimental registry. 
https://tools.ietf.org/html/rfc8126#section-4.1

Best wishes
Thomas

-----Original Message-----
From: GROW <[e-mail]> On Behalf Of Paolo Lucente
Sent: Monday, October 26, 2020 2:16 PM
To: [e-mail]
Subject: [GROW] Support for Enterprise-specific TLVs in BMP


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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrow&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C8e59dfcfe10049770cdc08d879b1524b%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637393149780032342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vGqvOnCFbXFWaaccQplg66o1HF%2FE8rKRGEeZ0MWXSQQ%3D&amp;reserved=0