>Howard,
>
>We are purposely hoping/intending these requirements
>to lead to new, different, novel, ... architectures
>and protocols. Things like draft-ietf-bmwg-conterm-01.txt,
>for example, are written from the perspective of the
>current architecture and protocols (in particular BGP).
>If we use them as a basis for the requirements document
>we may tend to bias people to thinking "they just want
>to hack BGP a bit more" (ok, I'm being a bit overdramatic
>here to make the point) when in fact what we want is the
>exact opposite.
>
>Frank Kastenholz
Frank,
I recognize that the BMWG document officially is written from the
perspective of BGP. We are, in fact, trying to coordinate it with FIB
based convergence and IGP convergence.
But I'd ask you to share some of our thinking rather than the literal
document. The team's feeling is that there were NO rigorous
definitions of convergence, and they are desperately needed. If the
IRTF-RR could take our work and further generalize it, I think both
the BMWG team would participate and be generally delighted.
I don't see, however, how the requirements and architecture can
progress without better definitions of convergence, much less with
the introduction of undefined terms such as "settling."
Think of definitions of convergence, of identifier vs. locator, etc.,
as saws and hammers to build the Reliquary of Requirements and the
Ark of Architecture.
>
>At 12:40 PM 3/5/02 -0500, Howard C. Berkowitz wrote:
>>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".
>
>==================================================
>My preferrred signature is:
> This information is for the sole use of
> whoever receives it and may contain confusing,
> enlightening, enraging, entertaining,
> irritating, or just plain stupid information,
> including without limitation, double-secret-
> probation information belonging to [CENSORED
> BY THE NSA/FBI/MOUSE]. Any unauthorized review,
> use, disclosure, or distribution outside of an
> establishment serving alchohol is prohibited on
> days that do not end in Y.
>But our ******'d lawyers would rather have:
>
>=======================================
>This email message is for the sole use of the intended recipient (s) and may
>contain confidential and privileged information, including without
>limitation, Confidential and/or Proprietary Information belonging to
>Unisphere Networks, Inc. Any unauthorized review, use, disclosure or
>distribution is prohibited. If you are not the intended recipient, please
>contact the sender by reply email and destroy all copies of the original
>message.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT