Withdrawls and announcements attempt 2

Fri Jun 21 16:22:08 UTC 1996

> Its /a little/ more complex than that.  The RFC does /not/ call for closing
> down a BGP session when you change your route filters.  Cisco's have to do
> this, but its not part of the RFC.  So, if I, for the sake of argument,
> added a new filter /after/ I made an announcement to someone I would have to
> somewhere keep track of the fact that I made the announcement.  It seems to
> me that this could get to be a bit memory intensive (keeping track of the
> state of every announcement made to every peer).

You need one bit per peer per path and code that is smart enough to
use a bit map.  For 40,000 paths and 128 BGP peers, thats an
additional 640KB.  In a 64 MB router thats 1% of memory.  The reconfig
code needs to be smart enough to deal with adding the 33rd peer if you
want to do dynamic allocation.  Gated and (unreleased) Bay code
provide existance proof that can be done.

When policy is changed such that something like a MED is changed, you
need to go around clearing bits to indicate that the route needs to be
readvertised.  If the route needs to be withdrawn, leave the "I
announced it" bits set.  If it needs to be added, leave the bits
clear.  If it is changed, clear any bits to make it look like it
wasn't advertised.  Keep a list of routes that need attention and
advertise out those that need to be advertised and withdraw those that
need to be withdrawn, using the bit map to keep track of who still
needs to get an update.

Curtis