Network Design

EuropCom is an MPLS-based service provider. It took significant effort to stabilize their IPv4 infrastructure; therefore, they do not want to put it in jeopardy when starting the IPv6 service. Furthermore, operating costs for managing the core are already significant, and EuropCom does not plan to deploy any "service-specific" mechanism in the core that would drive these costs higher. Note that EuropCom considers the introduction of IPv6 as a new service, rather than a replacement for IPv4.

The design team studied and tested several approaches, including the following:

• Pseudowire emulation (RFC 3916) Although this approach would make the IPv6 deployment completely transparent to EuropCom infrastructure, this is a layer 2 technology, which was not selected for deploying any of the existing services currently supported by EuropCom, mainly because of scalability concerns.

• IPv6 over IPv4 tunnels over MPLS This approach was considered seriously because IPv4 over MPLS LSPs were already in place; enabling IPv6 tunnels over the existing LSP infrastructure sounded like a simple and attractive solution. Testing demonstrated some weakness in terms of configuration (the tunnel types have to be manually setup), traffic overhead (on small packets, the extra IPv4 header was significant), and troubleshooting (tunnel in tunnel proved be very tricky to manage). Performance-wise, this solution was also disappointing on some of the smaller routers, because of the chain of lookups at the egress PE (label+IPv4+IPv6) before forwarding the packets.

• 6PE/6VPE The mechanisms tested by EuropCom encompass transport over an IPv4 MPLS core of both Internet traffic (6PE) and VPN traffic (6VPE). The conclusion was that these mechanisms are the perfect fit for EuropCom. They have the advantages of the tunnel approach, without the overhead and performance hit. In addition, troubleshooting IPv6 over MPLS is not different from troubleshooting VPNv4, which EuropCom is familiar with. In fact, the overall similarity between 6PE/6VPE and VPNv4 allows EuropCom to leverage their experience with VPNv4 in deploying and operating the IPv6 services.

The following list of goals was put in place by EuropCom to build a compelling business case for choosing the 6PE approach:

• Minimal operational cost and risk. The core routers and related operations are unchanged. This applies to core hardware, software, configuration, list of enabled protocols, network management, QoS, routing and forwarding table size.

• No impact on existing IPv4 and MPLS services.

• Only PE and CE routers are upgraded.

• EuropCom can deploy 6PE on existing PE routers or introduce dedicated PEs for IPv6 traffic. This provides a flexible solution depending on EuropCom customer requirements in terms of traffic and isolation.

• No impact on IPv6 CE routers, other than peering with EuropCom PEs or CEs.

6PE will provide IPv6 connectivity over EuropCom core and enable global IPv6 IA. 6VPE will provide the equivalent service for VPN customers. In addition to these basic services, others such as DNS, IPv6 traffic monitoring, IPv6 content hosting, and VoIPv6 will also be deployed.

With IPv4, PE routers are already dedicated to either VPN customers or Internet access customers: EuropCom plans to keep the same role separation with IPv6. IPv4 IA customers are the primary target for IPv6 IA, and VPNv4 customers for VPNv6 service. To optimize its business model, EuropCom plans to reuse IPv4 IA PEs and CEs for IPv6, and VPNv4 PEs for VPNv6. However, it does not exclude the cases where it might be practical to deploy dedicated IA IPv6 PEs, especially VPNv6 PEs, based on customer demand.

Access Design

In terms of access to its network resources and services, EuropCom customers can be separated in two categories:

• Directly connected This is the case of other service providers for which EuropCom provides transport or Internet access. Their equipment can be collocated with EuropCom at its various POPs.

• Indirectly connected This is the case of enterprises and residential users connecting to EuropCom over an access provider.

Neither of these groups of customers requires an extensive access layer. Figure 13-5 depicts the elements of the access layer. They are independent of the overall design of the POP, and they can be found in various combinations in all EuropCom POPs.

Figure 13-5. EuropCom Access Layer

The interfaces used at the access layer are summarized in Table 13-3.

Table 13-3. Interface Types Used at the Access Layer

Interface Type	Speed	Use
E1	2.048 Mbps	Access for enterprises, full or groomed dedicated circuits, Frame Relay
OC-3	155 Mbps	Access for Enterprises over ATM
OC-48	2.5 Gbps	Access to other service providers
OC-192	10 Gbps	Access for content providers
Gigabit Ethernet	1 Gbps	Access for metro Ethernet enterprise customers and for service providers collocated at the same POPs
10 Gigabit Ethernet	10 Gbps	Access for content providers

Both PE and CE routers make up EuropCom access layer within a POP. They all perform access functions depending on their role in a service offering, functions listed here:

• CE routers located in the POP interface with residential or small business customers. They have to terminate layer 2 circuits, PPP sessions, or L2TP tunnels depending on the business model of the access provider connecting EuropCom to its IA customers. In this role, the CEs can also handle customer provisioning for both IPv4 and IPv6 services. In the case of IPv6, this function can be performed by various means, as mentioned in Chapter 3: stateless autoconfiguration, stateless DHCP, provisioning through IPCP with the help of a RADIUS server, DHCP-PD. The CEs have access to DNS and RADIUS servers.

• PE routers aggregate multiple CE routers collocated in the POP. They also provide direct access to certain enterprise customers and to service providers. PE routers have limited involvement, if any, in the customer-provisioning functions.

Additional layer 2 devices such as Ethernet switches or ATM switches are also part of the access layer. This section focuses on the access features enabled on these devices.

Intermediate System-to-Intermediate System (IS-IS) is the interior gateway protocol (IGP) used within the access layer, between the PE and the CEs managed by EuropCom. In the case of IPv6, considering the lack of depth in the access layer, no hierarchy is necessary in the IGP design. Static routing is used in interfacing with residential and small business customers. eBGP is used between EuropCom and its service provider or large enterprise customers.

Note

Low-end remote CEs managed by EuropCom might run routing protocols that require less processing power, such as RIP (RIPng) or EIGRP (EIGRPv6).

The EuropCom business model is highly focused on the edge features, and this is reflected in the limited depth and complexity of its access layer. Chapter 14, "Deploying IPv6 in an IP Service Provider Network," presents the case of an access service provider with an extensive rich access layer, which has more features. Its detailed description in terms of design and operation offers the reader examples of other features typical in the access layer of a service provider's network.

POP Design

In EuropCom network, Internet exchange points (IX) are also L1 POPs delivering IPv4 and IPv6 services to Enterprises and other service providers. A typical IX, shown in Figure 13-6, includes the following:

• Connections to other IX

• PEs delivering services to IPv4 and IPv6 enterprise and service provider nodes

