Subject: Re: [rrg] Next pass

From: [email-masked] (Noel Chiappa)
Date: Fri, 23 Apr 2010 18:00:39 -0400 (EDT)

> From: <[email-masked]>

    > Can the scalability issue be solved without any firm policy on the use
    > provider independent prefixes/addresses?

That's the $64B question....

    > To what extent a loc/id solution can mitigate/solve the routing
    > scalability issue?

I don't think location/identity separation _in and of itself_ solves the
routing scalability issue (e.g. if everyone goes out and does PI anyway), but
it is to many of us a _necessary precusor_ - i.e. once you have it then you
can do the _other things_ that are needed to solve routing scalability,
things that are just too painful without location/identity separation.

	Noel

---

From: [email-masked]
Date: Fri, 23 Apr 2010 18:37:03 -0400

Isn't that accomplished by eliminating the scalability issue without depending on/using  A  N  Y    S I N G L E  (Unicast) address-prefix ?

I don't think location/identity separation _in and of itself_ solves the
routing scalability issue (e.g. if everyone goes out and does PI anyway), but
it is to many of us a _necessary precusor_ - i.e. once you have it then you
can do the _other things_ that are needed to solve routing scalability,
things that are just too painful without location/identity separation.
I could easily agree to hailing loc/id-split while taking the view that my TARA-locator fits in here,too.
 However, I don't. It would only increase the  confusion.It is already bad enough that people think having a solution that is called " loc/id-split solution" is already 
a property that makes it outstanding. Terminology is only noise and smoke (Goethe :-)
Heiner

    Noel
_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: Tony Li <[email-masked]>
Date: Fri, 23 Apr 2010 18:48:27 -0700

> things that are just too painful without location/identity separation.

This is correct.  Once we have loc/id and renumbering, then we can do things
like ask folks to stop using PI because we have made PA almost as good.
Again, avoiding the multi-homing usage for PI route injection is the goal.

Yes, policies need to go in place to do this, but policies do not happen
when there is no technical capability.

Tony

---

From: Russ White <[email-masked]>
Date: Sat, 24 Apr 2010 20:24:26 -0400

> Again, avoiding the multi-homing usage for PI route injection is the goal.

What about traffic engineering? Will a loc/id split "solve" traffic
engineering (which is normally done by leaking longer prefixes today),
and if so, how?

I understand you can "map" the id to the locator you'd prefer to bring
the traffic in through, but does that truly solve the traffic
engineering problem unless you also have one locator per possible exit
point (customer/edge pair) for every (transit) network in the world, and
does this actually scale better than what we have today? IE, what's the
incentive to aggregate locators, vs the incentive for de-aggregating
locators, or even assigning tons of locators because, "well, it's free
to advertise a locator, and the table is really small, so..."

It seems to me the locator table will end up just where the routing
table is today--there's no cost to advertise the things, so, hey, why
not? You could, I suppose, constrain the locator space so its very
small, but that doesn't seem like a very good solution, either.

So, IMHO, this is all neat and everything, but until the economic
problem is addressed, there's not much hope of doing anything other than
kicking the can down the road a couple of years or so.

:-)

Russ

---

From: Tony Li <[email-masked]>
Date: Sat, 24 Apr 2010 18:12:21 -0700

> engineering (which is normally done by leaking longer prefixes today),

No, but as we've discussed before, traffic engineering through deaggregation
is a self-inflicted problem.  When ISPs feel that this is worth addressing,
I'm sure that we'll see requests for prefix scoping or longer prefix
filtering.  Or even retraction of longest-match.
 
> to advertise a locator, and the table is really small, so..."

More to the point, it will simply be against policy to get PI allocations.

Tony

---

From: [email-masked]
Date: Sun, 25 Apr 2010 05:37:35 -0400

Russ,
We could go on for another  6 years and try to find out whether AS numbers are better suited for aggregation rather than IP numbers (or NOT).
For routing purposes the locators MUST have an intrinsic metric (which is what TARA and its TARA-locator provides). 
TARA is the only approach which  everyone can study just by using Google-map, e.g. by trying to find a route from NY, Time Square to Sun Francisco Golden Gate Bridge.
There you can see the (blue) route in each zooming level - at the start, in the middle, at the end. Google demonstrates that topology aggregation works. But we have at least a 15 years' expertise that nodal hierarchy does not work- starting with PNNI, ending with ILNP.

Google does it while dealing with a million times larger network. We could do it too - even without worrying about the network size in case that  end users should become nodes too - virtually linked  to some multi-homing nodes.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Russ White <[email-masked]>
An: Tony Li <[email-masked]>
Cc: [email-masked]; Noel Chiappa <[email-masked]>
Verschickt: So., 25. Apr. 2010, 2:24
Thema: Re: [rrg] Next pass

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Sun, 25 Apr 2010 15:40:34 -0400

