Network Working Group D. Katz Internet Draft Juniper Networks D. Ward Cisco Systems Expires:
January,April, 2006 July,October, 2005 Generic Application of BFD draft-ietf-bfd-generic-00.txtdraft-ietf-bfd-generic-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol in environments not specifically documented in other specifications. Comments on this draft should be directed to firstname.lastname@example.org. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KEYWORDS]. 1. Introduction BFD [BFD] provides a liveness detection mechanism that can be utilized by other network components for which their integral liveness mechanisms are either too slow, inappropriate, or nonexistent. Other drafts have detailed the use of BFD in specific situations ([BFD-1HOP], [BFD-MULTI], [BFD-MPLS]). As the utility of BFD has become understood, there have been calls to specify BFD interactions with a growing list of network functions. Rather than producing a long series of short documents on the application of BFD, it seemed worthwhile to describe the interactions between BFD and other network functions in a broad way. This document describes the generic application of BFD. Applications with specific requirements should be spelled out in specific documents. 2. Overview The Bidirectional Forwarding Detection (BFD) specification defines a protocol with simple and specific semantics. Its sole purpose is to verify connectivity between a pair of systems, for a particular data protocol across a path (which may be of any technology, length, or OSI layer). The promptness of the detection of a path failure can be controlled by trading off protocol overhead and system load with detection times. BFD is *not* intended to directly provide control protocol liveness information; those protocols have their own means and vagaries. Rather, control protocols can use the services provided by BFD to inform their operation. BFD can be viewed as a service provided by the layer in which it is running. The service interface with BFD is straightforward. The application supplies session parameters (neighbor address, time parameters, protocol options), and BFD provides the session state, of which the most interesting transitions are to and from the Up state. The application is expected to bootstrap the BFD session, as BFD has no discovery mechanism. An implementation SHOULD establish only a single BFD session per data protocol path, regardless of the number of applications that wish to utilize it. There is no additional value in having multiple BFD sessions to the same endpoints. If multiple applications request different session parameters, it is a local issue as to how to resolve the parameter conflicts. BFD in turn will notify all applications bound to a session when a session state change occurs. BFD should be viewed as having an advisory role to the protocol or protocols or other network function with which it is interacting, which will then use their own mechanisms to effect any state transitions. The interaction is very much at arm's length, which keeps things simple and decoupled. In particular, BFD explicitly does not carry application-specific information, partly for architectural reasons, and partly because BFD may have curious and unpredictable latency characteristics and as such makes a poor transport mechanism. 3. Control Protocol Interactions The object when BFD interacts with a control protocol is to advise the control protocol of the connectivity of the data protocol. In the case of routing protocols, for example, this allows the connectivity failure to trigger the rerouting of traffic around the failed path. BFD sessions are typically bootstrapped by the control protocol, using the mechanism (discovery, configuration) used by the control protocol to find neighbors. In most cases it is not desirable to preclude the control protocol from establishing an adjacency if the BFD session cannot be established (usually because the neighbor does not support BFD.) If the control protocol carries signaling that indicates the willingness of each system to establish a BFD session, the lack of a BFD session may be used to block establishment of a control protocol adjacency. If it appears that the neighboring system does not support BFD (because the control protocol adjacency was established but no BFD Control packets have been received from the neighbor) it is useful to increase the interval between transmitted BFD Control packets beyond the minimum. This will have minimal impact on BFD session establishment if the neighbor decides to run BFD after all, since BFD Control packets will be sent on an event-driven basis once the first packet is seen from the neighbor. The mechanism by which the control protocol achieves its reaction to the path failure depends on the capabilities of the protocol. A protocol which is tightly bound to the failing data protocol may wish to emulate a control protocol failure across the path (such as tearing down an adjacency or peer in a routing protocol that supports only the failed data protocol.) Note that this should not be interpreted as BFD replacing the control protocol liveness mechanism, if any, as the control protocol may rely on mechanisms not verified by BFD (multicast, for instance) so BFD most likely cannot detect all failures that would impact the control protocol. However, a control protocol may choose to use BFD session state information to more rapidly detect an impending control protocol failure, particularly if the control protocol operates in band (over the data protocol.) If the control protocol has a more explicit mechanism for announcing path state, it is preferable to use that mechanism rather than impacting the connectivity of the control protocol (since the control protocol may be supporting other data protocols that are still functioning), particularly if the control protocol operates out of band from the failed data protocol. If the control protocol has a Graceful Restart mechanism, BFD may be used in conjunction with this mechanism. If BFD is implemented in the forwarding plane, a session failure implies that data can no longer be forwarded. In this case, any Graceful Restart in progress should be aborted. See [BFD-1HOP] for a more detailed discussion. If hierarchical or dependent layers of control protocols are in use (say, OSPF and IBGP), it may not be useful for more than one of them to interact with BFD. In this example, because IBGP is dependent on OSPF for its routing information, the faster failure detection relayed to IBGP may actually be detrimental. The cost of a peer state transition is high in BGP, and OSPF will naturally heal the path through the network if it were to receive the failure detection. In general, it is best for the protocol at the lowest point in the hierarchy to interact with BFD, and then to use existing interactions between the control protocols to effect changes as necessary. This will provide the fastest possible failure detection and recovery in a network. 4. Interactions With Non-Protocol Functions BFD session status may be used to affect other system functions that are not protocol-based (for example, static routes.) If the path to a remote system fails, it may be desirable to not attempt to passavoid passing traffic to that remote system, so the local system may wish to take internal measures to accomplish this.this (such as withdrawing a static route and withdrawing that route from routing protocols.) Bootstrapping of the BFD session in the non-protocol case is likely to be derived from configuration information in this case.information. There is no need to exchange endpoints or discriminator values via any othermechanism other than configuration (via OSSOperational Support Systems or any other means) as the endpoints must be known and configured by the same means. 5. Data Protocols and Demultiplexing BFD is intended to protect a single "data protocol" and is encapsulated within that protocol. A pair of systems may have multiple BFD sessions over the same topology if they support (and are encapsulated by) different protocols. For example, if two systems have IPv4 and IPv6 running across the same link between them, these are considered two separate paths and require two separate BFD sessions. This same technique is used for more fine-grained paths. For example, if multiple differentiated services [DIFFSERV] are being operated on over IPv4, an independent BFD session may be run for each service level. The BFD Control packets must be marked in the same way as the data packets, partly to ensure as much fate sharing as possible between BFD and data traffic, and also to demultiplex the initial packet if the discriminator values have not been exchanged. 6. Other Application Issues BFD can provide liveness detection for OAM-like functions in tunneling and pseudowire protocols. Running BFD inside the tunnel is recommended, as it exercises more aspects of the path. One way to accommodate this is to address BFD packets based on the tunnel endpoints, assuming that they are numbered. If a planned outage is to take place on a path over which BFD is run, it is preferable to take down the BFD session by going into ADMIN DOWN state prior to the outage. 6.7. Interoperability Issues The BFD protocol itself is designed so that it will always interoperate at a basic level; asynchronous mode is mandatory and is always available, and other modes and functions are negotiated at run time. Since the service provided by BFD is identical regardless of the variants used, the particular choice of BFD options has no bearing on interoperability. The interaction between BFD and other protocols and control functions is very loosely coupled. The actions taken are based on existing mechanisms in those protocols and functions, so interoperability problems are very unlikely unless BFD is applied in contradictory ways (such as a BFD session failure causing one implementation to go down and another implementation to come up.) Normative References [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", draft-ietf-bfd-base-03.txt, July,draft-ietf-bfd-base-04.txt, October, 2005. [BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single Hop)", draft-ietf-bfd-v4v6-1hop-03.txt, July,draft-ietf-bfd-v4v6-1hop-04.txt, October, 2005. [BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs", draft-ietf-bfd-mpls-01.txt, February,draft-ietf-bfd-mpls-02.txt, July, 2005. [BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft- ietf-bfd-multihop-03.txt, July, 2005. [DIFFSERV] Nichols, K. et al, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December, 1998. [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Security Considerations This specification does not raise any additional security issues beyond those of the specifications referred to in the list of normative references. IANA Considerations This document has no actions for IANA. Authors' Addresses Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, California 94089-1206 USA Phone: +1-408-745-2000 Email: email@example.com Dave Ward Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1-408-526-4000 Email: firstname.lastname@example.org Changes from the previous draft Text concerning the interaction between BFD and a hierarchy of control protocols was added. A discussion of bootstrapping and session establishment was included. Graceful Restart interactions were mentioned. A section on fine-grained path demultiplexing was added. IPR Disclaimer The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Full Copyright Notice Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. This document expires in January,April, 2006.