PCE Working Group C. Lin Internet-Draft New H3C Technologies Intended status: Standards Track Y. Liu Expires: July 5, 2024 China Mobile R. Chen ZTE Y. Qiu New H3C Technologies January 5, 2024 PCEP Extension to Support SRv6 Segment List optimization draft-lin-pce-srv6-segment-list-optimize-01 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 5 2024. Copyright Notice Copyright (c) 2024 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 (http://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 Liu, et al. Expire July, 2024 [Page 1] Internet-Draft PCEP SRv6 Segment List Optimization January 2024 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. Abstract The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for optimizing the arrangement of segment lists to solve the problem of the penultimate segment node being unable to perform PSP behavior when the egress node has both End SID and service SID, and improve the forwarding efficiency of data packets. Table of Contents 1. Introduction ................................................ 3 2. Terminology ................................................. 3 3. Requirement Background ...................................... 4 4. Extend the Flags of SRv6-ERO subobject ...................... 4 5. Operation ................................................... 5 6. IANA Considerations ......................................... 5 7. Security Considerations ..................................... 5 8. References .................................................. 6 8.1. Normative References ................................... 6 8.2. Informative References ................................. 7 9. Acknowledgments ............................................. 7 Authors' Addresses ............................................. 7 Liu, et al. Expires July, 2024 [Page 2] Internet-Draft PCEP SRv6 Segment List Optimization January 2024 1. Introduction Segment Routing (SR) [RFC8402] allows a headend node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. The headend node is said to steer a flow into an SR Policy [RFC8402]. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. [I-D.ietf-pce-segment-routing-ipv6] provides a mechanism for a network controller (acting as a PCE) to instantiate candidate paths for an SR Policy onto a head-end node (acting as a PCC) using PCEP. This document defines PCEP extensions for optimizing the arrangement of segment lists to solve the problem of the penultimate segment node being unable to perform PSP behavior when the egress node has both End SID and service SID, and improve the forwarding efficiency of data packets. 2. Terminology The following terminologies are used in this document. SR: Segment Routing SRv6: SR for IPv6 SRH: Segment Routing Header SID: Segment Identifier CE: Customer Edge PE: Provider Edge VPN: Virtual Private Network PSP: Penultimate Segment Pop PCEP: Path Computation Element Communication Protocol Liu, et al. Expires July, 2024 [Page 3] Internet-Draft PCEP SRv6 Segment List Optimization January 2024 PCE: Path Computation Element PCC: Path Computation Client 3. Requirement Background The requirement background of optimizing the arrangement of segment lists is specified in [I-D.liu-idr-srv6-segment-list-optimize]. When instantiating the candidate path of SRv6 Policy to the ingress node via PCEP, it is also necessary to inform the ingress node which is the egress node's SID. After the head node receives the PCEP message, when the SID is used as the egress node's SID of the SRv6 forwarding path, if SRH.SegmentList already contains the service SID of the egress node, the egress node's SID will not be encapsulated at the same time. 4. Extend the Flags of SRv6-ERO subobject Extend the Flags of the SRv6-ERO subobject defined in [I-D.ietf-pce- segment-routing-ipv6]. Define a E bit to identify which is the egress node's SID. The format of SRv6 ERO after adding E bit is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type=40 | Length | NT | Flags |E|V|T|F|S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRv6 SID (optional) | | (128-bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // NAI (variable, optional) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID Structure (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: E-Flag: This flag, when set, indicates that this segment is the egress node's SID. Liu, et al. Expires July, 2024 [Page 4] Internet-Draft PCEP SRv6 Segment List Optimization January 2024 If the SRH.SegmentList of the packet already contains the service SID of the egress node, the End SID of the egress node will not be encapsulated in the segment list at the same time. 5. Operation After the controller arranges the SRv6 forwarding path, it informs the ingress node which is the egress node's SID through the E-Flag. When the controller distributes the SRv6 Policy configuration to the head node through PCEP, the E bit of Flags field of the SRv6-ERO Subobject corresponding to the egress node is set to 1. And the E- Flag bits corresponding to the ingress node and intermediate node are set to 0. After receiving the SRv6 Policy configuration with E bit set to 1, the ingress node will not simultaneously arrange the End SID and Service SID of the egress node into the SRH.SegmentList of packet. For data packets forwarded to VPN through this SRv6 Policy, the SRH.SegmentList will not encapsulate the End SID corresponding to the egress node in the SID list of SRv6 Policy. If the forwarding path does not include the service SID of the egress node, then the End SID of the egress node should be encapsulated in SRH.SegmentList. For the OAM detection message of this SRv6 Policy, all node SIDs of the SID lists will be encapsulated. 6. IANA Considerations This document requests that IANA allocate the following registration in the "SRv6-ERO Flag Field" sub-registry for the "Path Computation Element Protocol (PCEP) Numbers" registry maintained by IANA: +-------+-------------------------------------+---------------+ | Bit | Description | Reference | +=======+=====================================+===============+ | TBA | Indication of egress node's SID (E) | This document | +-------+-------------------------------------+---------------+ 7. Security Considerations [RFC8754] defines the notion of an SR domain and use of SRH within the SR domain. Procedures for securing an SR domain are defined the section 5.1 and section 7 of [RFC8754]. Liu, et al. Expires July, 2024 [Page 5] Internet-Draft PCEP SRv6 Segment List Optimization January 2024 This document does not impose any additional security challenges to be considered beyond security threats described in [RFC8754], [RFC8679] and [RFC8986]. 8. References 8.1. Normative References [I-D.ietf-pce-segment-routing-ipv6] Li, C., Negi, M., Sivabalan, S., Koldychev, M., Kaladharan, P., Zhu, Y., "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing leveraging the IPv6 dataplane", draft- ietf-pce-segment-routing-ipv6-20 (work in progress), September 2023. [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., Michel, C., and H. Chen, "MPLS Egress Protection Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . Liu, et al. Expires July, 2024 [Page 6] Internet-Draft PCEP SRv6 Segment List Optimization January 2024 8.2. Informative References TBD 9. Acknowledgments TBD Authors' Addresses Changwang Lin New H3C Technologies Email: linchangwang.04414@h3c.com Yisong Liu China Mobile Email: liuyisong@chinamobile.com Ran Chen ZTE Corporation Email: chen.ran@zte.com.cn Yuanxiang Qiu New H3C Technologies Email: qiuyuanxiang@h3c.com Liu, et al. Expires July, 2024 [Page 7]