Answering several points in one email, so the thread doesn't get
scattered all over the place...

> filtering.  Or even retraction of longest-match.

Agreed--and a loc/id split doesn't solve this problem. If we are causing
a self-inflicted table size issue today by refusing to aggregate in
order to engineer traffic flows, then we are just as likely to get into
the same position at some point in the future.

> More to the point, it will simply be against policy to get PI allocations.

But that doesn't stop people from deaggregating the locator space. I
know that's not the _intent_, but the reality is that all systems are
eventually deployed up to, and beyond, their technical limits, not the
way we think they "should" be deployed. The next to worst case is
probably the best estimate of where things will turn out.

> We could go on for another  6 years and try to find out whether AS numbers are better suited for aggregation rather than IP numbers (or NOT).

I would point out that AS numbers as aggregation points isn't something
I've advocated, or am likely to advocate. The reality is that
aggregating at the AS level is just another "forced traffic engineering"
scheme that people are likely to either reject, or simply work their way
around, in order to control what they want to control--the points at
which traffic enters and exits their AS.

Beyond which, I don't think AS' aren't situated in any way where
aggregating to the AS level would actually be something useful, at this
point. Perhaps 10 years ago it might be arguable, but today I'd guess
we're far beyond the point of gaining anything with such a design (of
course, I don't have hard facts, this is just an intuitive guess).

> TARA is the only approach which  everyone can study just by using Google-map, e.g. by trying to find a route from NY, Time Square to Sun Francisco Golden Gate Bridge.

Geographic routing doesn't present any more, or less, _possible_
information than any other routing system. I could inject a locator for
every person in the world (each person's "home address"), and wind up
with a locator table of about 6 billion--still pretty large, I think,
even by Internet standards. :-)

The only thing geographic routing systems provide is a possibly well
defined set of points at which to aggregate location information--given
everyone agrees to those points, and as long as there's no economic gain
to be made from gaming the system. The reality is no-one has ever
devised a routing system (that I know of) where it's better,
economically, to inject less information rather than more purely on data
plane/forwarding considerations.

More information always provides less stretch and more efficient
routing. Until links are free, or less than free (you are paid to
install more bandwidth), the economics will always drive more optimal
routing, and hence more state. It's just the way routing works.

> Not sure I completely understand what you're asking here? The abstract
> incentive to aggregate locators is to minimize routing overhead; I understand
> that at the moment there's no practical incentive descendant from that, but
> perhaps if more-specifics start getting filtered, or something, there will
> bey a real incentive.

If there's no incentive to reduce the routing table size today, then
what will the incentive be when it's just locators? I would argue the
incentive is in the opposite direction, that there will be a definite
disincentive to deaggregate locators just as there is routes today.

> The problem is that the architecture does not give them a better
> tool to do traffic engineering with; hammer-nail.

I'm not certain it has anything to do with the technology. Rather, it's
a matter of reality: if you want steer traffic, you must have more
state. Either that state must be in the packet header (source routing),
in the construction of a tunnel (semi-permanent circuit), or in the
forwarding table. You can't get better traffic flow control with less
information; it's just a logical impossibility.

So, going back to my original email, the point is that while loc/id
split might be neat, and I actually don't disagree with the concept
(some of the proposals on the table give me the willies, but that's
another issue), I don't know that loc/id separation "solves" any sort of
"table size" issue.

So long as we understand this up front...

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Sun, 25 Apr 2010 15:47:50 -0400

> routing, and hence more state. It's just the way routing works.

After sending this, I realized it's slightly wrong...

Until the cost of installing a new MB of memory is obviously more than
the cost of a link/path (including the router, of course), the economics
will always sway in favor of adding more state to preserve (or control)
link usage. Since the cost of adding a new link generally includes the
cost of adding more memory in some way, shape, or form (IE, the one cost
includes the other), I don't see how this balance is ever going to be
changed.

Of course, I could be wildly wrong. Someone could look back on this line
of thought in ten years and say I just didn't understand some new model
or paradigm, but in current terms, I don't see any way around the
preference for more state against buying more paths.

:-)

Russ

---

From: [email-masked]
Date: Sun, 25 Apr 2010 16:19:14 -0400

Russ, 
It didn't submit TARA just because I didn't want to offer it like sour beer (this is a German proverb). I did provide it to some Cisco people. The reaction was a polite YESandNo
but the comments and especially the not-asked questions showed me the lack of understanding. The same I can conclude from your comments below. Maybe however you can admit that in case I start a trip here from Munich, Karlsplatz Germany to San Francisco Golden Gate Bridge I don't need the city map of San Francisco to make the right next hop here in Munich towards the Munich airport. This means: I don't need approx. 99,9 % of the world's road maps just to make the next hop at that place where I am at that moment.

