Quoted material from document.
>2. System-wide
>Defining a single target for maximum convergence time for the real
>Internet is absurd. As we mentioned earlier, the Internet is large
>enough and diverse enough so that it is quite likely that new
>changes are introduced somewhere before the system fully digests old
>ones.
Do we have an agreement on what convergence time means? In the
current BMWG work, we have tried to make that definition more
rigorous, and also recognize there are several kinds of convergence
time with different scopes. These different times need distinct
names to avoid confusion. While draft-ietf-bmwg-conterm-01.txt is
officially focused on BGP, it really does try to come up with some
fairly general terms.
>
>So, the first requirement here is that there must be mechanisms to
>limit the scope of any one change's visibility and effects. The
>number of routers that have to perform calculations in response to a
>change is kept small, as is the settling time.
Suggested clarification:
The Internet consists of a multitude of scopes (Sx) of
information. A scope
[perhaps a better name is needed] is an area that is aware of detailed
topology, other constraints on that topology, and changes within that area.
A scope contains Rs routers and a variable number, En, of basic network
elements E (such as prefixes or links/path)
It is a requirement that the convergence time of a scope be constant,
within a range TBD.
This implies that convergence time either:
1. Is not a function of the number En, but of Rs.
2. The overall mechanism will automatically divide a scope
that grows too large to meet the convergence time objective,
without impact on the administration of that scope or its
connectivity to other scopes.
There may be a notion of partial convergence within a scope, in which
it can be said that for Z% of the changes (with average interarrival
time Tc), within Y% of the Tc seconds, X% of the routers have converged
**** let's either formally define "settling" or call it a specific kind of
convergence *****
**** and if En is TBD, does that imply that all routers have the same
control plane processing power? ******
>The second requirement is based on the following assumptions
>- the scope of a change's visibility and impact can be limited.
>That is, routers within that scope know of the change and
>recalculate their tables based on the change. Routers outside of
>the scope don't see it at all.
>- Within any scope, S, network changes are constantly occurring and
>the average inter-change interval is Tc seconds.
>- There are Rs routers within scope S
>- A subset of the destinations known to the routers in S, Ds, are
>impacted by a given change.
>- We can state that for Z% of the changes, within Y% of Tc seconds
>after a change, C, X% of the Rs routers have their routes to Ds
>settled to a useful answer (useful meaning that packets can get to
>Ds, thought perhaps not by the optimal path -- this allows some
>'hunting' for the optimal solution)
>X, Y, Z, ARE TBD
>This requirement implies that the scopes can be kept relatively
>small in order to minimize Rs and maximize Tc.
>
>The growth rate of the convergence time MUST NOT be related to the
>growth rate of the Internet as a whole. This implies that the
>convergence time either
>1. Not be a function of basic network elements (such as prefixes and
>links/paths), and/or
>2. That the Internet be continuously divisible into chunks that
>limit the scope and effect of a change, thereby limiting the number
>of routers, prefixes, links, and so on involved in the new
>calculations.
>The growth rate of the convergence time MUST NOT be related to the
>growth rate of the Internet as a whole. This implies that the
>convergence time either
>1. Not be a function of basic network elements (such as prefixes and
>links/paths), and/or
>2. That the Internet be continuously divisible into chunks that
>limit the scope and effect of a change, thereby limiting the number
>of routers, prefixes, links, and so on involved in the new
>calculations.
I think we need a more specific definition of "growth rate of the internet".
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT