idnits 2.17.1 draft-ietf-bfd-mpls-03.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 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 467. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 118 has weird spacing: '... may be assoc...' == Line 335 has weird spacing: '...ence of the f...' -- 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 (June 2006) is 6526 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) == Missing Reference: 'RFC2119' is mentioned on line 84, but not defined == Missing Reference: 'LSP-Ping' is mentioned on line 352, but not defined == Unused Reference: 'RFC' is defined on line 381, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-05 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-v4v6-1hop-05 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-09) exists of draft-ietf-bfd-multihop-04 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-vccv-09 -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-oam-msg-map-02 Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Aggarwal 3 Internet Draft Juniper Networks 4 Expiration Date: December 2006 5 K. Kompella 6 Juniper Networks 8 T. Nadeau 9 Cisco Systems, Inc. 11 G. Swallow 12 Cisco Systems, Inc. 14 June 2006 16 BFD For MPLS LSPs 18 draft-ietf-bfd-mpls-03.txt 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Abstract 45 One desirable application of Bi-directional Forwarding Detection 46 (BFD) is to detect a MPLS LSP data plane failure. LSP-Ping is an 47 existing mechanism for detecting MPLS data plane failures and for 48 verifying the MPLS LSP data plane against the control plane. BFD can 49 be used for the former, but not for the latter. However the control 50 plane processing required for BFD control packets is relatively 51 smaller than the processing required for LSP-Ping messages. A 52 combination of LSP-Ping and BFD can be used to provide faster data 53 plane failure detection and/or make it possible to provide such 54 detection on a greater number of LSPs. This document describes the 55 applicability of BFD in relation to LSP-Ping for this application. It 56 also describes procedures for using BFD in this environment. 58 Table of Contents 60 1 Specification of requirements ......................... 3 61 2 Introduction .......................................... 3 62 3 Applicability ......................................... 3 63 3.1 BFD for MPLS LSPs: Motivation ......................... 3 64 3.2 Using BFD in Conjunction with LSP-Ping ................ 5 65 4 Theory of Operation ................................... 5 66 5 Initialization and Demultiplexing ..................... 6 67 6 Session Establishment ................................. 7 68 6.1 BFD Discriminator TLV in LSP-Ping ..................... 7 69 7 Encapsulation ......................................... 8 70 8 Security Considerations ............................... 9 71 9 IANA Considerations ................................... 9 72 10 Acknowledgments ....................................... 9 73 11 References ............................................ 9 74 11.1 Normative References .................................. 9 75 11.2 Informative References ................................ 10 76 12 Author Information .................................... 10 77 13 Intellectual Property Statement ....................... 11 78 14 Full Copyright Statement .............................. 12 79 1. Specification of requirements 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. Introduction 87 One desirable application of Bi-directional Forwarding Detection 88 (BFD) is to track the liveliness of a Multi Protocol Label Switched 89 (MPLS) Label Switched Path (LSP). In particular BFD can be used to 90 detect a data plane failure in the forwarding path of a MPLS LSP. 91 LSP-Ping [RFC4379] is an existing mechanism for detecting MPLS LSP 92 data plane failures and for verifying the MPLS LSP data plane against 93 the control plane. This document describes the applicability of BFD 94 in relation to LSP-Ping for detecting MPLS LSP data plane failures. 95 It also describes procedures for using BFD for detecting MPLS LSP 96 data plane failures. 98 3. Applicability 100 In the event of a MPLS LSP failing to deliver data traffic, it may 101 not always be possible to detect the failure using the MPLS control 102 plane. For instance the control plane of the MPLS LSP may be 103 functional while the data plane may be mis-forwarding or dropping 104 data. Hence there is a need for a mechanism to detect a data plane 105 failure in the MPLS LSP path [RFC4377]. 107 3.1. BFD for MPLS LSPs: Motivation 109 LSP-Ping described in [LSP-Ping] is an existing mechanism for 110 detecting a MPLS LSP data plane failure. In addition LSP-Ping also 111 provides a mechanism for verifying the MPLS control plane against the 112 data plane. This is done by ensuring that the LSP is mapped to the 113 same Forwarding Equivalence Class (FEC), at the egress, as the 114 ingress. 116 BFD cannot be used for verifying the MPLS control plane against the 117 data plane. However BFD can be used to detect a data plane failure 118 in the forwarding path of a MPLS LSP. The LSP may be associated with 119 any of the following FECs: 120 a) RSVP IPv4/IPv6 Session [RFC3209] 121 b) LDP IPv4/IPv6 prefix [RFC3036] 122 c) VPN IPv4/IPv6 prefix [RFC4364] 123 d) Layer 2 VPN [L2-VPN] 124 e) Layer 2 Circuit ID [RFC4447] 126 LSP-Ping includes extensive control plane verification. BFD on the 127 other hand was designed as a light-weight means of testing only the 128 data plane. As a result, LSP-Ping is computationally more expensive 129 than BFD for detecting MPLS LSP data plane faults. BFD is also more 130 suitable for being implemented in hardware or firmware due to its 131 fixed packet format. Thus the use of BFD for detecting MPLS LSP data 132 plane faults has the following advantages: 134 a) Support for fault detection for greater number of LSPs. 136 b) Fast detection. Detection with sub-second granularity is 137 considered as fast detection. LSP-Ping is intended to be used in an 138 environment where fault detection messages are exchanged, either for 139 diagnostic purposes or for infrequent periodic fault detection, in 140 the order of tens of seconds or minutes. Hence its not appropriate 141 for fast detection. BFD on the other hand is designed for sub-second 142 fault detection intervals. Following are some potential cases when 143 fast detection may be desirable for MPLS LSPs: 145 1. In the case of a bypass LSP used for facility based link or 146 node protection [RFC4090]. In this case the bypass LSP is essentially 147 being used as an alternate link to protect one or more LSPs. It 148 represents an aggregate and is used to carry data traffic belonging 149 to one or more LSPs, when the link or the node being protected fails. 150 Hence fast failure detection of the bypass LSP may be desirable 151 particularly in the event of link or node failure when the data 152 traffic is moved to the bypass LSP. 154 2. MPLS Pseudo Wires (PW). Fast detection may be desired for MPLS 155 PWs depending on i) the model used to layer the MPLS network with the 156 layer 2 network. and ii) the service that the PW is emulating. For a 157 non-overlay model between the layer 2 network and the MPLS network 158 the provider may rely on PW fault detection to provide service status 159 to the end-systems. Also in that case interworking scenarios such as 160 ATM/Frame Relay interworking may force periodic PW fault detection 161 messages. Depending on the requirements of the service that the MPLS 162 PW is emulating, fast failure detection may be desirable. Use of BFD 163 for PWs is further described in [VCCV] and [OAM-MAP]. 165 There may be other potential cases where fast failure detection is 166 desired for MPLS LSPs. 168 3.2. Using BFD in Conjunction with LSP-Ping 170 BFD can be used for MPLS LSP data plane fault detection. However it 171 does not have all the funcitonality of LSP-Ping. In paticular it 172 cannot be used for verifying the control plane against the data 173 plane. LSP Ping performs the following functions that are outside the 174 scope of BFD: 176 a) Association of a LSP-Ping echo request message with a FEC. In 177 the case of Penultimate Hop Popping (PHP), for a single label stack 178 LSP, the only way to associate a fault detection message with a FEC 179 is by carrying the FEC in the message. LSP-Ping provides this 180 functionality. Next-hop label allocation also makes it necessary to 181 carry the FEC in the fault detection message as the label alone is 182 not sufficient to identify the LSP being verified. In addition to 183 this presence of the FEC in the echo request message makes is 184 possible to verify the control plane against the data plane at the 185 egress LSR. 187 b) Equal cost multi-path (ECMP) considerations. LSP-Ping traceroute 188 makes it possible to probe multiple alternate paths for LDP IP FECs. 190 c) Traceroute. LSP-Ping supports traceroute for a FEC and it can be 191 used for fault isolation. 193 Hence BFD is used in conjunction with LSP-Ping for MPLS LSP fault 194 detection: 196 i) LSP-Ping is used for boot-strapping the BFD session as described 197 later in this document. 199 ii) BFD is used to exchange fault detection (i.e. BFD session) 200 packets at the required detection interval. 202 iii) LSP-Ping is used to periodically verify the control plane 203 against the data plane by ensuring that the LSP is mapped to the same 204 FEC, at the egress, as the ingress. 206 4. Theory of Operation 208 To use BFD for fault detection on a MPLS LSP a BFD session MUST be 209 established for that particular MPLS LSP. BFD control packets MUST be 210 sent along the same data path as the LSP being verified and are 211 processed by the BFD processing module of the egress LSR. If the LSP 212 is associated with multiple FECs, a BFD session SHOULD established 213 for each FEC. For instance this may happen in the case of next-hop 214 label allocation. Hence the operation is conceptually similar to the 215 data plane fault detection procedures of LSP-Ping. 217 If MPLS fast-reroute is being used for the MPLS LSP the use of BFD 218 for fault detection can result in false fault detections if the BFD 219 fault detection interval is less than the MPLS fast-reroute 220 switchover time. When MPLS fast-reroute is triggered because of a 221 link or node failure BFD control packets will be dropped until 222 traffic is switched on to the backup LSP. If the time taken to 223 perform the switchover exceeds the BFD fault detection interval a 224 fault will be declared even though the MPLS LSP is being locally 225 repaired. To avoid this the BFD fault detection interval should be 226 greater than the fast-reroute switchover time. An implementation 227 SHOULD provide configuration options to control the BFD fault 228 detection interval. 230 If there are multiple alternate paths from an ingress LSR to an 231 egress LSR for a LDP IP FEC, LSP-Ping traceroute MAY be used to 232 determine each of these alternate paths. A BFD session SHOULD be 233 established for each alternate path that is discovered. 235 Periodic LSP-Ping echo request messages SHOULD be sent by the ingress 236 LSR to the egress LSR along the same data path as the LSP. This is to 237 periodically verify the control plane against the data plane by 238 ensuring that the LSP is mapped to the same FEC, at the egress, as 239 the ingress. The rate of generation of these LSP-Ping echo request 240 messages SHOULD be significantly less than the rate of generation of 241 the BFD control packets. An implemetation MAY provide configuration 242 options to control the rate of generation of the periodic LSP-Ping 243 echo request messages. 245 5. Initialization and Demultiplexing 247 A BFD session may be established for a FEC associated with a MPLS 248 LSP. As desribed above in the case of PHP and next-hop label 249 allocation the BFD control packet received by the egress LSR does not 250 contain sufficient information to associate it with a BFD session. 251 Hence the demultiplexing MUST be done using the remote discriminator 252 field in the received BFD control packet. The exchange of BFD 253 discriminators for this purpose is described in the next section. 255 6. Session Establishment 257 A BFD session is boot-strapped using LSP-Ping. This specification 258 describes procedures only for BFD asynchronous mode. The initiation 259 of fault detection for a particular combination 260 results in the exchange of LSP-Ping echo request and echo reply 261 packets, in the ping mode, between the ingress and egress LSRs for 262 that . To establish a BFD session a LSP-Ping echo 263 request message MUST carry the local discriminator assigned by the 264 ingress LSR for the BFD session. This MUST subsequently be used as 265 the My Discriminator field in the BFD session packets sent by the 266 ingress LSR. 268 On receipt of the LSP-Ping echo request message, the egress LSR MUST 269 send a BFD control packet to the ingress LSR. This BFD control 270 packet MUST set the Your Discriminator field to the discriminator 271 received from the ingress LSR in the LSP-Ping echo request message. 272 The egress LSR MAY respond with a LSP-Ping echo reply message that 273 carries the local discriminator assigned by it for the BFD session. 274 The local discriminator assigned by the egress LSR MUST be used as 275 the My Discriminator field in the BFD session packets sent by the 276 egress LSR. 278 Once the ingress LSR learns the local discriminator assigned by the 279 egress LSR for a given BFD session, it MUST send a BFD control packet 280 to the egress LSR with the Your Discriminator set to the local 281 discriminator of the egress LSR. The egress LSR demultiplexes the BFD 282 session based on the received Your Discriminator field. As mentioned 283 above the egress LSR MUST send control packets to the ingress LSR 284 with the Your Discriminator field set to the local discriminator of 285 the ingress LSR. The ingress LSR uses this to demultiplex the BFD 286 session. 288 6.1. BFD Discriminator TLV in LSP-Ping 290 LSP-Ping echo request and echo reply messages carry a BFD 291 discriminator TLV for the purpose of session establishment as 292 described above. IANA is requested to assign a type value of 15 to 293 this TLV. This TLV has a length of 4. The value contains the 4 byte 294 local discriminator that the LSR, sending the LSP-Ping message, 295 associates with the BFD session. 297 If the BFD session is not in UP state, the periodic LSP-Ping echo 298 request messages MUST include the BFD discriminator TLV. 300 7. Encapsulation 302 BFD control packets sent by the ingress LSR MUST be encapsulated in 303 the MPLS label stack that corresponds to the FEC for which fault 304 detection is being performed. If the label stack has a depth greater 305 than one, the TTL of the inner MPLS label MAY be set to 1. This may 306 be necessary for certain FECs to enable the egress LSR's control 307 plane to receive the packet [LSP-Ping]. For MPLS PWs, alternatively, 308 the presence of a fault detection message may be indicated by setting 309 a bit in the control word [VCCV]. 311 The BFD control packet sent by the ingress LSR MUST be a UDP packet 312 with a well known destination port 3784 [BFD-IP] and a source port 313 assigned by the sender as per the procedures in [BFD-IP]. The source 314 IP address is a routable address of the sender. The destination IP 315 address is randomly chosen from the 127/8 range, with the following 316 exception. If the FEC is a LDP IP FEC the ingress LSR may discover 317 multiple alternate paths to the egress LSR for this FEC using LSP- 318 ping traceroute. In this case the destination IP address, used in a 319 BFD session established for one such alternate path, is the address 320 in the 127/8 range discovered by LSP-ping traceroute [RFC4379] to 321 exercise that particular alternate path. 323 The IP TTL MUST be set to 1. 325 BFD control packets sent by the egress LSR are UDP packets. The 326 source IP address is a routable address of the replier; the source 327 port is the well-known UDP port 3784. The destination IP address and 328 UDP port MUST be copied from the source IP address and UDP port of 329 the control packet received from the ingress LSR. 331 The BFD control packet sent by the egress LSR to the ingress LSR MAY 332 be routed based on the destination IP address as per the procedures 333 in [BFD-MHOP]. Or the BFD control packet sent by the egress LSR to 334 the ingress LSR MAY be encapsulated in a MPLS label stack. If this is 335 the case the presence of the fault detection message is indicated as 336 described above. This may be the case if the FEC for which the fault 337 detection is being perfomed corresponds to a bi-directional LSP or a 338 MPLS PW. This may also be the case when there is a return LSP from 339 the egress LSR to the ingress LSR. 341 Note that once the BFD session for the MPLS LSP is UP, either end of 342 the BFD session MUST NOT change the source IP address and the local 343 discriminator values of the BFD control packets it generates, unless 344 it first brings down the session. This implies that a LSR MUST ignore 345 BFD packets for a given session, that is demultiplexed using the 346 received Your Discriminator field, if the session is in UP state and 347 if the My Discriminator or the Source IP address fields of the 348 received packet do not match the values associated with the session. 350 8. Security Considerations 352 Security considerations discussed in [BFD], [BFD-MHOP] and [LSP-Ping] 353 apply to this document. 355 9. IANA Considerations 357 This document introduces a BFD discriminator TLV in LSP-Ping. This 358 has to be assigned from the TLV type registry maintained by IANA. 359 IANA is requested to assign a value of 15 to this TLV. 361 10. Acknowledgments 363 We would like to thank Yakov Rekhter, Dave Katz and Ina Minei for 364 contributing to the discussions that formed the basis of this 365 document and for their comments. Thanks to Dimitri Papadimitriou for 366 his comments and review. 368 11. References 370 11.1. Normative References 372 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding 373 Detection", draft-ietf-bfd-base-05.txt. 375 [BFD-IP] D. Katz, D. Ward, "BFD for IPv4 and IPv6 (Single Hop)", 376 draft-ietf-bfd-v4v6-1hop-05.txt 378 [RFC4379] K. Kompella et. al., "Detecting MPLS Data Plane Failures", 379 RFC 4379, February 2006. 381 [RFC] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, March 1997. 384 11.2. Informative References 386 [BFD-MHOP] D. katz, D. Ward, "BFD for Multihop Paths", 387 draft-ietf-bfd-multihop-04.txt 389 [VCCV] T. Nadeau, C. Pignataro, R. Aggarwal, 390 "Pseudo Wire (PW) Virtual Circuit Connection Verification 391 ((VCCV)", 392 draft-ietf-pwe3-vccv-09.txt 394 [RFC3209] Awduche, D., et. al, "RSVP-TE: Extensions to RSVP for LSP 395 tunnels", RFC 3209, December 2001. 397 [RFC4090] P. Pan, et. al., "Fast Reroute Extensions to RSVP-TE for 398 LSP Tunnels", May 2005. 400 [RFC3036] Andersson, L., et al, "LDP Specification", RFC 3036. 402 [RFC4364] E. Rosen, Y. Rekhter, "BGP/MPLS IP VPNs", RFC 4364, 403 February 2006. 405 [L2-VPN] K. Kompella, et. al., "Layer 2 VPNs Over Tunnels", 406 draft-kompella-ppvpn-l2vpn-03.txt 408 [RFC4447] L. Martini et. al.,"Pseudowire Setup and Maintenance 409 using LDP", RFC 4447, April 2006. 411 [OAM-MAP] Nadeau, T., Morrow, M., Busschbach, P., et. al, 412 Pseudo Wire (PW) OAM Message Mapping, 413 draft-ietf-pwe3-oam-msg-map-02.txt, January 2004 415 [RFC4377] Nadeau, T., et. al, "OAM Requirements for MPLS 416 Networks", RFC 4377, February 2006. 418 12. Author Information 420 Rahul Aggarwal 421 Juniper Networks 422 1194 North Mathilda Ave. 423 Sunnyvale, CA 94089 424 Email: rahul@juniper.net 426 Kireeti Kompella 427 Juniper Networks 428 1194 North Mathilda Ave. 429 Sunnyvale, CA 94089 430 Email: kireeti@juniper.net 431 Thomas D. Nadeau 432 Cisco Systems, Inc. 433 300 Beaver Brook Road 434 Boxboro, MA 01719 435 Phone: +1-978-936-1470 436 Email: tnadeau@cisco.com 438 George Swallow 439 Cisco Systems, Inc. 440 300 Beaver Brook Road 441 Boxborough , MA - 01719 442 USA 443 Email: swallow@cisco.com 445 13. Intellectual Property Statement 447 The IETF takes no position regarding the validity or scope of any 448 Intellectual Property Rights or other rights that might be claimed to 449 pertain to the implementation or use of the technology described in 450 this document or the extent to which any license under such rights 451 might or might not be available; nor does it represent that it has 452 made any independent effort to identify any such rights. Information 453 on the procedures with respect to rights in RFC documents can be 454 found in BCP 78 and BCP 79. 456 Copies of IPR disclosures made to the IETF Secretariat and any 457 assurances of licenses to be made available, or the result of an 458 attempt made to obtain a general license or permission for the use of 459 such proprietary rights by implementers or users of this 460 specification can be obtained from the IETF on-line IPR repository at 461 http://www.ietf.org/ipr. 463 The IETF invites any interested party to bring to its attention any 464 copyrights, patents or patent applications, or other proprietary 465 rights that may cover technology that may be required to implement 466 this standard. Please address the information to the IETF at ietf- 467 ipr@ietf.org. 469 14. Full Copyright Statement 471 Copyright (C) The Internet Society (2006). This document is subject 472 to the rights, licenses and restrictions contained in BCP 78, and 473 except as set forth therein, the authors retain all their rights. 475 This document and the information contained herein are provided on an 476 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 477 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 478 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 479 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 480 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 481 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.