Subject: Re: MPLS Performance analysis.....

From: Eric Rosen <[email-masked]>
Date: Thu, 01 Jun 2000 11:04:41 -0400

This will be my  last message in this thread, as I don't  want to get into a
neverending discussion of MPLS vs. IP encapsulation.  

Brijesh> When MPLS work started the enhancing  the speed of IP route look up
Brijesh> was a key motivator behind the technology.  

I don't  recall anyone saying that there  was some upper bound  on the speed
with which IP lookups can be done.  

The performance motivators behind MPLS were the following:

- A piece  of hardware  that supported high-speed  MPLS forwarding,  but not
  high-speed native  forwarding of  protocol X, could  be made,  by suitable
  label imposition policies elsewhere, to forward protocol X at high speed. 

- If  changes in  the  criteria  used for  assigning  packets  to FECs  are
  implemented, high  speed forwarding could  still be provided  by existing,
  unmodified MPLS forwarders. 

Perhaps your position is that  the first point is irrelevant, either because
no one uses ATM anymore, or because  "IP over ATM" is fine and dandy the way
it is.   You might also  argue that the  second point holds equally  well if
MPLS is replaced by some form of IP encapsulation.

Well,  I'd  agree that  the  second  point by  itself  is  not a  sufficient
motivator for MPLS.  Not by itself.  But to argue in favor of a scheme which
does TE and VPN based solely  on IP encapsulation, you'd need to demonstrate
that  there is  no need  for MPLS-like  signalling to  dynamically associate
forwarding  information with the  destination addresses  that appear  in the
encapsulation header.  If this signalling is  needed, all you have is a more
complicated and less efficient form of  MPLS.  On the other hand, if one has
a religious  view that prohibits anything  but IP headers  from being looked
at, this might be considered a worthwhile tradeoff ;-)

Brijesh> it doesn't really matter if  you provision your source routes using
Brijesh> CR-LDP [sic] for certain traffic (or whatever else you have), or by
Brijesh> going to each  router in the network and  creating suitable entries
Brijesh> (manually or auto-magically  under the control of a  TE process) in
Brijesh> the routers 

You're saying it  doesn't matter whether configuring a  path requires you to
touch one router or ten?  I think that is a hard position to defend.

Brijesh> so  that a  particular  class  of traffic  goes  over a  statically
Brijesh> configured path.

This would seem to require either  that the encapsulation header has a field
to  explicitly identify  the class  of  traffic, or  that the  encapsulation
destination address  itself identifies not  merely the destination,  but the
combination of destination and traffic class.   I think that if you work out
the details of  this, you will simply  end up back with MPLS,  though with a
much longer header. 

You may agree or disagree with my position, but don't trivialize it as being
based on any absurd assumption about IP vs. MPLS performance.

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 01 Jun 2000 09:26:12 -0700

Eric Rosen wrote:
	[..]
> with which IP lookups can be done.

This response doesn't seem to address the quoted text, since
there's no implication of an upper bound there either.

A claim that *was* heard in the early days of IP/label switching is
that it would make for faster per-hop forwarding lookups. You may
not have said it, it may not apply to the motives of ATM-turned-MPLS
switch designers, and you may wish it were never said, but it was.
Said claim has also been proven wrong, but that doesn't change
the fact that the claim was made in certain quarters.

Can we now stop trying to either ressurect the disproven claim
about lookup speeds, and also stop trying to pretend the claim
was never made? I'd like to fall asleep at my desk again.

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: "Loa Andersson" <[email-masked]>
Date: Fri, 02 Jun 2000 13:05:08 +0200

Grenville,

I'm sorry to send yet another mail on this thread, but I feel that 
there is two sides to this.

1. The claim of "improvement" was made. Remember the social realistic
introduction campaign for tag-switching. 

2. But there was also quite a bit of talk on the "uselessness of MPLS"
based on the fact that it is possible to do a IP lock up as fast as 
a label lookup. 

Trying to explain that there were some other things that we wanted 
from MPLS proved to very futile. I heard the argument "HW based lookup
and wire-speed forwarding" already at the MIT meeting (-96) all the way 
up to the IEEE conference in March this year. With the conclusion that
MPLS is useless - it doesn't give you any increase in forwarding 
capacity.

I might owe Sean a apology, but that was what I read in his text.

To my recollection there were at least 4 different motivations for 
developing MPLS

1. We needed TE-capabilities in IP networks (constraint based routing).

2. A tunnel mechanism for VPNs.

3. "Creating IP routers of ATM-switches"

4. Capacity increase.

Of these number 4 was dead before it ever got to fly, but was used as
an argument against MPLS.
The ATM argument is probably also dead, if for no other reason most
decent ATM switches has an IP capability of their own toady. It is 
no secret that it was from this angle I myself was approaching the 
MPLS at first, but was dropped well back in the end of -97.
The tunnel mechanism for VPNs is till valid, but only one of the
possible
solutions.
The TE argument is the one we are going after.

I vividly remember trying to explain this to a couple of people already
at the Munich IETF the summer of '97. Without much success, MPLS was 
useless because there was no capacity increase!

So, I would be glad to stop this discussion if it is mutual. I would be 
interested to discuss MPLS on it merits (mostly TE), but I won't accept
the "no capacity increase argument", if the conclusion is that MPLS
is useless. I will come back and tell you that you argue based on the 
wrong arguments.

/Loa

Grenville Armitage wrote:

-- 

Loa Andersson
Director Routing Architecture Lab, EMEA
St Eriksgatan 115A, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
e-mail: [email-masked]

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 02 Jun 2000 09:05:19 -0700

[..]
> is useless. I will come back and tell you that you argue based on the

Loa, you are reading way too much into my post. Please re-read
the para you quoted below. I acknowledge the speedup claim was
made, I believe it is irrelevant, and I make no statement either
way on whether this proves MPLS is useful or not. Please dont
attribute to me arguments you apparently are still hearing from
others. If you want confirmation of my belief in the use of
MPLS for TE, check IEEE Comms Jan2000 issue.

Can I go back to sleep now?

cheers,
gja

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 5 Jun 2000 18:48:52 +0300 (EEST)

> 3. "Creating IP routers of ATM-switches"

te became late to the table.  in the early ietf mlps bofs, cisco was
pushing mpls (ldp) as a means to automatically set up a full mesh of vcs
between routers in a more scalable way than what could be achieved by
atm (both in terms of number of routing peers and number of vcs legs).
forgot the silly ingress vs. egress control debates?  i tried to promote
mpls as a fourth generation general purpose connection oriented protocol
to replace fr and atm, but didn't get much support until the te
application poped up.

-- juha

---

From: "Dmitri Krioukov" <[email-masked]>
Date: Mon, 5 Jun 2000 18:57:46 -0400

i'd like to hear any points of view of the members
of this list on motivation #1 (te) accompanied
with some far going criticism to this reference:
http://smg.ulb.ac.be/Preprints/Fortz99_29.html
(it was brought up to discussion on nanog
mailing list recently).

i understand that the major assumption in this paper
(about the demand matrix availability) is too
brave, but this paper is a major indication
that the te-related research beyond the ever
lasting vc reinvention approach has not been
exhausted yet. clearly, you wouldn't need any
external signaling mechanism if all benefits
te brings you (congestion avoidance, qos, etc)
may be achieved by means of some (rather
futuristic at this point) routing protocol.

at the very general level, the packet switched
networks proved to provide much higher level of
adaptation to the new requirements. since the
packet switched networks are theoretically
more complex than circuit switched ones, the way
to adapt to a new requirement (te) may not be obvious
until some significant research effort is done. this
does not mean that we have to avoid this effort since
the easy way may not lead anywhere...

the interesting point would be that ip was created
as a result of significant, well-funded academic
research effort. i'm not sure if the same was true
with respect to the osi stack.
--
dima.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Juha
> Heinanen
> Sent: Monday, June 05, 2000 11:49 AM
> To: Loa Andersson
> Cc: Grenville Armitage; [email-masked]
> Subject: Re: MPLS Performance analysis.....
>
>
> Loa Andersson writes:
>

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 05 Jun 2000 22:23:48 -0400

In message <[email-masked]>, "Dmitri Krioukov" 
> with respect to the osi stack.

Dima,

Since you've asked for a quick review ...

I've seen a paper related to this work by other AT&T authors
(unpublished) that produced a formal proof that for topologies with
given constraints OSPF costs could be set sufficiently well that there
was no benefit to MPLS-TE.  Unfortunately the constraints are violated
by too many topologies and building to them is impractical so that
other paper may remain unpublished.

