Subject: [v6ops] Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt

From: Fred Baker <[email-masked]>
Date: Fri, 24 Sep 2010 23:29:54 -0700

The authors have asked me to take a poll on whether this should become a working group draft. This is an updated version of draft-azinger-cidrv6, which was discussed at the Maastricht IETF meeting.

So: question to the house - should it become a working group draft?

I'll listen to the discussion and count yes's and no's (which if you would prefer you can send to [email-masked] to avoid cluttering the mailing list) next weekend.

Begin forwarded message:

> From: [email-masked]
> Date: September 24, 2010 12:45:06 PM PDT
> To: [email-masked]
> Subject: I-D Action:draft-azinger-scalable-addressing-00.txt 
> Reply-To: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : A Scalable Addressing Allocation Architecture for IPv6
> 	Author(s)       : M. Azinger, et al.
> 	Filename        : draft-azinger-scalable-addressing-00.txt
> 	Pages           : 14
> 	Date            : 2010-09-24
> 
> This document presents a scalable architecture for assigning and
> aggregating IPv6 address space.  The current IPv4 addressing
> aggregation strategy was defined in [RFC1519] (and updated in
> [RFC4632]) and the IPv4 address allocation architecture was defined
> in [RFC1518].  A similar address allocation architecture was proposed
> for IPv6 in [RFC1887].  The objective of this document is to update
> the previous documents and provide the best current guidance on an
> address allocation architecture to help manage the growth of routing
> tables in IPv6.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-azinger-scalable-addressing-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Sep 2010 08:37:51 +1300

Just commenting on a few points, and cross-posting in
response to Fred's request:

On 2010-09-25 22:35, S.P.Zeidler wrote:
> Hi,
> 
> I'm not currently with a provider, so personally I'm only a very small
> scale v6 op at present. :) Things that struck me but may be seen
> differently by people with current operational experience:
> 
> Points 4+5:
> "People should just get PA from one of their providers when they want to
> multihome, and talk them into allowing other providers to announce it"
> 
> been there, done that, finally got over it. Anyone not seeing that as a
> dead horse?

> Also, how does a PA /48 that gets announced more specific have a smaller
> impact on the routing tables than a PI /48? 

It doesn't. The effect is exactly the same, for all practical
purposes. This emperor has no clothes.

As we have known for many years, it's only if multihoming is
achieved by running a different PA prefix for each provider that we
don't blow out the BGP4 table. Hence RFC3582, RFC4177, shim6, ILNP,
LISP and a host of other work (see draft-irtf-rrg-recommendation).

> even the provider it's PA to
> must announce it more specific or have to accept being the loser in
> routing decisions because more specific has to win (and in all traffic
> accounted contracts, that idea will not sit well).
> Aggregating this at a higher tier would require checking that there
> didn't exist any announcement through a non-customer and de-aggregating
> as soon as one was seen; I'm not sure the collective computational load
> for that would be so much lower than just announcing the prefix.
> 
> Next:
> The analysis in point 6 looks bogus to me.

> 
> point one (rephrased a lot):
> "If v6 ASes grow by 54% now, it will continue to grow by at least 50%.
> It is not existing v4 ASes adding v6 and being naturally limited by all
> current v4 ASes having added the one v6 prefix necessary to survive,
> after which point the growth rate will drop drastically to the yearly
> growth rate in ASes we see in v4 now".
> Obviously, we are in a flood fill period that is rather not
> representative for the long run.

Well, if every active AS that announces IPv4 prefix(es) today also
announced IPv6 prefix(es), guess what, we'd have about 35,000 active
ASes announcing IPv6 prefixes. That doesn't really matter; the question
is whether we would also have 330,000 IPv6 prefixes, or significantly
fewer, and how these numbers will evolve in future. And that, truly,
I cannot guess.

> 
> point two (also rephrased):
> "If you only have one upstream in v6 at present you are likely an end user
> who never will have more than one upstream and could as well use PA"
> 
> That's an assertion that thoroughly underestimates both getting
> the upstreams one has for v4 to provide v6, and introduction periods
> where one irons out the kinks and learns the ropes with one friendly
> and knowledgeable upstream before tackling v6 with the rest of the
> upstream zoo.

Not to mention the expected increase in multihoming in the future.

> 
> Could someone with a grab on current data do a comparison of what the ASes
> that are recognized as stubs in v6 do in v4, please, just to replace
> guessing (either way) with information?

Data are always nice, and I suspect that these data are available
at potaroo.net, but actually, I would hesitate to extrapolate from
the early-adopter IPv6 deployment today.

> 
> Overall document:
> Given that even huge ASes will only originate a small number of
> prefixes in v6 compared to dozens to hundreds in v4 now, what problem
> exactly is this trying to fix?

That depends entirely on user sites and ISPs following good (CIDR-like)
practice. So I think encouraging that is the useful goal of this draft.

> As long as getting PI space is bound to getting or having an AS I don't
> really see the scaling problem.

Well, unless it encourages a gold rush on AS numbers.

> Running an AS requires the necessary routers, time by skilled engineers
> (even most IT workers only have a very vague idea how networking works
> and are definitely not able to set up BGP; you can contract the service
> but that costs money), and the usually more expensive upstream contracts
> that allow BGP sessions.
> Businesses tend to be able to do the math and decide that a server or
> two in housing and two independently numbered upstreams are way cheaper;
> if they serve their needs as well, they will pick that option.