Topology aggregation can easily provide what is needed to eliminate the entire scalability problem, furthermore to enable the next hop lookup by either one or three table offsets.
Should there ever be a not yet predictable problem, well than let's just add one additional zooming level, There is no need for a 6 billion entries routing table. 
Stretch 1 is guaranteed,of course.

TE: Even if, temporarily, the best next hop, were to be avoided i.e. replaced by some hop which is part of some detour, the same fast methode for accessing the next hop would be possible: Temporaritly the offset tables have to get another next hop entry.

Or: Take time-of-day routing. You cannot do this without having any idea about geographically taken routes.
+more...

But I appreciate your comments pointing out the drive towards deaggregation very much. See with TARA there wouldn't be any single Prefix buildining/aggregation hence no problem
with deaggregation at all !!!

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Russ White <[email-masked]>
An: Tony Li <[email-masked]>
Cc: [email-masked]; Noel Chiappa <[email-masked]>
Verschickt: So., 25. Apr. 2010, 21:40
Thema: Re: [rrg] Next pass

> We could go on for another  6 years and try to find out whether AS numbers are 
better suited for aggregation rather than IP numbers (or NOT).

> TARA is the only approach which  everyone can study just by using Google-map, 
e.g. by trying to find a route from NY, Time Square to Sun Francisco Golden Gate 
Bridge.

:-)

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 25 Apr 2010 23:52:14 +0200

Hi Heiner,

> Maybe however you can admit that in case I start a trip here from
> Munich, Karlsplatz Germany to San Francisco Golden Gate Bridge I don't
> need the city map of San Francisco to make the right next hop here in
> Munich towards the Munich airport. This means: I don't need approx. 99,9
> % of the world's road maps just to make the next hop at that place where
> I am at that moment.

Clearly you don't need world map to get to the MUC. To translate this to 
RRG language you can follow AIS default route.

But once you get to MUC you better know which plane to take. And here 
comes a challenge.

Your destination (content you are looking for) is more then likely to be 
very distributed - even globally. The times where user A just wanted to 
talk to server B has gone long time back. Distributed file systems are 
now reality, distributed video files are norm and there is no way to map 
chunks of data to the geographical coordinates. And not even due to size 
of few orders more then 6 million .. mostly due to the dynamics of 
changes which would be required.

So coming back to your example in order to get to your distributed 
destination you better have a well defined timetable on the wall of MUC 
airport to direct you to the right destination. It could be mapping 
plane like we see in LISP or enhanced DNS like we see in ILNP except in 
latter (ILNP) you don't even need to get to any major hub to know which 
way to go.

Cheers,
R.

---

From: [email-masked]
Date: Mon, 26 Apr 2010 03:50:13 -0400

-----Ursprüngliche Mitteilung----- 
Von: Robert Raszuk <[email-masked]>
An: [email-masked]
Verschickt: So., 25. Apr. 2010, 23:52
Thema: Re: [rrg] Next pass

Hi Heiner, 
 
> % of the world's road maps just to make the next hop at that place where 
 
Clearly you don't need world map to get to the MUC. To translate this to RRG language you can follow AIS default route. 
 
But once you get to MUC you better know which plane to take. And here comes a challenge.

... which I am well aware of: My composed TARA-map must contain this single-hop link between the airports of Munich and S.Francisco, although that bridges a forth of the globe.
 
Your destination (content you are looking for) is more then likely to be very distributed - even globally. The times where user A just wanted to talk to server B has gone long time back. Distributed file systems are now reality, distributed video files are norm and there is no way to map chunks of data to the geographical coordinates. And not even due to size of few orders more then 6 million .. mostly due to the dynamics of changes which would be required. 

So coming back to your example in order to get to your distributed destination you better have a well defined timetable on the wall of MUC airport to direct you to the right destination. It could be mapping plane like we see in LISP or enhanced DNS like we see in ILNP except in latter (ILNP) you don't even need to get to any major hub to know which way to go.

What makes you believe that no other concept than what I'd call mainstream-IETF is able to cope with new challenges?. I give you an example: A year ago Google map was not able to display a route from NY to San Francisco as perfectly as it is able today: At that time, when you zoomed out for seeing the entire blue route from start to end, and when you thereafter zoomed closer e.g. to see the details in the surrounding of Chicago, it failed. Meanwhile you can do that, too. Will say: If you have a particular problem and are supposed to solve it based on a particular architecture then you will be able to solve it, after the time it takes to solve it of course, and well, restricted by the given architecture.
So this is no other sort of argument as was the partition argument I have been confronted several times.

Heiner

Cheers, 
R.

---

From: Patrick Frejborg <[email-masked]>
Date: Mon, 26 Apr 2010 11:36:26 +0300

Russ,

