I forgot to put my message in here... Here it was. I'll wake up one of
these days.
Ok, this is probably obvious, and may have been thought of by many of you
before, but here are some thooughts. Comment if you'd like...
Ok, the huge number of withdrawls with respect to announcements has to do
with the fact that withdrawls of routes are made to a peer even if the
announcement of that route was never made to the sepcified peer. (Or so
conjectured Craig in his talk). At first I was wondering why they had such
a thing written into the RFC (i.e. why am I withdrawing a route that I never
announced to someone, it seems like a horrible waste), but in a blinding
flash of the obvious while I was sitting outside having a cigarette it came
to me....
Route map filters.
Well, ok, how much more obvious can you get you ask?
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).
This leads me to wonder whether if we had infinite memory (just for the sake
of argument), if it would be more processor intensive to keep track of all
of your announcements or if the overhead invloved in dealing with withdrawls
that don't affect me is less.
Justin Newton
Internet Architect
Erol's Internet Services
