<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="utf-8"?>

<!-- updated by Sarah 01/03/24 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.3 (Ruby 3.0.2) -->
<?rfc tocompact="yes"?>
<?rfc tocindent="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ipr="trust200902"
number="9545"
docName="draft-ietf-spring-mpls-path-segment-22"
obsoletes=""
updates=""
category="std"
consensus="true"
submissionType="IETF"
tocDepth="3"
xml:lang="en"
tocInclude="true"
sortRefs="true"
symRefs="true"
version="3">
  <!-- xml2rfc v2v3 conversion 3.18.2 -->

  <front>
    <title abbrev="PSID in SR-MPLS">Path Segment Identifier in MPLS Based MPLS-Based Segment Routing Network</title> Networks</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-spring-mpls-path-segment-22"/> name="RFC" value="9545"/>
    <author initials="W." surname="Cheng" fullname="Weiqiang Cheng" role="editor">
      <organization>China Mobile</organization>
      <address>
        <email>chengweiqiang@chinamobile.com</email>
      </address>
    </author>
    <author initials="H." surname="Li" fullname="Han Li">
      <organization>China Mobile</organization>
      <address>
        <email>lihan@chinamobile.com</email>
      </address>
    </author>
    <author initials="C." surname="Li" fullname="Cheng Li" role="editor">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>c.l@huawei.com</email>
      </address>
    </author>
    <author initials="R." surname="Gandhi" fullname="Rakesh Gandhi">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <country>Canada</country>
        </postal>
        <email>rgandhi@cisco.com</email>
      </address>
    </author>
    <author initials="R." surname="Zigler" fullname="Royi Zigler">
      <organization>Broadcom</organization>
      <address>
        <email>royi.zigler@broadcom.com</email>
      </address>
    </author>

    <date year="2023" month="November" day="30"/>
    <area>Routing Area</area>
    <workgroup>SPRING Working Group</workgroup> year="2024" month="February"/>

    <area>rtg</area>
    <workgroup>spring</workgroup>

<keyword>Performance Measurement</keyword>
<keyword>Bidirectional SR Path</keyword>
<keyword>End-to-End Path Protection</keyword>
<keyword>SR Path Segment</keyword>
<keyword>Path Segment</keyword>

    <abstract>
      <?line 123?>
      <t>A Segment Routing (SR) path is identified by an SR segment list. A
