idnits 2.17.1 draft-ietf-idr-rs-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 seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 1, 2015) is 3193 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) == Unused Reference: 'RFC2439' is defined on line 295, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-idr-bgp-nh-cost-02 == Outdated reference: A later version (-12) exists of draft-ietf-idr-ix-bgp-route-server-07 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Internet Initiative Japan 4 Intended status: Standards Track J. Haas 5 Expires: January 2, 2016 J. Scudder 6 Juniper Networks, Inc. 7 A. Nipper 8 T. King, Ed. 9 DE-CIX Management GmbH 10 July 1, 2015 12 Making Route Servers Aware of Data Link Failures at IXPs 13 draft-ietf-idr-rs-bfd-00 15 Abstract 17 When route servers are used, the data plane is not congruent with the 18 control plane. Therefore, the peers on the Internet exchange can 19 lose data connectivity without the control plane being aware of it, 20 and packets are dropped on the floor. This document proposes the use 21 of BFD between the two peering routers to detect a data plane 22 failure, and then uses BGP next hop cost to signal the state of the 23 data link to the route server(s). 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 29 be interpreted as described in [RFC2119] only when they appear in all 30 upper case. They may also appear in lower or mixed case as English 31 words, without normative meaning. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 2, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Mutual Discovery of Route Server Client Routers . . . . . 3 70 2.2. Tracking Connectivity . . . . . . . . . . . . . . . . . . 4 71 3. Advertising Client Router Connectivity to the Route Server . 4 72 4. Utilizing Next Hop Unreachability Information at Client 73 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 5. Recommendations for Using BFD . . . . . . . . . . . . . . . . 5 75 6. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7. Other Considerations . . . . . . . . . . . . . . . . . . . . 6 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 In configurations (typically Internet exchanges) where EBGP routing 83 information is exchanged between client routers through the agency of 84 a route server [I-D.ietf-idr-ix-bgp-route-server], but traffic is 85 exchanged directly, operational issues can arise when partial data 86 plane connectivity exists among the route server client routers. 87 This is because, as the data plane is not congruent with the control 88 plane, the client routers on the Internet exchange can lose data 89 connectivity without the control plane - the route server - being 90 aware of it, and packets are dropped on the floor. 92 To remedy this, two basic problems need to be solved: 94 1. Client routers must have a means of verifying connectivity 95 amongst themselves, and 96 2. Client routers must have a means of communicating the knowledge 97 so gained back to the route server. 99 The first can be solved by application of Bidirectional Forwarding 100 Detection [RFC5880]. The second can be solved by use of BGP NH-SAFI 101 [I-D.ietf-idr-bgp-nh-cost]. There is a subsidiary problem that must 102 also be solved. Since one of the key value propositions offered by a 103 route server is that client routers need not be configured to peer 104 with each other: 106 3. Client routers must have a means (other than configuration) to 107 know of one another's existence. 109 This can also be solved by an application of BGP NH-SAFI. 111 Throughout this document, we generally assume that the route server 112 being discussed is able to represent different RIBs towards different 113 clients, as discussed in section 2.3.2.1. 114 [I-D.ietf-idr-ix-bgp-route-server]. These procedures (other than the 115 use of BFD to track next hop reachability) have limited value if this 116 is not the case. 118 2. Operation 120 Below, we detail procedures where a route server tells its client 121 routers about other client routers (by sending it their next hops 122 using NH-SAFI), the client router verifies connectivity to those 123 other client routers (using BFD) and communicates its findings back 124 to the route server (again using NH-SAFI). The route server uses the 125 received NH-SAFI routes as input to the route selection process it 126 performs on behalf of the client. 128 2.1. Mutual Discovery of Route Server Client Routers 130 Strictly speaking, what is needed is not for a route server client 131 router to know of other (control-plane) client routers, but rather to 132 know (so that it can validate) all the next hops the route server 133 might choose to send the client router, i.e. to know of potential 134 forwarding plane relationships. 136 In effect, this requirement amounts to knowing the BGP next hops the 137 route server is aware of in its Adj-RIBs-In. Fortunately, 138 [I-D.ietf-idr-bgp-nh-cost] defines a construct that contains exactly 139 this data, the "Next-Hop Information Base", or NHIB, as well as 140 procedures for a BGP speaker to communicate its NHIB to its peer. 141 Thus, the problem can be solved by the route server advertising its 142 NHIB to its client router, following those procedures. 144 We observe that (as per NH-SAFI) the cost advertised in the route 145 server's Adj-NHIB-Out need not reflect a "real" IGP cost, the only 146 requirement being that the advertised costs are commensurate. A 147 route server MAY choose to advertise any fixed cost other than all- 148 ones (which is a reserved value in NH-SAFI). This specification does 149 not suggest semantics be imputed to the NH-SAFI advertised by the 150 route server and received by the client, other than "this next hop is 151 present in the control plane, you might like to track it". The route 152 server is not allowed to advertise a next hop as NH_UNREACHABLE. 154 A route server client SHOULD use BFD (or other means beyond the scope 155 of this document) to track forwarding plane connectivity [RFC5880] to 156 each next hop depicted in the received NH-SAFI. 158 2.2. Tracking Connectivity 160 For each next hop in the Adj-NHIB-In received from the route server, 161 the client router SHOULD use some means to confirm that data plane 162 connectivity does exist to that next hop. 164 For each next hop in the Adj-NHIB-In received from the route server, 165 the client router SHOULD setup a BFD session to it if one is not 166 already available and track the reachability of this next hop. 168 For each next hop being tracked, a corresponding NH-SAFI route should 169 be placed in the client router's own Adj-NHIB-Out to be advertised to 170 the route server. Any next hop for which connectivity has failed 171 should have its cost advertised as NH_UNREACHABLE. (This may also be 172 done as a result of policy even if connectivity exists.) Any other 173 next hop should have some feasible cost advertised. The values 174 advertised may be all equal, or may be set according to policy or 175 other implementation-specific means. 177 If the test of connectivity between one client router and another 178 client router has failed the client router that detected this failure 179 should perform connectivity test for a configurable amount of time 180 (preferable 24 hours) on a regular basis (e.g. every 5 minutes). If 181 during this time no connectivity can be restored no more testing is 182 performed and this client router is advertised as NH_UNREACHABLE 183 until manually changed or the client router is rebooted. 185 3. Advertising Client Router Connectivity to the Route Server 187 As discussed above, a client router will advertise its Adj-NHIB-Out 188 to the route server. The route server should use this information as 189 input to its own decision process when computing the Adj-RIB-Out for 190 this peer. This peer-dependent Adj-RIB-Out is then advertised to 191 this peer. In particular, the route server MUST exclude any routes 192 whose next hops the client has declared to be NH_UNREACHABLE. The 193 route server MAY also consider the advertised cost to be the "IGP 194 cost" section 9.1 [RFC4271] when doing this computation. 196 4. Utilizing Next Hop Unreachability Information at Client Routers 198 A client router detecting an unreachable next hop signals this 199 information to the route server as described above. Also, it treats 200 the routes as unresolvable as per section 9.1.2.1 [RFC4271] and 201 proceeds with route selection as normal. 203 Changes in nexthop reachability via these mechanisms should receive 204 some amount of consideration toward avoiding unnecessary route 205 flapping. Similar mechanisms exist in IGP implementations and should 206 be applied to this scenario. 208 5. Recommendations for Using BFD 210 The RECOMMENDED way a client router can confirm the data plane 211 connectivity to its next hops is available, is the use of BFD in 212 asynchronous mode. Echo mode MAY be used if both client routers 213 running a BFD session support this. The use of authentication in BFD 214 is OPTIONAL as there is a certain level of trust between the 215 operators of the client routers at a particular IXP. If trust cannot 216 be assumed, it is recommended to use pair-wise keys (how this can be 217 achieved is outside the scope of this document). The ttl/hop limit 218 values as described in section 5 [RFC5881] MUST be obeyed in order to 219 secure BFD sessions from packets coming from outside the IXP. 221 There is interdependence between the functionality described in this 222 document and BFD from an administrative point of view. To streamline 223 behaviour of different implementations the following is RECOMMENDED: 225 o If BFD is administratively shut down by the administrator of a 226 client router then the functionality described in this document 227 MUST also be administratively shut down. 228 o If the administrator enables the functionality described in this 229 document on a client router then BFD MUST be automatically 230 enabled. 232 The following values of the BFD configuration of client routers (see 233 section 6.8.1 [RFC5880]) are RECOMMENDED in order to allow a fast 234 detection of lost data plane connectivity: 236 o DesiredMinTxInterval: 1,000,000 (microseconds) 237 o RequiredMinRxInterval: 1,000,000 (microseconds) 238 o DetectMult: 3 239 The configuration values above are a trade-off between fast detection 240 of data plane connectivity and the load client routers must handle 241 keeping up the BFD communication. Selecting smaller 242 DesiredMinTxInterval and RequiredMinRxInterval values generates lots 243 of BFD packets, especially at larger IXPs with many hundreds of 244 client routers. 246 The configuration values above are selected in order to handle brief 247 interrupts on the data plane. Otherwise, if a BFD session detects a 248 brief data plane interrupt to a particular client router, it will 249 cause to signal the route server that it should remove routes from 250 this client router and tell it shortly afterwards to add the routes 251 again. This is disruptive and computational expensive on the route 252 server. 254 The configuration values above are also partially impacted by BGP 255 advertisement time in reaction to events from BFD. If the 256 configuration values are selected so that BFD detects data plane 257 interrupts a lot faster than the BGP advertisement time, a data plane 258 connectivity flapping could be detected by BFD but the route server 259 is not informed about them because BGP is not able to transport this 260 information fast enough. 262 As discussed, finding good configuration values is hard so a client 263 router administrator MAY select better suited values depending on the 264 special needs of the particular deployment. 266 6. Bootstrapping 268 If the route server starts it does not know anything about 269 connectivity states between client routers. So, the route server 270 assumes optimistically that all client routers are able to reach each 271 other unless told otherwise. 273 7. Other Considerations 275 For purposes of routing stability, implementations may wish to apply 276 hysteresis ("holddown") to next hops that have transitioned from 277 reachable to unreachable and back. 279 8. Normative References 281 [I-D.ietf-idr-bgp-nh-cost] 282 Varlashkin, I., Raszuk, R., Patel, K., Bhardwaj, M., and 283 S. Bayraktar, "Carrying next-hop cost information in BGP", 284 draft-ietf-idr-bgp-nh-cost-02 (work in progress), May 285 2015. 287 [I-D.ietf-idr-ix-bgp-route-server] 288 Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 289 "Internet Exchange BGP Route Server", draft-ietf-idr-ix- 290 bgp-route-server-07 (work in progress), June 2015. 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 296 Flap Damping", RFC 2439, November 1998. 298 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 299 Protocol 4 (BGP-4)", RFC 4271, January 2006. 301 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 302 (BFD)", RFC 5880, June 2010. 304 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 305 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 306 2010. 308 Authors' Addresses 310 Randy Bush 311 Internet Initiative Japan 312 5147 Crystal Springs 313 Bainbridge Island, Washington 98110 314 US 316 Email: randy@psg.com 318 Jeffrey Haas 319 Juniper Networks, Inc. 320 1194 N. Mathilda Ave. 321 Sunnyvale, CA 94089 322 US 324 Email: jhaas@juniper.net 326 John G. Scudder 327 Juniper Networks, Inc. 328 1194 N. Mathilda Ave. 329 Sunnyvale, CA 94089 330 US 332 Email: jgs@juniper.net 333 Arnold Nipper 334 DE-CIX Management GmbH 335 Lichtstrasse 43i 336 Cologne 50825 337 Germany 339 Email: arnold.nipper@de-cix.net 341 Thomas King (editor) 342 DE-CIX Management GmbH 343 Lichtstrasse 43i 344 Cologne 50825 345 Germany 347 Email: thomas.king@de-cix.net