Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces
draft-mmm-bfd-on-lags-03

Network Working Group                                     M. Bhatia, Ed.
Internet-Draft                                            Alcatel-Lucent
Intended status: Standards Track                            M. Chen, Ed.
Expires: August 4, 2012                              Huawei Technologies
                                                         S. Boutros, Ed.
                                                    M. Binderberger, Ed.
                                                           Cisco Systems
                                                            J. Haas, Ed.
                                                        Juniper Networks
                                                        February 1, 2012

Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG)
                               Interfaces
                        draft-mmm-bfd-on-lags-03

Abstract

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

   The mechanism allows to verify the link connectivity, either in
   combination with or in absence of LACP, with a shorter detection time
   than what LACP offers.  The connectivity check can also cover
   elements of layer 3.

   A dedicated well-known UDP port is introduced that all BFD packets
   over member links use to disambiguate those from ordinary BFD
   packets.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   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 http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months

Bhatia, et al.           Expires August 4, 2012                 [Page 1]
Internet-Draft           BFD for LAG Interfaces            February 2012

   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 August 4, 2012.

Copyright Notice

   Copyright (c) 2012 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
   (http://trustee.ietf.org/license-info) 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.

Bhatia, et al.           Expires August 4, 2012                 [Page 2]
Internet-Draft           BFD for LAG Interfaces            February 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  BFD on LAG member links  . . . . . . . . . . . . . . . . . . .  4
     2.1.  Micro BFD async session address family . . . . . . . . . .  5
     2.2.  Micro BFD async session negotiation  . . . . . . . . . . .  5
   3.  LAG Management Module  . . . . . . . . . . . . . . . . . . . .  6
     3.1.  BFD in the presence of LACP  . . . . . . . . . . . . . . .  6
     3.2.  BFD in the absence of LACP . . . . . . . . . . . . . . . .  7
     3.3.  Handling Exceptions  . . . . . . . . . . . . . . . . . . .  7
   4.  BFD on LAG members and layer-3 applications  . . . . . . . . .  7
   5.  Detecting a member link failure  . . . . . . . . . . . . . . .  7
   6.  Security Consideration . . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  Contributing authors . . . . . . . . . . . . . . . . . . . . .  8
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     10.2. Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Bhatia, et al.           Expires August 4, 2012                 [Page 3]
Internet-Draft           BFD for LAG Interfaces            February 2012

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.  BFD protocol provides as well 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 to a single logical
   link.  The goal is to provide higher bandwidth with the aggregated
   logical link 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 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
   connectivity per member link.

   Running a single BFD session over the LAG virtual port, and without
   internal knowledge of the LAG virtual port physical members, will
   make it impossible for BFD to guarantee a detection of the physical
   member link failures.

   The goal is to verify every member link connectivity.

   The approach is to run BFD async session over each member link and
   make BFD control whether the member link should be part of the L2
   Loadbalance table of the LAG virtual port in the presence and in the
   absence of LACP.

   This document describes how to establish a BFD async session per
   physical member link of the Link Aggregation (LAG) virtual port.

   While there are native Ethernet mechanisms to detect failures
   (802.1ax, .3ah) that could be used for LAG, the solution proposed 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 proposed for a fast detection of LAG member link

Bhatia, et al.           Expires August 4, 2012                 [Page 4]
Internet-Draft           BFD for LAG Interfaces            February 2012

   failure is running BFD async sessions on every LAG member link.  We
   call these per LAG member link BFD sessions as micro BFD sessions in
   the rest of this document.

2.1.  Micro BFD async session address family

   Only one address family MUST be used for all micro BFD async sessions
   running on all LAG member links. i.e. all member link async BFD
   sessions MUST either use IPv4 or IPv6.

2.2.  Micro BFD async session negotiation

   A single micro BFD session runs on each member link of the LAG.  The
   micro BFD async sessions negotiation MUST follow the same procedures
   defined in [RFC5880] and [RFC5881].

   Only asynchronous mode is considered in this document.  The echo
   function is outside the document's scope.  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 machine.  Timer values
   MAY be different, even among the micro BFD sessions belonging to the
   same LAG virtual port, although it is expected that micro BFD
   sessions belonging to the same LAG virtual port use the same timer
   values.

   The demultiplexing of a received 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.

   When receiving a BFD packet for a micro session with a valid, non-
   zero Your Discriminator, a check MUST be done if the packet was
   received on the correct member link interface.  If the check fails
   then the packet MUST be discarded.  This needs to be done before
   state variables for the BFD sessions are updated by the received
   packet.

   The BFD Control packets for each micro BFD session are IP/UDP
   encapsulated as defined in [RFC5881], but with a new UDP destination
   port "BfdBndlPort" (to be assigned by IANA).  Control packets use a
   destination IP address that is the peer's remote IP address.  The
   details of how this destination IP address is learnt is outside the
   scope of the document .

   On Ethernet-based LAG member links the destination MAC is a dedicated

Bhatia, et al.           Expires August 4, 2012                 [Page 5]
Internet-Draft           BFD for LAG Interfaces            February 2012

   MAC address (to be assigned by IANA according to [RFC5342]) to be the
   immediate next hop.  This will be used for the initial BFD down
   packets of a session, while sending BFD Init and Up packets with the
   MAC address learned from the received BFD packets.

   On Ethernet-based LAG member links the source MAC is the embedded MAC
   address of the port transmitting the packet.

   This mechanism helps to reduce the use of additional MAC addresses,
   which reduces the requirements for the Ethernet hardware on the
   receiving port.

3.  LAG Management Module

   The LAG Management Module (LMM) could be envisaged as a client of
   BFD, i.e. the LMM requests a micro BFD session per member link.

   LMM then uses the micro BFD session state, in addition to LACP state,
   to monitor the health of the individual members links of the LAG.

   The micro BFD session for a particular port MUST be requested when
   the port is attached to an aggregator.  The session MUST be deleted
   when the port is detached from the aggregator.

3.1.  BFD in the presence of LACP

   Once LACP has determined that a link is suitable for aggregation
   within its selected LAG, and has completed negotiations with the
   partner device so as to bring that link to Distributing state, at
   that point the micro BFD session can be started on the link.

   BFD, as a layer 3 protocol, is viewed as running across the LAG, with
   load balancing constraints ensuring particular micro BFD sessions are
   effectively bound to particular member links.

   Although the link is in LACP Distributing state it should not be used
   for carrying traffic other than the micro BFD session.  BFD is used
   to verify that a link is ready to be an active member of its LAG for
   the purpose of carrying LAG level data traffic.  Only when the micro
   BFD session is up should the link become active for forwarding
   general traffic over the bundle.

   In all cases where a micro BFD session goes down the corresponding
   link is removed from the active set of members of the bundle.

   LACP remains in Distributing state as BFD runs above the LACP layer
   but the link is inactive until such time as the micro BFD session is

Bhatia, et al.           Expires August 4, 2012                 [Page 6]
Internet-Draft           BFD for LAG Interfaces            February 2012

   restored.  This applies also to the case where a BFD session is
   started on an existing active link and the BFD session never comes
   up.

3.2.  BFD in the absence of LACP

   Use of LACP for link aggregation, is strictly optional.  It is
   equally possible to use no aggregation control protocol and to step
   directly from the layer 1 or layer 2 OAM state becoming operational
   to starting the micro BFD session.

3.3.  Handling Exceptions

   A possible exception to this would apply if the BFD over LAG feature
   were provisioned after the link was already active within the LAG.
   In such cases it may be desirable to retain the link in its active
   status to avoid disruption to traffic forwarding while the micro BFD
   session is brought up.

   Another exception is when the BFD over LAG feature is un-provisioned
   after links were already BFD validated and active within the LAG.  In
   such case, it may be desirable to retain those links in their active
   status to avoid disruption to traffic forwarding since expectation is
   that the peer device will soon un-provision the BFD over LAG feature.

   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.

4.  BFD on LAG members and layer-3 applications

   Layer 3 protocols like e.g.  OSPF may use a micro BFD session to
   detect failures on the LAG virtual port, or may establish a new BFD
   session over the logical LAG virtual port.

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.

Bhatia, et al.           Expires August 4, 2012                 [Page 7]
Internet-Draft           BFD for LAG Interfaces            February 2012

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

   The IANA is requested to assign a well-known port number for the UDP
   encapsulated micro BFD sessions.  IANA is also requested to assign a
   dedicated MAC address according to RFC 5342 [RFC5342].

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
   BT
   Email: paul.hitchen@bt.com

   George Swallow
   Cisco Systems
   Email: swallow@cisco.com

   Wim Henderickx
   Alcatel-Lucent
   Email: wim.henderickx@alcatel-lucent.com

   Nobo Akiya
   Cisco Systems
   Email: nobo@cisco.com

   Neil Ketley
   Cisco Systems
   Email: nketley@cisco.com

   Carlos Pignataro
   Cisco Systems
   Email: cpignata@cisco.com

Bhatia, et al.           Expires August 4, 2012                 [Page 8]
Internet-Draft           BFD for LAG Interfaces            February 2012

   Nitin Bahadur
   Juniper Networks
   Email: nitinb@juniper.net

   Zuliang Wang
   Huawei Technologies
   Email: liang_tsing@huawei.com

   Liang Guo
   China Telecom
   Email: guoliang@gsta.com

   Jeff Tantsura
   Ericsson
   Email: jeff.tantsura@ericsson.com

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

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

   [RFC5342]  Eastlake, D., "IANA Considerations and IETF Protocol Usage
              for IEEE 802 Parameters", BCP 141, RFC 5342,
              September 2008.

Bhatia, et al.           Expires August 4, 2012                 [Page 9]
Internet-Draft           BFD for LAG Interfaces            February 2012

Authors' Addresses

   Manav Bhatia (editor)
   Alcatel-Lucent
   Bangalore  560045
   India

   Email: manav.bhatia@alcatel-lucent.com

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

   Email: mach@huawei.com

   Sami Boutros (editor)
   Cisco Systems

   Email: sboutros@cisco.com

   Marc Binderberger (editor)
   Cisco Systems

   Email: mbinderb@cisco.com

   Jeffrey Haas (editor)
   Juniper Networks

   Email: jhaas@juniper.net

Bhatia, et al.           Expires August 4, 2012                [Page 10]