I really hope you're correct. But if word gets around the world of
CIOs that the thing to do is get your own AS and a PI prefix,
then you can't be sure that sanity will prevail. And frankly,
site managers that I've talked to are puzzled and worried by the
prospect of running several simultaneous PA prefixes, and having
to renumber when they add or drop an ISP. See RFC 5887.

> The danger of every corner shop in the world trying to get PI is not
> actually there IMHO.

Again, I hope you're correct, but why not document the fact that it's
highly undesirable?

   Brian

> Comments to my comments?
> regards,
> 	spz

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Sep 2010 08:51:30 +1300

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 [email-masked].
>>
>> 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
>

---

From: Randy Bush <[email-masked]>
Date: Sat, 25 Sep 2010 15:52:08 -0400

i do not believe any wg in ietf is the forum for discussing adding to
allocation policy.  if any, the operator community is.

rand

---

From: Randy Bush <[email-masked]>
Date: Sat, 25 Sep 2010 16:01:28 -0400

> 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.

you are not describing this draft

randy

---

From: Fred Baker <[email-masked]>
Date: Sat, 25 Sep 2010 13:03:58 -0700

> practice. So I think encouraging that is the useful goal of this draft.

Which is where the draft is trying to go.

> Again, I hope you're correct, but why not document the fact that it's

We are in fact seeing quite a growth in AS numbers and in requests for PI allocation. You might look at

     http://www.potaroo.net/tools/asn16/

The growth rate of the AS number space is not spiking up per se, but it is non-linear, with increases in rate circa 2000 (with the dot-com bubble bursting, there was an increase in the assignment rate of AS numbers) and 2009-2010. I would imagine these are not "to get PI space" but "to multihome using BGP". If anything, I see that as the argument for solutions like ILNP or NAT66 (the draft, which does stateless prefix translation, not the idea of making stateful IPv6/IPv6 network ADDRESS translators). They enable the transit operators to view their networks as PA while their customers view themselves as pseudo-PI. Yes, it has issues similar to those described in RFC 2993.

---

From: Tony Li <[email-masked]>
Date: Sat, 25 Sep 2010 14:57:02 -0700

> allocation policy.  if any, the operator community is.

This draft is about the routing and addressing architecture, which is well within the purview of the IETF.  Yes, it deserves discussion in conjunction with the operations community, thus we are presenting it to v6ops.

Regards,
Tony

---

From: Randy Bush <[email-masked]>
Date: Sat, 25 Sep 2010 18:01:21 -0400

> This draft is about the routing and addressing architecture

   Internet Registries should begin to hand out IPv6 blocks of /32 or
   shorter to network service providers in order to accommodate both
   their growth and their customers' growth.  In addition Internet
   Registries should severely limit or eliminate the amount of PI
   assignments in order to help facilitate the decrease in routing table
   growth.  Service providers will allocate /48's to their customer
   organizations with multi-homing requirements.  Implementation and
   deployment of these modifications should occur immediately.

architecture?  sure looks likes nails and 2x4s to me.

randy

---

From: Tony Li <[email-masked]>
Date: Sat, 25 Sep 2010 15:10:01 -0700

> architecture?  sure looks likes nails and 2x4s to me.

Architecture _is_ about planning where the nails and 2x4's should go.  Construction is putting them there.

If it would help the discussion, we could easily couch the discussion in the euphemisms of graph theory, but that would seem disingenuous.  We would rather offer the blueprints.

Tony

---

From: Randy Bush <[email-masked]>
Date: Sat, 25 Sep 2010 18:13:14 -0400

> Architecture _is_ about planning where the nails and 2x4's should go.

and, btw, you once loudly and forcefully whacked me that the ietf was
not about architecture.  glad to seee you have changed on that one.

> If it would help the discussion, we could easily couch the discussion
> in the euphemisms of graph theory, but that would seem disingenuous.
> We would rather offer the blueprints.

to be specific.  the paragraph i quoted above was the conclusion and one
recommendation of the draft.  it is not something the ietf should be
saying.  see thomas's draft.

randy

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 25 Sep 2010 22:02:53 -0700

"Effort must be put forward to minimize the impact of IPv6
   deployment to the routing subsystem."

I believe a lot of us think more effort needs to be put into making a
bigger impact on the routing system :)  ... but seriously, the IPv6
routing system is not the problem, it is the IPv4 routing system that
is causing real growth in the DFZ.  It is the IPv4 routing system that
did not have enough address which required CIDR, and it is the IPv4
routing system that is going to continue to grow as the secondary
market for /24s starts to pick up.  Please note, IPv6 and its strong
aggregation model is the solution for your IPv4 routing system / DFZ
problems... in the end.

"this document addresses the problem of routing
   table size by examining steps to minimize the impact of Multi-homing
   and Traffic Engineering, two widely implemented features that provide
   enhanced network resiliency and traffic path control."

First, I don't believe the full contents of this document deliver on
this introductory statement ("traffic engineering" is only mentioned
once).  Second, I believe this situation exists and is impactful in
IPv4, not so much in IPv6.  I agree that it would be bad if we had as
many /48s as we have /24s.   I believe the arguments laid out are
about all the problems with IPv4, yet it only offers IPv6 solutions.
IPv6 already has strict aggregation.  Yes, PI /48s are a blemish in
that design ... but i have seen more than one enterprise network, not
an ISP, with /32s.... pick your poison.

IMHO, this draft simply says RFC 4632 and 1887 are good, and PI is bad. Right?

Today in IPv4, i originate nearly ~30 prefixes for the purpose of TE
(which is tied to NAT) and the result piece meal allocations over the
last 10 years.  In IPv6, i announce 1 /32 to the DFZ and a handful of
/48s will be announced to my ISP for local on-net ISP TE, not DFZ
growth.

