Just a note from a client side perspective of an MPLS user. We currently are
using an AT&T MPLS backbone for portions of our WAN. One of the major
benefits is the fully meshed nature of the system. We have around 13 sites
up so far, all with the equivalent of a fully meshed connection. We use BGP4
to distribute routes (AT&T's choice, but it works great - we use private AS
numbers. You get a choice of BGP or static routes. Tough choice, eh?). We've
had great response times, we're basically 3 hops from anywhere on our
network, we are now implementing CoS (AT&T beta site) and international
service (also AT&T beta sites). Reliability has been as good as any of my
other frame pvc circuits. Our accesses are currently frame (mostly frac-t)
with one site running IMA on three t's. AT&T is rolling ATM access out, and
then DSL, which I can't wait to get for smaller offices (actually, about the
size of my home office would be perfect).

Downsides? None right now. When we came up originally, we had some issues
with getting ahold of people in the maintenance group that had a clue what I
was talking about ("I know that LMI is up, but I'm not getting BGP
connectivity" "No, BGP" "It's a routing protocol" "No, I don't want to talk
to the Internet group, I want to talk to the next level of tech support")
but that has all be resolved at this point.

As far as the equipment at the client side is concerned, everything is 2600
or higher (3620,3640,3660). We are currently running voice (lucent pbx),
video (h.323) and data over the network, with minimal issues. Coast to coast
ping times (San Diego to Reston) average about 110ms from client to client.

If anyone is implementing one of these networks and needs any info, let me
know.

andras



-----Original Message-----
From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 23, 2001 8:22 PM
To: [EMAIL PROTECTED]
Subject: Re: Isn't MPLS basically just ATM PNNI, but for layer 3?
[7:5670]


>I would like to hear some opinions on MPLS.  I have been reading about it,
>and, pardon me if I'm wrong, but it seems to me like just a reinvention of
>ATM PNNI.

Not really.  A more accurate analogy would be to say that MPLS is ATM 
without cells.

MPLS has two parts, a forwarding plane and a control plane.  PNNI is 
purely a control plane function. It's based on OSPF, plus a 
reservation mechanism.

MPLS control, however, doesn't have the topology discovery that PNNI 
does, just the path setup using CR-LDP, LDP, or RSVP-TE. The 
existence of potential paths to set up typically comes from IP 
routing.  I like to think of MPLS as an overdrive for IP routing, but 
definitely not, as some people misconstrue it, a replacement for IP 
routing.

There is active work on Generalized MPLS (GMPLS) that extends the 
forwarding based on frame/packet headers to forwarding based on TDM 
time slots, wavelengths/lambdas, or physical ports.  Obviously, these 
are more applications for cross-connects of facilities, without the 
flexibility of per-frame or per-packet decisionmaking.

>
>I would be very interested in hearing some comments on the future of MPLS.
>Particularly since ATM PNNI seemed to have gotten nowhere with the telcos
>(and I still don't completely understand why not), then why is MPLS going
to
>do any better (or is it)?

Remember PNNI is "private network to network interface".  There are 
other ATM routing schemes meant for carrier use, such as B-ICI.

>
>I would be particularly interested in hearing Howard Berkowitz's opinion on
>the future of MPLS.

Especially considering GMPLS and emerging optical technologies, it is 
a major direction.  It complements, but does not replace, IP routing.
FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=5678&t=5678
--------------------------------------------------
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