On Wed, Jan 2, 2013 at 12:56 PM, Tony Li <tony...@tony.li> wrote: > While we can do SOME things to decrease session resets, we cannot fix all > cases and simply treating things as a withdraw and walking away is wholly > unacceptable, as some of you will hopefully agree. Creating arbitrary hair > here is NOT going to help as the error handling code itself will become > fraught with errors.
Tony, Every operator I've asked thinks "ignore bad BGP messages," which is even more extreme than treat-as-withdraw, is a good idea. I'm not saying anyone thinks this would be a good default. These things can just be knobs used when they are appropriate or necessary. Respectfully, you are about as wrong as one could get on this issue. Of course customers don't want one prefix to be broken. Fifteen years of "CEF problem" have taught us all that these conditions are hard to troubleshoot. However, it is often preferable to have one or many prefixes broken, than have a BGP session flap endlessly due to some bug. The vendor should have some standards body coverage for giving the operator this knob, and customers are right to ask for it. Sure, you're giving us more rope. Sometimes that is what we need. Related to this, what is your plan for dealing with BGP Attribute re-ordering in the rewrite of RFC4760? Currently there is no mechanism for telling a BGP neighbor that you intend to send the MP-NLRIs before other Attributes. Doing that goes against RFC4271's recommendations. Relying on that behavior (e.g. for error-handling) is not possible unless the neighbor promises to do it. Thus far, there seems to be no intent to allocate another Capability Code for this. The MP-BGP Capabilities Optional Parameter was not designed to be extended to do other things besides announce to the neighbor what AFI/SAFIs it supports. -- Jeff S Wheeler <j...@inconcepts.biz> Sr Network Operator / Innovative Network Concepts _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
