On Mon, Dec 7, 2009 at 10:11 PM, Joel M. Halpern <[email protected]> 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 _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
