[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] New RG charter discussion
forgot to mention that the understanding of the problem and its modelling
(allowing for extrapolation) is also the only way to reliably determine
a) the severity of the problem (the real issue is that variation in the
estimations result in huge difference over periods of X years)
b) by when the existing routing and addressing system is potentially going
to result in serious problems (how much head-room is left and over which
period can this evolution be sustainted vs routing system capabilities and
their own evolution)
c) which causes are the most impacting and in which conditions they occur
(noticing that some of these causes are constraints, "future" solution
would have to accommodate them)
the point is that (even a partial) an answer to these question can lead to
different levels of investigations in terms of solution space:
algorithmic, new routing paradigms, etc. but also routing protocol
design/engineering, system engineering, etc.
-d.
__________________
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
--
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