Subject: Re: [rrg] Summary of architectural solution space

From: [email-masked]
Date: Tue, 11 Nov 2008 16:36:13 EST

Bill,
I see most of my comments all over the years addressed by strategy B,  
however please specify what you mean by "perform plain old hierarchical  aggregation 
on the LOCs". 
I am afraid you mean Nimrod/PNNI topology aggregation to which I  formerly 
looked up with glee - but not anymore. During the last time I  praised 
Google-map, e.g. how a route from NY,Broadway, to Sausolito,  Main-Street, is drawn 
"across differently zoomed maps". But meanwhile I see that  Google-map cannot 
catch-up with TARA either: If you see the blue line passing  the entire US and 
you want to zoom closer, let's say at some place  half-way down, like Chicago, 
it cannot be done :-(
Routing technology could need some big push everywhere :-)
 
Heiner

In einer eMail vom 11.11.2008 21:39:36 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hi  Folks,

I'm trying to put together a more or less concise summary of  the
general architectures we've discussed here these past couple  years.
This is not a comparison of specific proposals (which Robin  Whittle
has done an excellent job of) but rather a summary of the universe  of
general strategies we've looked at and haven't resolutely  rejected.
I'd appreciate your constructive  criticism:

http://bill.herrin.us/network/rrgarchitectures.html

Particular  answers I'm interested in:

1. Have I overlooked any viable approaches  to the problem? If so, what are 
they?

2. Have I overlooked any  architectural elements? I'm looking for
architectural elements here, not  engineering issues. For example, I
left out path-MTU issues because that's  a "how do we shoehorn this
into IPv4 of IPv6" engineering issue. It's only  relevant in an
engineering compatibility context. Obviously engineering  compatibility
issues will greatly inform the final architecture, but that's  not what
I'm after in this document.

3. Do you see any areas where I  could offer a more clear description?
How would you word it?

4. Have  I listed anything for which we have a strong consensus that we
can discard  the approach from consideration due to some uncorrectable
defect which is  obvious even without an engineering viability study?
By strong consensus, I  mean "nearly unanimous."

Thanks in advance,
Bill  Herrin

-- 
William D. Herrin ................  [email-masked]  [email-masked]
3005 Crane Dr.  ...................... Web: <http://bill.herrin.us/>
Falls Church, VA  22042-3004
_______________________________________________
rrg mailing  list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

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

---

From: [email-masked]
Date: Tue, 11 Nov 2008 17:14:07 EST

In einer eMail vom 11.11.2008 22:38:58 Westeuropäische Normalzeit schreibt  
[email-masked]:

Since  you start by talking about the root cause of the routing  scaling
problem,

Scott,
there is only one root cause which is the user reachability information  
dissemination. Neither the network of the roads and streets nor the network of  
the postal service with all the post offices and all the residential letter  
boxes do have this problem. Of course one cannot argue against this root cause -  
unless there is a solution which can enable best next hop forwarding without  
it.
 
Heiner

---

From: [email-masked]
Date: Mon, 17 Nov 2008 17:37:39 EST

In einer eMail vom 17.11.2008 17:08:38 Westeuropäische Normalzeit schreibt  
[email-masked]:

On Sat,  Nov 15, 2008 at 3:49 PM, Iljitsch van Beijnum
<[email-masked]>  wrote:
> Depends on the topology restrictions you're willing to live  with. I don't
> think we need to support the situation where a  multihomer connects to ISPs
> in South Africa and Hawaii.

What  about the one where he connects via a low earth orbit  satellite
constellation which has redundant ground stations in Hawaii, New  York,
Germany and India? Or any 4 points that actually fit on an orbit?  The
cool thing about LEO is that it starts around 100 miles up, so  you
don't have long speed of light delays or large  transmit-power
requirements. But you do have a huge geographic  spread.

In a developing country, it would be doubly-handy if a customer  could
use a terrestrial radio network when the signal is good and fall  back
on a more expensive LEO satellite when the terrestrial radio  network
has problems, all without disturbing the ongoing  end-to-end
connections.
Yes. This is precisely where the routing challenges start to get  exciting.
 
Heiner

---

From: [email-masked]
Date: Fri, 21 Nov 2008 02:51:16 EST

