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".
that assumes that (a) both of the constraints are "hard" constraints
(e.g. you either have leaf nets advertising single prefixes, or you
don't; you either have hosts with multiple addresses, or you don't.)
and (b) both of the constraints have to be simultaneously applied up
front, and then forever. I don't think either of these is true.
and if one of your constraints is scalability and the other is
deployability, you generally want to optimize for deployability first.
that probably sounds like heresy. but it's easier to deploy first and
make incremental modifications for scalability than it is to do the
opposite. well, okay, it might be _easier_ to make the protocol
scalable first and then deploy later, but that' s only because you can
keep refining an undeployed protocol forever without having to worry
about impacting the installed base.
HTTP is a mess, but it's successful because it was "optimized for
Ietf mailing list