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

In message <Pine.LNX.4.44.0309181408040.17750-100000 at netcore.fi>, Pekka Savola 
writes:
> On Tue, 16 Sep 2003, Curtis Villamizar wrote:
> > In message <Pine.LNX.4.44.0309162130570.24960-100000 at netcore.fi>, Pekka Sav
> ola 
> > 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 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 at ietf.org
> https://www1.ietf.org/mailman/listinfo/rps