- routing-wg - mailman.ripe.net

Draft minutes routing wg - RIPE 40
by Joao Luis Silva Damas 18 Oct '01

18 Oct '01

Dear all, please find attached the draft minutes of the routing wg session during the recent RIPE 40 meeeting in Prague. Many thanks to Matthew Williams, from the RIPE NCC, who quickly and thoroughly produced the notes. Best Regards, Joao Damas RIPE NCC

1 1

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

16 Oct '01

At 01:18 PM 10/10/01 +0200, BLOCKI,JACEK \(HP-Poland,ex1\) wrote: >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? Because extending your IGP to customer sites is a bit silly, bloating your IGP and inducing a potential for misinformation from an external domain. You really don't want to do this. It may work well in small networks but certainly not in large players. Tony

3 2

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

16 Oct '01

> > > 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 ). > > I am not sure I am following you here. Are you saying that we should > re-adress customers so that we get larger blocks of PA space > to give to > mulithomed customers? > > I think that re-addressing is pretty hard to do in any larger scale, > although that would certanly help some other issues. > That's why filtering /20 only without re-aligning the holes in the block won't work. In the end /20 make the routing table looks pretty but they are black-holing lots of traffic. As we all agree that re-assign address is NOT practical at all thus just filtering /20 block is not a good solution. > another good start would be to start reclaiming space that > has been handed > out from various ISPs old B-space and later taken with the customer. I > know a few operators that have done that (including us to > some extent), > and it's a rather demanding task but will help the operators > and reudce > the routing table as well. > > - kurtis - > I am with you here. Starting from the beginning is much better than asking them to change later. 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 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: 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..... :-)

11 19

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.

16 45