[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard
In message <Pine.LNX.4.44.0309191015080.29158-100000@netcore.fi>, Pekka Savola
writes:
> 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.
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.
Regardless, for a transition period you have duplicate entries if the
policies were identical. One entry would be in import (for IPv4) the
other would be otherwise identical mp-import for
ipv6,ipv4-multicast,ipv6-multicast. If the server side can recognize
older clients, then the inconvenience of duplicate entries can be
elimitated. See paragraph below.
> > 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.
> > 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.
Curtis
> > > ======
> > > "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 RPS
> L
> > > 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