idnits 2.17.1 draft-ietf-bfd-on-lags-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 13, 2013) is 3963 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) == Unused Reference: 'RFC5342' is defined on line 353, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5342 (Obsoleted by RFC 7042) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bhatia, Ed. 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track M. Chen, Ed. 5 Expires: December 15, 2013 Huawei Technologies 6 S. Boutros, Ed. 7 M. Binderberger, Ed. 8 Cisco Systems 9 J. Haas, Ed. 10 Juniper Networks 11 June 13, 2013 13 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) 14 Interfaces 15 draft-ietf-bfd-on-lags-01 17 Abstract 19 This document proposes a mechanism to run BFD on Link Aggregation 20 Group (LAG) interfaces. It does so by running an independent 21 Asynchronous mode BFD session on every LAG member link. 23 This mechanism allows the verification of member link continuity, 24 either in combination with, or in absence of, LACP. It provides a 25 shorter detection time than what LACP offers. The continuity check 26 can also cover elements of layer 3 bidirectional forwarding. 28 This mechanism utilizes a well-known UDP port distinct from that of 29 single-hop BFD over IP. This new UDP port removes the ambiguity of 30 BFD over LAG packets from BFD over single-hop IP. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 15, 2013. 55 Copyright Notice 57 Copyright (c) 2013 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. BFD on LAG member links . . . . . . . . . . . . . . . . . . . 4 74 2.1. Micro BFD session address family . . . . . . . . . . . . . 5 75 2.2. Micro BFD session negotiation . . . . . . . . . . . . . . 5 76 2.3. Micro BFD session Ethernet details . . . . . . . . . . . . 6 77 3. Interaction between LAG and BFD . . . . . . . . . . . . . . . 6 78 4. BFD on LAG member links and layer-3 applications . . . . . . . 7 79 5. Detecting a member link failure . . . . . . . . . . . . . . . 7 80 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 7 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 83 9. Contributing authors . . . . . . . . . . . . . . . . . . . . . 8 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 87 Appendix A. Considerations when using BFD on member links . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] 93 provides a mechanism to detect faults in the bidirectional path 94 between two forwarding engines, including interfaces, data link(s), 95 and to the extent possible the forwarding engines themselves, with 96 potentially very low latency. The BFD protocol also provides a fast 97 mechanism for detecting communication failures on any data links and 98 the protocol can run over any media and at any protocol layer. 100 Link aggregation (LAG) as defined in [IEEE802.1AX] provides 101 mechanisms to combine multiple physical links into a single logical 102 link. This logical link provides higher bandwidth and better 103 resiliency since if one of the physical member links fails the 104 aggregate logical link can continue to forward traffic over the 105 remaining operational physical member links. 107 Currently, the Link Aggregation Control Protocol (LACP) is used to 108 detect failures on a per physical member link. However, the use of 109 BFD for failure detection would (1) provide a faster detection (2) 110 provide detection in the absence of LACP (3) and would be able to 111 verify L3 Continuity per member link. 113 Running a single BFD session over the aggregation without internal 114 knowledge of the member links would make it impossible for BFD to 115 guarantee detection of the physical member link failures. 117 The goal is to verify link Continuity for every member link. This 118 corresponds to [RFC5882], section 7.3. 120 The approach taken in this document is to run a Asynchronous mode BFD 121 session over each LAG member link and make BFD control whether the 122 LAG member link should be part of the L2 Loadbalance table of the LAG 123 interface in the presence or the absence of LACP. 125 This document describes how to establish an Asynchronous mode BFD 126 session per physical LAG member link of the LAG interface. 128 While there are native Ethernet mechanisms to detect failures 129 (802.1ax, .3ah) that could be used for LAG, the solution proposed in 130 this document enables operators who have already deployed BFD over 131 different technologies (e.g. IP, MPLS) to use a common failure 132 detection mechanism. 134 2. BFD on LAG member links 136 The mechanism proposed for a fast detection of LAG member link 137 failure is to run Asynchronous mode BFD sessions on every LAG member 138 link. We call these per LAG member link BFD sessions "micro BFD 139 sessions" in the remainder of this document. 141 2.1. Micro BFD session address family 143 Member link micro BFD sessions, when using IP/UDP encapsulation, can 144 use IPv4 or IPv6 addresses. Two micro sessions MAY exist per member 145 link, one IPv4, another IPv6. When an address family is used on one 146 member link then it MUST be used on all member links of the 147 particular LAG. 149 2.2. Micro BFD session negotiation 151 A single micro BFD session for every enabled address family runs on 152 each member link of the LAG. The micro BFD session's negotiation 153 MUST follow the same procedures defined in [RFC5880] and [RFC5881]. 155 Only Asynchronous mode BFD is considered in this document; the use of 156 the BFD echo function is outside the scope of this document. At 157 least one system MUST take the Active role (possibly both). The 158 micro BFD sessions on the member links are independent BFD sessions: 159 They use their own unique local discriminator values, maintain their 160 own set of state variables and have their own independent state 161 machines. Timer values MAY be different, even among the micro BFD 162 sessions belonging to the same aggregation, although it is expected 163 that micro BFD sessions belonging to the same aggregation will use 164 the same timer values. 166 The demultiplexing of a received BFD packet is solely based on the 167 Your Discriminator field, if this field is nonzero. For the initial 168 Down BFD packets of a BFD session this value MAY be zero. In this 169 case demultiplexing MUST be based on some combination of other fields 170 which MUST include the interface information of the member link. 172 The procedure for the Reception of BFD Control Packets in Section 173 6.8.6 of [RFC5880] is amended as follows for per LAG member link 174 micro BFD sessions: "If the Your Discriminator field is non-zero and 175 a micro BFD over LAG session is found, the interface on which the 176 micro BFD control packet arrived on MUST correspond to the interface 177 associated with that session." 179 This document defines the BFD Control packets for each micro BFD 180 session to be IP/UDP encapsulated as defined in [RFC5881], but with a 181 new UDP destination port 6784. 183 Control packets use a destination IP address that is configured on 184 the peer system and can be reached via the LAG interface. The 185 details of how this destination IP address is learned are outside the 186 scope of this document. 188 2.3. Micro BFD session Ethernet details 190 On Ethernet-based LAG member links the destination MAC is the 191 dedicated multicast MAC address 01-00-5E-90-00-01 to be the immediate 192 next hop. This dedicated MAC address MUST be used for the initial 193 BFD packets of a micro BFD session when in the Down/AdminDown and 194 Init state. When a micro BFD session is changing into Up state then 195 the first bfd.DetectMult packets with Up state MUST be sent with the 196 dedicated MAC. For the following BFD packets with Up state the MAC 197 address from the received BFD packets for the session MAY be used 198 instead of the dedicated MAC. 200 All implementations MUST be able to send and receive BFD packets in 201 Up state using the dedicated MAC address. Implementations supporting 202 both, sending BFD Up packets with the dedicated and the received MAC, 203 need to offer means to control the behaviour. 205 On Ethernet-based LAG member links the source MAC SHOULD be the MAC 206 address of the member link transmitting the packet. 208 This mechanism helps to reduce the use of additional MAC addresses, 209 which reduces the required resources on the Ethernet hardware on the 210 receiving member link. 212 Micro BFD packets SHOULD always be sent untagged. However, when the 213 LAG is operating in the context of IEEE 802.1q or IEEE 802.qinq, the 214 micro BFD packets may either be untagged or sent with a vlan tag of 215 Zero (802.1p priority tagged). Implementations compliant to this 216 standard MUST be able to receive both untagged and 802.1p priority 217 tagged micro BFD packets. 219 3. Interaction between LAG and BFD 221 The micro BFD sessions for a particular LAG member link MUST be 222 requested when a member link state is either Distributing or Standby. 223 The sessions MUST be deleted when the member link is neither in 224 Distributing nor in Standby state anymore. 226 BFD is used to control if the load balance algorithm is able to 227 select a particular LAG member link. In other words, even when LACP 228 is used and considers the member link to be ready to forward traffic, 229 the member link MUST NOT be used by the load balancer until all the 230 micro BFD sessions of the particular member link are in Up state. 232 In case an implementation has separate load balance tables for IPv4 233 and IPv6 and if both an IPv4 and IPv6 micro session exist for a 234 member link then an implementation MAY enable the member link in the 235 load balance algorithm based on the BFD session with a matching 236 address family alone. 238 An exception is the BFD packet itself. Implementations MAY receive 239 and transmit BFD packets via the Aggregator's MAC service interface 240 independent of the session state. 242 4. BFD on LAG member links and layer-3 applications 244 The mechanism described in this document is likely to be used by 245 modules like LMM or some Interface management module. Typical layer 246 3 protocols like OSPF do not have an insight into the LAG and treat 247 it as one bigger interface. The signaling from micro sessions to 248 layer 3 protocols is effectively done by the impact of BFD micro 249 sessions on the load balance table and the LMM's potential decision 250 to shut down the LAG. An active method to test the impact of micro 251 sessions is for layer 3 protocols to request a single BFD session per 252 LAG. 254 5. Detecting a member link failure 256 When a micro BFD session goes down then this member link MUST be 257 taken out of the LAG L2 load balance table(s). 259 In case an implementation has separate load balance tables for IPv4 260 and IPv6 then if both an IPv4 and IPv6 micro session exist for a 261 member link an implementation MAY remove the member link from the 262 load balance table only that matches the address family of the 263 failing BFD session. If for example the IPv4 micro session fails but 264 the IPv6 micro session stays Up then the member link MAY be removed 265 from the IPv4 load balance table only but remains forwarding in the 266 IPv6 load balance table. 268 6. Security Consideration 270 This document does not introduce any additional security issues and 271 the security mechanisms defined in [RFC5880] apply in this document. 273 7. IANA Considerations 275 IANA assigned a dedicated MAC address 01-00-5E-90-00-01 as well as 276 UDP port 6784 for UDP encapsulated micro BFD sessions. 278 8. Acknowledgements 280 We would like to thank Dave Katz, Alexander Vainshtein, Greg Mirsky 281 and Jeff Tantsura for their comments. 283 The initial event to start the current discussion was the 284 distribution of draft-chen-bfd-interface-00. 286 9. Contributing authors 288 Paul Hitchen 289 BT 290 Email: paul.hitchen@bt.com 292 George Swallow 293 Cisco Systems 294 Email: swallow@cisco.com 296 Wim Henderickx 297 Alcatel-Lucent 298 Email: wim.henderickx@alcatel-lucent.com 300 Nobo Akiya 301 Cisco Systems 302 Email: nobo@cisco.com 304 Neil Ketley 305 Cisco Systems 306 Email: nketley@cisco.com 308 Carlos Pignataro 309 Cisco Systems 310 Email: cpignata@cisco.com 312 Nitin Bahadur 313 Juniper Networks 314 Email: nitinb@juniper.net 316 Zuliang Wang 317 Huawei Technologies 318 Email: liang_tsing@huawei.com 320 Liang Guo 321 China Telecom 322 Email: guoliang@gsta.com 324 Jeff Tantsura 325 Ericsson 326 Email: jeff.tantsura@ericsson.com 328 10. References 330 10.1. Normative References 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, March 1997. 335 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 336 (BFD)", RFC 5880, June 2010. 338 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 339 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 340 June 2010. 342 [RFC5882] Katz, D. and D. Ward, "Generic Application of 343 Bidirectional Forwarding Detection (BFD)", RFC 5882, 344 June 2010. 346 10.2. Informative References 348 [IEEE802.1AX] 349 IEEE Std. 802.1AX, "IEEE Standard for Local and 350 metropolitan area networks - Link Aggregation", 351 November 2008. 353 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 354 for IEEE 802 Parameters", BCP 141, RFC 5342, 355 September 2008. 357 Appendix A. Considerations when using BFD on member links 359 If the BFD over LAG feature were provisioned on an aggregated link 360 member after the link was already active within a LAG, BFD session 361 state SHOULD NOT influence the load balance algorithm until the BFD 362 session state transitions to Up. If the BFD session never 363 transitions to Up but the LAG becomes inactive, the previously 364 documented procedures would then normally apply. 366 This procedure ensures that the sequence of events - enabling the LAG 367 and enabling BFD on the LAG - has no impact on the forwarding 368 service. 370 If the BFD over LAG feature was deprovisioned on an aggregate link 371 member while the associated micro BFD session was in Up state, BFD 372 SHOULD transition its state to AdminDown and SHOULD attempt to 373 communicate this state change to the peer. 375 If the local or the remote state of a micro BFD session is AdminDown 376 the system SHOULD NOT indicate a connectivity failure to any client 377 and SHOULD NOT remove the particular LAG member link from forwarding. 378 This behaviour is independent from the use of LACP for the LAG. 380 When traffic is forwarded across a link while the corresponding micro 381 BFD session is not in Up state an implementation MAY use a 382 configurable timeout value after which the BFD session must have 383 reached Up state or otherwise the link is taken out of forwarding. 385 When such timeout values exist then the configuration MUST allow to 386 turn off the timeout function. 388 The configurable timeout value shall ensure that a LAG is not 389 remaining forever in an "inconsistent" state where forwarding occurs 390 on a link with no confirmation from the micro BFD session that the 391 link is healthy. 393 Note that if one device is not operating a micro BFD session on a 394 link, while the other device is and perceives the session to be Down, 395 this will result in the two devices having a different view of the 396 status of the link. This would likely lead to traffic loss across 397 the LAG. The use of another protocol to bootstrap BFD can detect 398 such mismatched config, since the side that's not configured can send 399 a rejection error. Such bootstrapping mechanisms are outside the 400 scope of this document. 402 Authors' Addresses 404 Manav Bhatia (editor) 405 Alcatel-Lucent 406 Bangalore 560045 407 India 409 Email: manav.bhatia@alcatel-lucent.com 410 Mach(Guoyi) Chen (editor) 411 Huawei Technologies 412 Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District 413 Beijing 100095 414 China 416 Email: mach@huawei.com 418 Sami Boutros (editor) 419 Cisco Systems 421 Email: sboutros@cisco.com 423 Marc Binderberger (editor) 424 Cisco Systems 426 Email: mbinderb@cisco.com 428 Jeffrey Haas (editor) 429 Juniper Networks 431 Email: jhaas@juniper.net