idnits 2.17.1 draft-ietf-bfd-mpls-00.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 3979, Section 5, paragraph 1 on line 373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 386. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 7) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 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 87 has weird spacing: '... may be assoc...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'KEYWORDS' is mentioned on line 55, but not defined == Missing Reference: 'LSP-PING' is mentioned on line 61, but not defined == Missing Reference: 'LSP-FR' is mentioned on line 114, but not defined == Unused Reference: 'RFC' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'BFD-IP' is defined on line 302, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-mpls-lsp-ping-05 == Outdated reference: A later version (-09) exists of draft-ietf-bfd-multihop-00 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-vccv-03 -- Obsolete informational reference (is this intentional?): RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-rfc2547bis-01 == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-08 -- Unexpected draft version: The latest known version of draft-nadeau-pwe3-oam-msg-map is -04, but you're referring to -05. == Outdated reference: A later version (-07) exists of draft-ietf-mpls-oam-requirements-02 Summary: 6 errors (**), 0 flaws (~~), 16 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Rahul Aggarwal 2 Internet Draft Kireeti Kompella 3 Expiration Date: January 2005 Juniper Networks 4 Thomas D. Nadeau 5 George Swallow 6 Cisco Systems, Inc 8 BFD For MPLS LSPs 10 draft-ietf-bfd-mpls-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or IPR claims of which I am aware have been disclosed, and any 16 of which I become aware will be disclosed, in accordance with RFC 17 3668. 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 Abstract 37 One desirable application of Bi-directional Forwarding Detection 38 (BFD) is to detect a MPLS LSP data plane failure. LSP-Ping is an 39 existing mechanism for detecting MPLS data plane failures and for 40 verifying the MPLS LSP data plane against the control plane. BFD can 41 be used for the former, but not for the latter. However the control 42 plane processing required for BFD control packets is relatively 43 smaller than the processing required for LSP-Ping messages. A 44 combination of LSP-Ping and BFD can be used to provide faster data 45 plane failure detection and/or make it possible to provide such 46 detection on a greater number of LSPs. This document describes the 47 applicability of BFD in relation to LSP-Ping for this application. It 48 also describes procedures for using BFD in this environment. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 56 1. Introduction 58 One desirable application of BFD is to track the liveliness of a 59 Multi Protocol Label Switched (MPLS) Label Switched Path (LSP). In 60 particular BFD can be used to detect a data plane failure in the 61 forwarding path of a MPLS LSP. LSP-Ping [LSP-PING] is an existing 62 mechanism for detecting MPLS LSP data plane failures and for 63 verifying the MPLS LSP data plane against the control plane. This 64 document describes the applicability of BFD in relation to LSP-Ping 65 for detecting MPLS LSP data plane failures. It also describes 66 procedures for using BFD in this environment. 68 2. Applicability 70 In the event of a MPLS LSP failing to deliver data traffic, it may 71 not always be possible to detect the failure using the MPLS control 72 plane. For instance the control plane of the MPLS LSP may be 73 functional while the data plane may be mis-forwarding or dropping 74 data. Hence there is a need for a mechanism to detect a data plane 75 failure in the MPLS LSP path [OAM-REQ]. 77 2.1. BFD for MPLS LSPs: Motivation 79 LSP-Ping described in [LSP-Ping] is an existing mechanism for 80 detecting a MPLS LSP data plane failure. In addition LSP-Ping also 81 provides a mechanism for verifying the MPLS control plane against the 82 data plane. This is done by ensuring that the LSP is mapped to the 83 same Forwarding Equivalence Class (FEC) as the ingress. 85 BFD cannot be used for verifying the MPLS control plane against the 86 data plane. However BFD can be used to detect a data plane failure 87 in the forwarding path of a MPLS LSP. The LSP may be associated with 88 any of the following FECs: 89 a) RSVP IPv4/IPv6 Session [RSVP-TE] 90 b) LDP IPv4/IPv6 prefix [LDP] 91 c) VPN IPv4/IPv6 prefix [2547] 92 d) Layer 2 VPN [L2-VPN] 93 e) Layer 2 Circuit ID [LDP-PW] 95 LSP-Ping includes extensive control plane verification. BFD on the 96 other hand was designed as a light-weight means of testing only the 97 data plane. As a result, LSP-Ping is computationally more expensive 98 than BFD for detecting MPLS LSP data plane faults. BFD is also more 99 suitable for being implemented in hardware or firmware due to its 100 fixed packet format. Thus the use of BFD for detecting MPLS LSP data 101 plane faults has the following advantages: 103 a) Support for fault detection for greater number of LSPs. 105 b) Fast detection. Detection with sub-second granularity is 106 considered as fast detection. LSP-Ping is intended to be used in an 107 environment where fault detection messages are exchanged in the order 108 of seconds. Hence its not appropriate for fast detection. BFD on the 109 other hand is designed for sub-second fault detection intervals. 110 Following are some potential cases when fast detection may be 111 desirable for MPLS LSPs: 113 1. In the case of a bypass LSP used for facility based link or 114 node protection [LSP-FR]. In this case the bypass LSP is essentially 115 being used as an alternate link to protect one or more LSPs. It 116 represents an aggregate and is used to carry data traffic belonging 117 to one or more LSPs when the link or the node being protected fails. 118 Hence fast failure detection of the bypass LSP may be desirable 119 particularly in the event of link or node failure when the data 120 traffic is moved to the bypass LSP. 122 2. MPLS Pseudo Wires (PW). Fast detection may be desired for MPLS 123 PWs depending on i) the model used to layer the MPLS network with the 124 layer 2 network. and ii) the service that the PW is emulating. For a 125 non-overlay model between the layer 2 network and the MPLS network 126 the provider may rely on PW fault detection to provide service status 127 to the end-systems. Also in that case interworking scenarios such as 128 ATM/Frame Relay interworking may force periodic PW fault detection 129 messages. Depending on the requirements of the service that the MPLS 130 PW is emulating, fast failure detection may be desirable. Use of BFD 131 for PWs is further described in [VCCV] and [OAM-MAP]. 133 We would like to point that the applicability of fast detection to 134 MPLS LSPs needs more study and operational input. 136 2.2. Using BFD in Conjunction with LSP-Ping 138 BFD can be used for MPLS LSP data plane fault detection. However it 139 does not have all the funcitonality of LSP-Ping. In paticular it 140 cannot be used for verifying the control plane against the data 141 plane. LSP Ping performs the following functions that are outside the 142 scope of BFD: 144 a) Association of a LSP-Ping echo request message with a FEC. In 145 the case of Penultimate Hop Popping (PHP), for a single label stack 146 LSP, the only way to associate a fault detection message with a FEC 147 is by carrying the FEC in the message. LSP-Ping provides this 148 functionality. Next-hop label allocation also makes it necessary to 149 carry the FEC in the fault detection message as the label alone is 150 not sufficient to identify the LSP being verified. In addition to 151 this presence of the FEC in the echo request message makes is 152 possible to verify the control plane against the data plane at the 153 egress LSR. 155 b) ECMP considerations. LSP-Ping makes it possible to exercise 156 multiple alternate paths for a given LSP. 158 c) Traceroute. LSP-Ping supports traceroute for a FEC and it can be 159 used for fault isolation. 161 Hence BFD is used in conjunction with LSP-Ping for MPLS LSP fault 162 detection: 164 i) LSP-Ping is used for boot-strapping the BFD session as described 165 later in this document. 167 ii) BFD is used to exchange fault detection (i.e. BFD session) 168 packets at the required detection interval. 170 iii) LSP-Ping is used to periodically verify the control plane 171 against the data plane by re-synchronizing the MPLS LSP and FEC 172 mappings. 174 3. Theory of Operation 176 To use BFD for fault detection on a MPLS LSP a BFD session is 177 established for that particular MPLS LSP. BFD control packets are 178 sent along the same data path as the LSP being verified and are 179 processed by the control plane of the egress LSR. If the LSP is 180 associated with multiple FECs, a BFD session is established for each 181 FEC. For instance this may happen in the case of next-hop label 182 allocation. Hence the operation is conceptually similar to the data 183 plane fault detection procedures of LSP-Ping. 185 If MPLS fast-reroute is being used for the MPLS LSP the use of BFD 186 for fault detection can result in false fault detections if the BFD 187 fault detection interval is less than the MPLS fast-reroute 188 switchover time. When MPLS fast-reroute is triggered because of a 189 link or node failure BFD control packets will be dropped until 190 traffic is switched on to the backup LSP. If the time taken to make 191 the switchover exceeds the BFD fault detection interval a fault will 192 be delcared even though the MPLS LSP is being locally repaired. To 193 avoid this the BFD fault detection interval should be greater than 194 the fast-reroute switchover time. 196 4. Initialization and Demultiplexing 198 A BFD session may be established for a FEC associated with a MPLS 199 LSP. As desribed above in the case of PHP and next-hop label 200 allocation the BFD control packet received by the egress LSR does not 201 contain sufficient information to associate it with a BFD session. 202 Hence the demultiplexing has to be done using the remote 203 discriminator field in the received BFD control packet. The exchange 204 of BFD discriminators for this purpose is described in the next 205 section. 207 5. Session Establishment 209 A BFD session is boot-strapped using LSP-Ping. The initiation of 210 fault detection for a particular combination results 211 in the exchange of LSP-Ping echo request and echo reply packets, in 212 the ping mode, between the ingress and egress LSRs for that . To establish a BFD session a LSP-Ping echo request message 214 carries the local discriminator assigned by the ingress LSR for the 215 BFD session. This is subsequently used as the My Discriminator field 216 in the BFD session packets sent by the ingress LSR. The egress LSR 217 responds with a echo reply message that carries the local 218 discriminator assigned by it for the BFD session. This is 219 subsequently used as the My Discriminator field in the BFD session 220 packets sent by the egress LSR. 222 Once the ingress LSR learns the local discriminator assigned by the 223 egress LSR for a given BFD session, it sends a BFD control packet to 224 the egress LSR with the Your Discriminator set to the local 225 discriminator of the egress LSR. The egress LSR demultiplexes the BFD 226 session based on the received Your Discriminator field. It sends 227 control packets to the ingress LSR with the Your Discriminator field 228 set to the local discriminator of the ingress LSR. The ingress LSR 229 can use this to demultiplex the BFD session. 231 5.1. BFD Discriminator TLV in LSP-Ping 233 LSP-Ping echo request and echo reply messages carry a BFD 234 discriminator TLV for the purpose of session establishment as 235 described above. This TLV has a type TBD and a length of 4. The value 236 contains the 4 byte local discriminator that the LSR sending the LSP- 237 Ping message associates with the BFD session. 239 6. Encapsulation 241 BFD control packets sent by the ingress LSR are encapsulated in the 242 MPLS label stack that corresponds to the FEC for which fault 243 detection is being performed. If the label stack has a depth greater 244 than one, the TTL of the inner MPLS label maybe set to 1. This may be 245 necessary for certain FECs to enable the egress LSR's control plane 246 to receive the packet [LSP-Ping]. For MPLS PWs, alternatively, the 247 presence of a fault detection message may be indicated by setting a 248 bit in the control word [VCCV]. 250 The BFD control packet sent by the ingress LSR MUST be a UDP packet 251 with a well known destination port TBD and a source port assigned by 252 the sender. The source IP address is a routable address of the 253 sender. The destination IP address is a (randomly chosen) address 254 from 127/8. The IP TTL is set to 1. 256 BFD control packets sent by the egress LSR are UDP packets. The 257 source IP address is a routable address of the replier; the source 258 port is the well-known UDP port TBD. The destination IP address and 259 UDP port are copied from the source IP address and UDP port of the 260 control packet received from the ingress LSR. The BFD control packet 261 sent by the egress LSR to the ingress LSR may be encapsulated in a 262 MPLS label stack and the presence of the fault detection message is 263 indicated as described above. This may be the case if the FEC for 264 which the fault detection is being perfomed corresponds to a bi- 265 directional LSP or a MPLS PW. This may also be the case when there is 266 a return LSP from the egress LSR to the ingress LSR. It may also be 267 routed based on the destination IP address [BFD-MHOP]. 269 7. Security Considerations 271 Security considerations discussed in [BFD] and [LSP-Ping] apply to 272 this document. 274 8. IANA Considerations 276 This document introduces a BFD discriminator TLV in LSP-Ping. This 277 has to be assigned from the TLV type registry maintained by IANA. 279 9. Acknowledgments 281 We would like to thank Yakov Rekhter, Dave Katz and Ina Minei for 282 contributing to the discussions that formed the basis of this 283 document and for their comments. Thanks to Dimitri Papadimitriou for 284 his comments and review. 286 10. References 288 10.1. Normative References 290 [BFD] Katz, D., and Ward, D., 291 "Bidirectional Forwarding Detection", 292 draft-katz-ward-bfd-02.txt, August 2003. 294 [LSP-Ping] K. Kompella et. al., "Detecting MPLS Data Plane Failures", 295 draft-ietf-mpls-lsp-ping-05.txt 297 [RFC] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, March 1997. 300 10.2. Informative References 302 [BFD-IP] D. Katz, D. Ward, "BFD for IPv4 and IPv6 (Single Hop)", 303 draft-katz-ward-bfd-v4v6-1hop-01.txt 305 [BFD-MHOP] D. katz, D. Ward, "BFD for Multihop Paths", 306 draft-ietf-bfd-multihop-00.txt 308 [VCCV] T. Nadeau, R. Aggarwal, "Pseudo Wire (PW) Virtual Circuit 309 Connection Verification ((VCCV)", 310 draft-ietf-pwe3-vccv-03.txt 312 [RSVP-TE] Awduche, D., et al, "RSVP-TE: Extensions to RSVP for LSP 313 tunnels", RFC 3209, December 2001. 315 [LDP] Andersson, L., et al, "LDP Specification", RFC 3036. 317 [2547] E. Rosen, Y. Rekhter, "BGP/MPLS IP VPNs", 318 draft-ietf-l3vpn-rfc2547bis-01.txt 320 [L2-VPN] K. Kompella, et. al., "Layer 2 VPNs Over Tunnels", 321 draft-kompella-ppvpn-l2vpn-03.txt 323 [LDP-PW] L. Martini et. al.,"Pseudowire Setup and Maintenance 324 using LDP", 325 draft-ietf-pwe3-control-protocol-08.txt 327 [OAM-MAP] Nadeau, T., Morrow, M., Busschbach, P., et. al, 328 Pseudo Wire (PW) OAM Message Mapping, 329 draft-nadeau-pwe3-oam-msg-map-05.txt, January 2004 331 [OAM-REQ] Nadeau, T., et. al, "OAM Requirements for MPLS 332 Networks", draft-ietf-mpls-oam-requirements-02.txt, 333 June 2003. 335 11. Author Information 337 Rahul Aggarwal 338 Juniper Networks 339 1194 North Mathilda Ave. 340 Sunnyvale, CA 94089 341 Email: rahul@juniper.net 343 Kireeti Kompella 344 Juniper Networks 345 1194 North Mathilda Ave. 346 Sunnyvale, CA 94089 347 Email: kireeti@juniper.net 349 Thomas D. Nadeau 350 Cisco Systems, Inc. 351 300 Beaver Brook Road 352 Boxboro, MA 01719 353 Phone: +1-978-936-1470 354 Email: tnadeau@cisco.com 356 George Swallow 357 Cisco Systems, Inc. 359 300 Beaver Brook Road 360 Boxborough , MA - 01719 361 USA 362 Email: swallow@cisco.com 364 12. Intellectual Property 366 The IETF takes no position regarding the validity or scope of any 367 Intellectual Property Rights or other rights that might be claimed to 368 pertain to the implementation or use of the technology described in 369 this document or the extent to which any license under such rights 370 might or might not be available; nor does it represent that it has 371 made any independent effort to identify any such rights. Information 372 on the procedures with respect to rights in RFC documents can be 373 found in BCP 78 and BCP 79. 375 Copies of IPR disclosures made to the IETF Secretariat and any 376 assurances of licenses to be made available, or the result of an 377 attempt made to obtain a general license or permission for the use of 378 such proprietary rights by implementers or users of this 379 specification can be obtained from the IETF on-line IPR repository at 380 http://www.ietf.org/ipr. 382 The IETF invites any interested party to bring to its attention any 383 copyrights, patents or patent applications, or other proprietary 384 rights that may cover technology that may be required to implement 385 this standard. Please address the information to the IETF at ietf- 386 ipr@ietf.org. 388 13. Full Copyright Statement 390 Copyright (C) The Internet Society (2004). This document is subject 391 to the rights, licenses and restrictions contained in BCP 78 and 392 except as set forth therein, the authors retain all their rights. 394 This document and the information contained herein is provided on an 395 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 396 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 397 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 398 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 399 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 401 14. Acknowledgement 403 Funding for the RFC Editor function is currently provided by the 404 Internet Society.