Subject: Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of

From: [email-masked]
Date: Wed, 17 Mar 2010 07:03:28 EDT

In einer eMail vom 17.03.2010 07:53:14 Westeuropäische Normalzeit schreibt  
[email-masked]:

Lixia,
Thanks for the above document reference. My guess: You collect this  
AS-level topological network information just for academic interest.  i.e. for 
doing some interesting studies. That's  all.

we do not do studies just for academic  interest.
The goal of the above is to explain what  one can or cannot observe about 
the AS  connectivity.

I should have said "for doing off-line  purposes". I have expressed the 
"on-line" objectives many times, some  of them see below, which I think go 
beyond keeping the internet running just  as well as is currently still the case.

Not sure I understand the definition of "off-line purposes";  RIPE and 
Routeviews get data from running routers.

Let me express what I mean by on-line purposes: 
                           next hop determination - followed by the rest of 
routing issues

This is not at all my point. My question is: What would be  achievable in 
terms of better routing, if  the same kind of  topological information were 
available in inter-domain routing as is the  case in intra-domain routing !

I understand, and my point (based on the  data) is that inter-domain 
topological info is largely *not* available,  and for a reason.

Nor would my TARA-model insist on being  fed with all topology info, even 
more: its goal is to skim the  available topology information. See below from 
my previous email, I didn't  mention the two additional side effects: 1) no 
single prefix and  2) no  single route to be disseminated/collected  
anymore.

looks like I just got lost further :(

I stated this many times. 

And there  is indeed a very long list of  achievabilities including:
- Mobility without home-agent/care-of-address server by  well-scoped 
broadcast search  messages

Any comments  to this mobility objective?

a nice objective.

-  Congestion handling by detouring  and not, a la  re-ECN,  by slowing 
down (video :-( ???) transmission  
- Enabling any detours (incl. crankback using ones) and  getting rid of the 
loop phantom  fear

Any comments to this TE  objective?

not necessarily disagreement, though the above did not specifically  
mention multipath approach (e.g. the multipath TCP effort), that can be  effective 
means towards those objectives 

If you look at the topological graph on _www.hummel-research.de_ 
(http://www.hummel-research.de)  you can see  extensive multipath. What this 
particular picture does not show are the  detouring- capabilities which include hops 
in opposite direction of the  displayed arrows, i.e. reasonable loops like 
crankback encompassing  detours. Multipath is a networking layer topic and 
should be implemented there  (rather than as a transport layer feature).

- 99 % state-less  Multicast

Any comments  here?

I do not understand fully here.
does it refer to IP multicast?
(there are lots host mcast solutions that dont introduce state to  routers; 
one may also view CDNs as asynchronous multicast  delivery)

Sure, IP Multicast.

- speeding  up next hop determination by 20 x 100 = 2000 % 
-......etc..etc...

Comments?

Please let me just ask one question: any thought on how to achieve  those 
objectives? in particular how to get from here to there without a  total 
restart?

I showed it on the list and in precisest detail to preceding RRG-chair  
Dima Krioukov's.
 
It is a huge shift, but only in thinking. 
A single tiny BGP-UPDATE extension is needed to as to advertise adjacent  
loose/strict/GRE-tunnel LINKs and the TARA-locators of their both  ends.

By  insisting on DV this group prevents all major progress, including that  
progress none of us is currently able to think of. Remember the IBM  
commercial! Rather asking the transport goods for where we are, we  should provide 
a networking layer technology for the benefit of services  above.

if  I could change couple words in the very last statement above: we need  
to provide a networking layer technology that *best fit*  the services 
above.  

Note that, in the long run,  networking layer not necessarily = IP layer; 
see the recent paper by Van  Jacobson etc "networking named content" 
(_http://www.parc.com/publication/2318/networking-named-content.html_ 
(http://www.parc.com/publication/2318/networking-named-content.html) ).  I'm currently 
working with Van along this  direction.

Yes, IP is not the lowest networking level. Next hop selection due to a  
received TARA-locator (= 5 octets which is much less than a MPLS stack)  might 
as well be done by some (new) MPLS. Or consider ethernet:
MAC- address, mainly,  just shoot for globally uniqueness,  which  could be 
provided by the TARA-locator plus some additional info, too.
 
IP addresses aren't more routable than MAC or labels: It depends on  
extensive mapping efforts whereas the geographical  coordinates _are_already_at 
their_places !!!!!!!!!! 
My goal is clear: improve routing  by exploiting routable data.  And I 
really do acknowledge the existing internet deployment situation. BTW, it  would 
be simplest to place the 5 octet-sized TARA-locator into the
16 octet-sized IPv6 address.Though I wouldn't mind that, it is more  
responsible to keep IPv4 alive, i.e. to look for alternatives of embedding  it.

Lixia

=

Heiner