""Nigel Taylor"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Pointing back to W B. Norton's "Internet Service Providers and > Peering" and "The Art of Peering" he makes some suggestions that > cold-potato routing could be used to circumvent sub-optimal routing. > There are a number of ways that cold-poato routing could be achieved, > but as it relates to this discussion, wouldn't controlled > de-aggregated routes and the use of MEDs provide another mechnisim > to achieving this objective? Is this a case of the "ends dosen't > justify the mean"?.
There are many ways to fix all sorts of inter-domain routing scenarios. However, do you want to accept MED's from all providers in the same way? How about with your customers? Should peers be different than transit providers and customers? Most people don't listen to MED's because you can't trust the other organization to give you the correct information. Many companies take advantage of certain scenarios like the ones I described in emails way back (they are also described in Huitema and J.Scott Marcus), creating the whole content providers vs. access providers situations. In my mind, I have found somewhat of a compromise on the matter of inter-domain routing. I feel that, yes, de-aggregation is bad. Yes, cold potato routing can have some advantages. And, yes, MED's can be a good thing. In many situations you can change out MED's for as-path prepends, and vice-versa. I like using MED's, however (it is the BGP metric after all). If I were to define a strategy for implementation, it would be somewhat like the following: local-pref is a hammer: use it only as you would a hammer. if you want to ignore all the hard work that everybody else on the Internet is doing for traffic engineering, by all means use it. I say make a global setting of like 200 local-pref for everything, that way you can still lower it when you need to. Leave as-path alone, maybe even ignore it. The way people are prepending now is sort of stupid. Who needs 40-something prepends? That's just routing table pollution in my mind. Use MED's for controlling both inbound and outbound. By setting inbound MED's (to control the flow of outbound traffic), you can take into account the as-path if you want to. If you use local-pref for this same purpose, you can't. If you use as-path, you are stuck with just that tool. Using MED's you still have a full toolbox. The above strategy is defined in RFC 3272 and it does make sense. To finally answer your question, control of inbound flow of traffic... well it's sort of tricky. You can go with a policy of no de-aggregation. That's a good policy. If you already have a large number of prefixes and can't consolidate them, then you obviously don't want to de-agg them even further. If that's your situation, then you should probably build "regional peering routes" where you try to separate the aggregates by location and only announce them in a few places, not all over the place. Large aggregates and MED's is optimal, but there may be times when nobody's listening (to your MED's, your phone calls, your emails, hehehe) so in that situation, you may want to either increase your internal bandwidth to support the sub-optimal traffic or possibly announce the more-specifics (de-aggregate) but with NO-EXPORT (so it doesn't go past one provider). You can also use dynamic NAT to influence inbound, which should also be looked into. Also, note that some people "Just don't care about inbound because other people can override your engineering with local-pref anyways" and the same type of people often use the RFC 1958 (and others) argument, "Be strict when sending and tolerant when receiving". Be sure to understand all the arguments before choosing the right strategy for your organization. -dre Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=51460&t=51448 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
