Re: [RRG] arguments for map and encap

[Lixia Zhang <lixia@CS.UCLA.EDU>]

On May 7, 2008, at 6:09 PM, Tony Li wrote:

> Hi Michael, Dan,
>
> Thanks for contributing.
>
> |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.
>
> I think that this is not a precise statement of the problem.  There  
> are many
> reasons, both technical and non-technical why end-sites want to have  
> PI
> addresses.  Further, it's clearly the service providers who are  
> damaging
> aggregatability through actions such as traffic engineering by prefix
> deaggragation.  Thus, I think it's much more productive to focus on  
> the
> technical issues that need to be addressed.
>
> Today, the technical driver that injects routes into the global  
> table is the
> use of explicit, globally-advertised prefixes for multi-homing.

Yes.

>  Most of the
> other drivers (e.g., not wanting to renumber, traffic engineering  
> without
> re-aggregation) are economically based, and not technical  
> requirements of
> the architecture.  Thus, we should be focused on dealing with the
> multi-homing issue.
>
> The crux of the multi-homing issue is that explicit prefixes are  
> necessary
> because transport protocols are tied to the initially selected  
> address and
> if that address is topologically significant, the transport is  
> vulnerable to
> topological changes.

To be a bit more precise: a specific TCP connection can be vulnerable  
to topological changes during its lifetime.

> |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.
>
> You are of course welcome to your opinion, but that's not the only
> perspective.  In particular, the RG is not constrained in this way.   
> While
> it makes sense to remain relevant, economic incentives are not the  
> only way
> to ensure that particular architectures are deployed.  Did the Web get
> deployed initially because of the economics?  Subnetting?  NAT?   
> CIDR?  BGP?
> In short, there are a variety of forcing functions that can cause
> deployment, and our real requirement IMHO, is to ensure that there  
> is some
> effective forcing function but it need not be economic.  Sometimes  
> just
> solving a common problem is sufficient.

the above cited examples, Subnetting,  NAT, CIDR, and BGP, seem to all  
have shared a common effective forcing function: the pressing need.
and changes happened at the place which felt the most pressure.

If we try the same token here: the pressure for needing scalable  
routing is felt by the parties carrying the full routing table, and  
probably not by TCP connections which enjoy the use of PI prefixes.


> |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.
>
>
> I'll just point out that to make a more convincing and balanced  
> argument,
> it's necessary to address both the positives and negatives of an  
> approach.
> Would you care to expound a bit?

Well said.

Lixia


--
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