- lir-wg - mailman.ripe.net

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

Re: Multihoming - Resilience or Independence
by SchmitzJo＠aol.com 11 Oct '01

11 Oct '01

Dear Nurani, you wrote: > Rather than the RIRs giving advise on these operational matters, we think > it would be appropriate and helpful if these recommendations would come > from the ISP community. I fully support this statement. > A few BCPs or guideline documents would be useful to point these > requesters to. Could this be an initiative for the routing-wg? I had some general input on this in the past months. I am also aware that there are some very early drafts which had not been circulated widely. interesting in various ways ;-) I have no objections against discussing this in the Routing WG, even with the initial modest goal of collecting the individual points of view (which would form a suitable basis to further develop the ideas presented). Nonetheless, it is obvious that within the Routing WG the focus is on technical issues only. Anybody who is interested in summarizing and presenting his/hers ideas is welcome to do so. I can easily reserve some time for that in the next Routing WG session in January to give this a focus. Just step up... :-) Thanks Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

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

11 Oct '01

That is very common procedure. In doing that at least 2 entries will be in the global routing table. And that's exactly the intension of the customer so in case one path failed(thus withdrwan properly ) the other path will kick in. If the provider B lost both connections to the customer and provider A then it lost the FULL correct routing table then this is not the issue of filtering /20 anymore. If provider B configure their BGP sessions right then it should withdraw all the routes from provider A and the customer. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki@hp.com] > Sent: Thursday, October 11, 2001 2:12 PM > To: Lu, Ping; lir-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > Hi, > The customer will of course use 2 ISP - as requested. He will > use addresses > coming from a single PA block advertised by two providers. Of > course you > need to ensure 100% up connection between border routers. If > connection > between border routers is down one of them has to stop > advertising PA block. > Otherwise you have problem with return traffic. Imagine > provider B lost > connection to both customer and provider A. If B is still > advertising common > block some ASes may decide to reach customer over B, but B > cannot reach > customer network... In order to deliver proposed service > providers A and B > have to be connected with redundant network, which is quite common. > > Vicious circle (sp) as I see it: > *Providers want small routing tables > *Customers 100% up service so they as for resilience > *Providers usually have single POP in area > *Customers go BGP creating problem for community (table grows) and > themselves (BGP expert costs) > > Solution: > Providers enter into cooperation so they can advertise > customer addresses > over 2 independent BGP speakers. This idea is not very different from > existing aggregation. Specific routing information is hidden > in a group of > ASes instead of single AS. Of course you need some > administrative effort > (e.g. consistent billing) but from technical point of view it seems > feasible. I may be wrong, it won't be for the first time ;-) > Regards, > Jacek > > > -----Original Message----- > From: Lu, Ping [mailto:PLu@cw.net] > Sent: Thursday, October 11, 2001 5:02 PM > To: 'BLOCKI,JACEK (HP-Poland,ex1)'; lir-wg(a)ripe.net; > routing-wg(a)ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > > > -----Original Message----- > > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki@hp.com] > > Sent: Wednesday, October 10, 2001 1:10 PM > > To: lir-wg(a)ripe.net; routing-wg(a)ripe.net > > Subject: RE: Multihoming - Resilience or Independence > > > > > > 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--/ > > > > That's the problem. When customer want to be muitl-homed you > can't tell them > to use which ISP ? If the original prefix are not in the CIDR > with the other > ISP > then the customer have to change all their IP address. If > they don't then > the second > ISP have to leak the original prefix into global routing table. > > The question is how do you convince your customer to change > all their IP > addresses to > have a second link without the risk of losing its business ? > > > > 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 > > > > It is a good idea but not easy to implement under the > pressure of making > revenue. > > > 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 BLOCKI,JACEK (HP-Poland,ex1) 11 Oct '01

11 Oct '01

