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

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