Subject: RE: ATM Switches as LSR encoding techniques

From: Eric Gray <[email-masked]>
Date: Tue, 30 May 2000 18:09:57 -0700

Robert,

	See in-line comment.

> -----Original Message-----
> From: Robert Raszuk [mailto:[email-masked]]
> Sent: Tuesday, May 30, 2000 4:31 PM
> To: David Charlap
> Cc: [email-masked]
> Subject: Re: ATM Switches as LSR encoding techniques
> 
> 
> 
> David,
> 
> > want to?  If you've got ATM, use it.  One of the big points about using
> > MPLS is to have one unified control plane - if you're going to run MPLS
> > through an ATM network that doesn't participat in MPLS, then you've just
> 
> I am talking daily to all major ISPs worldwide deploying MPLS and nobody
> mentioned "unified control plane" as the reason to introduce MPLS into
> their network. The major reason is to be able to use applications which
> MPLS offers (Traffic Eng, MPLS-VPNs, Circuit Transport, Hierarchical
> Routing etc ...) 

This assertion sounds a little strange.

All of these things are things that exist and can be 
supported using ATM (for example).  Yet people you're
talking to want them using MPLS.  Perhaps the unified
control plane issue is not as orthogonal as you think?

...
> Robert.
> ...
> > -- David

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 May 2000 18:25:09 -0700

Eric,

> talking to want them using MPLS.

That is true that all of them can be provisioned with ATM today. But the
problem is that using L2 (or any kind of tunneling) for TE, for VPN or
even for Circuit Transport scales very poorly. Once you provisioned
hundred or maybe thousand of VC your operations people are starting to
suffer from lack of control and maintenance nightmare. That from the
provider point of view.

From the customer point of view things don't look nice either when he
needs to peer with hundreds of his own routers (the VPN case) rather
then with one (or two for redundancy) residing on his provider edge.

What MPLS gives you is the freedom to use L3 to deliver all of those
services without touching the underling L2. In fact you build your core
only once and don't need to modify it when customer is added/deleted or
when he requesting new service.

> Perhaps the unified control plane issue is not as orthogonal as you think?

As a matter of fact no later then last friday I was talking to large
telco shop which are deploying ATM + MPLS and they have cleary stated
that they want to run both PNNI + LDP. The reason being is that this ATM
backbone will be still serving the SVC/Soft-PVC connections while in the
same time be a mpsl aware transport for IP traffic.

R.

> Eric Gray wrote:

---

From: David Charlap <[email-masked]>
Date: Wed, 31 May 2000 10:36:02 -0400

Robert Raszuk wrote:
>>
>> All of these things are things that exist and can be supported using
>> ATM (for example).  Yet people you're talking to want them using
>> MPLS.
> 
> That is true that all of them can be provisioned with ATM today. But
> the problem is that using L2 (or any kind of tunneling) for TE, for
> VPN or even for Circuit Transport scales very poorly. Once you
> provisioned hundred or maybe thousand of VC your operations people are
> starting to suffer from lack of control and maintenance nightmare.

And this same nightmare doesn't exist if you provision hundreds or
thousands of LSPs through that exact same network?

-- David

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 31 May 2000 08:59:00 -0700

> thousands of LSPs through that exact same network?

When you provision let's say TE tunnels (in not all but in the most cases) you
are not building them from your customer interface to customer interface on the
other end of your network. What you are building  is a set of tunnels to
interconnect your own boxes with (either edge-egde or middle-edge or any other
possible combination) but always within you domain. That itself reduces the
number of LSPs versus VCs very dramatically. In MPLS-VPN by using for example
prefix based label stacking you don't need to provision any LSP/VC to create
very large VPNs across your core.

Of course one may argue that instead of building L3 networks with IGPs just
flat or hierarchical PNNI should be used in a closed provider network to achive
the same. Unfortunately by looking at the current industry trends, dominance of
IP and proven scalbility of BGP & IGPs in the Internet I don't think that this
option is practical.

R.

> David Charlap wrote:

---

From: Eric Rosen <[email-masked]>
Date: Wed, 31 May 2000 12:30:27 -0400

EricGray> All of  these things  are things that  exist and can  be supported
EricGray> using ATM (for  example).  Yet people you're talking  to want them
EricGray> using MPLS.   Perhaps the  unified control plane  issue is  not as
EricGray> orthogonal as you think?

There are  a number of  reasons for preferring  MPLS to ATM that  don't have
much  to do  with the  control plane:  ATM's cell-switching  overhead, ATM's
scalability  problems   having  to  do  with   lack  of  multipoint-to-point
capability,  the scalability  problems of  having to  have  n**2 connections
among the  n routers on  the ATM network,  ATM's dependence on  a particular
data link  layer, the  inability of  most ATM switches  to handle  native IP
packets at  all, etc.  IMHO,  it's the scaling  issues rather than  the more
abstract "unified control plane" issues  which are driving the market.  Many
of the things  which can in theory be  done with ATM are difficult  to do in
practice because of the scaling limitations.

But I would agree  that there are also important reasons that  do have to do
with unifying the control plane: I  think the need to support an ATM routing
and addressing infrastructure  which is independent from the  IP routing and
addressing  infrastructure is  a problem,  one which  MPLS doesn't  have.  I
don't know though how much the customers really care about this. 

Some folks have made a fetish out of this drive for a unified control plane,
arguing that  what is really needed  is the one true  grand unified protocol
that does absolutely everything.  I think what Robert is saying is that this
fetish is not something which derives from customer needs.