Scalable Routing Proposals which match Bill Herrin's "Summary
of Routing Architectures discussed in the RRG"
Established
2009-01-03 Robin Whittle, attempting to follow the RRG discussions,
starting here: http://www.irtf.org/pipermail/rrg/2008-December/000592.html.
Last
update (to version 02) 2009-02-24 - changes noted in Red..
Important note
2009-03-01
I have
made a page:
../RRG-2009/rec/
which lists what I think is missing from the current draft of the RRG
recommendations.
Version 02
The
first version of this page was 00. To see an
older version xx, use this directory name with index-xx.html added.
Please don't link to these.
Please see my mailing list
messages (Re: [rrg] Proposals which match rrgarchitectures.html pls
check thepage) for the update history to version 01.
Context
Strategy
A
These are
core-edge separation schemes, with
the
new functionality being
implemented in the network (in or near DFZ, ISP and end-user CE
routers, but also for internal routers for Ivip forwarding
approaches). Will work with existing hosts (except that Ivip
forwarding and PMTUD management won't accept fragmentable packets
longer than a certain size.)
- LISP in all its variants.
- APT.
- Ivip.
- TRRP.
- Six/One
Router (for IPv6 only).
A paper arguing for this class of
solutions (core-edge separation) and against the "elimination" class
(Strategy B) is:
* match.
*~ closest match, but not a full
description.
A1
I am uncertain about these. See the discussion
2008-December/000591
(RW) and
2008-December/000593
(BH). For
now, I am matching them all with A1c, since it is my impression
this best
reflects the current BGP arrangements, and since I understand that none
of these proposals require a change in ISP's BGP arrangements.
LISP- LISP-
APT Ivip TRRP Six/One NERD ALT
Router
A1a A1b A1c * *
* * *
* |
A2
It is
not clear which, if any, of these variants best matches APT. Six/One Router has no specific mapping
system.
LISP-
LISP- APT Ivip TRRP Six/One NERD ALT
Router
A2a *
A2b
*~? *~ A2c
* *~?
* |
A3
LISP-
LISP- APT Ivip TRRP Six/One NERD ALT
Router
A3a *
* *
* * A3b
* |
A4
I think
none of the proposals match A4a or A4b.
This was the text from
version 01:
LISP,
APT and
TRRP match the encapsulation description of A4c, but AFAIK, they do not
have specific arrangements for dealing with the resulting Path MTU
Discovery problems. A4c specifies a particular method of doing
this, which I argue is impractical: [RAM] ITR complexity & security
(ICMP) in LISP-NERD/CONS & eFIT-APT 2007-07-28: http://www.ietf.org/mail-archive/web/ram/current/msg01766.html
. I don't recall anyone arguing it is practical.
Here is some new text:
There was a
discussion of LISP's PMTUD approach on the list starting in late
January 2009 in the thread "LISP PMTU - 2 methods in
draft-farinacci-lisp-11". There I agreed that LISP does have a
PMTUD approach, but that it is not as fully developed as mine: ../pmtud-frag/ . That approach came
from the Open-LISP project. I think that if it was fully
developed to be secure and to reduce the amount of state to be held by
the ITR (for instance by only holding state for packets which might
cause MTU problems) then I think this approach would come to resemble
the one I propose.
LISP-
LISP- APT Ivip TRRP Six/One NERD ALT
Router
A4a
A4b A4c *? *?
*? *?
A4d
*(encaps)
A4e
* A4f
*(PLF v6)
A4g
*(EAF v4)
|
A5
I think
none of the proposals match A5b or A5c.
LISP-
LISP- APT Ivip TRRP Six/One NERD ALT
Router
A5a *
* * *
* * A5b
A5c
|
Strategy
B
This is the
elimination class of
proposals. Any such proposal requires
new host functions, including changes to
host stacks, APIs and applications. Strategy B solutions
do not not require changes to the interdomain routing system or to the
rest of the network, except perhaps improvements to DNS.
No-one
is suggesting such a solution for IPv4 - they are all modifications to
IPv6. This is due, in part, to the lack of IPv4 address space
required for this technique, in which each multihomed end-user network
has a block of space from each upstream ISP, of the same size as its
network's address space.
ILNP
is one such proposal, I think.
HIP
may be another. However neither of these is fully documented as a
solution to the routing scaling problem.
(See
#discuss-01
below - maybe neither of these really fit Bill's description. For
instance, do either have a mapping system?)
Can
anyone confirm this or suggest other proposals? Can anyone write
about B1x and B2x with respect to actual proposals?
Marcelo Bagnulo
Braun suggests ProxySHIM6 may be a Strategy B approach. I know
nothing about it.
Strategy
C
Geographic aggregation. Heiner
Hummel has been proposing this for at least a year - but there is no
substantial documentation of this or any other such proposal.
Strategy
D
I don't know of anyone
proposing FIB compression as a solution for the routing scaling problem.
Strategy
E
There has been no serious
discussion of a billing systems for DFZ routes on the RAM or RRG lists.
Has there every been a serious proposal along these lines?
Strategy
F
Not a solution - do
nothing.
Strategy G
The original vision of IPv6: those end-user
networks which wanted multihoming would get a PA prefix from each of
their
two or more ISPs, and use SHIM6.
Loose Ends and
Discussion
(#discuss-01)
Please see Marcelo Bagnulo Braun's message:
http://www.irtf.org/pipermail/rrg/2009-January/000668.html
.
In version 00 I had SHIM6 in Strategy B, but Marcelo is
correct in pointing out it doesn't match my description of requiring
API or application changes. Nor does it match Bill's description,
at least in this respect: "GUID to LOC maps are pushed from the host
towards a distributed registry as they
change. Hosts request and temporarily cache individual mappings from
the registry as
needed."
Does ILNP really match Bill's Strategy B description?
Does it have such a mapping system?
What about HIP?
Does it fully match Bill's description?
I deleted mention
of SHIM6 from Strategy B and retained mention of it in Strategy G.
Please
see my list message
http://www.irtf.org/pipermail/rrg/2009-January/000670.html
for discussion of whether
ProxyShim6
is a scalable routing solution, and whether it matches any existing
Strategy.
.