Yakov,
Would you mind to explain what you wanted to express by what has been
called your law ?
It is pretty difficult, because DV-based routing does NOT
provide ANY topology. While favoring topology aggregation, I am in
favor of "topology which follows addressing", however in a well determined
sense:
that a (sparsed) topology is built/viewed based on geographical
information (addressing).
I would appreciate your own clarification.
Heiner
BTW: We have just reached the final, whill Russia join too?
In einer eMail vom 24.06.2008 16:28:24 Westeuropäische Normalzeit schreibt
yakov@juniper.net:
Dino,
> > Robin,
> > Yes !!! Be assured, myself,
I am also and only focused on a long-
> > term solution, i.e. on a
forever scaling solution.
> > At the same time I never was opposed to
LISP or whichever map-encap
> > variant if considered to be a
near-term interim solution.By other
> > words: map-encap is
definitely not the longterm solution.
> > Instead I am convinced that
topology aggregation will become the
> > longterm solution
because it would scale even if the internet became
> > bigger
than the network of our roads and streets.
>
> And to add to
this, from the beginning, none of the LISP authors felt
> that
LISP was the ultimate long-term solution.
>
> So, should the
short-term map-n-encap solution be for IPv4 and the
> long-term
solution be for IPv6 only? That would depart from the
> thought
of having one solution for both address-families.
>
> Could we
agree that one map-n-encap solution for both IPv4 and IPv6 be
> a
short-term solution while we work on a long-term solution for IPv6-
>
only?
Perhaps we should first agree that there is a need a *short
term*
solution for both IPv4 and IPv6. The following (from Tony's
e-mail
on 5/26/2008) is relevant to the discussion on whether there
is
such a need:
Well, Ross Callon has been quoted as
saying that the Juniper
implementation will have no problems
up through many millions
of routes.
Now,
conceptually, that could happen tomorrow. However, at
the
current growth rates, that's likely to be many
years.
Yakov.