Cameron

---

From: Tony Li <[email-masked]>
Date: Sat, 25 Sep 2010 22:10:56 -0700

> not about architecture.  glad to seee you have changed on that one.

More accurately, I was taking a sarcastic jab at certain parties within the IETF who, both individually and collectively, are unwilling and unable to make architectural decisions.

Yes, they are the hard calls.  They are the ones that require adult leadership.  The ones that have implications, far and wide.  They are Real Decisions that may result in discomfort or hardship for some.  They will be politically unpopular.  But they have to be made for us to make progress.  Someone has to steer.  The alternative is anarchy.

Someone has to steer the bus.

Tony

---

From: Tony Li <[email-masked]>
Date: Sat, 25 Sep 2010 22:20:19 -0700

On Sep 25, 2010, at 10:02 PM, Cameron Byrne wrote:

> ... but seriously, the IPv6
> is causing real growth in the DFZ.  

It is true that IPv4 has a higher absolute number of prefixes.  However, it is IPv6 that has the far higher growth rate, which is disturbingly familiar to those who recollect the early days of IPv4.  We're replaying the same movie, without the benefits of aggregation.

> It is the IPv4 routing system that
> market for /24s starts to pick up.  

It was the lack of aggregation that forced IPv4 into CIDR and topological aggregation.  

> Please note, IPv6 and its strong

The fact of the matter is that IPv6's growth rate is out of control.  There is no "strong aggregation".  If there were, the measures that we're recommending would not be necessary.

> IMHO, this draft simply says RFC 4632 and 1887 are good, and PI is bad. Right?

That, and that we need to act accordingly.  We need strong aggregation, somehow.

Tony

---

From: Gert Doering <[email-masked]>
Date: Sun, 26 Sep 2010 11:40:46 +0200

Hi,

On Sat, Sep 25, 2010 at 10:20:19PM -0700, Tony Li wrote:
> The fact of the matter is that IPv6's growth rate is out of control.  

Indeed: IPv6 is still not growing fast enough.

We want to reach IPv6 saturation: every network out there has IPv6 - and
that translates (roughly) to "about IPv6 prefix per active AS".  We're
at about 1/10th of that, and have a long way to go.

Now, of course, we could ask all those BGP-multihomed IPv4 leaf ASes
to change their business model, not run BGP for IPv6, and not insert 
their own IPv6 prefix into the global table.  But why would they listen?

So what's the message going to be?

  "deploy IPv6 *now*"

or

  "oh, well, your current business model how your network is connected to
   the Internet is incompatible with the IETF's ideas about IPv6, and while
   we have no alternative for you, please deploy IPv6 anyway"

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Randy Bush <[email-masked]>
Date: Sun, 26 Sep 2010 07:44:41 -0400

> More accurately, I was taking a sarcastic jab at certain parties
> within the IETF who, both individually and collectively, are unwilling
> and unable to make architectural decisions.

actually, you said the ietf was not allowed to do so since kobe/92 as an
argument against my attempting to do so.

randy

---

From: Michael Sinatra <[email-masked]>
Date: Sun, 26 Sep 2010 02:11:39 -0700

> the benefit of that experience, and that it keeps away from

I heartily agree, and I would support a statement from the IETF that 
carefully laid out the implications.  I think these are well-known in 
the ops community, but it doesn't hurt to say them again.

However, I also think the IETF can do better than say "let's go back to 
the good old PA days."  Either offer a set of solutions (including 
perhaps something that limits how many prefixes an AS can orginate in 
IPv6).  The shift toward PA addressing can be one of several options. 
Then let the ops communities and RIRs choose the options.  The other 
possibility is to keep quiet and let the other communities come up with 
options.

> topic in the IRTF and IETF for ten years and more, and it's hard.

You'll get no argument here.  The general issue of providing a massively 
scalable address space while limiting the DFZ routing table is a very 
hard one--and it demands difficult solutions.  I very much appreciate 
the work the IETF is doing toward this end.  At the same time, I don't 
think the current draft under consideration moves us any closer to 
solving the problem.

michael

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 26 Sep 2010 10:29:49 -0700

On Sep 26, 2010, at 2:11, Michael Sinatra <[email-masked]> wrote:

> I heartily agree, and I would support a statement from the IETF that carefully laid out the implications.  I think these are well-known in the ops community, but it doesn't hurt to say them again.
> 
> However, I also think the IETF can do better than say "let's go back to the good old PA days."  Either offer a set of solutions (including perhaps something that limits how many prefixes an AS can orginate in IPv6).

Given that there's no real bound on getting additional ASes I'm not sure that heading down that road has the implication you think it does. Someone who qualifies for one as qualifies for more.

>  The shift toward PA addressing can be one of several options.

Networks that need to multi home in v4 are going to need to in v6. So long as we acknowledge that reality we're fine.

> Then let the ops communities and RIRs choose the options.  The other possibility is to keep quiet and let the other communities come up with options.
> 
>> 3. Finally, you say:
>> 
> You'll get no argument here.  The general issue of providing a massively scalable address space while limiting the DFZ routing table is a very hard one--and it demands difficult solutions.  I very much appreciate the work the IETF is doing toward this end.  At the same time, I don't think the current draft under consideration moves us any closer to solving the problem.
> 
> michael
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Tony Li <[email-masked]>
Date: Sun, 26 Sep 2010 11:18:30 -0700

> argument against my attempting to do so.

Again, that was sarcasm, pointing out that those who are responsible for progressing the architecture mostly seem to inhibit progress.

Tony

---

From: Randy Bush <[email-masked]>
Date: Sun, 26 Sep 2010 14:32:55 -0400

> IPv6 and its strong aggregation model is the solution 

do remind me of ipv6's strong aggregation model.

imiho, two thinks drive the ipv4 routing table growth, multi-homing
(whether PI or punched PA) and st00pidity about routing security.  there
is no cure for either.  the same pressures will be exerted in ipv6.

> IPv6 already has strict aggregation.

it does?

Tony Li wrote: 

> It is true that IPv4 has a higher absolute number of prefixes.
> However, it is IPv6 that has the far higher growth rate, which is
> disturbingly familiar to those who recollect the early days of IPv4.
> We're replaying the same movie, without the benefits of aggregation.

and some of us seem to be trying to play one of the sadder parts of that
movie, classful addressing.

> That, and that we need to act accordingly.  We need strong

forget it.  we ain't gonna get it.  multihoming and st00pidity are gonna
win.

http://archive.psg.com/jsac-deagg.pdf

randy

---

From: Sascha Lenz <[email-masked]>
Date: Sun, 26 Sep 2010 22:37:00 +0200

Hi,

Am 26.09.2010 um 11:40 schrieb Gert Doering:

> Indeed: IPv6 is still not growing fast enough
[...]

single best argument against this draft.
Don't make it any more complicated than IPv4 by now, we need
a better growth-rate / adaption nowadays, not more hurdles for end-users.

No need for any more comments. Everything was mentioned in this thread already.
The draft has no reasonable benefits (in the real world, i'm not saying it does not
make sense theoretically).

> did you enable IPv6 on something today...?

. o O(actually, yes - my mom got IPv6 now, too. Not joking!)

-- 
Mit freundlichen Grüßen / Kind Regards

Sascha Lenz [SLZ-RIPE]
Senior System- & Network Architect

BayCIX GmbH - http://www.baycix.de/
Schillerstraße 2
D-84034 Landshut
Tel.  +49-1520-2773550
Fax. +49-871-9253629

Geschäftsführer Thomas Zajac
Registergericht Landshut
HR B 4878
Ust-Ident: DE200684164

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 26 Sep 2010 23:48:25 +0200

Randy,

The draft proposes to limit PI space allocations in favor of PA space 
for v6. This is by all means a good proposal and therefor I am in full 
support of this draft to proceed.

Contrary to what you seems to be alluding it does not impact operator's 
operational practices nor limits the deployment of v6 in any way.

The main reason why I support this draft is fact that PA addresses when 
used for multihoming can be easily and automatically scoped to the 
extend of it's propagation radius. PI addresses just can't and will 
continue to completely unnecessarily trash global table.

Respectfully,
R.

---

From: Martin Millnert <[email-masked]>
Date: Mon, 27 Sep 2010 00:54:57 +0200

> So: question to the house - should it become a working group draft?

I do not think the current text should become a wg draft.

As my comments are long, I start out with my conclusion:
The draft proposes three actions to be implemented immediately by RIRs:
 1) Hand out IPv6 blocks accommodating for future growth,
 2) Remove IPv6 PI,
 3) Allocate at least /48 to customers with multi-homing requirements

1 is being done today. 
Economics says 2 cannot have the intended consequences, until is
practical and near problem-free to switch between providers. As many
have noted, it is not today.
3 is being done today, but offers no gain over PI multi-homing in
reducing DFZ prefix size.

Provide the tools before the laws! Laws without proper motivation or
tools leads to anarchy and blatant disregard for the laws.

My comments touch three somewhat distinct areas, as per below:
  1) Comment on the IPv6 routing table statistics section,
  2) Comment on cited source draft-narten-radir-problem-statement as
being some sort of scientific basis,
  3) Comment on the PI space pieces of the document.

1) Section 6, Table 1: IPv6 Routing Table Statistics for 2009 [Huston].

As long as prefixes originated by AS:es stay at 1 per AS, this is a
*wanted* result. No problem what-so-ever.  The IETF still wants IPv6 to
be deployed, right? (No buts, yes and no will do at this point. :) )
  6.1 states that 610 new ASNs have started announcing prefixes from
January 2009 to December 2009, announcing 654 new "root prefixes". That
translates to 7.2% more root prefixes than ASNs.  Not a very shocking
number by by measure.

As for more specifics:  This is not a problem today and indications from
the current IPv6 DFZ are very near irrelevant, for two reasons:
  1)  The appropriate filtering that IPv6 allows, few do it. It is an
appropriate response to TE-trigger-happy operators [1],
  2)  The current size of the table is so small, and operational
experience generally very limited thus far, that few networks have made
a big effort to tidy up their announces and allocations (Tele2 is
exemplary in this regard and perhaps Mikael Abrahamsson can elaborate if
desired)

For whatever precision one can do the growth rate extrapolations today,
as in Table 2, it would seem more close to reality to account for the
fact that only 1800 of 35000 ASNs had joined December 2009. Perhaps a
better model to look for, would be is using the 7.2% extra above  as the
prefix-per-AS factor (or better yet, find the DFZ-wide number, and
investigate the > 1 prefix-per-ASN cases a bit as well) and growing to a
limit of #AS-count.
  Even doing so, it would say very little. (For example, we haven't
predicted #AS-count)  Taking table 2 as far as is done in the draft has
very little utility. Throwing darts at some randomly printed numbers on
a dart board seem about equally probable.

2)  draft-narten-radir-problem-statement has expired.  Not familiar with
IETF enough to comment on what effect that has, I'm just noting it.

