Subject: RE: [[email-masked]: PI addressing in IPv6 advances in ARIN]

From: [email-masked] (Noel Chiappa)
Date: Sat, 15 Apr 2006 11:34:20 -0400 (EDT)

> From: "Tony Hain" <[email-masked]>

    > portability could be one outcome.

Given that the point of this PI exercise seems to be to increase the
viability of IPv6, maybe you should go for it, and add number portability
too? That should further increase the viability.

    > it is manageable to deal with porting between providers within a city,
    > but not between cities

Metro addressing! All those old classics are making a comeback...

    > those groups couldn't see the forest for the trees. They were
    > absolutely technically informed, but completely unwilling to listen to
    > the big picture political reality. 

And the current group has a superior grasp of the all-around picture? Ah, got
it.

    > an attempt to get in front of what is a growing wave of demand to head
    > off an outright pronouncement from outside the community which will
    > result in number portability.

Since there's no technical difference between PI and number portability, I
expect approval of PI-space will lead to portability anyway.

Yes, the current criteria for PI-space are rather limited, but since there's
no particular technical rationale for picking /N versus /M, I expect to see a
salami-slicing political debate in which people will demand smaller and
smaller blocks be supported, because to do anything else is dumping on the
"little guy", while letting the "big players" have acess to something the
small players don't.

Sigh, we're going to be paying the price for not (long ago) setting up a
charging system for having a route be visible in the "default-free zone".

    > there is a middle ground that gets messy because it does not have
    > simple solutions without constraining topology. 
    > ...
    > That set of requirements leads to structured allocations and topology
    > constraints. Both sides will have to give

I'm curious to hear what the ISP's will have to say about this "topology
constraints" stuff...

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 15 Apr 2006 09:54:36 -0700

> too? That should further increase the viability.

The IETF is an engineering organization. Engineers are good at
engineering, not so good at setting policy. Let's assume that the policy
is driven externally, and that engineers cannot impose their preferred
solution. Some will say that the sky has begun to fall, and retire in an
ivory tower of gloom. The optimistic engineer, on the other hand, will
take that as a challenge. 

Clearly, the current set-up based on BGP and "default-free" tables is
not set to absorb more than a small number of PI prefixes -- maybe a few
thousands, maybe a few tens of thousands, certainly not a few hundred of
millions. But who says that we cannot change it? Number portability,
after all, only requires a layer of indirection. We can certainly
engineer that!

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 15 Apr 2006 19:49:39 +0200

On 15-apr-2006, at 18:54, Christian Huitema wrote:

> millions. But who says that we cannot change it?

10 years of discussions within the IETF and basic information theory  
say routing won't work on the scale of the current and future  
internet without aggregation with reasonable hardware price/ 
performace ratio assumptions.

> Number portability,

And we have. It's called the DNS. But it seems people need more  
indirection. Where do we draw the line? Portable street addresses?  
Portable GPS coordinates?

It's really too bad, because we almost have what we need to pull this  
whole scalability thing off in IPv6: stateless autoconfig, DHCPv6  
prefix delegation, dynamic DNS updates, MIPv6, shim6. The only thing  
missing is some finishing touches (ok, more than "some" for shim6,  
but it is moving along) and for firewall vendors to jump on the  
bandwagon and move away from hardcoded IP address based filters.

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 15 Apr 2006 20:23:39 +0200

> On 15-apr-2006, at 18:54, Christian Huitema wrote:
[..]
> bandwagon and move away from hardcoded IP address based filters.

Iljitsch, please stop seeing the 'bad' side about this. If people really
are going to stick millions of routes into BGP they will hang themselves
anyway as they will be the ones having to buy the fat new shiny routers
for lots of cash, which can then be provided by all those nice
consultants and vendors who thrive on things like that. The funniest
thing is that due to the open process we can always point fingers *evil
grin*.

But I don't see a problem at all as I mentioned before.

The bright point is that the PI space provides something really good: 
 - Folks will have their Globally Unique address space.
On which they can rely that it will be theirs for a long time.
Which means that it can be used as a perfect identifier for setups like
shim6.

The "PI space" will then reside in their own network, while when the
packet goes over the internet, at the moment it crossed their border,
the packet gets translated to the address space of the upstream
provider, when arriving at the other side it gets translated back into
the "PI space".

This will make them happy and keep the routing table very small. Just
like the original idea of doing IPv6 PA was :)

Greets,
 Jeroen

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Apr 2006 15:48:36 -0400

> And we have. It's called the DNS.

no it's not.  DNS sucks for that.  it's too slow, too likely to be out of sync.
DNS names are the wrong kinds of names for this.  the protocol is poorly
adapted for this purpose, the infrastructure is worse.

I agree with Christian.  we can build indirection into the routing 
infrastructure.   it's probably the right way to go. 

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 17 Apr 2006 12:56:11 -0700

> infrastructure.   it's probably the right way to go.

One could argue that we already have. It's called MPLS...

Tony

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Apr 2006 16:37:26 -0400

> One could argue that we already have. It's called MPLS...

