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

Re: [RRG] Agenda for Vancouver meeting



Avri,
> 
> I have posted an agenda for the meeting.
> 
>      http://www3.ietf.org/proceedings/05nov/agenda/RRG.txt
> 
> There is still room for anyone else who wants to present some  relevant
> research or research suggestions.

I won't be in Vancouver next week, but given that convergence is one of
the topics that will be adressed during the meeting, I would like to
point out that the convergence problem has broad implications and that
it would be wise to reconsider how routing protocols react to topology
changes.

During the last few years, there has been a lot of activity in improving
the convergence time of intra and interdomain routing protocols. Recent
work [1] indicate that intradomain routing protocols can converge within
less than one second in large network topologies. This requires a lot of
tuning of the implementations of those protocols.

Most routing protocols assume that failures are urgent and unpredictible
and try to react as quickly as possible. This is not necessarily the
best solution. In fact, measurements carried out in the Sprint backbone
have shown that 20% of the failures are caused by maintenance
operations. For those planned failures, the routing protocol should be
able to converge without losing any packet (provided of course that the
network remains connected, but this is always the case in practice).
Today, some solutions have been proposed to solve this problem inside
link-state intradomain routing protocols [2],[3], but the problem is
open for interdomain routing although solutions like EPIC or RCN could
help in this case.

Finally, reacting quickly to failures is not necessarily the best
solution. In practice, a local reaction followed by an ordered
convergence is better than a fast convergence. See for example the
various MPLS-based fast reroute techniques developped within IETF and
the solutions currently being studied within the RTGWG of the IETF.
Those techniques can be use to protect intradomain and interdomain links
[4]. In both cases, it is possible to restore the packet flow within
less than 50 milliseconds after a link failure.

I think that it would be interesting from the perspective of the RRG
working group to consider all kinds of topology changes and see whether
there could be better solutions than simply reducing the convergence time.


References

[1] Achieving sub-second IGP convergence in large IP networks, P.
Francois, C. Filsfils, J. Evans, O. Bonaventure,
ACM SIGCOMM Computer Communication Review, July 2005
http://www.info.ucl.ac.be/people/OBO/biblio-date.html
[2] Loop-free convergence using ordered FIB updates, P. Francois, O.
Bonaventure, M. Shand, S. Previdi, S. Bryant, Internet draft,
draft-francois-ordered-fib-00.txt, work in progress, July 2005
http://www.ietf.org/internet-drafts/draft-francois-ordered-fib-00.txt
[3] Avoiding transient loops during IGP convergence, P. Francois, O.
Bonaventure, IEEE INFOCOM 2005, March 2005, Miami, Fl., USA
http://www.info.ucl.ac.be/~pfr/
[4] Achieving sub-50 milliseconds recovery upon BGP peering link
failures, Olivier Bonaventure, Clarence Filsfils, Pierre Francois,
Co-Next 2005, October 24-27 2005, Toulouse, France
http://www.info.ucl.ac.be/people/OBO/biblio-date.html


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