Re: Has PSI been assigned network 1?
Well, there is a big _if_: if things will work w/o RADB (and they will, for no sane provider will use RADB as the sole source of exterior information at peering points, not for at least before it became the proven and stable service) -- people will forget to update things, cut the corners, etc. NACRs were so big headache that our implementation people dance around when they hear that there won't be any NACRs. RADB got to be easy to use to become real. The e-mail interface of NACRs is close to uselessness, and too big headache to deal with. Waiting time on processing is simply ridiculous. There should be a host accepting telnet sessions for on-line updates (which have to be installed *immediately*, so whoever added a network can test connectivity and go ahead). There should be well-defined and useful interface to service providers databases. It should be secure. RADB should be able to implement _existing_ routing policies, not the subset which can be defined in RIPE-81 (it currently can't, there are places which use a lot of _very_ hairy stuff). Without that i do not see RADB being successful or useful beyond the point of filtering updates from particularly obnoxious peers. --vadim From: Guy Middleton <guy@ghost.uunet.ca> To: avg@sprint.net, curtis@ans.net, jerry@fc.net Subject: Re: Has PSI been assigned network 1? Cc: nanog@merit.edu, prs@isi.edu Message-Id: <95Apr18.213028edt.53028-1@ghost.uunet.ca> Date: Tue, 18 Apr 1995 21:30:28 -0400
Curtis, you are able to do that only because all others were legally bound to fill your database.
I'm not sure people will be spending their resources on populating database for somebody else's benefit.
(And RADB already has lots of garbadge in it).
Once the RADB is in general use, we can expect that networks other than ANS will use it to generate route-filters. There is an interconnect point already using the CA*net registry, for example. Any active use of the RADB creates an incentive to ensure that it is accurate.
In message <199504191750.NAA18978@titan.sprintlink.net>, Vadim Antonov writes:
Well, there is a big _if_: if things will work w/o RADB (and they will, for no sane provider will use RADB as the sole source of exterior information at peering points, not for at least before it became the proven and stable service) -- people will forget to update things, cut the corners, etc.
NACRs were so big headache that our implementation people dance around when they hear that there won't be any NACRs.
RADB got to be easy to use to become real. The e-mail interface of NACRs is close to uselessness, and too big headache to deal with. Waiting time on processing is simply ridiculous.
To register a new route, we need prefix, prefix length, home AS. The rest is helpfull, like contact information for when things are broken, or might break. If the AS is already known, we have policy for it, so you don't need to bother figuring out which AS and ENSS to route through as you did with each NACR. If new AS keep popping up, you can define an AS macro such as: SPRINT-DIRECT-ATTACHED-CUSTOMERS-WITH-UNIQUE-AS and then specify that each new AS falls into the AS macro and so get the policy treatment for the AS macro.
There should be a host accepting telnet sessions for on-line updates (which have to be installed *immediately*, so whoever added a network can test connectivity and go ahead).
I'm surprised your trouble ticketing system doesn't support a "next action timer" that allows you to get notification after some time period, like when the new circuit is supposed to be turned up, or when the routing reconfiguration is supposed to have been completed so you can then check connectivity.
There should be well-defined and useful interface to service providers databases.
It should be secure.
I agree on the security note. It should be more secure. Then again accepting route advertisements with no validation whatsoever isn't very secure either.
RADB should be able to implement _existing_ routing policies, not the subset which can be defined in RIPE-81 (it currently can't, there are places which use a lot of _very_ hairy stuff).
First - the current spec is RIPE-181. AS 690 has about as complex a set of policies as anyone I can imagine. RIPE-181 can handle our import policy just fine. We've suggested some minor syntax changes that would substantially reduce the number of lines required to express this (without defining a few thousand macros to accomplish this), but the current syntax does provide the needed flexibility. Our export policy cannot be expressed in RIPE-181 because some of our export policy is AS path based. An AS path extension has already been proposed (or at least batted around on the rps mailing list).
Without that i do not see RADB being successful or useful beyond the point of filtering updates from particularly obnoxious peers.
--vadim
Thanks for sharing your insights on this topic. Curtis btw- I correected the Cc (which I botched in the first place) from prs@isi.edu to rps@isi.edu.
Vadim Antonov <avg@sprint.net> writes: Well, there is a big _if_: if things will work w/o RADB (and they will, for no sane provider will use RADB as the sole source of exterior information at peering points, not for at least before it became the proven and stable service) -- people will forget to update things, cut the corners, etc.
We have such a proven and stable service in Europe: The RIPE Routing Registry. Yes we could do more to get it populated better but that is a matter of appropriate resources which we do not have at this point. As a matter of fact I am quite envious of the amount of money NFS spends on the RA. We also have a number of useful tools that make use of the registry. These were developed with money from real service providers (European and US). We also have a number of providers that use the registry (albeit not exclusively) in configuring their routers. I understand from them that it actually helps them limit the complexity involved.
RADB got to be easy to use to become real. The e-mail interface of NACRs is close to uselessness, and too big headache to deal with. Waiting time on processing is simply ridiculous.
Do not confuse the transport mechanism with the update mechanism. We support only e-mail as a transport at this point and get no flak about it because the update itself is automatic and turnaround times are consequently low. The main factor is the e-mail transit time.
There should be a host accepting telnet sessions for on-line updates (which have to be installed *immediately*, so whoever added a network can test connectivity and go ahead).
See above. We have working code for interactive updates but before deployment we need to solve authentication and authorisation issues. Since mail works very well this is not a high priority at present.
There should be well-defined and useful interface to service providers databases.
We have that at the moment: Make a dump of your database in RIPE-181 format and we will copy it. It is crude. It works. We are working on improving it.
It should be secure.
Please define secure. ;-) We have and authorisation and authentication framework for updates. See ripe-120 for details.
RADB should be able to implement _existing_ routing policies, not the subset which can be defined in RIPE-81 (it currently can't, there are places which use a lot of _very_ hairy stuff).
In a routing policy description language such as RIPE-181 tradeoffs have to be made between complexity and power of expression. In RIPE-181 we have made some design decisions towards limiting complexity. The main reason for this is that all ISPs will have to learn the language! The RPS working group will work to expand power of expression while hopefully retaining enough simplicity for the majority of cases to prevent your "implementation people dance around" when it gets replaced eventually.
Without that i do not see RADB being successful or useful beyond the point of filtering updates from particularly obnoxious peers.
Maybe you should contribute to the RPS working group, especially in the area of suggesting features needed where RIPE-181 lacks the expressive power you need. Daniel
Vadim: On your comment:
NACRs were so big headache that our implementation people dance around when they hear that there won't be any NACRs.
Beyond the technical issues which Steve Richardson mentioned where your dependency on the NACRs could have been avoided - we've had several issues regarding the knowledge base of those submitting NACRs. We've provided several phone tutorials to those people submitting NACRs on CIDR and aggregation. Over the phone tutorials of this material are a little difficult at best. I even offered to discuss this in a meeting here in Ann Arbor, but that offer was not accepted. Your people seem to rotate through the NACR submission process without the benefit of training in CIDR. I suspect their frustration with NACRs has come in part from their lack of understanding. In the past 5 months there have been massive changes to the NSFNET/ANSnet and to the Internet. These changes cause stress for us all - but lack of training aids unnecessary burdens to us all. Perhaps your management will help us all by giving you some additional time to train your implementation people. I suspect the lack of knowledge will hurt in the RADB based world as well. Sue Hares
On Thu, 20 Apr 1995, Susan Hares wrote:
NACRs were so big headache that our implementation people dance around when they hear that there won't be any NACRs.
We've provided several phone tutorials to those people submitting NACRs on CIDR and aggregation. Over the phone tutorials of this material are a little difficult at best. I even offered to discuss this in a meeting here in Ann Arbor, but that offer was not accepted.
Your people seem to rotate through the NACR submission process without the benefit of training in CIDR. I suspect their frustration with NACRs has come in part from their lack of understanding.
In the past 5 months there have been massive changes to the NSFNET/ANSnet and to the Internet. These changes cause stress for us all - but lack of training aids unnecessary burdens to us all.
Are you aware of the ACM article by Harald Eidnes available in Postscript form at ftp://ftp.uninett.no/pub/misc/eidnes-cidr.ps.Z ? Does anyone know if there is a WWW site or gopher that has a collection of tutorial level documents. For many neophytes RFC's and stuff like the PRIDE documents can be somewhat intimidating to dig into. BTW, I changed prs@isi.edu up there to rps@isi.edu ;-)) 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
Thank-you for the reference. I'll look at Harald's document. Sue Hares
participants (5)
-
Curtis Villamizar -
Daniel Karrenberg -
Michael Dillon -
Susan Hares -
Vadim Antonov