[lir-wg] Discussion about RIPE-261
Carlos Morgado chbm at cprm.net
Tue May 27 18:34:21 CEST 2003
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 at 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.
[ lir-wg Archives ]