[db-wg] RE: Proposed change 2004.1: extended route creation rules

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
> >          )
> >         )
> >        )
> >       )
> >      )
> >
> >
>
>
>