idnits 2.17.1 draft-nitinb-lsp-ping-over-mpls-tunnel-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 751. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 762. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 775. 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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In inter-AS (autonomous system) scenarios, information regarding the LSP FEC change(s) SHOULD not be passed across domains. A NIL FEC MAY be used to make the trace go through without false positives. An ASBR (autonomous system border router) may choose to intercept all echo requests and echo responses and change them to hide FEC information from other domains. Detailed operation regarding the same is outside the scope of this document. Passing of FEC change information between domains MAY be done if the two AS domains belong to the same provider/organization. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 15, 2007) is 6007 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) ** Obsolete normative reference: RFC 4379 (ref. '1') (Obsoleted by RFC 8029) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-upstream-label-03 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Bahadur, Ed. 3 Internet-Draft K. Kompella, Ed. 4 Updates: RFC4379 Juniper Networks, Inc. 5 (if approved) G. Swallow, Ed. 6 Intended status: Standards Track Cisco Systems 7 Expires: May 18, 2008 November 15, 2007 9 Mechanism for performing LSP-Ping over MPLS tunnels 10 draft-nitinb-lsp-ping-over-mpls-tunnel-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 18, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes methods for performing lsp-ping traceroute 44 over mpls tunnels. The techniques outlined in RFC 4379 fail to 45 perform correct traceroute validation and path discovery for a LSP 46 that goes over other mpls tunnels. This document describes new 47 procedures that can be used in conjunction with the standard 48 procedures described in RFC 4379 to trace such LSPs. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Conventions used in this document . . . . . . . . . . . . 3 54 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Packet format . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Downstream Detailed Mapping TLV . . . . . . . . . . . . . 5 58 3.2.1. Multipath data sub-TLV . . . . . . . . . . . . . . . . 6 59 3.2.2. Label stack sub-TLV . . . . . . . . . . . . . . . . . 7 60 3.2.3. Stack change sub-TLV . . . . . . . . . . . . . . . . . 7 61 3.3. Deprecation of Downstream Mapping TLV . . . . . . . . . . 9 62 4. Performing lsp-ping traceroute on tunnels . . . . . . . . . . 9 63 4.1. Transit node procedure . . . . . . . . . . . . . . . . . . 10 64 4.1.1. Addition of a new tunnel . . . . . . . . . . . . . . . 10 65 4.1.2. Transition between tunnels . . . . . . . . . . . . . . 10 66 4.2. Ingress node procedure . . . . . . . . . . . . . . . . . . 12 67 4.2.1. Processing Downstream Detailed Mapping TLV . . . . . . 12 68 4.2.1.1. Stack Change sub-TLV not present . . . . . . . . . 12 69 4.2.1.2. Stack Change sub-TLV(s) present . . . . . . . . . 12 70 4.2.2. Modifications to handling to EGRESS_OK responses. . . 15 71 4.3. Handling deprecated Downstream Mapping TLV . . . . . . . . 15 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 79 Intellectual Property and Copyright Statements . . . . . . . . . . 19 81 1. Introduction 83 This documents describes methods for performing lsp-ping traceroute 84 over mpls tunnels. The techniques outlined in [1] outline a 85 traceroute mechanism that includes FEC validation and ECMP path 86 discovery. Those mechanisms are insufficient and do not provide 87 details in case the FEC being traced traverses one or more mpls 88 tunnels. This document uses the existing definitions of [1] to 89 define a mechanism using which a traceroute request can correctly 90 traverse mpls tunnels with proper FEC and label validations. 92 1.1. Conventions used in this document 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 [2]. 98 2. Motivation 100 A LSP-Ping traceroute may cross multiple mpls tunnels en-route the 101 destination. Let us consider a simple case. 103 A B C D E 104 o -------- o -------- o --------- o --------- o 105 \_____/ | \______/ \______/ | \______/ 106 LDP | RSVP RSVP | LDP 107 | | 108 \____________________/ 109 LDP 111 Figure 1: LDP over RSVP tunnel 113 When a traceroute is initiated from router A, router B returns 114 downstream mapping information for node C in the echo-response. The 115 next echo request reaches router C with a LDP FEC. Node C is a pure 116 RSVP node and does not run LDP. Node C will receive the packet with 117 2 labels but only 1 FEC in the Target FEC stack. Consequently, node 118 C will be unable to perform FEC complete validation. It will let the 119 trace continue by just providing next-hop information based on 120 incoming label, and by looking up the forwarding state associated 121 with that label. However, ignoring FEC validation defeats the 122 purpose of control plane validatations. The echo request should 123 contain sufficient information to allow node C to perform FEC 124 validations to catch any misrouted echo-requests. 126 The above problem can be extended for a generic case of tunnel over 127 tunnel or multiple tunnels (e.g. B-C can be a separate RSVP tunnel 128 and C-D can be a separate RSVP tunnel). The problem of FEC 129 validation for tunnels can be solved if the transit routers (router B 130 in the above example) provide some hint or information to the ingress 131 regarding the start of a new tunnel. 133 Stitched LSPs involve 2 or more LSP segments stitched together. The 134 LSP segments can be signaled using the same or different signaling 135 protocols. In order to perform an end-to-end trace of a stitched 136 LSP, the ingress needs to know FEC information regarding each of the 137 stitched LSP segments. For example, conside the figure below. 139 A B C D E F 140 o -------- o -------- o --------- o -------- o ------- o 141 \_____/ \______/ \______/ \______/ \_______/ 142 LDP LDP BGP RSVP RSVP 144 Figure 2: Stitched LSP 146 Consider ingress (A) tracing end-to-end LSP A--F. When an echo 147 request reaches router C, there is a FEC change happening at router 148 C. With current lsp-ping mechanisms, there is no way to convey this 149 information to A. Consequently, when the next echo request reaches 150 router D, router D will know nothing about the LDP FEC that A is 151 trying to trace. 153 Thus, the procedures outlined [1] do not make it possible for the 154 ingress node to: 156 1. Know that tunneling has occured 157 2. Trace the path of the tunnel 158 3. Trace the path of stitched LSPs 160 3. Packet format 162 3.1. Introduction 164 In many cases there has been a need to associate additional data in 165 the lsping echo response. In most cases, the additional data needs 166 to be associated on a per downstream neighbor basis. Currently, the 167 echo response contains 1 downstream map TLV (DSMAP) per downstream 168 neighbor. But the DSMAP format is not extensible and hence it's not 169 possible to associate more information with a downstream neighbor. 170 This draft defines a new extensible format for the DSMAP and provides 171 mechanisms for solving the tunneled lsp-ping problem using the new 172 format. In summary, the draft makes the following tlv changes: 174 o Addition of new Downstream Detailed Mapping TLV (DDMAP). 175 o Deprecation of existing Downstream Mapping TLV. 176 o Addition of Downstream FEC Stack Change Sub-TLV to DDMAP. 178 3.2. Downstream Detailed Mapping TLV 180 A new TLV has been added to the mandatory range of TLVs. The TLV 181 type is pending IANA allocation. 183 Type # Value Field 184 ------ ------------ 186 TBD Downstream detailed mapping 188 Figure 3 190 The Downstream Detailed Mapping object is a TLV that MAY be included 191 in an echo request message. Only one Downstream Detailed Mapping 192 object may appear in an echo request. The presence of a Downstream 193 Mapping object is a request that Downstream Detailed Mapping objects 194 be included in the echo reply. If the replying router is the 195 destination of the FEC, then a Downstream Detailed Mapping TLV SHOULD 196 NOT be included in the echo reply. Otherwise the replying router 197 SHOULD include a Downstream Detailed Mapping object for each 198 interface over which this FEC could be forwarded. 200 0 1 2 3 201 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 2 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | MTU | Address Type | DS Flags | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Downstream IP Address (4 or 16 octets) | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Downstream Interface Address (4 or 16 octets) | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Sub-tlv length | Reserved | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 . . 212 . List of Sub TLVs . 213 . . 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 4: Downstream Detailed Mapping TLV 217 The Downstream Detailed Mapping TLV format is derived from the 218 Downstream Mapping TLV format. The key change is that variable 219 length and optional fields have been coverted into sub-TLVs. The 220 fields have the same use and meaning as in [1]. The newly added sub- 221 TLVs and their fields are as described below. 223 Sub-tlv length 224 Total length in bytes of the sub-tlvs associated with this TLV. 226 Sub-Type Value Field 227 --------- ------------ 228 TBD Multipath data 229 TBD Label stack 230 TBD FEC Stack change 232 Figure 5: Downstream Detailed Mapping Sub-TLV List 234 3.2.1. Multipath data sub-TLV 236 0 1 2 3 237 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 2 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 |Multipath Type | Multipath Length |Reserved (MBZ) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 | (Multipath Information) | 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 6: Multipath Sub-TLV 248 The multipath data sub-TLV includes information multipath 249 information. The TLV fields and their usage is as defined in [1]. 251 3.2.2. Label stack sub-TLV 253 0 1 2 3 254 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 2 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Downstream Label | Protocol | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 . . 259 . . 260 . . 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Downstream Label | Protocol | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 7: Label Stack Sub-TLV 267 The Label stack sub-TLV contains the set of labels in the label stack 268 as it would have appeared if this router were forwarding the packet 269 through this interface. Any Implicit Null labels are explicitly 270 included. The number of labels present in the sub-TLV is determined 271 based on the sub-TLV data length. Labels are treated as numbers, 272 i.e., they are right justified in the field. The label format and 273 protocol type are as defined in [1]. When the Detailed Downstream 274 Mapping TLV in sent in the echo response, this sub-TLV MUST be 275 included. 277 3.2.3. Stack change sub-TLV 279 A router SHOULD include the the FEC Stack change sub-TLV when the 280 downstream node in the echo response has a different FEC stack than 281 the FEC stack received in the echo request. One ore more FEC Stack 282 change sub-TLVs MAY be present in the Downstream Detailed Mapping 283 TLV. The format is as below. 285 0 1 2 3 286 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 2 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |Operation Type | Address type | FEC-tlv length| Reserved | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Remote Peer Address (0, 4 or 16 octets) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 . . 293 . FEC TLV . 294 . . 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 8: Stack Change Sub-TLV 298 Operation Type 300 The operation type specifies the action associated with the FEC 301 change. The following operation types are defined. 303 Type # Operation 304 ------ --------- 305 1 Push 306 2 Pop 308 Operation Type Values 310 A FEC Stack change sub-TLV containing a PUSH operation MUST NOT be 311 followed by a FEC Stack change sub-TLV containing a POP operation. 312 One or more POP operations MAY be followed by one or more PUSH 313 operations. One FEC Stack change sub-TLV MUST be included per FEC 314 change. For example, if 2 labels are going to be pushed, then 1 315 FEC change sub-TLV MUST be included for each FEC. A FEC Swap 316 operation is to be simulated by including a POP type FEC change 317 sub-TLV followed by a PUSH type FEC change sub-TLV. 318 A Downstream detailed mapping TLV containing only 1 FEC change 319 sub-TLV with Pop operation is equivalent to EGRESS_OK for the 320 outermost FEC in the FEC stack. The ingress router performing the 321 lsp trace MUST treat such a case as an EGRESS_OK for the outermost 322 FEC. 324 FEC tlv Length 326 Length in bytes of the FEC TLV. 328 Address Type 330 The Address Type indicates the remote peer's address type. The 331 Address Type is set to one of the following values. The peer 332 address length is determined based on the address type. The 333 address type MAY be different from the address type included in 334 the Downstream Detailed Mapping TLV. This can happen in case the 335 LSP goes over a tunnel of a different address family. The address 336 type MAY be set to Unspecified if the peer-address is either 337 unavailable or the transit router does not wish it provide it for 338 security or administrative reasons. 340 Type # Address Type Address length 341 ------ ------------ -------------- 343 0 Unspecified 0 344 1 IPv4 4 345 2 IPv6 16 347 Figure 10: Remote peer address type 349 Remote peer address 351 The remote peer address specifies the remote peer which is the 352 next-hop for the FEC being currently traced. E.g. In the LDP 353 over RSVP case Figure 1, router B would respond back with the 354 address of router D as the remote peer address for the LDP FEC 355 being traced. This allows the ingress node to provide helpful 356 information regarding FEC peers. If the operation type is PUSH, 357 the remote peer address is the address of the peer from which the 358 FEC was learned. If the operation type is POP, the remote peer 359 address MAY not be set to Unspecified. For upstream assigned 360 labels [3], an operation type of POP will have a remote peer 361 address (the upstream node that assigned the label) and this 362 SHOULD be included in the FEC change sub-TLV. 364 FEC TLV 365 The FEC TLV is present only when FEC-tlv length field is non-zero. 366 The FEC TLV specifies the FEC associated with the FEC stack change 367 operation. This TLV MAY be included when the operation type is 368 POP. It SHOULD be included when the operation type is PUSH. The 369 FEC TLV contains exactly 1 FEC from the list of FECs specified in 370 [1]. A NIL FEC MAY be associated with a PUSH operation if the 371 responding router wishes to hide the details of the FEC being 372 pushed. 374 3.3. Deprecation of Downstream Mapping TLV 376 The Downstream Mapping TLV has been deprecated. LSP-ping procedures 377 should now use the Downstream Detailed Mapping TLV. Detailed 378 procedures regarding interoperability between the deprecatd TLV and 379 the new tlv are specified in Section 4.3. 381 4. Performing lsp-ping traceroute on tunnels 383 This section describes the procedures to be followed by an ingress 384 node and transit nodes when performing lsp-ping traceroute over mpls 385 tunnels. 387 4.1. Transit node procedure 389 4.1.1. Addition of a new tunnel 391 A transit node (Figure 1) knows when that the FEC being traced is 392 going to enter a tunnel at that node. Thus, it knows about the new 393 outer FEC. All transit nodes that are the origination point of a new 394 tunnel SHOULD add the a FEC Stack change sub-TLV (Section 3.2.3) to 395 the Downstream Detailed Mapping TLV Figure 4 in the echo-response. 396 The transit node SHOULD add 1 FEC Stack change sub-TLV of operation 397 type PUSH, per new tunnel being originated at the transit node. 399 A transit node that sends a Downstream FEC Stack change sub-TLV in 400 the echo response SHOULD fill the address of the remote peer; which 401 is the peer of the current LSP being traced. If the transit node 402 does not know the address of the remote peer, it MAY leave it as 403 unspecified. 405 If the transit node wishes to hide the nature of the tunnel from the 406 ingress of the echo-request, then it MAY not want to send details 407 about the new tunnel FEC to the ingress. In such a case, the transit 408 node SHOULD use the NIL FEC. The echo response would then contain a 409 FEC Stack change sub-TLV with operation type PUSH and a NIL FEC. The 410 value of the label in the NIL FEC MUST be set to zero. The remote 411 peer address length MUST be set to 0 and the remote peer address type 412 MUST be set to Unspecified. The transit node SHOULD add 1 FEC Stack 413 change sub-TLVs of operation type PUSH, per new tunnel being 414 originated at the transit node. 416 4.1.2. Transition between tunnels 418 A B C D E F 419 o -------- o -------- o --------- o -------- o ------- o 420 \_____/ \______/ \______/ \______/ \_______/ 421 LDP LDP BGP RSVP RSVP 423 Figure 11: Stitched LSPs 425 In the above figure, we have 3 seperate LSP segments stitched at C 426 and D. Node C SHOULD include 2 FEC Stack change sub-TLVs. One with a 427 POP operation for the LDP FEC and one for the PUSH operation for the 428 BGP FEC. Similarly, node D SHOULD include 2 FEC Stack change sub- 429 TLVs, one with a POP operation for the BGP FEC and one with a PUSH 430 operation for the RSVP FEC. 432 If node C wishes to perform FEC hiding, it SHOULD respond back with 2 433 FEC Stack change sub-TLVs. One POP followed by 1 PUSH. The POP 434 operation MAY either not include the FEC TLV (by setting FEC-tlv 435 length to 0) or set the FEC TLV to contain the LDP FEC. The PUSH 436 operation SHOULD have the FEC TLV contain the NIL FEC. 438 If node C performs FEC hiding and node D also performs FEC hiding, 439 then node D MAY choose to not send any FEC change sub-TLVs in the 440 echo response since the number of labels has not changed (for the 441 downstream of node D) and the FEC type also has not changed (NIL 442 FEC). If node D performs FEC hiding, then node F will respond as 443 EGRESS_OK for the NIL FEC. The ingress (node A) will know that 444 EGRESS_OK corresponds to the end-to-end LSP. 446 A B C D E F 447 o -------- o -------- o --------- o --------- o --------- o 448 \_____/ | \___________________/ |\_______/ 449 LDP |\ RSVP-A | LDP 450 | \_______________________________/| 451 | RSVP-B | 452 \________________________________/ 453 LDP 455 Figure 12: Hierarchical LSPs 457 In the above figure, the following sequence of FEC change sub-TLVs 458 will be performed 460 Node B: 462 Respond with 2 FEC change sub-TLVs: Push RSVP-B, Push RSVP-A. 464 Node D: 466 Respond with EGRESS_OK when RSVP-A is top of FEC stack. Downstream 467 information for node E when echo request contains RSVP-B as top of 468 FEC stack. 470 If node B is performing tunnel hiding, then: 472 Node B: 474 Respond with 2 FEC change sub-TLVs: PUSH NIL-FEC, PUSH NIL-FEC. 476 Node D: 478 Respond with either EGRESS_OK (if D can co-relate that the NIL-FEC 479 corresponds to RSVP-A which is terminating at D) or respond with FEC 480 change sub-TLV: POP (since D knows that number of labels towards 481 next-hop is decreasing). 483 A B C D E F G 484 o -------- o -------- o ------ o ------ o ----- o ----- o 485 LDP LDP BGP \ RSVP RSVP / LDP 486 \_____________/ 487 LDP 489 Figure 13: Stitched hierarchical LSPs 491 In the above case, node D will send 3 FEC change sub-TLVs. One POP 492 (for the BGP FEC) followed by 2 PUSHes (one for LDP and one for 493 RSVP). 495 4.2. Ingress node procedure 497 It is the responsibility of an ingress node to understand tunnel 498 within tunnel semantics and lsp stitching semantics when performing a 499 lsp traceroute. This section describes the ingress node procedure 500 based on the kind of response an ingress node receives from a transit 501 node. 503 4.2.1. Processing Downstream Detailed Mapping TLV 505 Downstream Detailed Mapping TLV should be processed in procedures 506 similar to those of Downstream Mapping TLV, defined in Section 4.4 of 507 [1] 509 4.2.1.1. Stack Change sub-TLV not present 511 This would be the default behavior as described in [1]. The ingress 512 node MUST perform echo response processing as per the procedures in 513 [1]. 515 4.2.1.2. Stack Change sub-TLV(s) present 517 If one or more FEC Stack change sub-TLVs (Section 3.2.3) are received 518 in the echo response, the ingress node SHOULD process them and 519 perform some validation. 521 The FEC stack changes are associated with a downstream neighbor and 522 along a particular path of the LSP. Consequently, the ingress will 523 need to maintain a FEC-stack per path being traced (in case of 524 multipath). All changes to the FEC stack resulting from the 525 processing of FEC Stack change sub-TLV(s) should be applied only for 526 the path along a given downstream neighbor. The following algorithm 527 should be followed for processing FEC Stack change sub-TLVs. 529 push_seen = FALSE 530 fec_stack_depth = current-depth-of-fec-stack-being-traced 531 saved_fec_stack = current_fec_stack 533 while (sub-tlv = get_next_sub_tlv(downstream_detailed_map_tlv)) 535 if (sub-tlv == NULL) break 537 if (sub-tlv.type == FEC-Stack-Change) { 539 if (sub-tlv.operation == POP) { 540 if (push_seen) { 541 Drop the echo response 542 current_fec_stack = saved_fec_stack 543 return 544 } 546 if (fec_stack_depth == 0) { 547 Drop the echo response 548 current_fec_stack = saved_fec_stack 549 return 550 } 552 Pop FEC from FEC stack being traced 553 fec_stack_depth--; 554 } 556 if (sub-tlv.operation == PUSH) { 557 push_seen = 1 558 Push FEC on FEC stack being traced 559 fec_stack_depth++; 560 } 561 } 562 } 564 if (fec_stack_depth == 0) { 565 Drop the echo response 566 current_fec_stack = saved_fec_stack 567 return 568 } 570 Figure 14: FEC Stack Change Sub-TLV Processing Guideline 572 The next echo request along the same path should use the modified FEC 573 stack obtained after processing the FEC Stack change sub-TLVs. A 574 non-NIL FEC guarantees that the next echo request along the same path 575 will have the Downstream Detailed Mapping TLV validated for IP 576 address, Interface address and label stack mismatches. 578 If the top of the FEC stack is a NIL FEC and the echo response does 579 not contain any FEC Stack change sub-TLV, then it does not 580 necessarily mean that the LSP has not started traversing a different 581 tunnel. It could be that the LSP associated with the NIL FEC 582 terminated at a transit node and at the same time a new LSP started 583 at the same transit node. The NIL FEC would now be associated with 584 the new LSP (and the ingress has no way of knowing this). Thus, it 585 is not possible to build an accurate hierarchical LSP topology if a 586 traceroute contains NIL FECs. 588 4.2.2. Modifications to handling to EGRESS_OK responses. 590 The procedures above allow the addition of new FECs to the original 591 FEC being traced. Consequently, the EGRESS_OK response from a 592 downstream node may not necessarily be for the FEC being traced. It 593 could be for one of the new FECs that was added. On receipt of an 594 EGRESS_OK response, the ingress should check if the Target FEC sent 595 to the node that just responded was the base FEC that was being 596 traced. If it was not, then it should pop the an entry from the 597 Target FEC stack and resend the request with the same TTL (as 598 previously sent). The process of popping a FEC is to be repeated 599 until either the ingress receives a non-EGRESS_OK response or until 600 all the additional FECs added to the FEC stack have already been 601 popped. Using EGRESS_OK responses, an ingress can build a map of the 602 hierarchical LSP structure traversed by a given FEC. 604 4.3. Handling deprecated Downstream Mapping TLV 606 The Downstream Mapping TLV has been deprecated. Applications should 607 now use the Downstream Detailed Mapping TLV. The following 608 procedures SHOULD be used for backward compatibility with routers 609 that do not support the Downstream Detailed Mapping TLV. 611 o The Downstream Mapping TLV and the Downstream Detailed Mapping TLV 612 MUST never be sent together in the same echo request or in the 613 same echo response. 614 o If the echo request contains a Downstream Detailed Mapping TLV and 615 the corresponding echo response contains an error code of 2 (one 616 or more of the TLVs was not understood), then the sender of the 617 echo request MAY resend the echo request with the Downstream 618 Mapping TLV (instead of the Downstream Detailed Mapping TLV). In 619 cases where the a detailed response is needed, the sender can 620 choose to ignore the router that does not support the Downstream 621 Detailed Mapping TLV. 623 o If the echo request contains a Downstream Mapping TLV, then a 624 Downstream Detailed Mapping TLV MUST NOT be sent in the echo 625 response. This is to handle the case that the sender of the echo 626 request does not support the new tlv. 627 o If echo request forwarding is in use; such that the echo request 628 is processed at an intermediate router and then forwarded on; then 629 the intermediate router is responsible for making sure that the 630 TLVs being used among the ingress, intermediate and destination 631 are consistent. The intermediate router MUST NOT forward an echo 632 request or an echo response containing a Downstream Detailed 633 Mapping TLV if it itself does not support that TLV. 635 5. Security Considerations 637 Tracing inside a tunnel might have some security implications. There 638 are different ways to prevent tracing tunnel details. 640 1. If one wants to prevent tracing inside a tunnel, one can hide the 641 outer MPLS tunnel by not propagating the MPLS TTL into the outer 642 tunnel (at the start of the outer tunnel). By doing this, lsp- 643 ping packets will not expire in the outer tunnel and the outer 644 tunnel will not get traced. TTL hiding can be imposed on a per 645 LSP basis as need be. 646 2. If one doesn't wish to expose the details of the new outer LSP, 647 then the NIL FEC can be used to hide those details. Using the 648 NIL FEC ensures that the trace progresses without false negatives 649 and all transit nodes (of the new outer tunnel) perform some 650 minimal validations on the received echo requests. 652 In inter-AS (autonomous system) scenarios, information regarding the 653 LSP FEC change(s) SHOULD not be passed across domains. A NIL FEC MAY 654 be used to make the trace go through without false positives. An 655 ASBR (autonomous system border router) may choose to intercept all 656 echo requests and echo responses and change them to hide FEC 657 information from other domains. Detailed operation regarding the 658 same is outside the scope of this document. Passing of FEC change 659 information between domains MAY be done if the two AS domains belong 660 to the same provider/organization. 662 Other security considerations, as discussed in [1] are also 663 applicable to this document. 665 6. IANA Considerations 667 This document introduces a new Downstream Detailed Mapping TLV. It 668 is requested that IANA assign a TLV type in the range of 0-32767 from 669 the TLV type registry created in [1]. 671 It is requested that IANA create a new registry for the Sub-Type 672 field of Downstream Detailed Mapping TLV. The valid range for this 673 is 0-65535. Assignments in the range 0-32767 are made via Standards 674 Action as defined in ; assignments in the range 32768-64511 are made 675 via Expert Review (see below); values in the range 64512-65535 are 676 for Vendor Private Use, and MUST NOT be allocated. If a sub-TLV has 677 a Type that falls in the range for Vendor Private Use, the Length 678 MUST be at least 4, and the first four octets MUST be that vendor's 679 SMI Enterprise Code, in network octet order. The rest of the Value 680 field is private to the vendor. 682 It is requested that IANA assign a sub-TLV types from the 0-32767 683 range for the sub-TLVs defined in Figure 5. 685 7. Acknowledgements 687 The authors would like to thank Yakov Rekhter and Adrian Farrel for 688 their suggestions on the draft. 690 8. References 692 8.1. Normative References 694 [1] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label 695 Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 697 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 698 Levels", BCP 14, RFC 2119, March 1997. 700 8.2. Informative References 702 [3] Aggarwal, R., "MPLS Upstream Label Assignment and Context- 703 Specific Label Space", draft-ietf-mpls-upstream-label-03 (work 704 in progress), November 2007. 706 Authors' Addresses 708 Nitin Bahadur (editor) 709 Juniper Networks, Inc. 710 1194 N. Mathilda Avenue 711 Sunnyvale, CA 94089 712 US 714 Phone: +1 408 745 2000 715 Email: nitinb@juniper.net 716 URI: www.juniper.net 718 Kireeti Kompella (editor) 719 Juniper Networks, Inc. 720 1194 N. Mathilda Avenue 721 Sunnyvale, CA 94089 722 US 724 Phone: +1 408 745 2000 725 Email: kireeti@juniper.net 726 URI: www.juniper.net 728 George Swallow (editor) 729 Cisco Systems 730 1414 Massachusetts Ave 731 Boxborough, MA 01719 732 US 734 Email: swallow@cisco.com 735 URI: www.cisco.com 737 Full Copyright Statement 739 Copyright (C) The IETF Trust (2007). 741 This document is subject to the rights, licenses and restrictions 742 contained in BCP 78, and except as set forth therein, the authors 743 retain all their rights. 745 This document and the information contained herein are provided on an 746 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 747 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 748 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 749 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 750 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 751 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 753 Intellectual Property 755 The IETF takes no position regarding the validity or scope of any 756 Intellectual Property Rights or other rights that might be claimed to 757 pertain to the implementation or use of the technology described in 758 this document or the extent to which any license under such rights 759 might or might not be available; nor does it represent that it has 760 made any independent effort to identify any such rights. Information 761 on the procedures with respect to rights in RFC documents can be 762 found in BCP 78 and BCP 79. 764 Copies of IPR disclosures made to the IETF Secretariat and any 765 assurances of licenses to be made available, or the result of an 766 attempt made to obtain a general license or permission for the use of 767 such proprietary rights by implementers or users of this 768 specification can be obtained from the IETF on-line IPR repository at 769 http://www.ietf.org/ipr. 771 The IETF invites any interested party to bring to its attention any 772 copyrights, patents or patent applications, or other proprietary 773 rights that may cover technology that may be required to implement 774 this standard. Please address the information to the IETF at 775 ietf-ipr@ietf.org. 777 Acknowledgment 779 Funding for the RFC Editor function is provided by the IETF 780 Administrative Support Activity (IASA).