Internet Engineering Task Force J. Durand Internet-Draft CISCO Intended status: Standards Track D. Freedman Expires: September 10, 2015 Claranet March 9, 2015 Path validation toward BGP next-hop with AUTO-BFD draft-jdurand-auto-bfd-00.txt Abstract This document describes a solution called AUTO-BFD, that automatically initiates BFD sessions for BGP next-hops. This makes it possible to avoid blackholing scenarios when a BGP peer is not the BGP next-hop, especially on Internet eXchange Points (IXPs) when BGP Route-Servers are deployed. When they are configured with this mechanism, routers can automatically try to establish a new adjacency for every new BGP next-hop. BGP routes are then checked against the state of the BFD session for the corresponding next-hop. Foreword A placeholder to list general observations about this document. 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 RFC 2119 [1]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 10, 2015. Durand & Freedman Expires September 10, 2015 [Page 1] Internet-Draft AUTO-BFD March 2015 Copyright Notice Copyright (c) 2015 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions and Accronyms . . . . . . . . . . . . . . . . . . 3 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 3 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 5. BFD Session Ageing . . . . . . . . . . . . . . . . . . . . . 5 6. Possible other use cases . . . . . . . . . . . . . . . . . . 6 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Configuration . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Internet eXchange Points (IXPs) implement BGP Route-Servers (RS) [5] so that connected members do not need to configure BGP peerings with every other member to exchange routes. Through a single peering with the RS, a member can receive routes of all the other members peering with the RS. The RS redistributes routes and could simply be described as a Route-Reflector for eBGP peerings. Usually, deployed RS do not modify the BGP next-hop of exchanged routes so traffic exchanged between IXP members does not pass through the RS, which keeps only a control-plane role, exactly as for a BGP RR. The drawback is that it may happen that a peering stays up between members and route-server while there is no connectivity between members. This results in black holes for members with no Durand & Freedman Expires September 10, 2015 [Page 2] Internet-Draft AUTO-BFD March 2015 easy troubleshooting: usually upon such problem a member just shuts its connectivity to the IXP. This situation has happened several times on many different IXPs and many members do not want to peer with route-servers for this reason. EBGP UP----> RS <-------EBGP UP | | | | | | ----------------IXP LAN--------------------- | | | | V | | V Member 1 <================> Member 2 BROKEN CONNECTIVITY Figure 1 This proposal intends to solve this situation with the automation of BFD adjacency creation when new BGP next-hops are discovered. When configured with this solution, routers can automatically try to establish a new adjacency for every new BGP next-hop. BGP routes are then checked against the BFD session states for the corresponding next-hop. 2. Definitions and Accronyms o BFD: Bidirectional Forwarding Detection protocol [3][4] o BGP: Border Gateway Protocol [2] o IXP: Internet eXchange Point o RR: Route Reflector (BGP Route-Reflector) o RS: Route Server (BGP Route-Server) [5] 3. Solution Requirements The following requirements apply to the solution described in this document: o The solution MUST be independent of the BGP route-server's configuration. In other words IXP members SHOULD be able to check each other's liveliness without anything configured on the route- server. Durand & Freedman Expires September 10, 2015 [Page 3] Internet-Draft AUTO-BFD March 2015 o Solution MUST NOT imply a configuration per IXP member. Each IXP member SHOULD automatically discover other members and automatically start probing when this is possible. o The solution MUST accept situations when not all the IXP members do not implement it. In other words the implementation of this mechanism on one of the IXP member MUST NOT impact the other members. o The solution SHOULD rely on a widely adopted host liveliness verification protocol in the context of BGP peerings. The used host liveliness mechanism MUST be negotiated between members to avoid false positives. o The solution SHOULD be as simple as possible and SHOULD NOT require the design of a new protocol. Based on these requirements, the following is suggested: o BFD [3] (Bidirectional Forwarding Detection) is an appropriate liveliness verification mechanism that IXP members can use to check their mutual status. It is widely adopted in the Internet community for this use and its scalability on modern routers makes it suitable for IXPs. Also BFD integrates an initial negotiation phase that makes it appropriate to interdomain scenarios, when all routers are not configured with the same options. o IXP members cannot easily rely on an existing protocol to announce their mutual capability to support a host liveliness protocol. Since IXP members using BGP RS do not directly establish BGP peerings between them, any use of BGP to announce BFD capability would require solution support on the BGP RS which would prevent any usage on an IXP not implementing it. Solutions based on optional transitive BGP attribute have been studied [6] and showed some complexity and privacy challenges as it could force every member to disclose topology information globally to the downstreams of other IXP members. 4. Solution Overview The solution proposed in this document, named AUTO-BFD, is straightforward and relies on existing mechanisms. It works as follows: o AUTO-BFD is configured on the BGP peering to the BGP RS. o Every time a new BGP next-hop is received from this peering, AUTO- BFD triggers a new BFD session with this next-hop (or reinstates Durand & Freedman Expires September 10, 2015 [Page 4] Internet-Draft AUTO-BFD March 2015 an existing session, see Section 5). The operation mode for this BFD session MUST be asynchronous. Timers can be locally configured. Optional security configuration can limit the number of authorized adjacencies or trigger BFD only for next-hops in a given prefix. Other optional configuration can define the BFD timers. o Routes coming from the AUTO-BFD enabled BGP neighbor are then checked based on the BGP next-hop and its BFD session state. Acceptance of routes is then subject to the administrative policy based on BFD session state. An example of such a policy can be found in appendix Appendix A 5. BFD Session Ageing In order to maintain the relevance of AUTO-BFD sessions, it is required to prune sessions when they are not needed anymore. A router X may not simply prune BFD session toward Y when there are no more routes with corresponding next-hop Y as the BFD session may still be needed by the Y to accept route from X. The following solution makes it possible to prune BFD sessions only when it is sure the remote end does not need it anymore. A per- session timer (bfd.AutoAge) is defined to determine an interval. This timer MAY derive its configuration from a global value in an implementation. The timer counts down until it expires, at which point, the relevant AUTO-BFD session is checked against next-hop information received from the AUTO-BFD configured BGP session to determine if there are still next hops received which relate to the session. Based on the information, the following occurs: o If next-hops for the remote system are still being received, bfd.LocalDiag should be set to XX, which will set the appropriate diagnostic code "XX - Continuing AUTO-BFD" (to be assigned by IANA) in the outgoing control packet, to indicate that the next hop continues to be seen and used by this system. At this point, the timer is reset and no further action is taken until it expires next. o If next-hops for the remote system are no longer being received, the following occurs: * If the session is still up (bfd.Sessionstate is UP) and a control packet arrives which would not change the state, but with the flag "XX - Continuing AUTO-BFD" set, this indicates that the remote system is still receiving routes with the local system as the next hop. In this case, the session MUST remain Durand & Freedman Expires September 10, 2015 [Page 5] Internet-Draft AUTO-BFD March 2015 up, the timer is reset and no further action is taken until it expires next. * If the session is still up (bfd.Sessionstate is UP) and a control packet arrives which would not change the state, but does not set the "XX - Continuing AUTO-BFD" diagnostic flag, then we must consider that the remote system is no longer receiving routes with the local system as next hop. In this case, the bfd.LocalState should be set to 'AdminDown' and the session should be placed in an Administrative Down state. When a session is first established (or indeed re-established as per Section 4), it is important that the bfd.LocalDiag should be set to XX to ensure that control packets start to signal this state to the remote system. 6. Possible other use cases While the primary focus of the authors is to solve the issue met with BGP route-servers on IXPs described in section Section 1, the proposed solution may also apply to the following use cases: o IBGP Route-Reflector (RR): the scenario described for BGP RS could also apply for IBGP RR. The solution described in this draft could be used to validate received IBGP routes against real reachability of BGP next-hop (a router in same AS in case next-hop self is used, or the EBGP next-hop announcing the route. o Any EBGP peering: the proposed solution would enable automatic BFD auto-deployment on every EBGP peering. AUTO-BFD would automatically "harden" the peering without the need of any additional configuration. 7. Future Work Following points may need to be documented further in next versions of this document based on comments received by the community: o AUTO-BFD interoperability with manual BFD sessions. o S-BFD integration o Security considerations Durand & Freedman Expires September 10, 2015 [Page 6] Internet-Draft AUTO-BFD March 2015 8. Acknowledgements The authors would like to thank the following people for their comments and support: [TBD]. 9. IANA Considerations This memo requests a code point from the registry for BFD diagnostic codes [3]: XX -- Continuing Auto-BFD 10. Security Considerations TBD 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [3] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [4] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010. [5] "Internet Exchange Route Server", . 11.2. Informative References [6] "Path validation toward BGP next-hop", . Appendix A. Configuration This configuration in classic Cisco IOS style will help reader understand the way AUTO-BFD can be integrated in current deployments. Durand & Freedman Expires September 10, 2015 [Page 7] Internet-Draft AUTO-BFD March 2015 router bgp 65001 neighbor 192.0.2.102 remote-as 65102 ! address-family ipv4 unicast neighbor 192.0.2.102 activate neighbor 192.0.2.102 auto-bfd neighbor 192.0.2.102 route-map FROM-RS in ! route-map FROM-RS permit 10 match next-hop bfd-session-state Up set local-pref 120 route-map FROM-RS deny 20 match next-hop bfd-session-state Down Init route-map FROM-RS permit 30 match next-hop bfd-session-state AdminDown set local-pref 50 Figure 2 Authors' Addresses Jerome Durand CISCO Systems, Inc. 11 rue Camille Desmoulins Issy-les-Moulineaux 92782 CEDEX FR Email: jerduran@cisco.com David Freedman Claranet 21 Southampton Row, Holborn London WC1B 5HA UK Email: david.freedman@uk.clara.net Durand & Freedman Expires September 10, 2015 [Page 8]