more on prdb format

Marten,

  You raise a couple of really good philosophical issues here that probably
need some discussion.  (On the other hand, I wasn't present for the last
round of discussions, so maybe Dale just needs bringing up to speed).
I'll try to do one in this message;  a simpler one follows separately.

> I would like to keep the attributes as they are defined now as they are
> and any extra stuff needed should move to new (experimental)
> attributes. We can't have a stable set of attributes if we keep
> changing the form of them. This will confuse too many people.

In this case, I have placed some extra information at the end of an
existing attribute (EGP/BGP, and Active/Passive or Default/NonDefault).  
Assume for the moment that this information really does have to be
stored somewhere in order to be able to build configurations from the
data. Then there are a few ways we could handle this:

  1) Append the information to the existing attribute [as you found in
     our data now].  This probably violates the published spec (unless
     it actually doesn't *say* that you can't have any extra parameters
     at the end).  It can confuse people, as you mentioned.  But it does
     supply all of the normal information in a form usable by normal
     tools.  (As you mentioned, prtraceroute is using that information
     today).

  2) Create a parallel experimental attribute that is just like the 
     description above, but which has a different name.  Obviously I
     can generate my config files using that new attribute name.  But
     then we have a decision on whether I should be producing *both*
     attributes all the time, or just the new experimental one.  If I
     don't produce both, then prtraceroute (and future tools) have just
     gotten poorer because they have lost access to some valid data.
     If I do produce both, then everyone's data gets twice as complex.
     And we still introduce confusion because there is a new named
     attribute showing up in the GRR data.  (And everyone has to support
     this new attribute in their conf file).

  3) Instead of creating an experimental attribute that has all the
     information, create a different one that has only the new information
     (e.g. EGP/BGP/IDRP and "which end of the session" markers).  Now
     we still have all the disadvantages of #2 except for the replication
     of data, and we have a much tougher path to migrate to one sensible
     combined attribute later.  (The code to generate the configs happens
     to get a bit messier, too;  and this messiness means that people will
     make more mistakes in entering the data).

I think that part of the problem comes form having a specification
document that was frozen before implementations were built.  Mind you,
I am *extremely* happy that RIPE-181 was published and exists as a
[realatively]?  firm target;  this has put to bed a lot of previous
discussions about which ways of doing things ought to be chosen and
allowed coding progress to be made.  (And RIPE-122, which specifies the
inet-rtr).  But we need a method of modifying the document in minor
ways to reflect discoveries from implementation experience, and we
certainly need the ability to implement experimental changes in advance
of formal group acceptance of those changes.  Obviously, if the
eventual group decision is different than the draft implementation,
then the implmentation has to change if possible.  The IETF model of
"draft standards" is one model--I don't think BGP4 even has an RFC
number yet, even though it is the default current standard.  RIPE might
have a different solution ("draft-ripe-122-experimental-mods"?), but I
think *something* is needed.

The other half of the question is how to handle such experimental mods
in the GRR.  We have all ready discovered (I think) that there needs to
be close coordination between the internal attribute names of *ALL* of
the registries participating in the GRR.  (Merit is still sorting out
changes based on conf file changes going to 181, and our two new
attributes assigned this week need to be put into conf files by all
registries that are going to accept RADB or PRDB.db data, which is
probably all registries).  We could come up with models that strip such
experimental information in the transfer process.  This would be
relatively easy to implement, but it would produce most of the problems
listed in the numbered sections above (i.e. useful information would
disappear).  Or, we could implement a system to give rapid global
support for experimental changes:  a way to post drafts of experimental
changes, and to get support code for those changes (at least conf
attribute additions) to all GRR participants.  Or some combination.

My preference is for rapid support of some extensions that needn't
interrupt backward compatibility (e.g. new tokens at the end of an
attribute), along with guidelines and support procedures for
documenting and integrating those changes into all the registries.
Plus other (presumably slower) arrangements for more substantial
changes.  Eventually, all changes need to go through the group
process.  But whatever the procedures are or become, it must be
possible to build new things quickly, and then to bring discoveries
from those implementations into the standards process as they are
proven.  (Even if this involves filtering the new extensions from the
the transfer format files for a while).

Grist for the GRR discussions.

Thoughts?

--Dale

     

===========================================================================

>  * > - there are some extra keywords for the peer definition in an inet-rtr
>  * > which are not ripe-181, what are we going to do with them? Examples:
>  * > *pe: 144.171.1.254 AS2649 BGP passive
>  * > *pe: 192.231.238.3 AS2020 EGP def
>  * > 
>  * > According to the spec, after the protocol indication there can be an
>  * > optional AS number only ....
>  * 
>  * Yes, this is problem.  I doubt we can generate AS690 configs without
>  * this information, or that any else can generate their configs without
>  * it, either.  Suggestions?
> 
> Not sure. Perhaps we need some experimental extensions to the inet-rtr
> object... You are probably closer to knowing what you want than us. I
> would like to keep the attributes as they are defined now as they are
> and any extra stuff needed should move to new (experimental)
> attributes. We can't have a stable set of attributes if we keep
> changing the form of them. This will confuse too many people.
> 
>  * > - then the number of AS objects that have no policy information. May
>  * > of them have fake maintainers, many of them are European, and I
>  * > personally do not think they should be in the prdb (or rrdb for that
>  * > matter). 
>  * 
>  * Sounds like a problem for the GRR meeting at the IETF.  You don't
>  * want to throw away the AS-name information just because there isn't any
>  * policy registered for it, because then prtraceroute etc. become much
>  * less valuable tools.  There should be a good way of picking the "best"
>  * (or, probably, most authorative) source for data to be used by
>  * tools.
> 
> Definately yes. Let's take this up at the GRR meeting.
> 
>  * Eliminating maintainer objects for which we have no contact information
>  * has been on my queue for about three hours now;  that one will get solved
>  * when I get some time.
> 
> No problem, all these comments were purely things that I noticed. Now
> that we have a real spec in ripe-181, we should try and stick to it.
> We should start with a stable set and only after that move on.
> 
>  * >           What we have done at the NCC is simply place them in their
>  * > own little database (source NCC-AS-LIST) which is simply generated
>  * > automatically and provides at least a descr for all unknown ASes in
>  * > the RR. 
>  * 
>  * How is this different from having these little records in the
>  * prdb.db?
> 
> Slightly in semantics. The AS list we keep is not part of the routing
> registry as such. Again, we should take these issues up with the
> general data distribution model.
> 
>  * >         I think you should only register the AS that have policy info.
>  * > If not, the RRs have loads of overlapping and possibly inconsistent or
>  * > differently formatted information which is no good.
>  * 
>  * Again, refusing to know the name of an AS because they haven't yet 
>  * registered their policy strikes me as a bit self-defeating.  Overlapping
>  * and therefore potentially inconsistent data is probably the central 
>  * problem of the GRR;  we have it in a lot more cases than just this.
> 
> In my view (but I can be wrong) it is more what info is in a RR as
> opposed to info being used by the tools ... Not a big deal, a data
> distribution model should solve these things.
> 
> -Marten
> 



-------- Logged at  Thu Nov 17 18:47:31 MET 1994  ---------