From Karsten.Koepp at lambdanet.net Wed Nov 7 13:55:01 2001 From: Karsten.Koepp at lambdanet.net (Koepp, Karsten) Date: Wed, 7 Nov 2001 13:55:01 +0100 Subject: FW: more specific routes in today reality Message-ID: <39F27E3F569FD4119EF200508BAF85B90197C38E@CCGNT30> Nurani, I was missing a RIPE NCC hostmaster statement to this e-mail. Sascha quoted a hostmaster. > -----Original Message----- > From: Sascha E. Pollok [mailto:sp at iphh.net] > Sent: Tuesday, October 09, 2001 12:33 PM > To: Gert Doering; Vladimir A. Jakovenko > Cc: lir-wg at ripe.net; routing-wg at ripe.net > Subject: Re: more specific routes in today reality > > "- If PI is requested for multi-homing please explain why > the second > provider cannot route PA space as a more specific > route (with the > PA block holder adding a more specific route too)." > > This was suggested from a RIPE NCC Hostmaster when sending a > PI-space req. This looks a little contrary to your opinion doesn't > it? > > Sascha > Has this been a mistake, or is this the default answer to PI requests sent to the NCC nowadays? Is the NCC seriously going to recommend this to the members? I don't recommend the use of PI to customers either, and I don't want to roll up the multi-homing discussion. But PI should remain provider- independent and PA should remain provider-aggregatable. Regards Karsten Sorry for the late posting in this thread... From vovik at lucky.net Wed Nov 7 14:34:09 2001 From: vovik at lucky.net (Vladimir A. Jakovenko) Date: Wed, 7 Nov 2001 15:34:09 +0200 Subject: FW: more specific routes in today reality In-Reply-To: <39F27E3F569FD4119EF200508BAF85B90197C38E@CCGNT30>; from Karsten.Koepp@lambdanet.net on Wed, Nov 07, 2001 at 01:55:01PM +0100 References: <39F27E3F569FD4119EF200508BAF85B90197C38E@CCGNT30> Message-ID: <20011107153409.Q50363@lucky.net> On Wed, Nov 07, 2001 at 01:55:01PM +0100, Koepp, Karsten wrote: >Nurani, > >I was missing a RIPE NCC hostmaster statement to this e-mail. >Sascha quoted a hostmaster. [..skipped..] > >> >> "- If PI is requested for multi-homing please explain why >> the second >> provider cannot route PA space as a more specific >> route (with the >> PA block holder adding a more specific route too)." >> >> This was suggested from a RIPE NCC Hostmaster when sending a >> PI-space req. This looks a little contrary to your opinion doesn't >> it? >> >> Sascha >> > >Has this been a mistake, or is this the default answer to PI requests >sent to the NCC nowadays? Is the NCC seriously going to recommend this >to the members? >I don't recommend the use of PI to customers either, and I don't want >to roll up the multi-homing discussion. But PI should remain provider- >independent and PA should remain provider-aggregatable. Quote from RFC1930, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", page 7: "With the introduction of aggregation it should be noted that a prefix may be represented as residing in more than one AS, however, this is very much the exception rather than the rule". Quote from RFC2725, "Routing Policy System Security", page 9: "Route objects may exist for the same prefix with multiple origin AS values due to common multihoming practice that does not require a unique origin AS". RFC1930, Category: Best Current Practice, March 1996 RFC2725, Category: Standards Track, Dec 1999 -- Regards, Vladimir. From Karsten.Koepp at lambdanet.net Wed Nov 7 15:48:20 2001 From: Karsten.Koepp at lambdanet.net (Koepp, Karsten) Date: Wed, 7 Nov 2001 15:48:20 +0100 Subject: FW: more specific routes in today reality Message-ID: <39F27E3F569FD4119EF200508BAF85B90197C395@CCGNT30> Vladimir, > -----Original Message----- > From: Vladimir A. Jakovenko [mailto:vovik at lucky.net] > Sent: Wednesday, November 07, 2001 2:34 PM > To: Koepp, Karsten > Cc: 'nurani at ripe.net'; 'lir-wg at ripe.net' > Subject: Re: FW: more specific routes in today reality > > > On Wed, Nov 07, 2001 at 01:55:01PM +0100, Koepp, Karsten wrote: > >Nurani, > > > >I was missing a RIPE NCC hostmaster statement to this e-mail. > >Sascha quoted a hostmaster. > [..skipped..] > > > >> > >> "- If PI is requested for multi-homing please explain why > >> the second > >> provider cannot route PA space as a more specific > >> route (with the > >> PA block holder adding a more specific route too)." > >> > >> This was suggested from a RIPE NCC Hostmaster when sending a > >> PI-space req. This looks a little contrary to your opinion doesn't > >> it? > >> > >> Sascha > >> > > > >Has this been a mistake, or is this the default answer to PI requests > >sent to the NCC nowadays? Is the NCC seriously going to > recommend this > >to the members? > >I don't recommend the use of PI to customers either, and I don't want > >to roll up the multi-homing discussion. But PI should remain > provider- > >independent and PA should remain provider-aggregatable. > > Quote from RFC1930, "Guidelines for creation, selection, and > registration > of an Autonomous System (AS)", page 7: > > "With the introduction of aggregation it should be noted that > a prefix may > be represented as residing in more than one AS, however, this > is very much > the exception rather than the rule". > RFC1930 does not know PA or PI address categories, just routes. > Quote from RFC2725, "Routing Policy System Security", page 9: > > "Route objects may exist for the same prefix with multiple > origin AS values > due to common multihoming practice that does not require a > unique origin AS". RFC2725 does mention PI, but not the case where PA addresses are being multi-homed. All I am saying is, regardless of whether we want this type of multi-homing or not, networks originating from different AS should use PI space. It does neither save a route nor address space to make pieces of a PA block multi-homed. It only binds the network to the provider assigning the PAs. That's why I was up-set. Still waiting for the NCC to answer... Karsten From he at uninett.no Wed Nov 7 15:51:30 2001 From: he at uninett.no (Havard Eidnes) Date: Wed, 07 Nov 2001 15:51:30 +0100 (CET) Subject: more specific routes in today reality In-Reply-To: <20011107153409.Q50363@lucky.net> References: <39F27E3F569FD4119EF200508BAF85B90197C38E@CCGNT30> <20011107153409.Q50363@lucky.net> Message-ID: <20011107.155130.49033624.he@uninett.no> > Quote from RFC1930, "Guidelines for creation, selection, and registration > of an Autonomous System (AS)", page 7: > > "With the introduction of aggregation it should be noted that a prefix may > be represented as residing in more than one AS, however, this is very much > the exception rather than the rule". > > Quote from RFC2725, "Routing Policy System Security", page 9: > > "Route objects may exist for the same prefix with multiple origin AS values > due to common multihoming practice that does not require a unique origin AS". > > RFC1930, Category: Best Current Practice, March 1996 > RFC2725, Category: Standards Track, Dec 1999 Just a point of clarification: that some text in a standards track RFC mentions a practice and permits that practice to be described, does not mean that the practice itself is standardized or recommended. But we all knew that already, right? Regards, - H?vard From gert at space.net Wed Nov 7 17:18:29 2001 From: gert at space.net (Gert Doering) Date: Wed, 7 Nov 2001 17:18:29 +0100 Subject: FW: more specific routes in today reality In-Reply-To: <39F27E3F569FD4119EF200508BAF85B90197C395@CCGNT30>; from Karsten.Koepp@lambdanet.net on Wed, Nov 07, 2001 at 03:48:20PM +0100 References: <39F27E3F569FD4119EF200508BAF85B90197C395@CCGNT30> Message-ID: <20011107171828.S59207@Space.Net> Hi, On Wed, Nov 07, 2001 at 03:48:20PM +0100, Koepp, Karsten wrote: > All I am saying is, regardless of whether we want this type of multi-homing > or not, networks originating from different AS should use PI space. It does > neither save a route nor address space to make pieces of a PA block > multi-homed. It only binds the network to the provider assigning the PAs. > That's why I was up-set. Whether or not an announcement is PI or PA has no influence on the number of routes visible in the global table. Using a sub-block from PA space has two advantages: - more flexible in block size (what if the customer comes back later and needs twice the space?) - more robust concerning filtering / dampening (the ISPs PA space will most likely be still visible, even if the sub-network is filtered somewhere) - if the customer goes away, the network can be given back and the route will disappear -> good for conservation *and* aggregation. The only benefit of PI is "you can keep your network if you change ISPs", which is convenient for the end customer but very expensive on the global routing system. This is why people actually ask for "stop handing out PI at all" (which I am *not* advocating here, but think about it). - and due to this pros and cons, which most people agree upon, the RIPE recommendations make sense. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 73128 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From Karsten.Koepp at lambdanet.net Wed Nov 7 17:55:44 2001 From: Karsten.Koepp at lambdanet.net (Koepp, Karsten) Date: Wed, 7 Nov 2001 17:55:44 +0100 Subject: FW: more specific routes in today reality Message-ID: <39F27E3F569FD4119EF200508BAF85B90197C39B@CCGNT30> Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert at space.net] > Sent: Wednesday, November 07, 2001 5:18 PM > To: Koepp, Karsten > Cc: 'Vladimir A. Jakovenko'; 'lir-wg at ripe.net' > Subject: Re: FW: more specific routes in today reality > > > Hi, > > On Wed, Nov 07, 2001 at 03:48:20PM +0100, Koepp, Karsten wrote: > > All I am saying is, regardless of whether we want this type > of multi-homing > > or not, networks originating from different AS should use > PI space. It does > > neither save a route nor address space to make pieces of a PA block > > multi-homed. It only binds the network to the provider > assigning the PAs. > > That's why I was up-set. > > Whether or not an announcement is PI or PA has no influence > on the number > of routes visible in the global table. What I said before. > Using a sub-block from PA space has two advantages: > > - more flexible in block size (what if the customer comes back later > and needs twice the space?) Means the customer has to renumber to a bigger network. Can be done. > - more robust concerning filtering / dampening (the ISPs PA > space will > most likely be still visible, even if the sub-network is filtered > somewhere) I admit this is an advantage. > - if the customer goes away, the network can be given back and the > route will disappear -> good for conservation *and* aggregation. I don't follow that this will decrease routes. > The only benefit of PI is "you can keep your network if you > change ISPs", > which is convenient for the end customer but very expensive > on the global > routing system. > > This is why people actually ask for "stop handing out PI at > all" (which > I am *not* advocating here, but think about it). > > - and due to this pros and cons, which most people agree > upon, the RIPE recommendations make sense. Gert, after all you are convincing. This means in turn, it would be conform to the rules to multi-home PA addresses and it just depends on the service providers co-operating to create the route objects. Is this really current practice? Where or when is this gonna be reflected in RIPE docs? Karsten Total number of questions concerning RIPE policies: 73128 > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 73128 > > SpaceNet AG Mail: netmaster at Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > From sabrina at ripe.net Thu Nov 8 15:56:23 2001 From: sabrina at ripe.net (Sabrina Waschke) Date: Thu, 08 Nov 2001 15:56:23 +0100 Subject: FW: more specific routes in today reality In-Reply-To: Message from "Koepp, Karsten" of "Wed, 07 Nov 2001 13:55:01 +0100." <39F27E3F569FD4119EF200508BAF85B90197C38E@CCGNT30> Message-ID: <200111081456.fA8EuNq30279@birch.ripe.net> The role of the RIPE NCC in this matter is to simply point out the different options, so that network operators can take them into account when requesting address space. It is the ISPs that decide what gets routed. The RIPE NCC has no influence on this. We will continue to assign PI address space unless the RIPE community revises this policy. However, if there are clear recommendations from the community, the RIPE NCC will certainly make these recommendations known to its members. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o "Koepp, Karsten" writes: * Nurani, * * I was missing a RIPE NCC hostmaster statement to this e-mail. * Sascha quoted a hostmaster. * * > -----Original Message----- * > From: Sascha E. Pollok [mailto:sp at iphh.net] * > Sent: Tuesday, October 09, 2001 12:33 PM * > To: Gert Doering; Vladimir A. Jakovenko * > Cc: lir-wg at ripe.net; routing-wg at ripe.net * > Subject: Re: more specific routes in today reality * * * > * > "- If PI is requested for multi-homing please explain why * > the second * > provider cannot route PA space as a more specific * > route (with the * > PA block holder adding a more specific route too)." * > * > This was suggested from a RIPE NCC Hostmaster when sending a * > PI-space req. This looks a little contrary to your opinion doesn't * > it? * > * > Sascha * > * * Has this been a mistake, or is this the default answer to PI requests * sent to the NCC nowadays? Is the NCC seriously going to recommend this * to the members? * I don't recommend the use of PI to customers either, and I don't want * to roll up the multi-homing discussion. But PI should remain provider- * independent and PA should remain provider-aggregatable. * * Regards Karsten * * Sorry for the late posting in this thread... * From gert at space.net Thu Nov 8 17:25:52 2001 From: gert at space.net (Gert Doering) Date: Thu, 8 Nov 2001 17:25:52 +0100 Subject: FW: more specific routes in today reality In-Reply-To: <39F27E3F569FD4119EF200508BAF85B90197C39B@CCGNT30>; from Karsten.Koepp@lambdanet.net on Wed, Nov 07, 2001 at 05:55:44PM +0100 References: <39F27E3F569FD4119EF200508BAF85B90197C39B@CCGNT30> Message-ID: <20011108172552.L59207@Space.Net> Hi, On Wed, Nov 07, 2001 at 05:55:44PM +0100, Koepp, Karsten wrote: [..] > > - if the customer goes away, the network can be given back and the > > route will disappear -> good for conservation *and* aggregation. > I don't follow that this will decrease routes. The assumption is that if the customer goes to a different ISP and is then only single-homed, his (new) network will then not have to be visible world-wide, and his "old" space can be returned to the old ISP. With PI, the space is "claimed forever" and will have to be visible forever, even if the customer is not multihomed any more. [..] > Gert, after all you are convincing. > This means in turn, it would be conform to the rules to multi-home PA > addresses and it just depends on the service providers co-operating > to create the route objects. This is how I understand "current rules" of consent. > Is this really current practice? People are doing it (we have been doing it in the past, and the fact that we're not doing it right now just means "we have no customers that match that particular solution"). People do much worse things (to rant for a while), like "announcing a /19 in individual /24's with different prepends/MEDs to get load- balancing" - look at what AS 1913 announces to see something really scary... :-( > Where or when is this gonna be reflected in RIPE docs? As Sabrina answered today, this is a conflict that has been there forever, in a way. RIPE can't tell people what's "legal" concerning BGP announcement and routing/filtering, so they don't. Even if it might be helpful to have a clear statement on what should be announced and what not ("RIPE are the network gods, they know/*make* the rules!"), the people that don't care today won't care then... > Total number of questions concerning RIPE policies: 73128 Oh, it's not *that* difficult :-) Basically "doing the reasonable thing with enough common sense" will usually not be too different from what's "legal according to policies". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 73128 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From hank at att.net.il Fri Nov 9 08:27:58 2001 From: hank at att.net.il (Hank Nussbacher) Date: Fri, 09 Nov 2001 09:27:58 +0200 Subject: RIPE-227? Message-ID: <4.3.2.7.2.20011109091956.00ac92e0@max.att.net.il> Does anyone know if the RIPE robot supports RIPE-227 templates? This fairly new template (Oct 2, 2001) for ASN requests. The robot saw it as of the 'RIPE147' type and then proceeded to flag as warnings: >-ANNOUNCED ADDRESS RANGES- > > >Warning #1 > >Template was not recognised and *not* processed. Please >check your spelling! > > >-PEERING CONTACTS- > > >Warning #2 > >Template was not recognised and *not* processed. Please >check your spelling! So either the template as listed in RIPE-227 is wrong or the robot is broken. Thanks, Hank From sabrina at ripe.net Fri Nov 9 17:37:21 2001 From: sabrina at ripe.net (Sabrina Waschke) Date: Fri, 09 Nov 2001 17:37:21 +0100 Subject: RIPE-227? In-Reply-To: Message from Hank Nussbacher of "Fri, 09 Nov 2001 09:27:58 +0200." <4.3.2.7.2.20011109091956.00ac92e0@max.att.net.il> Message-ID: <200111091637.fA9GbLq07793@birch.ripe.net> The robot doesn't recognize these two templates yet. This will be fixed. Thanks for reporting it, Hank. FYI: The RIPE NCC Database and Software Department are working on a whois library which will be able to parse and validate whois objects of any type - that will include multi-line fields, and strictly adhere to the internal format of the objects in the whois DB. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o Hank Nussbacher writes: * Does anyone know if the RIPE robot supports RIPE-227 templates? This * fairly new template (Oct 2, 2001) for ASN requests. The robot saw it * as of the 'RIPE147' type and then proceeded to flag as warnings: * * >-ANNOUNCED ADDRESS RANGES- * > * > * >Warning #1 * > * >Template was not recognised and *not* processed. Please * >check your spelling! * > * > * >-PEERING CONTACTS- * > * > * >Warning #2 * > * >Template was not recognised and *not* processed. Please * >check your spelling! * * So either the template as listed in RIPE-227 is wrong or the robot is broken * . * * Thanks, * Hank * * From hank at att.net.il Sat Nov 10 17:41:38 2001 From: hank at att.net.il (Hank Nussbacher) Date: Sat, 10 Nov 2001 18:41:38 +0200 Subject: RIPE-227? In-Reply-To: <200111091637.fA9GbLq07793@birch.ripe.net> References: <4.3.2.7.2.20011109091956.00ac92e0@max.att.net.il> Message-ID: <4.3.2.7.2.20011110183827.00aad720@max.att.net.il> At 17:37 09/11/01 +0100, Sabrina Waschke wrote: How then does one submit an ASN request without being trapped by the robot? -Hank >The robot doesn't recognize these two templates yet. This will be fixed. >Thanks for reporting it, Hank. > >FYI: >The RIPE NCC Database and Software Department are working on a whois >library which will be able to parse and validate whois objects of any >type - that will include multi-line fields, and strictly adhere to the >internal format of the objects in the whois DB. > >Kind regards, > >Sabrina Waschke > >-- > >o------------------------------------------o >| Sabrina Waschke sabrina at ripe.net | >| Registration Services Operations Manager | >| | >| RIPE NCC tel +31 20 535 4444 | >| www.ripe.net fax +31 20 535 4445 | >o------------------------------------------o > > Hank Nussbacher writes: > * Does anyone know if the RIPE robot supports RIPE-227 templates? This > * fairly new template (Oct 2, 2001) for ASN requests. The robot saw it > * as of the 'RIPE147' type and then proceeded to flag as warnings: > * > * >-ANNOUNCED ADDRESS RANGES- > * > > * > > * >Warning #1 > * > > * >Template was not recognised and *not* processed. Please > * >check your spelling! > * > > * > > * >-PEERING CONTACTS- > * > > * > > * >Warning #2 > * > > * >Template was not recognised and *not* processed. Please > * >check your spelling! > * > * So either the template as listed in RIPE-227 is wrong or the robot is > broken > * . > * > * Thanks, > * Hank > * > * From sabrina at ripe.net Mon Nov 12 12:51:36 2001 From: sabrina at ripe.net (Sabrina Waschke) Date: Mon, 12 Nov 2001 12:51:36 +0100 Subject: RIPE-227? In-Reply-To: Your message of Sat, 10 Nov 2001 18:41:38 +0200. <4.3.2.7.2.20011110183827.00aad720@max.att.net.il> References: <4.3.2.7.2.20011110183827.00aad720@max.att.net.il> Message-ID: <200111121151.fACBpaq14002@birch.ripe.net> Hank Nussbacher writes: * At 17:37 09/11/01 +0100, Sabrina Waschke wrote: * * How then does one submit an ASN request without being trapped by the * robot? -Hank The robot gives warnings and the request is passed on to a hostmaster for processing. This is mentioned in the automatic response by the RIPE NCC Automatic Hostmaster Robot. However, if you have an error in your request (e.g. a mandatory field is missing in a maintainer template) you should correct this before resubmitting the request. If you want to bypass the syntax checking robot after it is gone through the robot once and received error messages, you can do so by re-sending the request and putting the keyword "NOAUTO " in the subject of your mail (please include a space at the end of the keyword). Please don't hesitate to contact if you have any further questions. Regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o * >The robot doesn't recognize these two templates yet. This will be fixed. * >Thanks for reporting it, Hank. * > * >FYI: * >The RIPE NCC Database and Software Department are working on a whois * >library which will be able to parse and validate whois objects of any * >type - that will include multi-line fields, and strictly adhere to the * >internal format of the objects in the whois DB. * > * >Kind regards, * > * >Sabrina Waschke * > * >-- * > * >o------------------------------------------o * >| Sabrina Waschke sabrina at ripe.net | * >| Registration Services Operations Manager | * >| | * >| RIPE NCC tel +31 20 535 4444 | * >| www.ripe.net fax +31 20 535 4445 | * >o------------------------------------------o * > * > Hank Nussbacher writes: * > * Does anyone know if the RIPE robot supports RIPE-227 templates? This * > * fairly new template (Oct 2, 2001) for ASN requests. The robot saw it * > * as of the 'RIPE147' type and then proceeded to flag as warnings: * > * * > * >-ANNOUNCED ADDRESS RANGES- * > * > * > * > * > * >Warning #1 * > * > * > * >Template was not recognised and *not* processed. Please * > * >check your spelling! * > * > * > * > * > * >-PEERING CONTACTS- * > * > * > * > * > * >Warning #2 * > * > * > * >Template was not recognised and *not* processed. Please * > * >check your spelling! * > * * > * So either the template as listed in RIPE-227 is wrong or the robot is * > broken * > * . * > * * > * Thanks, * > * Hank * > * * > * * From hank at att.net.il Mon Nov 12 11:49:53 2001 From: hank at att.net.il (Hank Nussbacher) Date: Mon, 12 Nov 2001 12:49:53 +0200 Subject: RIPE-227? In-Reply-To: <200111091637.fA9GbLq07793@birch.ripe.net> References: <4.3.2.7.2.20011109091956.00ac92e0@max.att.net.il> Message-ID: <4.3.2.7.2.20011112124801.00a88e50@max.att.net.il> At 17:37 09/11/01 +0100, Sabrina Waschke wrote: >The robot doesn't recognize these two templates yet. This will be fixed. >Thanks for reporting it, Hank. So I stripped off the template tags and resubmitted and got back: >PLEASE NOTE: >This ticket has *NOT* been identified as a request for IP >addresses or AS numbers. >We will handle this message with lower priority than a request for IP >addresses / AS numbers. If your mail in fact is a request for IP >addresses / AS numbers, there are most likely missing / incorrect >fields in your mail. Please make sure to correct and complete your >request so that we can give it appropriate priority. So if I submit with ASN template tags, your robot flags it as an error and returns it. If I strip off the ASN tags then it gets sent to a lower priority queue. What is the magic sequence that will allow my ASN request to enter a normal queue? -Hank >FYI: >The RIPE NCC Database and Software Department are working on a whois >library which will be able to parse and validate whois objects of any >type - that will include multi-line fields, and strictly adhere to the >internal format of the objects in the whois DB. > >Kind regards, > >Sabrina Waschke > >-- > >o------------------------------------------o >| Sabrina Waschke sabrina at ripe.net | >| Registration Services Operations Manager | >| | >| RIPE NCC tel +31 20 535 4444 | >| www.ripe.net fax +31 20 535 4445 | >o------------------------------------------o > > Hank Nussbacher writes: > * Does anyone know if the RIPE robot supports RIPE-227 templates? This > * fairly new template (Oct 2, 2001) for ASN requests. The robot saw it > * as of the 'RIPE147' type and then proceeded to flag as warnings: > * > * >-ANNOUNCED ADDRESS RANGES- > * > > * > > * >Warning #1 > * > > * >Template was not recognised and *not* processed. Please > * >check your spelling! > * > > * > > * >-PEERING CONTACTS- > * > > * > > * >Warning #2 > * > > * >Template was not recognised and *not* processed. Please > * >check your spelling! > * > * So either the template as listed in RIPE-227 is wrong or the robot is > broken > * . > * > * Thanks, > * Hank > * > * From sabrina at ripe.net Tue Nov 13 12:50:13 2001 From: sabrina at ripe.net (Sabrina Waschke) Date: Tue, 13 Nov 2001 12:50:13 +0100 Subject: RIPE-227? In-Reply-To: Message from Hank Nussbacher of "Mon, 12 Nov 2001 12:49:53 +0200." <4.3.2.7.2.20011112124801.00a88e50@max.att.net.il> Message-ID: <200111131150.fADBoDq28074@birch.ripe.net> Hank, The robot has now been fixed and recognizes all templates when using the correct titles including the '#'. Please do *NOT* remove the template titles as presented on the request form(s). The robot will not recognize the form and set it to a lower priority. As I said in my previous message the robot gave a warning (not an error) for the templates #[ANNOUNCED ADDRESS RANGES]# and #[PEERING CONTACTS]# and the requests were immediately forwarded to a hostmaster for processing. Requests containing errors should be corrected and resent, the keyword NOAUTO can be used to bypass the robot. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina at ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o Hank Nussbacher writes: * At 17:37 09/11/01 +0100, Sabrina Waschke wrote: * * >The robot doesn't recognize these two templates yet. This will be fixed. * >Thanks for reporting it, Hank. * * So I stripped off the template tags and resubmitted and got back: * * >PLEASE NOTE: * >This ticket has *NOT* been identified as a request for IP * >addresses or AS numbers. * >We will handle this message with lower priority than a request for IP * >addresses / AS numbers. If your mail in fact is a request for IP * >addresses / AS numbers, there are most likely missing / incorrect * >fields in your mail. Please make sure to correct and complete your * >request so that we can give it appropriate priority. * * So if I submit with ASN template tags, your robot flags it as an error and * returns it. If I strip off the ASN tags then it gets sent to a lower * priority queue. What is the magic sequence that will allow my ASN request * to enter a normal queue? * * -Hank * * * * * >FYI: * >The RIPE NCC Database and Software Department are working on a whois * >library which will be able to parse and validate whois objects of any * >type - that will include multi-line fields, and strictly adhere to the * >internal format of the objects in the whois DB. * > * >Kind regards, * > * >Sabrina Waschke * > * >-- * > * >o------------------------------------------o * >| Sabrina Waschke sabrina at ripe.net | * >| Registration Services Operations Manager | * >| | * >| RIPE NCC tel +31 20 535 4444 | * >| www.ripe.net fax +31 20 535 4445 | * >o------------------------------------------o * > * > Hank Nussbacher writes: * > * Does anyone know if the RIPE robot supports RIPE-227 templates? This * > * fairly new template (Oct 2, 2001) for ASN requests. The robot saw it * > * as of the 'RIPE147' type and then proceeded to flag as warnings: * > * * > * >-ANNOUNCED ADDRESS RANGES- * > * > * > * > * > * >Warning #1 * > * > * > * >Template was not recognised and *not* processed. Please * > * >check your spelling! * > * > * > * > * > * >-PEERING CONTACTS- * > * > * > * > * > * >Warning #2 * > * > * > * >Template was not recognised and *not* processed. Please * > * >check your spelling! * > * * > * So either the template as listed in RIPE-227 is wrong or the robot is * > broken * > * . * > * * > * Thanks, * > * Hank * > * * > * * From huberman at gblx.net Tue Nov 13 16:41:22 2001 From: huberman at gblx.net (David R Huberman) Date: Tue, 13 Nov 2001 08:41:22 -0700 (MST) Subject: FreeIPdb Released Message-ID: Hello, As promised, Global Crossing API is pleased to announce the release of FreeIPdb Version 1.0 at: http://www.freeipdb.org FreeIPdb is an open-source suite of tools allowing you to manage your IPv4 and IPv6 address space and address space assignments in the most efficient manner possible. Future versions will incorporate RWHOIS, SWIP, and inetnum capabilities. Enjoy the tools and please subscribe to the mailing lists for support and to provide us feedback. /david *--------------------------------* | Global Crossing API | | Manager, Global IP Addressing | | (703) 627-5800 | | huberman at gblx.net | *--------------------------------* From ncc at ripe.net Wed Nov 14 17:06:56 2001 From: ncc at ripe.net (RIPE NCC Document Announcement Service) Date: Wed, 14 Nov 2001 17:06:56 +0100 Subject: New/Revised Document available: "Guidelines for Setting up a Local Internet Registry at the RIPE NCC" Message-ID: <200111141606.fAEG6uq05431@birch.ripe.net> New/Revised RIPE Document Announcement -------------------------------------- A new/revised document is available from the RIPE document store: "Guidelines for Setting up a Local Internet Registry at the RIPE NCC" (ripe-230) Short content description ------------------------- The "Guidelines for Setting up a Local Internet Registry at the RIPE NCC" aims to provide the necessary information for those who are considering setting up a Local Internet Registry (LIR) with the RIPE NCC. In this document, some initial guidelines are given on which organisations usually set up an LIR. Further, the steps necessary to set up an LIR are described. Finally, the RIPE NCC IP address allocation and assignment policies are discussed. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-230.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-230.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-230 is available from the WWW at the following URL: http://www.ripe.net/docs/new-lir.html From marck at rinet.ru Thu Nov 15 19:00:47 2001 From: marck at rinet.ru (Dmitry Morozovsky) Date: Thu, 15 Nov 2001 21:00:47 +0300 (MSK) Subject: New/Revised Document available: "Guidelines for Setting up a Local Internet Registry at the RIPE NCC" In-Reply-To: <200111141606.fAEG6uq05431@birch.ripe.net> Message-ID: <20011115205528.L68665-100000@woozle.rinet.ru> Hello there colleagues, it seems NCC's Majordomo don't allow documents of about 50k to pass, so here is modified version. On Wed, 14 Nov 2001, RIPE NCC Document Announcement Service wrote: RNDAS> New/Revised RIPE Document Announcement RNDAS> -------------------------------------- RNDAS> A new/revised document is available from the RIPE document store: RNDAS> RNDAS> "Guidelines for Setting up a Local Internet Registry at the RIPE RNDAS> NCC" (ripe-230) [snip] I've made some kind of "unified diff" between old and new documents. I'd tried to eliminate trivial changes such as "a LIR" -> "an LIR". after '@@' there are chapter names. Also, it seems to me that some small amounts of data had been lost -- some words enclosed in angle brackets and looking like sgml/html tags. Hope this would be useful. [ Here was the attachment; Now it is published at ftp://ftp.cronyx.ru/pub/misc/ripe-212-230.diff.txt ] Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru *** ------------------------------------------------------------------------ From p.mujta at cdp.pl Sat Nov 17 21:11:10 2001 From: p.mujta at cdp.pl (Przemyslaw Mujta) Date: Sat, 17 Nov 2001 21:11:10 +0100 Subject: Question about more specific route. Message-ID: <3BF6C45E.7030001@cdp.pl> hello, I have question - what is about announcing PA assignment /24 from example AS1 to AS2 where AS2 maintain PA allocation /16 ? Should I always ask AS2 maintainer whitch give me PA assignmet about aprove announcing my assignment to other AS ? Maybe some RIPE documents describe with details case about announce from AS prefix like more specific route whitch are assignment example from other ISP. best regards, -- Przemyslaw Mujta PM452-RIPE master network administrator +48 22 8606707 Crowley Data Poland From bortzmeyer at gitoyen.net Sun Nov 18 21:46:02 2001 From: bortzmeyer at gitoyen.net (Stephane Bortzmeyer) Date: Sun, 18 Nov 2001 21:46:02 +0100 Subject: Question about more specific route. In-Reply-To: <3BF6C45E.7030001@cdp.pl> (Przemyslaw Mujta 's message of Sat, 17 Nov 2001 21:11:10 +0100) Message-ID: <200111182046.VAA00468@ludwigV.sources.org> On Saturday 17 November 2001, at 21 h 11, Przemyslaw Mujta wrote: > I have question - what is about announcing PA assignment /24 from > example AS1 to AS2 where AS2 maintain PA allocation /16 ? If I parse correctly the above sentence, it is OK, but you'll need to be sure that AS2 modified its filters accordingly. Most LIR filter out announcements of their own allocations from other AS. > Should I always ask AS2 maintainer whitch give me PA assignmet about > aprove announcing my assignment to other AS ? Maybe some RIPE documents > describe with details case about announce from AS prefix like more > specific route whitch are assignment example from other ISP. I don't think it is RIPE's business, it is a matter between AS 1 and AS 2. Just be sure this agreement is recorded in the RIPE database (a route object, at least) or you may be filtered out by third parties. Could you explain a bit more, with drawings? I understand that you want AS2 to have x.y.0.0/16 allocated, x.y.z.0/24, assigned to AS1, which will announce it to AS2 and may be to other AS. Am I correct? From meeting at ripe.net Tue Nov 20 15:48:51 2001 From: meeting at ripe.net (RIPE NCC Meeting Registration) Date: Tue, 20 Nov 2001 15:48:51 +0100 Subject: RIPE-41 announcement Message-ID: <200111201448.fAKEmpq20374@birch.ripe.net> Dear Colleagues, It is our pleasure to open registration for the RIPE 41 meeting, to be held from 14th January - 18th January 2002 at hotel Krasnapolsky in Amsterdam, The Netherlands. More information about this meeting and accommodations can be found on this page: http://www.ripe.net/ripe/meetings/current/ripe-41/ Online registration will open on Monday 19th November 2001 and close on Friday 4th January 2002. On-site registration will open on Monday 14th January 2002. Please note the following: To avoid waiting queues at the registration desk on-site we encourage pre-payment by credit card. The registration fee for this meeting is EUR 350.00 (this includes refreshments and lunches) and the dinner fee is EUR 65.00. However, if payment is received before 4 January 2002, the pre-payment cut-off date, you will receive a pre-registration discount of EUR 50.00. Therefore, the fee for attendees paying before the cut-off date is EUR 300.00 for the meeting and 65.00 EUR for the RIPE dinner event. Confirmation of Registration: For your convenience you can register using our secure website at: https://www.ripe.net/cgi-bin/mtgreg (encrypted form) http://www.ripe.net/cgi-bin/mtgreg (non-encrypted form) If you still prefer not to send your credit card number using an encrypted transfer method, we have prepared a fax form. This form is attached to the acknowledgment of your registration. You will receive a second acknowledgment by e-mail as soon your payment has been processed. In addition, you will find the receipt for your payment in your conference envelope. Participants requiring a visa to enter The Netherlands are advised to begin the required procedures as soon as possible. The RIPE Meeting organizers are pleased to provide letters of invitation to those attendees requiring them. Should you have any further questions, please do not hesitate to contact us at . Dear Colleagues, It is our pleasure to open registration for the RIPE 41 meeting, to be held from 14th January - 18th January 2002 at hotel Krasnapolsky in Amsterdam, The Netherlands. More information about this meeting and accommodations can be found on this page: http://www.ripe.net/ripe/meetings/current/ripe-41/ Online registration will open on Monday 19th November 2001 and close on Friday 4th January 2002. On-site registration will open on Monday 14th January 2002. Please note the following: To avoid waiting queues at the registration desk on-site we encourage pre-payment by credit card. The registration fee for this meeting is EUR 350.00 (this includes refreshments and lunches) and the dinner fee is EUR 65.00. However, if payment is received before 4 January 2002, the pre-payment cut-off date, you will receive a pre-registration discount of EUR 50.00. Therefore, the fee for attendees paying before the cut-off date is EUR 300.00 for the meeting and 65.00 EUR for the RIPE dinner event. Confirmation of Registration: For your convenience you can register using our secure website at: https://www.ripe.net/cgi-bin/mtgreg (encrypted form) http://www.ripe.net/cgi-bin/mtgreg (non-encrypted form) If you still prefer not to send your credit card number using an encrypted transfer method, we have prepared a fax form. This form is attached to the acknowledgment of your registration. You will receive a second acknowledgment by e-mail as soon your payment has been processed. In addition, you will find the receipt for your payment in your conference envelope. Participants requiring a visa to enter The Netherlands are advised to begin the required procedures as soon as possible. The RIPE Meeting organizers are pleased to provide letters of invitation to those attendees requiring them. Should you have any further questions, please do not hesitate to contact us at . Kind regards, Asha Raghoebarsing RIPE Meeting Co-ordinator