The MPLS-OPS Archive

Cell Relay Retreat>MPLS-OPS Archive>month:2001-Mar> msg00131



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: Questions about MPLS

  • From: Geoff Bennett <geoff.bennett@marconi.com>
  • Date: Mon, 19 Mar 2001 09:13:20 +0000
  • Cc: Danny McPherson <danny@ambernetworks.com>, mpls-ops@mplsrc.com
  • Resent-Date: Mon, 19 Mar 2001 04:51:30 -0500
  • To: "S. Chkaravorty" <sc12@erols.com>, Vijay Gill <wrath@cs.umbc.edu>
  • X-Sender: gbennett@salamander.eu.fore.com

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