draft-ietf-mpls-spring-lsp-ping-01.txt | draft-ietf-mpls-spring-lsp-ping-02.txt | |||
---|---|---|---|---|
Network Work group N. Kumar | Network Work group N. Kumar | |||
Internet-Draft G. Swallow | Internet-Draft G. Swallow | |||
Intended status: Standards Track C. Pignataro | Intended status: Standards Track C. Pignataro | |||
Expires: May 4, 2017 Cisco Systems, Inc. | Expires: June 4, 2017 Cisco Systems, Inc. | |||
N. Akiya | N. Akiya | |||
Big Switch Networks | Big Switch Networks | |||
S. Kini | S. Kini | |||
Individual | Individual | |||
H. Gredler | H. Gredler | |||
Juniper Networks | Juniper Networks | |||
M. Chen | M. Chen | |||
Huawei | Huawei | |||
October 31, 2016 | December 1, 2016 | |||
Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using | Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using | |||
MPLS Dataplane | MPLS Dataplane | |||
draft-ietf-mpls-spring-lsp-ping-01 | draft-ietf-mpls-spring-lsp-ping-02 | |||
Abstract | Abstract | |||
Segment Routing architecture leverages the source routing and | Segment Routing architecture leverages the source routing and | |||
tunneling paradigms and can be directly applied to MPLS data plane. | tunneling paradigms and can be directly applied to MPLS data plane. | |||
A node steers a packet through a controlled set of instructions | A node steers a packet through a controlled set of instructions | |||
called segments, by prepending the packet with a Segment Routing | called segments, by prepending the packet with a Segment Routing | |||
header. | header. | |||
The segment assignment and forwarding semantic nature of Segment | The segment assignment and forwarding semantic nature of Segment | |||
skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on May 4, 2017. | This Internet-Draft will expire on June 4, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 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 | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 | 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Challenges with Existing mechanism . . . . . . . . . . . . . 4 | 4. Challenges with Existing mechanism . . . . . . . . . . . . . 4 | |||
4.1. Path validation in Segment Routing networks . . . . . . . 4 | 4.1. Path validation in Segment Routing networks . . . . . . . 4 | |||
4.2. Service Label . . . . . . . . . . . . . . . . . . . . . . 5 | 4.2. Service Label . . . . . . . . . . . . . . . . . . . . . . 5 | |||
5. Segment ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 5 | 5. Segment ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 5 | |||
5.1. IPv4 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 5 | 5.1. IPv4 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 6 | |||
5.2. IPv6 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 6 | 5.2. IPv6 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 6 | |||
5.3. IGP-Adjacency Segment ID . . . . . . . . . . . . . . . . 7 | 5.3. IGP-Adjacency Segment ID . . . . . . . . . . . . . . . . 7 | |||
6. Extension to Downstream Mapping TLV . . . . . . . . . . . . . 8 | 6. Extension to Downstream Detailed Mapping TLV . . . . . . . . 9 | |||
7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 9 | 7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 10 | |||
7.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 10 | 7.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 10 | |||
7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 10 | 7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 11 | |||
7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 10 | 7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 11 | |||
7.5. TTL Consideration for traceroute . . . . . . . . . . . . 12 | 7.5. TTL Consideration for traceroute . . . . . . . . . . . . 13 | |||
8. Issues with non-forwarding labels . . . . . . . . . . . . . . 13 | 8. Issues with non-forwarding labels . . . . . . . . . . . . . . 13 | |||
9. Backward Compatibility with non Segment Routing devices . . . 13 | 9. Backward Compatibility with non Segment Routing devices . . . 14 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
10.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . 13 | 10.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . 14 | |||
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 10.2. Protocol in Label Stack Sub-TLV of Downstream Detailed | |||
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 | Mapping TLV . . . . . . . . . . . . . . . . . . . . . . 14 | |||
13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 14 | 10.3. Return Code . . . . . . . . . . . . . . . . . . . . . . 15 | |||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | |||
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 | 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
14.2. Informative References . . . . . . . . . . . . . . . . . 16 | 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
14.1. Normative References . . . . . . . . . . . . . . . . . . 16 | ||||
14.2. Informative References . . . . . . . . . . . . . . . . . 17 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | ||||
1. Introduction | 1. Introduction | |||
[I-D.ietf-spring-segment-routing] introduces and explains Segment | [I-D.ietf-spring-segment-routing] introduces and explains Segment | |||
Routing architecture that leverages the source routing and tunneling | Routing architecture that leverages the source routing and tunneling | |||
paradigms. A node steers a packet through a controlled set of | paradigms. A node steers a packet through a controlled set of | |||
instructions called segments, by prepending the packet with Segment | instructions called segments, by prepending the packet with Segment | |||
Routing header. A detailed definition about Segment Routing | Routing header. A detailed definition about Segment Routing | |||
architecture is available in [I-D.ietf-spring-segment-routing] | architecture is available in [I-D.ietf-spring-segment-routing] | |||
As defined in [I-D.ietf-spring-segment-routing-mpls], the Segment | As defined in [I-D.ietf-spring-segment-routing-mpls], the Segment | |||
Routing architecture can be directly applied to MPLS data plane in a | Routing architecture can be directly applied to MPLS data plane in a | |||
way that, the Segment identifier (Segment ID) will be of 20-bits size | way that, the Segment identifier (Segment ID) will be of 20-bits size | |||
and Segment Routing header is the label stack. | and Segment Routing header is the label stack. | |||
"Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures" | "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures" | |||
[RFC4379] defines a simple and efficient mechanism to detect data | [I-D.ietf-mpls-rfc4379bis] defines a simple and efficient mechanism | |||
plane failures in Label Switched Paths (LSP) by specifying | to detect data plane failures in Label Switched Paths (LSP) by | |||
information to be carried in an MPLS "echo request" and "echo reply" | specifying information to be carried in an MPLS "echo request" and | |||
for the purposes of fault detection and isolation. Mechanisms for | "echo reply" for the purposes of fault detection and isolation. | |||
reliably sending the echo reply are defined. The functionality | Mechanisms for reliably sending the echo reply are defined. The | |||
defined in [RFC4379]is modeled after the ping/traceroute paradigm | functionality defined in [I-D.ietf-mpls-rfc4379bis] is modeled after | |||
(ICMP echo request [RFC0792]) and is typically referred to as LSP | the ping/traceroute paradigm (ICMP echo request [RFC0792]) and is | |||
ping and LSP traceroute. [RFC6424] updates [RFC4379] to support | typically referred to as LSP ping and LSP traceroute. | |||
hierarchal and stitching LSPs. | [I-D.ietf-mpls-rfc4379bis] supports hierarchal and stitching LSPs. | |||
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, segment assignment in Segment Routing architecture is not | protocols, segment assignment in Segment Routing architecture is not | |||
hop-by-hop basis. | hop-by-hop basis. | |||
This nature of Segment Routing raises additional consideration for | This nature of Segment Routing raises additional consideration for | |||
fault detection and isolation in Segment Routing network. This | fault detection and isolation in Segment Routing network. This | |||
document illustrates the problem and describe a mechanism to perform | document illustrates the problem and describe a mechanism to perform | |||
LSP Ping and Traceroute on Segment Routing network over MPLS data | LSP Ping and Traceroute on Segment Routing network over MPLS data | |||
plane. | plane. | |||
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", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
3. Terminology | 3. Terminology | |||
This document uses the terminologies defined in | This document uses the terminologies defined in | |||
[I-D.ietf-spring-segment-routing], [RFC4379], and so the readers are | [I-D.ietf-spring-segment-routing], [I-D.ietf-mpls-rfc4379bis], and so | |||
expected to be familiar with the same. | the readers are expected to be familiar with the same. | |||
4. Challenges with Existing mechanism | 4. Challenges with Existing mechanism | |||
This document defines sub-TLVs for the Target FEC Stack TLV and | This document defines sub-TLVs for the Target FEC Stack TLV and | |||
explains how they can be used to tackle below challenges. | explains how they can be used to tackle below challenges. | |||
4.1. Path validation in Segment Routing networks | 4.1. Path validation in Segment Routing networks | |||
[RFC4379] defines the OAM machinery that helps with fault detection | [I-D.ietf-mpls-rfc4379bis] defines the OAM machinery that helps with | |||
and isolation in MPLS dataplane path with the use of various Target | fault detection and isolation in MPLS dataplane path with the use of | |||
FEC Stack Sub-TLV that are carried in MPLS Echo Request packets and | various Target FEC Stack Sub-TLV that are carried in MPLS Echo | |||
used by the responder for FEC validation. While it is obvious that | Request packets and used by the responder for FEC validation. While | |||
new Sub-TLVs need to be assigned, the unique nature of Segment | it is obvious that new Sub-TLVs need to be assigned, the unique | |||
Routing architecture raises a need for additional machinery for path | nature of Segment Routing architecture raises a need for additional | |||
validation. This section discuss the challenges as below: | machinery for path validation. This section discuss the challenges | |||
as below: | ||||
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, 5002, 5003, 5004, 5005, 5006, 5007, 5008 respectively. | The Node segment IDs for R1, R2, R3, R4, R5, R6, R7 and R8 are 5001, | |||
5002, 5003, 5004, 5005, 5006, 5007, 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. | ||||
9124 --> Adjacency segment ID from R2 to R4. | 9236 --> Adjacency Segment ID from R3 to R6 over link L2. | |||
9123 --> Adjacency Segment ID from R2 to R3. | ||||
9124 --> Adjacency segment ID from R2 to R4. | ||||
9123 --> Adjacency Segment ID from R2 to R3. | ||||
The forwarding semantic of Adjacency Segment ID is to pop the segment | The forwarding semantic of Adjacency Segment ID is to pop the segment | |||
ID and send the packet to a specific neighbor over a specific link. | ID and send the packet to a specific neighbor over a specific link. | |||
A malfunctioning node may forward packets using Adjacency Segment ID | A malfunctioning node may forward packets using Adjacency Segment ID | |||
to incorrect neighbor or over incorrect link. Exposed segment ID | to incorrect neighbor or over incorrect link. Exposed segment ID | |||
(after incorrectly forwarded Adjacency Segment ID) might still allow | (after incorrectly forwarded Adjacency Segment ID) might still allow | |||
such packet to reach the intended destination, although the intended | such packet to reach the intended destination, although the intended | |||
strict traversal has been broken. | strict traversal has been broken. | |||
Assume in above topology, R1 sends traffic with segment stack as | Assume in above topology, R1 sends traffic with segment stack as | |||
{9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8. If | {9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8. If | |||
the Adjacency Segment ID 9124 is misprogrammed in R2 to send the | the Adjacency Segment ID 9124 is misprogrammed in R2 to send the | |||
packet to R1 or R3, it will still be delivered to R8 but is not via | packet to R1 or R3, it will still be delivered to R8 but is not via | |||
skipping to change at page 5, line 27 ¶ | skipping to change at page 5, line 37 ¶ | |||
represents a service to be applied along the path. Since these | represents a service to be applied along the path. Since these | |||
labels are part of the label stack, they can influence the path taken | labels are part of the label stack, they can influence the path taken | |||
by a packet and consequently have implications on MPLS OAM. Service | by a packet and consequently have implications on MPLS OAM. Service | |||
Label is left for future study. | Label is left for future study. | |||
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 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 [RFC4379], this allows LSP ping/traceroute operations to | defined in [I-D.ietf-mpls-rfc4379bis], this allows LSP ping/ | |||
function when Target FEC Stack TLV contains more FECs than received | traceroute operations to function when Target FEC Stack TLV contains | |||
label stack at responder nodes. | more FECs than received label stack at responder nodes. | |||
Three new sub-TLVs are defined for Target FEC Stack TLVs (Type 1), | Three new sub-TLVs are defined for Target FEC Stack TLVs (Type 1), | |||
Reverse-Path Target FEC Stack TLV (Type 16) and Reply Path TLV (Type | Reverse-Path Target FEC Stack TLV (Type 16) and Reply Path TLV (Type | |||
21). | 21). | |||
sub-Type Value Field | sub-Type Value Field | |||
-------- --------------- | -------- --------------- | |||
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 | |||
skipping to change at page 8, line 37 ¶ | skipping to change at page 9, line 17 ¶ | |||
Specifies the advertising node identifier. When Protocol is set | Specifies the advertising node identifier. When Protocol is set | |||
to 1, then the 32 rightmost bits represent OSPF Router ID and if | to 1, then the 32 rightmost bits represent OSPF Router ID and if | |||
protocol is set to 2, this field carries 48 bit ISIS System ID. | protocol is set to 2, this field carries 48 bit ISIS System ID. | |||
Receiving Node Identifier | Receiving Node Identifier | |||
Specifies the downstream node identifier. When Protocol is set to | Specifies the downstream node identifier. When Protocol is set to | |||
1, then the 32 rightmost bits represent OSPF Router ID and if | 1, then the 32 rightmost bits represent OSPF Router ID and if | |||
protocol is set to 2, this field carries 48 bit ISIS System ID. | protocol is set to 2, this field carries 48 bit ISIS System ID. | |||
6. Extension to Downstream Mapping TLV | 6. Extension to Downstream Detailed Mapping TLV | |||
In an echo reply, the Downstream Mapping TLV [RFC4379] is used to | In an echo reply, the Downstream Detailed Mapping TLV | |||
report for each interface over which a FEC could be forwarded. For a | [I-D.ietf-mpls-rfc4379bis] is used to report for each interface over | |||
FEC, there are multiple protocols that may be used to distribute | which a FEC could be forwarded. For a FEC, there are multiple | |||
label mapping. The "Protocol" field of the Downstream Mapping TLV is | protocols that may be used to distribute label mapping. The | |||
used to return the protocol that is used to distribute a specific a | "Protocol" field of the Downstream Detailed Mapping TLV is used to | |||
label. The following protocols are defined in section 3.2 of | return the protocol that is used to distribute a specific a label. | |||
[RFC4379]: | The following protocols are defined in section 3.4.1.2 of | |||
[I-D.ietf-mpls-rfc4379bis]: | ||||
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 segment routing, OSPF or ISIS can be used for label | |||
distribution, this document adds two new protocols as follows: | distribution, this document adds two new protocols as follows: | |||
Protocol # Signaling Protocol | Protocol # Signaling Protocol | |||
---------- ------------------ | ---------- ------------------ | |||
TBD5 OSPF | TBD5 OSPF | |||
TBD6 ISIS | TBD6 ISIS | |||
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 [RFC4379]. | that require further considerations beyond | |||
[I-D.ietf-mpls-rfc4379bis]. | ||||
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 Target FEC Stack TLV may need to have deviating contents. | carried in Target FEC Stack TLV may need to have deviating contents. | |||
This document outlines expected Target FEC Stack TLV construction | This document outlines expected Target FEC Stack TLV construction | |||
mechanics by initiator for known scenarios. | mechanics by initiator for known scenarios. | |||
Ping | Ping | |||
skipping to change at page 9, line 50 ¶ | skipping to change at page 10, line 29 ¶ | |||
communicate the segments traversed. | communicate the segments traversed. | |||
Traceroute | Traceroute | |||
Initiator MUST initially include FECs corresponding to all of | Initiator MUST initially include FECs corresponding to all of | |||
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 FEC Stack Change TLV with | |||
one or more of original segment(s) being popped, initiator MAY | one or more of original segment(s) being popped, initiator MAY | |||
remove corresponding FEC(s) from Target FEC Stack TLV in the | remove corresponding FEC(s) from Target FEC Stack TLV in the | |||
next (TTL+1) traceroute request as defined in section 4.3.1.2 | next (TTL+1) traceroute request as defined in section 4.6 of | |||
of [RFC6424]. | [I-D.ietf-mpls-rfc4379bis]. | |||
When a received echo reply does not contain FEC Stack Change | When a received echo reply does not contain FEC Stack Change | |||
TLV, initiator MUST NOT attempt to remove FEC(s) from Target | TLV, initiator MUST NOT attempt to remove FEC(s) from Target | |||
FEC Stack TLV in the next (TTL+1) traceroute request. | FEC Stack TLV in the next (TTL+1) traceroute request. | |||
7.2. FEC Stack Change sub-TLV | 7.2. FEC Stack Change sub-TLV | |||
Section 3.3.1.3 of [RFC6424] defines FEC Stack Change sub-TLV that a | Section 3.4.1.3 of [I-D.ietf-mpls-rfc4379bis] defines FEC Stack | |||
router must include when the FEC stack changes. | Change sub-TLV that a router must include when the FEC stack changes. | |||
The network node which advertised the Node Segment ID is responsible | The network node which advertised the Node Segment ID is responsible | |||
for generating FEC Stack Change sub-TLV of &pop& operation for Node | for generating FEC Stack Change sub-TLV of &pop& operation for Node | |||
Segment ID, regardless of if PHP is enabled or not. | Segment ID, regardless of if PHP is enabled or not. | |||
The network node that is immediate downstream of the node which | The network node that is immediate downstream of the node which | |||
advertised the Adjacency Segment ID is responsible for generating FEC | advertised the Adjacency Segment ID is responsible for generating FEC | |||
Stack Change sub-TLV of &pop& operation for Adjacency Segment ID. | Stack Change sub-TLV of &pop& operation for 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 Node Segment ID with PHP flag is | |||
equivalent to usage of implicit Null in MPLS protocols. Adjacency | equivalent to usage of implicit Null in MPLS protocols. Adjacency | |||
Segment ID is also similar in a sense that it can be thought as next | Segment ID is also similar in a sense that it can be thought as next | |||
hop destined locally allocated segment that has PHP enabled. | hop destined locally allocated segment that has PHP enabled. | |||
Procedures described in Section 4.4 of [RFC4379] relies on Stack-D | Procedures described in Section 4.4 of [I-D.ietf-mpls-rfc4379bis] | |||
and Stack-R explicitly having Implicit Null value. It may simplify | relies on Stack-D and Stack-R explicitly having Implicit Null value. | |||
implementations to reuse Implicit Null for Node Segment ID PHP and | It may simplify implementations to reuse Implicit Null for Node | |||
Adjacency Segment ID cases. | Segment ID PHP and Adjacency Segment ID cases. | |||
7.4. Segment ID Check | 7.4. Segment ID Check | |||
This section updates the procedure defined in Step 6 of section 4.4. | This section updates the procedure defined in Step 6 of section 4.4. | |||
of [RFC4379] | of [I-D.ietf-mpls-rfc4379bis] | |||
If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at FEC- | If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at FEC- | |||
stack-depth is 34 (IPv4 IGP-Prefix Segment ID), the responder | stack-depth is 34 (IPv4 IGP-Prefix Segment ID), the responder | |||
should set Best return code to 10, "Mapping for this FEC is not | should set Best return code to 10, "Mapping for this FEC is not | |||
the given label at stack-depth <RSC>" if any below conditions | the given label at stack-depth <RSC>" if any below conditions | |||
fail: | fail: | |||
/* The responder LSR is to check if it is the egress of the IPv4 | /* The responder LSR is to check if it is the egress of the IPv4 | |||
IGP-Prefix Segment ID described in the Target FEC Stack Sub-TLV, | IGP-Prefix Segment ID described in the Target FEC Stack Sub-TLV, | |||
and if the FEC was advertised with the PHP bit set.*/ | and if the FEC was advertised with the PHP bit set.*/ | |||
skipping to change at page 11, line 39 ¶ | skipping to change at page 12, line 23 ¶ | |||
* Validate that Node Segment ID is advertised of PHP bit. | * Validate that Node Segment ID is advertised of PHP bit. | |||
If the Label-stack-depth is more than 0 and Target FEC Sub-TLV at | If the Label-stack-depth is more than 0 and Target FEC Sub-TLV at | |||
FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), set Best | FEC-stack-depth is 35 (IPv6 IGP-Prefix Segment ID), set Best | |||
return code to 10 if any below conditions fail: | return code to 10 if any below conditions fail: | |||
* Validate that Node Segment ID is advertised for IPv6 Prefix. | * Validate that Node Segment ID is advertised for IPv6 Prefix. | |||
If the Label-stack-depth is 0 and Target FEC sub-TLV at FEC-stack- | If the Label-stack-depth is 0 and Target FEC sub-TLV at FEC-stack- | |||
depth is 36 (Adjacency Segment ID), set Best return code to (error | depth is 36 (Adjacency Segment ID), set Best return code to TBD7 | |||
code TBD) if any below conditions fail: | (Section 10.3) if any below conditions fail: | |||
When the Adj. Type is 1 (Parallel Adjacency): | When the Adj. Type is 1 (Parallel Adjacency): | |||
+ Validate that Receiving Node Identifier is local IGP | + Validate that Receiving Node Identifier is local IGP | |||
identifier. | identifier. | |||
+ Validate that Adjacency Segment ID is advertised by | + Validate that Adjacency Segment ID is advertised by | |||
Advertising Node Identifier of Protocol in local IGP | Advertising Node Identifier of Protocol in local IGP | |||
database. | database. | |||
skipping to change at page 12, line 29 ¶ | skipping to change at page 13, line 16 ¶ | |||
LSP Traceroute operation can properly traverse every hop of Segment | LSP Traceroute operation can properly traverse every hop of Segment | |||
Routing network in Uniform Model described in [RFC3443]. If one or | Routing network in Uniform Model described in [RFC3443]. If one or | |||
more LSRs employ Short Pipe Model described in [RFC3443], then LSP | more LSRs employ Short Pipe Model described in [RFC3443], then LSP | |||
Traceroute may not be able to properly traverse every hop of Segment | Traceroute may not be able to properly traverse every hop of Segment | |||
Routing network due to absence of TTL copy operation when outer label | Routing network due to absence of TTL copy operation when outer label | |||
is popped. Short Pipe being the most commonly used model. The | is popped. Short Pipe being the most commonly used model. The | |||
following TTL manipulation technique MAY be used when Short Pipe | following TTL manipulation technique MAY be used when Short Pipe | |||
model is used. | model is used. | |||
When tracing a LSP according to the procedures in [RFC4379] the TTL | When tracing a LSP according to the procedures in | |||
is incremented by one in order to trace the path sequentially along | [I-D.ietf-mpls-rfc4379bis] the TTL is incremented by one in order to | |||
the LSP. However when a source routed LSP has to be traced there are | trace the path sequentially along the LSP. However when a source | |||
as many TTLs as there are labels in the stack. The LSR that | routed LSP has to be traced there are as many TTLs as there are | |||
initiates the traceroute SHOULD start by setting the TTL to 1 for the | labels in the stack. The LSR that initiates the traceroute SHOULD | |||
tunnel in the LSP's label stack it wants to start the tracing from, | start by setting the TTL to 1 for the tunnel in the LSP's label stack | |||
the TTL of all outer labels in the stack to the max value, and the | it wants to start the tracing from, the TTL of all outer labels in | |||
TTL of all the inner labels in the stack to zero. Thus a typical | the stack to the max value, and the TTL of all the inner labels in | |||
start to the traceroute would have a TTL of 1 for the outermost label | the stack to zero. Thus a typical start to the traceroute would have | |||
and all the inner labels would have TTL 0. If the FEC Stack TLV is | a TTL of 1 for the outermost label and all the inner labels would | |||
included it should contain only those for the inner stacked tunnels. | have TTL 0. If the FEC Stack TLV is included it should contain only | |||
The Return Code/Subcode and FEC Stack Change TLV should be used to | those for the inner stacked tunnels. The Return Code/Subcode and FEC | |||
diagnose the tunnel as described in [RFC4379] and [RFC6424]. When | Stack Change TLV should be used to diagnose the tunnel as described | |||
the tracing of a tunnel in the stack is complete, then the next | in [I-D.ietf-mpls-rfc4379bis]. When the tracing of a tunnel in the | |||
tunnel in the stack should be traced. The end of a tunnel can be | stack is complete, then the next tunnel in the stack should be | |||
detected from the "Return Code" when it indicates that the responding | traced. The end of a tunnel can be detected from the "Return Code" | |||
LSR is an egress for the stack at depth 1. Thus the traceroute | when it indicates that the responding LSR is an egress for the stack | |||
procedures in [RFC4379] can be recursively applied to traceroute a | at depth 1. Thus the traceroute procedures in | |||
[I-D.ietf-mpls-rfc4379bis] can be recursively applied to traceroute a | ||||
source routed LSP. | source routed LSP. | |||
8. Issues with non-forwarding labels | 8. Issues with non-forwarding labels | |||
Source stacking can be optionally used to apply services on the | Source stacking can be optionally used to apply services on the | |||
packet at a LSR along the path, where a label in the stack is used to | packet at a LSR along the path, where a label in the stack is used to | |||
trigger service application. A data plane failure detection and | trigger service application. A data plane failure detection and | |||
isolation mechanism should provide its functionality without applying | isolation mechanism should provide its functionality without applying | |||
these services. This is mandatory for services that are stateful, | these services. This is mandatory for services that are stateful, | |||
though for stateless services [RFC4379] could be used as-is. It MAY | though for stateless services [I-D.ietf-mpls-rfc4379bis] could be | |||
also provide a mechanism to detect and isolate faults within the | used as-is. It MAY also provide a mechanism to detect and isolate | |||
service function itself. | faults within the service function itself. | |||
How a node treats Service label is outside the scope of this document | How a node treats Service label is outside the scope of this document | |||
and will be included in this or a different document later. | and will be included in this or a different document later. | |||
9. Backward Compatibility with non Segment Routing devices | 9. Backward Compatibility with non Segment Routing devices | |||
[I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment | [I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment | |||
Routing operates in network where SR-capable and non-SR-capable nodes | Routing operates in network where SR-capable and non-SR-capable nodes | |||
coexist. In such networks, there may not be any FEC mapping in the | coexist. In such networks, there may not be any FEC mapping in the | |||
responder when the Initiator is SR-capable while the responder is not | responder when the Initiator is SR-capable while the responder is not | |||
skipping to change at page 13, line 41 ¶ | skipping to change at page 14, line 27 ¶ | |||
node, LSP trace may fail as the non-SR-capable node is not aware of | node, LSP trace may fail as the non-SR-capable node is not aware of | |||
"IGP Adjacency Segment ID" sub-TLV and may not reply with FEC Stack | "IGP Adjacency Segment ID" sub-TLV and may not reply with FEC Stack | |||
change. This may result in any further downstream nodes to reply | change. This may result in any further downstream nodes to reply | |||
back with Return-code as 4, "Replying router has no mapping for the | back with Return-code as 4, "Replying router has no mapping for the | |||
FEC at stack-depth". | FEC at stack-depth". | |||
10. IANA Considerations | 10. IANA Considerations | |||
10.1. New Target FEC Stack Sub-TLVs | 10.1. New Target FEC Stack Sub-TLVs | |||
IANA is requested to assign 3 new Sub-TLVs from "Sub-TLVs for TLV | IANA is requested to assign three new sub-TLVs from "Sub-TLVs for TLV | |||
Types 1, 16 and 21" sub-registry. | Types 1, 16 and 21" sub-registry from the "Multi-Protocol Label | |||
Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" | ||||
[IANA-MPLS-LSP-PING] registry. | ||||
Sub-Type Sub-TLV Name Reference | Sub-Type Sub-TLV Name Reference | |||
---------- ----------------- ------------ | ---------- ----------------- ------------ | |||
34 IPv4 IGP-Prefix Segment ID Section 4.1 (this document) | 34 IPv4 IGP-Prefix Segment ID Section 5.1 (this document) | |||
35 IPv6 IGP-Prefix Segment ID Section 4.2 (this document) | 35 IPv6 IGP-Prefix Segment ID Section 5.2 (this document) | |||
36 IGP-Adjacency Segment ID Section 4.3 (this document) | 36 IGP-Adjacency Segment ID Section 5.3 (this document) | |||
10.2. Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping | ||||
TLV | ||||
IANA is requested to create a new "Protocol" registry under the Label | ||||
Stack Sub-TLV of the Downstream Detailed Mapping TLV in the "Multi- | ||||
Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping | ||||
Parameters" registry [IANA-MPLS-LSP-PING]. | ||||
Value Meaning Reference | ||||
------ ---------- ------------ | ||||
0 Unknown Section 3.4.2.1 [I-D.ietf-mpls-rfc4379bis] | ||||
1 Static Section 3.4.2.1 [I-D.ietf-mpls-rfc4379bis] | ||||
2 BGP Section 3.4.2.1 [I-D.ietf-mpls-rfc4379bis] | ||||
3 LDP Section 3.4.2.1 [I-D.ietf-mpls-rfc4379bis] | ||||
4 RSVP-TE Section 3.4.2.1 [I-D.ietf-mpls-rfc4379bis] | ||||
TBD5 OSPF Section 6 (this document) | ||||
TBD6 ISIS Section 6 (this document) | ||||
10.3. Return Code | ||||
IANA is requested to assign a new Return Code from the "Multi- | ||||
Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping | ||||
Parameters" [IANA-MPLS-LSP-PING] in "Return Codes" Sub-registry. | ||||
Value Meaning Reference | ||||
------- ----------------- ------------ | ||||
TBD7 Mapping for this FEC is not associated Section 7.4 | ||||
with the incoming interface (this document) | ||||
11. Security Considerations | 11. Security Considerations | |||
This document defines additional Sub-TLVs and follows the mechanism | This document defines additional Sub-TLVs and follows the mechanism | |||
defined in [RFC4379]. So all the security consideration defined in | defined in [I-D.ietf-mpls-rfc4379bis]. So all the security | |||
[RFC4379] will be applicable for this document and in addition it | consideration defined in [I-D.ietf-mpls-rfc4379bis] will be | |||
does not impose any security challenges to be considered. | applicable for this document and in addition it does not impose any | |||
security challenges to be considered. | ||||
12. Acknowledgement | 12. Acknowledgement | |||
The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji | The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji | |||
Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta and | Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta, | |||
Lizhong Jin for their review and comments. | Lizhong Jin, Tom Petch, and Mustapha Aissaoui for their review and | |||
comments. | ||||
The authors wold like to thank Loa Andersson for his comments and | The authors wold like to thank Loa Andersson for his comments and | |||
recommendation to merge drafts. | recommendation to merge drafts. | |||
13. Contributing Authors | 13. Contributors | |||
Tarek Saad | ||||
Cisco Systems | ||||
Email: tsaad@cisco.com | ||||
Siva Sivabalan | ||||
Cisco Systems | ||||
Email: msiva@cisco.com | ||||
Balaji Rajagopalan | The following are key contributors to this document: | |||
Juniper Networks | ||||
Email: balajir@juniper.net | ||||
Faisal Iqbal | Tarek Saad, Cisco Systems, Inc. | |||
Cisco Systems | Siva Sivabalan, Cisco Systems, Inc. | |||
Email: faiqbal@cisco.com | Balaji Rajagopalan, Juniper Networks | |||
Faisal Iqbal, Cisco Systems, Inc. | ||||
14. References | 14. References | |||
14.1. Normative References | 14.1. Normative References | |||
[I-D.ietf-isis-segment-routing-extensions] | [I-D.ietf-isis-segment-routing-extensions] | |||
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., | Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., | |||
Litkowski, S., Decraene, B., and j. jefftant@gmail.com, | Litkowski, S., Decraene, B., and j. jefftant@gmail.com, | |||
"IS-IS Extensions for Segment Routing", draft-ietf-isis- | "IS-IS Extensions for Segment Routing", draft-ietf-isis- | |||
segment-routing-extensions-09 (work in progress), October | segment-routing-extensions-09 (work in progress), October | |||
2016. | 2016. | |||
[I-D.ietf-mpls-rfc4379bis] | ||||
Kompella, K., Swallow, G., Pignataro, C., Kumar, N., | ||||
Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label | ||||
Switched (MPLS) Data Plane Failures", draft-ietf-mpls- | ||||
rfc4379bis-09 (work in progress), October 2016. | ||||
[I-D.ietf-ospf-segment-routing-extensions] | [I-D.ietf-ospf-segment-routing-extensions] | |||
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., | Psenak, P., Previdi, S., Filsfils, C., Gredler, H., | |||
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF | Shakir, R., Henderickx, W., and J. Tantsura, "OSPF | |||
Extensions for Segment Routing", draft-ietf-ospf-segment- | Extensions for Segment Routing", draft-ietf-ospf-segment- | |||
routing-extensions-10 (work in progress), October 2016. | routing-extensions-10 (work in progress), October 2016. | |||
[I-D.ietf-spring-segment-routing] | [I-D.ietf-spring-segment-routing] | |||
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., | Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., | |||
and R. Shakir, "Segment Routing Architecture", draft-ietf- | and R. Shakir, "Segment Routing Architecture", draft-ietf- | |||
spring-segment-routing-09 (work in progress), July 2016. | spring-segment-routing-10 (work in progress), November | |||
2016. | ||||
[I-D.ietf-spring-segment-routing-ldp-interop] | ||||
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and | ||||
S. Litkowski, "Segment Routing interworking with LDP", | ||||
draft-ietf-spring-segment-routing-ldp-interop-04 (work in | ||||
progress), July 2016. | ||||
[I-D.ietf-spring-segment-routing-mpls] | [I-D.ietf-spring-segment-routing-mpls] | |||
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., | Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., | |||
Litkowski, S., Horneffer, M., Shakir, R., | Litkowski, S., Horneffer, M., Shakir, R., | |||
jefftant@gmail.com, j., and E. Crabbe, "Segment Routing | jefftant@gmail.com, j., and E. Crabbe, "Segment Routing | |||
with MPLS data plane", draft-ietf-spring-segment-routing- | with MPLS data plane", draft-ietf-spring-segment-routing- | |||
mpls-05 (work in progress), July 2016. | mpls-05 (work in progress), July 2016. | |||
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | ||||
RFC 792, DOI 10.17487/RFC0792, September 1981, | ||||
<http://www.rfc-editor.org/info/rfc792>. | ||||
[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, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <http://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, | |||
<http://www.rfc-editor.org/info/rfc3443>. | <http://www.rfc-editor.org/info/rfc3443>. | |||
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in | [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in | |||
Support of Generalized Multi-Protocol Label Switching | Support of Generalized Multi-Protocol Label Switching | |||
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, | (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, | |||
<http://www.rfc-editor.org/info/rfc4203>. | <http://www.rfc-editor.org/info/rfc4203>. | |||
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol | ||||
Label Switched (MPLS) Data Plane Failures", RFC 4379, | ||||
DOI 10.17487/RFC4379, February 2006, | ||||
<http://www.rfc-editor.org/info/rfc4379>. | ||||
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions | [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions | |||
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, | |||
<http://www.rfc-editor.org/info/rfc5307>. | <http://www.rfc-editor.org/info/rfc5307>. | |||
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for | ||||
Performing Label Switched Path Ping (LSP Ping) over MPLS | ||||
Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, | ||||
<http://www.rfc-editor.org/info/rfc6424>. | ||||
14.2. Informative References | 14.2. Informative References | |||
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, | [I-D.ietf-spring-segment-routing-ldp-interop] | |||
D., and S. Mansfield, "Guidelines for the Use of the "OAM" | Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and | |||
Acronym in the IETF", BCP 161, RFC 6291, | S. Litkowski, "Segment Routing interworking with LDP", | |||
DOI 10.17487/RFC6291, June 2011, | draft-ietf-spring-segment-routing-ldp-interop-04 (work in | |||
<http://www.rfc-editor.org/info/rfc6291>. | progress), July 2016. | |||
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., | [IANA-MPLS-LSP-PING] | |||
Yasukawa, S., and T. Nadeau, "Detecting Data-Plane | IANA, "Multi-Protocol Label Switching (MPLS) Label | |||
Failures in Point-to-Multipoint MPLS - Extensions to LSP | Switched Paths (LSPs) Ping Parameters", | |||
Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, | <http://www.iana.org/assignments/mpls-lsp-ping-parameters/ | |||
<http://www.rfc-editor.org/info/rfc6425>. | mpls-lsp-ping-parameters.xhtml>. | |||
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, | ||||
RFC 792, DOI 10.17487/RFC0792, September 1981, | ||||
<http://www.rfc-editor.org/info/rfc792>. | ||||
Authors' Addresses | Authors' Addresses | |||
Nagendra Kumar | Nagendra Kumar | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
7200 Kit Creek Road | 7200 Kit Creek Road | |||
Research Triangle Park, NC 27709 | Research Triangle Park, NC 27709 | |||
US | US | |||
Email: naikumar@cisco.com | Email: naikumar@cisco.com | |||
End of changes. 44 change blocks. | ||||
156 lines changed or deleted | 183 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |