idnits 2.17.1 draft-litkowski-idr-rtc-interas-01.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 an Introduction section. ** There are 10 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The abstract seems to contain references ([RFC4684]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2015) is 3341 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: 'RFC4364' is defined on line 328, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interdomain Working Group S. Litkowski 3 Internet-Draft Orange Business Service 4 Intended status: Standards Track J. Haas 5 Expires: September 6, 2015 Juniper Networks 6 K. Patel 7 Cisco Systems 8 March 5, 2015 10 Inter Domain considerations for Constrained Route distribution 11 draft-litkowski-idr-rtc-interas-01 13 Abstract 15 [RFC4684] defines Multi-Protocol BGP (MP-BGP) procedures that allow 16 BGP speakers to exchange Route Target reachability information in 17 order to limit the propagation of Virtual Private Networks (VPN) 18 Network Layer Reachability Information (NLRI). 20 [RFC4684] addresses both intra domain and inter domain distributions. 21 Based on operational deployments, the current distribution model 22 defined in [RFC4684] may cause some issue in specific scenarios. 24 This document refines the route distribution rules for inter domain 25 NLRIs in order to address these specific scenarios. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in [RFC2119]. 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 September 6, 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 Table of Contents 67 1. External NLRI propagation . . . . . . . . . . . . . . . . . . 2 68 1.1. Peering type based pruning . . . . . . . . . . . . . . . 3 69 1.2. NLRI type based pruning . . . . . . . . . . . . . . . . . 4 70 1.3. Analysis of both approaches . . . . . . . . . . . . . . . 4 71 2. Problem statement : disjoint peer AS . . . . . . . . . . . . 5 72 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Security considerations . . . . . . . . . . . . . . . . . . . 7 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. External NLRI propagation 81 [RFC4684] Section 3.1 and 3.2 describes propagation of Route Target 82 NLRI between ASes and inside an AS and distinguish two types of NLRIs 83 : 85 o Locally originated NLRI where origin-as field of the NLRI is equal 86 to the local AS number. 88 o External NLRI where origin-as field of the NLRI is different from 89 the local AS number. 91 The global idea of inter AS propagation, is to propagate only VPN 92 routes on shortest path towards the peer ASes using pruning of some 93 branches of the distribution tree. 95 Based on current implementations of RFC4684, we can see two flavors 96 of pruning for interAS that are both compatible with RFC4684 text. 98 o Pruning based on peering type : pruning rule is applied when RT 99 membership path are learned from eBGP peers only. No pruning is 100 applied when path is iBGP. 102 o Pruning based on NLRI type : pruning rule is applied to external 103 RT membership NLRIs (source AS different from local AS). This 104 pruning rule applies both to eBGP and iBGP. 106 1.1. Peering type based pruning 108 AS 400 AS 500 109 | 110 ASBR1 --- (mpebgp vpnv4+rtc)___ 111 | \ 112 | \ 113 ASBR2 --- (mpebgp vpnv4+rtc) -- PE1 114 | \ 115 | (mpibgp vpnv4+rtc) 116 | \ 117 | RR ------------ PE3 118 | / 119 | (mpibgp vpnv4+rtc) 120 | / 121 ASBR3 --- (mpebgp vpnv4+rtc) -- PE2 122 | 123 | 125 Figure 1 127 In the figure above, ASBR1,ASBR2 and ASBR3 are MPLS VPN nodes part of 128 the AS 400. We consider that all these ASBRs are importing the same 129 RT : 400:1, which is also exported by PE3. All ASBRs will generate 130 the same RT membership NLRI 400:400:1/96 towards their PE. PE2 will 131 send its path for this RT membership to RR. As PE1 has two ebgp 132 paths for the same RT membership NLRI, it will apply pruning (as per 133 peering type based pruning policy), if we consider that path from 134 ASBR1 is the best path, RT distribution tree will only have a branch 135 to ASBR1, and so ASBR2 will not receive any VPN route for RT 400:1 136 from PE1. PE1 will also send the RT membership NLRI to RR. RR will 137 so have two paths for NLRI 400:400:1/96. As both path are iBGP, no 138 pruning will be applied (as per peering type based pruning policy), 139 and RR will create tree branches for 400:1 to both PE1 and PE2. As a 140 result, VPN routes originated by PE3 with RT 400:1 will be sent by RR 141 to PE1 and PE2. PE1 will propagate the routes only to ASBR1. PE2 142 will propagate the routes to ASBR3. AS 400 will have knowledge from 143 PE3 routes only from ASBR1 and ASBR2. 145 1.2. NLRI type based pruning 147 We consider the same setup as in Figure 1. All ASBRs will generate 148 the same RT membership NLRI 400:400:1/96 towards their PE. PE2 will 149 send its path for this RT membership to RR. As PE1 has two ebgp 150 paths for the same external RT membership NLRI, it will apply pruning 151 (as per NLRI type based pruning policy, pruning is applied because 152 NLRI is external), if we consider that path from ASBR1 is the best 153 path, RT distribution tree will only have a branch to ASBR1, and so 154 ASBR2 will not receive any VPN route for RT 400:1 from PE1. PE1 will 155 also send the RT membership NLRI to RR. RR will so have two paths 156 for NLRI 400:400:1/96. As the NLRI is external, pruning will be 157 applied : if we consider that path from PE1 is the best one, a single 158 branch of distribution tree will be added towards PE1. As a result, 159 VPN routes originated by PE3 with RT 400:1 will be sent by RR to PE1 160 only. PE1 will propagate the routes only to ASBR1. AS 400 will have 161 knowledge from PE3 routes only from ASBR1. 163 AS 400 AS 500 AS 400 164 | | 165 | | 166 | | 167 cPE1 --------- sPE1 ------ RR ------- sPE2 ---------- cPE2 168 | | 169 | | 170 Figure 2 172 Figure 2 presents at typical case where an AS (AS400) uses another AS 173 (AS500) as transit to build VPN services. If cPE1 and cPE2 shares a 174 common VPN using RT 400:1, in case of NLRI type based pruning in 175 AS500, RR in AS500 will perform pruning of VPN routes for NLRI 176 400:400:1/96. Considering that path from sPE1 is considered as best 177 path, sPE2 will be pruned and cPE2 will never receive VPN routes from 178 cPE1. This issue is discussed further in Section 2. 180 1.3. Analysis of both approaches 182 Both pruning approaches have pros and cons. Service Provider will 183 need to be aware of this pros/cons while deploying inter AS RTC. 185 o NLRI type based pruning helps in saving BGP paths in network 186 nodes, inter AS distribution tree is only established on shortest 187 path (at AS boundary and within the AS). In figure 1, PE2 does 188 not receive VPN routes for RT 400:1 because these routes are 189 already advertised through another path. This approach prevents 190 hot potatoe routing and transit for disjoint ASes. 192 o Peering type based pruning is based on the fact that the local AS 193 does not know the precise location of the VPNs in the peer AS, so 194 there is no reason for a route reflector to perform blind pruning 195 that may lead to suboptimal routing. In figure 1, if we consider 196 that ASBR3 is located in New York City, and ASBR1/2 are located in 197 San Francisco. Considering that PE3 is located in Washington, 198 performing NLRI type based pruning will prevent ASBR3 to receive 199 PE3 routes, so routing from Washington to New York City will 200 transit through San Francisco. We must note that in case of ASBR1 201 and ASBR2 being in two far cities, peering type based pruning will 202 also suffer from suboptimal routing. The other point in favor of 203 peering type pruning is faster convergence. In figure 1, when PE1 204 fails, backup routes are already available in AS400 through ASBR3. 206 As a summary, NLRI type based pruning helps in saving BGP paths in 207 the transit networks, while peering type based pruning permits more 208 optimal routing and faster convergence with the drawback of 209 propagating additional routes. Peering type based pruning may also 210 experience convergence or suboptimal routing case in case a single 211 node is attached to multiple routers in the external AS. 213 2. Problem statement : disjoint peer AS 215 The previous section described how inter AS route distribution works 216 and pros and cons of the existing approaches. Apart of these pros/ 217 cons, pruning in both solutions may lead to some problematic 218 situation where the remote AS is disjoint, as already shown in 219 Section 1.2. 221 +-------+ 222 | DC1 | -- CE1 -- (mpebgp vpnv4+rtc) -- PE1 223 +-------+ \ 224 (mpibgp vpnv4+rtc) 225 \ 226 RR 227 / 228 (mpibgp vpnv4+rtc) 229 +-------+ / 230 | DC2 | -- CE2 -- (mpebgp vpnv4+rtc) -- PE2 231 +-------+ 232 Figure 3 234 The figure above describes another typical service provider scenario 235 where datacenters are connected through MPLS VPN interas option B 236 with the Service Provider network. Route Target Constraint (RTC) is 237 deployed on MPeBGP sessions as well as internally in the service 238 provider network to ensure optimal distribution of VPN routes 239 (required for scaling reason). In this scenario, both Datacenters 240 are using the same AS number, generally a private ASN (65000) like a 241 typical PE-CE connection. As we expect DCs to communicate between 242 each other, some features like "as-override" are deployed on PEs to 243 overcome ASPATH loop issue. 245 In the Figure 3, CE1 and CE2 are advertising the RT 1:1 respectively 246 to PE1 and PE2, the generated NLRI would be 65000:1:1/96. According 247 to procedures defined in [RFC4684] Section 3.2, both PEs are using 248 the standard BGP route selection and advertising rules. So both PEs 249 are advertising their path for 65000:1:1/96 to the route-reflector. 250 In case of NLRI type based pruning, route-reflector will establish 251 the distribution tree only to PE1 (considering PE1 is the best path). 253 Due to this behavior, VPN routes from DC1 would never to send to DC2 254 because PE2 is not part of the flooding tree and as DC1 and DC2 are 255 disjoint, even if they are using the same ASN, there is no 256 communication possible between them. 258 The same issue may appear if two MPeBGP sites using the same ASN are 259 connected on the same PE like in figure 4. In this situation both 260 NLRI type based pruning and Peering type based pruning solutions are 261 impacted. 263 +-------+ 264 | DC1 | 265 +-------+ 266 \ 267 (mpebgp vpnv4+rtc) 268 \ 269 PE 270 / 271 (mpebgp vpnv4+rtc) 272 / 273 +-------+ 274 | DC2 | 275 +-------+ 276 Figure 4 278 3. Proposal 280 This document proposes to introduce some new behavior in complement 281 of [RFC4684] to manage the disjoint AS case. 283 In order to support our scenario, path pruning MAY be disabled by 284 configuration for a given origin AS (different from the local AS). 285 Implementations MAY also permit path pruning to be disabled for 286 private AS numbers by default, but must make provision for it to be 287 selectively enabled if such a feature is present. 289 This modification in establishing route distribution tree may create 290 unnecessary flooding states in the situations where a real AS is 291 multihomed to a service provider network (as displayed in Figure 3). 293 ASN 65000 ASN 64000 294 +-----------+ +-------------+ 295 | ASBR3 | -- (mpebgp vpnv4+rtc) -- ASBR1 PE1 ---- | CE1 --- DC1 | 296 | | | \ / +-------------+ 297 | | | (mpibgp vpnv4+rtc) 298 |(vpnv4+rtc)| \ / 299 | | | RR 300 | | | / \ 301 | | | (mpibgp vpnv4+rtc) ASN 64000 302 | | | / \ +-------------+ 303 | ASBR4 | -- (mpebgp vpnv4+rtc) -- ASBR2 PE2 ---- | CE2 --- DC2 | 304 +-----------+ +-------------+ 306 Figure 3 308 In the figure above, disabling pruning is required for AS64000 but it 309 may be interesting to keep it enabled for AS65000. Implementations 310 may require support for such granularity as proposed previously. 312 4. Security considerations 314 This document does not introduce any new security issue compared to 315 [RFC4684]. 317 5. Acknowledgements 319 6. IANA Considerations 321 There is no IANA consideration. 323 7. Normative References 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 329 Networks (VPNs)", RFC 4364, February 2006. 331 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 332 R., Patel, K., and J. Guichard, "Constrained Route 333 Distribution for Border Gateway Protocol/MultiProtocol 334 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 335 Private Networks (VPNs)", RFC 4684, November 2006. 337 Authors' Addresses 339 Stephane Litkowski 340 Orange Business Service 342 Email: stephane.litkowski@orange.com 344 Jeff Haas 345 Juniper Networks 347 Email: jhaas@juniper.net 349 Keyur Patel 350 Cisco Systems 352 Email: keyupate@cisco.com