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

[Brian E Carpenter]

Michael,

Again, cross-posting to v6ops - I think your arguments must be discussed
there. (Normally, I avoid cross-posting like the plague.)

Three comments on your points below:

1. I agree that it is not the IETF's place to assert policy
in this area. Actually we are not supposed to, under the terms
of RFC2860 (which, as it happens, Fred and I both signed in ink).

2. But it is our place to document the technical implications
of various alternatives, as they affect the future scaling of
the Internet. It's certainly correct that the operator community
has most of the data and experience, of course. So I would
advocate that any IETF document in this area is written with
the benefit of that experience, and that it keeps away from
asserting policy.

3. Finally, you say:

>> On the other hand, having the IETF work on new
>> protocols that scale better would probably be appreciated.

Er, yes, but see my previous message - we've been on this
topic in the IRTF and IETF for ten years and more, and it's hard.

Regards
   Brian Carpenter

On 2010-09-26 08:29, Michael Sinatra wrote:
> 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
>