Subject: Re: Some queries

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Jan 2001 13:08:23 -0500

In message <009401c06704$892669a0$f23987cb@faisal-s>, "Faisal S. Naik" writes:
> 
> Hello friends, 
> At a recent discussion with my MS class students, i was discussing MPLS > and related issues. The discussion went into a complete confusion when > we got stuck at the very question 
> WHY use MPLS?
> Is it only because of the fact that the efficient swapping mechanism, > that MPLS is considered good. What about already accepted switching > techs like ATMs, incase they are integrated with IPv6 networks for > better services like QoS through flow labels?
> would anyone be kind enough to clarify?
> Regards,
> Faisal

Hi,

I just read the answers on this an you guys all got it wrong.  :-)

The scaling argument was close, but hierarchy was needed in some way
that could make the overall solution scale, not just allow the PNNI
routing to scale but prevent scalability in the upper layers.

There were a number of motivations for getting rid of ATM in IP
networks.  One was the cell tax which at a typical 20% would not alone
kill ATM.  Another was SAR.  You can't get fast ATM router interfaces
because SAR speed and SAR buffering becomes a problem.  This alone was
enough to kill ATM.

Perhaps even larger was the problems of independent control planes and
the effect on IGP scaling.  Flooding is needed for reliability in the
IGP and flooding in a full mesh of N routers has some N^3 properties
with regard to messages sent when a router in the mesh fails and N^2
when a VC fails.  Attempts to constrain the flooding tended to slow
convergence and sometimes cause long lived IGP inconsistency when
change occurred.  This is not a problem is the flooding follows the
physical interconnections as it does with MPLS since the number of
adjacencies per node drops dramatically.

The IGP scaling problem was address by ISPs by partitioning their
network into core and regions but this reduced the effectivenes of TE.

There was also no way to change a BW reservation amount and no
make-before-break rerouting.  If a better path was available, ATM
implementations would not use it (or would not do so for very long
periods of time).  There was more attention to adaptivity in MPLS.

Lack of local-protect was at one point seen as a limitation.

There were also implementation issues.  ATM vendors were slow to add
buffering to the switches and never added enough.  They were slow to
do EPD/PPD and never did RED, pushing ABR way too long (which never
worked well in practice).  There was reluctance to give up on the CAC
religion and allow overbooking.  Layout algorithms were not very good
for what the ISPs wanted to do and results were poor.

Curtis

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Thu, 04 Jan 2001 16:21:54 -0500

Curtis,

> adjacencies per node drops dramatically.

Over time , would there be any inclinations to add direct connectivity between B
and H, and then over F and D, and so on, leading to perhaps densely meshed
networks in the long run ? What is your opinion on this?

                          B-------C-------D
                        /                                          \
                      /                                               \
                 A                                                    E
                    \                                                /
                      \                                            /
                       F--------G--------H

One could use a common control plane and may still run into IGP scaling issues
because the network is densely meshed, right?

> network into core and regions but this reduced the effectivenes of TE.

Could you kindly elaborate your thoughts on this?

thanks,
cyl

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Jan 2001 22:26:39 -0500

> because the network is densely meshed, right?

Densely meshed in a 1,000 node network might mean 10-15 adjacencies
per node.  That is still a lot less than full mesh of 999 adjacencies
per node if IP over ATM were used.

> Could you kindly elaborate your thoughts on this?

Typically a provider would partition the topology into N regions where
N is 10s, then run VCs within an ATM core that interconnected the
regions and VCs within each region.  The routers had no visibility
into TE state so if there was mutliple routers bordering the core and
a given region and one of those core routers had a much less congested
path to a destination (recognizing that congestion was more likely
within specific regions than with the core) then the core routers had
no good way to pick the right edge router and get on the VC with a
cleaner shot at the destination.  [Its late.  I hope this is clear.]

Curtis

---

From: "Yi Chu" <[email-masked]>
Date: Fri, 5 Jan 2001 09:22:29 -0500

Please forgive me if my question is so obvious and maybe stupid, since I am
new to this discussion.

Why 1000 nodes can have 10-15 adjacencies while IP over ATM needs 999
adjacencies per node?  I think IP over ATM uses ATM VC just as a physical
link, so there is no difference in adjacencies per node whether the routers
are connected through Sonet links or ATM VCs.

So what is the reason that IP over ATM requires full VC mesh of all nodes?

Yi Chu

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]] On Behalf Of Curtis
Villamizar
Sent:	Thursday, January 04, 2001 10:27 PM
To:	Cheng-Yin Lee
Cc:	[email-masked]; Faisal S. Naik; mpls uunet; [email-masked];
[email-masked]
Subject:	Re: Some queries

In message <[email-masked]>, "Cheng-Yin Lee" writes:
> Over time , would there be any inclinations to add direct connectivity
betwee
> n B
> One could use a common control plane and may still run into IGP scaling
issue
> s

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 08 Jan 2001 11:15:11 -0500

> So what is the reason that IP over ATM requires full VC mesh of all nodes?

If you use ATM as a means of traffic engineering, you must apply a
full mesh of VCs and allow ATM to route the VCs.

If you use ATM solely as a link layer protocol, you can set up a much
more limited set of VCs that correspond more closely to the physical
topology, but ATM is no longer able to route the traffic.  The traffic
follows the set of hops dictated at layer 3.

If you use MPLS, you get a control plane that maps directly onto the
physical topology and therefore has less adjacecencies but you retrain
the ability to traffic engineer from edge to edge.

Curtis

---

From: "Yi Chu" <[email-masked]>
Date: Mon, 8 Jan 2001 11:40:33 -0500

ATM is a link layer protocol and should be treated as such.  It can be
stretched to support TE, to a limited fashion (region to region, e.g.).
Full mesh of 1000 nodes is not the fault of ATM as a protocol, it is the
failure of not doing proper capacity engineering, IMHO.

yi

-----Original Message-----
From:	Curtis Villamizar [mailto:[email-masked]]
Sent:	Monday, January 08, 2001 11:15 AM
To:	Yi Chu
Cc:	[email-masked]; Cheng-Yin Lee; Faisal S. Naik; mpls uunet;
[email-masked]; [email-masked]
Subject:	Re: Some queries

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 08 Jan 2001 13:01:39 -0500

> failure of not doing proper capacity engineering, IMHO.

It is a reality for ISPs with 500-1,000 access routers.  Since the
1,000 node full mesh would work really badly, ISPs break networks into
10s of regions, then they have on the order of a 100 node full mesh
withing the region though flooding within the core becomes manageable.
They also lose edge-to-edge TE capability that with hierarchical
MPLS-TE they will get back (when hierarchical MPLS-TE is ready).

As Vijay and Jim pointed out earlier, the limit of OC12c on router ATM
interfaces caused this hierarchical plan to start to break down around
1997 or 1998, fueling a sense of urgency to replace ATM in the core.

Curtis