IDR J. Heitz Internet-Draft P. Narasimha Intended status: Standards Track S. Gulrajani Expires: September 11, 2019 Cisco March 10, 2019 BGP Diagnostic Path Attribute draft-heitz-idr-diagnostic-attr-00 Abstract A BGP path attribute for the purpose of network diagnostics is described. It is non-transitive, such that BGP speakers will not forward it by default. It is structured as a list of elements. An element begins with the BGP identifier and AS number of the speaker that adds the element and includes a list of TLVs. Any speaker can add or remove an element to/from the list. TLVs for a timestamp and for a checksum are described. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 11, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. Heitz, et al. Expires September 11, 2019 [Page 1] Internet-Draft BGP Diagnostic Attribute March 2019 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Timestamp TLV . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Checksum TLV . . . . . . . . . . . . . . . . . . . . . . 4 3. Operational Considerations . . . . . . . . . . . . . . . . . 4 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction A BGP path attribute for the purpose of network diagnostics is described. It is non-transitive, such that BGP speakers will not propagate it by default. It is structured as a list of elements. An element begins with the BGP identifier and AS number of the speaker that adds the element and includes a list of TLVs. Any speaker can add or remove an element to/from the list. TLVs for a timestamp and for a checksum are described. The diagnostic attribute may be sent in a withdraw message. 2. Data Formats The BGP diagnostic consists of a series of elements, each of which is formatted as follows. Heitz, et al. Expires September 11, 2019 [Page 2] Internet-Draft BGP Diagnostic Attribute March 2019 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Identfifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + TLVs + : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are as follows: ASN - 4 octet Autonomous System Number of the speaker that added this element. BGP Identfifier - BGP Identifier of the speaker that added this element. Length - The number of octets comprising this element, If there were no TLVs included, this length would be 10. TLVs - Any number of TLVs as further described. Each TLV is optional. 2.1. Timestamp TLV The time at which the indicated speaker created this attribute during the process of creating to message to be sent. The precision of the timestamp depends upon the diagnostic application that requires it and is out of scope of this document. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are as follows: Heitz, et al. Expires September 11, 2019 [Page 3] Internet-Draft BGP Diagnostic Attribute March 2019 Type - 1. Length - 12. Seconds - The number of Seconds since 0 h 1 January 1900 UTC as further described in Section 6 of [RFC5905]. Fraction - A fraction of the above seconds also described in Section 6 of [RFC5905]. 2.2. Checksum TLV A checksum of the BGP message, including the marker field. The checksum is only valid between the sending and receiving speaker. Since a receiving speaker may propagate an update, it will likely change the set of attributes or their order in its own update message, thus making the checksum useless in the propagated update. A BGP speaker MAY remove the checksum TLV from a propagated Diagnostic Path Attribute. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length = 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are as follows: Type - 2. Length - 6. Checksum - The 16 bit checksum computed according to [RFC1071]. 3. Operational Considerations As with any new BGP attribute, if it is propagated, NLRI packing into BGP UPDATE messages may be affected. This needs to be taken into consideration when using the Timestamp TLV to measure bulk update message timing. The Checksum TLV is useful to narrow down a source of corruption of UPDATE messages in each of the software and hardware layers between the actual BGP processes. Heitz, et al. Expires September 11, 2019 [Page 4] Internet-Draft BGP Diagnostic Attribute March 2019 The Diagnostic Path Attribute MAY be sent in an UPDATE message that does not contain an NLRI field [RFC4271] or an MP_REACH_NLRI Path Attribute [RFC4760]. When carried in such a message, it is unlikely to be propagated, although it is possible. 4. Error Handling A checksum error shall not be treated as a protocol error. The response is implementation dependent. A TLV length error shall be treated as attribute-discard according to [RFC7606]. An unrecognized TLV MUST not be treated as a protocol error. 5. Security Considerations This attribute is not forwarded by default. Therefore, it should cause no unexpected ill effects. 6. IANA Considerations IANA is requested to assign a BGP path attribute value for the BGP Diagnostic Path Aattribute. IANA is requested to create and maintain a registry for the TLV types. The allocation policies as per [RFC8126] are stated for the range of values. Range Allocation Policy ----------- ------------------------------ 0-32767 First Come First Served 32768-65535 Experimental Value Description Reference --------- ------------------------------ --------- 0 Reserved This RFC 1 Timestamp This RFC 2 Checksum This RFC 7. Normative References [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the Internet checksum", RFC 1071, DOI 10.17487/RFC1071, September 1988, . Heitz, et al. Expires September 11, 2019 [Page 5] Internet-Draft BGP Diagnostic Attribute March 2019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Authors' Addresses Jakob Heitz Cisco 170 West Tasman Drive San Jose, CA, CA 95134 USA Email: jheitz@cisco.com Prasad S. Narasimha Cisco 170 West Tasman Drive San Jose, CA, CA 95134 USA Email: snprasad@cisco.com Heitz, et al. Expires September 11, 2019 [Page 6] Internet-Draft BGP Diagnostic Attribute March 2019 Sameer Gulrajani Cisco 170 West Tasman Drive San Jose, CA, CA 95134 USA Email: sameerg@cisco.com Heitz, et al. Expires September 11, 2019 [Page 7]