Noel Chiappa wrote: > > 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"? The costs aren't just getting pushed to the multihoming site, because the software that has to deal with multihoming isn't just distributed to those users. The costs are getting pushed on to software developers, and from there, to everybody who uses IPv6 software, and from there, to slower adoption of IPv6 in general - which is to say, everybody pays many times over. Contrast this with an approach that says: "Yes, you can have multiple egress routes to your network under a single prefix, but you have to pay to use a special prefix that is reserved for multihomed sites. And all of your inbound traffic will be routed through one of a set of aggregators that hide your real (PA) prefies and link transitions from the rest of the network, and which tunnel (or maybe NAT - your choice) your traffic to you over one or more of your PA prefixes. And those aggregators won't be in any single location, or be run by any single organization. So you're insulated from single points of failure. But you will have to pay your share of costs of running that service, plus a bit more for contingencies. And if you want to change aggregators, or to stop multihoming and stop paying for that service, you'll have to renumber." *That* approach would put the costs squarely on those who benefited. > > 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. ...and not much more. > 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? No, but we're not talking about replacing brick with steel. We're talking about replacing brick with straw. > > 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. and I'll start treating such proposals as potentially viable when I see evidence that the engineering work is being done. Keith _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf