| Internet-Draft | Using RFC 6374 for SR-MPLS Networks | May 2021 |
| Gandhi, et al. | Expires 6 November 2021 | [Page] |
Segment Routing (SR) leverages the source routing paradigm. RFC 6374 specifies protocol mechanisms to enable the efficient and accurate measurement of packet loss, one-way and two-way delay, as well as related metrics such as delay variation in MPLS networks. This document utilizes these mechanisms for Performance Delay and Loss Measurements in SR networks with MPLS data plane (SR-MPLS), for both SR-MPLS links and end-to-end SR-MPLS paths including Policies. In addition, this document defines Return Path TLV and Block Number TLV extensions for RFC 6374.¶
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."¶
This Internet-Draft will expire on 6 November 2021.¶
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.¶
Segment Routing (SR) leverages the source routing paradigm and greatly simplifies network operations for Software Defined Networks (SDNs). SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. SR takes advantage of the Equal-Cost Multipaths (ECMPs) between source and transit nodes, between transit nodes and between transit and destination nodes. SR Policies as defined in [I-D.ietf-spring-segment-routing-policy] are used to steer traffic through a specific, user-defined paths using a stack of Segments. Built-in SR Performance Measurement (PM) is one of the essential requirements to provide Service Level Agreements (SLAs).¶
[RFC6374] specifies protocol mechanisms to enable the efficient and accurate measurement of performance metrics in MPLS networks using query and response messages. [RFC7876] specifies mechanisms for sending and processing out-of-band responses over an UDP return path when receiving RFC 6374 based query messages. These mechanisms are also well-suited in SR-MPLS networks.¶
This document utilizes the mechanisms defined in [RFC6374] for Performance Delay and Loss Measurements in SR-MPLS networks, for both SR-MPLS links and end-to-end SR-MPLS paths including Policies. In addition, this document defines Return Path TLV and Block Number TLV extensions for [RFC6374].¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
ACH: Associated Channel Header.¶
DM: Delay Measurement.¶
ECMP: Equal Cost Multi-Path.¶
G-ACh: Generic Associated Channel (G-ACh).¶
GAL: Generic Associated Channel (G-ACh) Label.¶
LM: Loss Measurement.¶
MPLS: Multiprotocol Label Switching.¶
NTP: Network Time Protocol.¶
PM: Performance Measurement.¶
PSID: Path Segment Identifier.¶
PTP: Precision Time Protocol.¶
SID: Segment ID.¶
SL: Segment List.¶
SR: Segment Routing.¶
SR-MPLS: Segment Routing with MPLS data plane.¶
TC: Traffic Class.¶
TE: Traffic Engineering.¶
URO: UDP Return Object.¶
In the reference topology shown in Figure 1, the querier node R1 initiates a query message and the responder node R3 sends a response message for the query message received. The response message is sent back to the querier node R1 in-band on the same path (same set of links and nodes) or a different path in the reverse direction.¶
SR is enabled with MPLS data plane on nodes R1 and R3. The nodes R1 and R3 may be directly connected via a link enabled with MPLS (Section 2.9.1 of [RFC6374]) or a Point-to-Point (P2P) SR-MPLS path [RFC8402]. The link may be a physical interface, virtual link, or Link Aggregation Group (LAG) [IEEE802.1AX], or Layer-2 LAG bundle member link. The SR-MPLS path may be an SR-MPLS Policy [I-D.ietf-spring-segment-routing-policy] on node R1 (called head-end) with destination to node R3 (called tail-end).¶
T1 T2
/ \
+-------+ Query +-------+
| | - - - - - - - - - ->| |
| R1 |=====================| R3 |
| |<- - - - - - - - - - | |
+-------+ Response +-------+
\ /
T4 T3
Querier Responder
For delay and loss measurement in SR-MPLS networks, the procedures defined in [RFC6374] are used in this document. Note that one-way, two-way and round-trip delay measurements are defined in Section 2.4 of [RFC6374] and are further described in this document for SR-MPLS networks. Similarly, packet loss measurements are defined in Section 2.2 of [RFC6374] and are further described in this document for SR-MPLS networks.¶
In SR-MPLS networks, the query and response messages defined in [RFC6374] are sent as following:¶
It may be desired in SR-MPLS networks that the same path (same set of links and nodes) between the querier and responder be used in both directions of the measurement. This is achieved by using the SR-MPLS Return Path TLV extension defined in this document.¶
The packet loss measurement using Alternate-Marking Method defined in [RFC8321] requires collecting Block Number of the traffic counters. This is achieved by using the Block Number TLV extension defined in this document.¶
The performance measurement procedure for SR-MPLS links can be used to compute extended Traffic Engineering (TE) metrics for delay and loss as described in this document. The metrics are advertised in the network using the routing protocol extensions defined in [RFC7471], [RFC8570], and [RFC8571].¶
The In-Situ Operations, Administration, and Maintenance (IOAM) mechanisms for SR-MPLS defined in [I-D.gandhi-mpls-ioam-sr] are used to record OAM information in the packets, and are outside the scope of this document.¶
As described in Section 2.9.1 of [RFC6374], the query and response messages flow over an MPLS Generic Associated Channel (G-ACh). These query and response messages contain G-ACh Label (GAL) (value 13, with S=1). The GAL is followed by an Associated Channel Header (ACH), where Channel Type identifies the measurement message type, and the message payload following the ACH as shown in Figure 2.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL (value 13) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A query message as shown in Figure 2 is sent over the SR-MPLS links for both delay and loss measurement using the procedures described in [RFC6374]. For SR-MPLS links, the TTL value is set to 1 in the SR-MPLS header.¶
A query message for an end-to-end SR-MPLS Policy, for both delay and loss measurement, contains SR-MPLS label stack [I-D.ietf-spring-segment-routing-policy], with the G-ACh Label (GAL) at the bottom of the stack (with S=1) as shown in Figure 3. For SR-MPLS Policies, the TTL value is set to 255 in the SR-MPLS header.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label(1) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label(n) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL (value 13) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SR-MPLS label stack can be empty (format as shown in Figure 2) to indicate Implicit NULL label case.¶
For SR-MPLS Policy performance measurement, in order to ensure that the query message is processed by the intended responder, Destination Address TLV (Type 129) [RFC6374] MAY be sent in the query message. The responder only returns Success in Control Code if it is the intended destination for the query. Otherwise, it MUST return 0x15: Error - Invalid Destination Node Identifier [RFC6374].¶
In one-way measurement mode defined in Section 2.4 of [RFC6374], the querier can receive "out-of-band" response messages with IP/UDP header by properly setting the UDP Return Object (URO) TLV in the query message. The URO TLV (Type=131) is defined in [RFC7876] and includes the UDP-Destination-Port and IP Address. When the querier sets an IP address and an UDP port in the URO TLV, the response is sent to that IP address as destination address and UDP port as destination port. In addition, the "control code" in the query message is set to "out-of-band response requested".¶
In one-way delay measurement mode, as per Reference Topology, the timestamps T1 and T2 are collected by the query and response messages. Both these timestamps are used to measure one-way delay as (T2 - T1).¶
In two-way measurement mode defined in Section 2.4 of [RFC6374], the response messages are sent back to the querier in-band on the same link or the same end-to-end SR-MPLS path (same set of links and nodes) in the reverse direction.¶
For SR-MPLS links, the response message (format as shown in Figure 2) is sent back on the same incoming link where the query message is received. In this case, the "control code" in the query message is set to "in-band response requested".¶
For end-to-end SR-MPLS paths, the responder needs to transmit the response message (example as shown in Figure 3) on a specific return SR-MPLS path [I-D.ietf-pce-sr-bidir-path]. The querier can request in the query message to the responder to send the response message back on a given return path using the SR-MPLS Segment List sub-TLV in the Return Path TLV defined in this document.¶
In two-way delay measurement mode, as per Reference Topology, all timestamps T1, T2, T3, and T4 are collected by the query and response messages. All four timestamps are used to measure two-way delay as ((T4 - T1) - (T3 - T2)).¶
The Loopback measurement mode defined in Section 2.8 of [RFC6374] can be used to measure round-trip delay for a bidirectional circular SR-MPLS path [I-D.ietf-pce-sr-bidir-path]. The query messages in this case also carry the return path label stack as part of the MPLS header. The GAL is carried at the bottom of the label stack (with S=1) (example as shown in Figure 3).¶
As the responder does not process the query messages and generate response messages, the Loopback Request object (Type 3) [RFC6374] is not required for an end-to-end SR-MPLS path.¶
In loopback delay measurement mode, as per Reference Topology, the timestamps T1 and T4 are collected by the query messages. Both these timestamps are used to measure round-trip delay as (T4 - T1).¶
As defined in [RFC6374], MPLS DM query and response messages use Associated Channel Header (ACH) (value 0x000C for delay measurement) [RFC6374], which identifies the message type, and the message payload following the ACH. For both SR-MPLS links and end-to-end SR-MPLS Policies, the same MPLS DM ACH value is used.¶
The DM message payload as defined in Section 3.2 of [RFC6374] is used for delay measurement, for both SR-MPLS links and end-to-end SR-MPLS Policies.¶
The Section 3.4 of [RFC6374] defines timestamp format that can be used for delay measurement. The IEEE 1588 Precision Time Protocol (PTP) timestamp format [IEEE1588] is used by default as described in Appendix A of [RFC6374]. The timestamping in hardware is recommended in SR-MPLS networks.¶
The LM protocol can perform two distinct kinds of loss measurement as described in Section 2.9.8 of [RFC6374].¶
As defined in [RFC6374], MPLS LM query and response messages use Associated Channel Header (ACH) (value 0x000A for direct loss measurement or value 0x000B for inferred loss measurement), which identifies the message type, and the message payload following the ACH. For both SR-MPLS links and end-to-end SR-MPLS Policies, the same MPLS LM ACH value is used.¶
The LM message payload as defined in Section 3.1 of [RFC6374] is used for loss measurement, for both SR-MPLS links and end-to-end SR-MPLS Policies.¶
As defined in [RFC6374], Combined DM+LM query and response messages use Associated Channel Header (ACH) (value 0x000D for direct loss and delay measurement or value 0x000E for inferred loss and delay measurement), which identifies the message type, and the message payload following the ACH. For both SR-MPLS links and end-to-end SR-MPLS Policies, the same MPLS DM+LM ACH value is used.¶
The message payload as defined in Section 3.3 of [RFC6374] is used for combined delay and loss measurement, for both SR-MPLS links and end-to-end SR-MPLS Policies.¶
The Path Segment Identifier (PSID) [I-D.ietf-spring-mpls-path-segment] carried in the received data packet for the traffic flow under measurement can be used for accounting received traffic on the on the egress node of the SR-MPLS Policy. In direct mode, the PSID in the received query message as shown in Figure 4 can be used to associate the receive traffic counter on the responder to detect the transmit packet loss for the end-to-end SR-MPLS Policy.¶
In inferred mode, the PSID in the received query message as shown in Figure 4 can be used to count the received query messages on the responder to detect the transmit packet loss for an end-to-end SR-MPLS Policy.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSID | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL (value 13) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Different values of PSID can be used to measure packet loss per SR-MPLS Policy, per Candidate Path or per Segment List of the SR Policy [I-D.ietf-spring-segment-routing-policy].¶
In two-way measurement mode, the responder needs to send the response message on a specific return path. The querier can request in the query message to the responder to send a response message back on a given return path (e.g. co-routed SR-MPLS path for two-way measurement). This way the responder avoids creating and maintaining extra dynamic SR states for the return paths.¶
In one-way measurement mode, the querier can send its reachability information to the responder using Return Path TLV.¶
[RFC6374] defines query and response messages those can include or more optional TLVs. New TLV Type (TBA2) is defined in this document for Return Path to carry return path information in query messages. The format of the Return Path TLV is shown in Figure 5:¶
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 = TBA2 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Return Path Sub-TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Return Path TLV is a Mandatory TLV Type. The querier MUST only insert one Return Path TLV in the query message. The responder that supports this TLV, MUST only process the first Return Path TLV and ignore the other Return Path TLVs if present. The responder also MUST NOT add Return Path TLV in the response message. The Reserved field MUST be set to 0 and MUST be ignored on the receive side.¶
The Return Path TLV contains a Sub-TLV to carry the return path. The format of the SR-MPLS Segment List Sub-TLV is shown in Figure 6. The SR-MPLS Segment List Sub-TLV contains SR-MPLS Label Stack. The Label entries in the Segment List MUST be in network order. The SR-MPLS Segment List Sub-TLV in the Return Path TLV is of the following Type:¶
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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label(1) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label(n) (bottom of stack) | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An SR-MPLS Segment List Sub-TLV may carry only Binding SID [I-D.ietf-pce-binding-label-sid] of the Return SR-MPLS Policy.¶
The Return Path TLV MUST carry only one Return Path Sub-TLV. The responder that supports this Sub-TLV, MUST only process the first Return Path Sub-TLV and ignore the other Return Path Sub-TLVs if present. The responder also MUST send response message back on the return path specified in the Return Path Sub-TLV. The Reserved field MUST be set to 0 and MUST be ignored on the receive side.¶
The direct mode loss measurement using Alternate-Marking Method defined in [RFC8321] requires collecting Block Number of the counters for the data traffic flow under measurement. To be able to correlate the transmit and receive traffic counters of the matching Block Number, the Block Number of the traffic counters is carried in the LM query and response messages.¶
[RFC6374] defines query and response messages those can include one or more optional TLVs. New TLV Type (value TBA1) is defined in this document to carry the Block Number (8-bit) of the traffic counters in the LM query and response messages. The format of the Block Number TLV is shown in Figure 7:¶
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 = TBA1 | Length | Reserved |R| Block Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Block Number TLV is a Mandatory TLV Type. The querier MUST only insert one Block Number TLV in the query message to identify the Block Number for the traffic counters in the forward direction. The responder that supports this TLV, MUST only inert one Block Number TLV in the response message to identify the Block Number for the traffic counters in the reverse direction. The responder also MUST return the first Block Number TLV from the query message and ignore the other Block Number TLVs if present. The R Flag MUST be clear in the query message and set in the response message. The Reserved field MUST be set to 0 and MUST be ignored on the receive side.¶
The Point-to-Multipoint (P2MP) SR-MPLS path that originates from a root node terminates on multiple destinations called leaf nodes (e.g. P2MP SR-MPLS Policy [I-D.ietf-pim-sr-p2mp-policy]).¶
The procedures for delay and loss measurement described in this document for end-to-end P2P SR-MPLS Policies are also equally applicable to the P2MP SR-MPLS Policies. The procedure for one-way measurement is defined as following:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tree-SID | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GAL (value 13) | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The considerations for two-way and loopback measurement modes for P2MP SR-MPLS Policy (e.g. for co-routed bidirectional SR-MPLS path) are outside the scope of this document.¶
An SR-MPLS Policy can have ECMPs between the source and transit nodes, between transit nodes and between transit and destination nodes. Usage of Anycast SID [RFC8402] by an SR-MPLS Policy can result in ECMP paths via transit nodes part of that Anycast group. The query and response messages need to be sent to traverse different ECMP paths to measure delay of each of the ECMP path of an SR-MPLS Policy.¶
Forwarding plane has various hashing functions available to forward packets on specific ECMP paths. For SR-MPLS Policy, sweeping of entropy label [RFC6790] values can be used in query and response messages to take advantage of the hashing function in forwarding plane to influence the ECMP path taken by them.¶
The considerations for loss measurement for different ECMP paths of an SR-MPLS Policy are outside the scope of this document.¶
The extended TE metrics for SR-MPLS link delay and loss can be computed using the performance measurement procedures described in this document to advertise in the routing domain as follows:¶
The procedures defined in this document are backwards compatible with the procedures defined in [RFC6374] at both querier and responder. If the responder does not support the new Mandatory TLV Types defined in this document, it MUST return Error 0x17: Unsupported Mandatory TLV Object as per [RFC6374].¶
This document describes the procedures for performance delay and loss measurement for SR-MPLS networks, for both SR-MPLS links and end-to-end SR-MPLS Policies using the mechanisms defined in [RFC6374] and [RFC7876]. This document does not introduce any additional security considerations other than those covered in [RFC6374], [RFC7471], [RFC8570], [RFC8571], and [RFC7876].¶
IANA is requested to allocate a value for the following Mandatory Block Number TLV Type for [RFC6374] to be carried in the query and response messages from the "MPLS Loss/Delay Measurement TLV Object" registry contained within the "Generic Associated Channel (G-ACh) Parameters" registry set:¶
IANA is also requested to allocate a value for the following Mandatory Return Path TLV Type for [RFC6374] to be carried in the query messages from the "MPLS Loss/Delay Measurement TLV Object" registry contained within the "Generic Associated Channel (G-ACh) Parameters" registry set:¶
IANA is requested to create the "Return Path Sub-TLV" sub-registry as part of the Return Path TLV registry. All code points in the range 1 through 127 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in the range 128 through 239 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC8126]. Remaining code points are allocated according to Table 1:¶
| Value | Description | Reference |
|---|---|---|
| 0 | Reserved | This document |
| 1 - 127 | Unassigned | This document |
| 128 - 239 | Unassigned | This document |
| 240 - 249 | Experimental | This document |
| 250 - 254 | Private Use | This document |
| 255 | Reserved | This document |
This document defines the following new values in the Return Path Sub-TLV sub-registry:¶
| Value | Description | Reference |
|---|---|---|
| 1 | SR-MPLS Segment List of the Return Path | This document |
The authors would like to thank Thierry Couture for the discussions on the use-cases for the performance measurement in segment routing networks. Authors would like to thank Patrick Khordoc for implementing the mechanisms defined in this document. The authors would like to thank Greg Mirsky for providing many useful comments and suggestions. The authors would also like to thank Stewart Bryant, Sam Aldrin, Tarek Saad, and Rajiv Asati for their review comments. Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for MPLS-RT expert review.¶
Sagar Soni Cisco Systems, Inc. Email: sagsoni@cisco.com Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com Pier Luigi Ventre CNIT Italy Email: pierluigi.ventre@cnit.it¶