Hi, The customer will of course use 2 ISP - as requested. He will use addresses coming from a single PA block advertised by two providers. Of course you need to ensure 100% up connection between border routers. If connection between border routers is down one of them has to stop advertising PA block. Otherwise you have problem with return traffic. Imagine provider B lost connection to both customer and provider A. If B is still advertising common block some ASes may decide to reach customer over B, but B cannot reach customer network... In order to deliver proposed service providers A and B have to be connected with redundant network, which is quite common. Vicious circle (sp) as I see it: *Providers want small routing tables *Customers 100% up service so they as for resilience *Providers usually have single POP in area *Customers go BGP creating problem for community (table grows) and themselves (BGP expert costs) Solution: Providers enter into cooperation so they can advertise customer addresses over 2 independent BGP speakers. This idea is not very different from existing aggregation. Specific routing information is hidden in a group of ASes instead of single AS. Of course you need some administrative effort (e.g. consistent billing) but from technical point of view it seems feasible. I may be wrong, it won't be for the first time ;-) Regards, Jacek -----Original Message----- From: Lu, Ping [mailto:PLu@cw.net] Sent: Thursday, October 11, 2001 5:02 PM To: 'BLOCKI,JACEK (HP-Poland,ex1)'; lir-wg(a)ripe.net; routing-wg(a)ripe.net Subject: RE: Multihoming - Resilience or Independence > -----Original Message----- > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki@hp.com] > Sent: Wednesday, October 10, 2001 1:10 PM > To: lir-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > 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--/ > That's the problem. When customer want to be muitl-homed you can't tell them to use which ISP ? If the original prefix are not in the CIDR with the other ISP then the customer have to change all their IP address. If they don't then the second ISP have to leak the original prefix into global routing table. The question is how do you convince your customer to change all their IP addresses to have a second link without the risk of losing its business ? > 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 > It is a good idea but not easy to implement under the pressure of making revenue. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

ANNOUNCEMENT: Public Release of Asused
by Manuel Valente 11 Oct '01

11 Oct '01

Greetings, The RIPE NCC is pleased to announce the release of asused version 3.64. Asused is a tool to check and summarise address space registered in the RIPE database. For a given list of allocations the tool prints various information concerning the allocations and the assignments they contain. The software is written in Perl and uses several Perl modules. Please grab it from: ftp://ftp.ripe.net/tools/asused-3.64.tar.gz ChangeLog for version 3.64: 3.64 Wed Oct 10 14:22:24 2001 * Fixed recognition of inetnum objects with <tab> sign in the range. * Broken dates in changed: field now handled properly, without exiting the program. * Fixed failure in case of registry with no allocations. * Recognize mixed case status: fields. 3.63 Tue Aug 21 13:52:04 2001 * Fixed netname handling according to the RIPE223 - now, case doesn't matter, so netnames with different letter-case still match. * There have been reports about Makefile failure with Perl 5.002, due changed format in the output of the MakeMaker. This is fixed now, by using our own stubs in the Makefile.PL. * Couple of strange inetnum objects were found in the DB, namely - 192.0.0.0 - 192.255.255.255, which broke proper recognition of the allocation. Now they are recognized by asused. Still, it's possible that there are other similar objects in DB. Note: Versions 3.61 and 3.62 were not publicly released. -- Manuel Valente - Software Manager - RIPE NCC

1 0

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

11 Oct '01

> -----Original Message----- > From: BLOCKI,JACEK (HP-Poland,ex1) [mailto:jacek_blocki@hp.com] > Sent: Wednesday, October 10, 2001 1:10 PM > To: lir-wg(a)ripe.net; routing-wg(a)ripe.net > Subject: RE: Multihoming - Resilience or Independence > > > 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--/ > That's the problem. When customer want to be muitl-homed you can't tell them to use which ISP ? If the original prefix are not in the CIDR with the other ISP then the customer have to change all their IP address. If they don't then the second ISP have to leak the original prefix into global routing table. The question is how do you convince your customer to change all their IP addresses to have a second link without the risk of losing its business ? > 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 > It is a good idea but not easy to implement under the pressure of making revenue. 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 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

changed attribute proposal and not only
by Andrei Robachevsky 11 Oct '01

11 Oct '01

Dear Colleagues, Please find enclosed the proposal of modification of the changed attribute that was presented at the RIPE-40 meeting in Prague. However, another proposal (or rather idea) came up in light of recent discussions regarding timestamping and cleanup procedures in the RIPE Database. Let me present you this idea first. As was pointed by the two proposals there is a need to store and display status information about an object in the database, such as last update time, number of references, etc. At the same time in order to be reliable this information should be automatically generated by the database software and be outside users' control. Regarding "changed attribute" proposal people felt that this changes some of the basic principles of the RIPE Database. Recent Ulf's proposal makes things even worse since it requires that modification to an object may be caused by an update of another object. But in fact these attributes/facilities do not represent an object, but rather status information about the object. Extending Ulf's analogy with the Unix FS, they are part of the inode, not the data blocks. So status information (object metadata) may be stored and displayed separately from the object itself by, say, using a flag. Much like we display the contents using cat, but status using ls. And this information will be used for cleanup procedure, reliable timestamping, etc. This will not affect any object template, preserve users' data and add flexibility to the database. Something like this: $ whois -q meta RC1234-RIPE ... person: Referenced Contact nic-hdl: RC1234-RIPE ... changed: refcon(a)somedom.dom 20011005 source: RIPE %metainfo: RC1234-RIPE %update-time: 2001-10-05 16:50:07 %ref-time: 2001-10-06 09:17:33 %ref-count: 3 Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0