Draft of RIPE81++

Daniel, Marten, and Tony,

We'd like to discuss three parts of the draft prior to the
RIPE meeting in Portugal.  They are:

1) the mandatory nature of the gateways in the interas attribute
2) the mandatory nature of asin/out attributes if interas attributes are
   present
3) the proposal for an asname attribute
4) the proposal for a change time attribute

1) the mandatory nature of the gateways in the interas attribute

We are concerned that requiring the identification of the local
gateway and the remote gateway in the interas attribute has two
problems.  The first problem is that of maintenance of the attribute.
If an AS is required to list both the local gateway and the remote
gateway, then the AS must update its registry information whenever
the remote AS makes any configuration changes. This could lead
to many inconsistencies within the database. 

The second issue is that by permitting ASs to just register information 
about a local gateway is in keeping with the principle of only entering
local information in the registry. If an AS wants to indicate
a local preference for a gateway independent of information about
another ASs border routers, that seems in keeping with the underlying
philosophy of the routing registry.

We suggest that making the listing of a pair of gateways mandatory
will lead to inconsistencies in the registry and therefore it
should remain optional.  However, we do realize that permitting
the registration of 0, 1 or 2 gateways with the proposed syntax 
can lead to ambiguity.  

Is there a way that we can leave the gateway statements as optional 
and clarify the ambiguity business? For instance, there are several 
ways to clarify this ambiguity.  For instance we could simply declare that
if there is one gateway, it is the local one.  There are also easy 
syntax change options, such as allowing the token "-" to stand for
one or both of the gateways to eliminate ambiguity.

We were in agreement until a few weeks ago that these would be optional
and to make them mandatory simply to resolve a syntax problem when
other solutions are available is a loss

2) the mandatory nature of asin/out attributes if interas attributes are
   present

There are three reasons that we oppose making asin/out mandatory
conditional on whether there is an interas attribute specified.

First of all, asin/out attribute is just a subset of the interas
attribute; therefore the requirement to repeat information from
the interas attribute in the asin/out attribute is redundant. It
brings no added information to the registry.

Secondly, there are cases where the information in the asin/out
attribute will not clearly reflect the interas information, thereby
presenting inconsistent information in asin/out and interas.  The
example of this is:

interasin:  from 690:1 lgateway1  rgateway accept 237
interasin:  from 690:3 lgateway2  rgateway accept 237

So if the user is required to register an asin attribute, what
do they choose?  Whatever the choice it will reflect acceptance
of AS 237 by AS 690, but the preference will be inconsistent
with the information described in interas.

Finally, by making asin/out mandatory with the use of the interas
attribute, we increase our chances of introducing discrepancies
into the registry whenever modifications are made to the registry.
Any updates that are made to an AS's information must be
repeated in both attributes.

Therefore we propose that the asin/out attribute and the interas
attribute should remain optional and uncoupled.  We propose
that users should be able to use none, one or both to describe
their local routing policy.

3) the proposal for an asname attribute

It seems reasonable to add an asname attribute because it
will simplify server client requests and is used explicitly
by some tools.  Just as netnames for IP addresses have proved
useful and are often listed independently, we think that it
would be useful to have an attribute which is explicitly
for AS names.  For example, the "AStrace" tool explicitly uses 
this information and AS names have proven useful in much of our PRDB work.

4) the proposal for a change time attribute

The suggestion to add an attribute which automatically
appends the time stamp of the change to that attribute
seems like a simple modification and one that would
provide another indication as to how current information is.
If someone were to check the registry twice in one day
for information, and the information had been modified
more than once that day, the time stamp would indicate
that.  

Also, there is a small chance that modifications might
arrive out of order due to network problems and the time
stamp would be a good way to insure that older information
does not override current information.
 
The change time attribute is another useful bit of
information if we need to do any problem diagnostics
and it doesn't require any dramatic changes to the registry.

Just as you all would, we would like to settle these
little issues as soon as possible so that the document
can be accepted at the RIPE meeting.  We appreciate
how difficult some of these discussions have been, but
we are just as anxious as you to move ahead and get
this implemented and operational.

        --Elise 
 





-------- Logged at  Mon Sep 5 14:01:07 MET DST 1994  ---------