Subject: RE: Resolving geo discussions

From: "Bound, Jim" <[email-masked]>
Date: Fri, 11 Apr 2003 17:07:05 -0400

I have to throw in the towel and say I think Tony, Noel and Christian
convinced me.  Geo as core method in our architecture is not going to
fly nor should we try to push this as RFC std. But doing bottom up
probably will happen is my guess.  I think an INFO RFC or BCP would get
consensus here stating the ramifications of using this approach, but its
your own trip.

I would suggest this would put this debate as lets document it and issue
BCP and we move on to solve the problem at hand with architecture we can
review.  Maybe if we had matrix of each one proposed on slide we could
share as idea?  

- We kill this discussion and turn it into work with deliverable.
- We remove it to continue the architecture effort
- And maybe we could produce a doc INFO/BCP that would be useful and the
IETF would think we have some clue as a team to produce something others
can use :--)
- And we don't discuss it for 10 more years and just point to the RFC
which will be useful to those who have children and come here to do work
someday :--)

/jim

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]] 
> Sent: Friday, April 11, 2003 4:24 PM
> To: Iljitsch van Beijnum
> Cc: [email-masked]
> Subject: RE: Resolving geo discussions
> 
> 
> > > We have had this discussion many times in the past 10 years. After
> many
> > > rounds of e-mail, the consensus generally is that if geo 
> is going to 
> > > happen, it will happen "bottom up" and be user driven.
> > 
> > This is news to me. I would really appreciate some pointers to
> archives
> > of these past discussions.
> 
> Try the Big Internet mailing archives:  
> ftp://munnari.oz.au/big-internet/list-archive
> 
> > > For example, one
> > > may see the chamber of commerce of lower Picardy request 
> a /32 from 
> > > RIPE, and use it to provides "independent" /48 addresses to its 
> > > members, using a combination of tunnels and arrangements 
> with local 
> > > ISP. In fact,
> > > there are already a few virtual ISP operating under this model.
> > 
> > So if I want to do this in a slightly larger area, say everything 
> > within a 20000 km radius of The Hague, I could get a larger address 
> > block, say a /16?
> 
> Not really. You will be subject to the same slow-start 
> algorithm as regular ISP. You probably will get a /32 first, 
> and when you will have demonstrated that you serve more than 
> N sites, you will get a /30, etc.
> 
> -- Christian Huitema
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Apr 2003 11:11:20 +0200

Yes, I think it is time to get out an info RFC on this. Indeed I haven't
seen any new arguments for a number of years. We need a brave person to
act as document editor though.

  rian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 14 Apr 2003 13:38:27 +0200

On maandag, apr 14, 2003, at 11:11 Europe/Amsterdam, Brian E Carpenter 

> act as document editor though.

What exactly do we want to be in this RFC?

If it's just "if you're going to do geo, beware of ..." I'll be happy 
to include something like that in the upcoming rewrite of my draft.

Iljitsch van Beijnum

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Apr 2003 15:38:29 +0200

> to include something like that in the upcoming rewrite of my draft.

I think it needs to build on the observation that there is no congruence
between network topology and geography to show that we have no way to make
geo addresses aggregate in practice. It doesn't need to be that long.
But since it's an abstract "why this doesn't work" argument, I think
it needs to be separate from any specific technical proposal.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Mon, 14 Apr 2003 15:10:26 +0100

> it needs to be separate from any specific technical proposal.

Well, geography meets topology at an IX, so the exchange-based addressing
experiments being done by Euro6IX are interesting in this respect,
possibly.   Perhaps Jordi can comment on that.

Tim

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 14 Apr 2003 16:39:35 +0200

Right,

I'm following the discussion in "silent mode", because I've no cycles now with the preparation of several new projects, and the
Madrid Summit, in addition to my regular work in several projects ... not too much !

But I'm sure that other people from Euro6IX can also comment on this.

Anyway, if I survive to my actual 1-hour sleep time per day, at the end of the month, I will try to be more proactive.

Regards,
Jordi

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Apr 2003 17:38:17 +0200

> possibly.   Perhaps Jordi can comment on that.

There's no doubt that if you can persuade all the upstream ISPs to do
the right thing, and persuade all the local downstream ISPs to do the 
right thing, the IX-based addressing model can help a lot (and can simply 
use PA space as if it was PI). But I don't think the economic forces involved
will exercise the required persuasion.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 15 Apr 2003 00:18:44 +0200

On maandag, apr 14, 2003, at 15:38 Europe/Amsterdam, Brian E Carpenter 

>  think it needs to build on the observation that there is no congruence

I disagree. The whole point of this RFC would be to end the discussion. 
That's not going to happen by simply presenting one viewpoint. Either 
it needs to be an overview that lists all the arguments pro and con and 
possibly drawing some conclusions along the way, or if it only presents 
a single point of view it must get into the nitty gritty and not 
suffice with "I know someone in Jakarta who connects to Reykjavik so 
geo aggregation can't work".

Why don't we do some calculations to see how good or bad it can work?

For instance, even in a worst case scenario when distribution of 
interconnection is completely random, there is always some gain to be 
had: if there are m interconnects, having an aggregate point to one 
interconnect and then filter out all routes that are identical to the 
aggregate must save 1/m-th in the routing table size in all nodes 
except the one sourcing the aggregate.

If we accept some constraints, we can do much better. For instance, if 
we use a fully switched network (not inconceivable with MPLS) we can 
have one node that sources the aggregate and holds all more specifics, 
all other nodes only need the aggregate and the more specifics learned 
from the local interconnect, which is 1/m-th of all more specifics on 
average.

In a routed network, the gains aren't as big as all intermediate nodes 
need to know the more specifics for packets that may need to be routed 
through them, but some quick guestimates land around the 50% mark. 
That's 18 months according to Moore, which doesn't sound like much but 
1.5 years interest on the "aluminum factory" as one former boss used to 
call it (our new network cost the same as an aluminum factory (and 
probably used as much electricity too)) adds up to a substantial pile 
of change.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Apr 2003 17:45:47 +0200

> it needs to be an overview that lists all the arguments pro and con and

Of course

> possibly drawing some conclusions along the way, 

It needs to, otherwise it can't be used as a reference to
avoid future repeat discussions.

> or if it only presents
> a single point of view 

I think you mean "a clear conclusion" :-)

> it must get into the nitty gritty and not

Yes, but there is the pesky interaction with economic forces to consider.
That makes it hard to avoid the final conclusion being a judgement.

> from the local interconnect, which is 1/m-th of all more specifics on

I don't think that allows for the economic constraints that
mean that certain traffic is only allowed to travel on links
paid for by certain parties. In other words you can theorize
about some ideal mathematical model, but how do you mix in
the economic constraints? One of today's constraints, for example,
is "get rid of the packet as quick as you can, unless it's going
to my own customer" and that has major impact on the BGP4 topology. 
I think this quickly gets into Research Group territory.

> probably used as much electricity too)) adds up to a substantial pile

But it isn't just Moore's law. It's convergence time. And this is exactly
where we are still waiting for useable output from the Routing
Research Group.

   Brian

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 15 Apr 2003 19:01:37 +0200

> which will be useful to those who have children and come here to do 

Well, what you are saying is along the lines I tried to say in my other 
mail. Although I am not sure a BCP is the right way forward. I think we 
need something that more looks like the scenarios documents from v6ops.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 15 Apr 2003 19:02:17 +0200

Anyone? :-)

- kurtis -

On måndag, apr 14, 2003, at 11:11 Europe/Stockholm, Brian E Carpenter

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 15 Apr 2003 23:14:14 +0200

On dinsdag, apr 15, 2003, at 17:45 Europe/Amsterdam, Brian E Carpenter 

> I think you mean "a clear conclusion" :-)

Do I?

> That makes it hard to avoid the final conclusion being a judgement.

Economy is much like routing: if you get to assign the costs, you can 
pretty much make it do anything.

[...]
>> If we accept some constraints, we can do much better.
[...]

> paid for by certain parties.

I'm only concerned with routing inside individual provider networks, so 
this shouldn't be a problem.

> In other words you can theorize

Yes, this is an important issue. Please read section 10 in my draft, 
but here is my conclusion:

	Since networks can control the level of late exit routing by
	(selectively) de-aggregating and many interconnection (peering)
	agreements call for equal traffic volumes in both directions, the
	potential for changes in the flow of traffic should not adversely 
affect
	existing networks.

> I think this quickly gets into Research Group territory.

Hm, can we afford to wait for results there?

The way I see it, if we start giving out GAPI addresses now, we have a 
few years to come up with good aggregation before we really need it. If 
it turns out that geo aggregation is unworkable a solution like MHAP 
that can use PI addresses without the need to have them in the routing 
tables can still save us without renumbering. Only if that doesn't work 
either the GAPI users need to renumber.

On the other hand, if the IRTF comes up with something good in 3 years, 
everyone who is multihoming using some kind of ad-hoc method such as 
shooting holes in PA will need to renumber at that point for it to 
work. That probably means that very few people will use it as 
renumbering is a huge pain.

> where we are still waiting for useable output from the Routing

Aggregation helps with convergence too.

---

From: Sean Doran <[email-masked]>
Date: Wed, 16 Apr 2003 02:50:33 +0100

WRT geographical address assignments: mutually-hostile
sites overlap physically already, and the incidence of this
is increasing.  Site multihoming approaches which do not
take this into account should already be considered unworkable.

Even perfect GPS knowledge in every device does not
eliminate the need to have a DHCP dialogue or some other
configuration activity in the host or in the network (or both),
in the presence of multiple overlapping administrative domains.

Geographical addressing strategies of any variety must
be able to cope with this sort of thing (think of a set of overlapping
802.1 networks at an IETF venue: one for normal hotel
guests, one for hotel operating activities, and one for
IETF attendees, each with different access and usage policies,
wireless network names, passwords, and inter-network
connectivity), or they are simply uninteresting.

On Tuesday, Apr 15, 2003, at 22:14 Europe/London, Iljitsch van Beijnum 
wrote:

