Re: summary of the discussions so far

[Marc Blanchet <]

I think the discussion on the fact that current software break may not be 
the right way to discuss this.

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.

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