> From: Keith Moore <moore@xxxxxxxxxx>
>> multiple addresses were adopted as the way to do large-scale
>> multi-homing .. because it was the only approach that seemed
>> technically feasible within the existing architecture (both
>> routing, and the various namespaces).
> if it seemed technically feasible, perhaps it was because a problem
> one hasn't tried to solve yet (and which is "somebody else's
> problem") seems more feasible than a problem one is familiar with.
May I point out the "only" in my original statement?
Putting it another way, we have a set of constraints on the solution
space: constraints from routing; and then constraints from deployability
(the multiple address thing you were commenting on, which started this),
etc.
If one *first* applies the constraint of "technical feasability within
the current routing/naming architecture", the only one that makes it
through that filter is "use multiple addresses". What you said was that
if you first apply the "deployability" filter, the set that comes through
that filter does not include that solution.
In other words, no matter what order one applies the constraints (i.e.
whether one starts with the ones one are familiar with, or not), the
set that makes it through both is "null-set".
Noel
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf