PCE H. Chen Internet-Draft China Telecom Intended status: Standards Track H. Yuan Expires: January 9, 2021 UnionPay T. Zhou W. Li G. Fioccola Huawei July 8, 2020 PCEP SR Policy Extensions to Enable IFIT draft-chen-pce-sr-policy-ifit-01 Abstract Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. In-situ Flow Information Telemetry (IFIT) refers to network OAM applications that apply dataplane on- path telemetry techniques. This document defines extensions to PCEP to distribute SR policies carrying IFIT information. So that IFIT behavior can be enabled automatically when the SR policy is applied. 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 RFC 2119 [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 January 9, 2021. Chen, et al. Expires January 9, 2021 [Page 1] Internet-Draft pcep-sr-policy-ifit July 2020 Copyright Notice Copyright (c) 2020 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 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. IFIT Attributes in SR Policy . . . . . . . . . . . . . . . . 3 3. SR Policy for IOAM . . . . . . . . . . . . . . . . . . . . . 3 3.1. IOAM Pre-allocated Trace Option TLV . . . . . . . . . . . 4 3.2. IOAM Incremental Trace Option TLV . . . . . . . . . . . . 5 3.3. IOAM Directly Export Option TLV . . . . . . . . . . . . . 5 3.4. IOAM Edge-to-Edge Option TLV . . . . . . . . . . . . . . 6 4. SR Policy for Enhanced Alternate Marking . . . . . . . . . . 7 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. PCE Initiated SR Policy . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Segment Routing (SR) policy [I-D.ietf-spring-segment-routing-policy] is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. In-situ Flow Information Telemetry (IFIT) refers to network OAM applications that apply dataplane on-path telemetry techniques, including In-situ OAM (IOAM) [I-D.ietf-ippm-ioam-data] and Alternate Marking [RFC8321]. It can provide flow information on the entire forwarding path on a per- packet basis in real time. Chen, et al. Expires January 9, 2021 [Page 2] Internet-Draft pcep-sr-policy-ifit July 2020 An automatic network requires the Service Level Agreement (SLA) monitoring on the deployed service. So that the system can quickly detect the SLA violation or the performance degradation, hence to change the service deployment. The SR policy native IFIT can facilitate the closed loop control, and enable the automation of SR service. This document defines extensions to PCEP to distribute SR policies carrying IFIT information. So that IFIT behavior can be enabled automatically when the SR policy is applied. This PCEP extension allows to signal the IFIT capabilities together with the SR-policy. In this way IFIT methods are automatically activated and running. The flexibility and dynamicity of the IFIT applications are given by the use of additional functions on the controller and on the network nodes, but this is out of scope here. It is to be noted the companion document [I-D.qin-idr-sr-policy-ifit] that proposes the BGP extension to enable IFIT applications for SR policy. 2. IFIT Attributes in SR Policy SR Policy Association Group (SRPAG) is defined in [I-D.ietf-pce-segment-routing-policy-cp] to extend PCEP to support association among candidate paths of a given SR policy. SR Policy Identifiers TLV, SR Policy Name TLV, SR Policy Candidate Path Identifiers TLV, and SR Policy Candidate Path Preference TLV are introduced to construct the SR policy structure. This document is to add IFIT attribute TLVs to the SRPAG. The following sections will describe the requirement and usage of different IFIT modes, and define the corresponding TLV encoding in PCEP. Note that the IFIT attributes here described can also be generalized and included as TLVs for other Association Groups. In this regard RFC 8697 [RFC8697] defines the generic mechanism to associate sets of LSPs and a set of attributes, for example IFIT. 3. SR Policy for IOAM In-situ Operations, Administration, and Maintenance (IOAM) [I-D.ietf-ippm-ioam-data] records operational and telemetry information in the packet while the packet traverses a path between two points in the network. In terms of the classification given in RFC 7799 [RFC7799] IOAM could be categorized as Hybrid Type 1. IOAM Chen, et al. Expires January 9, 2021 [Page 3] Internet-Draft pcep-sr-policy-ifit July 2020 mechanisms can be leveraged where active OAM do not apply or do not offer the desired results. When SR policy enables the IOAM, the IOAM header will be inserted into every packet of the traffic that is steered into the SR paths. This document aims to define the control plane. While a relevant document for the data plane is [I-D.ietf-ippm-ioam-ipv6-options] for Segment Routing over IPv6 data plane (SRv6). 3.1. IOAM Pre-allocated Trace Option TLV The IOAM tracing data is expected to be collected at every node that a packet traverses to ensure visibility into the entire path a packet takes within an IOAM domain. The preallocated tracing option will create pre-allocated space for each node to populate its information. The format of IOAM pre-allocated trace option TLV is defined as follows: 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 | Length | +---------------------------------------------------------------+ | Namespace ID | Rsvd1 | +-------------------------------+-----------------------+-------+ | IOAM Trace Type | Flags | Rsvd2 | +----------------------------------------------+--------+-------+ Fig. 1 IOAM Pre-allocated Trace Option TLV Where: Type: to be assigned by IANA. Length: the total length of the value field not including Type and Length fields. Namespace ID: A 16-bit identifier of an IOAM-Namespace. The definition is the same as described in section 4.4 of [I-D.ietf-ippm-ioam-data]. IOAM Trace Type: A 24-bit identifier which specifies which data types are used in the node data list. The definition is the same as described in section 4.4 of [I-D.ietf-ippm-ioam-data]. Chen, et al. Expires January 9, 2021 [Page 4] Internet-Draft pcep-sr-policy-ifit July 2020 Flags: A 4-bit field. The definition is the same as described in [I-D.ietf-ippm-ioam-flags] and section 4.4 of [I-D.ietf-ippm-ioam-data]. Rsvd1: A 16-bit field reserved for further usage. It MUST be zero. Rsvd2: A 4-bit field reserved for further usage. It MUST be zero. 3.2. IOAM Incremental Trace Option TLV The incremental tracing option contains a variable node data fields where each node allocates and pushes its node data immediately following the option header. The format of IOAM incremental trace option TLV is defined as follows: 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 | Length | +---------------------------------------------------------------+ | Namespace ID | Rsvd1 | +-------------------------------+-----------------------+-------+ | IOAM Trace Type | Flags | Rsvd2 | +----------------------------------------------+--------+-------+ Fig. 2 IOAM Incremental Trace Option TLV Where: Type: to be assigned by IANA. Length: the total length of the value field not including Type and Length fields. All the other fields definition is the same as the pre-allocated trace option TLV in section 4.1. 3.3. IOAM Directly Export Option TLV IOAM directly export option is used as a trigger for IOAM data to be directly exported to a collector without being pushed into in-flight data packets. The format of IOAM directly export option TLV is defined as follows: Chen, et al. Expires January 9, 2021 [Page 5] Internet-Draft pcep-sr-policy-ifit July 2020 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 | Length | +---------------------------------------------------------------+ | Namespace ID | Flags | +-------------------------------+---------------+---------------+ | IOAM Trace Type | Rsvd | +-----------------------------------------------+---------------+ | Flow ID | +---------------------------------------------------------------+ Fig. 3 IOAM Directly Export Option TLV Where: Type: to be assigned by IANA. Length: the total length of the value field not including Type and Length fields. Namespace ID: A 16-bit identifier of an IOAM-Namespace. The definition is the same as described in section 4.4 of [I-D.ietf-ippm-ioam-data]. IOAM Trace Type: A 24-bit identifier which specifies which data types are used in the node data list. The definition is the same as described in section 4.4 of [I-D.ietf-ippm-ioam-data]. Flags: A 16-bit field. The definition is the same as described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. Flow ID: A 32-bit flow identifier. The definition is the same as described in section 3.2 of [I-D.ietf-ippm-ioam-direct-export]. Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 3.4. IOAM Edge-to-Edge Option TLV The IOAM edge to edge option is to carry data that is added by the IOAM encapsulating node and interpreted by IOAM decapsulating node. The format of IOAM edge-to-edge option TLV is defined as follows: Chen, et al. Expires January 9, 2021 [Page 6] Internet-Draft pcep-sr-policy-ifit July 2020 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 | Length | +---------------------------------------------------------------+ | Namespace ID | IOAM E2E Type | +-------------------------------+-------------------------------+ Fig. 4 IOAM Edge-to-Edge Option TLV Where: Type: to be assigned by IANA. Length: the total length of the value field not including Type and Length fields. Namespace ID: A 16-bit identifier of an IOAM-Namespace. The definition is the same as described in section 4.6 of [I-D.ietf-ippm-ioam-data]. IOAM E2E Type: A 16-bit identifier which specifies which data types are used in the E2E option data. The definition is the same as described in section 4.6 of [I-D.ietf-ippm-ioam-data]. 4. SR Policy for Enhanced Alternate Marking The Alternate Marking [RFC8321]technique is an hybrid performance measurement method, per RFC 7799 [RFC7799] classification of measurement methods. Because this method is based on marking consecutive batches of packets. It can be used to measure packet loss, latency, and jitter on live traffic. This document aims to define the control plane. While a relevant document for the data plane is [I-D.ietf-6man-ipv6-alt-mark] for Segment Routing over IPv6 data plane (SRv6). The format of EAM TLV is defined as follows: 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 | Length | +-------------------------------+-------+---------------+-------+ | FlowMonID | Period | Rsvd | +---------------------------------------+---------------+-------+ Where: Chen, et al. Expires January 9, 2021 [Page 7] Internet-Draft pcep-sr-policy-ifit July 2020 Type: to be assigned by IANA. Length: the total length of the value field not including Type and Length fields. FlowMonID: A 20-bit identifier to uniquely identify a monitored flow within the measurement domain. The definition is the same as described in section 5.3 of [I-D.ietf-6man-ipv6-alt-mark]. Period: Time interval between two alternate marking period. The unit is second. Rsvd: A 4-bit field reserved for further usage. It MUST be zero. 5. Examples 5.1. PCE Initiated SR Policy The interactions between the PCE and PCC is the same as described in [I-D.ietf-pce-segment-routing-policy-cp]. The only change is to take the additional optional IFIT TLVs within the SRPAG object. PCE sends PCInitiate message, containing the SRPAG Association object. The Association Source is set to the IP address of the PCC and the Association ID is set to 0xFFFF. PCC uses the color, endpoint, preference and IFIT option from the SRPAG object to create a new candidate path. If no SR policy exists to hold the candidate path, then a new SR policy is created to hold the new candidate-path. The Originator of the candidate path is set to be the address of the PCE that is sending the PCInitiate message. PCC sends a PCRpt message back to the PCE to report the newly created Candidate Path. The PCRpt message contains the SRPAG Association object. The Association Source is set to the IP address of the PCC and the Association ID is set to a number that PCC locally chose to represent the SR Policy. 6. IANA Considerations This document defines new IFIT TLVs for carrying additional information about SR policy and SR candidate paths. IANA is requested to make the assignment of a new value for the existing "PCEP TLV Type Indicators" registry as follows: Chen, et al. Expires January 9, 2021 [Page 8] Internet-Draft pcep-sr-policy-ifit July 2020 Codepoint Description Reference ------------------------------------------------------------- TBD1 IOAM Pre-allocated Trace This document Option TLV TBD2 IOAM Incremental Trace This document Option TLV TBD3 IOAM Directly Export This document Option TLV TBD4 IOAM Edge-to-Edge This document Option TLV TBD5 Enhanced Alternate Marking This document TLV 7. Security Considerations TBD. 8. Acknowledgements 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, January 2018, . [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., Dhody, D., and Y. Tanaka, "Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, . Chen, et al. Expires January 9, 2021 [Page 9] Internet-Draft pcep-sr-policy-ifit July 2020 9.2. Informative References [I-D.ietf-6man-ipv6-alt-mark] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. Pang, "IPv6 Application of the Alternate Marking Method", draft-ietf-6man-ipv6-alt-mark-01 (work in progress), June 2020. [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, d., and J. Lemon, "Data Fields for In-situ OAM", draft- ietf-ippm-ioam-data-09 (work in progress), March 2020. [I-D.ietf-ippm-ioam-direct-export] Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ OAM Direct Exporting", draft-ietf-ippm-ioam-direct- export-00 (work in progress), February 2020. [I-D.ietf-ippm-ioam-flags] Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-01 (work in progress), January 2020. [I-D.ietf-ippm-ioam-ipv6-options] Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- ipv6-options-01 (work in progress), March 2020. [I-D.ietf-pce-segment-routing-policy-cp] Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. Bidgoli, "PCEP extension to support Segment Routing Policy Candidate Paths", draft-ietf-pce-segment-routing-policy- cp-00 (work in progress), June 2020. [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", draft- ietf-spring-segment-routing-policy-07 (work in progress), May 2020. Chen, et al. Expires January 9, 2021 [Page 10] Internet-Draft pcep-sr-policy-ifit July 2020 [I-D.qin-idr-sr-policy-ifit] Qin, F., Yuan, H., Zhou, T., Min, L., and G. Fioccola, "BGP SR Policy Extensions to Enable IFIT", draft-qin-idr- sr-policy-ifit-00 (work in progress), January 2020. Appendix A. Authors' Addresses Huanan Chen China Telecom Guangzhou China Email: chenhuan6@chinatelecom.cn Hang Yuan UnionPay 1899 Gu-Tang Rd., Pudong Shanghai China Email: yuanhang@unionpay.com Tianran Zhou Huawei 156 Beiqing Rd., Haidian District Beijing China Email: zhoutianran@huawei.com Weidong Li Huawei 156 Beiqing Rd., Haidian District Beijing China Email: poly.li@huawei.com Chen, et al. Expires January 9, 2021 [Page 11] Internet-Draft pcep-sr-policy-ifit July 2020 Giuseppe Fioccola Huawei Riesstrasse, 25 Munich Germany Email: giuseppe.fioccola@huawei.com Chen, et al. Expires January 9, 2021 [Page 12]