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

On Mon, 15 Sep 2003, Curtis Villamizar wrote:
> 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.

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 be 
different anyway.  I believe I gave a couple of points to consider as 
well.

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

Right.. but it has gotten nowhere in about five years if 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.

This is irrelevant: the fact stands that at least in the RIPE region (I
don't know much of the others, but I guess the situation is pretty much
the same), RPSLng has *not* been deployed at all.  So, it seems to me that
any statements of its wide use are quite questionable.

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