idnits 2.17.1 draft-ietf-bfd-on-lags-02.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 (November 11, 2013) is 3813 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) -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: May 15, 2014 Huawei Technologies 6 S. Boutros, Ed. 7 M. Binderberger, Ed. 8 Cisco Systems 9 J. Haas, Ed. 10 Juniper Networks 11 November 11, 2013 13 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) 14 Interfaces 15 draft-ietf-bfd-on-lags-02 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 May 15, 2014. 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 (see 277 [RFC7042]) as well as UDP port 6784 for UDP encapsulated micro BFD 278 sessions. 280 8. Acknowledgements 282 We would like to thank Dave Katz, Alexander Vainshtein, Greg Mirsky 283 and Jeff Tantsura for their comments. 285 The initial event to start the current discussion was the 286 distribution of draft-chen-bfd-interface-00. 288 9. Contributing authors 290 Paul Hitchen 291 BT 292 Email: paul.hitchen@bt.com 294 George Swallow 295 Cisco Systems 296 Email: swallow@cisco.com 298 Wim Henderickx 299 Alcatel-Lucent 300 Email: wim.henderickx@alcatel-lucent.com 302 Nobo Akiya 303 Cisco Systems 304 Email: nobo@cisco.com 306 Neil Ketley 307 Cisco Systems 308 Email: nketley@cisco.com 310 Carlos Pignataro 311 Cisco Systems 312 Email: cpignata@cisco.com 314 Nitin Bahadur 315 Juniper Networks 316 Email: nitinb@juniper.net 318 Zuliang Wang 319 Huawei Technologies 320 Email: liang_tsing@huawei.com 322 Liang Guo 323 China Telecom 324 Email: guoliang@gsta.com 326 Jeff Tantsura 327 Ericsson 328 Email: jeff.tantsura@ericsson.com 330 10. References 332 10.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, March 1997. 337 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 338 (BFD)", RFC 5880, June 2010. 340 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 341 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 342 June 2010. 344 [RFC5882] Katz, D. and D. Ward, "Generic Application of 345 Bidirectional Forwarding Detection (BFD)", RFC 5882, 346 June 2010. 348 10.2. Informative References 350 [IEEE802.1AX] 351 IEEE Std. 802.1AX, "IEEE Standard for Local and 352 metropolitan area networks - Link Aggregation", 353 November 2008. 355 [RFC7042] Eastlake, D. and J. Abley, "IANA Considerations and IETF 356 Protocol and Documentation Usage for IEEE 802 Parameters", 357 BCP 141, RFC 7042, October 2013. 359 Appendix A. Considerations when using BFD on member links 361 If the BFD over LAG feature were provisioned on an aggregated link 362 member after the link was already active within a LAG, BFD session 363 state SHOULD NOT influence the load balance algorithm until the BFD 364 session state transitions to Up. If the BFD session never 365 transitions to Up but the LAG becomes inactive, the previously 366 documented procedures would then normally apply. 368 This procedure ensures that the sequence of events - enabling the LAG 369 and enabling BFD on the LAG - has no impact on the forwarding 370 service. 372 If the BFD over LAG feature was deprovisioned on an aggregate link 373 member while the associated micro BFD session was in Up state, BFD 374 SHOULD transition its state to AdminDown and SHOULD attempt to 375 communicate this state change to the peer. 377 If the local or the remote state of a micro BFD session is AdminDown 378 the system SHOULD NOT indicate a connectivity failure to any client 379 and SHOULD NOT remove the particular LAG member link from forwarding. 380 This behaviour is independent from the use of LACP for the LAG. 382 When traffic is forwarded across a link while the corresponding micro 383 BFD session is not in Up state an implementation MAY use a 384 configurable timeout value after which the BFD session must have 385 reached Up state or otherwise the link is taken out of forwarding. 387 When such timeout values exist then the configuration MUST allow to 388 turn off the timeout function. 390 The configurable timeout value shall ensure that a LAG is not 391 remaining forever in an "inconsistent" state where forwarding occurs 392 on a link with no confirmation from the micro BFD session that the 393 link is healthy. 395 Note that if one device is not operating a micro BFD session on a 396 link, while the other device is and perceives the session to be Down, 397 this will result in the two devices having a different view of the 398 status of the link. This would likely lead to traffic loss across 399 the LAG. The use of another protocol to bootstrap BFD can detect 400 such mismatched config, since the side that's not configured can send 401 a rejection error. Such bootstrapping mechanisms are outside the 402 scope of this document. 404 Authors' Addresses 406 Manav Bhatia (editor) 407 Alcatel-Lucent 408 Bangalore 560045 409 India 411 Email: manav.bhatia@alcatel-lucent.com 412 Mach(Guoyi) Chen (editor) 413 Huawei Technologies 414 Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District 415 Beijing 100095 416 China 418 Email: mach@huawei.com 420 Sami Boutros (editor) 421 Cisco Systems 423 Email: sboutros@cisco.com 425 Marc Binderberger (editor) 426 Cisco Systems 428 Email: mbinderb@cisco.com 430 Jeffrey Haas (editor) 431 Juniper Networks 433 Email: jhaas@juniper.net