Subject: RE: Draft: PI addressing derived from AS numbers

From: "Michel Py" <[email-masked]>
Date: Thu, 30 Jan 2003 08:26:52 -0800

Pekka,

This is an interesting draft, thanks for submitting.
I do like the fact that it does indeed try to limit the number of
prefixes announced but I think it's a terrible idea at the moment,
though.

This would create a terrible precedent. In the long run, we can expect:
- People that have swamp space lobbying for v6 PI also, on the grounds
that if people that have an ASN get v6 PI space they should get it too.
Actually, swamp space holders have on paper a better reason than ASN
holders to get v6 PI space.
- AS numbers being extended to 32 bits. Then people that get ASNs above
64k will also strongly lobby to get PI on the grounds that it's not fair
that early adopters only get it.

If we had no other choice, I would support this as being not as bad as
unrestricted PI. But it's still unaggregatable, and we do have a better
choice: GAPI.

If we come to the point where the community decides that indeed the
deployment of IPv6 is being hindered by the lack of a solution (and
we're not there yet), we could then discuss about adding a clause to
GAPI that limits the initial allocations to organizations that already
have an ASN.

Michel.

---------------------------------------------
From: Pekka Savola [mailto:[email-masked]] 
Hello,
I've sent a short draft (7 pages) to Internet-Drafts for publication.
I propose an automatic allocation of /48, /40 or /32 (based on how the 
community feels) of PI addresses if you have an AS number.
A 16-bit AS number in the range 1 - 2^15, that is.  This is just to
enable
IPv6 multihoming temporarily, until another mechanism is devised, to
those
end-sites that already do it today.  This is kind of a "stop those lame
excuses now, please" -solution.
Note: personally, I think ASN-PI like this is not a good idea, but it's
at
least better than some others, like breaking aggregates or doing stuff
like that -- this is controlled, after a fashion.
Until publication, it's available at:
http://www.netcore.fi/pekkas/ietf/draft-savola-multi6-asn-pi-00.txt
And the abstract is:
   In IPv6, the current IPv4 site multihoming practises have been
   operationally disabled, to prevent a creation of an unmanageable
   swamp of more specific routes.  Some argue that the lack of a
   comprehensive site multihoming solution is hindering the deployment
   of IPv6.  This memo presents a few proposals for end-sites with
   autonomous system (AS) number to be able to derive a provider
   independent block of addresses from the first half of the 16-bit AS-
   number space.  This could enable a temporary IPv6 site multihoming
   solution for those that already employ similar mechanisms in IPv4.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Jan 2003 21:15:08 +0200 (EET)

To re-iterate (for all the w.g.), I don't like the approach myself, but I
fail to see good alternatives, _if_ something that works out has to be
pushed out soon.  If there's no such need, fine.

Btw, in a private comment a few bad typographical errors were pointed out
to me, so I updated the draft about 2 hours after I sent the message here.

> holders to get v6 PI space.

Uhh, what do you mean by swamp space holders, those that don't have ASN?  
Multihomers that use private ASN's or static routing and have their
primary ISP advertise a more specific?

> - AS numbers being extended to 32 bits. 

If I have any say, I wouldn't extend AS number space at all, but I guess
that's another issue.. instead of making policy people try to solve a
problem with technology.  A bad mix.  Perhaps some serious time for
IAB/IESG architectureal guidance.  But I digress...

> Then people that get ASNs above

I agree, but when that happens (3+ years), I'm hoping there are already
some mechanism(s) to do at least some multihoming.

The main point with the mechanism is that I don't see it likely that new,
really significant, big enterprises just crop up with a timescale of 3-5+
years and _require_ this kind of mechanism.  (As could be argued by many
enterprises of 10,000+ employees, today.)

> unrestricted PI. But it's still unaggregatable, and we do have a better

GAPI is a new term to me.  I assume this means Geographically Aggregated
PI.  That kind of proposals have some really bad drawbacks, and I'm having
difficulties imagining those ideas materializing.
 
> we're not there yet), [...]

Well, maybe it is hindered, at least on paper.  Some just make lame 
excuses for not getting into IPv6.  For some, these problems are real, of 
course, but hardly something to delay IPv6 migration..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Eliot Lear <[email-masked]>
Date: Thu, 30 Jan 2003 19:04:58 -0800

Ultimately the same (or very similar) routing decision process will 
occur, with the same complexity and the same problems, so I would agree 
with you assessments.  Thus, while I understand the reasoning for the 
proposal, I would argue that perhaps the best thing to do is nothing 
until we have something better.  That may be a while.  Oh well...

But thanks..

Eliot

---

From: Peter Tattam <[email-masked]>
Date: Fri, 31 Jan 2003 14:38:45 +1100 (EST)

I will be working to progress my recent work to draft stage over the next few
months.  I have reason to beleive it will offer the flexibilit yof BG and PI
space without impacting the current routing infrastructure.

I would suggest holding off on such an interim solution as you are suggesting
it will be a step backwards, not forwards.  I agree that doing nothing is
better than this proposal.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: "Michael H. Lambert" <[email-masked]>
Date: Fri, 31 Jan 2003 09:52:21 -0500

> pushed out soon.  If there's no such need, fine.

Would it make sense to push Pekka's draft along the experimental track in 
the spirit of RFC 1797 (the 39/8 subnet experiment)?  It may not be an 
optimal solution, but it would give the community some breathing room while 
better methods are developed.  I concur with Pekka that sunset provisions 
are important.

Michael

+-----------------------------------------------------------------------+
| Michael H. Lambert, Network Engineer           Phone: +1 412 268-4960 |
| Pittsburgh Supercomputing Center               FAX:   +1 412 268-8200 |
| 4400 Fifth Avenue, Pittsburgh, PA  15213       [email-masked]        |
+-----------------------------------------------------------------------+