Subject: [RRG] New RG charter discussion

From: Lixia Zhang <[email-masked]>
Date: Mon, 19 Feb 2007 15:43:46 -0800

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

----------------

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 [email-masked] 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

---

From: [email-masked]
Date: Tue, 20 Feb 2007 12:11:16 EST

Lixia,
I guess the more inner IRTG/rrg webpages need some updating (e.g wrt  current 
chairs).
Are the subgroups still in place ?
 
Heiner
 
In einer eMail vom 20.02.2007 00:45:02 Westeuropäische Normalzeit schreibt  
[email-masked]:

Tony and  Lixia

----------------

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Feb 2007 10:53:05 -0800

On Feb 20, 2007, at TuesdayFebruary20,9:11 AM, [email-masked]  
wrote:

> I guess the more inner IRTG/rrg webpages need some updating (e.g  
> wrt current chairs).

Yes, the web page will be updated when we converge on the charter.

> Are the subgroups still in place ?

We're trying to avoid using subgroups, under the theory that they  
balkanize the community unnecessarily.

Tony

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 24 Feb 2007 10:22:03 -0800

> and comments regarding the new charter.

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

> but are not yet mature enough for engineering work within the  
> IETF.  As the
> may bring.  The group will produce a list of prioritized design  
> goals and a

---

From: [email-masked]
Date: Sun, 25 Feb 2007 00:41:10 +0100

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 <[email-masked]>
Sent by: [email-masked]
24/02/2007 19:22
 
        To:     rrg <[email-masked]>
        cc: 
        Subject:        Re: [RRG] New RG charter discussion

Tony and Lixia

---

From: [email-masked]
Date: Sun, 25 Feb 2007 10:19:35 +0100

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

o) operational causes

thanks,
- d.

To:     rrg <[email-masked]>
cc:

Tony and Lixia

---

From: Tony Li <[email-masked]>
Date: Sun, 25 Feb 2007 11:33:41 -0800

Hi Dimitri,

> imho creates an amalgam in the problem statement the RRG is going  

Agreed.  This is a necessity, as the charter is by nature a broad and  
inclusive statement.

> stationary problem not transient problem (i.e. routing dynamics), the

The architectural deficiencies that you cite above become the drivers  
for FIB growth that cannot be economically sustained.  Thus, the  
thought is that by producing a more scalable architecture, we can   
reduce the FIB growth rate.

> latter become part of the constraints to be taken into account)

Agreed.

> but also RRG will never be able to confirm or infirm engineering  

I think that the RRG is a fine venue for collaboration, but the  
ongoing study and monitoring of the DFZ table is a non-trivial  
undertaking that will require funding.  As the RRG is not a funding  
organization, it can at most connect the funding with the researchers  
to put this type of study in place. This is certainly something that  
I'd like to see happen.

> problem and model global system behaviour

I have no problems with further investigation into the details of the  
problem.  However, some of us are already quite convinced (through  
first hand observation) that there is a real, tangible problem that  
needs to be addressed.  As a result, I'm not willing to completely  
serialize our work dependent on the outcome of research into the  
problem.  Thus, we should simply push on in parallel.

> at large shall address before trying to work on engineering oriented

I agree that more tools would be welcome.

Tony

---

From: Tony Li <[email-masked]>
Date: Sun, 25 Feb 2007 11:38:54 -0800

> design/engineering, system engineering, etc.

We already have one talk lined up for Prague that purports to provide  
a preliminary description of the problem.  It should be an excellent  
launch point for those that are interested in spending more time on  
problem analysis.

For folks that agree that some architectural changes are necessary, I  
suspect that the scope of the solution space will be bound more by  
the other requirements that we choose to address rather than the  
details of the scalability problem.  For example, architectural  
support for nomadicity may easily subsume any difficulties presented  
by multi-homing.

Regards,
Tony