Hi Tony, >-----Original Message----- >From: Tony Li [mailto:[EMAIL PROTECTED] >Sent: Thursday, December 04, 2008 9:20 AM >To: 'Noel Chiappa'; [email protected] >Subject: Re: [rrg] Fundamental objections to a host-basedscalableroutingsolution > > >Hi Noel, > > >| > If we go down the path of map-&-encap, we're effectively >|deciding to run >| > on top of a connection oriented infrastructure. >| >|I don't think I agree with this. It is certainly true that we're almost >|building a new packet-switching system on top of an existing >|one - and this >|certainly creates some problems (which I'm currently >|struggling with offline, >|along with a number of other people). > > > >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.
The new model would indeed look like Switched Virtual Circuits between xTRs connected to the global Internet DFZ, but that does not mean that the old model goes away. IMHO, this should be about arresting routing table growth at or near current levels w/o having to change the service models for existing deployments. In the meantime, however, address scaling and new services are accommodated by map-and-encaps and by rolling out IPv6. >|But I don't at all see how treating the entire Internet as a >|NBMA network >|means we're treating it like a "connection oriented >|infrastructure", any more >|than when we did almost exactly the same thing, when we >|started running IP >|over the old ARPANet. All we're doing is treating a composite >|NBMA network >|(an internetwork, to be technical) as if it were a classic >|single physical >|NBMA, which the 'routers' (xTRs in this case) use to >|communicate directly >|with each other, without much knowledge of what's going on >|inside that 'black >|box' NBMA they are using for data carriage. > > >I guess I'm not seeing too much of a conflict between these views. Yes, you >end up creating an NBMA architecture. I guess another way of making my >point is to look at how well we've done on dealing with NBMA systems before. >IMHO, it's not been all that well. For the old ARPANet, we ended up burying >the IMP number inside of the IP address. Then, because routing didn't work >so well, we ended up taking multiple hops across the NBMA network. ISATAP addresses bury the L2 (IPv4) address within the L3 (IPv6) address, but thankfully that address form is really only needed for next-hop resolution and operation of the IPv6 ND protocol. That, and for hosts that configure their own xTRs - but, I'm not sure we'll see many of those connected directly to links within the DFZ. >We've also tried to solve the NBMA problem with NHRP. That didn't go so >well because we couldn't really find a way to keep the levels (virtual & >physical) separated. > >Other efforts to solve it have required manual configuration of IP addresses >within IGPs. Not even possible. The ISATAP NBMA next-hop resolution model asks for a well maintained mapping system. Within a small site it may be sufficient to simply have mappings to a few hosts and default routers, but at Internet-scale we will certainly need to be able to map more-specific routes. IMHO, we seem to be seeing some positive developments along the lines of the mapping system even in recent discussions on this list. >For the sake of the current discussion, I'll stipulate that we can solve the >routing issues with the mythical perfect mapping funtion. However, I'm >still gravely concerned that we can no longer run natively and end up with >what you describe as a "kludgy, exponentially-complex mess". But, you still can run natively in exactly the same way we do it today; IPv4 routing in the DFZ, large IPv4 enterprises and IPv4 NATs do not go away. Only new networks and services will be the ones that use map/encaps for IPv6, but AFAICT that would not make them "second class citizens". As was once told to me long ago, the approach is one of building a "second story" on top of the existing Internet. I think (but am not certain) that this is essentially the same thing Noel has described as "jack-up". Anyway, I don't see kludge and complex mess in any of this; I see only benefits that could not be realized with a non map-and-encaps approach. And, as also was once told to me, "complexity is in the eye of the beholder". Fred [EMAIL PROTECTED] > >|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 - and with only the >|dimmest of plans >|(if any, in most cases) to make sure that in the long run we >|have a path _out_ >|of that kludgy, exponentially-complex mess, back to something >|a little more >|integrated, clean, flexible, powerful and robust. > > >Agreed. Moreover, if there is a way out, why do we need this kludge as a >stepping-stone... > > >Tony > >_______________________________________________ >rrg mailing list >[email protected] >https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
