Network Working Group                                     M. Bhatia, Ed.
Internet-Draft                                            Alcatel-Lucent
Intended status: Standards Track                            M. Chen, Ed.
Expires: June 3, 21, 2014                               Huawei Technologies
                                                         S. Boutros, Ed.
                                                    M. Binderberger, Ed.
                                                           Cisco Systems
                                                            J. Haas, Ed.
                                                        Juniper Networks
                                                       November 30,
                                                       December 18, 2013

Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG)


   This document defines a mechanism to run BFD on Link Aggregation
   Group (LAG) interfaces.  It does so by running an independent
   Asynchronous mode BFD session on every LAG member link.

   This mechanism allows the verification of member link continuity,
   either in combination with, or in absence of, Link Aggregation
   Control Protocol (LACP).  It provides a shorter detection time than
   what LACP offers.  The continuity check can also cover elements of
   layer 3 bidirectional forwarding.

   This mechanism utilizes a well-known UDP port distinct from that of
   single-hop BFD over IP.  This new UDP port removes the ambiguity of
   BFD over LAG packets from BFD over single-hop IP.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   This Internet-Draft will expire on June 3, 21, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  BFD on LAG member links  . . . . . . . . . . . . . . . . . . .  4  5
     2.1.  Micro BFD session address family . . . . . . . . . . . . .  5
     2.2.  Micro BFD session negotiation  . . . . . . . . . . . . . .  5
     2.3.  Micro BFD session Ethernet details . . . . . . . . . . . .  6
   3.  Interaction between LAG and BFD  . . . . . . . . . . . . . . .  6  7
   4.  BFD on LAG member links and layer-3 applications . . . . . . .  7
   5.  Detecting a member link failure  . . . . . . . . . . . . . . .  7
   6.  Security Consideration . . . . . . . . . . . . . . . . . . . .  7  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7  8
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  Contributing authors . . . . . . . . . . . . . . . . . . . . .  8
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     10.2. Informative References . . . . . . . . . . . . . . . . . .  9 10
   Appendix A.  Considerations when using BFD on member links . . . .  9 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 11

1.  Introduction

   The Bidirectional Forwarding Detection (BFD) protocol [RFC5880]
   provides a mechanism to detect faults in the bidirectional path
   between two forwarding engines, including interfaces, data link(s),
   and to the extent possible the forwarding engines themselves, with
   potentially very low latency.  The BFD protocol also provides a fast
   mechanism for detecting communication failures on any data links and
   the protocol can run over any media and at any protocol layer.

   Link aggregation (LAG) as defined in [IEEE802.1AX] provides
   mechanisms to combine multiple physical links into a single logical
   link.  This logical link provides higher bandwidth and better
   resiliency since if one of the physical member links fails the
   aggregate logical link can continue to forward traffic over the
   remaining operational physical member links.

   Currently, the Link Aggregation Control Protocol (LACP) is used to
   detect failures on a per physical member link.  However, the use of
   BFD for failure detection would (1) provide a faster detection (2)
   provide detection in the absence of LACP (3) and would be able to
   verify L3 Continuity per the ability for each member link. link to be able to forward L3

   Running a single BFD session over the aggregation without internal
   knowledge of the member links would make it impossible for BFD to
   guarantee detection of the physical member link failures.

   The goal is to verify link Continuity for every member link.  This
   corresponds to [RFC5882], section 7.3.

   The approach taken in this document is to run a Asynchronous mode BFD
   session over each LAG member link and make BFD control whether the
   LAG member link should be part of the L2 Loadbalance table of the LAG
   interface in the presence or the absence of LACP.

   This document describes how to establish an Asynchronous mode BFD
   session per physical LAG member link of the LAG interface.

   While there are native Ethernet mechanisms to detect failures
   (802.1ax, .3ah) that could be used for LAG, the solution defined in
   this document enables operators who have already deployed BFD over
   different technologies (e.g.  IP, MPLS) to use a common failure
   detection mechanism.

2.  BFD on LAG member links

   The mechanism defined for a fast detection of LAG member link failure
   is to run Asynchronous mode BFD sessions on every LAG member link.
   We call these per LAG member link BFD sessions "micro BFD sessions"
   in the remainder of this document.

2.1.  Micro BFD session address family

   Member link micro BFD sessions, when using IP/UDP encapsulation, can
   use IPv4 or IPv6 addresses.  Two micro sessions MAY exist per member
   link, one IPv4, another IPv6.  When an address family is used on one
   member link then it MUST be used on all member links of the
   particular LAG.

2.2.  Micro BFD session negotiation

   A single micro BFD session for every enabled address family runs on
   each member link of the LAG.  The micro BFD session's negotiation
   MUST follow the same procedures defined in [RFC5880] and [RFC5881].

   Only Asynchronous mode BFD is considered in this document; the use of
   the BFD echo function is outside the scope of this document.  At
   least one system MUST take the Active role (possibly both).  The
   micro BFD sessions on the member links are independent BFD sessions:
   They use their own unique local discriminator values, maintain their
   own set of state variables and have their own independent state
   machines.  Timer values MAY be different, even among the micro BFD
   sessions belonging to the same aggregation, although it is expected
   that micro BFD sessions belonging to the same aggregation will use
   the same timer values.

   The demultiplexing of a received BFD packet is solely based on the
   Your Discriminator field, if this field is nonzero.  For the initial
   Down BFD packets of a BFD session this value MAY be zero.  In this
   case demultiplexing MUST be based on some combination of other fields
   which MUST include the interface information of the member link. link and
   the destination UDP port of the received BFD packet.

   The procedure for the Reception of BFD Control Packets in Section
   6.8.6 of [RFC5880] is amended as follows for per LAG member link
   micro BFD sessions: "If the Your Discriminator field is non-zero and
   a micro BFD over LAG session is found, the interface on which the
   micro BFD control packet arrived on MUST correspond to the interface
   associated with that session."

   This document defines the BFD Control packets for each micro BFD
   session to be IP/UDP encapsulated as defined in [RFC5881], but with a
   new UDP destination port 6784.

   The new UDP port removes the ambiguity of BFD over LAG packets from
   BFD over single-hop IP.  An example is (mis-)configuring a LAG with
   micro BFD sessions on one side but using a [RFC5881] BFD session for
   the LAG (treated as a single interface) on the opposite side.

   The procedures in this document MUST be used for BFD messages
   addressed to port 6784 and MUST NOT be used for others ports assigned
   in RFCs described other BFD modes.

   Control packets use a destination IP address that is configured on
   the peer system and can be reached via the LAG interface.  The
   details of how this
   Implementations may range from explicitly configuring IP addresses
   for the BFD sessions to out-of-band methods for learning the
   destination IP address is learned address.  The details are outside the scope of this

2.3.  Micro BFD session Ethernet details

   On Ethernet-based LAG member links the destination MAC is the
   dedicated multicast MAC address 01-00-5E-90-00-01 to be the immediate
   next hop.  This dedicated MAC address MUST be used for the initial
   BFD packets of a micro BFD session when in the Down/AdminDown and
   Init state.  When a micro BFD session is changing into Up state then
   the first bfd.DetectMult packets with Up state MUST be sent with the
   dedicated MAC.  For the following BFD packets with Up state the
   source MAC address from the received BFD packets for the session MAY
   be used instead of the dedicated MAC.

   All implementations MUST be able to send and receive BFD packets in
   Up state using the dedicated MAC address.  Implementations supporting
   both, sending BFD Up packets with the dedicated and the received MAC,
   need to offer means to control the behaviour.

   On Ethernet-based LAG member links the source MAC SHOULD be the MAC
   address of the member link transmitting the packet.

   This mechanism helps to reduce the use of additional MAC addresses,
   which reduces the required resources on the Ethernet hardware on the
   receiving member link.

   Micro BFD packets SHOULD always be sent untagged.  However, when the
   LAG is operating in the context of IEEE 802.1q or IEEE 802.qinq, the
   micro BFD packets may either be untagged or sent with a vlan tag of
   Zero (802.1p priority tagged).  Implementations compliant to this
   standard MUST be able to receive both untagged and 802.1p priority
   tagged micro BFD packets.

3.  Interaction between LAG and BFD

   The micro BFD sessions for a particular LAG member link MUST be
   requested when a member link state is either Distributing or Standby.
   The sessions MUST be deleted when the member link is neither in
   Distributing nor in Standby state anymore.

   BFD is used to control if the load balance algorithm is able to
   select a particular LAG member link.  In other words, even when Link
   Aggregation Control Protocol (LACP) is used and considers the member
   link to be ready to forward traffic, the member link MUST NOT be used
   by the load balancer until all the micro BFD sessions of the
   particular member link are in Up state.

   In case an implementation has separate load balance tables for IPv4
   and IPv6 and if both an IPv4 and IPv6 micro session exist for a
   member link then an implementation MAY enable the member link in the
   load balance algorithm based on the BFD session with a matching
   address family alone.

   An exception is the BFD packet itself.  Implementations MAY receive
   and transmit BFD packets via the Aggregator's MAC service interface
   independent of the session state.

4.  BFD on LAG member links and layer-3 applications

   The mechanism described in this document is likely to be used by
   modules like LMM managing Interfaces or some Interface management module. Link aggregation groups and thus
   managing the member links of a LAG.  Typical layer 3 protocols like
   OSPF do not have an insight into the LAG and treat it as one bigger
   interface.  The signaling from micro sessions to layer 3 protocols is
   effectively done by the impact of BFD micro sessions on the load
   balance table and the LMM's Interface/LAG managing module's potential
   decision to shut down the LAG.  An active method to test the impact
   of micro sessions is for layer 3 protocols to request a single BFD
   session per LAG.

