Re: Why?

> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf