Let me repeat and expand upon my remarks just now.
-- The place --
There are three obvious places to implement the locator/identifier
(or locator/locator) mapping:
1. in hosts
2. in site border routers / middleboxes
3. in ISP networks
In hosts is extremely problematic for a number of reasons:
- costs and benefits aren't aligned with regard to the routing table
issue, so not enough incentive for deployment
- the number of hosts is enormous, updating them all takes
prohibitive amounts of time
- middleboxes and the like make any kind of change, especially with
IPv4, very hard to deploy
- there is no reason to assume that renumbering locators will be
significantly easier than renumbering host addresses is today
On the other hand, the advantage of working in hosts is that the
additional state is least problematic there because hosts already
keep state for all their sessions/associations.
Site border routers or middleboxes share the economic issue and, to a
lesser degree, the renumbering issue. Middleboxes (but not site
border routers) also generally store state for active sessions and
the number of sessions is still relatively limited at this point, so
a chaching mechanism is still workable here.
Performing the mapping in ISP networks has the very important benefit
that cost and benefit are aligned, but at this point, the number of
sessions flowing through any individual box is almost certainly too
large to be safely handled using caching, so flooding of at least
some state for all possible destinations is probably required.
Additionally, it's not too problematic to push something that started
in ISP networks to middleboxes, and something in middleboxes to
hosts, but the other way around is often not possible or very hard.
See the issues with shim6 proxying
-- A mapping system --
As I said, BGP and DNS can both be considered to be mapping
protocols, and they both have some aspects that are desirable and
some aspects that are problematic.
The DNS can carry millions of entries in a single zone (with some
effort) and probably an unlimited number of entries given a suitable
hierarchy. However, it requires on-demand operation, which means
dropped packets and/or delays at session start and the risk of caches
(see SQL slammer worm experiences). The DNS also has caching so not
only do you not get any updates when something changes, if you (as an
application) go out and ask again, you get a cached answer.
BGP on the other hand floods everything but has serious scaling
issues and suffers from the problem that local optimizations
introduce global state. Additionally, BGP is a routing protocol so it
needs to know about paths and loops, which means that information in
BGP must be updated at each hop.
What we need in a new mapping system is the scalability and
parallelism of the DNS coupled with the immediacy of BGP, but where
BGP distributes next hop information, the new mapping system should
distribute "last hop" information.
Margaret (I think) brought up the point that if a new mapping system
contains all the information that's now in BGP, we haven't really
gained anything. That's not necessarily true. The problem with BGP is
not so much the amount of information, or even the number of updates,
but rather, the need for all this information to come together in one
place: the RIB of every core router. If the new system is designed to
allow the easy splitting up the full state of the entire internet
over an arbitrary number of devices, each of those devices can live
at the knee in the price/performance curve.
An important goal in a new mapping protocol should be the ability to
flood updates where needed, i.e., in the case of multihoming where
the fact that one ISP is no longer usable is important to know for
all correspondents of the multihomed site, and the more deliberate
propagation of information that isn't time sensitive, such as the
movement of a single homed user of PI space. Additionally, such a
protocol can supply hooks for obtaining more detailed information
directly from the source. This would be useful in mobility, where a
destination is always reachable through the home agent, and a slight
delay in optimizing the path towards the current location of the
mobile node isn't problematic. In the same way, the flooded mapping
state could be highly aggregated and therefore make packets flow
rather suboptimally, but as soon as communciation starts, better
mappings can be negotiated end-to-end.
If we go for a "jack up" solution to the routing scalability problem,
existing PI prefixes can be jacked up one by one, facilitating
gradual deployment. However, the mapping mechanism could be made
forward compatible with more advanced identifier/locator splits so
the benefits would be in both the short-medium and long-medium terms.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
