draft-ietf-bfd-on-lags-02.txt   draft-ietf-bfd-on-lags-03.txt 
Network Working Group M. Bhatia, Ed. Network Working Group M. Bhatia, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track M. Chen, Ed. Intended status: Standards Track M. Chen, Ed.
Expires: May 15, 2014 Huawei Technologies Expires: June 3, 2014 Huawei Technologies
S. Boutros, Ed. S. Boutros, Ed.
M. Binderberger, Ed. M. Binderberger, Ed.
Cisco Systems Cisco Systems
J. Haas, Ed. J. Haas, Ed.
Juniper Networks Juniper Networks
November 11, 2013 November 30, 2013
Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG)
Interfaces Interfaces
draft-ietf-bfd-on-lags-02 draft-ietf-bfd-on-lags-03
Abstract Abstract
This document proposes a mechanism to run BFD on Link Aggregation This document defines a mechanism to run BFD on Link Aggregation
Group (LAG) interfaces. It does so by running an independent Group (LAG) interfaces. It does so by running an independent
Asynchronous mode BFD session on every LAG member link. Asynchronous mode BFD session on every LAG member link.
This mechanism allows the verification of member link continuity, This mechanism allows the verification of member link continuity,
either in combination with, or in absence of, LACP. It provides a either in combination with, or in absence of, Link Aggregation
shorter detection time than what LACP offers. The continuity check Control Protocol (LACP). It provides a shorter detection time than
can also cover elements of layer 3 bidirectional forwarding. 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 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 single-hop BFD over IP. This new UDP port removes the ambiguity of
BFD over LAG packets from BFD over single-hop IP. BFD over LAG packets from BFD over single-hop IP.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 2, line 8 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 15, 2014. This Internet-Draft will expire on June 3, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 44 skipping to change at page 4, line 44
The approach taken in this document is to run a Asynchronous mode BFD 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 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 LAG member link should be part of the L2 Loadbalance table of the LAG
interface in the presence or the absence of LACP. interface in the presence or the absence of LACP.
This document describes how to establish an Asynchronous mode BFD This document describes how to establish an Asynchronous mode BFD
session per physical LAG member link of the LAG interface. session per physical LAG member link of the LAG interface.
While there are native Ethernet mechanisms to detect failures While there are native Ethernet mechanisms to detect failures
(802.1ax, .3ah) that could be used for LAG, the solution proposed in (802.1ax, .3ah) that could be used for LAG, the solution defined in
this document enables operators who have already deployed BFD over this document enables operators who have already deployed BFD over
different technologies (e.g. IP, MPLS) to use a common failure different technologies (e.g. IP, MPLS) to use a common failure
detection mechanism. detection mechanism.
2. BFD on LAG member links 2. BFD on LAG member links
The mechanism proposed for a fast detection of LAG member link The mechanism defined for a fast detection of LAG member link failure
failure is to run Asynchronous mode BFD sessions on every LAG member is to run Asynchronous mode BFD sessions on every LAG member link.
link. We call these per LAG member link BFD sessions "micro BFD We call these per LAG member link BFD sessions "micro BFD sessions"
sessions" in the remainder of this document. in the remainder of this document.
2.1. Micro BFD session address family 2.1. Micro BFD session address family
Member link micro BFD sessions, when using IP/UDP encapsulation, can Member link micro BFD sessions, when using IP/UDP encapsulation, can
use IPv4 or IPv6 addresses. Two micro sessions MAY exist per member 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 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 member link then it MUST be used on all member links of the
particular LAG. particular LAG.
2.2. Micro BFD session negotiation 2.2. Micro BFD session negotiation
skipping to change at page 6, line 46 skipping to change at page 6, line 46
tagged micro BFD packets. tagged micro BFD packets.
3. Interaction between LAG and BFD 3. Interaction between LAG and BFD
The micro BFD sessions for a particular LAG member link MUST be The micro BFD sessions for a particular LAG member link MUST be
requested when a member link state is either Distributing or Standby. requested when a member link state is either Distributing or Standby.
The sessions MUST be deleted when the member link is neither in The sessions MUST be deleted when the member link is neither in
Distributing nor in Standby state anymore. Distributing nor in Standby state anymore.
BFD is used to control if the load balance algorithm is able to BFD is used to control if the load balance algorithm is able to
select a particular LAG member link. In other words, even when LACP select a particular LAG member link. In other words, even when Link
is used and considers the member link to be ready to forward traffic, Aggregation Control Protocol (LACP) is used and considers the member
the member link MUST NOT be used by the load balancer until all the link to be ready to forward traffic, the member link MUST NOT be used
micro BFD sessions of the particular member link are in Up state. 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 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 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 member link then an implementation MAY enable the member link in the
load balance algorithm based on the BFD session with a matching load balance algorithm based on the BFD session with a matching
address family alone. address family alone.
An exception is the BFD packet itself. Implementations MAY receive An exception is the BFD packet itself. Implementations MAY receive
and transmit BFD packets via the Aggregator's MAC service interface and transmit BFD packets via the Aggregator's MAC service interface
independent of the session state. independent of the session state.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
6. Security Consideration 6. Security Consideration
This document does not introduce any additional security issues and This document does not introduce any additional security issues and
the security mechanisms defined in [RFC5880] apply in this document. the security mechanisms defined in [RFC5880] apply in this document.
7. IANA Considerations 7. IANA Considerations
IANA assigned a dedicated MAC address 01-00-5E-90-00-01 (see IANA assigned a dedicated MAC address 01-00-5E-90-00-01 (see
[RFC7042]) as well as UDP port 6784 for UDP encapsulated micro BFD [RFC7042]) as well as UDP port 6784 for Bidirectional Forwarding
sessions. Detection (BFD) on Link Aggregation Group (LAG) Interfaces.
8. Acknowledgements 8. Acknowledgements
We would like to thank Dave Katz, Alexander Vainshtein, Greg Mirsky We would like to thank Dave Katz, Alexander Vainshtein, Greg Mirsky
and Jeff Tantsura for their comments. and Jeff Tantsura for their comments.
The initial event to start the current discussion was the The initial event to start the current discussion was the
distribution of draft-chen-bfd-interface-00. distribution of draft-chen-bfd-interface-00.
9. Contributing authors 9. Contributing authors
skipping to change at page 10, line 15 skipping to change at page 10, line 15
service. service.
If the BFD over LAG feature was deprovisioned on an aggregate link If the BFD over LAG feature was deprovisioned on an aggregate link
member while the associated micro BFD session was in Up state, BFD member while the associated micro BFD session was in Up state, BFD
SHOULD transition its state to AdminDown and SHOULD attempt to SHOULD transition its state to AdminDown and SHOULD attempt to
communicate this state change to the peer. communicate this state change to the peer.
If the local or the remote state of a micro BFD session is AdminDown If the local or the remote state of a micro BFD session is AdminDown
the system SHOULD NOT indicate a connectivity failure to any client the system SHOULD NOT indicate a connectivity failure to any client
and SHOULD NOT remove the particular LAG member link from forwarding. and SHOULD NOT remove the particular LAG member link from forwarding.
This behaviour is independent from the use of LACP for the LAG. 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 When traffic is forwarded across a link while the corresponding micro
BFD session is not in Up state an implementation MAY use a BFD session is not in Up state an implementation MAY use a
configurable timeout value after which the BFD session must have configurable timeout value after which the BFD session must have
reached Up state or otherwise the link is taken out of forwarding. reached Up state or otherwise the link is taken out of forwarding.
When such timeout values exist then the configuration MUST allow to When such timeout values exist then the configuration MUST allow to
turn off the timeout function. turn off the timeout function.
The configurable timeout value shall ensure that a LAG is not The configurable timeout value shall ensure that a LAG is not
 End of changes. 11 change blocks. 
20 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/