idnits 2.17.1 draft-scudder-grow-bmp-peer-up-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 14, 2018) is 1957 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GROW J. Scudder 3 Internet-Draft Juniper Networks 4 Updates: 7854 (if approved) December 14, 2018 5 Intended status: Standards Track 6 Expires: June 17, 2019 8 BMP Peer Up Message Namespace 9 draft-scudder-grow-bmp-peer-up-00.txt 11 Abstract 13 RFC 7854, BMP, uses different message types for different purposes. 14 Most of these are Type, Length, Value (TLV) structured. One message 15 type, the Peer Up message, lacks a set of TLVs defined for its use, 16 instead sharing a namespace with the Initiation message. Subsequent 17 experience has shown that this namespace sharing was a mistake, as it 18 hampers the extension of the protocol. 20 This document updates RFC 7854 by creating an independent namespace 21 for the Peer Up message. The changes in this document are formal 22 only, compliant implementations of RFC 7854 also comply with this 23 specification. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 17, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 61 2. String Definition . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Changes to RFC 7854 . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Revision to Information TLV, Renamed as Initiation 64 Information TLV . . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Revision to Peer Up Notification . . . . . . . . . . . . 3 66 3.3. Definition of Peer Up Information TLV . . . . . . . . . . 4 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 70 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 73 1. Introduction 75 [RFC7854] defines a number of different BMP message types. With the 76 exception of the Route Monitoring message type, these messages are 77 TLV-structured. Most message types have distinct namespaces and IANA 78 registries. However, the namespace of the Peer Up message overlaps 79 that of the Initiation message. As the BMP protocol has been 80 extended, this oversight has become problematic. In this document, 81 we create a distinct namespace for the Peer Up message to eliminate 82 this overlap, and create the corresponding missing registry. 84 The changes in this document are formal only, compliant 85 implementations of [RFC7854] also comply with this specification. 87 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all 93 capitals, as shown here. 95 2. String Definition 97 A string TLV is a free-form sequence of UTF-8 characters whose length 98 is given by the TLV's Length field. There is no requirement to 99 terminate the string with a null (or any other particular) character 100 -- the Length field gives its termination. 102 3. Changes to RFC 7854 104 We update [RFC7854] as follows: 106 o The "Information TLV" of section 4.4, that was shared between the 107 Initiation and Peer Up message types, is renamed as the 108 "Initiation Information TLV", and is only relevant to the 109 Initiation message type. 111 o A "Peer Up Information TLV" is defined, and is relevant to the 112 Peer Up message type. 114 o A "Peer Up TLVs" registry is created, seeded with the Peer Up 115 Information TLV. 117 Other than as summarized above, and detailed below, there are no 118 other changes. 120 3.1. Revision to Information TLV, Renamed as Initiation Information TLV 122 The Information TLV defined in section 4.4 of [RFC7854] is renamed 123 "Initiation Information TLV". It is used only by the Initiation 124 message, not by the Peer Up message. 126 The definition of Type = 0 is revised to be: 128 o Type = 0: String. The Information field contains a string 129 (Section 2). The value is administratively assigned. If multiple 130 strings are included, their ordering MUST be preserved when they 131 are reported. 133 3.2. Revision to Peer Up Notification 135 The final paragraph of section 4.10 of [RFC7854] references the 136 Information TLV (which is revised above (Section 3.1)). That 137 paragraph is replaced by the following: 139 o Information: Information about the peer, using the Peer Up 140 Information TLV format defined below (Section 3.3). The String 141 type may be repeated. Inclusion of the Information field is 142 OPTIONAL. Its presence or absence can be inferred by inspection 143 of the Message Length in the common header. 145 3.3. Definition of Peer Up Information TLV 147 The Peer Up Information TLV is used by the Peer Up message. 149 0 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Information Type | Information Length | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Information (variable) | 154 ~ ~ 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 o Information Type (2 bytes): Type of information provided. Defined 158 types are: 160 * Type = 0: String. The Information field contains a string 161 (Section 2). The value is administratively assigned. If 162 multiple strings are included, their ordering MUST be preserved 163 when they are reported. 165 o Information Length (2 bytes): The length of the following 166 Information field, in bytes. 168 o Information (variable): Information about the monitored router, 169 according to the type. 171 4. IANA Considerations 173 IANA is requested to create a registry within the BMP group, named 174 "BMP Peer Up Message TLVs", reference this document. 176 Registration procedures for this registry are: 178 +-------------+--------------------------+ 179 | Range | Registration Procedures | 180 +-------------+--------------------------+ 181 | 0-32767 | Standards Action | 182 | 32768-65530 | First Come, First Served | 183 | 65531-65534 | Experimental | 184 | 65535 | Reserved | 185 +-------------+--------------------------+ 187 Initial values for this registry are: 189 +-------+-------------+---------------+ 190 | Type | Description | Reference | 191 +-------+-------------+---------------+ 192 | 0 | String | this document | 193 | 65535 | Reserved | this document | 194 +-------+-------------+---------------+ 196 5. Security Considerations 198 This rearrangement of deck chairs does not change the underlying 199 security issues inherent in the existing [RFC7854]. 201 6. Acknowledgements 203 TBD 205 7. Normative References 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, 209 DOI 10.17487/RFC2119, March 1997, 210 . 212 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 213 Monitoring Protocol (BMP)", RFC 7854, 214 DOI 10.17487/RFC7854, June 2016, 215 . 217 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 218 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 219 May 2017, . 221 Author's Address 223 John Scudder 224 Juniper Networks 225 1194 N. Mathilda Ave 226 Sunnyvale, CA 94089 227 USA 229 Email: jgs@juniper.net