forwarded message from John Scudder

Here is some feedback on the as-in interas-in interaction. The lines
that start with [ca] are my comments for clarification.

------- start of forwarded message (RFC 934 encapsulation) -------
Message-Id: <9502070119.AA27306 at yurt.merit.edu>
From: John Scudder <jgs at merit.edu>
To: cengiz at ISI.EDU
Subject: more on pol2filters prefs
Date: Mon, 06 Feb 1995 20:19:12 -0500

Cengiz,

OK, I would like to revisit this old topic.  I have two points:

1. As far as I can reverse-engineer it, the algorithm for writing the
   preference onto NSFNET gated.conf files is considerably less 
   elaborate than the one used in pol2filters/policyparser.pl.  Namely,
   for a given set of routes matching a given expression, e.g.:

# 66 (NSF_DB{ aslist == 6:293 }) AND (NSF_DB{ aslist == 6:293(145) })

[ca] 66 is the preference used by the config file generator. It is
[ca] calculated using the as-in, interas-in preference interaction.

   the preference is 105 + max(advisory_metric).

   In this case the preference is 111.

   This is pretty easy to express; less easy for me to figure out where
   to code it in.  The code in get_import_policy() seems to want to do
   everything based on interas-in and as-in.  What I need access to in
   order to write an NSFNET-compatible preference is the advisory stuff.
   
   Suggestions?  If all else fails I can parse the comment lines and 
   pull out the metrics, then rewrite the preference for the routes which
   follow.  But that's not my preference :-), way too ugly.

   As you know, I need to produce files which slavishly follow current
   conventions in order to pull this transition off...

2. I note that every so often pol2filters writes a comment line with a
   large expression like this:

# 63 (NSF_DB{ aslist == 6:293 }) AND ((NSF_DB{ aslist == 1:293 } NSF_DB{ aslist
== 2:293 } NSF_DB{ aslist == 3:293 } NSF_DB{ aslist == 6:293 } ) AND NOT (NSF_DB
{ aslist == 1:293 } NSF_DB{ aslist == 1:293(144) } NSF_DB{ aslist == 1:293(144)
} NSF_DB{ aslist == 1:293(144) } NSF_DB{ aslist == 1:293(144) } NSF_DB{ aslist =
= 1:293(145) } NSF_DB{ aslist == 1:293(145) } NSF_DB{ aslist == 1:293(145) } NSF
_DB{ aslist == 1:293(145) } NSF_DB{ aslist == 2:293 } NSF_DB{ aslist == 2:293(14
4) } NSF_DB{ aslist == 2:293(144) } NSF_DB{ aslist == 2:293(144) } NSF_DB{ aslis
t == 2:293(144) } NSF_DB{ aslist == 2:293(145) } NSF_DB{ aslist == 2:293(145) }
NSF_DB{ aslist == 2:293(145) } NSF_DB{ aslist == 2:293(145) } NSF_DB{ aslist ==
3:293 } NSF_DB{ aslist == 3:293(144) } NSF_DB{ aslist == 3:293(144) } NSF_DB{ as
list == 3:293(144) } NSF_DB{ aslist == 3:293(144) } NSF_DB{ aslist == 3:293(145)
 } NSF_DB{ aslist == 3:293(145) } NSF_DB{ aslist == 3:293(145) } NSF_DB{ aslist
== 3:293(145) } NSF_DB{ aslist == 6:293 } NSF_DB{ aslist == 6:293(145) } NSF_DB{
 aslist == 6:293(145) } NSF_DB{ aslist == 6:293(145) } NSF_DB{ aslist == 6:293(1
45) } ))

   or even much larger.  These never seem to match anything in the examples
   I am looked at.

[ca] These are the left over routes that are not explicitly accepted
[ca] by interas-in. In the AS690, they evaluate to the empty set.

   This is more along the lines of "hmm, isn't that curious" than anything
   else, from someone who is looking at both pol2filters and RIPE-181 as
   a black box (well, as much as I can).  I don't care about the noise, as
   long as it works.  I do have a sneaking suspicion that pol2filters would
   run way faster if there was a way to ignore these, though.

- --John
------- end -------

Cengiz

-- 
Cengiz Alaettinoglu       Information Sciences Institute
(310) 822-1511            University of Southern California



-------- Logged at  Mon Feb 13 16:50:31 MET 1995  ---------