idnits 2.17.1 draft-ietf-bfd-generic-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 319. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 323), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** 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 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 -- 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 49, but not defined == Unused Reference: 'KEYWORD' is defined on line 260, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-04 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-v4v6-1hop-04 == Outdated reference: A later version (-07) exists of draft-ietf-bfd-mpls-02 == Outdated reference: A later version (-09) exists of draft-ietf-bfd-multihop-03 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Katz 3 Internet Draft Juniper Networks 4 D. Ward 5 Cisco Systems 6 Expires: April, 2006 October, 2005 8 Generic Application of BFD 9 draft-ietf-bfd-generic-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This document describes the generic application of the Bidirectional 40 Forwarding Detection (BFD) protocol in environments not specifically 41 documented in other specifications. Comments on this draft should be 42 directed to rtg-bfd@ietf.org. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 50 1. Introduction 52 BFD [BFD] provides a liveness detection mechanism that can be 53 utilized by other network components for which their integral 54 liveness mechanisms are either too slow, inappropriate, or 55 nonexistent. Other drafts have detailed the use of BFD in specific 56 situations ([BFD-1HOP], [BFD-MULTI], [BFD-MPLS]). As the utility of 57 BFD has become understood, there have been calls to specify BFD 58 interactions with a growing list of network functions. Rather than 59 producing a long series of short documents on the application of BFD, 60 it seemed worthwhile to describe the interactions between BFD and 61 other network functions in a broad way. 63 This document describes the generic application of BFD. Applications 64 with specific requirements should be spelled out in specific 65 documents. 67 2. Overview 69 The Bidirectional Forwarding Detection (BFD) specification defines a 70 protocol with simple and specific semantics. Its sole purpose is to 71 verify connectivity between a pair of systems, for a particular data 72 protocol across a path (which may be of any technology, length, or 73 OSI layer). The promptness of the detection of a path failure can be 74 controlled by trading off protocol overhead and system load with 75 detection times. 77 BFD is *not* intended to directly provide control protocol liveness 78 information; those protocols have their own means and vagaries. 80 Rather, control protocols can use the services provided by BFD to 81 inform their operation. BFD can be viewed as a service provided by 82 the layer in which it is running. 84 The service interface with BFD is straightforward. The application 85 supplies session parameters (neighbor address, time parameters, 86 protocol options), and BFD provides the session state, of which the 87 most interesting transitions are to and from the Up state. The 88 application is expected to bootstrap the BFD session, as BFD has no 89 discovery mechanism. 91 An implementation SHOULD establish only a single BFD session per data 92 protocol path, regardless of the number of applications that wish to 93 utilize it. There is no additional value in having multiple BFD 94 sessions to the same endpoints. If multiple applications request 95 different session parameters, it is a local issue as to how to 96 resolve the parameter conflicts. BFD in turn will notify all 97 applications bound to a session when a session state change occurs. 99 BFD should be viewed as having an advisory role to the protocol or 100 protocols or other network function with which it is interacting, 101 which will then use their own mechanisms to effect any state 102 transitions. The interaction is very much at arm's length, which 103 keeps things simple and decoupled. In particular, BFD explicitly 104 does not carry application-specific information, partly for 105 architectural reasons, and partly because BFD may have curious and 106 unpredictable latency characteristics and as such makes a poor 107 transport mechanism. 109 3. Control Protocol Interactions 111 The object when BFD interacts with a control protocol is to advise 112 the control protocol of the connectivity of the data protocol. In 113 the case of routing protocols, for example, this allows the 114 connectivity failure to trigger the rerouting of traffic around the 115 failed path. 117 BFD sessions are typically bootstrapped by the control protocol, 118 using the mechanism (discovery, configuration) used by the control 119 protocol to find neighbors. In most cases it is not desirable to 120 preclude the control protocol from establishing an adjacency if the 121 BFD session cannot be established (usually because the neighbor does 122 not support BFD.) 124 If the control protocol carries signaling that indicates the 125 willingness of each system to establish a BFD session, the lack of a 126 BFD session may be used to block establishment of a control protocol 127 adjacency. 129 If it appears that the neighboring system does not support BFD 130 (because the control protocol adjacency was established but no BFD 131 Control packets have been received from the neighbor) it is useful to 132 increase the interval between transmitted BFD Control packets beyond 133 the minimum. This will have minimal impact on BFD session 134 establishment if the neighbor decides to run BFD after all, since BFD 135 Control packets will be sent on an event-driven basis once the first 136 packet is seen from the neighbor. 138 The mechanism by which the control protocol achieves its reaction to 139 the path failure depends on the capabilities of the protocol. A 140 protocol which is tightly bound to the failing data protocol may wish 141 to emulate a control protocol failure across the path (such as 142 tearing down an adjacency or peer in a routing protocol that supports 143 only the failed data protocol.) Note that this should not be 144 interpreted as BFD replacing the control protocol liveness mechanism, 145 if any, as the control protocol may rely on mechanisms not verified 146 by BFD (multicast, for instance) so BFD most likely cannot detect all 147 failures that would impact the control protocol. However, a control 148 protocol may choose to use BFD session state information to more 149 rapidly detect an impending control protocol failure, particularly if 150 the control protocol operates in band (over the data protocol.) 152 If the control protocol has a more explicit mechanism for announcing 153 path state, it is preferable to use that mechanism rather than 154 impacting the connectivity of the control protocol (since the control 155 protocol may be supporting other data protocols that are still 156 functioning), particularly if the control protocol operates out of 157 band from the failed data protocol. 159 If the control protocol has a Graceful Restart mechanism, BFD may be 160 used in conjunction with this mechanism. If BFD is implemented in 161 the forwarding plane, a session failure implies that data can no 162 longer be forwarded. In this case, any Graceful Restart in progress 163 should be aborted. See [BFD-1HOP] for a more detailed discussion. 165 If hierarchical or dependent layers of control protocols are in use 166 (say, OSPF and IBGP), it may not be useful for more than one of them 167 to interact with BFD. In this example, because IBGP is dependent on 168 OSPF for its routing information, the faster failure detection 169 relayed to IBGP may actually be detrimental. The cost of a peer 170 state transition is high in BGP, and OSPF will naturally heal the 171 path through the network if it were to receive the failure detection. 173 In general, it is best for the protocol at the lowest point in the 174 hierarchy to interact with BFD, and then to use existing interactions 175 between the control protocols to effect changes as necessary. This 176 will provide the fastest possible failure detection and recovery in a 177 network. 179 4. Interactions With Non-Protocol Functions 181 BFD session status may be used to affect other system functions that 182 are not protocol-based (for example, static routes.) If the path to 183 a remote system fails, it may be desirable to avoid passing traffic 184 to that remote system, so the local system may wish to take internal 185 measures to accomplish this (such as withdrawing a static route and 186 withdrawing that route from routing protocols.) 188 Bootstrapping of the BFD session in the non-protocol case is likely 189 to be derived from configuration information. 191 There is no need to exchange endpoints or discriminator values via 192 any mechanism other than configuration (via Operational Support 193 Systems or any other means) as the endpoints must be known and 194 configured by the same means. 196 5. Data Protocols and Demultiplexing 198 BFD is intended to protect a single "data protocol" and is 199 encapsulated within that protocol. A pair of systems may have 200 multiple BFD sessions over the same topology if they support (and are 201 encapsulated by) different protocols. For example, if two systems 202 have IPv4 and IPv6 running across the same link between them, these 203 are considered two separate paths and require two separate BFD 204 sessions. 206 This same technique is used for more fine-grained paths. For 207 example, if multiple differentiated services [DIFFSERV] are being 208 operated on over IPv4, an independent BFD session may be run for each 209 service level. The BFD Control packets must be marked in the same 210 way as the data packets, partly to ensure as much fate sharing as 211 possible between BFD and data traffic, and also to demultiplex the 212 initial packet if the discriminator values have not been exchanged. 214 6. Other Application Issues 216 BFD can provide liveness detection for OAM-like functions in 217 tunneling and pseudowire protocols. Running BFD inside the tunnel is 218 recommended, as it exercises more aspects of the path. One way to 219 accommodate this is to address BFD packets based on the tunnel 220 endpoints, assuming that they are numbered. 222 If a planned outage is to take place on a path over which BFD is run, 223 it is preferable to take down the BFD session by going into ADMIN 224 DOWN state prior to the outage. 226 7. Interoperability Issues 228 The BFD protocol itself is designed so that it will always 229 interoperate at a basic level; asynchronous mode is mandatory and is 230 always available, and other modes and functions are negotiated at run 231 time. Since the service provided by BFD is identical regardless of 232 the variants used, the particular choice of BFD options has no 233 bearing on interoperability. 235 The interaction between BFD and other protocols and control functions 236 is very loosely coupled. The actions taken are based on existing 237 mechanisms in those protocols and functions, so interoperability 238 problems are very unlikely unless BFD is applied in contradictory 239 ways (such as a BFD session failure causing one implementation to go 240 down and another implementation to come up.) 242 Normative References 244 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", 245 draft-ietf-bfd-base-04.txt, October, 2005. 247 [BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single 248 Hop)", draft-ietf-bfd-v4v6-1hop-04.txt, October, 2005. 250 [BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs", 251 draft-ietf-bfd-mpls-02.txt, July, 2005. 253 [BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft- 254 ietf-bfd-multihop-03.txt, July, 2005. 256 [DIFFSERV] Nichols, K. et al, "Definition of the Differentiated 257 Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 258 2474, December, 1998. 260 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", RFC 2119, March 1997. 263 Security Considerations 265 This specification does not raise any additional security issues 266 beyond those of the specifications referred to in the list of 267 normative references. 269 IANA Considerations 271 This document has no actions for IANA. 273 Authors' Addresses 275 Dave Katz 276 Juniper Networks 277 1194 N. Mathilda Ave. 278 Sunnyvale, California 94089-1206 USA 279 Phone: +1-408-745-2000 280 Email: dkatz@juniper.net 282 Dave Ward 283 Cisco Systems 284 170 W. Tasman Dr. 285 San Jose, CA 95134 USA 286 Phone: +1-408-526-4000 287 Email: dward@cisco.com 289 Changes from the previous draft 291 Text concerning the interaction between BFD and a hierarchy of 292 control protocols was added. A discussion of bootstrapping and 293 session establishment was included. Graceful Restart interactions 294 were mentioned. A section on fine-grained path demultiplexing was 295 added. 297 IPR Disclaimer 299 The IETF takes no position regarding the validity or scope of any 300 Intellectual Property Rights or other rights that might be claimed to 301 pertain to the implementation or use of the technology described in 302 this document or the extent to which any license under such rights 303 might or might not be available; nor does it represent that it has 304 made any independent effort to identify any such rights. Information 305 on the procedures with respect to rights in RFC documents can be 306 found in BCP 78 and BCP 79. 308 Copies of IPR disclosures made to the IETF Secretariat and any 309 assurances of licenses to be made available, or the result of an 310 attempt made to obtain a general license or permission for the use of 311 such proprietary rights by implementers or users of this 312 specification can be obtained from the IETF on-line IPR repository at 313 http://www.ietf.org/ipr. 315 The IETF invites any interested party to bring to its attention any 316 copyrights, patents or patent applications, or other proprietary 317 rights that may cover technology that may be required to implement 318 this standard. Please address the information to the IETF at ietf- 319 ipr@ietf.org. 321 Full Copyright Notice 323 Copyright (C) The Internet Society (2005). 325 This document is subject to the rights, licenses and restrictions 326 contained in BCP 78, and except as set forth therein, the authors 327 retain all their rights. 329 This document and the information contained herein are provided on an 330 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 331 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 332 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 333 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 334 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 335 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 337 Acknowledgement 339 Funding for the RFC Editor function is currently provided by the 340 Internet Society. 342 This document expires in April, 2006.