• Connections to other POPs

• Resources supporting hosted services

• Management applications (fault management, performance management, accounting management)

Figure 13-6. Level 1/IX POP Design

Figure 13-6 illustrates the layer 2/layer 3 structure of an IX/POP.

EuropCom L1 POPs peer with other EuropCom POPs/IX as well as with other ISPs. At the same time, they also connect some local customers, whether IA customers or VPN customers. One of the characteristics of EuropCom peering with other ISPs with regard to IPv6 is that it is intended to be exclusively over MPLS. This simplifies greatly the interface design between EuropCom and other ISPs sharing the same IX, as detailed in the "Inter-AS Design" section.

EuropCom interacts with other service providers in the following ways:

• EuropCom customers connected to its POP over an infrastructure (layer 1 or layer 2) provided by another regional service provider

• EuropCom customers connected to another regional service provider's POP with an inter-service provider agreement (performed in IX)

• EuropCom customers connected to a EuropCom POP which itself is connected to the EuropCom core over another service provider

• Other service provider using EuropCom core as a transit MPLS network

In terms of implications on IPv6 configurations and operation, the second bullet requires some inter-AS support in the context of IPv6, and the fourth bullet requires some CsC IPv6 support. These cases are detailed in the sections "Inter-AS Design" and "Carrier Supporting Carrier Service Design."

Note that in L3 POPs, some routers can play both the role of core Provider routers (P-routers) and Provider Edge (PE) routers.

Core Design

The 6PE/6VPE approach has the advantage of minimizing the impact on the network core when enabling IPv6 traffic over it. In particular, P-routers do not need any software or hardware upgrade, or any configuration change, as long as a few caveats are understood and accepted, which revolve around ICMP (reviewed in the "ICMP Design Considerations" section).

IGP Design Considerations

EuropCom was already running IS-IS as the core IGP prior to deploying IPv6. IS-IS enables IPv4 connectivity within the network core and between PE routers. Because IPv6 routes for both Internet access and VPN will be announced "via" IPv4 PE loopback addresses already distributed by IS-IS, no changes are required on IS-IS running in the core, and minimum impact is expected on the routing tables in core routers.

For IA, EuropCom uses the next-hop-self configuration nit on the PE-PE iBGP peering, and advertises PE's own loopback addresses into IS-IS. So, on both IA PE routers and VPN PE routers, the LSP tail end belongs to the PEs. And the same LSPs are used for IPv4 and IPv6 traffic.

When IPv6 is deployed, the only additional entries in core routers routing tables are IPv4 addresses configured on new PE routers. These are essentially Route Reflectors (RRs) because EuropCom design choice is to deploy dedicated RRs for 6PE/6VPE peering, while enabling IPv6 on existing PEs. With RRs, IPv4 addresses distributed via IS-IS in the core, PEs, and RRs can establish BGP peering over IPv4 and exchange IPv6 routes. Example 13-1 shows the IS-IS configuration (unchanged) in core router Bruxel-P.

Example 13-1. IGP Configuration in the Core

Bruxel-P#show running interface Serial0/0  ip address 172.20.4.2 255.255.255.0  ip router isis  tag-switching ip ! router isis  net 49.0000.0000.0013.00  redistribute connected metric 50  passive-interface Loopback0

MPLS Design Considerations

For label distribution, EuropCom runs LDP over IPv4 to establish LSPs between the PE's IPv4 loopback addresses, on PEs providing Internet access as well as on PEs providing VPN access. P-routers have all their interfaces running LDP and allocating labels for these PE loopback addresses. PE routers have their P-router-facing interfaces also running LDP. Because 6PE and 6VPE are planned to reuse the very same LSPs, LDP is completely transparent to the IPv6 deployment. Note that because both 6PE and 6VPE use the two-label mechanism described in Chapter 3 (in the section "IPv6 over 6PE") and Chapter 7, respectively, Penultimate Hop Popping (PHP) can happen at the last P-router without the need to use explicit-null label to "hide" the IPv6 packet from the penultimate hop router, which is IPv6 unaware. No configuration change is therefore required for LDP on the PE-P interfaces.

Example 13-2 presents the LDP configuration bits, valid for both IPv4 and IPv6 traffic.

Example 13-2. LDP Configuration in the Core

hostname Bruxel ip cef tag-switching tdp router-id Loopback0 interface Serial0/0  ip address 172.20.4.2 255.255.255.0  tag-switching ip

Note

Some service providers might be interested in using distinct LSPs for IPv4 and IPv6 traffic. Dedicated LSP head and tail end can be set up for IPv6 traffic. This is achieved by configuring BGP peering for address families IPv6 and VPNv6 between dedicated IPv4 loopback addresses, distinct from the ones used for IPv4 and VPNv4 peering. Note that, when doing so, the dedicated loopback addresses must be advertised into the core IGP, and be allocated labels by LDP.

Some MPLS service provider want to control closely what addresses are being allocated labels. They use mpls ldp advertise-tag for ldp-pe-filter, where ldp-pe-filter is an access list that permits only LSP certain tail-end addresses. If different addresses are used for IPv6, these access lists may have to be modified accordingly.

EuropCom has been deploying MPLS-based traffic engineering Fast ReRoute (FRR) to provide bandwidth protection upon link failure within the core, with restoration times equivalent to SONET/SDH APS and greater scalability. Because IPv6 traffic uses the very same LSPs that have been set up and protected against failures for IPv4, it will take advantage of the same level of protection at no extra cost.

Note

Some Internet service providers have chosen to separate strictly the IA traffic from the VPN traffic in the core. Sometimes for legacy reasons, only the VPN traffic is MPLS switched, whereas the other traffic is IP forwarded. In such a deployment model, PE routers are dedicated to either providing VPN access service or IA service. The latter routers are not MPLS enabled. Furthermore, MPLS routers, whether core or edge, are configured to allocate labels only for certain addresses, usually the one configured on VPN PE routers.

Deploying IPv6 Internet access in that environment requires either dedicating PEs for IPv6 over MPLS traffic, or migrating existing Internet access PEs to MPLS prior to enabling IPv6 on them. In both cases, the PE interfaces facing the MPLS core network must also be MPLS enabled, which involves some core routers reconfiguration. These core routers may also require configuration changes to allocate labels for the new PE addresses.

Enabling IPv6 in such a network scenario, not covered in this chapter, leads to bigger impact on the service provider network, including some impact on the core.

QOS Design Considerations

