Re: Has PSI been assigned network 1?
On Wed, 19 Apr 1995 18:49:39 -0400 you said:
telent info.ripe.net to test it out.
RIPE database does not control the actual routing.
I'm not sure the current RADB project has any mention of real-time updates of gated from the database. `With dozens of updates we do every day it nearly as good as useless.
CERN (as an example) picks up my routing updates daily and builds its new access filter based on mine and others routing updates. I'm not sure you want realtime updates to the actual routing. In any event, it is an improvement over the time lag of NACR updates.
It should be secure.
I use a password on all AS updates to AS378.
You call *that* secure? We have way too many people who need to do changes for our AS-es. Check the contact list for AS1800.
You can assign as many users as you wish to control specific ASs. Currently it checks my email address and password. No match - and the maintainer of the AS gets a warning mail about the attempt to alter the routing within my AS - and I have gotten warning e-mails already. Adding in PGP authentication should not be too hard if it is not done already.
If i can't implement my existing policy, i cannot use RADB, ok?
(Well, we _will_ use it -- to talk to people whose announcements are loaded with garbadge). We simply cannot use it to talk to major service providers because policies in place cannot be represented in RIPE-81.
So speak to the authors and get it improved.
--vadim
Hank
From: Hank Nussbacher <HANK@taunivm.tau.ac.il> Currently it checks my email address and password. No match - and the maintainer of the AS gets a warning mail about the attempt to alter the routing within my AS - and I have gotten warning e-mails already. Adding in PGP authentication should not be too hard if it is not done already.
We would be much more comfortable with PGP. Currently, passwords are going in cleartext over Email, not an impressively secure scheme. Though PGP does preclude automatic submission by maintainers who do not wish to keep secret keys online. Personally, I will accept the restriction. Inter-RR exchanges (e.g. RIPE/RADB/MCI/...) may find such restrictions more of a problem. I have some tangential questions. Currently, we submit o NACRs o SWIPs to InterNIC o email re routing updates to Sprint o 81ish objects to MCI o 81ish objects to the RADB and I am told we will be moving to rwhois. 0 - Why the same data to MCI and RADB? It would seem reasonable to send all updates to one registry and have the others fetch what they need. 1 - When can do stop needing NACRs? Monday, i.e. effectively now? 2 - The RADB has a lot of old, now obsolete, data maintained by others. Do we have to ask each old maintainer to clean it out, or will it all be cleaned up as the changeover settles down? 3 - SWIPs and 81ish objects (and NACRs, but they're going away, yes?) share a non-trivial subset. Are there maintainers' tools for generating both from a single database? If not, we will surely create errors of consistency. 4 - Are there more appropriate fora for weenie questions? FYI, despite the lack of rigor, Sprint's has seemed (from the bottom of the pond view) to be the most immediate and reliable over the many moons. ( Of course, with only 700 customers as compared to, e.g., Karl's 5,000 they have a much easier time of it. :-) But the overwhelming problem with all avenues has been the NACR delay.
In message <m0s33hL-000301C@rip.psg.com>, Randy Bush writes:
I have some tangential questions. Currently, we submit o NACRs o SWIPs to InterNIC o email re routing updates to Sprint o 81ish objects to MCI o 81ish objects to the RADB and I am told we will be moving to rwhois.
0 - Why the same data to MCI and RADB? It would seem reasonable to send all updates to one registry and have the others fetch what they need.
That is the goal. We're not there yet.
1 - When can do stop needing NACRs? Monday, i.e. effectively now?
Still need them. A lot of people are typing as fast as they can to remove this requirement. Code takes time to write and debug.
2 - The RADB has a lot of old, now obsolete, data maintained by others. Do we have to ask each old maintainer to clean it out, or will it all be cleaned up as the changeover settles down?
If this is true, it will have to be cleaned up. Maybe someone from ISI or Merit can comment on this.
3 - SWIPs and 81ish objects (and NACRs, but they're going away, yes?) share a non-trivial subset. Are there maintainers' tools for generating both from a single database? If not, we will surely create errors of consistency.
I'm not sure why a route object can't just indicate your intention to route using and existing AS number, allowing you to register AS, prefix, and prefix length and have the rest taken from InterNIC. This requires coordination between InterNIC and the IRR. Ideally, InterNIC would provide signed information indicating that you have SWIP registered the prefix you are IRR registering (through RADB, MCI, RIPE, or whatever). Again, it is mostly a "small matter of code".
4 - Are there more appropriate fora for weenie questions?
FYI, despite the lack of rigor, Sprint's has seemed (from the bottom of the pond view) to be the most immediate and reliable over the many moons. ( Of course, with only 700 customers as compared to, e.g., Karl's 5,000 they have a much easier time of it. :-) But the overwhelming problem with all avenues has been the NACR delay.
The typical one week or less NACR delay is longer than a tail circuit installation? Are you sure the problem isn't submitting the NACR after the circuit is installed rather than when the circuit is ordered? Curtis
Curtis Villamizar writes:
2 - The RADB has a lot of old, now obsolete, data maintained by others. Do we have to ask each old maintainer to clean it out, or will it all be cleaned up as the changeover settles down?
If this is true, it will have to be cleaned up. Maybe someone from ISI or Merit can comment on this.
We are working closely with MCI and other RR databases to clean up a lot of the contradictory and outdated information. Hopefully most of this will be cleaned up as the changeover settles down.... - Craig -- Craig Labovitz labovit@merit.edu Merit Network, Inc. (313) 764-0252 (office) 1071 Beal Ave, Ann Arbor, MI (313) 747-3745 (fax)
Allow me to clarify Curtis's remarks: | > 1 - When can do stop needing NACRs? Monday, i.e. effectively now? | Still need them. A lot of people are typing as fast as they can to | remove this requirement. Code takes time to write and debug. _ANS_ needs NACRs or RADB updates for the time being. If I were in Andrew Partan and company's shoes rather than in mine, I would simply refuse to submit them. Why? Because ANS has this history of centre-of-the-universe arrogance which I keep hoping the newer, nicer engineers there are going to be able to undo and get rid of, even though there are real risks involved in trusting one's peers just as everybody else does. The appropriate way to make routing clean and safe is pointing out problems to one's well-meaning peers and using bilateral and multilateral social pressure against one's more aloof ones. Considering that DREN and DISA have *both* been able to present a pretty clean set of routes to their new peers with a bit of friendly help and some reminders that this is an Important Thing To Do, I think we have existence proof of this. Just as a pair of data points: I was very very very keen on having an RS (or RS-like device) at FIX-EAST last week in order to help with the transition of those two fednets before they cleaned up their routing. I now no longer see a need to continue with the RS for that purpose. The second data point: we (SprintLink) do peer experimentally with the RSes at MAE-EAST, and asked to be given all NETCOM routes given to us from the RS. When I last checked, we were seeing clean information from our direct NETCOM peering, but, as I pointed out to Jessica Yu, there were some glaring problems with what the RS there was giving us. So, in my opinion, as far as a technology to keep routing information clean among big providers, the RSes aren't worthwhile at this time. As far as a technology to keep routing information clean between big providers and small providers at a peering point, imho that is a matter for bilateral agreements and other peer-to-peer and public pressures. The only thing I see as potentially useful with the RSes, unfortunately, is the possibility of working on a solution to The Big Problem, which is keeping routing symmetrical between any two big providers peering at lots and lots of peering points. I see the primary use of a fully populated RADB as a tool for debugging. The fact that you see it as a tool for configuring your network is simply interesting. Sean.
When I last checked, we were seeing clean information from our direct NETCOM peering, but, as I pointed out to Jessica Yu, there were some glaring problems with what the RS there was giving us.
The case you refered here is that among the 300 netcom routes the RS passed to your router, several of them are not originated from Netcom. As we discussed before, this was due to the particular routes registered in the PRDB with incorrect or out dated AS origin field. E.g. one of the routes we looked at was 192.33.137/24. The PRDB shows the following: route: 192.33.137.0/24 descr: NETCOM On-line Communications Services, Inc. descr: 3031 Tisch Way descr: Mezzanine descr: San Jose descr: CA 95128, USA origin: AS2551 comm-list: COMM_NSFNET advisory: AS690 1:2551(147) 2:1321 mnt-by: MAINT-AS2551 changed: nsfnet-admin@merit.edu 941110 source: PRDB Note the field 'origin' here is AS2551 which is Netcom AS. While the BGP path shows AS Path: 2551 701 IGP. So there is an inconsistency here. Note, the data we used to test with you is from PRDB since RADB is not populated at this point (waiting for the community to register the information). Since the generation of AS690 configuration at this point does not rely on the AS origin filed, so not much effort being spent to clean up the data in this field. This actually brought an important point. That is, when ASs registering routes in RADB, please make sure the correct 'origin' field is registered and properly maintained. Also, it's important for ASs to start cleaning up the data in the PRDB especially the 'origin' field if they expect the data be transdered to RADB at some point. Second point is that your claim of Sprint seeing clean routes directly from Netcom could be flase because I believe Netcom advertises the same set of routes to you as to the RS. That means you get 192.33.137/24 from them as well unless Netcom applies a special exporting filtering when advertising routes to you. Just checked with Netcom engineer and they do not have special filtering with you. Please check at your router again or log the incomming advertisment from netcom to verify it. --Jessica
In message <m0s33hL-000301C@rip.psg.com>, Randy Bush writes: | 2 - The RADB has a lot of old, now obsolete, data maintained by others. Do | we have to ask each old maintainer to clean it out, or will it all be | cleaned up as the changeover settles down? | | 3 - SWIPs and 81ish objects (and NACRs, but they're going away, yes?) share | a non-trivial subset. Are there maintainers' tools for generating both | from a single database? If not, we will surely create errors of | consistency. This almost but not quite touches on what are (for me) the big questions of the RADB, which are, firstly, in the absence of really easy to use tools that keep router configurations and the RADB in sync, of what use is the RADB, other than as a "this is what things should have looked like a while ago" debugging tool or in the cases of ISPs who configure their routers from the RADB, the most likely reason for not being able to reach network X ("gee, they haven't updated the RADB and therefore you can't get there from here")? Secondly, if the RADB and the world's routers are all in sync, of what value is the RADB as something to protect the world from weird announcements? I don't know the answers to these, and they're not entirely rhetorical questions. | FYI, despite the lack of rigor, Sprint's has seemed (from the bottom of the | pond view) to be the most immediate and reliable over the many moons. Thanks, Randy. We're trying, despite massive screw ups from time to time (fat fingers Doran and so forth). | But the overwhelming problem with all avenues has been the NACR delay. I agree. Looking back at routing problems reported to us over the last several months in such a way that I saw them, the overwhelming majority has concerned the PRDB not being in sync with the rest of the world. The next largest number of routing problems had to do with customers' BGP peerings with SprintLink, and the bulk of those problems involved singly-homed customers. Sean.
Hank, Enduser filtering (CERN) is in principle completely different from what we (might if not possible else) do: I am not supposed to filter anything between meetpoints and customers, because I agree to some people who pay for it to provide Internet access. I would filter nothing at all (curretnly do filter nothing), which does not mean that my suport hosts and networks are open. Filtering comes alo into place when customers want only access between certain networks, but in general NSPs/ISPs are not supposed to filter at all. Routing is different. We filter routing updates (not access filters) to accelerate BGP convergence. We filter what we announce to the outside world (of course not all the trash we get in). That is not that fast paced changing data since the provider-provider structure is rather stable. And we don't need to nacr for each small 2 node attachment either, so I see no big workload there. Why must the NACR process be so responsive? Mike On Thu, 20 Apr 1995, Hank Nussbacher wrote:
On Wed, 19 Apr 1995 18:49:39 -0400 you said:
telent info.ripe.net to test it out.
RIPE database does not control the actual routing.
I'm not sure the current RADB project has any mention of real-time updates of gated from the database. `With dozens of updates we do every day it nearly as good as useless.
CERN (as an example) picks up my routing updates daily and builds its new access filter based on mine and others routing updates. I'm not sure you want realtime updates to the actual routing. In any event, it is an improvement over the time lag of NACR updates.
It should be secure.
I use a password on all AS updates to AS378.
You call *that* secure? We have way too many people who need to do changes for our AS-es. Check the contact list for AS1800.
You can assign as many users as you wish to control specific ASs. Currently it checks my email address and password. No match - and the maintainer of the AS gets a warning mail about the attempt to alter the routing within my AS - and I have gotten warning e-mails already. Adding in PGP authentication should not be too hard if it is not done already.
If i can't implement my existing policy, i cannot use RADB, ok?
(Well, we _will_ use it -- to talk to people whose announcements are loaded with garbadge). We simply cannot use it to talk to major service providers because policies in place cannot be represented in RIPE-81.
So speak to the authors and get it improved.
--vadim
Hank
-------------------------------------------------------------------------------- Michael F. Nittmann nittmann@wis.com Network Architect nittmann@b3.com B3 Corporation, Marshfield, WI (CIX Member) (715) 387 1700 xt. 158 US Cyber (SM), Washington DC (715) 573 2448 (715) 831 7922 --------------------------------------------------------------------------------
participants (7)
-
Craig Labovitz -
Curtis Villamizar -
Hank Nussbacher -
Jessica Yu -
Michael F. Nittmann -
randy＠psg.com -
Sean Doran