idnits 2.17.1 draft-kumarkini-mpls-spring-lsp-ping-02.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 45 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3466 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: 'I-D.gredler-spring-mpls' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'RFC6291' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 607, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.gredler-spring-mpls' ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Work group N. Kumar 3 Internet-Draft G. Swallow 4 Intended status: Standards Track C. Pignataro 5 Expires: April 30, 2015 N. Akiya 6 Cisco Systems, Inc. 7 S. Kini 8 Ericsson 9 H. Gredler 10 Juniper Networks 11 M. Chen 12 Huawei 13 October 27, 2014 15 Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using 16 MPLS Dataplane 17 draft-kumarkini-mpls-spring-lsp-ping-02 19 Abstract 21 Segment Routing architecture leverages the source routing and 22 tunneling paradigms and can be directly applied to MPLS data plane. 23 A node steers a packet through a controlled set of instructions 24 called segments, by prepending the packet with Segment Routing 25 header. 27 The segment assignment and forwarding semantic nature of Segment 28 Routing raises additional consideration for connectivity verification 29 and fault isolation in LSP with Segment Routing architecture. This 30 document illustrates the problem and describe a mechanism to perform 31 LSP Ping and Traceroute on Segment Routing network over MPLS data 32 plane. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 30, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 69 3. Challenges with Existing mechanism . . . . . . . . . . . . . 3 70 3.1. Path validation in Segment Routing networks . . . . . . . 4 71 3.2. Service Label . . . . . . . . . . . . . . . . . . . . . . 5 72 4. Segment ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. IPv4 Prefix Node Segment ID . . . . . . . . . . . . . . . 5 74 4.2. IPv6 Prefix Node Segment ID . . . . . . . . . . . . . . . 6 75 4.3. IGP Adjacency Segment ID . . . . . . . . . . . . . . . . 7 76 5. Extension to Downstream Mapping TLV . . . . . . . . . . . . . 8 77 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 6.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 8 79 6.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 9 80 6.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 9 81 6.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 10 82 6.5. TTL Consideration for traceroute . . . . . . . . . . . . 10 83 7. Issues with non-forwarding labels . . . . . . . . . . . . . . 11 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 8.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 12 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 88 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . 12 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 91 12.2. Informative References . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 [I-D.filsfils-spring-segment-routing] introduces and explains Segment 97 Routing architecture that leverages the source routing and tunneling 98 paradigms. A node steers a packet through a controlled set of 99 instructions called segments, by prepending the packet with Segment 100 Routing header. A detailed definition about Segment Routing 101 architecture is available in [I-D.filsfils-spring-segment-routing] 102 and different use-cases are discussed in 103 [I-D.filsfils-spring-segment-routing-use-cases] 105 The Segment Routing architecture can be directly applied to MPLS data 106 plane in a way that, the Segment identifier (Segment ID) will be of 107 20-bits size and SR header is the label stack. 109 Multi Protocol Label Switching (MPLS) has defined in [RFC4379] a 110 simple and efficient mechanism to detect data plane failures in Label 111 Switched Paths (LSP) by specifying information to be carried in an 112 MPLS "echo request" and "echo reply" for the purposes of fault 113 detection and isolation, and mechanisms for reliably sending the echo 114 reply. The functionality is modeled after the ping/traceroute 115 paradigm (ICMP echo request [RFC0792]) and is typically referred to 116 as LSP ping and LSP traceroute. 118 Unlike LDP or RSVP which are the other well-known MPLS control plane 119 protocols, segment assignment in Segment Routing architecture is not 120 hop-by-hop basis. 122 This nature of Segment Routing raises additional consideration for 123 fault detection and isolation in Segment Routing network. This 124 document illustrates the problem and describe a mechanism to perform 125 LSP Ping and Traceroute on Segment Routing network over MPLS data 126 plane. 128 2. Requirements notation 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 3. Challenges with Existing mechanism 136 This document defines Target FEC Stack sub-TLVs and explains how they 137 can be used to tackle below challenges. 139 3.1. Path validation in Segment Routing networks 141 [RFC4379] defines the OAM machinery that helps with fault detection 142 and isolation in MPLS dataplane path with the use of various Target 143 FEC Stack Sub-TLV that are carried in MPLS Echo Request packets and 144 used by the responder for FEC validation. While it is obvious that 145 new Sub-TLVs need to be assigned, the unique nature of Segment 146 Routing architecture raises a need for additional machinery for path 147 validation. This section discuss the challenges as below: 149 L1 150 +--------+ 151 | L2 | 152 R3-------R6 153 / \ 154 / \ 155 R1----R2 R7----R8 156 \ / L3 157 \ / 158 R4-------R5 160 Figure 1: Segment Routing network 162 {5001, 5002, 5003, 5004, 5005, 5006, 5007, 5008} --> Node Segment ID for R1, R2, R3 R4, R5 R6, R7, R8 respectively. 164 9136 --> Adjacency Segment ID from R3 to R6 over link L1. 165 9236 --> Adjacency Segment ID from R3 to R6 over link L2. 167 The forwarding semantic of Adjacency Segment ID is to pop the segment 168 ID and send the packet to a specific neighbor over a specific link. 169 A malfunctioning node may forward packets using Adjacency Segment ID 170 to incorrect neighbor or over incorrect link. Exposed segment ID 171 (after incorrectly forwarded Adjacency Segment ID) might still allow 172 such packet to reach the intended destination, although the intended 173 strict traversal has been broken. 175 Assume in above topology, R1 sends traffic with segment stack as 176 {9124, 5007, 9378} so that the path taken will be R1-R2-R4-R5-R7-R8. 177 If the Adjacency Segment ID 9124 is misprogrammed in R2 to send the 178 packet to R1 or R3, it will still be delivered to R8 but is not via 179 the expected path. 181 MPLS traceroute may help with detecting such deviation in above 182 mentioned scenario. However, in a different example, it may not be 183 helpful if R3, due to misprogramming, forwards packet with Adjacency 184 Segment ID 9236 via link L1 while it is expected to be forwarded over 185 Link L2. 187 3.2. Service Label 189 A Segment ID can represent a service based instruction. An SR header 190 can have label stack entries where the label represents a service to 191 be applied along the path. Since these labels are part of the label 192 stack, they can influence the path taken by a packet and consequently 193 have implications on MPLS OAM. This document describes how the 194 procedures of [RFC4379] can be applied to in the absence of service- 195 labels in Section 6.5. Additional considerations for service labels 196 are included in Section 7 and requires further discussion. 198 4. Segment ID sub-TLV 200 The format of the following Segment ID sub-TLVs follows the 201 philosophy of Target FEC Stack TLV carrying FECs corresponding to 202 each label in the label stack. When operated with the procedures 203 defined in [RFC4379], this allows LSP ping/traceroute operations to 204 function when Target FEC Stack TLV contains more FECs than received 205 label stack at responder nodes. 207 Three new sub-TLVs are defined for TLVs type 1, 16 and 21. 209 sub-Type Value Field 210 -------- --------------- 211 TBD1 IPv4 Prefix Node Segment ID 212 TBD2 IPv6 Prefix Node Segment ID 213 TBD3 Adjacency Segment ID 215 Service Segments and FRR will be considered in future version. 217 4.1. IPv4 Prefix Node Segment ID 219 The format is as below: 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | IPv4 Prefix | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 |Prefix Length | Protocol | Reserved | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 IPv4 Prefix 231 This field carries the IPv4 prefix to which the Node Segment ID is 232 assigned. 234 Prefix Length 236 The Prefix Length field is one octet, it gives the length of the 237 prefix in bits (values can be 1 - 32). 239 Protocol 241 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is 242 ISIS. 244 4.2. IPv6 Prefix Node Segment ID 246 The format is as below: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | | 252 | IPv6 Prefix | 253 | | 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |Prefix Length | Protocol | Reserved | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 IPv6 Prefix 261 This field carries the IPv6 prefix to which the Node Segment ID is 262 assigned. 264 Prefix Length 266 The Prefix Length field is one octet, it gives the length of the 267 prefix in bits (values can be 1 - 128). 269 Protocol 271 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is 272 ISIS. 274 4.3. IGP Adjacency Segment ID 276 The format is as below: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Local Interface ID (4 or 16 octets) | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Remote Interface ID (4 or 16 octets) | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Protocol | Adj. Type | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 287 | Advertising Node Identifier | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Local Interface ID 292 An identifier that is assigned by local LSR for a link on which 293 Adjacency Segment ID is bound. This field is set to local link 294 address (IPv4 or IPv6). Incase of unnumbered, 32 bit link 295 identifier defined in [RFC4203], [RFC5307] is used. If the 296 Adjacency Segment ID represents parallel adjacencies 297 (Section 3.5.1 of [I-D.filsfils-spring-segment-routing]) this 298 field MUST be set to zero. 300 Remote Interface ID 302 An identifier that is assigned by remote LSR for a link on which 303 Adjacency Segment ID is bound. This field is set to remote 304 (downstream neighbor) link address (IPv4 or IPv6). In case of 305 unnumbered, 32 bit link identifier defined in [RFC4203], [RFC5307] 306 is used. If the Adjacency Segment ID represents parallel 307 adjacencies (Section 3.5.1 of 308 [I-D.filsfils-spring-segment-routing]) this field MUST be set to 309 zero. 311 Protocol 313 Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is ISIS 315 Adj. Type 317 Set to 4, if the Local/Remote Interface ID is of 4 octets and set 318 to 6 if the field is of 16 octets. 320 Advertising Node Identifier 321 Specifies the advertising node identifier. When Protocol is set 322 to 1, then the 32 rightmost bits represent OSPF Router ID and if 323 protocol is set to 2, this field carries 48 bit ISIS System ID. 325 5. Extension to Downstream Mapping TLV 327 In an echo reply, the Downstream Mapping TLV [RFC4379] is used to 328 report for each interface over which a FEC could be forwarded. For a 329 FEC, there are multiple protocols that may be used to distribute 330 label mapping. The "Protocol" field of the Downstream Mapping TLV is 331 used to return the protocol that is used to distribute a specific a 332 label. The following protocols are defined in section 3.2 of 333 [RFC4379]: 335 Protocol # Signaling Protocol 336 ---------- ------------------ 337 0 Unknown 338 1 Static 339 2 BGP 340 3 LDP 341 4 RSVP-TE 343 With segment routing, OSPF or ISIS can be used for label 344 distribution, this document adds two new protocols as follows: 346 Protocol # Signaling Protocol 347 ---------- ------------------ 348 5 OSPF 349 6 ISIS 351 6. Procedures 353 This section describes aspects of LSP Ping and traceroute operations 354 that require further considerations beyond [RFC4379]. 356 6.1. FECs in Target FEC Stack TLV 358 When LSP echo request packets are generated by an initiator, FECs 359 carried in Target FEC Stack TLV may need to or desire to have 360 deviating contents. This document outlines expected Target FEC Stack 361 TLV construction mechanics by initiator for known scenarios. 363 Ping 365 Initiator MUST include FEC(s) corresponding to the destination 366 segment. 368 Initiator MAY include FECs corresponding to some or all of 369 segments imposed in the label stack by the initiator to 370 communicate the segments traversed. 372 Traceroute 374 Initiator MUST initially include FECs corresponding to all of 375 segments imposed in the label stack. 377 When a received echo reply contains FEC Stack Change TLV with 378 one or more of original segment(s) being popped, initiator MAY 379 remove corresponding FEC(s) from Target FEC Stack TLV in the 380 next (TTL+1) traceroute request. 382 When a received echo reply does not contain FEC Stack Change 383 TLV, initiator MUST NOT attempt to remove FEC(s) from Target 384 FEC Stack TLV in the next (TTL+1) traceroute request. Note 385 that Downstream Label field of DSMAP/DDMAP contains hints on 386 how initiator may be able to update the contents of next Target 387 FEC Stack TLV. However, such hints are ambiguous without full 388 understanding of PHP capabilities. 390 6.2. FEC Stack Change sub-TLV 392 Section 3.3.1.3 of [RFC6424] defines a new sub-TLV that a router must 393 include when the FEC stack changes. 395 The network node which advertised the Node Segment ID is responsible 396 for generating FEC Stack Change sub-TLV of &pop& operation for Node 397 Segment ID, regardless of if PHP is enabled or not. 399 The network node that is immediate downstream of the node which 400 advertised the Adjacency Segment ID is responsible for generating FEC 401 Stack Change sub-TLV of &pop& operation for Adjacency Segment ID. 403 6.3. Segment ID POP Operation 405 The forwarding semantic of Node Segment ID with PHP flag is 406 equivalent to usage of implicit Null in MPLS protocols. Adjacency 407 Segment ID is also similar in a sense that it can be thought as next 408 hop destined locally allocated segment that has PHP enabled. 409 Procedures described in Section 4.4 of [RFC4379] relies on Stack-D 410 and Stack-R explicitly having Implicit Null value. It may simplify 411 implementations to reuse Implicit Null for Node Segment ID PHP and 412 Adjacency Segment ID cases. However, it is technically incorrect for 413 Implicit Null value to externally appear. Therefore, implicit Null 414 MUST NOT be placed in Stack-D and Interface and Label Stack TLV for 415 Node Segment ID PHP and Adjacency Segment ID cases. 417 6.4. Segment ID Check 419 If the Target FEC Stack Sub-TLV at FEC-stack-depth is TBD1 (IPv4 420 Prefix Node Segment ID), the responder SHOULD set Best return code 421 to (error code TBD) if any below conditions fail: 423 * Validate that Node Segment ID is advertised for IPv4 Prefix. 425 * Validate that Node Segment ID is advertisement of PHP bit. 427 * To be Updated 429 If the Target FEC Sub-TLV at FEC-stack-depth is TBD2 (IPv6 Prefix 430 Node Segment ID), set Best return code to (error code TBD) if any 431 below conditions fail: 433 * Validate that Node Segment ID is advertised for IPv6 Prefix. 435 * Validate that Node Segment ID is advertised of PHP bit. 437 * To be Updated 439 If the Target FEC sub-TLV at FEC-stack-depth is TBD3 (Adjacency 440 Segment ID), set Best return code to (error code TBD) if any below 441 conditions fail: 443 * Validate that Remote Interface ID matches the local identifier 444 of the interface on which the packet was received. 446 * Validate that IGP Adjacency Segment ID is advertised by 447 Advertising Node Identifier of Protocol in local IGP database. 449 6.5. TTL Consideration for traceroute 451 LSP Traceroute operation can properly traverse every hop of Segment 452 Routing network in Uniform Model described in [RFC3443]. If one or 453 more LSRs employ Short Pipe Model described in [RFC3443], then LSP 454 Traceroute may not be able to properly traverse every hop of Segment 455 Routing network due to absence of TTL copy operation when outer label 456 is popped. In such scenario, following TTL manipulation technique 457 MAY be used. 459 When tracing a LSP according to the procedures in [RFC4379] the TTL 460 is incremented by one in order to trace the path sequentially along 461 the LSP. However when a source routed LSP has to be traced there are 462 as many TTLs as there are labels in the stack. The LSR that 463 initiates the traceroute SHOULD start by setting the TTL to 1 for the 464 tunnel in the LSP's label stack it wants to start the tracing from, 465 the TTL of all outer labels in the stack to the max value, and the 466 TTL of all the inner labels in the stack to zero. Thus a typical 467 start to the traceroute would have a TTL of 1 for the outermost label 468 and all the inner labels would have TTL 0. If the FEC Stack TLV is 469 included it should contain only those for the inner stacked tunnels. 470 The lack of an echo response or the Return Code/Subcode should be 471 used to diagnose the tunnel as described in [RFC4379]. When the 472 tracing of a tunnel in the stack is complete, then the next tunnel in 473 the stack should be traced. The end of a tunnel can be detected from 474 the "Return Code" when it indicates that the responding LSR is an 475 egress for the stack at depth 1. Thus the traceroute procedures in 476 [RFC4379] can be recursively applied to traceroute a source routed 477 LSP. 479 7. Issues with non-forwarding labels 481 Source stacking can be optionally used to apply services on the 482 packet at a LSR along the path, where a label in the stack is used to 483 trigger service application. A data plane failure detection and 484 isolation mechanism should provide its functionality without applying 485 these services. This is mandatory for services that are stateful, 486 though for stateless services [RFC4379] could be used as-is. It MAY 487 also provide a mechanism to detect and isolate faults within the 488 service function itself. 490 To prevent services from being applied to an "echo request" packet, 491 the TTL of service labels MUST be 0. However TTL processing rules of 492 a service label must be the same as any MPLS label. Due to this a 493 TTL of 0 in the service label would prevent the packet from being 494 forwarded beyond the LSR that provides the service. To avoid this 495 problem, the originator of the "echo request" MUST NOT include the 496 service label in the label stack of an echo request above the tunnel 497 label of the tunnel that is being currently traced. In other words 498 the ingress must remove all service-labels above the label of the 499 tunnel being currently traced, but retain service labels below it 500 when sending the echo request. Note that load balancing may affect 501 the path when the service labels are removed, resulting in a newer 502 path being traversed. However this new path is potentially different 503 only up to the LSR that provides the service. Since this portion of 504 the path was traced when the tunnels above this tunnel in the stack 505 were traced and followed the exact path as the source routed LSP, 506 this should not be a major concern. Sometimes the newer path may 507 have a problem that was not in the original path resulting in a false 508 positive. In such a case the original path can be traversed by 509 changing the label stack to reach the intermediate LSR with labels 510 that route along each hop explicitly. 512 8. IANA Considerations 514 8.1. New Target FEC Stack Sub-TLVs 516 IANA is requested to assign 3 new Sub-TLVs from "Sub-TLVs for TLV 517 Types 1, 16 and 21" sub-registry. 519 Sub-Type Sub-TLV Name Reference 520 ---------- ----------------- ------------ 521 TBD1 IPv4 Prefix Node Segment ID Section 4.1 (this document) 522 TBD2 IPv6 Prefix Node Segment ID Section 4.2 (this document) 523 TBD3 Adjacency Segment ID Section 4.3 (this document) 525 9. Security Considerations 527 This document defines additional Sub-TLVs and follows the mechanism 528 defined in [RFC4379]. So all the security consideration defined in 529 [RFC4379] will be applicable for this document and in addition it 530 does not impose any security challenges to be considered. 532 10. Acknowledgement 534 The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji 535 Rajagopalan and Harish Sitaraman for their review and comments. 537 The authors wold like to thank Loa Andersson for his comments and 538 recommendation to merge drafts. 540 11. Contributing Authors 542 Tarek Saad 543 Cisco Systems 544 Email: tsaad@cisco.com 546 Siva Sivabalan 547 Cisco Systems 548 Email: msiva@cisco.com 550 12. References 552 12.1. Normative References 554 [I-D.filsfils-spring-segment-routing] 555 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 556 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 557 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 558 "Segment Routing Architecture", draft-filsfils-spring- 559 segment-routing-04 (work in progress), July 2014. 561 [I-D.filsfils-spring-segment-routing-use-cases] 562 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 563 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 564 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 565 Crabbe, "Segment Routing Use Cases", draft-filsfils- 566 spring-segment-routing-use-cases-01 (work in progress), 567 October 2014. 569 [I-D.gredler-spring-mpls] 570 Gredler, H., Rekhter, Y., Jalil, L., Kini, S., and X. Xu, 571 "Supporting Source/Explicitly Routed Tunnels via Stacked 572 LSPs", draft-gredler-spring-mpls-06 (work in progress), 573 May 2014. 575 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 576 RFC 792, September 1981. 578 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 579 Requirement Levels", BCP 14, RFC 2119, March 1997. 581 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 582 in Multi-Protocol Label Switching (MPLS) Networks", RFC 583 3443, January 2003. 585 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support 586 of Generalized Multi-Protocol Label Switching (GMPLS)", 587 RFC 4203, October 2005. 589 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 590 Label Switched (MPLS) Data Plane Failures", RFC 4379, 591 February 2006. 593 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 594 of Generalized Multi-Protocol Label Switching (GMPLS)", 595 RFC 5307, October 2008. 597 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 598 Performing Label Switched Path Ping (LSP Ping) over MPLS 599 Tunnels", RFC 6424, November 2011. 601 12.2. Informative References 603 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 604 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 605 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 607 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 608 S., and T. Nadeau, "Detecting Data-Plane Failures in 609 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 610 6425, November 2011. 612 Authors' Addresses 614 Nagendra Kumar 615 Cisco Systems, Inc. 616 7200 Kit Creek Road 617 Research Triangle Park, NC 27709 618 US 620 Email: naikumar@cisco.com 622 George Swallow 623 Cisco Systems, Inc. 624 1414 Massachusetts Ave 625 Boxborough, MA 01719 626 US 628 Email: swallow@cisco.com 630 Carlos Pignataro 631 Cisco Systems, Inc. 632 7200 Kit Creek Road 633 Research Triangle Park, NC 27709-4987 634 US 636 Email: cpignata@cisco.com 638 Nobo Akiya 639 Cisco Systems, Inc. 640 2000 Innovation Drive 641 Kanata, ON K2K 3E8 642 Canada 644 Email: nobo@cisco.com 646 Sriganesh Kini 647 Ericsson 649 Email: sriganesh.kini@ericsson.com 650 Hannes Gredler 651 Juniper Networks 653 Email: hannes@juniper.net 655 Mach(Guoyi) Chen 656 Huawei 658 Email: mach.chen@huawei.com