[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.0309181408040.17750-100000@netcore.fi>, Pekka Savola
writes:
> On Tue, 16 Sep 2003, Curtis Villamizar wrote:
> > In message <Pine.LNX.4.44.0309162130570.24960-100000@netcore.fi>, Pekka Sav
> ola
> > writes:
> > > On Tue, 16 Sep 2003, Curtis Villamizar wrote:
> > > > In message <Pine.LNX.4.44.0309160816080.5651-100000@netcore.fi>, Pekka
> Savo
> > > la w
> > > > rites:
> > > > >
> > > > > Did you even read what I wrote? I certainly didn't see a problem in
> > > > > having different IPv6 and IPv4 records, because, well, they have to b
> e
> > > > > different anyway. I believe I gave a couple of points to consider as
>
> > > > > well.
> > > >
> > > > If you have no issue with separate IPv6 and IPv4 records then the
> > > > matter is resolved. There is no transition problem, nor is there any
> > > > long term problem other than separate IPv6 and IPv4 records which may
> > > > be a nuisance later at worst.
> > >
> > > I recall that RPSLng also supports ipv4.unicast (which is supported by
> > > RPSL as well), and ipv4.multicast. The issue is clearly not settled by
> > > that, I think,
> >
> > As far as I can tell you have made no point which has withstood
> > strutiny. If you think there is a problem, please state the problem
> > concisely.
>
> I'll just cut-n-paste my earlier response below. There are certainly open
> issues on keeping IPv4 unicast and multicast data in sync. Further, it
> might be desirable to have IPv4 unicast in the same database, so that you
> could just run the IRRToolSet (or some other tool) just once, from one
> database to get both v4 and v6 data, but this is a smaller point.
You seem not to be missing something. The mp-* and non- mp-* entries
will be in the same database. For backwards compatibility the ipv4
unicast policy will be in the same database but at least initially
expressed as non- mp-* policy statements. Since policy is currently
quite different between unicase and multicase and ipv4 and ipv6 this
is not only not a problem, it is not even an inconvenience. 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.
So none of your objections below are valid.
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 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