""Peter van Oene""  wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> At 06:04 PM 9/30/2002 +0000, Priscilla Oppenheimer wrote:
> >I have an even more fundamental question. ;-) Why does MPLS need a
routing
> >protocol at all? Obviously, the forwarding of traffic doesn't use it.
> >Forwarding is based on the labels. Is it for the label distribution
> >component? Couldn't that be done with manual configuration?
>
> Static label assignment is tremendously onerous. Keep in mind that without
> a control plane that has some topological awareness, you'd need to
> configure label in/out relationships on every transit router in your
> network, per LSP.  Try that with 5000 LSPs :)  I'd rather do 5-10 in a low
> security prison myself.

I disagree - I don't believe you need inherent topological awareness at all,
at least not in an routing protocol that is inherent to the systems in
question.

Let me explain.   When I said why couldn't LSP's just be implemented
manually, I was opening the door to an LSP being a perfect drop-in
replacement to today's ATM PVC's.  Hey - ATM PVC's today are configured
manually in the sense that there is usually an overarching piece of
management software that the engineers use to build and rebuild all the
PVC's and nobody seems to have a problem with that, and this obviates the
need for PNNI or any other kind of dynamic topology calculation mechanism
within the system itself. MPLS could do the same thing - it could provide
the hooks for which companies could build management software  to build
permanent LSP's, as opposed to being forced to dance the IP tune even if
they don't want to.

What I'm saying is this.  MPLS, in my eyes, seemed to offer a powerful
management 'virtualization mechanism' for creating paths.  Ideally, MPLS
would remain generalized such that implementers could use a wide variety of
ways to create LSP's, and could mix and match these ways as they see fit.
But not anymore, MPLS is handcuffed to IP, and I think this IP-only
obsession will slow the implementation of MPLS.  Let's face it, IP, is on
the whole, unprofitable for the provider.  So in this financial day and age,
it's not surprising that providers aren't exactly going to rush to implement
any technology that is  IP-centric.  They will still adopt it because IP is
the key to future profitability, but the implementation will be
unnecessarily slowed.
>
> Pete
>
>
>
>
> >Priscilla
> >
> >
> >nrf wrote:
> > >
> > > ""Chuck's Long Road""  wrote
> > > in message
> > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > > hey, friends, I'm always interested in learning something I
> > > didn't know
> > > > before. not claiming to know a whole lot about MPLS, but in
> > > terms of
> > > > operation, MPLS operates on top of a routing protocol, any
> > > routing
> > > protocol,
> > > > correct? Requires that CEF is enabled, at least in the Cisco
> > > world, but
> > > any
> > > > old routing protocol is fair game as the transport piece,
> > > correct?
> > > >
> > > > So to me, the question would become one of the relative
> > > merits of any
> > > > routing protocol, without the MPLS issue clouding it. I would
> > > think, but
> > > > what do I know?
> > >
> > >
> > > 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.
> > >
> > >
> > >
> > > >
> > > > 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 .
> > > > >
> > > > >
> > > > > Thanks as always
> > > > >
> > > > >
> > > > > Jaspreet
> > > > > _________________________________________________________
> > > > >
> > > > > Consultant
> > > > >
> > > > >
> > > > > Andrew NZ Inc
> > > > > Box 50 691, Porirua
> > > > > Wellington 6230, New Zealand
> > > > > Phone +64 4 238 0723
> > > > > Fax +64 4 238 0701
> > > > > e-mail [EMAIL PROTECTED]
> > > > >
> > > > >
> > > > > WARNING:  The contents of this e-mail and any attached
> > > files may contain
> > > > > information that is legally privileged and/or confidential
> > > to the named
> > > > > recipient.  This information is not to be used by any other
> > > person
> > > and/or
> > > > > organisation.  The views expressed in this document do not
> > > necessarily
> > > > > reflect those of Andrew NZ Inc   If you have received this
> > > e-mail and
> > > any
> > > > > attached files in error please notify the sender by reply
> > > e-mail and
> > > > destroy
> > > > > your copy of this message.  Thank you.
> > > > >
> > > >
> > > >
> > >
> --------------------------------------------------------------------------
> > > > ----------------------
> > > > > This message is for the designated recipient only and may
> > > > > contain privileged, proprietary, or otherwise private
> > > information.
> > > > > If you have received it in error, please notify the sender
> > > > > immediately and delete the original.  Any unauthorized use
> > > of
> > > > > this email is prohibited.
> > > >
> > > >
> > >
> --------------------------------------------------------------------------
> > > > ----------------------




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=54885&t=54507
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to