Re: requirements sub-group draft

From: Kastenholz, Frank (FKastenholz@unispherenetworks.com)
Date: Wed Dec 12 2001 - 12:47:24 EST


At 12:21 PM 12/12/01 -0500, Jeffrey Haas wrote:
>On Wed, Dec 12, 2001 at 07:44:31AM -0800, Yakov Rekhter wrote:
>> I certainly don't recall such an agreement. In fact, I disagree with
>> the statement that inter-intra domain split is "A Bad Idea".
>
>Perhaps a good question to ask is, "Are there differences in convergence
>properties at the different 'levels' of network hierarchy that warrant
>differentiation in the topology distribution in the protocol?"
>
>Someone else noted that they really just want one protocol with
>N arbitrary levels of hierarchy. We definitely don't want N protocols.
>One protocol may not fit all. Two (IGP/EGP) may not fit all, but
>works "relatively" well.
>
>But I digress. Requirements were being discussed, not implementations.

Yes, there definitely should not be a "if you are at layer N
then you must use protocol X" sort of requirement in the architecture.
Different protocols may be developed to fulfill the different
operational requirements of different operational areas of
the network. For example, RIP is a perfectly adequate protocol
for relatively small, uncomplicated spots in the network, so
RIP when implementation work comes along, RIP ought to be
modified/extended/....'ed so that it can work within the context
of the architecture developed in response to these requirements.
Then, if your network is "small and uncomplex" then you ought
to be able to run RIP.

Basically, when it comes time to develop the actual protocols,
- the architecture should not mandate a preset, fixed, number
  of protocols or protocol 'families' (eg, "2")
- the architecture should allow many protocols to be developed.
  these protocols can be optimized for certain uses within the
  network and from a spec-writing-perspective, an applicability
  statement would say "if your network has attributes X, Y, and Z
  then protocol Q is probably the one you want" (yes, that's
  simplistic but you ought to get the idea :-)
- the architecture, really, specifies the interactions between
  different protocols or different instances of the same
  protocol. basically, it defines the inter-topological-element
  behaviors/interactions/relations.

frank kastenholz



This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT