|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
:: 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
|