|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Withdrawls and announcements attempt 2
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 - - - - - - - - - - - - - - - - -
|