QoS design is detailed in the "Quality of Service Design" section. Overall, EuropCom expects its QoS design to be fully transparent to the IPv6 deployment. All classification has been pushed to the CE. The core is overengineered, so that no QoS mechanism is implemented there. EuropCom edges use the precedence to classify traffic sent to CEs: Precedence is expected to be set the same way for IPv6 and IPv4 (by CEs), to reach zero impact on edge as well.

ICMP Design Considerations

Until P-routers are upgraded to a software version that provides minimum IPv6 support, they cannot send ICMPv6 messages, not even encapsulated in an MPLS stack. The issue is explained in Chapter 3, in the section "IPv6 over 6PE."

Although this is acceptable for EuropCom in the initial phases, it is not sustainable on the long run. Note that this minimum support is limited to ICMPv6, and requires no IPv6 configuration.

ICMP is useful in two areas: It allows troubleshooting paths using traceroute, and it is used for discovering optimal MTU throughout the network (PMTU). None of these two operational aspects is critical, as explained in section "Operating and Troubleshooting the Network." The EuropCom network has been designed and configured so that edge routers are responsible for sending back ICMP too-big messages on behalf of the core, and IP traceroute can be advantageously replaced by MPLS traceroute, which works between 6PE LSP endpoints.

EuropCom has chosen to wait for the next scheduled core software upgrade to get a resolution to the challenges just discussed.

Edge Design

EuropCom has decided to reuse existing PE routers when deploying IPv6, except for the RRs, which are a critical part of their IPv4 service design. Instead, it is migrating PE routers dedicated to IPv4 IA to 6PE routers (supporting both IPv4 and IPv6 Internet access) and PE routers dedicated to VPNv4 access to 6VPE routers (supporting both VPNv4 and VPNv6 access).

In the initial IPv6 deployment phase, EuropCom anticipates IPv6 connectivity requests only at a few locations (London, Paris, Berlin, Milan, and Nice). It has therefore decided to make these locations IPv6 ready up front, while migrating the remaining locations based on customer demand for service.

Unlike P-routers, the impact on PE routers that need to provide IPv6 connectivity is significant, both in term of node upgrade (hardware/software) and in terms of configuration. PE routers need to be upgraded with images that support IPv6, 6PE, and, for some of them, 6VPE. Depending on the platforms used on the edge, some edge devices also require hardware upgrades.

Note

At the time of this writing, the 6VPE feature is only available through the Cisco IOS Early Field Test program, and on certain Cisco platforms.

Software upgrade is not a concern: All PEs were upgraded a while ago to a Cisco IOS version that supports IPv6 during a routine maintenance operation. So the current migration envisioned consists essentially of a configuration change. The dedicated RRs represent an addition to EuropCom infrastructure.

For providing a consistent perspective of EuropCom configurations, a few routers (PE and RRs) will be referred to. Figure 13-7 provides a logical view of EuropCom network, with these few routers (at Nice, Milan, Paris, London, Berlin, and Munich) highlighted.

Figure 13-7. EuropCom Network Details

The following naming convention is used in EuropCom network:

• PEs and CEs are prefixed by POP name (Nice-PE-IA, Milan-IGW, and so on).

• PEs are suffixed by their functional role:

  - IA for PEs providing IA: Nice-PE-IA

  - VPN for PEs providing VPN access: London-PE-VPN

  - RR6 for RRs: Milan-RR6

  - IGW for Internet gateways: Milan-IGW

• Customer CEs are suffixed by the company name they belong to (Nice-CE-Cisco).

• EuropCom CEs are suffixed with EuropCom: Nice-CE-EuropCom.

• The first name instance of each router category (London-PE-VPN, Milan-RR6) does not carry any numeric suffix. If several routers of the same category are deployed in the same location, a numeric suffix is used to distinguish them (London-PE-VPN_1, Milan-RR6_1, and so on).

Note that some customers (Cisco in London, IBM in Berlin) are dual homed.

PE Router Design and Implementation Considerations

For the PEs migrating to provide IPv6 access (IA for 6PE and VPN access for 6VPE), the core-facing interfaces remain unchanged:

• Core-facing interfaces are IPv4-only.

• IGP toward the core remains IS-IS.

• LDP on core-facing interfaces remains LDP over IPv4.

However, three significant configuration changes have to be made:

• IPv6 must be enabled on the CE-facing interfaces.

• Some IPv6 routing protocol (static, IGP, BGP) must be configured/enabled on the CE-facing interfaces to exchange IPv6 routes with CEs.

• BGP IPv6 (and/or VPNv6) peering must be established with remote PEs to which the PEs intend to forward MPLS-encapsulated IPv6 traffic. Note that in the EuropCom design, the IPv6 iBGP peering is always performed through RRs, as detailed in the "Route Reflector Design" section.

These three basic configuration tasks enable the network to provide basic IPv6 unicast transport and VPN services. They are reviewed in the sections "PE-CE Interface Design," "PE-CE Routing Design," and "PE-PE Routing Design."

EuropCom has chosen to deploy dedicated RRs for 6PE and 6VPE. This is to avoid overloading existing RRs with additional configuration and BGP routes, and keep the potential influence and security concerns distinguished between IPv4 and IPv6. A full configuration setup is required for these routers that are added to the existent infrastructure. RR configuration tasks are detailed in the section "Route Reflector Design."

Additional configuration may be needed for advanced services and features such as the following:

• QoS configuration for IPv6

• Management configuration

• Security (access control) configuration

These topics are detailed in the sections "Quality of Service Design" and "Operating and Troubleshooting the Network."

Before making the network changes mentioned, EuropCom has defined the IPv6 addressing plan for the deployment. This is detailed in the "Addressing" section. It covers both EuropCom's own addressing plan and the prefix-allocation scheme used for EuropCom customers.

PE-CE Interface Design

6PE routers are routers that migrated from IPv4 only to dual stack (IPv4 and IPv6). EuropCom does not initially plan to dedicate PEs for IPv6 traffic, but rather to enable IPv6 on interfaces previously connecting IPv4-only customers.

EuropCom plans to IPv6 enable these interfaces at the pace of its customers' migration.

Customers migrating to IPv6 are assigned an IPv6 prefix (from /48 up to /64 depending on their size; see the "Addressing" section for details) from the EuropCom owned 2001:6FC::/32 prefix space.

For PE-CE interfaces, link-local addresses are used for IPv6 eBGP peering (see Chapter 2, "An IPv6 Refresher," for the benefits of using link-local). These link-local addresses will not derive from the EUI-64 address of the interface, because extensive BGP reconfiguration would be necessary when the hardware is replaced because of failure or to upgrade. Instead, EuropCom is telling its IPv6 customers to use link-local addresses for CE-PE peering in the form of FE80::ASN:ID, where ASN is the customer autonomous system number, and ID is an arbitrary 16-bit number defined by the autonomous system to identify a particular router. Example 13-3 is illustrates a PE-CE interface configuration on a router providing IA (Nice-PE-IA), where new configuration (IPv6) is highlighted.

