idnits 2.17.00 (12 Aug 2021) /tmp/idnits18439/draft-mapathak-interas-option-d-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 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.) ** The abstract seems to contain references ([RFC4364]), 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 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 (July 10, 2012) is 3595 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'VPN-IPv6' is mentioned on line 147, but not defined == Missing Reference: 'RFC6513' is mentioned on line 148, but not defined == Missing Reference: 'DS-ARCH' is mentioned on line 602, but not defined == Missing Reference: 'DIFF-TUNNEL' is mentioned on line 617, but not defined == Unused Reference: 'RFC2858' is defined on line 654, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2858 (Obsoleted by RFC 4760) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Pathak 3 Internet-Draft Affirmed Networks 4 Intended status: Informational K. Patel 5 Expires: January 11, 2013 A. Sreekantiah 6 Cisco Systems 7 July 10, 2012 9 Inter-AS Option D for BGP/MPLS IP VPN 10 draft-mapathak-interas-option-d-00.txt 12 Abstract 14 This document describes a new option known as an Inter-AS option D to 15 the 'Multi-AS Backbones' section of [RFC4364]. This option combines 16 VPN VRFs at the Autonomous System Border Router (ASBR) as described 17 in 'Option A' with the distribution of labeled VPN-IP routes as 18 described in 'Option B'. In addition, this option allows for a data 19 plane consisting of two methods of traffic forwarding between 20 attached ASBR pairs. 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 January 11, 2013. 39 Copyright Notice 41 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 70 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Inter-AS Option D Reference Model . . . . . . . . . . . . . . 5 72 4. Private Interface Operation without Carrier's Carrier (CSC) . 7 73 5. Private Interface Forwarding with CSC . . . . . . . . . . . . 8 74 6. Shared Interface Forwarding . . . . . . . . . . . . . . . . . 11 75 7. Route Advertisement to External BGP Peers . . . . . . . . . . 12 76 7.1. Route Advertisement - Private interface forwarding . . . . 12 77 7.2. Route Advertisement - Shared interface forwarding . . . . 13 78 7.3. Route Advertisement to Internal BGP Peers . . . . . . . . 14 79 8. Option D Operation Requirements . . . . . . . . . . . . . . . 14 80 8.1. Inter-AS IP VPN Route Distribution . . . . . . . . . . . . 14 81 8.2. Private Interface Forwarding Route Distribution . . . . . 14 82 8.3. Shared interface forwarding Route Distribution . . . . . . 14 83 9. Inter-AS Quality of Service for Option D . . . . . . . . . . . 15 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 88 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 MPLS VPN providers often need to inter-connect different ASes to 94 provide VPN services to customers. This requires the setting up of 95 Inter-AS connections at ASBRs. The inter-AS connections may or may 96 not be between different providers. The mechanisms to set up 97 inter-as connections are described in [RFC4364]. Of particular 98 interest for this draft are the ones documented in section 10 of 99 [RFC4364]. 101 For the option described in section 10, part (a) of [RFC4364], 102 commonly referred to as Option A, peering ASBRs are connected by 103 multiple sub-interfaces, with at least one interface for each VPN 104 that spans the two ASes. Each ASBR acts as a PE, and thinks that the 105 other ASBR is a CE. The ASBRs associate each sub-interface with a 106 VRF and a BGP session is established per sub-interface to signal IP 107 (unlabeled) prefixes. As a result, traffic within the VPN VRFs is 108 IP. The advantage of this option is that the VPNs are isolated from 109 each other and since the traffic is IP, QoS mechanisms that operate 110 on IP traffic can be applied to achieve customer SLAs. The drawback 111 of this option is that there needs to be one BGP session per sub- 112 interface (and at least one sub-interface per VPN), which can be a 113 potential scalability concern if there are a large number of VRFs. 115 For the option described in section 10, part (b) of [RFC4364], 116 commonly referred to as Option B, peering ASBRs are connected by one 117 or more sub-interfaces that are enabled to receive MPLS traffic. An 118 MP-BGP session is used to distribute the labeled VPN prefixes between 119 the ASBRs. Therefore, the traffic that flows between them is 120 labeled. The advantage of this option is that it's more scalable, as 121 there is no need to have one sub-interface and BGP session per VPN. 122 The drawback of this option is that QoS mechanisms that can only be 123 applied to IP traffic cannot be used as the traffic is MPLS. There 124 is also no isolation between the VRFs. 126 The solution described in this draft aims to address the scalability 127 concerns of Option A by using a single BGP session to signal VPN 128 prefixes. In this solution, the forwarding connections between the 129 ASBRs are maintained on a per-VRF basis, while the control plane 130 information is exchanged using a single MP-BGP session. 132 If the solution is used between any attached ASBR pairs belonging to 133 separate Autonomous Systems (AS), then VRF based route filtering 134 policies via RTs is achieved directly between ASBR pairs, independent 135 of PE based RT filtering within an AS. 137 1.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 2. Scope 145 The Inter-AS VPN option described in this draft is applicable to 146 both, the IPv4 VPN services described in [RFC4364] and the IPv6 VPN 147 services defined in [VPN-IPv6]. It is NOT applicable to MVPN IPv4 148 and MVPN IPv6 services defined in [RFC6513]. Support of existing 149 'Multi-AS' options, along with the new techniques are beyond the 150 scope of this document. 152 3. Inter-AS Option D Reference Model 154 Figure 1 shows an arbitrary Multi-AS VPN interconnectivity scenario 155 between Customer Edge routers. CE1 and CE3, interconnected by 156 Service Providers SP1 and SP2, belong to the same VPN, say Red. CE2 157 and CE4 belong to a different VPN, say Green. This example shows 3 158 interfaces ('red', 'white' and 'green') between ASBR1 (belonging to 159 SP1) and ASBR2 (belonging to SP2). 161 Interface 'red' is a VRF attachment circuit associated to VRF1 (on 162 ASBR1 and ASBR2) for VPN Red and is used to trasport labeled or 163 native IP VPN traffic between VRF pairs. Similarly, interface 164 'green' is a VRF attachment circuit associated to VRF2 (on ASBR1 and 165 ASBR2) for VPN Green and is used to transport labeled or native IP 166 VPN traffic between VRF pairs. Interface 'white' is not associated 167 with any VRF instances i.e. this interface is 'global' in nature (in 168 the context of the connected ASes) and carries as a minimum all ASBR 169 exported VPN-IP routing updates. 171 We shall use the term "private interface forwarding" to describe the 172 model where packets for the "Red" VPN are forwarded on the "red" 173 interface, while packets belonging to "Green" VPN are forwarded on 174 the "green" interface. There are no BGP sessions running on the 175 "red" and "green" interfaces; rather the 'white' interface carries 176 all ASBR VPN-IP routing updates exported from VRF pairs. We shall 177 use the term "shared interface forwarding" to describe the model 178 where the "white" interface will be used to forward all the traffic 179 between the ASBRs. For shared interface forwarding outside of a VRF 180 context, interfaces 'red' and 'green' are not required. In addition 181 to carrying all ASBR VPN-IP routing updates, interface 'white' 182 transports labeled IP VPN traffic or native IP traffic. IP VPN 183 packets entering or leaving the ASBR via this interface may be 184 forwarded using normal MPLS mechanisms (e.g. through use of the LFIB) 185 or through a lookup within a VRF that has been identified via MPLS 186 label values. 188 CE1----\ /--------RR1--------\ 189 \ / \ 190 PE1---SP1 MPLS Cloud---ASBR1 191 / / | \ 192 CE2-----/ red / | \ green 193 / white \ 194 \ | / 195 CE3-----\ \ | / 196 \ \ | / 197 PE2--SP2 MPLS Cloud---ASBR2 198 / \ / 199 CE4----/ \--------RR2--------/ 201 Figure 1 203 In the diagram above: 205 1. CE1 and CE3 belong to VPN Red. 207 2. CE2 and CE4 belong to VPN Green. 209 3. PE1 uses RDs RD-red1 and RD-green1 for VPN Red (VRF Red) and VPN 210 Green (VRF Green) respectively. 212 4. PE2 uses RDs RD-red2 and RD-green2 for VPN Red (VRF Red) and VPN 213 Green (VRF Green) respectively. 215 5. ASBR1 has VRFs Red and Green provisioned with RD-red3 and RD- 216 green3 respectively. 218 6. ASBR2 has VRFs Red and Green provisioned with RD-red4 and RD- 219 green4 respectively. 221 7. There are 3 interfaces between ASBR1 and ASBR2. 223 8. On each ASBR, one interface is associated with VRF Red and one 224 with VRF Green. These are the interfaces marked "red" and "green" 225 respectively. 227 9. There is a third interface over which there is an MP-BGP session 228 between the ASBRs. This is the interface marked "white". 230 10. VPN route importing is achieved by configuring the appropriate 231 RTs. 233 11. The PE and ASBR routers in each AS peer with a route-reflector 234 in that AS. 236 The following sections describe in detail the different modes of 237 operation for Option D. 239 4. Private Interface Operation without Carrier's Carrier (CSC) 241 This section describes how route distribution and packet forwarding 242 takes place when using the private interface forwarding option 243 without the use of CSC, ie. the traffic sent between the private 244 interfaces is unencapsulated. 246 Route Distribution: 248 [The following description is for VPN Red, but Route Distribution for 249 VPN Green is exactly analogous to this] 251 1. CE1 advertises a prefix N to PE1. 253 2. PE1 advertises a VPN prefix RD-red1:N to RR1, which in turn 254 advertises it to ASBR1 via iBGP. 256 3. ASBR1 imports the prefix into VPN Red and creates a prefix RD- 257 red3:N. 259 4. ASBR1 advertises the imported prefix RD-red3:N to ASBR2. It sets 260 itself as the next-hop for this prefix and also allocates a local 261 label that is signaled with the prefix. 263 5. By default, ASBR1 does not advertise the source prefix RD-red1:N 264 to ASBR2. This advertisement is suppressed as the prefix is being 265 imported into an Option D VRF. 267 6. ASBR2 receives the prefix RD-red3:N and imports it into VPN Red 268 as RD-red4:N. 270 7. While installing the prefix into the VRF Red RIB table, ASBR2 271 sets the nexthop of RD-red4:N to ASBR1s interface address in VRF Red. 272 The routing context for this entry is also set to that of VRF Red. 274 8. While installing the MPLS forwarding entry for RD-red4:N, by 275 default, the label that was advertised by ASBR1 for the prefix is not 276 installed in the Forwarding Information Base. This enables the 277 traffic between the ASBRs to be IP. 279 9. ASBR2 advertises the imported prefix RD-Red4:N to RR2, which in 280 turn advertises it to PE2. It sets itself as the next-hop for this 281 prefix and also allocates a local label that is signaled as part of 282 the VPN-IP NLRI. 284 10. By default, ASBR2 does not advertise the source prefix RD5:N to 285 PE2. This advertisement is suppressed. 287 11. PE2 imports the RD-red4:N into VRF Red as RD-red2:N. 289 Packet Forwarding 291 The packet forwarding would work just as it would in an Option A 292 scenario: 294 1. CE3 sends a packet destined for N to PE2. 296 2. PE2 encapsulates the packet with the VPN label allocated by ASBR2 297 and the IGP label (if any) needed to tunnel the packet to ASBR2. 299 3. The packet arrives on ASBR2 with the VPN Label, ASBR2 pops the 300 VPN Label and sends the packet as IP to ASBR1 on the "red" interface. 302 4. The IP packet arrives at ASBR1 on the "red" interface. ASBR1 303 then encapsulates the packet with the VPN Label allocated by PE1 and 304 the IGP label needed to tunnel the packet to PE1. 306 5. The packet arrives on PE1 with the VPN label; PE1 disposes the 307 VPN label and forwards the IP packet to CE1. 309 5. Private Interface Forwarding with CSC 311 Let's assume that VPN Red is used to provide VPN service to its 312 customer carrier who in turn provides a VPN service to a customer. 313 This implies that VPN RED is used to provide an LSP between the PE 314 (PE3 and PE4) loopbacks of the baby carrier in the following 315 topology: 317 /--------RR1--------\ 318 / \ 319 PE3---(CSC-)CE1---(CSC-)PE1---SP1 MPLS Cloud---ASBR1 320 | | 321 | | 322 white| |red 323 | | 324 | | 325 PE4---(CSC-)CE2---(CSC-)PE2---SP2 MPLS Cloud---ASBR2 326 \ / 327 \--------RR2----------/ 329 Figure 2 331 Thus, let's assume that in the diagram above: 333 1. CSC-PE1 uses RD RD-red1 for VPN Red (VRF Red). 335 2. CSC-PE2 uses RD RD-red2 for VPN Red (VRF Red). 337 3. ASBR1 has VRF Red provisioned with RD-red3. 339 4. ASBR2 has VRF Red provisioned with RD-red4. 341 5. There are 2 interfaces between ASBR1 and ASBR2. 343 6. On each ASBR, one interface is associated with VRF Red. This is 344 the interface marked "red" in the Figure 2. 346 7. There is a second interface over which there is an MP-BGP session 347 between the ASBRs. This interface is in the global context and is 348 marked "white" in the figure. 350 Route Distribution: 352 1. CSC-CE1 advertises PE3s loopback N to PE1. 354 2. CSC-PE1 advertises a VPN prefix RD-red1:N to RR1, which 355 advertises it to ASBR1 via MP-iBGP. 357 3. ASBR1 imports the prefix into VPN Red and creates a prefix RD- 358 red3:N. 360 4. ASBR1 advertises the imported prefix RD-red3:N to ASBR2. It sets 361 itself as the next-hop for this prefix and also allocates a local 362 label that is signaled as part of the VPN-IP NLRI. 364 5. By default, ASBR1 does not advertise the source prefix RD-red1:N 365 to ASBR2. This advertisement is suppressed as the prefix is being 366 imported into an Option D VRF. 368 6. ASBR2 receives the prefix RD-red3:N and imports it into VPN Red 369 as RD-red4:N. 371 7. While installing the prefix into the VRF Red RIB table, ASBR2 372 sets the nexthop of RD-red4:N to ASBR1s interface address in VRF Red. 373 The nexthop routing context is also set to that of VRF Red. 375 8. While installing the MPLS forwarding entry for RD-red4:N, the 376 outgoing label is installed in forwarding. This enables the traffic 377 between the ASBRs to be MPLS. 379 9. ASBR2 advertises the imported prefix RD-red4:N to RR2, which 380 advertises it to CSC-PE2. It sets itself as the next-hop for this 381 prefix and also allocates a local label that is signaled as part of 382 the VPN-IP NLRI. 384 10. By default, ASBR2 does not advertise the source prefix RD-red4:N 385 to PE2. This advertisement is suppressed. 387 11. PE2 imports the RD-red4:N into VRF Red as RD-red2:N. 389 Packet Forwarding: 391 1. PE4 sends a MPLS packet destined for N to CSC-CE2. 393 2. CSC-CE2 swaps the MPLS label and sends a packet destined for N to 394 CSC-PE2. 396 3. CSC-PE2 encapsulates the packet with the VPN label allocated by 397 ASBR2 and the IGP label needed (if any) to tunnel the packet to 398 ASBR2. 400 4. The packet arrives on ASBR2 with the VPN Label, ASBR2 swaps the 401 received VPN label with the outgoing label received from ASBR1 and 402 sends the MPLS packet on to the VRF Red interface. 404 5. The MPLS packet arrives at ASBR1 on the VRF red interface, ASBR1 405 then swaps the received MPLS label with a label stack consisting of 406 the VPN Label allocated by PE1 and the IGP label needed to tunnel the 407 packet to CSC-PE1. 409 6. The packet arrives on CSC-PE1 with the VPN label; PE1 disposes 410 the VPN label and forwards the MPLS packet to CSC-CE1. 412 7. CSC-CE1 in turn swaps the label and forwards the labeled packet 413 to PE3. 415 6. Shared Interface Forwarding 417 This section describes how route distribution and packet forwarding 418 takes place when using the shared interface forwarding option. The 419 topology is the same as in Figure 1. 421 Route Distribution (VPN Red): 423 1. CE1 advertises a prefix N to PE1. 425 2. PE1 advertises a VPN prefix RD-red1:N to RR1, which advertises it 426 to ASBR1 via iBGP. 428 3. ASBR1 imports the prefix into VPN Red and creates a prefix RD- 429 red3:N 431 4. ASBR1 advertises the imported prefix RD-red3:N to ASBR2. It sets 432 itself as the next-hop for this prefix and also allocates a local 433 label that is signaled with the prefix. 435 5. By default, ASBR1 does not advertise the source prefix RD-red1:N 436 to ASBR2. This advertisement is suppressed as the prefix is being 437 imported into an Option D VRF. 439 6. ASBR2 receives the prefix RD-red3:N and imports it into VPN Red 440 as RD-red4:N 442 7. While installing the prefix into the VRF Red RIB table, ASBR2 443 retains the nexthop of RD-red4:N as received in the BGP update from 444 ASBR1. This is the address of ASBR1's s shared interface address in 445 the global table. The nexthop routing context is also left unchanged 446 and corresponds to that of the global table. 448 8. While installing the MPLS forwarding entry for RD-red4:N, the 449 outgoing label is installed in forwarding. This enables the traffic 450 between the ASBRs to be MPLS. 452 9. ASBR2 advertises the imported prefix RD-red4:N to RR2, which 453 advertises it to PE2. It sets itself as the next-hop for this prefix 454 and also allocates a local label that is signaled as part of the 455 VPN-IP NLRI. 457 10. By default, ASBR2 does not advertise the source prefix RD-red4:N 458 to PE2. This advertisement is suppressed. 460 11. PE2 imports the RD-red4:N into VRF Red as RD-red2:N. 462 Packet Forwarding: 464 The packet forwarding would work just as it would in an Option B 465 scenario: 467 1. CE3 sends a packet destined for N to PE2. 469 2. PE2 encapsulates the packet with the VPN label allocated by ASBR2 470 and the IGP label needed to tunnel the packet to ASBR2. 472 3. The packet arrives on ASBR2 with the VPN Label. ASBR2 swaps the 473 received VPN label with the outgoing label received from ASBR1 and 474 sends the MPLS packet on to the global shared link interface. 476 4. The MPLS packet arrives at ASBR1 on the global shared link 477 interface. ASBR1 then swaps the received MPLS label with a label 478 stack consisting of the VPN Label allocated by PE1 and the IGP label 479 needed to tunnel the packet to PE1. 481 5. The packet arrives on PE1 with the VPN label; PE1 disposes the 482 VPN label and forwards the IP packet to CE1. 484 7. Route Advertisement to External BGP Peers 486 ASBR1 (refer Figure 1) does route advertisement and VPN route 487 processing using the standard BGP-VPN rules. It processes the VRF 488 Red RT extended community attributes and learns the label bindings 489 associated with routes for VPN Red. VPN-IP routes are imported into 490 VRF Red's Routing Information Base (RIB) where their RT and RD 491 attributes, assigned by PE1 are removed. 493 ASBR1 VPN-IP routes are not advertised to RR1 as the original routes 494 applicable to VPN Red sourced by PE1 were received from an internal 495 BGP peer. Any installed routes that are not imported into VRF1 RIB 496 MAY be advertised to external BGP peers using the existing [RFC4364] 497 Multi-AS "Option B" techniques. Dependant on which packet forwarding 498 method is used, routes are then exported from VRFs and advertised 499 from ASBR1 to ASBR2 as described in the following sections. 501 7.1. Route Advertisement - Private interface forwarding 503 VPN-IP prefixes are advertised from ASBR1 to ASBR2 via a BGP session 504 that is in the global routing table context. This implies that the 505 advertised next-hop address is also reachable via the global routing 506 table context. In order to force traffic to be forwarded via an 507 interface 'red' that is in a VRF routing table context, VRF 508 forwarding entries need to be installed using a next-hop address that 509 is in VRF Red's (which resides on ASBR2) routing context. The 510 address of the next-hop could be the same as the global table address 511 of the remote ASBR (in this case ASBR1), although this would require 512 that the same IP address be used across all VRF attachment circuits 513 linking ASBR pairs. 515 Alternatively, if a Service Provider needs to number the VRF 516 interfaces differently from the global table VPN session, a 517 configuration method SHOULD be available so as to map the 518 corresponding global table VPNv4 neighbor address to an IP address 519 reachable in the given VRF. 521 ASBR1 exports routes associated to VPN Red from VRF Red's RIB to BGP 522 where RD and RT attributes, plus label bindings are attached to these 523 routes. These labeled VPN-IP routes are advertised across interface 524 'red' to ASBR2 via BGP, with a label value set to implicit-null and 525 the 'S' bit set. The routes next-hop addresses is set either to 526 ASBR1 (usually interface 'red') or an address reachable via interface 527 'red'. ASBR2 imports the VRF Red's exported routes into VRF Red's 528 RIB where the routes RT and RD attributes are removed. The next-hop 529 of the imported routes is either set via a policy or left unchanged 530 to an address in VRF Red's routing context. ASBR2 exports routes 531 from VRF Red's RIB to BGP and attaches RT and RD attributes, as 532 configured at VRF Red plus label bindings. Labeled VPN-IP routes are 533 now advertised to PE2 via RR2 and so on. ASBR2 sets itself as the 534 nexthop for these routes abd allocates a local label. As an 535 optimization to conserve label space, ASBR2 MAY allocate a per-VRF 536 aggregate label as the local label while advertising the routes to 537 iBGP peers. 539 7.2. Route Advertisement - Shared interface forwarding 541 ASBR1 exports routes associated to VPN Red from VRF Red's RIB to BGP 542 where RD and RT attributes, plus label bindings are attached to these 543 routes. These labeled VPN-IP routes are advertised across interface 544 'white' to ASBR2 via BGP, with a next-hop set to ASBR1. ASBR2 545 imports the VRF Red exported routes into (its local) VRF Red RIB 546 where the routes RT and RD attributes are removed. The imported 547 routes next-hop is set to ASBR1, available via interface 'white'. 548 ASBR2 exports routes from VRF Red's RIB to BGP and attaches RT and RD 549 attributes, as configured at VRF Red plus label bindings. Labeled 550 VPN-IP routes are now advertised to PE2 via RR2 and so on. 552 7.3. Route Advertisement to Internal BGP Peers 554 All the received VPN-IP routes from an adjancent ASBR are imported 555 into local VRFs on the receiving ASBR. The receiving ASBR needs to 556 advertise these routes to its local IBGP sessions. The next-hop for 557 these routes SHOULD be set to itself when the local ASBR advertises 558 these routes to its IBGP sessions. 560 8. Option D Operation Requirements 562 8.1. Inter-AS IP VPN Route Distribution 564 Routes received from internal or external peers that are imported 565 into ASBR VRFs SHOULD NOT be readvertised to any BGP neighbors. 566 Routes that are not imported into VRFs but are installed in the 567 ASBR's global routing table MAY be readvertised using existing Option 568 'B' techniques as described in the Multi-AS section of [RFC4364]. 569 The ASBR MUST be equipped with RT based filtering mechanisms that 570 explicitly permit all or a subset of such RT values to be 571 readvertised to its neighbors. 573 VPN-IP routes that are converted by the ASBR MUST NOT be readvertised 574 to the source peer of the route. It SHOULD be possible to remove/ 575 manipulate individual RT values when advertising routes on a per 576 neighbor basis. This is useful where the SP wants to separate RT 577 values advertised to EBGP peers from RT values advertised to IBGP 578 peers. 580 8.2. Private Interface Forwarding Route Distribution 582 For private interface forwarding, labeled VPN-IP routes advertised 583 from ASBR to ASBR MUST have their next-hop set to an address within a 584 VRF RIB. This address will usually be the VRF attachment circuit 585 interface. 587 If the Service Provider needs to number the VRF interfaces 588 differently from the global table VPNv4 neighbor, a configuration 589 method SHOULD be available so as to map the corresponding global 590 table VPNv4 neighbor address to an IP address reachable in the given 591 VRF. This route mapping policy SHOULD be configurable on both 592 outbound and inbound peers. 594 8.3. Shared interface forwarding Route Distribution 596 For shared interface forwarding outside of a VRF context, the next- 597 hop must be a 'global' (non VRF RIB) address on an ASBR. This 598 address will usually be the interface linking ASBR pairs. 600 9. Inter-AS Quality of Service for Option D 602 It SHOULD be possible for the ASBR as a DS boundary node [DS-ARCH] 603 operating traffic classification and conditioning functions to match 604 on ingress and egress a combination of application (TCP, UDP port, 605 RTP session, data pattern etc), IP Source Address, IP Destination 606 Address or DS field per packet, per VRF or per VRF attachment circuit 607 (in the case of private interface forwarding). 609 Once matched, the packets Layer-2 header (if applicable), IP DSCP and 610 MPLS EXP bits or combinations of the above should be capable of being 611 re-marked, and optionally shaped per traffic stream, depending on the 612 DS domain's Traffic Conditioning Agreement (TCA). This will assist 613 where different DS domains have different TCA rules. 615 For Private interface forwarding, the ASBR should be capable of 616 forwarding explicit null labeled MPLS packets across VRF attachment 617 circuits. This SHOULD assist with a pipe mode [DIFF-TUNNEL] 618 operation of traffic conditioning behavior at the ASBR. MPLS based 619 forwarding between attached ASBRs inherently should have these 620 mechanisms built in. 622 10. Security Considerations 624 This document doesnt not alter the underlying security properties of 625 BGP based VPNs. In particular, the the private interface forwarding 626 using a new Multi-AS option defined in this document has same 627 security implications as Multi-AS option 'a'of [RFC4364]. The global 628 interface forwarding using a new Multi-AS option defined in this 629 document is outside the scope of this document. 631 This document doesnt not alter the underlying security properties of 632 BGP based VPNs for the shared interface forwaring using the new 633 Multi-AS option. The security implications for this mechanism are 634 same as Multi-AS option 'b' of [RFC4364]. 636 11. Acknowledgements 638 The authors wish to acknowledge the contributions of the authors of 639 the original Option D draft: Marko Kulmala, Ville Hallivuori, Jyrki 640 Soini, Jim Guichard, Robert Hanzl and Martin Halstead. The authors 641 would like to thank Eric Rosen for his comments. 643 12. References 644 12.1. Normative References 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, March 1997. 649 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 650 Networks (VPNs)", RFC 4364, February 2006. 652 12.2. Informative References 654 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 655 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 657 Authors' Addresses 659 Manu Pathak 660 Affirmed Networks 661 35 Nagog Park 662 Acton, MA 01720 663 USA 665 Email: manu_pathak@affirmednetworks.com 667 Keyur Patel 668 Cisco Systems 669 170 W. Tasman Drive 670 San Jose, CA 95134 671 USA 673 Email: keyupate@cisco.com 675 Arjun Sreekantiah 676 Cisco Systems 677 170 W. Tasman Drive 678 San Jose, CA 95134 679 USA 681 Email: asreekan@cisco.com