*> 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,
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.
Bob Braden
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf