[Rps] Re: Last Call: 'RPSLng' to Proposed Standard

On Tue, 16 Sep 2003, Curtis Villamizar wrote:
> In message <Pine.LNX.4.44.0309162130570.24960-100000 at netcore.fi>, Pekka Savola 
> writes:
> > On Tue, 16 Sep 2003, Curtis Villamizar wrote:
> > > In message <Pine.LNX.4.44.0309160816080.5651-100000 at 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 be 
> > > > 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.

======
"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