Subject: RE: geo short vs long term? [Re: Geo pros and cons]

From: "Tony Li" <[email-masked]>
Date: Thu, 3 Apr 2003 12:17:41 -0800

Jim,

Yes, geo addressing at the continental level makes much more sense
because the connectivity within a continent is pretty much a 
given.  Not so at the metro or lower layers, so it doesn't
recurse down nicely.

Note that a hybrid system that was geo at the top and provider
based below was proposed some 10 years ago, but some folks
shouted it down because they didn't feel that the aggregation
at the continental level would have a great effect.  Of course,
we had very few ISPs at that exact point in time and they
were correct.  For the moment.

I would have zero issues with continental aggregation tied
to lower layers that were topological.  [Well, ok, I don't think
that Antartica should get as much as China, but that's a nit. ;-) ]

Tony

|    -----Original Message-----
|    From: Bound, Jim [mailto:[email-masked]] 
|    Sent: Thursday, April 03, 2003 6:05 AM
|    To: J. Noel Chiappa; [email-masked]
|    Subject: RE: geo short vs long term? [Re: Geo pros and cons]
|    
|    
|    This is logical and makes sense.
|    
|    But practically, if say the U.S., Mexico, and Canada all 
|    had a toplevel
|    GEO prefix would the connectivity issue still be real or just
|    theoretical?
|    
|    Within this GEO if all had 2ffe then another set of bits 
|    for Mexico,
|    U.S. and Canada how would that exacerbate routing problems 
|    in Austrailia
|    or France?
|    
|    Thanks
|    /jim
|    
|     
|    
|    
|    > -----Original Message-----
|    > From: J. Noel Chiappa [mailto:[email-masked]] 
|    > Sent: Thursday, April 03, 2003 8:35 AM
|    > To: [email-masked]
|    > Cc: [email-masked]
|    > Subject: Re: geo short vs long term? [Re: Geo pros and cons]
|    > 
|    > 
|    >     > From: "Michael H. Lambert" <[email-masked]>
|    > 
|    >     >> Geographic addressing has been discussed extensively 
|    > about 17 times in
|    >     >> the IETF, and every time it has been rejected. 
|    > Discussing it one more
|    >     >> time is not going to change this. There is *never* 
|    > going to be a rough
|    >     >> consensus *in favour of* geographic addressing. There 
|    > will *always* be
|    >     >> a lot of people against it
|    > 
|    >     > Since you have more historical context than many of us 
|    > on the list,
|    >     > could you please summarize the arguments which have 
|    > been used against
|    >     > geo? I suspect that they are mainly financial and 
|    > political, but there
|    >     > might be technical issues I'm unaware of.
|    > 
|    > Actually, I don't think that's quite correct: the argument 
|    > against it is in fact rooted in technical issues, although 
|    > there are non-technical issues in the later stages.
|    > 
|    > The analysis of geographic has been fairly well summarized in 
|    > recent discussion here on the list, but very simply, it goes:
|    > 
|    > - i) for the overhead of the routing to scale, the hierarchy 
|    > of addressing abstractions has to be reasonably closely 
|    > related to the actual interconnection topology;
|    > - ii) this means that either connectivity has to follow 
|    > addressing, or addressing has to follow connectivity;
|    > - iii) the IETF cannot mandate where connectivity gets added;
|    > - iv) connectivity gets put in where there are actual traffic 
|    > flows and/or commercial reasons to put it in.
|    > 
|    > Therefore we have to have the addressing follow the 
|    > connectivity, and an addressing scheme such as geographic, 
|    > which to scale needs to have the connectivity follow the 
|    > addressing, is not feasible.
|    > 
|    > 	Noel
|    > 
|    > 
|    > PS: Everyone, about the "this is stupid" comment - that 
|    > wasn't directed at anyone in particular, but at all of us, me 
|    > included. I suddenly had my brain start to function, and 
|    > realized that there is never going to be *rough consensus in 
|    > favour of geographic* - which is what we'd need to go forward 
|    > with it - and therefore further discussion thereof is not 
|    > useful. I hope I didn't offend anyone - if I did, my apologies.
|    > 
|    > 
|    
|

---

From: Joe Abley <[email-masked]>
Date: Sat, 5 Apr 2003 21:03:21 -0500

On Thursday, Apr 3, 2003, at 15:17 Canada/Eastern, Tony Li wrote:

> given.

Connectivity within a continent may be a given for all continents at 
some point in the future. Today it's only really a given for North 
America, Australasia and Europe.

Joe

---

From: Randy Bush <[email-masked]>
Date: Sat, 5 Apr 2003 19:00:46 -0800

> Connectivity within a continent may be a given for all continents
> at some point in the future. Today it's only really a given for
> North America, Australasia and Europe.

if you don't count the oceanic island nations, se asia, ...  all of
which backhaul a long way.  net topology is extremely different
from geography.  this repeating idea of geographic aggregation
simply ignores reality.

randy

---

From: Joe Abley <[email-masked]>
Date: Sat, 5 Apr 2003 22:18:01 -0500

> from geography.  this repeating idea of geographic aggregation

Yes. That was my point.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 6 Apr 2003 11:27:10 +0200

> from geography.  this repeating idea of geographic aggregation

Trying to get something right that was done wrong in the past isn't 
"repeating".

The idea behind geographic addressing is not that the topology and 
addressing become interchangable. The simple fact that a multihomer 
connects to the net in two places makes this impossible by definition.

The point is that it becomes possible to draw lines on the map in such 
a way that aggregating routing information that crosses these lines 
gets rid of enough routing information that the savings in routing 
table size are worth the effort.

For this purpose, it is irrelevant that the aggregation circle with 
Singapore in the middle may also include Palo Alto and LA. That still 
gets rid of Asia/Pacific more specifics in most of the US and the rest 
of the world. And even if some Asian networks connect to other places, 
this only breaks aggregation for these specific networks.

Maybe the savings aren't that big. But then again, the effort isn't all 
that huge either: the RIRs need to implement a tool that allows local 
internet registries (ISPs) to give out geography-based /48s to 
multihomers. That's all.

(Aside: I'm not that familiar with the Asia/Pacific region, but I 
believe the interconnection within many countries isn't all that bad, 
it's the interconnection between countries in the region that's still 
in the early stages. So aggregating at the continent level wouldn't 
work well there, but aggregating on the country level could.)

---

From: Randy Bush <[email-masked]>
Date: Sun, 6 Apr 2003 09:48:41 -0400

> Trying to get something right that was done wrong in the past isn't 

not taking lessons from history and physical reality is naive at best,
and dangerous at worst.

randy

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 6 Apr 2003 19:40:14 +0200

> not taking lessons from history and physical reality is naive at best,

Is it really that hard to let go of preconceived notions?

The only "lessons from history" I can find are discussions that went 
nowhere because neither party bothered to get into enough detail to see 
if something useful could be done or not. Physical reality is that 
every meter of fiber costs money. There are only two cost-effective 
ways to connect networks: over the shortest possible distances, or by 
aggregating as much traffic and as many logical connections over a 
single circuit as possible. Both allow good geographical aggregation.

---

From: Sean Doran <[email-masked]>
Date: Wed, 16 Apr 2003 04:34:04 +0100

> from geography.  this repeating idea of geographic aggregation

Standing in my building does not give you the right to expect
me to deliver packets to you.

If your GPRS operator gives you an address related to my
building's physical location, and packets arrive via my immediate
provider to me for that address, rather than to you through your GSM 
operator,
I will drop them on the floor, even though *in principle* I could 
deliver them
to you via, say, wavelan, or a 100baseTX port.   (I don't really want 
you on my
network though; I have more business-productive things to pay for
than the porn you're surfing while in my lobby, never mind security 
issues...)

Your GPRS operator, therefore, will have to give you addresses
that are unrelated to my building's physical location, even when
you're standing in it.

If we ever have a "visitor" network, you can bet that those packets 
will cross
only the public Internet, not my corporate WAN.   You'll get public IP
addresses rather than internal (and mostly 1918) ones, because you
will only be allowed to connect to the visitor wireless LAN
(or the visitor 100baseTX plug) no matter what desk you put your laptop 
upon,
even if it's mine.

	Sean.

---

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

On Sunday, Apr 6, 2003, at 10:27 Europe/London, Iljitsch van Beijnum 

> connects to the net in two places makes this impossible by definition.

No, this is not true, unless you insist a multihomer only ever uses one 
address
to fit a constrained L2 topology.

Multi-address-with-existing-v6-semantics and 
multi-address-using-GSE-or-other-split-I/L
approaches both preserve the direct relationship between topology and 
address or locator.

