On Wed, Dec 21, 2005 at 08:34:06PM +0100, Jeroen Massar wrote:
The issue with announcing say a /48 is though that networks which filter will filter it out and will only reach you over the aggregate. Of course that is their choice, just like yours is to try to announce the /48's in IPv6, or the /23's for IPv4. An IPv4 /28 doesn't reach far either.
The problem here is though that your /48 will propagate through ISP's with less strict filters and they will act as transits for your /48. My experience tells that the ones not filtering also have a not so-good setup thus your connectivity tends to go all around the world.
This description of the problem ain't totally correct. The problem is that the more specific route propagates thru fewer paths, thus the average AS_PATH (and forwarding path) length is usually (much) higher for the more specific route than the aggregate. Routers decide on CIDR, so packets to the more specific will travel the long way instead of the short way. It's NOT a matter of "the ones not filtering also have a not so-good setup". Actually, many/most of the "big good IPv6 players" nowadays DO allow /48s as they recognize the need for "end site multihoming". And this also contributes to the fact that /48 multihoming is nowadays far more feasible (as long as your upstreams are "sane and well connected") than let's say a year ago. Caveat: this is a EU/US centric view. I'm not sure about the development in the ASPAC region on this matter as I didn't follow that closely (partly because it's difficult to follow anything there as it's network-topological "quite distant" and few hosts and accessible routers to test from).
The same as IPv4 announce a /48. Have a fallback /32 for folks who do filter it out.
As outline above, that will artificially impair connectivity performance.
Here you say it your self: "Advertisement policies" this is routing again, which has not much to do with Address Space.
It does, as long as we don't have a total decoupling between locators and identifiers, alongside with the required tools for traffic engineering with the locators.
One can deaggregate in IPv6 also, just don't expect it to be accepted. Just like a /24 won't be accepted by most folks.
Uhm, sorry, but that's wrong. /24s are widely(!) accepted and only very seldom not accepted. There are many (MANY!) folks running on /24 PI (== no larger covering aggregate) without problems.
-- Kevin
<waits for flame war to erupt> :)
</me donates his asbestos suite and tin foil hat> :)
</me shows off his designer collection of asbestos>
This is the very hard part. (political and technical) But it might be years before we will hit the actual limits of BGP. We still have to be nice to our kids though as they will hit it ;)
Really? Where are the limits of BGP? Can you show me any numbers? You'd be the first. I'm not aware of any protocol inherent scaling brickwalls like with other protocols where certain timing constraints place limits (or thinking of L1 systems, you remember CSMA/CD?). That doesn't mean that there are none - I'm not a scientist or mathematician - I'd be happy to have any numbers to back the FUD about the end of world being near. :-)
Most if not all of these have problems for some uses, eg Traffic Engineering is supposedly not possible anymore the way it is currently being done in BGP. Mindset changes will be required.
For all, or only for those who are not deemed worthy of entering the market on the same terms and conditions like the existing players? ;) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0