|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Addressing versus Routing (Was: Deploying IPv6 in a datacenter)
On Wed, Dec 21, 2005 at 11:36:00PM +0100, Daniel Roesen wrote: > > 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?). Last time I checked, Ethernet is still 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: [email protected] -- [email protected] -- PGP: 0xA85C8AA0
|