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

Thanks for the responses so far.  Trying to answer in general...

On Wed, 11 Aug 2004, Martin Stiemerling wrote:
[Pekka:]
> | 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.
> 
> Hmm, NSIS protocol suite (new protocol that does path-coupled QoS signaling 
> ala RSVP and firewall/NAT signaling) relies on the use of router alert 
> options for the initial NSIS peer discovery process.  Is there any other 
> proposal to get a discovery mechanism like router alert options without the 
> disadvantages of this option?

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.

For example, has the design clearly restricted itself to the first or 
the last hop, or within the first couple of hops?

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.

...

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.

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