> From: "Kastenholz, Frank" <FKastenholz@unispherenetworks.com>
> 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.
Unless, of course, the basic architectual framework is so different that you
can't really jam RIP into it. If you have the choice between i) doing the
right thing, and ii) making it compatible with RIP, I hope for Ghu's sake
that people pick i).
> 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")
I suppose I can see circumstances in which there might be a need for a
special-purpose protocol - i.e. not one that's part of the "standard"
package, but I think it should be assumed to be very unusual, and not the
"canonical" method.
(Note that there's a difference between protocols and algorithms. TCP has one
protocol for sending ACKs and retransmits and such, but there are many
different deployed algorithms for when to do those things. Similarly, a
well-designed routing architecture ought to allow different algorithms for,
e.g. how you do your topology abstraction for external advertisment - but it
should happen in the context of a single protocol for sending out those
advertisements.)
For one, if you have a box which is only talking some specialized protocols,
it won't be able to interact with other boxes *if need be*. (I understand
that there will be policy reasons to constrain interactions, and that's OK.
I'm talking about the inverse; when you want to talk, but the technology
simply doesn't allow it.) When the design makes some interactions
hard/impossible, people can't do interactions if they later decide they need
to - and this constraint on interactions between different entities can
really be a crippling problem.
In general, the protocol should be sufficiently flexible to handle most
cases. If it's not, then something's wrong.
> - the architecture should allow many protocols to be developed.
> these protocols can be optimized for certain uses within the
> network
Same comments all over again.
Noel
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT