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

 Pekka and Curtis,
   Thanks for the feedback.  Sorry for not responding sooner (I've
been trying to absorb everything and formulate a response).  I've
been updating the draft to reflect many of your comments
(thanks, Pekka).


On Fri, 2003-09-19 at 03:21, Pekka Savola wrote:
> 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.

  I think there indeed needs to be some text to clarify the use of
mp-* and non mp-* entries.  Should the document recommend the use of
non-mp entries to express v4 policies for existing non-RPSLng
compliant tools?  Should this be mandatory or optional?  And perhaps
more controversily, if there are mp- attributes present in an object,
should the non-mp attributes be ignored by RPSLng compliant tools
to reduce the possibility for conflicts.

  Further should there be clarification on the case where an import,
export, or default attribute references a route-set/filter-set/etc.
which contains mp- attributes?  Should RPSLng compliant tools ignore
the mp- attributes in this case (as non-RPSLng compliant tools would
do).

> 
> > For backwards compatibility the ipv4
> > unicast policy will be in the same database but at least initially
> > expressed as non- mp-* policy statements. 
> 
> Right.

  One option I thought about would be to change the mp-members,
mp-filter, mp-peer, mp-peering, and interface attributes to be
IPv6 specific.  In other words, rename them to something like
members6, filter6, peer6, peering6, and interface6 (well, perhaps
not the interface attribute since it introduces new functionality).
This would preserve explicit support for backward compatibility
with IPv4 as one would need to continue to express IPv4 prefixes
and policy info in the existing RPSL attributes.

  I think backward compatibility in these attributes is more
important than the import, export, and default attributes as
I believe one is more likely to reference another org's route-set,
filter-set, etc., than another org's aut-num object.


 -Larry Blunk
  Merit


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