[ppml] "Recommended Practices" procedure
Scott Leibrand
sleibrand at internap.com
Thu Jun 29 18:04:19 EDT 2006
- Previous message: [ppml] "Recommended Practices" procedure
- Next message: [ppml] "Recommended Practices" procedure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 06/29/06 at 5:15pm -0400, Jason Schiller (schiller at uu.net)...: > Although somewhat difficult, the problem isn't getting each of the > customer's upstream ISPs to send the more specifics between their peering > sessions, the customer is presumably paying their upstream ISPs to carry > these routes. Agreed. > The problem is getting all the other default free ISPs to carry the > route. Sources that buy transit from someone other than the customer's > upstream ISPs will be dependent on the upstream ISP that provided the PA > IP space, unless they also carry the more specifics. I would maintain that getting other default free ISPs to carry the deaggregated PA /48 is beneficial, for traffic engineering and routing optimization, but unnecessary in most cases for reachability. The only case in which it would be insufficient would be if the provider who allocated the addresses went totally offline (stopped originating their /32) or partitioned their network in such a way that they were unable to reach *any* of the peering links to the customer's other provider. (Remember, they're accepting the /48 from the other provider, presumably over all their peering links, so that's a lot of diverse paths.) I would argue that if you need resilience against that kind of failure, you should be using PI space, not PA. Even in the IPv4 world, PA multihomers can experience issues when the provider who allocated them the space has issues affecting their announcement of the aggregate. -Scott
- Previous message: [ppml] "Recommended Practices" procedure
- Next message: [ppml] "Recommended Practices" procedure
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list