[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.
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 ?
Yakov.
--
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