Extension for Stateful PCE to allow Optional Processing of PCE Communication Protocol (PCEP) Objects
draft-ietf-pce-stateful-pce-optional-09

PCE Working Group                                                  C. Li
Internet-Draft                                                  H. Zheng
Updates: 8231 (if approved)                          Huawei Technologies
Intended status: Standards Track                            S. Litkowski
Expires: 18 October 2024                                           Cisco
                                                           16 April 2024

     Extension for Stateful PCE to allow Optional Processing of PCE
                 Communication Protocol (PCEP) Objects
                draft-ietf-pce-stateful-pce-optional-09

Abstract

   This document introduces a mechanism to mark some of the Path
   Computation Element (PCE) Communication Protocol (PCEP) objects as
   optional during PCEP messages exchange for the Stateful PCE model to
   allow relaxing some constraints during path computation and setup.
   This document introduces this relaxation to stateful PCE and updates
   RFC 8231.

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 18 October 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

Li, et al.               Expires 18 October 2024                [Page 1]
Internet-Draft                STATEFUL-OPT                    April 2024

   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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Usage Example . . . . . . . . . . . . . . . . . . . . . .   4
   3.  PCEP Extension  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . .   4
     3.2.  Handling of P flag  . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  The PCRpt Message . . . . . . . . . . . . . . . . . .   5
         3.2.1.1.  Delegation  . . . . . . . . . . . . . . . . . . .   5
       3.2.2.  The PCUpd Message and the PCInitiate Message  . . . .   6
     3.3.  Handling of I flag  . . . . . . . . . . . . . . . . . . .   6
       3.3.1.  The PCUpd Message . . . . . . . . . . . . . . . . . .   6
       3.3.2.  The PCRpt Message . . . . . . . . . . . . . . . . . .   7
       3.3.3.  The PCInitiate Message  . . . . . . . . . . . . . . .   7
     3.4.  Unknown Object Handling . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . .   8
   6.  Implementation Status . . . . . . . . . . . . . . . . . . . .   8
   7.  Manageability Considerations  . . . . . . . . . . . . . . . .   9
     7.1.  Control of Function and Policy  . . . . . . . . . . . . .   9
     7.2.  Information and Data Models . . . . . . . . . . . . . . .   9
     7.3.  Liveness Detection and Monitoring . . . . . . . . . . . .   9
     7.4.  Verify Correct Operations . . . . . . . . . . . . . . . .   9
     7.5.  Requirements On Other Protocols . . . . . . . . . . . . .   9
     7.6.  Impact On Network Operations  . . . . . . . . . . . . . .   9
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Appendix A.  Contributors . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   [RFC5440] describes the Path Computation Element Communication
   Protocol (PCEP) which enables communication between a Path
   Computation Client (PCC) and a Path Control Element (PCE), or between
   two PCEs based on the PCE architecture [RFC4655].

Li, et al.               Expires 18 October 2024                [Page 2]
Internet-Draft                STATEFUL-OPT                    April 2024

   PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of
   extensions to PCEP to enable active control of Multiprotocol Label
   Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS)
   tunnels.  [RFC8281] describes the setup and teardown of PCE-initiated
   LSPs under the active stateful PCE model, without the need for local
   configuration on the PCC, thus allowing for dynamic control.

   [RFC5440] defined the P flag (Processing-Rule) in the Common Object
   Header to allow a PCC to specify in a Path Computation Request
   (PCReq) message (sent to a PCE) whether the object must be taken into
   account by the PCE during path computation or is optional.  The I
   flag (Ignore) is used by the PCE in a Path Computation Reply (PCRep)
   message to indicate to a PCC whether or not an optional object was
   considered by the PCE during path computation.  Stateful PCE
   [RFC8231] specified that the P and I flags of the PCEP objects
   defined in [RFC8231] is to be set to zero on transmission and ignored
   on receipt, since they are exclusively related to the path
   computation requests.  The behaviour for P and I flag in other
   messages defined in [RFC5440] and other extension was not specified.
   This document specifies how the P and I flag could be used in the
   stateful PCE model to identify optional objects in the Path
   Computation State Report (PCRpt) [RFC8231], the Path Computation
   Update Request (PCUpd) [RFC8231], and the LSP Initiate Request
   (PCInitiate) [RFC8281] message.

   This document updates [RFC8231] concerning usage of the P and I flag
   as well as the handling of unknown objects in the stateful PCEP
   message exchange.

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

2.  Overview

   [RFC5440] describes the handling of unknown objects as per the
   setting of the P flag for the PCReq message.  Further, [RFC8231]
   defined the usage of the LSP Error Code TLV in the PCRpt message in
   response to failed LSP Update Request via the PCUpd message (for
   example, due to an unsupported object/TLV).

