Excerpts from Noel Chiappa on Thu, Dec 04, 2008 11:05:56AM -0500: > What's troubling me much more (wearing both engineering and > architectural hats) is that we are, in effect, building a second > packet-switching system on top of the first, but separate from it
As argued elsewhere ... in order for it to be a different "packet switching system", it would have to have different addressing, routing, and switching. In the scope of the globally routed Internet, addressing is the same -- a BGP neighbor in the core BGPs with an ETR just as with any other node. Routing is the same -- good old BGP. The switching is the same -- every packet is switched by the same core routers in the same way. All that's different is that packets are prepared for crossing the globally routed Internet at a new point, which is to say that when they implement map-and-encap, edge sites are separated away from the core, but the core is the same. There is no new switching system, only a new adaptation, at its edges, to the existing switching system, once a prefix is removed from it. Excerpts from Tony Li on Thu, Dec 04, 2008 09:20:10AM -0800: > Ok, but the underlying system is effectively a set of > connection-oriented tunnels. Yes, you're using packets to emulate > that connection, but you're definitely treating the tunnel as a > point-to-point link. At the last three IETF meetings I've told you that encapsulation does not imply "tunnel", and it certainly doesn't imply a network-layer connection. There is no setup phase, and there is no shared state necessary for a decapsulator to receive a packet. If I were a decapsulator, you could encapsulate a packet and throw it at me and I would do the right thing whether I had ever heard of you before or not. Paul Francis and crew called a "funnel", as opposed to a "tunnel". > Agreed. Moreover, if there is a way out, why do we need this kludge > as a stepping-stone... Ignoring "kludge" for the moment because everything is equally grubby as far as I can tell, this is the big question. This is why it's important to evaluate the various approaches to locator/identifier separation. Can we solve the routing scaling problem indirectly while solving locator/identifier split for session control? I'm not saying map-and-encap is the most elegant thing we can do. However, we do have time constraints. You can only change all the hosts in a few special markets. For others you have to do some kind of "separation", whether NAT, proxying, or map-and-encap. NAT doesn't work for sites that are multihomed unless you change the hosts (socket bindings break when routing changes). Proxying is desperate. What are you left with? Also, see Lixia's slides from two IETFs ago where she said that investing in developing map-and-encap loses us little and may gain us everything. Scott _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
