hapter 12 supports many functions. The WAN functions pre- viously supported by a core router might now be fulfilled by what is called a P leaf. It is not neces- sarily a dedicated box; instead one should think of the P leaf as ports on a shared multitenant fabric. Figure 13.20 offers a compelling argument for merchant-silicon-based routing. Nine bays of equipment can be replaced by one-half of a bay-nearly a 20X improvement. The footprint, power consumption, and unit cost all scale roughly the same. 13.2.5 ROUTE REFLECTION In the introduction to MPLS, it was described that the ingress services edge would request the transport of packets to a distant egress edge. Expanding further, each service edge, either through static configuration or a dynamic protocol called Border Gateway Protocol (BGP), knows the set of addresses that are accessible behind it. Each edge needs to then advertise this information to all other edges in the network. Using a simple IPv4 Internet service as an example, one PE may know that the address 200.201.202.203 is accessible through it. It needs to shout to the rest of VENDOR PROPRIETRY MERCHANT SILICON CUSTOM ASIC D1 Physical Core Router 9 Racks of Equipment 51 Tbps Merchant Silicon P Leaf Half Rack of Equipment 57 Tbps ROADMAP FIGURE 13.20 Packet core technology evolution. Network Core FIGURE 13.21 Why use a RR? the PEs in the network "hey, if you want to send packets to 200.201.202.203 send them to me." It could do this by sending individual messages to each other IPv4 PE in the network. This creates N2 sessions to exchange routing updates. The industry developed a RR as a meet-me point for exchanging routing state. Each PE establishes one session to the RR to send and receive routing state (see Figure 13.21). Because they can become a single point of failure, RRs are always deployed with at least 1 + 1 redundancy. There are very sophisticated schemes for load balancing, scaling, and creating resil- iency in the RR infrastructure. Historically, RRs were implemented using traditional rout