Li, et al.               Expires 18 October 2024                [Page 3]
Internet-Draft                STATEFUL-OPT                    April 2024

   This document specifies the procedure of marking some objects as
   'optional to be processed' by the PCEP peer in the stateful PCEP
   messages.  Furthermore, this document updates the procedure for
   handling unknown objects in the stateful PCEP messages based on the P
   flag.

2.1.  Usage Example

   The PCRpt message is used to report the current state of an LSP.  As
   part of the message both the <intended-attribute-list> and <actual-
   attribute-list> is encoded (see [RFC8231]).  For example, the
   <intended-attribute-list> could include the METRIC object to indicate
   a limiting constraint (Bound 'B' flag set) for the Path Delay
   Variation metric [RFC8233].  In some scenarios, it would be useful to
   state that this limiting constraint can be relaxed by the PCE in case
   it cannot find a path.  In these cases it would be useful to mark the
   objects as 'optional' and it could be ignored by the PCEP peer.
   Also, it would be useful for the PCEP speaker to learn if the PCEP
   peer has relaxed the constraint and ignored the processing of the
   PCEP object.

   Thus, this document specifies how the already existing P and I flag
   in the PCEP common object header could be used during the stateful
   PCEP message exchange.  Further, it should be noted that similar to
   handling of P and I flag in [RFC5440], the flag applies to full PCEP
   Object and could not be applied to the granularity of an optional
   TLVs encoded in the PCEP Object.

3.  PCEP Extension

3.1.  STATEFUL-PCE-CAPABILITY TLV

   A PCEP speaker indicates its ability to support the handling of the P
   and I flag in the stateful PCEP message exchange during the PCEP
   initialization phase, as follows.  During the PCEP initialization
   phase, a PCC sends an Open message with an OPEN object that contains
   the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231].  A new
   flag, the R (RELAX) flag, is added to this TLV to indicate the
   support for relaxing the processing of some objects via the use of
   the P and I flag in the PCEP common object header.

   R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag
   indicates that the PCEP Speaker is willing to handle the P and I
   flags in the PCEP common object header for the PCEP objects in the
   stateful PCEP messages.  In case the bit is unset, it indicates that
   the PCEP Speaker would not handle the P and I flags in the PCEP
   common object header for stateful PCE messages.

Li, et al.               Expires 18 October 2024                [Page 4]
Internet-Draft                STATEFUL-OPT                    April 2024

   The R flag MUST be set by both PCC and PCE to indicate support for
   the handling of the P and I flag in the PCEP common object header to
   allow relaxing some constraints by marking objects as 'optional to
   process'.  If the PCEP speaker did not set the R flag but receives
   PCEP objects with P or I bit set, it MUST behave as per the
   processing rule in [RFC8231].  Note that while [RFC8231] stated that
   P and I flags of the PCEP objects defined in [RFC8231] are set to 0
   on transmission and ignored on receipt, it did not say anything about
   already existing PCEP objects and thus the behaviour remained
   undefined.  To safely use this future, both peers need to set the R
   flag.

3.2.  Handling of P flag

3.2.1.  The PCRpt Message

   The P flag in the PCRpt message [RFC8231] allows a PCC to specify to
   a PCE whether the object must be taken into account by the PCE
   (during state maintenance, path computation, or re-optimisation) or
   is optional to process.  When the P flag is set in the PCRpt message
   received on a PCEP session on which the R bit was set by both peers,
   the object SHOULD be taken into account by the PCE.  Conversely, when
   the P flag is cleared, the object is optional and the PCE is free to
   ignore it.  The P flag for the mandatory objects such as the LSP and
   the ERO (Explicit Route Object) object (intended path) MUST be set in
   the PCRpt message.  If a mandatory object is received with the P flag
   set incorrectly according to the rules stated above, the receiving
   peer MUST send a PCErr message with Error-Type=10 (Reception of an
   invalid object) and Error-value=1 (reception of an object with P flag
   not set).  On a PCEP session on which R bit was set by both peers,
   the PCC SHOULD set the P flag by default, unless a local
   configuration or local policy indicates that some constraints
   (corresponding PCEP objects) can be marked as optional and could be
   ignored by the PCE or the object itself conveys informational
   parameters that can be safely ignored.

3.2.1.1.  Delegation

   Delegation is an operation to grant a PCE temporary rights to modify
   a subset of parameters on one or more LSPs by a PCC as described in
   [RFC8051].  Note that for the delegated LSPs, the PCE can update and
   mark some objects as ignored even when the PCC had set the P flag
   during the delegation.  Similarly, the PCE can update and mark some
   objects as a 'must to process' even when the PCC had not set the P
   flag during delegation.

