I-D Action:draft-azinger-scalable-addressing-00.txt
Michael K. Smith - Adhost
mksmith at adhost.com
Tue Sep 28 16:58:43 CEST 2010
> -----Original Message-----
> From: ipv6-ops-bounces+mksmith=adhost.com at lists.cluenet.de
> [mailto:ipv6-ops-bounces+mksmith=adhost.com at lists.cluenet.de] On
> Behalf Of Brian E Carpenter
> Sent: Monday, September 27, 2010 7:39 PM
> To: Doug Barton
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: I-D Action:draft-azinger-scalable-addressing-00.txt
>
> On 2010-09-28 11:03, Doug Barton wrote:
> > On 9/27/2010 2:36 PM, Fred Baker wrote:
> >>
> >> On Sep 27, 2010, at 2:24 PM, Doug Barton wrote:
> >>> So this is one more strong argument for IPv6 PI in as many places
> >>> as humanly possible.
> >
> >>> Please note that I am not suggesting that this is a "fire and
> >>> forget" solution, I'm aware that even in IPv6-topia there will
> >>> still be renumbering due to organizational changes (e.g., mergers
> >>> and acquisitions) but we really should be focusing on IPv6 PI as
> >>> the answer, not as the problem.
> >>
> >> So you would very strongly prefer a world in which router memory
> >> sizes are required to be effectively infinite.
> >
> > Easy there tiger, that's not at all what I said, and it's not even close
> > to what I think. Someone else already pointed out that where they have
> > 2-4 IPv4 blocks advertised now, they could easily get by with just 1
> > IPv6 announcement. In my book that's making the routing table smaller,
> > not larger. :)
> >
> > What I'm advocating is not blindly bloating the routing table ad
> > infinitum. What I'm suggesting is that we look at the whole chess board.
>
> Right, one BGP4 update on the first square, two BGP4 updates on the second
> square, four on the third square, and so on...
>
> The question is, as Fred was I think getting at, where do you stop?
>
> If you arrange guidelines and policies such that you stop at, say,
> a few hundred thousand PI prefixes announced world-wide, we can hope
> that
> the routers won't melt.
>
> If you arrange guidelines and policies such that you head towards ten
> million PI prefixes announced in BGP4, then San Jose, we got a problem.
>
> I think this is what the IETF, and v6ops specifically, needs to
> communicate on a technical basis to the RIR and ops community.
> People on this list here probably know it, but not everybody.
>
> Beyond that, please read draft-irtf-rrg-recommendation, but
> remember that it's only words.
>
> Brian
I'm trying to wrap my brain around how PA space is going to be "better" than PI space. Follow my potentially flawed logic.
- I have a /32 that I announce through my various upstreams - no more specifics, just one /32.
- I get a /48 from my upstream out of their /32. I announce my /48 through my various providers
- I pressure my provider into announcing my /48 as well for traffic engineering
- Now we have a /32 and a /48 in the table.
- Rinse, repeat
How is this better? Is it really anyone's assumption that I should be forced into a one-upstream solution and that I would find that acceptable?
Regards,
Mike
More information about the ipv6-ops
mailing list