Network Working Group D. Farinacci Internet-Draft lispers.net Intended status: Experimental S. Ouissal Expires: 2 November 2023 E. Nordmark Zededa 1 May 2023 LISP Data-Plane Telemetry draft-farinacci-lisp-telemetry-10 Abstract This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages. 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 2 November 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Farinacci, et al. Expires 2 November 2023 [Page 1] Internet-Draft LISP Data-Plane Telemetry May 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Telemetry Record Encoding . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 8 B.1. Changes to draft-farinacci-lisp-telemetry-10 . . . . . . 8 B.2. Changes to draft-farinacci-lisp-telemetry-09 . . . . . . 8 B.3. Changes to draft-farinacci-lisp-telemetry-08 . . . . . . 8 B.4. Changes to draft-farinacci-lisp-telemetry-07 . . . . . . 8 B.5. Changes to draft-farinacci-lisp-telemetry-06 . . . . . . 8 B.6. Changes to draft-farinacci-lisp-telemetry-05 . . . . . . 8 B.7. Changes to draft-farinacci-lisp-telemetry-04 . . . . . . 8 B.8. Changes to draft-farinacci-lisp-telemetry-03 . . . . . . 9 B.9. Changes to draft-farinacci-lisp-telemetry-02 . . . . . . 9 B.10. Changes to draft-farinacci-lisp-telemetry-01 . . . . . . 9 B.11. Changes to draft-farinacci-lisp-telemetry-00 . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction This document describes how the Locator/Identifier Separation Protocol (LISP) can obtain, measure, and distribute data-plane telemetry information. LISP is an encapsulation protocol built around the fundamental idea of separating the topological location of a network attachment point from the node's identity [RFC9300]. As a result LISP creates two namespaces: Endpoint Identifiers (EIDs), that are used to identify end-hosts and routable Routing Locators (RLOCs), used to identify network attachment points. LISP then defines functions for mapping between the two namespaces and for encapsulating traffic originated by devices using non-routable EIDs for transport across a network infrastructure that routes and forwards using RLOCs. This document specifies how a decapsulating xTR returns telemetry data to an encapsulating xTR using RLOC-probe messages defined in [RFC9301]. Farinacci, et al. Expires 2 November 2023 [Page 2] Internet-Draft LISP Data-Plane Telemetry May 2023 Early versions of this document will define the type and format of the telemetry data and how it will be distributed. Later versions of this document will describe how telemetry measurement will be performed. 2. Definition of Terms Encapsulating xTR is a LISP ITR, RTR, or PITR data-plane network element [RFC9300]. An encapsulating xTR typically sends RLOC- probe Map-Request messages to decapsulating xTRs to test for reachability of RLOC addresses. For the design scope of this specification, RLOC-probes are also sent to obtain LISP telemetry data measured by a decapsulating xTR. Decapsulating xTR is a LISP ETR, RTR, or PETR data-plane network element [RFC9300]. A decapsulating xTR typically RLOC-probe replies with a Map-Reply message to an RLOC-probe Map-Request sent by an encapsulating xTR. When a decapsulating xTR does data-plane telemetry measurement, it returns measurement data in RLOC-probe Map-Reply messages to an encapsulating xTR. Telemetry Record a telemetry record is an RLOC-record that contains telemetry data specified in this document. The telemetry data is encoded as an LCAF JSON Type specified in [RFC8060]. 3. Overview The following list of telemetry data has been identified as being useful to obtain: * Packet Count - the number of packets received within a given time window between the encapsulating xTR and decapsulating xTR. * Byte Count - the number bytes summed from all packets received within a given time window between the encapsulating xTR and decapsulating xTR. * Packet Rate - the rate in packets per second an encapsulating xTR is sending encapsulated packets to a decapsulating xTR. * Bit Rate - the bit rate per second an encapsulating xTR is sending encapsulated packets to a decapsulating xTR. * Bandwidth - the amount of bandwidth used between encapsulating xTR and decapsulating xTR in bytes per second. Farinacci, et al. Expires 2 November 2023 [Page 3] Internet-Draft LISP Data-Plane Telemetry May 2023 * Packet Loss - the number of packets lost within a given time window between the encapsulating xTR and decapsulating xTR. * Packet Jitter - the amount of inter-packet time for a train of packets within a given time window between the encapsulating xTR and decapsulating xTR. * Forward Hop-Count - the number underlay router hops from the encapsulating xTR to the decapsulating xTR. * Forward One-Way Latency - the amount of time from the encapsulating xTR to the decapsulating xTR. Available when a universal clock and rough time synchronization is available. * Reverse TTL - the TTL value a decapsulating xTR is using for the RLOC-probe Map-Reply. This is used to compute the return or Reverse Hop-Count or number of underlay router hops between the decapsulating xTR and encapsulating xTR. * Reverse Timestamp - the universal clock timestamp when the decapsulating xTR sent the RLOC-probe Map-Reply message. This is used to compute the return or Reverse One-Way Latency between the decapsulating xTR to the encapsulating xTR. 4. Telemetry Record Encoding A Telemetry Record is an RLOC-record encoded in LCAF JSON Type format [RFC8060] within the EID-record inserted in a RLOC-probe Map-Reply message. The RLOC-record is appended to the existing RLOC-records for the EID being probed. An encapsulating xTR does not need to request telemetry data so the decapsulating xTR can provide it unilaterally by default or via configuration to enable the feature. When an encapsulating xTR receives a Telemetry Record in a RLOC-probe Map-Reply, it SHOULD NOT store it in the map-cache and not use the RLOC-record for forwarding (since there are no RLOCs in this record). The priority for this RLOC-record MUST be set to 255 and the weight MUST be set to 0. The JSON key values imply directionality. The directionality is from encapsulating xTR to decapsulating xTR. That is, the same direction of RLOC-probe Map-Requests and encapsulated packet flow. The JSON string format is defined to be: Farinacci, et al. Expires 2 November 2023 [Page 4] Internet-Draft LISP Data-Plane Telemetry May 2023 { "type" : "telemetry", "packet-count" : "", "packet-loss" : "", "byte-count" : "", "packet-rate" : "", "bit-rate" : "
", "bandwidth" : "", "packet-jitter" : "", "forward-latency" : "", "forward-hop-count" : "", "reverse-ttl" : "", "reverse-timestamp" : "" } JSON data values: Farinacci, et al. Expires 2 November 2023 [Page 5] Internet-Draft LISP Data-Plane Telemetry May 2023 +============+====================================================+ | JSON Value | Encoding Description | +============+====================================================+ | | Number of packets encoded as an integer value | | | within a string. | +------------+----------------------------------------------------+ | | Number of lost packets encoded as an integer value | | | within a string. | +------------+----------------------------------------------------+ | | Number of bytes encoded as an integer value within | | | a string. | +------------+----------------------------------------------------+ | | Packet rate in packets per second encoded as an | | | integer value within a string. | +------------+----------------------------------------------------+ |
| Bit rate in kilobits per second encoded as an | | | integer value within a string. | +------------+----------------------------------------------------+ | | Bandwidth in kilobytes encoded as an integer value | | | within a string. | +------------+----------------------------------------------------+ | | Packet jitter in milliseconds encoded as an | | | integer value within a string. | +------------+----------------------------------------------------+ | | Latency in milliseconds encoded as an integer | | | value within a string. | +------------+----------------------------------------------------+ | | Hop count encoded as an integer value within a | | | string. | +------------+----------------------------------------------------+ | | Map-Reply IP header TTL encoded as an integer | | | value within a string. | +------------+----------------------------------------------------+ | | Timestamp encoded in Linux UTC format as an within | | | a string (i.e. Tue Jun 26 16:27:25 UTC 2018). | +------------+----------------------------------------------------+ Table 1 5. Security Considerations RLOC-probe Map-Reply messages are signed to protect and authenticate the Telemetry Record according to details in [RFC9303]. Telemetry Records can be kept confidential by encrypting RLOC-probe Map-Reply message with the asymmetric keys described in [I-D.ietf-lisp-ecdsa-auth] or the symmetric keys computed by the key exchange detailed in [RFC8061]. Farinacci, et al. Expires 2 November 2023 [Page 6] Internet-Draft LISP Data-Plane Telemetry May 2023 6. IANA Considerations At this time there are no specific requests for IANA. 7. References 7.1. Normative References [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, . [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, . [RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., "The Locator/ID Separation Protocol (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022, . [RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., "Locator/ID Separation Protocol (LISP) Control Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022, . [RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, "Locator/ID Separation Protocol Security (LISP-SEC)", RFC 9303, DOI 10.17487/RFC9303, October 2022, . 7.2. Informative References [I-D.ietf-lisp-ecdsa-auth] Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA Authentication and Authorization", Work in Progress, Internet-Draft, draft-ietf-lisp-ecdsa-auth-10, 5 March 2023, . Appendix A. Acknowledgments The authors would like to thank the LISP WG for their review and acceptance of this draft. A special thanks to Colin Cantrell for his review, commentary and guidance. Farinacci, et al. Expires 2 November 2023 [Page 7] Internet-Draft LISP Data-Plane Telemetry May 2023 Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] B.1. Changes to draft-farinacci-lisp-telemetry-10 * Posted May 2023. * Document timer and reference update. B.2. Changes to draft-farinacci-lisp-telemetry-09 * Posted November 2022. * Included new references to standards track RFCs. * Document timer and reference update. B.3. Changes to draft-farinacci-lisp-telemetry-08 * Posted May 2022. * Document timer and reference update. B.4. Changes to draft-farinacci-lisp-telemetry-07 * Posted November 2021. * Document timer and reference update. B.5. Changes to draft-farinacci-lisp-telemetry-06 * Posted May 2021. * Document timer and reference update. B.6. Changes to draft-farinacci-lisp-telemetry-05 * Posted November 2020. * Document timer and reference update. B.7. Changes to draft-farinacci-lisp-telemetry-04 * Posted June 2020. * Document timer and reference update. Farinacci, et al. Expires 2 November 2023 [Page 8] Internet-Draft LISP Data-Plane Telemetry May 2023 B.8. Changes to draft-farinacci-lisp-telemetry-03 * Posted December 2019. * Document timer and reference update. B.9. Changes to draft-farinacci-lisp-telemetry-02 * Posted June 2019. * Document timer and reference update. B.10. Changes to draft-farinacci-lisp-telemetry-01 * Posted December 2018. * Document timer and reference update. B.11. Changes to draft-farinacci-lisp-telemetry-00 * Initial draft posted June 2018. Authors' Addresses Dino Farinacci lispers.net San Jose, CA United States of America Email: farinacci@gmail.com Said Ouissal Zededa Santa Clara, CA United States of America Email: said@zededa.com Erik Nordmark Zededa Santa Clara, CA United States of America Email: erik@zededa.com Farinacci, et al. Expires 2 November 2023 [Page 9]