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]