Re: [GROW] Support for Enterprise-specific TLVs in BMP
Hi Thomas, Thanks very much for your support. Thanks also for letting emerge the interop point, very valid: in fact one may be inclined to think - wrongly, of course - that since there is no two devices directly communicating with each other then interop is not a point. Instead it is still a big thing since devices exporting telemetry should interop with the (same) collection infrastructure the same way. Finally thanks for the suggestions for the text, we will make sure to incorporate them. Paolo On 03/11/2020 12:58, thomas.g...@swisscom.com wrote: 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 On Behalf Of Paolo Lucente Sent: Monday, October 26, 2020 2:16 PM To: grow@ietf.org 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 GROW@ietf.org https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=04%7C01%7CThomas.Graf%40swisscom.com%7C8e59dfcfe10049770cdc08d879b1524b%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637393149780032342%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vGqvOnCFbXFWaaccQplg66o1HF%2FE8rKRGEeZ0MWXSQQ%3Dreserved=0 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Support for Enterprise-specific TLVs in BMP
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 On 27/10/2020 20:50, Jeffrey Haas wrote: 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Support for Enterprise-specific TLVs in BMP
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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Support for Enterprise-specific TLVs in BMP
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 Sent: Monday, October 26, 2020 9:23 AM To: Jakob Heitz (jheitz) Cc: grow@ietf.org 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 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 >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
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 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Support for Enterprise-specific TLVs in BMP
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 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 > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
