[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] RRG process clarification
We've been told that the process that we're trying to execute is still
not clear. Here's an attempt to clarify things.
Our ultimate goal is to deliver a recommendation for a routing
architecture. Please note that our goal is NOT to deliver a wholly
complete, fleshed out routing subsystem implementation, complete with
protocols, specs, and running code. Those are all non-goals. Although
one can potentially learn a great deal from running implementations,
they are more useful in improving designs than fundamental
architecture. What we should be doing is trying to reach consensus on
the various pieces of the architecture.
An architecture (a.k.a., a framework) is a set of concepts around how
a system works. An architecture divides the system into its various
subsystems and describes the functions of those subsystems and their
interactions. Obviously, one can iterate down, performing
hierarchical decomposition of the architecture. If you pursue this
far enough, then you'll find that you have an implementation, but
again, that's not our charter. We need only go so far as to provide a
The level of detail that we have to deliver is certainly open to
discussion. Since we are not expected to deliver the engineering part
of the solution, it is sufficient for us to provide enough specifics
so that good, competent engineers can take the architecture and design
the details of a solution without further guidance.
Initially, we started with putting a number of proposals on the table,
which helped us better understand the design space. However we have
noticed that lately the discussions have mostly focused on microscopic
detail about the various proposals instead of the high level
architectural issues. This is natural, we have a great deal of
engineering experience, and we're more easily attracted to how the
little bits work at the bottom than how things should look from the
Unfortunately, our charter is to understand that larger perspective.
There is a very broad solution space at hand, and we need to
understand the breadth of it. Yes, we could simply pick one solution
and go with that, but we would not be performing our due diligence.
The community has placed in us the responsibility to understand the
whole of the solution space, partition it, and select the best path
through it. Without exploring the solution space at least a bit, we
won't have done a credible job of thinking about all of the ways that
we could architect the system.
Further, once we have surveyed the solution space, we need to develop
rough consensus on the approach through the solution space. Arguing
about 'incremental deployment', for example, doesn't help this at
all. We need to first come to some agreement on the very highest
level branches in the decision tree (e.g., do we do map-and-encap or
translation or ???), and not worry about the detailed leaves. That is
up to the IETF to wrestle with.
Getting a consensus on this very highest level branches is a difficult
task, as it requires a good understanding of multiple important
factors as well as their interplays, perhaps with the mapping system
design as a centerpiece. Again, our job is to deliver an architecture,
thus we must first reach such a consensus.
As we gain consensus on more and more of these high level design
decisions, we will then be able to put together a sound architecture.
For people who are experienced engineers, this is somewhat analogous
to writing a functional specification of a system. We need not do the
entire work of detailed design. Rather, our task is to specify all of
the vital properties for later refinement.
Tony & Lixia
to unsubscribe send a message to email@example.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg