draft-ietf-mpls-spring-lsp-ping-13.txt   rfc8287.txt 
Network Work group N. Kumar, Ed. Internet Engineering Task Force (IETF) N. Kumar, Ed.
Internet-Draft C. Pignataro, Ed. Request for Comments: 8287 C. Pignataro, Ed.
Intended status: Standards Track Cisco Category: Standards Track Cisco
Expires: April 20, 2018 G. Swallow ISSN: 2070-1721 G. Swallow
Southend Technical Center Southend Technical Center
N. Akiya N. Akiya
Big Switch Networks Big Switch Networks
S. Kini S. Kini
Individual Individual
M. Chen M. Chen
Huawei Huawei
October 17, 2017 December 2017
Label Switched Path (LSP) Ping/Traceroute for Segment Routing IGP Prefix Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR)
and Adjacency SIDs with MPLS Data-plane IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs)
draft-ietf-mpls-spring-lsp-ping-13 with MPLS Data Planes
Abstract Abstract
A Segment Routing architecture leverages source routing and tunneling A Segment Routing (SR) architecture leverages source routing and
paradigms and can be directly applied to use of a Multi Protocol tunneling paradigms and can be directly applied to the use of a
Label Switching (MPLS) data plane. A node steers a packet through a Multiprotocol Label Switching (MPLS) data plane. A node steers a
controlled set of instructions called segments, by prepending the packet through a controlled set of instructions called "segments" by
packet with a Segment Routing header. prepending the packet with an SR header.
The segment assignment and forwarding semantic nature of Segment The segment assignment and forwarding semantic nature of SR raises
Routing raises additional consideration for connectivity verification additional considerations for connectivity verification and fault
and fault isolation for an LSP within a Segment Routing architecture. isolation for a Label Switched Path (LSP) within an SR architecture.
This document illustrates the problem and defines extensions to This document illustrates the problem and defines extensions to
perform LSP Ping and Traceroute for Segment Routing IGP Prefix and perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and
Adjacency SIDs with an MPLS data plane. IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc8287.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Coexistence of SR-Capable and Non-SR-Capable Node 1.1. Coexistence of SR-Capable and Non-SR-Capable Node
Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 4 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Challenges with Existing mechanisms . . . . . . . . . . . . . 4 4. Challenges with Existing Mechanisms . . . . . . . . . . . . . 5
4.1. Path validation in Segment Routing networks . . . . . . . 4 4.1. Path Validation in Segment Routing Networks . . . . . . . 5
5. Segment ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 5 5. Segment ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 7
5.1. IPv4 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 6 5.1. IPv4 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 7
5.2. IPv6 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 7 5.2. IPv6 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 8
5.3. IGP-Adjacency Segment ID . . . . . . . . . . . . . . . . 8 5.3. IGP-Adjacency Segment ID . . . . . . . . . . . . . . . . 9
6. Extension to Downstream Detailed Mapping TLV . . . . . . . . 9 6. Extension to Downstream Detailed Mapping TLV . . . . . . . . 11
7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 10 7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 11
7.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 11 7.2. FEC Stack Change Sub-TLV . . . . . . . . . . . . . . . . 12
7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 11 7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 13
7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 11 7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 13
7.5. TTL Consideration for traceroute . . . . . . . . . . . . 17 7.5. TTL Consideration for Traceroute . . . . . . . . . . . . 19
8. Backward Compatibility with non Segment Routing devices . . . 17 8. Backward Compatibility with Non-SR Devices . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 18 9.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 20
9.2. Protocol in the Segment ID sub-TLV . . . . . . . . . . . 18 9.2. Protocol in the Segment ID Sub-TLV . . . . . . . . . . . 20
9.3. Adjacency Type in the IGP-Adjacency Segment ID . . . . . 19 9.3. Adjacency Type in the IGP-Adjacency Segment ID . . . . . 20
9.4. Protocol in Label Stack Sub-TLV of Downstream Detailed 9.4. Protocol in the Label Stack Sub-TLV of the Downstream
Mapping TLV . . . . . . . . . . . . . . . . . . . . . . . 19 Detailed Mapping TLV . . . . . . . . . . . . . . . . . . 21
9.5. Return Code . . . . . . . . . . . . . . . . . . . . . . . 19 9.5. Return Code . . . . . . . . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 20 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . 21 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
"Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures" "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures"
[RFC8029] defines a simple and efficient mechanism to detect data [RFC8029] defines a simple and efficient mechanism to detect data-
plane failures in Label Switched Paths (LSP) by specifying plane failures in Label Switched Paths (LSPs) by specifying
information to be carried in an MPLS "echo request" and "echo reply" information to be carried in an MPLS "echo request" and "echo reply"
for the purposes of fault detection and isolation. Mechanisms for for the purposes of fault detection and isolation. Mechanisms for
reliably sending the echo reply are defined. The functionality reliably sending the echo reply are defined. The functionality
defined in [RFC8029] is modeled after the ping/traceroute paradigm defined in [RFC8029] is modeled after the Ping/Traceroute paradigm
(ICMP echo request [RFC0792]) and is typically referred to as LSP (ICMP echo request [RFC792]) and is typically referred to as "LSP
ping and LSP traceroute. [RFC8029] supports hierarchical and Ping" and "LSP Traceroute". [RFC8029] supports hierarchical and
stitching LSPs. stitching LSPs.
[I-D.ietf-spring-segment-routing] introduces and describes a Segment [SR] introduces and describes an SR architecture that leverages the
Routing architecture that leverages the source routing and tunneling source routing and tunneling paradigms. A node steers a packet
paradigms. A node steers a packet through a controlled set of through a controlled set of instructions called "segments" by
instructions called segments, by prepending the packet with Segment prepending the packet with an SR header. A detailed definition of
Routing header. A detailed definition of the Segment Routing the SR architecture is available in [SR].
architecture is available in [I-D.ietf-spring-segment-routing].
As described in [I-D.ietf-spring-segment-routing] and As described in [SR] and [SR-MPLS], the SR architecture can be
[I-D.ietf-spring-segment-routing-mpls], the Segment Routing directly applied to an MPLS data plane, the SID will be 20 bits, and
architecture can be directly applied to an MPLS data plane, the the SR header is the label stack. Consequently, the mechanics of
Segment identifier (Segment ID) will be of 20-bits size and the data-plane validation of [RFC8029] can be directly applied to SR
Segment Routing header is the label stack. Consequently, the MPLS.
mechanics of data place validation of [RFC8029] can be directly
applied to SR MPLS.
Unlike LDP or RSVP which are the other well-known MPLS control plane Unlike LDP or RSVP, which are the other well-known MPLS control plane
protocols, the basis of segment ID assignment in Segment Routing protocols, the basis of Segment ID assignment in SR architecture is
architecture is not always on a hop-by-hop basis. Depending on the not always on a hop-by-hop basis. Depending on the type of Segment
type of segment ID, the assignment can be unique to the node or ID, the assignment can be unique to the node or within a domain.
within a domain.
This nature of Segment Routing raises additional considerations for This nature of SR raises additional considerations for validation of
validation of fault detection and isolation in a Segment Routing fault detection and isolation in an SR network. This document
network. This document illustrates the problem and describes a illustrates the problem and describes a mechanism to perform LSP Ping
mechanism to perform LSP Ping and Traceroute for Segment Routing IGP and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency SIDs
Prefix and Adjacency SIDs within an MPLS data plane. within an MPLS data plane.
1.1. Coexistence of SR-Capable and Non-SR-Capable Node Scenarios 1.1. Coexistence of SR-Capable and Non-SR-Capable Node Scenarios
[I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment [INTEROP] describes how SR operates in a network where SR-capable and
Routing operates in a network where SR-capable and non-SR-capable non-SR-capable nodes coexist. In such a network, one or more
nodes coexist. In such a network, one or more SR-based LSPs and non- SR-based LSPs and non-SR-based LSPs are stitched together to achieve
SR-based LSPs are stitched together to achieve an end-to-end LSP. an end-to-end LSP. This is similar to a network where LDP and RSVP
This is similar to a network where LDP and RSVP nodes coexist and the nodes coexist and the mechanism defined in Section 4.5.2 of [RFC8029]
mechanism defined in Section 4.5.2 of [RFC8029] is applicable for LSP is applicable for LSP Ping and Trace.
Ping and Trace.
Section 8 of this document explains one of the potential gaps that is Section 8 of this document explains one of the potential gaps that is
specific to SR-Capable and non-SR-capable node scenarios and explains specific to SR-Capable and non-SR-capable node scenarios and explains
how the existing mechanism defined in [RFC8029] handles it. how the existing mechanism defined in [RFC8029] handles it.
2. Requirements notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology 3. Terminology
This document uses the terminologies defined in This document uses the terminology defined in [SR] and [RFC8029];
[I-D.ietf-spring-segment-routing], [RFC8029], readers are expected to readers are expected to be familiar with those terms.
be familiar with it.
4. Challenges with Existing mechanisms 4. Challenges with Existing Mechanisms
The following example describes the challenges with using the current The following example describes the challenges with using the current
MPLS OAM mechanisms on a Segment Routing network. MPLS Operations, Administration, and Maintenance (OAM) mechanisms on
an SR network.
4.1. Path validation in Segment Routing networks 4.1. Path Validation in Segment Routing Networks
[RFC8029] defines the MPLS OAM mechanisms that help with fault [RFC8029] defines the MPLS OAM mechanisms that help with fault
detection and isolation for an MPLS data-plane path by the use of detection and isolation for an MPLS data-plane path by the use of
various Target FEC Stack Sub-TLVs that are carried in MPLS Echo various Target Forwarding Equivalence Class (FEC) Stack sub-TLVs that
Request packets and used by the responder for FEC validation. While are carried in MPLS echo request packets and used by the responder
it is obvious that new Sub-TLVs need to be assigned for Segment for FEC validation. While it is obvious that new sub-TLVs need to be
Routing, the unique nature of the Segment Routing architecture raises assigned for SR, the unique nature of the SR architecture raises the
the need for additional operational considerations for path need for additional operational considerations for path validation.
validation. This section discusses the challenges as below: This section discusses the challenges.
L1 L1
+--------+ +--------+
| L2 | | L2 |
R3-------R6 R3-------R6
/ \ / \
/ \ / \
R1----R2 R7----R8 R1----R2 R7----R8
\ / \ /
\ / \ /
R4-------R5 R4-------R5
Figure 1: Segment Routing network Figure 1: Segment Routing Network
The Node Segment IDs for R1, R2, R3, R4, R5, R6, R7 and R8 are 5001, The Node Segment IDs for R1, R2, R3, R4, R5, R6, R7, and R8 are 5001,
5002, 5003, 5004, 5005, 5006, 5007, 5008 respectively. 5002, 5003, 5004, 5005, 5006, 5007, and 5008, respectively.
9136 --> Adjacency Segment ID from R3 to R6 over link L1. 9136 --> Adjacency Segment ID from R3 to R6 over link L1.
9236 --> Adjacency Segment ID from R3 to R6 over link L2. 9236 --> Adjacency Segment ID from R3 to R6 over link L2.
9124 --> Adjacency segment ID from R2 to R4. 9124 --> Adjacency segment ID from R2 to R4.
9123 --> Adjacency Segment ID from R2 to R3. 9123 --> Adjacency Segment ID from R2 to R3.
The forwarding semantic of Adjacency Segment ID is to pop the Segment The forwarding semantic of the Adjacency Segment ID is to pop the
ID and send the packet to a specific neighbor over a specific link. Segment ID and send the packet to a specific neighbor over a specific
A malfunctioning node may forward packets using Adjacency Segment ID link. A malfunctioning node may forward packets using the Adjacency
to an incorrect neighbor or over an incorrect link. The exposed Segment ID to an incorrect neighbor or over an incorrect link. The
Segment ID (of an incorrectly forwarded Adjacency Segment ID) might exposed Segment ID (of an incorrectly forwarded Adjacency Segment ID)
still allow such packet to reach the intended destination, although might still allow such a packet to reach the intended destination,
the intended strict traversal has been broken. even though the intended strict traversal was broken.
Assume in above topology, R1 sends traffic with segment stack as In the topology above, assume that R1 sends traffic with a segment
{9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8. If stack as {9124, 5008} so that the path taken will be
the Adjacency Segment ID 9124 is misprogrammed in R2 to send the R1-R2-R4-R5-R7-R8. If the Adjacency Segment ID 9124 is misprogrammed
packet to R1 or R3, the packet may still be delivered to R8 (if the in R2 to send the packet to R1 or R3, the packet may still be
nodes are configured with same SRGB) but is not via the expected delivered to R8 (if the nodes are configured with the same SR Global
path. Block (SRGB)) [SR] but not via the expected path.
MPLS traceroute may help with detecting such a deviation in the above MPLS traceroute may help with detecting such a deviation in the
mentioned scenario. However, in a different example, it may not be above-mentioned scenario. However, in a different example, it may
helpful. For example if R3, due to misprogramming, forwards a packet not be helpful, for example, if R3 forwards a packet with Adjacency
with Adjacency Segment ID 9236 via link L1, while it is expected to Segment ID 9236 via link L1 (due to misprogramming) when it was
be forwarded over Link L2. expected to be forwarded over link L2.
5. Segment ID sub-TLV 5. Segment ID Sub-TLV
The format of the following Segment ID sub-TLVs follows the The format of the following Segment ID sub-TLVs follows the
philosophy of Target FEC Stack TLV carrying FECs corresponding to philosophy of the Target FEC Stack TLV carrying FECs corresponding to
each label in the label stack. When operated with the procedures each label in the label stack. When operated with the procedures
defined in [RFC8029], this allows LSP ping/traceroute operations to defined in [RFC8029], this allows LSP Ping/Traceroute operations to
function when Target FEC Stack TLV contains more FECs than received function when the Target FEC Stack TLV contains more FECs than
label stack at responder nodes. received label stacks at the responder nodes.
Three new sub-TLVs are defined for Target FEC Stack TLVs (Type 1), Three new sub-TLVs are defined for the Target FEC Stack TLV (Type 1),
Reverse-Path Target FEC Stack TLV (Type 16) and Reply Path TLV (Type the Reverse-Path Target FEC Stack TLV (Type 16), and the Reply Path
21). TLV (Type 21).
sub-Type Value Field Sub-Type Sub-TLV Name
-------- --------------- -------- ---------------
34 IPv4 IGP-Prefix Segment ID 34 IPv4 IGP-Prefix Segment ID
35 IPv6 IGP-Prefix Segment ID 35 IPv6 IGP-Prefix Segment ID
36 IGP-Adjacency Segment ID 36 IGP-Adjacency Segment ID
See Section 9.2 for the registry for the Protocol field specified See Section 9.2 for the registry for the Protocol field specified
wihtin these sub-TLVs. within these sub-TLVs.
5.1. IPv4 IGP-Prefix Segment ID 5.1. IPv4 IGP-Prefix Segment ID
The IPv4 IGP-Prefix Segment ID is defined in The IPv4 IGP-Prefix Segment ID is defined in [SR]. The format is as
[I-D.ietf-spring-segment-routing]. The format is as specified below: specified below:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Prefix | | IPv4 Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved | |Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Prefix IPv4 Prefix
This field carries the IPv4 prefix to which the Segment ID is This field carries the IPv4 Prefix to which the Segment ID is
assigned. In case of Anycast Segment ID, this field will carry assigned. In case of an Anycast Segment ID, this field will carry
IPv4 Anycast address. If the prefix is shorter than 32 bits, the IPv4 Anycast address. If the prefix is shorter than 32 bits,
trailing bits SHOULD be set to zero. trailing bits SHOULD be set to zero.
Prefix Length Prefix Length
The Prefix Length field is one octet, it gives the length of the The Prefix Length field is one octet. It gives the length of the
prefix in bits (values can be 1 - 32). prefix in bits (values can be 1-32).
Protocol Protocol
Set to 1, if the Responder MUST perform FEC validation using OSPF
as IGP protocol. Set to 2, if the Responder MUST perform Egress This field is set to 1, if the responder MUST perform FEC
FEC validation using ISIS as IGP protocol. Set to 0, if Responder validation using OSPF as the IGP protocol. Set to 2, if the
can use any IGP protocol for Egress FEC validation. responder MUST perform Egress FEC validation using the
Intermediate System to Intermediate System (IS-IS) as the IGP
protocol. Set to 0, if the responder can use any IGP protocol for
Egress FEC validation.
Reserved Reserved
MUST be set to 0 on send, and MUST be ignored on receipt. The Reserved field MUST be set to 0 when sent and MUST be ignored
on receipt.
5.2. IPv6 IGP-Prefix Segment ID 5.2. IPv6 IGP-Prefix Segment ID
The IPv6 IGP-Prefix Segment ID is defined in The IPv6 IGP-Prefix Segment ID is defined in [SR]. The format is as
[I-D.ietf-spring-segment-routing]. The format is as specified below: specified below:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Prefix | | IPv6 Prefix |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved | |Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Prefix IPv6 Prefix
This field carries the IPv6 prefix to which the Segment ID is This field carries the IPv6 prefix to which the Segment ID is
assigned. In case of Anycast Segment ID, this field will carry assigned. In case of an Anycast Segment ID, this field will carry
IPv4 Anycast address. If the prefix is shorter than 128 bits, the IPv4 Anycast address. If the prefix is shorter than 128 bits,
trailing bits SHOULD be set to zero. trailing bits SHOULD be set to zero.
Prefix Length Prefix Length
The Prefix Length field is one octet, it gives the length of the The Prefix Length field is one octet, it gives the length of the
prefix in bits (values can be 1 - 128). prefix in bits (values can be 1-128).
Protocol Protocol
Set to 1, if the Responder MUST perform FEC validation using OSPF Set to 1 if the responder MUST perform FEC validation using OSPF
as IGP protocol. Set to 2, if the Responder MUST perform Egress as the IGP protocol. Set to 2 if the responder MUST perform
FEC validation using ISIS as IGP protocol. Set to 0, if Responder Egress FEC validation using IS-IS as the IGP protocol. Set to 0
can use any IGP protocol for Egress FEC validation. if the responder can use any IGP protocol for Egress FEC
validation.
Reserved Reserved
MUST be set to 0 on send, and MUST be ignored on receipt.
MUST be set to 0 on send and MUST be ignored on receipt.
5.3. IGP-Adjacency Segment ID 5.3. IGP-Adjacency Segment ID
This Sub-TLV is applicable for any IGP-Adjacency defined in This sub-TLV is applicable for any IGP-Adjacency defined in [SR].
[I-D.ietf-spring-segment-routing]. The format is as specified below: The format is as specified below:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adj. Type | Protocol | Reserved | | Adj. Type | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| Local Interface ID (4 or 16 octets) | | Local Interface ID (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
skipping to change at page 8, line 31 skipping to change at page 9, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| Advertising Node Identifier (4 or 6 octets) | | Advertising Node Identifier (4 or 6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
| Receiving Node Identifier (4 or 6 octets) | | Receiving Node Identifier (4 or 6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adj. Type (Adjacency Type) Adj. Type (Adjacency Type)
Set to 1, when the Adjacency Segment is Parallel Adjacency as Set to 1 when the Adjacency Segment is a Parallel Adjacency as
defined in [I-D.ietf-spring-segment-routing]. Set to 4, when the defined in [SR]. Set to 4 when the Adjacency Segment is IPv4
Adjacency segment is IPv4 based and is not a parallel adjacency. based and is not a Parallel Adjacency. Set to 6 when the
Set to 6, when the Adjacency segment is IPv6 based and is not a Adjacency Segment is IPv6 based and is not a Parallel Adjacency.
parallel adjacency. Set to 0, when the Adjacency segment is over Set to 0 when the Adjacency Segment is over an unnumbered
unnumbered interface. interface.
Protocol Protocol
Set to 1, if the Responder MUST perform FEC validation using OSPF Set to 1 if the responder MUST perform FEC validation using OSPF
as IGP protocol. Set to 2, if the Responder MUST perform Egress as the IGP protocol. Set to 2 if the responder MUST perform
FEC validation using ISIS as IGP protocol. Set to 0, if Responder Egress FEC validation using IS-IS as the IGP protocol. Set to 0
can use any IGP protocol for Egress FEC validation. if the responder can use any IGP protocol for Egress FEC
validation.
Reserved Reserved
MUST be set to 0 on send, and MUST be ignored on receipt. MUST be set to 0 on send and MUST be ignored on receipt.
Local Interface ID Local Interface ID
An identifier that is assigned by the local LSR for a link to
which Adjacency Segment ID is bound. This field is set to a local An identifier that is assigned by the local Label Switching Router
link address (IPv4 or IPv6). For IPv4, this field is 4 octets; (LSR) for a link to which the Adjacency Segment ID is bound. This
for IPv6, this field is 16 octets. In case of unnumbered, this field is set to a local link address (IPv4 or IPv6). For IPv4,
field is 4 octets and includes a 32 bit link identifier as defined this field is 4 octets; for IPv6, this field is 16 octets. If
in [RFC4203], [RFC5307]. If the Adjacency Segment ID represents unnumbered, this field is 4 octets and includes a 32-bit link
parallel adjacencies ([I-D.ietf-spring-segment-routing]), this identifier as defined in [RFC4203] and [RFC5307]. If the
Adjacency Segment ID represents Parallel Adjacencies [SR], this
field is 4 octets and MUST be set to 4 octets of zeroes. field is 4 octets and MUST be set to 4 octets of zeroes.
Remote Interface ID Remote Interface ID
An identifier that is assigned by remote LSR for a link on which An identifier that is assigned by the remote LSR for a link on
Adjacency Segment ID is bound. This field is set to remote which the Adjacency Segment ID is bound. This field is set to the
(downstream neighbor) link address (IPv4 or IPv6). For IPv4, this remote (downstream neighbor) link address (IPv4 or IPv6). For
field is 4 octets; for IPv6, this field is 16 oct ets. In case of IPv4, this field is 4 octets; for IPv6, this field is 16 octets.
unnumbered, this field is 4 octets and includes a 32 bit link If unnumbered, this field is 4 octets and includes a 32-bit link
identifier as defined in [RFC4203], [RFC5307]. If the Adjacency identifier as defined in [RFC4203] and [RFC5307]. If the
Segment ID represents parallel adjacencies Adjacency Segment ID represents Parallel Adjacencies [SR], this
([I-D.ietf-spring-segment-routing]), this field is 4 octets and field is 4 octets and MUST be set to 4 octets of zeroes.
MUST be set to 4 octets of zeroes.
Advertising Node Identifier Advertising Node Identifier
It specifies the advertising node identifier. When Protocol is This specifies the Advertising Node Identifier. When the Protocol
set to 1, then this field is 4 octets and carries the 32-bit OSPF field is set to 1, then this field is 4 octets and carries the
Router ID; if Protocol is set to 2, then this field is 6 octets 32-bit OSPF Router ID. If the Protocol field is set to 2, then
and carries the 48-bit ISIS System ID; if Protocol is set to 0, this field is 6 octets and carries the 48-bit IS-IS System ID. If
then this field is 4 octets, and MUST be set to zero. the Protocol field is set to 0, then this field is 4 octets and
MUST be set to zero.
Receiving Node Identifier Receiving Node Identifier
It specifies the downstream node identifier. When Protocol is set This specifies the downstream node identifier. When the Protocol
to 1, then this field is 4 octets and carries the 32-bit OSPF field is set to 1, then this field is 4 octets and carries the
Router ID; if Protocol is set to 2, then this field is 6 octets 32-bit OSPF Router ID. If the Protocol field is set to 2, then
and carries the 48-bit ISIS System ID; if Protocol is set to 0, this field is 6 octets and carries the 48-bit IS-IS System ID. If
then this field is 4 octets, and MUST be set to zero. the Protocol field is set to 0, then this field is 4 octets and
MUST be set to zero.
6. Extension to Downstream Detailed Mapping TLV 6. Extension to Downstream Detailed Mapping TLV
In an echo reply, the Downstream Detailed Mapping TLV [RFC8029] is In an echo reply, the Downstream Detailed Mapping TLV [RFC8029] is
used to report for each interface over which a FEC could be used to report for each interface over which a FEC could be
forwarded. For a FEC, there are multiple protocols that may be used forwarded. For a FEC, there are multiple protocols that may be used
to distribute label mapping. The "Protocol" field of the Downstream to distribute label mapping. The Protocol field of the Downstream
Detailed Mapping TLV is used to return the protocol that is used to Detailed Mapping TLV is used to return the protocol that is used to
distribute the label carried in "Downstream Label" field. The distribute the label carried in the Downstream Label field. The
following protocols are defined in [RFC8029]: following protocols are defined in [RFC8029]:
Protocol # Signaling Protocol Protocol # Signaling Protocol
---------- ------------------ ---------- ------------------
0 Unknown 0 Unknown
1 Static 1 Static
2 BGP 2 BGP
3 LDP 3 LDP
4 RSVP-TE 4 RSVP-TE
With segment routing, OSPF or ISIS can be used for label With SR, OSPF or IS-IS can be used for label distribution. This
distribution, this document adds two new protocols as follows: document adds two new protocols as follows:
Protocol # Signaling Protocol Protocol # Signaling Protocol
---------- ------------------ ---------- ------------------
5 OSPF 5 OSPF
6 ISIS 6 IS-IS
See Section 9.4. See Section 9.4.
7. Procedures 7. Procedures
This section describes aspects of LSP Ping and traceroute operations This section describes aspects of LSP Ping and Traceroute operations
that require further considerations beyond [RFC8029]. that require further considerations beyond [RFC8029].
7.1. FECs in Target FEC Stack TLV 7.1. FECs in Target FEC Stack TLV
When LSP echo request packets are generated by an initiator, FECs When LSP echo request packets are generated by an initiator, FECs
carried in the Target FEC Stack TLV may need to differ to support a carried in the Target FEC Stack TLV may need to differ to support an
Segment Routing architecture. The following defines Target FEC Stack SR architecture. The following defines the Target FEC Stack TLV
TLV construction mechanics by an initiator for Segment Routing construction mechanics by an initiator for SR scenarios.
scenarios.
Ping Ping
Initiator MUST include FEC(s) corresponding to the destination The initiator MUST include FEC(s) corresponding to the
segment. destination segment.
Initiator MAY include FECs corresponding to some or all of The initiator MAY include FECs corresponding to some or all of
segments imposed in the label stack by the initiator to the segments imposed in the label stack by the initiator to
communicate the segments traversed. communicate the segments traversed.
Traceroute Traceroute
Initiator MUST initially include FECs corresponding to all of The initiator MUST initially include FECs corresponding to all
segments imposed in the label stack. segments imposed in the label stack.
When a received echo reply contains FEC Stack Change TLV with When a received echo reply contains the FEC Stack Change TLV
one or more of original segment(s) being popped, initiator MAY with one or more of the original segments being popped, the
remove corresponding FEC(s) from Target FEC Stack TLV in the initiator MAY remove a corresponding FEC(s) from the Target FEC
next (TTL+1) traceroute request as defined in Section 4.6 of Stack TLV in the next (TTL+1) traceroute request, as defined in
[RFC8029]. Section 4.6 of [RFC8029].
When a received echo reply does not contain FEC Stack Change When a received echo reply does not contain the FEC Stack
TLV, initiator MUST NOT attempt to remove FEC(s) from Target Change TLV, the initiator MUST NOT attempt to remove any FECs
FEC Stack TLV in the next (TTL+1) traceroute request. from the Target FEC Stack TLV in the next (TTL+1) traceroute
request.
As defined in [I-D.ietf-ospf-segment-routing-extensions] and As defined in [SR-OSPF] and [SR-IS-IS], the Prefix SID can be
[I-D.ietf-isis-segment-routing-extensions], Prefix SID can be advertised as an absolute value, an index, or as a range. In any of
advertised as absolute value, index or as range. In any of these these cases, the initiator MUST derive the Prefix mapped to the
cases, Initiator MUST derive the Prefix mapped to the Prefix SID and Prefix SID and use it in the IGP-Prefix Segment ID defined in
use it in IGP-Prefix Segment ID defined in Section 5.1 and 5.2. How Sections 5.1 and 5.2. How the responder uses the details in the
the Responder uses the details in the SR-FEC Sub-TLV to perform the SR-FEC sub-TLV to perform the validation is a local implementation
validation is a local implementation matter. matter.
7.2. FEC Stack Change sub-TLV 7.2. FEC Stack Change Sub-TLV
[RFC8029] defines a FEC Stack Change sub-TLV that a router must [RFC8029] defines a FEC Stack Change sub-TLV that a router must
include when the FEC stack changes. include when the FEC stack changes.
The network node which advertised the Node Segment ID is responsible The network node that advertised the Node Segment ID is responsible
for generating a FEC Stack Change sub-TLV with pop operation type for for generating a FEC Stack Change sub-TLV with the Post Office
Node Segment ID, regardless of whether penultimate hop popping (PHP) Protocol (POP) operation type for the Node Segment ID, regardless of
is enabled or not. whether or not Penultimate Hop Popping (PHP) is enabled.
The network node that is immediate downstream of the node which The network node that is immediately downstream of the node that
advertised the Adjacency Segment ID is responsible for generating FEC advertised the Adjacency Segment ID is responsible for generating the
Stack Change sub-TLV for "POP" operation for Adjacency Segment ID. FEC Stack Change sub-TLV for POP operation for the Adjacency Segment
ID.
7.3. Segment ID POP Operation 7.3. Segment ID POP Operation
The forwarding semantic of Node Segment ID with PHP flag is The forwarding semantic of the Node Segment ID with the PHP flag is
equivalent to usage of implicit Null in MPLS protocols. Adjacency equivalent to usage of Implicit Null in MPLS protocols. The
Segment ID is also similar in a sense that it can be thought of as Adjacency Segment ID is also similar in a sense that it can be
locally allocated segment that has PHP enabled destined for next hop thought of as a locally allocated segment that has PHP enabled when
IGP adjacency node. Procedures described in Section 4.4 of [RFC8029] destined for the next-hop IGP Adjacency Node. Procedures described
relies on Stack-D and Stack-R explicitly having Implicit Null value. in Section 4.4 of [RFC8029] rely on the Stack-D and Stack-R
Implementations SHOULD use Implicit Null for Node Segment ID PHP and explicitly having the Implicit Null value. Implementations SHOULD
Adjacency Segment ID PHP cases. use the Implicit Null for the Node Segment ID PHP and Adjacency
Segment ID PHP cases.
7.4. Segment ID Check 7.4. Segment ID Check
This section modifies the procedure defined in Section 4.4.1 of This section modifies the procedure defined in Section 4.4.1 of
[RFC8029]. Step 4 defined in Section 4.4.1 of [RFC8029] is updated [RFC8029]. Step 4 defined in Section 4.4.1 of [RFC8029] is modified
as below: as below:
4. If the label mapping for FEC is Implicit Null, set FEC-status 4. If the label mapping for FEC is Implicit Null, set the
to 2 and proceed to step 4a. Otherwise, if the label mapping FEC-status to 2 and proceed to step 4a. Otherwise,
for FEC is Label-L, proceed to step 4a. Otherwise, set if the label mapping for FEC is Label-L, proceed to step 4a.
FEC-return-code to 10 ("Mapping for this FEC is not the given Otherwise, set the FEC-return-code to 10 ("Mapping for this
label at stack-depth"), set FEC-status to 1, and return. FEC is not the given label at stack-depth"), set the
FEC-status to 1, and return.
4a. Segment Routing IGP Prefix and Adjacency SID Validation: 4a. Segment Routing IGP-Prefix and IGP-Adjacency SID Validation:
If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV
FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), { at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment ID), {
Set Best return code to 10, "Mapping for this FEC is not the Set the Best-return-code to 10, "Mapping for this FEC is not
given label at stack-depth <RSC>" if any below conditions the given label at stack-depth <RSC>" if any below
fail: conditions fail:
/* The responder LSR is to check if it is the egress of the /* The responder LSR is to check if it is the egress of the
IPv4 IGP-Prefix Segment ID described in the Target FEC Stack IPv4 IGP-Prefix Segment ID described in the Target FEC Stack
Sub-TLV, and if the FEC was advertised with the PHP bit sub-TLV, and if the FEC was advertised with the PHP bit
set.*/ set.*/
- Validate that Node Segment ID is advertised for IPv4 - Validate that the Node Segment ID is advertised for the
Prefix by IGP Protocol { IPv4 Prefix by IGP Protocol {
o When protocol field in received IPv4 IGP-Prefix o When the Protocol field in the received IPv4 IGP-
Segment ID Sub-TLV is 0, Use any locally enabled IGP Prefix Segment ID sub-TLV is 0, use any locally
protocol. enabled IGP protocol.
o When protocol field in received IPv4 IGP-Prefix o When the Protocol field in the received IPv4 IGP-
Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. Prefix Segment ID sub-TLV is 1, use OSPF as the IGP
protocol.
o When protocol field in received IPv4 IGP-Prefix o When the Protocol field in the received IPv4 IGP-
Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. Prefix Segment ID sub-TLV is 2, use IS-IS as the IGP
protocol.
o When protocol field in received IPv4 IGP-Prefix o When the Protocol field in the received IPv4 IGP-
Segment ID Sub-TLV is an unrecognized value, it MUST Prefix Segment ID sub-TLV is an unrecognized value, it
be treated as Protocol value of 0. MUST be treated as a Protocol value of 0.
} }
- Validate that Node Segment ID is advertised with No-PHP - Validate that the Node Segment ID is advertised with the
flag { No-PHP flag. {
o When Protocol is OSPF, NP-flag defined in Section 5 of o When the Protocol is OSPF, the NP-Flag defined in
[I-D.ietf-ospf-segment-routing-extensions] MUST be set Section 5 of [SR-OSPF] MUST be set to 0.
to 0.
o When Protocol is ISIS, P-Flag defined in Section 2.1 o When the Protocol is IS-IS, the P-Flag defined in
of [I-D.ietf-isis-segment-routing-extensions] MUST be Section 6.1 of [SR-IS-IS] MUST be set to 0.
set to 0.
} }
If it can be determined that no protocol associated with If it can be determined that no protocol associated with the
Interface-I would have advertised FEC-Type at FEC-stack- Interface-I would have advertised the FEC-Type at FEC-stack-
depth, Set Best return code to 12, "Protocol not associated depth, set the Best-return-code to 12, "Protocol not
with interface at FEC stack-depth" and return. associated with interface at FEC-stack-depth" and return.
set FEC-Status to 1, and return. Set FEC-Status to 1 and return.
} }
Else if the Label-stack-depth is greater than 0 and Target FEC Else, if the Label-stack-depth is greater than 0 and the Target
Stack Sub-TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix Segment FEC Stack sub-TLV at FEC-stack-depth is 34 (IPv4 IGP-Prefix
ID), { Segment ID), {
Set Best return code to 10 if any below conditions fail: Set the Best-return-code to 10 if any below conditions fail:
- Validate that Node Segment ID is advertised for IPv4 - Validate that the Node Segment ID is advertised for the
Prefix by IGP Protocol { IPv4 Prefix by the IGP protocol {
o When protocol field in received IPv4 IGP-Prefix o When the Protocol field in the received IPv4 IGP-
Segment ID Sub-TLV is 0, Use any locally enabled IGP Prefix Segment ID sub-TLV is 0, use any locally
protocol. enabled IGP protocol.
o When protocol field in received IPv4 IGP-Prefix o When the Protocol field in the received IPv4 IGP-
Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. Prefix Segment ID sub-TLV is 1, use OSPF as the IGP
protocol.
o When protocol field in received IPv4 IGP-Prefix o When the Protocol field in the received IPv4 IGP-
Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. Prefix Segment ID sub-TLV is 2, use IS-IS as the IGP
protocol.
o When protocol field in received IPv4 IGP-Prefix o When the Protocol field in the received IPv4 IGP-
Segment ID Sub-TLV is an unrecognized value, it MUST Prefix Segment ID sub-TLV is an unrecognized value, it
be treated as Protocol value of 0. MUST be treated as a Protocol value of 0.
} }
If it can be determined that no protocol associated with If it can be determined that no protocol associated with
Interface-I would have advertised FEC-Type at FEC-stack- Interface-I would have advertised the FEC-Type at FEC-stack-
depth, Set Best return code to 12, "Protocol not associated depth, set the Best-return-code to 12, "Protocol not
with interface at FEC stack-depth" and return. associated with interface at FEC stack-depth" and return.
set FEC-Status to 1, and return. Set FEC-Status to 1 and return.
} }
Else if the Label-stack-depth is 0 and Target FEC Sub-TLV at Else, if the Label-stack-depth is 0 and the Target FEC sub-TLV
FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), { at FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), {
Set Best return code to 10 if any of the below conditions Set the Best-return-code to 10 if any of the below
fail: conditions fail:
/* The LSR needs to check if its being a tail-end for the /* The LSR needs to check if it is being a tail-end for the
LSP and have the prefix advertised with PHP bit set*/ LSP and have the prefix advertised with the PHP bit set*/
- Validate that Node Segment ID is advertised for IPv6 - Validate that the Node Segment ID is advertised for the
Prefix by IGP Protocol { IPv6 Prefix by the IGP protocol {
o When protocol field in received IPv6 IGP-Prefix o When the Protocol field in the received IPv6 IGP-
Segment ID Sub-TLV is 0, Use any locally enabled IGP Prefix Segment ID sub-TLV is 0, use any locally
protocol. enabled IGP protocol.
o When protocol field in received IPv6 IGP-Prefix o When the Protocol field in the received IPv6 IGP-
Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. Prefix Segment ID sub-TLV is 1, use OSPF as the IGP
protocol.
o When protocol field in received IPv6 IGP-Prefix o When the Protocol field in the received IPv6 IGP-
Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. Prefix Segment ID sub-TLV is 2, use IS-IS as the IGP
protocol.
o When protocol field in received IPv6 IGP-Prefix o When the Protocol field in the received IPv6 IGP-
Segment ID Sub-TLV is an unrecognized value, it MUST Prefix Segment ID sub-TLV is an unrecognized value, it
be treated as Protocol value of 0. MUST be treated as a Protocol value of 0.
} }
- Validate that Node Segment ID is advertised with No-PHP - Validate that the Node Segment ID is advertised with the
flag. { No-PHP flag. {
o When Protocol is OSPF, NP-flag defined in Section 5 of o When the Protocol is OSPF, the NP-flag defined in
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] MUST Section 5 of [SR-OSPFV3] MUST be set to 0.
be set to 0.
o When Protocol is ISIS, P-Flag defined in Section 2.1 o When the Protocol is IS-IS, the P-Flag defined in
of [I-D.ietf-isis-segment-routing-extensions] MUST be Section 6.1 of [SR-IS-IS] MUST be set to 0.
set to 0.
} }
If it can be determined that no protocol associated with If it can be determined that no protocol associated with
Interface-I would have advertised FEC-Type at FEC-stack- Interface-I would have advertised the FEC-Type at FEC-stack-
depth, Set Best return code to 12, "Protocol not associated depth, set the Best-return-code to 12, "Protocol not
with interface at FEC stack-depth" and return. associated with interface at FEC stack-depth" and return.
set FEC-Status to 1, and return. Set the FEC-Status to 1 and return.
} }
Else if the Label-stack-depth is greater than 0 and Target FEC Else, if the Label-stack-depth is greater than 0 and the Target
Sub-TLV at FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), FEC sub-TLV at FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment
{ ID), {
set Best return code to 10 if any below conditions fail: Set the Best-return-code to 10 if any below conditions fail:
- Validate that Node Segment ID is advertised for IPv4 - Validate that the Node Segment ID is advertised for the
Prefix by IGP Protocol { IPv4 Prefix by the IGP protocol {
o When protocol field in received IPv6 IGP-Prefix o When the Protocol field in the received IPv6 IGP-
Segment ID Sub-TLV is 0, Use any locally enabled IGP Prefix Segment ID sub-TLV is 0, use any locally
protocol. enabled IGP protocol.
o When protocol field in received IPv6 IGP-Prefix o When the Protocol field in the received IPv6 IGP-
Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. Prefix Segment ID sub-TLV is 1, use OSPF as the IGP
protocol.
o When protocol field in received IPv6 IGP-Prefix o When the Protocol field in the received IPv6 IGP-
Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. Prefix Segment ID sub-TLV is 2, use IS-IS as the IGP
protocol.
o When protocol field in received IPv6 IGP-Prefix o When the Protocol field in the received IPv6 IGP-
Segment ID Sub-TLV is an unrecognized value, it MUST Prefix Segment ID sub-TLV is an unrecognized value, it
be treated as Protocol value of 0. MUST be treated as a Protocol value of 0.
} }
If it can be determined that no protocol associated with If it can be determined that no protocol associated with
Interface-I would have advertised FEC-Type at FEC-stack- Interface-I would have advertised the FEC-Type at FEC-stack-
depth, Set Best return code to 12, "Protocol not associated depth, set the Best-return-code to 12, "Protocol not
with interface at FEC stack-depth" and return. associated with interface at FEC stack-depth" and return.
set FEC-Status to 1, and return. Set the FEC-Status to 1 and return.
} }
Else if the Target FEC sub-TLV at FEC-stack-depth is 36 (IGP- Else, if the Target FEC sub-TLV at FEC-stack-depth is 36
Adjacency Segment ID), { (IGP-Adjacency Segment ID), {
set Best return code to TBD1 (Section 10.3) if any below Set the Best-return-code to 35 (Section 9.5) if any below
conditions fail: conditions fail:
When the Adj. Type is 1 (Parallel Adjacency): When the Adj. Type is 1 (Parallel Adjacency):
o Validate that Receiving Node Identifier is local IGP o Validate that the Receiving Node Identifier is the
identifier. local IGP identifier.
o Validate that IGP-Adjacency Segment ID is advertised o Validate that the IGP-Adjacency Segment ID is
by Advertising Node Identifier of Protocol in local advertised by the Advertising Node Identifier of the
IGP database { Protocol in the local IGP database {
* When protocol field in received IGP-Adjacency * When the Protocol field in the received IGP-
Segment ID Sub-TLV is 0, Use any locally enabled Adjacency Segment ID sub-TLV is 0, use any locally
IGP protocol. enabled IGP protocol.
* When protocol field in received IGP-Adjacency * When the Protocol field in the received IGP-
Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. Adjacency Segment ID sub-TLV is 1, use OSPF as the
IGP protocol.
* When protocol field in received IGP-Adjacency * When the Protocol field in the received IGP-
Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. Adjacency Segment ID sub-TLV is 2, use IS-IS as the
IGP protocol.
* When protocol field in received IGP-Adjacency * When the Protocol field in the received IGP-
Segment ID Sub-TLV is an unrecognized value, it Adjacency Segment ID sub-TLV is an unrecognized
MUST be treated as Protocol value of 0. value, it MUST be treated as a Protocol value of 0.
} }
When the Adj. Type is 4 or 6 (IGP Adjacency or LAN When the Adj. Type is 4 or 6 (IGP Adjacency or LAN
Adjacency): Adjacency):
o Validate that Remote Interface ID matches the local o Validate that the Remote Interface ID matches the
identifier of the interface (Interface-I) on which the local identifier of the interface (Interface-I) on
packet was received. which the packet was received.
o Validate that Receiving Node Identifier is local IGP o Validate that the Receiving Node Identifier is the
identifier. local IGP identifier.
o Validate that IGP-Adjacency Segment ID is advertised o Validate that the IGP-Adjacency Segment ID is
by Advertising Node Identifier of Protocol in local advertised by the Advertising Node Identifier of
IGP database { Protocol in the local IGP database {
* When protocol field in received IGP-Adjacency * When the Protocol field in the received IGP-
Segment ID Sub-TLV is 0, Use any locally enabled Adjacency Segment ID sub-TLV is 0, use any locally
IGP protocol. enabled IGP protocol.
* When protocol field in received IGP-Adjacency * When the Protocol field in the received IGP-
Segment ID Sub-TLV is 1, Use OSPF as IGP protocol. Adjacency Segment ID sub-TLV is 1, use OSPF as the
IGP protocol.
* When protocol field in received IGP-Adjacency * When the Protocol field in the received IGP-
Segment ID Sub-TLV is 2, Use ISIS as IGP protocol. Adjacency Segment ID sub-TLV is 2, use IS-IS as the
IGP protocol.
* When protocol field in received IGP-Adjacency * When the Protocol field in the received IGP-
Segment ID Sub-TLV is an unrecognized value, it Adjacency Segment ID sub-TLV is an unrecognized
MUST be treated as Protocol value of 0. value, it MUST be treated as a Protocol value of 0.
} }
set FEC-Status to 1, and return. Set the FEC-Status to 1 and return.
} }
7.5. TTL Consideration for traceroute 7.5. TTL Consideration for Traceroute
LSP Traceroute operation can properly traverse every hop of Segment The LSP Traceroute operation can properly traverse every hop of the
Routing network for the Uniform Model as described in [RFC3443]. If SR network for the Uniform Model as described in [RFC3443]. If one
one or more LSRs employ a Short Pipe Model, as described in or more LSRs employ a Short Pipe Model, as described in [RFC3443],
[RFC3443], then LSP Traceroute may not be able to properly traverse then the LSP Traceroute may not be able to properly traverse every
every hop of Segment Routing network due to the absence of TTL copy hop of the SR network due to the absence of TTL copy operation when
operation when the outer label is popped. The Short Pipe is one of the outer label is popped. The Short Pipe is one of the most
the most commonly used models. The following TTL manipulation commonly used models. The following TTL manipulation technique MAY
technique MAY be used when the Short Pipe model is used. be used when the Short Pipe Model is used.
When tracing a LSP according to the procedures in [RFC8029] the TTL When tracing an LSP according to the procedures in [RFC8029], the TTL
is incremented by one in order to trace the path sequentially along is incremented by one in order to trace the path sequentially along
the LSP. However when a source routed LSP has to be traced there are the LSP. However, when a source-routed LSP has to be traced, there
as many TTLs as there are labels in the stack. The LSR that are as many TTLs as there are labels in the stack. The LSR that
initiates the traceroute SHOULD start by setting the TTL to 1 for the initiates the traceroute SHOULD start by setting the TTL to 1 for the
tunnel in the LSP's label stack it wants to start the tracing from, tunnel in the LSP's label stack it wants to start the tracing from,
the TTL of all outer labels in the stack to the max value, and the the TTL of all outer labels in the stack to the max value, and the
TTL of all the inner labels in the stack to zero. Thus a typical TTL of all the inner labels in the stack to zero. Thus, a typical
start to the traceroute would have a TTL of 1 for the outermost label start to the traceroute would have a TTL of 1 for the outermost label
and all the inner labels would have TTL 0. If the FEC Stack TLV is and all the inner labels would have a TTL of 0. If the FEC Stack TLV
included it should contain only those for the inner stacked tunnels. is included, it should contain only those for the inner-stacked
The Return Code/Subcode and FEC Stack Change TLV should be used to tunnels. The Return Code/Subcode and FEC Stack Change TLV should be
diagnose the tunnel as described in [RFC8029]. When the tracing of a used to diagnose the tunnel as described in [RFC8029]. When the
tunnel in the stack is complete, then the next tunnel in the stack tracing of a tunnel in the stack is complete, then the next tunnel in
should be traced. The end of a tunnel can be detected from the the stack should be traced. The end of a tunnel can be detected from
"Return Code" when it indicates that the responding LSR is an egress the Return Code when it indicates that the responding LSR is an
for the stack at depth 1. Thus the traceroute procedures in egress for the stack at depth 1. Thus, the traceroute procedures in
[RFC8029] can be recursively applied to traceroute a source routed [RFC8029] can be recursively applied to traceroute a source-routed
LSP. LSP.
8. Backward Compatibility with non Segment Routing devices 8. Backward Compatibility with Non-SR Devices
[I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment [INTEROP] describes how SR operates in a network where SR-capable and
Routing operates in a network where SR-capable and non-SR-capable non-SR-capable nodes coexist. In such networks, there may not be any
nodes coexist. In such networks, there may not be any FEC mapping in FEC mapping in the responder when the initiator is SR-capable, while
the responder, when the Initiator is SR-capable, while the responder the responder is not (or vice-versa). But this is not different from
is not (or vice-versa). But this is not different from RSVP and LDP RSVP and LDP interoperation scenarios. When LSP Ping is triggered,
interop scenarios. When LSP Ping is triggered, the responder will the responder will set the FEC-return-code to Return 4, "Replying
set the FEC-return-code to Return 4, "Replying router has no mapping router has no mapping for the FEC at stack-depth".
for the FEC at stack-depth".
Similarly when a SR-capable node assigns Adj-SID for a non-SR-capable Similarly, when an SR-capable node assigns Adj-SID for a non-SR-
node, LSP traceroute may fail as the non-SR-capable node is not aware capable node, the LSP traceroute may fail as the non-SR-capable node
of "IGP Adjacency Segment ID" sub-TLV and may not reply with FEC is not aware of the "IGP Adjacency Segment ID" sub-TLV and may not
Stack change. This may result in any further downstream nodes to reply with the FEC Stack Change sub-TLVs. This may result in any
reply back with Return-code as 4, "Replying router has no mapping for further downstream nodes replying back with a Return Code of 4,
the FEC at stack-depth". "Replying router has no mapping for the FEC at stack-depth".
9. IANA Considerations 9. IANA Considerations
9.1. New Target FEC Stack Sub-TLVs 9.1. New Target FEC Stack Sub-TLVs
IANA is requested to assign three new Sub-TLVs from "Sub-TLVs for TLV IANA has assigned three new sub-TLVs from the "sub-TLVs for TLV Types
Types 1, 16 and 21" sub-registry from the "Multi-Protocol Label 1, 16, and 21" subregistry of the "Multi-Protocol Label Switching
Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry [IANA].
[IANA-MPLS-LSP-PING] registry.
Sub-Type Sub-TLV Name Reference Sub-Type Sub-TLV Name Reference
-------- ----------------- ------------ -------- ----------------- ------------
34 IPv4 IGP-Prefix Segment ID Section 5.1 of this document 34 IPv4 IGP-Prefix Segment ID Section 5.1
35 IPv6 IGP-Prefix Segment ID Section 5.2 of this document 35 IPv6 IGP-Prefix Segment ID Section 5.2
36 IGP-Adjacency Segment ID Section 5.3 of this document 36 IGP-Adjacency Segment ID Section 5.3
Note to the RFC Editor (please remove before publication): IANA has
made early allocation for sub-type 34, 35 and 35. The early
allocation expires 2018-09-15.
9.2. Protocol in the Segment ID sub-TLV 9.2. Protocol in the Segment ID Sub-TLV
IANA is requested to create a new "Protocol in the Segment ID sub- IANA has created a new "Protocol in the Segment ID sub-TLV" (see
TLV" (see Section 5) registry under the "Multi-Protocol Label Section 5) registry under the "Multi-Protocol Label Switching (MPLS)
Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" Label Switched Paths (LSPs) Ping Parameters" registry. Code points
registry. Code points in the range of 0-250 will be assigned by in the range of 0-250 will be assigned by Standards Action [RFC8126].
Standards Action. The range of 251-254 are reserved for experimental The range of 251-254 is reserved for experimental use and will not be
use and will not be assigned. The initial entries into the registry assigned. The value of 255 is marked "Reserved". The initial
will be: entries into the registry are:
Value Meaning Reference Value Meaning Reference
---------- ---------------- ------------ ---------- ---------------- ------------
0 Any IGP Protocol This document 0 Any IGP protocol This document
1 OSPF This document 1 OSPF This document
2 ISIS This document 2 IS-IS This document
9.3. Adjacency Type in the IGP-Adjacency Segment ID 9.3. Adjacency Type in the IGP-Adjacency Segment ID
IANA is requested to create a new "Adjacency Type in the IGP- IANA has created a new "Adjacency Type in the IGP-Adjacency Segment
Adjacency Segment ID" (see Section 5.3) registry under the "Multi- ID" registry (see Section 5.3) under the "Multi-Protocol Label
Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
Parameters" registry. Code points in the range of 0-250 will be registry. Code points in the range of 0-250 will be assigned by
assigned by Standards Action. The range of 251-254 are reserved for Standards Action. The range of 251-254 is reserved for experimental
experimental use and will not be assigned. The initial entries into use and will not be assigned. The value of 255 is marked "Reserved".
the registry will be: The initial entries into the registry are:
Value Meaning Value Meaning
---------- ---------------- ---------- ----------------
0 Unnumbered interface Adjacency 0 Unnumbered Interface Adjacency
1 Parallel Adjacency 1 Parallel Adjacency
4 IPv4, non-parallel Adjacency 4 IPv4, Non-parallel Adjacency
6 IPv6, non-parallel Adjacency 6 IPv6, Non-parallel Adjacency
9.4. Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV 9.4. Protocol in the Label Stack Sub-TLV of the Downstream Detailed
Mapping TLV
IANA is requested to create a new "Protocol in Label Stack Sub-TLV of IANA has created a new "Protocol in the Label Stack sub-TLV of the
Downstream Detailed Mapping TLV" registry under the "Multi-Protocol Downstream Detailed Mapping TLV" registry under the "Multi-Protocol
Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
registry. Code points in the range of 0-250 will be assigned by registry. Code points in the range of 0-250 will be assigned by
Standards Action. The range of 251-254 are reserved for experimental Standards Action. The range of 251-254 is reserved for experimental
use and will not be assigned. The initial entries into the registry use and will not be assigned. The value of 255 is marked "Reserved".
will be: The initial entries into the registry are:
Value Meaning Reference Value Meaning Reference
---------- ---------------- ------------ ---------- ---------------- ------------
0 Unknown Section 3.4.1.2 of RFC8029 0 Unknown Section 3.4.1.2 of RFC 8029
1 Static Section 3.4.1.2 of RFC8029 1 Static Section 3.4.1.2 of RFC 8029
2 BGP Section 3.4.1.2 of RFC8029 2 BGP Section 3.4.1.2 of RFC 8029
3 LDP Section 3.4.1.2 of RFC8029 3 LDP Section 3.4.1.2 of RFC 8029
4 RSVP-TE Section 3.4.1.2 of RFC8029 4 RSVP-TE Section 3.4.1.2 of RFC 8029
5 OSPF Section 6 of this document 5 OSPF Section 6 of this document
6 ISIS Section 6 of this document 6 IS-IS Section 6 of this document
7-250 Unassigned 7-250 Unassigned
251-254 Experimental use This document 251-254 Reserved for
255 Reserved This document Experimental Use This document
255 Reserved This document
9.5. Return Code 9.5. Return Code
IANA is requested to assign a new Return Code from the "Multi- IANA has assigned a new Return Code from the "Multi-Protocol Label
Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in the
Parameters" in the 0-191 (Standards Action) range from the "Return 0-191 (Standards Action) range from the "Return Codes" subregistry.
Codes" Sub-registry.
Value Meaning Reference Value Meaning Reference
---------- ----------------- ------------ ---------- ----------------- ------------
TBD1 Mapping for this FEC is not associated Section 7.4 of 35 Mapping for this FEC is not associated Section 7.4 of
with the incoming interface this document with the incoming interface this document
10. Security Considerations 10. Security Considerations
This document defines additional MPLS LSP Ping Sub-TLVs and follows This document defines additional MPLS LSP Ping sub-TLVs and follows
the mechanisms defined in [RFC8029]. All the security considerations the mechanisms defined in [RFC8029]. All the security considerations
defined in [RFC8029] will be applicable for this document, and in defined in [RFC8029] will be applicable for this document and, in
addition, they do not impose any additional security challenges to be addition, they do not impose any additional security challenges to be
considered. considered.
11. Acknowledgement 11. References
The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji
Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta,
Lizhong Jin, Tom Petch, Victor Ji and Mustapha Aissaoui, Tony
Przygienda, Alexander Vainshtein and Deborah Brungard for their
review and comments.
The authors wold like to thank Loa Andersson for his comments and
recommendation to merge drafts.
12. Contributors
The following are key contributors to this document:
Hannes Gredler, RtBrick, Inc.
Tarek Saad, Cisco Systems, Inc.
Siva Sivabalan, Cisco Systems, Inc.
Balaji Rajagopalan, Juniper Networks
Faisal Iqbal, Cisco Systems, Inc.
13. References
13.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
in Multi-Protocol Label Switching (MPLS) Networks", in Multi-Protocol Label Switching (MPLS) Networks",
RFC 3443, DOI 10.17487/RFC3443, January 2003, RFC 3443, DOI 10.17487/RFC3443, January 2003,
<https://www.rfc-editor.org/info/rfc3443>. <https://www.rfc-editor.org/info/rfc3443>.
skipping to change at page 21, line 26 skipping to change at page 22, line 35
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/info/rfc5307>. <https://www.rfc-editor.org/info/rfc5307>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029, Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017, DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>. <https://www.rfc-editor.org/info/rfc8029>.
13.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-isis-segment-routing-extensions] 11.2. Informative References
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and j. jefftant@gmail.com, [IANA] IANA, "Multi-Protocol Label Switching (MPLS) Label
"IS-IS Extensions for Segment Routing", draft-ietf-isis- Switched Paths (LSPs) Ping Parameters",
segment-routing-extensions-13 (work in progress), June <http://www.iana.org/assignments/
mpls-lsp-ping-parameters>.
[INTEROP] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and
S. Litkowski, "Segment Routing interworking with LDP",
Work in Progress, draft-ietf-spring-segment-routing-ldp-
interop-09, September 2017.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[SR] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", Work in Progress, draft-ietf-spring-
segment-routing-14, December 2017.
[SR-IS-IS] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura,
"IS-IS Extensions for Segment Routing", Work in Progress,
draft-ietf-isis-segment-routing-extensions-15, December
2017. 2017.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [SR-MPLS] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", Work in Progress, draft-ietf-spring-segment-
routing-mpls-11, October 2017.
[SR-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", Work in Progress,
draft-ietf-ospf-segment-routing-extensions-24, December
2017.
[SR-OSPFV3]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3- Extensions for Segment Routing", Work in Progress,
segment-routing-extensions-10 (work in progress), draft-ietf-ospf-ospfv3-segment-routing-extensions-10,
September 2017. September 2017.
[I-D.ietf-ospf-segment-routing-extensions] Acknowledgements
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-19 (work in progress), August 2017.
[I-D.ietf-spring-segment-routing] The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta,
and R. Shakir, "Segment Routing Architecture", draft-ietf- Lizhong Jin, Tom Petch, Victor Ji, Mustapha Aissaoui, Tony
spring-segment-routing-12 (work in progress), June 2017. Przygienda, Alexander Vainshtein, and Deborah Brungard for their
review and comments.
[I-D.ietf-spring-segment-routing-ldp-interop] The authors would like to thank Loa Andersson for his comments and
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and recommendation to merge documents.
S. Litkowski, "Segment Routing interworking with LDP",
draft-ietf-spring-segment-routing-ldp-interop-09 (work in
progress), September 2017.
[I-D.ietf-spring-segment-routing-mpls] Contributors
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-10
(work in progress), June 2017.
[IANA-MPLS-LSP-PING] The following are key contributors to this document:
IANA, "Multi-Protocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters",
<http://www.iana.org/assignments/mpls-lsp-ping-parameters/
mpls-lsp-ping-parameters.xhtml>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, Hannes Gredler, RtBrick, Inc.
RFC 792, DOI 10.17487/RFC0792, September 1981, Tarek Saad, Cisco Systems, Inc.
<https://www.rfc-editor.org/info/rfc792>. Siva Sivabalan, Cisco Systems, Inc.
Balaji Rajagopalan, Juniper Networks
Faisal Iqbal, Cisco Systems, Inc.
Authors' Addresses Authors' Addresses
Nagendra Kumar (editor) Nagendra Kumar (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, NC 27709-4987 Research Triangle Park, NC 27709-4987
US United States of America
Email: naikumar@cisco.com Email: naikumar@cisco.com
Carlos Pignataro (editor) Carlos Pignataro (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
7200-11 Kit Creek Road 7200-11 Kit Creek Road
Research Triangle Park, NC 27709-4987 Research Triangle Park, NC 27709-4987
US United States of America
Email: cpignata@cisco.com Email: cpignata@cisco.com
George Swallow George Swallow
Southend Technical Center Southend Technical Center
Email: swallow.ietf@gmail.com Email: swallow.ietf@gmail.com
Nobo Akiya Nobo Akiya
Big Switch Networks Big Switch Networks
Email: nobo.akiya.dev@gmail.com Email: nobo.akiya.dev@gmail.com
Sriganesh Kini Sriganesh Kini
Individual Individual
Email: sriganeshkini@gmail.com Email: sriganeshkini@gmail.com
 End of changes. 178 change blocks. 
575 lines changed or deleted 587 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/