idnits 2.17.1 draft-chen-bfd-interface-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2011) is 4676 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Chen 3 Internet-Draft Z. Wang 4 Intended status: Standards Track Huawei Technologies Co.,Ltd 5 Expires: January 2, 2012 L. Guo 6 China Telecom 7 M. Binderberger 8 July 1, 2011 10 Bidirectional Forwarding Detection (BFD) for Interface 11 draft-chen-bfd-interface-00 13 Abstract 15 This document describes how application clients can request IP-based 16 Bidirectional Forwarding Detection (BFD) sessions while either being 17 IP agnostic themselves or while dealing with IP unnumbered 18 interfaces. 20 A dedicated well-known multicast IP address 224.XXX.XXX.XXX is used 21 as the destination IP address of the BFD packets when running BFD for 22 interface. It allows for BFD sessions on interfaces that may have no 23 IP addresses, either because the interface is unnumbered or because 24 the layer 3 protocol status of the interfaces is not up yet. 26 One application of BFD for interface is to run BFD over LAG/Bundle 27 component links. An example will be given in this document. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 2, 2012. 51 Copyright Notice 53 Copyright (c) 2011 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Extensions to BFD . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Implementation example for LAG . . . . . . . . . . . . . . . . 6 72 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 6 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 The Bidirectional Forwarding Detection (BFD) protocol RFC 5880 83 [RFC5880] provides a mechanism for liveness detection of arbitrary 84 paths between systems. It is intended to provide low-overhead, 85 short- duration detection of failures in the path between adjacent 86 forwarding engines, including the interfaces, data link(s), and to 87 the extent possible the forwarding engines themselves. 89 Although BFD can be used for detecting failures of the path between 90 two interfaces, normally the application clients are not the 91 interfaces themselves but layer 3 applications like Open Shortest 92 Path First (OSPF) [RFC2328] or Border Gateway Protocol 93 (BGP)[RFC4271]. There are scenarios though that may require running 94 BFD directly on the interfaces and to associate the BFD session 95 status with the status of the interfaces, and consequently taking 96 down or bringing up the interfaces rapidly by BFD. One example of 97 this is a Link Aggregation Group (LAG) or bundle interface that 98 consists of multiple component interfaces; it requires to detect the 99 status of each component interface hence to block the faulty 100 interfaces and avoid unnecessary packets loss, or take down the LAG/ 101 bundle interface when the number/bandwidth of failed component 102 interfaces reaches a preconfigured threshold. This can be achieved 103 by establishing separate BFD session for each pair of component 104 interfaces to detect the failures, and the interfaces or the LAG 105 management module owning these interfaces are clients served by those 106 BFD sessions. 108 2. Problem Statement 110 IP addresses (source and destination IP address) are necessary when 111 setting up a BFD session. But for an unnumbered interface there is 112 no dedicated IP address configured, for a LAG component interfaces 113 it's possible that the interface is not IP activated yet. Hence a 114 BFD session can not be established due to lack of either the 115 destination IP address or Address Resolution Protocol (ARP) on an 116 Ethernet interface. 118 Therefore it is required that BFD can run on the interfaces without 119 knowledge of an IP address specific for the interface and without the 120 need to use ARP. 122 In addition, when the interface is itself the client of the BFD 123 session, then the status of the interfaces will be associated with 124 the status of the BFD session. There may be a deadlock situation 125 since BFD session down may take down the interfaces (e.g., layer 3 126 protocol down), and subsequently BFD packets, including other control 127 protocols packets (e.g. ARP) that are tightly coupled with the 128 status of the interface, cannot be transmitted between the pair of 129 interfaces, thus failing to bring up the interfaces. 131 To avoid the deadlock BFD packets SHOULD NOT be blocked by the layer 132 N protocol status of the interface when the application depends on 133 the BFD status to enable layer N of the interface. If this cannot be 134 achieved then the BFD status MUST be ignored by the application when 135 bringing up an interface. The BFD status can then be used afterwards 136 to bring the interface down. 138 3. Extensions to BFD 140 This document does not change the format of BFD control packets and 141 the BFD state machine defined in RFC 5880 [RFC5880]. Currently, only 142 asynchronous mode is considered in this document. 144 To solve the issues described in Section 2, this document introduces 145 a new concept of using Multicast BFD (M-BFD). M-BFD uses a dedicated 146 well-known multicast IP address (224.XXX.XXX.XXX, to be assigned by 147 IANA) as the destination IP address when sending BFD packets. With 148 this extension, a BFD session can be setup for the interfaces that 149 are IP unnumbered. In addition it will not require to use address 150 resolution (ARP) before sending the BFD packets. 152 When sending BFD packets, the destination address MUST be set to 153 224.XXX.XXX.XXX, the destination UDP port is set as defined in 154 RFC 5881 [RFC5881] for BFD control packets. The BFD packets are sent 155 to the specified interface that is associated with the BFD session. 156 The BFD source address MUST be an IP address that belongs to the 157 sending system. If no such address is available then 0.0.0.0 should 158 be used as a source address. 160 When BFD for interface is configured on an interface, it MUST be able 161 to receive the BFD packets with destination IP address set to the 162 well-known multicast IP address (e.g., 224.XXX.XXX.XXX) and send them 163 to the BFD module for further processing. 165 Due to the potential deadlock problem described in section 2 166 application clients MUST be able to proceed without an UP status 167 message from BFD. Otherwise interoperability is at risk. It may be 168 desirable for the application client to wait for BFD reporting back 169 an UP status; in this case it is recommended to introduce a 170 configuration option to allow this wait-for-BFD behaviour. 172 4. Implementation example for LAG 174 The following is an example how the mechanism above allows to use BFD 175 to activate and deactivate LAG (bundle) component links. Some 176 details are implementation specific and are NOT part of this 177 standard. 179 The interface states as well as the details of a LAG interface are 180 controlled by the Interface Management Module (IMM). When BFD is 181 enabled by configuration for a particular LAG then IMM requests a 182 M-BFD session for all interfaces that are configured to be components 183 of the LAG interface. 185 A new interface status "BFD down" is defined. When the status of 186 interface is associated with the status of the BFD session that is 187 configured on the interface, if the BFD session is down, it will 188 notify the interface management module to set the status of interface 189 to "BFD down", and for upper layer protocols, the interface presents 190 as in down status. When the BFD session is UP, it will notify the 191 interface management module to clear the "BFD down" status. 193 Once a LAG component link has reached the "BFD up" status it becomes 194 an active part of the Bundle. When the status changes to "BFD down" 195 the component link is removed from the Bundle. For this to work it 196 is mandatory that whatever the status of an interface is, "BFD down" 197 or not, the BFD packet transmission and reception is not impacted by 198 this status. 200 5. Security Consideration 202 This document does not introduce any additional security issues and 203 the security mechanisms defined in [RFC5880] apply in this document. 205 6. IANA Considerations 207 The IANA is required to assign a well-known multicast IP address: 208 "224.XXX.XXX.XXX". 210 7. Acknowledgements 212 8. References 213 8.1. Normative References 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 219 (BFD)", RFC 5880, June 2010. 221 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 222 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 223 June 2010. 225 8.2. Informative References 227 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 229 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 230 Protocol 4 (BGP-4)", RFC 4271, January 2006. 232 Authors' Addresses 234 Mach(Guoyi) Chen 235 Huawei Technologies Co.,Ltd 236 No. 3 Xinxi Road, Shang-di, Hai-dian District 237 Beijing, 100085 238 China 240 Email: mach@huawei.com 242 Zuliang Wang 243 Huawei Technologies Co.,Ltd 244 No. 3 Xinxi Road, Shang-di, Hai-dian District 245 Beijing, 100085 246 China 248 Email: liang_tsing@huawei.com 250 Liang Guo 251 China Telecom 252 Guangzhou 253 Guangzhou 254 China 256 Email: guoliang@gsta.com 257 Marc Binderberger 258 Lausanne, 259 Switzerland 261 Email: marc@sniff.de