--- 1/draft-ietf-bfd-v4v6-1hop-10.txt 2010-01-06 07:12:46.000000000 +0100 +++ 2/draft-ietf-bfd-v4v6-1hop-11.txt 2010-01-06 07:12:46.000000000 +0100 @@ -1,19 +1,19 @@ Network Working Group D. Katz Internet Draft Juniper Networks Intended status: Proposed Standard D. Ward - Cisco Systems -Expires: April, 2010 October 16, 2009 + Juniper Networks +Expires: July, 2010 January 5, 2010 BFD for IPv4 and IPv6 (Single Hop) - draft-ietf-bfd-v4v6-1hop-10.txt + draft-ietf-bfd-v4v6-1hop-11.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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. @@ -93,20 +93,34 @@ Echo function, or need make an exception for ingress filtering Echo packets. An implementation of the Echo function also requires Application Programming Interfaces (APIs) that may not exist on all systems. A system implementing the Echo function MUST be capable of sending packets to its own address, which will typically require bypassing the normal forwarding lookup. This typically requires access to APIs that bypass IP layer functionality. + Please note that BFD is intended as a connectivity check/connection + verification OAM mechanism. It is applicable for network-based + services (e.g. router-to-router, subscriber-to-gateway, LSP/circuit + endpoints and service appliance failure detection). In these + scenarios it is required that the operator correctly provision the + rates at which BFD is transmitted to avoid congestion (e.g link, I/O, + CPU) and false failure detection. It is not applicable for + application-to-application failure detection across the Internet + because it does not have sufficient capability to do necessary + congestion detection and avoidance and therefore cannot prevent + congestion collapse. Host-to-host or application-to-application + deployment across the Internet will require the encapsulation of BFD + within a transport that provides "TCP-friendly" [TFRC] behavior. + 3. Initialization and Demultiplexing In this application, there will be only a single BFD session between two systems over a given interface (logical or physical) for a particular protocol. The BFD session must be bound to this interface. As such, both sides of a session MUST take the "Active" role (sending initial BFD Control packets with a zero value of Your Discriminator) and any BFD packet from the remote machine with a zero value of Your Discriminator MUST be associated with the session bound to the remote system, interface, and protocol. @@ -224,51 +238,51 @@ unauthorized packets and may be useful in implementations in which cryptographic checksum use is susceptible to denial of service attacks. The use or non-use of this mechanism does not impact interoperability. 10. References 10.1. Normative References [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", - draft-ietf-bfd-base-10.txt, October, 2009. + draft-ietf-bfd-base-10.txt, January, 2010. [BFD-GENERIC] Katz, D., and Ward, D., "Generic Application of BFD", draft-ietf-bfd-generic-05.txt, February, 2009. [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October, 2007. [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 10.2. Informative References [BCP38] Ferguson, P, and Senie, D., "Network Ingress Filtering: - Defeating Denial of Service Attacks which employ IP Source Address - Spoofing", RFC 2827, May 2000. + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", RFC 2827, May 2000. + + [TFRC] Floyd, S., et al, "TCP Friendly Rate Control (TFRC): Protocol + Specification", RFC 5348, September, 2008. Authors' Addresses Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, California 94089-1206 USA Phone: +1-408-745-2000 Email: dkatz@juniper.net Dave Ward - Cisco Systems - 170 W. Tasman Dr. - San Jose, CA 95134 USA - Phone: +1-408-526-4000 - Email: dward@cisco.com + Juniper Networks + 1194 N. Mathilda Ave. + Sunnyvale, California 94089-1206 USA + Phone: +1-408-745-2000 + Email: dward@juniper.net Changes from the previous draft - The Encapsulation section was reorganized, and the details of Echo - packet encapsulation and transmission were expanded. The IANA - Considerations section was updated to include the port number - assignments. + The applications section was clarified. - This document expires in April, 2010. +This document expires in July, 2010.