Re: [RRG]

["William Herrin" <bill@herrin.us>]

On Sat, Mar 22, 2008 at 1:24 PM, Tony Li <tony.li@tony.li> wrote:
>  I'd like to turn now to the issue of the dynamics of the mapping function.
>  In particular, how fast can we allow the mapping entries to be updated?  Do
>  we need to constrain the overall flux of the mapping?
>
>  As always, a clear, succinct articulation of the correct questions is more
>  valuable than a position statement.  ;-)

Tony,

Here are a couple of questions within that question:


1. Estimate the width of the map system as a function of the number of
contained map entries. Some map systems will have a fixed width (the
ITR always talks directly to the origin map server) while others will
have a variable width (I get my maps from my neighbor who gets them
from his, etc.)

2. As a function of the width of the map system (W) what is the
maximum acceptable time (T) in which a change must be propagated to
all devices who need to know that a change has happened.

2a. What's the maximum acceptable time in which one EID may be
inaccessible to another because of a map change due to a path failure?

2b. What's the maximum acceptable time in which one EID may be
inaccessible to another because of a planned change? BGP handles both
cases the same, which is a pity.

3. What function best describes the relationship between the peak
update rate in the system and the peak update rate in the system's
most heavily loaded device? For example, with BGP a map change at one
leaf will usually require a change across most BGP routers in the
system, so in the worst case its D=S and in the average case it's
somewhere between D=0.9S and D=0.5S.

4. What should the maximum acceptable update rate (updates/minute) be
on the most heavily loaded device (D) in the system?

5. What is the target minimum supported update rate for the system (S)
as a whole?

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