On Aug 11, 2004, at 7:58 AM, Pekka Savola wrote:
On Tue, 10 Aug 2004, Fleischman, Eric wrote:If you can come up with another technique for doing path-coupled signaling which is less susceptible to abuse I'd drop RAO in a heart-beat. There are a bunch of very useful things that require (or at least work a heck of a lot better with) path-coupled signaling: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.
I'd be interested about this as well, but also in more general.
I'd be in favor of deprecating the IP router alert option completely. Effectively this affects RSVP and MLD *). I'd want to similarly do away with the IPv6 Hop-by-Hop options. At the very least, I'd like to prevent further standardization of these options.
The justification is simple: any "magic" packets which all routers on the path must somehow examine and process seems a very dubious concept when we want to avoid DoS attacks etc. on the core equipment which must run on hardware: effectively this means that either these are ignored in any case (nullifying the use of such options), or put on a "slow path" (causing a potential for DoS). IMHO, it seems just simply bad protocol design to require such behaviour.
I'm interested what others think about this.. :)
- figuring out where to install QoS state in complex topologies
- firewall and NAT traversal
- finding the thing furthest away from you (as opposed to closest to you) that performs a certain function, such as state-deaggregation for QoS or tunnel anchor for IPSEC tunnels.
It seems to me that the key is to be able to screen packets at wire rate, even if they must be looked at by the control plane of each router. that seems only loosely related to RAO itself.
*) MLD should be relatively straight-forward to re-design (just send the MLD reports to a link-local address which the router is listening), or just keep it as is for now. RSVP can probably thrown away without many tears.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
This message was passed through ietf_censored@xxxxxxxxxxxxxxxxxxxx, which is a sublist of ietf@xxxxxxxxx Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator (ietf_admin@xxxxxxxx).
David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@xxxxxxxxx
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf