North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: v6 multihoming (Re: The Choice: IPv4 Exhaustion or Transition to IPv6)

  • From: Nicolás Antoniello
  • Date: Fri Jun 29 13:29:37 2007

Hi Steve,

Sure... I've never mention 3 STM4... the example said 3 carriers.

OK, you may do it with communities, but if you advertise all in just one 
prefix, even with communities, I find it very difficult to control the 
trafic when it pass through 2 or more AS (it may be quite easy for the 
peer AS, but what about the other ASs)?

Nicolas.


On Fri, 29 Jun 2007, Stephen Wilcox wrote:

steve. >Hi Nicolas,
steve. > you will never make 2GB of traffic go down one STM4 or even 3x STM4! 
steve. >
steve. >But you are asking me about load balancing amongst 3 upstreams...
steve. >
steve. >Deaggregation of your prefix is an ugly way to do TE. If you buy 
steve. >from carriers that support BGP communities there are much nicer 
steve. >ways to manage this. I've never deaggregated and I have had and do 
steve. >have individual prefixes that generate more traffic than any 
steve. >single GE link.
steve. >
steve. >Steve
steve. >
steve. >On Fri, Jun 29, 2007 at 12:11:58PM -0300, Nicolás Antoniello wrote:
steve. >> Hi Stephen,
steve. >> 
steve. >> Supose you have STM4 links, ok?
steve. >> And you have 2G of trafic from your 100000 ADSL customers, ok?
steve. >> And those STM4 go to 3 dif carriers in USA.
steve. >> Then, how you advertise only one IPv6 prefix to all and make the 2G go 
steve. >> trough one STM4 ?
steve. >> 
steve. >> 
steve. >> On Fri, 29 Jun 2007, Stephen Wilcox wrote:
steve. >> 
steve. >> steve. >
steve. >> steve. >Hi Christian,
steve. >> steve. > I am not seeing how v4 exhaustion, transition to v6, multihoming in v6 and destruction ov DFZ are correlated.
steve. >> steve. >
steve. >> steve. >If you took everything on v4 today and migrated it to v6 tomoro the routing table would not grow - actually by my calculation it should shrink (every ASN would only need one prefix to cover its current and anticipated growth). So we'll see 220000 routes reduce to 25000.
steve. >> steve. >
steve. >> steve. >The technology we have now is not driving multihoming directly and v4 vs v6 is not a factor there.
steve. >> steve. >
steve. >> steve. >So in what way is v6 destroying DFZ?
steve. >> steve. >
steve. >> steve. >Steve
steve. >> steve. >
steve. >> steve. >On Fri, Jun 29, 2007 at 02:13:50PM +0000, Christian Kuhtz wrote:
steve. >> steve. >> 
steve. >> steve. >> Amazink!  Some things on NANOG _never_ change.  Trawling for trolls I must be.
steve. >> steve. >> 
steve. >> steve. >> If you want to emulate IPv4 and destroy the DFZ, yes, this is trivial.  And you should go ahead and plan that migration.
steve. >> steve. >> 
steve. >> steve. >> As you well known, one of the core assumptions of IPv6 is that the DFZ policy stay intact, ostensibly to solve a very specific scaling problem.
steve. >> steve. >> 
steve. >> steve. >> So, go ahead and continue talking about migration while ignoring the very policies within which that is permitted to take place and don't let me interrupt that ranting.
steve. >> steve. >> 
steve. >> steve. >> Best Regards,
steve. >> steve. >> Christian 
steve. >> steve. >> 
steve. >> steve. >> --
steve. >> steve. >> Sent from my BlackBerry.      
steve. >> steve. >> 
steve. >> steve. >> -----Original Message-----
steve. >> steve. >> From: Stephen Wilcox <[email protected]>
steve. >> steve. >> 
steve. >> steve. >> Date: Fri, 29 Jun 2007 14:55:06 
steve. >> steve. >> To:Christian Kuhtz <[email protected]>
steve. >> steve. >> Cc:Andy Davidson <[email protected]>, [email protected],       Donald Stahl <[email protected]>, [email protected]
steve. >> steve. >> Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
steve. >> steve. >> 
steve. >> steve. >> 
steve. >> steve. >> multihoming is simple, you get an address block and route it to your upstreams.
steve. >> steve. >> 
steve. >> steve. >> the policy surrounding that is another debate, possibly for another group
steve. >> steve. >> 
steve. >> steve. >> this thread is discussing how v4 to v6 migration can operate on a network level
steve. >> steve. >> 
steve. >> steve. >> Steve
steve. >> steve. >> 
steve. >> steve. >> On Fri, Jun 29, 2007 at 01:37:23PM +0000, Christian Kuhtz wrote:
steve. >> steve. >> > Until there's a practical solution for multihoming, this whole discussion is pretty pointless.
steve. >> steve. >> > 
steve. >> steve. >> > --
steve. >> steve. >> > Sent from my BlackBerry.      
steve. >> steve. >> > 
steve. >> steve. >> > -----Original Message-----
steve. >> steve. >> > From: Andy Davidson <[email protected]>
steve. >> steve. >> > 
steve. >> steve. >> > Date: Fri, 29 Jun 2007 14:27:33 
steve. >> steve. >> > To:Donald Stahl <[email protected]>
steve. >> steve. >> > Cc:[email protected]
steve. >> steve. >> > Subject: Re: The Choice: IPv4 Exhaustion or Transition to IPv6
steve. >> steve. >> > 
steve. >> steve. >> > 
steve. >> steve. >> > 
steve. >> steve. >> > 
steve. >> steve. >> > On 29 Jun 2007, at 14:24, Donald Stahl wrote:
steve. >> steve. >> > 
steve. >> steve. >> > >> That's the thing .. google's crawlers and search app runs at layer  
steve. >> steve. >> > >> 7, v6 is an addressing system that runs at layer 3.  If we'd (the  
steve. >> steve. >> > >> community) got everything right with v6, it wouldn't matter to  
steve. >> steve. >> > >> Google's applications whether the content came from a site hosted  
steve. >> steve. >> > >> on a v4 address, or a v6 address, or even both.
steve. >> steve. >> > > If Google does not have v6 connectivity then how are they going to  
steve. >> steve. >> > > crawl those v6 sites?
steve. >> steve. >> > 
steve. >> steve. >> > I think we're debating from very similar positions...
steve. >> steve. >> > 
steve. >> steve. >> > v6 isn't the ideal scenario of '96 extra bits for free', because if  
steve. >> steve. >> > life was so simple, we wouldn't need to ask this question.
steve. >> steve. >> > 
steve. >> steve. >> > Andy
steve. >> steve. >> > 
steve. >> steve. >
steve. >