draft-ietf-bfd-on-lags-00.txt   draft-ietf-bfd-on-lags-01.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: November 11, 2013 Huawei Technologies Expires: December 15, 2013 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
May 10, 2013 June 13, 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-00 draft-ietf-bfd-on-lags-01
Abstract Abstract
This document proposes a mechanism to run BFD on Link Aggregation This document proposes 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, LACP. It provides a
shorter detection time than what LACP offers. The continuity check shorter detection time than what LACP offers. The continuity check
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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 November 11, 2013. This Internet-Draft will expire on December 15, 2013.
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 3, line 12 skipping to change at page 3, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. BFD on LAG member links . . . . . . . . . . . . . . . . . . . 4 2. BFD on LAG member links . . . . . . . . . . . . . . . . . . . 4
2.1. Micro BFD session address family . . . . . . . . . . . . . 5 2.1. Micro BFD session address family . . . . . . . . . . . . . 5
2.2. Micro BFD session negotiation . . . . . . . . . . . . . . 5 2.2. Micro BFD session negotiation . . . . . . . . . . . . . . 5
2.3. Micro BFD session Ethernet details . . . . . . . . . . . . 6 2.3. Micro BFD session Ethernet details . . . . . . . . . . . . 6
3. LAG Management Module . . . . . . . . . . . . . . . . . . . . 6 3. Interaction between LAG and BFD . . . . . . . . . . . . . . . 6
3.1. Interaction between LAG and BFD . . . . . . . . . . . . . 6 4. BFD on LAG member links and layer-3 applications . . . . . . . 7
3.2. Handling Exceptions . . . . . . . . . . . . . . . . . . . 7 5. Detecting a member link failure . . . . . . . . . . . . . . . 7
4. BFD on LAG members and layer-3 applications . . . . . . . . . 8 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 7
5. Detecting a member link failure . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Consideration . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Contributing authors . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Contributing authors . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 Appendix A. Considerations when using BFD on member links . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The Bidirectional Forwarding Detection (BFD) protocol [RFC5880] The Bidirectional Forwarding Detection (BFD) protocol [RFC5880]
provides a mechanism to detect faults in the bidirectional path provides a mechanism to detect faults in the bidirectional path
between two forwarding engines, including interfaces, data link(s), between two forwarding engines, including interfaces, data link(s),
and to the extent possible the forwarding engines themselves, with and to the extent possible the forwarding engines themselves, with
potentially very low latency. The BFD protocol also provides a fast potentially very low latency. The BFD protocol also provides a fast
mechanism for detecting communication failures on any data links and mechanism for detecting communication failures on any data links and
skipping to change at page 4, line 36 skipping to change at page 4, line 36
verify L3 Continuity per member link. verify L3 Continuity per member link.
Running a single BFD session over the aggregation without internal Running a single BFD session over the aggregation without internal
knowledge of the member links would make it impossible for BFD to knowledge of the member links would make it impossible for BFD to
guarantee detection of the physical member link failures. guarantee detection of the physical member link failures.
The goal is to verify link Continuity for every member link. This The goal is to verify link Continuity for every member link. This
corresponds to [RFC5882], section 7.3. corresponds to [RFC5882], section 7.3.
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 member link and make BFD control whether the member session over each LAG member link and make BFD control whether the
link should be part of the L2 Loadbalance table of the LAG virtual LAG member link should be part of the L2 Loadbalance table of the LAG
port 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 member link of the LAG virtual port. 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 proposed 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 proposed for a fast detection of LAG member link
skipping to change at page 5, line 40 skipping to change at page 5, line 40
that micro BFD sessions belonging to the same aggregation will use that micro BFD sessions belonging to the same aggregation will use
the same timer values. the same timer values.
The demultiplexing of a received BFD packet is solely based on the The demultiplexing of a received BFD packet is solely based on the
Your Discriminator field, if this field is nonzero. For the initial 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 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 case demultiplexing MUST be based on some combination of other fields
which MUST include the interface information of the member link. which MUST include the interface information of the member link.
The procedure for the Reception of BFD Control Packets in Section The procedure for the Reception of BFD Control Packets in Section
6.8.6 of [RFC5880] is amended as follows for per member link micro 6.8.6 of [RFC5880] is amended as follows for per LAG member link
BFD over LAG sessions: "If the Your Discriminator field is non-zero micro BFD sessions: "If the Your Discriminator field is non-zero and
and a micro BFD over LAG session is found, the interface on which the a micro BFD over LAG session is found, the interface on which the
micro BFD control packet arrived on MUST correspond to the interface micro BFD control packet arrived on MUST correspond to the interface
associated with that session." associated with that session."
This document defines the BFD Control packets for each micro BFD This document defines the BFD Control packets for each micro BFD
session to be IP/UDP encapsulated as defined in [RFC5881], but with a session to be IP/UDP encapsulated as defined in [RFC5881], but with a
new UDP destination port 6784. new UDP destination port 6784.
Control packets use a destination IP address that is configured on Control packets use a destination IP address that is configured on
the peer system and can be reached via the LAG interface. The the peer system and can be reached via the LAG interface. The
details of how this destination IP address is learned are outside the details of how this destination IP address is learned are outside the
skipping to change at page 6, line 21 skipping to change at page 6, line 21
next hop. This dedicated MAC address MUST be used for the initial 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 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 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 the first bfd.DetectMult packets with Up state MUST be sent with the
dedicated MAC. For the following BFD packets with Up state the MAC dedicated MAC. For the following BFD packets with Up state the MAC
address from the received BFD packets for the session MAY be used address from the received BFD packets for the session MAY be used
instead of the dedicated MAC. instead of the dedicated MAC.
All implementations MUST be able to send and receive BFD packets in All implementations MUST be able to send and receive BFD packets in
Up state using the dedicated MAC address. Implementations supporting Up state using the dedicated MAC address. Implementations supporting
both, sending BFD Up packets with the dedicated and the received MAC both, sending BFD Up packets with the dedicated and the received MAC,
need to offer means to control the behaviour. need to offer means to control the behaviour.
On Ethernet-based LAG member links the source MAC SHOULD be the MAC On Ethernet-based LAG member links the source MAC SHOULD be the MAC
address of the port transmitting the packet. address of the member link transmitting the packet.
This mechanism helps to reduce the use of additional MAC addresses, This mechanism helps to reduce the use of additional MAC addresses,
which reduces the required resources on the Ethernet hardware on the which reduces the required resources on the Ethernet hardware on the
receiving port. receiving member link.
Micro BFD packets SHOULD always be sent untagged. However, when the 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 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 micro BFD packets may either be untagged or sent with a vlan tag of
Zero (802.1p priority tagged). Implementations compliant to this Zero (802.1p priority tagged). Implementations compliant to this
standard MUST be able to receive both untagged and 802.1p priority standard MUST be able to receive both untagged and 802.1p priority
tagged micro BFD packets. tagged micro BFD packets.
3. LAG Management Module 3. Interaction between LAG and BFD
3.1. Interaction between LAG and BFD
The LAG Management Module (LMM) could be envisaged as a client of
BFD; i.e. the LMM requests the micro BFD sessions per member link.
The 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 sessions for a particular port MUST be requested when a The micro BFD sessions for a particular LAG member link MUST be
member port state is either Distributing or Standby. The sessions requested when a member link state is either Distributing or Standby.
MUST be deleted when the member port is neither in Distributing nor The sessions MUST be deleted when the member link is neither in
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 port. In other words, even when LACP is used and select a particular LAG member link. In other words, even when LACP
considers the member link to be ready to forward traffic, the member is used and considers the member link to be ready to forward traffic,
link is only used by the load balancer when all the micro BFD the member link MUST NOT be used by the load balancer until all the
sessions of the member link are Up. 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 then 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 an implementation MAY enable the member link in the member link then an implementation MAY enable the member link in the
distribution algorithm only when the BFD session with a matching load balance algorithm based on the BFD session with a matching
address family is changing into Up state. address family alone.
An exception are the BFD packets 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.
3.2. Handling Exceptions 4. BFD on LAG member links and layer-3 applications
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 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.
If the BFD over LAG feature were deprovisioned on an aggregate link
member after the BFD session had transitioned to Up, BFD MAY indicate
to the remote port that it should not take the port down or remove it
from the aggregation by setting its BFD session state to AdminDown.
When a micro BFD session receives AdminDown from the peer, it is
RECOMMENDED to have a configurable timeout value. If the BFD session
has not been removed within the timeout period the link is taken out
of forwarding.
When traffic is forwarded across a link before the corresponding
micro BFD session is Up it is RECOMMENDED to have a configurable
timeout value after which the BFD session must have reached Up state
or otherwise the link is taken out of forwarding.
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.
4. BFD on LAG members and layer-3 applications
The mechanism described in this document is likely to be used by The mechanism described in this document is likely to be used by
modules like LMM or some Interface management module. Typical layer modules like LMM or some Interface management module. Typical layer
3 protocols like OSPF do not have an insight into the LAG and treat 3 protocols like OSPF do not have an insight into the LAG and treat
it as one bigger interface. The signalling from micro sessions to it as one bigger interface. The signaling from micro sessions to
layer 3 protocols is effectively done by the impact of BFD micro layer 3 protocols is effectively done by the impact of BFD micro
sessions on the load balance table and the LMM's potential decision sessions on the load balance table and the LMM's potential decision
to shut down the LAG. An active method to test the impact of micro 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 sessions is for layer 3 protocols to request a single BFD session per
LAG. LAG.
5. Detecting a member link failure 5. Detecting a member link failure
When a micro BFD session goes down then this member link MUST be When a micro BFD session goes down then this member link MUST be
taken out of the LAG L2 load balance table(s). taken out of the LAG L2 load balance table(s).
In case an implementation has separate load balance tables for IPv4 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 and IPv6 then if both an IPv4 and IPv6 micro session exist for a
member link an implementation MAY remove the member link from the member link an implementation MAY remove the member link from the
load balance table only that matches the address family of the load balance table only that matches the address family of the
failing BFD session. If for example the IPv4 micro session fails but failing BFD session. If for example the IPv4 micro session fails but
the IPv6 micro session stays up then the member link MAY be removed the IPv6 micro session stays Up then the member link MAY be removed
from the IPv4 load balance table only but remains forwarding in the from the IPv4 load balance table only but remains forwarding in the
IPv6 load balance table. IPv6 load balance table.
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
skipping to change at page 10, line 36 skipping to change at page 9, line 39
[IEEE802.1AX] [IEEE802.1AX]
IEEE Std. 802.1AX, "IEEE Standard for Local and IEEE Std. 802.1AX, "IEEE Standard for Local and
metropolitan area networks - Link Aggregation", metropolitan area networks - Link Aggregation",
November 2008. November 2008.
[RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage [RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage
for IEEE 802 Parameters", BCP 141, RFC 5342, for IEEE 802 Parameters", BCP 141, RFC 5342,
September 2008. September 2008.
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 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
service.
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 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 indicate a connectivity failure to any client
and SHOULD NOT remove the particular LAG member link from forwarding.
This behaviour is independent from the use of 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 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 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 Authors' Addresses
Manav Bhatia (editor) Manav Bhatia (editor)
Alcatel-Lucent Alcatel-Lucent
Bangalore 560045 Bangalore 560045
India India
Email: manav.bhatia@alcatel-lucent.com Email: manav.bhatia@alcatel-lucent.com
Mach(Guoyi) Chen (editor) Mach(Guoyi) Chen (editor)
Huawei Technologies Huawei Technologies
 End of changes. 20 change blocks. 
86 lines changed or deleted 87 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/