Subject: Re: Why?

From: [email-masked] (Noel Chiappa)
Date: Sat, 12 Mar 2005 16:53:14 -0500 (EST)

> From: Keith Moore <[email-masked]>

    >> 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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Sat, 12 Mar 2005 19:37:07 -0500

> space: constraints from routing; and then constraints from 
> deployability (the multiple address thing you were commenting on, 
> which started this), etc.
>
> 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.
>

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".