an learn them and add them to a PSFT for customer 2, which has RD 1:2. These routes are redistributed into the EBGP interface at PEE, and BGP will associate these routes with an RD (1:2) and one or more route targets. BGP passes these routes, with the route target(s), to the other BGP PE LSRs over the IBGP interface. Because site E is only to be "connected" to other customer-2 sites, we will assume a single route target of 1:2. Only the PE LSRs with the same route target specifica- tion accept the routes, SO for example PEA ignores these routes because it only uses a route target of 1:1. However, the PSFT for RD 1:2 on PECD has route target 1:2 specified SO it imports the routes; the PSFT for RD 1:1 on PECD (i.e., customer 1) does not have this route target and SO ignores the routes. Now the routes are added to the PSFT for RD 1:2 at PECD, and these can be redistri- buted to the OSPF instance running between PECD and CED. Now CED has learned the routes and can redistribute them into the IGP running at site D. This process is carried out in the reverse direction and for all end sites that share common route targets. It should be noted that at no point in this example have the routes in the P LSRs been distributed to the customer sites, nor have the customer site routes been redistributed to the P LSRs. This is by design; the PE and P LSRs will run their own instance of an IGP that simply allows signaling to be transported through the core and with an address space that can be hidden from customers. It will be seen that there is no need to redistribute the BGP routes into the core IGP. LSP Paths and the Forwarding Model for an MPLS VPN In a conventional core IP network that uses an IGP in the core and BGP at the edge, there is a requirement for at least aggregated BGP routes to be redistributed into the IGP. The reason for this is that if a packet for an external network is in transit through the core, the core routers need to know the next hop. An alternative solution is to run IBGP on every router in the core SO 