In message <Pine.LNX.4.44.0309181408040.17750-100000@netcore.fi>, Pekka Savola writes:
In message <Pine.LNX.4.44.0309162130570.24960-100000@netcore.fi>, Pekka Sav
On Tue, 16 Sep 2003, Curtis Villamizar wrote: ola
writes:
On Tue, 16 Sep 2003, Curtis Villamizar wrote:
In message <Pine.LNX.4.44.0309160816080.5651-100000@netcore.fi>, Pekka Savo la w rites:
Did you even read what I wrote? I certainly didn't see a problem in having different IPv6 and IPv4 records, because, well, they have to b
e
different anyway. I believe I gave a couple of points to consider as
well.
If you have no issue with separate IPv6 and IPv4 records then the matter is resolved. There is no transition problem, nor is there any long term problem other than separate IPv6 and IPv4 records which may be a nuisance later at worst.
I recall that RPSLng also supports ipv4.unicast (which is supported by RPSL as well), and ipv4.multicast. The issue is clearly not settled by that, I think,
As far as I can tell you have made no point which has withstood strutiny. If you think there is a problem, please state the problem concisely.
I'll just cut-n-paste my earlier response below. There are certainly open issues on keeping IPv4 unicast and multicast data in sync. Further, it might be desirable to have IPv4 unicast in the same database, so that you could just run the IRRToolSet (or some other tool) just once, from one database to get both v4 and v6 data, but this is a smaller point.
You seem not to be missing something. The mp-* and non- mp-* entries will be in the same database. For backwards compatibility the ipv4 unicast policy will be in the same database but at least initially expressed as non- mp-* policy statements. Since policy is currently quite different between unicase and multicase and ipv4 and ipv6 this is not only not a problem, it is not even an inconvenience. 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. So none of your objections below are valid. Curtis
====== "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