--pgp-sign-Multipart_Fri_Jun_17_14:02:42_2005-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "iv" == Ivo Vachkov <ivo.vachkov@gmail.com> writes:

    iv> how should the multipath be organized - on a packet or
    iv> connection basis ???

emphatically on a packet basis.

The purpose of cached routes is to speed lookups, and the overall
system needs to behave as if it were consulting just the routing
table, not cached routes.  If the presence of cached routes is exposed
in the overall functioning of the system, IMHO that means the caching
mechanism is broken.  That garbage Linux does to let you ``load
balance'' between ``two ISPs'' by caching the source and destination
IP and nailing it to one of the multiple paths is, well, garbage.
First, if you want to do that, use the firewall, which is designed to
track connections with a lot more subtlety and correctness than a
cached route.  I think we shouldn't confuse this with ``multipath
routing,'' but PF (and ipfilter?) would already have the ability to do
this kind of Linux-multipath with 'keep state' rules and IP pools in
the route-to destination, if the firewall policy routing features
worked.  In the Linux ``load-balancing'' scenario, I think NAT is
applied _after_ the multipath routing, which IMO is silly because
connection state is maintained in two places with different
rules---the policy routing in our firewalls would keep the state in
one place, and more accurately.

Second, the multipath I'm suggesting is not for some pseudo-NAT ``load
balancing'' multiple ISP low-end Interweb nonsense.  I'm suggesting
more like what Cisco and other serious router companies have offered
for years, something that would be used mostly inside an ISP, with a
routing protocol like OSPF or IS-IS to install the multiple paths.  It
could also be used on an ad-hoc wireless mesh, another place people
are using OSPF and other IGPs.  Within and between ISPs, the forward
and return path that a packet takes is usually not symmetric because
of ``hot potato'' routing, so what you see in 'traceroute' is the path
your packets take to reach the destination, but it's generally not the
path they follow back to you.  So, there is no need to cache a route
because you worry in some way about the return path, and obviously for
those using Cisco multipath there is no need to involve NAT anywhere.
Multipath done in the routing table should definitely be per-packet.

--pgp-sign-Multipart_Fri_Jun_17_14:02:42_2005-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQCVAwUAQrMQTInCBbTaW/4dAQJP4QQAkysVJkMXZ/uoybxzFW+YaTUHhAlGvGCK
YVu/eF/lZYIQNzazXWqBW9qMhS6pCGpGjDtMq+Iz/1QRRJ5rQvrFOvA1hjw97Hij
Ww16o1Ed0YsablJf2meP47QN1twxsjkHTtz3hX5bGoBT6qfIKfQoxN0sBYKG1k6Q
E53ydzR6DBA=
=j/Ux
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Fri_Jun_17_14:02:42_2005-1--