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