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

From: Curtis Villamizar <[email-masked]>
Date: Fri, 19 Sep 2003 15:07:03 -0400

Larry,

Good to hear from you.

Comments inline.  I think we can converge on something that we can all
live with by just adding a transition issue appendix and deciding what
needs to go into it.

Curtis

In message <[email-masked]>, "Larry J. Blunk" writes
:
>  Pekka and Curtis,
>    Thanks for the feedback.  Sorry for not responding sooner (I've
> been trying to absorb everything and formulate a response).  I've
> been updating the draft to reflect many of your comments
> (thanks, Pekka).
> 
> 
> On Fri, 2003-09-19 at 03:21, Pekka Savola wrote:
> > 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.
> 
>   I think there indeed needs to be some text to clarify the use of
> mp-* and non mp-* entries.  Should the document recommend the use of
> non-mp entries to express v4 policies for existing non-RPSLng
> compliant tools?  Should this be mandatory or optional?  And perhaps
> more controversily, if there are mp- attributes present in an object,
> should the non-mp attributes be ignored by RPSLng compliant tools
> to reduce the possibility for conflicts.

This is strictly a transition issue and a strong recommendation to
specify non mp-* for IPv4 should be made for initial transition
purposes.  See comments below about eliminating this need with better
server code.  Any such recommendation should be in an appendix on
transition issues, not in the main body of the document.

>   Further should there be clarification on the case where an import,
> export, or default attribute references a route-set/filter-set/etc.
> which contains mp- attributes?  Should RPSLng compliant tools ignore
> the mp- attributes in this case (as non-RPSLng compliant tools would
> do).
> 
> > 
> > > For backwards compatibility the ipv4
> > > unicast policy will be in the same database but at least initially
> > > expressed as non- mp-* policy statements. 
> > 
> > Right.
> 
>   One option I thought about would be to change the mp-members,
> mp-filter, mp-peer, mp-peering, and interface attributes to be
> IPv6 specific.  In other words, rename them to something like
> members6, filter6, peer6, peering6, and interface6 (well, perhaps
> not the interface attribute since it introduces new functionality).
> This would preserve explicit support for backward compatibility
> with IPv4 as one would need to continue to express IPv4 prefixes
> and policy info in the existing RPSL attributes.
> 
>   I think backward compatibility in these attributes is more
> important than the import, export, and default attributes as
> I believe one is more likely to reference another org's route-set,
> filter-set, etc., than another org's aut-num object.
> 
>  -Larry Blunk
>   Merit

It would be best if old clients could be recognized.  This would mean
conversion to new server code only before mp-* could be freely used.
At that point when an old client is recognized all mp-* attributes can
be returned with s/mp-// as long as they apply to IPv4.  With the
server code hiding the mp- stuff a query that hits an mp-import
or import that referenced an mp-filter or filter would alway be
returning just a import and filter to the older client.

This is not so much an issue for the spec as it is for the
implementation and a transition consideration for deployment.  It
doesn't hurt to mention the issues in the spec, but there is no need
to change the spec.

There is always a need to make a smooth transition.

Rather than change the spec to make mp-peer etc into peer6 etc, leave
the spec as is but for early transition only accept a mp-peer if it is
specifies a non-IPv4-unicast peering.  When the server code is updated
in enough places you can accept a mp-peer that specifies ipv4 but
return a plain peering to older clients.

_______________________________________________
Rps mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rps

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 18 Sep 2003 14:18:30 -0400

In message <[email-masked]>, Pekka Savola 
writes:
> On Tue, 16 Sep 2003, Curtis Villamizar wrote:
> > In message <[email-masked]>, Pekka Sav
> ola 
> > writes:
> > > On Tue, 16 Sep 2003, Curtis Villamizar wrote:
> > > > In message <[email-masked]>, 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
> 
>