extensions to the registry

Daniel,

> From dfk at ripe.net Tue Mar 22 07:53:16 1994
> 
> To add to Tony's comments with which I agree.
> 
> - I personally do not like the [to] [from] etc. syntactic sugar.
>   Users who want a more comfortable input language, should use a local 
>   post/preprocessor which we should provide.
>   If the routing registry itself (view it as a database) provides different
>   representations we will get lots of confusion as to the semantics.
>   Also all tools using the RR will have to accept multiple representations
>   which is only adding possibilities for bugs and general entropy

The main reason that [to] and [from] are not stripped prior to entry
in the DB was that it made it easier to have "user friendly" responses
to whois queries that stated policy. The translator will strip the
keywords from the ripe-alike file. You make a good point and we
will discuss it further.

> 
> - The RIPE-81 as-out does *not* have a preference for a reason.
>   I (think I) know what you want to do, BUT ...

We went around and around about this one, and decided to test it.  Admittedly
you can not force compliance to an as-out preference.

>   Try to define the semantics in a clear, concise and understandable way! 
>   I cannot.
>   This will also obscure the principle of what as-in and as-out really means.

Not convinced that this obscures the principle of as-in and as-out.

>   This will lead to confusion even if its optionality and advisory nature 
>   is clearly marked.

Since we still accept the less complex descriptions why should this lead to
confusion - especially if we document it well.

>   The only gain obtainable from it is some conistency checking implementable
>   only if the full topology is known.
>   Rather use as-exclude and as-transit for this as these are clearly non-local
>   attributes.
> 

> - Usage of communities must be clearly flagged with the potential problems
>   w.r.t. implementability. The only way I see it implementable is network
>   based lists, now that the BGP4 folks have withdrawn the path attribute from
>   the spec. It also needs to be mentioned that using them can potentially
>   hurt CIDR aggregation efficiency badly.

We will work on clarifying the documentation.

> 
> - I like the as-exclude attribute (without syntactic sugar)
>   It needs more language about that this can be implemented in two ways:
> 
> 	- using path info by the AS registering the as-exclude
> 
> 	- filtering implemented by the AS mentioned.
> 
>   The second is advisory in nature but should be encouraged. It needs
>   language that filtering by the AS mentioned is quite OK based on the
>   as-exclude etc. pp.
> 

More documentation work - guess that's why we have drafts.

>   This also means we need a way to provide server functionality of the type
>   "tell me all ASes mentioning ASx (me) in as-exclude!" At them moment we
>   can get this from the full database file but this does not scale.
> 

Is this what is called job security - there is always something else
that has to be done? ;-)

> - as-transit can be quite usefule but needs a better definition of semantics 
>   It has similar problems as as-out preferences: You need the whole graph.
>   But these are more acceptable here as as-transit is clearly not local.
>   It also needs a section on how this can be implemented. 
>   And its advisory nature.
> 

Again better documentation.

> - border router level
>   this should not go in the as-out attributes but rather be a separate
>   set of attributes line "link-out" "link-in" with a requirement
>   to have the as-in and as-out as well. this way you get an optional level 
>   of complexity.
>   Otherwise it looks fine.
> 
> - database selector
>   same problems as community
> 
> In conclusion I personally would be very unhappy if you folks announced a 
> registry using this stuff tomorrow. This needs some solid design sessions
> where semantics are clearly defined and we can discuss what is needed and
> what is fluff. Finally this needs some test as to wether people actually
> understand it (the same way).
> 

Daniel, we really have discussed this in great detail and have approached
Andrew and Bill to test things. It is understandable that before you all
would like to adopt this that you would like to have further discussions
with us.  Bill has looked at it a bit, but Andrew let us know that this was
low on his priority list.  So we would like to go ahead with the announcement
of the Merit Routing Registry. We will try to make it clear that the straight 
RIPE-81 syntax is perfectly acceptable, but that if folks have routing requirements
that may not be accomdated by the more standard syntax, there is a way to describe
more complex routing policies.

> I strongly fear that adding too many features at this point in time can 
> provide enough problems to make this whole RR idea fail. 
> I do not want that to happen.
> 

We do not want this whole RR idea to fail either. We are willing to float
the extensions as a test to see if folks say that the extensions are too
complicated. If that is the case, we are still able to accept the RIPE-81
syntax.  So it seems like the result would be that technical folks would
reject the "complex" and accept the "simple." We (RIPE and Merit) would
still have the minimum set of information registered and there would be
two active registries.

> Another *very worthwhile* idea is to make much more clear what is basic
> functionality and what is enhanced functionality.
> 
Point well taken.

> Please do not understand these remarks as antagonistic or de-valuing your
> work. Due to resource-sacrceness over here you are very much leading
> the way for extensions. I apreceiate that very much. My overwhelming
> concern is to not de-value the RR concept by making it overly 
> complex.
> 
We are in complete agreement in your concern to not de-value the RR concept.

> Daniel
> 
> PS: I am missing the aggregate stuff.
> 
We would like to discuss the possibility of actually just adding
an attribute to intnum - say creator - which would indicate who
originated the net/length registration.  The idea behind having
only one "classless" net object (instead of a network object and
an aggregate object) is to move away from the idea of classful
nets.  After all who is to say what the intnum registration should
be in a classless world - is 35/8 a network or an aggregate? Just
a thought.
      --Elise

            --Elise





-------- Logged at  Wed Mar 23 16:29:32 MET 1994  ---------