October 2001 - routing-wg - mailman.ripe.net

Re: more specific routes in today reality
by Vladimir A. Jakovenko 11 Oct '01

11 Oct '01

On Wed, Oct 10, 2001 at 10:08:09PM +0200, Kurt Erik Lindqvist KPNQwest wrote: > >> >If a provider can't supply the above to a customer that really have the >> >need for multiple connections and is willing to pay for it, I would change >> >provider anyay. > >> Also pls don't forget about some geographical regions, covered by RIPE, where >> mostly impossible to build even one last mile channel to nearest "Tier-1 bla >> bla bla" provider for non-huge money. > >And in what way would my own AS number and PA space give me more last-mile >providers? Don't forget about cheap sattelite channels :-) Lets imagine situation - customer in a country, where all terrastical long- range channels are controlled by one big pro-government PTT. There isn't POPs of any of "Tier-1 bla bla bla" providers. All of them can be reached only by expensive long-rage terrastical or (less expensive) sattelite channel. In this situation the most popular solution for local customer, who needs reliable and cheap IP uplink and high speed access to regional Internet resources, is to build two channels to local ISPs (not so reliable, but much more cheaper than even one external uplink) and to local IX. -- Regards, Vladimir.

2 1

Re: Multihoming - Resilience or Independence
by Gert Doering 11 Oct '01

11 Oct '01

Hi, On Wed, Oct 10, 2001 at 04:07:24PM +0100, Stephen Burley wrote: > Er you can not reserve space so you can not do this and if you give them > enough space to garutee routing we are talking a /20 then that is LIR space > size...hhmmm. Back into MIR land :-) - but I think the main problem with this proposal is "what happens if the ISPs in question stop liking each other and this breaks apart" - which would not be the first time. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

4 3

RE: Multihoming - Resilience or Independence
by Boyan Krosnov 11 Oct '01

11 Oct '01

