Hello Michael and Dan We good and thoughtful mail from you. I agree with the logic you present here. However, there maybe some details that you are overlooking.
- multihoming is not only for service providers, but required by end users/network customers. Multihoming is not only about PI addressing, but also of the possibility to route through alternative provider and to have a backup route. If this is the case, the beneficiary is the end user who should bear the cost for what she/he wishes for. - it is not all service providers who experience the routing scalability problem. The problem seems to be more of tier 1 and tier 2 providers, rather than the access providers. At least those access providers I have talked about this, do not confess having such a problem. Of course we could assume that the ISPs are going to be consolidated to bigger ones and at this point we need to have the technology in place. But I do not find this believable. Regards Hannu >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf >Of ext Michael Meisel >Sent: Tuesday, May 06, 2008 04:07 >To: Routing Research Group >Subject: [RRG] arguments for map and encap > >In their earlier post >(http://www.ops.ietf.org/lists/rrg/2008/msg01159.html), the >RRG co-chairs requested that we first come to a consensus on >the "highest-level branches of the decision tree". Towards >that goal, Dan Jen and I want to open a discussion on this >issue with some arguments for choosing the map & encap branch. > >First, some background. We know the fundamental reason that >the current routing system doesn't scale: there is a conflict >between network customers and their transit-network providers. >It is in the interest of network users to have >provider-independent (PI) addresses, while it is in the >interest of network service providers to maintain IP address >aggregatability. > >So what the RRG is tasked to decide is: what changes should be >made to resolve this conflict? > >We believe that the answer is to take a path that (1) best >resolves the conflict for the long term and also (2) provides >a feasible economic incentive to make the changes. > >1. Selecting the best long term solution. >The Internet as it stands is a great success. We want to first >make changes that are in the best long term interest. Faced >with equally good long term changes, we should also select the >one with the highest degree of backwards compatibility. > >2. Ensuring that parties required to make changes have >incentive to do so. >For any solution that does not align cost with benefit, it may >be possible to deploy it in a few places, but the solution >will not be widely adopted unless the economics are on the right side. > >This means we cannot expect everyone to change operations. It >is reasonable to ask each ISP to make a big change, but only >if they can see some appreciable benefit. Conversely, it is >not reasonable to ask all home users to change in order to >better accommodate ISPs. The scaling problem is perhaps felt >most profoundly at the ISPs, so fixing the problem by making >changes at all ISPs seem more reasonable. Forcing changes upon >all network customers would need to be matched by a compelling >gain for those customers. > > >Arguments for Map & Encap > >For a long term solution, we believe some decoupling of the >network customers and transit networks is necessary. The >conflict over PI addresses is a clear example of the need to >decouple. In the long term, it also opens up a number of new >possibilities at both sides for scaling and routing changes in >the core and techniques to exploit mapping service for new >features at the edges. > >As compared to other types of schemes, map & encap requires >changes only to the nodes at the borders (where encap/decap >occurs), along perhaps with a small support infrastructure. No >changes are required at end hosts who benefit only indirectly >from the change -- in fact, map & encap schemes can be made >invisible to end users (and edge networks in general, if desirable). > >Service providers, both large and small, are the parties that >stand to benefit from a resolution to the conflict. Thus, they >should be the ones who bear the burden of deployment. Thus, >map & encap seems to be the solution that best aligns cost >with benefit, as well as the best long-term direction going forward. > >-Michael and Dan > >-- >to unsubscribe send a message to [EMAIL PROTECTED] with the >word 'unsubscribe' in a single line as the message text body. >archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg > -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
