On Mon, Dec 31, 2012 at 1:41 PM, John Leslie <[email protected]> wrote: > And, I'm not sure what it means to "settle on" "treat-as-withdraw" > that some of us consider "good enough" for a "limited" period while > humans are working to resolve the actual problem. We know that the > "limits" on such a period correlate all to well with the amount of > pain being inflicted on paying customers.
It means just that, "settle on." Treat-As-Withdraw leaves plenty of circumstances where BGP will still be reset, perhaps endlessly until clue arrives. Let me just go through the explanation of what happened to many networks in October 2012 again. LANL announced some malformed routes to the DFZ. Most routers propagated them and ignored the malformed bits. Some routers did not, and instead, they reset the BGP session. That was a bug, but the customers had NO OPTIONS TO WORK AROUND THIS. Their ONLY CHOICE was to wait for a patch from their vendor (for folks whose vendor routers did this) or install a patch (for the lucky users who were running OpenBSD) or to ask their transit provider to install a prefix-list to block the 5 malformed paths from going to them. If customers had treat-as-withdraw in the form being discussed today, it would not have helped. Why? Malformed Attribute Flags are not one of the criteria it addresses. What networks need is an IGNORE BAD MESSAGES option so BGP can avoid session-reset, even if the cost is rather high (say a lot of RIB inconsistency.) Let the network operator choose when the cost of bad RIB information becomes so high that he would rather have BGP reset. After all, this will vary from one network to the next based on business needs, so there should be flexibility. That is why treat-as-withdraw is "settling." Ignore bad messages is a very simple option that "fixes" (mitigates) virtually all problems so the operator can buy time to diagnose it in detail, or wait for his vendor to provide a software update, or whatever. I'm not arguing this should be the only option or even the default option. I'm arguing that it should be ONE OPTION. As far as I'm concerned, you can have treat-as-withdraw, and you can build as much complicated error handling logic into it as you want. That effort might help me someday. But if it doesn't, I know for sure that IGNORE BAD MESSAGES is something I can fall back on, which is very likely to buy me the time I need. -- Jeff S Wheeler <[email protected]> Sr Network Operator / Innovative Network Concepts _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
