summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9357.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9357.txt')
-rw-r--r--doc/rfc/rfc9357.txt420
1 files changed, 420 insertions, 0 deletions
diff --git a/doc/rfc/rfc9357.txt b/doc/rfc/rfc9357.txt
new file mode 100644
index 0000000..69cc3e6
--- /dev/null
+++ b/doc/rfc/rfc9357.txt
@@ -0,0 +1,420 @@
+
+
+
+
+Internet Engineering Task Force (IETF) Q. Xiong
+Request for Comments: 9357 ZTE Corporation
+Category: Standards Track February 2023
+ISSN: 2070-1721
+
+
+ Label Switched Path (LSP) Object Flag Extension for Stateful PCE
+
+Abstract
+
+ RFC 8231 describes a set of extensions to the Path Computation
+ Element Communication Protocol (PCEP) to enable stateful control of
+ MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. One of the
+ extensions is the LSP object, which includes a Flag field with a
+ length of 12 bits. However, all bits of the Flag field have already
+ been assigned.
+
+ This document defines a new LSP-EXTENDED-FLAG TLV for the LSP object
+ for an extended Flag field.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc9357.
+
+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.
+
+Table of Contents
+
+ 1. Introduction
+ 2. Conventions Used in this Document
+ 2.1. Terminology
+ 2.2. Requirements Language
+ 3. PCEP Extension
+ 3.1. The LSP-EXTENDED-FLAG TLV
+ 3.2. Processing
+ 4. Advice for Specification of New Flags
+ 5. Backward Compatibility
+ 6. IANA Considerations
+ 6.1. LSP Object
+ 6.1.1. PCEP TLV Type Indicators
+ 6.1.2. LSP Extended Flags Field
+ 7. Management Considerations
+ 8. Security Considerations
+ 9. References
+ 9.1. Normative References
+ 9.2. Informative References
+ Appendix A. Working Group Discussion
+ Acknowledgements
+ Contributors
+ Author's Address
+
+1. Introduction
+
+ [RFC5440] describes the Path Computation Element Communication
+ Protocol (PCEP), which is used between a PCE and a Path Computation
+ Client (PCC) (or other PCE) to enable computation of Multi-protocol
+ Label Switching for Traffic Engineering (MPLS-TE) Label Switched
+ Paths (LSPs).
+
+ PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set
+ of extensions to PCEP to enable active control of MPLS-TE and
+ Generalized MPLS (GMPLS) tunnels. One of the extensions is the LSP
+ object, which contains a Flag field; bits in the Flag field are used
+ to indicate delegation, synchronization, removal, etc.
+
+ As defined in [RFC8231], the length of the Flag field is 12 bits, and
+ all of the bits have already been defined as shown in Table 1. This
+ document extends the Flag field of the LSP object for other use by
+ defining a new LSP-EXTENDED-FLAG TLV for an extended Flag field in
+ the LSP object (see Section 3.1).
+
+ +=====+======================+==================+
+ | Bit | Description | Reference |
+ +=====+======================+==================+
+ | 0 | PCE-allocation | [BIND-LABEL-SID] |
+ +-----+----------------------+------------------+
+ | 1 | ERO-compression | [RFC8623] |
+ +-----+----------------------+------------------+
+ | 2 | Fragmentation | [RFC8623] |
+ +-----+----------------------+------------------+
+ | 3 | P2MP | [RFC8623] |
+ +-----+----------------------+------------------+
+ | 4 | Create | [RFC8281] |
+ +-----+----------------------+------------------+
+ | 5-7 | Operational (3 bits) | [RFC8281] |
+ +-----+----------------------+------------------+
+ | 8 | Administrative | [RFC8281] |
+ +-----+----------------------+------------------+
+ | 9 | Remove | [RFC8281] |
+ +-----+----------------------+------------------+
+ | 10 | SYNC | [RFC8281] |
+ +-----+----------------------+------------------+
+ | 11 | Delegate | [RFC8281] |
+ +-----+----------------------+------------------+
+
+ Table 1: LSP Object Flag Field
+
+2. Conventions Used in this Document
+
+2.1. Terminology
+
+ The terminology is defined in [RFC5440] and [RFC8231].
+
+2.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. PCEP Extension
+
+ The LSP object is defined in Section 7.3 of [RFC8231]. This document
+ defines a new LSP-EXTENDED-FLAG TLV for an extended Flag field in the
+ LSP object.
+
+3.1. The LSP-EXTENDED-FLAG TLV
+
+ The format of the LSP-EXTENDED-FLAG TLV shown in Figure 1 follows the
+ format of all PCEP TLVs, as defined in [RFC5440].
+
+ 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=64 | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ // LSP Extended Flags //
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: LSP-EXTENDED-FLAG TLV Format
+
+
+ Type (16 bits): 64
+
+ Length (16 bits): This indicates the length of the value portion in
+ bytes. It MUST be in multiples of 4 and greater than 0.
+
+ LSP Extended Flags: This contains an array of units of 32-bit flags
+ numbered from the most significant as bit zero, where each bit
+ represents one LSP flag (for operation, feature, or state). The
+ LSP Extended Flags field SHOULD use the minimal amount of space
+ needed to encode the flag bits. Currently, no bits are assigned.
+ Unassigned bits MUST be set to zero on transmission and MUST be
+ ignored on receipt.
+
+ As an example of usage of the LSP-EXTENDED-FLAG TLV, the E-flag is
+ requested for entropy label configuration, as proposed in
+ [PCEP-ENTROPY-LABEL].
+
+3.2. Processing
+
+ The LSP Extended Flags field is an array of units of 32 flags that
+ are allocated starting from the most significant bit. The bits of
+ the LSP Extended Flags field will be assigned by future documents.
+ This document does not define any flags. Flags that an
+ implementation is not supporting MUST be set to zero on transmission.
+ Implementations that do not understand any particular flag MUST
+ ignore the flag.
+
+ Note that PCEP peers MUST handle varying lengths of the LSP-EXTENDED-
+ FLAG TLV.
+
+ If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV of a length more
+ than it currently supports or understands, it MUST ignore the bits
+ beyond that length.
+
+ If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV of a length less
+ than the one supported by the implementation, it MUST act as if the
+ bits beyond the length were not set.
+
+4. Advice for Specification of New Flags
+
+ Following the model provided in Section 3.1 of [RFC8786], we provide
+ the following advice for new specifications that define additional
+ flags. Each such specification is expected to describe the
+ interaction between these new flags and any existing flags. In
+ particular, new specifications are expected to explain how to handle
+ the cases when both new and preexisting flags are set. They are also
+ expected to discuss any security implications of the additional flags
+ (if any) and their interactions with existing flags.
+
+5. Backward Compatibility
+
+ The LSP-EXTENDED-FLAG TLV defined in this document does not introduce
+ any backward compatibility issues. An implementation that does not
+ understand or support the LSP-EXTENDED-FLAG TLV MUST ignore the TLV,
+ as per [RFC5440]. Future documents that define bits in the LSP-
+ EXTENDED-FLAG TLV are expected to also define the error handling
+ required for cases in which the LSP-EXTENDED-FLAG TLV is missing when
+ it MUST be present.
+
+ Further, any additional bits in the LSP-EXTENDED-FLAG TLV that are
+ not understood by an implementation MUST be ignored. It is expected
+ that future documents that define bits in the LSP-EXTENDED-FLAG TLV
+ will take that into consideration.
+
+6. IANA Considerations
+
+6.1. LSP Object
+
+6.1.1. PCEP TLV Type Indicators
+
+ IANA has allocated the following TLV Type Indicator value within the
+ "PCEP TLV Type Indicators" registry of the "Path Computation Element
+ Protocol (PCEP) Numbers" registry:
+
+ +=======+===================+===========+
+ | Value | Description | Reference |
+ +=======+===================+===========+
+ | 64 | LSP-EXTENDED-FLAG | RFC 9357 |
+ +-------+-------------------+-----------+
+
+ Table 2
+
+6.1.2. LSP Extended Flags Field
+
+ IANA has created the "LSP-EXTENDED-FLAG TLV Flag Field" registry
+ within the "Path Computation Element Protocol (PCEP) Numbers"
+ registry to manage the LSP Extended Flags field of the LSP-EXTENDED-
+ FLAG TLV. New values are assigned by Standards Action [RFC8126].
+ Each bit should be tracked with the following qualities:
+
+ * Bit number (counting from bit 0 as the most significant bit)
+
+ * Capability Description
+
+ * Reference
+
+ No values are currently defined. Bits 0-31 are initially marked as
+ "Unassigned". Bits with a higher ordinal than 31 will be added to
+ the registry in future documents if necessary.
+
+7. Management Considerations
+
+ Implementations receiving set LSP Extended Flags that they do not
+ recognize MAY log this. That could be helpful for diagnosing
+ backward compatibility issues with future features that utilize those
+ flags.
+
+8. Security Considerations
+
+ [RFC8231] sets out security considerations for PCEP when used for
+ communication with a stateful PCE. This document does not change
+ those considerations. For LSP object processing, see [RFC8231].
+
+ The flags for the LSP object and their associated security
+ considerations are specified in [RFC8231], [RFC8281], [RFC8623], and
+ [BIND-LABEL-SID].
+
+ This document provides for the future addition of flags in the LSP
+ object. Any future document that specifies new flags must also
+ discuss any associated security implications. No additional security
+ issues are raised in this document beyond those that exist in the
+ referenced documents. Note that [RFC8231] recommends that the
+ stateful PCEP extension be authenticated and encrypted using
+ Transport Layer Security (TLS) [RFC8253] [PCEPS-TLS1.3], as per the
+ recommendations and best current practices in [RFC9325]. Assuming
+ that the recommendation is followed, then the flags will be protected
+ by TLS.
+
+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,
+ <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, March 2009,
+ <https://www.rfc-editor.org/info/rfc5440>.
+
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
+ Computation Element Communication Protocol (PCEP)
+ Extensions for Stateful PCE", RFC 8231,
+ DOI 10.17487/RFC8231, September 2017,
+ <https://www.rfc-editor.org/info/rfc8231>.
+
+9.2. Informative References
+
+ [BIND-LABEL-SID]
+ Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
+ and C. Li, Ed., "Carrying Binding Label/Segment Identifier
+ (SID) in PCE-based Networks.", Work in Progress, Internet-
+ Draft, draft-ietf-pce-binding-label-sid-15, 20 March 2022,
+ <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
+ binding-label-sid-15>.
+
+ [PCEP-ENTROPY-LABEL]
+ Xiong, Q., Peng, S., and F. Qin, "PCEP Extension for SR-
+ MPLS Entropy Label Position", Work in Progress, Internet-
+ Draft, draft-peng-pce-entropy-label-position-08, 29 August
+ 2022, <https://datatracker.ietf.org/doc/html/draft-peng-
+ pce-entropy-label-position-08>.
+
+ [PCEPS-TLS1.3]
+ Dhody, D., Turner, S., and R. Housley, "PCEPS with TLS
+ 1.3", Work in Progress, Internet-Draft, draft-dhody-pce-
+ pceps-tls13-01, 20 October 2022,
+ <https://datatracker.ietf.org/doc/html/draft-dhody-pce-
+ pceps-tls13-01>.
+
+ [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
+ Zhang, "OSPF Protocol Extensions for Path Computation
+ Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088,
+ January 2008, <https://www.rfc-editor.org/info/rfc5088>.
+
+ [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
+ Zhang, "IS-IS Protocol Extensions for Path Computation
+ Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
+ January 2008, <https://www.rfc-editor.org/info/rfc5089>.
+
+ [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
+ "PCEPS: Usage of TLS to Provide a Secure Transport for the
+ Path Computation Element Communication Protocol (PCEP)",
+ RFC 8253, DOI 10.17487/RFC8253, October 2017,
+ <https://www.rfc-editor.org/info/rfc8253>.
+
+ [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
+ Computation Element Communication Protocol (PCEP)
+ Extensions for PCE-Initiated LSP Setup in a Stateful PCE
+ Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
+ <https://www.rfc-editor.org/info/rfc8281>.
+
+ [RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful
+ Path Computation Element (PCE) Protocol Extensions for
+ Usage with Point-to-Multipoint TE Label Switched Paths
+ (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019,
+ <https://www.rfc-editor.org/info/rfc8623>.
+
+ [RFC8786] Farrel, A., "Updated Rules for Processing Stateful PCE
+ Request Parameters Flags", RFC 8786, DOI 10.17487/RFC8786,
+ May 2020, <https://www.rfc-editor.org/info/rfc8786>.
+
+ [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
+ "Recommendations for Secure Use of Transport Layer
+ Security (TLS) and Datagram Transport Layer Security
+ (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
+ 2022, <https://www.rfc-editor.org/info/rfc9325>.
+
+Appendix A. Working Group Discussion
+
+ The working group discussed the idea of a fixed length (with 32 bits)
+ for the LSP-EXTENDED-FLAG TLV. Though 32 bits would be sufficient
+ for quite a while, the use of variable length with a multiple of 32
+ bits allows for future extensibility where we would never run out of
+ flags and there would not be a need to define yet another TLV in the
+ future. Further, note that [RFC5088] and [RFC5089] use the same
+ approach for the PCE-CAP-FLAGS sub-TLV and are found to be useful.
+
+Acknowledgements
+
+ The authors would like to thank Loa Andersson, Adrian Farrel, Aijun
+ Wang, and Gyan Mishra for their reviews, suggestions, and comments
+ for this document.
+
+Contributors
+
+ The following people have substantially contributed to this document:
+
+ Dhruv Dhody
+ Huawei Technologies
+ Email: dhruv.ietf@gmail.com
+
+
+ Greg Mirsky
+ Ericsson
+ Email: gregimirsky@gmail.com
+
+
+Author's Address
+
+ Quan Xiong
+ ZTE Corporation
+ No.6 Huashi Park Rd
+ Wuhan
+ Hubei, 430223
+ China
+ Email: xiong.quan@zte.com.cn