Draft of RIPE81++

Elise, Tony & al.

>----- Text sent by Tony Bates follows -------
>  epg at merit.edu writes:
>   * 
>   * 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.

When  I  proposed  together  with  Tony  to  put  this  attribute
mandatory,  I  would  not  have  thought  that  we would create a
revolution :-) 
Elise, I agree with you, there's no need to register  information
you don't need, it's more difficult to manage, but as Tony points
out, why would anybody need this detailed information unless  you
really  want to configure a box with it, in which case you *need*
the local and remote addresses.  Well, I don't know  the  answer,
but  you  probably have such a case, otherwhise you would not ask
for it :-) What I would propose is to:

1- Keep the ordering as it is in Ripe-81++ (to be  close  to  the
as-in syntax),

2- Accept the Local and remote router info to be optional

3- Solve the parsing issue by adding what Jessica proposed (L:... R:...)

Well, I'm not sure I do agree with what I write, but if I can get a
consensus ...

>   * 2) the mandatory nature of asin/out attributes if interas attributes are
>   *    present
>   * 
>   * 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

Tony, the question is not answered, Elise is right. This AS will have a line
like

as-in: from AS690 ?? accept 237

since as-in IS mandatory. What pref should I use? *I* have no answer to this
one!

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

Interasin will give details on as-in. There's several ways to remove the
dupplication of information:

1- If interasin is present, as-in is refused (berk!)
2- put interasin and as-in optional, but how about a policy without any
interasin nor as-in ? ;-)

Personnaly, I don't think that the majority of the policies  will
use  the interasin and I would prefer to keep the dupplication of
information by keeping as-in and interasin (with as-in mandatory,
and  interasin  optional),  providing  we  can find a solution to
preference issue in as-in...

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

I support this as well.

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

I also support this, and I will discuss it with Wilfried.

-- 
Jean-Michel



-------- Logged at  Tue Sep 6 22:56:11 MET DST 1994  ---------