[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures



Dino,

Dino,

Whether "it's not at all bad" depends on the locality of the
traffic.

Right, the guys at UCLB are gathering data on this.

Ok.

To preserve "truth in advertising" the LISP spec needs (a) to
clearly
spelled out the assumptions you make about the locality of the
traffic, as well as (b) to document the system behavior if these
assumptions
turned out to be incorrect.

Right, but we don't have the data yet so that is why it's not
documented.

Just because "we don't have the data yet" is *not* a valid reason for
why (a) and (b) are "not documented". This is because to document
*assumptions* does not require the data - the data is required to
test the assumptions. Likewise, documenting the system behavior if
the assumptions turned out to be incorrect does not require the
data.

We are assuming, at this point, nothing in terms of traffic locality.

First you agreed that whether "it's not at all bad" depends
on the locality of the traffic. But then you assume "nothing
in terms of traffic locality". Putting the two together
means that you have no clue on how bad that is going to be.

We have a rough idea but no data yet to back it. That is all I am saying Yakov.

And, by the way, you still did not answer my original question.
Namely, what were the problems that motivated development of CEF,
and how these problems would be solved in the context of LISP ?

I did answer it. It was software switching based population of the hardware or faster path forwarding cache.

Dino


--
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