Vadim, others, Vadim Antonov wrote:
My guess is that most network operations folks would be quite interested in learning what kind of operational impact to expect from the deployment of your boxes (and, frankly, what kind of defensive measures they have to take to minimise the impact).
As David Schwartz noted on the basis of earlier posts, and I would like to confirm, the incarnation of PathControl we are discussing optimizes outbound routing. I've received off-list mail on this question too, so I'd like to be clear about it. The consequence is that ISP folks should not be worried about new floods of strange-looking BGP data emerging about their customers which they might be obliged to accept. The customer outbound feeds will become no stranger than they are already :-) Applied in a stub AS, we do not create any prefixes which are not already present. So as an ISP serving such a stub, you would be exposed to what amounts to an (automated) change in internal policy for the client AS - the same thing that would happen if they shifted local prefs, or other controls, by hand. Either they now select you as the winning advertisement where before they did not, or vice versa. Once more, we do not cause the stub AS's own advertisement of themselves to change. We specifically avoid touching locally originated prefixes. If the ISP is currently accepting any of the routes PathControl is designed to change, then the AS is not stub, it's transit. Hopefully this clarifies an important issue. (Referring back to Paul Vixie's point, we have found that careful optimization of a single outbound step has very substantial payoffs in terms of the end to end, bidirectional performance. The figures quoted on our web page and in the press release refer to this: end to end application speedup caused solely by outbound route selection!) Mike