Jeff,
>>> No, ignore-bad-message is not harder to implement. To say so is simply a >>> lie. >> >> I'm sorry, but this conversation has taken a turn for the worse. I may be >> wrong (I really don't think so), but I am not lying. >> >> You owe me an apology and I'm not going to continue this conversation until >> you do. > > If calling your statement a lie has offended you, I apologize. Thank you. > It is, > however, absolutely wrong; and you've framed it as absolutely right. You're welcome to disagree. It remains my opinion about the coding complexity. I think my experience with BGP coding speaks for itself. What's yours again? > To review, you've said that ignoring a BGP message is not even > possible. Of course we know that isn't true. Do we? Given an arbitrary set of errors on a byte stream where there are no guaranteed delimiters, how do you propose to resynchronize with absolute certainty. My position is that it is risky as it requires certain inferences. > You've also said it is > harder to ignore a message than to treat-as-withdraw. This is not > true either. So you can tell us what's true and what's not? I'm dying to know about O.J., L.H. Oswald, and Marilyn. Do tell. ;-) Yes, in my professional opinion, trying to recover from the semantic errors is pretty straightforward. Recovering from the syntactic errors is not going to work and will end up as a reset. Guessing about the message delimiters is going to be messy and hard. > To do treat-as-withdraw you have to, at minimum, extract > NLRI from a known to be damaged message. The current error-handling > draft then requires you to apply numerous rules. Only then may you > decide if you treat-as-withdraw or terminate the BGP session. Your > assertions cannot possibly be correct in any implementation, period. Again, I was speaking to a practical implementation, not necessarily what the draft is currently specifying. The reality is simple: extract the NLRI. If you can do so cleanly, then treat them all as withdrawn and syslog loudly. If you can't extract the NLRI cleanly, then it's reset time. > The fact is you don't want to ignore messages. I am much more > persuaded by your argument that ignoring messages may result in the > persistence of bad RIB entries which may be re-forwarded within or > outside the AS. That is a good argument. It's not constructive, > however, to cloud the issue by making absurd statements like "ignoring > a message is impossible." It is possible, you just feel strongly that > it is the wrong approach. It is impossible to do so in the general case with 100% certainty. You have lost context on the data stream. You can no longer distinguish between data and TLV overhead. There is (unfortunately) no redundancy that you can use to determine that any hypothetical recovery is correct. That makes it a poor error recovery approach. Now, if we had thought to have put a CRC-16 at the end of each message, we'd be in much better shape. Sigh. Tony _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
