idnits 2.17.1 draft-uttaro-idr-oad-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 : ---------------------------------------------------------------------------- ** There are 37 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An implementation MUST allow the operator to specify whether the attributes from the ATTR_SET (within an ATTR_SET_STACK) are to be used for best path computation. Note that attributes MUST not be mixed; i.e., either only the attributes from an ATTR_SET are used, or no attribute from an ATTR_SET are used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The proposed mechanism allows non-transitive attributes to be sent across AS boundary. Sending the non-transitive attributes to non-trusted peers can create routing inconsistencies and other vulnerabilities and MUST not be done. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 10, 2014) is 3757 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Uttaro 2 Internet-Draft AT&T 3 Intended status: Standards Track S. Ray 4 Expires: July 14, 2014 Cisco Systems 5 P. Mohapatra 6 Cumulus Networks 7 January 10, 2014 9 One Administrative Domain 10 draft-uttaro-idr-oad-01 12 Abstract 14 The notional premise that different Autonomous Systems belong to 15 different administrative authorities may not always hold. A single 16 administrative authority may instantiate services on and across 17 multiple ASes. A customer accessing those services can reasonably 18 expect that attributes such as LOCAL_PREF that influence routing be 19 applicable even across different ASes. This document describes a 20 mechanism to do so. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 14, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 70 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2.1. One Administrative Domain . . . . . . . . . . . . . . . . 3 73 3. ATTR_SET_STACK attribute . . . . . . . . . . . . . . . . . . 6 74 4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. Single provider scenario . . . . . . . . . . . . . . . . 8 76 4.2. Dual provider scenario . . . . . . . . . . . . . . . . . 11 77 5. Configuration Management . . . . . . . . . . . . . . . . . . 12 78 6. Operational Considerations . . . . . . . . . . . . . . . . . 13 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 10. Normative References . . . . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 One of the basic assumptions of Internet deployment is that different 88 Autonomous Systems (ASes) belong to different administrative 89 authorities that use independent policies. Therefore, attributes 90 such as LOCAL_PREF are not sent across AS boundary. As networks have 91 evolved, such an assumption may not always hold. A single 92 administrative authority such as a Service Provider (SP) may own 93 equipments in multiple ASes and may instantiate services on and 94 across multiple ASes. As a result, an SP customer's end-points may 95 be connected to multiple ASes even though the customer expects the SP 96 network to behave as a single "domain". For instance, a customer 97 utilizing LOCAL_PREF to influence routing expects that the expressed 98 routing preference be preserved at all of their endpoints whether or 99 not they are connected to same or different ASes. This expectation 100 is reasonable since the ASes, being under the same administrative 101 authority, use consistent policies and LOCAL_PREF set in one AS would 102 be comparable in another AS (when designed to be so). To facilitate 103 such control, this document proposes an approach where non-transitive 104 attributes are tunneled across ASes and are interpreted at traffic 105 ingress points. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 1.2. Terminology 115 One Administrative Domain (OAD): 117 A collection of autonomous systems (ASes) that are managed by a 118 single administrative entity. They do not appear any different to 119 ASes that belong to a separate administration. 121 2. Motivation 123 2.1. One Administrative Domain 125 LP 100 Provider network 126 | +--------------------+ 127 v__|_+------+ +------+ | 128 +---+ / | | AS 1 | | AS 2 | | 129 |CE1|/ | | +--+ | | 130 | |\ | | | | | | 131 +---+ \__|_| | | | | 132 ^ | +--|---+ +--|---+ | 133 | +----|---------|-----+ 134 LP 90 +-+-+ +-+-+ 135 |CE2| |CE3| 136 | | | | 137 +---+ +---+ 139 Figure 1: Typical OAD network 141 Today a large SP network often consists of multiple ASes, for 142 instance, reflecting the SP's internal management structure. The SP 143 provides services across those ASes to its customers. Some of the 144 sites of a given customer may be connected to one AS whereas some of 145 the other sites of the same customer may be connected to another AS. 146 However, for these customers, the SP network is a single entity. In 147 many instances, the customer desires the routing behavior between two 148 of its sites be uniform whether or not these sites are in the same AS 149 or in different ASes. 151 Figure 1 provides a typical example of a VPN customer. A customer 152 site with equipment, CE1, is dual-homed to the provider in AS1. A 153 second site of the customer with CE2 is also connected to AS1. A 154 third site of the same customer with CE3 is connected to AS2. CE1 155 advertises a route. The customer sets different LOCAL_PREF for its 156 two links to the provider network and thereby chooses one of the 157 links as the primary path. CE2 receives the LOCAL_PREFs and 158 correctly uses the preferred link for forwarding. However, CE3 159 doesn't receive the LOCAL_PREFs since LOCAL_PREF is not sent across 160 ASes. So CE3 might start to load balance the traffic to CE1 over 161 both links, or might use the non-preferred link solely. 163 In this scenario, the two ASes are contiguous and under the same 164 administrative domain. So it is desirable that the SP customer be 165 able to use the simple mechanism of setting LOCAL_PREF to influence 166 routing decisions irrespective of the internal design of the provider 167 network. In other words, it is desirable to make the OAD behave 168 essentially as one AS. 170 The SP may be able to solve the issue by mapping LOCAL_PREF to a 171 community in AS1, allowing the community to go across the AS boundary 172 and finally reverse mapping the community to LOCAL_PREF in AS2. 173 However, an approach like that is narrow in scope and is difficult to 174 manage in a large network. 176 Provider 3rd 177 LP 100 network Party Provider network 178 | +----------+ +------+ +----------+ 179 v__|_+------+ | | | | +------+ | 180 +---+ / | | AS 1 | | | AS 3 | | | AS 2 | | 181 |CE1|/ | | +----+ +-----+ | | 182 | |\ | | | | | | | | | | 183 +---+ \__|_| | | | | | | | | 184 ^ | +--|---+ | | | | +--|---+ | 185 | +----|-----+ +------+ +----|-----+ 186 LP 90 +-+-+ +-+-+ 187 |CE2| |CE3| 188 | | | | 189 +---+ +---+ 191 Figure 2: Non-adjacent OAD network 193 Multiple ASes under the same administrative authority may not always 194 be contiguous. Figure 2 shows a scenario where two ASes, AS1 and 195 AS2, that belong to the same provider, are separated by an AS that is 196 owned by a third party. Such a scenario may arise due to merger of 197 two SPs. While the mechanism proposed in this draft would work in 198 the same way, caution must be exercised in exposing internal 199 parameters of the provider network to a 3rd party transit AS. 201 We acknowledge that one can consider fixing the problem described 202 here by merging the ASes into one AS (i.e., by renumbering them to 203 one ASN). However, in many cases that is not a viable option. 204 Instead, the solution described here allows an OAD consisting of 205 multiple ASes to essentially behave as a single AS. 207 3. ATTR_SET_STACK attribute 209 +------------------------------+ 210 | Attr Flags (O|T) Code = TBD | 211 +------------------------------+ 212 | Length | 213 +------------------------------+ - 214 | Attr Flags (O|T) Code = 128 | ^ 215 +------------------------------+ | 216 | Length (for the outer attrs) | | 217 +------------------------------+ ATTR_SET 1 218 | Origin AS (provider network) | | 219 +------------------------------+ | 220 . Path Attributes (variable) . v 221 +------------------------------+ - 222 | Attr Flags (O|T) Code = 128 | ^ 223 +------------------------------+ | 224 | Length (for inner attributes)| | 225 +------------------------------+ ATTR_SET 2 226 | Origin AS (customer network) | | 227 +------------------------------+ | 228 . Path Attributes (variable) . v 229 +------------------------------+ - 230 // // 231 // // 232 +------------------------------+ - 233 | Attr Flags (O|T) Code = 128 | ^ 234 +------------------------------+ | 235 | Length (for inner attributes)| | 236 +------------------------------+ ATTR_SET n 237 | Origin AS (customer network) | | 238 +------------------------------+ | 239 . Path Attributes (variable) . v 240 +------------------------------+ - 242 Figure 3: ATTR_SET_STACK 244 The problem described in Section 2 arises because non-transitive 245 attributes that crucially influence routing decisions are dropped at 246 AS boundaries. The key idea is to carry these non-transitive 247 attributes to the traffic ingress point. BGP already supports 248 attribute tunneling by using the ATTR_SET attribute that 249 transperantly carries multiple attributes that need to be preserved 250 across AS boundaries ([RFC6368]). However, ATTR_SET can carry only 251 one set of attributes. As shown in the examples later on, a solution 252 for the present problem needs to carry two sets of attributes, (i) 253 the attribute set for the edge (PE to CE connection, to address the 254 problem described in [RFC6368]), and (ii) the attribute set for the 255 core (PE to RR connection). Moreover, a mechanism is needed to 256 differentiate the set of attributes for the core from the set of 257 attributes for the edge. Such distinction is needed even if, say, 258 only the attributes for the core is present. 260 Towards this end, this document generalizes the attribute tunneling 261 mechanism by introducing a new attribute called ATTR_SET_STACK that 262 carries multiple ATTR_SETs by stacking them. This approach allows 263 adding multiple ATTR_SETs as well as preserves the sequence in which 264 they must be used. The attribute is defined as shown in Figure 3. 266 The 'Length' field of ATTR_SET_STACK includes the cumulative length, 267 in octet, of all the ATTR_SET attributes. 269 In this document we define the rules for stacking two ATTR_SET 270 attributes, which are sufficient for the purpose of OAD. We keep the 271 rules open to future additions to support applications that may 272 require more than two ATTR_SET attributes. 274 Rules: 276 o When an AS border router (ASBR) advertises a route that doesn't 277 have an ATTR_SET_STACK attribute to another AS, if allowed by the 278 policy, the ASBR 280 * Creates an ATTR_SET_STACK attribute, 282 * "Pushes" any existing ATTR_SET attribute in the ATTR_SET_STACK 283 attribute. 285 * Encodes the current attributes in an ATTR_SET and "pushes" this 286 ATTR_SET in the ATTR_SET_STACK attribute. 288 Thus, when there are edge attributes to tunnel, the ASBR creates 289 an ATTR_SET_STACK attribute with two ATTR_SET attributes in it 290 with the ATTR_SET for the edge attributes at the bottom. When 291 only core attributes are to be tunneled, it creates an 292 ATTR_SET_STACK attribute with one ATTR_SET attribute in it 293 carrying the core (set by PE) attributes. 295 o An ingress PE that imports the route "pops" the top ATTR_SET 296 attributes from the ATTR_SET_STACK. If permitted by the local 297 policy, it uses the attributes from it in its best path selection 298 process. 300 o When an ingress PE advertises an imported route to a CE, only the 301 bottom ATTR_SET element is advertised to it (without any 302 ATTR_SET_STACK attribute wrapper). 304 o If a router receives a route with an ATTR_SET_STACK attribute, and 305 it propagates that route to one of its peers, then if the peer is 306 trusted, the peer receives the route with the same ATTR_SET_STACK 307 attribute; otherwise the ATTR_SET_STACK is removed from the route. 309 Note that the creation of ATTR_SET_STACK is controlled by local 310 policy (discussed later) and SHOULD be done only for trusted peer 311 ASes. 313 4. Example Scenarios 315 In this section, we provide some examples of customer accessing VPN 316 service from a provider to illustrate the difference between the 317 existing behavior and the OAD behavior. 319 4.1. Single provider scenario 321 This is a simpler case of a customer connected to only one provider 322 network and there is no edge attribute set. 324 Provider OAD 325 ------------ 326 AS1 AS2 328 (RD1)A/B, Lbl1 329 +------ PE1 330 / \ 331 / LP=200\ 332 / \ 333 CE1 RR1 ................ RR2 --- PE3 ------ CE2 334 \ / \ / +--------------------------+ 335 \ LP=150/ \ / | (RD3)A/B | 336 \ / ASBR1 ... ASBR2 | -> Lbl1, NH=PE1, LP=100 | 337 +------ PE2 | -> Lbl2, NH=PE2, LP=100 | 338 (RD2)A/B, Lbl2 +--------------------------+ 340 Figure 4: Option C Network (existing behavior) 341 Provider OAD 342 ------------ 343 AS1 AS2 345 (RD1)A/B, Lbl1 346 +------ PE1 347 / \ 348 / LP=200\ 349 / \ 350 CE1 RR1 ................ RR2 --- PE3 ------ CE2 351 \ / \ / +--------------------------+ 352 \ LP=150/ \ / | (RD3)A/B | 353 \ / ASBR1 ... ASBR2 | -> Lbl1, NH=PE1, LP=100 | 354 +------ PE2 | ATTR_SET: LP=200 | 355 (RD2)A/B, Lbl2 | -> Lbl2, NH=PE2, LP=100 | 356 | ATTR_SET: LP=150 | 357 +--------------------------+ 359 Figure 5: Option C Network (OAD behavior) 361 As shown in Figure 4, the provider network consisting of two ASes 362 connected by option C technique ([RFC4364]). The customer site with 363 CE1 is dual-homed and advertises prefix A/B to PE1 and PE2. Customer 364 prefers the PE1-CE1 link. This preference is expressed by setting 365 LOCAL_PREF to 200 on the route advertised by PE1 whereas PE2 sets 366 LOCAL_PREF to 150. The second customer site with CE2 is connected to 367 PE3 in AS2. Each PE uses a unique RD. So PE3 receives two prefixes: 368 (RD1)A/B and (RD2)A/B, and imports them into (RD3)A/B. Therefore, 369 the prefix (RD3)A/B has two paths. The first path is with nexthop 370 PE1 (in option C, the nexthops remain unchanged), and the second path 371 is with nexthop PE2. 373 Existing behavior: 374 When RR1 sends the routes to RR2, since they are in different 375 ASes, RR1 does not send LOCAL_PREFs to RR2. So when RR2 sends 376 the routes to PE3, it sends default LOCAL_PREF (shown as 100). 377 I.e., PE3 loses the route preferences that were set in AS1. 379 OAD behavior: 380 When OAD behavior is turned on on RR1 (and RR2 is added as a 381 trusted peer), when RR1 sends the routes to RR2, it creates an 382 ATTR_SET_STACK attribute with one ATTR_SET in it that contains 383 the LOCAL_PREF of the route. When PE3 imports the routes into 384 (RD3)A/B, it extracts the LOCAL_PREFs from the ATTR_SET_STACK 385 (which contains only one ATTR_SET attribute). Therefore, PE3 386 has both the LOCAL_PREF set by PE1 and PE2 (coming from the 387 ATTR_SET_STACK) and the (default) LOCAL_PREF set by RR2. As 388 per the policy set on PE2, the LOCAL_PREFs coming from AS1 can 389 be used by PE2 for computing best path and hence honor the 390 routing preferences set by the customer. This behavior is 391 depicted in Figure 5. 393 Provider OAD 394 ------------ 395 AS1 AS2 397 A/B (RD1, Lbl1) 398 +------ PE1 399 / \ 400 / LP=200\ 401 / \ 402 CE1 RR1 RR2 --- PE3 ------ CE2 403 \ / \ / +-----------------------------+ 404 \ LP=150/ \ / | A/B | 405 \ / ASBR1 ... ASBR2 | -> Lbl1', NH=ASBR2, LP=100 | 406 +------ PE2 | -> Lbl2', NH=ASBR2, LP=100 | 407 A/B (RD2, Lbl2) +-----------------------------+ 409 Figure 6: Option B Network (existing behavior) 411 Provider OAD 412 ------------ 413 AS1 AS2 415 A/B (RD1, Lbl1) 416 +------ PE1 417 / \ 418 / LP=200\ 419 / \ 420 CE1 RR1 RR2 --- PE3 ------ CE2 421 \ / \ / +-----------------------------+ 422 \ LP=150/ \ / | A/B | 423 \ / ASBR1 ... ASBR2 | -> Lbl1', NH=ASBR2, LP=100 | 424 +------ PE2 | ATTR_SET: LP=200 | 425 A/B (RD2, Lbl2) | -> Lbl2', NH=ASBR2, LP=100 | 426 | ATTR_SET: LP=150 | 427 +-----------------------------+ 429 Figure 7: Option B Network (OAD behavior) 431 Figure 6 shows the same provider network when its two ASes are 432 connected by option B ([RFC4364]). Similar to the option C case, on 433 PE3, the prefix (RD3)A/B has two paths, but both with nexthop ASBR2. 435 The VPN label of each route is changed by ASBR2, which allows the 436 packet to ultimately reach PE1 or PE2. 438 Existing behavior: 439 Similar to option C, ASBR1 does not send LOCAL_PREFs to ASBR2. 440 So PE3 loses the route preferences that were set in AS1. 442 OAD behavior: 443 When OAD behavior is turned on on ASBR1 (and ASBR2 is added as 444 a trusted peer), when ASBR1 sends the routes to ASBR2, it 445 creates an ATTR_SET_STACK attribute with one ATTR_SET in it 446 that contains the LOCAL_PREF of the route. This way PE3 447 receives both the LOCAL_PREF set by PE1 and PE2 (coming from 448 the ATTR_SET_STACK) and the (default) LOCAL_PREF set by ASBR2. 449 Therefore PE2 can honor the routing preferences set by the 450 customer. 452 4.2. Dual provider scenario 454 Provider 1 455 ---------- 456 AS1 AS2 458 PE1(Lbl1) 459 / \ 460 +------+ / \LP=200 461 |A/B | / \ +--------------------------+ 462 |LP=100| / RR1 ...... RR2 --- PE3 |A/B | 463 +------+ / / | | -> Lbl1', LP=100 | 464 | /LP=150 | | core ATTR_SET: LP=200 | 465 | / | | edge ATTR_SET: LP=100 | 466 | PE2(Lbl2) | | -> Lbl2', LP=100 | 467 ------|---/---------------------------- | core ATTR_SET: LP=150 | 468 | / | | edge ATTR_SET: LP=100 | 469 CE1 CE2 +--------------------------+ 470 \ / +------------------------+ 471 +-----+ \ / |A/B NH=Provider1(LP=100)| 472 |A/B | /----------------------\ | NH=Provider2(LP=90) | 473 |LP=90| | Provider 2 | +------------------------+ 474 +-----+ \----------------------/ 476 Figure 8: OAD Network in Dual Provider Setup 478 This example considers the scenario when there is both an edge 479 ATTR_SET and a core ATTR_SET. The scenario is shown in Figure 8 480 where a customer utilizes enterprise VPN service from both Provider 1 481 and Provider 2. Provider 1 runs an OAD consisting of two ASes, AS1 482 and AS2, connected by interAS Option B or Option C techniques. To 483 Provider 1, the customer connects one site at AS1 via CE1 and another 484 site at AS2 via CE2. At AS1, CE1 is dual-homed connecting to PE1 and 485 PE2 as IBGP ([RFC6368]) and prefers PE1. 487 CE1 originates a route, A/B, that it advertises to CE2 via both 488 Provider 1 and Provider 2. CE1 prefers Provider 1 by setting the 489 LOCAL_PREF attribute to 100 towards Provider 1 and to 90 towards 490 Provider 2. Within Provider 1, since PE1 is preferred by the 491 customer, PE1 advertises A/B to RR1 with LOCAL_PREF 200 (and label 492 Lbl1) and PE2 advertises A/B with LOCAL_PREF 150 (and label Lbl2). 493 RR1 preserves both routes since PE1 and PE2 uses different route- 494 distinguishers for the customer VPN route. 496 In Provider 1's OAD, PE3 receives two routes for A/B: the first one 497 with label Lbl1' and a next-hop that takes the packet to PE1, and the 498 second one with label Lbl2' and a next-hop that takes the packet to 499 PE2. 501 CE2 receives one route each from Provider 1 (at AS2) and Provider 2. 502 By using the mechanism described in [RFC6368], CE2 sees the 503 LOCAL_PREF attributes set by CE1 and chooses Provider 1's path and 504 sends traffic to PE3. 506 Existing behavior: 507 PE3 does not have any visibility into the LOCAL_PREFs that PE1 508 or PE2 has set (as LOCAL_PREF is non-transitive attribute) and 509 may choose the path with Lbl2' as its bestpath and send traffic 510 to PE2 violating the intent of the customer to receive traffic 511 via PE1. 513 OAD behavior: 514 When OAD is turned on, PE3 receives the ATTR_SET_STACK 515 attribute containing two ATTR_SETs: (i) the top ATTR_SET 516 containing the core attributes (set by PE1 or PE2), (ii) the 517 bottom ATTR_SET containing the edge attributes that comes from 518 the CE. PE3 extracts the top ATTR_SET for its own best path 519 computation and sends the bottom ATTR_SET to CE2. This way PE3 520 is able to honor the prefences set in AS1. 522 5. Configuration Management 524 An implementation MUST allow the operator to identify the neighbors 525 that belong to the same OAD, and/or are trusted. 527 An implementation MUST allow the operator to specify whether the 528 attributes from the ATTR_SET (within an ATTR_SET_STACK) are to be 529 used for best path computation. Note that attributes MUST not be 530 mixed; i.e., either only the attributes from an ATTR_SET are used, or 531 no attribute from an ATTR_SET are used. 533 6. Operational Considerations 535 When non-transitive attributes such as LOCAL_PREF are tunneled across 536 AS boundary, the values used for these attributes must be consistent 537 across different ASes in an OAD. 539 When the originator sends an ATTR_SET_STACK attribute to a 3rd party 540 peer AS, even if the peer AS is a transit AS with respect to the 541 provider network, the peer AS may extract the ATTR_SETs and use them 542 for its own calculations (e.g., if the customer also has a site 543 connected to the 3rd party AS). If the routing policies of the 3rd 544 party AS is not consistent with the originator AS, routing 545 inconsistencies may occur. Therefore, ATTR_SET_STACK attribute may 546 be sent to a peer AS only if the peer AS is trusted. In this 547 context, a trusted AS is either in the same OAD, or it is 548 contractually bound to treat the ATTR_SET_STACK attribute as an 549 opaque attribute, or its routing policy is consistent with the 550 originator AS. 552 A route carrying an ATTR_SET attribute potentially has two sets of 553 non-transitive attributes for possible use: (i) those in the 554 ATTR_SET, and (ii) those carried by the route. The non-transitive 555 attributes are given a "global" scope when those in the ATTR_SET are 556 used. Sometimes, however, a "local" scope may be preferred in some 557 ASes in a given OAD, in which case the non-transitive attributes 558 carried by the route are used. Local policy must govern which set of 559 attributes should be used. 561 7. Acknowledgments 563 8. IANA Considerations 565 IANA shall assign a value from the "BGP Path Attributes" registry, to 566 be called "ATTR_SET_STACK", with this document as the reference. 568 9. Security Considerations 570 The proposed mechanism allows non-transitive attributes to be sent 571 across AS boundary. Sending the non-transitive attributes to non- 572 trusted peers can create routing inconsistencies and other 573 vulnerabilities and MUST not be done. 575 Procedures and protocol extensions defined in this document do not 576 otherwise affect the BGP security model. 578 10. Normative References 580 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 581 Requirement Levels", BCP 14, RFC 2119, March 1997. 583 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 584 Networks (VPNs)", RFC 4364, February 2006. 586 [RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. 587 Yamagata, "Internal BGP as the Provider/Customer Edge 588 Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", 589 RFC 6368, September 2011. 591 Authors' Addresses 593 James Uttaro 594 AT&T 595 200 S. Laurel Avenue 596 Middletown, NJ 07748 597 USA 599 Email: uttaro@att.com 601 Saikat Ray 602 Cisco Systems 603 170 W. Tasman Drive 604 San Jose, CA 95134 605 USA 607 Email: sairay@cisco.com 609 Pradosh Mohapatra 610 Cumulus Networks 611 140C S. Whisman Rd 612 Mountain View, CA 94041 613 USA 615 Email: pmohapat@cumulusnetworks.com