Proposed change 2004.1: extended route creation rules
- Previous message (by thread): Proposed change 2004.1: extended route creation rules
- Next message (by thread): New Draft Document: De-boganising New Address Blocks
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Frank Bohnsack
Frank.Bohnsack at deu.mci.com
Mon Feb 9 23:22:32 CET 2004
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). 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): New Draft Document: De-boganising New Address Blocks
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]