[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard
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