- NANOG - lists.nanog.org

subscribe
by zhouws＠ns.bta.net.cn 09 Jun '95

09 Jun '95

subscribe zhouws(a)ns.bta.net.cn

1 0

AS690 use of multiple routing registries
by Steve Heimlich 06 Jun '95

06 Jun '95

Folks, This note outlines changes to the ANS AS690 use of various registries which comprise the Internet Routing Registry (IRR). [RIPE gang, please forward to your mailing lists as appropriate]. Currently, the IRR consists of the following four well-known registries: the RADB, the CA*Net registry, the MCI registry, and the RIPE registry. AS690, to date, has relied exclusively on the RADB for generation of its configurations. As a result, those organizations which would naturally register in the MCI, CA*Net, or RIPE registries have been making redundant registrations in the RADB to ensure connectivity with ANS. This redundant registration has been inconvenient for many, and leads to multiple copies of route objects with inconsistent attributes. As of next week, ANS will begin to use route objects from the CA*Net, MCI, and RIPE routing registries. In order to do this, we will first create an ANS registry (containing customers of ANS) with "source: ANS" as its distinguishing attribute. Beginning with next Wednesday's AS690 config run (changed from Tuesday due to the U.S. Memorial Day holiday), we will prefer routes with AS690 advisories from these registries in the following order: ANS, CA*Net, MCI, and the RADB. Once we verify that this has succeeded, we will include the RIPE registry ahead of the RADB on next Friday's config run (i.e., ANS, CA*Net, MCI, RIPE, RADB). This method for config generation will eliminate the need for multiple registrations of singly-homed routes. Toward the end of June, we expect to have software running which will eliminate the use of AS690 advisories. This software generates an initial policy first by using registered advisories (a one-time operation). Currently, this results in a 16,000 line aut-num object for AS690. As this is somewhat unreasonable, we will be reducing the number of per-network exceptions in favor of one policy per home AS. As we approach the deployment of this capability, we will be working with peer providers on arranging mutually acceptable policies with AS690. Steve

2 2

nanog notes for May 1995 meeting status
by sob＠academ.com 04 Jun '95

04 Jun '95

All the notes I took are now on line and available. I have not plugged in the speakers slides yet. That is next. Let me know if you find I have omitted something important in my notes that was not caputured on the slides. Let me know if I have something wrong. Thanks -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: bcm!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

more on nanog notes
by sob＠academ.com 04 Jun '95

04 Jun '95

The notes on Bill's talk that he sent to the list are now html-ized on the notes page at http://www.academ.com/nanog/may1995/index.html -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: bcm!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

NANOG notes
by sob＠academ.com 02 Jun '95

02 Jun '95

The agenda page with all the mailto's is up at the URL: http://www.academ.com/nanog/may1995 More to come!

1 0

Re: AS690 use of multiple routing registries
by Vadim Antonov 27 May '95

27 May '95

How about just doing like all other ISPs do? I.e. do policy at as-path level w/o the benefit of RADB. You don't need any new software to do that, and can do that right tomorrow. As it is now the ANS's policy to use RADB data to filter incoming routing updates generates about 60% of our trouble tickets, which is particularly aggravated by the fact that in most cases the resolution is completely outside of our control (like in case of AS 1800). IMO RADB already created more troubles than it will ever help to fix. I see no particluar reason for Sprint to spend any resources on keeping ANS's exterior routing sane. So do not expect "advisory: AS690" from us. Of course, (as ICM _has_ AUP) we can always start demanding NACRs from ANS. Just to make people who make decisions there to wake up. --vadim To: nanog(a)merit.edu Subject: AS690 use of multiple routing registries Date: Fri, 26 May 1995 16:44:47 -0400 From: Steve Heimlich <heimlich(a)ans.net> Status: R Folks, This note outlines changes to the ANS AS690 use of various registries which comprise the Internet Routing Registry (IRR). [RIPE gang, please forward to your mailing lists as appropriate]. Currently, the IRR consists of the following four well-known registries: the RADB, the CA*Net registry, the MCI registry, and the RIPE registry. AS690, to date, has relied exclusively on the RADB for generation of its configurations. As a result, those organizations which would naturally register in the MCI, CA*Net, or RIPE registries have been making redundant registrations in the RADB to ensure connectivity with ANS. This redundant registration has been inconvenient for many, and leads to multiple copies of route objects with inconsistent attributes. As of next week, ANS will begin to use route objects from the CA*Net, MCI, and RIPE routing registries. In order to do this, we will first create an ANS registry (containing customers of ANS) with "source: ANS" as its distinguishing attribute. Beginning with next Wednesday's AS690 config run (changed from Tuesday due to the U.S. Memorial Day holiday), we will prefer routes with AS690 advisories from these registries in the following order: ANS, CA*Net, MCI, and the RADB. Once we verify that this has succeeded, we will include the RIPE registry ahead of the RADB on next Friday's config run (i.e., ANS, CA*Net, MCI, RIPE, RADB). This method for config generation will eliminate the need for multiple registrations of singly-homed routes. Toward the end of June, we expect to have software running which will eliminate the use of AS690 advisories. This software generates an initial policy first by using registered advisories (a one-time operation). Currently, this results in a 16,000 line aut-num object for AS690. As this is somewhat unreasonable, we will be reducing the number of per-network exceptions in favor of one policy per home AS. As we approach the deployment of this capability, we will be working with peer providers on arranging mutually acceptable policies with AS690. Steve

