> From: Russ White <[email protected]>
> What about traffic engineering? Will a loc/id split "solve" traffic
> engineering (which is normally done by leaking longer prefixes today),
> and if so, how?
Well, in the abstract, you can do some kinds of traffic engineering this way;
some things you can't do without 'true' traffic-engineering, i.e. with
support for all the traffic path control things you want to be able to do
designed into the architecture. (Which is also true of doing TE with
more-specifics, BTW - there are some things you can't do with them, either.)
Exactly what you can do depends on the details of the particular loc/id split
design; e.g. does each endpoint name map into just a single locator, or
multiple? (Many of the benefits of loc/id separation, especially in the
routing realm, come from the ability to map to multiple locators, so I would
assume most schemes would allow this.)
> I understand you can "map" the id to the locator you'd prefer to bring
> the traffic in through, but does that truly solve the traffic
> engineering problem unless you also have one locator per possible exit
> point (customer/edge pair) for every (transit) network in the world,
> and does this actually scale better than what we have today?
I'm not sure I understand 100% what your model is here. (I suspect you're
asking about the inherent limitations of trying to do path control with just
a destination address, as opposed to a fully specified path - this is related
to my point above, about the limitations of various kludges to do TE.)
However, let me point out a few things about loc/id split, and scaling.
TE done with routing is inevitably a 'push' system, in which i) everyone has
to find out about the more-specifics, and ii) everyone has to pay part of the
cost. (I understand that if we limit scopes, we can reduce the 'everyone'
somewhat, but even in that restricted scope, we are burdening the distributed
routing computation with those extra paths.)
Done with mapping, though, i) only the entities which are actually
communicating with the destination need to get the extra information (i.e.
it's a 'pull' system), and ii) instead of being involved in a large
distributed computation, the extra computation involved, for those entities,
is just a mapping step.
> IE, what's the incentive to aggregate locators, vs the incentive for
> de-aggregating locators, or even assigning tons of locators because,
> "well, it's free to advertise a locator, and the table is really small,
> so..."
Not sure I completely understand what you're asking here? The abstract
incentive to aggregate locators is to minimize routing overhead; I understand
that at the moment there's no practical incentive descendant from that, but
perhaps if more-specifics start getting filtered, or something, there will
bey a real incentive.
And why is assigning tons of locators bad? Yes, assuming your mapping system
supports 1->many mappings, the individual mapping entries are bigger, but
most sites will only have a subset of the mappings (for correspondents), so
the overall size is not a problem.
> It seems to me the locator table will end up just where the routing
> table is today--there's no cost to advertise the things, so, hey, why
> not?
Are you assuming that every site has a copy of the entire
{identity->location} mapping table? I guess I've been assuming that it's
demand loaded, and cached, in which the size of the complete 'table' is not
an issue.
Even if it is fully loaded, the dynamics of updating a mapping table are
different from the dynamics of path computation, especially when the latter
is done (as now) via a giant distributed computation.
> You could, I suppose, constrain the locator space so its very small,
> but that doesn't seem like a very good solution, either.
I don't understand what you mean by 'locator space'? Do mean the namespace,
or the number of assigned values from that namespace, or what?
> From: Tony Li <[email protected]>
> as we've discussed before, traffic engineering through deaggregation is
> a self-inflicted problem.
It may well be self-inflicted, but that doesn't mean that what they want to
do, at a high level (i.e. engineer traffic, not inject more-specifics) is not
legitimate. The problem is that the architecture does not give them a better
tool to do traffic engineering with; hammer-nail.
Noel
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
