> > >At the risk of starting a religious war, I've never understood why MPLS
>is
>> >so IP-centric. It's not called IPLS, it's called MPLS. With only a few
>> >exceptions, most MPLS initiatives I see presume that devices are running
>an
>> >IP stack to handle control-plane mechanisms.
>>
>> Look at the evolved GMPLS specification, which deals with
>> wavelengths, time slots, and physical ports as well as packets. Their
>> payloads are definitely not limited to IP, but could involve
>> SONET/SDH frames, lambdas, etc.
>
>It's not the payloads I'm worried about, it's the control plane. Let me say
>that I haven't read many of the GMPLS spec's, so correct me if I'm wrong.
>But even with the GMPLS specifications, there seems to be an underlying
>presumption of an IP control plane, and only an IP control plane. If this
>is true, then that would mean that anybody who wants to implement GMPLS will
>be forced to use IP also, perhaps before they are ready to do so.
>
>>
>> In the ATM world, PNNI certainly is more evolved than standard OSPF,
>> but it still would need extension for current concepts of traffic
>> engineering. Why do the work twice, once for IP and once for ATM?
>> Optical routing is another concern; I've been bothered that layer 1
>> optical folk again are reinventing routing algorithms usually
>> described as "based on OSPF," but that really aren't that different
>> than OSPF with additional constraints and the opaque LSA.
>
>That's exactly what I'm talking about. I think that MPLS's best use by far
>was its original conception which was to give carriers a completely
>generalized control-plane mechanism with which they could bind their WAN
>switches, their ADM's, their routers, and whatever else -
Am I correct, then, that you see the core of MPLS control as
variously LDP, CR-LDP, or RSVP-TE? These are all literally path
setup protocols. What is the intelligence that tells them the
possible path topology? Manual provisioning?
>and they could do
>so on their own pace and using their existing gear without requiring
>upgrades or fancy interworking. Instead, MPLS seems to now have effectively
>become a 'feature' of IP - if you want to use MPLS, you must use IP.
I would agree with your last statement, but I don't see what the
alternative is for topology discovery, fast failover without massive
redundancy ala SONET, etc.
>
>
>I'm thinking of all the ATM signalling parameters, especially PNNI. Also
>UNI, things like that.
>
>You asked above of why do the work twice (once for IP, once for PNNI) if you
>want to incorporate current concepts of TE. But my question is, why force
>the current concepts of TE onto PNNI? Why not build out specs for MPLS to
>handle the existing PNNI parameters? Carriers who use PNNI seem to be fine
>with the existing PNNI feature set, so why force them to adopt a different
>TE model before they're ready?
Again, I'm a little confused by what you mean by MPLS. There are at
least three logical parts:
MPLS forwarding, presumably to include GMPLS non-packet-forwarding,
MPLS path setup
Topology information to guide MPLS path setup
and, if you split it up, fast failover, shared risk groups,
and the like.
>
>I can see a situation where a carrier with an existing ATM network can drop
>in MPLS switches that have the complete ATM control-plane built in,
>therefore not requiring that the carrier upgrade all its switches.
That's not implausible. That additional board for MPLS is really an
IP control plane engine. I'm unclear how MPLS path setup signaling
would coexist with ATM path setup, or if they'd be ships in the night.
> As the
>existing ATM switches are retired, they are replaced with these MPLS
>switches. Eventually there will be no more legacy gear and everything will
>be MPLS. The point is that the carrier smoothly transitioned from legacy to
>modern technology.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=53834&t=53737
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
