APNIC Home APNIC Home
Info & FAQ |  Resource services |  Training |  Meetings |  Membership |  Documents |  Whois & Search |  Internet community

You're here:  Home  Mailing Lists global-v6 


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GLOBAL-V6]IPv6 Allocation Policy



On Wed, 21 May 2003, Craig A. Huegen wrote:
> > So, it seems to me that Cisco would be best using multiple ISP-specific PA
> > addresses, right?  That would seem to solve about all the problems related
> > to traffic engineering?  (You only configure addresses of those ISP's
> > which are connected to your public service sites -- and each of them gets
> > there without WAN traffic.)
> 
> Actually, it would not.
> 
> Multiple PA prefixes as a solution has far too many problems.

Certainly, one can argue that it has far too many problems for any kinds 
of networks.

> I as a
> network administrator cannot control the traffic flow -- originating hosts
> get to set the network paths by their choices of source/destination
> addresses.

You cannot control the source addresses the hosts pick anyway *).  The
only way you could meaningfully influence it would be via having a single
destination prefix for each region-specific service in the DFZ.  And as
the BGP path selection is not as good as it could be, even that is shaky.  
So, I think you need the off-band mechanisms to optimize this (e.g.  
cookies to store the location + HTTP redirection).

If a service located e.g. in Australia has IP addresses from two 
Australian ISPs only, I would wager to guess the traffic flow is rather 
optimal in that region.

*) this is another thing RIR's+IANA have been incredibly stupid about,
much less stingy to a harmful degree: come on, with one IANA /23
allocation, you can only make 64 "sTLA" allocations.  If IANA had given
each RIR e.g. a /16, the longest-prefix match might have resulted in
useful results so that when destination has addresses from RIPE and ARIN
region, the source who is in ARIN region might have chosen the ARIN
destination... but NO.

> I have to manage extra prefixes on
> every subnet and carry those multiple prefixes in my IGP.  

Only those subnets where you have services would be critical: not too many 
I think.

> A failure of a
> circuit at the edge of the network would trigger an amazingly huge
> state-change wave across the network, 

Which edge?  I assume you mean the edge between a regional ISP and a 
regional office, not the edge to your subnets.

> withdrawing the prefixes from the
> interface, then removing them from the IGP.

I would hope that a change like this would be topologically regional (and
thus not such a big deal), or otherwise I'd worry whether it's useful to 
spread the information further away than necessary.

> There are just too many problems in a large network like ours to use the
> multi-PA solution.

Many say that, and I kind of agree to an extent, but this has never been 
fleshed out... and as you seem most worried about the services and not 
having to haul it across the WAN, I think those could be manageably 
enabled in multi-PA fashion, at least.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings