Internet-Draft PCEP extensions for SRv6 Policy SID List March 2025
Ali, et al. Expires 2 September 2025 [Page]
Workgroup:
PCE Working Group
Internet-Draft:
draft-all-pce-srv6-policy-sid-list-optimization-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
Z. Ali
Cisco Systems, Inc.
C. Lin
New H3C Technologies
Y. Liu
China Mobile
R. Venkateswaran
Cisco Systems, Inc.
R. Chen
ZTE Corporation
C. Li
Huawei Technologies
Y. Qiu
New H3C Technologies
S. Sidor
Cisco Systems, Inc.

Path Computation Element Communication Protocol (PCEP) extensions for SRv6 Policy SID List Optimization

Abstract

In some use cases, an SRv6 policy's SID list ends with the policy endpoint's node SID, and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. In such cases, the SID list can be optimized by excluding the endpoint Node SID when installing the policy. This draft specifies a PCEP extension to indicate whether the endpoint's node SID needs to be included or excluded when installing the SRv6 Policy.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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 September 2025.

Table of Contents

1. Introduction

Segment Routing (SR) [RFC8402] allows a node to steer a packet flow along any path. A Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of segments that represent a source-routed policy. The headend node is said to steer a flow into an SR Policy. The packets steered into an SR Policy have an ordered list of segments associated with that SR Policy written into them. Segment Routing Policy Architecture [RFC9256] updates [RFC8402] as it details the concepts of SR Policy and steering into an SR Policy. [RFC8986] describes the representation and processing of this ordered list of segments for Segment Routing over IPv6 (SRv6). [RFC9603] specifies PCEP extensions to support SR for the IPv6 data plane.

A PCE computes the SRv6 TE Policy SID list from the headend to the endpoint. The computed SID list may end with the policy endpoint's Node SID or the penultimate hop adjacency SID. If the computed SID list ends with the policy endpoint's node SID and the overlay SID in the steered traffic (over policy) already ensures that the traffic is taken to the policy endpoint with the same intent, the SRv6 policy endpoint device needs to process back-to-back local node SIDs. Examples of overlay SID containing the local node SID are a service SID, a binding SID for transit policies, an EPE SID, etc. From a compression efficiency viewpoint, carrying back-to-back end-point node SID is inefficient. The SID list in the packet can be optimized by excluding the end-point node SID when installing the policy. End-point node SID exclusion improves the compression efficiency and makes packet processing more efficient for the policy endpoint.

Excluding the policy endpoint's node SID is possible in most use cases, but not all. For example, if the SRv6 policy is used to carry MPLS traffic, as described in [I-D.draft-agrawal-spring-srv6-mpls-interworking], it is not possible to exclude the policy endpoint's node SID. Specifically, the endpoint's node SID inclusion or exclusion is a policy attribute. This draft specifies a PCEP extension to include or exclude the node SID when installing the SRv6 Policy.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Terminology

This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP, PCEP Peer.

SR: Segment Routing.

SID: Segment Identifier.

SRv6: Segment Routing over IPv6 data plane.

4. Overview of PCEP Extensions

4.1. New TLV in the SRPA Object

The draft specifies a new SRPOLICY-POL-ATTRIBUTE TLV for the SR Policy Association object defined in [I-D.draft-ietf-pce-segment-routing-policy-cp]. The SRPOLICY-POL-ATTRIBUTE TLV is optional.

 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            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Flags                           |I|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SRPOLICY-POL-ATTRIBUTE TLV

4.2. A New flag in the SRPOLICY-POL-ATTRIBUTE TLV

This document specifies I-flag (endpoint node SID Inclusion flag) bit in the Flags field of "SRPOLICY-POL-ATTRIBUTE" TLV specified in this document. The flag is applicable only to SR policies with SRv6 data plane. The flag MUST be ignored for SR policies with SR-MPLS data planee.

I (endpoint node SID Inclusion) - 1 bit (Bit Position TBD2):

4.3. New flag in SRv6-PCE-CAPABILITY sub-TLV

I-flag (endpoint node SID Inclusion capability flag) is proposed in the SRv6-PCE-CAPABILITY sub-TLV defined in [RFC9603]. The bit position for the flag in the SRv6 Capability Flag Field registry is to be defined by IANA.

I (endpoint node SID Inclusion capability flag) - 1 bit (Bit Position TBD3):

5. Operation

A PCEP speaker indicates its ability to support I-flag in the Flags field of the SRPOLICY-POL-ATTRIBUTE TLV during the PCEP initialization phase by setting the I-flag in the SRv6-PCE-CAPABILITY sub-TLV in the Open message.

A PCEP peer indicates the inclusion or exclusion of the endpoint's Node SID in I-flag in the Flags field of the SRPOLICY-POL-ATTRIBUTE TLV.

A PCEP peer MUST NOT set the I-flag flag if capability was not advertised by both peers.

If the PCEP peers are capable of supporting the I-flag and the I-flag in the Flags field of the SRPOLICY-POL-ATTRIBUTE TLV is set, the PCC MUST include the endpoint node SID when installing the SRv6 Policy sid list(s) used to carry data traffic.

If the PCEP peers are capable of supporting the I-flag and the I-flag in the Flags field of the SRPOLICY-POL-ATTRIBUTE TLV is not set, the PCC MUST NOT include the endpoint node SID when installing the SRv6 Policy sid list(s) used to carry data traffic.

I-flag value in the Flags field of the SRPOLICY-POL-ATTRIBUTE TLV MUST NOT change for a given SRv6 Policy Candidate Path during its lifetime.

Local policy at PCC MAY override the I-flag.

PCE ignores the I-flag received from the PCC when computing the path and computes the SRv6 Policy SID list from the headend to the endpoint. PCE MAY use the I-flag value for debugging purposes.

6. Backward compatibility

If at least one PCEP peer is not capable of supporting the I-flag, the endpoint Node SID inclusion/exclusion SHOULD be set based on local policy at the PCC.

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]. This document does not impose any additional security challenges to be considered beyond security threats described in [RFC8754], [RFC8679] and [RFC8986].

8. IANA Considerations

TBA

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, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5440]
Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, , <https://www.rfc-editor.org/info/rfc5440>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[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, , <https://www.rfc-editor.org/info/rfc8402>.
[RFC8679]
Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., Michel, C., and H. Chen, "MPLS Egress Protection Framework", RFC 8679, DOI 10.17487/RFC8679, , <https://www.rfc-editor.org/info/rfc8679>.
[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, , <https://www.rfc-editor.org/info/rfc8754>.
[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, , <https://www.rfc-editor.org/info/rfc8986>.
[RFC9256]
Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, , <https://www.rfc-editor.org/info/rfc9256>.
[RFC9603]
Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M., and Y. Zhu, "Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing", RFC 9603, DOI 10.17487/RFC9603, , <https://www.rfc-editor.org/info/rfc9603>.

9.2. Informative References

Appendix A. Acknowledgements

The authors would like to thank Ketan Talaulikar for the review comments.

Authors' Addresses

Zafar Ali
Cisco Systems, Inc.
Changwang Lin
New H3C Technologies
Yisong Liu
China Mobile
Rajesh M Venkateswaran
Cisco Systems, Inc.
Ran Chen
ZTE Corporation
Cheng Li
Huawei Technologies
Yuanxiang Qiu
New H3C Technologies
Samuel Sidor
Cisco Systems, Inc.