<There's an interesting point in the middle of this, about how multihoming presents technically rooted problems no matter *how* we do the addressing, even if we solve the conflict he mentions, and that these problems have an impact on what policies it is useful to discuss...> From: "Joel M Snyder, writing fool" <Joel_M_Snyder@opus1.com> GIVEN that I have sufficient knowledge about routing as is necessary to fully understand every technical issue involved Sorry, I guess I just assumed the wrong interpretation of what your question was about. (Also, to be honest, if we've got to the point that most everyone understands these issues, I guess it's time for the champagne... :-) GIVEN that I have a rudimentary and imperfect understanding of the political and economic issues regarding IP numbering and the propagation of routes thereunto I'm not sure anyone has a truly "global" view of this, although if one listens on this and other lists hard, one can start to get a view which integrates the large and small ISP's, equipment suppliers, etc, etc... GIVEN that there exists some set of organizations who want to purchase multiple T1s from multiple independent suppliers ... HOW do I resolve the conflict between justifiable corporate service requirements and the expressed statements ... that anyone who does not consume at least a /18 worth of address space is not worthy of being globally routed? To start with, this is another case where setting the size-based filter for routing updates is having deleritous effects. Again, all we're doing is creating a demand for address space, and as long as there is no well-modulated back-pressure on address space (such as charging for it), I'm not sure I see any easy way of dealing with it. Second, whether it's a /18 or a /24 is of no interest to the routing. Let's assuming we can separate the addressing issues out, to focus just on the routing cost, which is going to be the same *regardless* of how you resolve the address space issues. This is important: *** No matter how you do the addresses, you *still* have the problem that if *** a significant percentage of customers want to be multihomed, and we still *** don't have any mechanism or tools for reducing the scopes of those *** advertisements from global (such as I mentioned in my original message on *** this thread), we will find it technically impossible to provide this *** multihoming capability to a large number of users: we will be rerunning the *** very routing table growth (tracking local sites individually) that caused *** us to go to CIDR in the first place. I don't know about you, but I could do without a re-run of that particular learning experience! :-) Ideally, in solving this, I would take a monetary approach, which is to say "what are the true costs of this multihoming, and given that, is it important enough to the client for them to pay for it", but of course we don't have a charging mechanism for routes that would help to answer this, and maybe never will. So, I can't use that copout. Maybe a better question is to ask "what goal are they really after with multi-homing", because if the answer is "reliability", then perhaps they get more bang for their <insert-local-currency> with things like multiple access lines, etc. I am asking, I suspect, not for a technical answer (there being none other than Chiappa's "it's gonna cost"), but the most politically correct answer to give the organization I understand that you have a very "bottom-line" concern, which is "what do we tell the customer", but I hope that this time I have made clear to everyone that there is no solution to the technical question of "can we provide multihoming on a large scale", *at least in the system as it stands today*. (I.e. if this is an important goal we need to get cracking on technical solutions...) Any policy discussion must take place in an environment which is aware of this technical constraint. Thus, your question about the policy conflict you pointed out is interesting and true, but ultimately not a critical one... Noel