Proposed change 2004.1: extended route creation rules
- Previous message (by thread): Proposed change 2004.1: extended route creation rules
- Next message (by thread): Proposed change 2004.1: extended route creation rules
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Engin Gunduz
engin at ripe.net
Mon Feb 16 16:52:44 CET 2004
Hi, On 2004-02-09 22:29:37 +0100, Frank Bohnsack wrote: > Hi, > > > -----Original Message----- > > From: routing-wg-admin at ripe.net [mailto:routing-wg-admin at ripe.net]On > > Behalf Of Joao Damas > > Sent: Monday, February 09, 2004 3:55 PM > > To: Engin Gunduz > > Cc: routing-wg at ripe.net; db-wg at ripe.net; Frank Bohnsack > > Subject: Re: Proposed change 2004.1: extended route creation rules > > ... > > if this is, as stated, a rare event, would it not be better to have > > this be dealt with via a request to ripe-dbm? > > You can implement a Perl snippet that does the checks you describe > > without polluting the general DB code with what feels like a kludge. > > Thats probably right for the moment and as far as I can remember this > came to pass maybe 10 or 15 times in the last 2 years (for AS702). Hm, this is more than I expected in fact (10-15 cases for a single ASN) even if this is a quite big autonomous system. I remember dealing with one of these, but have you sent the others to ripe-dbm at ripe.net as well, or just gave up trying to create them (as it would take ripe-dbm some time to figure out what's going on;)). Is there anybody else in the mailing lists who encountered similar cases? Regards, -engin Engin Gunduz RIPE NCC Software Engineering Department > I think this will be more and more important in the near future and > we should be prepared for it. Further I believe it would increase the > user acceptance of routing registries and push tools such as IRRToolSet. > > Frank > > > > > Joao > > > > On 9 Feb, 2004, at 15:07, Engin Gunduz wrote: > > > > > > > > Dear colleagues, > > > > > > [apologies for duplicate mails] > > > > > > Some time ago, Frank brought an issue regarding route object > > > aggregation to our attention in the DB-WG mailing list. Please > > > see the short thread at: > > > > > > http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00474.html > > > http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00475.html > > > > > > We have prepared a proposal to extend the route object creation > > > rules to resolve this issue. However, the resulting proposal > > > turns out to be quite complex as it builds on the current route > > > object creation rules, which are already complex enough. > > > > > > Considering that the need for route object aggregation is encountered > > > very rarely, it might not be worth implementing it. After the > > > deployment of version 3 of our whois software, we have seen only a > > > couple of such cases. In those cases, we have resolved the issue by > > > applying the rules that we specify below manually. > > > > > > I would like to ask the working groups if they think this proposal > > > is too complex. Implementing it would not be a problem technically, > > > but I'm more concerned about explaining the complex rules properly > > > to the users of the whois database. > > > > > > Best regards, and thanks for your time, > > > -- > > > Engin Gunduz > > > RIPE NCC Software Engineering Department > > > > > > > > > ============================================================= > > > A PROPOSAL FOR EXTENDED ROUTE OBJECT CREATION RULES > > > > > > This document is about being able to create route objects that > > > aggregate inetnums/route objects. This is needed where a user > > > cannot merge two or more inetnum objects into one larger inetnum > > > object, but still needs to create a route object that aggregates > > > these inetnum objects. This is seen especially with assigned PI > > > inetnum objects. > > > A hypothetical example: Suppose there exist the following two > > > inetnums in the whois database: > > > > > > inetnum: 12.0.0.0 - 12.0.0.255 > > > netname: EXAMPLE-PI > > > descr: Example Banking PLC > > > admin-c: AA1-RIPE > > > status: ASSIGNED PI > > > > > > inetnum: 12.0.1.0 - 12.0.1.255 > > > netname: ANOTHER-EXAMPLE-PI > > > descr: Anotherexample Printing Industries NV > > > admin-c: ZZ1-RIPE > > > status: ASSIGNED PI > > > > > > These are assigned to different end-users. Further suppose that > > > they coincidentally take service from the same Internet Service > > > Provider. The Internet Service Provider will want to aggregate these > > > two assignments into a single 12.0.0.0/23 route to be announced, > > > rather than announcing two separate prefixes, in order to keep the > > > number of prefixes in routing tables to the minimum. However, the > > > Internet Provider will not be able to create a single route object in > > > the RIPE Routing Registry which implements RPSSec RFC (RFC2725). This > > > is because the inetnum object that contains the 12.0.0.0/23 prefix > > > will be > > > > > > inetnum: 12.0.0.0 - 12.9.255.255 > > > netname: EU-ZZ-000000 > > > descr: block for PI assignments > > > descr: maintained by RIPE NCC > > > country: EU > > > remarks: These addresses are assigned > > > to network operators. The RIPE NCC > > > does not operate any networks using > > > address space from this block. > > > An explanation of how to find the > > > correct contacts is available at > > > <http://www.ripe.net/nicdb.html> > > > admin-c: CREW-RIPE > > > tech-c: CREW-RIPE > > > tech-c: OPS4-RIPE > > > status: ALLOCATED PI > > > mnt-by: RIPE-NCC-HM-MNT > > > mnt-lower: RIPE-NCC-HM-MNT > > > changed: hostmaster at ripe.net 20030731 > > > source: RIPE > > > > > > Note the "mnt-lower:" attribute that has RIPE-NCC-HM-MNT. > > > See http://www.ripe.net/ripencc/faq/database/qa4.html#5 for > > > a graphical representation of the current route object creation rules. > > > > > > Proposal: > > > To address this problem, we need to extend the route object creation > > > rules > > > so that it would be possible to create a route object that takes its > > > authorisation from a collection of route and/or inetnum objects that > > > are > > > more specific than the route object to be created. As the situation is > > > quite rare, the 'extended' behaviour can be activated by using the > > > keyword > > > 'EXTENDED-ROUTE-CREATION' in the subject line of the update message or > > > with > > > the syncupdates. The extended behaviour is not the default behaviour. > > > > > > The Algorithm: > > > The proposed algorithm to authorise the route object creation is: > > > > > > Check if the keyword was used. If not, proceed with normal route > > > creation rules > > > as described in RFC2725 > > > (http://www.ripe.net/ripencc/faq/database/qa4.html#5) > > > Check if there is an exact match route object or an exact match > > > inetnum object > > > If there is one, then proceed with normal route creation rules > > > even if the > > > keyword was specified. > > > Find the inetnums/routes that can be used for route creation: > > > Get a list of all inetnums and route objects that are one level > > > more > > > specific than the route object to be created. (-r > > > -Troute,inetnum -m <prefix>) > > > From this list, eliminate the inetnums that have exact match or > > > less specific > > > route objects. (Note: During route object creation, the > > > existing route > > > objects take precedence over existing inetnum objects). > > > Check if the resulting set of inetnums/routes cover the whole > > > space of > > > the route to be created. If not, authorisation fails, hence > > > creation attempt > > > fails. > > > Collect the mntners to be used during the authorisation check. > > > Follow these > > > rules: > > > For each object in the set, check if there are "mnt-routes:" > > > attributes in > > > the object. If there are, they will be used. If there are > > > not, the mntners > > > that are mentioned in "mnt-by:" attributes will be used. > > > Check the authorisation: During the authorisation, the mntners > > > in the same object > > > will be ORed, while the mntners in separate objects will be > > > ANDed. > > > > > > > > > Example 1: > > > > > > Suppose we have these inetnums in the database: > > > > > > inetnum: 0.0.0.0 - 255.255.255.255 > > > status: ALLOCATED UNSPECIFIED > > > mnt-by: RIPE-NCC-HM-MNT > > > mnt-lower: RIPE-NCC-HM-MNT > > > mnt-routes: RIPE-NCC-NONE-MNT > > > > > > inetnum: 12.0.0.0 - 12.255.255.255 > > > status: ALLOCATED PI > > > mnt-by: RIPE-NCC-HM-MNT > > > mnt-lower: RIPE-NCC-HM-MNT > > > > > > inetnum: 12.0.0.0 - 12.0.0.255 > > > netname: EXAMPLE-PI > > > descr: Example Banking PLC > > > admin-c: AA1-RIPE > > > status: ASSIGNED PI > > > mnt-by: MNT-EXAMPLE-PI > > > > > > inetnum: 12.0.1.0 - 12.0.1.255 > > > netname: ANOTHER-EXAMPLE-PI > > > descr: Anotherexample Printing Industries NV > > > admin-c: ZZ1-RIPE > > > status: ASSIGNED PI > > > mnt-by: MNT-ANOTHEREXAMPLE-MNT-BY > > > mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES > > > mnt-routes: MNT-ANOTHEREXAMPLE-MNT-ROUTES-2 > > > > > > > > > There is also this aut-num object: > > > > > > aut-num: AS65534 > > > mnt-by: MNT-AUT-NUM-MNT-BY > > > mnt-routes: MNT-AUT-NUM-MNT-ROUTES > > > > > > There are no route objects that are in 12.0.0.0/23 space, > > > or less specific of 12.0.0.0/23. > > > > > > The user wants to create the following route object: > > > > > > route: 12.0.0.0/23 > > > origin: AS65534 > > > mnt-by: MNT-ROUTE > > > > > > When the creation is attempted without the keyword > > > 'EXTENDED-ROUTE-CREATION,' > > > the whois software will try to get the IP space authentication from > > > inetnums, > > > as no related route object exists. The one level less specific > > > inetnum is > > > 12.0.0.0 - 12.255.255.255, which has the attribute "mnt-lower: > > > RIPE-NCC-HM-MNT". > > > As the user does not have access to the authorisation for > > > RIPE-NCC-HM-MNT > > > mntner, the creation attempt will fail. > > > > > > When the creation is attempted with the keyword > > > 'EXTENDED-ROUTE-CREATION': > > > - There are no exact match route or inetnum objects, so proceed with > > > extended route creation rules. > > > - to get the authorisation from IP space, the whois software will > > > perform > > > '-r -Troute,inetnum -m 12.0.0.0/23' query, which will return > > > > > > inetnum: 12.0.0.0 - 12.0.0.255 > > > inetnum: 12.0.1.0 - 12.0.1.255 > > > > > > - there are no inetnums to be eliminated from the list. > > > - the resulting set of inetnums/routes (it actually has two inetnums > > > and no routes) covers the whole space of 12.0.0.0/23. > > > - collect the mntners to be used in the authorisation process. > > > from the aut-num: MNT-AUT-NUM-MNT-ROUTES > > > from the route object itself that will be created: MNT-ROUTE > > > from the IP space: (MNT-EXAMPLE-PI AND > > > (MNT-ANOTHEREXAMPLE-MNT-ROUTES OR > > > MNT-ANOTHEREXAMPLE-MNT-ROUTES-2)) > > > 12.0.0.0 - 12.0.0.255 does not have "mnt-routes:", so "mnt-by:" > > > must > > > be used. > > > 12.0.1.0 - 12.0.1.255 has two "mnt-routes:", so they both must be > > > used, > > > but they must be ORed. > > > - the resulting mntner list: > > > ( > > > MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND > > > ( > > > MNT-EXAMPLE-PI AND > > > ( > > > MNT-ANOTHEREXAMPLE-MNT-ROUTES OR > > > MNT-ANOTHEREXAMPLE-MNT-ROUTES-2 > > > ) > > > ) > > > ) > > > > > > Example 2: > > > > > > Suppose there are these inetnums in the database: > > > > > > inetnum: 0.0.0.0 - 255.255.255.255 > > > mnt-by: RIPE-NCC-HM-MNT > > > mnt-lower: RIPE-NCC-HM-MNT > > > mnt-routes: RIPE-NCC-NONE-MNT > > > > > > inetnum: 12.0.0.0 - 12.255.255.255 > > > mnt-by: RIPE-NCC-HM-MNT > > > mnt-lower: RIPE-NCC-HM-MNT > > > > > > inetnum: 12.0.0.0 - 12.0.0.255 > > > mnt-routes: MNT-INETNUM-1 > > > > > > inetnum: 12.0.1.0 - 12.0.1.255 > > > mnt-routes: MNT-INETNUM-2 > > > > > > and the following route objects: > > > > > > route: 12.0.1.0/24 > > > origin: AS65534 > > > mnt-routes: MNT-ROUTE-1 > > > > > > route: 12.0.2.0/23 > > > origin: AS6 > > > mnt-routes: MNT-ROUTE-2 > > > > > > route: 12.0.2.0/23 > > > origin: AS65534 > > > mnt-routes: MNT-ROUTE-3 > > > mnt-routes: MNT-ROUTE-4 > > > > > > and this aut-num: > > > > > > aut-num: AS65534 > > > mnt-by: MNT-AUT-NUM-MNT-BY > > > mnt-routes: MNT-AUT-NUM-MNT-ROUTES > > > > > > The user wants to create the following route object: > > > > > > route: 12.0.0.0/22 > > > origin: AS65534 > > > mnt-by: MNT-ROUTE > > > > > > When the creation is attempted without the keyword > > > 'EXTENDED-ROUTE-CREATION,' > > > the whois software will try to get the IP space authentication from > > > inetnums, > > > as no related route object exists. The one level less specific > > > inetnum is > > > 12.0.0.0 - 12.255.255.255, which has "mnt-lower: RIPE-NCC-HM-MNT" > > > attribute. > > > As the user does not have access to the authorisation for > > > RIPE-NCC-HM-MNT > > > mntner, the creation attempt will fail. > > > > > > When the creation is attempted with the keyword > > > 'EXTENDED-ROUTE-CREATION': > > > - There are no exact match route or inetnum objects, so proceed with > > > extended route creation rules. > > > - to get the authorisation from IP space, the whois software will > > > perform > > > '-r -Troute,inetnum -m 12.0.0.0/22' query, which will return > > > > > > inetnum: 12.0.0.0 - 12.0.0.255 > > > inetnum: 12.0.1.0 - 12.0.1.255 > > > route: 12.0.1.0/24 > > > route: 12.0.2.0/23 (origin AS6) > > > route: 12.0.2.0/23 (origin AS65534) > > > > > > - eliminate the inetnums with less specific or exact match route > > > objects > > > in the list. The resulting list will be: > > > > > > inetnum: 12.0.0.0 - 12.0.0.255 > > > route: 12.0.1.0/24 > > > route: 12.0.2.0/23 (origin AS6) > > > route: 12.0.2.0/23 (origin AS65534) > > > > > > - the resulting list covers the whole 12.0.0.0/22 space. Continue. > > > - Collect the mntners to be used during the authorisation check. > > > from the aut-num: MNT-AUT-NUM-MNT-ROUTES > > > from the route object itself that will be created: MNT-ROUTE > > > from the IP space: (MNT-INETNUM-1 AND MNT-ROUTE-1 AND > > > (MNT-ROUTE-2 AND (MNT-ROUTE-3 OR MNT-ROUTE-4))) > > > > > > - the resulting mntner list: > > > ( > > > MNT-AUT-NUM-MNT-ROUTES AND MNT-ROUTE AND > > > ( > > > ( > > > MNT-INETNUM-1 AND MNT-ROUTE-1 AND > > > ( > > > MNT-ROUTE-2 AND > > > ( > > > MNT-ROUTE-3 OR MNT-ROUTE-4 > > > ) > > > ) > > > ) > > > ) > > > )
- Previous message (by thread): Proposed change 2004.1: extended route creation rules
- Next message (by thread): Proposed change 2004.1: extended route creation rules
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]