One of the interesting points about locator / identity separation is
that it allows (at least in some solutions), the distribution of traffic
engineering authority and responsibility.
Currently, either you have an AS number, and advertise in BGP, in which
case you have about as much control as you our current system allows
over path selection, or you do not have an AS number, and have no control.
With ID ? Locator, the enterprise as influence / control over the
information in the mapping system, while the service providers can still
perform traffic engineering relative to their aggregatable locators.
Yes, that does mean that they can de-aggregate. But The scope of
control is much more about how traffic flows within their domain,
instead of controlling how traffic reaches their customers (which is
their customers' concern.) As long as the two functions are conflated,
it is really hard to separate the engineering domains.
Yours,
Joel
PS: My primary concern is the potential driver from large numbers of
multi-homed enterprises. Most ISPs are at least aware of the trade-off
they are making when they disaggregate. And there are even social
forces at work to help reduce that. Whereas the evidence is that the
RIR pressure against PI in IPv6 is very weak.
Noel Chiappa wrote:
> From: Russ White <[email protected]>
> I can give you examples where loc/id will reduce the table size. ...
> Anecdotal evidence doesn't provide an answer, though.
Those 'examples' weren't individual examples, but examples of _classes_ of
scenarios where separation of location and identity can, if the engineering
details of the location/identity scheme used are appropriate, provide reduced
routing table sizes. In the second (site multi-homing) case I mentioned, this
reduction is over a global scope - which is of particular interest as it seems
to be a fairly common one.
Your original statement was "I don't know that loc/id separation 'solves' any
sort of 'table size' issue." Well, I don't know about you, but to me,
significantly reducing routing table sizes globally does indeed count as
'solv[ing a routing] 'table size' issue".
> 1. We have mechanisms we could use to reduce the table size today,
> already in the protocols coded and deployed.
> 2. Such mechanisms are not used today.
> 3. Why?
Presumably because use of those mechanisms precludes doing something else
people want to do, which they cannot otherwise do because _there is no
mechanism available to do it in a way that also meets other goals they have_.
So perhaps if we provide such an alternative mechanism, things will be
different.
> longer prefixes are important to control the way traffic _enters_ their
> networks. The degree of control here is rather find grained, in fact,
> based on ... even where specific services live in the customer's
> network.
> Given all the above, some major part of the answer to "why," in #3
> above, seems to me to be, "because we want to control inbound traffic
> flow."
And a appropriately designed location/identity separation system does provide
inbound traffic control (in fact, that was my _first_ example). So if it's
really inbound traffic control that needs to be provided, then I'm happy,
because an appropriately engineered location/identity separation system does
provide that capability - and at least one existing system does provide it.
> Well, there is a third--just deal with the additional state.
You missed #4 - be smarter about who has to get what state.
> I suspect you just end up with a locator table that's generally about
> the same size as the current routing table (my guess is it will end up
> being at least one loc per PE, possibly more, depending on your model),
> and an ID table that's absolutely _flooded_ with new state (after all,
> the state is now externalized in such a way that advertising an IPv4
> /32 doesn't really "cost" anything any longer, does it?).
What's a 'locator table'? Do you mean the routing table (which is exactly the
same in location/identity separate architectures as it is now)? Exactly what
kind of size evolution it will see is hard to predict, but to the extent that
site multi-homing is driving growth, another way to do site multi-homing would
presumably slow down that growth.
And I'm not certain what the 'ID table' might be; I'm assuming it's the
{identity->location} mapping database. It might be 'large' in the abstract
sense (because it will never be agglomerated together in one place, unless
someone does a tree-walk to build a complete local copy of the database), but
DNS is also 'large', and that doesn't seem to be an issue because... we're
smarter about who has to get what DNS state. (This has all been explored in
some depth, including being modelled in considerable detail, using full-scale
simulations. See the papers I mentioned in a previous post today.)
> the state is now externalized in such a way that advertising an IPv4
> /32 doesn't really "cost" anything any longer, does it?
Not really - which is why mobility is another potential application for
location/identity separation. The cost is a mapping cache entry in only those
entities the mobile entry is communicating with, and a small amount of control
traffic to distribute those mapping entries, and keep them up to date as the
mobile node moves.
> The roots of this problem are policy and economics, not technical.
So then what causes the common (so common it has a name) hammer-nail syndrome,
if not _not providing appropriate tools (i.e. technology) to do what people
need to do_ (and which they need to do for political and economic reasons)?
There are things that people want to do (e.g. control inbound traffic,
multi-homing) which are _perfectly reasonable things to want to do_ - the only
problem being that the current Internet architecture doesn't provide any good
tools to do them. So we wind up with ugly kludges, and routing tables which
grow rapidly. Maybe we should provide better tools (technology) to do those
things...
> I just that I don't think reality will curve the way we want it to just
> because we think it should.
True. As Feynman said, "For a successful technology, reality must take
precedence over public relations, for Nature cannot be fooled." But again,
if all you give them is a hammer...
Noel
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
