Re: [RRG] RRG process clarification

[Peter Sherbin <pesherb@yahoo.com>]

> We need to first come to some agreement on the very highest  
> levetl branches in the decision tree (e.g., do we do map-and-encap or  
> translation or ???),...

This sounds good and in line with the original expectations of RRG. It looks that the initial step is to define drivers or building blocks (the Internet atoms - "iats" - if you will). Next would be to agree on how drivers interact (or how we want them to interact) thus outlining an architecture.

There were several attempts to list drivers and major concepts such as location ID; name ID; what physical item must have a location ID; which items must bear a name ID; location ID space/structure; name ID space/structure; behavior of items with name IDs; role of items with location IDs; a wireline connectivity is a private instance of generally mobile world; etc. Formulating a general principle such as "a sender of the data bears costs of the data delivery to the final destination over the network" would guide the actual participants in all aspects of their Internet activities thus helping with the implementation in a long run.

Thanks,

Peter


--- On Fri, 4/18/08, Lixia Zhang <lixia@CS.UCLA.EDU> wrote:

> From: Lixia Zhang <lixia@CS.UCLA.EDU>
> Subject: [RRG] RRG process clarification
> To: "rrg" <rrg@psg.com>
> Date: Friday, April 18, 2008, 3:07 AM
> 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


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

--
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