--- 1/draft-ietf-bfd-multihop-00.txt 2006-02-04 22:51:12.000000000 +0100 +++ 2/draft-ietf-bfd-multihop-01.txt 2006-02-04 22:51:12.000000000 +0100 @@ -1,39 +1,42 @@ + Network Working Group D. Katz Internet Draft Juniper Networks D. Ward Cisco Systems -Expires: January, 2005 July, 2004 +Expires: August, 2005 February, 2005 BFD for Multihop Paths - draft-ietf-bfd-multihop-00.txt + draft-ietf-bfd-multihop-01.txt Status of this Memo - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + or will be disclosed, and any of which I become aware will be + disclosed, in accordance with RFC 3668. 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/ietf/1id-abstracts.txt + http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. + http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. @@ -124,23 +127,22 @@ Unidirectional links are classified as multihop paths because the return path (which must exist at some level in order to make the link useful) may be arbitrary, and the return paths for BFD sessions protecting parallel unidirectional links may overlap or even be identical. (If two unidirection links, one in each direction, are to carry a single BFD session, this can be done using the single-hop approach.) Either of the two methods outlined earlier may be used in the - Unidirectional link case (as an MPLS LSP is in fact a unidirectional - link), but a more general solution can be done strictly within BFD - and without addressing limitations. + Unidirectional link case, but a more general solution can be done + strictly within BFD and without addressing limitations. The approach is similar to the one-hop specification, since the unidirectional link is a single hop. Let's define the two systems as the Unidirectional Sender and the Unidirectional Receiver. In this approach the Unidirectional Sender MUST operate in the Active role (as defined in the base BFD specification), and the Unidirectional Receiver MUST operate in the Passive role. In the Passive role, by definition, the Unidirectional Receiver does not transmit any BFD Control packets until it learns the @@ -154,27 +156,27 @@ 4. Authentication By their nature, multihop paths expose BFD to spoofing. Implementations of BFD SHOULD utilize authentication over multihop paths to help mitigate denial-of-service attacks. Normative References [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", - draft-ietf-bfd-base-00.txt, July, 2004. + draft-ietf-bfd-base-01.txt, February, 2005. [BFD-1HOP] Katz, D., and Ward, D., "BFD for IPv4 and IPv6 (Single - Hop)", draft-ietf-bfd-v4v6-1hop-00.txt, July, 2004. + Hop)", draft-ietf-bfd-v4v6-1hop-01.txt, February, 2005. [BFD-MPLS] Aggarwal, R., and Kompella, K., "BFD for MPLS LSPs", - draft-ietf-bfd-mpls-00.txt, July, 2004. + draft-ietf-bfd-mpls-01.txt, February, 2005. [GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004. [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999. @@ -193,42 +195,35 @@ 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 -Full Copyright Notice +Changes from the previous draft - Copyright (C) The Internet Society (2004). All Rights Reserved. + No changes were made other than updating references and boilerplate + language. - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. +Full Copyright Notice - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. + Copyright (C) The Internet Society (2004). 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 is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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." + 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 August, 2005.