[lir-wg] Discussion about RIPE-261

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.