[Rps] Re: Last Call: 'RPSLng' to Proposed Standard

In message <Pine.LNX.4.44.0309151040220.27172-100000 at netcore.fi>, Pekka Savola 
writes:
> I'm not sure if I agree with what you call "tough luck", but I've omitted 
> them from the response, as more arguing on those wouldn't seem to be 
> productive.
> 
> On Fri, 12 Sep 2003, Curtis Villamizar wrote:
> > In message <Pine.LNX.4.44.0309111134070.10628-100000 at netcore.fi>, Pekka Sav
> ola 
> > writes:
> > > On Wed, 10 Sep 2003, Curtis Villamizar wrote:
> > > > In message <Pine.LNX.4.44.0309101200110.30657-100000 at netcore.fi>, Pekka
>  Sav
> > > ola 
> > > > writes:
> > > [...]
> > > > > However, there seem to be a number of (more or less) textual inaccura
> cies
> > >  
> > > > > and confusion in the document, which should be settled prior to 
> > > > > publication.
> > > > > 
> > > > > I think there are the three most important issues here are:
> > > > > 
> > > > >  * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you 
> > > > > conflicting information about IPv4 unicast, then what?
> > > > 
> > > > Not an issue.  If only IPv4 policy is specified by a given statement,
> > > > then either the old form or the new form can be used.  Currently
> > > multiple import, export, and default statements can appear.  Their
> > > > effects are additive.  The effect of adding mp-* statements specifying
> > > > ipv4 using the longer syntax is the same as adding more of the
> > > > existing import, export, and default statements.
> > > 
> > > I'm not sure if I see it as the same.  The user running RPSL tool must
> > > check both the traditional and RPSLng entries.  This is a change.  More 
> > > likely than not, depending on the transition/co-existence plan, he will 
> > > also have to maintain records on both old and new.  This is bound to caus
> e 
> > > inconsistencies in the data.
> > 
> > The transition is quite easy.  The change adds mp-* but does not
> > depricate (ever) the use of the non mp- forms.  Just keep all the IPv4
> > unicast policy in the old form until conversion is considered
> > complete.  If it is never certain that conversion is complete, keep
> > the IPv4 unicast in the old form indefinitely.
> 
> "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!

Any AS object that provides policy already has many import and export
statements.  Today IPv4 and IPv6 policy does not match so different
statements are needed anyway.  For example, AS3561 has 737 import
statements and 738 export statements.  I would venture to guess their
IPv6 policy is a lot simpler.

> 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..

I had a lot to do with IPv4 deployment (NSFNET 1992-1995, ANS and
UUNET 1995-1998) and I had a lot to do with definition of RPSL and use
of RPSL.  Considering how long widespread IPv6 deployment has been
"coming RSN" the IPv6 world has got nowhere by comparison.  I suggest
you get off your soapbox and stick with concrete comments and
suggestions.

> > Its deployed so obviously it works.  We're not talking about something
> > no one has ever tried.  This is documenting a set of extensions that
> > are in use.
> 
> Being used by a few people and being used as widely as RPSL is used today 
> are two different things.  It is obviously not being used widely if RIPE 
> just got it's test version of the database and the tools out a month or 
> something like that ago.

Larry could probably give you the lineage of this work better than I
could.  I think David Kessens was working on expressing IPv6 policy in
RPSL as far back as 1997 or so.

RIPE uses its database mostly as a Internet address and AS registry.
That you can express policy in RPSL for RIPE is just an added benefit
for their customers.  RIPE has had IPv6 inetnum records for a very
long time for the purpose of address registry.

> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Curtis