sort of.  MPLS with globally-scoped tags,  and a database of 
coarse (think subnet sized) identifer to locator mappings that is 
distributed via BGP.  border routers look at the destination host
identifier, find the set of locators that correspond to it, and pick
the best locator given current routing conditions.

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 17 Apr 2006 12:20:05 -0700

> Metro addressing! All those old classics are making a comeback...

Ideas never die; some are just ahead of their time. ;)

> And the current group has a superior grasp of the all-around picture? Ah,

I didn't say that. Note they did not specify exactly how they were going to
do it, just that it would be done. If the technical group has approaches
that are better than first-come from a swamp-block, now is the time to get
them on the table. They have called the bluff of the PA-only tantrum and
will do random assignments if nothing better emerges. 

> "little guy", while letting the "big players" have acess to something the

I happen to agree with you here, which is why I have been advocating a
particular geo approach that can work with existing BGP and be scaled up and
down as far as necessary to contain the routes. Unfortunately to date, the
IESG has not understood the necessity to have a working group to refine a
globally acceptable approach.

> charging system for having a route be visible in the "default-free zone".

The existence of a "default-free-zone" was long ago relegated to myth
status. There are different views of what this mythical entity contains, so
by definition there is no single zone. Rather than fight to maintain an ego
driven myth, we should be accepting reality and organizing structure in what
appears where. 

> I'm curious to hear what the ISP's will have to say about this "topology

They never like it because it restrains their freedom. At the same time the
"carrier" side of the house has learned to deal with it in the PSTN context,
so the "ISP" side will be getting an education in dealing with
customer/governmental requirements. 

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Apr 2006 23:08:13 +0200

On 17-apr-2006, at 21:20, Tony Hain wrote:

> I have been advocating a

Since this has been coming up from time to time for over a decade,  
why not look at it, document the results and be done much faster when  
it comes up again and again the following decade, I would think.

But I also happen to think that aggregation inside ISP networks based  
on geography (which has little to do with "metro addressing" as  
proposed but never worked out in detail 10 years ago) can actually  
work. Unfotunately when it was time to decide on an approach to  
further develop in multi6 there was no support for this so shim6  
happened (which is also a good approach in its own right) but now the  
operator / policy making community balks at shim6...

Anyway, here's the draft once again for those looking for some  
reading material:

http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt

But it's really a no-brainer: with "straight" PI we know that smarter  
routing is never going to help us for those prefixes. But if PI  
addresses are given out in _some_ aggregatable we at least have a  
chance that we can clean up the routing tables later. Geography makes  
sense to aggregate on as a next best thing when provider aggregation  
can't be used because it optimizes for one of the few network  
properties that are more or less constant: the speed of light.

(With apologies to Brian for not having run my 100M BGP table  
simulations.)

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 17 Apr 2006 17:46:23 -0700

> it comes up again and again the following decade, I would think.
That was why I proposed a bof, and will do so again.

Noel Chiappa wrote:
> ...
> Perhaps I'm not understanding your point, but the whole point of my
> comment
> is that there's no "bright technical line" differentiation between one
> size
> and another, and we'll inevitably wind up being forced to support the
> smallest possible one.
>
That was my point as well. Given that all uses of PI are as legitimate as
any other, the issue boils down to finding a way to bucket the results into
manageable pieces that will fit in known routers and protocols. 

> 
> Perhaps the IESG's reluctance is because this now turns into something
> like
> the old (PC-incorrect) joke about the gentleman and the debutante in the
> railway - we've already decided what we are, now we're only haggling about
> the price (or block-size, as the case may be).
>
The first step on the path to deciding price is to do the AA thing and
acknowledge that there is no single global perception of all possible routes
(ie: there are already buckets). Once that is acknowledged, we know the
system doesn't collapse in the presence of buckets, so the next step is to
decide who plays which role in the scenario. The pragmatist says our job is
to find the point of equally shared pain. The ISPs want all the pain to be
at the edge, and randomly assigned PI puts all the pain in the middle. There
are alternatives to be explored. Iljitsch and I have similar approaches
where the basic difference is who gets to decide the blocks and on what
frequency they might change. Either will work, but there may be others that
a working group should evaluate for their trade-offs.

> the best locator given current routing conditions.
My point was that the technology exists. Yours is that it is currently
deployed and operated in a closed manner. I suspect that the difference was
because closed was easier than opening it up to manage a global tag list,
and that sufficient motivation would change that.

Terry Gray wrote:
> ...
> It does make me wonder if there is any hope for resurrection of 8+8...
>
The time for that was before the APIs were defined. At this point it would
need to be 6+10 (though the e.g.b. control-mongering ISPs are pushing to
reduce the amount of space that a sight can have to make it 7+9), but either
way it is nothing more than shim6 being done by the edge routers rather than
the end systems. The application wants persistence and the network wants the
freedom to randomly over-write bits to improve its efficiency (never mind
that the process of deciding and over-writing is inherently inefficient).
Given that the application is closest to the end user, the end user doesn't
care about efficiency unless they are given quantitative feedback about
cost, and the globally distributed cost of a routing slot in a fictitious
single routing zone is difficult to define, the winner should be obvious.

