with the same route target for the RD. If this configuration is followed through for each PE and each customer RD, there will be one VPN for each customer and the VPNs will be disjoint from each other. However, MPLS VPN offers an additional feature whereby it is possible for routes to be imported and exported between sites of different customers or even the Internet. This is achieved by configuring additional route targets such that where routes are to be shared, the route targets are the same. If customer 1 and customer 2 wish to share connectivity, but only between sites B and C, then a new route target identifier is created and installed for the correct RDs in PEB and PEC. If the new route target identifier is 1:300, then in PEB RD 1:2 (for the customer-2 address space) would have the 1:300 routing target added for importing and exporting routes. In PECD RD 1:1 (for customer 1) would have the target identifier 1:300 added for importing and exporting the site-B routes into site C. Note that PECD has two customer sites attached and will have two PSFTs identified by RD 1:1 and RD 1:2. It would be up to the customers to agree between themselves not to have overlap- ping addresses at their sites, but when this is done they can establish connectivity over the provider VPN infrastructure. The preceding discussion has shown how the PE LSRs run BGP and the P LSRs run an IGP such as OSPF. There is one further requirement for full routing dissemination: The CE routers and PE routers need to peer for routing information. Note that the CE only peers with its immediate PE neighbor and can do SO using an IGP such as OSPF (although other Chapter 13 Multiprotocol Label Switching options are possible). It is worth exploring how the routes are disseminated for a path between CEE and CED and where site E is only connected to the VPN for customer 2. First CEE will learn about routes in site E through the IGP running in site E; these will be exported (and possibly summarized) into the IGP running between CEE and PEE such that PEE c