Subject: [RRG] More discussion please: mapping churn

From: "Tony Li" <[email-masked]>
Date: Sun, 30 Mar 2008 19:03:16 -0700

Hi,

There hasn't been much discussion on the mapping churn rate.  There have
been a few good questions, but not much back and forth.  Do folks have an
opinion or should I just propose some text?

Thanks,
Tony

--
to unsubscribe send a message to [email-masked] 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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 31 Mar 2008 07:57:14 +0200

Tony,
> opinion or should I just propose some text?

With the volume of this group it is difficult for me to keep track of 
what sort of text you are looking for, given the terse statement above.  
Do we have text that even defines the mapping function?  If entries are 
aggregated within the network somewhere, then that has a substantial 
impact on tolerable rate of churn.  On the other hand, in the case where 
mapping information is stored locally in an unaggregated fashion (and it 
really doesn't matter - push or pull, just how much is actually stored), 
then we begin to think about memory limits and the use of primary and 
secondary store.

Where to go from here?  Perhaps tell me why what I wrote above is or 
isn't relevant, repetitive, etc?

Eliot

---

From: Scott Brim <[email-masked]>
Date: Mon, 31 Mar 2008 08:11:26 -0400

> opinion or should I just propose some text?

I understand you're trying to nail down criteria, but I think it's 
premature to put numbers on this.  To start with, are you still using a 
general definition of "mapping", or is the question specific to 
intermediary-based map-n-encap?  Second, are you assuming a single 
database that needs to be updated, or allowing for multiple DBs or 
distributed DB?  Are you taking into account that in pull models 
"outdated" mapping entries might still be valid?

It might be better to turn this on its side.  Instead of organizing your 
questions by different functions like mapping discovery/distribution, 
organize them by the points where functions take place.  So instead of 
asking about "mapping churn rate at all possible places", how about "all 
kinds of requirements at intermediate map-n-encap points"?

---

From: Robin Whittle <[email-masked]>
Date: Tue, 01 Apr 2008 10:59:09 +1100

Hi Scott,

> "outdated" mapping entries might still be valid?

I agree with what I understand as your concern - that each practical
proposal has such a different structure that the "dynamics of the
mapping function" needs to be described in different terms for each
proposal.

I can't think of a single answer to Tony's question which covers the
problem in general, since each proposal has its own goals and ways
of coping with challenges.

More about this in:

  Concerns about the RRG process ... & how not to design an airliner
  2008-03-24 http://psg.com/lists/rrg/2008/msg00971.html

Please also see the initial and final paragraphs in my message just
sent "new draft on ' A Taxonomy for ...".

I think the attempt to get a high-level theoretical perspective has
potential value, but if we spend hours trying to contort complex
reality into overly-remote theoretical perspectives, we are wasting
precious energy when we would be better off debating the merits of
each proposal, improving our proposals and improving the way they
are documented.

  - Robin

---

From: "Tony Li" <[email-masked]>
Date: Mon, 31 Mar 2008 19:10:42 -0700

|I understand you're trying to nail down criteria, but I think it's 
|premature to put numbers on this.  

That's fine.  I'd be happy with a qualitative answer or even some more
discussion leading up to a qualitative answer.

|To start with, are you 
|still using a 
|general definition of "mapping", or is the question specific to 
|intermediary-based map-n-encap?  

For now, I'm remaining general, but if it's helpful, we can break it down by
case analysis.

|Second, are you assuming a single 
|database that needs to be updated, or allowing for multiple DBs or 
|distributed DB?  Are you taking into account that in pull models 
|"outdated" mapping entries might still be valid?

I think it's safe to assume that it's distributed.  ;-)  HOSTS.TXT didn't
scale that well.

Yes, of course, pull models have issues.  Should be fodder for discussion...

Tony

---

From: "William Herrin" <[email-masked]>
Date: Tue, 1 Apr 2008 09:18:45 -0400

>  opinion or should I just propose some text?

Hi Tony,

I think there may be four relevant numbers:

Maximum per-machine RIB-style update rate, that is map updates which
are conveyed by the machine but not used in the machine's forwarding
plane

Maximum per-machine FIB update rate for TCAM-based FIBs

Maximum per-machine FIB update rate for hardware-accelerated trie-based FIBs

Maximum per-machine FIB update rate for non-accelerated trie-based
FIBs (read: generic x86 server)

I have trouble imagining a system that doesn't have to contend with
some or all of these limits. No matter how cleverly we structure it,
our system will still be composed of individual machines.

Call me crazy, but I think we pretty much understand how RIBs and FIBs
work within the scope of an individual machine and we know what we can
expect with hardware available today. We can punch BGP routes into
Quagga unbound from server route table and see where it chokes to get
a decent estimate of the maximum per-machine RIB update rate. Similar
strategies should work for the other three. Whether the knowledge
source is a map or a route doesn't make much of a difference at the
individual-machine level. Or am I wrong?

I don't think there is a useful way to pre-assess system-wide maximums
aside from asking proposal authors to specify how tightly bound the
system-wide maximum is to the heaviest-loaded machine maximum and then
justify that analysis.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked] [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004