Folks, For any RPSL lovers among you that weren't at the Address Policy WG meeting this morning, the topic of cleaning up referenced AS numbers came up again. There are about ~2,000 16 bits ASNs that have been returned, but are still referenced in the import/export lines of other aut-num objects, either directly or via as-sets. There will be more discussion of this in the Database WG this afternoon, but I thought I'd mention it here as it has implications for those on this list that use RPSL. Cheers, Rob
Hi all In the DB WG session this afternoon we only touch on the fact that this project is ongoing. I go into more details on the problems we have with this project with my short presentation in the Routing WG tomorrow. Regards denis On 14/05/2014 10:28, Rob Evans wrote:
Folks,
For any RPSL lovers among you that weren't at the Address Policy WG meeting this morning, the topic of cleaning up referenced AS numbers came up again. There are about ~2,000 16 bits ASNs that have been returned, but are still referenced in the import/export lines of other aut-num objects, either directly or via as-sets.
There will be more discussion of this in the Database WG this afternoon, but I thought I'd mention it here as it has implications for those on this list that use RPSL.
Cheers, Rob
Hi Denis, Just for my understanding. For such clean-ups is there any need to have a policy to remove certain object references or this comes under RIR housekeeping can be done once problem has been identified by the community consensus. Regards, Aftab A. Siddiqui On Wed, May 14, 2014 at 1:33 PM, Denis Walker <denis@ripe.net> wrote:
Hi all
In the DB WG session this afternoon we only touch on the fact that this project is ongoing. I go into more details on the problems we have with this project with my short presentation in the Routing WG tomorrow.
Regards denis
On 14/05/2014 10:28, Rob Evans wrote:
Folks,
For any RPSL lovers among you that weren't at the Address Policy WG meeting this morning, the topic of cleaning up referenced AS numbers came up again. There are about ~2,000 16 bits ASNs that have been returned, but are still referenced in the import/export lines of other aut-num objects, either directly or via as-sets.
There will be more discussion of this in the Database WG this afternoon, but I thought I'd mention it here as it has implications for those on this list that use RPSL.
Cheers, Rob
Hi Aftab It is quite a complex process to automate the removal of these references and old references may come back later looking like new policy but is still old policy, if the user did not handle the removal themselves. We will put some scenarios to you tomorrow and ask some questions, but we don't have many answers yet. Regards Denis Walker Business Analyst RIPE NCC Database Team On 14/05/2014 11:09, Aftab Siddiqui wrote:
Hi Denis, Just for my understanding. For such clean-ups is there any need to have a policy to remove certain object references or this comes under RIR housekeeping can be done once problem has been identified by the community consensus.
Regards,
Aftab A. Siddiqui
On Wed, May 14, 2014 at 1:33 PM, Denis Walker <denis@ripe.net <mailto:denis@ripe.net>> wrote:
Hi all
In the DB WG session this afternoon we only touch on the fact that this project is ongoing. I go into more details on the problems we have with this project with my short presentation in the Routing WG tomorrow.
Regards denis
On 14/05/2014 10:28, Rob Evans wrote:
Folks,
For any RPSL lovers among you that weren't at the Address Policy WG meeting this morning, the topic of cleaning up referenced AS numbers came up again. There are about ~2,000 16 bits ASNs that have been returned, but are still referenced in the import/export lines of other aut-num objects, either directly or via as-sets.
There will be more discussion of this in the Database WG this afternoon, but I thought I'd mention it here as it has implications for those on this list that use RPSL.
Cheers, Rob
Hi Aftab, Aftab Siddiqui wrote:
Hi Denis, Just for my understanding. For such clean-ups is there any need to have a policy to remove certain object references or this comes under RIR housekeeping can be done once problem has been identified by the community consensus.
my point of view as a DB-Co-chair (at the moment) is that we don't need a formal policy, if the problem is well understood, we do have a sound proposal how to move forward and there is no severe impact on daily operations for the users of the DB services; (and no substantial disagreement). In case we hit a roadblock and find out that the/a proposed solution/s would require major changes for the resource holders, or the managment of number resources in our region, then for all means, we would use the formal PDP, imho.
Regards,
Aftab A. Siddiqui
Best reegards, Wilfried.
On Wed, May 14, 2014 at 1:33 PM, Denis Walker <denis@ripe.net> wrote:
Hi all
In the DB WG session this afternoon we only touch on the fact that this project is ongoing. I go into more details on the problems we have with this project with my short presentation in the Routing WG tomorrow.
Regards denis
On 14/05/2014 10:28, Rob Evans wrote:
Folks,
For any RPSL lovers among you that weren't at the Address Policy WG meeting this morning, the topic of cleaning up referenced AS numbers came up again. There are about ~2,000 16 bits ASNs that have been returned, but are still referenced in the import/export lines of other aut-num objects, either directly or via as-sets.
There will be more discussion of this in the Database WG this afternoon, but I thought I'd mention it here as it has implications for those on this list that use RPSL.
Cheers, Rob
Hi,
my point of view as a DB-Co-chair (at the moment) is that we don't need a formal policy, if the problem is well understood, we do have a sound proposal how to move forward and there is no severe impact on daily operations for the users of the DB services; (and no substantial disagreement).
For those who weren't present in the routing working group this afternoon, either physically or virtually, there was a strong sentiment that the RIPE NCC should *not* edit other objects to remove references to reclaimed ASNs. Send out warnings, by all means, but editing other objects would open up a can of worms that is best left sealed under pressure. Cheers, Rob
Rob Evans wrote:
Hi,
my point of view as a DB-Co-chair (at the moment) is that we don't need a formal policy, if the problem is well understood, we do have a sound proposal how to move forward and there is no severe impact on daily operations for the users of the DB services; (and no substantial disagreement).
For those who weren't present in the routing working group this afternoon, either physically or virtually, there was a strong sentiment that the RIPE NCC should *not* edit other objects to remove references to reclaimed ASNs.
Send out warnings, by all means, but editing other objects would open up a can of worms that is best left sealed under pressure.
Thanks for this feedback, noted! Wilfried.
Cheers, Rob
Hi Rob, Well, I just watched the video to catch the sentiment :)
Send out warnings, by all means, but editing other objects would open up a can of worms that is best left sealed under pressure.
Send out warnings to whom? Because you may end up getting bounce back and then what? Are there any plans to try the warning procedure? I totally agree its a can of worms but it shouldn't be left sealed forever.
Cheers, Rob
Regards, Aftab A. Siddiqui
On Wed, May 14, 2014 at 10:28 AM, Rob Evans <rhe@nosc.ja.net> wrote:
Folks,
For any RPSL lovers among you that weren't at the Address Policy WG meeting this morning, the topic of cleaning up referenced AS numbers came up again. There are about ~2,000 16 bits ASNs that have been returned, but are still referenced in the import/export lines of other aut-num objects, either directly or via as-sets.
Do anyone have any number on the scale of the problem as in how many out of those ~2000 are only referred to a few times, or maybe just internal referred toward another returned ASN? I would guess that there are some of those that are referred to more than others, and others have very few and easy to figure out the scope of. I know this will very likely be a manual process to verify this but the job probably has to be done sooner or later. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
participants (5)
-
Aftab Siddiqui
-
Denis Walker
-
Rob Evans
-
Roger Jørgensen
-
Wilfried Woeber