Even where OSPF and MPLS perform nearly as well when everything is up,
when a link fails and the OSPF costs can be very suboptimal.  The
MPLS-TE might converge to a near optimal solution faster than the OSPF
weights could all be changed by an external system.  There was also
the very real possibility of multiple link failures which is always
troublesome for techniques which rely on precomputed costs for any
given single failure.

The AT&T approach outlined here may be very well suited for AT&T's
immediate needs.  OSPF is a very stable protocol whose behaviour is
well understood and implementations tend to be very reliable.  MPLS
may gain an efficiency advantage as a network topology become a more
of a dense mesh and this advantage becomes more important as a network
becomes very heavily utilized.  OTOH, a TE implementation may converge
to a result which is also quite poor and may be fairly unpredictable
(ie: layout efficiency depending on order in which LSPs are restored).

Given a relatively simple and well provisioned network topology and a
desire to stick with conservative design to acheive high reliability
this approach is a good choice.  As MPLS implementations mature, the
risk of deploying MPLS is lowered.  As risk lowers and if topology
becomes more complex and high utilizations raise efficiency concerns,
it may become advantageous to use MPLS TE.

There are some very smart people at AT&T.  This is both a good
acedemic paper and the practicality of the approach for many
circumstances makes it also a practical and relevant paper.

btw- Thanks for the pointer.  I wasn't aware that this was submitted
for publication.

Curtis

> with respect to the osi stack.

ps- Quite a bit of money was poured into OSI, much of it by commercial
interests including the US telcos and European PTTs.  IP and the
NSFNET was not all that well funded if you consider that most of the
funding went into operating a network.  NSF put $15M/year into the
T3NSFNET backbone at peak if my memory serves well.  I think that
exceeded even the IETF chocolate chip cookie expenses by a significant
margin.  It wasn't until a few years into commercialization that IP
networks began playing with real money by government standards.  Its
interesting to note that the whole NSFNET program was more than paid
for in taxes resulting from the commercialization of the Internet.  :-)

---

From: "Brijesh Kumar" <[email-masked]>
Date: Tue, 6 Jun 2000 11:54:24 -0400

Dmitri Krioukov writes:
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Dmitri
> Krioukov

That is a very good case specific paper (also a good theoretical paper),
however the solution is  dependent on the demand matrix (demand between two
nodes s and t) D(s,t,T) remaining constant for a substantial period of time
(T). The authors recognize that the solution will be lot more harder to
implement when this assumption is not true. The overheads of Routing
protocols being directly dependent on the frequency  at which network states
must be updated in routers, makes the goal of supporting time variant
traffic demands without proportionally increasing routing and related
signaling overheads very hard, if not impossible, to achieve. On the other
hand, as you rightly said, the difficulty of designing routing protocols
that can naturally accommodate TE should not be precluded as an approach.
But that approach better match MPLS TE functionality and have less overheads
to be acceptable. Kind of hard task..

At this point, MPLS remains the best long term solution for TE.

> the easy way may not lead anywhere...

Good point. I am sure even MPLS design can benefit from those efforts.

--brijesh
Ennovate Networks Inc.

---

From: "Dmitri Krioukov" <[email-masked]>
Date: Tue, 6 Jun 2000 20:21:46 -0400

thanks for the review. it does make sense.

in fact, you've noticed the same problem
brijesh mentioned a little bit later -- the
absence of the time parameter (a link failure
is partial case of the demand matrix evolution
in time). (another issue is if you really have
or can have even a static demand matrix for your
network.)

obviously, the fundamental cause of not having
time dependency is that the graph theory doesn't
have it either, and as soon as you have a link
cost change, you essentially have another graph
that you have to recalculate. unfortunately, this
starting point could never sound right to me...

has any dynamic routing protocol research been
done outside of the distance vector and link
state approaches?

thanks,
--
dima.

PS the reference under discussion was mentioned 
   by bora akyol

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Curtis
> Villamizar
> Sent: Monday, June 05, 2000 10:24 PM
> To: Dmitri Krioukov
> Cc: Juha Heinanen; Loa Andersson; Grenville Armitage; [email-masked];
> [email-masked]; [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 06 Jun 2000 23:16:12 -0400

In message <[email-masked]>, "Dmitri Krioukov" 
> done outside of the distance vector and link

Yes, but we are straying outside the charter of the WG mailing list.

Curtis