I would also like to call into question the science that is driving this
draft (and implicitly one of its cited sources).

Essentially we have now a debate over the DFZ size problem and the
update churn problem (BGP convergence).

draft-narten-radir-problem-statement, in section 5, vaugely says:
"Even if the size could be bounded, the amount of work needed to
maintain paths for a given set of prefixes appears to be increasing."

I checked all the sources of draft-narten-radir-problem-statement, and
could not find the supporting science of this statement.
  In section 5.1, however, there is a cited source, a certain [2],
Geoff's average-aspath-length picture, that is actually showing a very
modest increase. The increase is in fact very far below Moore's Law, at
essentially a linear growth at 0.05 ASNs-in-the-aspath per year. 

I too, however, can refer to Geoff Huston data and presentations, and
would like to call on [3], in which this hypothesis that BGP convergence
is getting problematically ever-more increasingly complicated to reach
or calculate was debunked. His own conclusion with regards to his
average-aspath-length picture and the properties of BGP, are, much to
the contrary to that of draft-narten-radir-problem-statement, that BGP
stability is NOT a problem.  The conclusion is that convergence is NOT
proportional to DFZ size.
  In draft-narten-radir-problem-statement the aspath-average-length
picture is instead taken to imply, at least as a supporting argument,
that the internet is falling over. I agree with Geoff in disagreeing
with this.

Now that we can't find any citations supporting the argument that the
internet is falling over due to BGP updates, the only real issue at hand
is routing table size.

Remember, IPv6-operators have still a very effective tool to keep their
routers happy: the filtering of more-specifics.  An AS can decide by
itself between either purchasing more router memory or filtering
more-specifics.  Note well that a PA-space customer having a /48, that
is multi-homed via multiple providers, will not be multi-homed towards
filtering ISPs. However, should they announce their /48 from the PIv6
pool, their announcement will not be filtered by more-specifics
filtering.

I have yet to see any scientifically based calculations on likely prefix
counts in IPv6 as time moves on. I guess no one knows.  I do not share
the urgency expressed in draft-azinger-scalable-addressing-00.txt
regarding this point at all.

3)  The real concern, as I conclude above, should be roots announced
into the IPv6 DFZ.  Whether they get the label PI or a PA is nearly
irrelevant, IMO:
  If we assume for a moment that an organization decides that it
requires by NRO-assured globally (with-high-probability :) ) unique
space of its own administration, not simply because it can, but because
of the associated independence this provides. It will then get said
space. 
  Some organizations might be hindered to participate in the Internet in
the most cost-effective manner, should they have to acquire LIR status
and get PA space instead, but it won't stop them from doing so.  Making
the Internet more expensive and harder to use seems contrary to any
assumed goals of the IETF.  In fact, it is likely preferred if such
organizations that consider PI space in the first place, are able to get
real PI space as implemented today by RIRs (/48s all from few specific
blocks of the v6 space). 

In section 5, the draft says: "It is in the interests of the network
infrastructure to document a best practice for obtaining IPv6 addresses,
and it is recommended that most, if not all, network numbers be
distributed through service providers."

The draft fails to outline how a RIR can ascertain that a organization
is not a "Service Provider" entitled to PA space, should PI be
outlawed. 

The conclusion is then:  Barring any alternatives to having space of its
own administration to support its functions (eg., fail-free automatic
renumbering (prefix translation or what have you) and support of
multi-homing), it seems a bit pointless to outlaw PI.  Similarly,
outlawing stub ASNs and multi-homing seems a bit far-fetched.

Furthermore, IPv6 address allocation policies, at least in the RIPE
region, implement aggregation already today, by reserving nearby blocks
on given allocations to LIRs, as suggested by the document.

Best Regards,
-- 
Martin Millnert <[email-masked]>

[1] http://www.space.net/~gert/RIPE/ipv6-filters.html
[2] http://www.potaroo.net/bgprpts/bgp-average-aspath-length.png
[3] http://www.potaroo.net/presentations/2009-11-04-bgp-stability.pdf
(draft-azinger-scalable-addressing-00.txt cites a slightly more recent
Geoff-presentation which includes this again in
http://www.potaroo.net/presentations/2010-03-04-bgp2009.pdf )

---

From: Michael Sinatra <[email-masked]>
Date: Sun, 26 Sep 2010 18:39:23 -0700

On 09/26/10 10:29, Joel Jaeggli wrote:

> Given that there's no real bound on getting additional ASes I'm not
> sure that heading down that road has the implication you think it
> does. Someone who qualifies for one as qualifies for more.

Agreed.  That was part of what I was getting at when I talked about 
pressure on AS allocation policy.

> Networks that need to multi home in v4 are going to need to in v6. So
> long as we acknowledge that reality we're fine.

Agreed.

michael

---

From: Gert Doering <[email-masked]>
Date: Mon, 27 Sep 2010 12:15:29 +0200

Hi,

On Sun, Sep 26, 2010 at 11:48:25PM +0200, Robert Raszuk wrote:
> extend of it's propagation radius. 

How so?  Either the route is globally visible, or not.  If it's not,
you're not fully independent from the aggregate owner - and this is 
what multihomed customers usually want: even if one of their ISPs
competely breaks down, their Internet connectivity survives (or, at
least, recovers).

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Sep 2010 07:28:10 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Fred Baker
> Sent: Saturday, September 25, 2010 1:04 PM
> To: Brian E Carpenter
> Cc: IPv6 Operations; S.P.Zeidler; IPv6 operators forum
> Subject: Re: [v6ops] I-D 
> Action:draft-azinger-scalable-addressing-00.txt
> 
> >> Overall document:
> We are in fact seeing quite a growth in AS numbers and in 
> requests for PI allocation. You might look at
> 
> The growth rate of the AS number space is not spiking up per 
> se, but it is non-linear, with increases in rate circa 2000 
> (with the dot-com bubble bursting, there was an increase in 
> the assignment rate of AS numbers) and 2009-2010. I would 
> imagine these are not "to get PI space" but "to multihome 
> using BGP". If anything, I see that as the argument for 
> solutions like ILNP or NAT66 (the draft, which does stateless 
> prefix translation, not the idea of making stateful IPv6/IPv6 
> network ADDRESS translators). They enable the transit 
> operators to view their networks as PA while their customers 
> view themselves as pseudo-PI. Yes, it has issues similar to 
> those described in RFC 2993.

This is actually the same situation as for IRON. End user
networks perceive what they get from their IRON service
arrangements as PI, but all that gets presented to the BGP
are highly-aggregated prefixes that are indistinguishable
from PA.

IRON solves the whole package of IPv6 transition and
coexistence requirements - not just bits and pieces like
some others that seem to be getting lots of popular hype.
IMO, it is worth a closer look.

Fred
[email-masked]

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 27 Sep 2010 13:15:31 -0500

There is a similar (perennial) debate within the RIR community about the same issue. Note that not all of the opinions below are mine, I'm merely summarizing:

Q: how do we get as many people as possible to deploy IPv6 as rapidly as possible?
A: education, information, and make it MUCH easier to qualify for IPv6 space than it was to get IPv4 in order to remove any excuse for people to deploy.

Q: What about $special_subgroup_of_internet_users?
A: Sure, let's build a loophole so that it's easier for them to get PI space, the more the merrier!

Q: but what about the DFZ routing table impact of all of this easily-obtained PI space?
A: well, the cost of the space (RIR fees) will limit the amount of "every corner shop gets a /48" so this isn't really as big of a problem as you think.
A2: $RIR doesn't create/govern/dictate Internet routing policy, so that's not really our concern. If it's an issue, IETF and the operator community should address it.
A3: It'd be fine if $BIG_ROUTER_VENDOR and $DEEP_POCKETED_ISP would just upgrade their router hardware/technology instead of being cheap. Moore's law FTW!

Q: Why isn't PD space acceptable as long as IPSs are making it reasonably easy to get?
A: Multihoming is hard (some providers won't accept /48s, even PI, let alone PD subnets from another SP's block)
A2: Rehoming is harder, and makes it "impossible" to tell $ISP that they suck and take my business elsewhere.

As an operator, I do think that there's a vaccum around IETF's view on the PI vs PD debate, and absent any recommendation to the contrary, I see the RIRs continuing to favor making it easier and easier to get PI allocations of IPv6 in the name of providing an incentive to deploy. So I think that a recommendation is necessary to steer the debate as far as IETF is concerned, and I support *a* draft to discuss where we are currently and where we need to go.

That said, I think that this document's recommendations are a bit simplistic, and it needs to discuss some of the known issues being covered in places like the RRG (RFC5887, for example) rather than just making a pronouncement that "it must be done thusly" without any solution nor discussion of the reason why it's not being done like that already.

Thanks
Wes George

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Sunday, September 26, 2010 5:48 PM
To: [email-masked]
Subject: Re: [v6ops] Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt

Randy,

Respectfully,
R.

This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Tony Li <[email-masked]>
Date: Mon, 27 Sep 2010 12:34:09 -0700

Wes,

> That said, I think that this document's recommendations are a bit simplistic, and it needs to discuss some of the known issues being covered in places like the RRG (RFC5887, for example) rather tha…

Thank you, I think that's a constructive comment.

You're correct, our draft is NOT an attempt to describe the problem and all of the aspects of the problem.  It is simply a proposal for a solution.

I think that there is value in doing the survey document that you propose, but I'd suggest that it should actually be a separate document, independent of any solution.

Would this work for you?

Regards,
Tony

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 28 Sep 2010 14:35:18 -0500

-----Original Message-----
From: Tony Li [mailto:[email-masked]]
Sent: Monday, September 27, 2010 3:34 PM
To: George, Wes E [NTK]
Cc: [email-masked]
Subject: Re: [v6ops] Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt

Wes,

[[WEG]] My point was that a proposal for a solution without acknowledgement that there's no easy solution (and discussion of common exceptions) risks irrelevance. This is because it makes it seem like we haven't actually considered the many angles of this problem and are content to simply tell people to do it a certain way even if that's not actually tenable given the current routing architecture and standards. I don't think that this necessarily requires an exhaustive survey of all possible issues, just a summarization of the big ones that have to be taken into consideration when recommending a solution to this problem, and which ones we're at least supposedly working to fix.
I don't mind if this draft takes the stance that these are the things which can/should/must be done *today* to improve routing system scale, and then referring to RRG docs as to the things which must still be addressed to further improve things since these things won't get us far enough. However, the recommendations in the draft are not necessarily implementable today. I'd refer you to Martin Millnert's message from Sunday as to why the current draft somewhat misses there, and there have been other good comments to that effect as well.
Put bluntly, if it were this simple, we'd already be doing it this way, but we're not.
At a minimum, multihoming, TE deaggregation, and renumbering would need to be covered, not just from the perspective of their contribution to the route scale problem but to make a recommendation in those cases in order to strike the balance between scalability and required functionality?
For example: "Service providers will allocate /48's to their customer organizations with multi-homing requirements." Ok, great, but the follow-on to that is some sort of a recommendation about what prefix lengths SPs should (not) filter at AS boundaries to make that recommendation workable, and why this is better for scale than PI space of the same size.

[[WEG]] Why do we need another separate survey/problem statement document? We've covered a lot of it in RRG and its cited documents, so I feel like we'd be retreading it (and therefore likely retreading a lot of the same arguments) without actually getting any closer to a solution.
In other words, we know the problem(s). We don't need more problem statements any more than we need oversimplified recommendations that can't actually be applied. We need to actually start making decisions and implementing fixes, because I'd argue that the community has already sort of reached equilibrium in how they're going to implement absent any new solutions. Therefore, this draft is either premature, in the wrong WG, or needs to cite whatever efforts are in progress to fix these issues (ie, wherever AIS and renumbering, if not ILNP end up being worked in IETF) to justify why a change in current process is being recommended.

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 28 Sep 2010 13:24:31 -0700

Hi Wes,

> [[WEG]] Why do we need another separate survey/problem statement document?

Well, you've asked us to discuss the issues surrounding the problem and why things are the way they are.  I see that as fair.  I don't see that it's specific to our proposal, and thus would like to factor it out.

This should not be a big deal.

Consider the case where someone else proposes a different solution.  Should they repeat the entire discussion?

Tony

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 28 Sep 2010 17:22:26 -0500

-----Original Message-----
From: Tony Li [mailto:[email-masked]]
Sent: Tuesday, September 28, 2010 4:25 PM
To: George, Wes E [NTK]
Cc: [email-masked]
Subject: Re: [v6ops] Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt

Hi Wes,

[[WEG]] No, they shouldn't. I agree that a general overview is not appropriate for your draft, but as I said, that already exists, so you shouldn't have to repeat the entire discussion either, especially given your intimate involvement in the current one. ;-)
So let me clarify. I want you to discuss the issues surrounding the problem and why things are the way they are specific to your solution. You already cover how different things contribute to the problem in your draft. I'm more looking for additional discussion on the solution side. How does your recommendation solve some of the problems, what does it not solve, what exceptions to your rules do these problems create, and how should people handle those exceptions? Explain to the reader not just why making the recommended changes are beneficial, but also what's different from today that makes implementing the recommendations less onerous as time goes on.

That may be as simple as saying - "stop doing PI - we know renumbering sucks, but we're working to fix it here [reference]" instead of just "stop doing PI".

And if [reference]=null, we have a much larger problem.

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 28 Sep 2010 15:33:05 -0700

> And if [reference]=null, we have a much larger problem.

Ok, then we have a much larger problem.

If we work on renumbering, we get complaints that "renumbering is too hard, so we want PI".

If we work on locator/ID split, then we get a large set of complaints, mostly of the form "your proposal would require changes".

In the global scope of (Internet community, operators, IETF, vendors, etc.) there is no direction in which we can make progress.  All proposals will inconvenience someone, if only because they require change.   As a result, all we get is "no thank you".

If we do nothing, where things will break first is in the operator's backyard.  This makes it your call.  How do we move forward?

Tony

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 28 Sep 2010 21:25:07 -0500

-----Original Message-----
From: Tony Li [mailto:[email-masked]]
Sent: Tuesday, September 28, 2010 6:33 PM
To: George, Wes E [NTK]
Cc: [email-masked]
Subject: Re: [v6ops] Fwd: I-D Action:draft-azinger-scalable-addressing-00.txt

If we work on renumbering, we get complaints that "renumbering is too hard, so we want PI".
[[WEG]] I'd view this as a sign that we haven't found a good solution to renumbering. I don't think that we'll necessarily find a perfect solution that will prevent this response, but not working on it because people whine about it isn't a good solution either. If we don't want everything to end up PI, we need a solution for renumbering, because at least then we can say "don't do PI" knowing that we've at least partially addressed the concern. Though perhaps L/I split will help to kill 2 birds with one stone...

If we work on locator/ID split, then we get a large set of complaints, mostly of the form "your proposal would require changes".
[[WEG]] omelet...broken eggs...etc. I understand being resistant to change, but most proposals, LI split or otherwise require some sort of change to the existing system, it's just a question of where. When change is unavoidable, there are two categories - those who are willing to move past that and help to come to a good solution, and those in denial.

In the global scope of (Internet community, operators, IETF, vendors, etc.) there is no direction in which we can make progress.  All proposals will inconvenience someone, if only because they require change.   As a result, all we get is "no thank you".
[[WEG]] Ultimately, we have to set out in a direction, even if it turns out to be the wrong one. Right now, we seem content to continually define and redefine the problem and repeatedly discuss a possible solution set without actually making any decisions on a solution. Rough consensus by definition will inconvenience multiple someones.

If we do nothing, where things will break first is in the operator's backyard.  This makes it your call.  How do we move forward?
[[WEG]] Step 1, admit we have a problem. :-) I think that the operator community has been pretty clear in voicing this concern and the fact that we need a solution.
Seriously, short term, we define what we want to do in terms of addressing as you have started to do in this draft, to give the RIRs and operator community some guidance where it is lacking today. But we need to do it with the addition of discussion where we know it isn't actually feasible without other work being done. That will help reinforce the point that we do have a larger, longer-term problem to deal with here.
Then we need to actually solve the longer term problem. AIS, renumbering, ILNP. Get them into IETF WGs and get more people working on them. They may not be the best solutions, and they may not even represent a consensus in RRG (if such a thing exists), but they're a start. We'll either refine them into something that solves enough of the problem so that most people can support, or we'll find that it's the wrong direction, but we can't keep doing nothing. I can only hope that as this stuff transitions from IRTF/RRG into IETF that we get away from the infighting about whose idea is better and start working towards a common goal.

