The MPLS-OPS Archive

["S. Chkaravorty" <sc12@erols.com>]

Geoff,

 Didn't mean to say anything close to what you interpreted about ATM tho' I wish
you touched on the well-known SAR (?) scalability issue beyond OC-48. I would love
to know what large deployments (by name) have ATM SVCs.

I agree with the rest of your observations.

SC

Geoff Bennett wrote:

> Hi SC,
>
> I think there's a danger of taking examples out of context here.  I assume
> you're implying that ATM is C/O like RSVP, and that means it doesn't scale.
>
> This is partially true, but you have to understand some of the background
> reasons for it.
>
> RSVP, as deployed initially for QoS signalling, was a soft sate protocol in
> which the refresh procedure could not be aggregated.  Result...it didn't
> scale beyond large Enterprise or small SP deployments (note, there may be
> folks who would disagree even with this over-simplification).
>
> In addition, the generation of IP routers on which this form of RSVP was
> deployed were never designed to hold the connection state.
>
> ATM doesn't require a soft state refresh, and so loss of a connection can
> be explicitly signalled.  Refreshes are "piggy backed" into the data
> streams.  This makes it "more scalable" than RSVP, but does that mean it's
> "scalable"?  There are certainly some very large ATM deployments, and they
> operate in an SVC mode (I'm talking here about certain US Government
> deployments).  Customers using large, dynamic ATM systems (ie. with SVCs)
> universally report a lower operational cost and a shorter learning curve
> than for a similar sized IP system.
>
> Most SP deployments use PVCs, or Soft PVCs  (ATM Forum PNNI Annex C).  So
> there is considerable state aggregation possible.
>
> ATM switches were explicitly designed to create, hold, monitor and
> re-establish state.  Modern router implementations are also being improved
> in this area.  My impression is that this isn't happening to support RSVP
> QoS, but to hold TCP states for protocols like BGP.
>
> So I'm willing to give RSVP the benefit of the doubt because if we ever
> actually get an IP QoS architecture (as opposed to DiffServ CoS) it's
> likely it will use RSVP signalling.
>
> Question: "What signalling protocol will we use in the future Internet?"
>
> Answer: "I don't know, but we'll call it RSVP."
>
> (Wish I could claim this was original but somebody already said it about
> Ethernet :-)
>
> Cheers,
> Geoff
>
> PS.  This group really lit up eh?  Keep up the comments comrades!!!
>
> At 00:38 01/01/88 -0500, S. Chkaravorty wrote:
> >Danny;
> >
> >It indeed is - pushed by some large vendors and some of their
> >not-so-experienced engineers.  Just as a note, before anyone gets overly
> >excited, it was many years back that RSVP was found NON-SCALABLE.  Guess what
> >protocol mirrors RSVP most?!
> >
> >SC
> >
> >Vijay Gill wrote:
> >
> >> On Fri, 16 Mar 2001, Danny McPherson wrote:
> >>
> >> > There's NOTHING you can do with MPLS-based VPNs that couldn't
> >> > be done with IP-based VPNs (likely in a more scalable manner),
> >> > it's just that marketing hype and a bunch of glue has pushed
> >> > the former of the two into the spotlight.
> >>
> >> I see danny's experience as an operator is coming through. Let me second
> >> what Danny just said. From our given operational experience, vendors have
> >> their hands full, trying to make a few routing tables and the associated
> >> software work and this is something thats been worked on for a decade.
> >> I'm not holding my breath waiting for real networks with real customers
> >> (read more than a few thousand), to be able to deploy and support some of
> >> the more esoteric solutions being proposed here. I was fighting ibgp
> >> withdraw bugs as late as a year ago and we regularly reboot line cards
> >> trying to get forwarding working on some vendors equipment. I'll weigh in
> >> on the pessimistic side of things here.
> >>
> >> > As well, MPLS doesn't give you QoS any more than IP does, it's a big
> >> > bunch of marketing hype.
> >>
> >> Amen.
> >>
> >> /vijay
> >>
> >> -------
> >> The MPLS-OPS Mailing List
> >> Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> >> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> >
> >-------
> >The MPLS-OPS Mailing List
> >Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
> >Archive: http://www.mplsrc.com/mpls-ops_archive.shtml
> >
> ================================================================
> Geoff Bennett                             Tel: (33) 497 21 43 62
> Director, Office of the CTO               Fax: (33) 497 21 43 50
> Marconi
> Gaia - Bat. E                           email: geoff.bennett@marconi.com
> BP 123
> 06903 SOPHIA ANTIPOLIS
> FRANCE
> ================================================================

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml