> >I got an even more fundamental question - why does MPLS require IP at all? > >At the risk of starting a religious way, it's not called Internet Protocol > >Label Switching, it's Multi-protocol label switching. MPLS has effectively > >become a feature of IP, as opposed to a generalized control-plane mechanism > >for which is what it was originally intended. > > > > Let me offer a different way to look at it. MPLS really isn't > monolithic. As a sub-IP protocol in the IETF, basic MPLS still has > separable forwarding and control plane aspects. The control plane > involves path setup protocols such as RSVP-TE and LDP. These, in > turn, have to get overall topology information from _somewhere_. > Besides IP routing protocols and PNNI, what is there for that purpose > that wouldn't need to be invented?
You just hit it on the head. First of all, why is it considered a sub-IP protocol? In fact, why is the IETF running the show in the first place? 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. > > 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. > > > > > > >> > >> I suppose there are always the issue of interoperability. > >> > >> I would certainly appreciate the wisdom of the folks on this group. > >> > >> Chuck > >> > >> > >> > >> ""Kohli, Jaspreet"" wrote in message > >> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> > I am looking for a comparative design question: Why a large corporation > >> > should or should not use MPLS over EIGRP . Any useful links will be > > > > greatly appreciated . Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54561&t=54507 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
