|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: RouteScience?
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: [email protected] [mailto:[email protected]]On Behalf Of > Peter Francis > Sent: Thursday, August 23, 2001 1:53 PM > To: Sean Finn > Cc: [email protected] > 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 [email protected] > >> > >> PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
|