idnits 2.17.1 draft-heitz-idr-diagnostic-attr-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An unrecognized TLV MUST not be treated as a protocol error. -- The document date (March 10, 2019) is 1845 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) ** Downref: Normative reference to an Informational RFC: RFC 1071 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR J. Heitz 3 Internet-Draft P. Narasimha 4 Intended status: Standards Track S. Gulrajani 5 Expires: September 11, 2019 Cisco 6 March 10, 2019 8 BGP Diagnostic Path Attribute 9 draft-heitz-idr-diagnostic-attr-00 11 Abstract 13 A BGP path attribute for the purpose of network diagnostics is 14 described. It is non-transitive, such that BGP speakers will not 15 forward it by default. It is structured as a list of elements. An 16 element begins with the BGP identifier and AS number of the speaker 17 that adds the element and includes a list of TLVs. Any speaker can 18 add or remove an element to/from the list. TLVs for a timestamp and 19 for a checksum are described. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 11, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2.1. Timestamp TLV . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Checksum TLV . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Operational Considerations . . . . . . . . . . . . . . . . . 4 66 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 A BGP path attribute for the purpose of network diagnostics is 75 described. It is non-transitive, such that BGP speakers will not 76 propagate it by default. It is structured as a list of elements. An 77 element begins with the BGP identifier and AS number of the speaker 78 that adds the element and includes a list of TLVs. Any speaker can 79 add or remove an element to/from the list. TLVs for a timestamp and 80 for a checksum are described. The diagnostic attribute may be sent 81 in a withdraw message. 83 2. Data Formats 85 The BGP diagnostic consists of a series of elements, each of which is 86 formatted as follows. 88 0 1 2 3 89 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 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | ASN | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | BGP Identfifier | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Length | | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 97 | | 98 + TLVs + 99 : : 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 The fields are as follows: 104 ASN - 4 octet Autonomous System Number of the speaker 105 that added this element. 107 BGP Identfifier - BGP Identifier of the speaker that added this 108 element. 110 Length - The number of octets comprising this element, If 111 there were no TLVs included, this length would 112 be 10. 114 TLVs - Any number of TLVs as further described. Each 115 TLV is optional. 117 2.1. Timestamp TLV 119 The time at which the indicated speaker created this attribute during 120 the process of creating to message to be sent. The precision of the 121 timestamp depends upon the diagnostic application that requires it 122 and is out of scope of this document. 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Type = 1 | Length = 12 | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Seconds | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Fraction | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 The fields are as follows: 136 Type - 1. 138 Length - 12. 140 Seconds - The number of Seconds since 0 h 1 January 1900 UTC as 141 further described in Section 6 of [RFC5905]. 143 Fraction - A fraction of the above seconds also described in 144 Section 6 of [RFC5905]. 146 2.2. Checksum TLV 148 A checksum of the BGP message, including the marker field. The 149 checksum is only valid between the sending and receiving speaker. 150 Since a receiving speaker may propagate an update, it will likely 151 change the set of attributes or their order in its own update 152 message, thus making the checksum useless in the propagated update. 153 A BGP speaker MAY remove the checksum TLV from a propagated 154 Diagnostic Path Attribute. 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Type = 2 | Length = 6 | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Checksum | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 The fields are as follows: 166 Type - 2. 168 Length - 6. 170 Checksum - The 16 bit checksum computed according to [RFC1071]. 172 3. Operational Considerations 174 As with any new BGP attribute, if it is propagated, NLRI packing into 175 BGP UPDATE messages may be affected. This needs to be taken into 176 consideration when using the Timestamp TLV to measure bulk update 177 message timing. 179 The Checksum TLV is useful to narrow down a source of corruption of 180 UPDATE messages in each of the software and hardware layers between 181 the actual BGP processes. 183 The Diagnostic Path Attribute MAY be sent in an UPDATE message that 184 does not contain an NLRI field [RFC4271] or an MP_REACH_NLRI Path 185 Attribute [RFC4760]. When carried in such a message, it is unlikely 186 to be propagated, although it is possible. 188 4. Error Handling 190 A checksum error shall not be treated as a protocol error. The 191 response is implementation dependent. 193 A TLV length error shall be treated as attribute-discard according to 194 [RFC7606]. 196 An unrecognized TLV MUST not be treated as a protocol error. 198 5. Security Considerations 200 This attribute is not forwarded by default. Therefore, it should 201 cause no unexpected ill effects. 203 6. IANA Considerations 205 IANA is requested to assign a BGP path attribute value for the BGP 206 Diagnostic Path Aattribute. 208 IANA is requested to create and maintain a registry for the TLV 209 types. The allocation policies as per [RFC8126] are stated for the 210 range of values. 212 Range Allocation Policy 213 ----------- ------------------------------ 214 0-32767 First Come First Served 215 32768-65535 Experimental 217 Value Description Reference 218 --------- ------------------------------ --------- 219 0 Reserved This RFC 220 1 Timestamp This RFC 221 2 Checksum This RFC 223 7. Normative References 225 [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the 226 Internet checksum", RFC 1071, DOI 10.17487/RFC1071, 227 September 1988, . 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, 231 DOI 10.17487/RFC2119, March 1997, 232 . 234 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 235 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 236 DOI 10.17487/RFC4271, January 2006, 237 . 239 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 240 "Multiprotocol Extensions for BGP-4", RFC 4760, 241 DOI 10.17487/RFC4760, January 2007, 242 . 244 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 245 "Network Time Protocol Version 4: Protocol and Algorithms 246 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 247 . 249 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 250 Patel, "Revised Error Handling for BGP UPDATE Messages", 251 RFC 7606, DOI 10.17487/RFC7606, August 2015, 252 . 254 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 255 Writing an IANA Considerations Section in RFCs", BCP 26, 256 RFC 8126, DOI 10.17487/RFC8126, June 2017, 257 . 259 Authors' Addresses 261 Jakob Heitz 262 Cisco 263 170 West Tasman Drive 264 San Jose, CA, CA 95134 265 USA 267 Email: jheitz@cisco.com 269 Prasad S. Narasimha 270 Cisco 271 170 West Tasman Drive 272 San Jose, CA, CA 95134 273 USA 275 Email: snprasad@cisco.com 276 Sameer Gulrajani 277 Cisco 278 170 West Tasman Drive 279 San Jose, CA, CA 95134 280 USA 282 Email: sameerg@cisco.com