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