Diagnostics from 181 analysis tool

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 15:14:18 MET 1994  ---------