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

In message <Pine.LNX.4.44.0309191015080.29158-100000 at netcore.fi>, Pekka Savola 
writes:
> 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.

I seriously doubt this is common unless you have a small number of
peers.  The majority of providers support IPv4 unicast only so policy
for multicast or IPv6 is meaningless.

Regardless, for a transition period you have duplicate entries if the
policies were identical.  One entry would be in import (for IPv4) the
other would be otherwise identical mp-import for
ipv6,ipv4-multicast,ipv6-multicast.  If the server side can recognize
older clients, then the inconvenience of duplicate entries can be
elimitated.  See paragraph below.

> > 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.

They are similar formats.

> > 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?

It was just considered above.  I thought that was obvious enough since
this is similar to past transitions and I understand how the mp-* were
intended to be used.  If you want something in the spec on transition,
a paragraph or two from this email message can be added.  I don't
think its needed but it wouldn't hurt.

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 RPS
> L 
> > > 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
> > 
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings