I am pretty in line with Iljitsch. I also think that it is
feasonable/reasonable to have the new design in the middle. At least for an
introduction period.
When I would talk about 1-2 K FIB entries, I mean of course 1-2 K
links,mainly loose links, the more remote, the looser,
however precisest in length. I would also call the
database "map-based". But because this is also a routing table, the
alternative should rather be called "prefix-based".
Same remarks about the current stage.
We have had a very long discussion about the dual nature id/loc.
We never had a discussion about strict/loose links. I mean algorithmically
determined loose links.
We have adopted the term "stretch" but none of the current models
(LISP,lvip,..) has anything to do with it. It takes map-based models, as
to rate them by stretch values, doesn't it ? (I would claim stretch=1 for my
map-based concept of course :-)
Another fundamental point of discussion is:
Shall a) the IP-header serve the model or b) shall the model serve
the IP-header ?
We have seen that a) is possible (TOS converted to DSCP). Why not again
here !?
In summary, it is too early to start with the finish.
Heiner
In einer eMail vom 07.09.2007 13:27:10 Westeuropäische Normalzeit schreibt
iljitsch at muada.com:
On
7-sep-2007, at 3:47, Noel Chiappa wrote:
>> From: Iljitsch van
Beijnum <iljitsch at muada.com>
>
>> The question is whether
it would be easier to replace it. So far, I
>> can't think of anyone
else other than myself speaking out in favor of
>> that, or even
entertaining the question seriously. :-)
> Really?
:-)
Dangers of caching: information from long ago may disappear
unless
it's refreshed periodically. (-:
>>
Obviously a new protocol would have to be able to interact with
>> BGP and
>> be not much worse at talking BGP than a
native speaker.
> Well, "interact with BGP" and "talk BGP" sound
like two very
> different things
> to me - unless by "talk
BGP" you mean "emulate a BGP speaker".
Yes, they are different things:
there is the protocol, which would be
more or less independent from
BGP, and the implementation, which
would almost certainly need to be
able to talk both the new protocol
and talk to BGP speakers. Whether
this counts as emulating... don't
know.
> The thing is
that if you have a system with a fundamentally
> different
model
> of the world (e.g. map-based, instead of route-table based),
the
> interface
> between it and BGP is necessarily going
to be something of a
> kludge, and any
> emulation is
perforce going to be be something less than stellar.
At the very least
a new protocol would have to support the situation
where the new
protocol is spoken in the middle and BGP both on the
left and on the
right. Obviously the BGP speakers may at that point
also interact
through regular BGP, e.g.:
BGP A -- New -- BGP B
\ /
BGP C
(Where "new" may be one or more ASes running the new
protocol.) So
the new protocol must be able to emulate BGP
processing so well that
it allows A and B to make (almost) identical
decisions as in the case
where there was no new protocol. For
instance, AS paths must be at
least retained and probably be added
to as information travels
through the new protocol. It gets even
more interesting when two
clouds speaking the new protocol are
separated by a BGP cloud.
I don't think an internet-wide map based
protocol is feasible, unless
aggregation is so draconian that the
protocol itself becomes largely
irrelevant and operators will mostly
be dealing with traffic
engineering exceptions rather than the
protocol itself. A system
where there is a map of the "center" of
the network (as seen from a
given vantage point) where mapping
to/from prefix tables happens at
the edges of the map would be very
interesting.
_______________________________________________
RAM
mailing
list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram