RE: summary of the discussions so far

[Marc Blanchet <]

At/À 15:39 2001-10-26 +0200, Peirens, Bart you wrote/vous écriviez:
> > While there is a limited number of software that we know are
> > working on the
> > registry (as opposed so smtp clients/servers for example), we
> > should not
> > design the new language spec on the specific behavior of one
> > specific software.
> >
>
> wasn't RPSL exactly designed to avoid these complex migration periods of
>  running dual database systems for a limited amount of time?
agreed.  However, how can we transition without dual databases? see below.


> all 10.x parts of rfc2622 clearly state this as well.
yes and agreed.


> ===
> 10.4 Extensions by changing the syntax of existing RPSL attributes
>
>    If all of the methods described above fail to provide the desired
>    extension, it may be necessary to change the syntax of RPSL. Any
>    change in RPSL syntax must provide backwards compatibility, and
>    should be considered only as a last resort since full compatibility
>    may not be achievable.  However, we require that the old syntax to be
>    still valid.
>
> ===
>
> exactly the fact that we had to run parallel systems for quite some
>  months with the ripe-181 -> RPSL change shows that these 'limited'
>  use is still considered a quite important amount....
exactly.

so how can we manage this "transition"? The key issue, to me, is that it is 
still a database, which means that it is a storage of information which is 
read by multiple agents. There is no easy negociation like with a protocol 
which could handle versioning by describing the version of the protocol at 
the beginning of the exchange and having clients and servers behave 
accordingly to the negociated version.  Here, using the same illustration, 
with the database, we essentially have only clients, no servers, (unless 
the server does the tricks of versioning).

It is quite sure that the old syntax must be valid. This is the easy part.
However, as soon as you introduce things that were not in the original 
syntax, then the database now has new things that old software does not 
understand.

The only way to have very good confidence that the new syntax will not 
break old software is to only define new objects, not change anything in 
the current objects and replicate every needed object in the new namespace. 
All those new objects will not be recognized and hopefully be discarded by 
old software.

Another way to say what I tried to say: having a complete new namespace 
does not make sense to me.
If we agree on this (no complete new namespace), then that means that we 
have to live with modified objects and new attributes which will be 
probably badly handled by old software. So the discussion on which one will 
have more or less impact, to me, is mostly irrelevent.

Correct me if I'm wrong.

Marc.

> -----Original Message-----
> From: Marc Blanchet [
	    
	    
]
> Sent: Friday, October 26, 2001 2:54 AM
> To: Florent Parent; rpslng@localhost
> Subject: Re: summary of the discussions so far
>
>
> I think the discussion on the fact that current software
> break may not be
> the right way to discuss this.
>
> I would recommend to:
> - think about being as compatible as possible with the
> previous language
> definition
> - but keep the design clean and right
>
> I think the problem with compatibility will be essentially
> similar whatever
> we introduce new attributes or new objects.
>
> However, the right way to think about this compatibility
> issue is probably
> more related to deployment of the new database.
> As an example,
> - having the old format being in one database instance
> - and having a new database instance containing the previous database
> (synched) together with the new objects
>
> old software connects to the first database instance
> new software connects to the second database instance
>
> kill the old database after sometime.
>
> That way, the issue of compatibility is more a deployment
> issue than a
> language compatibility level issue.
>
> my 2 cents.
>
> Marc.
>
>
> At/À 09:32 2001-10-23 -0400, Florent Parent you wrote/vous écriviez:
>
> > >From the discussions so far, it seems that we need to carefully
> >consider the advantages/drawbacks of introducing new classes and
> >attributes to support multicast and IPv6.
> >
> >Adding new classes and attributes allows us to keep good backward
> >compatibility: The legacy tools should simply ignore the new objects
> >and attributes.
> >
> >On the other hand, one can argue that IPv6 addresses can be used in
> >the current attributes and these IPv6 objects should only be used by
> >tools that have been designed for them. This needs further
> thoughts as
> >that there are cases where you need to distinguish between the afi
> >IPv4/IPv6 (ie. type of routes exchanged in import/export)
> >
> > >From the proposals and comments seen so far, I believe we
> have these 2
> >"views":
> >
> >Don't break current software
> >Define new objects and attributes for IPv6
> >Define new attributes for multicast
> >
> >Allow IPv6 in current attributes
> >Let the software sort the address family (or identify the
> address family)
> >May require some transition period for new tools
> >
> >------------------------------------------------------------
> >
> >Below, I've tried to summarize the different proposals, adding some
> >benefits (+) and drawbacks (-) for each. I find this a
> useful exercise
> >to get a good idea on where the issues are. Please send me
> any changes
> >required.
> >
> >Introducing a new attribute or new class is being considered a (-) in
> >the text below. How much of a drawback is left to be discussed.
> >
> >route
> >-----
> >New attribute to distinguish between unicast/multicast
> >New object route6 for IPv6
> >
> >+ route6 shouldn't break current software
> >- Adds new class and attribute
> >
> >New dictionary element "address-family" or "afi" to distinguish
> >between ipv4|ipv6|ipv4-multicast|ipv6-multicast in attributes
> >
> >+ No new class or attribute
> >- current software can choke on new "afi" syntax in new objects
> >
> >Rely on the user software to determine what type of address in in the
> >route object.
> >
> >+ No changes in RPSL
> >- Can break current software that does not support IPv6
> >
> >
> >inet-rtr
> >--------
> >New attribute if6addr.
> >New attribute peer6.
> >
> >+ doean't break current software
> >- new attributes
> >
> >Rely on the user software to determine what type of address in in the
> >inet-rtr object.
> >
> >+ No changes in RPSL
> >- Current software can choke on unexpected IPv6 addresses
> >
> >route-set
> >---------
> >New attribute members6
> >
> >+ doean't break current software
> >- new attributes
> >
> >New dictionary element "address-family" or "afi" to distinguish
> >between ipv4|ipv6 in members attribute
> >
> >+ no new attribute
> >- current software can choke on new "afi" syntax in new objects
> >
> >Just add IPv6 addresses in members attribute, rely on
> software to sort
> >things out.
> >
> >+ No changes in RPSL
> >- Current software can choke on unexpected IPv6 addresses if they
> >   reference them
> >
> >aut-num
> >-------
> >New option "nlri_afi" or "afi" in BGP4 protocol spec
> >New attributes import6/export6 to specify IPv6 peering
> >
> >New dictionary element "address-family" or "afi" to distinguish
> >between ipv4|ipv6
> >New attributes import6/export6 to specify IPv6 peering
> >
> >Allow IPv6 addresses in import/export attributes (peering) and use an
> >"address-family" identifier to indicate the type of routes exchanged
> >(ipv4|ipv6). Multicast can be specified as an "action" on the nlri.
> >
> >
> >--
> >Florent Parent
> >Viagénie inc.  http://www.viagenie.qc.ca
> >+1.418.656.9254 x 227
>
>
> -------------
> Marc Blanchet
> Viagenie
> http://www.viagenie.qc.ca
> tel: +1-418-656-9254 x225
> -------------
> IPv6 easy connectivity: http://www.freenet6.net
> RFC/W3C/IANA searchable repository: http://www.normos.org
> -------------
>

-------------
Marc Blanchet
Viagenie
http://www.viagenie.qc.ca
tel: +1-418-656-9254 x225
-------------
IPv6 easy connectivity: http://www.freenet6.net
RFC/W3C/IANA searchable repository: http://www.normos.org
-------------