Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

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)

  • From: Daniel Roesen
  • Date: Wed Dec 21 17:37:08 2005

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




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.