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

RE: Multihoming - Resilience or Independence
by Tony Barber 15 Oct '01

15 Oct '01

At 07:09 PM 10/10/01 +0200, BLOCKI,JACEK \(HP-Poland,ex1\) wrote: > >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 ^^^^^^^^^^^^^^^^^^^^ And there is the first problem. Tony

1 0

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

15 Oct '01

> -----Original Message----- > From: Aled Morris [mailto:aledm@qix.co.uk] > Sent: Friday, October 12, 2001 8:59 AM > To: Stephane Bortzmeyer > Cc: Nipper, Arnold; Dave Pratt; lir-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: Re: Multihoming - Resilience or Independence > > > On Thu, 11 Oct 2001, Stephane Bortzmeyer wrote: > > >Or, said in an other way: RIPE policies make very difficult > to be multihomed, > >therefore people in RIPEland take a lot of time to explain > that multihoming is > >bad. > > RIPE doesn't make up the policies - the members make the policies. > > RIPE didn't invent IP either, nor did they have a say in the design of > router architecture, nor in the pricing of RAM chips. > > Multihoming which relies on long prefixes being carried in the default > free zone, and/or more AS numbers, simply doesn't scale. That isn't a > policy matter, it's simple math. > > Which policy do you think should be changed in order to "solve" the > multihoming problem? > > Aled > -- > QiX Limited > I do think it is policy related. For example, Customer Alpha want to be multi-homed from the very beginning so he requests a /24 block from RIPE. What RIPE should do is asking which TWO ISPs Alpha is going to use. Let's say the policy requires Alpha to be under the CIDR block between these two ISPs according to a table like: UUnet & CW : 123.45.32.0/20 UUnet & Quest : 123.45.64.0/20 Ebone & Sprint: 123.45.96.0/20 ... and IX range: 123.45.128.0/20 Some note about this example: 1. The major ISP can always filter these range at /20 without worring the holes inside them. 2. It won't need to cover 100% of multi-homed customer but if major ISPs are covered it will reduce the routing table dramatically. 3. For IX people(more than 2 ISPs), it won't be aggregate possible but by allocating them in the same range we might find some small blocks (/23 /22 are highly possible ) that are aggregate possible. This is just one example what RIPE CAN do. And because it involves different ISPs it certainly looks like a community affair that belongs to the RIR level. 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 15 Oct '01

15 Oct '01

> > > assume that I > > > am cost concious resdient with a sattelite down-link (yupp, > > > they exist), > > > and a DSL line and a Cable link. Should I not be allowed > the same easy > > > choice of up-link as the corporate world? > > > > > > Let's then assume that I have my home on VoIP only so NAT is > > > out. Do I get > > > my own AS-number and PA space then? > > > > > > > You are using three different IP addresses that are > dynamically (OK. If you > > insist statically) assigned to three different links. But > how can I reach > > your web server ? > > This is different from the corporate world to have the same > IP coming in > > from different links. > > If I only have three addresses I need some form of NAT on my > home network, > and that will brak my services as well as block the > Web-server, just as > point out. So I need a routable block. > OK. There are two different requirements here. One is people just want to connect to Internet and have different links for back-up thus no-need for static IP. The problem will be the SOHO customers running application that needs static IP address. Assume they uses /28 then it will be a big problem for the up-stream to leak them into the global routing table. By just filtering out /28 won't solve the problem. But I think it is a little bit easier to make them to be reassigned to the aggregate block with their back-up link provider, don't you think ? This way, we can have the cake and eat it too. > > > > 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. > > > > In this SOHO situation you don't need a seperate entry in the > > global routing table. Also the point is two links (phone line won't > > die the same time as the satellite, will they ?) > > No, but in order to use this Sat uplink I need to have > globally routable > address block. Which will pollut the routigtable. So in my extream > example, we would end up with a address block per SOHO user. > > - kurtis - > My point is still you can have these customers' business and making sure they are ASSIGNED (by you) on the aggregate block so the other ISP can aggregate them. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

Re: [hostmaster-staff] Re: MIR proposal / reservation revisited?
by Wilfried Woeber, UniVie/ACOnet 15 Oct '01

15 Oct '01

To me, this rather sounds like a case for revisiting reservation, rather than arguing for a new registry type/structure/rules. Am I missing something? Wilfried. ______________________________________________________________________ Date: Fri, 28 Sep 2001 13:58:24 +0200 From: Gert Doering <gert(a)space.net> To: Adrian Bool <aid(a)vianw.net> CC: lir-wg(a)ripe.net Subject: Re: [hostmaster-staff] Re: MIR proposal Hi, On Fri, Sep 28, 2001 at 12:05:41PM +0100, Adrian Bool wrote: > I feel that international networks require the ability to operate according > to the same rules as RIPE - just working on a smaller scale - as another > level down in the hierarchy. Not only "international networks", but also national ones that have a hierarchical structure of re-sellers. > i.e We should should be able to apply for more IP space once we have > sub-allocated 80% of our allocation to our in-country networks - natuarally > in a responsible manner, according to the same rules that an RIR would > allocate space to these in-country networks. Sure. 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

6 9

RE: more specific routes in today reality
by Hallgren, Michael 15 Oct '01

15 Oct '01

> > > If it is a outage and you are running BGP you will need to > wait for your > router to converge. In worst case you will be dragged into the routing > problems. However, I agree with Randy that 90% of outages are due to > local-tail problems. > > I agree that two links to two operators are more reliable, > but the real > questions are if they are enough MORE reliable to justify the extra > routes, and if so how do we implement this? And this should > be a general > solution all the way down to the residential users... > OK. I went backstreams up the thread. Sure, since we're talking about "all the way down to the residential users..." > I am not conviced that having multiple upstreams for entrprises, SOHO, > residentials or even small ISPs are worth it. OK mh > > - kurtis - > >

1 0

RE: more specific routes in today reality
by Hallgren, Michael 15 Oct '01

15 Oct '01

> > > This however, does not mean though that multiple uplinks to > more than one > > provider gives you more security than mulitple uplinks to one. > > I completely disagree with you. > So do I (at least in this little part of the thread, which I haven't had the opportunity to follow at all length). For example, a provider-wide routing (or performance, or whatever) problem would be your problem if homed only to that one provider. > Multiple links may have failure modes in addition to and > identical to some > of the failure modes of a single connection, but multiple > links also removes > a complete calls of failure modes associated with a single connection. > > This is a pretty fundemental tenet of communications systems > in general as > is not limited to IP. > mh > Peter > >

3 3

Multihoming - Resilience or Independence
by Dave Pratt 15 Oct '01

15 Oct '01

Hiya All, There has recently been a long thread, getting rather technical, about how best to achieve multihoming with the best resilience, etc. However, I feel there is another perhaps stronger argument as to why a customer wishes to obtain, keep and announce his own prefix(es): Bandwidth costs are reducing rapidly and customers do not wish to be tied to a single provider because of the pain associated with renumbering their address space. Going through the hoops to achieve multihoming may not improve resilience but, especially if they are "slow" setting up the second connection, the bandwidth can be cheaper as the customer can change ISPs much more easily if the price stays too high. It would be interesting to know which fraction of the "unclean" address space is singly connected. Our customer base may be unusual, but over 50% would not suprise me. Cheers Dave ps. Do not let any customers see this email..... :-)

24 48

more specific routes in today reality
by Vladimir A. Jakovenko 15 Oct '01

15 Oct '01

Hello. My apologies if mentioned below issues have already been discussed. If they were - pls just point me to the location where I can find more on that subject. According to my observations at least since this summer the RIPE NCC staff promotes usage of more specific PA routes (originated by more than one AS) for multihomed customers opposite to the "classic" scheme with PI addresses (or new enterpise LIR ;-). In this situation we are going to expect increase of ammount of: 1. Routes with more than one origin. 2. Less specific routes within existing more specific. Actual (ripe-185) document of "IPv4 and ASN Policies in the RIPE NCC Service Region" and working draft (on http://www.ripe.net/rs/ipv4policy.html) refer to rfc1930 which contains section 7 - "One prefix, one origin AS": Generally, a prefix can should belong to only one AS. This is a direct consequence of the fact that at each point in the Internet there can be exactly one routing policy for traffic destined to each prefix. In the case of an prefix which is used in neighbor peering between two ASes, a conscious decision should be made as to which AS this prefix actually resides in. With the introduction of aggregation it should be noted that a prefix may be represented as residing in more than one AS, however, this is very much the exception rather than the rule. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ According to measurements on RIPE DB dump on Oct 4 there were about 17% of prefixes with more than on origin AS. It isn't just RIPE specific - measurements from other IRRs are close. Announcement of less specific routes within existent more specific route (lets assume that there is no bgp routing process misconfiguration - both, less and more specific, routes have route objects) clashes with an aggregation issues promoted in many RIPE documents. In 1990th such announces would be treated as typical "bad practice" but now they are more and more close to "regular practice". Just in fact there is still some network operators, whose routing policy (in the part of BGP peers filtering) had been formed by influence of rfc1930 and other aggregation issues, states something like that: "if peer announces more specific routes within existent less specific route, all more specific routes will be rejected unless peer explicity asks to accept it". Unfortunately it is difficult to dispute such policy unactuality without appropriate documents. Is it possible at least "to legalize" applicability of more specific routes with more than one origin for multihoming purposes in ripe-185 successor? On my opinnion it would be also good to: 1. Create new RIPE document which would describe usage of more specific routes with multiple origins for multihoming, including all pros and cons of such technique. 2. Extend ripe-127 successor with references to new document mentioned above or (why not?) integrate both of them in one document. 3. Extend ripe-211 successor with something like that: "Due to tendency of increasing number of small blocks (smaller than the default allocation size) of PI or PA (more specific multihoming, load balancing, etc) addresses network operators taking routing decisions based on prefix length are recommended to accept and route longer (up to /24) prefixes with valid route objects." -- Regards, Vladimir.

17 51

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

15 Oct '01

> > Well, this can ofcourse then be taken to the extreme. Let's > assume that I > am cost concious resdient with a sattelite down-link (yupp, > they exist), > and a DSL line and a Cable link. Should I not be allowed the same easy > choice of up-link as the corporate world? > > Let's then assume that I have my home on VoIP only so NAT is > out. Do I get > my own AS-number and PA space then? > You are using three different IP addresses that are dynamically (OK. If you insist statically) assigned to three different links. But how can I reach your web server ? This is different from the corporate world to have the same IP coming in from different links. > I think we all agree that the current routing model is broken and no > longer does what we would expect it to do. However, I think > Randy is right > in that this will take at least 5 years to redo though. Just look at > addressing / CIDR /IPv6. That has taken what, 8 years? At > least, and we > are not really near any deployment. A CIDR like solution of this is > simple. Filter. > Maybe you are willing to black-hole some /24 block like eBay ? > > 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. In this SOHO situation you don't need a seperate entry in the global routing table. Also the point is two links (phone line won't die the same time as the satellite, will they ?) > > IXes are a bad example as just beeing present won't do. You > need to get > peers as well. And if you are a company my guess is that most > providers > rather sell you bandwidth than peer. This is going backward to ask company to have full mesh among all the ISPs ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

2 1

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

15 Oct '01

It is odd that I have to agree with you on "customer do need multiple links to different ISPs" but I hope it is not because CW carries other ISP's non-CIDRable prefixes to let you think "CW less" about us. The point is we will aggregate other ISP's prefixes if they are CIDR able. Most of the case are there are holes in the range so CIDR is out-of-question. While the other camp insist to filter out any routes more specific than /20. They are doing nothing to re-allocate their PA assigned to multi-homed customers so CW can CIDR them into /20. The funny thing is the solution are controlled by the other camp but they are all talk but no action. (Or trying to tell you multi-homed is a bad idea because they can't deal with the routing table ). Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Peter Galbavy [mailto:peter.galbavy@knowtion.net] > Sent: Thursday, October 11, 2001 4:17 AM > To: Kurt Erik Lindqvist KPNQwest; Nipper, Arnold > Cc: lir-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: Re: Multihoming - Resilience or Independence > > > > > the basic issue is that multi-homing is *the demand*. And > it's not the > ISP > > > who has to evaluate whether it's the right one but the > *customer*. We > live > > > in a customer - driven world. Money makes the world go round, not > techies. > > > > Is that really what the customer want? Or do they actually > want resilience > > and redundancy? And for that there are other ways... > > I have been watching this thread for a while now, and I > finally cannot help > but stick my oar in. > > There are two very clearly defined camps here; one the > 'technical' camp that > says 'we have many ways of making it work' or 'this is the > only way it will > work' and the other camp is the 'commercial' saying either > 'the customer > does not trust just one ISP' or 'I don't care how it works, > but it must > work'. > > Now, to add just another opinion to the thread, which is > really not that > different to some other but may possibly offer something new; > > In my line of work I have set-up 4 LIRs in the past two years > for companies > that have had either had bad experiences with their ISPs > (usually more than > one serially) or some have had to do all 'reasonable' things > to ensure good, > reliable connectivity for either contractual or due-diligence reasons. > > Regardless of how good an ISP is *now*, there will come a > time when they are > sold, bought, merge or go bust that causes change. My > personal bugbear was > INS. Great in the early days, but within days of > Clueless&Witless buying > them, the whole thing started to come apart. This is not > isolated, and they > are not the only ones at all. > > Also, especially in Europe, ISPs tend to be reliant on 3rd > party local-loop > carriers, even when we are talking about data-centre / > co-location delivery > of services. In the UK, all ISPs exclude 3rd party links from > SLAs. Right. > Good one. > > Trying to solve the problem of people not trusting ISPs by > changing the > technology to ensure that people *must* trust one ISP (IPv6 > IMHO is just > such a technology) is not a very customer friendly attitude. > It does not > work and will not work. > > In every other line of business, it is quite normal to buy > your product or > service from two suppliers, telecoms and Internet are the only real > exceptions. You could also discount other utilities, but > there is an issue > of delivery there that precludes efficient and real > competition, so no more > there please. As the Internet becomes a true necessity for > business, supply > will more and more be selected like any other service, and the same > contingencies will be made. > > So, IMHO, please stop trying to 'solve' the problem by > pretending that you > or any other ISP is reliable, civil and economically viable > and stop trying > to 'solve' the problem by mandating technology solutions that > enforce this > goal. It will not work. > > Peter > > >

2 1