MPLS/2547 and other line, cloud and lan virtualizations ("liberate your 
Internet traffic from the
tyranny of physical infrastructure!") likewise, only the other way 
around: they can adjust topology
to fit existing addresses.

> Maybe the savings aren't that big.

The savings are enormous.  Aggregating the entire western hemisphere 
behind
a single prefix would be wonderful.  (I propose using existing Sprint 
address space.)

However you are overlooking the fact that there are costs too (on top 
of the
monopoly rent I will gladly extract from hundreds of millions of people 
like you,
who will deliver all your North American traffic only to me).

In particular, should connectivity between me and something covered by 
my single
prefix fail, you and everyone else in the eastern hemisphere will not 
know this -- not
a really problem, except for the cases where there are longer paths 
available which still work.

I suggest that aggressive regulation will constrain this problem, so 
engineers
need not think about the dissolution of abstraction boundaries, and 
other things
that go bump in the night.

Massive spending on local redundancy and resiliency is the correct 
answer.
The industry's approach -- connecting to more than one provider -- is 
fundamentally
a bad idea.  Fortunately, gentle guidance will resolve this surprising 
failure of the market,
and lead to a more stable and reliable Internet for everyone.

> But then again, the effort isn't all that huge either: the RIRs need 
> to implement a tool that allows local internet registries (ISPs) to 
> give out geography-based /48s to multihomers. That's all.

My approach is even easier.  "No, you can't have an address, unless you 
get it from Sprint".
This requires no new tools (they have already deployed the vacation 
program and procmail),
and offers ARIN a considerable opportunity for staff reduction.

I also think it's cheaper to pay me obscene one-provider charges in a 
few years than it
will be to deal with a routing system with a hundred thousand 
residentially multihoming
/48s in each of hundreds of major cities.   My neighbours, oddly 
enough, use different
providers than I do, so their providers would have to know about my 
/48, and mine theirs,
and no aggregation is possible for this immediate area for any set of 
providers operating
within the closest abstraction/aggregation boundary.   This is not 
atypical, in my experience,
and boundary pressure is likely to force a trade-off between leaking 
global exceptions and
increasing local state.

Sigh.  I wish I were the One True Monopoly.   You should too: there'd 
be less of this sort of email.
Try working on SAPI: "Sean-Assigned Public Internet addresses".    
That'd be much cooler.

	Sean.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Apr 2003 10:02:14 +0200

On woensdag, apr 16, 2003, at 06:08 Europe/Amsterdam, Sean Doran wrote:

>> connects to the net in two places makes this impossible by >> definition.

> No, this is not true, unless you insist a multihomer only ever uses 
> one address

You really have been in hibernation, haven't you?

Constrained L4 architecture, anyone? Multiaddressing needs a huge 
amount of work before it can catch up with the level of functionality 
provided by today's routing-based approaches. That's why we're still 
discussing the routing stuff, even though we know it has inherent 
scalability problems.

>> The point is that it becomes possible to draw lines on the map in 
>> such a way that aggregating routing information that crosses these 
>> lines gets rid of enough routing information that the savings in 
>> routing table size are worth the effort.

[...]

> a single prefix would be wonderful.  (I propose using existing Sprint 

Ok, here you cross the line between being purposefully ignorant and 
being offensive. I think your comments here disqualify you as chair of 
this wg, and I am asking you here and now to step back and let someone 
else, who can take all of this seriously, take over.

> monopoly rent I will gladly extract from hundreds of millions of 
> people like you, who will deliver all your North American traffic only 
> to me).

Ha ha. Is this the way the IETF is supposed to work? People volunteer 
many hours of work only to be mocked? Didn't you even read the *title* 
of my draft?

         "Provider-_I_n_t_e_r_n_a_l_ Aggregation based on Geography
                      to Support Multihoming in IPv6"

> fundamentally a bad idea.

So you agree you have no business chairing a _multihoming_ in IPv6 wg?

Two final quotes for those of you still reading:

> My approach is even easier.  "No, you can't have an address, unless 
> you get it from Sprint".

> Try working on SAPI: "Sean-Assigned Public Internet addresses".    

Iljitsch van Beijnum

---

From: Sean Doran <[email-masked]>
Date: Wed, 16 Apr 2003 14:10:51 +0100

On Wednesday, Apr 16, 2003, at 09:02 Europe/London, Iljitsch van 

> discussing the routing stuff, even though we know it has inherent 

Do you think the WG could arrive at a consensus on exactly these points?

That is: multi6 could, if there was agreement,  document that the L4 
architecture
as it stands now is in the way of considering solutions which we do not 
at present
"know ... has inherent scalability problems".

I happen to favour such a recognition/admission of the problem.
Whether this would trigger useful reactions outside multi6 is a point 
which
interests me enormously.

> else, who can take all of this seriously, take over.

I would seriously appreciate it if someone would volunteer himself or 
herself to the ADs
so that I am freer to address (apologies for the pun) many of the 
discussions here in
a much more me-like fashion.

	Sean.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Apr 2003 17:09:04 +0200

On woensdag, apr 16, 2003, at 15:10 Europe/Amsterdam, Sean Doran wrote:

>> I am asking you here and now to step back and let someone else, who 
>> can take all of this seriously, take over.

> herself to the ADs so that I am freer to address (apologies for the 
> pun) many of the discussions here in a much more me-like fashion.

Sounds good to me.

If nobody wants the job, maybe the ADs can find someone with no 
previous multi6 experience? A fresh point of view certainly wouldn't 
hurt.

Now that we have that out of the way...

> architecture as it stands now is in the way of considering solutions 
> which we do not at present "know ... has inherent scalability 
> problems".

> Whether this would trigger useful reactions outside multi6 is a point 

Obviously I feel it would still be useful to pursue short term 
solutions in order to buy time to develop good long term solutions, but 
that wasn't the question...

It seems to me that if there is going to be consensus about _anything_ 
it has to happen during a meeting, where there is much more pressure to 
do _something_. On the list, calls for consensus usually don't yield 
much result one way or the other.

But to really answer your question: I think it should be doable to find 
consensus on the fact that layer 4 choices in the past are making our 
life difficult today, but I'm not sure we can agree on a plan of 
attack. I suspect that many people will take the position "if TCP wants 
a stable address, we'll implement magic in the IP layer to make this 
happen" rather than "let's improve TCP". Well, maybe that could be our 
consensus. I'd rather see it happen cleanly by changing TCP, but if we 
can get it to work without too big a mess in IP, I suppose I can get 
behind that.

If we can indeed find rough consensus on that, maybe we don't even have 
to throw it back outside multi6.

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Apr 2003 08:53:35 -0700

>  maybe the ADs can find someone with no previous multi6 experience?

no one has such experience.  so far, multi6 is a fantasy.

randy

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Apr 2003 18:01:24 +0200

> no one has such experience.  so far, multi6 is a fantasy.

What I meant was: someone who isn't and/or hasn't been involved in this 
wg.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 17 Apr 2003 10:29:05 +0200

On onsdag, apr 16, 2003, at 17:09 Europe/Stockholm, Iljitsch van 
Beijnum wrote:

>
> But to really answer your question: I think it should be doable to 
> find consensus on the fact that layer 4 choices in the past are making 
> our life difficult today, but I'm not sure we can agree on a plan of 
> attack. I suspect that many people will take the position "if TCP 
> wants a stable address, we'll implement magic in the IP layer to make 
> this happen" rather than "let's improve TCP". Well, maybe that could 
> be our consensus. I'd rather see it happen cleanly by changing TCP, 
> but if we can get it to work without too big a mess in IP, I suppose I 
> can get behind that.
>
> If we can indeed find rough consensus on that, maybe we don't even 
> have to throw it back outside multi6.

I think the first step still is to define what the options are. Then we 
can start worry about consensus. But I agree that we need to start at a 
meeting.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 17 Apr 2003 15:34:18 +0200

On donderdag, apr 17, 2003, at 10:29 Europe/Amsterdam, Kurt Erik 
Lindqvist wrote:

> I think the first step still is to define what the options are. Then 
> we can start worry about consensus.

In any multiaddressing scheme, there must be a point where a single 
"handle", be it an address, an FQDN, a control block or what have you, 
is tied to two or more paths through the network. There are many ways 
to do this:

- let the applications handle it (SMTP, DNS)
- let the network layer handle it (MIP)
- let the transport layer handle it (SCTP)
- let a middlebox or border router handle it (MHAP)

GSE isn't easily classified here as transport, network and border 
routers all need to play their part.

I think we can agree that having the applications do it isn't good 
enough for many applications as sessions don't survive a rehoming event.

Network layer has the advantage it is presumably easy to implement.

Transport layer has the advantage that it already has the end-to-end 
state which makes failover easier and doesn't pollute the architecture 
by introducing state elsewhere.

Middlebox/border router has the advantage the number of boxes that need 
to be upgraded is very small.

These are our basic choices. The problem is that each of the advantages 
and disadvantages will be appreciated differently by different users. 
Enterprise users want central policy control, home users and mobile 
users want flexibility no no reliance on provider cooperation. Some 
people need multihoming in IPv6 yesterday, others haven't even heard of 
IPv6 in the first place.

If possible, I think the best choice is not to choose at all, but make 
the mechanism generic enough that it can work anywhere.