Re: [PWE3] PWE3 question

[Eric Rosen <erosen@cisco.com>]

Since you don't understand why ATM is unscalable, a little clarification may
be in order.

Scalability  is a matter  of the  way in  which an  increase in  demand gets
reflected as an increase in the resources needed to support that demand.  To
talk sensibly of scalability, you have  to specify a particular demand and a
particular set of resources.

In the present context, "demand" is  the number of PWs that the network must
support at  some given  time, and  the number of  PEs the  network supports.
"Resources" are entries in the cross-connect tables of intermediate switches
(P  routers).  (I  thought this  context was  understood, but  perhaps not.)
Let's suppose you have n PE routers, and each terminates m PWs.

Case 1: Martini signaling, mp2p LSPs.  The amount of resources needed in each
P router is O(n).

Case 2: Martini signaling, p2p  LSP tunnels.  The amount of resources needed
in each P router is O(n**2).

Case 3: ATM style, no tunneling, each PW known to the P routers.  The amount
of resources needed in each P router is O(m*n). 

I think  it is clear  enough that for  a given set  of P routers,  the upper
bound on  the demand that can  be handled is much  larger in case  1 than in
cases 2  or 3.   So case 1  would be said  to scale  better in terms  of the
number of cross-connect  entries needed in each P router  to support a given
number of pseudowires.  Note  that in cases 2 and 3, it  does you no good to
simply add more P routers when your demand increases, as it is the resources
in each P router that are scaling  as the square of the demand. (Yes, I know
that not every PW goes through every P router, but that is a minor effect.)

A scheme in which resources in a number of intermediate switches increase as
the square  of the  demand would generally  be considered  unscalable.  What
this means in practice is that relatively small increases in demand call for
larger and  larger intermediate switches.  My understanding  is that service
providers do not generally like it when this happens.

The  fact that  each new  generation of  ATM switch  supports more  and more
cross-connect entries does not show that there is no scalability problem; on
the contrary it shows that there is a scalability problem. 

The  only  way   around  scalability  problems  is  to   use  hierarchy  and
aggregation.  The cost of using  hierarchy and aggregation of course is that
you lose granularity and optimality.   If one wants good scaling, one learns
to live with this, even if it means diffserv.

If the demand is characterized as  "PWs supported at a given time", then the
SVC/PVC distinction is irrelevant. 

Note  that the  resource is  characterized as  cross-connect entries  in the
switches, NOT as space  in the VPI/VCI field.  So the size  of that field is
also irrelevant.

I recognize that ATM does have a means of aggregation (VP-switching), though
it is limited in applicability, due  to a lack of consistency about who owns
the VPI  field.  But presumably those  who don't want  to aggregate multiple
PWs into a single LSP tunnel wouldn't use VP-switching either.  

But I'll acknowledge that it might  be more precise to say "ATM VC-switching
is unscalable" rather than "ATM is unscalable".










_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3