idnits 2.17.1 draft-ymbk-idr-rs-bfd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 (February 5, 2015) is 3369 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) == Outdated reference: A later version (-03) exists of draft-ietf-idr-bgp-nh-cost-01 == Outdated reference: A later version (-12) exists of draft-ietf-idr-ix-bgp-route-server-06 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: August 9, 2015 J. Scudder 6 Juniper Networks, Inc. 7 A. Nipper 8 T. King, Ed. 9 DE-CIX Management GmbH 10 February 5, 2015 12 Making Route-Servers Aware of Data Link Failures at IXPs 13 draft-ymbk-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 August 9, 2015. 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 This document may not be modified, and derivative works of it may not 66 be created, and it may not be published except as an Internet-Draft. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2.1. Mutual Discovery of Route Server Client Routers . . . . . 3 73 2.2. Tracking Connectivity . . . . . . . . . . . . . . . . . . 4 74 3. Advertising Client Router Connectivity to the Route Server . 5 75 4. Bootstraping . . . . . . . . . . . . . . . . . . . . . . . . 5 76 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 5 77 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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 One way that is highly recommended is the use of BFD in echo mode. 165 Authentication may or may not be used. For each next hop in the Adj- 166 NHIB-In received from the route server, the client router SHOULD 167 setup a BFD session to it if not one is already available and track 168 the reachability of this next hop. 170 For each next hop being tracked, a corresponding NH-SAFI route should 171 be placed in the client router's own Adj-NHIB-Out to be advertised to 172 the route server. Any next hop for which connectivity has failed 173 should have its cost advertised as NH_UNREACHABLE. (This may also be 174 done as a result of policy even if connectivity exists.) Any other 175 next hop should have some feasible cost advertised. The values 176 advertised may be all equal, or may be set according to policy or 177 other implementation-specific means. 179 If the test of connectivity between on client router and another 180 client router has failed the client router that detected this failure 181 should perform connectivity test for a configurable amount of time 182 (preferable 24 hours) on a regular basis (e.g., every 5 minutes). If 183 during this time no connectivity can be restored no more testing is 184 performed and this client router is advertised as NH_UNREACHABLE 185 until manually changed or the client router is rebooted. 187 A client router tracking next hop reachability should also use that 188 determination as input to its own bestpath determination, as per 189 section 9.1 [RFC4271]. 191 3. Advertising Client Router Connectivity to the Route Server 193 As discussed above, a client router will advertise its Adj-NHIB-Out 194 to the route server. The route server should use this information as 195 input to its own decision process when computing the Adj-RIB-Out for 196 this peer. This peer-dependent Adj-RIB-Out is then be advertised to 197 this peer. In particular, the route server MUST exclude any routes 198 whose next hops the client has declared to be NH_UNREACHABLE. The 199 route server MAY also consider the advertised cost to be the "IGP 200 cost" section 9.1 [RFC4271] when doing this computation. 202 4. Bootstraping 204 If the route server starts it does not know anything about 205 connectivity states between client routers. So, the route server 206 assumes optimistically that all client routers are able to reach each 207 other unless told otherwise. 209 5. Other Considerations 211 For purposes of routing stability, implementations may wish to apply 212 hysteresis ("holddown") to next hops that have transitioned from 213 reachable to unreachable and back. 215 6. Normative References 217 [I-D.ietf-idr-bgp-nh-cost] 218 Varlashkin, I. and R. Raszuk, "Carrying next-hop cost 219 information in BGP", draft-ietf-idr-bgp-nh-cost-01 (work 220 in progress), March 2012. 222 [I-D.ietf-idr-ix-bgp-route-server] 223 Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 224 "Internet Exchange Route Server", draft-ietf-idr-ix-bgp- 225 route-server-06 (work in progress), December 2014. 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 231 Protocol 4 (BGP-4)", RFC 4271, January 2006. 233 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 234 (BFD)", RFC 5880, June 2010. 236 Authors' Addresses 238 Randy Bush 239 Internet Initiative Japan 240 5147 Crystal Springs 241 Bainbridge Island, Washington 98110 242 US 244 Email: randy@psg.com 246 Jeffrey Haas 247 Juniper Networks, Inc. 248 1194 N. Mathilda Ave. 249 Sunnyvale, CA 94089 250 US 252 Email: jhaas@juniper.net 254 John G. Scudder 255 Juniper Networks, Inc. 256 1194 N. Mathilda Ave. 257 Sunnyvale, CA 94089 258 US 260 Email: jgs@juniper.net 262 Arnold Nipper 263 DE-CIX Management GmbH 264 Lichtstrasse 43i 265 Cologne 50825 266 Germany 268 Email: arnold.nipper@de-cix.net 270 Thomas King (editor) 271 DE-CIX Management GmbH 272 Lichtstrasse 43i 273 Cologne 50825 274 Germany 276 Email: thomas.king@de-cix.net