On Thu, Jan 3, 2013 at 9:53 PM, Saikat Ray (sairay) <[email protected]> wrote: > [SR] Wrong in what sense? BGP code does not care whether it is a transit or > an ASBR. What I described is exactly what the code will do. > (i) a path for a prefix (a "net") is withdrawn. > (ii) BGP deletes the path from that net. > (iii) BGP reruns bestpath computation. > (iv) If the bestpath changes, > (a) if there is a new bestpath, then BGP readvertises the > new bestpath to all its peers > (b) if there is no bestpath (which would be the case when > there is no path for the net), BGP will send withdraws to all its peers.
Bugs can be present at other places than an ASBR. Imagine the following very ordinary network: AS100 --- [ ASBR2 --- AR3 --- ASBR4 --- ] AS500 ASBR2 will have iBGP routing exchange with ASBR4 by some means. This may be an ordinary iBGP session, via a route-reflector, or whatever. If AR3 is buggy but it is in the forwarding path between ASBR2 and ASBR4, then ASBR4 potentially will send packets to AR3, yet AR3 has treat-as-withdraw a route. ASBR4 is not subject to the bug, receives and installs the iBGP-learnt route from ASBR2, and happily announces it to AS500. Now you see that ASBR4 and AS500 can both send traffic into the network which is either blackholed or looped because of a bug in AR3. This is exactly why the base BGP specification has a lot of rules about what kind of routing policy you shouldn't apply to iBGP-learnt routes. You can create loops or blackholes with no malfunction at all, if your vendor has given you a little bit of rope -- the ability to apply a route-map to an iBGP neighbor and alter local-preference or various other path attributes which influence the bestpath decision. You certainly will encounter blackholes or loops if a router in the middle of your network is buggy and does treat-as-withdraw. If every AS contained only one router (or two), you would be correct. However, you have overlooked the possibility of a bug affecting just a path learnt by a transit router in the middle of an AS. On Thu, Jan 3, 2013 at 9:54 PM, Tony Li <[email protected]> wrote: >> 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. It is, however, absolutely wrong; and you've framed it as absolutely right. To review, you've said that ignoring a BGP message is not even possible. Of course we know that isn't true. You've also said it is harder to ignore a message than to treat-as-withdraw. This is not true either. 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. 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. Operators continuously feel that the IETF does not understand their concerns. The IETF feels that operators don't participate. Both are right. I'm giving you the operator perspective and I am perfectly willing to admit that my suggestion is both extreme and potentially stupid; but I think it is still be smarter than the one on the table right now. It would be more productive for you to state the reason why you think ignoring messages is stupid, than to simply say it's not possible or it's too hard. If you want operators to participate in the process, you have got to be forthright with people who may have a very different view than you. I can say, I want to crush my thumb with a hammer, and you can tell me that's stupid and be right. If you say it's not possible because hammers don't work that way, of course I'm going to call you out because I know hammers can be swung in all manner of dangerous ways. If you tell me my position is stupid, at least that is a matter of opinion and open to argument. -- Jeff S Wheeler <[email protected]> Sr Network Operator / Innovative Network Concepts _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
