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

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 Savola 
> 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 inaccuracies
> >  
> > > > 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 cause 
> > 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!

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

> > > >  * issue 5) and others-- whether the document needs to specify all the
> > > > relevant modifications explicitly, or not.  IMHO, Stds Track document 
> > > > should describe every change, not just say something like "other 
> > > > attributes are modified in a similar fashion" (or something to that 
> > > > effect)
> > > 
> > > There is no need to repeat lengthy syntax descriptions contained in
> > > the base RFC if a straightforward modification is being made.  The
> > > example you gave points to text that is perfectly clear.  The existing
> > > <filter> accepts IPv4 addresses.  The <mp-filter> allows either IPv4
> > > or IPv6 addresses to be specified.  Perhaps this statement could be
> > > worded differently, but the syntax definitely should not be repeated.
> > > The syntax definition in RPSL remains authoritative except the
> > > additions defined here and no definitions that are not being changed
> > > should be included.
> > 
> > I'm not sure if all those modifications are completely straightfoward.
> 
> That's fine.  Sometimes when something has been in use for a while the
> people that have been using it won't see an ambiguity or ommission
> because they already know how things work.  Please be specific if
> there are instances of this.

I think I've already pointed out some of those.  All in all, I think *at 
least* the document should mention which things are being changed, and how 
(e.g. as a list, even if not "repeating lengthy discussions").

> > I don't see Updates like that at all.  What you're describing would seem 
> > closer to "Obsoletes".  This spec DOES make changes/additions to the 
> > existing sec, e.g. at rp-attribute next-hop.
> 
> It makes additions only.  For example, IPv6 changes to next-hop only
> apply to IPv6 static routes.

But still, it changes the rp-attribute.

> > > > 2) one important aspect to consider is interaction with old specification
> > ,
> > > > that is:
> > > > 
> > > >    Keeping this in mind, the "import:", "export:", and "default:"
> > > >    attributes implicitly specify IPv4 unicast policy and remain as
> > > >    defined previously in RPSL, and new multi-protocol (prefixed with the
> > > >    string "mp-") attributes are introduced. These will be described
> > > >    below.
> > > > 
> > > > ==> so, should one get information from both the RPSLng multiprotocol
> > > > attributes and the old ones?  What if they conflict?  Maybe some words wo
> > uld
> > > > be useful on how to effectively transition/co-exist with both RPSL and
> > > > RPSLng?
> > > 
> > > See prior note.  Not an issue.
> > 
> > Not so sure on that.
> 
> 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.

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