[RRG] RRG process clarification

[Lixia Zhang <lixia@CS.UCLA.EDU>]

Folks,

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  
working architecture.
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  
larger perspective.
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.
Regards,
Tony & Lixia



--
to unsubscribe send a message to rrg-request@psg.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