1 0

How to Delete Objects from the RADB
by Brian Renaud 26 May '95

26 May '95

A number of you have had problems when you tried to delete an object from the RADB. Here is a brief tutorial on the subject. If you have additional questions, please send a note to db-admin(a)ra.net. -Brian How to Delete Objects from the RADB Internet Service Providers (ISPs) and network operators will often need to delete Route objects, AS objects, or Maintainer objects from the RADB. You'll need to delete a Route object (and submit a new one), for example, if: --You are changing ISPs and need to change the origin AS (Home AS) for your route --You are no longer using a particular route prefix --You are moving to a larger aggregate and want to delete a more specific prefix If you want to change any of the following attributes, you'll first need to delete the object, and then re-submit the corrected one: Object Field ----- ----- Route route: origin: AS aut-num: Maintainer mntner: Follow these instructions to delete an object from the RADB: 1. Use the whois tool to get a copy of the object exactly as it currently exists in the registry. Put the object in a temporary file. For example: whois -h whois.ra.net 10.1.2.0/24 > temp 2. Edit the 'temp' file you've created. If the file contains more than one object, remove the extra objects so that only the object or objects you want to delete remain. 3. Do not change any lines in the object(s) you want to delete. Simply append a line such as the following to the objects: delete: user(a)your.net <reason for the deletion> To delete more than one object, append a 'delete:' line to each object and separate each object by a blank line. Your 'temp' file might then look like this: route: 10.1.2/24 descr: Example-NET origin: AS0 mnt-by: AS0-MNT changed: pern@Example-NET 950525 source: RADB delete: user(a)your.net prefix no longer used route: 10.1.3/24 descr: Example-NET origin: AS0 comm-list: COMM_NSFNET advisory: AS690 1:701(136) 2:701(134) 3:1800 mnt-by: AS0-MNT changed: pern@Example-NET 950525 source: RADB delete: user(a)your.net prefix no longer used 4. Submit the object to auto-dbm(a)ra.net. For example: mail auto-dbm(a)ra.net < temp If you have further questions about deleting RADB objects, send e-mail to db-admin(a)ra.net.

2 1

Re: How to Delete Objects from the RADB
by Selina Priestley 25 May '95

25 May '95

This is very nice. Thanks! I think it's important to note specifically that the changed: attribute cannot be altered either in order for a delete to be accepted, since this is counter-intuitive for some folks (uh, me ;-). Selina > > A number of you have had problems when you tried to delete an object > from the RADB. Here is a brief tutorial on the subject. If you > have additional questions, please send a note to db-admin(a)ra.net. > > -Brian > > > How to Delete Objects from the RADB > > Internet Service Providers (ISPs) and network operators will often need > to delete Route objects, AS objects, or Maintainer objects from the > RADB. You'll need to delete a Route object (and submit a new one), for > example, if: > > --You are changing ISPs and need to change the origin AS (Home AS) for > your route > --You are no longer using a particular route prefix > --You are moving to a larger aggregate and want to delete a more > specific prefix > > If you want to change any of the following attributes, you'll first need > to delete the object, and then re-submit the corrected one: > > Object Field > ----- ----- > Route route: > origin: > AS aut-num: > Maintainer mntner: > > Follow these instructions to delete an object from the RADB: > > 1. Use the whois tool to get a copy of the object exactly as it currently > exists in the registry. Put the object in a temporary file. For > example: > > whois -h whois.ra.net 10.1.2.0/24 > temp > > 2. Edit the 'temp' file you've created. If the file contains more than > one object, remove the extra objects so that only the object or > objects you want to delete remain. > > 3. Do not change any lines in the object(s) you want to delete. Simply > append a line such as the following to the objects: > > delete: user(a)your.net <reason for the deletion> > > To delete more than one object, append a 'delete:' line to each object > and separate each object by a blank line. Your 'temp' file might then > look like this: > > route: 10.1.2/24 > descr: Example-NET > origin: AS0 > mnt-by: AS0-MNT > changed: pern@Example-NET 950525 > source: RADB > delete: user(a)your.net prefix no longer used > > route: 10.1.3/24 > descr: Example-NET > origin: AS0 > comm-list: COMM_NSFNET > advisory: AS690 1:701(136) 2:701(134) 3:1800 > mnt-by: AS0-MNT > changed: pern@Example-NET 950525 > source: RADB > delete: user(a)your.net prefix no longer used > > 4. Submit the object to auto-dbm(a)ra.net. For example: > > mail auto-dbm(a)ra.net < temp > > If you have further questions about deleting RADB objects, send e-mail > to db-admin(a)ra.net. >

1 0

Re: CIX doing registries?? Just say no!
by Bob Collet 25 May '95

25 May '95

> As I mentioned at the nanog conference, I would very much like to > have registries where we _pay_ for the registration services; the > idea being that paying for the service will result in much better > service. I also mentioned that I would like such registries to > be non-for-profit, and that I would rather CIX stay the hell away > from registries. > > Why am I against CIX? Registries delegate authority over two > different kinds of things: domain names and IP addresses [and AS > numbers too]. > The former have almost no value prior to registration, the latter > have value wether or not they are being used. Either way NICs perform > the service of the delegating authority over domain names and IP > addresses; what they don't do is evaluate the market value of the > domain names and IP addresses they hand out, and _that_ is what I worry > an outfit like CIX might be tempted to do. It wouldn't be too bad if > we had to pay market prices for IP addresses and domain names, but > CIX might not have to pay market prices for the right to > delegate authority either; I don't want to see a huge scam here... > In the old White Paper we were proposing that any surplus funds go to places like ISOC/IETF. Surplus funds, that is surplus over cost of operations, would me minimzed by a board of some type. I am sorry you feel we'd scam you. In any case, the White Paper did its job by acting as a catalyst for further movement with the result being Paul and Jerry's Internet registration Tool Set proposal. > How would CIX determine the fees that we're to pay them for > their registration services?? In response to their members' questions > as to what they (the members) would get [for their fees being spent > on this project] that non-CIX-members woudln't, Paul and Jerry > mumbled something about a two-tiered service pricing scheme where > CIX members would get lower fees. Am I the only one bothered by this? > I think they might have been referring to the tool set. > And _what_ is CIX going to give _who_ in exchange for the > right/responsibility of delegating authority over the Class C space > lying at 207.*.*.* and beyond?? And what would they then charge for > the service of assigning these to ISP's [and whoever else]?? > > Mind you, I don't want to see IP address space auctions like > the electromagnetic spectrum auctions the FCC has been carrying out... > I think that careful delegation, will give us enough time to get to > the point where the older IP assignments can be redone (i.e. when > people renumber) or to when IPv6 can be deployed (which opens up a > whole new wonderful can of worms. My proposal is that a > non-for-profit organization free of conflicting interests (like > the members vs. > non-members problem CIX has) take over the InterNIC's > registry responsibilities. In the old White paper the goal was for the CIX to simply act as a clearing house where the actual registries that customers would deal with operate at ISP level. Therefore, I fail to see the conflict of interest. In any case, as described above, the immediate problem is with the current state of support tools, and that is where we think we should be focusing our attention. Any advise on this matter would be appreciated. The bottom line is to do what's right and what's needed for the ISP community. Thanks Bob Collet Preident, CIX > > Which would be the best forum to discuss these matters? > > Nick >

1 0

Re: Gentle Reminder about NANOG
by bmanning＠ISI.EDU 25 May '95

25 May '95

> > Please send me a summary of your remarks from Tuesday's discussions prior to > 9:15am concerning RFC 1797 and OPS review of IETF documentation. > OPS review: With the increasing number of RFCs and drafts that have a direct impact on operations, the question was asked if a true operations forum like NANOG would be willing to function as a review board. It was noted that there have been efforts in the past to address this issue, within the Operations Area of the IETF, which met with some difficulties. It was suggested that the IESG be approached regarding a modification of the standard RFC template to include a operational impact statement, much like the security impact bullet. Bill Manning has taken the action item to do just that. He has asked the IETF OPS AD for input and will talk to the RFC editor when she returns, about making this suggestion at the next IESG meeting. There are some hopes that if there is progress in this area that operators will actually spend time reviewing drafts prior to publication with an eye to the impact the proposed changes will have on operations. RFC 1797 status: RFC 1797 is authorization to test for problems in a distributed class A, before the IANA begins delegation of CIDR blocks in the traditional class A space. Every owner of an AS number has the subnet 39.<AS & 0x7fff>.0/24. The assignment is temporary, and lasts until 951131. There are currently 12 providers with registered delegations. The inital test is to be able to support your own in-addr domain from the primary server. There are currently some reachability problems, since some providers are blocking /24 nets. Current both cisco and gated code is being tested. Bay Networks may be involved soon. There are a few hosts currently on-net that are not ciscos: in-addr.ep.net anka.stupi.se exp39.ripe.net postel.wind.surfnet.nl Other hosts should be brought on-net and some interesting services should be hosts on them. It is likely that one or more root name servers will be moved and at least one ftp and web server may make the change. Two of the lessons learned so far: - Conversion to classless EGP is mandatory (BGP4 is your choice) and conversion to a classless IGP is mandatory. This last is not generally recognized and may be the cause of significant problems in 1996 unless there is action taken NOW. - cisco users need to add the following: "ip classless" to their configs. There has been set up a mailing list to coordinate and discuss this experiment: exp39(a)isi.edu. Send to exp39-request(a)isi.edu to join. --bill

1 0