In message <Pine.LNX.4.44.0309211712130.7588-100000@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