Subject: RE: Question about use of RSVP in Production Networks

From: "Ping Pan" <[email-masked]>
Date: Wed, 11 Aug 2004 17:32:10 -0700

Do you count for RSVP-TE, that has been deployed widely in carrier
networks? Other than multicast and wild-card filtering, all other
features (and more) defined in the context of RSVP have been developed
and deployed. The number of RSVP sessions (a.k.a. MPLS LSP's) is in the
range of thousands in large backbone networks.

Hope this will help.

- Ping

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-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 12 Aug 2004 22:15:37 -0700

I am interested in learning about any production sites using RSVP-TE as well. 

-----Original Message-----
From: Bob Natale [mailto:[email-masked]]
Sent: Thursday, August 12, 2004 3:00 PM
To: Fleischman, Eric; Dean Anderson
Cc: [email-masked]
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-masked]>  
>Subject: Re: Question about use of RSVP in Production Networks  
>To: "Fleischman, Eric" <[email-masked]>
>Cc: [email-masked]
>
>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
>
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.
>This message was passed through [email-masked], 
which is a sublist of [email-masked]. Not all messages are passed. 
Decisions on what to pass are made solely by IETF_CENSORED ML 
Administrator ([email-masked]).

---

From: "John Loughney" <[email-masked]>
Date: Fri, 13 Aug 2004 12:25:57 +0200

Dean,

needed.  
need to
then
opens
to
Cisco in
for
>this problem was found to be low latency queuing, not RSVP.

Adding VOIP to an enterprise LAN can often add to congestion. Some on-path signaling can help here - not to mention NAT & FW traversal issues.  RSVP doesn't solve these, but NSIS is looking into these issues.

John

---

From: Bob Natale <[email-masked]>
Date: Thu, 12 Aug 2004 18:00:20 -0400

Hi,

Cordially,
BobN

---- Original message ----
are 
screw
needed.  
need to
then
opens
to
Cisco in
for
For
of
to
what
Thank

---

From: Dan Wing <[email-masked]>
Date: Thu, 12 Aug 2004 12:34:30 -0700

Dean Anderson wrote:
> RSVP is a idea that doesn't cut the mustard in the real world. There are
> mis-using or mis-configuring RSVP. ISPs several AS's away can really screw

That isn't a fault of RSVP, the protocol.  Rather, it's a fault of
insufficient authorization for a requested flow.

> 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.

Enterprises have WANs (ATM, FR, MPLS) which do have congestion problems.
Even within a LAN it's possible to have congestion problems (PC backups,
database replication).

 > 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
> circuit--the link between the customer and the ISP.  The best solution for
> useful.

RSVP only needs to be enabled on the links that might become congested,
such as an enterprise's WAN links.  It usually doesn't need to be
enabled on a non-bandwidth-constrained LAN.

-d

 > An RSVP tunnel is useless.
 >
> 3) RSVP doesn't detect certain kinds of problems that are important. For
>>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
>>production settings. Would you please let me know how many devices, what
>>applications, and how successful these deployments (if any) are? Thank
>>you.
>>
>>

---

From: Bob Natale <[email-masked]>
Date: Thu, 12 Aug 2004 18:05:52 -0400

Hi Ping,

My apologies (to all) for making the same point later in the
thread that you had already made here...processing my list of
open mail in the wrong order evidently!

But I am glad to have your confirmation of the wide deployment
of RSVP-TE in carrier MPLS nets.  I worked hard to promote that
approach several years before there were any such actual deployments
and have since moved on to other domains.

Cordially,
BobN

---- Original message ----
>Date: Wed, 11 Aug 2004 17:32:10 -0700
>From: "Ping Pan" <[email-masked]>  
>Subject: RE: Question about use of RSVP in Production Networks

---

From: "Fleischman, Eric" <[email-masked]>
Date: Fri, 13 Aug 2004 09:37:06 -0700

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-masked]]
Sent: Thursday, August 12, 2004 3:00 PM
To: Fleischman, Eric; Dean Anderson
Cc: [email-masked]
Subject: Re: Question about use of RSVP in Production Networks

Hi,

Cordially,
BobN

---- Original message ----
are 
screw
needed.  
need to
then
opens
to
Cisco in
for
For
of
to
what
Thank

---

From: Dean Anderson <[email-masked]>
Date: Sat, 14 Aug 2004 22:46:07 -0400 (EDT)

On Fri, 13 Aug 2004, Tony Hain wrote:

> Propagating clueless FUD does not result in progress. 

That is true. Lets try to keep the FUD to a minimum.

> Inter-provider trust is something the Internet has to deal with. The
> self-proclaimed gods of the ISP world bluster about how much smarter they
> are than the Bell-heads, but even the lowly Bell-heads figured this one out.

Literally true. Most choose not to trust providers they don't know
anything about and have no direct connectivity with. Some choose not to
trust those they have direct connectivity with. Some choose to run
alternate internal networks and not trust the other internal networks.  
But unrealistic amounts of trust is something you'd have to to deploy RSVP
in the general internet.  It has nothing to do with bluster or competition
with Bell-heads.

> > choose which packets to discard.  
> 
> RSVP is a signaling protocol. The policy installed in the routers with
> congested links is the one deciding what to discard, and it has the
> opportunity to take hints from that signaling if it chooses. 
> 
> Despite rumors to the contrary, most complex enterprise networks include
> non-LAN links, and even in the all-LAN case there are speed mismatches
> between old and new segments.

Complex, as in fortune 1000. fortune 5000? (no such list, I think, but you
get the idea).  There aren't actually that many organizations that have
more than one office.

> > If you have no congestion problem, then
> Signaling is useful for more than QoS, though it is not clear that RSVP as
> currently defined is useful for signaling non-QoS related policy. 

Literally true. But its not clear that RSVP is useful for anything,
outside of some very limited situations.

> As you say it depends on the nature of the congestion, but also the nature
> of the application in the face of congestion. Generalizing all complex
> topologies to a congested uplink just leads to protocol decisions that are
> useless in the real world. 

I'm not generalizing topologies. I'm generalizing the type of problems
that need to be solved.  We have a whole lot of situations with tail
circuit congestion and comparatively few problems with large enterprise
congestion.  

> This is the type of BS that keeps useful tools out of the hands of those
> that need them, but don't have enough time to figure out the reality. The
> only points that need to pay attention to signaling are those where
> congestive loss is likely to occur. Even then, a smart implementation might
> only pay attention once a threshold has been crossed indicating that queues
> are building. 
> 
> > 
> WTFO! RSVP is a periodic signal, so it does detect and respond to mid-span
> events. 

Yes. Sooner or later RSVP will notice a link is down. But so will BGP and
OSPF. One wants this to happen within milliseconds in a QOS solution.  An
old saying somes to mind: "Same day service in a millisecond world".

> The reason the Internet has been successful is that each administrative
> domain gets to decide which technologies are deployable. Your decision that
> RSVP is not deployable does not automatically restrict if from wide
> deployment. 
> 
> In answer to Eric's original question, the FUD being spread through
> responses like Dean's have squelched what little RSVP had been deployed
> several years ago. That does not remove the need for a signaling protocol,
> as many WGs find they need to define new ones or variants. The bottom line
> is that the lack of a trust model makes operators suspicious of any external
> signal.

I didn't say that a signaling protocol wasn't needed. I said that RSVP 
doesn't cut the mustard for the needed protocol.

		--Dean