|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: Global BGP - 2001-06-23 - Vendor X's statement...
> Date: 26 Jun 2001 19:23:42 -0700 > From: Sean Donelan <[email protected]> [ heavy snipping throughout ] > I agree, you must have both sides (conservative send, and liberal > receive). > > Sending bad data is not acceptable. Cisco should not send bad data. I think that everyone agrees here... the question is, what penalty to apply and with what scope when some router spews bad data? > Crashing/aborting when you receive bad data isn't acceptable either. > Bad data happens, Vendor X should not abort if it had other options. 1. Flapping. If the route is bad, put the route in "time out corner". 2. AS-PATH filtering. If the as-path looks funny, kill the route. 3. Bogon/spoofing filtering. If the source IP is funny, block traffic from that IP. Solutions to routing problems follow a "punishment fitting the crime" system. In this sense, I agree with your logic about penalizing a single route being of appropriate scope for bad BGP. Heavy flapping is bad because of a two-word phrase: state maintenance. Any proposed solution should avoid intensive state maintenance, else it will be as much of a pain as flapping. My gut feel is that I'd rather nuke the connection with a bad router, deducing "we don't trust this one". Looking at the above 1-3, however, this sort of behavior does not make sense: 1. If a route flaps, do we damp[en] all routes from it, because { one is | some are } "bad"? No. 2. When some idiot redistributes their upstreams' routes, do we kill their BGP session? I wish, but the answer is no. 3. When funky packets land, do we blackhole anything from the sending router? Nope; this would be increasingly dangerous as one got farther into the core. The above are examples of layer-eight mistakes. If we consider bad data to be the result of a loose nut between the keyboard and the chair, then we should probably penalize on a per-route basis. Up to this point, I agree with you, Sean [Donelan]. But the $100k question (100kroute question?) is: "Does bad data fit in this category, or does it mean that the router on the other end is so fscked that we kill the connection?" It would seem that the RFCs imply the latter. If we suggest otherwise, I should think that we should argue on these grounds... this is where it is handy to have data that will either prove or disprove the claim that "bad data = bad router". My $0.01 (only $0.01 because I'm at the edge), Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <[email protected]> To: [email protected] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[email protected]>, or you are likely to be blocked.
|