[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] cache issues in LISP and CONS - it's bad . . .
On 10/18/07, Robin Whittle <rw@firstpr.com.au> wrote
> LISP-CONS LISP-NERD eFIT-APT Ivip TRRP
>
> Full DB ITRs? No* Yes Default ITRD No
> Mappers
>
> Caching ITRs? All* No ITR ITRC All
> ITFH
>
> Local query No* Default QSD No
> servers for Mappers QSC
> caching ITRs?
Hi Robin,
I'm unclear what you mean here. Would you clarify?
> Caching ITR must Yes No No Yes
> drop packets it
> has no mapping for?
Actually, the ITR for TRRP is not required to drop packets for which
it has no map. It may drop packets if memory is tight or the mapping
occurs too slowly, but should attempt to hold them for transmission on
receiving a mapping. Specific strategies for determining which packets
to hold and for how long are not proposed.
> Distribution of Pull ITRs down Push Push Pull
> database to CAR-CDR load DB & slow fast DNS-like
> networks with global updates via Repli- global
> ITRs etc.? network via HTTP BGP cator network
> from DB system
> servers &
> other ITRs
>
> Incremental RRG Yes
> deployment via messages
> "anycast ITRs in 264 & 288
> the core"?
The answer for TRRP is Yes as well. Note the first sentence of phase 3
at http://bill.herrin.us/network/trrp-implementation.html which
explicitly envisions this step.
Regards,
Bill Herrin
--
William D. Herrin herrin@dirtside.com bill@herrin.us
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
--
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