Dear All, I was not at the recent RIPE Mtg and so may be behind the curve. I have been trying to see what is the status of the deployment of RPSLng, and testing the tools. My simple test worked OK, but I can't do more without having more objects to test against. These would need to be inserted by others. There was some traffic on the RPSLng list during the autumn, and near as I can make out there is still some dispute about some details of the syntax; I am not able to contribute meaningfully to that debate. I do note that the contentious items appeared to relate to the aut-num object. It seems to me we need: 1) Agreement 2) Deployment 3) Population 4) and for us, JunOS support The production database contains inet6num: objects. It does not contain or support route6: objects. Is anything in dispute about the route6: object? If not, could the production server be updated to support it, as a step forward. This would allow organisations to enter their route6: objects, and more extensive testing could then be done against these, using -f to keep the aut-num local. This would allow a bit of (2) and (3) in advance of complete (1). It would focus people's minds a bit. At present I have no lever to get customers to do (3) when any route6: objects they enter can only be in the test db. At the moment it feels like everyone is waiting for everyone else :-) Is this justified or am I completely at sea? Cheers, -- Tim
Hi Tim, On 2004-02-17 17:39:17 +0000, Tim Streater wrote:
Dear All,
I was not at the recent RIPE Mtg and so may be behind the curve. I have been trying to see what is the status of the deployment of RPSLng, and testing the tools. My simple test worked OK, but I can't do more without having more objects to test against. These would need to be inserted by others.
There was a nice prensentation from Simon Leinen in the DB WG. Here's what we have in the draft minutes: ====== RPSLng status and deployment (Simon L., SWITCH) See presentation RPSLng is usable for multiple protocols RIPE NCC offers a test database, but there are very few (4) real aut-num objects using the new policy attributes. Still needs a bit of work to tidy up the syntax, and operator input is seriously needed. It was noted (Randy) that the operators who use tools to extract their routing configs from the database need to be involved. It was also noted that since changes will take place in the future we should start to think about versioning. Please start trying to use RPSLng. It is not too late to update the specification. ===== I think what's needed is a bit more time, for testing.
There was some traffic on the RPSLng list during the autumn, and near as I can make out there is still some dispute about some details of the syntax; I am not able to contribute meaningfully to that debate. I do note that the contentious items appeared to relate to the aut-num object.
It seems to me we need:
1) Agreement 2) Deployment 3) Population 4) and for us, JunOS support
IMHO we must put 'Testing' as the first item in the list above.
The production database contains inet6num: objects. It does not contain or support route6: objects. Is anything in dispute about the route6: object? If not, could the production server be updated to support it, as a step forward. This would allow organisations to enter their route6: objects, and more extensive testing could then be done against these,
As far as I can understand, there is nothing in dispute for route6 objects. It is also theorically possible to introduce route6 object without adding mp-* attributes, however, we don't see this as a good way to go, because of several reasons: - to add route6, we need at least one change in aut-num objects as well. Namely, we need to change "mnt-routes:" attribute to accept ipv6 prefixes as well: (*) mnt-routes: MAINT-AS65001 {3ffe:ffff::/32^+, 35.42.0.0/16^+} This is required to implement route6 creation authorisation rules. - it would not be a good idea to test stuff on a production database. - it would be quite resource consuming to implement the RPSLng draft part by part.
using -f to keep the aut-num local. This would allow a bit of (2) and (3) in advance of complete (1). It would focus people's minds a bit. At present I have no lever to get customers to do (3) when any route6: objects they enter can only be in the test db.
At the moment it feels like everyone is waiting for everyone else :-) Is this justified or am I completely at sea?
Cheers, --
Tim
Best regards, -- Engin Gunduz RIPE NCC Software Engineering Department (*) The RIPE Whois database does not accept prefix lists in curly braces in "mnt-routes:" attribute right now, however, currently we are working on it and the functionality (only for IPv4 prefixes) will be available shortly.
participants (2)
-
Engin Gunduz
-
Tim Streater