On Mon, 15 Sep 2003, Curtis Villamizar wrote:
In message <Pine.LNX.4.44.0309151040220.27172-100000@netcore.fi>, Pekka Savola writes:
I'm not sure if I agree with what you call "tough luck", but I've omitted them from the response, as more arguing on those wouldn't seem to be productive.
In message <Pine.LNX.4.44.0309111134070.10628-100000@netcore.fi>, Pekka Sav
On Fri, 12 Sep 2003, Curtis Villamizar wrote: ola
writes:
In message <Pine.LNX.4.44.0309101200110.30657-100000@netcore.fi>, Pekka Sav
On Wed, 10 Sep 2003, Curtis Villamizar wrote: ola
writes: [...]
However, there seem to be a number of (more or less) textual inaccura cies
and confusion in the document, which should be settled prior to publication.
I think there are the three most important issues here are:
* issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you conflicting information about IPv4 unicast, then what?
Not an issue. If only IPv4 policy is specified by a given statement, then either the old form or the new form can be used. Currently multiple import, export, and default statements can appear. Their effects are additive. The effect of adding mp-* statements specifying ipv4 using the longer syntax is the same as adding more of the existing import, export, and default statements.
I'm not sure if I see it as the same. The user running RPSL tool must check both the traditional and RPSLng entries. This is a change. More likely than not, depending on the transition/co-existence plan, he will also have to maintain records on both old and new. This is bound to caus e inconsistencies in the data.
The transition is quite easy. The change adds mp-* but does not depricate (ever) the use of the non mp- forms. Just keep all the IPv4 unicast policy in the old form until conversion is considered complete. If it is never certain that conversion is complete, keep the IPv4 unicast in the old form indefinitely.
"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!
Any AS object that provides policy already has many import and export statements. Today IPv4 and IPv6 policy does not match so different statements are needed anyway. For example, AS3561 has 737 import statements and 738 export statements. I would venture to guess their IPv6 policy is a lot simpler.
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..
I had a lot to do with IPv4 deployment (NSFNET 1992-1995, ANS and UUNET 1995-1998) and I had a lot to do with definition of RPSL and use of RPSL. Considering how long widespread IPv6 deployment has been "coming RSN" the IPv6 world has got nowhere by comparison. I suggest you get off your soapbox and stick with concrete comments and suggestions.
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 be different anyway. I believe I gave a couple of points to consider as well.
Its deployed so obviously it works. We're not talking about something no one has ever tried. This is documenting a set of extensions that are in use.
Being used by a few people and being used as widely as RPSL is used today are two different things. It is obviously not being used widely if RIPE just got it's test version of the database and the tools out a month or something like that ago.
Larry could probably give you the lineage of this work better than I could. I think David Kessens was working on expressing IPv6 policy in RPSL as far back as 1997 or so.
Right.. but it has gotten nowhere in about five years if so.
RIPE uses its database mostly as a Internet address and AS registry. That you can express policy in RPSL for RIPE is just an added benefit for their customers. RIPE has had IPv6 inetnum records for a very long time for the purpose of address registry.
This is irrelevant: the fact stands that at least in the RIPE region (I don't know much of the others, but I guess the situation is pretty much the same), RPSLng has *not* been deployed at all. So, it seems to me that any statements of its wide use are quite questionable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings