[GROW] Support for Enterprise-specific TLVs in BMP

Paolo Lucente <paolo@ntt.net> Mon, 26 October 2020 13:15 UTC

Return-Path: <paolo@ntt.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740AB3A0ADF for <grow@ietfa.amsl.com>; Mon, 26 Oct 2020 06:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGl_eqby2C7W for <grow@ietfa.amsl.com>; Mon, 26 Oct 2020 06:15:49 -0700 (PDT)
Received: from mail4.sttlwa01.us.to.gin.ntt.net (mail4.sttlwa01.us.to.gin.ntt.net [IPv6:2001:418:3ff:110::40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395823A0121 for <grow@ietf.org>; Mon, 26 Oct 2020 06:15:49 -0700 (PDT)
Received: from Paolos-MacBook-Pro.local (unknown [IPv6:2001:418:1401:10::1021]) by mail4.sttlwa01.us.to.gin.ntt.net (Postfix) with ESMTPSA id 8BDAE22014B for <grow@ietf.org>; Mon, 26 Oct 2020 13:15:47 +0000 (UTC)
To: grow@ietf.org
From: Paolo Lucente <paolo@ntt.net>
Message-ID: <366e142a-6235-2d60-ad64-00a1da34133a@ntt.net>
Date: Mon, 26 Oct 2020 14:15:45 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/U90MeEj0vc7iKCp3ZBvXfebKCEM>
Subject: [GROW] Support for Enterprise-specific TLVs in BMP
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2020 13:15:50 -0000

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