Example 13-3. PE-CE Interface Configuration for IA

hostname Nice-PE-IA !PE#26 .. !To Nice-CE-a -(AS:20331, 2001:6FC:2124:1) interface Serial1/0  ip address 172.21.7.1 255.255.255.0  ipv6 address FE80::83D7:26 link-local  !  !To Nice-CE-b (AS:27301,2001:6FC:2124:2)  interface Serial2/0   ip address 172.21.8.1 255.255.255.0   ipv6 address FE80::83D7:26 link-local  !  !To Nice-CE-c (AS:17110, 2001:6FC:2124:3)  interface Serial3/0   ip address 172.21.9.1 255.255.255.0   ipv6 address FE80::83D7:26 link-local

Note that the IPv6 addresses on the CE-facing interface are link-locals, named after the EuropCom ASN (33751/0X83D7). EuropCom is also assigning a global address on the Loopback0 interface, for IPv6 operation purpose, and that should not be used for routing protocol peering.

The corresponding CE routers (Nice-CE-b and Nice-CE-c) use the same addressing scheme (link-local on CE-PE interfaces). Example 13-4 illustrates Nice-CE-b configuration.

Example 13-4. CE-PE Interface Configuration

hostname Nice-CE-b ! Node=61, AS=27301 Prefix=2001:6FC:2124:2::/56 .. interface Loopback0  ip address 100.61.61.1 255.255.255.255  ipv6 address 2001:6FC:2124:2::61/128 ! !to Nice-PE-IA interface Serial0/0  ip address 172.21.8.2 255.255.255.0  ipv6 address FE80::6AA5:61 link-local

A PE used for VPNv6 access, such as Nice-PE-VPN, will have an interface configuration as shown in Example 13-5.

Example 13-5. PE-CE Interface Configuration for VPN Access

hostname Nice-PE-VPN !PE#27 interface Loopback0 ip address 100.27.27.1 255.255.255.255 ipv6 address 2001:6FC::27/128 ! !to Nice-CE-Cisco interface Serial0/0  vrf forwarding Cisco-Nice  ip address 172.21.4.1  255.255.255.0  ipv6 address FE80::83D7:27 link-local  ipv6 address 2001:6FC::27/128 ! !to Nice-CE-IBM interface Serial1/0 vrf forwarding IBM-Nice ip address 172.21.5.1 255.255.255.0 ipv6 address FE80::83D7:27 link-local ipv6 address 2001:6FC::27/128

The configuration for Virtual Routing & Forwarding instances (VRFs) is detailed in the "VRF Design" section.

Although EuropCom does not offer a managed CE service, it does own the CEs that provide access to residential users. The PE-CE interface in that case is configured exactly the same way as customers CEs, with a link-local address.

PE-CE Routing Design

As discussed in Chapter 4, "IPv6 Routing Protocols," and Chapter 7, "VPN IPv6 Architecture and Services," several IPv6 routing protocols are available for exchanging routes between the PE and the CE. EuropCom would prefer to use eBGP as much as possible, although some EuropCom customers like the simplicity of static routing, and still others, using OSPFv3 or EIGRPv6, would prefer not to have to operate another protocol such as BGP. In addition, CEs owned by EuropCom (for residential access) will run IS-IS for IPv6 toward the PE.

Static Routing Design Considerations

Some of the smallest enterprise customers, which are single homed to EuropCom, are using an IPv6 default route to the PE, which in turn has static routes to the customer site. This configuration is limited to those sites with a small number of routes and no need for any dynamic routing protocol. These enterprises are usually getting a /56 (if they have a single subnet) up to a /48 (multiple subnets) prefix, which end up in a single static entry at the 6PE.

Static routing is applicable to both VPN and non-VPN enterprise customers. The following configuration excerpt illustrates the Nice-PE-IA setup, providing static routing toward customers CE-b and CE-c, which have been assigned, respectively, 2001:6FC:1119:1::/56 and 2001:6FC:1119:2::/56.

hostname Nice-PE-IA !PE#26 .. !Static routes to Customer sites: CE-b, CE-c ipv6 route 2001:6FC:2124:2::/56 Serial2/0 ipv6 route 2001:6FC:2124:3::/56 Serial3/0

The corresponding CE routers (Nice-CE-b in the following example) use a default route to point to Nice-PE-IA:

hostname Nice-CE-b ! Node=61, AS=27301 Prefix=2001:6FC:2124:2::/56 .. !Static route to EuropCom ipv6 route ::/0 Serial 0/0

In the case of EuropCom's own CEs interfacing CPEs for providing residential access, static routes are also automatically added when using DHCP Prefix Delegation (DHCP-PD) (a default route ::/0 pointing to the delegating router and a route toward the Null0 interface for each delegated prefix). See details in Chapter 3.

BGP Routing Design

The majority of EuropCom IPv4 VPN customers use eBGP to exchange routes with the PE. The EuropCom network operations team is familiar with BGP, which they like for its flexibility to deal with policies on a per-VPN basis. Given the similarities between 6PE and VPNv4, and the interest in VPNv6 services, EuropCom will be promoting eBGP as the routing protocol of choice on the PE-CE interface.

BGP dampening is configured to limit instability in the control plane caused by route flapping. eBGP peers over link-local addresses, with the addressing scheme defined in the "Addressing" section. Example 13-6 illustrates the BGP configuration for a 6PE router providing IPv6 IA (Nice-PE-IA). New configuration elements for IPv6 are highlighted.

Example 13-6. eBGP Configuration for a PE Router Providing IPv6 IA (Nice-PE-IA)

hostname Nice-PE-IA !PE#26 router bgp 33751  neighbor FE80::4F6B:44%Serial1/0 remote-as 20331  neighbor 172.21.7.1 remote-as 20331  !  address-family ipv4  neighbor 172.21.7.1  activate  bgp dampening 15 750 3000 60  exit-address-family  !  address-family ipv6  neighbor FE80::4F6B:44%Serial1/0 activate  bgp dampening 15 750 3000 60  exit-address-family

As a general VPNv4 BGP policy, and to protect PE routers, EuropCom is limiting the number of prefixes received from a particular CE to 50. Because IPv6 customers can get large chunks of addresses (up to /48; see "Addressing" section), the limit put on each CE connection will be dramatically lower for IPv6 than for IPv4. Example 13-7 illustrates the 6VPE configuration at Nice-PE-VPN, with regard to the PE-CE eBGP peering. The maximum number of prefixes for this customer is five. New configuration elements for IPv6 are highlighted.

