BGP announcements and small providers
karl at Mcs.Net
Wed Feb 26 21:57:59 UTC 1997
> Karl Denninger supposedly said:
> > You're making lots of assumptions.
> > 1) That client DNS systems will actually honor such a TTL. Many
> > don't (claim they're broken all you want, but these are the facts).
> > 2) That client SOFTWARE will actually go back and ask again for the
> > IP number. Several won't (Netscrape being rumored to be one of
> > them). TTLs are irrelavent in that case.
> > Go ahead and try to tell your customer, who purchased web service from you,
> > that you have the right to disrupt their operations at any time and under
> > any pretense and see how many of them you have left.
> How do you handle hardware upgrades, random crashes, etc. with your
> clients? Do you give them a refund for such downtimes? DO you guarentee
> that every client that tries to access their web page will always get
> My guess is you don't. You perform a service for them and probably
> schedule maintenence in such a way as to minimize downtime and impact on
> that service.
> If you have a better scheme, like fully redundent machines that fall over
> automatically and let you do maintenence on one while the other opperates
> then I think you have done an excellent job at providing a quality service
> for your customers. On the other hand, someone who has done such a setup
> should realize how easy it would be to migrate it to different addresses
> while maintaining pretty much complete connectivity for the old addresses
> for a reasonable time (like a standard TTL length).
> ---> Phil
We have a much better scheme.
Try coordinating multiple servers on multiple addresses, against the same
document and log data, without any possibility of corruption during a
significant period of time.
Second, why should we have to have twice the infrastructure in place for
such an event?
But let's put that aside for a minute, because it isn't the biggest issue.
Its not our internal infrastructure that is the worst problem (although
that's certainly significant and a royal pain in the ass). It can be
argued, though, that the disruption involved there comes about as a
consequence of our decision, and it impacts us. That's "fair", especially
if everyone has to play by the same rules (ie: an MCI customer who leaves
has to renumber, an MCSNet customer who leaves has to renumber, etc).
But at the indirect level its a different issue entirely.
Our CUSTOMER'S networks should not be subject to disruption because *WE*,
as their IP packet supplier, change a vendor relationship.
Again, if you don't know why this is the case, then you need to talk
to some attorneys. Tying customers like this at an indirect level can
expose you to all kinds of fun and games, none of them technical.
Building policy *as a group* which acts to restrain trade (and this most
certainly does) is extraordinarily dangerous. I will have nothing to do
with any association or group which does this, because from my analysis
the risk exists that such an act is a criminal violation of US Federal
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service
| 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
More information about the NANOG