In einer eMail vom 20.11.2008 23:09:18 Westeuropäische Normalzeit schreibt  
[email-masked]:

> correct me if  I am wrong:
> Strategy A means LISP etc.

LISP, TRRP, IVIP,  Six/One Router and I think APT are all specific
proposals within strategy  A, yes.

> Obviously A is about to be abandonned,isn't it  ?

That's not obvious to me. ;)

> Strategy C tries to  emulate TARA. Doesn't it ?

I think TARA is a strategy-C approach, yes.  Remind me where the link
to TARA is so I can  double-check?

Right now I don't even have a doc which catches up with all the new  
developments which are either due to my own ideas or due to the RRG-mailinglist  
discussion's input. Forwarding just by either 1 lookup or by 3 lookups draws my  
attention to ALL routers (inter +intra domain). If forwarding were done by "my"  
geo-label and dest.user's interface selection by Christian Vogt's  
"Host-name"-key then hey: we don't need an IP address anymore at all !!!!!!!!!!  ????
 
Have fun at the meeting
 
Heiner

Thanks,
Bill

---

From: [email-masked]
Date: Sat, 22 Nov 2008 04:38:32 EST

TARA would handle it like the postal letter is handled. The envelope  shows 
the receiver's name (-> IPv4 addr)
and his/her (current) location (geo-label). By doing so,the upper  layers are 
not impacted.
 
Another point: I cannot imagine either that strategy C, as currently  
sketched, will work.
But if anyone wants to get an understanding of TARA: Click to Google -map,  
search a route from NY,Broadway  to Sausolito, Main Street and  observe/digest 
all the zooms at NY, Broadway.
Then make a hop, as is colored, and repeat all over again by searching from  
your current spot once more a route to Sausolito Main Street. If you do this  
until you have reach the destination you will realize that by 99,99% you don't 
 see  Main Street and yet you can route successfully.
For comparison: the internet with its 10,000 DFZ routers is a very very  tiny 
network.
 
Heiner

In einer eMail vom 22.11.2008 05:49:38 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hi, 
I  don´t see number 2 as completely orthogonal, this is why: since the IP is 
used  as part of the session identifier it becomes a requirement for it to 
don´t  change, then when you implement mobility or multihoming you end up with  
schemes that impact routing (inject prefixes). This is from a message from  
Robin Whittle a couple of days ago that explains it better than I  could: 
“If the Internet had been designed so the hosts were  somewhat smarter - so 
they could operate perfectly well despite their IP  address changing at any 
time - then we probably wouldn't have a routing  scaling problem.  We would 
already have something like SHIM6 or  ILNP.” 
Regards, 
Damian 

From:  [email-masked] [mailto:[email-masked]] On Behalf Of  
[email-masked]
Sent: November-21-08 2:59 PM
To:  [email-masked]; [email-masked]
Subject: Re: [rrg] Summary of  architectural solution space

The  root cause of the routing table growth problem is that we're using the 
same  element (IP address) to express three distinct concepts:   
    1.  the globally  unique identity (GUID) needed by the originating client 
system to find the  destination server,  
    2.  a component of  the session identity (SID) used by the layer 4 and 
higher protocols to keep  track of communications with other hosts, and  
    3.  the node's  present location or locations (LOC) within the network 
topography.  
 
I  would put it a little bit differently: The root cause is that, by the 
current  routing architecture, just a globally unique identity (GUID) is used  for 
finding both the egress router as well as the destination  server.

And  also: Point 2, although true, is a different topic, but is orthogonal to 
this  problem.

Heiner

In  einer eMail vom 21.11.2008 21:43:32 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hi  Folks,

The third draft is now available  at
http://bill.herrin.us/network/rrgarchitectures.html .  It adds  a
strategies D, E and F to the solution universe and moves the  major
criticisms of each strategy to a separate subheading so that  the
criticisms don't clutter the description of the approach.

The  second draft is archived  at
http://bill.herrin.us/network/rrgarchitectures2.html

For the  folks who offered suggestions on the earlier drafts: Thank
you. Have I  addressed the issues you brought up? How can I further
improve the  document?

For everyone: I'd like to close this document after this  draft. If you
have any additional comments or criticism, now's the  time.

Regards,
Bill Herrin