You can use this feature to delay route updates for a specified family until the forwarding table is synchronized. When a device starts up, BGP establishes peering sessions with its neighbors and receives route updates. These route updates are then readvertised as more specific BGP routes or less specific aggregates. Advertising routes prematurely, that is, before all the available routes are installed in the forwarding table might result in traffic loss.
In multihomed networks, this behavior might cause unnecessary loss of service when a BGP session at the primary provider edge comes up. This problem is more pronounced when the primary provider edge device advertises route aggregates because a few aggregate prefixes can be announced more quickly to the network peers than a full routing table with thousands of more specific prefixes to the forwarding table. To avoid this problem, the device must delay a BGP route advertisement until the associated forwarding state is installed into the forwarding table. A Juniper device can use this feature to delay the route advertisement; and you can configure the minimum and maximum delay periods.