Re: [rrg] Host changes vs. network changes

[Patrick Frejborg <[e-mail]>]

On Mon, Dec 7, 2009 at 10:11 PM, Joel M. Halpern <[e-mail]> wrote:
> I like the picture painted below of synergistic, incremental, flexbile
> deployment of improved behavior.
>
> However, this two-ended incentive relates to one of the things that concerns
> me about the current paths of this work.
>
> On the one hand, we are looking at a variety of tunneling mechanisms
> designed to relive the PI pressure on the core.
> One of the other important goals of most of these proposals is that they
> remove the difficulty of multihoming and changing providers (thus providing
> an incentive for enterprise cooperation / deployment.)
>
> Meanwhile, other sides of our house are looking at interesting ideas such as
> TCP Multipath support.  These techniques work most simply when the tcp
> sender and receiver have visibility to the attachment addresses of the site
> to the Internet, and the ability to select which one is used.
> All of the network based tunneling techniques I can see seem to have the
> property that in providing for multihoming and the ability to change
> providers, they remove exactly the visibility that our other hand is trying
> to utilize.
>
> There seems to be a systemic disconnect.
>

Joel,

think they are not that far away from each other.
I'm under time constraints so I jump directly into an example.

You could easily add xTRs to the hIPv4 framework by adding a RLOC
block to an ALOC realm, i.e. the ALOC realm would advertise two
prefixes to the DFZ
- the ALOC prefix used by the LSRs
- an aggregate of the RLOC block, the RLOC prefixes are assigned to
the xTRs belonging to the ALOC realm

So when a packet arrives to an ITR it need to do the following
- if the packet carries a hIPv4 header the endpoint has been upgraded
and take cares of itself, normal forwarding upon the destination IP
address
- if the packet carries an IPv4 header and the destination is found in
the RIB, normal forwarding upon the destination IP address
- if the packet carries an IPv4 header and not found in the RIB, send
the packet down to the ALT network and once a reply is received create
a cache entry and send it over the tunnel

And don't see this two approaches competing with each other, if the
endpoints gets upgraded do we really need to use the tunnel solution -
why not assemble the packet in such why that a non-overlay solution
can be used instead?

The only drawback by staying in the tunneling solution is that the
IP-address space needs to be globally unique (unless you do some kind
of DNS caching on the ITR, but I'm not eager to go there). If more
addresses is needed, the endpoints need to be upgraded anyway - choice
here is to move on to IPv6 or have hierarchy in the IPv4 space.

By synchronizing both groups in the house we will have two options,
routing hierarchy can be achieved by upgrading both network devices
and endpoints - but we don't need to wait on all endpoints before the
routing hierarchy can be put in place . And there exist a blueprint
how to take the architecture to the next level, it doesn't stop at the
network layer.

I might have missed something, haven't had time to check every corner case.

-- patte