5.  Detecting a member link failure

   When a micro BFD session goes down then this member link MUST be
   taken out of the LAG L2 load balance table(s).

   In case an implementation has separate load balance tables for IPv4
   and IPv6 then if both an IPv4 and IPv6 micro session exist for a
   member link an implementation MAY remove the member link only from
   the load balance table only that matches the address family of the failing
   BFD session.  If for  For example the IPv4 micro session fails but the IPv6
   micro session stays Up then the member link MAY be removed from only
   the IPv4 load balance table only but remains forwarding table; the link MAY remain in the IPv6 load balance
   balancing table.  Alternatively, the member link may be removed from
   both the IPv4 and IPv6 load balancing tables.  This decision is an
   implementation detail.

6.  Security Consideration

   This document does not introduce any additional security issues and
   the security mechanisms defined in [RFC5880] apply in this document.

7.  IANA Considerations

   IANA assigned a dedicated MAC address 01-00-5E-90-00-01 (see
   [RFC7042]) as well as UDP port 6784 for Bidirectional Forwarding
   Detection (BFD) on Link Aggregation Group (LAG) Interfaces.  IANA is
   requested to change the reference to [RFC-to-be].

   IANA is requested to change the registry for port 6784 to show the
   Assignee as [IESG] and the Contact as [BFD Chairs].  The expansion of
   [BFD Chairs] should be shown as "".
   IANA is requested to change the reference to [RFC-to-be].

8.  Acknowledgements

   We would like to thank Dave Katz, Alexander Vainshtein, Greg Mirsky
   and Jeff Tantsura for their comments.

   The initial event to start the current discussion was the
   distribution of draft-chen-bfd-interface-00.

9.  Contributing authors

   Paul Hitchen

   George Swallow
   Cisco Systems

   Wim Henderickx

   Nobo Akiya
   Cisco Systems

   Neil Ketley
   Cisco Systems

   Carlos Pignataro
   Cisco Systems

   Nitin Bahadur
   Juniper Networks
   Bracket Computing

   Zuliang Wang
   Huawei Technologies

   Liang Guo
   China Telecom

   Jeff Tantsura

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
              June 2010.

   [RFC5882]  Katz, D. and D. Ward, "Generic Application of
              Bidirectional Forwarding Detection (BFD)", RFC 5882,
              June 2010.

10.2.  Informative References

              IEEE Std. 802.1AX, "IEEE Standard for Local and
              metropolitan area networks - Link Aggregation",
              November 2008.

   [RFC7042]  Eastlake, D. and J. Abley, "IANA Considerations and IETF
              Protocol and Documentation Usage for IEEE 802 Parameters",
              BCP 141, RFC 7042, October 2013.

Appendix A.  Considerations when using BFD on member links

   If the BFD over LAG feature were provisioned on an aggregated link
   member after the link was already active within a LAG, BFD session
   state SHOULD NOT should not influence the load balance algorithm until the BFD
   session state transitions to Up.  If the BFD session never
   transitions to Up but the LAG becomes inactive, the previously
   documented procedures would then normally apply.

   This procedure ensures that the sequence of events - enabling the LAG
   and enabling BFD on the LAG - has no impact on the forwarding

   If the BFD over LAG feature was deprovisioned on an aggregate link
   member while the associated micro BFD session was in Up state, BFD
   should transition its state to AdminDown and SHOULD should attempt to
   communicate this state change to the peer.

   If the local or the remote state of a micro BFD session is AdminDown
   the system SHOULD NOT should not indicate a connectivity failure to any client
   and SHOULD NOT should not remove the particular LAG member link from forwarding.
   This behaviour is independent from the use of Link Aggregation
   Control Protocol (LACP) for the LAG.

   When traffic is forwarded across a link while the corresponding micro
   BFD session is not in Up state an implementation MAY may use a
   configurable timeout value after which the BFD session must have
   reached Up state or otherwise the link is taken out of forwarding.

   When such timeout values exist then the configuration MUST must allow to
   turn off the timeout function.

   The configurable timeout value shall ensure that a LAG is not
   remaining forever in an "inconsistent" state where forwarding occurs
   on a link with no confirmation from the micro BFD session that the
   link is healthy.

   Note that if one device is not operating a micro BFD session on a
   link, while the other device is and perceives the session to be Down,
   this will result in the two devices having a different view of the
   status of the link.  This would likely lead to traffic loss across
   the LAG.  The use of another protocol to bootstrap BFD can detect
   such mismatched config, since the side that's not configured can send
   a rejection error.  Such bootstrapping mechanisms are outside the
   scope of this document.

Authors' Addresses

   Manav Bhatia (editor)
   Bangalore  560045


   Mach(Guoyi) Chen (editor)
   Huawei Technologies
   Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District
   Beijing  100095


   Sami Boutros (editor)
   Cisco Systems


   Marc Binderberger (editor)
   Cisco Systems


   Jeffrey Haas (editor)
   Juniper Networks