idnits 2.17.1 draft-mmm-bfd-on-lags-07.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 (April 11, 2013) is 4005 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 397, 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: October 13, 2013 Huawei Technologies 6 S. Boutros, Ed. 7 M. Binderberger, Ed. 8 Cisco Systems 9 J. Haas, Ed. 10 Juniper Networks 11 April 11, 2013 13 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) 14 Interfaces 15 draft-mmm-bfd-on-lags-07 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 October 13, 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. LAG Management Module . . . . . . . . . . . . . . . . . . . . 6 78 3.1. Interaction between LAG and BFD . . . . . . . . . . . . . 6 79 3.2. Handling Exceptions . . . . . . . . . . . . . . . . . . . 7 80 4. BFD on LAG members and layer-3 applications . . . . . . . . . 8 81 5. Detecting a member link failure . . . . . . . . . . . . . . . 8 82 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 85 9. Contributing authors . . . . . . . . . . . . . . . . . . . . . 9 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] 94 provides a mechanism to detect faults in the bidirectional path 95 between two forwarding engines, including interfaces, data link(s), 96 and to the extent possible the forwarding engines themselves, with 97 potentially very low latency. The BFD protocol also provides a fast 98 mechanism for detecting communication failures on any data links and 99 the protocol can run over any media and at any protocol layer. 101 Link aggregation (LAG) as defined in [IEEE802.1AX] provides 102 mechanisms to combine multiple physical links into a single logical 103 link. This logical link provides higher bandwidth and better 104 resiliency since if one of the physical member links fails the 105 aggregate logical link can continue to forward traffic over the 106 remaining operational physical member links. 108 Currently, the Link Aggregation Control Protocol (LACP) is used to 109 detect failures on a per physical member link. However, the use of 110 BFD for failure detection would (1) provide a faster detection (2) 111 provide detection in the absence of LACP (3) and would be able to 112 verify L3 Continuity per member link. 114 Running a single BFD session over the aggregation without internal 115 knowledge of the member links would make it impossible for BFD to 116 guarantee detection of the physical member link failures. 118 The goal is to verify link Continuity for every member link. This 119 corresponds to [RFC5882], section 7.3. 121 The approach taken in this document is to run a Asynchronous mode BFD 122 session over each member link and make BFD control whether the member 123 link should be part of the L2 Loadbalance table of the LAG virtual 124 port in the presence or the absence of LACP. 126 This document describes how to establish an Asynchronous mode BFD 127 session per physical member link of the LAG virtual port. 129 While there are native Ethernet mechanisms to detect failures 130 (802.1ax, .3ah) that could be used for LAG, the solution proposed in 131 this document enables operators who have already deployed BFD over 132 different technologies (e.g. IP, MPLS) to use a common failure 133 detection mechanism. 135 2. BFD on LAG member links 137 The mechanism proposed for a fast detection of LAG member link 138 failure is to run Asynchronous mode BFD sessions on every LAG member 139 link. We call these per LAG member link BFD sessions "micro BFD 140 sessions" in the remainder of this document. 142 2.1. Micro BFD session address family 144 Member link micro BFD sessions, when using IP/UDP encapsulation, can 145 use IPv4 or IPv6 addresses. Two micro sessions MAY exist per member 146 link, one IPv4, another IPv6. When an address family is used on one 147 member link then it MUST be used on all member links of the 148 particular LAG. 150 2.2. Micro BFD session negotiation 152 A single micro BFD session for every enabled address family runs on 153 each member link of the LAG. The micro BFD session's negotiation 154 MUST follow the same procedures defined in [RFC5880] and [RFC5881]. 156 Only Asynchronous mode BFD is considered in this document; the use of 157 the BFD echo function is outside the scope of this document. At 158 least one system MUST take the Active role (possibly both). The 159 micro BFD sessions on the member links are independent BFD sessions: 160 They use their own unique local discriminator values, maintain their 161 own set of state variables and have their own independent state 162 machines. Timer values MAY be different, even among the micro BFD 163 sessions belonging to the same aggregation, although it is expected 164 that micro BFD sessions belonging to the same aggregation will use 165 the same timer values. 167 The demultiplexing of a received BFD packet is solely based on the 168 Your Discriminator field, if this field is nonzero. For the initial 169 Down BFD packets of a BFD session this value MAY be zero. In this 170 case demultiplexing MUST be based on some combination of other fields 171 which MUST include the interface information of the member link. 173 The procedure for the Reception of BFD Control Packets in Section 174 6.8.6 of [RFC5880] is amended as follows for per member link micro 175 BFD over LAG sessions: "If the Your Discriminator field is non-zero 176 and a micro BFD over LAG session is found, the interface on which the 177 micro BFD control packet arrived on MUST correspond to the interface 178 associated with that session." 180 This document defines the BFD Control packets for each micro BFD 181 session to be IP/UDP encapsulated as defined in [RFC5881], but with a 182 new UDP destination port 6784. 184 Control packets use a destination IP address that is configured on 185 the peer system and can be reached via the LAG interface. The 186 details of how this destination IP address is learned are outside the 187 scope of this document. 189 2.3. Micro BFD session Ethernet details 191 On Ethernet-based LAG member links the destination MAC is the 192 dedicated multicast MAC address 01-00-5E-90-00-01 to be the immediate 193 next hop. This dedicated MAC address MUST be used for the initial 194 BFD packets of a micro BFD session when in the Down/AdminDown and 195 Init state. When a micro BFD session is changing into Up state then 196 the first bfd.DetectMult packets with Up state MUST be sent with the 197 dedicated MAC. For the following BFD packets with Up state the MAC 198 address from the received BFD packets for the session MAY be used 199 instead of the dedicated MAC. 201 All implementations MUST be able to send and receive BFD packets in 202 Up state using the dedicated MAC address. Implementations supporting 203 both, sending BFD Up packets with the dedicated and the received MAC 204 need to offer means to control the behaviour. 206 On Ethernet-based LAG member links the source MAC SHOULD be the MAC 207 address of the port transmitting the packet. 209 This mechanism helps to reduce the use of additional MAC addresses, 210 which reduces the required resources on the Ethernet hardware on the 211 receiving port. 213 Micro BFD packets SHOULD always be sent untagged. However, when the 214 LAG is operating in the context of IEEE 802.1q or IEEE 802.qinq, the 215 micro BFD packets may either be untagged or sent with a vlan tag of 216 Zero (802.1p priority tagged). Implementations compliant to this 217 standard MUST be able to receive both untagged and 802.1p priority 218 tagged micro BFD packets. 220 3. LAG Management Module 222 3.1. Interaction between LAG and BFD 224 The LAG Management Module (LMM) could be envisaged as a client of 225 BFD; i.e. the LMM requests the micro BFD sessions per member link. 226 The LMM then uses the micro BFD session state, in addition to LACP 227 state, to monitor the health of the individual members links of the 228 LAG. 230 The micro BFD sessions for a particular port MUST be requested when a 231 member port state is either Distributing or Standby. The sessions 232 MUST be deleted when the member port is neither in Distributing nor 233 in Standby state anymore. 235 BFD is used to control if the load balance algorithm is able to 236 select a particular port. In other words, even when LACP is used and 237 considers the member link to be ready to forward traffic, the member 238 link is only used by the load balancer when all the micro BFD 239 sessions of the member link are Up. 241 In case an implementation has separate load balance tables for IPv4 242 and IPv6 then if both an IPv4 and IPv6 micro session exist for a 243 member link an implementation MAY enable the member link in the 244 distribution algorithm only when the BFD session with a matching 245 address family is changing into Up state. 247 An exception are the BFD packets itself. Implementations MAY receive 248 and transmit BFD packets via the Aggregator's MAC service interface 249 independent of the session state. 251 3.2. Handling Exceptions 253 If the BFD over LAG feature were provisioned on an aggregated link 254 member after the link was already active within a LAG, BFD session 255 state SHOULD NOT influence the load balance algorithm until the BFD 256 session state transitions to Up. If the BFD session never 257 transitions to Up but the LAG becomes inactive, the previously 258 documented procedures would then normally apply. 260 If the BFD over LAG feature were deprovisioned on an aggregate link 261 member after the BFD session had transitioned to Up, BFD MAY indicate 262 to the remote port that it should not take the port down or remove it 263 from the aggregation by setting its BFD session state to AdminDown. 265 When a micro BFD session receives AdminDown from the peer, it is 266 RECOMMENDED to have a configurable timeout value. If the BFD session 267 has not been removed within the timeout period the link is taken out 268 of forwarding. 270 When traffic is forwarded across a link before the corresponding 271 micro BFD session is Up it is RECOMMENDED to have a configurable 272 timeout value after which the BFD session must have reached Up state 273 or otherwise the link is taken out of forwarding. 275 Note that if one device is not operating a micro BFD session on a 276 link, while the other device is and perceives the session to be Down, 277 this will result in the two devices having a different view of the 278 status of the link. This would likely lead to traffic loss across 279 the LAG. 281 The use of another protocol to bootstrap BFD can detect such 282 mismatched config, since the side that's not configured can send a 283 rejection error. Such bootstrapping mechanisms are outside the scope 284 of this document. 286 4. BFD on LAG members and layer-3 applications 288 The mechanism described in this document is likely to be used by 289 modules like LMM or some Interface management module. Typical layer 290 3 protocols like OSPF do not have an insight into the LAG and treat 291 it as one bigger interface. The signalling from micro sessions to 292 layer 3 protocols is effectively done by the impact of BFD micro 293 sessions on the load balance table and the LMM's potential decision 294 to shut down the LAG. An active method to test the impact of micro 295 sessions is for layer 3 protocols to request a single BFD session per 296 LAG. 298 5. Detecting a member link failure 300 When a micro BFD session goes down then this member link MUST be 301 taken out of the LAG L2 load balance table(s). 303 In case an implementation has separate load balance tables for IPv4 304 and IPv6 then if both an IPv4 and IPv6 micro session exist for a 305 member link an implementation MAY remove the member link from the 306 load balance table only that matches the address family of the 307 failing BFD session. If for example the IPv4 micro session fails but 308 the IPv6 micro session stays up then the member link MAY be removed 309 from the IPv4 load balance table only but remains forwarding in the 310 IPv6 load balance table. 312 6. Security Consideration 314 This document does not introduce any additional security issues and 315 the security mechanisms defined in [RFC5880] apply in this document. 317 7. IANA Considerations 319 IANA assigned a dedicated MAC address 01-00-5E-90-00-01 as well as 320 UDP port 6784 for UDP encapsulated micro BFD sessions. 322 8. Acknowledgements 324 We would like to thank Dave Katz, Alexander Vainshtein, Greg Mirsky 325 and Jeff Tantsura for their comments. 327 The initial event to start the current discussion was the 328 distribution of draft-chen-bfd-interface-00. 330 9. Contributing authors 332 Paul Hitchen 333 BT 334 Email: paul.hitchen@bt.com 336 George Swallow 337 Cisco Systems 338 Email: swallow@cisco.com 340 Wim Henderickx 341 Alcatel-Lucent 342 Email: wim.henderickx@alcatel-lucent.com 344 Nobo Akiya 345 Cisco Systems 346 Email: nobo@cisco.com 348 Neil Ketley 349 Cisco Systems 350 Email: nketley@cisco.com 352 Carlos Pignataro 353 Cisco Systems 354 Email: cpignata@cisco.com 356 Nitin Bahadur 357 Juniper Networks 358 Email: nitinb@juniper.net 360 Zuliang Wang 361 Huawei Technologies 362 Email: liang_tsing@huawei.com 364 Liang Guo 365 China Telecom 366 Email: guoliang@gsta.com 368 Jeff Tantsura 369 Ericsson 370 Email: jeff.tantsura@ericsson.com 372 10. References 374 10.1. Normative References 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 380 (BFD)", RFC 5880, June 2010. 382 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 383 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 384 June 2010. 386 [RFC5882] Katz, D. and D. Ward, "Generic Application of 387 Bidirectional Forwarding Detection (BFD)", RFC 5882, 388 June 2010. 390 10.2. Informative References 392 [IEEE802.1AX] 393 IEEE Std. 802.1AX, "IEEE Standard for Local and 394 metropolitan area networks - Link Aggregation", 395 November 2008. 397 [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage 398 for IEEE 802 Parameters", BCP 141, RFC 5342, 399 September 2008. 401 Authors' Addresses 403 Manav Bhatia (editor) 404 Alcatel-Lucent 405 Bangalore 560045 406 India 408 Email: manav.bhatia@alcatel-lucent.com 409 Mach(Guoyi) Chen (editor) 410 Huawei Technologies 411 Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District 412 Beijing 100095 413 China 415 Email: mach@huawei.com 417 Sami Boutros (editor) 418 Cisco Systems 420 Email: sboutros@cisco.com 422 Marc Binderberger (editor) 423 Cisco Systems 425 Email: mbinderb@cisco.com 427 Jeffrey Haas (editor) 428 Juniper Networks 430 Email: jhaas@juniper.net