ultiple instantiations of the VNF. Peak-rate shaping is a good example of this constraint. Consider an end-to-end flow that requires peak-rate shaping feature. The flow is split into two or more load-balanced subflows that are processed by two more instantiations of the VNF over two separate paths (see Figure 3.12). The rate computation logic (e.g., leaky bucket algorithm) and packet processing operations (buffering, forwarding, discarding, etc.) will have to be split across two or more VNFs in real time in order to deliver end-to-end rate control for the aggregate flow. The two VNFs have to communicate and coordinate rate-control statistics and operations. The latency associated with such coordination will lead to inaccurate aggregate rate control. Building the Network of the Future Forwarding Instance 1 (ingress) (egress) Rate Control Algorithm Forwarding Instance 2 FIGURE 3.12 Problem of performing accurate rate control coordination across two forwarding VNF instances. There are other less egregious examples of the difficulty of splitting VNFs as multiple instantia- tions. As stated earlier in this section, a network flow often uses multiple equal-cost paths. Counters and statistics at multiple points along the path of flow may need to be combined in order to meet OAM requirements. Accurate computations that are needed for OAM may be difficult due to syn- chronization and discontinuity issues. For example, interval statistics for two paths may be added together to compute the total number of packets transmitted for the flow during a given hour. Time- synchronization across the multiple counting tasks will not be precise. Another example is man- aging states of TCP sessions (NAT, firewall [FW], proxy) and point-to-point entities. If session management is split across multiple VNFs, state has to be copied across instances. If one instance fails, the end-to-end session will fail. This may actually result in lower resiliency. Despite the complexities described above, operating multiple, parallel instances is the o