Jeff,
>>> 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. > > If you read back a few posts, you'll note that I suggest it is > possible (without certainty, though) to re-synchronize using the > MARKER. > > I'm not saying you must do that. To ignore a Message you can just > ignore all of its contents. If the Message Length is correct, then > you do not need to re-synchronize, because the Message framing won't > have been lost. I also suggested this in the same post. True, but again, we're trying to deal with error handling. When the interesting syntactic errors occur, then the Message Length is very much in doubt. A typical syntactic error is an off-by-one inconsistency between the Message Length and the sum of all of the lengths of the TLVs (and overhead). There is no good reason to believe the Message Length or the lengths of the TLVs is correct, so our code should probably check both. Then check to see if the Marker (no need to shout ;-) is in the right place. That's reasonable for off-by-one, but that's not the only possible mistake. It's easy to have an inconsistency which is in the tens or hundreds of bytes. Now what? We could again check both alternatives, but again, the presence of a Marker, even in one of the possible locations, is no guarantee. You could easily skip over an entire message, for example, and end up ignoring two updates, not just one. > You've tied a need to re-sync the Message stream, to the simple > ability to ignore Messages. You don't have to do both. If your > argument is that re-sync is too hard to be worthwhile, I'll buy into > your opinion; but you should still consider the simple case if > ignoring Messages with no re-sync feature. As I've argued above, yes, I'd say that the re-sync risk vs. effort vs. return tradeoff isn't worthwhile. I'm not sure why we would discuss a different error recovery mechanism that doesn't deal with the syntactic errors. Again, if there are no syntactic errors, then recovery by ignoring the message leaves the network in an inconsistent state, as you've stipulated. Clearly, treat-as-withdraw is preferable for this case. The remaining question is how to deal with the syntactic errors. I've argued that we shouldn't mess around and should just accept the session reset. > All you need to do to just ignore Messages is ignore the content of a > malformed message and move on. Either the Message Length will be > correct and the following Message will begin with a MARKER, or it > won't. What this buys you is much of what treat-as-withdraw intends > to fix with almost no implementation cost. I agree that the Message Length will either be correct or it won't. Now, all us need is an oracle (the computer science kind ;-), to tell us which is which. Got any handy? ;-) Regards, Tony _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
