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

In message <Pine.LNX.4.44.0309211712130.7588-100000 at netcore.fi>, Pekka Savola w
rites:
> On Fri, 19 Sep 2003, Curtis Villamizar wrote:
> > > > 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.
> 
> You fail to see that *we* set up the policies common to everyone we peer 
> with; we advertise both BGP unicast and multicast routes to everybody 
> equally. Almost nobody uses them, though, but that's not *our* problem.  
> We just wnt to have an equal policy for everyone.
> 
> [...]
> > > > 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.
> 
> That's good.  Taking an example with IRRToolSet, I want to embed both RPSL 
> and RPSLng format attributes or commands in a single text document, which 
> I will pass through IRRToolSet _once_. (e.g., requiring to run the tool 
> twice, once for each support with different command-line arguments is 
> unreasonable.)

RPSLng is a superset of RPSL.  After some **testing** of the RPSLng
server code, the entire database will be RPSLng.

The only issue will be whether RPSL only query clients will be
accommodated by 1) extracting the non mp-* RPSL from any RPSLng
entries that match the queries (by the server code) or 2) non mp-*
RPSL will be generated for the IPv4 part of the mp-* entries when
entered into the database, or 3) whether end users will have to submit
non mp-* for ipv4-unicast.

The point it that there are multiple ways to accommodate older client
code during transition.  Which method of transition to pick is
something more appropriate for a RIPE meeting, not for the language
spec.

> > > > At some later time the server software may be able to recognize older
> > > > client code and return non- mp-* entries converted from policy expresse
> d
> > > > as mp-* entries.  At some time, probably even later, it is expected tha
> t
> > > > 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.
> 
> Well, I can see multiple possible ways to do so -- so this the way forward 
> does seem to use a bit of phrasing.
> 
> Something added to an appendix would likely be very useful.

Good.  The comment above about 3 ways to do the transition might also
help.  The draft authors should feel free to reword any of this as
they see fit.

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

Curtis