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

Re: [RRG] New RG charter discussion



the sentence 


"At the moment, the Internet routing and addressing architecture is facing 
challenges in scalability, mobility, multi-homing, and traffic 
engineering."


is ambiguous, that statement tends to bundle causes and consequences and 
imho creates an amalgam in the problem statement the RRG is going to work 
on:


o) routing system problems

- stationary: scalability (RIB & FIB size)
- transient: efficiency updates (add, remove) frequency, and
  resulting convergence time 

o) root architectural causes 

- protocol dual stack (due to address space scaling)
- address = locator (result in traffic engineering issue ~ meshedness) 
  use address as identifier (result in policy routing issue) 
- mobility and multicast (overlay applications)

o) operational causes

- traffic engineering leading to prefix de-aggregation
- policy routing leading to prefix de-aggregation
- dual/multi homing (for resiliency)
- address allocation (due to address allocation policy)


but the major problem is not there:


o) FIB capacity combined to improved search algorithm solves the 
stationnery problem not transient problem (i.e. routing dynamics), the 
latter is where IETF can play a role, the former is a vendor-specific 
system engineering design - hence the question becomes where/what is the 
role of the research community ?

o) if system engineering can come to a solution for the stationary problem 
(without complete routing engine re-design) it still does not mean it 
solves the causes, i.e, such solution is not going to eliminate the need 
to support for mobility, multicast or traffic-engineering (hence the 
latter become part of the constraints to be taken into account)

o) one can also notice that the slope of the curve of increasing number of 
prefixes is also important to analyse (growth rate) vs system 
capabilities/needs - for the time being, the internet community at large 
can only benefit from ad-hoc measurement or unreliable predictions (based 
on rough extrapolations) in order to derive such behaviour - from that 
perspective, it is noticeable that no effort is considered to provide for 
a reliable and robust (i.e. scientific) methodology to analyze the 
phenomenon itself - this means that as chartered, the RRG will never be 
able to play a real  role in predicting / anticipating such "consequences" 
but also RRG will never be able to confirm or infirm engineering community 
expectations


hence, before focusing on engineering long or short term solutions (role 
of the IETF), the IRTF shall focus on real research tasks, such tasks 
start by asking what are the causes of the problem and how the current 
system with its goodies and flaws can be modeled - in brief, the role of 
the IRTF is to ask WHY such behaviour occurs, identify causes of the 
problem and model global system behaviour


the lack of systematic tools is a REAL issue that the research community 
at large shall address before trying to work on engineering oriented 
solutions


thanks,
- d.






Lixia Zhang <lixia@CS.UCLA.EDU>
Sent by: owner-rrg@psg.com
24/02/2007 19:22
 
        To:     rrg <rrg@psg.com>
        cc: 
        Subject:        Re: [RRG] New RG charter discussion



On Feb 19, 2007, at 3:43 PM, Lixia Zhang wrote:

> With the help from Aaron Falk, Tony and I drafted a new charter for 
> RRG, see attached below.  We would like to solicit people's inputs 
> and comments regarding the new charter.
>
> Tony and Lixia

It's bee a week since we posted the new charter draft.  We got one 
reply from Heiner (Thanks Heiner !).  This is a final call for input: 
If anyone has any further comment, please speak up now; if you agree 
with the new charter, we'd like to hear that too.
Otherwise we'll need to interpret the silence as consensus.

Tony and Lixia

> ----------------
>
> The Routing Research Group (RRG) is chartered to explore routing and
> addressing problems that are important to the development of the 
> Internet
> but are not yet mature enough for engineering work within the 
> IETF.  As the
> Internet continues to evolve, the challenges in providing a 
> scalable and
> robust global routing system will also change over time.  At the 
> moment,
> the Internet routing and addressing architecture is facing 
> challenges in
> scalability, mobility, multi-homing, and traffic engineering.  Thus 
> the RRG
> proposes to focus its effort on designing an alternate architecture 
> to meet
> these challenges.  Although Internet routing is a broad and active 
> research
> area, a focused effort at this time is necessary to assure rapid 
> progress
> towards reaching the goal.
>
> More specifically, we propose to explore architectural alternatives,
> including, but not limited to, separating host location and 
> identification
> information.  Research in addressing and algorithms will be 
> encouraged to
> understand whether this new direction can provide effective 
> solutions, to
> work out candidate designs as necessary for a complete solution, 
> and to
> fully understand both the gains and the tradeoffs that the new 
> solutions
> may bring.  The group will produce a list of prioritized design 
> goals and a
> recommendation for a routing and addressing architecture.
>
> The RRG will have an open general discussion mailing list where any
> topic of interest to the routing research community can be discussed,
> and topics related to scalable routing architectures are particularly
> encouraged.  For specific topics with widespread discussion,
> interested parties will be encouraged to form ad-hoc mailing lists,
> with summaries sent to the general mailing list quarterly.  Summaries
> will contain the recent conclusions reached as well as the near-term
> agenda for future progress.
>
> It is commonly recognized that productive design efforts can be
> carried out by small and focused design teams.  The RRG encourages the
> formation of focused design teams to explore specific design choices.
> As with ad-hoc mailing lists, individual design teams are required to
> report back quarterly to RRG with their progress and remaining open
> issues.  Each design team is expected to produce a set of Internet
> Drafts that documents their current thinking.
>
> The RRG, as a whole, will hold open meetings from time to time to
> solicit input from, and supply information to, the broader
> community. In particular, at least once per year there will be a
> review of the group's activities held at an IETF meeting.  More
> frequent meetings will be held if it will speed group progress.
> Ad-hoc and design team meetings are strongly encouraged.
>
> The output of the group will consist of Informational and Experimental
> RFCs as well as Journal Articles on the topics covered by the
> subgroups.
>
>
> --
> 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



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