This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] IPv6 access to K-root
- Previous message (by thread): [address-policy-wg] IPv6 access to K-root
- Next message (by thread): [address-policy-wg] IPv6 access to K-root
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Iljitsch van Beijnum
iljitsch at muada.com
Wed Mar 2 10:50:35 CET 2005
On 2-mrt-05, at 3:01, Daniel Roesen wrote: > I consider 15-hop AS_PATHs crossing ponds multiple times and tunnels > all > over etc with 500ms+ RTT quite fatal, compared to let's say 3-hop > AS_PATH all native. [...] > The problem operators on the net don't update filters, let > alone read "nice documents" how to do things properly. [...] > You cannot filter PA-more-specific-multihomer-prefixes away > without risking to lose connectivity to them. If the provider aggregate > has routing problems (be it interdomain or even intradomain) and your > transit cloud doesn't see the more-specific prefix announced by the > multihomer, you lose connectivity. [...] It's important to separate fundamental problems that aren't fixable, or require unpleasant compromises to be fixed, from the incidental problems that can be fixed in time and with education. The ones you list all fall in the latter category, IMO. The problem with the routing table size is that when it gets out of hand, there isn't much that you can do. We all know aggregation in IPv4 could be much better than it is now but still there is nothing anyone seems to be able to do to help the situation.
- Previous message (by thread): [address-policy-wg] IPv6 access to K-root
- Next message (by thread): [address-policy-wg] IPv6 access to K-root
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]