In einer eMail vom 17.03.2010 07:53:14 Westeuropäische Normalzeit schreibt
[email protected]:
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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