Li, et al.               Expires 18 October 2024                [Page 5]
Internet-Draft                STATEFUL-OPT                    April 2024

   The PCC MUST acknowledge this by sending the PCRpt message with the P
   flag set as per the PCE expectation for the corresponding object.  In
   case PCC cannot accept this, it would react as per the processing
   rules of unacceptable update in [RFC8231].

3.2.2.  The PCUpd Message and the PCInitiate Message

   The P flag in the PCUpd message [RFC8231] and the PCInitiate message
   [RFC8281] allows a PCE to specify to a PCC whether the object must be
   taken into account by the PCC (during path setup) or is optional to
   process.  When the P flag is set in the PCUpd/PCInitiate message
   received on a PCEP session on which R bit was set by both peers, the
   object MUST be taken into account by the PCC.  Conversely, when the P
   flag is cleared, the object is optional and the PCC is free to ignore
   it.  The P flag for the mandatory objects such as the SRP (Stateful
   PCE Request Parameters), the LSP and the ERO MUST be set in the
   PCUpd/PCInitiate message.  If a mandatory object is received with the
   P flag set incorrectly according to the rules stated above, the
   receiving peer MUST send a PCErr message with Error-Type=10
   (Reception of an invalid object) and Error-value=1 (reception of an
   object with P flag not set).  On a PCEP session in which both peers
   set R bit, the PCE SHOULD set the P flag by default unless a local
   configuration/policy indicates that some constraints (corresponding
   PCEP objects) can be marked as optional and could be ignored by the
   PCC or the object itself conveys informational parameters that can be
   safely ignored.

3.3.  Handling of I flag

3.3.1.  The PCUpd Message

   The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to
   a PCC whether or not an optional object was processed.  The PCE MAY
   include the ignored optional object in its update request and set the
   I flag to indicate that the optional object was ignored.  When the I
   flag is cleared, the PCE indicates that the optional object was
   processed.

   Note that when a PCE is unable to find the path that meets all the
   constraints as per the PCEP Object that cannot be ignored (i.e.  the
   P flag is set), the PCUpd message MAY optionally include the PCEP
   Objects that caused the path computation to fail along with the empty
   ERO.

Li, et al.               Expires 18 October 2024                [Page 6]
Internet-Draft                STATEFUL-OPT                    April 2024

3.3.2.  The PCRpt Message

   The I flag in the PCRpt message [RFC8231] allows a PCC to indicate to
   a PCE whether or not an optional object was processed in response to
   an LSP Update Request (PCUpd) or LSP Initiate Request (PCInitiate).
   The PCC MAY include the ignored optional object in its report and set
   the I flag to indicate that the optional object was ignored at PCC.
   When the I flag is cleared, the PCC indicates that the optional
   object was processed.  The I flag has no meaning if the PCRpt message
   is not in response to a PCUpd or PCInitiate message (i.e. without the
   SRP object in the PCRpt message).

   Note that when a PCC is unable to set up the path that meets all the
   parameters as per the PCEP Object that cannot be ignored (i.e. the P
   flag is set), the PCRpt message MAY optionally include the PCEP
   Objects that caused the path setup to fail along with the LSP-ERROR-
   CODE TLV [RFC8231] indicating the reason for the failure.

3.3.3.  The PCInitiate Message

   The I flag has no meaning in the PCinitiate message [RFC8281] and is
   ignored.

3.4.  Unknown Object Handling

   This document updates the handling of unknown objects in the stateful
   PCEP messages as per the setting of the P flag in the common object
   header in a similar way as [RFC5440], i.e. if a PCEP speaker does not
   understand an object with the P flag set or understands the object
   but decides to ignore the object, the entire stateful PCEP message
   MUST be rejected and the PCE MUST send a PCErr message with Error-
   Type="Unknown Object" or "Not supported Object" [RFC5440].  In case
   the P flag is not set, the PCEP speaker is free to ignore the object
   and continue with the message processing as defined.

   [RFC8231] defined LSP Error Code TLV to be carried in PCRpt message
   in the LSP object to convey error information.  This document does
   not change that procedure.

4.  Security Considerations

   This document specifies how the already existing P and I flag in the
   PCEP common object header could be used during stateful PCEP
   exchanges.  It updates the unknown object error handling in stateful
   PCEP message exchange.  These changes on their own do not add any new
   security concerns.  The security considerations identified in
   [RFC5440], [RFC8231], and [RFC8281] continue to apply.

