Internet DRAFT - draft-boutros-bfd-over-lag
draft-boutros-bfd-over-lag
BFD Working Group Sami Boutros
Internet Draft George Swallow
Intended status: Standards Track Nobo Akiya
Expires: December 2011
Cisco Systems, Inc
June 2011
BFD over LAG interfaces
draft-boutros-bfd-over-lag-00
Abstract
The Bidirectional Forwarding Detection (BFD) protocol is used to
detect faults on interfaces and data links. This document describes
a mechanism to run a BFD async session per member link of a Link
Aggregation (LAG) interface, BFD would be able to run at a much
aggressive rate then Link aggregation control protocol (LACP), and
can run in the absence of LACP, and would be able to verify L3
connectivity per member link.
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 [RFC2119].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
Boutros et al., Expires December 2011 [Page 1]
Internet-Draft draft-boutros-bfd-over-lag-00 June 2011
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30th, 2011.
Table of Contents
1. Introduction...................................................2
2. Bootstrapping BFD sessions per physical member link of a LAG...3
3. Scenarios......................................................3
3.1. Bootstrapping BFD sessions...................................3
3.2. Detecting a Link failure.....................................4
4. IANA Considerations............................................4
5. Security Considerations........................................4
6. References.....................................................5
6.1. Normative References.........................................5
Full Copyright Statement..........................................5
Intellectual Property Statement...................................6
1. Introduction
As described in [BFD], the Bidirectional Forwarding Detection (BFD)
protocol 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 as defined in [IEEE 802.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.
This document describes how to bootstrap and establish a BFD async
session per physical member link of the Link Aggregation (LAG)
interface.
We propose the use of LSP Ping to bootstrap a BFD session per
member link using mechanisms described in [RFC5884].
Boutros et al., Expires December, 2011 [Page 2]
Internet-Draft draft-boutros-bfd-over-lag-00 June 2011
2. Bootstrapping BFD sessions per physical member link of a LAG
LSP Ping will be used to bootstrap a BFD session per physical LAG
member.
An LSP Ping Echo Request will be sent per physical member link from
the source node to the target node, the request will contain a NIL
FEC, and a discriminator TLV.
The source node connected to the physical member link of the LAG,
would wait to see the BFD packet with the discriminator negotiated,
the target node MUST send BFD packets with the negotiated
discriminator and the source node MUST reply with BFD packets to
bring the BFD Async session up on the same member link it received
the BFD packets on.
In order to send BFD and LSP Ping packets over the member links
prior to L2 and L3 coming up, BFD and LSP Ping IP packets will need
to use an address from the 127.x range as a destination address, as
well the L2 header to be put on BFD/LSP Ping IP packets could be
one of the reserved Multicast MAC addresses defined in the scope of
[IEEE .1ad] to be the immediate next hop.
BFD and LSP Ping IP packets corresponding to a BFD session on a
physical member link will be pre-routed to the member link.
If both source and target nodes initiate an LSP Ping Echo request
to start a BFD session on a member link, each node MUST use the
same discriminator value of the other node in the BFD session on
this physical member link, this will make sure that we have one BFD
session per member link.
LSP Ping may be used for L3 address discovery prior to L3 coming
up, since if one side initiate the Echo request with its source
address, and 127.x destination address on a given physical member
link, the reply coming back on the same physical member link will
have the other side source address.
3. Scenarios
Assume 2 nodes A and B are connected via a LAG interface that has 3
member links link 1, 2 and 3, further assume that all member links
in the LAG interface are active.
3.1. Bootstrapping BFD sessions
Node A will send an LSP Ping Echo request on Link-1, by adding
Boutros et al., Expires December, 2011 [Page 3]
Internet-Draft draft-boutros-bfd-over-lag-00 June 2011
1- A NIL FEC.
2- Specifying a discriminator value corresponding to Link-1.
3- The ip destination address on the packet will be picked from the
127.x range.
The LSP Ping echo request will then be encaped with a L2 header, by
setting the destination mac to one of the reserved Multicast MAC
addresses defined in the scope of [IEEE 802.1ad].
Node B receives the LSP Ping Echo request, and may send an Echo
reply with its ip address to Node A.
Node B starts a BFD session using the negotiated discriminator
value in the BFD control packets. B then encapsulates the BFD
packets with a L2 header setting the destination mac to one of the
reserved Multicast MAC addresses defined in the scope of [IEEE
802.1ad].
Once Node A sees the BFD control packets coming on member Link-1,
Node A must reply to those BFD control packet on the same member
Link-1, negotiation MUST follow the same procedures defined in
[BFD] and [BFD-IP].
Node A will then repeat all the above on Link-2 and Link-3,
specifying a new discriminator value for each Link.
3.2. Detecting a Link failure
In the above scenario assume that Link-2 failed, once BFD detects
the failure on both node-A and node-B, each node will update its
forwarding table to remove the down link from the aggregation so
traffic can follow only on the remaining links 1 and 3.
4. IANA Considerations
TBD
5. Security Considerations
The proposal introduced in this document does not introduce any new
security considerations beyond that already apply to the base BFD
specification [BFD] and [BFD-IP].
Boutros et al., Expires December, 2011 [Page 4]
Internet-Draft draft-boutros-bfd-over-lag-00 June 2011
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", RFC 5880, June 2010.
[BFD-IP] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[RFC5884] Aggarwal, R. et al., Bidirectional Forwarding Detection
(BFD) for MPLS Label Switched Paths (LSPs), RFC 5884, June 2010.
Authors' Addresses
Sami Boutros
Cisco Systems, Inc.
Email: sboutros@cisco.com
George Swallow
Cisco Systems, Inc.
Email: swallow@cisco.com
Nobo Akiya
Cisco Systems, Inc.
Email: nobo@cisco.com
Full Copyright Statement
Copyright (c) 2011 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.
Boutros et al., Expires December, 2011 [Page 5]
Internet-Draft draft-boutros-bfd-over-lag-00 June 2011
All IETF Documents and the information contained therein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers
or users of this specification can be obtained from the IETF on-
line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document.
Please address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that
are published by third parties, including those that are translated
into other languages, should not be considered to be definitive
versions of IETF Documents. The definitive version of these Legal
Provisions is that published by, or under the auspices of, the
IETF. Versions of these Legal Provisions that are published by
third parties, including those that are translated into other
languages, should not be considered to be definitive versions of
these Legal Provions.
For the avoindance od doubt, each Contributor to the UETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect
Boutros et al., Expires December, 2011 [Page 6]
Internet-Draft draft-boutros-bfd-over-lag-00 June 2011
and shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Boutros et al., Expires December, 2011 [Page 7]
