Skip to main content

PCEP extension to support Candidate Paths validity
draft-chen-pce-sr-policy-cp-validity-01

Document Type Active Internet-Draft (individual)
Authors Ran Chen , Detao Zhao , Samuel Sidor , Mike Koldychev , Zafar Ali
Last updated 2024-03-01
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chen-pce-sr-policy-cp-validity-01
Inter-Domain Routing                                             R. Chen
Internet-Draft                                                   D. Zhao
Intended status: Standards Track                         ZTE Corporation
Expires: 2 September 2024                                       S. Sidor
                                                            M. Koldychev
                                                                  Z. Ali
                                                     Cisco Systems, Inc.
                                                            1 March 2024

           PCEP extension to support Candidate Paths validity
                draft-chen-pce-sr-policy-cp-validity-01

Abstract

   This document defines PCEP extensions for signaling the validity
   control parameters of a candidate path for an SR Policy.

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 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 (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.

Chen, et al.            Expires 2 September 2024                [Page 1]
Internet-Draft   PCEP extension to support CPs validity       March 2024

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  CP Validity TLV . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Stateful PCEP Messages  . . . . . . . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   SR Policy architecture are specified in [RFC9256].  An SR Policy
   comprises one or more candidate paths (CP) of which at a given time
   one and only one may be active (i.e., installed in forwarding and
   usable for steering of traffic).  Each CP in turn may have one or
   more SID-List of which one or more may be active; when multiple SID-
   List are active then traffic is load balanced over them.

   [I-D.chen-spring-sr-policy-cp-validity]supplemented candidate path
   validity criterion in [RFC9256].  It defines three validity control
   parameters under candidate Path to control the validity judgment of
   candidate Path.

   PCEP Extensions for Segment Routing [RFC8664] specifies extensions
   that allow PCEP to work with basic SR-TE paths.

   PCEP extension to support Segment Routing Policy Candidate Paths
   [I-D.ietf-pce-segment-routing-policy-cp] specifies extensions that
   allow PCEP to signal additional attributes of an SR Policy, which are
   not covered by [RFC8664].  SR Policy is modeled in PCEP as an
   Association and the SR Candidate Paths are the members of that
   Association.  Thus the PCE can take computation and control decisions
   about the Candidate Paths, with the additional knowledge that these
   Candidate Paths belong to the same SR Policy.

   This document defines PCEP extensions for signaling the validity
   control parameters of a candidate path for an SR Policy.

2.  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].

Chen, et al.            Expires 2 September 2024                [Page 2]
Internet-Draft   PCEP extension to support CPs validity       March 2024

3.  PCEP Extensions

   As defined in [RFC8697] , TE LSPs are associated by adding them to a
   common association group by a PCEP peer.
   [I-D.ietf-pce-segment-routing-policy-cp] defines SR Policy
   Association (SRPA), and the SR Candidate Paths are the members of
   this Association.  We define the CP validity TLV in the SR Policy
   Association (SRPA) object to signal the validity control parameters
   of a candidate path.

3.1.  CP Validity TLV

   The format of the CP Validity 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          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  valid SL count |                   Reserved                  |                                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     valid SL weight                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               Figure 1

   where:

   Type: to be assigned by IANA.

   Length: the total length of the value field not including Type and
   Length fields.

   valid SL count´╝Ü1-octet field which indicates the minimum number of
   valid segment Lists under the active candidate path.  When the number
   of valid segment Lists under candidate path is greater than or equal
   to this field, the candidate path is considered valid. 0 indicates no
   requirement for SL count.  0xff indicates that the candidate path is
   considered valid only if all the segment Lists are valid.

Chen, et al.            Expires 2 September 2024                [Page 3]
Internet-Draft   PCEP extension to support CPs validity       March 2024

   valid SL weight: 4-octet field which indicates the minimum value of
   the sum of the weights of the valid segment List under the active
   candidate Path.  When the sum of the weights of the valid segment
   Lists under the candidate path is greater than or equal to this
   field, the candidate Path is considered valid. 0 indicates no
   requirement for weight.0xffffffff indicates that the candidate path
   is considered valid only if all the segment Lists are valid.

   Unless specifically stated otherwise, the CP Validity TLV is assumed
   to be single instance.  Meaning, only one instance of the TLV SHOULD
   be present in the object and only the first instance of the TLV
   SHOULD be interpreted and subsequent instances SHOULD be ignored.

3.2.  Stateful PCEP Messages

   As per [RFC8697], the ASSOCIATION object MAY be carried in the PCUpd,
   PCRpt, and Path Computation Initiate (PCInitiate) messages.  The CP
   Validity TLV is carried in a SR Policy Association (SRPA) object and
   MAY also be carried in the PCUpd, PCRpt, and Path Computation
   Initiate (PCInitiate) messages.

   When carried in a PCRpt message, this object is used to report the
   validity control parameters of a candidate path for a SR Policy.

   When an LSP is delegated to a stateful PCE, the stateful PCE can
   create the validity control parameters of a candidate path for a SR
   Policy.  This is done by including the CP Validity TLV in a PCUpd
   message.

   A PCE initiating a new SR policy can also include the validity
   control parameters of a candidate path for this policy.  This is done
   by including the CP Validity TLV in a PCInitiate message.

4.  IANA Considerations

   This document defines the new TLV 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:

      Value   Description               Reference
     ------- ------------------------- --------------
       TBD    CP Validity TLV       This document

                                  Figure 2

Chen, et al.            Expires 2 September 2024                [Page 4]
Internet-Draft   PCEP extension to support CPs validity       March 2024

5.  Security Considerations

   Procedures and protocol extensions defined in this document do not
   affect the security considerations discussed in
   [I-D.ietf-pce-segment-routing-policy-cp].

6.  Acknowledgements

   TBD.

7.  Normative References

   [I-D.chen-spring-sr-policy-cp-validity]
              Chen, R., Zhao, D., and C. Lin, "Validity of SR Policy
              Candidate Path", Work in Progress, Internet-Draft, draft-
              chen-spring-sr-policy-cp-validity-01, 19 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-chen-spring-
              sr-policy-cp-validity-01>.

   [I-D.ietf-pce-segment-routing-policy-cp]
              Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
              Bidgoli, "PCEP Extensions for SR Policy Candidate Paths",
              Work in Progress, Internet-Draft, draft-ietf-pce-segment-
              routing-policy-cp-14, 9 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
              segment-routing-policy-cp-14>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8664]  Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "Path Computation Element Communication
              Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
              DOI 10.17487/RFC8664, December 2019,
              <https://www.rfc-editor.org/info/rfc8664>.

   [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,
              <https://www.rfc-editor.org/info/rfc8697>.

Chen, et al.            Expires 2 September 2024                [Page 5]
Internet-Draft   PCEP extension to support CPs validity       March 2024

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

Authors' Addresses

   Ran Chen
   ZTE Corporation
   Nanjing
   China
   Email: chen.ran@zte.com.cn

   Detao Zhao
   ZTE Corporation
   Nanjing
   China
   Email: zhao.detao@zte.com.cn

   Samuel Sidor
   Cisco Systems, Inc.
   Bratislava
   Slovakia
   Email: ssidor@cisco.com

   Mike Koldychev
   Cisco Systems, Inc.
   Email: mkoldych@cisco.com

   Zafar Ali
   Cisco Systems, Inc.
   Email: zali@cisco.com

Chen, et al.            Expires 2 September 2024                [Page 6]