Tony

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Apr 2006 17:27:35 +0200

Keith,
> [course] (think subnet sized) identifer to locator mappings that is 
Haha.  Check out some stuff Professor Dave Cheriton did at
http://www-dsg.stanford.edu/triad/

It smells remarkably like pathalias to me ;-)

Eliot

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Apr 2006 11:42:27 -0400

> It smells remarkably like pathalias to me ;-)

except that I'm not proposing that border routers do source routing, just that
they map from PI identifiers to PA locators and prepend a header that causes
the payload to be routed to the locator.

Keith

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 18 Apr 2006 14:46:15 -0400

On Tue, Apr 18, 2006 at 11:42:27AM -0400, Keith Moore wrote:
> except that I'm not proposing that border routers do source routing,
> just that they map from PI identifiers to PA locators and prepend a
> header that causes the payload to be routed to the locator.

And that sounds exactly like pathalias and what the Usenet/SMTP smart
routers did, yes?  Hopefully though they wouldn't require as much CPU
power to calculate as pathalias database required --- as I recall Erik
Fair at Apple used a Cray for that purpose, because he didn't like
waiting....  :-)

						- Ted

---

From: Keith Moore <[email-masked]>
Date: Tue, 18 Apr 2006 15:45:17 -0400

> routers did, yes?  

not in my recollection.  It's been awhile, but I recall pathalias being
used to do source routing - given a hostname, to specify a complete
path to that host.  (I also recall it sometimes being used to do
rerouting - discarding the current source route and replacing it with
one thought to be better.  It's also my recollection that the latter
tended to cause routing loops and dropped messages.)

I don't recall pathalias being used to replace a global
location-independent identifer with an aggregatable global locator.
UUCP didn't have any such beast.

> Hopefully though they wouldn't require as much CPU
> power to calculate as pathalias database required 

pathalias was trying to add automatic routing to uucp.  we're already
doing routing in the internet, and I don't see how what's being
discussed here will increase the complexity of those computations over
what they already are.  

as far as I can tell, we're talking about ways to make routing
computations _more_ efficient.   adding a layer of indirection that
hides locators from end networks should allow locators to be strictly
PA and even to be renumbered from time to time  without impacting users.

Keith

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 18 Apr 2006 16:16:30 -0400

> Fair at Apple used a Cray for that purpose, because he didn't like
Peter Honeyman optimized my original algorithm considerably; there's even
a paper on it on my web page.  There were two more fundamental problems
that neither of us every really solved.

One is relatively easy today: we didn't have good maps of connectivity for
each site.  Today, though, we have routing protocols that are supposed to
disseminiate such data.  Even now, though, there's a tension between
physical connectivity and policy; we ran into that, too.  The harder
problem, though was metrics.  Simple hop count gave bad results; bandwidth
varied.  (That said, the probability of uucp silently dropping the message
was high enough that maybe we should have stayed with just that as a
metric....)

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Apr 2006 22:21:32 +0200

Steven M. Bellovin wrote:
>> as I recall Erik
> a paper on it on my web page. 

Erik's a patient man, but given the resources he certainly took
advantage of them...

Eliot

---

From: Theodore Ts'o <[email-masked]>
Date: Wed, 19 Apr 2006 12:44:25 -0400

> UUCP didn't have any such beast.

Fair enough.  I was thinking of the rerouting hacks that would replace
UUCP bang paths with a shortcut routing using SMTP mail.  That was
fairly reliable, from my memory.  This probably isn't an exact analogy
for the aggregatable global locator that you were referring to, but it
had that effect, roughly speaking.

						- Ted

---

From: "Erik E. Fair" <[email-masked]>
Date: Tue, 18 Apr 2006 14:53:52 -0700

I'm patient, but when you have a heavily loaded VAX-11/780 (I think
this was before the host apple.com was upgraded to a VAX-8650)
doing netnews, where even the highly optimized "compress" program
beats on the CPU, and a Cray X/MP-48 just sitting there across the
LAN ...

So, I set up a TCP "compression service" set up on the Cray (bits
go in, compressed bits come out; inetd makes this easy and UniCOS
came with the "compress") and blasted netnews batches across the
10Mb/s Ethernet from the VAX and captured the results for transmission
to Apple's UUCP-based netnews neighbors.

It was lots faster that way and it took a large load off the VAX.
Unfortunately, I had to discontinue the practice when some of my
netnews neighbors complained of corrupted batches; it seems that
there were some subtle 32 bit assumptions in compress that I didn't
have the time to track down. Still, it was fun to play with a
supercomputer at a place where they believed in interactive computing,
and didn't charge for CPU time.

Then there was the time I ported pathalias to the Cray ...

	Erik <[email-masked]>

---

From: "Erik E. Fair" <[email-masked]>
Date: Tue, 18 Apr 2006 14:53:52 -0700

Erik <[email-masked]>