I-D Action:draft-azinger-scalable-addressing-00.txt

[Paul Timmins]

Gert Doering wrote:
>> They are obliged to work within the architecture that IETF lays out.
>>     
> If the IETF tries to mandate something that the RIR members don't accept,
> what then?
>   
And as a RIR member who needs to see IPv6 adoption happen, I'll expend 
all my available resources in that arena to ensure that a return to this 
'only ISPs can have PI addressing' nonsense dies a quick death.

And I say that as an ISP. My customers need more reasons to migrate, not 
less.
>> The IETF doesn't pretend to be involved in economic issues, as you well know.
>>     
> Address allocation is massively influenced by economic factors.  So trying
> to dictate allocation policy and at the same time claiming "economics are
> of no interest to us" is FAIL.
>
> (The IETF tried this before, with the "there must only be 8192 TLAs in
> the default-free zone" approach - and never came up with any guidance 
> that enabled anyone to decide who is big enough to receive a TLA, and who 
> has to adjust their business model to "no, you are too small, base your 
> whole ISP operation on 3rd-party space".  FAIL.).
>   
Double fail, and as an ISP that has grown drastically in the last 3 
years, I'm glad that died a quick death. I've already renumbered my 
network once, back when it truly was small. Never again.
>> Again, we're not here to discuss policy.  Our point is about
>> architecture.  Policy decides who qualifies for what role.  Architecture
>> is deciding how the technical pieces must be put together to scale.
[snip]
>> >From an architecture point of view, both PI and PA are just "blocks of
>> addresses used to number devices and visible in the global routing table".
>>
>> The difference is purely policy-wise: what strings are attached to this
>> specific block of addresses, what price tag is attached.
>>
>> Now, I'm not saying that PI is the "right" or "only" way forward - but some of 
>> the statements made above just don't reflect my pocket of reality
Too many times I hear IETF members saying 'we need more input from the 
operations community, you all should join our mailing lists'.

This to me poses 2 obvious issues:
    1) You recognize you are making decisions in a vacuum and do it anyway
    2) The burden is on the people doing this stuff every day to make 
sure some ivory tower policy doesn't pop out of nowhere and stomp on 
whatever they were         doing to get stuff done.

I propose the IETF do two things to help scalability:
    1) Sit on their hands. Until they know what's happening out here, 
any policy making is completely stupid.
    2) Listen to what people are saying. I hear all sorts of terrible 
arguments for why IPv6 should have NAT. I disagree this should happen. I 
*do* agree the customers shouldn't have to renumber their entire 
networks every time they switch IPs. There are currently two ways of 
doing this:
       a) NAT
       b) Large scale PI distribution, for free, so networks can get 
stable addressing.
    As much as I favor the vendor lockin that forcing my customers to 
use my space on their internal networks creates, I want them to see the 
benefits, and I don't want them locked into SOMEONE ELSE'S PA space.

So if the IETF wants to do something, solve that dictomy and we'll be 
much further along.
and
As for the routing table growth? Well, IPv6 has the above problem, 
either we need NAT or PI addresses for everyone before the majority of 
businesses will accept it.

So if we're going forward, let's either decide to create a standard way 
to do NAT, and a way to detect it, and a way to request translations. 
Individual sites can decide to restrict the ability to request 
translations, sure, that's their right, but that will give me ammo as an 
operator to explain who just broke protocol X (them, as they're not 
fully implementing the RFC)

Or let's give everyone PI space and find a good protocol to aggregate it 
where possible.

As far as routing bloat without changes to this policy, that is a self 
fixing problem. Currently we are announcing 4 IP blocks via BGP, and 
will probably be announcing 6 before we start to not need them anymore, 
or maybe even more.

Under IPv6 we will need one. That's a 6:1 aggregation ratio just by 
switching to IPv6. Not bad! And quite representative of the internet as 
a whole.

The slow start policies the RIRs had to use kept them from giving us a 
/18 to start with, so now we have two /21s, a /20, and a /22.

-Paul