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

[Michael Sinatra]

On 09/24/10 23:51, Fred Baker wrote:
> I would appreciate opinions from the operators forum; please post
> comments to v6ops at ietf.org.
>
> The IPv6 Operations Working Group has been asked to adopt this
> document as a working group draft. In essence, the outcome would
> become a suggestion to the RIR and *NOG communities regarding the way
> the IETF would suggest that IPv6 prefixes be allocated. Note the use
> of the word "suggest". In summary, what this says is that the IETF
> holds no strong opinions about specific prefix lengths or boundaries,
> but strongly feels that the allocation policies should be scalable -
> which means that PI allocations to edge networks should be done only
> when Really Truly Appropriate.
>
> My question is: is this something that the operational community
> would consider helpful, or is it something the operational community
> would prefer the IETF kept its nose out of? If the operational
> community would find it helpful, is the specific suggestion
> reasonable from an operational perspective?

I may be a bit of a curmudgeon here, but I think one sentiment you might 
hear from the operations community is: "No thank-you.  The IETF has 
already done more than enough to place obstacles in front of IPv6 
adoption, particularly by 'end sites'.  We don't need to add to that."

On a slightly more constructive note:

It's very clear to me that the belief that we could limit the routing 
table growth by massively aggregating prefixes and creating a strong 
distinction between "end sites" and "service providers" has been 
discredited--and IPv6 almost failed as a result.  I don't think turning 
the clock back is going to help at all and I think such an effort will 
be largely ignored (as was the original effort to make IPv6 largely 
PA-only).

Three major issues I have with this and similar efforts:

1. It presupposes a particular economic architecture within the 
Internet, one where there is a relatively clear distinction between 
service providers and end sites, specific relationships between service 
providers and end sites, and a particular arrangement of these entities. 
  Even if I accept this as matching the reality of today's Internet--and 
that point is certainly arguable, I can't know that this arrangement 
will exist throughout the lifetime of IPv6--it certainly didn't for the 
full life of IPv4.

Moreover, the policy recommendations are driven by this economic 
characterization.  The draft goes through a number of logical gyrations 
in section 2.3 to show that the recommendations are based on technical 
grounds in order to justify the IETF's jurisdiction.  Strikingly, this 
is the longest section of the document, and by far the longest section 
of original content, as opposed to quotations from other RFCs. 
Nevertheless, the recommendations rest entirely on a particular economic 
reality (or characterization thereof) and therefore make little sense 
coming from a standards body.

2. It is service-provider-centric.  This is justified by topological 
considerations in section 4 (the second-longest section of the 
document), but this justification is misplaced, partly due to its 
assumption that aggregation among *end sites* is the only way to reduce 
routing table growth.  The recommendations impose costs on end sites by 
making them renumber when they want to change service providers or by 
making them convince service providers to poke holes in their 
announcements--requests which service providers could easily ignore.  It 
makes multi-homing of end sites more difficult.  It imposes no costs on 
service providers who happily have access to portable addresses, derive 
additional benefit from a smaller routing table, and share zero cost for 
either of these benefits.  It doesn't require much thought to see why 
the operations community might be opposed to this.  Standards shouldn't 
merely reflect the interests of those who only make up a portion of the 
overall Internet community.

3. It makes an extrapolated projection of the IPv6 prefix growth rate, 
while characterizing that growth based solely on current IPv6 address 
growth, rather than including the richness of IPv4 experience.  The 
current IPv4 stats tell us that IPv4 table bloat is caused by 
announcement of disaggregated prefixes that could be aggregated, and by 
announcement of multiple non-aggregable prefixes by the same AS.  A 
rather draconian policy would be to assert that no AS can ever announce 
more than one IPv6 prefix.  If someone acquires additional prefixes from 
mergers and acquisitions, they must renumber.  It imposes costs on end 
sites and service providers alike, which is why it would never be 
adopted.  It also forces the AS allocation policy to be the limiting 
policy for address growth and might put pressure on that policy.  But 
unlike a PA-only policy, it takes into account more factors in routing 
table growth.

Anyway, my point is not to say that my suggestion is better; rather it 
is intended as a straw man to show how stilted the proposed draft is 
regarding service providers (#2 above) and our limited IPv6 experience 
(#3 above).

On a more general note, these arguments are best left to the RIRs and 
their constituents and the NRO--and they are well versed in this topic. 
  Having the IETF get involved at this stage of the game would be 
counter-productive.   On the other hand, having the IETF work on new 
protocols that scale better would probably be appreciated.

michael