Hi Jeff,
> I've already posted an alternative. The BGP MARKER makes it possible > to recover Message framing. I'm not sure I think this is a good idea. I'm pretty convinced that it's NOT a good idea. What happens if the marker is preceded by 0xFF? Ok, you can make some educated guesses based on what looks to be a length field (probably NOT starting with 0xFF), but you are just guessing. And what if the error was egregious and your parsing is off by more than a byte or two? That marker might be a path attribute. Now what? Ok, yes, you could take a risk and see if you can keep parsing, but then what happens if you hit another error? Just keep guessing along? Your odds of guessing correctly are falling. Or do you try to be really, really smart? While you may be willing to gamble with your domain, please remember that you are also gambling with every network that accepts updates from you, transitively. For lots of folks, that's the bulk of the Internet. Is this a good gamble? I'm not convinced. >> Semantic errors would be consistency violations within the contents of the >> message. In these cases, treat-as-withdraw seems reasonable. > > The current draft for "treat-as-withdraw" has a great deal of > complexity. You seem to both favor this solution, and hate the > complexity. I also hate the complexity, and "ignore-bad-message" is > my alternative. To be specific, treat-as-withdraw seems to be less dangerous. As implemented (and perhaps NOT as envisioned), treat-as-withdraw can be done with an acceptable amount of complexity, IMHO. It needs to be done VERY simply. > Would you rather the draft simply eliminate a lot of the complexity? > I would, because the complexity is what creates more opportunities for > session-reset. It also may catalyze bugs. I would welcome that, but we should recognize that we're making a tradeoff. 4271 opts for maximum simplicity: if there's an error, shut it down. Anything more than that will be added complexity. What we're trying to do is to add some small amounts of complexity for a hopefully significant amount of robustness. If done right, that would be a reasonable tradeoff. If done wrong, this could be a major disaster. >> The entire problem with the ignore option is that it leaves bogus >> information in the network. Suppose that the update contains an AS path >> change for a prefix. If you ignore the update, then you ignore that path >> change, AND, you fail to propagate that change to your upstream neighbors. >> Now, BGP's loop prevention mechanism is out the window and, in the worst >> case, you've created an inter-domain forwarding loop. >> >> If, on the other hand, you withdraw that prefix, then any alternate >> connectivity for that prefix can come into play. >> >> In short, treat-as-withdraw is a fail safe approach. Ignoring updates is >> not. > > Treat-as-withdraw is NOT fail-safe. It can create loops or blackholes > in your network. Claiming over and over that it is safe will not make > it true. Example please? Assuming that the prefixes are parsed out of the message correctly, then treating them as withdrawn should be hazard free. > Ignore-bad-message has bad qualities, which are just as bad as > treat-as-withdraw, except it is less complicated to implement and > there is a greater chance it can avoid a potentially crippling > session-reset loop. Non-sequitur. Cyclic resets are orthogonal to treat-as-withdraw. As enumerated above, ignore-bad-message is harder to implement and is more dangerous. Tony _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