Example 13-7. eBGP Configuration for a PE Router Providing VPNv6 Access (Nice-PE-VPN)

hostname Nice-PE-VPN !PE#27 .. router bgp 33751 .. address-family ipv4 vrf Cisco-Nice  neighbor 172.21.4.2 remote-as 21214  neighbor 172.21.4.2 activate  neighbor 172.21.4.2 maximum-prefix 100  bgp dampening 15 750 3000 60  no auto-summary  no synchronization  exit-address-family  !  address-family ipv4 vrf IBM-Nice  neighbor 172.21.5.2 remote-as 22200  neighbor 172.21.5.2 activate  neighbor 172.21.5.2 maximum-prefix 100  bgp dampening 15 750 3000 60  no auto-summary  no synchronization  exit-address-family  ! address-family ipv6 vrf Cisco-Nice  neighbor FE80::52DE:33%Serial0/0 remote-as 21214  neighbor FE80::52DE:33%Serial0/0 activate  neighbor FE80::52DE:33%Serial0/0 maximum-prefix 5  bgp dampening 15 750 3000 60  no synchronization  exit-address-family !  address-family ipv6 vrf IBM-Nice  neighbor FE80::56B8:35%Serial1/0 remote-as 22200  neighbor FE80::56B8:35%Serial1/0 activate  neighbor FE80::56B8:35%Serial1/0 maximum-prefix 5  network 2001:6FC::27/128  bgp dampening 15 750 3000 60  no synchronization  exit-address-family

The node's global address (2001:6FC::27/128) is announced for the sole purpose of troubleshooting (see the "Operating and Troubleshooting the Network" section).

On the customer side, the eBGP configuration for Nice-CE-Cisco is shown in Example 13-8.

Example 13-8. eBGP Configuration for a CE Router

hostname Nice-CE-Cisco !PE#33 .. router bgp 21214  no synchronization  bgp log-neighbor-changes  neighbor 172.21.4.1 remote-as 33751  neighbor FE80::83D7:27%Serial0/0 remote-as 33751  no auto-summary  ! address-family ipv4  neighbor 172.21.4.1 activate  neighbor 172.21.4.1 allowas-in 2  redistribute ospf 100 !  address-family ipv6  neighbor FE80::83D7:27%Serial0/0 activate  neighbor FE80::83D7:27%Serial0/0 allowas-in 2  network 2001:6FC:1123:1::/52 !site-address  aggregate-address 2001:6FC:1123:1::/52 summary-only  no synchronization  exit-address-family

Note that 2001:6FC:1123:1::/52 is the site address for Nice-CE-Cisco.

IGP Routing Design

Some EuropCom IPv4 VPN customers are using an IGP (OSPF, IS-IS, EIGRP) to connect to the PE. The same considerations for choosing the IPv4 IGP apply to IPv6. However, with Cisco IOS setups, no IGP currently supports IPv6 in a VPN context, so this alternative cannot be offered by EuropCom to its VPNv6 customers. Non-VPN enterprise customers would not want to expose their IGP outside the enterprise, so this is not an attractive alternative for them.

Finally, EuropCom-owned CEs need to run an IPv6 IGP with the PE. One possibility would have been for EuropCom to use iBGP between the CE and the PE. Several drawbacks and deployment constraints led EuropCom to abandon this design:

• With the first approach considered, plain iBGP sessions are set up from the CE to other iBGP speakers. This requires a full mesh of iBGP sessions from that CE to other CEs and 6PEs, a solution that scales poorly.

• Alternatively, the CE is configured as the RR client of its 6PE router of attachment. This indirectly leads to MPLS being enabled on the CE-PE interface (BGP reflection implies that the BGP sessions share the same attributes, and MPLS is required on one side), which is not an option for EuropCom. Another issue arises with this design: The CE next hop is propagated by the RRs, and would have to be advertised all over EuropCom network.

• Alternatively, confederations could be used. The BGP autonomous system is divided into multiple autonomous systems. In the EuropCom case, that would be one autonomous system for the core, and one autonomous system for PE-CE pairs. These autonomous systems are running eBGP between them, but they exchange routing as if they were using iBGP; next hop, metric, and local preference information are preserved. To the outside world, the confederation (the group of autonomous systems) looks like a single autonomous system. That solution was too complicated to put in place, and would require a significant redesign of the BGP EuropCom infrastructure.

In the end, EuropCom decided to go for IS-IS between these EuropCom CEs and the PE, as illustrated in Example 13-9.

Example 13-9. Using IS-IS on the PE-CE Interface

hostname Nice-CE-EuropCom !PE#23 .. !to Nice-PE-IA interface interface Serial0/0  ip address 172.21.23.2 255.255.255.0  ipv6 address FE80::52DE:23 link-local  ipv6 router isis EuropCom23 ! router isis EuropCom23   net 49.0001.0000.0000.0023.00

PE-PE Routing Design

Peering between 6PEs and between 6VPEs is similar to the currently deployed VPNv4 PE-PE peering. It is using iBGP, with RRs to limit the number BGP sessions.

Because EuropCom plans to deploy dedicated RRs for handling iBGP IPv6 route distribution, the iBGP sessions from each 6PE (and 6VPE) to RRs will not refer the same loopback addresses. They will, however, advertise the same next hop so that the same LSPs are used.

In Examples 13-10 and 13-11, routers Nice-PE-IA and Nice-PE-VPN, the IPv4 RRs, have IPv4 addresses 100.56.56.1 and 100.57.57.1, respectively. The IPv6 RRs have addresses 100.46.46.1 and 100.47.47.1. The RR design is detailed in the section "Route Reflector Design."

In the case of 6PE, the advertised routes must be explicitly labeled (unlike VPN where the labeling is implicit in the configuration, and IPv4, where BGP does not transport a label when advertising prefixes). This is achieved by using the keyword send-label when specifying the 6PE peer, as shown in Example 13-10.

Example 13-10. i BGP Configuration for a PE Router Providing IPv6 IA (Nice-PE-IA)

