I meant to include a TOC with my previous message. Here it is, with
the conclusion.
The last section compares Ivip with the souped-up real-time version
of my "I-R-lite" subset of IRON-RANGER. It includes a list and
description of all of Ivip's network elements:
ITR, DITR, ITFH; QSA, QSR, QSC; ETR
- Robin
I-R terminology
How I-R-lite differs from the full I-R proposal
I-R-lite description
Goals
Non-goals
Improving I-R-lite
Splitting up the VP file
Alternatives to the VP file
"Aggregating" the VP discovery process
More, cheaper, devices for the IR(LF) role?
Map Updates, resulting in real-time mapping distribution
A different approach to "registering EID prefixes"
(EUNs tell the VP companies directly which IR(EID) routers to
use in the mapping, so the IR(EID) routers don't register
their EIDs with the IR(VP) routers.)
Scaling vs. simplicity - and more on real-time mapping distribution
(Comparison with Ivip.)
To summarize:
I-R is an interesting and in principle relatively simple CES
architecture. However, this simplicity involves a direct
communication path between the ITR-like devices and the
authoritative query servers - with a further "scattergun"
inefficiency in these interactions.
Ivip has more types of network elements and is more complex,
but this enables the workload to be split up in a manner which
reduces total effort - and in particular reduces the total
effort by the authoritative QSA query servers or any other
single network element.
With no low (3 or so) limit on the number of authoritative
QSA query servers, Ivip can have dozens, or in principle
hundreds of QSAs, to share the total load for the MABs they
handle - though I expect most DITR networks to work fine with
10 to 20 sites.
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
