RE: [RRG] arguments for map and encap

[<hannu.flinck@nsn.com>]

 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: owner-rrg@psg.com [mailto:owner-rrg@psg.com] 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 rrg-request@psg.com 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 rrg-request@psg.com 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