RE: RouteScience?

["John Leddy" <jleddy () routescience com>]

Peter,

It has been a few days, but I did want to respond to
your last post.

The initial PathControl product is designed to address
the egress decisions of a multihomed enterprise.  Many
of the first product features were driven by this set of
customer configurations.  The NO_EXPORT attribute is an
example of something that can be done in many enterprises
but will not be possible in most ISP applications.  The
goal was to do everything possible to make it unlikely that bad
configurations could leak our performance routes.

We are in discussion with ISPs who wish to deploy this technology
in their own networks.  The constraints in that environment
are rather different, and we are addressing features to deal
with the added complexities of peering, downstream AS's,
national/international geographies, internal link congestion, etc.

We look forward to being able to discuss our ISP release on this
list, once that time comes.  We will be publishing more technical
information about the product over time.

John Leddy
RouteScience


> -----Original Message-----
> From: owner-nanog () merit edu [mailto:owner-nanog () merit edu]On Behalf Of
> Peter Francis
> Sent: Thursday, August 23, 2001 1:53 PM
> To: Sean Finn
> Cc: nanog () merit edu
> Subject: Re: Routescience?
>
>
>
> > Christoper,
> >
> >  no, the PathControl device does *not* adjust outgoing
> > advertisements in any way; all prefixes that we repeat
> > carry the NO_EXPORT attribute.
>
> And if the ISP using your box has downstream BGP customers in
> different ASes?
>
> The NO_EXPORT tag really serves no purpose here because any ISP
> that would be avertising your bozxes routes to its upstreams
> already has a much bigger problem.
>
> The NO_EXPORT tag just makes it more complicated to get the
> "better paths" to the ISPs BGP customers.
>
> Adding unnecessary locks just to make something sound "safe" is
> usually a surefire way cause a disaster when a slightly-clued
> person clears the tag to get the routes to downstreams and
> suddenly discovers they are announcing your boxes routes to the world.
>
> Do you guys have a white paper on all this?
>
> Peter
>
> > cheers -- Sean
> >
> >
> > "Christopher A. Woodfield" wrote:
> > > Can/will the box adjust inbound route selection via the use of
> prepending
> > > and/or provider communities?
> > >
> > > -C
> > >
> > > > 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
> > >
> > > --
> > > ---------------------------
> > > Christopher A. Woodfield                rekoil () semihuman com
> > >
> > > PGP Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B