hostname Nice-PE-IA !PE#26 .. router bgp 33751  bgp log-neighbor-changes !For IPv4 Internet access to Milan-RR4  neighbor 100.56.56.1 remote-as 33751  neighbor 100.56.56.1 update-source Loopback0  neighbor 100.57.57.1 remote-as 33751  neighbor 100.57.57.1 update-source Loopback0 ! !For IPv6 Internet access to Milan-RR6  neighbor 100.46.46.1 remote-as 33751  neighbor 100.46.46.1 update-source Loopback0  neighbor 100.47.47.1 remote-as 33751  neighbor 100.47.47.1 update-source Loopback0 !  address-family ipv4  neighbor 100.56.56.1 activate  neighbor 100.57.57.1 activate  exit-address-family  !  address-family ipv6  neighbor 100.46.46.1 activate  neighbor 100.46.46.1 send-label  neighbor 100.47.47.1 activate  neighbor 100.47.47.1 send-label  exit-address-family

Example 13-11 illustrates an iBGP configuration on a PE router providing VPNv6 access.

Example 13-11. BGP Configuration for a PE Router Providing VPNv6 Access (Nice-PE-VPN)

hostname Nice-PE-VPN !PE#27 .. router bgp 33751 bgp log-neighbor-changes !For VPNv4 to Milan-RR4  neighbor 100.56.56.1 remote-as 33751  neighbor 100.56.56.1 update-source Loopback0  neighbor 100.57.57.1 remote-as 33751  neighbor 100.57.57.1 update-source Loopback0 !For VPNv6 to Milan-RR6  neighbor 100.46.46.1 remote-as 33751  neighbor 100.46.46.1 update-source Loopback0  neighbor 100.47.47.1 remote-as 33751  neighbor 100.47.47.1 update-source Loopback0 !  address-family vpnv4  neighbor 100.56.56.1 activate  neighbor 100.56.56.1 send-community extended  neighbor 100.57.57.1 activate  neighbor 100.57.57.1 send-community extended  bgp dampening 15 750 3000 60  exit-address-family  ! address-family vpnv6  neighbor 100.46.46.1 activate  neighbor 100.46.46.1 send-community extended  neighbor 100.47.47.1 activate  neighbor 100.47.47.1 send-community extended  bgp dampening 15 750 3000 60  exit-address-family

Route Reflector Design

To scale its IPv4 IA service and its VPNv4 service, EuropCom leveraged RRs in its network design. It makes a lot of sense to deploy a similar RR infrastructure for scaling IPv6 IA and VPNv6 service.

For both IA and VPN services, the primary reason for deploying RRs is to improve scalability, by drastically reducing the number of BGP sessions. One RR usually peers with many iBGP speakers, preventing a full mesh of BGP sessions.

Because both IA traffic and VPN traffic are MPLS switched, RRs are not part of the LSP and can potentially be located anywhere in the network. IPv4 RRs are deployed only at L1 POPs, and dedicated for peering with IA PEs and VPN PEs. PEs peer with RRs based on their geographical proximity. RRs peer together in a full-mesh topology.

EuropCom plans to follow a similar design for IPv6 RRs and deploy IPv6 RRs at L1 POPs. Prefix aggregation can be done more aggressively with IPv6, which will keep the number of routes under better control. With this in mind, EuropCom does not expect the IPv6 BGP table size to get more than a few hundred entries per VPN for the next two to three years. As far as the IA, EuropCom considered the total number of allocated IPv6 prefixes worldwide (on 17/10/2005, it was 1322) and the number of BGP IPv6 routes currently deployed in IPv6 core BGP routers (700 entries in October 2005 according to http://www.cidr-report.org and evolving linearly). EuropCom expects the total number of BGP IPv6 routes to stay below 2000 entries by 2008, well below the current 150,000 IPv4 entries it is experiencing. Therefore, unlike IPv4 RRs, IPv6 RRs will be shared between IPv6 IA and IPv6 VPN.

EuropCom will monitor any change in the RIRs address allocation strategy: If the RIRs agree to allocate /32 prefix to large corporations for provider-independent prefixing, BGP IPv6 tables could quickly reach tens thousands of entries. Variation in the pace of the IPv6 prefix allocation, as well as service growth and customer needs, will dictate the expansion of the RR infrastructure and the possible specialization of RRs to each of the two services.

The deployment strategy for RR is different from the one for PE routers. EuropCom wants to separate IPv6 RRs from IPv4 RRs. If anything unexpected happens with IPv6, only PEs servicing IPv6 will be affected and only from the IPv6 service perspective. Because EuropCom plans to deploy IPv6 access incrementally, this strategy will dramatically lower the risk on business-critical services such as IPv4 IA and VPNv4. PEs (6PE and 6VPE) will be connected to RRs based on geographical proximity, exactly like the VPNv4 RRs. For redundancy reasons, two IPv6 RRs per L1 POP will be deployed.

To provide IPv6 RR functionality, EuropCom will install new hardware in L1 POP, and connect it to the P-routers and PE routers. It will then configure BGP peering to PEs in the L1 POP, as well as PEs in L2 POP and L3 POP attached to it. Figure 13-8 illustrates the peering points between the RR in L1 POP, and the set of RR clients.

Figure 13-8. EuropCom RR Design

The following list of BGP RR clients must be configured in IPv6 RR (xxx-RR6 and xxx-RR6_1) routers at each L1 POP:

• PE routers (xxx-PE-IA) of the L1 POP providing IPv6 IA to EuropCom customers. This is IPv6 (6PE) peering.

• PE routers (xxx-PE-VPN) of the L1 POP providing IPv6 VPN access to EuropCom customers. This includes both VPNv6 (6VPE) peering for interconnecting customer sites, and IPv6 peering (6PE) for providing IA to VPN customers.

• PE routers (yyy-PE-IA, zzz-PE-IA) of the L2 POPs and L3 POPs (underneath this L1 POP) providing IPv6 IA to EuropCom customers. This is IPv6 (6PE) peering.

• PE routers (yyy-PE-VPN, zzz-PE-VPN) of the L2 POPs and L3 POPs (underneath this L1 POP) providing IPv6 VPN access to EuropCom customers. This includes both IPv6 (6PE) and VPNv6 (6VPE) peering.

• Internet gateway (xxx-IGW) located in the L1 POP, to provide PE customers an access to the IPv6 Internet.

• RRs from other service providers. This is to provide inter-AS connectivity, and it includes both IPv6 and VPNv6 peering. This service is detailed in the "Inter-AS Design" section.

• EuropCom RRs in other L1 POP. All RRs peer together, with both IPv6 and VPNv6 address families enabled, as shown in Figure 13-9

Figure 13-9. Topology of the IPv6 and VPNv6 Route Reflection

Example 13-12 illustrates the Milan-RR6 configuration, with regard to peering with Milan PEs (providing IA and VPN access) and Nice PEs (L2 POP attached to Milan). It also includes peering with Milan's Internet gateway (Milan-IGW). It does not show peering with L3 POPs, peering with RRs in other L1 POP, or peering with RRs of other service providers.

Example 13-12. RR Configuration Example

hostname Milan-RR6 !RR#46 router bgp 33751 !6PE peering for providing Internet access address-family ipv6 !Peering with Internet Gateway Milan-IGW  neighbor 100.1.1.1 activate  neighbor 100.1.1.1 route-reflector-client  neighbor 100.1.1.1 send-label !Peering with Nice Internet access router Nice-PE-IA  neighbor 100.26.26.1 activate  neighbor 100.26.26.1 route-reflector-client  neighbor 100.26.26.1 send-label !Peering with Nice VPN router Nice-PE-VPN  neighbor 100.27.27.1 activate  neighbor 100.27.27.1 route-reflector-client  neighbor 100.27.27.1 send-label !Peering with Milan Internet access router Milan-PE-IA  neighbor 100.61.61.1 activate  neighbor 100.61.61.1 route-reflector-client  neighbor 100.61.61.1 send-label !Peering with Milan VPN router Milan-PE-VPN  neighbor 100.62.62.1 activate  neighbor 100.62.62.1 route-reflector-client  neighbor 100.62.62.1 send-label ! !VPNv6 peering for providing inter-site connectivity  address-family vpnv6 !Peering with Milan VPN router Nice-PE-VPN  neighbor 100.27.27.1 activate  neighbor 100.27.27.1 route-reflector-client  neighbor 100.27.27.1 send-community extended !Peering with Milan VPN router Milan-PE-VPN  neighbor 100.62.62.1 activate  neighbor 100.62.62.1 route-reflector-client  neighbor 100.62.62.1 send-community extended

VRF Design

The EuropCom business model is to provide VPNv6 access to some of its current VPNv4 customers. The VRF design for these VPNv6 customers is intended to be rigorously identical to the one already defined, configured, and deployed for IPv4. In particular, all existing VRFs have been assigned names, route distinguisher (RD), and route target. Enabling them for IPv6 is a matter of service enhancement and service coexistence rather than IPv4-to-IPv6 transition or new deployment.

All basic steps for the VRF design have already been made for the VPNv4 service:

1.	Definition and configuration of VRF
2.	Definition and configuration of RD
3.	Definition and configuration of routing policies (import/export)
4.	Interaction with the backbone control plane
5.	Configuration of CE-facing interfaces
6.	QoS policies

The concept of Multiprotocol VRF (MP-VRF) was detailed in Chapter 7, and it suits perfectly EuropCom strategy. Only a fraction of the actual VPNv4 design needs to be revisited. The remaining parts are a migration task, from an IPv4 service to a dual-stack service.

Out of the six steps defined above, Steps 1, 2, and 3 are handled by the migration of IPv4 VRF(s) into MP-VRF(s). VRF names, route targets, and RDs already defined for VPNv4 service apply seamlessly to VPNv6 service wherever MP-VRF is enabled. The VRF migration can be done automatically and without disrupting VPNv4 VRF operations (including forwarding) by executing the following commands:

Nice-PE-VPN(config)#service internal Nice-PE-VPN(config)#vrf upgrade-cli multi-af-mode common-policies [vrf <name>]

EuropCom plans to use this command, one VRF at a time (the command can do all VRF at once, but the migration will be driven by individual customer requests). Example 13-13 illustrates how the migration works in router Nice-PE-VPN.

Example 13-13. Migrating IPv4 VRF to MP-VRF

Nice-PE-VPN(config)#do show running hostname Nice-PE-VPN !#27 .. ip vrf Cisco-Nice  rd 21214:1  route-target export 21214:1  route-target import 21214:1 ! interface Serial0/0  ip vrf forwarding Cisco-Nice  ip address 172.21.4.1  255.255.255.0 .. Nice-PE-VPN(config)#service internal Nice-PE-VPN(config)#vrf upgrade-cli multi-af-mode common-policies vrf Cisco-Nice Nice-PE-VPN(config)#do show running hostname Nice-PE-VPN !#27 .. vrf definition Cisco-Nice  rd 21214:1  route-target export 21214:1  route-target import 21214:1   address-family ipv4   exit-address-family  !   address-family ipv6   exit-address-family !  interface Serial0/0  vrf forwarding Cisco-Nice  ip address 172.21.4.1  255.255.255.0

When enabling a VRF for IPv6, the name and the RD remains unchanged (Cisco-Nice/21214:1, for instance). With the EuropCom design approach, the route targets also remain unchanged: IPv6 is simply "enabled" for that particular VRF, and on all interfaces that belong to it.

Step 4 requires configuring the VPNv6 interaction with the backbone control plane. The interaction with the backbone control plane requires some design and configuration work and was described in the "PE-PE Routing Design" section.

Step 5 is partly covered by the migration to MP-VRFs (the VRF bound to the interface that was IPv4 only became IPv4 and IPv6). The remaining part is to configure IPv6 (addressing and routing) in the interface.

Step 6 does not need to be revisited because the same QoS policies apply to IPv6. The existing QoS design is expected to map onto VPNv6 and IPv6 IA traffic seamlessly. This is described in the "Quality of Service Design" section.

Note

With MP-VRF, an interface can only belong to one VRF, and a VRF is uniquely identified by a single name and a single RD. On a given VRF interface, IPv4 and IPv6 can be enabled together or separately, but they cannot be put in different VRFs. The enabling of each protocol is done at two levels: The protocol is enabled in the VRF definition, and then activated on a VRF interface by assigning an address (IPv4 or IPv6) to the interface.

It is a VRF design choice to share a route target between IPv4 and IPv6, or to keep them distinct. EuropCom chose to keep them identical, to minimize the redesign of VRF when deploying IPv6, and to minimize operation costs. However, that does not prevent it from enabling IPv4 only on certain sites of a given VPN, in which case sites not enabled for IPv6 will not participate in the IPv6 VPN.

Inter-AS Design

To connect to other service providers at POP/IX, EuropCom has been using the Scenario C for its VPNv4 traffic, as described in RFC2547bis, in the section "Multi-AS Backbones."

In Scenario C, multihop MP-eBGP redistributes VPN routes across RRs in different autonomous systems. Labeled IPv4 routes to the PEs are advertised across Autonomous System Boundary Routers (ASBRs) so that a complete LSP is set up end to end.

In this scenario, ASBRs are not VPN aware; only RRs are VPN aware. For VPNv4, the following setup/configuration has been deployed:

• EuropCom VPN PEs and RRs are leaking loopback addresses to service providers they peer with:

  - VPN PEs are leaking one loopback address (/32) for enabling next-hop resolution at the remote service provider location.

  - VPN RRs are leaking one loopback address (/32) for enabling interprovider (inter-RR) eBGP peering.

• The address leaking is performed over MP-BGP, with label, so that intermediate routers (P-routers) do not see these addresses. Therefore, the following MP-BGP peering has been set up for VPNv4:

  - VPN PEs iBGP peering with VPN RRs

  - EuropCom ASBRs iBGP peering with VPN RRs

  - EuropCom ASBRs eBGP peering with remote service provider ASBR

• VPN RRs of each service provider are peering together over eBGP and exchanging VPN routes. The next hop is forwarded "unchanged," so that the end-to-end LSP is not via RRs.

EuropCom customers at the Nice POP are accessing resources outside the EuropCom network, via xxCom, a Tier 1 Italian MPLS service provider. xxCom shares EuropCom Internet exchange facility in Milan.

To enable the service for IPv6 and VPNv6 in Nice, using inter-AS Scenario C, EuropCom needs to modify the configuration at Nice-PE-IA, Nice-PE-VPN, Milan-RR6, and Milan-ASBR routers. Note that for Milan-ASBR, the configuration upgrade decision is driven by the new Milan-RR6 (see "Route Reflector Design" section). The ASBRs remain completely IPv6 unaware, and do not need to be IPv6 capable.

Figure 13-10 shows the BGP peering points required to enable IPv6 interprovider connectivity from PE routers Nice-PE-IA and Nice-PE-VPN (providing IPv6 IA and VPN access, respectively) to the xxCom network.

Figure 13-10. BGP Peering Points for Enabling Inter-AS in Nice POP

The following list of additional BGP peerings is necessary to enable inter-AS (Scenario C) communication from an L2 POP such as Nice:

• IPv4 with label peering from PE in Nice to the RR in Milan (Milan-RR6). This includes NICE-PE-IA (providing IA) and Nice-PE-VPN (providing VPN access) and comes in addition to peering points between the same pair of routers already described in the section "Route Reflector Design." These BGP peering points are used to distribute IPv4 PE addresses to the other autonomous systems.

• IPv4 with label peering from the RR in Milan (Milan-RR6) to the ASBR (Milan-ASBR). This is also for distributing IPv4 PE addresses to the other autonomous systems.

• IPv6 (6PE) and VPNv6 (6VPE) peering from the RR in Milan to the RR in the other autonomous systems, to exchange IPv6 and VPNv6 routes, respectively.

The BGP peering (IPv4 with label) between boundary routers (Milan-ASBR and xxCom-ASBR) was already set up for IPv4 inter-AS communication and is reused without configuration changes for IPv6 communication.

Example 13-14 illustrates the additional configuration in a VPN PE (Nice-PE-VPN) required in inter-AS Scenario C to distribute the PE IPv4 address with label to xxCom.

Example 13-14. Inter-AS: IPv4+Label Peering from Nice-PE-VPN to RR

hostname Nice-PE-VPN !PE#27 router bgp 33751 address-family ipv4  neighbor 100.46.46.1 activate  neighbor 100.46.46.1 send-label  network 100.27.27.1 255.255.255.255

The RR in Milan is configured to peer with the xxCom RR, for both address families IPv6 and VPNv6, as illustrated in Example 13-15.

Example 13-15. Inter-AS: IPv6 and VPNv6 Peering from Milan-RR6 to xxCom

hostname Milan-RR6 !PE#46 router bgp 33751   neighbor 200.43.43.1 remote-as 16531 !to XXCom RR .. address-family vpnv6 !VPNv6 interAS  neighbor 200.43.43.1 activate  neighbor 200.43.43.1 send-community both  neighbor 200.43.43.1 next-hop-unchanged allpaths ! address-family ipv6 !IPv6 IA interAS  neighbor 200.43.43.1 activate  neighbor 200.43.43.1 send-label  neighbor 200.43.43.1 next-hop-unchanged allpaths

The RR in Milan is also peering with the ASBR (Milan-ASBR) and with each PE (Nice-PE-IA and Nice-PE-VPN) to exchange IPv4 PE addresses with label, as illustrated in Example 13-16.

Example 13-16. Inter-AS: IPv4+Label Peering from Milan-RR6 to PEs and Milan-ASBR

hostname Milan-RR6 !PE#46 router bgp 33751 .. address-family ipv4  neighbor 100.70.70.1 activate !Peering to Milan-ASBR  neighbor 100.70.70.1 send-label  neighbor 100.26.26.1 activate !Peering to Nice-PE-IA  neighbor 100.26.26.1 send-label  neighbor 100.27.27.1 activate !Peering to Nice-PE-VPN  neighbor 100.27.27.1 send-label

The Milan ASBR Milan-ASBR peers with the RR (Milan-RR6) as well as with the xxCom ASBAR (xxCom-ASBR) to exchange IPv4 PE addresses with label, as illustrated in Example 13-17.

Example 13-17. Inter-AS: Configuration at Milan-ASBR

hostname Milan-ASBR !PE#70 router bgp 33751 ..  neighbor 100.46.46.1 remote-as 33751 !to Milan-RR6  neighbor 90.1.1.2 remote-as 16531 !to xxCom ASBR !  address-family ipv4  neighbor 100.46.46.1 activate  neighbor 100.46.46.1 send-label  neighbor 90.1.1.2 activate  neighbor 90.1.1.2 send-label

In summary, to enable interprovider access to xxCom, EuropCom performed the steps listed in Table 13-4.

Table 13-4. Inter-AS Deployment Task List

Node	EuropCom Task
6PE	IPv4 with label MP-iBGP peering to RRs Leak loopback address (network 100.x.x.1 mask 255.255.255.255) (6PE peering with RRs done outside this task)
6VPE	IPv4 with label MP-iBGPpeering to RRs Leak loopback address (network 100.x.x.1 mask 255.255.255.255) (6VPE peering with RRs done outside this task)
IPv6 RR	IPv4 with label MP-iBGP peering to each 6PE and 6VPE IPv4 with label MP-iBGP peering to ASBR Leak loopback address (network 100.x.x.1 mask 255.255.255.255) IPv6 with label MP-eBGP peering to xxCom IPv6 RR VPNv6 MP-eBGP peering to xxCom IPv6 RR (MP-iBGP peering with 6PE/6VPEs done outside this task)
ASBR	IPv4 with label MP-iBGP peering to IPv6 RRs (IPv4 MP-eBGP peering with label to xxCom ASBR done already in the context of VPNv4)