Lars,
even the existing routing paradigms should be questioned.
LISP doesn't do anything for Multicast, it doesn't do anything wrt the IPv4
depletion issue, it produces new update churn as to fight existing update
churn.
Or: Wasn't IPv6 the future? Now the new routing architecture is supposed to
be backward compatible with IPv4 AND !!! IPv6. Hasn't IPv6 got its chance and
didn't it miss this chance ?
What about the orthogonality between intra- and interdomain routing
protocols?! Isn't this a pity ?
I mentioned Multicast and LISP above. I should defend LISP. All existing
multicast models have an enormous flaw: they are not state-less. This can be
changed and -imo- should be changed.
Summary: There could be such a bright future for routing.But not if BGP,
i.e. the distance vector algorithm, is considered a holy cow.
Heiner
In einer eMail vom 18.04.2008 19:29:10 Westeuropäische Normalzeit schreibt
lars.eggert@nokia.com:
Hi,
thanks for your note - it does really make things a lot
clearer.
On 2008-4-18, at 0:07, ext Lixia Zhang wrote:
> Further,
once we have surveyed the solution space, we need to
> develop
rough consensus on the approach through the solution space.
> Arguing about 'incremental deployment', for example, doesn't
help
> this at all. We need to first come to some agreement
on the very
> highest level branches in the decision tree (e.g.,
do we do map-and-
> encap or translation or ???), and not worry about
the detailed
> leaves. That is up to the IETF to wrestle
with.
I hate to bring up the R-word, but I think before we can get to
a
consensus on architectural or technical directions for a solution,
we
need some consensus on what the requirements are for the
architecture.
What are the goals and non-goals?
All the
solution proposals on the table apear to have slightly
different
sets of problems they address, based on what the proponents
of each
consider important. The ongoing discussion intermingles
arguments
about which goals are important to address for a future
architecture
with which technical mechanisms are suitable to address
them, and
that's confusing (well, to me at least.)
Lars
--
to
unsubscribe send a message to rrg-request@psg.com with the
word
'unsubscribe' in a single line as the message text body.
archive:
<http://psg.com/lists/rrg/> &
ftp://psg.com/pub/lists/rrg