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 deployability".
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf