Hi John,
I fully agree with your comments, and particularly in respect to this myth about ATM "scalability".
(By the way, I notice with some amusement that this term "scalability" is frequently used by some IETF colleagues as a disdainfully derogatory label for anything disliked ! What does it mean precisely ? At least the context in which it is used should be qualified. )
ATM was intended to be used in conjunction with signaling protocols (PNNI, etc.), and not just for providing semi-permanent VCCs or VPCs, even though these may be the main use nowadays.
If people simply use PVCs, then sooner or later the n**2 limitation will become an issue.
If SVCs are used as intended, and assuming reasonable holding times, the n**2 limitations hardly apply. In this respect, ATM is no more or less scalable than any other label multiplexed, connection-oriented packet technology being used out there, in my understanding.
Also, while I agree label stacking is a useful concept, it simply implies the nesting of the virtual circuits in the multiplexed packet stream. There is no magic here, and this nesting of the VCs does not enable us to get around the usual constraints of queueing traffic performance.
But I know myths die hard, since its often in the interests of some folks to propagate them for whatever reasons !
Regards,
Khalid
-----Original Message-----
From: Rutemiller, John [mailto:John.Rutemiller@marconi.com]
Sent: Wednesday, May 15, 2002 6:40 AM
To: 'pwe3@ietf.org'
Subject: RE: [PWE3] PWE3 question
Protocols should not dictate network architecture.
The choice of whether an operator desires to use a separate
label inside the network for each psuedo-wire, or to use a
label stack to improve scaling inside the network is a
network design issue.
It is not a protocol design issue.
And this issue of ATM scalability is non-sense. Virtual Paths
provide a mechanism that helps in scalabililty. The two-levels
was a constraint if you wanted to provide a virutal path to
customers, and the VP space was a limit if trying to connect
lots of devices at the very edge of the network. But it was
fine for providing connection scaling within the network.
Although MPLS definitely has an advantage with multi-level stacks.
The ATM technology itself does not have any inherent scaling problems
with the number of connections that can exist within the network.
It is possible to have about 268 million connections (2**28) over a
single NNI link. The only limitation is what can be implemented in
ATM switches, and the performance of the control processors, at
a resonable cost. The number of connections supported by a single
ATM switch continues to climb.
I would hope that MPLS could follow the same trend. Unless you are
implying that there is something about MPLS that makes it harder to
support the same number of connections (LSPs) on a single device as
can be found on current ATM switches.
John
> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Friday, May 10, 2002 11:33 AM
> To: Shahram Davari
> Cc: 'Sasha Vainshtein'; 'pwe3@ietf.org'; Danny McPherson (E-mail);
> 'Andrew G. Malis'; Neil. 2. Harrison (E-mail)
> Subject: Re: [PWE3] PWE3 question
>
>
>
> Our original assumption long ago was that no one with a
> clue would want to
> use a scheme in which each pseudowire lays down state in
> the P routers.
> Otherwise it would be as bad (unscalable) as ATM.
>
> Given that one wants instead to tunnel the pseudowires,
> there needs to be
> some applicable signaling protocol which is mandatory
> to implement in
> devices that set up tunneled pseudowires. This is
> necessary in order to
> ensure multi-vendor interoperability.
>
> If someone wants to standardize a method for setting
> up non-tunneled
> pseudowires, there is nothing to stop them, and no particular
> reason why LDP
> should be involved.
>
> I imagine the networks which want to do non-tunneled
> pseudowires will be the
> same networks which have deployed CR-LDP, ITU's standard
> MPLS signaling
> protocol, so you may wish to look into that, perhaps within
> the auspices of
> ITU.
>
> There is already an i-d proposing to use RSVP-TE to set
> up non-tunneled
> pseudowires, though I did try to discourage the authors on
> the grounds of
> the assumption in the first paragraph above.
>
>
>
>
>
>
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3