Hello, we would like to ask the db-wg working group to change the behavior of adding route objects to the ripe database. I had a discussion with someone from ripe during the routing registry course and he told me that ripe could change the way how route objects can be created but this must be decided by the db-wg. We need route-objects for proper routing via bgp4. As customers may change their upstream they need for a certain amount of time more than one route object. The creating of this new route object failes if the old isp does not respond. Let me give you the following example: inetnum: 192.168.230.0 - 192.168.231.255 netname: DUMMY-NET descr: Customer GmbH country: DE org: ORG-AAAAA-RIPE admin-c: AA1 tech-c: AA1 status: ASSIGNED PI mnt-by: RIPE-NCC-HM-PI-MNT mnt-by: CUSTOMER-MNT mnt-by: NEW-ISP-MNT mnt-lower: RIPE-NCC-HM-PI-MNT mnt-routes: OLD-ISP1-MNT mnt-routes: OLD-ISP2-MNT mnt-routes: NEW-ISP-MNT mnt-domains: OLD-ISP1-MNT mnt-domains: OLD-ISP2-MNT mnt-domains: NEW-ISP-MNT source: RIPE # Filtered route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT source: RIPE # Filtered we want now add this object parallel to the existing one: route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS5678 mnt-by: NEW-ISP-MNT source: RIPE # Filtered but fail because: not authenticated by: OLD-ISP1-MNT Thus if OLD-ISP doesnt want for whatever reason help the customer it seems to be that he can block new route objects. This is stupid and can as i know only solved with the help of ripe ncc. It seems to work only if the old isp changed his route object: route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT source: RIPE # Filtered to route: 192.168.231.0/24 descr: Dummy New via old ISP origin: AS1234 mnt-by: OLD-ISP1-MNT mnt-by: NEW-ISP-MNT source: RIPE # Filtered I think the owner of the network (inetnum object) should be able to create route objects for his IPs. This would solve the problem. Currently he cant do this because the AS does not have his Maintainer i doubt large ISPs want even for a short period customer maintainer in their AS. To avoid abuse, the db should prevent to alter or create route-objects if there is no maintainer in the inetnum object. If the db will accept new route objects created by those who are maintainer in the inetnum object, the customer can do this without help of the old isp or ripe ncc. Could we have some input and comments from the working group ? Winfried Haug --- Headlight Housing Factory | Rechenzentrum: Azenbergstrasse 35 | Neue Bruecke 8 D-70174 Stuttgart | D-70173 Stuttgart Fon: +49 711 2840 0 | e-mail: wh@headlight.de Fax: +49 711 2840 999 | http://www.headlight.de
Hello Winfried! Why there is *-ISP-MNT in your PI, not your one?
inetnum: 192.168.230.0 - 192.168.231.255 netname: DUMMY-NET descr: Customer GmbH country: DE org: ORG-AAAAA-RIPE admin-c: AA1 tech-c: AA1 status: ASSIGNED PI mnt-by: RIPE-NCC-HM-PI-MNT mnt-by: CUSTOMER-MNT mnt-by: NEW-ISP-MNT mnt-lower: RIPE-NCC-HM-PI-MNT mnt-routes: OLD-ISP1-MNT mnt-routes: OLD-ISP2-MNT mnt-routes: NEW-ISP-MNT mnt-domains: OLD-ISP1-MNT mnt-domains: OLD-ISP2-MNT mnt-domains: NEW-ISP-MNT source: RIPE # Filtered
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Why there is *-ISP-MNT in your PI, not your one? we are the new ISP and our MNT is in the inetnum!
inetnum: 192.168.230.0 - 192.168.231.255 netname: DUMMY-NET descr: Customer GmbH country: DE org: ORG-AAAAA-RIPE admin-c: AA1 tech-c: AA1 status: ASSIGNED PI mnt-by: RIPE-NCC-HM-PI-MNT mnt-by: CUSTOMER-MNT <- customer (owner of net) mnt-by: NEW-ISP-MNT <- we mnt-lower: RIPE-NCC-HM-PI-MNT mnt-routes: OLD-ISP1-MNT <- OLD ISP1 mnt-routes: OLD-ISP2-MNT <- OLD ISP2 mnt-routes: NEW-ISP-MNT <- we mnt-domains: OLD-ISP1-MNT mnt-domains: OLD-ISP2-MNT mnt-domains: NEW-ISP-MNT source: RIPE # Filtered
Beside that, if you have ONE Upstream and get a second one the first needs to place a mnt-routes in his route object. If the customer later wants a third upstream, he needs the first TWO to install a mnt-routes. A lot of large player in the market have no workflow for doing this. They are able to create a route object for themselves but not alter it so that another isp can create a route object for his as. "Able" means they are allowed by they internal policy/workflow to send the right mail to the ripe db address. They consider this as an exception from their normal policy how to handle a customer:-) The last action took around 6 weeks and lots of emails to explain what we / the customer needs. This is really a nightmare. It worked only because the person at the tier1 isp has altered his route-object while we phoned, we sent the create route object to ripe and afterwards he deleted again the mnt-routes so nobody saw a change. Winfried
Hi!
Why there is *-ISP-MNT in your PI, not your one? we are the new ISP and our MNT is in the inetnum!
But why not only client's one?
Beside that, if you have ONE Upstream and get a second one the first needs to place a mnt-routes in his route object
Why?
. If the customer later wants a third upstream, he needs the first TWO to install a mnt-routes.
If the customer wants a third upstream (not just moving from first to second) - he need own autonomous system at first. It also solves this problem ;) I have customers with own PI and my ASN. First, there WILL be service interruption when such customer moves from one ISP to another. Second, correct workflow is: 1. Customer with own PI have OWN mnter, and ONLY it is present in his inetnum: object. 2. This mntner have PGP authorization (by the way, it is a must nowdays). 3. Customer makes a route object: route: 192.168.231.0/24 descr: Customer route origin: AS_FROM_UPSTREAM mnt-by: CUSTOMER-MNT source: RIPE # Filtered then signs it with his PGP key and send it to UPSTREAM. Upstream signs it with his key (or add passwd: field if he is too lame to make PGP key ;) ) and send it to auto-dbm@ripe.net. Customer id free to change his route, because of there is customer's mntner. If there is TWO route objects with same net and different AS (and if there is two announces from two points with different AS) - it just will not work. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On Apr 05, Winfried Haug <wh@germany.com> wrote:
we would like to ask the db-wg working group to change the behavior of adding route objects to the ripe database. I had a discussion with someone from ripe during the routing registry course and he told me that ripe could change the way how route objects can be created but this must be decided by the db-wg. I believe that this is a sensible proposal.
I would even argue that the WG should consider allowing whoever controls mnt-routes OR the referenced aut-num object to remove (not create) a route/route6 object even if the request is not authenticated by both maintainers. -- ciao, Marco
Hello Marco,
-----Ursprungliche Nachricht----- Von: db-wg-admin@ripe.net [mailto:db-wg-admin@ripe.net]Im Auftrag von Marco d'Itri Gesendet: Mittwoch, 5. April 2006 14:25 An: db-wg@ripe.net Betreff: Re: [db-wg] Adding route objects
On Apr 05, Winfried Haug <wh@germany.com> wrote:
we would like to ask the db-wg working group to change the behavior of adding route objects to the ripe database. I had a discussion with someone from ripe during the routing registry course and he told me that ripe could change the way how route objects can be created but this must be decided by the db-wg. I believe that this is a sensible proposal.
I would even argue that the WG should consider allowing whoever controls mnt-routes OR the referenced aut-num object to remove (not create) a route/route6 object even if the request is not authenticated by both maintainers.
this would not help in our case and i assume many ISPs might have the same scenario. As long as ISP OLD is routing the block the old route-object is necessary. If ISP OLD doesnt WANT to add a mnt-routes, i have to send a fax. In order to minimize the down-time, we need an additional route-object for 1-2 days. My proposal would be: The ISP should be able to remove his route-object referring to his AS number. This is still working!. The maintainer referenced to the inetnum object should be able to create and delete the route-objects tied to his inetnum. What can happen ? Case 1: Inetnum-Maintainer deletes one of his route-objects -> bad for him, he might loose connectivity Case 2: Inetnum-Maintainer creates a route-object with a AS he has no connection to -> nothing critical or am i wrong ? But the unwanted object can be deleted by the AS maintainer directly or the inetnum maintainer. Case 3: Inetnum-Maintainer creats a route-object for his upstream -> perfect The current situation is not very nice for customers and causes additional work at the Ripe NCC. Addionally, it give the first owner of a route-object a power to deny further route objects. This doesnt make sense in my eyes. Winfried Headlight Housing Factory | Rechenzentrum: Azenbergstrasse 35 | Neue Bruecke 8 D-70174 Stuttgart | D-70173 Stuttgart Fon: +49 711 2840 0 | e-mail: wh@headlight.de Fax: +49 711 2840 999 | http://www.headlight.de
Case 2: Inetnum-Maintainer creates a route-object with a AS he has no connection to -> nothing critical or am i wrong ?
Well, I guess a couple of parties would not be delighted to see someone incorrectly "claiming" to be announced by them.
But the unwanted object can be deleted by the AS maintainer directly or the inetnum maintainer.
Case 3: Inetnum-Maintainer creats a route-object for his upstream -> perfect
What I forgot to ask: are we talking about PA or PI space? If it is PA, then we would start to "support" punching holes into aggregatable blocks. Wilfried.
I would very like to ask someone to raise this topic at RIPE 52, if possible. Either db-wg or routing-wg should do. Joao
Joao Damas wrote:
I would very like to ask someone to raise this topic at RIPE 52, if possible. Either db-wg or routing-wg should do.
Joao
I think it needs to be raised in *both* Routing and Address Policy, maybe in Anti-Spam, too. I also appreciate Andrei's reference to the RFC providing guidance. My gut feeling is that we should either take it formally through the PDP in the framework of Routing and/or Address Policy I will definitely put it onto the draft agenda for DB, Wilfried.
I would even argue that the WG should consider allowing whoever controls mnt-routes OR the referenced aut-num object to remove (not create) a route/route6 object even if the request is not authenticated by both maintainers. this would not help in our case and i assume many ISPs might have the same scenario. Yes, I understand this and I support your proposal. What I am proposing is an additional change to solve the second part of
On Apr 05, Winfried Haug <wh@germany.com> wrote: the problem (how to remove old route objects when the old ISP is not cooperating). -- ciao, Marco
On Thu, 6 Apr 2006, Marco d'Itri wrote:
On Apr 05, Winfried Haug <wh@germany.com> wrote:
I would even argue that the WG should consider allowing whoever controls mnt-routes OR the referenced aut-num object to remove (not create) a route/route6 object even if the request is not authenticated by both maintainers. this would not help in our case and i assume many ISPs might have the same scenario. Yes, I understand this and I support your proposal. What I am proposing is an additional change to solve the second part of the problem (how to remove old route objects when the old ISP is not cooperating).
Well, if the maintainer of the inetnum, and the maintainer of the origin-as for the to-be-registered-route-object agree and can send a pgp-signed, or whatever auth they use, object to ripedb, it should be registered, either with a warning stating there already exists a route-object, (which actually would be better for customers that are changing isp's since the filters for their coming global transit would work directly), or that the existing route-object simply is removed and the new one installed, I would prefer to be able to have multiple route-objects (as was possible earlier in ripedb), and to manually clean the database when customers sucessfully have changed global transit.
-- Best regards /Fredrik ------------------------------------------------------- KTHNOC, KTH, S-100 44 Stockholm, Sweden +46 8 790 65 17 -------------------------------------------------------
Fredrik Widell wrote:
On Thu, 6 Apr 2006, Marco d'Itri wrote:
On Apr 05, Winfried Haug <wh@germany.com> wrote:
I would even argue that the WG should consider allowing whoever controls mnt-routes OR the referenced aut-num object to remove (not create) a route/route6 object even if the request is not authenticated by both maintainers.
this would not help in our case and i assume many ISPs might have the same scenario.
Yes, I understand this and I support your proposal. What I am proposing is an additional change to solve the second part of the problem (how to remove old route objects when the old ISP is not cooperating).
Well, if the maintainer of the inetnum, and the maintainer of the origin-as for the to-be-registered-route-object agree and can send a pgp-signed, or whatever auth they use, object to ripedb, it should be registered, either with a warning stating there already exists a route-object, (which actually would be better for customers that are changing isp's since the filters for their coming global transit would work directly), or that the existing route-object simply is removed and the new one installed,
I would prefer to be able to have multiple route-objects (as was possible earlier in ripedb), and to manually clean the database when customers sucessfully have changed global transit.
I am in complete agreement with this. I've wasted a lot of time in the past with this exact issue. I do not believe the old route object should be deleted via this mechanism though - that should be cleaned via the existing mechanisms. -- Ian Dickinson Development Engineer PIPEX ian.dickinson@pipex.net http://www.pipex.net This e-mail is subject to: http://www.pipex.net/disclaimer.html
Fredrik Widell wrote:
On Thu, 6 Apr 2006, Marco d'Itri wrote:
On Apr 05, Winfried Haug <wh@germany.com> wrote:
I would even argue that the WG should consider allowing whoever controls mnt-routes OR the referenced aut-num object to remove (not create) a route/route6 object even if the request is not authenticated by both maintainers.
this would not help in our case and i assume many ISPs might have the same scenario.
Yes, I understand this and I support your proposal. What I am proposing is an additional change to solve the second part of the problem (how to remove old route objects when the old ISP is not cooperating).
Well, if the maintainer of the inetnum, and the maintainer of the origin-as for the to-be-registered-route-object agree and can send a pgp-signed, or whatever auth they use, object to ripedb, it should be registered, either with a warning stating there already exists a route-object, (which actually would be better for customers that are changing isp's since the filters for their coming global transit would work directly), or that the existing route-object simply is removed and the new one installed,
I would prefer to be able to have multiple route-objects (as was possible earlier in ripedb), and to manually clean the database when customers sucessfully have changed global transit.
I am in complete agreement with this. I've wasted a lot of time in the past with this exact issue. I do not believe the old route object should be deleted via this mechanism though - that should be cleaned via the existing mechanisms. -- Ian Dickinson Development Engineer PIPEX ian.dickinson@pipex.net http://www.pipex.net This e-mail is subject to: http://www.pipex.net/disclaimer.html
participants (8)
-
Fredrik Widell -
Ian Dickinson -
Ian Dickinson -
Joao Damas -
Max Tulyev -
md＠Linux.IT -
Wilfried Woeber, UniVie/ACOnet -
Winfried Haug