Wes George

---

From: Tony Li <[email-masked]>
Date: Tue, 28 Sep 2010 21:16:37 -0700

> I can only hope that as this stuff transitions from IRTF/RRG into IETF that we get away from the infighting about whose idea is better and start working towards a common goal.

Fine words.  Which part of human nature are you expecting folks to give up?  Ego?

I've been working on this problem since 1992, and I still have precious few allies.

Tony

---

From: Fred Baker <[email-masked]>
Date: Wed, 29 Sep 2010 05:17:34 -0700

On Sep 26, 2010, at 5:02 PM, Brian E Carpenter wrote:

> On 2010-09-25 18:29, Fred Baker wrote:
> In its present form, no.
> A draft entitled "Operational implications of various IPv6 address
> assignment approaches" would be a fine thing to adopt.
> 
>   Brian

In the collective opinions of the chairs, this pretty much sums up the response to the question.

---

From: Rémi Després <[email-masked]>
Date: Wed, 29 Sep 2010 14:36:26 +0200

Le 29 sept. 2010 à 04:25, George, Wes E [NTK] a écrit :

> ...
> [[WEG]] I'd view this as a sign that we haven't found a good solution to renumbering. I don't think that we'll necessarily find a perfect solution that will prevent this response, but not working on it because people whine about it isn't a good solution either. If we don't want everything to end up PI, we need a solution for renumbering, because at least then we can say "don't do PI" knowing that we've at least partially addressed the concern.

You may be interested in an approach to renumbering proposed in draft-despres-softwire-sam-01.
Its sec. 3.3 is titled "Multihoming and Renumbering with PA Prefixes".

It implies an added feature in hosts that need to take advantage of multihoming , e.g with shim6, but it is a simple feature to add AFAIKT.
This being done, everything else is simple to operate and scalable (stateless operation).

So far, it has been difficult to draw attention to this solution, but I already received encouragements from a couple of influential IETF individuals, and plan to pursue. 

> Though perhaps L/I split will help to kill 2 birds with one stone...

In my understanding, too complex, in particular by its lack of incremental deployability.

Regards,
RD

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 29 Sep 2010 14:48:17 +0100

> In the collective opinions of the chairs, this pretty much sums up the response to the question.

I would very much like to see a draft along these lines.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 25 Sep 2010 23:35:01 +0100

On 25/09/2010 23:10, Tony Li wrote:
> Construction is putting them there.
> 
> If it would help the discussion, we could easily couch the discussion in
> the euphemisms of graph theory, but that would seem disingenuous.  We
> would rather offer the blueprints.

Tony,

I believe Randy is correct on this point.  The critical part of this
document is the section entitled "Recommendations" which is a statement on
the topic of addressing policy, pure and simple.  Addressing policy is just
not the responsibility of the IETF.

If you word it differently, it may work better.  E.g. if you tabulate the
baseline ipv6 PA allocation and PI assignment sizes from each of the RIRs,
then note that they are - or are not - compatible with the routing /
architectural issues noted in this document, and that should any move occur
to change these standard block sizes, that the architectural concerns of
this document or its successor should be noted.  Would this not say what
needs to be said, except that you're no longer issuing a direct policy
mandate to the RIRs?

Also, where did you pull the /32 and /48 figures from (and don't answer
"from current addressing policy, of course")?  If you're going to make a
specific recommendation on the basis of architectural concerns, would it
not be advisable to give specific reasons for the exact numbers chosen,
without so obviously looking into the can to see what people are already doing?

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 25 Sep 2010 21:22:04 +0100

> Again, I hope you're correct, but why not document the fact that it's

Because this is documented practice in the RIR community, and has been for
years?

Stepping back a little, I'm not quite sure what the purpose of this draft
really is.  Is it just to provide the IETF's stamp of approval for the
actual ipv6 assignment and allocation strategies used by the RIRs since the
year dot, or am I missing something obvious?  If this is the case, couldn't
the document be shortened to about 2 paragraphs?

On the issue of PI, so long as there is no other viable means of
multihoming, PI will be assigned copiously.  And as the RIRs implement
bottom-up policy, it's not likely that these policies will change without a
good quality alternative in place.

Declaring that PI is a Bad Thing is not helpful.  We already know it's bad.
 It's just there's no other viable way to multihome right now.

Nick

---

From: Randy Bush <[email-masked]>
Date: Thu, 30 Sep 2010 13:55:30 +0900

> Declaring that PI is a Bad Thing is not helpful.  We already know it's
> bad.  It's just there's no other viable way to multihome right now.

not precisely.  hole-punched PA.  same result in size of routing table,
of course.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 30 Sep 2010 12:31:02 +0100

Mmmm, delayed email.  Sorry about any context problems which this and the 
other email just delivered to v6ops@ietf might have caused.  FWIW, these 
emails were written 5 days ago, and most of the content appeared on 
v6-ops@cluenet anyway.  Pls to ignore.

Nick

-- 
Network Ability Ltd. | Head of Operations      | Tel: +353 1 6169698
3 Westland Square    | INEX - Internet Neutral | Fax: +353 1 6041981
Dublin 2, Ireland    | Exchange Association    | Email: [email-masked]