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

[Martin Millnert <[e-mail]>]

On Fri, 2010-09-24 at 23:29 -0700, Fred Baker wrote:
> 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 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 <[e-mail]>

[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 )


> 
> I'll listen to the discussion and count yes's and no's (which if you would prefer you can send to [e-mail] to avoid cluttering the mailing list) next weekend.
> 
> Begin forwarded message:
> 
> > From: [e-mail]
> > Date: September 24, 2010 12:45:06 PM PDT
> > To: [e-mail]
> > Subject: I-D Action:draft-azinger-scalable-addressing-00.txt 
> > Reply-To: [e-mail]
> > 
> > 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
> > [e-mail]
> > 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
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops