Re: hop-by-hop and router alert options [Re: Question about use of RSVP in Production Networks]

[David R Oran <[e-mail]>]

> 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 :-)

> For example, has the design clearly restricted itself to the first or
> the last hop, or within the first couple of hops?
>
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.

There are other useful examples which I can share if people are 
interested.

> 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.
>
What about discovery of the furthest point. Do you not find that a 
persuasive use case?

> ...
>
> 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).
>
This assume edge tree topologies, which are common but hardly 
ubiquitous.

> 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 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> This message was passed through [e-mail], 
> which is a sublist of [e-mail]. Not all messages are passed. 
> Decisions on what to pass are made solely by IETF_CENSORED ML 
> Administrator ([e-mail])
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: [phone]
Email: [e-mail]


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