Draft of RIPE81++

Jean-Michel and Tony,
Thanks for your comments.  Let me preface my following responses with
a probably contentious statement (though I'm not looking for an
argument nor trying to start a fight) - we probably wouldn't be having
this debate if we had just modified as-in and as-out to optionally
include multi-exit discriminators.  Then there would be no need for
interas-in and interas-out and there would be no need to translate
from interas-in/out to as-in/out. But I acknowledge that you all do
not want to modify as-in/out and therefore if we are to support
multi-exit discriminators, we need to have a new attribute.

Just wanted to say that because as I responded to all this, it
seemed to me that we were trying to refine a kludge instead of focusing
on what we had started out to describe. Probably just grumpy 'cause
it's a nice day and I'm stuck inside.

So now for the responses to your responses....


>-----------------------Jean-Michel writes------------------
> 
> 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.
> > 

Guess, our thoughts on this are colored by working with folks like
BARRNET which have always had at least two gateways that peer with
our one gateway.  BARRNET has then preferred to accept one set of
nets at one router and the rest of the nets at another router.

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

Whereas someone will always configure their peer router, we're not
convinced that folks will show the same attention to updating the
routing registry.

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

Whoops, maybe I had a wrong assumption here.  It seemed to me that
the local and remote gateway characteristics of the interas-in/out
attribute had been changed to mandatory (whereas they used to be
optional) because with the selected syntax listing one gateway
only would be ambiguous.  Listing no gateways or two gateways is
unambiguous; it's only if you are permitted to list only one gateway
that there is no way to distinguish whether it is a local gateway or
a remote gateway. Have I made the incorrect assumption?

> >   * 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),
> 

OK

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

OK

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

OK

> 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!
> 

My assumption is that since neither as-in/out nor interas-in/out are
mandatory attributes within the aut-num object, it is unnecessary
to mandate a corresponding as-in/out attribute if there is an
interas-in/out attribute specified. The policy expressed in the
aut-num object should be the union of the as-in/out and interas-in/out
statements.

I think that we (both Merit and RIPE) have artifically added this
complexity because we all compromised on the way we added the multi-
discriminator information by creating a new attribute.  Since we
have done this, we should try to avoid mandating a situation which
will knowingly misrepresent registered information.

> > 
> >   * 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 ? ;-)
> 

Jean-Michel, as-in/out has never been mandatory - at least from my
reading of the documents.  So folks could previoulsy register an 
aut-num without registering any policy. If we want to mandate that
folks have to register policy in aut-num; then that is a different
reason to make as-in/out mandatory. But in that case mandating either
as-in/out or interas-in/out would suffice to meet the requirement.

Since as-in/out has never been mandatory, I do not understand why
it should be mandatory if someone chooses to register interas-in/out.

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

Repeat, of my previous comment - as-in has never been mandatory.

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

Tony, not heartburn, but it would be nice to make it mandatory
and grandfather in the data that exists without it.  And any tools
that need an asname can default to just returning the asnumber
instead. 

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

OK, we'll lobby the DB working group.

See you all in Lisbon.
          --Elise



-------- Logged at  Wed Sep 7 00:11:51 MET DST 1994  ---------