On Fri, Jan 4, 2013 at 1:54 AM, Saikat Ray (sairay) <[email protected]> wrote: > [SR] Ok. This however does not happen in bgp-free core (ASBR2 will tunnel > the packet to ASBR4 even if AR3 is in the forwarding path).
Yes, absolutely true. On Fri, Jan 4, 2013 at 2:01 AM, Tony Li <[email protected]> wrote: > And we should also note that this can happen with ANY error recovery > mechanism. Anytime AR3 and ASBR4 receive different information or process it > differently, you'll have a problem. Also true with simple session reset: if > AR3 detects an error and shuts down its iBGP connection, then ASBR4 won't > know it and you've got a blackhole. > > Bottom line: this situation already occurs with session reset, will occur > with treat-as-withdraw, and will occur with ignore-bad-messages. > > So, what was the point of this argument again? The point is that treat-as-withdraw is relatively complicated and does not solve all the problems that many list participants might expect it to. Ignore-bad-message is less complicated. It has similar problems to treat-as-withdraw but the implementation cost, and bug risk, is lower. Because several posters have expressed concern about the complexity of additional code required to implement treat-as-withdraw, and because some aspects of it truly haven't been thought through yet, it is useful to compare treat-as-withdraw to something simple, even if it may seem stupid at first. On Fri, Jan 4, 2013 at 2:15 AM, Tony Li <[email protected]> wrote: > 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? For 13 years I've maintained a reference implementation of BGP for the purpose of troubleshooting vendor implementations. I'm posting, however, to speak from the operator perspective. There are plenty of programmers participating in the IETF process, and not enough operators. >> 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. 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. 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. >> 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. ;-) I've written several times how to ignore messages easily. You already know how though, you just think it's a bad idea. This is a reasonable place to disagree. I'll save my opinion about JFK for another time. > 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. Indeed. -- Jeff S Wheeler <[email protected]> Sr Network Operator / Innovative Network Concepts _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