sub-set
      subset of segments from the segment list cannot be leveraged to
      distinguish one SR path from another as they may be partially
      congruent. SR path identification is a pre-requisite prerequisite for various use-cases
      use cases such as Performance Measurement, performance measurement and end-to-end 1+1 path
      protection.</t>
      <t>In an SR for over MPLS (SR-MPLS) data plane (SR-MPLS), plane, an Egress egress node cannot determine
      on which SR path a packet traversed the network from the label stack
      because the segment identifiers are removed from the label stack as the
      packet transits the network.</t>
      <t>This document defines a Path Segment Identifier(PSID) Identifier (PSID) to identify an SR
      path on the egress node of the path.</t>
    </abstract>
  </front>
  <middle>
    <?line 135?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Segment Routing (SR) <xref target="RFC8402"/> leverages the source-routing paradigm to steer packets from a source node through a controlled set of instructions, called segments, "segments", by prepending the packet with an SR header. In SR with the MPLS data plane SR-MPLS <xref target="RFC8660"/> target="RFC8660"/>, the SR header is instantiated through a label stack.</t>
      <t>In an SR-MPLS network, when a packet is transmitted along an SR path, the labels in the MPLS label stack will be swapped or popped. The result of this is that no label or only the last label may be left in the MPLS label stack when the packet reaches the egress node. Thus, the egress node cannot use the SR label stack to determine along which SR path the packet came.</t>
      <t>However, identifying a path on the egress node is a pre-requisite prerequisite for various use-cases use cases in SR-MPLS networks, such as Performance Measurement performance measurement (<xref target="psid-for-pm"/>), bidirectional path paths (<xref target="psid-for-bpath"/>), and end-to-end 1+1 path protection (Live-Live (a Live-Live case) (<xref target="psid-for-protection"/>).</t>
      <t>Therefore, this document defines a new segment type, referred to herein as a Path Segment. "Path Segment". A Path Segment is defined to uniquely identify an SR path on the egress node of the path. It <bcp14>MAY</bcp14> be used by the egress node for path identification. Note that, that per-path state will be maintained in the egress node due to the requirements in the aforementioned use cases, though in normal cases that cases, the per-path state will be maintained in the ingress node only.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>
        <?line -18?> here.
        </t>

</section>
      <section anchor="abbreviations-and-terms">
        <name>Abbreviations and Terms</name>
        <t>MPLS: Multiprotocol
<dl>
          <dt>MPLS:</dt><dd>Multiprotocol Label Switching.</t>
        <t>SR: Switching</dd>
          <dt>PSID:</dt><dd>Path Segment Routing.</t>
        <t>SID: Segment Identifier.</t>
        <t>SR-MPLS: Instantiation of SR on the MPLS data plane.</t>
        <t>SR path: A SR path is a Identifier</dd>
          <dt>SID:</dt><dd>Segment Identifier</dd>
          <dt>SR:</dt><dd>Segment Routing</dd>
          <dt>SR-MPLS:</dt><dd>SR over MPLS</dd>
          <dt>SR path:</dt><dd>A path described by a Segment-List.</t>
        <t>Sub-Path: A sub-path is a segment list.</dd>
          <dt>Sub-Path:</dt><dd>A part of a path, which contains a sub-set subset of
          the nodes and links of the path.</t>
        <t>PSID: Path Segment Identifier.</t> path.</dd>
	</dl>
      </section>
    </section>
    <section anchor="path-segment">
      <name>Path Segment</name>
      <t>A Path Segment is a Local Segment local segment <xref target="RFC8402"/> which that uniquely identifies an SR path on the egress node. A Path Segment Identifier(PSID) Identifier (PSID) is a single label that is assigned from the Segment Routing Local Block (SRLB) <xref target="RFC8402"/> of the egress node of an SR path.</t>
      <t>A PSID is used to identify a Segment List. segment list. However, one PSID can be used to identify multiple Segment Lists segment lists in some use cases if needed. For example, one single PSID <bcp14>MAY</bcp14> be used to identify some or all Segment segment lists in a Candidate candidate path or an SR policy, policy if an operator would like to aggregate these Segment Lists segment lists in operation.</t>
      <t>When a PSID is used, the PSID can be inserted at the ingress node and <bcp14>MUST</bcp14> immediately follow the last label of the SR path, path; in other words, it must be inserted after the routing segment (adjacency/node/prefix (adjacency, node, or prefix segment) that is pointing to the egress node of the SR path. Therefore, a PSID will not be the top label in the label stack when received on an intermediate node of the associated path, but it can be the top label in the label stack on the penultimate node.</t>
      <t>The value of the TTL field in the MPLS label stack entry containing a PSID can be set to any value except 0. If a PSID is the bottom label, the S bit <bcp14>MUST</bcp14> be set, and if the PSID is NOT the bottom label, the S bit <bcp14>MUST</bcp14> be 0.</t>
      <t>The egress node <bcp14>MUST</bcp14> pop the PSID. The egress node <bcp14>MAY</bcp14> use the PSID for further processing. For example, when performance measurement is enabled on the SR path, it can trigger packet counting or timestamping.</t>
      <t>The addition of the PSID will require the egress to read and process the PSID label in addition to the regular processing. This additional processing may have an impact on forwarding performance. Behavior relating to the use of explicit null directly preceding the PSID is undefined in this document.</t>
      <t>Generic
      <t>A Generic Associated Channel Label (GAL) <bcp14>MAY</bcp14> be used for Operations, Administration Administration, and Maintenance (OAM) in MPLS networks. As per <xref target="RFC5586"/>, when a GAL is used, the ACH Associated Channel Header (ACH) appears immediately after the bottom of the label stack.</t>
      <t>The SR path computation needs to know the Maximum SID Depth (MSD) that can be imposed at the ingress node of a given SR path <xref target="RFC8664"/>. This ensures that the SID stack depth of a computed path does not exceed the number of SIDs the node is capable of imposing. As per <xref target="RFC8491"/> target="RFC8491"/>, the MSD signals the total number of MPLS labels that can be imposed, where the total number of MPLS labels includes the PSID.</t>
      <t>An example label stack with a PSID is shown in <xref target="figure1"/>:</t>
      <figure anchor="figure1">
        <name>Label Stack with a PSID</name>
        <artwork><![CDATA[
            +--------------------+
            |       ...          |
            +--------------------+
            |      Label 1       |
            +--------------------+
            |      Label 2       |
            +--------------------+
            |       ...          |
            +--------------------+
            |      Label n       |
            +--------------------+
            |        PSID        |
            +--------------------+
            ~       Payload      ~
            +--------------------+
]]></artwork>
      </figure>
      <t>Where:</t>
      <ul spacing="normal">
        <li>
          <t>The Labels 1 to n are the segment label stack used to direct how
to steer the packets along the SR path.</t>
        </li>
        <li>
          <t>The PSID identifies the SR path in the context of the egress node of the SR path.</t>
        </li>
      </ul>
      <t>Signaling
      <t>The signaling of the PSID between the egress node, the ingress node node, and possibly a centralized controller is out of the scope of this document.</t>
      <section anchor="equal-cost-multipathecmp-considerations">
        <name>Equal-Cost Multipath(ECMP) Multipath (ECMP) Considerations</name>
        <t>If an Entropy Label(EL) Label (EL) is also used on the egress node, as per <xref target="RFC6790"/> target="RFC6790"/>, the Entropy label Indicator (ELI) EL and Entropy Label (EL) Indicator (ELI) would be placed before the tunnel label and hence does label; hence, they do not interfere with the PSID PSID, which is placed below.</t>
        <t>It is worthy to note that in the case of ECMP, with or without the use of an EL, the SR packets may be forwarded over multiple paths. In this case, the SID list cannot directly reflect the actual forwarding path and the PSID can only identify the SID list rather than the actual forwarding path.</t>
        <t>Also, similar to a Synonymous Flow Labels(SFL) Label (SFL) <xref target="RFC8957"/>, the introduction of an a PSID to an existing flow may cause that flow to take a different path through the network under the conditions of Equal-Cost Multipath. This, in ECMP. In turn, this may invalidate certain uses of the PSID, such as performance measurement applications. Therefore, the considerations of SFLs as per section 5 in <xref section="5" sectionFormat="of" target="RFC8957"/> of SFL also apply to PSID PSIDs in implementation.</t>
      </section>
    </section>
    <section anchor="use-cases">
      <name>Use cases</name> Cases</name>
      <t>This section describes use cases which that can leverage the PSID. The content is for informative purpose, purposes, and the detailed solutions might be defined in other documents in the future.</t>
      <section anchor="psid-for-pm">
        <name>PSID for Performance Measurement</name>
        <t>As defined in <xref target="RFC7799"/>, performance measurement can
be classified into Passive, Active, and Hybrid measurement. measurements. Since a PSID is encoded in the SR-MPLS Label Stack label stack, as shown in Figure 1, <xref target="figure1"/>,
existing implementation implementations on the egress node can leverage a PSID for
measuring packet counts.</t>
        <t>For Passive performance measurement, path identification at the
measuring points is the pre-requisite. prerequisite. A PSID can be used by the
measuring points (e.g., the ingress and egress nodes of the SR path or a
centralized controller) to correlate the packet counts and timestamps
from the ingress and egress nodes for a specific SR path, then path; then, packet
loss and delay can be calculated for the end-to-end path, respectively.</t>
        <t>Furthermore, a PSID can also be used for:</t>
        <ul spacing="normal">
          <li>
            <t>Active Performance Measurement performance measurement for
an SR path in SR-MPLS networks for collecting packet counters and
timestamps from the egress node using probe messages.</t>
          </li>
          <li>
            <t>In-situ OAM<xref
            <t>In situ OAM <xref target="RFC9197"/> for SR-MPLS to identify
the SR Path path associated with the in-situ in situ data fields in the data packets
on the egress node.</t>
          </li>
          <li>
            <t>In-band Performance Measurement performance measurement for SR-MPLS to identify
the SR Path path associated with the collected performance metrics.</t>
          </li>
        </ul>
      </section>
      <section anchor="psid-for-bpath">
        <name>PSID for Bidirectional SR Path</name> Paths</name>
        <t>In some scenarios, for example, scenarios (e.g., mobile backhaul transport networks, networks),
there are requirements to support bidirectional paths<xref paths <xref target="RFC6965"/>, and the path is
normally treated as a single entity. Forward and reverse directions of the path
have the same fate, fate; for example, failure in one direction will result in
switching traffic at both directions. MPLS supports this by introducing
the concepts of a co-routed bidirectional LSP Label Switched Path (LSP) and an associated bidirectional
LSP <xref target="RFC5654"/>.</t>
        <t>In the current SR architecture, an SR path is a unidirectional path
<xref target="RFC8402"/>.
In order to support bidirectional SR paths, a straightforward way is
to bind two unidirectional SR paths to a single bidirectional SR
path. PSIDs can be used to identify and correlate the
traffic for the two unidirectional SR paths at both ends of the
bidirectional path.</t>
        <t>The mechanism of constructing bidirectional path paths using a PSID is out of the scope of this document and has been described in several documents, such as <xref target="I-D.ietf-pce-sr-bidir-path"/> and <xref target="I-D.ietf-idr-sr-policy-path-segment"/>.</t>
      </section>
      <section anchor="psid-for-protection">
        <name>PSID for End-to-end End-to-End Path Protection</name>
        <t>For end-to-end 1+1 path protection (i.e., a Live-Live case), the egress
node of the path needs to know the set of paths that constitute the
primary and the secondaries, secondaries in order to select the primary path packets
for onward transmission, transmission and to discard the packets from the secondaries <xref target="RFC4426"/>.</t>
        <t>To do this in Segment Routing, SR, each SR path needs a path identifier
that is unique at the egress node. For SR-MPLS, this can be the Path
Segment label allocated by the egress node.</t>
        <t>The detailed solution of using a PSID in end-to-end 1+1 path protection is out of the scope of this document.</t>
      </section>
      <section anchor="psid-nesting">
        <name>Nesting of PSIDs</name>
        <t>Binding
        <t>A Binding SID (BSID) <xref target="RFC8402"/> can be used for SID list
compression. With a BSID, an end-to-end SR path in a trusted domain can be split into several
sub-paths, where each sub-path is identified by a BSID. Then Then, an end-to-end SR
path can be identified by a list of BSIDs, BSIDs; therefore, it can provide
better scalability.</t>
        <t>BSID
        <t>A BSID and a PSID can be combined to achieve both sub-path and
end-to-end path monitoring. A reference model for such a combination in
(Figure 2) (<xref target="figure2"/>) shows
an end-to-end path (A-&gt;D) in a trusted domain that spans three subdomains
(Access, Aggregation
(the Access, Aggregation, and Core domain) domains) and consists of three sub-paths,
one in each subdomain (sub-path (A-&gt;B), sub-path (B-&gt;C) (B-&gt;C), and
sub-path (C-&gt;D)).</t>
        <t>The SID list of a sub-path can be expressed as &lt;SID1, SID2, ...SIDn, ..., SIDn, s-PSID&gt;, where the s-PSID is the PSID of the sub-path. Each sub-path is associated with a BSID and an s-PSID.</t>
        <t>The SID list of the end-to-end path can be expressed as &lt;BSID1, BSID2, ..., BSIDn, e-PSID&gt;, where the e-PSID is the PSID of the end-to-end path.</t>
        <t><xref target="figure2"/> shows the details of the label stacks when a PSID and a BSID are
used to support both sub-path and end-to-end path monitoring in a
	multi-domain scenario.</t>
        <figure anchor="figure2">
          <name>Nesting of PSIDs</name>
          <artwork><![CDATA[
         /--------\       /--------\       /--------\
       /            \   /            \   /            \
     A{    Access    }B{  Aggregation }C{     Core     }D
       \            /   \            /   \            /
         \--------/       \--------/       \--------/
       Sub-path(A->B)    Sub-path(B->C)   Sub-path(C->D)
       sub-path(A->B)    sub-path(B->C)   sub-path(C->D)
    |<--------------->|<-------------->|<-------------->|
                          E2E Path(A->D)
    |<------------------------------------------------->|

 +------------+

 +-------------+
 ~A->B SubPath~
 +------------+  +------------+
 |s-PSID(A->B)| sub-path~
 +-------------+  +-------------+
 |s-PSID(A->B) |  ~B->C SubPath~
 +------------+  +------------+  +------------+ sub-path~
 +-------------+  +-------------+  +-------------+
 | BSID(B->C)  |  |s-PSID(B->C)|  |s-PSID(B->C) |  ~C->D SubPath~
 +------------+  +------------+  +------------+ sub-path~
 +-------------+  +-------------+  +-------------+
 | BSID(C->D)  |  | BSID(C->D)  |  |s-PSID(C->D)|
 +------------+  +------------+  +------------+  |s-PSID(C->D) |
 +-------------+  +-------------+  +-------------+  +------------+
 |e-PSID(A->D) |  |e-PSID(A->D) |  |e-PSID(A->D) |  |e-PSID(A->D)|  |e-PSID(A->D)|  |e-PSID(A->D)|  |e-PSID(A->D)|
 +------------+  +------------+  +------------+
 +-------------+  +-------------+  +-------------+  +------------+
]]></artwork>
        </figure>
      </section>
    </section>
    <section anchor="Security">
      <name>Security Considerations</name>
      <t>A PSID in SR-MPLS is a local label similar to other labels/Segment, labels and segments, such as a VPN label, defined in MPLS and SR-MPLS. The data plane processing of a PSID is a local implementation of an ingress node, node or an egress node, which follows the same logic of an existing MPLS dataplane. data plane. As per the definition of a PSID, only the egress node and the ingress node of the associated path will learn the information of a PSID. The intermediate nodes of this path will not learn it.</t>
      <t>A PSID may be used on an ingress node that is not the ingress of the associated path, path if the associated label stack with the PSID is part of a deeper label stack which that represents a longer path. For example example, the case described in <xref target="psid-nesting"/> and the related BSID is are not used while the original label stack of a sub-path is inserted as a part of the whole label stack. In this case, the PSID must be distributed in a trusted domain under the considerations defined in <xref section="8.1" sectionFormat="of" target="RFC8402"/>.</t>
      <t>A PSID is used within an SR-MPLS trusted domain <xref target="RFC8402"/> and must not leak outside the domain, therefore domain; therefore, no new security threats are introduced comparing compared to current SR-MPLS. As per <xref target="RFC8402"/>, SR domain boundary routers <bcp14>MUST</bcp14> filter any external traffic destined
   to a label associated with a segment within the trusted domain, domain; this applies to a PSID as well. Other security considerations of SR-MPLS, SR-MPLS described in <xref section="8.1" sectionFormat="of" target="RFC8402"/> applies apply to this document.</t>
      <t>The distribution of a PSID from an egress node to an ingress nodes node is performed within an SR trusted SR-trusted domain, and it is out of the scope of this document. The details of the mechanism and related security considerations will be described in other documents.</t>
    </section>

    <section anchor="implementation-status">
      <name>Implementation Status</name>
      <t>[Note to the RFC Editor - remove this section before publication, as well as remove the reference to <xref target="RFC7942"/>.</t>
      <t>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 <xref target="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.</t>
      <t>According to <xref target="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".</t>
      <section anchor="huawei-technologies">
        <name>Huawei Technologies</name>
        <ul spacing="normal">
          <li>
            <t>Organization: Huawei Technologies.</t>
          </li>
          <li>
            <t>Implementation: Huawei PTN7900 Series Routers implementation of SR-TP<xref target="HW-IMP"/>.</t>
          </li>
          <li>
            <t>Description: SR-TP is a feature of Huawei PTN7900 series Routers, which uses PSIDs to associate with paths and build up bidirectional paths. Huawei PTN7900 Series Routers with version V100R018C00 and above have commercially implemented the definition of PSID and use cases which is defined in section 2 and Section 3.2 in this document, including all the "<bcp14>MUST</bcp14>" and "<bcp14>SHOULD</bcp14>" clauses, while other use cases for PSID in section 3 are not yet implemented. For control plane, PTN7900 Series Routers support configuring PSID using NETCONF.</t>
          </li>
          <li>
            <t>Maturity Level: Product</t>
          </li>
          <li>
            <t>Coverage: Partial, section 2 and use case section 3.2.</t>
          </li>
          <li>
            <t>Version: Draft-12</t>
          </li>
          <li>
            <t>Licensing: N/A</t>
          </li>
          <li>
            <t>Implementation experience: Nothing specific.</t>
          </li>
          <li>
            <t>Contact: li.fan@huawei.com</t>
          </li>
          <li>
            <t>Last updated: September 14, 2023</t>
          </li>
        </ul>
      </section>
      <section anchor="zte-corp">
        <name>ZTE Corp</name>
        <ul spacing="normal">
          <li>
            <t>Organization: ZTE Corporation.</t>
          </li>
          <li>
            <t>Implementation: ZTE's SPN implementation of PSID<xref target="ZTE-IMP"/>.</t>
          </li>
          <li>
            <t>Description: The feature of SR-MPLS PSID has been implemented in ZTE SPN products and follows the definition and mechanism as defined in section 2 and Section 3.2 including all the "<bcp14>MUST</bcp14>" and "<bcp14>SHOULD</bcp14>" clauses while other use cases for PSID in section 3 are not yet implemented.</t>
          </li>
          <li>
            <t>Maturity Level: Product</t>
          </li>
          <li>
            <t>Coverage: Partial,section 2 and use case section 3.2.</t>
          </li>
          <li>
            <t>Version: Draft-12</t>
          </li>
          <li>
            <t>Licensing: N/A</t>
          </li>
          <li>
            <t>Implementation experience: Nothing specific.</t>
          </li>
          <li>
            <t>Contact: liu.aihua@zte.com.cn</t>
          </li>
          <li>
            <t>Last updated: September 21, 2023</t>
          </li>
        </ul>
      </section>
      <section anchor="new-h3c-technologies">
        <name>New H3C Technologies</name>
        <ul spacing="normal">
          <li>
            <t>Organization: New H3C Technologies.</t>
          </li>
          <li>
            <t>Implementation: H3C CR16000, CR19000 series routers implementation of PSID.</t>
          </li>
          <li>
            <t>Description: Section 2 and Section 3.2 including all the "<bcp14>MUST</bcp14>" and "<bcp14>SHOULD</bcp14>" clauses have been implemented in above-mentioned New H3C Products(running Version 7.1.086 and above) for testing, while other use cases for PSID in section 3 are not yet implemented.</t>
          </li>
          <li>
            <t>Maturity Level: Beta</t>
          </li>
          <li>
            <t>Coverage: Partial, section 2 and use case section 3.2.</t>
          </li>
          <li>
            <t>Version: Draft-12</t>
          </li>
          <li>
            <t>Licensing: N/A</t>
          </li>
          <li>
            <t>Implementation experience: Nothing specific.</t>
          </li>
          <li>
            <t>Contact: linchangwang.04414@h3c.com</t>
          </li>
          <li>
            <t>Last updated: September 13, 2023</t>
          </li>
        </ul>
      </section>
      <section anchor="spirent-communications">
        <name>Spirent Communications</name>
        <ul spacing="normal">
          <li>
            <t>Organization: Spirent Communications</t>
          </li>
          <li>
            <t>Implementation: Spirent Testcenter Product Family implementation of SR-TP test capability<xref target="SP-IMP"/>.</t>
          </li>
          <li>
            <t>Description: Spirent Testcenter product family implements SR-MPLS PSID test capabilities on the versions above Spirent Testcenter 4.85. Spirent Testcenter fully support testing all clauses defined in section 2 and Section 3.1,3.2,3.4 , including all the "<bcp14>MUST</bcp14>" and "<bcp14>SHOULD</bcp14>" clauses, and partially support the test of clauses in section 3.3.</t>
          </li>
          <li>
            <t>Maturity Level: Production</t>
          </li>
          <li>
            <t>Coverage: fully cover section 2 and use case section 3.1,3.2, 3.4, partially cover section 3.3</t>
          </li>
          <li>
            <t>Version: Draft-12</t>
          </li>
          <li>
            <t>Licensing: N/A</t>
          </li>
          <li>
            <t>Implementation experience: Nothing specific.</t>
          </li>
          <li>
            <t>Contact: junqi.zhao@spirent.com</t>
          </li>
          <li>
            <t>Last updated: September 21, 2023</t>
          </li>
        </ul>
      </section>
      <section anchor="fiberhome">
        <name>Fiberhome</name>
        <ul spacing="normal">
          <li>
            <t>Organization: Fiberhome Corporation.</t>
          </li>
          <li>
            <t>Implementation: Fiberhome SPN series of products (Citrans 650/690E) implementation of PSID<xref target="FH-IMP"/>.</t>
          </li>
          <li>
            <t>Description: SR-TP is a feature of SPN products, which realizes a controllable L3 tunnel, builds the end-to-end L3 deployment business model. The PSID follows the definition and mechanism as defined in section 2 and Section 3.2 including all the "<bcp14>MUST</bcp14>" and "<bcp14>SHOULD</bcp14>" clauses had been implemented, while other use cases for PSID in section 3 are not yet implemented.</t>
          </li>
          <li>
            <t>Maturity Level: Product</t>
          </li>
          <li>
            <t>Coverage: Partial,section 2 and use case section 3.2.</t>
          </li>
          <li>
            <t>Version: Draft-12</t>
          </li>
          <li>
            <t>Licensing: N/A</t>
          </li>
          <li>
            <t>Implementation experience: Nothing specific.</t>
          </li>
          <li>
            <t>Contact: zhhan@fiberhome.com</t>
          </li>
          <li>
            <t>Last updated: September 21, 2023</t>
          </li>
        </ul>
      </section>
      <section anchor="interoperability-test">
        <name>Interoperability Test</name>
        <t>[Note to the RFC Editor - remove this section before publication, as well as remove the reference to <xref target="RFC7942"/>.</t>
        <t>The Interoperability test of PSID had been done among products from several vendors, including Huawei(PTN7900, V100R018C00), ZTE(ZXCTN 6180, Ver 4.00.00), FiberHome(Citrans 650/690E) , Spirent (Chassis: SPT-N4U-220.Test. Module: PX3-QSFP28-12-225A. Version: 4.86) and Nokia in 2018<xref target="INTEROP-TEST"/>. Note that PSID is a key feature of Layer3 in SPN architecture <xref target="SPN-L3"/>. This is reported by Weiqiang Cheng from China Mobile at September, 21, 2023.</t>
      </section>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>This document does not require any has no IANA actions.</t>
    </section>
  </middle>

  <back>
    <displayreference target="I-D.ietf-pce-sr-bidir-path" to="BIDIR-PATH"/>
    <displayreference target="I-D.ietf-idr-sr-policy-path-segment" to="SR-EXTENSIONS"/>

    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC8402">
          <front>
            <title>Segment Routing Architecture</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <date month="July" year="2018"/>
            <abstract>
              <t>Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
              <t>SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.</t>
              <t>SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8402"/>
          <seriesInfo name="DOI" value="10.17487/RFC8402"/>
        </reference>
        <reference anchor="RFC8660">
          <front>
            <title>Segment Routing with the MPLS Data Plane</title>
            <author fullname="A. Bashandy" initials="A." role="editor" surname="Bashandy"/>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <date month="December" year="2019"/>
            <abstract>
              <t>Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8660"/>
          <seriesInfo name="DOI" value="10.17487/RFC8660"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>

      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC4426">
          <front>
            <title>Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification</title>
            <author fullname="J. Lang" initials="J." role="editor" surname="Lang"/>
            <author fullname="B. Rajagopalan" initials="B." role="editor" surname="Rajagopalan"/>
            <author fullname="D. Papadimitriou" initials="D." role="editor" surname="Papadimitriou"/>
            <date month="March" year="2006"/>
            <abstract>
              <t>This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4426"/>
          <seriesInfo name="DOI" value="10.17487/RFC4426"/>
        </reference>
        <reference anchor="RFC5586">
          <front>
            <title>MPLS Generic Associated Channel</title>
            <author fullname="M. Bocci" initials="M." role="editor" surname="Bocci"/>
            <author fullname="M. Vigoureux" initials="M." role="editor" surname="Vigoureux"/>
            <author fullname="S. Bryant" initials="S." role="editor" surname="Bryant"/>
            <date month="June" year="2009"/>
            <abstract>
              <t>This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5586"/>
          <seriesInfo name="DOI" value="10.17487/RFC5586"/>
        </reference>
        <reference anchor="RFC5654">
          <front>
            <title>Requirements of an MPLS Transport Profile</title>
            <author fullname="B. Niven-Jenkins" initials="B." role="editor" surname="Niven-Jenkins"/>
            <author fullname="D. Brungard" initials="D." role="editor" surname="Brungard"/>
            <author fullname="M. Betts" initials="M." role="editor" surname="Betts"/>
            <author fullname="N. Sprecher" initials="N." surname="Sprecher"/>
            <author fullname="S. Ueno" initials="S." surname="Ueno"/>
            <date month="September" year="2009"/>
            <abstract>
              <t>This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T).</t>
              <t>This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.</t>
              <t>The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5654"/>
          <seriesInfo name="DOI" value="10.17487/RFC5654"/>
        </reference>
        <reference anchor="RFC6790">
          <front>
            <title>The Use of Entropy Labels in MPLS Forwarding</title>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="S. Amante" initials="S." surname="Amante"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="L. Yong" initials="L." surname="Yong"/>
            <date month="November" year="2012"/>
            <abstract>
              <t>Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6790"/>
          <seriesInfo name="DOI" value="10.17487/RFC6790"/>
        </reference>
        <reference anchor="RFC6965">
          <front>
            <title>MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design</title>
            <author fullname="L. Fang" initials="L." role="editor" surname="Fang"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="R. Zhang" initials="R." surname="Zhang"/>
            <author fullname="M. Daikoku" initials="M." surname="Daikoku"/>
            <author fullname="P. Pan" initials="P." surname="Pan"/>
            <date month="August" year="2013"/>
            <abstract>
              <t>This document describes the applicability of the MPLS Transport Profile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, mobile backhaul, and packet optical transport.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6965"/>
          <seriesInfo name="DOI" value="10.17487/RFC6965"/>
        </reference>
        <reference anchor="RFC8664">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing</title>
            <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="J. Hardwick" initials="J." surname="Hardwick"/>
            <date month="December" year="2019"/>
            <abstract>
              <t>Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.</t>
              <t>This document updates RFC 8408.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8664"/>
          <seriesInfo name="DOI" value="10.17487/RFC8664"/>
        </reference>
        <reference anchor="RFC7799">
          <front>
            <title>Active and Passive Metrics and Methods (with Hybrid Types In-Between)</title>
            <author fullname="A. Morton" initials="A." surname="Morton"/>
            <date month="May" year="2016"/>
            <abstract>
              <t>This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7799"/>
          <seriesInfo name="DOI" value="10.17487/RFC7799"/>
        </reference>
        <reference anchor="RFC7942">
          <front>
            <title>Improving Awareness of Running Code: The Implementation Status Section</title>
            <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <date month="July" year="2016"/>
            <abstract>
              <t>This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. 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.</t>
              <t>This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="205"/>
          <seriesInfo name="RFC" value="7942"/>
          <seriesInfo name="DOI" value="10.17487/RFC7942"/>
        </reference>
        <reference anchor="RFC8957">
          <front>
            <title>Synonymous Flow Label Framework</title>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <author fullname="M. Chen" initials="M." surname="Chen"/>
            <author fullname="G. Swallow" initials="G." surname="Swallow"/>
            <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <date month="January" year="2021"/>
            <abstract>
              <t>RFC 8372 ("MPLS Flow Identification Considerations") describes the requirement for introducing flow identities within the MPLS architecture. This document describes a method of accomplishing this by using a technique called "Synonymous Flow Labels" in which labels that mimic the behavior of other labels provide the identification service. These identifiers can be used to trigger per-flow operations on the packet at the receiving label switching router.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8957"/>
          <seriesInfo name="DOI" value="10.17487/RFC8957"/>
        </reference>
        <reference anchor="RFC8491">
          <front>
            <title>Signaling Maximum SID Depth (MSD) Using IS-IS</title>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="U. Chunduri" initials="U." surname="Chunduri"/>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <date month="November" year="2018"/>
            <abstract>
              <t>This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8491"/>
          <seriesInfo name="DOI" value="10.17487/RFC8491"/>
        </reference>
        <reference anchor="RFC9197">
          <front>
            <title>Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)</title>
            <author fullname="F. Brockners" initials="F." role="editor" surname="Brockners"/>
            <author fullname="S. Bhandari" initials="S." role="editor" surname="Bhandari"/>
            <author fullname="T. Mizrahi" initials="T." role="editor" surname="Mizrahi"/>
            <date month="May" year="2022"/>
            <abstract>
              <t>In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9197"/>
          <seriesInfo name="DOI" value="10.17487/RFC9197"/>
        </reference>
        <reference anchor="I-D.ietf-pce-sr-bidir-path">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) Paths</title>
            <author fullname="Cheng Li" initials="C." surname="Li">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Mach Chen" initials="M." surname="Chen">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Quan Xiong" initials="Q." surname="Xiong">
              <organization>ZTE Corporation</organization>
            </author>
            <date day="9" month="September" year="2023"/>
            <abstract>
              <t>   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 grouping two unidirectional
   SR Paths (one in each direction in the network) into a single
   associated bidirectional SR Path.  The mechanisms defined in this
   document can also be applied using a stateful PCE for both PCE-
   initiated and PCC-initiated LSPs or when using a stateless PCE.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-pce-sr-bidir-path-12"/>
        </reference>
        <reference anchor="I-D.ietf-idr-sr-policy-path-segment">
          <front>
            <title>SR Policy Extensions for Path Segment and Bidirectional Path</title>
            <author fullname="Cheng Li" initials="C." surname="Li">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Zhenbin Li" initials="Z." surname="Li">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Yuanyang Yin" initials="Y." surname="Yin">
              <organization>China Telecom</organization>
            </author>
            <author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar">
              <organization>Cisco Systems</organization>
            </author>
            <date day="16" month="August" year="2023"/>
            <abstract>
              <t>   A Segment Routing (SR) policy is a set of candidate SR paths
   consisting of one or more segment lists with necessary path
   attributes.  For each SR path, it may also have its own path
   attributes, and Path Segment is one of them.  A Path Segment is
   defined to identify an SR path, which can be used for performance
   measurement, path correlation, and end-2-end path protection.  Path
   Segment can be also used to correlate two unidirectional SR paths
   into a bidirectional SR path which is required in some scenarios, for
   example, mobile backhaul transport network.

   This document defines extensions to BGP to distribute SR policies
   carrying Path Segment and bidirectional path information.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-sr-policy-path-segment-08"/>
        </reference>
        <reference anchor="HW-IMP" target="https://carrier.huawei.com/en/products/fixed-network/carrier-ip/router/ptn/ptn7900">
          <front>
            <title>Huawei PTN7900 Routers</title>
            <author>
              <organization/>
            </author>
            <date year="2021" month="September" day="21"/>
          </front>
        </reference>
        <reference anchor="ZTE-IMP" target="https://www.zte.com.cn/china/product_index/ip_network/item01/zxctn-6700/zxctn_6700.html">
          <front>
            <title>ZTE ZXCTN-6700 Routers</title>
            <author>
              <organization/>
            </author>
            <date year="2021" month="September" day="21"/>
          </front>
        </reference>
        <reference anchor="FH-IMP" target="https://www.fiberhome.com/operator/product/products/294.aspx.html">
          <front>
            <title>Fiberhome Routers</title>
            <author>
              <organization/>
            </author>
            <date year="2021" month="September" day="21"/>
          </front>
        </reference>
        <reference anchor="SP-IMP" target="https://www.spirent.com/assets/u/flexe-test-solution-for-5g-backhaul">
          <front>
            <title>Spirent Devices</title>
            <author>
              <organization/>
            </author>
            <date year="2021" month="September" day="21"/>
          </front>
        </reference>
        <reference anchor="INTEROP-TEST" target="http://www.cww.net.cn/web/news/channel/articleinfo.action?id=452789">
          <front>
            <title>Adhering to Innovation-Driven Development and Focusing on Technological Breakthroughs--China Mobile Research Institute Accelerates 5G R&amp;D and Tests</title>
            <author>
              <organization>China Mobile</organization>
            </author>
            <date year="2019" month="May" day="30"/>
          </front>
        </reference>
        <reference anchor="SPN-L3" target="https://opennetworking.org/wp-content/uploads/2018/12/The-transport-network-consi-deration-for-5G-in-CMCC.pdf">
          <front>
            <title>The-transport-network-consi-deration-for-5G-in-CMCC</title>
            <author>
              <organization>China Mobile</organization>
            </author>
            <date year="2018" month="December" day="01"/>
          </front>
        </reference>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4426.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5586.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5654.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6965.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8957.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8491.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml"/>

<!-- [I-D.ietf-pce-sr-bidir-path] IESG State: I-D Exists-->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-pce-sr-bidir-path.xml"/>

<!-- [I-D.ietf-idr-sr-policy-path-segment] IESG State: I-D Exists-->
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-sr-policy-path-segment.xml"/>

      </references>
    </references>
    <?line 505?>

<section numbered="false" anchor="Acknowledgements">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Adrian Farrel, Stewart Bryant,
Shuangping Zhan, Alexander Vainshtein, Andrew <contact fullname="Adrian Farrel"/>, <contact
      fullname="Stewart Bryant"/>, <contact fullname="Shuangping
      Zhan"/>, <contact fullname="Alexander
      Vainshtein"/>, <contact fullname="Andrew
      G. Malis, Ketan
Talaulikar, Shraddha Hegde, Xinyue Zhang, Loa Andersson Malis"/>, <contact fullname="Ketan
      Talaulikar"/>, <contact fullname="Shraddha
      Hegde"/>, <contact fullname="Xinyue Zhang"/>, <contact
      fullname="Loa Andersson"/>, and Bruno Decraene <contact fullname="Bruno Decraene"/> for their
      review, suggestions, comments comments, and contributions to this document.</t>
      <t>The authors would like to acknowledge the contribution from Alexander
Vainshtein <contact fullname="Alexander
Vainshtein"/> on "Nesting of PSIDs".</t> PSIDs" (<xref target="psid-nesting"/>).</t>
    </section>

    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <?line 518?>
<t>The following people have substantially contributed to this document.</t>
      <contact initials="M." surname="Chen" fullname="Mach(Guoyi) Chen">
        <organization>Huawei Technologies Co., Ltd</organization> Ltd.</organization>
        <address>
          <email>mach.chen@huawei.com</email>
        </address>
      </contact>
      <contact initials="L." surname="Wang" fullname="Lei Wang">
        <organization>China Mobile</organization>
        <address>
          <email>wangleiyj@chinamobile.com</email>
        </address>
      </contact>
      <contact initials="A." surname="Liu" fullname="Aihua Liu">
        <organization>ZTE Corp</organization> Corp.</organization>
        <address>
          <email>liu.aihua@zte.com.cn</email>
        </address>
      </contact>
      <contact initials="G." surname="Mirsky" fullname="Greg Mirsky">
        <organization>ZTE Corp</organization> Corp.</organization>
        <address>
          <email>gregimirsky@gmail.com</email>
        </address>
      </contact>
      <contact initials="G. S." surname="Mishra" fullname="Gyan S. Mishra">
        <organization>Verizon Inc.</organization>
        <address>
          <email>gyan.s.mishra@verizon.com</email>
        </address>
      </contact>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA908bXPbNprfPeP/gEtnbu2uSFuOncSebjd+TTxnO17LbXe7
vdmBSEhCQ5EqQcZW3PS33G+5X3bPCwCClBQn3cztzWWmtUQBD4Dn/Y2Iomh9
7d2BeLq+lhZJLqfqQKSlHFWRVtUoMrNS5+NoOstMNJPVJDJqPFV5Fe3srK8l
sjoQpkrX10xVKjk9EOent2fwvMiNyk1tDkRV1mp9baYP1teEqIrkQPxhrswf
7LdiOpNJ1X6Wqlk1gUdP3QOdp7BgMMjMp6UamfBJUVadRwAb9xk+0nmmc9Ue
01nf1MPmYV7As0pXGcy5hrOLAZ9dnOOG9EirEmCKy+uLgTiSRqV+wE1RV4A2
caWqu6J8u74mh8NSAZavB+cnOGdwE+E0+AHwduDHH8K39bW78YEYXN+cX70S
P8Bs/OFVWdQzoJCsYC872ztPo34/erq9vgYQ6mpSlIDfSDD1flD6Fy1h0vFE
5WM8VVECxOOJzqW4LIY6U/iwLPBcKtVVUeJ3NZU6OxAJTrqzIF4mOGlKc2JA
TLPIa5mLC70SuAWW6YnMVwOhDVow3e0Q2Ne1hK2IW5VM8iIrxloZpludV+Xc
LhtuPs5eTmhOe6Eb+VaZiXgl83QSbFqbpBCDuanU1PTEeZ7Ebegyl2kIvhwT
gJcJTuysUMy1+FGPM9Xs/qgsZEqjGggwLH5Pw14O7c8MiKSmKvWwrlrUvJTJ
ZONVDfM2CV8fw404LuKeuECB9CtOYX6MRF2KmAuA8IP8CJdYKHcwJlN6/vNq
Yh5qWACIWXtYP96ewo7KWYsh6ljiwJfvK5ofJ3kD4lWpxuJSl+bt/GNAxjBM
T2nYyzE+am/k1Rx4cxADIDMppQf0vSr1+yL3ZHbAYHRs4ikNfvmOBzmS5EU5
lZV+p0h93Zwdv9jd3vGfnz3bhs86H3VH7e7uPHOf9/ZeNJ+f7e26z8+e72/7
z/vP9gKofszz5/v7/vP+brPy/t7zZkf7ffd5v7/Pz8+jk5jU9yxRkSmjoU51
Sfq7/bNOS/x5VmQ6mbf0O417/UN0fnlNH0ETsyK0bHd9ewUH2CbNpUrDQ7wq
wi8Bk/IDr7z60fZ+tNO3YGU5VqBtxaSqZuZgayuRZQmaNW7YdUvlW7OySOuk
Mlsjfa/SKGfF6gZHerZV0k62ZlWO/+HmkIICGWjxFMhVP/71+PYqevb88VPA
6E85gjvB3d1d3LD3FkmMO8A/0Jrdb+nZP9wRNGif7f7W+/ukymk3/PEf+DGe
VNOMj3H2evEUZ3qoykkxVY8dwA/83GOM3ESiQzFTpQT15A7TUGVnfzeWZnYf
bHhwvbjhwUyXaB9P1DudqJXbdcM+d7eG59FepTEKNlZvjTJ1r6JKmSoyRQZ2
tsgjkNhobxwNZfJ2IutM4I5JMK5uT2/eXEe3p4Pb9s4P04lCTwgcEtAgefFO
EqCTEsQ+x/OorJiR7QcTIc6KpDY4GvRNo6ATmYFNUPJtNQFmHU9MFIXqVtwo
o2SZTGABA8sCRcVhkqgMkQ7Kfe+VuPn3E4J/C6dZhr0VSrzBYX8/2t4jx2FB
9iwOE/gPWBMZ904Nt3J1Z4CDZZ6rbEuWlU7ADIDGi8FFAgT8Wad/2t3bef5i
3xH9Krp42kbd7QTQX8rczMBLc5IboY+ooxTP5inyKtJ5dHx5fPy7jvYi6u9E
26vUCvBubtcGwsQAbOtuhruogGhb9SwDYwx8DGC2+jtbv2PP8Swd4dqIiCiK
hByCUwxYYt46XPANNwY3mwJVrtBGaOdRpmI4F2i/boTVxGAzTRWLQ3Cy6yGo
50oUI/ebEaOymIpqolqjRQL0KioxVCIDzizlGOAC46bwGyxdg60DzlS4CG5g
fY2gSJgCTC6kQYBz8BzmCGGGVJdZNgfHKB+DOw8C5mb6fSeEETCGRkgxK1VU
ql9gGdBtArAk3slSF7URtVFRAp6yAUcb+BxWulYlmc88UeJSSVOXCo/RIzZX
eRpVRQR/RP+PfV4RVE6liPdixOs5oQrXIDccmAHWzyQcbsP62JsIS5yC02CM
yItUOeykClTmFCIClNK7iYYNuWMBDFANgGqgIOAPXXvEseWDBumZHKoMIiAY
DKhKJJyvRQxP1hLwUioBhyveAbClABjvwcrAbJUJF46JuW4ngGWI1WpaIlUj
OIJZFaBsYMSxicS3e3HcReeEgyN4FSAHmIt3UU1iz8tTnaYob+trX4Fyqljr
E8HX15by9cODdZY+fPAsyEcxRV2CU1La0cBdMtXjKe4Q/HBgPz6/5Wxpx/Pe
rN6Ep+QrF1kGuLQSoUFnlrwr8OVB1fJvLCY9lCpgS9ABKSnxBs93GulNKJko
CbIdwwlpQJehLD/Zs4HzB2fDcX4mCTJsQwKeQSmlwX4DOju2lT4KdOTtAReC
MfHMB+CIC6a6QmgyA/kLqNdrOAjXbfYcMtWdzjKUYnMnZzMAAoIyK/BTjHoZ
GNLUWcVEx90jjWQF2LZAYHiRg+jzSqBZ+LFVDZkaVatXxrMEiAbDB2GI6TIc
7qM2vQU+tELqJArOHAJHZebFlxHTluBg4QSiAmbl18Ud8mLPywLyglwpCp+s
zPQCKeFAj2g4sfHwMDM6JSsym374AHqK3HRWbuAq0LbCUUN8QgMfV45i4wI8
kwj/J3CTm+31/DgAF7NSUaWCn1SPOWFBv0g42p1XbNV8BiNhhipLti04H/Ag
cWSoi8BytXUTAieYNK3O9S+1Ag77PerpvBKXh39DTqwNW87ucKTXEkMViytA
APF6T4BTS6EPshY8dBID4WFeSdqnXtxHWivcfkUyBNzBRPVyKBGV+AQWAwDI
xcQqiF1SCTCOgsuMn7PY0ck+dTfAuwFaQEiJjl99BW5ksJ8LCNxrUL6WxuIt
GHZg0NSIJ5ffDW6f9PivuHpDn29O//Ld+c3pCX4evD68uPAf1uyIwes3312c
NJ+amcdvLi9Pr054MjwVrUdrT4BUT5h1n7y5vj1/c3V48YQPE/IbmklA7BAP
CAIO4ke6z6ylyiQlhCOEgKPj6//+r/4u6OJ/A2W80+/vgzLmLy/6z3fhC6of
Xo0UGH9Fv2YNFaGkzB0YCUD/TFcyA8oA65pJcZcTK8dra1//HTHznwfim2Ey
6+9+ax/ggVsPHc5aDwlni08WJjMSlzxasozHZut5B9Pt/R7+rfXd4T14+M2f
MSkqov6LP3+7ZjnokLKVmkTF2ICjnBr8FZXcgbgEo6FRiRRJkQGPoWIegCXF
UHdMfDi4Oeh6vPz8/ORgiZti50QM/twbUdRkIPKgEIqlRtnOIxmHIK3xS43T
6w3boGPtlgbFCE41TQan+trORgc7nF6SZZTW2rKBQc8D5BAHBP44OWkgiIwt
wOhb01ZVZH+u6fQrPLWYA4WvWr9z6NDVn1JcFBhMukeht8W77KpVTTv7iGJd
UNMLLiSti0Ft5txW0ln42Bg9zkO3tusT8naPsgJMN/iHF0dtD9FiqqPnm/2y
9T602XPD2r7l0voVia7CG3qMcmgWuBPeToQzp8TJmWoBIDVuMK/iFbfQIzCA
KkXH6QyMirqXU5jGK1is0EKhQQoXInAwEXXOIIjVaC2JueZUYyhrCVS641Nq
rofLwwOXgAEVXmfIZ29JWcoxpkQlWTRllpyF55HhQ0z+wG5miE52wEJUAY+r
knRvtWhvkMtJGerpVKXo7QKvjcAhL+66vqIlrndacTsUZ5IZ6gXrjEDfs0W1
bOO8jQ2Z/iwTlSfzLVx9C4zCSN+7nyGKLsBW2OTMCofBc1Lg6FgMkIm14TIO
rYqZ3bq1tAteLfhoSmMcV5AbT4bKoqG1KAhGkXAowGcf1iAwlcPwo4tZMYWo
Bbl06sC7MFCBK5rVfrXb2wsB8pqlK11yhXUNp8HY9w0pjroMuSmfW8DqPlGz
SmyDpzUK+AVhD4uqAmEn6Mw7A3BfK2YKhsXWV48azoK5aK0+Zf6280pbxKRf
IX7xIDmKaQ0B+XNBAy2KLuCoLonlwGQlMBKNUVuKiayzwFOfBp46bFvlcpgx
wdvMzMSsSj0e+9iVK0iU/gN+1lMF2J/OnAXEDcs01c62+Y0SH1pnMmRjIAnE
Tilh0x6gmeR5x4P0Xum4zmT7yJQ5cAMxwvC/UUQ3ke8U8TMVQPGsgI47WVLI
HCAnFkcKxmo4XakyGUoeYh7OpO5noLYAOcC4meCgJqMIPFE+APfqJ3fxQNcZ
JHy9UrkqdSIOG2E65nykdTw2Xh1ebLb0LpL8jVN5oGIOU4gTNabjCEOkvNCf
BqoirTfeHF5u+kqui+DAIho8NVsqLON8+GAZBRZs683D49eC3UrT0oiNSrP8
bundTQfcNjxFRem64p2ixSEGeJtbxXop7/W0ngrE3QlWysXG5QATPGiLneae
zgqzQnGTPzOmpLVb0OUzwGu2LIK1+zIMSnA1ViFUnWcovFGr24BmypAWRaXh
8mX1dAjnRwfu/MR4JwlxB243ShRlbnC7xJ8hwrGuZRMscECBHgZ46VZngsMe
AG/0nFmGByJaqR6dqvMkq1PVCBeR5jB3WqKTV4EzOw7msAEY6OFhpMeAOtj5
AU7+Df659DX/+2O05N8f22N+tX/jOA4e/m44LCX9LwRn55+G82XPlf/z+2E6
/n44vzkwco5VBPvw0+AwhzwciK8s53DV5E9PbFDVZrYnH6z7Virir6/J/F0w
//ZRUeQcQIcFgYBrnVfKGlkA23KPjU29NkkzY5NqoevULMh830QWwSjne1Bh
5b5a4dp3wQ5IusliBgZxCJpYqYVQpbfcHQVZN3qISlck6OgAvPdwWp8ppvQs
OJZuCZOAV+wzny2TAyHw6S+1zKLjAtxYDnZhqxunx5fXm+IYq0CuCERBMXhH
p7jKbM602Di94HgpMwXjfDHgonyD13bYDWC1nYPEdDuHsCAhlx+Anm/SSVtr
CVqM4wGs1mTgKOMndHFZ5dVkKxkcTgcLBkbP62vyXkeoIInNGneEAkk4hQcJ
zj27nufkE4GVrCZzYjqXTEPqY7iEaEVk9RgmBiwaE19V6CScXvQaRmCms3ll
63Yg3iCKa2I0JIKx+XmyIcYyA3lCQeHLexzg6mfI6eSNJxXQtOXTUK0nT9ux
D+WLfNzWAg80n5CcyPwjINluAO17YLamGr2wCvuM8iKfTzFzfIZhEkvtxuDs
wgXD+3vP0cVg7m6KLDYWpv2Rew4GiQt5YoSAEGmu9AQkoGfojkkIDiWgYoTE
BUVg8+JckgjLWeiAlSgo7BhS5mIZ/7N3QBFcVZd5j1bWOcQKHLkmEMeBW4X0
NaEgN7nwVR42+E6ZTc2aVohmVUkgb05sjM1z77Hd9fgjb+PsgmUP4RKHur47
jYYcl5S+gogpl+9cmO/raw68Sx+ZIBVgE0FACFfa6sQjtqqMQoKuaNAhJGZ1
iU5Jz7NdqgBnVKuyzQkgBXo8oWg08Is5ZHZayueZRzVQQjml5eOdVTWHh6/C
kgOxqQlXITxi1xHy4SpiwcHX12B3SYaJH6pZA7sCjvHrOzjaYVLRXzzi6/mw
1Gk4PxYDjSCbeBL0UZE2iW1XSgktoAycrDMylKLfW1/zgtCm67LCQYtcDlHr
a7wxltwmdjOs5zBEtKdahY3esvKC9bxb0DFFYVz03CoqxYsZKq5kLJm/oeJx
3DaAVAtqDmo69pVSSetry00iFYaToqQwTrWKZoQG5lIXwRrbKPDR1ZH9pDAz
lSA6WrXK3AJfX8sKOzWFhefu6InMkjqjCA+hEAWbIheDgZVmivjLFjzOOLSf
krrwiCTpD8JB6y0xZ64UD+KIIE26pK5HO0sQeUnV5Rqq8ucp9gw7jDUp0ZAX
uTcIom8s7MBTLI5b9+o8j4AnagEhKQkjtvSBUsNV3VaCrCIsxZSm1G2QbvKm
XFt4lDKn7JDXHZxFZ8u7vrYkJex3NERSfQRpv29rFosYQLZkq4Jo3zjVHCi1
o1Z11EEOVBrXR215nfKtBtgeq7VgtEZhuof7V4Xv//KtPk39lvYPaobbNoKK
GnrL9YwGL9ZrDXtz+8/2UIM6HW9rCrafFFtpsF2e61pNUh3xVs0pMYXeBM0u
FbWfCL9Oq6ywvkYpG/JmJRx3BDA7Jx2BcUFtiSYkD+C4bBOV/zUodOPKN4iM
EYouKLFhgZG9XzvmeNke37AXNpx7b0VjI7E12Zg5pM0mBTV7oFZroeticE1H
DFijNWB9DUdw8uXZHiYnLGVpgboknwa4ADvmNFaza8rp5u0aUJ0v0AjCrab2
EBPIokQPaCVlLUSsEQrMIqF9tj6fuEMfCEiLNUuN9L4ruou66eS9OWp3V1hf
YxfrmlIlq8oViLCWvoaFLbmcyvzYBhxJQZ86RgJTvoAhn5OaKmz902bKhHQt
NsAkS1oVWKs5o/5opMWxCAjAEGO8VnXXkJ3OGnen8SAfHlb3NoOeRJjBkNX9
zZjrWlQxp425IeVy3fRThK5T0z3hvITHmjF0rLAzv92SETa9oG5otzcsSf7Z
YqNlJsp0Fb5VlGg5K/VUlnOvecCNBbceVKBiv71hdOXjIjeHN+3swYhaf4jF
bRMS+EGFLalzL2FCPwY5g6AZ0S/LEowd8VaCb2FuwayA9rVdKewJ7BLyIswo
kG0fC9+wcKVHrnO6TGernnnW2KWeixd92eWa9MCglSIBxVwkrIcWGkm8RCy4
60iQkPPzx3jhk7MQxJpXih1cGMGawfJhzs+JAY80d7Xh+htHVKwNq6uhLiFj
baNZfONkOsMjUmHwB7TLRxSuydYhAm9I4vtcBlGUFtiR4itHEL5VHAVY2eVu
Vas1iaZhcb3T7krLUuiUL6zNetGndDsTKSoH3CAAbiJzkaOtzADi38EkDFgq
zMUD0wK1dYaWlnCH2CD3JvDBAS9D16AEW9dwJNab/gzk5nWcU/Aqcnx7iVPZ
3BxFqZYpMBAlCawWs/A5VEDbu2FDmp1NinJMBwncCHYYfXuyuZQIJAxmBkKK
4b1SuE3+CeR4A1vIDRZBbJHYVUCOMUHEwzatXYE421TWMFg4loToH5IT4Uhp
l97wGMH9HW32GhRtHEXfHm8yppqHx3iKzaaC6VMrVFLw4ywh1D3xJztKP30D
g/s9nLLTwyQyfAB9ZCIk3bdhlp8fuWCLPjtxswvE4rTLk10XlbmSXZTcgly+
7yWByooDHPEJjvwR+DOcQi2eQq08RWcx3pWrPaDIMxc16QXvNQbJYMO1rGt3
SD5tCaLivA7vDHVZf+G0DecTg0LgijmjyDKJ88LjJSWRLZcL/+nxB37aVphZ
/+nxB3bi4QP9n+QBP304ggehWHw4phEsGjTixK/5Uwhx6/EHwRl/cifYevyB
nzaw+Ga5aj1hwQoekFDxzF+/6dQYvu0+WfKgXapo/zvdOSVryfpnxSKP/8NF
YHKrDIJllN/weHgSXOO3hRFiccavLIqMl1+F+A3R8ekQlkEk3rdoBYhuBXqA
KyB+v8QKRCdaofvdrkgPfhWfvcSyJZVHE4L8zO9fYAfdytaOq2x1XRouamEa
dqAgrgPL3CmxgM/jfvkQNoI12RkK9TJqMrMarsm7c+aUa7xb1uNr4gkpvr++
cm0oQSaUwEryQGgJTuwGbwMEvRNF2Bzj9tHNSI64UygsAHGTV6smxKllbqQy
TWBPb49xY4VNePo+SG6DdKVzOoFvLeHku2/gV52K2bLmgGqxbYlTBZmSpWs8
tunsZhHGzkIflPGObQMHyzMMS1etvj5b+3Hlsg62hPP4cX648VWtVnrh+cry
fdPomSo1c8ziG76QIqVCO075HyRwzs0+aHqDNiLOTGD5qxXN2r5757F/8Ljn
KN5aXns0Oj6saaGBTR3rvGFrbgsbtZ1p30AXdq3i7LtJ0W5bWFY7Y+SDQ0kV
B+ySwXfQeesLriaXipZUZVpFhIENdV7EfdxKk2xZ1seJpNCt12E6a4axDKKO
9mrZ6C3GUrgPdnZoQhAG4Iss/NqCVSzo18qKX8ZyWSvKiE8Bb7aPqcktWcnv
9KXgRnoYFdn9DYsaY9254DeQDXepjXSG8QY206l7+IREdKmalFhB0Wv6nBSy
EeiCC+qK+BZJlN9pYceGtlRAU8aXuoAV7lSWxeINaT9//g7VqLXahsgdnl1F
w3CpdszqfWPPRE7x2QQLv2TYUkNczwwFnWokNiHc4Y6Fo1N/YfVpEbW4XfSG
m/QW51pZHFchy72K0UJUpy7HlTghztvafwB/ayou/p1fPOFuOUCqOKUbL0Rk
3w3kXbvqoy3jz+qhK4/2HGnxr5+igmgTYHMZb393x6VcQpilSuj9D8IV7QvR
gTmmbnm0yTW7Tn8n5ZQgQZi2zBNWvaheRGmqwtt5GnyO5iFXVXSC18tY6hkx
lE7j4zowCRN/bV5sTmOpiL/OHHt1N+26CE2TcKFev9QG9AajXNop3lZDVeEK
FViiMRHiDDu/1gVfiDXxHHQrDvE97MfE4hr0j1FB8wMFWNofGkUfMzPvdFov
OgQU5jVNGFMsVMMei9JwWcXmoHCLYGTCIhfoNDUaYWDms6dAh5x6d/H+Ctu0
EJppa7xUKmx0Cbu9w5pqTcJMBCVkBHeQGNsMqJs2EUKhNL22Gh4qlxpmBA+p
tRp4QoLbQoh4B0JH3X4L/EW2RJdiBFoZWw5jcUOvUrKGluk7bWPRBssscV1I
6D2Qc8TNFwnyuNXnAf/0xBNiDRJlSd3q+KKLurOlO2FfDxdjvG/HOHYZ5/S+
V0sfUA7Ul+NpZ74YM1Q5CApppLLOqdM6Cdw73CuYbGy2NUJhegrlFgZj1zXh
Sd2DBtQNs+DWRkqlQ3r30a81ldbweWyo1Asr4AR1x5QQS+/KocWdOd0TcObi
obmZhASnYSL3XrhRCqxb9cR1HSy9pAcrh2/wvhz9nmYvva8G72GhEmOLmAt3
jAwUJZLtHRdLPGuwYbfXDw98XYnVeV+Lk0ZNHPAQ9s8tr+HEzkKmtZAjF7Wz
cPKV+YFtNJtoW1cB+gxrnaWI4CVVwfiRIxEorPThgb7vb2/fbPdfHMM4yj4N
UckTwelSqzLh1/FDonOqp+v70/Ru34puOWtOSe5wsGO/PY13Fpqxe7ZBlt4b
yDJakt8h5Hf67IuB2BZS05uO7MWyuDaboPYUG765xZ+StKMumasqPBe717Zf
gQOv3iocumwVjKaA06fkOTt/dXp7/ObqzLHcJfIAGvkLvLrjACs92G5lfz0u
uFEEX9ai2w96HUS58zRHiHcs233PZDwQZOai/g4/vtCJynEnB+Jq69CW1tuc
zFKPyuAA30+lYqyzsBb4Mb67gZeTZToeyfadTrQKvndTz7AdK8X37GaVolbn
/m6Prg3zdYXmWiWc1hFV92NRNm1SX3edGhr2B4NXfiwRScT8w4O9e8d5/gCj
JZRozANpdP4/Uc3btpDNgWdwb7iku3qGdWMQMAdiQGaq8fE+mfE/g82/CJdb
3KzkSfp1kSc/mSVX8eRSpvwdXBmy5bL7vXitFay50++w5hUEbK+fHj9qUJaN
i5cJ1gENO77pP9ve3u7hB1AfXtuXK82Kfwega0u+EOuQSl/G46Txo+b1cXdS
yxBmw3kVlq7iedyPt188a8zFJrcDcMrhy6hiRkSXR48gonKq6f++zsxRF4zx
Mrt4e3e3v/ty8jT5BOX5tMOh7n6qYzDHde4aV5fx6MdGdpnUjcXLnbBdD1a2
BBdncqpDi9/2fIjO/EYNFTYheL9uq902+y6uY5WpGHXWMW2d3F4Hhcd2jVnX
xVhfZckKu/GLvXjZD6MafRlnvC3H8pv5Vkw+QWn3e8BL8N+u+GwvhV4d8Fcc
+X1gHKu4vOf2EUpJ/NShdoXStpfjhGLBJ02opf1RyeATwYfdXusGpnAy7OJ/
U3x+rvNfdPx+IouXwUVrHxedULmD4AT30C3KSnOb3aLv0ZWVZiz6AlaTY87B
eQUbx5raVsSzve2tZ/vbp5srnRS+We9zwobQ/+j5DDF115rgciIK5S6e2jcw
ehwhmG4FFwakapYVcw770VvFXBg1DcTN6zb/QhdnItMFM/Ulbcr/B8fn/QRv
um1dl/hZfg+JB2XI6F19VuSkJ/+FWUO1uCOnFK2Pbhkjxe4QOS24q5klkNK9
rpPvHae2Qu3MEfGGjeZ6Ydi72UM3f4Mu6BTP+i/wV7Ih29sx/Uri/xrwvETM
e97KbBxPKNmHtynfRle730U7O9sx4jQWl7BLutf5r0+jvwzOrnfo9sCdnb3D
uGEaMFrPuDfmqnirJfI0XhD48BDeE4lW1t8mFJQB8aadQGdcyLkqn1LRErRH
2LSKyXa6NtG/f6uRSGiHODPXvtCZEdu6OBLW9XzV84zlGxzF+eHV4WJNFZ9+
8Onh5sInl5N0r6JjHpMgSNsFzGCjKKIGal7iMMEMcqbSsXUcHr7qPvpA1WB+
91alf3qSF08++Bfi6apH07nXAt+zeisO0xJODz4Qtr0CdSt1hzWuo3Iu86q3
vjaAcCMf4/v14keY0BOHmbqXVKj6HnugJpXCYsFhnpbgR78C2oOmBlb8D3Bd
wUjfSlBzsKIE1A0mpUzTiRSv1RjzdX/V+bxWBBa86ItCIhTgDmM17xE44gVY
jKSUKleuBVeXNqvYw86n8Rh9Gr6Vzt5J7tqtfJVkSTXl45iRDW5dNa4puRCD
eCSsrzVYQH9tsf4eO3IG2V+3PJsdvgCgwBonBS2mHtobeuy9kL5ouOQc/wPi
7ZzHYl4AAA==

-->
</rfc>