idnits 2.17.1 draft-lucente-grow-bmp-tlv-ebit-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7854, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (17 January 2022) is 827 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-ietf-grow-bmp-peer-up-00 == Outdated reference: A later version (-14) exists of draft-ietf-grow-bmp-tlv-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Global Routing Operations P. Lucente 3 Internet-Draft NTT 4 Updates: 7854 (if approved) Y. Gu 5 Intended status: Standards Track Huawei 6 Expires: 21 July 2022 17 January 2022 8 Support for Enterprise-specific TLVs in the BGP Monitoring Protocol 9 draft-lucente-grow-bmp-tlv-ebit-02 11 Abstract 13 Message types defined by the BGP Monitoring Protocol (BMP) do 14 provision for data in TLV - Type, Length, Value - format, either in 15 the shape of optional TLVs at the end of a BMP message or Stats 16 Reports TLVs. However the space for Type value is unique and 17 governed by IANA. To allow the usage of vendor-specific TLVs, a 18 mechanism to define per-vendor Type values is required. In this 19 document we introduce an Enterprise Bit, or E-bit, for such purpose. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 21 July 2022. 38 Copyright Notice 40 Copyright (c) 2022 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. TLV encoding . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. IANA-registered TLV encoding . . . . . . . . . . . . . . 3 58 3.2. Enterprise-specific TLV encoding . . . . . . . . . . . . 3 59 3.3. TLV encoding remarks . . . . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 5. Operational Considerations . . . . . . . . . . . . . . . . . 4 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 7.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 The BGP Monitoring Protocol (BMP) is defined in RFC 7854 [RFC7854]. 72 Support for trailing TLV data is extended by TLV support for BMP 73 Route Monitoring and Peer Down Messages [I-D.ietf-grow-bmp-tlv]. 75 Vendors need the ability to define proprietary Information Elements, 76 because, for example, they are delivering a pre-standard product. 77 This This would align with Also for code point assignment to be 78 eligible, an IETF document needs to be adopted at a Working Group and 79 in a stable condition. In this context E-bit helps during early 80 development phases where inter-operability among vendors is tested 81 and shipped to network operators to be tested there as well. This 82 would align with This document re-defines the format of IANA- 83 registered TLVs in a backward compatible manner with respect to 84 previous documents and existing IANA allocations; it also defines the 85 format for newly introduced enterprise-specific TLVs. The concept of 86 an E-bit, or Enterprise Bit, is not new. For example, such mechanism 87 is defined in Section 4.1 of [RFC8126]. Section 4.2 of [RFC8126]. 88 Section 3.2 of [RFC7011] for a very similar purpose. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in BCP 95 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 96 appear in all capitals, as shown here. 98 3. TLV encoding 100 3.1. IANA-registered TLV encoding 102 Existing TLV encodings are defined in Section 4.4 of [RFC7854] 103 (Information TLVs), Section 4.8 of [RFC7854] (Stats Reports TLVs), 104 draft-ietf-grow-bmp-tlv [I-D.ietf-grow-bmp-tlv] and 105 draft-ietf-grow-bmp-peer-up [I-D.ietf-grow-bmp-peer-up] and are 106 updated as follows: 108 * 1 bit to flag an enterprise-specific TLV set to zero. The TLV 109 Type value must have been defined in IANA-BMP [IANA-BMP] 111 * 15 bits of TLV Type, 113 * 2 octets of TLV Value length, 115 * 0 or more octets of TLV Value. 117 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 |E| Type | Length (2 octets) | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Value (variable) | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 Figure 1 126 TLVs SHOULD be sorted by their code point. 128 3.2. Enterprise-specific TLV encoding 130 Enterprise-specific TLV encoding is defined as follows: 132 * 1 bit to flag an enterprise-specific TLV set to one 134 * 15 bits of TLV Type, 135 * 2 octets of IANA PEN plus TLV value length, 137 * 4 octets of IANA Private Enterprise Number IANA-PEN [IANA-PEN] 139 * 0 or more octets of TLV Value. 141 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 |E| Type | Length (2 octets) | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Enterprise number | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Value (variable) | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Figure 2 152 3.3. TLV encoding remarks 154 The encoding specified in this document applies to all existing BMP 155 Message Types and their namespaces defined in Future BMP Message 156 Types MUST make use of the TLV encoding defined in this document. 157 Multiple TLVs of the same type can be repeated as part of the same 158 message and it is left to the specific use-cases whether all, any, 159 the first or the last TLV should be considered. RFC 7854 [RFC7854], 160 TLV support for BMP Route Monitoring and Peer Down Messages 161 [I-D.ietf-grow-bmp-tlv] and BMP Peer Up Message Namespace 162 [I-D.ietf-grow-bmp-peer-up]. While the proposed encoding is not per- 163 se backward compatible, there is no existing IANA-allocated Type 164 value that makes use of the most significant bit (which is being used 165 in this document to define the E-bit). 167 4. Security Considerations 169 This document does not add any additional security considerations. 171 5. Operational Considerations 173 It is recommended that vendors making use of the Enterprise Bit 174 extension have a well-defined internal registry for privately 175 assigned code points that is also exposed to the public. 177 6. IANA Considerations 179 The TLV Type values used by BMP are managed by IANA as are the 180 Private Enterprise Numbers used by enterprise-specific Type values 181 IANA-PEN [IANA-PEN]. This document makes no changes to these 182 registries. 184 7. References 186 7.1. Normative References 188 [I-D.ietf-grow-bmp-peer-up] 189 Scudder, J., "BMP Peer Up Message Namespace", Work in 190 Progress, Internet-Draft, draft-ietf-grow-bmp-peer-up-00, 191 24 July 2019, . 194 [I-D.ietf-grow-bmp-tlv] 195 Lucente, P. and Y. Gu, "TLV support for BMP Route 196 Monitoring and Peer Down Messages", Work in Progress, 197 Internet-Draft, draft-ietf-grow-bmp-tlv-06, 25 October 198 2021, . 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, 203 DOI 10.17487/RFC2119, March 1997, 204 . 206 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 207 Monitoring Protocol (BMP)", RFC 7854, 208 DOI 10.17487/RFC7854, June 2016, 209 . 211 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 212 Writing an IANA Considerations Section in RFCs", BCP 26, 213 RFC 8126, DOI 10.17487/RFC8126, June 2017, 214 . 216 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 217 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 218 May 2017, . 220 7.2. Informative References 222 [IANA-BMP] IANA, "BGP Monitoring Protocol (BMP) Parameters", 2016, 223 . 226 [IANA-PEN] IANA, "Private Enterprise Numbers", 1982, 227 . 229 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 230 "Specification of the IP Flow Information Export (IPFIX) 231 Protocol for the Exchange of Flow Information", STD 77, 232 RFC 7011, DOI 10.17487/RFC7011, September 2013, 233 . 235 Acknowledgements 237 The authors would like to thank Thomas Graf, Jeff Haas and Pierre 238 Francois for their valuable input. 240 Authors' Addresses 242 Paolo Lucente 243 NTT 244 Siriusdreef 70-72 245 2132 Hoofddorp 246 Netherlands 248 Email: paolo@ntt.net 250 Yunan Gu 251 Huawei 252 Huawei Bld., No.156 Beiqing Rd. 253 Beijing 254 100095 255 China 257 Email: guyunan@huawei.com