rfc9703xml2.original.xml   rfc9703.xml 
<?xml version="1.0"?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.2119.xml">
<!ENTITY RFC8287 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8287.xml">
<!ENTITY RFC8029 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8029.xml">
<!ENTITY RFC7705 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7705.xml">
<!ENTITY RFC8690 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8690.xml">
<!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8174.xml">
<!ENTITY RFC8403 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8403.xml">
<!ENTITY RFC8664 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8664.xml">
<!ENTITY RFC4271 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4271.xml">
<!ENTITY RFC5065 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5065.xml">
<!ENTITY RFC6286 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6286.xml">
<!ENTITY RFC9086 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.9086.xml">
<!ENTITY RFC9087 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.9087.xml">
<!ENTITY RFC7942 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7942.xml">
<!ENTITY RFC9256 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.9256.xml">
<!ENTITY RFC6793 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6793.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mpls-sr-epe-oam-19" ipr="trust200902">
<front>
<title abbrev="EPE-OAM">Label Switched Path (LSP) Ping/Traceroute for Segment
Routing (SR)
Egress Peer Engineering Segment Identifiers (SIDs)
with MPLS Data Plane</title>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde"> <!DOCTYPE rfc [
<organization>Juniper Networks Inc.</organization> <!ENTITY nbsp "&#160;">
<address> <!ENTITY zwsp "&#8203;">
<postal> <!ENTITY nbhy "&#8209;">
<street>Exora Business Park</street> <!ENTITY wj "&#8288;">
<city>Bangalore</city> ]>
<region>KA</region>
<code>560103</code>
<country>India</country>
</postal>
<email>shraddha@juniper.net</email>
</address>
</author>
<author initials="M." surname="Srivastava" fullname="Mukul Srivastava">
<organization>Juniper Networks Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>msri@juniper.net</email>
</address>
</author>
<author initials="K." surname="Arora" fullname="Kapil Arora"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<organization>Individual Contributor</organization> tf-mpls-sr-epe-oam-19" number="9703" consensus="true" ipr="trust200902" obsolete
<address> s="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="
<postal> 3" symRefs="true" sortRefs="true" version="3">
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>kapil.it@gmail.com</email>
</address>
</author>
<front>
<title abbrev="LSP Ping/Traceroute for SR EPE-SIDs with MPLS">Label Switched
Path (LSP) Ping/Traceroute for
Segment Routing (SR) Egress Peer Engineering (EPE) Segment Identifiers (SIDs
)
with MPLS Data Plane</title>
<seriesInfo name="RFC" value="9703"/>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde">
<organization>Juniper Networks Inc.</organization>
<address>
<postal>
<street>Exora Business Park</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>shraddha@juniper.net</email>
</address>
</author>
<author initials="M." surname="Srivastava" fullname="Mukul Srivastava">
<organization>Juniper Networks Inc.</organization>
<address>
<email>msri@juniper.net</email>
</address>
</author>
<author initials="K." surname="Arora" fullname="Kapil Arora">
<organization>Individual Contributor</organization>
<address>
<email>kapil.it@gmail.com</email>
</address>
</author>
<author initials="S." surname="Ninan" fullname="Samson Ninan"> <author initials="S." surname="Ninan" fullname="Samson Ninan">
<organization>Ciena</organization> <organization>Ciena</organization>
<address> <address>
<postal> <email>samson.cse@gmail.com</email>
<street></street> </address>
<city></city> </author>
<region></region> <author initials="X." surname="Xu" fullname="Xiaohu Xu">
<code></code> <organization>China Mobile</organization>
<country></country> <address>
</postal> <postal>
<email>samson.cse@gmail.com</email> <city>Beijing</city>
</address> <country>China</country>
</author> </postal>
<author initials="X." surname="Xu" fullname="Xiaohu Xu"> <email>xuxiaohu_ietf@hotmail.com </email>
<organization>China Mobile</organization> </address>
<address> </author>
<postal> <date year="2024" month="December"/>
<street></street> <area>RTG</area>
<city>Beijing</city> <workgroup>mpls</workgroup>
<region></region> <keyword>OAM</keyword>
<code></code> <keyword>EPE</keyword>
<country>China</country> <keyword>BGP-LS</keyword>
</postal> <keyword>BGP</keyword>
<email>xuxiaohu_ietf@hotmail.com </email> <keyword>SPRING</keyword>
</address> <keyword>SDN</keyword>
</author> <keyword>SID</keyword>
<date year="2024"/> <abstract>
<area>Routing</area> <t>Egress Peer Engineering (EPE) is an application of Segment Routing
<workgroup>Routing area</workgroup> (SR) that solves the problem of egress peer selection. The SR-based
<keyword>OAM</keyword> BGP-EPE solution allows a centralized controller, e.g., a
<keyword>EPE</keyword> Software-Defined Network (SDN) controller, to program any egress peer.
<keyword>BGP-LS</keyword> The EPE solution requires the node or the SDN controller to program 1) the
<keyword>BGP</keyword> PeerNode Segment Identifier (SID) describing a session between two
<keyword>SPRING</keyword> nodes, 2) the PeerAdj SID describing the link or links that are
<keyword>SDN</keyword> used by the sessions between peer nodes, and 3) the PeerSet SID
<keyword>SID</keyword> describing any connected interface to any peer in the related group.
This document provides new sub-TLVs for EPE-SIDs that are used in
<abstract> the Target FEC Stack TLV (Type 1) in MPLS Ping and Traceroute
<t>Egress Peer Engineering (EPE) is an application of Segment Routing to procedures.</t>
solve the problem of egress peer selection. The Segment Routing based </abstract>
BGP-EPE solution allows a centralized controller, e.g. a Software </front>
Defined Network (SDN) controller to program any egress peer. <middle>
The EPE solution requires the node or the SDN controller to program <section anchor="intro" numbered="true" toc="default">
the PeerNode Segment <name>Introduction</name>
Identifier(SID) describing a session between two nodes, the PeerAdj SID <t> Egress Peer Engineering (EPE), as defined in <xref target="RFC9087"
describing the link (one or more) that is used by sessions between peer nodes format="default"/>, is an effective mechanism that is used to select the e
, gress peer
and the PeerSet SID describing any connected interface to any peer in the rel link based on different criteria. In this scenario, egress peers may
ated group. belong to a completely different ownership. The EPE-SIDs provide the
This document provides new sub-TLVs for EPE Segment means to represent egress peer nodes, links, sets of links, and sets of
Identifiers (SID) that would be used in nodes. Many network deployments have built their networks consisting of
the MPLS Target stack TLV (Type 1), in MPLS Ping and Traceroute procedures. multiple Autonomous Systems (ASes) either for the ease of operations or as
a
</t> result of network mergers and acquisitions. The inter-AS links
</abstract> connecting any two ASes could be traffic-engineered using
EPE-SIDs in this case, where there is single ownership but different
</front> AS numbers. It is important to validate the control
plane to forwarding plane synchronization for these SIDs so that any
<middle> anomaly can be easily detected by the network operator. EPE-SIDs may
<section title="Introduction" anchor='intro'> also be used in an ingress Segment Routing (SR) policy <xref target="RFC92
<t> Egress Peer Engineering (EPE) as defined in 56"
<xref target ='RFC9087'/> is format="default"/> to choose exit points where the remote AS has
an effective mechanism to select the egress peer link based on different criteri a completely different ownership. This scenario is out of scope for this
a. document.
In this scenario, egress peers may belong to a completely different ownership. </t>
The EPE-SIDs provide means to represent egress peer nodes, links, sets of links <figure anchor="reference_diagram">
and sets of nodes. <name>Reference Diagram</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Many network
deployments have built their networks consisting of multiple Autonomous
Systems, either for the ease of operations or as a result of network mergers and
acquisitions.
The inter-AS links connecting any two Autonomous Systems could be traffic-engine
ered
using EPE-SIDs in this case, where there is single ownership but different AS
numbers.
It is important to validate
the control plane to forwarding plane synchronization for these SIDs so
that any anomaly can be detected easily by the network operator.
EPE-SIDs may also be used in ingress SR policy <xref target ='RFC9256'/>to choos
e exit points
where the remote AS belongs to completely different
ownership. This scenario is out of scope of this document.
</t>
<t>
<figure anchor="reference_diagram" title="Reference Diagram">
<artwork>
+---------+ +------+ +---------+ +------+
| | | | | | | |
| H B------D G | H B------D G
| | +---/| AS 2 |\ +------+ | | +---/| AS2 |\ +------+
| |/ +------+ \ | |---L/8 | |/ +------+ \ | |---L/8
A AS1 C---+ \| | A AS1 C---+ \| |
| |\\ \ +------+ /| AS 4 |---M/8 | |\\ \ +------+ /| AS4 |---M/8
| | \\ +-E |/ +------+ | | \\ +-E |/ +------+
| X | \\ | K | X | \\ | K
| | +===F AS 3 | | | +===F AS3 |
+---------+ +------+ +---------+ +------+]]></artwork>
</figure>
</artwork> <t>In <xref target="reference_diagram" format="default"/>, EPE-SIDs are
</figure> configured on AS1 towards AS2 and AS3 and advertised in the Border
In this reference diagram, EPE-SIDs are Gateway Protocol - Link State (BGP-LS) <xref target="RFC9086"
configured on AS1 towards AS2 and AS3 and format="default"/>. In certain cases, the EPE-SIDs advertised by the
advertised in BGP-LS <xref target="RFC9086"/>. control plane may not be in synchronization with the label programmed in
In certain cases the EPE-SIDs advertised by the control plane may not be in the data plane. For example, on C, a PeerAdj SID could be advertised to
synchronization with the label programmed in the data plane. For example, indicate it is for the link C-&gt;D. Due to some software anomaly, the
on C a PeerAdj SID could be advertised to indicate it is for the link C->D. actual data forwarding on this PeerAdj SID could be happening over the
Due to some software anomaly, the actual data forwarding on this PeerAdj SID C-&gt;E link. If E had relevant data paths for further forwarding the
could be happening over the C->E link. If E had relevant data paths for fur packet, this kind of anomaly would go unnoticed by the network operator.
ther A detailed example of a correctly programmed state and an incorrectly
forwarding the packet, this kind of anomaly will go unnoticed by the network programmed state along with a description of how the incorrect state can
operator. be detected is described in <xref target="Appendix" format="default"/>.
A detailed example of a correctly programmed state and an incorrectly progra A Forwarding Equivalence Class (FEC) definition for the EPE-SIDs will
mmed detail the control plane association of the SID. The
state along with a description of how the incorrect state can be detected data plane validation of the SID will be done during the MPLS Traceroute
is procedure. When there is a multi-hop External BGP (EBGP) session
described in <xref target="APPENDIX"/>. between the ASBRs, a PeerNode SID is advertised, and the traffic
A FEC definition for the EPE-SIDs will define the details of the control <bcp14>MAY</bcp14> be load-balanced between the interfaces connecting
plane association of the SID. The data plane validation of the SID will the two nodes. In <xref target="reference_diagram" format="default"/>,
be done during the MPLS traceroute procedure. When there is a multi-hop EBG C and F could have a PeerNode SID advertised. When the Operations,
P Administration, and Maintenance (OAM) packet is received on F, it needs
session between the ASBRs, PeerNode SID is advertised, and the traffic MAY b to be validated that the packet came from one of the two interfaces
e connected to C.
load-balanced between the interfaces connecting the two nodes. In the refer </t>
ence <t> This document provides Target Forwarding Equivalence Class (FEC)
diagram, C and F could have a PeerNode-SID advertised. When the OAM packet Stack TLV definitions for EPE-SIDs. This solution requires the
is node constructing the Target FEC Stack TLV to determine the types of
received on F, it needs to be validated that the packet came from one of SIDs along the path of the LSP. Other procedures for MPLS Ping and
the two interfaces connected to C. Traceroute, as defined in <xref target="RFC8287" sectionFormat="of"
</t> section="7"/> and clarified in <xref target="RFC8690" format="default"/>,
<t> This document provides Target Forwarding Equivalence Class (FEC) are applicable for EPE-SIDs as well.</t>
stack TLV definitions for EPE-SIDs. This solution requires that the node </section>
constructing the target FEC stack can <section anchor="operation" numbered="true" toc="default">
determine the type of the SIDs along the path of the <name>Theory of Operation</name>
LSP. Other procedures for MPLS Ping and Traceroute <t><xref target="RFC9086" format="default"/> provides mechanisms to
as defined in <xref target="RFC8287"/> section 7 and clarified by <xref target advertise the EPE-SIDs in BGP-LS. These EPE-SIDs may be used to build SR
="RFC8690"/> paths and may be communicated using extensions described in <xref
are applicable for EPE-SIDs as well.</t> target="I-D.ietf-idr-bgp-sr-segtypes-ext" format="default"/> and <xref
target="I-D.ietf-idr-sr-policy-safi" format="default"/> or Path
</section> Computation Element Protocol (PCEP) extensions as defined in <xref
target="RFC8664" format="default"/>. Data plane monitoring for such
<section title="Theory of Operation" anchor='operation'> paths that consist of EPE-SIDs will use extensions defined in this
<t><xref target ='RFC9086'/> provides document to build the Target FEC Stack TLV. The MPLS Ping and
mechanisms to advertise the EPE-SIDs in BGP-LS. These EPE-SIDs Traceroute procedures <bcp14>MAY</bcp14> be initiated by the head-end of
may be used to build Segment Routing paths as the SR path or a centralized topology-aware data plane monitoring
described in system, as described in <xref target="RFC8403" format="default"/>. The
<xref target ='I-D.ietf-idr-segment-routing-te-policy'/> or extensions in <xref target="I-D.ietf-idr-bgp-sr-segtypes-ext"
using Path Computation Element Protocol (PCEP) extensions as defined format="default"/>, <xref target="I-D.ietf-idr-sr-policy-safi"
in <xref target="RFC8664"/>. Data plane monitoring for such paths which format="default"/>, and <xref target="RFC8664" format="default"/> do not
consist of EPE-SIDs will use extensions defined in this document to define how to acquire and carry the details of the SID that can be used
build the Target FEC stack TLV. The MPLS Ping and Traceroute procedures to construct the FEC. Such extensions are out of scope for this
MAY be initiated by the head-end of the Segment Routing path or a centralized document. The node initiating the data plane monitoring may acquire the
topology-aware data plane monitoring system as described in details of EPE-SIDs through BGP-LS advertisements, as described in <xref
<xref target="RFC8403"/>. The extensions in target="RFC9086" format="default"/>. There may be other possible
<xref target ='I-D.ietf-idr-segment-routing-te-policy'/> and mechanisms that can be used to learn the definition of the SID from the
<xref target="RFC8664"/> do not define how to carry the details controller. Details of such mechanisms are out of scope for this
of the SID that can be used to construct the FEC. Such document.</t>
extensions are out of the scope for this document. <t>The EPE-SIDs are advertised for inter-AS links that run EBGP
The node initiating the data plane monitoring sessions. <xref target="RFC9086" format="default"/> does not define the
may acquire the details of EPE-SIDs through BGP-LS advertisements as detailed procedures of how to operate EBGP sessions in a scenario with
described in <xref target ='RFC9086'/>. There may be other unnumbered interfaces. Therefore, these scenarios are out of scope for
possible mechanisms to learn the definition of the SID this document. Anycast and multicast addresses are not in the scope of
from controller. Details of such mechanisms are this document. During the AS migration scenario, procedures described in
out of scope for this document.</t> <xref target="RFC7705" format="default"/> may be in force. In these
<t>The EPE-SIDs are advertised for inter-AS links which run EBGP sessions. scenarios, if the local and remote AS fields in the FEC (as described in
<xref target ='RFC9086'/> <xref target="FEC_definitions" format="default"/>) carry the globally
does not define the detailed procedures to operate EBGP sessions in a scenario w configured AS Number and not the "local AS" (as defined in <xref
ith target="RFC7705" format="default"/>), then the FEC validation procedures m
unnumbered interfaces. Therefore, these scenarios are ay
out of scope for this document. fail. </t>
Anycast and multicast addresses are not in the scope of this document. <t>As described in <xref target="intro" format="default"/>, this
document defines Target FEC Stack TLVs for EPE-SIDs that can be used in
detecting MPLS data plane failures <xref target="RFC8029"
format="default"/>. This mechanism applies to paths created across
ASes of cooperating administrations. If the ping or traceroute
packet enters a non-cooperating AS domain, it might be dropped by the
routers in the non-cooperating domain. Although a complete path
validation cannot be done across non-cooperating domains, it still
provides useful information that the ping or traceroute packet entered a
non-cooperating domain.</t>
</section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<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, <xref target="RFC2119"
format="default"/>, <xref target="RFC8174" format="default"/> when, and
only when, they appear in all capitals, as shown here. </t>
</section>
<section anchor="FEC_definitions" numbered="true" toc="default">
<name>FEC Definitions</name>
<t> In this document, three new sub-TLVs are defined for the Target FEC St
ack TLV (Type
1), the Reverse-Path Target FEC Stack TLV (Type 16), and the Reply Path
TLV (Type 21); see <xref target="sub_tlv"/>.</t>
During AS migration scenario procedures <section anchor="peer_node_sid" numbered="true" toc="default">
described in <xref target="RFC7705"/> may be in force. In these scenarios, <name>PeerNode SID Sub-TLV</name>
if the local and remote AS fields in the FEC <figure anchor="peer_node_sid_tlv">
as described in <xref target="FEC_definitions"/> carries the <name>PeerNode SID Sub-TLV</name>
globally configured ASN and not the "local AS" as defined in <xref target="RFC77 <artwork name="" type="" align="left" alt=""><![CDATA[
05"/>, 0 1 2 3
the FEC validation procedures may fail. </t> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
<t> As described in <xref target="intro"/>, this document defines FEC stack TLVs +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
for EPE-SIDs, that can be used in detecting MPLS data plane |Type = 39 | Length |
failures <xref target="RFC8029"/>. This mechanism applies to paths created acros +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s | Local AS Number (4 octets) |
across ASes of co-operating administrations. If the ping or traceroute packet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
enters a non co-operating AS domain, it might be dropped by the routers in the | Remote AS Number (4 octets) |
non co-operating domain. Although complete path validation cannot be done across +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
, | Local BGP Router ID (4 octets) |
non co-operating domains, it still provides useful information that the +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ping/traceroute packet entered a non co-operating domain.</t> | Remote BGP Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
</section> <dl>
<section title="Requirements Language"> <dt>Type:</dt><dd>2 octets</dd>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <dt>Value:</dt><dd>39</dd>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <dt>Length:</dt><dd>2 octets</dd>
"OPTIONAL" in this document are to be interpreted as described in BCP 14, <dt>Value:</dt><dd>16</dd>
<xref target="RFC2119"/>, <xref target="RFC8174"/> when, and <dt>Local AS Number:</dt><dd>4 octets. The unsigned integer
only when, they appear in all capitals, as shown here. </t> representing the AS number <xref target="RFC6793" format="default"/>
</section> of the AS to which the PeerNode SID advertising node belongs. If
Confederations <xref target="RFC5065" format="default"/> are in use,
and if the remote node is a member of a different Member-AS within
the local Confederation, this is the Member-AS Number inside the
Confederation and not the Confederation Identifier.</dd>
<dt>Remote AS Number:</dt><dd>4 octets. The unsigned integer
representing the AS number <xref target="RFC6793" format="default"/>
of the AS of the remote node for which the PeerNode SID is
advertised. If Confederations <xref target="RFC5065"
format="default"/> are in use, and if the remote node is a member of
a different Member-AS within the local Confederation, this is the
Member-AS Number inside the Confederation and not the Confederation
Identifier.</dd>
<dt>Local BGP Router ID:</dt><dd>4 octets. The unsigned integer
representing the BGP Identifier of the PeerNode SID advertising node
as defined in <xref target="RFC4271" format="default"/> and <xref
target="RFC6286" format="default"/>. </dd>
<dt>Remote BGP Router ID:</dt><dd>4 octets. The unsigned integer
representing the BGP Identifier of the remote node as defined in
<xref target="RFC4271" format="default"/> and <xref target="RFC6286"
format="default"/>. </dd>
</dl>
<section anchor='FEC_definitions' title='FEC Definitions'> <t>When there is a multi-hop EBGP session between two ASBRs, a
PeerNode SID is advertised for this session, and traffic can be
load-balanced across these interfaces. An EPE controller that
performs bandwidth management for these links should be aware of the
links on which the traffic will be load-balanced. As per <xref
target="RFC8029" format="default"/>, the node advertising the EPE-SIDs
will send a Downstream Detailed Mapping (DDMAP) TLV specifying the
details of the next-hop interfaces. Based on this information, the
controller <bcp14>MAY</bcp14> choose to verify the actual forwarding
state with the topology information that the controller has. On the
router, the validation procedures will include the received DDMAP
validation, as specified in <xref target="RFC8029" format="default"/>,
to verify the control state and the forwarding state synchronization
on the two routers. Any discrepancies between the controller's state
and the forwarding state will not be detected by the procedures
described in this document.</t>
</section>
<section anchor="peer_adj_sid" numbered="true" toc="default">
<name>PeerAdj SID Sub-TLV</name>
<figure anchor="peer_adj_sid_tlv">
<name>PeerAdj SID Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = 38 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adj type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local BGP Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote BGP Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Address (4/16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface Address (4/16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t> <dl>
Three new sub-TLVs are defined for the Target FEC Stack TLV (Type 1),
the Reverse-Path Target FEC Stack TLV (Type 16), and the Reply Path
TLV (Type 21).</t>
<figure anchor="sub_tlv" title="New sub-TLV types">
<artwork>
Sub-Type Sub-TLV Name
-------- ---------------
TBD1 PeerAdj SID Sub-TLV
TBD2 PeerNode SID Sub-TLV
TBD3 PeerSet SID Sub-TLV
</artwork> <dt>Type:</dt><dd>2 octets </dd>
</figure> <dt>Value:</dt><dd>38</dd>
<dt>Length:</dt><dd>2 octets</dd>
<dt>Value:</dt><dd>Variable based on the IPv4/IPv6 interface
address. Length excludes the length of the Type and Length fields. For
IPv4 interface addresses, the length will be 28 octets. In the case of
an
IPv6 address, the length will be 52 octets.</dd>
<dt>Adj type:</dt><dd>1 octet</dd>
<dt>Value:</dt><dd>Set to 1 when the Adjacency Segment is IPv4. Set to
2 when the Adjacency Segment is IPv6.</dd>
<dt>RESERVED:</dt><dd>3 octets. <bcp14>MUST</bcp14> be zero when
sending and ignored on receiving.</dd>
<dt>Local AS Number:</dt><dd>4 octets. The unsigned integer
representing the AS number <xref target="RFC6793" format="default"/>
of the AS to which the PeerAdj SID advertising node belongs. If
Confederations <xref target="RFC5065" format="default"/> are in use,
and if the remote node is a member of a different Member-AS within the
local Confederation, this is the Member-AS Number inside the
Confederation and not the Confederation Identifier.</dd>
<dt>Remote AS Number:</dt><dd>4 octets. The unsigned integer
representing the AS number <xref target="RFC6793" format="default"/> of
the remote node's AS for which the PeerAdj SID is advertised. If
Confederations <xref target="RFC5065" format="default"/> are in use,
and if the remote node is a member of a different Member-AS within the
local Confederation, this is the Member-AS Number inside the
Confederation and not the Confederation Identifier.</dd>
<dt>Local BGP Router ID:</dt><dd>4 octets. The unsigned integer
representing the BGP Identifier of the PeerAdj SID advertising node as
defined in <xref target="RFC4271" format="default"/> and <xref
target="RFC6286" format="default"/>.</dd>
<dt>Remote BGP Router ID:</dt><dd>4 octets. The unsigned integer
representing the BGP Identifier of the remote node as defined in <xref
target="RFC4271" format="default"/> and <xref target="RFC6286"
format="default"/>.</dd>
<dt>Local Interface Address:</dt><dd>4 octets or 16 octets. In the case
of
PeerAdj SID, the local interface address corresponding to the PeerAdj SI
D
should be specified in this field. For IPv4, this field is 4 octets;
for IPv6, this field is 16 octets. Link-local IPv6 addresses are not
in the scope of this document.</dd>
<dt>Remote Interface Address:</dt><dd>4 octets or 16 octets. In the
case of PeerAdj SID, the remote interface address corresponding to the
PeerAdj SID should be specified in this field. For IPv4, this field
is 4 octets; for IPv6, this field is 16 octets. Link-local IPv6
addresses are not in the scope of this document.</dd>
</dl>
<section anchor='peer_node_sid' title='PeerNode SID Sub-TLV'> <t><xref target="RFC9086" format="default"/> mandates sending a local
interface ID and remote interface ID in the link descriptors and
allows a value of 0 in the remote descriptors. It is useful to
validate the incoming interface for an OAM packet, but if the remote
descriptor is 0, this validation is not possible. Optional link
descriptors of local and remote interface addresses are allowed as
described in <xref target="RFC9086" sectionFormat="of"
section="4.2"/>. In this document, it is <bcp14>RECOMMENDED</bcp14>
to send these optional descriptors and use them to validate incoming
interfaces. When these local and remote interface addresses are not
available, an ingress node can send 0 in the local and/or remote
interface address field. The receiver <bcp14>SHOULD</bcp14> skip the
validation for the incoming interface if the address field contains
0.</t>
</section>
<section anchor="peer_set_sid" numbered="true" toc="default">
<name>PeerSet SID Sub-TLV</name>
<figure anchor="peer_set_sid_tlv">
<name>PeerSet SID Sub-TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = 40 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local BGP Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No. of elements in set | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote BGP Router ID (4 octets) |
<figure anchor="peer_node_sid_tlv" title="PeerNode SID Sub-TLV"> One element in set consists of the details below
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote BGP Router ID (4 octets) |
</figure>
<artwork> <dl>
<dt>Type:</dt><dd>2 octets</dd>
<dt>Value:</dt><dd>40</dd>
<dt>Length:</dt><dd>2 octets</dd>
<dt>Value:</dt><dd>Expressed in octets and is a variable based on the
number of elements in the set. The length field does not include the
length of Type and Length fields.</dd>
<dt>Local AS Number:</dt><dd>4 octets. The unsigned integer
representing the AS number <xref target="RFC6793" format="default"/>
of the AS to which the PeerSet SID advertising node belongs. If
Confederations <xref target="RFC5065" format="default"/> are in use,
and if the remote node is a member of a different Member-AS within the
local Confederation, this is the Member-AS Number inside the
Confederation and not the Confederation Identifier.</dd>
<dt>Local BGP Router ID:</dt><dd>4 octets. The unsigned integer
representing the BGP Identifier of the PeerSet SID advertising node, as
defined in <xref target="RFC4271" format="default"/> and <xref
target="RFC6286" format="default"/>. </dd>
<dt>No. of elements in set:</dt><dd>2 octets. The number of remote
ASes over which the set SID performs load-balancing.</dd>
<dt>Reserved:</dt><dd>2 octets. <bcp14>MUST</bcp14> be zero when sent
and ignored when received.</dd>
<dt>Remote AS Number:</dt><dd>4 octets. The unsigned integer
representing the AS number <xref target="RFC6793" format="default"/>
of the remote node's AS for which the PeerSet SID is
advertised. If Confederations <xref target="RFC5065"
format="default"/> are in use, and if the remote node is a member of a
different Member-AS within the local Confederation, this is the
Member-AS Number inside the Confederation and not the Confederation
Identifier.</dd>
<dt>Remote BGP Router ID:</dt><dd>4 octets. The unsigned integer
representing the BGP Identifier of the remote node as defined in <xref
target="RFC4271" format="default"/> and <xref target="RFC6286"
format="default"/>. </dd>
</dl>
<t>PeerSet SID may be associated with a number of PeerNode SIDs and
PeerAdj SIDs. The remote AS number and the Router ID of each of these
PeerNode SIDs and PeerAdj SIDs <bcp14>MUST</bcp14> be included in the
FEC.</t>
</section>
</section>
<section anchor="validation" numbered="true" toc="default">
<name>EPE-SID FEC Validation</name>
<t>When a remote ASBR of the EPE-SID advertisement receives the MPLS OAM
packet with the top FEC being the EPE-SID, it <bcp14>MUST</bcp14>
perform validity checks on the content of the EPE-SID FEC sub-TLV. The
basic length check should be performed on the received FEC.</t>
<figure anchor="length_check">
<name>Length Validation</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
PeerAdj SID sub-TLV
-----------
If Adj type = 1, Length should be 28 octets
If Adj type = 2, Length should be 52 octets
0 1 2 3 PeerNode SID sub-TLV
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length = (20 + No. of IPv4 interface pairs * 8 +
|Type = TBD2 | Length | No. of IPv6 interface pairs * 32) octets
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local BGP router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote BGP Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> PeerSet SID sub-TLV
-----------
Length = (9 + No. of elements in the set *
(8 + No. of IPv4 interface pairs * 8 +
No. of IPv6 interface pairs * 32) octets]]></artwork>
</figure> </figure>
<t>Type : 2 octets </t>
<t> Value:TBD2</t>
<t>Length : 2 octets </t>
<t> Value: 16
</t>
<t>Local AS Number : 4 octets</t>
<t>The unsigned integer representing the AS number <xref
target ='RFC6793'/>
of the AS to which the PeerNode SID advertising
node belongs. If Confederations <xref target ='RFC5065'/> are in
use, and if the
remote node is a member of a different Member-AS within the local
Confederation, this is the Member-AS Number inside the Confederat
ion
and not the Confederation Identifier.</t>
<t>Remote AS Number : 4 octets</t> <t>If a malformed FEC sub-TLV is received, then a return code of 1,
"Malformed echo request received", as defined in <xref target="RFC8029"
<t>The unsigned integer representing the AS number <xref format="default"/> <bcp14>MUST</bcp14> be sent. The section below is
target ='RFC6793'/> appended to the procedure given in step 4a of <xref target="RFC8287"
of the AS of the remote node for which the sectionFormat="of" section="7.4"/>.
PeerNode SID is advertised. If Confederations <xref target ='RFC5 </t>
065'/> are in use,
and if the remote node is a member of a different Member-AS withi
n
the local Confederation, this is the Member-AS Number inside the
Confederation and not the Confederation Identifier.</t>
<t>Local BGP Router ID : 4 octets </t> <!--[rfced] Section 5.1.
<t>unsigned integer representing the BGP Identifier
of the PeerNode SID advertising node as defined in
<xref target ='RFC4271'/> and <xref target ='RFC6286'/>.
</t>
<t>Remote BGP Router ID : 4 octets</t>
<t>unsigned integer representing
the BGP Identifier of the remote node as defined in
<xref target ='RFC4271'/> and <xref target ='RFC6286'/>.
</t>
<t>When there is a multi-hop EBGP session between two ASBRs, PeerNode SID i d) Should "the remote AS field" or "one of the remote AS
s fields" be used for consistency?
advertised for this session and traffic can be
load balanced across these interfaces.
An EPE controller that does bandwidth management for these links should be
aware of the links on which the traffic will be load-balanced. As per
<xref target ='RFC8029'/>, the node advertising the EPE SIDs will send
Downstream Detailed Mapping TLV (DDMAP TLV) specifying the details of nextho
p
interfaces, the OAM packet will be sent out. Based on this information
controller MAY choose to verify the actual forwarding state with the topolog
y
information controller has. On the router, the validation procedures will i
nclude,
received DDMAP validation as specified in <xref target ='RFC8029'/> to verif
y the
control and forwarding state synchronization on the two routers. Any discrep
ancies
between controller's state and forwarding state will not be detected by the
procedures described in the document.</t>
</section> Original:
- Validate that the receiving node's BGP Local AS matches
with the remote AS field in the received PeerNode SID
FEC sub-TLV.
<section anchor='peer_adj_sid' title='PeerAdj SID Sub-TLV'> - Validate that the Receiving Node BGP Local AS matches
with one of the remote AS field in the received
PeerSet SID FEC sub-TLV.
-->
<figure anchor="peer_adj_sid_tlv" title="PeerAdj SID Sub-TLV"> <section anchor="fec_validation" numbered="true" toc="default">
<name>EPE-SID FEC Validation Rules</name>
<t>This is an example of Segment Routing IGP-Prefix, IGP-Adjacency
SID, and EPE-SID validations. Note that the term "receiving node" in
this section corresponds to the node that receives the OAM message
with the Target FEC Stack TLV.</t>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
Else, if the Label-stack-depth is 0 and the Target FEC Stack sub-TLV
at FEC stack-depth is 38 (PeerAdj SID sub-TLV), {
0 1 2 3 Set the Best-return-code to 10, "Mapping for this FEC is not
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 the given label at stack-depth <RSC>" [RFC8029]. Check if
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ any below conditions fail:
|Type = TBD1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adj-Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local BGP router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote BGP Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface address (4/16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface address (4/16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> - Validate that the receiving node's BGP Local AS matches
</figure> with the remote AS field in the received PeerAdj SID
<t>Type : 2 octets </t> sub-TLV.
<t> Value: TBD1</t>
<t>Length : 2 octets</t> - Validate that the receiving node's BGP Router-ID
<t> Value: variable based on IPv4/IPv6 interfac matches with the Remote Router ID field in the
e address. received PeerAdj SID sub-TLV.
Length excludes the length of Type and Length
fields.For IPv4 interface addresses length will
be 28 octets. In case of IPv6 address length will
be
52 octets.</t>
<t>Adj-Type : 1 octet</t>
<t> Value: Set to 1 when the Adjacency Segment
is IPv4
Set to 2 when the Adjacency Segment is IPv6
</t>
<t> RESERVED : 3 octets. MUST be zero when sending, and ig
nored on receiving.</t>
<t>Local AS Number : 4 octets</t>
<t>The unsigned integer representing the AS number <xref target ='RFC679
3'/> of the AS to which the PeerAdj SID advertising
node belongs. If Confederations <xref target ='RFC5065'/> are in
use, and if the
remote node is a member of a different Member-AS within the local
Confederation, this is the Member-AS Number inside the Confederat
ion
and not the Confederation Identifier.</t>
<t>Remote AS Number : 4 octets</t>
<t>The unsigned integer representing the AS number<xref target ='RFC
6793'/> of the AS of the remote node for which the
PeerAdj SID is advertised. If Confederations <xref target ='RFC50
65'/> are in use,
and if the remote node is a member of a different Member-AS withi
n
the local Confederation, this is the Member-AS Number inside the
Confederation and not the Confederation Identifier.</t>
<t>Local BGP Router ID : 4 octets </t>
<t> unsigned integer representing the
BGP Identifier of the PeerAdj SID advertising node as def
ined in
<xref target ='RFC4271'/> and <xref target ='RFC6286'/>.
</t>
<t>Remote BGP Router ID : 4 octets </t>
<t> unsigned integer representing
the BGP Identifier of the remote node
as defined in <xref target ='RFC4271'/> and <xref target ='RFC628
6'/>. </t>
<t>Local Interface Address :4 octets/16 octets</t>
<t>In case of PeerAdj SID, Local interface address corresponding
to the PeerAdj SID should be specified in this field.
For IPv4,this field is 4 octets; for IPv6, this field is 16
octets.
Link-local IPv6 addresses are not in the scope of this d
ocument.</t>
<t>Remote Interface Address :4 octets/16 octets</t> - Validate that there is an EBGP session with a peer
<t>In case of PeerAdj SID Remote interface address corresponding having a local AS number and BGP Router-ID as
to the PeerAdj SID should be apecified in this field. For IPv4, specified in the local AS number and Local Router-ID
this field is 4 octets; for IPv6, this field is 16 field in the received PeerAdj SID sub-TLV.
octets.
Link-local IPv6 addresses are not in the scope of this d
ocument..</t>
<t><xref target ='RFC9086'/> mandates sending If the remote interface address is not zero, validate the
local interface ID and remote interface ID in the Link Descriptors and a incoming interface. Set the Best-return-code to 35,
llows "Mapping for this FEC is not associated with the incoming
a value of 0 in the remote descriptors. It is useful to validate the interface" [RFC8287]. Check if any below conditions fail:
incoming interface for an OAM packet and if the remote descriptor is 0
this validation is not possible.
<xref target ='RFC9086'/> allows optional
link descriptors of local and remote interface addresses as
described in section 4.2. This document RECOMMENDs sending these option
al
descriptors and using them to validate incoming interface. When these
local and remote interface addresses are not available, an ingress
node can send 0 in the local and/or remote interface address field.
The receiver SHOULD skip the validation for the incoming interface
if the address field contains 0.</t>
</section> - Validate that the incoming interface on which the
OAM packet was received matches with the remote
interface specified in the PeerAdj SID sub-TLV.
<section anchor='peer_set_sid' title='PeerSet SID Sub-TLV'> If all above validations have passed, set the return code to 3,
<figure anchor="peer_set_sid_tlv" title="PeerSet SID Sub-TLV"> "Replying router is an egress for the FEC at stack-depth <RSC>"
[RFC8029].
}
<artwork> Else, if the Target FEC Stack sub-TLV at FEC stack-depth is 39
(PeerNode SID sub-TLV), {
0 1 2 3 Set the Best-return-code to 10, "Mapping for this FEC is not
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 the given label at stack-depth <RSC>" [RFC8029]. Check if any
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ below conditions fail:
|Type = TBD3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local BGP router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No.of elements in set | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote BGP Router ID (4 octets) |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
One element in set consists of below details - Validate that the receiving node's BGP Local AS matches
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ with the remote AS field in the received PeerNode SID
| Remote AS Number (4 octets) | FEC sub-TLV.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote BGP Router ID (4 octets) |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
</artwork> - Validate that the receiving node's BGP Router-ID matches
</figure> with the Remote Router ID field in the received
<t>Type : 2 octets </t> PeerNode SID FEC.
<t> Value: TBD3</t>
<t>Length : 2 octets </t>
<t> Value: Expressed in octets and variable base
d on the number of
elements in the set. The length field
does not include the length of
Type and Length fields.</t>
<t>Local AS Number :4 octets </t> - Validate that there is an EBGP session with a peer
<t>The unsigned integer representing the AS number <xref target ='RFC having a local AS number and BGP Router-ID as
6793'/> of the AS to which the PeerSet SID advertising specified in the local AS number and Local Router-ID
node belongs. If Confederations <xref target ='RFC5065'/> are in field in the received PeerNode SID FEC sub-TLV.
use, and if the
remote node is a member of a different Member-AS within the local
Confederation, this is the Member-AS Number inside the Confederat
ion
and not the Confederation Identifier.</t>
<t>Local BGP Router ID : 4 octets </t>
<t> unsigned integer representing
the BGP Identifier of the PeerSet SID advertising node as defined in
<xref target ='RFC4271'/> and <xref target ='RFC6286'/>.
</t>
<t>No.of elements in set: 2 octets</t>
<t> The number of remote ASes over
which the set SID performs load balancin
g.</t>
<t> Reserved : 2 octets. MUST be zero when sent and ignored when
received.</t>
<t>Remote AS Number : 4 octets </t> If all above validations have passed, set the return code to 3,
<t>The unsigned integer representing the AS number <xref target ='RF "Replying router is an egress for the FEC at stack-depth <RSC>"
C6793'/> of the AS of the remote node for which the [RFC8029].
PeerSet SID is advertised. If Confederations <xref target ='RFC50 }
65'/> are in use, Else, if the Target FEC Stack sub-TLV at FEC stack-depth is 40
and if the remote node is a member of a different Member-AS withi (PeerSet SID sub-TLV), {
n
the local Confederation, this is the Member-AS Number inside the
Confederation and not the Confederation Identifier.</t>
<t>Remote BGP Router ID : 4 octets </t> Set the Best-return-code to 10, "Mapping for this FEC is not
<t>unsigned integer representing the given label at stack-depth <RSC>" [RFC8029]. Check if any
the BGP Identifier of the remote node below conditions fail:
as defined in <xref target ='RFC4271'/> and <xref target
='RFC6286'/>. </t>
<t>PeerSet SID may be associated with a number of PeerNode - Validate that the receiving node's BGP Local AS matches
SIDs and PeerAdj SIDs. The remote AS number and the Router ID of each o with one of the remote AS fields in the received
f these PeerNode SIDs PeerSet SID FEC sub-TLV.
PeerAdj SIDs MUST be included in the FEC.</t>
</section> - Validate that the receiving node's BGP Router-ID matches
with one of the Remote Router ID fields in the
received PeerSet SID FEC sub-TLV.
</section> - Validate that there is an EBGP session with a peer having
a local AS number and BGP Router-ID as specified in the
local AS number and Local Router-ID fields in the received
PeerSet SID FEC sub-TLV.
<section anchor="validation" title="EPE-SID FEC validation"> If all above validations have passed, set the return code to 3,
<t> "Replying router is an egress for the FEC at stack-depth <RSC>"
When a remote ASBR of the EPE-SID advertisement receives the MPLS [RFC8029].
OAM packet with top FEC being the EPE-SID, }]]></artwork>
it MUST perform validity checks on the </section>
content of the EPE-SID FEC sub-TLV. </section>
The basic length check should be performed on the received FEC. <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<figure anchor="length_check" title="Length Validation"> <!-- [rfced] We have included some specific questions about the IANA
text below. In addition to responding to those questions, please
review all of the IANA-related updates carefully and let us know
if any further updates are needed.
<artwork> a) It appears that the "IANA Considerations" section references the
PeerAdj SID "Sub-TLVs for TLV Types 1, 16, and 21" registry in the "Multiprotocol
----------- Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
if Adj type = 1 Length should be 28 octets registry group, but it does not include a citation for this registry
If Adj type =2 Length should be 52 octets here or in the references section.
PeerNode SID May we add the following citation as a normative or informative
------------- reference as shown below?
Length = ( 20 + No.of IPv4 interface pairs * 8 +
No.of IPv6 interface pairs * 32 ) octets
PeerSet SID Original:
----------- IANA is requested to allocate three new Target FEC stack sub-TLVs
Length = (9 + No.of elements in the set * from the "Sub-TLVs for TLV types 1,16 and 21" subregistry in the
(8 + No.of IPv4 interface pairs * 8 + "TLVs" registry of the "Multi-Protocol Label switching (MPLS) Label
No.of IPv6 interface pairs * 32)) octets Switched Paths (LSPs) Ping parameters" namespace.
</artwork> Perhaps:
</figure> IANA has allocated three new Target FEC stack sub-TLVs in the
</t> "Sub-TLVs for TLV Types 1, 16, and 21" registry
<t> [IANA-MPLS-LSP-PING-Parameters] within the "TLVs" registry of the
If a malformed FEC sub-TLV "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
is received, then a return code of Ping Parameters" registry group.
1, "Malformed echo request received" as defined in <xref target="RFC8029"/>
MUST be sent. The below section is appended to the procedure given in Secti
on 7.4
point 4a of <xref target="RFC8287"/>.
</t>
<section anchor="fec_validation" title="EPE-SID FEC validiation">
<t>
<t> Segment Routing IGP-Prefix, IGP-Adjacency SID and EPE-SID Validation Reference:
: [IANA-MPLS-LSP-PING-Parameters]
Receiving node term used in this section implies the node that receives IANA, "Sub-TLVs for TLV Types 1, 16, and 21",
OAM message <https://www.iana.org/assignments/mpls-lsp-ping-parameters>.
with the FEC stack TLV.</t>
<artwork>
Else, if the Label-stack-depth is 0 and the Target FEC Stack sub-TLV
at FEC-stack-depth is TBD1 (PeerAdj SID sub-TLV), {
Set the Best-return-code to 10, "Mapping for this FEC is not b) We have removed "Sub-TLV" from the entries in Tables 1 and 2 per
the given label at stack-depth if any below IANA's note. Please let us know if "Sub-TLV" should be
conditions fail: removed from any other instances in the running text for consistency.
We note the following variations:
- Validate that the receiving node's BGP Local AS matches PeerAdj SID
with the remote AS field in the received PeerAdj SID PeerAdj SID FEC
FEC sub-TLV. PeerAdj SID FEC sub-TLV
PeerAdj SID Sub-TLV
PeerAdj SID sub-TLV
- Validate that the receiving node's BGP Router-ID PeerSet SID sub-TLV
matches with the Remote Router ID field in the PeerNode SID sub-TLV
received PeerAdj SID FEC. -->
- Validate that there is a EBGP session with a peer <t>IANA has allocated three new Target FEC Stack sub-TLVs
having local AS number and BGP Router-ID as in the "Sub-TLVs for TLV Types 1, 16, and 21" registry <xref target="IANA-MP
specified in the Local AS number and Local Router-ID LS-LSP-PING-Parameters" format="default"/>
field in the received PeerAdj SID FEC sub-TLV. within the "TLVs" registry of the "Multiprotocol Label Switching (MPLS)
Label Switched Paths (LSPs) Ping Parameters" registry group. </t>
If the Remote interface address is not zero, validate the <table anchor="sub_tlv" align="center">
incoming interface. <name>Sub-TLVs for TLV Types 1, 16, and 21 Registry</name>
Set the Best-return-code to 35 "Mapping for this FEC is not <thead>
associated with the incoming interface" [RFC8287] if any below <tr>
conditions fail: <th>Sub-Type</th>
<th>Sub-TLV Name</th>
</tr>
</thead>
<tbody>
<tr>
<td>38</td>
<td>PeerAdj SID</td>
</tr>
<tr>
<td>39</td>
<td>PeerNode SID</td>
</tr>
<tr>
<td>40</td>
<td>PeerSet SID</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sec-con" numbered="true" toc="default">
<name>Security Considerations</name>
<t>The EPE-SIDs are advertised for egress links for EPE
purposes or for inter-AS links between cooperating ASes.
When cooperating domains are involved, they can allow the packets
arriving on trusted interfaces to reach the control plane
and be processed.</t>
<t> When EPE-SIDs are created for egress
TE links where the neighbor AS is an independent entity, it may
not allow the packets arriving from the external world to reach the
control plane. In such deployments, the MPLS OAM packets will be
dropped by the neighboring AS that receives the MPLS OAM packet.</t>
<t>In MPLS Traceroute applications, when the AS boundary is
crossed with the EPE-SIDs, the Target FEC Stack TLV is changed.
<xref target="RFC8287" format="default"/> does not mandate that the initi
ator,
upon receiving an MPLS Echo Reply message that includes the
Target FEC Stack Change TLV with one or more of the original
segments being popped, remove the corresponding FEC(s) from
the Target FEC Stack TLV in the next (TTL+1) traceroute
request. </t>
<t>If an initiator does not remove the FECs belonging
to the previous AS that has traversed, it may expose the
internal AS information to the following AS being traversed in
the traceroute.
</t>
</section>
- Validate the incoming interface on which the OAM </middle>
packet was receieved, matches with the remote <back>
interface specified in the PeerAdj SID FEC sub-TLV <displayreference target="I-D.ietf-idr-bgp-sr-segtypes-ext" to="BGP-SR-SEGTY
PES-EXT"/>
<displayreference target="I-D.ietf-idr-sr-policy-safi" to="SR-BGP-POLICY"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
287.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
029.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
086.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
690.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
793.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
087.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
705.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
403.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
664.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
065.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
286.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
256.xml"/>
If all above validations have passed, set the return code to 3 <reference anchor="IANA-MPLS-LSP-PING-Parameters" target="https://www.ian
"Replying router is an egress for the FEC at stack-depth" a.org/assignments/mpls-lsp-ping-parameters">
} <front>
<title>Sub-TLVs for TLV Types 1, 16, and 21</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
Else, if the Target FEC sub-TLV at FEC-stack-depth is TBD2 <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
(PeerNode SID sub-TLV), { etf-idr-bgp-sr-segtypes-ext.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.i
etf-idr-sr-policy-safi.xml"/>
Set the Best-return-code to 10, "Mapping for this FEC is not </references>
the given label at stack-depth if any below </references>
conditions fail: <section anchor="Appendix" numbered="true" toc="default">
<name>Examples of Programmed States</name>
<t> This section describes examples of both a correctly and an
incorrectly programmed state and provides details on how the new
sub-TLVs described in this document can be used to validate the
correctness. Consider the diagram from <xref target="reference_diagram"
format="default"/>.</t>
<t>Correctly programmed state:</t>
- Validate that the receiving node's BGP Local AS matches <ul spacing="normal">
with the remote AS field in the <li>
received PeerNode SID FEC sub-TLV. <t>C assigns label 16001 and binds it to adjacency C-&gt;E </t>
</li>
<li>
<t>C signals that label 16001 is bound to adjacency C-&gt;E (e.g., via
BGP-LS)</t>
</li>
<li>
<t>The controller/ingress programs an SR path that has SID/label 16001
to steer the packet on the exit point from C onto adjacency C-&gt;E</t
>
</li>
<li>
<t>Using MPLS Traceroute procedures defined in this document, the Peer
Adj
SID sub-TLV is populated with entities to be validated by C when the
OAM packet reaches it</t>
</li>
<li>
<t>C receives the OAM packet and validates that the top label
(16001) is indeed corresponding to the entities populated in the
PeerAdj SID sub-TLV</t>
</li>
</ul>
<t>Incorrectly programmed state:</t>
<ul spacing="normal">
<li>
<t>C assigns label 16001 and binds it to adjacency C-&gt;D</t>
</li>
<li>
<t>The controller learns that PeerAdj SID label 16001 is bound to
adjacency C-&gt;E (e.g., via BGP-LS) -- this could be a software bug
on C or on the controller</t>
</li>
<li>
<t>The controller/ingress programs an SR path that has SID/label
16001 to steer the packet on the exit point from C onto adjacency
C-&gt;E</t>
</li>
<li>
<t>Using MPLS Traceroute procedures defined in this document, the Peer
Adj
SID sub-TLV is populated with entities to be validated by C
(including a local/remote interface address of C-&gt;E) when the OAM
packet reaches it</t>
</li>
<li>
<t>C receives the OAM packet and validates that the top label
(16001) is NOT bound to C-&gt;E as populated in the PeerAdj SID
sub-TLV and then responds with the respective error code</t>
</li>
</ul>
</section>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
- Validate that the receiving node's BGP Router-ID matches <t>Thanks to <contact fullname="Loa Andersson"/>, <contact
with the Remote Router ID field in the received fullname="Dhruv Dhody"/>, <contact fullname="Ketan Talaulikar"/>,
PeerNode SID FEC. <contact fullname="Italo Busi"/>, <contact fullname="Alexander
Vainshtein"/>, and <contact fullname="Deepti Rathi"/> for careful reviews
and
comments. Thanks to <contact fullname="Tarek Saad"/> for providing the
example described in <xref target="Appendix"/>.</t>
</section>
- Validate that there is a EBGP session with a peer </back>
having local AS number and BGP Router-ID as
specified in the Local AS number and Local Router-ID
field in the received PeerNode SID FEC sub-TLV.
If all above validations have passed, set the return code to 3 <!-- [rfced] Terminology and Abbreviations
"Replying router is an egress for the FEC at stack-depth".
}
Else, if the Target FEC sub-TLV at FEC-stack-depth is TBD3
(PeerSet SID sub-TLV), {
Set the Best-return-code to 10, "Mapping for this FEC is not a) Throughout the text, the following terminology appears to be capitalized
the given label at stack-depth" if any below inconsistently. Please review these occurrences and let us know if/how they
conditions fail: may be made consistent.
- Validate that the Receiving Node BGP Local AS matches Adj-Type vs. Adj type
with one of the remote AS field in the received PeerSet Integer vs. integer
SID FEC sub-TLV. Local AS number vs. local AS number
Local interface vs. local interface
Link Descriptors vs. link descriptors
Remote interface vs. remote interface
- Validate that the Receiving Node BGP Router-ID matches b) How may we make these terms consistent? For the case, we suggest
with one of the Remote Router ID field in the received capitalizing "Target" and "Stack" to match use in RFC 8287 and
PeerSet SID FEC sub-TLV. other past RFCs.
- Validate that there is a EBGP session with a peer having Target FEC Stack TLV vs.
local AS number and BGP Router-ID as Target FEC stack TLV vs.
specified in the Local AS number and Local Router-ID target FEC stack TLV vs.
field in the received PeerSet SID FEC sub-TLV. target FEC stack
[Note: should the last instance contain "TLV"?]
If all above validations have passed, set the return code to 3 FEC stack TLV vs.
"Replying router is an egress for the FEC at stack-depth" FEC stack
} [Note: should "Target" be added to these instances? And
</artwork> should the last instance contain "TLV"?]
</t> Target FEC Stack sub-TLV vs.
</section> Target FEC stack sub-TLV vs.
Target FEC sub-TLV
[Note: should "Stack" be added to the last instance?]
</section> c) In the text, "Type 1" appears to have two different names. Are these meant
<section anchor="IANA" title="IANA Considerations"> to be the same or different? We see "Target FEC Stack TLV (Type 1)" in RFC 8287.
<t>IANA is requested to allocate three new Target FEC stack sub-TLVs Please let us know how/if we may update. Note that we recommend making "stack"
from the "Sub-TLVs for TLV types 1,16 and 21" subregistry in the uppercase for consistency.
"TLVs" registry of the "Multi-Protocol Label switching (MPLS)
Label Switched Paths (LSPs) Ping parameters" namespace.
<list> Abstract:
<t>PeerAdj SID Sub-TLV : TBD1</t> MPLS Target stack TLV (Type 1)
<t>PeerNode SID Sub-TLV: TBD2</t>
<t>PeerSet SID Sub-TLV : TBD3</t>
</list>
The three lowest free values from the Standard Tracks range should be
allocated if possible.
</t> Section 4:
Target FEC Stack TLV (Type 1)
</section> d) It appears that in past RFCs, the term "FEC stack-depth" is used instead of
<section title='Security Considerations' anchor='sec-con'> "FEC-stack-depth". Should we update to only one hyphen?
<t>The EPE-SIDs are advertised for egress links for Egress Peer Engineering
purposes or for inter-AS links between co-operating ASes.
When co-operating domains are involved, they can allow the packets
arriving on trusted interfaces to reach the control plane
and get processed.</t>
<t> When EPE-SIDs are created for egress
TE links where the neighbor AS is an independent entity, it may
not allow packets arriving from external world to reach the
control plane. In such deployments MPLS OAM packets will be
dropped by the neighboring AS that receives the MPLS OAM packet.</t>
<t>In MPLS traceroute applications, when the AS boundary is
crossed with the EPE-SIDs, the FEC stack is changed.
<xref target="RFC8287"/> does not mandate that the initiator
upon receiving an MPLS Echo Reply message that includes the
FEC Stack Change TLV with one or more of the original
segments being popped remove a corresponding FEC(s) from
the Target FEC Stack TLV in the next (TTL+1) traceroute
request. </t>
<t>If an initiator does not remove the FECs belonging
to the previous AS that has traversed, it may expose the
internal AS information to the following AS being traversed in
traceroute.
</t>
</section> e) We see "MPLS Ping and Traceroute procedures" and "ping or traceroute packets"
<section title='Implementation Status'> in the running text. Should 1 instance of "MPLS traceroute procedure" perhaps be
<t> This section is to be removed before publishing as an RFC. "MPLS Ping and Traceroute procedures" for consistency?
</t>
<t>
RFC-Editor: Please clean up the references cited by this section
before publication.
</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>
<section title='Juniper Networks'>
<t>Juniper networks reported a prototype implementation of this draft.</t> Original:
The data plane validation of the SID will be done during the
MPLS traceroute procedure.
</section> Perhaps:
</section> The data plane validation of the SID will be done during the
<section title='Acknowledgments'> MPLS Ping and Traceroute procedures.
<t>Thanks to Loa Andersson, Dhruv Dhody, Ketan Talaulikar,
Italo Busi and Alexander Vainshtein, Deepti Rathi for
careful review and comments. Thanks to Tarek Saad for providing the example
described in Appendix section. </t>
</section>
</middle> f) FYI - We added expansions for the following abbreviations in the text.
Please review for accuracy.
<back> ASN: Access Service Network
<references title='Normative References'> BGP-LS: Border Gateway Protocol - Link State
&RFC8287; EBGP: External BGP
&RFC8029; OAM: Operations, Administration, and Maintenance
&RFC9086; -->
&RFC2119;
&RFC8174;
&RFC8690;
&RFC6793;
</references>
<references title='Informative References'>
&RFC9087;
&RFC7705;
&RFC8403;
&RFC8664;
&RFC4271;
&RFC5065;
&RFC6286;
&RFC7942;
&RFC9256;
<?rfc include="reference.I-D.ietf-idr-segment-routing-te-policy"?>
</references> <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
<section title='APPENDIX' anchor='APPENDIX'> Note that our script did not flag any words in particular, but this should
<t> This section describes an example of correctly programmed state and incorr still be reviewed as a best practice.
ectly -->
programmed state and provides details on how the new sub-TLVs described in thi
s
document can be used to validate the correctness.
Consider the diagram from <xref target ='reference_diagram'/>,
<t>Correctly programed state:</t>
<list>
<t>• C assigns label 16001 and binds it to adjacency C->E </t>
<t>• C signals label 16001 is bound to adjacency C->E (e.g. via BGP-LS)</t>
<t>• Controller/Ingress programs an SR path that has SID/label 16001
to steer packet on the exit point from C onto adjacency C->E</t>
<t>• Using MPLS trace procedures defined in this document, the PeerAdj SID
Sub-TLV is populates with entities to be validated by C when OAM packet reaches
it.</t>
<t>• C receives the OAM packet, it validates the top label (16001)
is indeed corresponding to the entities populated in the PeerAdj SID Sub-TLV</t>
</list>
<t>Incorrectly programed state:</t>
<list>
<t>• C assigns label 16001 and binds it to adjacency C->D</t>
<t>• The controller learns of PeerAdj SID label 16001 is bound to
adjacency C->E (e.g. via BGP-LS) – this could be a software bug on C or on contr
oller</t>
<t>• Controller/Ingress programs an SR path that has SID/label
16001 to steer packet on the exit point from C onto adjacency C->E</t>
<t>• Using MPLS trace procedures defined in this document, the PeerAdj SID
Sub-TLV is populates with entities to be validated by C
(including local/remote interface address of C->E) when OAM packet reaches it.</
t>
<t>• C receives the OAM packet, it validates the top label (16001) is NOT boun
d
to C->E as populated in the PeerAdj SID Sub-TLV and can respond with the
respective error code</t>
</list>
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 81 change blocks. 
784 lines changed or deleted 831 lines changed or added

This html diff was produced by rfcdiff 1.48.