Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer Engineering (EPE) Segment Identifiers (SIDs) with MPLS Data PlaneJuniper Networks Inc.Exora Business ParkBangaloreKarnataka560103Indiashraddha@juniper.netJuniper Networks Inc.msri@juniper.netIndividual Contributorkapil.it@gmail.comCienasamson.cse@gmail.comChina MobileBeijingChinaxuxiaohu_ietf@hotmail.com
RTG
mplsOAMEPEBGP-LSBGPSPRINGSDNSIDEgress Peer Engineering (EPE) is an application of Segment Routing
(SR) that solves the problem of egress peer selection. The SR-based
BGP-EPE solution allows a centralized controller, e.g., a
Software-Defined Network (SDN) controller, to program any egress peer.
The EPE solution requires the node or the SDN controller to program 1) the
PeerNode Segment Identifier (SID) describing a session between two
nodes, 2) the PeerAdj SID describing the link or links that are
used by the sessions between peer nodes, and 3) the PeerSet SID
describing any connected interface to any peer in the related group.
This document provides new sub-TLVs for EPE-SIDs that are used in
the Target FEC Stack TLV (Type 1) in MPLS Ping and Traceroute
procedures.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Theory of Operation
. Requirements Language
. FEC Definitions
. PeerNode SID Sub-TLV
. PeerAdj SID Sub-TLV
. PeerSet SID Sub-TLV
. EPE-SID FEC Validation
. EPE-SID FEC Validation Rules
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
. Examples of Programmed States
Acknowledgments
Authors' Addresses
Introduction Egress Peer Engineering (EPE), as defined in , is an effective mechanism that is used to select the egress peer
link based on different criteria. In this scenario, egress peers may
belong to a completely different ownership. The EPE-SIDs provide the
means to represent egress peer nodes, links, sets of links, and sets of
nodes. Many network deployments have built their networks consisting of
multiple Autonomous Systems (ASes) either for the ease of operations or as a
result of network mergers and acquisitions. The inter-AS links
connecting any two ASes could be traffic-engineered 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 easily detected by the network operator. EPE-SIDs may
also be used in an ingress Segment Routing (SR) policy to choose exit points where the remote AS has
a completely different ownership. This scenario is out of scope for this
document.
Reference Diagram
+---------+ +------+
| | | |
| H B------D G
| | +---/| AS2 |\ +------+
| |/ +------+ \ | |---L/8
A AS1 C---+ \| |
| |\\ \ +------+ /| AS4 |---M/8
| | \\ +-E |/ +------+
| X | \\ | K
| | +===F AS3 |
+---------+ +------+In , EPE-SIDs are
configured on AS1 towards AS2 and AS3 and advertised in the Border
Gateway Protocol - Link State (BGP-LS) . In certain cases, the EPE-SIDs advertised by the
control plane may not be in synchronization with the label programmed in
the data plane. For example, on C, a PeerAdj SID could be advertised to
indicate it is for the link C->D. Due to some software anomaly, the
actual data forwarding on this PeerAdj SID could be happening over the
C->E link. If E had relevant data paths for further forwarding the
packet, this kind of anomaly would go unnoticed by the network operator.
A detailed example of a correctly programmed state and an incorrectly
programmed state along with a description of how the incorrect state can
be detected is described in .
A Forwarding Equivalence Class (FEC) definition for the EPE-SIDs will
detail the control plane association of the SID. The
data plane validation of the SID will be done during the MPLS Traceroute
procedure. When there is a multi-hop External BGP (EBGP) session
between the ASBRs, a PeerNode SID is advertised, and the traffic
MAY be load-balanced between the interfaces connecting
the two nodes. In ,
C and F could have a PeerNode SID advertised. When the Operations,
Administration, and Maintenance (OAM) packet is received on F, it needs
to be validated that the packet came from one of the two interfaces
connected to C.
This document provides Target Forwarding Equivalence Class (FEC)
Stack TLV definitions for EPE-SIDs. This solution requires the
node constructing the Target FEC Stack TLV to determine the types of
SIDs along the path of the LSP. Other procedures for MPLS Ping and
Traceroute, as defined in and clarified in ,
are applicable for EPE-SIDs as well.Theory of Operation provides mechanisms to
advertise the EPE-SIDs in BGP-LS. These EPE-SIDs may be used to build SR
paths and may be communicated using extensions described in and or Path
Computation Element Protocol (PCEP) extensions as defined in . Data plane monitoring for such
paths that consist of EPE-SIDs will use extensions defined in this
document to build the Target FEC Stack TLV. The MPLS Ping and
Traceroute procedures MAY be initiated by the head-end of
the SR path or a centralized topology-aware data plane monitoring
system, as described in . The
extensions in , , and do not
define how to acquire and carry the details of the SID that can be used
to construct the FEC. Such extensions are out of scope for this
document. The node initiating the data plane monitoring may acquire the
details of EPE-SIDs through BGP-LS advertisements, as described in . There may be other possible
mechanisms that can be used to learn the definition of the SID from the
controller. Details of such mechanisms are out of scope for this
document.The EPE-SIDs are advertised for inter-AS links that run EBGP
sessions. does not define the
detailed procedures of how to operate EBGP sessions in a scenario with
unnumbered interfaces. Therefore, these scenarios are out of scope for
this document. Anycast and multicast addresses are not in the scope of
this document. During the AS migration scenario, procedures described in
may be in force. In these
scenarios, if the local and remote AS fields in the FEC (as described in
) carry the globally
configured AS Number and not the "local AS" (as defined in ), then the FEC validation procedures may
fail. As described in , this
document defines Target FEC Stack TLVs for EPE-SIDs that can be used in
detecting MPLS data plane failures . 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.Requirements LanguageThe key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are
to be interpreted as described in BCP 14, , when, and
only when, they appear in all capitals, as shown here. FEC Definitions In this document, 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); see .PeerNode SID Sub-TLVPeerNode SID Sub-TLV
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 = 39 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local BGP Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote BGP Router ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
2 octets
Value:
39
Length:
2 octets
Value:
16
Local AS Number:
4 octets. The unsigned integer
representing the AS number
of the AS to which the PeerNode SID advertising node belongs. If
Confederations 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.
Remote AS Number:
4 octets. The unsigned integer
representing the AS number
of the AS of the remote node for which the PeerNode SID is
advertised. If Confederations 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.
Local BGP Router ID:
4 octets. The unsigned integer
representing the BGP Identifier of the PeerNode SID advertising node
as defined in and .
Remote BGP Router ID:
4 octets. The unsigned integer
representing the BGP Identifier of the remote node as defined in
and .
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 , 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 MAY 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 ,
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.PeerAdj SID Sub-TLVPeerAdj SID Sub-TLV
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
2 octets
Value:
38
Length:
2 octets
Value:
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.
Adj type:
1 octet
Value:
Set to 1 when the Adjacency Segment is IPv4. Set to
2 when the Adjacency Segment is IPv6.
RESERVED:
3 octets. MUST be zero when
sending and ignored on receiving.
Local AS Number:
4 octets. The unsigned integer
representing the AS number
of the AS to which the PeerAdj SID advertising node belongs. If
Confederations 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.
Remote AS Number:
4 octets. The unsigned integer
representing the AS number of
the remote node's AS for which the PeerAdj SID is advertised. If
Confederations 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.
Local BGP Router ID:
4 octets. The unsigned integer
representing the BGP Identifier of the PeerAdj SID advertising node as
defined in and .
Remote BGP Router ID:
4 octets. The unsigned integer
representing the BGP Identifier of the remote node as defined in and .
Local Interface Address:
4 octets or 16 octets. In the case of
PeerAdj SID, the 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 document.
Remote Interface Address:
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.
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 . In this document, it is RECOMMENDED
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 SHOULD skip the
validation for the incoming interface if the address field contains
0.PeerSet SID Sub-TLVPeerSet SID Sub-TLV
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) |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
One element in set consists of the details below
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote BGP Router ID (4 octets) |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
Type:
2 octets
Value:
40
Length:
2 octets
Value:
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.
Local AS Number:
4 octets. The unsigned integer
representing the AS number
of the AS to which the PeerSet SID advertising node belongs. If
Confederations 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.
Local BGP Router ID:
4 octets. The unsigned integer
representing the BGP Identifier of the PeerSet SID advertising node, as
defined in and .
No. of elements in set:
2 octets. The number of remote
ASes over which the set SID performs load-balancing.
Reserved:
2 octets. MUST be zero when sent
and ignored when received.
Remote AS Number:
4 octets. The unsigned integer
representing the AS number
of the remote node's AS for which the PeerSet SID is
advertised. If Confederations 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.
Remote BGP Router ID:
4 octets. The unsigned integer
representing the BGP Identifier of the remote node as defined in and .
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 MUST be included in the
FEC.EPE-SID FEC ValidationWhen a remote ASBR of the EPE-SID advertisement receives the MPLS OAM
packet with the top FEC being the EPE-SID, it MUST
perform validity checks on the content of the EPE-SID FEC sub-TLV. The
basic length check should be performed on the received FEC.Length Validation
PeerAdj SID sub-TLV
-----------
If Adj type = 1, Length should be 28 octets
If Adj type = 2, Length should be 52 octets
PeerNode SID sub-TLV
-------------
Length = (20 + No. of IPv4 interface pairs * 8 +
No. of IPv6 interface pairs * 32) octets
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) octetsIf a malformed FEC sub-TLV is received, then a return code of 1,
"Malformed echo request received", as defined in MUST be sent. The section below is
appended to the procedure given in step 4a of .
EPE-SID FEC Validation RulesThis 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.
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), {
Set the Best-return-code to 10, "Mapping for this FEC is not
the given label at stack-depth <RSC>" [RFC8029]. Check if
any below conditions fail:
- Validate that the receiving node's BGP Local AS matches
with the remote AS field in the received PeerAdj SID
sub-TLV.
- Validate that the receiving node's BGP Router-ID
matches with the Remote Router ID field in the
received PeerAdj SID sub-TLV.
- 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
field in the received PeerAdj SID sub-TLV.
If the remote interface address is not zero, validate the
incoming interface. Set the Best-return-code to 35,
"Mapping for this FEC is not associated with the incoming
interface" [RFC8287]. Check if any below conditions fail:
- Validate that the incoming interface on which the
OAM packet was received matches with the remote
interface specified in the PeerAdj SID sub-TLV.
If all above validations have passed, set the return code to 3,
"Replying router is an egress for the FEC at stack-depth <RSC>"
[RFC8029].
}
Else, if the Target FEC Stack sub-TLV at FEC stack-depth is 39
(PeerNode SID sub-TLV), {
Set the Best-return-code to 10, "Mapping for this FEC is not
the given label at stack-depth <RSC>" [RFC8029]. Check if any
below conditions fail:
- Validate that the receiving node's BGP Local AS matches
with the remote AS field in the received PeerNode SID
FEC sub-TLV.
- Validate that the receiving node's BGP Router-ID matches
with the Remote Router ID field in the received
PeerNode SID FEC.
- 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
field in the received PeerNode SID FEC sub-TLV.
If all above validations have passed, set the return code to 3,
"Replying router is an egress for the FEC at stack-depth <RSC>"
[RFC8029].
}
Else, if the Target FEC Stack sub-TLV at FEC stack-depth is 40
(PeerSet SID sub-TLV), {
Set the Best-return-code to 10, "Mapping for this FEC is not
the given label at stack-depth <RSC>" [RFC8029]. Check if any
below conditions fail:
- Validate that the receiving node's BGP Local AS matches
with one of the remote AS fields in the received
PeerSet SID FEC sub-TLV.
- 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.
- 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.
If all above validations have passed, set the return code to 3,
"Replying router is an egress for the FEC at stack-depth <RSC>"
[RFC8029].
}IANA ConsiderationsIANA has allocated three new Target FEC Stack sub-TLVs
in the "Sub-TLVs for TLV Types 1, 16, and 21" registry
within the "TLVs" registry of the "Multiprotocol Label Switching (MPLS)
Label Switched Paths (LSPs) Ping Parameters" registry group.
Sub-TLVs for TLV Types 1, 16, and 21 Registry
Sub-Type
Sub-TLV Name
38
PeerAdj SID
39
PeerNode SID
40
PeerSet SID
Security ConsiderationsThe 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. 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.In MPLS Traceroute applications, when the AS boundary is
crossed with the EPE-SIDs, the Target FEC Stack TLV is changed.
does not mandate that the initiator,
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. 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.
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.BGP Support for Four-Octet Autonomous System (AS) Number SpaceThe Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK]Detecting Multiprotocol Label Switched (MPLS) Data-Plane FailuresThis document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data PlanesA Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header.The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture. This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane.Clarification of Segment ID Sub-TLV Length for RFC 8287RFC 8287 defines the extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with the MPLS data plane. RFC 8287 proposes three Target Forwarding Equivalence Class (FEC) Stack sub-TLVs. While RFC 8287 defines the format and procedure to handle those sub-TLVs, it does not sufficiently clarify how the length of the Segment ID sub-TLVs should be computed to be included in the Length field of the sub-TLVs. This ambiguity has resulted in interoperability issues.This document updates RFC 8287 by clarifying the length of each of the Segment ID sub-TLVs defined in RFC 8287.Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer EngineeringA node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or service based. SR segments allow steering a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain.This document describes an extension to Border Gateway Protocol - Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing.Informative ReferencesSub-TLVs for TLV Types 1, 16, and 21IANAA Border Gateway Protocol 4 (BGP-4)This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.This document obsoletes RFC 1771. [STANDARDS-TRACK]Autonomous System Confederations for BGPThe Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/Internet Protocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals.This document describes an extension to BGP that may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.This document obsoletes RFC 3065. [STANDARDS-TRACK]Autonomous-System-Wide Unique BGP Identifier for BGP-4To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet, unsigned, non-zero integer and relaxes the "uniqueness" requirement so that only Autonomous-System-wide (AS-wide) uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issues. This document updates RFC 4271. [STANDARDS-TRACK]Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH AttributeThis document discusses some existing commonly used BGP mechanisms for Autonomous System Number (ASN) migration that are not formally part of the BGP4 protocol specification. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work.A Scalable and Topology-Aware MPLS Data-Plane Monitoring SystemThis document describes features of an MPLS path monitoring system and related use cases. Segment-based routing enables a scalable and simple method to monitor data-plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and Label Switched Path (LSP) trace, in a very complementary way. MPLS topology awareness reduces management and control-plane involvement of Operations, Administration, and Maintenance (OAM) measurements while enabling new OAM features.Path Computation Element Communication Protocol (PCEP) Extensions for Segment RoutingSegment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.This document updates RFC 8408.Segment Routing Centralized BGP Egress Peer EngineeringSegment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows for the enforcement of a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain.The Segment Routing architecture can be directly applied to the MPLS data plane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols.This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based BGP-EPE solution allows a centralized (Software-Defined Networking, or SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain.Segment Routing Policy ArchitectureSegment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.Advertising Segment Routing Policies in BGPHuawei TechnologiesCisco SystemsCisco SystemsMicrosoftGoogle A Segment Routing (SR) Policy is an ordered list of segments (i.e.,
instructions) that represent a source-routed policy. An SR Policy
consists of one or more candidate paths, each consisting of one or
more segment lists. A headend may be provisioned with candidate
paths for an SR Policy via several different mechanisms, e.g., CLI,
NETCONF, PCEP, or BGP.
This document specifies how BGP may be used to distribute SR Policy
candidate paths. It introduces a BGP SAFI to advertise a candidate
path of a Segment Routing (SR) Policy and defines sub-TLVs for the
Tunnel Encapsulation Attribute for signaling information about these
candidate paths.
This documents updates RFC9012 with extensions to the Color Extended
Community to support additional steering modes over SR Policy.
Work in ProgressSegment Routing Segment Types Extensions for BGP SR PolicyCisco SystemsCisco SystemsHuawei TechnologiesMicrosoftGoogle This document specifies the signaling of additional Segment Routing
Segment Types for signaling of Segment Routing (SR) Policies in BGP
using SR Policy Subsequent Address Family Identifier.
Work in ProgressExamples of Programmed States 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 .Correctly programmed state:
C assigns label 16001 and binds it to adjacency C->E
C signals that label 16001 is bound to adjacency C->E (e.g., via BGP-LS)
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->E
Using MPLS Traceroute procedures defined in this document, the PeerAdj
SID sub-TLV is populated with entities to be validated by C when the
OAM packet reaches it
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
Incorrectly programmed state:
C assigns label 16001 and binds it to adjacency C->D
The controller learns that 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 the controller
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->E
Using MPLS Traceroute procedures defined in this document, the PeerAdj
SID sub-TLV is populated with entities to be validated by C
(including a local/remote interface address of C->E) when the OAM
packet reaches it
C receives the OAM packet and validates that the top label
(16001) is NOT bound to C->E as populated in the PeerAdj SID
sub-TLV and then responds with the respective error code
AcknowledgmentsThanks to , , ,
, , and for careful reviews and
comments. Thanks to for providing the
example described in .Authors' AddressesJuniper Networks Inc.Exora Business ParkBangaloreKarnataka560103Indiashraddha@juniper.netJuniper Networks Inc.msri@juniper.netIndividual Contributorkapil.it@gmail.comCienasamson.cse@gmail.comChina MobileBeijingChinaxuxiaohu_ietf@hotmail.com