Draft of RIPE81++

 epg at merit.edu writes:
  * 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.
  * 
Well..perhaps you have a point here...not sure though.. as we have modified it
(it accepts netlists now). When we looked at it the only time MEDs were
used were in the interas scenarios though right ?.

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

Now you are right about refining a kludge (IMHO somewhere we turned the whole 
thing into a kludge). However, I think the focus is still
there of what (at least in my mind) interas is tying to define and it
is what is depicted in the example. How to document more than one inter-AS
conection between two ASes.

  * 
  * So now for the responses to your responses....
  * 
  * 
Okay, 
	I also am going to try to chop some of the text 
as already some of this is confused which what is mandatory and what is isn't.

  * 
  * 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.
  * 
But how does this not fit into all stated. Barrnet clearly has a general
policy (as-in/out) between Barrnet and AS690 (the union the two sets of 
routes) and clearly has a policy describable by the interas attributes ?

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

Well then we are dead in the water then. How do we use tools without both ends
? - How do people understand the policy with ESP of the topology  ? 
Even worse - if we assume people dont register except their info. why 
both at all ?

  * > >   * 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 decla
  * re 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?
  * 
Nope - you are not under a mis-conception. They are both mandatory for reasons
above. They can be changed if people agree and I can just be on my own on this
one (no problem with that). But, let me re-iterate, they are not mandatory to
solve the ambiguity problem or to force our ordering. They are mandatory so the
provider documenting policy knows both end of the link. He has to know this.
How many people have a passive BGP connection that does not care who connects
to them ?

  * > 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:
  * > 
Wait though by proposing this we have them optional - Question is can you give
a case ? and even if it exists are they changing so often and will be
maintained by providers who wont update (hard to answer but important to
issue).

  * > 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
  * 
My last try on this. It is obvious to solve ambiguity - there are a million
different ways - I am not making them mandatory for this reason. The question is
how we will use them if they are optional and should we make the assumptionthat
users of the registry only care about there own data. Also, please tell
me how this all fits (in terms of reasoning for optional is we have only
a remote gateway registered - this just turns the whole argument upside down).


  * > Well, I'm not sure I do agree with what I write, but if I can get a
  * > consensus ...
  * > 
Me either (referring to Jimi suggested resolution) and I would like 
to see if we do need to go to consensus on this that this is decided at the
RIPE meeting.

  * 
Jimis text cut. Firstly, as-in is not mandatory - lets be clear on this.
However....

  * 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.
  * 
This is the one tricky one. I say yes it should become mandatory in the
presence of a corresponding interas attribute so that the global info is clear.
This is purely a clarity argument. If I understand the original argument for
this was against duplicity of info. This I (always I - just my own view ;-))
beleive is very little extra info and far outwighed by some making use of the
global info. Again as soon as I am once removed from the AS the local info is
of zero consequnce but the global info is.

  * 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.
  * 
It will not misrepresent but just have some levels of granularity. I believe
on a personal view we compromised the registry the day we added the extra
complexity (hows that for restructuring above ;-)) but I guess thats another
story.
  * > > 
  * 
  * 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

Right - lets drop this (is as-in mandatory confusion) before we start.

  * 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.
  * 
See above for why I like this.
  *  
  * > 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.
  * 
Agreed ;-). confusion confusion.

  * > >   * 3) the proposal for an asname attribute
  * > > 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. 

But... this constitutes a change of data and hence a transition. We would make
it optional for a period of time and then up it to madatory. This way
not everyone has their entry bounced to start with and we can let then
come in. We have three transitions to do for the RIPE routing registry and
to have to change all AS objects is gonna be too much I fear. 
This also fits into your tool algorithm above. 

  * 
  * > >   * 4) the proposal for a change time attribute
  * 
  * OK, we'll lobby the DB working group.

Fine.
  * 
		--T



-------- Logged at  Tue Sep 20 15:57:02 MET DST 1994  ---------