> From: Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>
> for wanting to move the cost of multihoming out of the core. But
> pushing those costs onto hosts and applications was moving those costs
> even further away from those who benefit from multihoming, than was the
> case in IPv4.
I am completely unable to understand how you come to this conclusion.
How is it that moving the costs of multihoming onto i) the multi-homed site,
and ii) those who use that multi-homed site "mov[es] those costs even further
away from those who benefit from [that] multihoming"? If it's not the
multi-homed site, and its users, which benefit from the multihoming, who on
earth is it?
> it seems to me that people keep wanting to take (relatively)
> straightforward, bulletproof interfaces and replace them with fragile
> ones that depend on extra layers of indirection, and additional
> services that (a) can fail, (b) don't share fate with the endpoints and
> (c) are likely to be very sensitive to configuration errors, all for
> the sake of some notion of architectural purity.
Abraham Lincoln was once asked 'How long should a person's legs be?' His
simple reply was 'Long enough to reach the ground'. So too it is with
structural (archictural) complexity. You need as much as you need.
It's not 'architectural purity' (whatever on earth that might be) that's
motivating people to suggest adding another level of indirection; rather,
it's the recognition that a given structure only works over a certain range
of sizes (and capabilities), and to get bigger than that, you need a new
structure.
Try building a brick house 100 stories tall - it simply won't work. Are those
who point to steel-frame structure for such edifices motivated by this
"architectural purity" you speak ofa?
> it's a fundamentally bad idea if you don't do very careful engineering
> on it to make sure that the resulting system is as reliable was it
> would be without the extra layer of indirection - and that includes
> accounting for the ability of people to misconfigure things.
That I completely concur with.
Noel
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf