On Thu, Jan 3, 2013 at 8:01 PM, Tony Li <[email protected]> wrote: > Example please? Assuming that the prefixes are parsed out of the message > correctly, then treating them as withdrawn should be hazard free.
If a transit router in your AS treats-as-withdraw a prefix, other routers may try to send traffic across it, but the router which has treated-as-withdraw will either have no information for that route, or it will have made a different bestpath choice. This could cause a loop or a blackhole. > Non-sequitur. Cyclic resets are orthogonal to treat-as-withdraw. As > enumerated above, ignore-bad-message is harder to implement and is more > dangerous. No, ignore-bad-message is not harder to implement. To say so is simply a lie. To treat-as-withdraw you have to follow some rules, parse a damaged message to look for NLRI, and then withdraw them. Treat-as-withdraw is unquestionably harder than simply ignoring the whole contents of a message. Your argument is some hand-waving about how hard it is to ignore a message, and your incorrect belief that treat-as-withdraw can't leave the RIB in state that can cause forwarding problems. I'm not picking at your position just for the sake of argument. I agree with you that error-handling (current draft) is too complicated. I'm suggesting alternatives, as well as modifications that should be made to either RFC4760bis or to error-handling to make it actually work. Just to move beyond ignore-bad-message vs. treat-as-withdraw arguments for now, I believe some basic questions need to be answered for treat-as-withdraw to be a useful option. 1) should a BGP speaker be able to promise that MP attributes will be sent first? if so, a capability code is needed this could be done by error-handling or RFC4760bis 2) should non-MP NLRIs in the message be moved in the way error-handling suggests? if so, a capability is absolutely required the basic encoding of BGP Messages changes if this is to be done 3) there are numerous attribute-specific rules in error-handling now. They are not crazy but they are complicated. Is this complexity enough to deter vendors from implementing error-handling at all? Are they likely to catalyze bugs? Do the attribute-specific rules do more harm than good? If you are in favor of treat-as-withdraw then the above are important questions to answer. -- Jeff S Wheeler <[email protected]> Sr Network Operator / Innovative Network Concepts _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