Li, et al.               Expires 18 October 2024                [Page 7]
Internet-Draft                STATEFUL-OPT                    April 2024

   As per [RFC8231], it is RECOMMENDED that these PCEP extensions can
   only be activated on authenticated and encrypted sessions across PCEs
   and PCCs belonging to the same administrative authority, using
   Transport Layer Security (TLS) [RFC8253] as per the recommendations
   and best current practices in [RFC9325] (unless explicitly set aside
   in [RFC8253]).

5.  IANA Considerations

5.1.  STATEFUL-PCE-CAPABILITY TLV

   [RFC8231] defined the STATEFUL-PCE-CAPABILITY TLV and IANA created
   the "STATEFUL-PCE-CAPABILITY TLV Flag Field" subregistry to manage
   the value of the STATEFUL-PCE-CAPABILITY TLV's Flag field.  IANA is
   requested to allocate a new bit in the subregistry, as follows:

   Bit       Description                 Reference
   -------------------------------------------------
   TBD1      RELAX bit                   [This-I.D.]

6.  Implementation Status

   [Note to the RFC Editor - remove this section before publication, as
   well as remove the reference to RFC 7942.]

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC7942].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC7942], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

Li, et al.               Expires 18 October 2024                [Page 8]
Internet-Draft                STATEFUL-OPT                    April 2024

   At the time of posting the -09 version of this document, there are no
   known implementations of this mechanism.  It is believed that some
   vendors are considering implementations, but these plans are too
   vague to make any further assertions.

7.  Manageability Considerations

7.1.  Control of Function and Policy

   An implementation supporting this document SHOULD allow configuration
   of the capability to support relaxation of constraints in the
   stateful PCEP message exchange.  They SHOULD also allow configuration
   of related LSP constraints (or parameters) that are optional to
   process.

7.2.  Information and Data Models

   An implementation supporting this document SHOULD allow the operator
   to view the capability defined in this document.  To serve this
   purpose, the PCEP YANG module [I-D.ietf-pce-pcep-yang] could be
   extended in the future.

7.3.  Liveness Detection and Monitoring

   Mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to those already
   listed in [RFC5440].

7.4.  Verify Correct Operations

   Mechanisms defined in this document do not imply any new operation
   verification requirements in addition to those already listed in
   [RFC5440].

7.5.  Requirements On Other Protocols

   Mechanisms defined in this document do not imply any new requirements
   on other protocols.

7.6.  Impact On Network Operations

   Mechanisms defined in this document do not have any impact on network
   operations in addition to those already listed in [RFC5440].

8.  Acknowledgments

   Thanks to Jonathan Hardwick for the discussion and suggestions around
   this draft.

Li, et al.               Expires 18 October 2024                [Page 9]
Internet-Draft                STATEFUL-OPT                    April 2024

   Thanks to Oscar Gonzalez de Dios, Mike Koldychev, Samuel Sidor, and
   Peng Shaofu for the review comments.

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

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

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

9.2.  Informative References

   [I-D.ietf-pce-pcep-yang]
              Dhody, D., Beeram, V. P., Hardwick, J., and J. Tantsura,
              "A YANG Data Model for Path Computation Element
              Communications Protocol (PCEP)", Work in Progress,
              Internet-Draft, draft-ietf-pce-pcep-yang-23, 18 March
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              pce-pcep-yang-23>.

Li, et al.               Expires 18 October 2024               [Page 10]
Internet-Draft                STATEFUL-OPT                    April 2024

   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
              Computation Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/info/rfc4655>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

   [RFC8051]  Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
              Stateful Path Computation Element (PCE)", RFC 8051,
              DOI 10.17487/RFC8051, January 2017,
              <https://www.rfc-editor.org/info/rfc8051>.

   [RFC8233]  Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
              "Extensions to the Path Computation Element Communication
              Protocol (PCEP) to Compute Service-Aware Label Switched
              Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
              2017, <https://www.rfc-editor.org/info/rfc8233>.

   [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.  Contributors

   Dhruv Dhody
   Huawei
   India

   Email: dhruv.ietf@gmail.com

Authors' Addresses

   Cheng Li
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing
   100095
   China
   Email: c.l@huawei.com

Li, et al.               Expires 18 October 2024               [Page 11]
Internet-Draft                STATEFUL-OPT                    April 2024

   Haomian Zheng
   Huawei Technologies
   H1, Huawei Xiliu Beipo Village, Songshan Lake
   Dongguan
   Guangdong, 523808
   China
   Email: zhenghaomian@huawei.com

   Stephane Litkowski
   Cisco
   Email: slitkows.ietf@gmail.com

Li, et al.               Expires 18 October 2024               [Page 12]