[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] RRG process clarification



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