Draft of RIPE81++

 epg at merit.edu writes:
  * 
  * Daniel, Marten, and Tony,
  * 
  * We'd like to discuss three parts of the draft prior to the
  * RIPE meeting in Portugal.  They are:
  *
Okay...here are my comments below. 
 
  * 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. 
  *
But surely by its very nature the attribute is a two way attribute and
we want to encourage people to update when they make a configuration
change. This is meant to contain this information. Also, what is the
semantic of just registering your own side anyway. How is one supposed
to work out the other side if you have multiple connections to an AS.

  * 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.
  *
Perhaps, but this is somewhat double edged as you also want to see the
ability to just (as it is optional) register the remote gateway as
well which appears to contradict both above points.

  * 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.  
  *
I dont agree on the inconsistencies. The type of people who will use
this attribute will know what their peers AS routers are. Lets face it
who runs there BGP peering without configuring the remote peer address?
 
  * 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.
  * 
Sure but this is not mandatory for solving the 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
  * 
Well perhaps it may have seen that way but this is probably due to me
copying in Jessicas text without checking properly. When discussed
here and with John-Micheal we would like to keep this mandatory. I
truly believe porviders will know both ends of their peering and are
as likely to update both address as much as they are to use this
attribute and update other policy information.

  * 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.
  * 
Sure - but for many they will use and understand the as-in/as-out
attrbiute. So it is an extras line of information but represents the
global routing policy.

  * 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.
  *
No not at all - at the AS level this is totally correct. If I am AS99
I dont care about the interactions of between AS690 gateways, only
that it accepts routes for AS237

  * 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.
  *
Yep - the fact remains though that extra information will be minimal,
will make it clearer for some - this was expressed at the RIPE
meeting. 
 
  * 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.
  *
Well I think the only thing we can do on these two points 
is put both arguments to RIPE routing group at the RIPE meeting and
let them decide.

  * 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.
  * 
I think this is a good thing to do as well. I am going to add this
into the text later today. I will leave in description as well. One
problem we have in terms of backward compatability is I will have to
make AS name optional. Is this going to cause you a lot of heart burn
otherwise we have yet another tranisition to do.

  * 4) the proposal for a change time attribute
  * 
Firstly, as said before this is totally outside the context of
RIPE-81++. I know what the suggestion is and has already been put by
Laurent to the DB wg. As far as I remember it was deemed "not worth
doing" by the chair. Please send a message about this again if you
want to see any progress on this I would say.


		--Tony.



-------- Logged at  Tue Sep 6 15:11:43 MET DST 1994  ---------