> few years to come up with good aggregation before we really need it. 
> If it turns out that geo aggregation is unworkable a solution like 
> MHAP that can use PI addresses without the need to have them in the 
> routing tables can still save us without renumbering. Only if that 
> doesn't work either the GAPI users need to renumber.

Single IPv6 numbers are not obviously rich enough
to convey information about more than one network attachment
point.  Consequently, things with multiple attachment points
need more than one number (leading to a possible explosion
of addresses in the presence of very rich connectivity),
or distant parties need to be able to map single numbers
to multiple attachment points (leading to a possible explosion
of information in the mapping system), or distant parties
must remain ignorant of the existence of multiple attachment
points (leading to non-optimal routing).

Where there is a mechanism whereby numbered
things acquire their numbers in a more timely and
shorter-term fashion than today's long-term static
assignment to DHCP servers and to some hosts,
then the question of what the numbers are
becomes relevant in analysing the risk of these
explosive increases of connectivity information.

Imagine that we could build a GPS receiver into every single device
that is IPv6 capable.   This does not provide these devices insight
into their network locations, because in a single cubic metre
in a telehousing facility, a device's next-hop might be able to
attach to several providers simultaneously, but it might not
be able to attach to all of the providers at once due to failures,
economics, or policy.    Simply knowing where the device
is physically does not allow a  distant party to make a
good decision about which of several different providers'
first-hop routers is the best next-hop to that physical coordinate.

This is already not a purely theoretical problem.  There are already
many individual cubic metres (and centimetres and even millimetres)
wherein there are growing amounts of numbered things.
Some of these things really do need multiple numbers rather
than clever ways of deriving physical location, particularly 
considering,
for example, virtual routers (e.g. cosinecom.com) participating in
multiple discrete virtual and actual network topologies within
different administrative domains.   This is one way some providers
support VPNs, and there are existing real-world cases of deploying
a virtual router platform into a telco central office.   Other 
providers are
offered a virtual access router which in effect behaves and
is managed as if it were a real physical access router in that facility,
as opposed to being offered ATM or ethernet based aggregation
and backhaul.

If you are doing DHCP or configuration activity in the host,
then you might as well use standard topologically assigned ("PA")
addressing and take advantage of the fact that this just works
for the singly-numbered case, and it is easy to acquire multiple
numbers this way, should the host and the site both support that
and find it useful.

There is so little to be gained for the cost of maintaining
a fine-grained geographical address distribution strategy globally
that, to put it bluntly, nobody who is actually in a position to
support such a thing is likely to be remotely interested in doing so.

> On the other hand, if the IRTF comes up with something good

"The IRTF" is us.   The people overlap is substantial.
There is no magic resource hiding in the IRTF that is not here as well.

>  renumbering is a huge pain.

This is the root of the problem.   "Never renumber" is the wrong 
solution.

	Sean.

---

From: Sean Doran <[email-masked]>
Date: Wed, 16 Apr 2003 03:08:32 +0100

On Tuesday, Apr 15, 2003, at 16:45 Europe/London, Brian E Carpenter 
wrote:

> One of today's constraints, for example,

Hot-potato routing, which you describe reasonably well in
the quote above, is an artifact of the non-use of MEDs.

This is not a very strong requirement, and mostly exists
because of mid-1990s differences in internal metrics between
Sprintlink and InternetMCI leading to the realization that one
could never really rely upon neighbour A's MEDs making sense
in comparison with neighbour B.   Decreasing inter-provider trust
over time also eroded the value of MEDs from other networks,
and ignoring/rewriting them effectively led to mutual hot-potato
routing becoming commonplace.

However, it was never universal, and still isn't.   There are networks
which accept MEDs from e.g. customers, just as there was a network
which did static MED-like multi-exit handling in the PR^H^HRADB.

The BGP4 topology (assuming we could agree on a definition) is
not affected by the MED/no-MED decision because of the inability
to compare reliably and in a useful way MEDs offered by different ASes
announcing the same prefix.

> I think this quickly gets into Research Group territory.

Unless it gets in the way of actual charter-relevant work, I personally
don't mind this sort of discussion happening on this list instead of on
one within the RRG.   The people are going to be the same anyway,
for the most part, and at the moment it doesn't really matter in which
forum clue gets applied, so long as it can be (or does).

> where we are still waiting for useable output from the Routing

Frank & I would be thrilled if you would volunteer yourself to manage
a subgroup focused on producing exactly this output.   
[email-masked].
Other applicants also seriously welcome.

	Sean.

---

From: Sean Doran <[email-masked]>
Date: Wed, 16 Apr 2003 03:42:06 +0100

On Monday, Apr 14, 2003, at 15:10 Europe/London, Tim Chown wrote:

> Well, geography meets topology at an IX,

Hmm...

Except to the extent that the logical connection of distant physical 
things
to IXes has been a common practise (and indeed, a popular product) for
a number of years, and that the old practise of bridging together 
different
physical locations into the same L2 LAN/LIS has not yet been 
abandoned...

What were the geographical coordinates of MAE-WEST again?

And there will be lots of interesting places with LINX addresses, I 
guess.   :-)
http://www.linx.net/members/index.thtml

	Sean.