Routing area S. Hegde
Internet-Draft K. Arora
Intended status: Standards Track M. Srivastava
Expires: October 18, 2021 Juniper Networks Inc.
S. Ninan
Individual Contributor
N. Kumar
Cisco Systems, Inc.
April 16, 2021
PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks
draft-ninan-mpls-spring-inter-domain-oam-02
Abstract
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 network may
consist of multiple IGP domains or multiple ASes under the control of
same organization. It is useful to have the LSP Ping and traceroute
procedures when an SR end-to-end path spans across multiple ASes or
domains. This document describes mechanisms to facilitae LSP ping
and traceroute in inter-AS/inter-domain SR networks in an efficient
manner with simple OAM protocol extension which uses dataplane
forwarding alone for sending Echo-Reply.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Hegde, et al. Expires October 18, 2021 [Page 1]
Internet-Draft Inter-as-OAM April 2021
This Internet-Draft will expire on October 18, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Inter domain networks with multiple IGPs . . . . . . . . . . 4
3. Return Path TLV . . . . . . . . . . . . . . . . . . . . . . . 5
4. Segment sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Type 1: SID only, in the form of MPLS Label . . . . . . . 5
4.2. Type 3: IPv4 Node Address with optional SID for SR-MPLS . 7
4.3. Type 4: IPv6 Node Address with optional SID for SR MPLS . 8
4.4. Segment Flags . . . . . . . . . . . . . . . . . . . . . . 9
5. SRv6 Dataplane . . . . . . . . . . . . . . . . . . . . . . . 10
6. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 10
6.1. Sending an Echo-Request . . . . . . . . . . . . . . . . . 10
6.2. Receiving an Echo-Request . . . . . . . . . . . . . . . . 10
6.3. Sending an Echo-Reply . . . . . . . . . . . . . . . . . . 10
7. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Procedures for Segment Routing LSP ping . . . . . . . . . 11
7.2. Procedures for Segment Routing LSP Traceroute . . . . . . 12
8. Building Reverse Path Segment List TLV dynamically . . . . . 12
8.1. The procedures to build the reverse path . . . . . . . . 13
8.2. Details with example . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Hegde, et al. Expires October 18, 2021 [Page 2]
Internet-Draft Inter-as-OAM April 2021
1. Introduction
+----------------+
| Controller/PMS |
+----------------+
|---------AS1----------| |--------AS2----------|
ASBR2-------ASBR3
/ \
/ \
PE1------P1------P2 P3------P4------PE4
\ /
\ /
ASBR1-------ASBR4
Figure 1: Inter-AS Segment Routing topology
Many network deployments have built their networks consisting of
multiple Autonomous Systems either for ease of operations or as a
result of network mergers and acquisitions. Segment Routing can be
deployed in such scenarios to provide end to end paths, traversing
multiple Autonomous systems(AS). These paths consist of Segment
Identifiers(SID) of different type as per [RFC8402].
[RFC8660] specifies the forwarding plane behaviour to allow Segment
Routing to operate on top of MPLS data plane.
[I-D.ietf-spring-segment-routing-central-epe] describes BGP peering
SIDs, which will help in steering packet from one Autonomous system
to another. Using above SR capabilities, paths which span across
multiple Autonomous systems can be created.
For example Figure 1 describes an inter-AS network scenario
consisting of ASes AS1 and AS2. Both AS1 and AS2 are Segment Routing
enabled and the EPE links have EPE labels configured and advertised
via [I-D.ietf-idr-bgpls-segment-routing-epe]. Controller or head-end
can build end-to-end Traffic-Engineered path consisting of Node-SIDs,
Adjacency-SIDs and EPE-SIDs. It is advantageous for operations to be
able to perform LSP ping and traceroute procedures on these inter-AS
SR paths. LSP ping/traceroute procedures use ip connectivity for
Echo-reply to reach the head-end. In inter-AS networks, ip
connectivity may not be there from each router in the path.For
example in Figure 1 P3 and P4 may not have ip connectivity for PE1.
Hegde, et al. Expires October 18, 2021 [Page 3]
Internet-Draft Inter-as-OAM April 2021
[RFC8403] describes mechanisms to carry out the MPLS ping/traceroute
from a PMS. It is possible to build GRE tunnels or static routes to
each router in the network to get IP connectivity for the reverse
path. This mechanism is operationally very heavy and requires PMS to
be capable of building huge number of GRE tunnels, which may not be
feasible.
It is not possible to carry out LSP ping and Traceroute functionality
on these paths to verify basic connectivity and fault isolation using
existing LSP ping and Traceroute mechanism([RFC8287] and [RFC8029]).
This is because, there exists no IP connectivity to source address of
ping packet, which is in a different AS, from the destination of
Ping/Traceroute.
[RFC7743] describes a Echo-relay based solution based on advertising
a new Relay Node Address Stack TLV containing stack of Echo-relay ip
addresses. That mechanism requires the return ping packet to reach
the control plane on every relay node.
This document describes a new mechanism which is efficient and simple
and can be easily deployed in SR networks. This mechanism uses
Return path TLV [RFC7110] to convey the reverse path. Three new sub-
TLVs for Return path TLV are defined, that faciliate encoding segment
routing label stack. The TLV can either be derived by a smart
application or controller which has a full topology view. This
document also proposes mechanisms to derive the Return path
dynamically during traceroute procedures.
2. Inter domain networks with multiple IGPs
|-Domain 1|-------Domain 2-----|--Domain 3-|
PE1------ABR1--------P--------ABR2------PE4
\ / \ /\ /
-------- ----------------- -------
BGP-LU BGP-LU BGP-LU
Figure 2: Inter-domain networks with multiple IGPs
When the network consists of large number of nodes, the nodes are
seggregated into multiple IGP domains. The connectivity to the
remote PEs can be achieved using BGP-LU [RFC3107] or by stacking the
labels for each domain as described in [RFC8604]. It is useful to
support mpls ping and traceroute mechanisms for these networks. The
Hegde, et al. Expires October 18, 2021 [Page 4]
Internet-Draft Inter-as-OAM April 2021
procedures described in this document for constructing Return path
TLV and its use in echo-reply is equally applicable to networks
consisting of multiple IGP domains that use BGP-LU or label stacking.
3. Return Path TLV
Segment Routing networks statically assign the labels to nodes and
PMS/Head-end may know the entire database. The reverse path can be
built from PMS/Head-end by stacking segments for the reverse path.
Return path TLV as defined in [RFC7110] is used to carry the return
path. While using the procedures described in this document, the
reply mode MUST be set to 5 and Return Path TLV MUST be included in
the Echo-Request message. The procedures decribed in [RFC7110] are
applicable for constructing the Return Path TLV. This document
define three new sub-TLVs to encode the Segment Routing path
The type of segment that the head-end chooses to send in the Return
Path TLV is governed by local policy.
Some networks may consist of pure IPV4 domains and Pure IPv6 domains.
Handling end-to-end MPLS OAM for such networks is out of scope for
this document. It is recommended to use dual stack in such cases and
use end-to-end IPv6 addresses for MPLS ping and trace route
procedures.
4. Segment sub-TLV
[I-D.ietf-spring-segment-routing-policy] defines various types of
segments. The segments applicable to this documents have been re-
defined here. One or more segment sub-TLV can be included in the
Return Path TLV. The segment sub-TLVs included in a Return Path TLV
MAY be of different types.
Below types of segment sub-TLVs are applicable for the Reverse Path
Segment List TLV.
Type 1: SID only, in the form of MPLS Label
Type 3: IPv4 Node Address with optional SID
Type 4: IPv6 Node Address with optional SID for SR MPLS
4.1. Type 1: SID only, in the form of MPLS Label
The Type-1 Segment Sub-TLV encodes a single SID in the form of an
MPLS label. The format is as follows:
Hegde, et al. Expires October 18, 2021 [Page 5]
Internet-Draft Inter-as-OAM April 2021
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Type 1 Segment sub-TLV
where:
Type: TBD1(to be assigned by IANA from the registry "Sub-TLV Target
FEC stack TLV").
Length is 8.
Flags: 1 octet of flags as defined in Section Section 4.4.
RESERVED: 3 octets of reserved bits. SHOULD be unset on transmission
and MUST be ignored on receipt.
Label: 20 bits of label value.
TC: 3 bits of traffic class
S: 1 bit of bottom-of-stack.
TTL: 1 octet of TTL.
The following applies to the Type-1 Segment sub-TLV:
The S bit SHOULD be zero upon transmission, and MUST be ignored upon
reception.
If the originator wants the receiver to choose the TC value, it sets
the TC field to zero.
If the originator wants the receiver to choose the TTL value, it sets
the TTL field to 255.
If the originator wants to recommend a value for these fields, it
puts those values in the TC and/or TTL fields.
Hegde, et al. Expires October 18, 2021 [Page 6]
Internet-Draft Inter-as-OAM April 2021
The receiver MAY override the originator's values for these fields.
This would be determined by local policy at the receiver. One
possible policy would be to override the fields only if the fields
have the default values specified above.
4.2. Type 3: IPv4 Node Address with optional SID for SR-MPLS
The Type-3 Segment Sub-TLV encodes an IPv4 node address, SR Algorithm
and an optional SID in the form of an MPLS label. The format is as
follows:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Type 3 Segment sub-TLV
where:
Type: TBD3(to be assigned by IANA from the registry "Sub-TLV Target
FEC stack TLV").
Length is 8 or 12.
Flags: 1 octet of flags as defined in Section Section 4.4.
SR Algorithm: 1 octet specifying SR Algorithm as described in section
3.1.1 in [RFC8402], when A-Flag as defined in Section Section 4.4is
present. SR Algorithm is used by the receiver to derive the Label.
When A-Flag is not encoded, this field SHOULD be unset on
transmission and MUST be ignored on receipt.
RESERVED: 2 octets of reserved bits. SHOULD be unset on transmission
and MUST be ignored on receipt.
IPv4 Node Address: a 4 octet IPv4 address representing a node.
SID: 4 octet MPLS label.
Hegde, et al. Expires October 18, 2021 [Page 7]
Internet-Draft Inter-as-OAM April 2021
The following applies to the Type-3 Segment sub-TLV:
The IPv4 Node Address MUST be present.
The SID is optional and specifies a 4 octet MPLS SID containing
label, TC, S and TTL as defined in Section Section 4.1.
If length is 8, then only the IPv4 Node Address is present.
If length is 12, then the IPv4 Node Address and the MPLS SID are
present.
4.3. Type 4: IPv6 Node Address with optional SID for SR MPLS
The Type-4 Segment Sub-TLV encodes an IPv6 node address, SR Algorithm
and an optional SID in the form of an MPLS label. The format is as
follows:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Type 4 Segment sub-TLV
where:
Type: TBD4(to be assigned by IANA from the registry "Sub-TLV Target
FEC stack TLV").
Length is 20 or 24.
Flags: 1 octet of flags as defined in Section Section 4.4.
SR Algorithm: 1 octet specifying SR Algorithm as described in section
3.1.1 in [RFC8402], when A-Flag as defined in Section Section 4.4 is
present. SR Algorithm is used by the receiver to derive the label.
When A-Flag is not encoded, this field SHOULD be unset on
transmission and MUST be ignored on receipt.
Hegde, et al. Expires October 18, 2021 [Page 8]
Internet-Draft Inter-as-OAM April 2021
RESERVED: 2 octets of reserved bits. SHOULD be unset on transmission
and MUST be ignored on receipt.
IPv6 Node Address: a 16 octet IPv6 address representing a node.
SID: 4 octet MPLS label.
The following applies to the Type-4 Segment sub-TLV:
The IPv6 Node Address MUST be present.
The SID is optional and specifies a 4 octet MPLS SID containing
label, TC, S and TTL as defined in Section Section 4.1 .
If length is 20, then only the IPv6 Node Address is present.
If length is 24, then the IPv6 Node Address and the MPLS SID are
present.
4.4. Segment Flags
The Segment Types described above MAY contain following flags in the
"Flags" field (codes to be assigned by IANA from the registry "Return
path sub-TLV Flags" )
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |A| |
+-+-+-+-+-+-+-+-+
Figure 6: Flags
where:
A-Flag: This flag indicates the presence of SR Algorithm id in the
"SR Algorithm" field applicable to various Segment Types.
Unused bits in the Flag octet SHOULD be set to zero upon transmission
and MUST be ignored upon receipt.
The following applies to the Segment Flags:
A-Flag is applicable to Segment Types 3, 4. If A-Flag appears with
any other Segment Type, it MUST be ignored.
Hegde, et al. Expires October 18, 2021 [Page 9]
Internet-Draft Inter-as-OAM April 2021
5. SRv6 Dataplane
SRv6 dataplane is not in the scope of this document and will be
addressed in a separate document.
6. Detailed Procedures
6.1. Sending an Echo-Request
In the inter-AS scenario when there is no reverse path connectivity,
LSP ping initiator MUST add a Return Path TLV in the Echo-request
message. The reverse Segment List MUST correspond to the return path
from the egress. The Return Path TLV must contain the Segment
Routing Path in the reverse direction encoded as an ordered list of
Segments. The first Segment MUST correspond to the top Segment in
MPLS header that the responder MUST use while sending the Echo-reply.
6.2. Receiving an Echo-Request
As described in [RFC7110], when Reply mode is set to 5 (Reply via
Specified Path), The Echo-Request MUST contain the Return path TLV.
Absence of Reply path TLV is treated as malformed Echo-Request.When a
Return Path TLV is received, and the responder that supports
processing it, it MUST use the Segments in Return Path TLV to build
the echo-reply. The responder MUST follow the normal FEC validation
procedures as described in [RFC8029] and [RFC8287] and this document
does not suggest any change to those procedures. When the Echo-reply
has to be sent out the Return Path TLV is used to construct the MPLS
packet to send out.
6.3. Sending an Echo-Reply
The Echo-Reply message is sent as MPLS packet with a MPLS label
stack. The Echo-Reply message MUST be constructed as described in
the [RFC8029]. An MPLS packet is constructed with Echo-reply in the
payload. The top label MUST be constructed from the first Segment
from the Return Path TLV. The remaining labels MUST follow the order
from the Return Path TLV. The responder MAY check the reachability
of the top label in its own LFIB before sending the Echo-Reply. In
certain scenarios the head-end may choose to send Type 2/Type 3
segments consisting of IPV4 address and SID. In such cases that node
sending the echo-reply MUST derive the MPLS labels from SIDs based on
SRGB and encode the echo-reply with MPLS labels.
The return code MUST be set as described in [RFC7110]. The Return
Path TLV MUST be included in Echo-Reply indicating the specified
return path that the echo reply message is required to follow.
Hegde, et al. Expires October 18, 2021 [Page 10]
Internet-Draft Inter-as-OAM April 2021
7. Detailed Example
An example topology is given in Figure 1 . This will be used in
below sections to explain LSP Ping and Traceroute procedures. The
PMS/Head-end has complete view of topology. PE1, P1, P2, ASBR1 and
ASBR2 are in AS1. Similarly ASBR3, ASBR4, P3, P4 and PE4 are in AS2.
AS1 and AS2 have Segment Routing enabled. IGPs like OSPF/ISIS are
used to flood SIDs in each Autonomous System. The ASBR1, ASBR2,
ASBR3, ASBR4 advertise BGP EPE SIDs for the inter-AS links. Topology
of AS1 and AS2 are advertised via BGP-LS to the controller/PMS or
Head-end node. The EPE-SIDs are also advertised via BGP-LS as
described in [I-D.ietf-idr-bgpls-segment-routing-epe]
The description in the document uses below notations for Segment
Identifiers(SIDs).
Node SIDs : N-PE1, N-P1, N-ASBR1 etc.
Adjacency SIDs : Adj-PE1-P1, Adj-P1-P2 etc.
EPE SIDS : EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2 etc.
Let us consider a traffic engineered path built from PE1 to PE4 with
Segment List stack as below. N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4
for following procedures. This stack may be programmed by
controller/PMS or Head-end router PE1 may have imported the whole
topology information from BGP-LS and computed the inter-AS path.
7.1. Procedures for Segment Routing LSP ping
To perform LSP ping procedure on an SR-Path from PE1 to PE4
consisting of label stacks [N-P1,N-ASBR1,EPE-ASBR1-ASBR4, N-PE4], The
remote end(PE4) needs IP connectivity to head end(PE1) for the
Segment Routing ping to succeed, because Echo-reply needs to travel
back to PE1 from PE4. But in typical deployment scenario there will
be no ip route from PE4 to PE1 as they belong to different ASes.
PE1 adds Return Path from PE4 to PE1 in the MPLS Echo-request using
multiple Segments in "Return Path TLV" as defined above. An example
return path Segment List for PE1 to PE4 for LSP ping is [N-ASBR4,
EPE-ASBR4-ASBR1, N-PE1]. An implementation may also build a Return
Path consisting of labels to reach its own AS. Once the label stack
is popped-off the Echo-reply message will be exposed.The further
packet forwarding will be based on ip lookup. An example Return Path
for this case could be [N-ASBR4, EPE-ASBR4-ASBR1].
Hegde, et al. Expires October 18, 2021 [Page 11]
Internet-Draft Inter-as-OAM April 2021
On receiving MPLS Echo-request PE4 first validates FEC in the Echo-
request. PE4 then builds label stack to send the response from PE4
to PE1 by copying the labels from "Return Path TLV". PE4 builds the
Echo-reply packet with the MPLS label stack constructed and imposes
MPLS headers on top of Echo-reply packet and sends out the packet
towards PE1. This Segment List stack can successfully steer reply
back to Head-end node(PE1).
7.2. Procedures for Segment Routing LSP Traceroute
As described in the procedures for LSP ping, the reverse Segment List
may be sent from head-end in which case the LSP Traceroute procedures
are similar to LSP ping. The head-end constructs the Return Path TLV
and the egress node uses the Return Path to construct the Echo-reply
packet header. Head-end/PMS is aware of the return path from every
node visited in the network and builds the Return Path segment list
for every visited node accordingly.
For Example:
For the same traffic engineered path PE1 to PE4 mentioned in above
sections, let us assume there is no reverse path available from the
nodes ASBR4 to PE1. During the Traceroute procedure, when PE1 has to
visit ASBR4, it builds return Path TLV and includes label to the
border-node which has the route to, PE1. In this example the Return
Path TLV will contain [EPE-ASBR4-ASBR1]. Further down the traceroute
procedure when P3 or P4 node is being visited, PE1 build the Return
Path TLV containing [N-ASBR4, EPE-ASBR4-ASBR1]. The Echo-reply will
be an MPLS packet with this label stack and will be forwarded to PE1.
8. Building Reverse Path Segment List TLV dynamically
In some cases, the head-end may not have complete visibility of
Inter-AS topology. In such cases, it can rely on downstream routers
to build the reverse path for mpls traceroute procedures. For this
purpose, new return code is defined which implies the Return Path TLV
in the Echo-reply corresponds to the return path to be used in next
Echo-Request.
Value Meaning
------ ----------------------
0x0006 Use Return Path TLV in Echo-Reply for next Echo-Request.
Figure 7: Return Code
Hegde, et al. Expires October 18, 2021 [Page 12]
Internet-Draft Inter-as-OAM April 2021
8.1. The procedures to build the reverse path
When an ASBR receives an echo-request from another AS, and ASBR is
configured to build the return path dynamically, ASBR MUST build a
Return Path TLV that should be used in next Echo-request and add it
in echo-reply. ASBR MUST locally decide the outgoing interface for
the echo-reply packet. Generally, remote ASBR will choose interface
on which the incoming OAM packet was receieved to send the echo-reply
out. Return Path TLV is built by adding two segment sub TLVs. The
top segment sub TLV consists of the ASBR's Node SID and second
segment consists of the EPE SID in the reverse direction to reach the
AS from which the OAM packet was received.The type of segment chosen
to build Return Path TLV is implementation dependent. In cases where
the AS is configured with different SRGBs, the Node SID of the ASBR
should be represented using type 3 segment so that all the nodes
inside the AS can correctly translate the Node-SID to a label.
Irrespective of which type of segment is included in the Return Path
TLV, the responder of echo-request always translates the Return Path
TLV to a label stack and builds MPLS header for the the echo-reply
packet. This procedure can be applied to an end-to-end path
consisting of multiple ASes. Each ASBR at the border adds its Node-
SID and EPE-SID on top of existing segments in the Return Path TLV.
8.2. Details with example
Let us consider a traffic engineered path built from PE1 to PE4 with
a label stack as below. N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4 for
the following procedures. This traceroute doesn't need any changes
to the Return Path TLV till it leaves AS1. The same Return Path TLV
that is received is included in the Echo-Reply. But this traceroute
requires changes to Return Path TLV once it starts probing AS2
routers. ASBR4 should form this Return Path TLV using its own Node
SID(N-ASBR4) and EPE SID (EPE-ASRB4-ASBR1) labels and set the return
code to 6. Then PE1 should use this Return Path TLV in subsequent
echo-requests. In this example, when the subsequent echo-request
reaches P3, it should use this Return Path TLV for sending the echo-
reply. The same Return Path TLV is enough for any router in AS2 to
send the reply. Because the first label(N-ASBR4) can direct echo-
reply to ASBR4 and second one (EPE-ASBR4-ASBR1) to direct echo-reply
to AS1. Once echo reply reaches AS1, normal IP forwarding helps it
to reach PE1 or the head-end.
9. Security Considerations
TBD
Hegde, et al. Expires October 18, 2021 [Page 13]
Internet-Draft Inter-as-OAM April 2021
10. IANA Considerations
Sub-TLVs for TLV Types 1, 16, and 21
SID only in the form of mpls label : TBD (Range 32768-65535)
IPv4 Node Address with optional SID for SR-MPLS : TBD (Range
32768-65535)
IPv6 Node Address with optional SID for SR-MPLS : TBD (Range
32768-65535)
11. Contributors
1.Carlos Pignataro
Cisco Systems, Inc.
cpignata@cisco.com
2. Zafar Ali
Cisco Systems, Inc.
zali@cisco.com
12. Acknowledgments
Thanks to Bruno Decreane for suggesting use of generic Segment sub-
TLV. Thanks to Adrian Farrel for careful review and comments.
Thanks to Mach Chen for suggesting to use Return Path TLV.
13. References
13.1. Normative References
[I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
Rosen, E., Jain, D., and S. Lin, "Advertising Segment
Routing Policies in BGP", draft-ietf-idr-segment-routing-
te-policy-11 (work in progress), November 2020.
[I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D.
Afanasiev, "Segment Routing Centralized BGP Egress Peer
Engineering", draft-ietf-spring-segment-routing-central-
epe-10 (work in progress), December 2017.
Hegde, et al. Expires October 18, 2021 [Page 14]
Internet-Draft Inter-as-OAM April 2021
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
"Return Path Specified Label Switched Path (LSP) Ping",
RFC 7110, DOI 10.17487/RFC7110, January 2014,
<https://www.rfc-editor.org/info/rfc7110>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
N., Kini, S., and M. Chen, "Label Switched Path (LSP)
Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
<https://www.rfc-editor.org/info/rfc8287>.
13.2. Informative References
[I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray,
S., and J. Dong, "BGP-LS extensions for Segment Routing
BGP Egress Peer Engineering", draft-ietf-idr-bgpls-
segment-routing-epe-19 (work in progress), May 2019.
[I-D.ietf-mpls-interas-lspping]
Nadeau, T. and G. Swallow, "Detecting MPLS Data Plane
Failures in Inter-AS and inter-provider Scenarios", draft-
ietf-mpls-interas-lspping-00 (work in progress), March
2007.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-09 (work in progress),
November 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
<https://www.rfc-editor.org/info/rfc3107>.
Hegde, et al. Expires October 18, 2021 [Page 15]
Internet-Draft Inter-as-OAM April 2021
[RFC7743] Luo, J., Ed., Jin, L., Ed., Nadeau, T., Ed., and G.
Swallow, Ed., "Relayed Echo Reply Mechanism for Label
Switched Path (LSP) Ping", RFC 7743, DOI 10.17487/RFC7743,
January 2016, <https://www.rfc-editor.org/info/rfc7743>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N.
Kumar, "A Scalable and Topology-Aware MPLS Data-Plane
Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July
2018, <https://www.rfc-editor.org/info/rfc8403>.
[RFC8604] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed.,
Henderickx, W., and D. Cooper, "Interconnecting Millions
of Endpoints with Segment Routing", RFC 8604,
DOI 10.17487/RFC8604, June 2019,
<https://www.rfc-editor.org/info/rfc8604>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
Authors' Addresses
Shraddha Hegde
Juniper Networks Inc.
Exora Business Park
Bangalore, KA 560103
India
Email: shraddha@juniper.net
Kapil Arora
Juniper Networks Inc.
Email: kapilaro@juniper.net
Mukul Srivastava
Juniper Networks Inc.
Email: msri@juniper.net
Hegde, et al. Expires October 18, 2021 [Page 16]
Internet-Draft Inter-as-OAM April 2021
Samson Ninan
Individual Contributor
Email: samson.cse@gmail.com
Nagendra Kumar
Cisco Systems, Inc.
Email: naikumar@cisco.com
Hegde, et al. Expires October 18, 2021 [Page 17]