idnits 2.17.00 (12 Aug 2021) /tmp/idnits57500/draft-ietf-bfd-on-lags-04.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 (December 18, 2013) is 3069 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) == Missing Reference: 'RFC-to-be' is mentioned on line 296, but not defined == Missing Reference: 'IESG' is mentioned on line 294, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: June 21, 2014 Huawei Technologies 6 S. Boutros, Ed. 7 M. Binderberger, Ed. 8 Cisco Systems 9 J. Haas, Ed. 10 Juniper Networks 11 December 18, 2013 13 Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) 14 Interfaces 15 draft-ietf-bfd-on-lags-04 17 Abstract 19 This document defines 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, Link Aggregation 25 Control Protocol (LACP). It provides a shorter detection time than 26 what LACP offers. The continuity check can also cover elements of 27 layer 3 bidirectional forwarding. 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 June 21, 2014. 51 Copyright Notice 53 Copyright (c) 2013 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. BFD on LAG member links . . . . . . . . . . . . . . . . . . . 5 70 2.1. Micro BFD session address family . . . . . . . . . . . . . 5 71 2.2. Micro BFD session negotiation . . . . . . . . . . . . . . 5 72 2.3. Micro BFD session Ethernet details . . . . . . . . . . . . 6 73 3. Interaction between LAG and BFD . . . . . . . . . . . . . . . 7 74 4. BFD on LAG member links and layer-3 applications . . . . . . . 7 75 5. Detecting a member link failure . . . . . . . . . . . . . . . 7 76 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 79 9. Contributing authors . . . . . . . . . . . . . . . . . . . . . 8 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 83 Appendix A. Considerations when using BFD on member links . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] 89 provides a mechanism to detect faults in the bidirectional path 90 between two forwarding engines, including interfaces, data link(s), 91 and to the extent possible the forwarding engines themselves, with 92 potentially very low latency. The BFD protocol also provides a fast 93 mechanism for detecting communication failures on any data links and 94 the protocol can run over any media and at any protocol layer. 96 Link aggregation (LAG) as defined in [IEEE802.1AX] provides 97 mechanisms to combine multiple physical links into a single logical 98 link. This logical link provides higher bandwidth and better 99 resiliency since if one of the physical member links fails the 100 aggregate logical link can continue to forward traffic over the 101 remaining operational physical member links. 103 Currently, the Link Aggregation Control Protocol (LACP) is used to 104 detect failures on a per physical member link. However, the use of 105 BFD for failure detection would (1) provide a faster detection (2) 106 provide detection in the absence of LACP (3) and would be able to 107 verify the ability for each member link to be able to forward L3 108 packets. 110 Running a single BFD session over the aggregation without internal 111 knowledge of the member links would make it impossible for BFD to 112 guarantee detection of the physical member link failures. 114 The goal is to verify link Continuity for every member link. This 115 corresponds to [RFC5882], section 7.3. 117 The approach taken in this document is to run a Asynchronous mode BFD 118 session over each LAG member link and make BFD control whether the 119 LAG member link should be part of the L2 Loadbalance table of the LAG 120 interface in the presence or the absence of LACP. 122 This document describes how to establish an Asynchronous mode BFD 123 session per physical LAG member link of the LAG interface. 125 While there are native Ethernet mechanisms to detect failures 126 (802.1ax, .3ah) that could be used for LAG, the solution defined in 127 this document enables operators who have already deployed BFD over 128 different technologies (e.g. IP, MPLS) to use a common failure 129 detection mechanism. 131 2. BFD on LAG member links 133 The mechanism defined for a fast detection of LAG member link failure 134 is to run Asynchronous mode BFD sessions on every LAG member link. 135 We call these per LAG member link BFD sessions "micro BFD sessions" 136 in the remainder of this document. 138 2.1. Micro BFD session address family 140 Member link micro BFD sessions, when using IP/UDP encapsulation, can 141 use IPv4 or IPv6 addresses. Two micro sessions MAY exist per member 142 link, one IPv4, another IPv6. When an address family is used on one 143 member link then it MUST be used on all member links of the 144 particular LAG. 146 2.2. Micro BFD session negotiation 148 A single micro BFD session for every enabled address family runs on 149 each member link of the LAG. The micro BFD session's negotiation 150 MUST follow the same procedures defined in [RFC5880] and [RFC5881]. 152 Only Asynchronous mode BFD is considered in this document; the use of 153 the BFD echo function is outside the scope of this document. At 154 least one system MUST take the Active role (possibly both). The 155 micro BFD sessions on the member links are independent BFD sessions: 156 They use their own unique local discriminator values, maintain their 157 own set of state variables and have their own independent state 158 machines. Timer values MAY be different, even among the micro BFD 159 sessions belonging to the same aggregation, although it is expected 160 that micro BFD sessions belonging to the same aggregation will use 161 the same timer values. 163 The demultiplexing of a received BFD packet is solely based on the 164 Your Discriminator field, if this field is nonzero. For the initial 165 Down BFD packets of a BFD session this value MAY be zero. In this 166 case demultiplexing MUST be based on some combination of other fields 167 which MUST include the interface information of the member link and 168 the destination UDP port of the received BFD packet. 170 The procedure for the Reception of BFD Control Packets in Section 171 6.8.6 of [RFC5880] is amended as follows for per LAG member link 172 micro BFD sessions: "If the Your Discriminator field is non-zero and 173 a micro BFD over LAG session is found, the interface on which the 174 micro BFD control packet arrived on MUST correspond to the interface 175 associated with that session." 177 This document defines the BFD Control packets for each micro BFD 178 session to be IP/UDP encapsulated as defined in [RFC5881], but with a 179 new UDP destination port 6784. 181 The new UDP port removes the ambiguity of BFD over LAG packets from 182 BFD over single-hop IP. An example is (mis-)configuring a LAG with 183 micro BFD sessions on one side but using a [RFC5881] BFD session for 184 the LAG (treated as a single interface) on the opposite side. 186 The procedures in this document MUST be used for BFD messages 187 addressed to port 6784 and MUST NOT be used for others ports assigned 188 in RFCs described other BFD modes. 190 Control packets use a destination IP address that is configured on 191 the peer system and can be reached via the LAG interface. 192 Implementations may range from explicitly configuring IP addresses 193 for the BFD sessions to out-of-band methods for learning the 194 destination IP address. The details are outside the scope of this 195 document. 197 2.3. Micro BFD session Ethernet details 199 On Ethernet-based LAG member links the destination MAC is the 200 dedicated multicast MAC address 01-00-5E-90-00-01 to be the immediate 201 next hop. This dedicated MAC address MUST be used for the initial 202 BFD packets of a micro BFD session when in the Down/AdminDown and 203 Init state. When a micro BFD session is changing into Up state then 204 the first bfd.DetectMult packets with Up state MUST be sent with the 205 dedicated MAC. For the following BFD packets with Up state the 206 source MAC address from the received BFD packets for the session MAY 207 be used instead of the dedicated MAC. 209 All implementations MUST be able to send and receive BFD packets in 210 Up state using the dedicated MAC address. Implementations supporting 211 both, sending BFD Up packets with the dedicated and the received MAC, 212 need to offer means to control the behaviour. 214 On Ethernet-based LAG member links the source MAC SHOULD be the MAC 215 address of the member link transmitting the packet. 217 This mechanism helps to reduce the use of additional MAC addresses, 218 which reduces the required resources on the Ethernet hardware on the 219 receiving member link. 221 Micro BFD packets SHOULD always be sent untagged. However, when the 222 LAG is operating in the context of IEEE 802.1q or IEEE 802.qinq, the 223 micro BFD packets may either be untagged or sent with a vlan tag of 224 Zero (802.1p priority tagged). Implementations compliant to this 225 standard MUST be able to receive both untagged and 802.1p priority 226 tagged micro BFD packets. 228 3. Interaction between LAG and BFD 230 The micro BFD sessions for a particular LAG member link MUST be 231 requested when a member link state is either Distributing or Standby. 232 The sessions MUST be deleted when the member link is neither in 233 Distributing nor in Standby state anymore. 235 BFD is used to control if the load balance algorithm is able to 236 select a particular LAG member link. In other words, even when Link 237 Aggregation Control Protocol (LACP) is used and considers the member 238 link to be ready to forward traffic, the member link MUST NOT be used 239 by the load balancer until all the micro BFD sessions of the 240 particular member link are in Up state. 242 In case an implementation has separate load balance tables for IPv4 243 and IPv6 and if both an IPv4 and IPv6 micro session exist for a 244 member link then an implementation MAY enable the member link in the 245 load balance algorithm based on the BFD session with a matching 246 address family alone. 248 An exception is the BFD packet itself. Implementations MAY receive 249 and transmit BFD packets via the Aggregator's MAC service interface 250 independent of the session state. 252 4. BFD on LAG member links and layer-3 applications 254 The mechanism described in this document is likely to be used by 255 modules managing Interfaces or Link aggregation groups and thus 256 managing the member links of a LAG. Typical layer 3 protocols like 257 OSPF do not have an insight into the LAG and treat it as one bigger 258 interface. The signaling from micro sessions to layer 3 protocols is 259 effectively done by the impact of BFD micro sessions on the load 260 balance table and the Interface/LAG managing module's potential 261 decision to shut down the LAG. An active method to test the impact 262 of micro sessions is for layer 3 protocols to request a single BFD 263 session per LAG. 265 5. Detecting a member link failure 267 When a micro BFD session goes down then this member link MUST be 268 taken out of the LAG L2 load balance table(s). 270 In case an implementation has separate load balance tables for IPv4 271 and IPv6 then if both an IPv4 and IPv6 micro session exist for a 272 member link an implementation MAY remove the member link only from 273 the load balance table that matches the address family of the failing 274 BFD session. For example the IPv4 micro session fails but the IPv6 275 micro session stays Up then the member link MAY be removed from only 276 the IPv4 load balance table; the link MAY remain in the IPv6 load 277 balancing table. Alternatively, the member link may be removed from 278 both the IPv4 and IPv6 load balancing tables. This decision is an 279 implementation detail. 281 6. Security Consideration 283 This document does not introduce any additional security issues and 284 the security mechanisms defined in [RFC5880] apply in this document. 286 7. IANA Considerations 288 IANA assigned a dedicated MAC address 01-00-5E-90-00-01 (see 289 [RFC7042]) as well as UDP port 6784 for Bidirectional Forwarding 290 Detection (BFD) on Link Aggregation Group (LAG) Interfaces. IANA is 291 requested to change the reference to [RFC-to-be]. 293 IANA is requested to change the registry for port 6784 to show the 294 Assignee as [IESG] and the Contact as [BFD Chairs]. The expansion of 295 [BFD Chairs] should be shown as "mailto:bfd-chairs@tools.ietf.org". 296 IANA is requested to change the reference to [RFC-to-be]. 298 8. Acknowledgements 300 We would like to thank Dave Katz, Alexander Vainshtein, Greg Mirsky 301 and Jeff Tantsura for their comments. 303 The initial event to start the current discussion was the 304 distribution of draft-chen-bfd-interface-00. 306 9. Contributing authors 308 Paul Hitchen 309 BT 310 Email: paul.hitchen@bt.com 312 George Swallow 313 Cisco Systems 314 Email: swallow@cisco.com 316 Wim Henderickx 317 Alcatel-Lucent 318 Email: wim.henderickx@alcatel-lucent.com 320 Nobo Akiya 321 Cisco Systems 322 Email: nobo@cisco.com 324 Neil Ketley 325 Cisco Systems 326 Email: nketley@cisco.com 328 Carlos Pignataro 329 Cisco Systems 330 Email: cpignata@cisco.com 332 Nitin Bahadur 333 Bracket Computing 334 Email: nitin@brkt.com 336 Zuliang Wang 337 Huawei Technologies 338 Email: liang_tsing@huawei.com 340 Liang Guo 341 China Telecom 342 Email: guoliang@gsta.com 344 Jeff Tantsura 345 Ericsson 346 Email: jeff.tantsura@ericsson.com 348 10. References 350 10.1. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 356 (BFD)", RFC 5880, June 2010. 358 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 359 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 360 June 2010. 362 [RFC5882] Katz, D. and D. Ward, "Generic Application of 363 Bidirectional Forwarding Detection (BFD)", RFC 5882, 364 June 2010. 366 10.2. Informative References 368 [IEEE802.1AX] 369 IEEE Std. 802.1AX, "IEEE Standard for Local and 370 metropolitan area networks - Link Aggregation", 371 November 2008. 373 [RFC7042] Eastlake, D. and J. Abley, "IANA Considerations and IETF 374 Protocol and Documentation Usage for IEEE 802 Parameters", 375 BCP 141, RFC 7042, October 2013. 377 Appendix A. Considerations when using BFD on member links 379 If the BFD over LAG feature were provisioned on an aggregated link 380 member after the link was already active within a LAG, BFD session 381 state should not influence the load balance algorithm until the BFD 382 session state transitions to Up. If the BFD session never 383 transitions to Up but the LAG becomes inactive, the previously 384 documented procedures would then normally apply. 386 This procedure ensures that the sequence of events - enabling the LAG 387 and enabling BFD on the LAG - has no impact on the forwarding 388 service. 390 If the BFD over LAG feature was deprovisioned on an aggregate link 391 member while the associated micro BFD session was in Up state, BFD 392 should transition its state to AdminDown and should attempt to 393 communicate this state change to the peer. 395 If the local or the remote state of a micro BFD session is AdminDown 396 the system should not indicate a connectivity failure to any client 397 and should not remove the particular LAG member link from forwarding. 398 This behaviour is independent from the use of Link Aggregation 399 Control Protocol (LACP) for the LAG. 401 When traffic is forwarded across a link while the corresponding micro 402 BFD session is not in Up state an implementation may use a 403 configurable timeout value after which the BFD session must have 404 reached Up state or otherwise the link is taken out of forwarding. 406 When such timeout values exist then the configuration must allow to 407 turn off the timeout function. 409 The configurable timeout value shall ensure that a LAG is not 410 remaining forever in an "inconsistent" state where forwarding occurs 411 on a link with no confirmation from the micro BFD session that the 412 link is healthy. 414 Note that if one device is not operating a micro BFD session on a 415 link, while the other device is and perceives the session to be Down, 416 this will result in the two devices having a different view of the 417 status of the link. This would likely lead to traffic loss across 418 the LAG. The use of another protocol to bootstrap BFD can detect 419 such mismatched config, since the side that's not configured can send 420 a rejection error. Such bootstrapping mechanisms are outside the 421 scope of this document. 423 Authors' Addresses 425 Manav Bhatia (editor) 426 Alcatel-Lucent 427 Bangalore 560045 428 India 430 Email: manav.bhatia@alcatel-lucent.com 432 Mach(Guoyi) Chen (editor) 433 Huawei Technologies 434 Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District 435 Beijing 100095 436 China 438 Email: mach@huawei.com 440 Sami Boutros (editor) 441 Cisco Systems 443 Email: sboutros@cisco.com 445 Marc Binderberger (editor) 446 Cisco Systems 448 Email: mbinderb@cisco.com 450 Jeffrey Haas (editor) 451 Juniper Networks 453 Email: jhaas@juniper.net