[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] RRG process clarification
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: owner-rrg@psg.com [mailto:owner-rrg@psg.com] 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 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
>
--
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