idnits 2.17.1 draft-jdurand-auto-bfd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3335 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'TBD' on line 285 == Outdated reference: A later version (-12) exists of draft-ietf-idr-ix-bgp-route-server-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Durand 3 Internet-Draft CISCO 4 Intended status: Standards Track D. Freedman 5 Expires: September 10, 2015 Claranet 6 March 9, 2015 8 Path validation toward BGP next-hop with AUTO-BFD 9 draft-jdurand-auto-bfd-00.txt 11 Abstract 13 This document describes a solution called AUTO-BFD, that 14 automatically initiates BFD sessions for BGP next-hops. This makes 15 it possible to avoid blackholing scenarios when a BGP peer is not the 16 BGP next-hop, especially on Internet eXchange Points (IXPs) when BGP 17 Route-Servers are deployed. When they are configured with this 18 mechanism, routers can automatically try to establish a new adjacency 19 for every new BGP next-hop. BGP routes are then checked against the 20 state of the BFD session for the corresponding next-hop. 22 Foreword 24 A placeholder to list general observations about this document. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [1]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 10, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Definitions and Accronyms . . . . . . . . . . . . . . . . . . 3 68 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 3 69 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 70 5. BFD Session Ageing . . . . . . . . . . . . . . . . . . . . . 5 71 6. Possible other use cases . . . . . . . . . . . . . . . . . . 6 72 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 78 11.2. Informative References . . . . . . . . . . . . . . . . . 7 79 Appendix A. Configuration . . . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 Internet eXchange Points (IXPs) implement BGP Route-Servers (RS) [5] 85 so that connected members do not need to configure BGP peerings with 86 every other member to exchange routes. Through a single peering with 87 the RS, a member can receive routes of all the other members peering 88 with the RS. The RS redistributes routes and could simply be 89 described as a Route-Reflector for eBGP peerings. 91 Usually, deployed RS do not modify the BGP next-hop of exchanged 92 routes so traffic exchanged between IXP members does not pass through 93 the RS, which keeps only a control-plane role, exactly as for a BGP 94 RR. The drawback is that it may happen that a peering stays up 95 between members and route-server while there is no connectivity 96 between members. This results in black holes for members with no 97 easy troubleshooting: usually upon such problem a member just shuts 98 its connectivity to the IXP. This situation has happened several 99 times on many different IXPs and many members do not want to peer 100 with route-servers for this reason. 102 EBGP UP----> RS <-------EBGP UP 103 | | | 104 | | | 105 ----------------IXP LAN--------------------- 106 | | | | 107 V | | V 108 Member 1 <================> Member 2 109 BROKEN 110 CONNECTIVITY 112 Figure 1 114 This proposal intends to solve this situation with the automation of 115 BFD adjacency creation when new BGP next-hops are discovered. When 116 configured with this solution, routers can automatically try to 117 establish a new adjacency for every new BGP next-hop. BGP routes are 118 then checked against the BFD session states for the corresponding 119 next-hop. 121 2. Definitions and Accronyms 123 o BFD: Bidirectional Forwarding Detection protocol [3][4] 125 o BGP: Border Gateway Protocol [2] 127 o IXP: Internet eXchange Point 129 o RR: Route Reflector (BGP Route-Reflector) 131 o RS: Route Server (BGP Route-Server) [5] 133 3. Solution Requirements 135 The following requirements apply to the solution described in this 136 document: 138 o The solution MUST be independent of the BGP route-server's 139 configuration. In other words IXP members SHOULD be able to check 140 each other's liveliness without anything configured on the route- 141 server. 143 o Solution MUST NOT imply a configuration per IXP member. Each IXP 144 member SHOULD automatically discover other members and 145 automatically start probing when this is possible. 147 o The solution MUST accept situations when not all the IXP members 148 do not implement it. In other words the implementation of this 149 mechanism on one of the IXP member MUST NOT impact the other 150 members. 152 o The solution SHOULD rely on a widely adopted host liveliness 153 verification protocol in the context of BGP peerings. The used 154 host liveliness mechanism MUST be negotiated between members to 155 avoid false positives. 157 o The solution SHOULD be as simple as possible and SHOULD NOT 158 require the design of a new protocol. 160 Based on these requirements, the following is suggested: 162 o BFD [3] (Bidirectional Forwarding Detection) is an appropriate 163 liveliness verification mechanism that IXP members can use to 164 check their mutual status. It is widely adopted in the Internet 165 community for this use and its scalability on modern routers makes 166 it suitable for IXPs. Also BFD integrates an initial negotiation 167 phase that makes it appropriate to interdomain scenarios, when all 168 routers are not configured with the same options. 170 o IXP members cannot easily rely on an existing protocol to announce 171 their mutual capability to support a host liveliness protocol. 172 Since IXP members using BGP RS do not directly establish BGP 173 peerings between them, any use of BGP to announce BFD capability 174 would require solution support on the BGP RS which would prevent 175 any usage on an IXP not implementing it. Solutions based on 176 optional transitive BGP attribute have been studied [6] and showed 177 some complexity and privacy challenges as it could force every 178 member to disclose topology information globally to the 179 downstreams of other IXP members. 181 4. Solution Overview 183 The solution proposed in this document, named AUTO-BFD, is 184 straightforward and relies on existing mechanisms. It works as 185 follows: 187 o AUTO-BFD is configured on the BGP peering to the BGP RS. 189 o Every time a new BGP next-hop is received from this peering, AUTO- 190 BFD triggers a new BFD session with this next-hop (or reinstates 191 an existing session, see Section 5). The operation mode for this 192 BFD session MUST be asynchronous. Timers can be locally 193 configured. Optional security configuration can limit the number 194 of authorized adjacencies or trigger BFD only for next-hops in a 195 given prefix. Other optional configuration can define the BFD 196 timers. 198 o Routes coming from the AUTO-BFD enabled BGP neighbor are then 199 checked based on the BGP next-hop and its BFD session state. 200 Acceptance of routes is then subject to the administrative policy 201 based on BFD session state. An example of such a policy can be 202 found in appendix Appendix A 204 5. BFD Session Ageing 206 In order to maintain the relevance of AUTO-BFD sessions, it is 207 required to prune sessions when they are not needed anymore. A 208 router X may not simply prune BFD session toward Y when there are no 209 more routes with corresponding next-hop Y as the BFD session may 210 still be needed by the Y to accept route from X. 212 The following solution makes it possible to prune BFD sessions only 213 when it is sure the remote end does not need it anymore. A per- 214 session timer (bfd.AutoAge) is defined to determine an interval. 215 This timer MAY derive its configuration from a global value in an 216 implementation. The timer counts down until it expires, at which 217 point, the relevant AUTO-BFD session is checked against next-hop 218 information received from the AUTO-BFD configured BGP session to 219 determine if there are still next hops received which relate to the 220 session. Based on the information, the following occurs: 222 o If next-hops for the remote system are still being received, 223 bfd.LocalDiag should be set to XX, which will set the appropriate 224 diagnostic code "XX - Continuing AUTO-BFD" (to be assigned by 225 IANA) in the outgoing control packet, to indicate that the next 226 hop continues to be seen and used by this system. At this point, 227 the timer is reset and no further action is taken until it expires 228 next. 230 o If next-hops for the remote system are no longer being received, 231 the following occurs: 233 * If the session is still up (bfd.Sessionstate is UP) and a 234 control packet arrives which would not change the state, but 235 with the flag "XX - Continuing AUTO-BFD" set, this indicates 236 that the remote system is still receiving routes with the local 237 system as the next hop. In this case, the session MUST remain 238 up, the timer is reset and no further action is taken until it 239 expires next. 241 * If the session is still up (bfd.Sessionstate is UP) and a 242 control packet arrives which would not change the state, but 243 does not set the "XX - Continuing AUTO-BFD" diagnostic flag, 244 then we must consider that the remote system is no longer 245 receiving routes with the local system as next hop. In this 246 case, the bfd.LocalState should be set to 'AdminDown' and the 247 session should be placed in an Administrative Down state. 249 When a session is first established (or indeed re-established as per 250 Section 4), it is important that the bfd.LocalDiag should be set to 251 XX to ensure that control packets start to signal this state to the 252 remote system. 254 6. Possible other use cases 256 While the primary focus of the authors is to solve the issue met with 257 BGP route-servers on IXPs described in section Section 1, the 258 proposed solution may also apply to the following use cases: 260 o IBGP Route-Reflector (RR): the scenario described for BGP RS could 261 also apply for IBGP RR. The solution described in this draft 262 could be used to validate received IBGP routes against real 263 reachability of BGP next-hop (a router in same AS in case next-hop 264 self is used, or the EBGP next-hop announcing the route. 266 o Any EBGP peering: the proposed solution would enable automatic BFD 267 auto-deployment on every EBGP peering. AUTO-BFD would 268 automatically "harden" the peering without the need of any 269 additional configuration. 271 7. Future Work 273 Following points may need to be documented further in next versions 274 of this document based on comments received by the community: 276 o AUTO-BFD interoperability with manual BFD sessions. 278 o S-BFD integration 280 o Security considerations 282 8. Acknowledgements 284 The authors would like to thank the following people for their 285 comments and support: [TBD]. 287 9. IANA Considerations 289 This memo requests a code point from the registry for BFD diagnostic 290 codes [3]: XX -- Continuing Auto-BFD 292 10. Security Considerations 294 TBD 296 11. References 298 11.1. Normative References 300 [1] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, March 1997. 303 [2] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 304 Protocol 4 (BGP-4)", RFC 4271, January 2006. 306 [3] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 307 (BFD)", RFC 5880, June 2010. 309 [4] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 310 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 311 2010. 313 [5] "Internet Exchange Route Server", 314 . 317 11.2. Informative References 319 [6] "Path validation toward BGP next-hop", 320 . 323 Appendix A. Configuration 325 This configuration in classic Cisco IOS style will help reader 326 understand the way AUTO-BFD can be integrated in current deployments. 328 router bgp 65001 329 neighbor 192.0.2.102 remote-as 65102 330 ! 331 address-family ipv4 unicast 332 neighbor 192.0.2.102 activate 333 neighbor 192.0.2.102 auto-bfd 334 neighbor 192.0.2.102 route-map FROM-RS in 335 ! 336 route-map FROM-RS permit 10 337 match next-hop bfd-session-state Up 338 set local-pref 120 339 route-map FROM-RS deny 20 340 match next-hop bfd-session-state Down Init 341 route-map FROM-RS permit 30 342 match next-hop bfd-session-state AdminDown 343 set local-pref 50 345 Figure 2 347 Authors' Addresses 349 Jerome Durand 350 CISCO Systems, Inc. 351 11 rue Camille Desmoulins 352 Issy-les-Moulineaux 92782 CEDEX 353 FR 355 Email: jerduran@cisco.com 357 David Freedman 358 Claranet 359 21 Southampton Row, Holborn 360 London WC1B 5HA 361 UK 363 Email: david.freedman@uk.clara.net