> Your prefixes (let's say /24) has to be announced by two ISPs > so the packets > will come back to you. If ISP A's link failed then that /24 > with ISP A in > the > ASPATH will be withdrawn. And ISP B's /24 will become active. > So in the > global > routing table there will be TWO /24 with different ASPATH. > > If this /24 is in ISP A's PA space then it saves one but the > one from ISP > B's one > NEEDs to be in the global routing table. Either I didn't understand you right, or you were wrong. It does not save a route in the DFZ. Let's say the customer gets A/24 out of proider A's A/17 prefix. B has to announce A/24 to the internet along with it's current prefixes. A has to announce A/17 AND A/24 to the internet. If A advertises A/17 only all the traffic for A/24 will go through B (because of the longest match rule), and I think that's not what that customer wants. So Being multihomed to two ASs with NAT or two addreses on each host does not create an extra route in the DFZ. Being multihomed to a single AS does not create an extra route in the DFZ. Being multihomed to two ASs (It doesn't matter PA or PI, separate AS or anounced by the two ASs. Prefix out of PA, separate AS is generally recognised to be the better technical solution.) does create at least 1 extra prefix and 2 extra as-paths in the DFZ. These are the facts about growth of the DFZ routing table caused by multihoming as I see them. There are of course other reasons for the growth like providers advertising 14 separate /24s when they can agregate it to /20 because "We were trying to do some input channel load balacing and have left this anouncements for months because our administrator does not have the time to deal with this thing, he/she has more important work to do". Now it's time to think how we can make people prefer the first 2 possibilities over the third. We've had enough of technical discussion I think. Regards, Boyan Krosnov, CCNP Network Administrator Lirex Net phone: +359-2-91815

1 0

Re: more specific routes in today reality
by Vladimir A. Jakovenko 11 Oct '01

11 Oct '01

On Wed, Oct 10, 2001 at 10:04:22PM +0200, Havard Eidnes wrote: >> On Tue, Oct 09, 2001 at 07:19:35AM -0700, Randy Bush wrote: >> >> We are talking about different types of multihoming. I mean simple >> >> multihoming situation when all multihomed customer's needs in routing are >> >> covered by they upstream providers routing policies. >> > ^ >> >note the use of plural above. now read rfc 1930. >> >> Randy, rfc1930 consists of 563 lines. I suppose you are talking about: > >I think it's far simpler than that. Quoting (and guessing): > > To rephrase succinctly: > > An AS is a connected group of one or more IP prefixes run by one > or more network operators which has a SINGLE and CLEARLY DEFINED > routing policy. > >I.e. a provider (an AS) can only have a single routing policy. > >However, I also sense some language confusion above, and that what >you're trying to say is actually > > "a simple multihoming situation where any one of the multiple > uptstream providers' routing policy would be adequate for the client > in question" Yes. >However, I don't agree that it's a good idea to willfully cause the >number of routes originated from different source ASes to increase. If we are talking about theory -- agree, it's not a good idea. >Furthermore, the routing complexity doesn't really rise as a function >of the number of ASes -- it's rather the number of prefixes or perhaps >rather the number of unique paths available which causes the entropy >increase in the default-free zone which scares some of us. In the >bigger picture it doesn't really make any difference whether the more- >specific route comes from PI or PA space or whether the route is >consistently originated from a new AS or (shudder) separately from the >two (or more) upstream providers; the entrypy increase in the default- >free zone would be the same either way. I agree with mentioned above statements about stability in "default-free zone". But (AFAIK) according to measurements and statistics amount of free AS-numbers are going to overflow more rapidly than free IPv4 address space. I believe that sometimes AS-numbers space will be extended, but (AFAIK) it requires global replacement of BGP-routing sotware. In this situation ?RIRs? are looking for ?temporary? solution how to decrease rate of AS-numbers allocation. One of such solutions (IMHO) is "more specific routes multihoming". I don't have exact information about other RIRs, but RIPE NCC already _promotes_ such solution. >From network operator (whose customers sometimes requires assistance to achieve multihoming) point of view adoption of such multihoming method, promoted by RIR, (sometimes) requires changes in routing policies and in what we are calling as "best practice". IMHO without new documents, recomendations, etc new multihoming method is (mostly) useless. Original posting was concerned in: - are there any already published/draft documents? - are there any plans to create such documents? If there aren't, and if community aren't going to accept such technology (from our discussion it seems that now there isn't common opinnion), IMHO, RIR "snake the air to no purpose" - such technology is (generally) useless. -- Regards, Vladimir.

1 0

RE: Multihoming - Resilience or Independence
by BLOCKI,JACEK (HP-Poland,ex1) 10 Oct '01

10 Oct '01

Hi, It seems multihoming discussion is an example of vicious circle (sp): More specific routes result in larger routing table but we want those routes and small table... Let me suggest a blasphemy: CIDR being advertised from two ASes. They say it should be only one, but why? In my opinion there is nothing wrong in advertising CIDR from two ASes as long as you can guarantee each border router advertises CIDR only if it can reach it. Imagine the following construction: AS-A--\ +(OSPF) --(CIDR) AS-B--/ Each BGP speaker advertises CIDR if and only if it learned about it from OSPF. It can be done, if you don't know how I'll forward you a working example. Each border router generates a default router and injects it into OSPF. From technical point of view I see no reasons why it should not work. What you need is: * An agreement between ISPs * Change in procedure making such a union of ASes an officially blessed solution so nobody would dare to hinder cooperation with filters. * Optionally you may need a separate CIDR, since both ASes have to advertise same prefix. You need it if each ISP wants to have private customers in addition to shared ones. The customer has "an independent connection to two ISPs" which is the quest item. I see more commercial than technical problems with such a solution. However my expertise is limited and somebody can point drawbacks I cannot see. Feel free to burn me on a stake, that's the right way of treating a blasphemy ;-) Regards, Jacek

1 0

RE: Multihoming - Resilience or Independence
by Lu, Ping 10 Oct '01

10 Oct '01

> -----Original Message----- > From: Steven Bakker [mailto:steven@icoe.att.com] > Sent: Wednesday, October 10, 2001 11:08 AM > To: Nipper, Arnold > Cc: Stephen Burley; Gert Doering; Dave Pratt; lir-wg(a)ripe.net; > routing-wg(a)ripe.net > Subject: Re: Multihoming - Resilience or Independence > > > On Wed, 2001-10-10 at 15:24, Nipper, Arnold wrote: > > Of course another prefix and another AS is added to the > routing table > > but thereby you are witdrawing at least more than two (both > prefs as well as > > AS). ==> table gets smaller. > > Your math is confusing... or maybe I'm misunderstanding the obvious. > Yes, multihoming adds another AS and (at least one) (longish) > prefix to > the routing table. But in your reasoning, which two prefixes > and one AS > are being withdrawn? If I resiliently multi-home to one ISP, > and I get > my address space from its block, I do not add any prefix or AS to the > (global) routing table. Even if I multi-home to two ISPs and > selectively NAT depending on the outgoing connection, I'll be NAT-ing > into the respective ISP's address space (which I presume is properly > aggregated), adding no prefix or AS. Your prefixes (let's say /24) has to be announced by two ISPs so the packets will come back to you. If ISP A's link failed then that /24 with ISP A in the ASPATH will be withdrawn. And ISP B's /24 will become active. So in the global routing table there will be TWO /24 with different ASPATH. If this /24 is in ISP A's PA space then it saves one but the one from ISP B's one NEEDs to be in the global routing table. The worse case: ISP A only announces aggregate block even if the link failed then the traffic will still go thru ISP A then get dropped. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

Re: Multihoming - Resilience or Independence
by Steven Bakker 10 Oct '01

10 Oct '01

On Wed, 2001-10-10 at 17:34, Peter Galbavy wrote: > > space. The larger the prefix, the larger the chance of some network > > operator out there filtering it to oblivion. > > Sorry to be picky, but I am sure you meant either 'the longer the prefix' or > 'the smaller the prefix' ? Sorry, yes, longer prefix, i.e., "more specific". Steven

1 0

RE: Multihoming - Resilience or Independence
by BLOCKI,JACEK (HP-Poland,ex1) 10 Oct '01

10 Oct '01

Hi, Decisions are based on both science and superstition. In my opinion requests to connect to "two independent ISPs" result mostly from superstition. BGP routing is not particularly good at servicing resilient links. If an access link to ISP fails it takes some time before routing reconfigures, we don't like route flaps do we?. In my opinion OSPF + 2 access links to 2 POPs of single ISP would do the you much better. I wonder why virtually nobody offers such a service? From my perspective an entity running LIR is responsible for both IP addressing and IP traffic shaping. An entity may wish to become a LIR for number of business reasons. RIR should not verify validity of those reasons, however RIR should verify if to-be LIR understand what he applies for. This may mean technical consultancy for free, but since RIPE is a non-profit organization raised membership fees have to be spent anyway ;-) Regards, Jacek

1 0

RE: more specific routes in today reality
by Lu, Ping 10 Oct '01

10 Oct '01

> > >> > >> Great! Now we have to collect routing policies from > thousands of small LIRs > >> while still have to deal with thousands of small prefixes. > > > So? There is no difference between thousands of PI prefixes and > > "thousands of small LIRs", except that the latter actually have to > > *pay* for what they cause. > > Right. Strong ACK on this. > So what do the small LIRs solve ? > >> And if the major ISPs stop listening to the more specfic > routes then even > >> using the address from PI space won't work (unless you are > big enough). > > > Yes. This is what it's all about. Small PI space really > hurts people. > > Yep. And therefore these "small" PI stuff should be cleaned > up. The User itself > can use it internally and could get a /24 routed from PA space. > > But it is really not the optimum solution, as it waste's ip > address space. And > we have enough RFC1918 space... > This is not enough but I am going to go with this solution. Then we will ask you to assign only aggregatable address( to a /20 of course) to your customer if they are going to use CW as a backup ISP. You will happily reassign their addresses once they got a link from CW, right ? If you don't then what ? CW will have to leak your /24 to the world but it is you causing it. On the other hand, if our customer ask you to be the backup ISP, we will ask them to change all their DNS records, all their host tables, all their static IP configs to change to the new aggregatable block. If they think this is too much hassle, we will advice them not to use your service because you don't accept /24 multi-homed customer. This sounds realistic enough ? > > Letting "the whole world" see a /16 (from the upstream) and > the direct > > peers a /24 (or whatever) means global routing will just > work fine (over > > the upstream's PA block) and and IX routing will also work just fine > > (using the more specific). > > right, but is it generally used ? > I see a lot of /24 out of the same block from a /16 announced > space globally > (AS5511 for example) > > Because it is not the solution to the real world, that's why people can only talk about it but not really to enforce it. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

