Draft of RIPE81++

Now, I know why I never joined a debate team....

>Tony Bates writes:
> 
>  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.
> 

It's probably too late to go back to our innocent beginnings, but it
would be nice to have one attribute - as-in/out which permitted the
simple case (from AS accept otherAS) AND the extended case (from AS
Lgateway Rgateway accept otherAS). The rules would be that it is
illegal to have only one gateway registered, but you could register
zero or two per as-in/out line.

So much for my daydreams.....

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

All I was trying to show was that there is a case where you want to
distinguish between two local entities (border routers) and 
their policies in relationship to a single remote entity (the remote 
border router). Yes, you need to know the remote routers ip address
to make a configuration file (duh!), so from a local policy perspective,
it's not necessary to identify the single remote router.

Not a big deal - just a preference.  

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

Actually, I was basing my opinion of the willingness of folks to update
a registry on the experience of SRI NIC, the InterNic and you all.
Seems like it's difficult to keep information current (I agree on the
necessity), and if there were less updates mandated for the local
person who didn't care if the remote end changed since it didn't
change the local person's policy, then we would have less chance
of inconsistencies.

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

OK, so what is illegal is to list only one gateway.  Can we just make
it illegal to list only one gateway, but to still have the <local
and remote gateway pair> optional?

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

And she repeats herself yet again....the point I was trying unsuccessfully
to make is that if the remote gateway changes (in my example) it is
a configuration change but not a policy change so therefore the local
person may not feel that it is urgent to update the registry.  If the
local person uses the registry to generate configuration files for the
local routers, you can bet your bippy that the registry will be updated.
If not, all bets are off.

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

Have to attend a meeting in about 2 minutes...will reply to this question
after the meeting...do I have to continue, or can we agree on zero or two,
with one being illegal?????

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

It would be nice if we could come to some conclusion...after all we are
really the only ones who argue in public :-)

Yikes - this note goes on forever....have to run...will try to respond to
the other zillion points later.
         --Elise



-------- Logged at  Wed Sep 7 20:06:25 MET DST 1994  ---------