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

[Curtis Villamizar <curtis@laptoy770.fictitious.org>]

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 <1063981473.3370.23.camel@ablate.merit.edu>, "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.