BGP Connection Collision Avoidance Enke Chen (enke@redback) Jenny Yuan (jenny@redback)

1. BGP Connection Collision AvoidanceEnke Chen (enke@redback.com)Jenny Yuan (jenny@redback.com)

2. Outline • BGP Connection Collision • On-going Issues with session establishment • Connection Collision Avoidance • Backward Compatibility & Graceful Restart • Summary

3. BGP Connection Collision • Connection collision occurs as a BGP speaker currently plays both the active role and the passive role. • Complications by connection collision • Overly complex state machine • State machine: one set vs. two sets • Intricate interaction and timing of two sockets and one session • Connection collision resolution requires more than just closing one of the connections! • It has been a challenge to make the BGP session bring-up code robust • Fixes have been going on for years!

4. On-going Issues with Session Bring-up • Inconsistent states due to lost Keepalives during collision resolution • Established -------- OpenConfirm • Some implementation sends notification for connection collision, which may results in the close of both connections • Some implementations handle connection collision by closing both connections. • Due to these issues sometimes it takes longer time for a session to be established. • Lack of uniformity hinders interoperability and complicates network operation.

5. Dealing with the Issues • Either keep fixing and breaking the code the old way • Or explore if the issues can be dealt with differently • Is it possible to simplify the session bring-up logic? • Observations: • Such issues do not exist in LDP or MSDP! • Can we follow the similar logic and avoid BGP connection collision all together?

6. Avoid Connection Collision (Proposal) • Let a BGP speaker play only the active or passive role for a particular session • Active role: initiates the connection • Passive role: waits for the connection • A BGP speaker determines its role based on the AS numbers, and peering addresses involved • The speaker with a larger AS number (and larger peering addresses when AS numbers are equal) plays the active role

7. Backward Compatibility & Graceful Restart • What to do when an active speaker receives a connection request? • Accept the connection if the speaker has no established or initiated connection. • Otherwise close both connections, perform a random back-off, and re-try. • Graceful restart • When necessary, a passive speaker can still initiate a connection (once) to signal the restart for faster recovery.

8. Summary • The session bring-up can be simplified significantly by avoiding or minimizing the connection collision • Only one set of state machine to maintain • More robust implementations • Reference: draft-chen-bgp-avoid-collision-00.txt

9. Acknowledgement • Thanks to Andrew Partan and John Scudder for their comments and suggestions.