Re: Has PSI been assigned network 1?
A half of them has to be explained how route announcement is different from broadcasting. Forget about good citizenship -- they may be willing but they must be educated first. [...]
Educated by whom?
It seems to me that this education is one of the services that small ISPs ought to expect of their national service providers.
Huh? Where did you see "education" in terms of service contracts? If a person goes in the business it is assumed that (s)he knows the profession. It is certainly not the case for many US-based Internet service providers. The problem is that even a tiniest service provider doing BGP with some bigger provider can kill most of the Internet by injecting a single bogus route. (I expect to hear more "RS will fix everything" speech at this point. Relax. It is not here yet; and we had occasions when bogus routes were killing ANS connectivity per-network filtering notwithstanding. There are bugs and interesting incompatibilities :). Such service provider doing multi-homed trick is simply a walking disaster. That's why we're making sure all parties involved understand the routing policy, safe networking practices, etc before we enable BGP.
Conversely, it seems that the rest of the community ought to expect that national service providers will be responsible for educating their customers, (e.g., ISPs).
Sounds kind of over-expectant. Considering that even large service providers have real bad problems with finding engineers who know what they are doing. The best we can do is to limit the damage by doing fascistic filtering, and work with those ISPs who want to listen and really want to learn. Others will be out of business earlier or later anyway. --vadim
On Fri, 21 Apr 1995, Vadim Antonov wrote:
It seems to me that this education is one of the services that small ISPs ought to expect of their national service providers.
Huh? Where did you see "education" in terms of service contracts?
If a person goes in the business it is assumed that (s)he knows the profession. It is certainly not the case for many US-based Internet service providers.
In today's world of exponential Internet growth, I don't think it is practically feasible to expect any significant percentage of ISP's to _know_the_business_ before they get into it.
Conversely, it seems that the rest of the community ought to expect that national service providers will be responsible for educating their customers, (e.g., ISPs).
Sounds kind of over-expectant. Considering that even large service providers have real bad problems with finding engineers who know what they are doing.
Yes, it is over-expectant to think that the national service providers should provide direct one-to-one training for their customers. On the other hand, as a small ISP who *WANTS* to learn and *WANTS* to know how things work before diving in, I must say that it has not been that easy finding the written materials at a tutorial level to learn this stuff. I have, however, found quite a lot of written materials out there on the net that help to some degree. I know that among ISP's I am the exception rather than the rule and although I would like to pass on some of this information to other new ISP's through some of the lists we are on, the material I have is not well organized enough to easily present it to others. If some of the operations folks could scrape together some resources to collect these materials into a coherent web site as an introduction to Internet operations, I'm sure many ISP's would be grateful for the chance to learn. Michael Dillon Voice: +1-604-549-1036 Network Operations Fax: +1-604-542-4130 Okanagan Internet Junction Internet: michael@junction.net http://www.junction.net - The Okanagan's 1st full-service Internet provider
...
although I would like to pass on some of this information to other new ISP's through some of the lists we are on, the material I have is not well organized enough to easily present it to others. If some of the operations folks could scrape together some resources to collect these materials into a coherent web site as an introduction to Internet operations, I'm sure many ISP's would be grateful for the chance to learn.
After some years being associated with the IEPG the observation I have to make is that the operations folk who really do understand how the Internet is glued together are way too busy keeping it strung together to do anything else. Micheal, if you have put together some information I'd be only too happy to put it on the IEPG WEB pages as another piece of the oprational information jigsaw puzzle. Your contribution is worthwhile is it is pretty wishful thinking to expect other operational people to assemble this stuff - the actual operational agenda is simply far too pressing for most of us. Geoff Huston IEPG (thats http://iepg.org/iepg)
A half of them has to be explained how route announcement is different from broadcasting. Forget about good citizenship -- they may be willing but they must be educated first. [...]
Educated by whom?
It seems to me that this education is one of the services that small ISPs ought to expect of their national service providers.
Huh? Where did you see "education" in terms of service contracts?
If a person goes in the business it is assumed that (s)he knows the profession. It is certainly not the case for many US-based Internet service providers.
The problem is that even a tiniest service provider doing BGP with some bigger provider can kill most of the Internet by injecting a single bogus route. (I expect to hear more "RS will fix everything" speech at this point. Relax. It is not here yet; and we had occasions when bogus routes were killing ANS connectivity per-network filtering notwithstanding. There are bugs and interesting incompatibilities :).
Such service provider doing multi-homed trick is simply a walking disaster. That's why we're making sure all parties involved understand the routing policy, safe networking practices, etc before we enable BGP.
Conversely, it seems that the rest of the community ought to expect that national service providers will be responsible for educating their customers, (e.g., ISPs).
Sounds kind of over-expectant. Considering that even large service providers have real bad problems with finding engineers who know what they are doing.
The best we can do is to limit the damage by doing fascistic filtering, and work with those ISPs who want to listen and really want to learn. Others will be out of business earlier or later anyway.
--vadim
Really? Fascistic filtering breaks connectivity. So you trade a *risk* of broken connectivity for KNOWN broken connectivity? Sounds like a poor trade to me, and one which, undertaken consciously and with knowledge of the repercussions, leaves you with being less than a full Internet connectivity provider. After all, if you're filtering perfectly valid announcements then you are, by definition, not providing connectivity to the "whole Internet" to the best of your ability, are you? The *better* path is to fix problems when they arise, and to drop peers if necessary until the problem site(s) become educated and/or fix the bad announcements being made to them. Is this a big job, and one which requires technical folks that know what they're doing -- on the job all the time? Yep. That's a cost of doing business in this game. The RS doesn't *fix* this per-se, but it does certainly give you fair warning of someone doing something known to be silly (like announcing a path which you know is authoritatively yours). -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info@mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net
Karl wrote:
Fascistic filtering breaks connectivity.
Please explain this. I do not think that strict filtering of routes necessarily detracts from sustained connectivity. While it may decrease the elasticity of the net, and it may delay the time for new networks to be connected, properly thought out routing policies can properly effect sturdy, efficient networks.
So you trade a *risk* of broken connectivity for KNOWN broken connectivity?
Yes, actually, I would. It comforts me to know that there are two more hurdles placed in network X's way so that our routes can not be spoofed across the world.
Sounds like a poor trade to me, and one which, undertaken consciously and with knowledge of the repercussions, leaves you with being less than a full Internet connectivity provider.
By filtering the routes that an ISP allows they are less than a full ISP?!!? -- Alan Hannan (402) 472-0241 MIDnet Inc.
Karl wrote:
Fascistic filtering breaks connectivity.
Please explain this. I do not think that strict filtering of routes necessarily detracts from sustained connectivity. While it may decrease the elasticity of the net, and it may delay the time for new networks to be connected, properly thought out routing policies can properly effect sturdy, efficient networks.
Sure. Routing policies are not the same thing as fascistic filtering. If your policy amounts to preventing certain prefixes from being announced to your network then you have by definition made it impossible to reach those sites from your backbone. This breaks connectivity.
So you trade a *risk* of broken connectivity for KNOWN broken connectivity?
Yes, actually, I would. It comforts me to know that there are two more hurdles placed in network X's way so that our routes can not be spoofed across the world.
But your routes *can* still be spoofed. This is the problem. Until and unless you can define exactly what the locus of "your routes" is, you have the problem. The route server approach *tries* to define this, and in fact it probably does (or can do) a reasonable job. Absent this kind of registry, filtering announcements may *appear* to make things more stable, but it fails to provide the widest connectivity and in fact just makes sites permanently unreachable.
Sounds like a poor trade to me, and one which, undertaken consciously and with knowledge of the repercussions, leaves you with being less than a full Internet connectivity provider.
By filtering the routes that an ISP allows they are less than a full ISP?!!? -- Alan Hannan (402) 472-0241 MIDnet Inc.
Filtering the *announcements* that an ISP will honor, without being able to verify whether or not they are really bogus, does exactly that. If you want some kind of assurance that prefixes being advertised are legit, then you need a routing-registry type-of-service. This service requires that the users and people putting in the data that it crunches trust it implicitly. I am not expressing an opinion here as to whether or not the current efforts in this area fill the requirement lists that people have. I am, however, saying that if you filter without *knowing* that the filters pass all legit prefixes (an impossible task unless you're omniscient) you will break connectivity in many specific cases. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 7 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info@mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net
The problem is that even a tiniest service provider doing BGP with some bigger provider can kill most of the Internet by injecting a single bogus route. (I expect to hear more "RS will fix everything" speech at this point. Relax. It is not here yet; and we had occasions when bogus routes were killing ANS connectivity per-network filtering notwithstanding. There are bugs and interesting incompatibilities :).
How about a speech that sez "Sprint will fix everything"? There was a comment made in Boulder that with the addition of Curtis's ideas on route damping and some judicious other tweeks, that an RS could do just that. We agreed to work on adding just such features to the RS code. It is not clear that there was a client demand for this feature right now. Now if Sprint were to become a RS client, and asked for this feature, I expect that it would get higher priority than it does now. --bill
participants (6)
-
Alan Hannan -
bmanning＠ISI.EDU -
Geoff Huston -
Karl Denninger, MCSNet -
Michael Dillon -
Vadim Antonov