Multi-6 [WAS: OT - Vint Cerf joins Google]
Igor Gashinsky
igor at gashinsky.net
Tue Sep 13 00:00:33 UTC 2005
:: All in all, site traffic engineering is NOT going to be an easy problem
:: to solve in a hop-by-hop forwarding paradigm based on clever
:: manipulation of L3 locators. Architecturally, what one would really
:: like is to not worry about the traffic engineering problem per-se.
:: Rather, what is needed is a mechanism that allows congestion control and
:: mechanisms to feed into the address selection algorithms, so that when a
:: link does become saturated, some traffic (but not all! ;-), shifts to
:: alternate addresses.
Traffic engineering is not *only* about congestion, in fact, for a large
content provider, it's about *policy*. Content providers like the fact
that by manipulating the routing policy we can chose to send X amount of
traffic to B via peering link Y (provided that prefix is announced by
both peers Y and Z). We also like that fact that we can change our
announcements so others can only use prefix X through transit provider Y
and not transit provider Z, unless transit provider Y goes away (those 2
are obviously not the only uses of such policies, but are just examples).
For us (and i'm sure not only us) it's about control, and that control
is required for financial, political (and when the 2 intersect), as well as
performance engineering reasons, things that are easily done in v4 right
now, and can not be done simply in v6 (please correct me if I'm wrong
here), unless every datacenter all of a sudden gets a /32 (and if the
folks in ARIN have no problems giving a large content provider a /26
(of v6 space) in order to encourage it's adoption, because the
current multihoming strategies simply do not work, please do drop me a
line)
Moving everything to the end-hosts is simply not a good idea imho.
-igor
More information about the NANOG
mailing list