I question the usefulness of path-coupled signalling beyond a certain point in the network. Dean Anderson voiced them pretty well in the original thread about RSVP -- it just doesn't seem to make any sense beyond a very closed environment (like the first hop) -- and in that case, you should be able to use another kind of signalling as well.
If we don't learn anything of the mistakes we did with RSVP, we're bound to repeat them.
First, we have to agree on what the mistakes were :-)
No. Here's one counter-argument. Enterprise networks tend to have dumb-bell topologies, where the bottleneck links are in the interior rather than at the edges (exactly the opposite of serivce provider networks). They have meshes of 100meg+ all over each site, but the sites are interconnected with some service (like MPLS VPN, frame relay, etc.) which is expensive and often with very limited bandwidth (sometimes sub-T1). These links are not necessarily all that easy to identify in the topology, because for reliability enterprises configure mulitple routers and backup links. There is strong demand for flow-granularity admission control on such links, and an end-to-end model works better because site-to-site flows can swamp both the uplink at one end and the downlink at the other end.For example, has the design clearly restricted itself to the first or the last hop, or within the first couple of hops?
There are other useful examples which I can share if people are interested.
What about discovery of the furthest point. Do you not find that a persuasive use case?For that purpose, I'm not 100% sure if you would need a path-coupled signalling. You'll certainly want path-coupled signalling for signalling with a much wider "span" (because it's the simplest way to do it from the host's perspective), but I'm arguing (as Dean was) that this isn't an interesting approach from the network operators' perspective.
This assume edge tree topologies, which are common but hardly ubiquitous....
As for the alternatives: 1) for first-hop only, there's really little need for a router alert, any protocol would do, as you already know who your routers are :-) 2) for hops beyond the first-hop router, I'd consider setting up a single server which would be responsible for brokering the QoS capabilities, firewall holes, etc. You contact the server, and ask it to open a certain kind of hole, set up certain QoS between (source, destination), etc. There are a number of options how you could discover this kind of system: a) a DHCP option b) a DNS lookup (e.g., SRV record based on your DNS search path) c) asking the upstream router using protocol learned in 1).
These kind of approaches essentially move the intelligence and processing to specific nodes who are better capable of handling such requests, having policy who can request what, removing the processing and cruft from the routers. And the hosts have have much easier time figuring out whether requesting these capabilities is supported in the network, instead of spewing a considerable amount of in-band signalling attempts to the network.
This is hardly a neutral characterization of the tradeoffs.
Cheers, Dave.
-- 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