Customer 2 Fig. 13.15 MPLS VPN architecture. As can be seen from the preceding description, there can be a large number of address spaces to manage in the collection of VPNs because it is likely that each customer is using a private address space range that might overlap with another customer's address space. This is not a problem for the CE and P routers/LSRs because they only use one address space on all interfaces. However, the PE routers have to manage multiple address spaces. Consequently, the PE Label Switch Routers have a routing table for each connected customer and one for the provider's IP space. The main task for the MPLS VPN architecture is to support transport between the PE LSRs without having to run multiple routing tables in them. For the purpose of routing protocols, the peering is organized such that each CE router only peers with the PE LSR it is immediately adjacent to. Specifically, it does not need to peer with another CE at another of the customer's sites or with the core network. This sig- nificantly simplifies the configuration and operating complexity of the CE router. IP Route Dissemination The key to the operation of the MPLS VPN is that each PE maintains a Per-Site Forwarding Table (PSFT) for each customer site that is directly connected to it. While this is an additional burden, it is limited to the number of customers connected to each PE, which is likely to be small (compared to the total number of sites in the whole network). However, a P LSR has to carry the traffic for potentially all VPNs. If each P LSR had to cope with the address space of each customer, it would require a PSFT for each VPN, which is clearly not scalable. Con- sequently, the core makes use of MPLS tunnels between each PE such that the customer MPLS Virtual Private Networks address space is never seen in the P LSRs because the packets are encapsulated inside an LSP. This means that each P LSR only has to run some form of IGP, such as OSPF, without needing to import any other routes. If the provider network (P a