Short version: Please contribute to the IRTF Routing Research Group
discussions on how to devise a new Internet
architecture (including by adding to the current
architecture) to solve the routing scaling problem.
Hi John and All,
This discussion includes debate about whether in a new Internet
architecture, the responsibility for handling network-centric
problems should in future be handled by hosts. These network-centric
real-time events, problems and responsibilities include:
1 - Multihoming.
2 - Traffic engineering.
3 - Portability of address space - or some other, yet to be
invented, approach which has the same effect of making it easy
to choose another ISP without the disruption, cost etc.
Please take a look at the current discussions in the IRTF Routing
Research Group. The RRG has been charged with the responsibility of
recommending to the IESG what sort of architectural changes should be
made to the Internet (really, the IPv4 Internet and the IPv6
Internet) to solve the routing scaling problem. The deadline is
March 2009.
RRG mailing list archives, wiki and charter:
http://www.irtf.org/pipermail/rrg/
http://trac.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup
http://www.irtf.org/charter?gtype=rg&group=rrg
The RAWS workshop (Amsterdam October 2006):
http://tools.ietf.org/html/rfc4984
http://www.iab.org/about/workshops/routingandaddressing/
I wrote a critique of any solution which pushes new responsibilities
onto hosts which concern things which occur in the network:
Fundamental objections to a host-based scalable routing solution
http://www.irtf.org/pipermail/rrg/2008-November/000271.html
Bill Herrin has a page which attempts to list the various approaches
to solving the routing scaling problem:
http://bill.herrin.us/network/rrgarchitectures.html
I think the problem definition there is biased towards the notion
that the solution is to have hosts take on new functions, including
with changes to stacks, APIs and applications. I wrote some
additional text which I think provides a more complete problem
description:
http://www.irtf.org/pipermail/rrg/2008-December/000525.html
Also of interest is a recent paper contrasting network centric
core-edge separation schemes with host-centric "elimination" schemes:
Towards a Future Internet Architecture: Arguments for Separating
Edges from Transit Core
Dan Jen (UCLA), Lixia Zhang (UCLA), Lan Wang (University of
Memphis), Beichuan Zhang (University of Arizona)
(HotNets-VII) Calgary, Alberta, Canada October 6-7, 2008
http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf
Bill is currently calling for RRG members to form strong consensus on
rejecting one or more solution strategies. (Msg 000554.) The types
of strategy are (with my descriptions for A, B and C):
Strategy A:
Network-based core-edge separation schemes, including LISP, APT
Ivip, TRRP and Six-One Router. (See the RRG wiki page for links.)
Strategy B:
Host-centric elimination schemes. "Elimination" means all end-user
network addresses are subsets of ISP prefixes. Only ISP prefixes
are advertised in the interdomain routing system.
See Brian Carpenter's message on how this is "unworkable for IPv4
and very close to the plan of record for IPv6" - except that
IPv6 doesn't provide multihoming (session survival when the
currently used ISP-provided address becomes unusable).
http://www.irtf.org/pipermail/rrg/2008-December/000577.html
Strategy C:
New interdomain routing system arrangements, including for
instance: geographical aggregation or compact routing.
(A critique of compact routing: http://arxiv.org/abs/0708.2309.)
Strategy D:
"Use plain old BGP for the RIB. Algorithmically compress the FIB in
each router."
Strategy E:
"Make no routing architecture changes. Instead, create a billing
system through which the folks running core routers are paid by the
folks announcing each prefix to carry those prefixes. Let economics
suppress growth to a survivable level."
Strategy F:
"Do nothing. (RFC 1887 § 4.4.1)"
My message calling for strong consensus in rejecting Strategies B, C,
D, E and F:
http://www.irtf.org/pipermail/rrg/2008-December/000565.html
- Robin http://www.firstpr.com.au/ip/ivip/
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf