Inline,
On Thu, 12 Aug 2004, Bob Braden wrote:
> *> 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.
> *>
>
> You are far from defining an alternative architecture here, but it
> seems to me that you are generally depending upon (manual)
> configuration to provide path information, rather than directly (and
> simply) discovering it. Your suggestion seems to be that "Trust the
> ISPs to configure it all correctly." Down that path lies disaster,
> IMHO. Path-coupled signaling provides auto-configuration of path
> information, and that seems like it's worth the cost in much of the
> network.
Not at all; maybe my three paragraphs weren't enough ;-).
My first assumption is that the enterprise or the ISP who is willing
to provide increased QoS etc. will explicitly set up their routers or
systems in more general to allow this. It won't be allowed by default
-- doing so would be an obvious disaster. Operators just *DON'T*
want the users or their computers to automatically adjust the routers'
behaviours, traffic quotas, etc. -- if they allow this, they want to
do it explicitly.
Now, if we already have an assumption that the network must have some
configuration components, it seems acceptable to consider moving the
policy information and the rest of the intelligence to one single box
in the network, instead of having to distribute and process it on
every router ("allow every router's traffic priorization be configured
directly by the requests of the users" -- doesn't that sound scary?).
The user could discover the address of that box automatically, using
e.g., the mechanisms outlined above. If it can't find the box, then
it would assume no QoS etc. is provided, and would not do any further
attempts while it is in that network.
If it can find the box, it could signal which QoS metrics it wants, on
which paths (from source S to destination D), etc. Then the box uses
some policy database (similar as the routers have) to figure out
whether to grant that (or not), and would configure the routers
appropriately (figuring out what the path between Source,Destination
pair is should be trivial based on a copy of routing data).
This seems to give the same functionality as path-coupled signalling
without the drawbacks of path-coupled signalling. It requires one
additional box which the users can try to reach, and which the
operator configures to be allowed to configure the routers b/w quotas
etc. appropriately.
Let's not reinvent RSVP. Pretty please. RSVP for user-network
signalling (RSVP-TE may be slightly different) isn't going unused
because it was only slightly too complex, and it needs a modern touch
and be reborn as a NSIS product; the approach is just fundamentally
unacceptable for networks and operators.
All of this is spoken with an operator (an NREN) hat on, if it
matters.
--
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