hi, > 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.
after the rrg-design-goals drafting, floor has been left open to the low level specification and implementation level. hence, the four steps between goals and low-level specs -- the principles, the models, the components, and the high-level specs -- have not been (seriously) addressed so far. the consequence of skipping these steps are: 1. low-level specs look already like a set of patches with unpredictable performance and impact/ consequences (the last mtg discussion was clear about this). by thinking locally and try acting globally this is the only result one could reach anyway. 2. there are different low-level specs under discussion while the bottom line shall be on common components and their interactions (before reaching the high-level spec stage). > Unfortunately, our charter is to understand that larger perspective. when looking at the rear mirror, one could observe that after brief consideration on goals and objectives, the low-level development phase has started without taking into account global architectural considerations. the design space analysis that has been launched is a not proof point either since they can not lead to further work on the model and the components of the common architecture (since the latter were not specified). i simply hope that this "process clarification" will lead the group toward routing system architectural sound work and outcome. thanks, -d. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Lixia Zhang > Sent: Friday, April 18, 2008 9:07 AM > To: rrg > Subject: [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 [EMAIL PROTECTED] 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 > -- to unsubscribe send a message to [EMAIL PROTECTED] 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
