idnits 2.17.1 draft-lucente-grow-bmp-tlv-ebit-00.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 (October 31, 2019) is 1638 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-01 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: May 3, 2020 October 31, 2019 8 Support for Enterprise-specific TLVs in the BGP Monitoring Protocol 9 draft-lucente-grow-bmp-tlv-ebit-00 11 Abstract 13 Message types defined by the BGP Monitoring Protocol (BMP) do 14 provision for optional trailing data in TLV - Type, Length, Value - 15 format; however the space for Type value is unique and governed by 16 IANA. To allow the usage of vendor-specific TLVs, a mechanism to 17 define per-vendor Type values is required. With this document we 18 want to introduce an Enterprise Bit, or E-bit, for such purpose. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 3, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 6.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 The BGP Monitoring Protocol (BMP) is defined in RFC 7854 [RFC7854]. 71 Support for trailing TLV data is extended by TLV support for BMP 72 Route Monitoring and Peer Down Messages [I-D.ietf-grow-bmp-tlv]. 74 Vendors need the ability to define proprietary Information Elements, 75 because, for example, they are delivering a pre-standards product, or 76 the Information Element is in some way commercially sensitive. 78 This document re-defines the format of IANA-registered TLVs in a 79 backward compatible manner with respect to previous documents and 80 existing IANA allocations; it also defines the format for newly 81 introduced enterprise-specific TLVs. 83 The concept of an E-bit, or Enterprise bit, is not new. For example 84 such mechanism is defined in Section 3.2 of [RFC7011] for a very 85 similar purpose. 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in BCP 92 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 93 appear in all capitals, as shown here. 95 3. TLV encoding 97 3.1. IANA-registered TLV encoding 99 Existing TLV encoding defined in Section 4.4 of [RFC7854] is reviewed 100 as follows: 102 o 1 bit to flag an enterprise-specific TLV set to zero. The TLV 103 Type value must have been defined in IANA-BMP [IANA-BMP] 105 o 15 bits of TLV Type, 107 o 2 octets of TLV Length, 109 o 0 or more octets of TLV Value. 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 |E| Type | Length (2 octets) | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Value (variable) | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Figure 1 120 3.2. Enterprise-specific TLV encoding 122 Enterprise-specific TLV encoding is defined as follows: 124 o 1 bit to flag an enterprise-specific TLV set to one 126 o 15 bits of TLV Type, 128 o 2 octets of TLV Length, 130 o 4 octets of IANA enterprise number IANA-PEN [IANA-PEN] 132 o 0 or more octets of TLV Value. 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 |E| Type | Length (2 octets) | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Enterprise number | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Value (variable) | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Figure 2 145 3.3. TLV encoding remarks 147 The encoding specified in this document applies to all existing BMP 148 Message Types and their namespaces defined in RFC 7854 [RFC7854], TLV 149 support for BMP Route Monitoring and Peer Down Messages 150 [I-D.ietf-grow-bmp-tlv] and BMP Peer Up Message Namespace 151 [I-D.ietf-grow-bmp-peer-up]. While the proposed encoding is not per- 152 se backward compatible, there is no existing IANA-allocated Type 153 value that makes use of the most significant bit (which is being used 154 in this document to define the E-bit). 156 Future BMP Message Types MUST make use of the TLV encoding defined in 157 this document. 159 TLVs SHOULD be sorted by their code point. Multiple TLVs of the same 160 type can be repeated as part of the same message and it is left to 161 the specific use-cases whether all, any, the first or the last TLV 162 should be considered. 164 4. Security Considerations 166 It is not believed that this document adds any additional security 167 considerations. 169 5. IANA Considerations 171 The TLV Type values used by BMP are managed by IANA as are the 172 Private Enterprise Numbers used by enterprise-specific Type values 173 IANA-PEN [IANA-PEN]. This document makes no changes to these 174 registries. 176 6. References 177 6.1. Normative References 179 [I-D.ietf-grow-bmp-peer-up] 180 Scudder, J., "BMP Peer Up Message Namespace", draft-ietf- 181 grow-bmp-peer-up-00 (work in progress), July 2019. 183 [I-D.ietf-grow-bmp-tlv] 184 Lucente, P., Gu, Y., and H. Smit, "TLV support for BMP 185 Route Monitoring and Peer Down Messages", draft-ietf-grow- 186 bmp-tlv-01 (work in progress), October 2019. 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, 190 DOI 10.17487/RFC2119, March 1997, 191 . 193 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 194 Monitoring Protocol (BMP)", RFC 7854, 195 DOI 10.17487/RFC7854, June 2016, 196 . 198 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 199 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 200 May 2017, . 202 6.2. Informative References 204 [IANA-BMP] 205 IANA, "BGP Monitoring Protocol (BMP) Parameters", 2016, 206 . 209 [IANA-PEN] 210 IANA, "Private Enterprise Numbers", 1982, 211 . 213 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 214 "Specification of the IP Flow Information Export (IPFIX) 215 Protocol for the Exchange of Flow Information", STD 77, 216 RFC 7011, DOI 10.17487/RFC7011, September 2013, 217 . 219 Acknowledgements 221 TBD 223 Authors' Addresses 225 Paolo Lucente 226 NTT 227 Siriusdreef 70-72 228 Hoofddorp, WT 2132 229 NL 231 Email: paolo@ntt.net 233 Yunan Gu 234 Huawei 235 Huawei Bld., No.156 Beiqing Rd. 236 Beijing 100095 237 China 239 Email: guyunan@huawei.com