RE: more specific routes in today reality
by Lu, Ping 10 Oct '01

10 Oct '01

> > > > Great! Now we have to collect routing policies from > thousands of small LIRs > > while still have to deal with thousands of small prefixes. > > So? There is no difference between thousands of PI prefixes and > "thousands of small LIRs", except that the latter actually have to > *pay* for what they cause. To syncronize between the major RIRs is already dufficult enough, to make sure thousands of small LIRs all have correct info is not worth the problem it is trying to solve. > > > > Now more and more major ISPs are filtering out routes from > other ISPs ( > > becuase we don't have > > transit agreements) so the multi-homed customer have to > have their own AS. > > No. This is an interesting arguments, but the fact that C&W > has problems > with some of their peers doesn't mean "the whole world has to drown in > multihomed ASes". Get your contracts right. > Maybe you will carry other ISP's transit routes and they can dump about several GB of traffic for you to pass thru. And you are asking ISP to spend tons of money to carry the traffic that other ISPs are making money of ? Compared to this solution I think multihomed ASes is more acceptable. > > And if the major ISPs stop listening to the more specfic > routes then even > > using the address from PI space won't work (unless you are > big enough). > > Yes. This is what it's all about. Small PI space really > hurts people. > The thing is any ISP can decide to only accept /20 and above and claim any routes beyond those are not important. The truth is the INTERNET is bandwidth oriented and business like IX and webhosting are high bandwidth but not prefixes hungry. But they are hurting because someone think they are not wasting IP addresses enough. So the advice is if for any reason you need a backup link from different ISPs you better claim a /20 even a /24 is enough. > > All these solutions kind of imply that if you can't have > /20 prefix then you > > can't be multi-homed. What happen if a customer want to > have an OC-48 > > multi-homed link but only use prefix < /20 (that happens to > the Internet > > Exchange people a lot ) ? > > So announce it to the internet exchange. Why does it have to > be visible > in the whole world? > > Letting "the whole world" see a /16 (from the upstream) and the direct > peers a /24 (or whatever) means global routing will just work > fine (over > the upstream's PA block) and and IX routing will also work just fine > (using the more specific). > > Bad example. > So if a end-user uses one ISP's /24 from their PA space and he want to divide 50-50 traffic with a second ISP then what ? The second ISP will say no /24 allowed so can you ask the first ISP to assign a /20 ? (Don't worry CW will happily accept your /24) Even worse example. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0