On Tue, Jun 26, 2001 at 11:48:29AM -0700, Sean Donelan wrote:

RFC 1771's guidance on what to do with a announcement may have been filled with good intentions, however the few times it has been executed, it seems to create excessive harm to the Internet.

I propose it is time to revise RFC 1771.

[snip]

RESOLVED, the error handling mechanism should be revised to reject only the portion of the announcement in dispute instead of disrupting the entire BGP session.

This would result in a small number of networks, most likely those who originated the disputed announcement or are closely associated with the announcer, being disrupted. But the portion of the Internet with generally accepted announcements would not be affected. This limits the colleteral damage from these disputed announcements to the small number of networks in dispute.

The basic issue is one of scale vs integrity. However, I think this particular case is one in which the RFC-dictated behavior is the correct choice. The problem is that one [set of] router[s] did not follow such behavior and thus escalated the scale of the problem significantly. Given that the malformed route in question was most likely originated from a single router, the only damage that should have been done was a loss of routability for networks behind that one router. While of course that could be arguably a significant number of networks, I think it's a safe assumption that X losing its peers is pretty much always a smaller impact than all of X's peers losing -their- peers. If network XYZ's routers have N peers each, the RFC-dictated behavior gives us N peering sessions lost (assuming the offending route was advertised to all peers), instead of N^2 (or greater) sessions as was the case. I think the logic of dropping the session is sound. If a router originates one malformed route, who's to say the rest of its routes are correct? Perhaps other routes are corrupted, but not in ways detectable by the router's sanity checks. Since the offending route is indeed malformed, it's not unreasonable to stop trusting the router from which it originated. Since it's likely[1] only a single router is originating the route, dropping sessions to that one router controls the blast radius[2]. This is not to say that the issue of scale is unimportant. It most certainly is. However, again, if the first router(s) to receive the route had behaved properly, the scale of the problem would have been small. The only place you'd see a flap of 100,000 routes is if the offending router was your upstream's. Everyone else would only see (at most) a flap of the routes originated by and/or behind that router (in BGP topology terms). Perhaps a knob to control the behavior would be an acceptable compromise for some. I think it's a bad idea for two reasons. First, it allows bugs such as this to go unfixed, because when it happens people just adjust the knob to keep their BGP sessions stable. Second, it circumvents the integrity control. If a router has many corrupted routes, but only a few trigger the sanity checks for malformation, the session stays alive and the remaining corrupted routes are then propagated network-wide. While this may seem like a paranoid philosophy, a little paranoia can be good when considering the integrity of the larger whole. -c [1] = Yes, "likely" is a relative term. I know there are plenty of cases where the same route is originated by multiple routers, however the odds of more than one of them corrupting a route at the same time are probably slim compared to the odds of a single one doing so. [2] = In this specific case, as I understand it, the direct peers did in fact drop the offending BGP session, however they propagated the offending announcement to their peers before doing so. In this case, of course, the blast radius is not controlled.