idnits 2.17.1 draft-mapathak-interas-ab-02.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 (May 28, 2015) is 3256 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'VPN-IPv6' is mentioned on line 146, but not defined == Missing Reference: 'RFC6513' is mentioned on line 147, but not defined == Missing Reference: 'DS-ARCH' is mentioned on line 598, but not defined == Missing Reference: 'DIFF-TUNNEL' is mentioned on line 613, but not defined == Unused Reference: 'RFC2858' is defined on line 651, 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: November 29, 2015 A. Sreekantiah 6 Cisco Systems 7 May 28, 2015 9 Inter-AS Option D for BGP/MPLS IP VPN 10 draft-mapathak-interas-ab-02.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 November 29, 2015. 39 Copyright Notice 41 Copyright (c) 2015 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 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Inter-AS Option D Reference Model . . . . . . . . . . . . . . 4 72 4. Private Interface Operation without Carrier's Carrier (CSC) . 6 73 5. Private Interface Forwarding with CSC . . . . . . . . . . . . 7 74 6. Shared Interface Forwarding . . . . . . . . . . . . . . . . . 9 75 7. Route Advertisement to External BGP Peers . . . . . . . . . . 11 76 7.1. Route Advertisement - Private interface forwarding . . . 11 77 7.2. Route Advertisement - Shared interface forwarding . . . . 12 78 7.3. Route Advertisement to Internal BGP Peers . . . . . . . . 12 79 8. Option D Operation Requirements . . . . . . . . . . . . . . . 12 80 8.1. Inter-AS IP VPN Route Distribution . . . . . . . . . . . 12 81 8.2. Private Interface Forwarding Route Distribution . . . . . 13 82 8.3. Shared interface forwarding Route Distribution . . . . . 13 83 9. Inter-AS Quality of Service for Option D . . . . . . . . . . 13 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 88 12.2. Informative References . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 inter- 97 as connections are described in [RFC4364]. Of particular interest 98 for this draft are the ones documented in section 10 of [RFC4364]. 100 For the option described in section 10, part (a) of [RFC4364], 101 commonly referred to as Option A, peering ASBRs are connected by 102 multiple sub-interfaces, with at least one interface for each VPN 103 that spans the two ASes. Each ASBR acts as a PE, and thinks that the 104 other ASBR is a CE. The ASBRs associate each sub-interface with a 105 VRF and a BGP session is established per sub-interface to signal IP 106 (unlabeled) prefixes. As a result, traffic within the VPN VRFs is 107 IP. The advantage of this option is that the VPNs are isolated from 108 each other and since the traffic is IP, QoS mechanisms that operate 109 on IP traffic can be applied to achieve customer SLAs. The drawback 110 of this option is that there needs to be one BGP session per sub- 111 interface (and at least one sub-interface per VPN), which can be a 112 potential scalability concern if there are a large number of VRFs. 114 For the option described in section 10, part (b) of [RFC4364], 115 commonly referred to as Option B, peering ASBRs are connected by one 116 or more sub-interfaces that are enabled to receive MPLS traffic. An 117 MP-BGP session is used to distribute the labeled VPN prefixes between 118 the ASBRs. Therefore, the traffic that flows between them is 119 labeled. The advantage of this option is that it's more scalable, as 120 there is no need to have one sub-interface and BGP session per VPN. 121 The drawback of this option is that QoS mechanisms that can only be 122 applied to IP traffic cannot be used as the traffic is MPLS. There 123 is also no isolation between the VRFs. 125 The solution described in this draft aims to address the scalability 126 concerns of Option A by using a single BGP session to signal VPN 127 prefixes. In this solution, the forwarding connections between the 128 ASBRs are maintained on a per-VRF basis, while the control plane 129 information is exchanged using a single MP-BGP session. 131 If the solution is used between any attached ASBR pairs belonging to 132 separate Autonomous Systems (AS), then VRF based route filtering 133 policies via RTs is achieved directly between ASBR pairs, independent 134 of PE based RT filtering within an AS. 136 1.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 2. Scope 144 The Inter-AS VPN option described in this draft is applicable to 145 both, the IPv4 VPN services described in [RFC4364] and the IPv6 VPN 146 services defined in [VPN-IPv6]. It is NOT applicable to MVPN IPv4 147 and MVPN IPv6 services defined in [RFC6513]. Support of existing 148 'Multi-AS' options, along with the new techniques are beyond the 149 scope of this document. 151 3. Inter-AS Option D Reference Model 153 Figure 1 shows an arbitrary Multi-AS VPN interconnectivity scenario 154 between Customer Edge routers. CE1 and CE3, interconnected by 155 Service Providers SP1 and SP2, belong to the same VPN, say Red. CE2 156 and CE4 belong to a different VPN, say Green. This example shows 3 157 interfaces ('red', 'white' and 'green') between ASBR1 (belonging to 158 SP1) and ASBR2 (belonging to SP2). 160 Interface 'red' is a VRF attachment circuit associated to VRF1 (on 161 ASBR1 and ASBR2) for VPN Red and is used to trasport labeled or 162 native IP VPN traffic between VRF pairs. Similarly, interface 163 'green' is a VRF attachment circuit associated to VRF2 (on ASBR1 and 164 ASBR2) for VPN Green and is used to transport labeled or native IP 165 VPN traffic between VRF pairs. Interface 'white' is not associated 166 with any VRF instances i.e. this interface is 'global' in nature (in 167 the context of the connected ASes) and carries as a minimum all ASBR 168 exported VPN-IP routing updates. 170 We shall use the term "private interface forwarding" to describe the 171 model where packets for the "Red" VPN are forwarded on the "red" 172 interface, while packets belonging to "Green" VPN are forwarded on 173 the "green" interface. There are no BGP sessions running on the 174 "red" and "green" interfaces; rather the 'white' interface carries 175 all ASBR VPN-IP routing updates exported from VRF pairs. We shall 176 use the term "shared interface forwarding" to describe the model 177 where the "white" interface will be used to forward all the traffic 178 between the ASBRs. For shared interface forwarding outside of a VRF 179 context, interfaces 'red' and 'green' are not required. In addition 180 to carrying all ASBR VPN-IP routing updates, interface 'white' 181 transports labeled IP VPN traffic or native IP traffic. IP VPN 182 packets entering or leaving the ASBR via this interface may be 183 forwarded using normal MPLS mechanisms (e.g. through use of the LFIB) 184 or through a lookup within a VRF that has been identified via MPLS 185 label values. 187 CE1----\ /--------RR1--------\ 188 \ / \ 189 PE1---SP1 MPLS Cloud---ASBR1 190 / / | \ 191 CE2-----/ red / | \ green 192 / white \ 193 \ | / 194 CE3-----\ \ | / 195 \ \ | / 196 PE2--SP2 MPLS Cloud---ASBR2 197 / \ / 198 CE4----/ \--------RR2--------/ 200 Figure 1 202 In the diagram above: 204 1. CE1 and CE3 belong to VPN Red. 206 2. CE2 and CE4 belong to VPN Green. 208 3. PE1 uses RDs RD-red1 and RD-green1 for VPN Red (VRF Red) and VPN 209 Green (VRF Green) respectively. 211 4. PE2 uses RDs RD-red2 and RD-green2 for VPN Red (VRF Red) and VPN 212 Green (VRF Green) respectively. 214 5. ASBR1 has VRFs Red and Green provisioned with RD-red3 and RD- 215 green3 respectively. 217 6. ASBR2 has VRFs Red and Green provisioned with RD-red4 and RD- 218 green4 respectively. 220 7. There are 3 interfaces between ASBR1 and ASBR2. 222 8. On each ASBR, one interface is associated with VRF Red and one 223 with VRF Green. These are the interfaces marked "red" and "green" 224 respectively. 226 9. There is a third interface over which there is an MP-BGP session 227 between the ASBRs. This is the interface marked "white". 229 10. VPN route importing is achieved by configuring the appropriate 230 RTs. 232 11. The PE and ASBR routers in each AS peer with a route-reflector 233 in that AS. 235 The following sections describe in detail the different modes of 236 operation for Option D. 238 4. Private Interface Operation without Carrier's Carrier (CSC) 240 This section describes how route distribution and packet forwarding 241 takes place when using the private interface forwarding option 242 without the use of CSC, ie. the traffic sent between the private 243 interfaces is unencapsulated. 245 Route Distribution: 247 [The following description is for VPN Red, but Route Distribution for 248 VPN Green is exactly analogous to this] 250 1. CE1 advertises a prefix N to PE1. 252 2. PE1 advertises a VPN prefix RD-red1:N to RR1, which in turn 253 advertises it to ASBR1 via iBGP. 255 3. ASBR1 imports the prefix into VPN Red and creates a prefix RD- 256 red3:N. 258 4. ASBR1 advertises the imported prefix RD-red3:N to ASBR2. It sets 259 itself as the next-hop for this prefix and also allocates a local 260 label that is signaled with the prefix. 262 5. By default, ASBR1 does not advertise the source prefix RD-red1:N 263 to ASBR2. This advertisement is suppressed as the prefix is being 264 imported into an Option D VRF. 266 6. ASBR2 receives the prefix RD-red3:N and imports it into VPN Red 267 as RD-red4:N. 269 7. While installing the prefix into the VRF Red RIB table, ASBR2 270 sets the nexthop of RD-red4:N to ASBR1s interface address in VRF Red. 271 The routing context for this entry is also set to that of VRF Red. 273 8. While installing the MPLS forwarding entry for RD-red4:N, by 274 default, the label that was advertised by ASBR1 for the prefix is not 275 installed in the Forwarding Information Base. This enables the 276 traffic between the ASBRs to be IP. 278 9. ASBR2 advertises the imported prefix RD-Red4:N to RR2, which in 279 turn advertises it to PE2. It sets itself as the next-hop for this 280 prefix and also allocates a local label that is signaled as part of 281 the VPN-IP NLRI. 283 10. By default, ASBR2 does not advertise the source prefix RD5:N to 284 PE2. This advertisement is suppressed. 286 11. PE2 imports the RD-red4:N into VRF Red as RD-red2:N. 288 Packet Forwarding 290 The packet forwarding would work just as it would in an Option A 291 scenario: 293 1. CE3 sends a packet destined for N to PE2. 295 2. PE2 encapsulates the packet with the VPN label allocated by ASBR2 296 and the IGP label (if any) needed to tunnel the packet to ASBR2. 298 3. The packet arrives on ASBR2 with the VPN Label, ASBR2 pops the 299 VPN Label and sends the packet as IP to ASBR1 on the "red" interface. 301 4. The IP packet arrives at ASBR1 on the "red" interface. ASBR1 302 then encapsulates the packet with the VPN Label allocated by PE1 and 303 the IGP label needed to tunnel the packet to PE1. 305 5. The packet arrives on PE1 with the VPN label; PE1 disposes the 306 VPN label and forwards the IP packet to CE1. 308 5. Private Interface Forwarding with CSC 310 Let's assume that VPN Red is used to provide VPN service to its 311 customer carrier who in turn provides a VPN service to a customer. 312 This implies that VPN RED is used to provide an LSP between the PE 313 (PE3 and PE4) loopbacks of the baby carrier in the following 314 topology: 316 /--------RR1--------\ 317 / \ 318 PE3---(CSC-)CE1---(CSC-)PE1---SP1 MPLS Cloud---ASBR1 319 | | 320 | | 321 white| |red 322 | | 323 | | 324 PE4---(CSC-)CE2---(CSC-)PE2---SP2 MPLS Cloud---ASBR2 325 \ / 326 \--------RR2----------/ 328 Figure 2 330 Thus, let's assume that in the diagram above: 332 1. CSC-PE1 uses RD RD-red1 for VPN Red (VRF Red). 334 2. CSC-PE2 uses RD RD-red2 for VPN Red (VRF Red). 336 3. ASBR1 has VRF Red provisioned with RD-red3. 338 4. ASBR2 has VRF Red provisioned with RD-red4. 340 5. There are 2 interfaces between ASBR1 and ASBR2. 342 6. On each ASBR, one interface is associated with VRF Red. This is 343 the interface marked "red" in the Figure 2. 345 7. There is a second interface over which there is an MP-BGP session 346 between the ASBRs. This interface is in the global context and is 347 marked "white" in the figure. 349 Route Distribution: 351 1. CSC-CE1 advertises PE3s loopback N to PE1. 353 2. CSC-PE1 advertises a VPN prefix RD-red1:N to RR1, which 354 advertises it to ASBR1 via MP-iBGP. 356 3. ASBR1 imports the prefix into VPN Red and creates a prefix RD- 357 red3:N. 359 4. ASBR1 advertises the imported prefix RD-red3:N to ASBR2. It sets 360 itself as the next-hop for this prefix and also allocates a local 361 label that is signaled as part of the VPN-IP NLRI. 363 5. By default, ASBR1 does not advertise the source prefix RD-red1:N 364 to ASBR2. This advertisement is suppressed as the prefix is being 365 imported into an Option D VRF. 367 6. ASBR2 receives the prefix RD-red3:N and imports it into VPN Red 368 as RD-red4:N. 370 7. While installing the prefix into the VRF Red RIB table, ASBR2 371 sets the nexthop of RD-red4:N to ASBR1s interface address in VRF Red. 372 The nexthop routing context is also set to that of VRF Red. 374 8. While installing the MPLS forwarding entry for RD-red4:N, the 375 outgoing label is installed in forwarding. This enables the traffic 376 between the ASBRs to be MPLS. 378 9. ASBR2 advertises the imported prefix RD-red4:N to RR2, which 379 advertises it to CSC-PE2. It sets itself as the next-hop for this 380 prefix and also allocates a local label that is signaled as part of 381 the VPN-IP NLRI. 383 10. By default, ASBR2 does not advertise the source prefix RD-red4:N 384 to PE2. This advertisement is suppressed. 386 11. PE2 imports the RD-red4:N into VRF Red as RD-red2:N. 388 Packet Forwarding: 390 1. PE4 sends a MPLS packet destined for N to CSC-CE2. 392 2. CSC-CE2 swaps the MPLS label and sends a packet destined for N to 393 CSC-PE2. 395 3. CSC-PE2 encapsulates the packet with the VPN label allocated by 396 ASBR2 and the IGP label needed (if any) to tunnel the packet to 397 ASBR2. 399 4. The packet arrives on ASBR2 with the VPN Label, ASBR2 swaps the 400 received VPN label with the outgoing label received from ASBR1 and 401 sends the MPLS packet on to the VRF Red interface. 403 5. The MPLS packet arrives at ASBR1 on the VRF red interface, ASBR1 404 then swaps the received MPLS label with a label stack consisting of 405 the VPN Label allocated by PE1 and the IGP label needed to tunnel the 406 packet to CSC-PE1. 408 6. The packet arrives on CSC-PE1 with the VPN label; PE1 disposes 409 the VPN label and forwards the MPLS packet to CSC-CE1. 411 7. CSC-CE1 in turn swaps the label and forwards the labeled packet 412 to PE3. 414 6. Shared Interface Forwarding 416 This section describes how route distribution and packet forwarding 417 takes place when using the shared interface forwarding option. The 418 topology is the same as in Figure 1. 420 Route Distribution (VPN Red): 422 1. CE1 advertises a prefix N to PE1. 424 2. PE1 advertises a VPN prefix RD-red1:N to RR1, which advertises it 425 to ASBR1 via iBGP. 427 3. ASBR1 imports the prefix into VPN Red and creates a prefix RD- 428 red3:N 430 4. ASBR1 advertises the imported prefix RD-red3:N to ASBR2. It sets 431 itself as the next-hop for this prefix and also allocates a local 432 label that is signaled with the prefix. 434 5. By default, ASBR1 does not advertise the source prefix RD-red1:N 435 to ASBR2. This advertisement is suppressed as the prefix is being 436 imported into an Option D VRF. 438 6. ASBR2 receives the prefix RD-red3:N and imports it into VPN Red 439 as RD-red4:N 441 7. While installing the prefix into the VRF Red RIB table, ASBR2 442 retains the nexthop of RD-red4:N as received in the BGP update from 443 ASBR1. This is the address of ASBR1's s shared interface address in 444 the global table. The nexthop routing context is also left unchanged 445 and corresponds to that of the global table. 447 8. While installing the MPLS forwarding entry for RD-red4:N, the 448 outgoing label is installed in forwarding. This enables the traffic 449 between the ASBRs to be MPLS. 451 9. ASBR2 advertises the imported prefix RD-red4:N to RR2, which 452 advertises it to PE2. It sets itself as the next-hop for this prefix 453 and also allocates a local label that is signaled as part of the VPN- 454 IP NLRI. 456 10. By default, ASBR2 does not advertise the source prefix RD-red4:N 457 to PE2. This advertisement is suppressed. 459 11. PE2 imports the RD-red4:N into VRF Red as RD-red2:N. 461 Packet Forwarding: 463 The packet forwarding would work just as it would in an Option B 464 scenario: 466 1. CE3 sends a packet destined for N to PE2. 468 2. PE2 encapsulates the packet with the VPN label allocated by ASBR2 469 and the IGP label needed to tunnel the packet to ASBR2. 471 3. The packet arrives on ASBR2 with the VPN Label. ASBR2 swaps the 472 received VPN label with the outgoing label received from ASBR1 and 473 sends the MPLS packet on to the global shared link interface. 475 4. The MPLS packet arrives at ASBR1 on the global shared link 476 interface. ASBR1 then swaps the received MPLS label with a label 477 stack consisting of the VPN Label allocated by PE1 and the IGP label 478 needed to tunnel the packet to PE1. 480 5. The packet arrives on PE1 with the VPN label; PE1 disposes the 481 VPN label and forwards the IP packet to CE1. 483 7. Route Advertisement to External BGP Peers 485 //Keyur: Which figure.. how does this section differ from Section 8. 486 ASBR1 does route advertisement and VPN route processing using the 487 standard BGP-VPN rules. It processes the VRF Red RT extended 488 community attributes and learns the label bindings associated with 489 routes for VPN Red. VPN-IP routes are imported into VRF Red's Routing 490 Information Base (RIB) where their RT and RD attributes, assigned by 491 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. 535 7.2. Route Advertisement - Shared interface forwarding 537 ASBR1 exports routes associated to VPN Red from VRF Red's RIB to BGP 538 where RD and RT attributes, plus label bindings are attached to these 539 routes. These labeled VPN-IP routes are advertised across interface 540 'white' to ASBR2 via BGP, with a next-hop set to ASBR1. ASBR2 541 imports the VRF Red exported routes into (its local) VRF Red RIB 542 where the routes RT and RD attributes are removed. The imported 543 routes next-hop is set to ASBR1, available via interface 'white'. 544 ASBR2 exports routes from VRF Red's RIB to BGP and attaches RT and RD 545 attributes, as configured at VRF Red plus label bindings. Labeled 546 VPN-IP routes are now advertised to PE2 via RR2 and so on. 548 7.3. Route Advertisement to Internal BGP Peers 550 All the received VPN-IP routes from an adjancent ASBR are imported 551 into local VRFs on the receiving ASBR. The receiving ASBR needs to 552 advertise these routes to its local IBGP sessions. The next-hop for 553 these routes SHOULD be set to itself when the local ASRB advertises 554 these routes to its IBGP sessions. 556 8. Option D Operation Requirements 558 8.1. Inter-AS IP VPN Route Distribution 560 Routes received from internal or external peers that are imported 561 into ASBR VRFs SHOULD NOT be readvertised to any BGP neighbors. 562 Routes that are not imported into VRFs but are installed in the 563 ASBR's global routing table MAY be readvertised using existing Option 564 'B' techniques as described in the Multi-AS section of [RFC4364]. 565 The ASBR MUST be equipped with RT based filtering mechanisms that 566 explicitly permit all or a subset of such RT values to be 567 readvertised to its neighbors. 569 VPN-IP routes that are converted by the ASBR MUST NOT be readvertised 570 to the source peer of the route. It SHOULD be possible to remove/ 571 manipulate individual RT values when advertising routes on a per 572 neighbor basis. This is useful where the SP wants to separate RT 573 values advertised to EBGP peers from RT values advertised to IBGP 574 peers. 576 8.2. Private Interface Forwarding Route Distribution 578 For private interface forwarding, labeled VPN-IP routes advertised 579 from ASBR to ASBR MUST have their next-hop set to an address within a 580 VRF RIB. This address will usually be the VRF attachment circuit 581 interface. 583 If the Service Provider needs to number the VRF interfaces 584 differently from the global table VPNv4 neighbor, a configuration 585 method SHOULD be available so as to map the corresponding global 586 table VPNv4 neighbor address to an IP address reachable in the given 587 VRF. This route mapping policy SHOULD be configurable on both 588 outbound and inbound peers. 590 8.3. Shared interface forwarding Route Distribution 592 For shared interface forwarding outside of a VRF context, the next- 593 hop must be a 'global' (non VRF RIB) address on an ASBR. This 594 address will usually be the interface linking ASBR pairs. 596 9. Inter-AS Quality of Service for Option D 598 It SHOULD be possible for the ASBR as a DS boundary node [DS-ARCH] 599 operating traffic classification and conditioning functions to match 600 on ingress and egress a combination of application (TCP, UDP port, 601 RTP session, data pattern etc), IP Source Address, IP Destination 602 Address or DS field per packet, per VRF or per VRF attachment circuit 603 (in the case of private interface forwarding). 605 Once matched, the packets Layer-2 header (if applicable), IP DSCP and 606 MPLS EXP bits or combinations of the above should be capable of being 607 re-marked, and optionally shaped per traffic stream, depending on the 608 DS domain's Traffic Conditioning Agreement (TCA). This will assist 609 where different DS domains have different TCA rules. 611 For Private interface forwarding, the ASBR should be capable of 612 forwarding explicit null labeled MPLS packets across VRF attachment 613 circuits. This SHOULD assist with a pipe mode [DIFF-TUNNEL] 614 operation of traffic conditioning behavior at the ASBR. MPLS based 615 forwarding between attached ASBRs inherently should have these 616 mechanisms built in. 618 10. Security Considerations 620 This document doesnt not alter the underlying security properties of 621 BGP based VPNs. In particular, the the private interface forwarding 622 using a new Multi-AS option defined in this document has same 623 security implications as Multi-AS option 'a'of [RFC4364]. The global 624 interface forwarding using a new Multi-AS option defined in this 625 document is outside the scope of this document. 627 This document doesnt not alter the underlying security properties of 628 BGP based VPNs for the shared interface forwaring using the new 629 Multi-AS option. The security implications for this mechanism are 630 same as Multi-AS option 'b' of [RFC4364]. 632 11. Acknowledgements 634 The authors wish to acknowledge the contributions of the authors of 635 the original Option D draft: Marko Kulmala, Ville Hallivuori, Jyrki 636 Soini, Jim Guichard, Robert Hanzl and Martin Halstead. The authors 637 would like to thank Eric Rosen for his comments. 639 12. References 641 12.1. Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, March 1997. 646 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 647 Networks (VPNs)", RFC 4364, February 2006. 649 12.2. Informative References 651 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 652 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 654 Authors' Addresses 656 Manu Pathak 657 Affirmed Networks 658 35 Nagog Park 659 Acton, MA 01720 660 USA 662 Email: manu_pathak@affirmednetworks.com 663 Keyur Patel 664 Cisco Systems 665 170 W. Tasman Drive 666 San Jose, CA 95134 667 USA 669 Email: keyupate@cisco.com 671 Arjun Sreekantiah 672 Cisco Systems 673 170 W. Tasman Drive 674 San Jose, CA 95134 675 USA 677 Email: asreekan@cisco.com