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

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.

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

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

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

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings