Skip to main content

Resource Reservation Protocol (RSVP) Proxy Approaches
RFC 5945



Lars Eggert
(Magnus Westerlund)

No Objection

(Gonzalo Camarillo)
(Jari Arkko)
(Lisa Dusseault)
(Pasi Eronen)


Note: This ballot was opened for revision 09 and is now closed.

Lars Eggert (was No Objection) Yes

(Cullen Jennings; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2010-03-22)
Need to discuss the applicability of deployment - as previous RSVP discussions, this is likely only deployable inside a single trust domain. 

For a proxy that does inspection or path triggered, how does it know which ones to "proxy" and what to ignore. It seems this will break all end to end RSVP that behind a proxy. 

Why are section 4.1 and 4.1 SHOULD and MAY implement. It seem like they need to be MUST.

How do proxies know what bandwidth to request for a flow? If they assume some certain bandwidth, this makes it much harder to deploy new services. 

Need to specify "predetermined time" in section 4.1. Not willing to have it be zero. 

Why is the Receiver-Proxy-Needed needed?

RAO paragraph in security consideration does not seem right. 

The dissection in last para of stein 5 is no longer true with the other changes.

Don't understand why this needs the group-keying work

For something like triggered approach, when does the reservation get town down?

The draft discusses deployments snooping SIP. Experience with SIP ALGs in firewalls has proven this is a really bad idea and mostly fails. Not to mention SIP over TLS. 

The draft seems to hint at detecting RTP packets - I have no idea how to do this, please clarify. 

ICE is sometime used to signal media flows, but not always - how would the device know. Even worst, how would it know what bandwidth to use. 

Has the working group considered if there are ways to achieve this that are not IPR encumbered?

(Magnus Westerlund; former steering group member) Yes

Yes ()


(Adrian Farrel; former steering group member) (was Yes) No Objection

No Objection (2009-04-29)
Nits to fix if you have to do a respin or in AUTH-48 if the RFC Editor
misses them.

I am surprised that all of your references are Informative. Surely some of these are prerequisites for understanding your work?

(Alexey Melnikov; former steering group member) No Objection

No Objection (2009-05-03)
4.3.  Inspection-Triggered Proxy


   Note however, that in case of reservation failure, the inspection-
   triggered RSVP Proxy does not have a direct mechanism for notifying
   the application (since it is not participating itself actively in
   application signaling) so that the application is not in a position
   to take appropriate action (for example terminate the corresponding
   session).  To mitigate this problem, the inspection-triggered RSVP
   Proxy may mark differently the DSCP of flows for which an RSVP

The first use of the DSCP acronym should be expanded.

I am also agreeing with Adrian's comment, I was wondering about this myself.

(Dan Romascanu; former steering group member) No Objection

No Objection (2009-05-21)
In Section 4.5: 

   Candidate protocols for realizing such interface
   include SNMP ([RFC3416]), COPS-PR ([RFC3084]), QPIM ([RFC3644]), the
   Extensible Markup Language (XML) and DIAMETER ([RFC3588]).  

SNMP is seldom used for configuration purposes over the Internet in real life. COPS-PR has very little reported deployment if at all. XML is manguage to present information and not a protocol. 

I suggest to take out XML, and to consider whether SNMP and COPS-PR should be left in the text. On the other hand I believe that it would be appropriate to mention here NETCONF (RFC 4741) which is a protocol that uses XML-encoding for performing configuration management operations on network devices.

(Gonzalo Camarillo; former steering group member) (was Discuss) No Objection

No Objection ()


(Jari Arkko; former steering group member) (was Discuss) No Objection

No Objection ()


(Lisa Dusseault; former steering group member) No Objection

No Objection ()


(Pasi Eronen; former steering group member) No Objection

No Objection ()


(Ralph Droms; former steering group member) No Objection

No Objection (2009-05-21)
In section 4.1, the paragraph immediately following figure 3 explains that receipt of a ResvErr by the RSVP Receiver Proxy "ensures that the RSVP Receiver Proxy is aware of the reservation failure, conventional RSVP procedures do not cater for notification of the sender of the reservation failure."  It's not clear to me why the sender needs to be notified of reservation failure.  Is this addressing a problem with RSVP generally or just RSVP Receiver Proxy?  I speculate that the problem here may be that the Proxy receives the ResvErr, so neither the application receiver nor the sender is explicitly notified of the reservation failure; do I have that right?  Would someone more familiar with RSVP than I am be able to deduce the reason for sender notification?  I'm happy to be educated as I'm not well-versed in RSVP.

Nit: "cater for" might read better as "cater to" or "provide for"

(Robert Sparks; former steering group member) No Objection

No Objection (2009-05-17)
Agree with Tim's concern #2 (what happens when you unintentionally (or intentionally) end up with more than one proxy in a path?

(Ross Callon; former steering group member) No Objection

No Objection (2009-05-21)
I am concerned that RSVP in general allows hosts to send something that the router has to receive in its control plane, which opens up the possibility of DOS attacks by the hosts against the routers. Given the current state of host security, it is pretty much a non-starter to let millions of hosts send anything to the router's control plane. The result is that service providers won't allow RSVP packets across the CE/PE boundary (or just tunnel them over the network). 

I am not aware of this being discussed anywhere. I think that this general issue is worth writing up in more detail. 

I am putting this in as a comment, rather than a DISCUSS, since this is not specific to RSVP proxy. It is a basic issue with RSVP (which of course is water than went over the dam a very long time ago). Thus it is not at all clear that this document is the right place to discuss this issue.

(Tim Polk; former steering group member) (was No Record, Discuss) No Objection

No Objection (2009-05-05)
section 1:

"presents several fundamental RSVP proxy approaches insisting on how ..."

I don't think "insisting" is the right word here!

section 4.4:

(Ron Bonica; former steering group member) (was Discuss) Abstain

Abstain (2009-05-19)
I am abstaining not so much because of the content of this document, but because this document extends other work which is not fit for deployment across provider boundaries.

For the most part, ISPs do not permit customers to signal bandwidth across their boundaries using RSVP. There are many reasons for this, most significant of which is that it generally does not support the ISPs business models.

Network security issues are also significant. When most routers detect an RSVP message, which includes the IP Router Alert Option, the router consumes additional resources to process the optioned packet, before it authenticates the packet. This leaves the router vulnerable to various types of DoS attack.

The IETF should address the general problem of secure signaling before it spends any more cycles on RSVP extensions.