that it can learn about the global routing table. However, neither solu- tion is useful here because we want to support overlapping edge address spaces. Addition- ally, even if there are not overlapping address spaces, neither solution is popular because either OSPF has to be burdened with all (or many aggregated) external routes, or, with the full BGP solution, there can be complex route-filtering operations required. MPLS VPN provides a more elegant solution. The route dissemination model has been defined. Note that the PE and P routers (as shown in Figure 13.15) are assumed to run an IGP that only concerns itself with the internal address space of the core network. Each of the IBGP interfaces on the PE routers is advertised in the IGP as a full host route (32-bit mask). Then, if LDP is enabled in the PE and P LSRs, the LSRs will have these host routes in the routing tables and will note each of them as an FEC that needs a label. Consequently, LDP will construct a full mesh of LSPs between each of the internal interfaces of the PE LSRs. Now packets can be forwarded between the PE routers using the LSPs, and because MPLS does not inspect the IP packet, there is no need for the P routers to know the external addresses or routes. There is a uniqueness problem with the solution just presented because a labeled packet arriving at an egress PE can have packets destined for different customers. Using LDP as MPLS Virtual Private Networks Customer 2 Customer 2 Unlabeled Unlabeled IP Packet IP Packet BGP Label Binding Traffic Direction Fig. 13.16 Packet path between site E and site D. The encapsulating LSP is shown highlighting the use of an additional label advertised by BGP. previously described results in LSPs that transport packets to the egress LSR without needing an IP prefix lookup. However, if packets were simply placed inside these LSPs at the ingress, then at the egress there would be no way to distinguish between packets des- tined for different customer sites connected to the PE. The IP addresses cannot be us