RE: [lir-wg] Discussion about RIPE-261
Kurt Erik Lindqvist wrote: Agreed. The flaws of IPv6 comes down to not solving the multihomign/routing scaling/world starvation problem. That is an IETF problem, and there is a WG for it.
For the record, and the following are verifiable _facts_: the IRTF and the IETF have been working on this problem for the last ten years. One of the Area Directors responsible for the multi6 WG has called it the "Titanic". By Kurtis' own account it is going to be 5 to 10 more years before they find a solution, if they do. The WG that Kurtis co-chairs has not even agreed to _requirements_ that were due two years ago; they are calling it recommendations now with zero proposals on the table. Anyone that wants to have a glimpse of what the IETF is going to do for them is encouraged to read Kurtis' own draft: http://www.ietf.org/internet-drafts/draft-kurtis-multihoming-longprefix- 00.txt Which basically says that we should allow /48 prefixes punched from PA space in the Global Routing Table. I am sure the educated reader that subscribes to this list will appreciate, especially smaller LIRs that can't afford a c12416 or M160 to hold a huge routing table. Michel.
On Tue, May 27, 2003 at 07:46:01AM -0700, Michel Py wrote: (i'm replying here as Kurtis is on this list)
Anyone that wants to have a glimpse of what the IETF is going to do for them is encouraged to read Kurtis' own draft: http://www.ietf.org/internet-drafts/draft-kurtis-multihoming-longprefix- 00.txt Which basically says that we should allow /48 prefixes punched from PA space in the Global Routing Table. I am sure the educated reader that
I don't think this is a workable solution. Because: * it doesn't actually solve the problem - in fact it gets worse as you de-aggregate PA space and force it throughout the Internet. I don't see the advantage of announcing PA /48s under other providers as oposed to giving people PI space, I see however problems in a future where /48s starts getting filtered and multihoming is silently broken. * it depends on what ASs 2 hops away from me do. If somewhere along the way someone summarizes my "main" provider's routes sudenly the chunk of Internet behind him will start using the more specific. Don't forget we're talking about selling service here and with this scenario I can't garantee my clients the connectivity I'm selling them will actually be used. * it makes it particularly hard to change providers quickly. By all means this is lock-in to the primary provider. Summing, I think this despite masking the problem in the short run it has enough problems of its own to not be adopted commercially. The document claims, "The third advantage of this model is that this mirrors existing operating practices in the IPv4 world.", not quite - if I allocate a /24 to a costumer they will not announce it to another provider. If they do, the other provider will most likely filter it based on whois/registrar database entries. This could probably be solved for the proposed scenario but it seems like a kludge. The document also mentions RPF - RPF is almost unworkable for multihomed situations where assymetric flow are common. Even in the case of multiple links to the same provider it may not work as traffic engineering will likely create assymetries.
subscribes to this list will appreciate, especially smaller LIRs that can't afford a c12416 or M160 to hold a huge routing table.
Other people have already mentioned on the list memory/cpu isn't an issue on this day and age. You definitly don't need a c12k to carry a full routing table today. cheers -- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
Anyone that wants to have a glimpse of what the IETF is going to do for them is encouraged to read Kurtis' own draft: http://www.ietf.org/internet-drafts/draft-kurtis-multihoming- longprefix- 00.txt Which basically says that we should allow /48 prefixes punched from PA space in the Global Routing Table. I am sure the educated reader that
I don't think this is a workable solution. Because: * it doesn't actually solve the problem - in fact it gets worse as you
Absolutely!
de-aggregate PA space and force it throughout the Internet. I don't see the advantage of announcing PA /48s under other providers as oposed to giving people PI space, I see however problems in a future where /48s starts getting filtered and multihoming is silently broken.
That is one possible scenario. The draft is written from the outset that I am currently more worried that we will never reach 1k routes of IPv6, and that this is a sign of no wider adoption. Trends from Gerts data are showing some improvement, but there is still quite a bit to go.
* it depends on what ASs 2 hops away from me do. If somewhere along the way someone summarizes my "main" provider's routes sudenly the chunk of Internet behind him will start using the more specific. Don't forget we're talking about selling service here and with this scenario I can't garantee my clients the connectivity I'm selling them will actually be used.
Agreed.
* it makes it particularly hard to change providers quickly. By all means this is lock-in to the primary provider.
Agreed.
Summing, I think this despite masking the problem in the short run it has enough problems of its own to not be adopted commercially.
Yes. But it's approach. Seriously I think that what will help us get out of the current dead-lock is a agreed path to a final solution. As I recently said on the multi6 list, I used to believe in a phased approach, but I have shifted and come to realize that the only thing that will work in the end is that we from the start work on the permanent solution. Otherwise we will keep adding patches forever.
The document claims, "The third advantage of this model is that this mirrors existing operating practices in the IPv4 world.", not quite - if I allocate a /24 to a costumer they will not announce it to another provider. If they do, the other provider will most likely filter it based on whois/registrar database entries. This could probably be solved for the proposed scenario but it seems like a kludge.
This is not true. This is done quite regularly. - kurtis -
Hi, On Tue, May 27, 2003 at 07:46:01AM -0700, Michel Py wrote:
Which basically says that we should allow /48 prefixes punched from PA space in the Global Routing Table. I am sure the educated reader that subscribes to this list will appreciate, especially smaller LIRs that can't afford a c12416 or M160 to hold a huge routing table.
While I'm not sure whether it's "the perfect solution" (it isn't), I disagree with you on the "evilishness" of it. There are two dangers with it: - it might blow up the IPv6 table to the number of currently active IPv4 ASes. That would be about 15.000, and shouldn't hurt any decent router (yes, my 2503 will not like it, but then, I always knew that it's not a proper core router anymore). - if there really starts a big run to IPv6 multihoming, it will increase pressure on the AS allocation/conservation policy (and we'll eventually run out of 16 bit ASNs, which would hurt). Also, it might not even be sufficient - some companies might still want to be "really, really independent" and get their own address block. The *benefit* of "/48 multihoming" is that you can filter those routes if you don't want to see them - then your routers will send packets down the /32 road, and eventually hit a router that knows about the /48 (which is why I consider this approach superior to "everybody gets a independent prefix", which I can't properly aggregate). Which brings us back to "why I want ONE regional block per RIR" - that's why. (I do not think we need to discuss this - I won't be able to convince you, you won't be able to convince me - I just wanted to point out that there are more points of view to this) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, May 27, 2003 at 09:07:05PM +0200, Gert Doering wrote:
The *benefit* of "/48 multihoming" is that you can filter those routes if you don't want to see them - then your routers will send packets down the /32 road, and eventually hit a router that knows about the /48
This is exactly why providers will have an hard time selling this to customers. 'It may work, it might not, depends, you have no control and neither do we'. -- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
Hi, On Wed, May 28, 2003 at 10:45:44AM +0100, Carlos Morgado wrote:
On Tue, May 27, 2003 at 09:07:05PM +0200, Gert Doering wrote:
The *benefit* of "/48 multihoming" is that you can filter those routes if you don't want to see them - then your routers will send packets down the /32 road, and eventually hit a router that knows about the /48
This is exactly why providers will have an hard time selling this to customers. 'It may work, it might not, depends, you have no control and neither do we'.
One of us us confused about this, and it's not me. A /48 from an aggregate is MUCH MORE reliable than a /48 that has no fallback aggregate. If the latter is filtered (or flap-dampened, or "lost" due to bad as-path filters, or however), you're dead. If the former is lost, you can always send packets in the direction of the aggregate, and at a certain proximity, the /48 will be visible again and be used for proper packet delivery. Besides this, I hope you're not selling *any* service related to Internet connectivity to your customers with the claim that you have any control about things more than two AS hops away from your network...? Because you haven't. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Wed, May 28, 2003 at 01:07:08PM +0200, Gert Doering wrote:
Hi,
On Wed, May 28, 2003 at 10:45:44AM +0100, Carlos Morgado wrote:
On Tue, May 27, 2003 at 09:07:05PM +0200, Gert Doering wrote:
The *benefit* of "/48 multihoming" is that you can filter those routes if you don't want to see them - then your routers will send packets down the /32 road, and eventually hit a router that knows about the /48
This is exactly why providers will have an hard time selling this to customers. 'It may work, it might not, depends, you have no control and neither do we'.
One of us us confused about this, and it's not me.
A /48 from an aggregate is MUCH MORE reliable than a /48 that has no fallback aggregate. If the latter is filtered (or flap-dampened, or "lost" due to bad as-path filters, or however), you're dead. If the former is lost, you can always send packets in the direction of the aggregate, and at a certain proximity, the /48 will be visible again and be used for proper packet delivery.
Ok, I wasn't clear - I was strictly speaking about broken up PA space, not PA /48 vs. PI /48. You're right, if people per rule filter at /32 PI /48 is worse. If people per rule filter at /48 (which seems to be a requirement for this scheme to work) then /48 PI is better as it permits traffic engineering by the multihomed network. I mean, if you multihome and know for a fact at least half of the internet won't see one of your links (either because of filters or sumarization) what's the point ? If you do know /48s will indeed be visible by most of the internet using PI results in the same number of entries as PA, allows better control by the multihomed network and given a carefull allocation policy (now that IPv6 space is plenty and sparse) allows to grow the /48(s) into bigger allocations with minimal disruption.
Besides this, I hope you're not selling *any* service related to Internet connectivity to your customers with the claim that you have any control about things more than two AS hops away from your network...? Because you haven't.
No, I'm selling in technical good faith. I currently take steps to maximize the quality of the transit I sell considering the current IPv4 framework and current practices. In my opinion however with the /48 PA method I can't in good faith sell the same level of service. cheers -- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
it might blow up the IPv6 table to the number of currently active IPv4 ASes. That would be about 15.000, and shouldn't hurt any
...and currently that would be a good thing.
decent router (yes, my 2503 will not like it, but then, I always knew that it's not a proper core router anymore).
I've got a Linux kernel for it...;-)
- if there really starts a big run to IPv6 multihoming, it will increase pressure on the AS allocation/conservation policy (and we'll eventually run out of 16 bit ASNs, which would hurt).
We will run out of them anyway, but this might speed things up. But it would also help speed up deployment of IPv6.
Also, it might not even be sufficient - some companies might still want to be "really, really independent" and get their own address block.
Agreed.
The *benefit* of "/48 multihoming" is that you can filter those routes if you don't want to see them - then your routers will send packets down the /32 road, and eventually hit a router that knows about the /48 (which is why I consider this approach superior to "everybody gets a independent prefix", which I can't properly aggregate). Which brings us back to "why I want ONE regional block per RIR" - that's why.
Yup. - kurtis -
On Thu, May 29, 2003 at 08:06:32AM +0200, Kurt Erik Lindqvist wrote:
The *benefit* of "/48 multihoming" is that you can filter those routes if you don't want to see them - then your routers will send packets down the /32 road, and eventually hit a router that knows about the /48 (which is why I consider this approach superior to "everybody gets a independent prefix", which I can't properly aggregate). Which brings us back to "why I want ONE regional block per RIR" - that's why. Yup.
Gert pointed me to this list and I lurked for a while now. But now I want to take my chance and say something about this: I'm on the customers side (not being a LIR, but rather seing it from the other perspective). We currently have our internetaccess at one provider and are quite happy with this most of the time. The only problem is the disaterous commercial situation of some providers. This forced us to change providers a few times now and we are just currently thinking of implementing multihoming. Not because its a better technical solution (this is a nice sideeffect, but not the main reason), but rather to be indepent from the next bankrupt. This is exactly what mutihoming with PA Address Space will not solve. Though I see the technical advantages Gert pointed out (especially bein reachable from an AS filtering small netblocks, this does not provide any solution to the commercial challenges providers are currently facing. So, what we really want is PI addresses. And with the current pratices they just do not aggregate which also is a bad thing. This is why I think the geographical approach already mentioned on the list (one netblock per country, different sizes depending on population) currently is the approach which fits that need best, I believe. Just my 0.02EUR, Nils
Nils Ketelsen wrote:
On Thu, May 29, 2003 at 08:06:32AM +0200, Kurt Erik Lindqvist wrote:
The *benefit* of "/48 multihoming" is that you can filter those routes if you don't want to see them - then your routers will send packets down the /32 road, and eventually hit a router that knows about the /48 (which is why I consider this approach superior to "everybody gets a independent prefix", which I can't properly aggregate). Which brings us back to "why I want ONE regional block per RIR" - that's why. Yup.
Gert pointed me to this list and I lurked for a while now. But now I want to take my chance and say something about this: I'm on the customers side (not being a LIR, but rather seing it from the other perspective).
We currently have our internetaccess at one provider and are quite happy with this most of the time. The only problem is the disaterous commercial situation of some providers. This forced us to change providers a few times now and we are just currently thinking of implementing multihoming. Not because its a better technical solution (this is a nice sideeffect, but not the main reason), but rather to be indepent from the next bankrupt.
This is exactly what mutihoming with PA Address Space will not solve. Though I see the technical advantages Gert pointed out (especially bein reachable from an AS filtering small netblocks, this does not provide any solution to the commercial challenges providers are currently facing.
So, what we really want is PI addresses. And with the current pratices they just do not aggregate which also is a bad thing. This is why I think the geographical approach already mentioned on the list (one netblock per country, different sizes depending on population) currently is the approach which fits that need best, I believe.
How do you come to that conclusion? Every other PI space will be with another ISP. So even thought you might have everything close together on a "human logic" level there is no way to aggregate the prefixes together in the routing system. Unless of course you want to do it PTT style where one is the one who routes this block. Other than your last paragraph I fully agree on what you describe. Unless there is a convincing way for this independence IPv6 won't fly. -- Andre
On Thu, May 29, 2003 at 11:36:16AM +0200, Andre Oppermann wrote:
Nils Ketelsen wrote:
So, what we really want is PI addresses. And with the current pratices they just do not aggregate which also is a bad thing. This is why I think the geographical approach already mentioned on the list (one netblock per country, different sizes depending on population) currently is the approach which fits that need best, I believe.
How do you come to that conclusion? Every other PI space will be with another ISP. So even thought you might have everything close together on a "human logic" level there is no way to aggregate the prefixes together in the routing system. Unless of course you want to do it PTT style where one is the one who routes this block.
I think in most cases the "human logic level" also works for routing. So I guess many people will carry the complete routingtable for those countries they communicate a lot with (mostly this will be the own country and some nearby, but YMMV) and just have a few aggregates like "send all traffic to $farcountry1 to uplink A, send all for $farcountry2 via uplink B etc". Communication mostly happens in the same way "human logic" does, because in the end its humans initiating the communication. I think this could be a good compromise between every multihomed user has to be in every routing table and ongoing provider dependance. Nils -- Please let us know if your SunSolve visit saved you a call to Sun Support! Access Denied [komplette Auskunft zu einem Patch auf http://sunsolve.sun.com/]
Nils Ketelsen wrote:
On Thu, May 29, 2003 at 11:36:16AM +0200, Andre Oppermann wrote:
Nils Ketelsen wrote:
So, what we really want is PI addresses. And with the current pratices they just do not aggregate which also is a bad thing. This is why I think the geographical approach already mentioned on the list (one netblock per country, different sizes depending on population) currently is the approach which fits that need best, I believe.
How do you come to that conclusion? Every other PI space will be with another ISP. So even thought you might have everything close together on a "human logic" level there is no way to aggregate the prefixes together in the routing system. Unless of course you want to do it PTT style where one is the one who routes this block.
I think in most cases the "human logic level" also works for routing. So
No, it does not. And that is exactly the point. It never has and probably never will as long as we don't have monopolies in each country. BTW have a look at how the country based E.164 telephony system is implementing number portability...
I guess many people will carry the complete routingtable for those countries they communicate a lot with (mostly this will be the own country and some nearby, but YMMV) and just have a few aggregates like "send all traffic to $farcountry1 to uplink A, send all for $farcountry2 via uplink B etc".
No. This could only hold true for maybe a leaf node (non-transit) with two upstreams. Everyone else who is doing any kind of transit will have to carry the full table. I ask you where are the savings? Which network engineer wants to define for each and every $forcountry where it goes? BTW we have that already today. For example you can have a primary uplink (default route) and a secondary uplink with a smaller ISP in your country from where you only import his and his peer prefixes. Under these circumstances even an obsolete 2500 can do BGP routing.
Communication mostly happens in the same way "human logic" does, because in the end its humans initiating the communication.
To decouple exactly this human logic from the technical implementation we have DNS and BGP. For example I'm in Switzerland. Interestingly the website with most hits (blick.ch) is physically placed in Germany and connected with a German ISP who does not even have a single line to Switzerland. This is just one case where your "human logic" assumptions breaks. And the Internet has exactly been designed to separate these layers from each other. It should, it must not matter where your resource is located.
I think this could be a good compromise between every multihomed user has to be in every routing table and ongoing provider dependance.
Nope. It looks like you have never done BGP before. Until you have got some significant experience, I'm sorry to say, you are not fully qualified for discussion on this level. (What about me? Have a look at AO6-RIPE, AS8271 and AS8235). -- Andre
Which network engineer wants to define for each and every $forcountry where it goes?
Oh, like UUCP you mean? Maybe we could distribute maps? Wait, that is part of the idea...(although they are based on population)... On a more serious note... If the geo-based routing models could be made to work, they would be great. I am just afraid that we are lacking a lot. Experience is one thing. From the global-v6 list I learned that Michel is working with some vendor on running code for the MHAP proposal. I am really curious for how it will work out in real-life and I hope that Michel posts data once they start testing. Personally I believe more on a solution based on location/identifier separation. - kurtis -
On söndag, jun 1, 2003, at 19:28 Europe/Stockholm, Kurt Erik Lindqvist wrote:
Oh, like UUCP you mean? Maybe we could distribute maps? Wait, that is part of the idea...(although they are based on population)...
Before I get shot-down over this : It's missing a ;-) at the end was intended as a joke... - kurtis -
Hi, On Thu, May 29, 2003 at 02:43:42PM +0200, Andre Oppermann wrote:
Nope. It looks like you have never done BGP before. Until you have got some significant experience, I'm sorry to say, you are not fully qualified for discussion on this level. (What about me? Have a look at AO6-RIPE, AS8271 and AS8235).
I find this way of discussion not very helpful. Especially if the attacks are coming from someone who didn't bother to back any of his claims with anything but "I know better than you". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55295 (54837) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Thu, May 29, 2003 at 12:44:08PM +0200, Nils Ketelsen wrote:
Communication mostly happens in the same way "human logic" does, because in the end its humans initiating the communication.
I think you put too much faith in www.foo.xy being actually located in XY when in fact it's probably hosted in USA, the images are served by Akamai acording to their own load algorithm and the shop form is submited to a server in the company HQ at country WZ. -- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
So, what we really want is PI addresses. And with the current pratices they just do not aggregate which also is a bad thing. This is why I think the geographical approach already mentioned on the list (one netblock per country, different sizes depending on population) currently is the approach which fits that need best, I believe.
How do you come to that conclusion? Every other PI space will be with another ISP. So even thought you might have everything close together on a "human logic" level there is no way to aggregate the prefixes together in the routing system. Unless of course you want to do it PTT style where one is the one who routes this block.
I think in most cases the "human logic level" also works for routing. So I guess many people will carry the complete routingtable for those countries they communicate a lot with (mostly this will be the own country and some nearby, but YMMV) and just have a few aggregates like "send all traffic to $farcountry1 to uplink A, send all for $farcountry2 via uplink B etc".
...and if you are a "Tier-1" operator that is also selling services all across the globe and use one single AS-number, you will end up having to carry all those routes anyway....and guess what, the "Tier-1"s are coming to the conclusion that routes equals state equals costs. Cost need to be recovered. I think you can work out the rest.
I think this could be a good compromise between every multihomed user has to be in every routing table and ongoing provider dependance.
It's a good idea, but the world doesn't really look that way. - kurtis -
This is way off-topic and I apologies for this.
Kurt Erik Lindqvist wrote: Agreed. The flaws of IPv6 comes down to not solving the multihomign/routing scaling/world starvation problem. That is an IETF problem, and there is a WG for it.
For the record, and the following are verifiable _facts_: the IRTF and the IETF have been working on this problem for the last ten years.
No one will disagree with you. The multi6 WG have certainly not delivered and that is not a secret. There are a number of reasons for that. However, I took over as co-chair with one of the goals to make it move forward, and we seem to be starting. In order to make your mail somewhat fair, it is also worth pointing out that to my knowledge Michel disagrees with multi6, and thinks it should be closed down. I am not clear on what you want to do instead to solve the problem except your own MHAP proposal. Michel started his own mailinglist, which AFAI can tell have not reach any more consensus than multi6 have.
One of the Area Directors responsible for the multi6 WG has called it the "Titanic". By Kurtis' own account it is going to be 5 to 10 more years before they find a solution, if they do.
You are now putting words in my mouth. I said that it would take us 5-10 years before we have a solution widely deployed. The same goes for most solutions I have seen proposed.
The WG that Kurtis co-chairs has not even agreed to _requirements_ that were due two years ago; they are calling it recommendations now with zero proposals on the table.
I am not sure we have been reading the same mailinglist, but the current discussions are around how to limit the number of proposals and how to group them. If you like it or not, a solution to the multi6 problem will require an overall architecture. And that needs to fit with the rest of the Internet and what is going on in genereal.
Anyone that wants to have a glimpse of what the IETF is going to do for them is encouraged to read Kurtis' own draft: http://www.ietf.org/internet-drafts/draft-kurtis-multihoming- longprefix- 00.txt
Picking out one single personal draft does not say anything about what the IETF will do for anyone. I have never said this proposal is perfect, far from it. Michel have his own personal opinion and agenda. That is fine. I prefer disagreeing with Michel working on his own proposal outside the IETF and getting it implemented and not standardized instead of people not working on this problem at all. - kurtis -
participants (6)
-
Andre Oppermann -
Carlos Morgado -
Gert Doering -
Kurt Erik Lindqvist -
Michel Py -
Nils Ketelsen