idnits 2.17.1 draft-kini-spring-mpls-lsp-ping-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3839 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6424' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'I-D.filsfils-rtgwg-segment-routing-use-cases' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'I-D.filsfils-rtgwg-segment-routing' is defined on line 296, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-previdi-isis-segment-routing-extensions-03 == Outdated reference: A later version (-05) exists of draft-psenak-ospf-segment-routing-extensions-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'OAM-UC' ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) == Outdated reference: A later version (-06) exists of draft-geib-spring-oam-usecase-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kini, Ed. 3 Internet-Draft Ericsson 4 Intended status: Standards Track H. Gredler 5 Expires: April 24, 2014 Juniper Networks 6 October 21, 2013 8 Detecting Multi-Protocol Label Switching (MPLS) Data Plane Failures in 9 Source Routed LSPs 10 draft-kini-spring-mpls-lsp-ping-00 12 Abstract 14 MPLS has defined mechanisms for fault detection and isolation and 15 mechanisms for reliably sending an echo reply in RFC 4379. Source 16 routed MPLS LSPs are a technique being proposed to address new use- 17 cases. This document describes how mechanisms defined for MPLS fault 18 detection and isolation can be applied for source routed LSPs. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 24, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 56 2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 3 57 3. Service Labels . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. Target FEC Stack . . . . . . . . . . . . . . . . . . . . 3 60 4.2. OSPF IPv4 Prefix . . . . . . . . . . . . . . . . . . . . 4 61 4.3. OSPF IPv6 Prefix . . . . . . . . . . . . . . . . . . . . 4 62 4.4. ISIS IPv4 Prefix . . . . . . . . . . . . . . . . . . . . 4 63 4.5. ISIS IPv6 Prefix . . . . . . . . . . . . . . . . . . . . 4 64 5. MPLS ping and trace of a source routed LSP . . . . . . . . . 4 65 6. Issues with non-forwarding labels . . . . . . . . . . . . . . 5 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 10.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 Multi Protocol Label Switching (MPLS) has defined in [RFC4379] a 77 simple and efficient mechanism to detect data plane failures in Label 78 Switched Paths (LSP) by specifying information to be carried in an 79 MPLS "echo request" and "echo reply" for the purposes of fault 80 detection and isolation, and mechanisms for reliably sending the echo 81 reply. The functionality is modeled after the ping/traceroute 82 paradigm (ICMP echo request [RFC0792]) and is typically referred to 83 as MPLS-ping and MPLS-traceroute. 85 Source routed LSP is a technique by which the ingress stacks a set of 86 tunnels to route the packet through an explicit-route. Newer use- 87 cases (e.g. [OAM-UC], [I-D.geib-spring-oam-usecase]) are being 88 explored using this technique and detecting data plane failures is a 89 basic requirement in all of them. This document describes how the 90 procedures defined in [RFC4379] can be applied to a source routed 91 LSP. 93 1.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 2. Abbreviations and Terminology 100 TTL - Time to Live 102 OAM - Operation, Administration, Management/Maintenance 104 LSP - Label Switched Path 106 FEC - Forwarding Equivalence Class 108 SPRING - Source Packet Routing in Networking 110 3. Service Labels 112 One of the proposals for source routed LSPs is to include service 113 labels in the MPLS label stack. These service labels are used to 114 apply a service (as indicated by the service label) to the packet at 115 the intermediate LSRs along the explicit-route. Since these labels 116 are part of the MPLS label stack these have implications on MPLS OAM. 117 This document describes how the procedures of [RFC4379] can be 118 applied to in the absence of service-labels in Section 5. Additional 119 considerations for service labels are included in Section 6 and 120 requires further discussion. 122 4. Packet Format 124 4.1. Target FEC Stack 126 The following new FEC Type sub-TLVs are defined to accommodate the 127 distribution of labels by Interior Gateway Protocols (IGP) OSPF and 128 ISIS ([I-D.gredler-rtgwg-igp-label-advertisement], 129 [I-D.gredler-isis-label-advertisement], 130 [I-D.gredler-ospf-label-advertisement], 131 [I-D.previdi-isis-segment-routing-extensions], 132 [I-D.psenak-ospf-segment-routing-extensions]). 134 +----------------------------+--------+------------------+ 135 | Sub-Type(suggested values) | Length | Value Field | 136 +----------------------------+--------+------------------+ 137 | 17 | 5 | OSPF IPv4 Prefix | 138 | 18 | 17 | OSPF IPv6 Prefix | 139 | 19 | 5 | ISIS IPv4 Prefix | 140 | 20 | 17 | ISIS IPv6 Prefix | 141 +----------------------------+--------+------------------+ 142 Table 1 144 4.2. OSPF IPv4 Prefix 146 This value of this sub-TLV is encoded the same as the "Generic IPv4 147 Prefix" defined in section 3.2.13 of [RFC4379]. 149 4.3. OSPF IPv6 Prefix 151 This value of this sub-TLV is encoded the same as the "Generic IPv6 152 Prefix" defined in section 3.2.14 of [RFC4379]. 154 4.4. ISIS IPv4 Prefix 156 This value of this sub-TLV is encoded the same as the "Generic IPv4 157 Prefix" defined in section 3.2.13 of [RFC4379]. 159 4.5. ISIS IPv6 Prefix 161 This value of this sub-TLV is encoded the same as the "Generic IPv6 162 Prefix" defined in section 3.2.14 of [RFC4379]. 164 5. MPLS ping and trace of a source routed LSP 166 The MPLS ping procedures described in [RFC4379] can be applied 167 unchanged to a source routed LSP. The ingress should encapsulate the 168 "echo request" with the label stack just as any data packet and send 169 it on the source routed LSP. Sometimes it is useful to ping a 170 specific tunnel that is used in a source routed LSP. In this case 171 the entire label stack of the source routed LSP must be used, but the 172 TTL of labels below the label of the tunnel that being debugged must 173 be set to zero. 175 When tracing a LSP according to the procedures in [RFC4379] the TTL 176 is incremented by one in order to trace the path sequentially along 177 the LSP. However when a source routed LSP has to be traced there are 178 as many TTLs as there are labels in the stack. The LSR that 179 initiates the traceroute SHOULD start by setting the TTL to 1 for the 180 tunnel in the LSP's label stack it wants to start the tracing from, 181 the TTL of all outer labels in the stack to the max value, and the 182 TTL of all the inner labels in the stack to zero. Thus a typical 183 start to the traceroute would have a TTL of 1 for the outermost label 184 and all the inner labels would have TTL 0. If the FEC Stack TLV is 185 included it should contain only those for the inner stacked tunnels. 186 The lack of an echo response or the Return Code/Subcode should be 187 used to diagnose the tunnel as described in [RFC4379]. When the 188 tracing of a tunnel in the stack is complete, then the next tunnel in 189 the stack should be traced. The end of a tunnel can be detected from 190 the "Return Code" when it indicates that the responding LSR is an 191 egress for the stack at depth 1. Thus the traceroute procedures in 192 [RFC4379] can be recursively applied to traceroute a source routed 193 LSP. 195 6. Issues with non-forwarding labels 197 Source stacking can be optionally used to apply services on the 198 packet at a LSR along the path, where a label in the stack is used to 199 trigger service application. A data plane failure detection and 200 isolation mechanism should provide its functionality without applying 201 these services. This is mandatory for services that are stateful, 202 though for stateless services [RFC4379] could be used as-is. It MAY 203 also provide a mechanism to detect and isolate faults within the 204 service function itself. 206 To prevent services from being applied to an "echo request" packet, 207 the TTL of service labels MUST be 0. However TTL processing rules of 208 a service label must be the same as any MPLS label. Due to this a 209 TTL of 0 in the service label would prevent the packet from being 210 forwarded beyond the LSR that provides the service. To avoid this 211 problem, the originator of the "echo request" must remove those 212 service labels from the stack upto the tunnel that is being currently 213 traced. In other words the ingress must remove all service-labels 214 above the label of the tunnel being currently traced, but retain 215 service labels below it when sending the echo request. Note that 216 load balancing may affect the path when the service labels are 217 removed, resulting in a newer path being traversed. However this new 218 path is potentially different only upto the LSR that provides the 219 service. Since this portion of the path was traced when the tunnels 220 above this tunnel in the stack were traced and followed the exact 221 path as the source routed LSP, this should not be a major concern. 222 Sometimes the newer path may have a problem that was not in the 223 original path resulting in a false positive. In such a case the 224 original path can be traversed by changing the label stack to reach 225 the intermediate LSR with labels that route along each hop 226 explicitly. 228 7. Acknowledgements 230 The authors would like to thank TBD for their comments. 232 8. IANA Considerations 234 New Sub-Types for the FEC Stack TLV are required to be allocated. 236 9. Security Considerations 237 10. References 239 10.1. Normative References 241 [I-D.gredler-isis-label-advertisement] 242 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 243 "Advertising MPLS labels in IS-IS", draft-gredler-isis- 244 label-advertisement-03 (work in progress), May 2013. 246 [I-D.gredler-ospf-label-advertisement] 247 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 248 "Advertising MPLS labels in OSPF", draft-gredler-ospf- 249 label-advertisement-03 (work in progress), May 2013. 251 [I-D.gredler-rtgwg-igp-label-advertisement] 252 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 253 "Advertising MPLS labels in IGPs", draft-gredler-rtgwg- 254 igp-label-advertisement-05 (work in progress), May 2013. 256 [I-D.previdi-isis-segment-routing-extensions] 257 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., and 258 S. Litkowski, "IS-IS Extensions for Segment Routing", 259 draft-previdi-isis-segment-routing-extensions-03 (work in 260 progress), October 2013. 262 [I-D.psenak-ospf-segment-routing-extensions] 263 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 264 Shakir, R., and W. Henderickx, "OSPF Extensions for 265 Segment Routing", draft-psenak-ospf-segment-routing- 266 extensions-03 (work in progress), October 2013. 268 [OAM-UC] Google, "Google Blackbox Monitoring", 2012, . 272 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 273 RFC 792, September 1981. 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, March 1997. 278 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 279 Label Switched (MPLS) Data Plane Failures", RFC 4379, 280 February 2006. 282 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 283 Performing Label Switched Path Ping (LSP Ping) over MPLS 284 Tunnels", RFC 6424, November 2011. 286 10.2. Informative References 288 [I-D.filsfils-rtgwg-segment-routing-use-cases] 289 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 290 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 291 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 292 Crabbe, "Segment Routing Use Cases", draft-filsfils-rtgwg- 293 segment-routing-use-cases-02 (work in progress), October 294 2013. 296 [I-D.filsfils-rtgwg-segment-routing] 297 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 298 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 299 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 300 "Segment Routing Architecture", draft-filsfils-rtgwg- 301 segment-routing-01 (work in progress), October 2013. 303 [I-D.geib-spring-oam-usecase] 304 Geib, R., "Use case for a scalable and topology aware MPLS 305 data plane monitoring system", draft-geib-spring-oam- 306 usecase-00 (work in progress), October 2013. 308 Authors' Addresses 310 Sriganesh Kini (editor) 311 Ericsson 313 Email: sriganesh.kini@ericsson.com 315 Hannes Gredler 316 Juniper Networks 318 Email: hannes@juniper.net