Robin,
I am accrediting to you your emphazising
that a) incremental deployment cabability is a MUST
b) that any higher level architectural objective must be backed by
the respective detailed solution.
ad a) I completey agree. I do claim this for TARA. By the same token any
other competing solution can be deployed incrementally - CONCURRENTLY ( so I
hesitate to promote the competing solutions :-).
This group think that it holds all the marbles in the own hand. Wrong. A
e.g. (most and forever) scalable solution can be deployed even unnoticed. BGP
provides everything that is hereby needed.
Therefore I don't feel urged to participate in the race of soliciting the
own solution within the next few days.
(and you shouldn't either )
ad b)
I think the same way. So, be assured whenever I take my mouth full, either
by boasting what TARA can accomplish or by harsh critizising other
more-liked solutions or by emphasizing important requirements,
It is always backed by the knowledge about the detailed solution.
In einer eMail vom 01.12.2009 13:05:22 Westeuropäische Normalzeit schreibt
[email protected]:
I have never been able to understand what you keep mentioning about
geographic mapping, or "location-namespace" etc. Can you give a
practical explanation of how it would work, with a different thread
subject than this one?
I did give a practical analogy: The tourist who wants to go from Munich,
Karlsplatz (Germany) to Sausolito, Mainstreet California equipped with maps
of the current city, county, state, country, continent and the world map. He
will be able to determine the next hop although his destination doesn't
show up on any of these maps.With what I have in mind he will be able to
compute a flat map which combines all of these maps, and how you would get
them, e.g. such that any direct link let's say from Munich airport to
S.F.airport is included while thousand others, e.g. like Vancouver to Seattle,
aren't.
But so far I have to be patient ( after all, it is only my personal
solution, meanwhile without any partners - a situation which I think you share
with me:-). No one is interested in better routing technology although, for
instance, a similarly reduced map wrt the sum of all areas of an OSPF
network might as well be of interest ( I think, though I don't care very much
about this side effect in view of the importance of a future routing
architecture ).
How would your system enable non-upgraded hosts or upgraded hosts in
non-upgraded networks communicate with the devices using your system?
This is my question 3:
_http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/_
(http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/)
Well, see ad a) and also let's see what the leaders of this group will
recommend.
How would traffic using your system traverse the DFZ? This is my
question 6.
Definitely most capable, i.e. capable to take the shortest route, or any
detour (see the picture on my website; unfortunately it doesn't show the
entire set of detouring possibilities - but I could compute you some).
No one can do magic tricks. There is a wide area of work waiting for all.
Example: The shortest route to the destination at almost the other side of
the globe be westward bound. I decide to go eastward. For the next few
routers the westbound route is still shortest. how do I indicate that they
should comply with my initial decision? Though I haven't even looked closer to
this scenario, I am optimistic to find a solution.But I cannot see at all
how the current routing technology would even scratch at this issue).
Heiner
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
