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

From: Paolo Lucente <[email-masked]>
Date: Mon, 26 Oct 2020 14:15:45 +0100

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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 26 Oct 2020 15:43:56 +0000

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 <[email-masked]> 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.
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Paolo Lucente <[email-masked]>
Date: Mon, 26 Oct 2020 17:22:38 +0100

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

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 27 Oct 2020 17:55:46 +0000

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 <[email-masked]> 
Sent: Monday, October 26, 2020 9:23 AM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [GROW] Support for Enterprise-specific TLVs in BMP

Hi Jakob,

Paolo

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 27 Oct 2020 15:50:43 -0400

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.
[...]
> 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

---

From: Paolo Lucente <[email-masked]>
Date: Wed, 28 Oct 2020 18:21:02 +0100

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