[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