> > > > I've been involved in Formal International Standards Bodies, where > the Camel was developed as a functional specification for a Mouse. > The market and the world are far faster than the carriers would like > it to be.
Here I must disagree. The fact is the traditional carriers basically are the market, in the sense that they are the ones with money to spend. It doesn't really matter if the standards bodies come up with all sorts of cool and funky technologies if nobody implements them. The only providers who are really in a position to implement much of anything these days are the traditional carriers because they are the only ones who actually have money (practically all of the pure Internet service-providers are bleeding red ink everywhere). And those traditional carriers are only going to implement something to the degree that it is profitable to do so. Which is why I am concerned for the future of MPLS. In its original conception, MPLS offered the promise for a generalized control-plane that could potentially span all the gear that a carrier has to run. A Grand Unified Theory of networking, if you will. Now, it has become IP-centric, and Internet-centric in particular (i.e. the involvement of the IETF). But the fact of the matter is that IP services in general, and the Internet in particular, are still highly unprofitable for the carriers. Untold billions have been spent on carrier Internet infrastructure with nary a hope of ever getting a semi-reasonable return on investment. The Internet has become a godsend to the consumer but a financial nightmare for the carriers. Which is why I believe that any new carrier-style technology that is directed towards the Internet will achieve unnecessarily slow adoption by the carriers. Now don't get me wrong, MPLS will be adopted, the real question is how quickly. If much of the work on MPLS is done mostly on IP and Internet features, and not on the more traditional telco features, this will slow the adoption of MPLS. Traditional carriers are not exactly champing at the bit to spend money adopting new Internet technology now that financial sanity has returned to the fold (notice how so many carriers are cancelling or slowing their Internet buildouts?). > > When I worked for a primarily carrier-oriented vendor, there were > deep emotions that they could make IP go away with: > (1) Ubiquitous fiber > (2) Apparently manually provisioned MPLS, since they equated the topology > to something of equal complexity and hierarchy to what you can do in > SS#7. > > >MPLS has potentially far more applicability than just in the Internet (for > >those who didn't catch it, the 'I' in IETF stands for Internet). For > >example, MPLS has tremendous potential for all the world's carrier's ATM > >networks. But right now, for them to take advantage, they have to upgrade > >their ATM switches to IP, rather than just installing a MPLS multi-service > >switch as a dropin replacement. > > > >> > >> Generalized MPLS (GMPLS) is certainly not IP only, as packet > >> forwarding is only one of its modes. It can set up forwarding based > >> on wavelengths, time slots, or ports. > > > >Neither is draft-martini, draft kompella, draft-fischer, or any of the other > >drafts. > > > >But the point is not the forwarding plane, it's the control plane, which > >still relies on IP. > > What do you propose as a scalable alternative that doesn't simply > meet telephony needs? I propose that MPLS exist as a control-plane technology that sits 'above' LDP/RSVP (in the case of IP) and PNNI (in the case of ATM) and other dynamic-provisioning technologies (in the case of, say, ADM's). MPLS would then be a generalized way to assign labels, and the actual mechanism of telling individual nodes of such label assignment would be the task of LDP/RSVP or PNNI or whatever. Naturally a lot of details would have to be worked out, but I believe this is not unreasonable as a gameplan. > > > > >> > >> The first MPLS predecessor, Ipsilon's (now part of Nokia) IP > >> switching was planned as a faster means of lookup than conventional > >> routing. With advances in L3 hardware and software, that simply > >> didn't turn out to be useful or even scalable. > >> > >> Those initial implementations, by Ipsilon, were ATM dependent both > >> for path setup and transport. > > > >And I think this functionality was sadly lost. Not the transport > >functionality, but the path-setup functionality. I think more work needs to > >be done on the ATM side of things to make MPLS more palatable to carriers > >who run lots of ATM and would like to migrate to MPLS but want a smooth > >transition path. > > Or some carriers may be displaced by VoX. I've seen quite a number of > marketing research documents that suggest the typical telco wants 90% > L2, 10% L3, because that's what they think their provisioning people > can understand. What I want to know is how many carriers out there are financially viable that only provide services at L3? I'm going to go with 'zero'. This is why I think that VoX won't replace traditional voice anytime soon. Traditional voice, while declining, still generates gobs of profits. A profitable business model built around VoX has yet to be developed. > > The models of manual provisioning, settlements, central coordinating > authorities, etc., still persists in the carrier view of the world. > Also, there are a fair number of vendors that want to retrofit full > MPLS into the spaghetti code of their ATM switches. I've tried to do > that. It was a nightmare. PNNI isn't enough. I'm not denying that such a thing would be very difficult for the vendors and the standards bodies. But what I see is that since the traditional carriers are the only ones left with money in the bank, they are going to call the shots. If nobody will offer them a version of MPLS that fits their business needs, then they will simply continue to buy ATM. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54606&t=54507 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
