Diff: rfc9545.original.xml

	rfc9545.original.xml	rfc9545.xml

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

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

	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.3 (Ruby 3.0.2 ) -->	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.3 (Ruby 3.0.2 ) -->

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

	<front>	<front>

	<title abbrev="PSID in SR-MPLS">Path Segment Identifier in MPLS Based Segmen	<title abbrev="PSID in SR-MPLS">Path Segment Identifier in MPLS-Based Segmen
	t Routing Network</title>	t Routing Networks</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-spring-mpls-path-segment	<seriesInfo name="RFC" value="9545"/>
	-22"/>
	<author initials="W." surname="Cheng" fullname="Weiqiang Cheng" role="editor ">	<author initials="W." surname="Cheng" fullname="Weiqiang Cheng" role="editor ">
	<organization>China Mobile</organization>	<organization>China Mobile</organization>
	<address>	<address>
	<email>chengweiqiang@chinamobile.com</email>	<email>chengweiqiang@chinamobile.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="H." surname="Li" fullname="Han Li">	<author initials="H." surname="Li" fullname="Han Li">
	<organization>China Mobile</organization>	<organization>China Mobile</organization>
	<address>	<address>
	<email>lihan@chinamobile.com</email>	<email>lihan@chinamobile.com</email>

	skipping to change at line 57 ¶	skipping to change at line 69 ¶
	</postal>	</postal>
	<email>rgandhi@cisco.com</email>	<email>rgandhi@cisco.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="R." surname="Zigler" fullname="Royi Zigler">	<author initials="R." surname="Zigler" fullname="Royi Zigler">
	<organization>Broadcom</organization>	<organization>Broadcom</organization>
	<address>	<address>
	<email>royi.zigler@broadcom.com</email>	<email>royi.zigler@broadcom.com</email>
	</address>	</address>
	</author>	</author>

	<date year="2023" month="November" day="30"/>
	<area>Routing Area</area>
	<workgroup>SPRING Working Group</workgroup>
	<abstract>
	<?line 123?>


	<t>A Segment Routing (SR) path is identified by an SR segment list. A	<date year="2024" month="February"/>
	sub-set of segments from the segment list cannot be leveraged to distinguish one
	SR path	<area>rtg</area>
	from another as they may be partially congruent. SR path identification	<workgroup>spring</workgroup>
	is a pre-requisite for various use-cases such as Performance Measurement, and en
	d-to-end 1+1 path protection.</t>	<keyword>Performance Measurement</keyword>
	<t>In SR for MPLS data plane (SR-MPLS), an Egress node cannot determine on	<keyword>Bidirectional SR Path</keyword>
	which SR path a packet traversed the network from the label stack because the s	<keyword>End-to-End Path Protection</keyword>
	egment identifiers are removed from the label stack as the packet transits the n	<keyword>SR Path Segment</keyword>
	etwork.</t>	<keyword>Path Segment</keyword>
	<t>This document defines Path Segment Identifier(PSID) to identify an SR p
	ath on the egress node of the path.</t>	<abstract>
		<t>A Segment Routing (SR) path is identified by an SR segment list. A
		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 prerequisite for various
		use cases such as performance measurement and end-to-end 1+1 path
		protection.</t>
		<t>In an SR over MPLS (SR-MPLS) data plane, an egress node cannot determin
		e
		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) to identify an S
		R
		path on the egress node of the path.</t>
	</abstract>	</abstract>
	</front>	</front>
	<middle>	<middle>

	<?line 135?>

	<section anchor="introduction">	<section anchor="introduction">
	<name>Introduction</name>	<name>Introduction</name>

	<t>Segment Routing (SR) <xref target="RFC8402"/> leverages the source-rout ing paradigm to steer packets from a source node through a controlled set of ins tructions, called segments, by prepending the packet with an SR header. In the M PLS data plane SR-MPLS <xref target="RFC8660"/> the SR header is instantiated th rough a label stack.</t>	<t>Segment Routing (SR) <xref target="RFC8402"/> leverages the source-rout ing paradigm to steer packets from a source node through a controlled set of ins tructions, called "segments", by prepending the packet with an SR header. In SR with the MPLS data plane <xref 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, t he 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 lab el stack to determine along which SR path the packet came.</t>	<t>In an SR-MPLS network, when a packet is transmitted along an SR path, t he 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 lab el stack to determine along which SR path the packet came.</t>

	<t>However, identifying a path on the egress node is a pre-requisite for v	<t>However, identifying a path on the egress node is a prerequisite for va
	arious use-cases in SR-MPLS networks, such as Performance Measurement (<xref tar	rious use cases in SR-MPLS networks, such as performance measurement (<xref targ
	get="psid-for-pm"/>), bidirectional path (<xref target="psid-for-bpath"/>), and	et="psid-for-pm"/>), bidirectional paths (<xref target="psid-for-bpath"/>), and
	end-to-end 1+1 path protection (Live-Live case) (<xref target="psid-for-protecti	end-to-end 1+1 path protection (a Live-Live case) (<xref target="psid-for-protec
	on"/>).</t>	tion"/>).</t>
	<t>Therefore, this document defines a new segment type, referred to herein	<t>Therefore, this document defines a new segment type, referred to herein
	as a Path Segment. A Path Segment is defined to uniquely identify an SR path on	as a "Path Segment". A Path Segment is defined to uniquely identify an SR path
	the egress node of the path. It <bcp14>MAY</bcp14> be used by the egress node f	on the egress node of the path. It <bcp14>MAY</bcp14> be used by the egress node
	or path identification. Note that, per-path state will be maintained in the egre	for path identification. Note that per-path state will be maintained in the egr
	ss node due to the requirements in the aforementioned use cases, though in norma	ess node due to the requirements in the aforementioned use cases, though in norm
	l cases that the per-path state will be maintained in the ingress node only.</t>	al cases, the per-path state will be maintained in the ingress node only.</t>
	<section anchor="requirements-language">	<section anchor="requirements-language">
	<name>Requirements Language</name>	<name>Requirements Language</name>

	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp	<t>
	14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	nterpreted as	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and	be interpreted as
	only when, they	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	appear in all capitals, as shown here.</t>	when, and only when, they appear in all capitals, as shown here.
	<?line -18?>	</t>

	</section>	</section>
	<section anchor="abbreviations-and-terms">	<section anchor="abbreviations-and-terms">
	<name>Abbreviations and Terms</name>	<name>Abbreviations and Terms</name>

	<t>MPLS: Multiprotocol Label Switching.</t>	<dl>
	<t>SR: Segment Routing.</t>	<dt>MPLS:</dt><dd>Multiprotocol Label Switching</dd>
	<t>SID: Segment Identifier.</t>	<dt>PSID:</dt><dd>Path Segment Identifier</dd>
	<t>SR-MPLS: Instantiation of SR on the MPLS data plane.</t>	<dt>SID:</dt><dd>Segment Identifier</dd>
	<t>SR path: A SR path is a path described by a Segment-List.</t>	<dt>SR:</dt><dd>Segment Routing</dd>
	<t>Sub-Path: A sub-path is a part of a path, which contains a sub-set of	<dt>SR-MPLS:</dt><dd>SR over MPLS</dd>
	the nodes and links of the path.</t>	<dt>SR path:</dt><dd>A path described by a segment list.</dd>
	<t>PSID: Path Segment Identifier.</t>	<dt>Sub-Path:</dt><dd>A part of a path, which contains a subset of
		the nodes and links of the path.</dd>
		</dl>
	</section>	</section>
	</section>	</section>
	<section anchor="path-segment">	<section anchor="path-segment">
	<name>Path Segment</name>	<name>Path Segment</name>

	<t>A Path Segment is a Local Segment <xref target="RFC8402"/> which unique	<t>A Path Segment is a local segment <xref target="RFC8402"/> that uniquel
	ly identifies an SR path on the egress node. A Path Segment Identifier(PSID) is	y identifies an SR path on the egress node. A Path Segment Identifier (PSID) is
	a single label that is assigned from the Segment Routing Local Block (SRLB) <xre	a single label that is assigned from the Segment Routing Local Block (SRLB) <xre
	f target="RFC8402"/> of the egress node of an SR path.</t>	f target="RFC8402"/> of the egress node of an SR path.</t>
	<t>A PSID is used to identify a Segment List. However, one PSID can be use	<t>A PSID is used to identify a segment list. However, one PSID can be use
	d to identify multiple Segment Lists in some use cases if needed. For example, o	d to identify multiple segment lists in some use cases if needed. For example, o
	ne single PSID <bcp14>MAY</bcp14> be used to identify some or all Segment lists	ne single PSID <bcp14>MAY</bcp14> be used to identify some or all segment lists
	in a Candidate path or an SR policy, if an operator would like to aggregate thes	in a candidate path or an SR policy if an operator would like to aggregate these
	e Segment Lists in operation.</t>	segment lists in operation.</t>
	<t>When a PSID is used, the PSID can be inserted at the ingress node and <	<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, in other wo	bcp14>MUST</bcp14> immediately follow the last label of the SR path; in other wo
	rds, inserted after the routing segment (adjacency/node/prefix segment) pointing	rds, it must be inserted after the routing segment (adjacency, node, or prefix s
	to the egress node of the SR path. Therefore, a PSID will not be the top label	egment) that is pointing to the egress node of the SR path. Therefore, a PSID wi
	in the label stack when received on an intermediate node of the associated path,	ll not be the top label in the label stack when received on an intermediate node
	but it can be the top label in the label stack on the penultimate node.</t>	of the associated path, but it can be the top label in the label stack on the p
		enultimate node.</t>
	<t>The value of the TTL field in the MPLS label stack entry containing a P SID 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 <b cp14>MUST</bcp14> be 0.</t>	<t>The value of the TTL field in the MPLS label stack entry containing a P SID 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 <b cp14>MUST</bcp14> be 0.</t>
	<t>The egress node <bcp14>MUST</bcp14> pop the PSID. The egress node <bcp1 4>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 timest amping.</t>	<t>The egress node <bcp14>MUST</bcp14> pop the PSID. The egress node <bcp1 4>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 timest amping.</t>
	<t>The addition of the PSID will require the egress to read and process th e PSID label in addition to the regular processing. This additional processing m ay have an impact on forwarding performance. Behavior relating to the use of exp licit null directly preceding the PSID is undefined in this document.</t>	<t>The addition of the PSID will require the egress to read and process th e PSID label in addition to the regular processing. This additional processing m ay have an impact on forwarding performance. Behavior relating to the use of exp licit null directly preceding the PSID is undefined in this document.</t>

	<t>Generic Associated Channel Label (GAL) <bcp14>MAY</bcp14> be used for O	<t>A Generic Associated Channel Label (GAL) <bcp14>MAY</bcp14> be used for
	perations, Administration and Maintenance (OAM) in MPLS networks. As per <xref t	Operations, Administration, and Maintenance (OAM) in MPLS networks. As per <xre
	arget="RFC5586"/>, when GAL is used, the ACH appears immediately after the botto	f target="RFC5586"/>, when a GAL is used, the Associated Channel Header (ACH) ap
	m of the label stack.</t>	pears immediately after the bottom of the label stack.</t>
	<t>The SR path computation needs to know the Maximum SID Depth (MSD) that	<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"/>.	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 num	This ensures that the SID stack depth of a computed path does not exceed the num
	ber of SIDs the node is capable of imposing. As per <xref target="RFC8491"/> the	ber of SIDs the node is capable of imposing. As per <xref target="RFC8491"/>, th
	MSD signals the total number of MPLS labels that can be imposed, where the tota	e MSD signals the total number of MPLS labels that can be imposed, where the tot
	l number of MPLS labels includes the PSID.</t>	al number of MPLS labels includes the PSID.</t>
	<t>An example label stack with PSID is shown in <xref target="figure1"/>:<	<t>An example label stack with a PSID is shown in <xref target="figure1"/>
	/t>	:</t>
	<figure anchor="figure1">	<figure anchor="figure1">

	<name>Label Stack with PSID</name>	<name>Label Stack with a PSID</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	+--------------------+	+--------------------+
	\| ... \|	\| ... \|
	+--------------------+	+--------------------+
	\| Label 1 \|	\| Label 1 \|
	+--------------------+	+--------------------+
	\| Label 2 \|	\| Label 2 \|
	+--------------------+	+--------------------+
	\| ... \|	\| ... \|
	+--------------------+	+--------------------+

	skipping to change at line 142 ¶	skipping to change at line 170 ¶
	<t>Where:</t>	<t>Where:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>
	<t>The Labels 1 to n are the segment label stack used to direct how	<t>The Labels 1 to n are the segment label stack used to direct how
	to steer the packets along the SR path.</t>	to steer the packets along the SR path.</t>
	</li>	</li>
	<li>	<li>
	<t>The PSID identifies the SR path in the context of the egress node o f the SR path.</t>	<t>The PSID identifies the SR path in the context of the egress node o f the SR path.</t>
	</li>	</li>
	</ul>	</ul>

	<t>Signaling of the PSID between the egress node, the ingress node and pos sibly a centralized controller is out of the scope of this document.</t>	<t>The signaling of the PSID between the egress node, the ingress node, an d possibly a centralized controller is out of the scope of this document.</t>
	<section anchor="equal-cost-multipathecmp-considerations">	<section anchor="equal-cost-multipathecmp-considerations">

	<name>Equal-Cost Multipath(ECMP) Considerations</name>	<name>Equal-Cost Multipath (ECMP) Considerations</name>
	<t>If Entropy Label(EL) is also used on the egress node, as per <xref ta	<t>If an Entropy Label (EL) is also used on the egress node, as per <xre
	rget="RFC6790"/> the Entropy label Indicator (ELI) and Entropy Label (EL) would	f target="RFC6790"/>, the EL and Entropy Label Indicator (ELI) would be placed b
	be placed before the tunnel label and hence does not interfere with the PSID whi	efore the tunnel label; hence, they do not interfere with the PSID, which is pla
	ch is placed below.</t>	ced below.</t>
	<t>It is worthy to note that in case of ECMP, with or without the use of	<t>It is worthy to note that in the case of ECMP, with or without the us
	EL, the SR packets may be forwarded over multiple paths. In this case, the SID	e of an EL, the SR packets may be forwarded over multiple paths. In this case, t
	list cannot directly reflect the actual forwarding path and the PSID can only id	he SID list cannot directly reflect the actual forwarding path and the PSID can
	entify the SID list rather than the actual forwarding path.</t>	only identify the SID list rather than the actual forwarding path.</t>
	<t>Also, similar to Synonymous Flow Labels(SFL) <xref target="RFC8957"/>	<t>Also, similar to a Synonymous Flow Label (SFL) <xref target="RFC8957"
	, the introduction of an PSID to an existing flow may cause that flow to take a	/>, the introduction of a PSID to an existing flow may cause that flow to take a
	different path through the network under conditions of Equal-Cost Multipath. Thi	different path through the network under the conditions of ECMP. In turn, this
	s, in turn, may invalidate certain uses of the PSID, such as performance measure	may invalidate certain uses of the PSID, such as performance measurement applica
	ment applications. Therefore, the considerations as per section 5 in <xref targe	tions. Therefore, the considerations of SFLs as per <xref section="5" sectionFor
	t="RFC8957"/> of SFL also apply to PSID in implementation.</t>	mat="of" target="RFC8957"/> also apply to PSIDs in implementation.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="use-cases">	<section anchor="use-cases">

	<name>Use cases</name>	<name>Use Cases</name>
	<t>This section describes use cases which can leverage the PSID. The conte	<t>This section describes use cases that can leverage the PSID. The conten
	nt is for informative purpose, and the detailed solutions might be defined in ot	t is for informative purposes, and the detailed solutions might be defined in ot
	her documents in the future.</t>	her documents in the future.</t>
	<section anchor="psid-for-pm">	<section anchor="psid-for-pm">
	<name>PSID for Performance Measurement</name>	<name>PSID for Performance Measurement</name>
	<t>As defined in <xref target="RFC7799"/>, performance measurement can	<t>As defined in <xref target="RFC7799"/>, performance measurement can

	be classified into Passive, Active, and Hybrid measurement. Since a PSID is enco	be classified into Passive, Active, and Hybrid measurements. Since a PSID is enc
	ded in the SR-MPLS Label Stack as shown in Figure 1,	oded in the SR-MPLS label stack, as shown in <xref target="figure1"/>,
	existing implementation on the egress node can leverage PSID for	existing implementations on the egress node can leverage a PSID for
	measuring packet counts.</t>	measuring packet counts.</t>
	<t>For Passive performance measurement, path identification at the	<t>For Passive performance measurement, path identification at the

	measuring points is the pre-requisite. PSID can be used by the	measuring points is the prerequisite. A PSID can be used by the
	measuring points (e.g., the ingress and egress nodes of the SR path or a	measuring points (e.g., the ingress and egress nodes of the SR path or a
	centralized controller) to correlate the packet counts and timestamps	centralized controller) to correlate the packet counts and timestamps

	from the ingress and egress nodes for a specific SR path, then packet	from the ingress and egress nodes for a specific SR path; then, packet
	loss and delay can be calculated for the end-to-end path, respectively.</t>	loss and delay can be calculated for the end-to-end path, respectively.</t>

	<t>Furthermore, PSID can also be used for:</t>	<t>Furthermore, a PSID can also be used for:</t>
	<ul spacing="normal">	<ul spacing="normal">
	<li>	<li>

	<t>Active Performance Measurement for	<t>Active performance measurement for
	an SR path in SR-MPLS networks for collecting packet counters and	an SR path in SR-MPLS networks for collecting packet counters and
	timestamps from the egress node using probe messages.</t>	timestamps from the egress node using probe messages.</t>
	</li>	</li>
	<li>	<li>

	<t>In-situ OAM<xref target="RFC9197"/> for SR-MPLS to identify	<t>In situ OAM <xref target="RFC9197"/> for SR-MPLS to identify
	the SR Path associated with the in-situ data fields in the data packets	the SR path associated with the in situ data fields in the data packets
	on the egress node.</t>	on the egress node.</t>
	</li>	</li>
	<li>	<li>

	<t>In-band Performance Measurement for SR-MPLS to identify	<t>In-band performance measurement for SR-MPLS to identify
	the SR Path associated with the collected performance metrics.</t>	the SR path associated with the collected performance metrics.</t>
	</li>	</li>
	</ul>	</ul>
	</section>	</section>
	<section anchor="psid-for-bpath">	<section anchor="psid-for-bpath">

	<name>PSID for Bidirectional SR Path</name>	<name>PSID for Bidirectional SR Paths</name>
	<t>In some scenarios, for example, mobile backhaul transport networks,	<t>In some scenarios (e.g., mobile backhaul transport networks),
	there are requirements to support bidirectional paths<xref target="RFC6965"/>, a	there are requirements to support bidirectional paths <xref target="RFC6965"/>,
	nd the path is	and the path is
	normally treated as a single entity. Forward and reverse directions of the path	normally treated as a single entity. Forward and reverse directions of the path

	have the same fate, for example, failure in one direction will result in	have the same fate; for example, failure in one direction will result in
	switching traffic at both directions. MPLS supports this by introducing	switching traffic at both directions. MPLS supports this by introducing

	the concepts of co-routed bidirectional LSP and associated bidirectional	the concepts of a co-routed bidirectional Label Switched Path (LSP) and an assoc iated bidirectional
	LSP <xref target="RFC5654"/>.</t>	LSP <xref target="RFC5654"/>.</t>
	<t>In the current SR architecture, an SR path is a unidirectional path	<t>In the current SR architecture, an SR path is a unidirectional path
	<xref target="RFC8402"/>.	<xref target="RFC8402"/>.
	In order to support bidirectional SR paths, a straightforward way is	In order to support bidirectional SR paths, a straightforward way is
	to bind two unidirectional SR paths to a single bidirectional SR	to bind two unidirectional SR paths to a single bidirectional SR
	path. PSIDs can be used to identify and correlate the	path. PSIDs can be used to identify and correlate the
	traffic for the two unidirectional SR paths at both ends of the	traffic for the two unidirectional SR paths at both ends of the
	bidirectional path.</t>	bidirectional path.</t>

	<t>The mechanism of constructing bidirectional path using 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-p olicy-path-segment"/>.</t>	<t>The mechanism of constructing bidirectional 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-s r-policy-path-segment"/>.</t>
	</section>	</section>
	<section anchor="psid-for-protection">	<section anchor="psid-for-protection">

	<name>PSID for End-to-end Path Protection</name>	<name>PSID for End-to-End Path Protection</name>
	<t>For end-to-end 1+1 path protection (i.e., Live-Live case), the egress	<t>For end-to-end 1+1 path protection (i.e., a Live-Live case), the egre
		ss
	node of the path needs to know the set of paths that constitute the	node of the path needs to know the set of paths that constitute the

	primary and the secondaries, in order to select the primary path packets	primary and the secondaries in order to select the primary path packets
	for onward transmission, and to discard the packets from the secondaries <xref t	for onward transmission and to discard the packets from the secondaries <xref ta
	arget="RFC4426"/>.</t>	rget="RFC4426"/>.</t>
	<t>To do this in Segment Routing, each SR path needs a path identifier	<t>To do this in SR, each SR path needs a path identifier
	that is unique at the egress node. For SR-MPLS, this can be the Path	that is unique at the egress node. For SR-MPLS, this can be the Path
	Segment label allocated by the egress node.</t>	Segment label allocated by the egress node.</t>

	<t>The detailed solution of using PSID in end-to-end 1+1 path protection is out of the scope of this document.</t>	<t>The detailed solution of using a PSID in end-to-end 1+1 path protecti on is out of the scope of this document.</t>
	</section>	</section>
	<section anchor="psid-nesting">	<section anchor="psid-nesting">
	<name>Nesting of PSIDs</name>	<name>Nesting of PSIDs</name>

	<t>Binding SID (BSID) <xref target="RFC8402"/> can be used for SID list	<t>A Binding SID (BSID) <xref target="RFC8402"/> can be used for SID lis
	compression. With BSID, an end-to-end SR path in a trusted domain can be split i	t
	nto several	compression. With a BSID, an end-to-end SR path in a trusted domain can be split
	sub-paths, each sub-path is identified by a BSID. Then an end-to-end SR	into several
	path can be identified by a list of BSIDs, therefore, it can provide	sub-paths, where each sub-path is identified by a BSID. Then, an end-to-end SR
		path can be identified by a list of BSIDs; therefore, it can provide
	better scalability.</t>	better scalability.</t>

	<t>BSID and PSID can be combined to achieve both sub-path and	<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	end-to-end path monitoring. A reference model for such a combination (<xref targ
	(Figure 2) shows an end-to-end path (A->D) in a trusted domain that spans thr	et="figure2"/>) shows
	ee subdomains	an end-to-end path (A->D) in a trusted domain that spans three subdomains
	(Access, Aggregation and Core domain) and consists of three sub-paths,	(the Access, Aggregation, and Core domains) and consists of three sub-paths,
	one in each subdomain (sub-path (A->B), sub-path (B->C) and	one in each subdomain (sub-path (A->B), sub-path (B->C), and
	sub-path (C->D)).</t>	sub-path (C->D)).</t>

	<t>The SID list of a sub-path can be expressed as <SID1, SID2, ...SID n, s-PSID>, where the s-PSID is the PSID of the sub-path. Each sub-path is as sociated with a BSID and an s-PSID.</t>	<t>The SID list of a sub-path can be expressed as <SID1, SID2, ..., S IDn, s-PSID>, 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 <BSID1, BS ID2, ..., BSIDn, e-PSID>, where the e-PSID is the PSID of the end-to-end path .</t>	<t>The SID list of the end-to-end path can be expressed as <BSID1, BS ID2, ..., BSIDn, e-PSID>, 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 P SID and BSID are	<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	used to support both sub-path and end-to-end path monitoring in a

	multi-domain scenario.</t>	multi-domain scenario.</t>
	<figure anchor="figure2">	<figure anchor="figure2">
	<name>Nesting of PSIDs</name>	<name>Nesting of PSIDs</name>
	<artwork><![CDATA[	<artwork><![CDATA[
	/--------\ /--------\ /--------\	/--------\ /--------\ /--------\
	/ \ / \ / \	/ \ / \ / \
	A{ Access }B{ Aggregation }C{ Core }D	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)	E2E Path(A->D)
	\|<------------------------------------------------->\|	\|<------------------------------------------------->\|


	+------------+	+-------------+
	~A->B SubPath~	~A->B sub-path~
	+------------+ +------------+	+-------------+ +-------------+
	\|s-PSID(A->B)\| ~B->C SubPath~	\|s-PSID(A->B) \| ~B->C sub-path~
	+------------+ +------------+ +------------+	+-------------+ +-------------+ +-------------+
	\| BSID(B->C) \| \|s-PSID(B->C)\| ~C->D SubPath~	\| BSID(B->C) \| \|s-PSID(B->C) \| ~C->D sub-path~
	+------------+ +------------+ +------------+	+-------------+ +-------------+ +-------------+
	\| BSID(C->D) \| \| BSID(C->D) \| \|s-PSID(C->D)\|	\| BSID(C->D) \| \| BSID(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) \| \|e-PSID(A->D)\|
	+------------+ +------------+ +------------+ +------------+	+-------------+ +-------------+ +-------------+ +------------+
	]]></artwork>	]]></artwork>
	</figure>	</figure>
	</section>	</section>
	</section>	</section>
	<section anchor="Security">	<section anchor="Security">
	<name>Security Considerations</name>	<name>Security Considerations</name>

	<t>A PSID in SR-MPLS is a local label similar to other labels/Segment, suc	<t>A PSID in SR-MPLS is a local label similar to other labels and segments
	h as a VPN label, defined in MPLS and SR-MPLS. The data plane processing of a PS	, such as a VPN label, defined in MPLS and SR-MPLS. The data plane processing of
	ID is a local implementation of an ingress node, or an egress node, which follow	a PSID is a local implementation of an ingress node or an egress node, which fo
	s the same logic of existing MPLS dataplane. As per definition of PSID, only the	llows the same logic of an existing MPLS data plane. As per the definition of a
	egress node and the ingress node of the associated path will learn the informat	PSID, only the egress node and the ingress node of the associated path will lear
	ion of PSID. The intermediate nodes of this path will not learn it.</t>	n the information of a PSID. The intermediate nodes of this path will not learn
	<t>A PSID may be used on an ingress node that is not the ingress of the as	it.</t>
	sociated path, if the associated label stack with PSID is part of a deeper label	<t>A PSID may be used on an ingress node that is not the ingress of the as
	stack which represents a longer path. For example the case described in <xref t	sociated path if the associated label stack with the PSID is part of a deeper la
	arget="psid-nesting"/> and the related BSID is not used while the original label	bel stack that represents a longer path. For example, the case described in <xre
	stack of sub-path is inserted as a part of the whole label stack. In this case,	f target="psid-nesting"/> and the related BSID are not used while the original l
	the PSID must be distributed in a trusted domain under the considerations defin	abel stack of a sub-path is inserted as a part of the whole label stack. In this
	ed in <xref section="8.1" sectionFormat="of" target="RFC8402"/>.</t>	case, the PSID must be distributed in a trusted domain under the considerations
	<t>A PSID is used within an SR-MPLS trusted domain <xref target="RFC8402"/	defined in <xref section="8.1" sectionFormat="of" target="RFC8402"/>.</t>
	> and must not leak outside the domain, therefore no new security threats are in	<t>A PSID is used within an SR-MPLS trusted domain <xref target="RFC8402"/
	troduced comparing to current SR-MPLS. As per <xref target="RFC8402"/>, SR doma	> and must not leak outside the domain; therefore, no new security threats are i
	in boundary routers <bcp14>MUST</bcp14> filter any external traffic destined	ntroduced compared to current SR-MPLS. As per <xref target="RFC8402"/>, SR domai
	to a label associated with a segment within the trusted domain, this applies	n boundary routers <bcp14>MUST</bcp14> filter any external traffic destined
	to PSID as well. Other security considerations of SR-MPLS, described in <xref se	to a label associated with a segment within the trusted domain; this applies
	ction="8.1" sectionFormat="of" target="RFC8402"/> applies to this document.</t>	to a PSID as well. Other security considerations of SR-MPLS described in <xref s
	<t>The distribution of a PSID from an egress node to an ingress nodes is p	ection="8.1" sectionFormat="of" target="RFC8402"/> apply to this document.</t>
	erformed within an SR trusted domain, and it is out of the scope of this documen	<t>The distribution of a PSID from an egress node to an ingress node is pe
	t. The details of the mechanism and related security considerations will be desc	rformed within an SR-trusted domain, and it is out of the scope of this document
	ribed in other documents.</t>	. The details of the mechanism and related security considerations will be descr
	</section>	ibed in other documents.</t>
	<section anchor="implementation-status">
	<name>Implementation Status</name>
	<t>[Note to the RFC Editor - remove this section before publication, as we
	ll as remove the reference to <xref target="RFC7942"/>.</t>
	<t>This section records the status of known implementations of the protoco
	l defined by this specification at the time of posting of this Internet-Draft, a
	nd 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 decisi
	on processes in progressing drafts to RFCs. Please note that the listing of any
	individual implementation here does not imply endorsement by the IETF. Furthermo
	re, no effort has been spent to verify the information presented here that was s
	upplied 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 ad
	vised to note that other implementations may exist.</t>
	<t>According to <xref target="RFC7942"/>, "this will allow reviewers and w
	orking groups to assign due consideration to documents that have the benefit of
	running code, which may serve as evidence of valuable experimentation and feedba
	ck that have made the implemented protocols more mature. It is up to the individ
	ual 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 S
	R-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. Huaw
	ei PTN7900 Series Routers with version V100R018C00 and above have commercially i
	mplemented the definition of PSID and use cases which is defined in section 2 an
	d Section 3.2 in this document, including all the "<bcp14>MUST</bcp14>" and "<bc
	p14>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</bc
	p14>" clauses while other use cases for PSID in section 3 are not yet implemente
	d.</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 implementatio
	n 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, whil
	e 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 T
	estcenter 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>" c
	lauses, 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/690
	E) 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 h
	ad been implemented, while other use cases for PSID in section 3 are not yet imp
	lemented.</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 s
	everal 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="S
	PN-L3"/>. This is reported by Weiqiang Cheng from China Mobile at September, 21,
	2023.</t>
	</section>
	</section>	</section>


	<section anchor="IANA">	<section anchor="IANA">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>

	<t>This document does not require any IANA actions.</t>	<t>This document has no IANA actions.</t>
	</section>	</section>
	</middle>	</middle>


	<back>	<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-EXTENS
		IONS"/>

	<references>	<references>
	<name>References</name>	<name>References</name>
	<references anchor="sec-normative-references">	<references anchor="sec-normative-references">
	<name>Normative References</name>	<name>Normative References</name>

	<reference anchor="RFC8402">
	<front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
	<title>Segment Routing Architecture</title>	02.xml"/>
	<author fullname="C. Filsfils" initials="C." role="editor" surname="	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
	Filsfils"/>	60.xml"/>
	<author fullname="S. Previdi" initials="S." role="editor" surname="P	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
	revidi"/>	19.xml"/>
	<author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
	<author fullname="B. Decraene" initials="B." surname="Decraene"/>	74.xml"/>
	<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 n
	ode 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 provi
	des a mechanism that allows a flow to be restricted to a specific topological pa
	th, while maintaining per-flow state only at the ingress node(s) to the SR domai
	n.</t>
	<t>SR can be directly applied to the MPLS architecture with no cha
	nge to the forwarding plane. A segment is encoded as an MPLS label. An ordered l
	ist of segments is encoded as a stack of labels. The segment to process is on th
	e top of the stack. Upon completion of a segment, the related label is popped fr
	om 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 segm
	ents 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 n
	ext 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 n
	ode steers a packet through a controlled set of instructions, called segments, b
	y 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 b
	ehavior 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</tit
	le>
	<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 sig
	nify the requirements in the specification. These words are often capitalized. T
	his document defines these words as they should be interpreted in IETF documents
	. This document specifies an Internet Best Current Practices for the Internet Co
	mmunity, 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</ti
	tle>
	<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 protoco
	l 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>
	</references>	</references>


	<references anchor="sec-informative-references">	<references anchor="sec-informative-references">
	<name>Informative References</name>	<name>Informative References</name>

	<reference anchor="RFC4426">	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.44
	<front>	26.xml"/>
	<title>Generalized Multi-Protocol Label Switching (GMPLS) Recovery F	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.55
	unctional Specification</title>	86.xml"/>
	<author fullname="J. Lang" initials="J." role="editor" surname="Lang	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.56
	"/>	54.xml"/>
	<author fullname="B. Rajagopalan" initials="B." role="editor" surnam	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.67
	e="Rajagopalan"/>	90.xml"/>
	<author fullname="D. Papadimitriou" initials="D." role="editor" surn	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.69
	ame="Papadimitriou"/>	65.xml"/>
	<date month="March" year="2006"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.86
	<abstract>	64.xml"/>
	<t>This document presents a functional description of the protocol	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.77
	extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)	99.xml"/>
	-based recovery (i.e., protection and restoration). Protocol specific formats an	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
	d mechanisms will be described in companion documents. [STANDARDS-TRACK]</t>	57.xml"/>
	</abstract>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
	</front>	91.xml"/>
	<seriesInfo name="RFC" value="4426"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
	<seriesInfo name="DOI" value="10.17487/RFC4426"/>	97.xml"/>
	</reference>
	<reference anchor="RFC5586">
	<front>
	<title>MPLS Generic Associated Channel</title>
	<author fullname="M. Bocci" initials="M." role="editor" surname="Boc
	ci"/>
	<author fullname="M. Vigoureux" initials="M." role="editor" surname=
	"Vigoureux"/>
	<author fullname="S. Bryant" initials="S." role="editor" surname="Br
	yant"/>
	<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 chann
	el associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition
	to MPLS pseudowires. In order to identify the presence of this Associated Channe
	l 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 lab
	el 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" surn
	ame="Niven-Jenkins"/>
	<author fullname="D. Brungard" initials="D." role="editor" surname="
	Brungard"/>
	<author fullname="M. Betts" initials="M." role="editor" surname="Bet
	ts"/>
	<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 P
	rofile (MPLS-TP). This document is a product of a joint effort of the Internatio
	nal Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile
	within the IETF MPLS and PWE3 architectures to support the capabilities and fun
	ctionalities of a packet transport network as defined by International Telecommu
	nications Union - Telecommunications Standardization Sector (ITU-T).</t>
	<t>This work is based on two sources of requirements: MPLS and PWE
	3 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 behavio
	r of the protocol mechanisms and procedures that constitute building blocks out
	of which the MPLS Transport Profile is constructed. The requirements are not imp
	lementation 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 acros
	s a network. This memo suggests ways of improving load balancing across MPLS net
	works using the concept of "entropy labels". It defines the concept, describes w
	hy entropy labels are useful, enumerates properties of entropy labels that allow
	maximal benefit, and shows how they can be signaled and used for various applic
	ations. 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 backha
	ul, 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) Extens
	ions 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 pa
	th without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). I
	t 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, includ
	ing an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Comput
	ation Element (PCE). This document specifies extensions to the Path Computation
	Element Communication Protocol (PCEP) that allow a stateful PCE to compute and i
	nitiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PC
	C) 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 per
	formance 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 de
	scribes 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 Statu
	s 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 I
	mplementation Status section. This will allow reviewers and working groups to as
	sign due consideration to documents that have the benefit of running code, which
	may serve as evidence of valuable experimentation and feedback that have made t
	he implemented protocols more mature.</t>
	<t>This process is not mandatory. Authors of Internet-Drafts are e
	ncouraged to consider using the process for their documents, and working groups
	are invited to think about applying the process to all of their protocol specifi
	cations. This document obsoletes RFC 6982, advancing it to a Best Current Practi
	ce.</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. Th
	is document describes a method of accomplishing this by using a technique called
	"Synonymous Flow Labels" in which labels that mimic the behavior of other label
	s provide the identification service. These identifiers can be used to trigger p
	er-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 Inter
	mediate System (IS-IS) router to advertise multiple types of supported Maximum S
	ID Depths (MSDs) at node and/or link granularity. Such advertisements allow enti
	ties (e.g., centralized controllers) to determine whether a particular Segment I
	D (SID) stack can be supported in a given network. This document only defines on
	e type of MSD: Base MPLS Imposition. However, it defines an encoding that can su
	pport other MSD types. This document focuses on MSD use in a network that is Seg
	ment 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 Maint
	enance (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="M
	izrahi"/>
	<date month="May" year="2022"/>
	<abstract>
	<t>In situ Operations, Administration, and Maintenance (IOAM) coll
	ects operational and telemetry information in the packet while the packet traver
	ses a path between two points in the network. This document discusses the data f
	ields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated i
	nto a variety of protocols, such as Network Service Header (NSH), Segment Routin
	g, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be u
	sed to complement OAM mechanisms based on, e.g., ICMP or other types of probe pa
	ckets.</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) Extens
	ions 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) p
	rovides
	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>	<!-- [I-D.ietf-pce-sr-bidir-path] IESG State: I-D Exists-->
	</abstract>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
	</front>	etf-pce-sr-bidir-path.xml"/>
	<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="Talaulika
	r">
	<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	<!-- [I-D.ietf-idr-sr-policy-path-segment] IESG State: I-D Exists-->
	carrying Path Segment and bidirectional path information.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.i
		etf-idr-sr-policy-path-segment.xml"/>


	</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/product
	s/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/pr
	oduct/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/flex
	e-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 Tec
	hnological Breakthroughs--China Mobile Research Institute Accelerates 5G R&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>
	</references>	</references>
	</references>	</references>

	<?line 505?>

	<section numbered="false" anchor="Acknowledgements">	<section numbered="false" anchor="Acknowledgements">
	<name>Acknowledgements</name>	<name>Acknowledgements</name>

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


	<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse">	<section anchor="contributors" numbered="false" toc="include" removeInRFC="f alse">
	<name>Contributors</name>	<name>Contributors</name>

	<?line 518?>

	<t>The following people have substantially contributed to this document.</t>	<t>The following people have substantially contributed to this document.</t>
	<contact initials="M." surname="Chen" fullname="Mach(Guoyi) Chen">	<contact initials="M." surname="Chen" fullname="Mach(Guoyi) Chen">

	<organization>Huawei Technologies Co., Ltd</organization>	<organization>Huawei Technologies Co., Ltd.</organization>
	<address>	<address>
	<email>mach.chen@huawei.com</email>	<email>mach.chen@huawei.com</email>
	</address>	</address>
	</contact>	</contact>
	<contact initials="L." surname="Wang" fullname="Lei Wang">	<contact initials="L." surname="Wang" fullname="Lei Wang">
	<organization>China Mobile</organization>	<organization>China Mobile</organization>
	<address>	<address>
	<email>wangleiyj@chinamobile.com</email>	<email>wangleiyj@chinamobile.com</email>
	</address>	</address>
	</contact>	</contact>
	<contact initials="A." surname="Liu" fullname="Aihua Liu">	<contact initials="A." surname="Liu" fullname="Aihua Liu">

	<organization>ZTE Corp</organization>	<organization>ZTE Corp.</organization>
	<address>	<address>
	<email>liu.aihua@zte.com.cn</email>	<email>liu.aihua@zte.com.cn</email>
	</address>	</address>
	</contact>	</contact>
	<contact initials="G." surname="Mirsky" fullname="Greg Mirsky">	<contact initials="G." surname="Mirsky" fullname="Greg Mirsky">

	<organization>ZTE Corp</organization>	<organization>ZTE Corp.</organization>
	<address>	<address>
	<email>gregimirsky@gmail.com</email>	<email>gregimirsky@gmail.com</email>
	</address>	</address>
	</contact>	</contact>
	<contact initials="G. S." surname="Mishra" fullname="Gyan S. Mishra">	<contact initials="G. S." surname="Mishra" fullname="Gyan S. Mishra">
	<organization>Verizon Inc.</organization>	<organization>Verizon Inc.</organization>
	<address>	<address>
	<email>gyan.s.mishra@verizon.com</email>	<email>gyan.s.mishra@verizon.com</email>
	</address>	</address>
	</contact>	</contact>
	</section>	</section>
	</back>	</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>	</rfc>

End of changes. 57 change blocks.
	1112 lines changed or deleted	271 lines changed or added
This html diff was produced by rfcdiff 1.48.