1. Entire Routes Reflecting capability draft-zhang-idr-bgp-entire-routes-reflect-00.txt Zhang Renhai : (zhangrenhai@huawei.com)zhangrenhai@huawei.com

2. A typical network organization RR PE1 PE2 PE3 CE

3. Users are thinking Performing the traffic load balancing between primary link and backup link to make the resources more efficiently used.

4. Questions and solution Can the RR reflect all routes to other client for performing traffic load balancing? If yes, how to withdraw one of multiple routes to a destination ? –Add a nexthop information in the withdraw segment in the update message. A new capability should be negotiated between RR and clients to achieve it.

5. Entire Routes Reflecting capability When a client is configured to receive multiple routes from RR, it should negotiate the capability with the RR before being capable of handling the changed format of the withdraw segment in update packet. For each, different parameters are included as multiple Capabilities in the Capabilities Optional Parameter. Capability Value field: +-------+-------+-------+-------+ | AFI | Res. | SAFI| +-------+-------+-------+-------+

6. Change of update Changes related to update action is: –For the routes of same destination, routes sender (or RR) has two choice: Send those with which the client can perform traffic load balancing send all routes if each of them has a different next hop, send the optimal one if the next hop is same. No change to update packet format –No change to any attributes of routes –Send the same NLRIs with different attributes (including NEXT_HOP) in different packets

7. Change of withdraw Implicit withdrawal –If the nexthop is the same, the update should be treated as a withdrawal –If the nexthop is different, the update SHOULD NOT be treated as implicit withdrawal any more, a new route is reaching prefix and nexthop can explicitly indicate the route to be withdrawn To withdraw a route, add a nexthop information in the withdrawal segment. –A withdrawal without the nexthop information should be treated as to withdraw all the routes to the destination

8. Change of withdraw segment For IPV4 address family +-----------------------------------------------------+ | Withdrawn Routes Length (2 octets) | +-----------------------------------------------------+ | NEXT_HOP (4 octets) | +-----------------------------------------------------+ | Withdrawn Routes (variable) | +-----------------------------------------------------+

9. Change of withdraw segment Other address family +---------------------------------------------------------+ | Address Family Identifier (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +---------------------------------------------------------+ | Length of Next Hop Network Address (1 octet) | +---------------------------------------------------------+ | Network Address of Next Hop (variable) | +---------------------------------------------------------+ | Withdrawn Routes (variable) | +---------------------------------------------------------+

10. Comments and questions Is there interest in this proposal? What work on this proposal remains? Should this be a working group draft?