[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