[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard
On Thu, 18 Sep 2003, Curtis Villamizar wrote:
> You seem not to be missing something. The mp-* and non- mp-* entries
> will be in the same database.
Probably yes, in the longer term; that helps some scenarios but doesn't
eliminate the issues.
> For backwards compatibility the ipv4
> unicast policy will be in the same database but at least initially
> expressed as non- mp-* policy statements.
Right.
> 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.
> 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.
> 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?
> > ======
> > "until conversion is considered complete". Do you think this takes a
> > year, two, or ten years? Note that for the conversion to be complete,
> > *EVERY* user or RPSL must have upgraded to RPSLng, right?
> >
> > But then again, you're advocating keeping the v4 unicast policy only in
> > the old form RPSL. Now, many sites want to mention their multicast
> > policies as well, or IPv6 policies. They have to maintain two different
> > databases and records to do this, using this transition approach.
> >
> > As for another approach, what might help a bit could be to have the
> > ability of the RPSLng databases to automatically generate the old form
> > RPSL data from the IPv4 unicast data which has possibly been entered in
> > the RPSLng registry, for maintaining the automatic backward compatibility
> > and minimizing the maintenance effort of all ISPs desiring to use the
> > RPSLng features.
> >
> > Another approach might be to general IPv4.unicast data to RPSLng from RPSL
> > data, so that everyone could start "safely" to use RPSLng only.
> >
> > But there are some potential "overlapping policy in RPSL or RPSLng" issue
> > here, not sure.
> >
> > Or, there could be some other approaches, I don't know. These might not
> > even require modifications (at least major ones) in the RPSLng spec. But
> > this seems like a subject which is non-trivial and bears some thinking
> > about... *before* we set off to really deploying RPSLng!
> >
> > We've been learning that lesson with the IPv6 transition work. Folks
> > probably thought it would be trivial, at first, and didn't pay attention
> > to the operational details..
> > =====
> >
> > --
> > Pekka Savola "You each name yourselves king, yet the
> > Netcore Oy kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >
> >
> > _______________________________________________
> > Rps mailing list
> > Rps@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rps
>
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings