Diagnostics from 181 analysis tool

>From the text description of the Route Object (ripe-181 5. p12):

  "Special cases:  There can only be a single orginating AS in each
  route object.  However in today's Internet sometimes a route is 
  injected by more than one AS.  This situation is potentially dangerous
  as it can create conflicting routing policies for that route and
  requires coordination between the originating ASes.  In the routing 
  registry this is represented by multiple route objects.

  This is a departure from the one route (net), one AS principle of the
  RIPE-81 routing registry.  The consequences for the different tools
  based in the routing registry will need to be evaluated and possibly
  additional consistency checking of the database is needed."

As far as I have been able to figure (and I've raised this before on this
list)  there are only three situations where a single Route will be mapped
to more than one AS:

  1) A Proxy Aggregate is being created simultaneously by too peers of
     an AS or of a region.  
  2) One (or more) of the "identical" aggregates is marked "withdrawn"
     (e.g. something once announced by ASX has moved to ASY;  ASX
     continues to register it with the "withdrawn" attribute for historical
     documentation.)
  3) There is a detectable mistake in the database (not entirely unlikely
     while we work out the complications of multiple geographically dispersed
     portions of the Global Routing Registry).

Can we all agree that "withdrawn" routes should be specifically excluded
from all normal policy analysis and configuration file generation?  That
eliminates condition #2.

I think we should also eliminate consideration of #3:  This kind of problem
needs to be solved, but not by the analysis tools or config file generators.

That leaves only condition #1:  dual proxy aggregation.  

Assume ASA and ASB are creating proxy aggregate P for their neighbor ASC. 

  Any policy specifying "ASA OR ASB" will get P.
  Any policy specifying "NOT( ASA OR ASB )" will not get P.

Neither of these cases is troublesome.

  Any policy specifying "ASA AND ASB" will select *only* those Proxy
  Aggregates being created by both ASA and ASB.

  Any policy specifying "ASA AND NOT ASB" will select ASA, setminus
  the shared proxy aggregate P.

These are *only* useful when someone specifically wants to detect the
situation of dual proxy aggregation, and to tailor his policy around that
situation.


Proposal:
---------

How about if we keep the problem of Dual Proxy Aggregation in mind, and
prepare to change our code to deal with it sometime in the future when we
figure out what is really needed to handle it.  But for the time being,
unless somebody can find holes in the arguments above, I'd say we continue
to code config file generators (and Route Servers) assuming that users
will either be willing to accept *all* versions of a Proxy Aggregate, or
that they will want none of them.  We can even detect the few expressions
that are probably empty (ASA AND ASanything_else) and issue warnings.
We *do* need options in the parser to handle these cases, so we can do
analysis on them later.  But for the normal applications lets postpone
this complicating factor, and support a level of analysis where ASA AND
ASB --> NULL.


Have I goofed in this analysis?

--Dale


===========================================================================

> 
> Marten Terpstra (Marten.Terpstra at ripe.net) on October 25:
> > 
> >  * > I have partially tested the partial evaluator.
> >  * > Remember the examples which I picked from Ripe database with ambiguous
> >  * > use of AND/OR/NOT. 
> >  * > Here are the results of partial evaluation on these examples:
> >  * > 
> >  * > peval NOT AS1729 AS1741 AS1755
> >  * > Evaluates to:
> >  * > (NOT(1729 ))
> > 
> > Well, I do not know. Doesn't this say:
> > 
> > AS1741 OR AS1755 OR NOT AS1729
> > 
> > In which case the OR NOT AS1729 is superfluous ...
> 
> My first thoughts:
> Actually AS1741 and AS1755 are superfluous since they are included in
> NOT AS1729 (see the example in Ripe-181).
> 
> My second thoughts after your explanation for "AND":
> "AS1741 OR AS1755 OR NOT AS1729" can not be further simplified because
> either "AS1741 AND AS1729" or "AS1755 AND AS1729" may be non-empty.
> 
> Hence the example in Ripe-181 is wrong. 
> I think when Tony wrote that text, the route-AS relation was still many
> to 1.	
> 
> > 
> >  * > peval NOT \(AS701 AND AS174 AND AS1133 AND AS1800 AND AS2044\)
> >  * > Evaluates to:
> >  * > ANY
> > 
> > Not true. What f there is a route orginating in all these ASes? It
> > should be denied .....
> 
> You are right. That is "AS701 AND AS174" may not be empty since the
> route-AS relation is now many to many (i.e. a route may belong to more
> than one AS). 
> 
> Actually I was under the impression that a route belonged to one AS
> till last Sunday when I talk to Dale and Rick on this. Dale told me
> that new text was added recently for this. And I have been reading only
> the appendices in the last few versions of Ripe-181.
> 
> peval can handle this form of evaluation as well. We will evaluate
> ASnumbers symbolicly (just like macros and community names) until
> level 4 where everything become network lists.
> 
> Thanks,
> 
> Cengiz
> 
> -- 
> Cengiz Alaettinoglu       Information Sciences Institute
> cengiz at isi.edu            University of Southern California
> 
> 



-------- Logged at  Thu Oct 27 22:31:39 MET 1994  ---------