Bob, I am interested in learning about any and all production use of the RSVP protocol. I am also interested in RSVP-TE. I am especially interested in learning the experiences of any organization which has deployed the RSVP protocol in production environments. I am interested in how well it performs, how cleanly it meets their business objectives, how well it scales, how hard (or easy) is it to manage, etc.
--Eric -----Original Message----- From: Bob Natale [mailto:[EMAIL PROTECTED] Sent: Thursday, August 12, 2004 3:00 PM To: Fleischman, Eric; Dean Anderson Cc: [EMAIL PROTECTED] Subject: Re: Question about use of RSVP in Production Networks Hi, Were Eric's question and Dean's answer limited to RSVP strictly, or would RSVP-TE deployments be of interest? If the latter, then what about emerging deployments of architectures that use RSVP-TE, such as MPLS, GMPLS, and ASON? (Or are none of the news releases true? ;-) Cordially, BobN ---- Original message ---- >Date: Wed, 11 Aug 2004 18:37:31 -0400 (EDT) >From: Dean Anderson <[EMAIL PROTECTED]> >Subject: Re: Question about use of RSVP in Production Networks >To: "Fleischman, Eric" <[EMAIL PROTECTED]> >Cc: [EMAIL PROTECTED] > >RSVP is a idea that doesn't cut the mustard in the real world. There are >several show-stopper problems with RSVP. > >1) somewhat like multicast, anyone using RSVP is vulnerable to others >mis-using or mis-configuring RSVP. ISPs several AS's away can really screw >up things for other ISPs. Because of this, it is unwise to deploy it >because it requires too much trust in other ISPs. > >That relegates RSVP to the enterprise Lan, where it usually isn't needed. >Remember, RSVP is only useful if you have a congestion problem and need to >choose which packets to discard. If you have no congestion problem, then >you have no need of RSVP. However, having a congestion problem also opens >the question of the nature of the congestion and what is the best way to >deal that problem. I was involved in a study done by Genuity and Cisco in >which the congestion problem was found to most often involve the tail >circuit--the link between the customer and the ISP. The best solution for >this problem was found to be low latency queuing, not RSVP. > >2) Unlike multicast, every hop end-to-end must use RSVP for it to be >useful. An RSVP tunnel is useless. > >3) RSVP doesn't detect certain kinds of problems that are important. For >example, a mid-span failure is not visible to RSVP. > >While RSVP is important research, it is not a widely deployable >technology. > >What I-D's are you encountering that depend on RSVP? > > --Dean > >On Tue, 10 Aug 2004, Fleischman, Eric wrote: > >> I am aware of some use of RSVP in labs but I am not aware of any use of >> RSVP in production networks (i.e., real life networks people connect to >> the Internet with). Simultaneously, I am encountering I-Ds and other >> work planning to use RSVP. This possible disconnect concerns me. >> Therefore, I would appreciate being educated by anybody using RSVP in >> production settings. Would you please let me know how many devices, what >> applications, and how successful these deployments (if any) are? Thank >> you. >> >> >> _______________________________________________ >> Ietf mailing list >> [EMAIL PROTECTED] >> https://www1.ietf.org/mailman/listinfo/ietf >> > > >_______________________________________________ >Ietf mailing list >[EMAIL PROTECTED] >https://www1.ietf.org/mailman/listinfo/ietf >_______________________________________________ >This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). _______________________________________________ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
