On Thu, 18 Sep 2003, Curtis Villamizar wrote:
You seem not to be missing something. The mp-* and non- mp-* entries will be in the same database.
Probably yes, in the longer term; that helps some scenarios but doesn't eliminate the issues.
For backwards compatibility the ipv4 unicast policy will be in the same database but at least initially expressed as non- mp-* policy statements.
Right.
Since policy is currently quite different between unicase and multicase
A fatal assumption. In about all academic networks and backbone transit providers -- which are significant users of RPSLng -- multicast and unicast topologies are very much the same. Ours (and many others') policies are identical.
and ipv4 and ipv6 this is not only not a problem, it is not even an inconvenience.
A smaller issues, yes. However, from "the use of tools" perspective, people will use both IPv4 and IPv6, and similar formats would be useful.
At some later time the server software may be able to recognize older client code and return non- mp-* entries converted from policy expressed as mp-* entries. At some time, probably even later, it is expected that older clients will disappear. At some point it may no longer be practical to run an IPv4 only network and/or run a unicast only network (though this seems not to be "on the horizon" at the moment) and then all clients which did not understand the mp-* syntax would be> gone because they would all need that syntax to support IPv6.
These are the issues I think will need *explicit* consideration before going down the path of happily adopting RPSLng. What if there are some holes in the spec or how it is implemented, or a clear view (for everyone) on what's the overall plan for deploying RPSL and RPSLng?
====== "until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right?
But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach.
As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features.
Another approach might be to general IPv4.unicast data to RPSLng from RPSL data, so that everyone could start "safely" to use RPSLng only.
But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure.
Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng!
We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details.. =====
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings