draft-ietf-bfd-on-lags-03.txt   draft-ietf-bfd-on-lags-04.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: June 3, 2014 Huawei Technologies Expires: June 21, 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 30, 2013 December 18, 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-03 draft-ietf-bfd-on-lags-04
Abstract Abstract
This document defines 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, Link Aggregation either in combination with, or in absence of, Link Aggregation
Control Protocol (LACP). It provides a shorter detection time than Control Protocol (LACP). It provides a shorter detection time than
what LACP offers. The continuity check can also cover elements of what LACP offers. The continuity check can also cover elements of
layer 3 bidirectional forwarding. 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 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].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 21, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . 5
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. Interaction between LAG and BFD . . . . . . . . . . . . . . . 6 3. Interaction between LAG and BFD . . . . . . . . . . . . . . . 7
4. BFD on LAG member links and layer-3 applications . . . . . . . 7 4. BFD on LAG member links and layer-3 applications . . . . . . . 7
5. Detecting a member link failure . . . . . . . . . . . . . . . 7 5. Detecting a member link failure . . . . . . . . . . . . . . . 7
6. Security Consideration . . . . . . . . . . . . . . . . . . . . 7 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. Contributing authors . . . . . . . . . . . . . . . . . . . . . 8 9. Contributing authors . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Considerations when using BFD on member links . . . . 9 Appendix A. Considerations when using BFD on member links . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
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
the protocol can run over any media and at any protocol layer. the protocol can run over any media and at any protocol layer.
skipping to change at page 4, line 26 skipping to change at page 4, line 26
mechanisms to combine multiple physical links into a single logical mechanisms to combine multiple physical links into a single logical
link. This logical link provides higher bandwidth and better link. This logical link provides higher bandwidth and better
resiliency since if one of the physical member links fails the resiliency since if one of the physical member links fails the
aggregate logical link can continue to forward traffic over the aggregate logical link can continue to forward traffic over the
remaining operational physical member links. remaining operational physical member links.
Currently, the Link Aggregation Control Protocol (LACP) is used to Currently, the Link Aggregation Control Protocol (LACP) is used to
detect failures on a per physical member link. However, the use of detect failures on a per physical member link. However, the use of
BFD for failure detection would (1) provide a faster detection (2) BFD for failure detection would (1) provide a faster detection (2)
provide detection in the absence of LACP (3) and would be able to provide detection in the absence of LACP (3) and would be able to
verify L3 Continuity per member link. verify the ability for each member link to be able to forward L3
packets.
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 LAG member link and make BFD control whether the session over each LAG member link and make BFD control whether the
skipping to change at page 5, line 37 skipping to change at page 5, line 41
own set of state variables and have their own independent state own set of state variables and have their own independent state
machines. Timer values MAY be different, even among the micro BFD machines. Timer values MAY be different, even among the micro BFD
sessions belonging to the same aggregation, although it is expected sessions belonging to the same aggregation, although it is expected
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 and
the destination UDP port of the received BFD packet.
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 LAG member link 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 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 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.
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 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.
details of how this destination IP address is learned are outside the Implementations may range from explicitly configuring IP addresses
scope of this document. for the BFD sessions to out-of-band methods for learning the
destination IP address. The details are outside the scope of this
document.
2.3. Micro BFD session Ethernet details 2.3. Micro BFD session Ethernet details
On Ethernet-based LAG member links the destination MAC is the 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 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 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
address from the received BFD packets for the session MAY be used source MAC address from the received BFD packets for the session MAY
instead of the dedicated MAC. be used 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 member link 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,
skipping to change at page 7, line 18 skipping to change at page 7, line 32
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.
4. BFD on LAG member links and layer-3 applications 4. BFD on LAG member links 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 managing Interfaces or Link aggregation groups and thus
3 protocols like OSPF do not have an insight into the LAG and treat managing the member links of a LAG. Typical layer 3 protocols like
it as one bigger interface. The signaling from micro sessions to OSPF do not have an insight into the LAG and treat it as one bigger
layer 3 protocols is effectively done by the impact of BFD micro interface. The signaling from micro sessions to layer 3 protocols is
sessions on the load balance table and the LMM's potential decision effectively done by the impact of BFD micro sessions on the load
to shut down the LAG. An active method to test the impact of micro balance table and the Interface/LAG managing module's potential
sessions is for layer 3 protocols to request a single BFD session per decision to shut down the LAG. An active method to test the impact
LAG. of micro sessions is for layer 3 protocols to request a single BFD
session per 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 only from
load balance table only that matches the address family of the the load balance table that matches the address family of the failing
failing BFD session. If for example the IPv4 micro session fails but BFD session. For example the IPv4 micro session fails but the IPv6
the IPv6 micro session stays Up then the member link MAY be removed micro session stays Up then the member link MAY be removed from only
from the IPv4 load balance table only but remains forwarding in the the IPv4 load balance table; the link MAY remain in the IPv6 load
IPv6 load balance table. 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 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 Bidirectional Forwarding [RFC7042]) as well as UDP port 6784 for Bidirectional Forwarding
Detection (BFD) on Link Aggregation Group (LAG) Interfaces. 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 "mailto:bfd-chairs@tools.ietf.org".
IANA is requested to change the reference to [RFC-to-be].
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 8, line 43 skipping to change at page 9, line 19
Neil Ketley Neil Ketley
Cisco Systems Cisco Systems
Email: nketley@cisco.com Email: nketley@cisco.com
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
Email: cpignata@cisco.com Email: cpignata@cisco.com
Nitin Bahadur Nitin Bahadur
Juniper Networks Bracket Computing
Email: nitinb@juniper.net Email: nitin@brkt.com
Zuliang Wang Zuliang Wang
Huawei Technologies Huawei Technologies
Email: liang_tsing@huawei.com Email: liang_tsing@huawei.com
Liang Guo Liang Guo
China Telecom China Telecom
Email: guoliang@gsta.com Email: guoliang@gsta.com
Jeff Tantsura Jeff Tantsura
skipping to change at page 9, line 44 skipping to change at page 10, line 20
November 2008. November 2008.
[RFC7042] Eastlake, D. and J. Abley, "IANA Considerations and IETF [RFC7042] Eastlake, D. and J. Abley, "IANA Considerations and IETF
Protocol and Documentation Usage for IEEE 802 Parameters", Protocol and Documentation Usage for IEEE 802 Parameters",
BCP 141, RFC 7042, October 2013. BCP 141, RFC 7042, October 2013.
Appendix A. Considerations when using BFD on member links Appendix A. Considerations when using BFD on member links
If the BFD over LAG feature were provisioned on an aggregated link If the BFD over LAG feature were provisioned on an aggregated link
member after the link was already active within a LAG, BFD session member after the link was already active within a LAG, BFD session
state SHOULD NOT influence the load balance algorithm until the BFD state should not influence the load balance algorithm until the BFD
session state transitions to Up. If the BFD session never session state transitions to Up. If the BFD session never
transitions to Up but the LAG becomes inactive, the previously transitions to Up but the LAG becomes inactive, the previously
documented procedures would then normally apply. documented procedures would then normally apply.
This procedure ensures that the sequence of events - enabling the LAG This procedure ensures that the sequence of events - enabling the LAG
and enabling BFD on the LAG - has no impact on the forwarding and enabling BFD on the LAG - has no impact on the forwarding
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 Link Aggregation This behaviour is independent from the use of Link Aggregation
Control Protocol (LACP) for the LAG. 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
remaining forever in an "inconsistent" state where forwarding occurs remaining forever in an "inconsistent" state where forwarding occurs
on a link with no confirmation from the micro BFD session that the on a link with no confirmation from the micro BFD session that the
link is healthy. link is healthy.
Note that if one device is not operating a micro BFD session on a 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, 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 this will result in the two devices having a different view of the
 End of changes. 24 change blocks. 
48 lines changed or deleted 64 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/