Re: [RRG] New RG charter discussion

[Tony Li <tli@cisco.com>]

Hi Dimitri,

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


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


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


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.


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


Agreed.


> 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


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.


> 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


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.


> 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


I agree that more tools would be welcome.

Tony

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