what are the underlying reasons to steer traffic?

I think one reason is to utilize the network as much as possible, make
use of all links that are available and share the load over them. Is
this a task the only the network should do or can the endpoints
participate in the traffic engineering as well?

If the routing architecture announces attachment points (aggregated in
DFZ)  to Internet - the local network is not advertised throughout the
DFZ - and having MPTCP on the endpoints the traffic engineering is
taken care by the endpoints. If congestion or failure occurs on either
attachment point the transport protocol shifts more traffic to the
other path.
Also, I find Valiant load-balancing interesting, but more studies
around that topic is needed.

So I think you necessarily don't need more state in the network if the
endpoints can take greater responsibility for their sessions and the
goal is to utilize all possible paths (attachment points). TE due to
other reasons need other tools.

-- patte

---

From: [email-masked]
Date: Mon, 26 Apr 2010 05:59:01 -0400

The best answer is: both (endpoints as well as transit nodes) have interests in routing. E.g. here multi-homing, there traffic balancing.
It is up to the architecture to serve both. CES versus CEE in the sense "an enduser must never experience any network layer issue" versus "should be the only one to..."
makes no sense.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Patrick Frejborg <[email-masked]>
An: Russ White <[email-masked]>
Cc: [email-masked]; Noel Chiappa <[email-masked]>
Verschickt: Mo., 26. Apr. 2010, 10:36
Thema: Re: [rrg] Next pass

Russ,

-- patte

---

From: Paul Jakma <[email-masked]>
Date: Mon, 26 Apr 2010 12:27:47 +0100 (BST)

On Sun, 25 Apr 2010, Robert Raszuk wrote:

> Your destination (content you are looking for) is more then likely 
> to be very distributed - even globally.

Perhaps obvious, but note that we can easily have a system that 
allows for both kinds of routing.

Prefix a -> Routed with reference to some external, universally 
understood space

Prefix b -> Routed without reference to any such space

If it is the case that geographic routing could "factor out" a 
sizable proportion of routes, then that's surely worth investigating? 
To allow the fact that such a system can not be used to aggregate 
/all/ routes to stymie its consideration completely is perhaps 
short-sighted.

More generally, if we have a number of different routing problems to 
solve, and if we are having trouble finding The One Way that solves 
them all, perhaps then we need to consider building a system composed 
of multiple different ways.

Wrt geographic routing: The ITU proposals to delegate to and assign 
IPv6 address space via per-country, statutory bodies could be a 
vehicle for such. Course, there is some opposition in places to the 
very idea of allowing delegation via ITU..

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
The Fifth Rule:
 	You have taken yourself too seriously.

---

From: [email-masked]
Date: Mon, 26 Apr 2010 07:55:32 -0400

-----Ursprüngliche Mitteilung----- 
Von: Paul Jakma <[email-masked]>
An: Robert Raszuk <[email-masked]>
Cc: [email-masked]
Verschickt: Mo., 26. Apr. 2010, 13:27
Thema: Re: [rrg] Next pass

On Sun, 25 Apr 2010, Robert Raszuk wrote: 
 
> Your destination (content you are looking for) is more then likely > to be very distributed - even globally. 
 
Perhaps obvious, but note that we can easily have a system that allows for both kinds of routing. 

yes,for sure: The amount of extra-churn for TARA info is neglectable compared with the permanent increase of the FIBs and RIBs. The size of the required TARA-routing table is pretty static.
 
Prefix a -> Routed with reference to some external, universally understood space 

If it is the case that geographic routing could "factor out" a sizable proportion of routes, then that's surely worth investigating? To allow the fact that such a system can not be used to aggregate /all/ routes to stymie its consideration completely is perhaps short-sighted. 

Note, Geographical data  is used to compose skimmed topologies (zooms) properly, i.e. not simple to select the next hop towards the destination's geo-location. So any detour is still enabled.
 
More generally, if we have a number of different routing problems to solve, and if we are having trouble finding The One Way that solves them all, perhaps then we need to consider building a system composed of multiple different ways. 

Topology-aware routing provides a huge multitude more of routes than a DV-based system (where you don't know all those detours via  nodes to which you have forwarded the BGP UPDATE)
 
Wrt geographic routing: The ITU proposals to delegate to and assign IPv6 address space via per-country, statutory bodies could be a vehicle for such. Course, there is some opposition in places to the very idea of allowing delegation via ITU.. 

There is a major difference with E.164 country codes: There you will always have ( at the country level) what I call the Istanbul effect.

Heiner
 
regards, 
-- Paul Jakma  [email-masked]  Key ID: 64A2FF6A 
Fortune: 
The Fifth Rule: 
   You have taken yourself too seriously. 
_______________________________________________ 
rrg mailing list 
[email-masked] 
http://www.irtf.org/mailman/listinfo/rrg