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