AS 690 aut-num progress (LONG!!!)

Curtis Villamizar (curtis at ans.net) on March 17:
> > The way you assigned preferences to interas-in lines and costs to
> > as-in lines is interesting. In that you can impose "override
> > as-in costs with interas-in preferences" and have the desired
> > behavior. Without overriding, it is still the correct policy, however
> > the preferences in the config files will reflect both the as-in
> > costs and interas-in preferences and be different numbers than that
> > appear on your policy.
> 
> I'm using interas-in to break ties in as-in and putting the result in
> gated's preference.  I'm not using cost for gated preference and
> preference for gated preference2.  I'll recheck, but I think the
> policy is written such that this always works and what gated will do
> will match what ripe rules predict should happen.

This is my observation as well. 
About gated preference2, it is not per route but it is per peer, isn't
it? In which case, it can not be used in this context.

> 
> > In your aut-num object, I have not seen a policy like:
> > 	1:3561:100 2:200:128 3:3561:111
> > which is not really expressible in ripe-181. Is this because there
> > were not such policies or did you approximate those to something else.
> 
> as-in: from AS3561 1 accept ASx
> interas-in: from AS3561 r100 * (pref=1) accept ASx
> as-in: from AS200 1 accept ASx				<- **note below
> interas-in: from AS200 r128 * (pref=2) accept ASx
> interas-in: from AS3561 r111 * (pref=3) accept ASx
> 
> Note: after the first time an interas-in line is used, the cost
> remains fixed and interas-in lines are used to express the remainder
> of the policy.  This is the trick that makes gated rules and ripe
> rules come up with the same ordering but for different reasons.  Gated
> would see the preferences.  If the first entry didn't use interas-in,
> but the second did, cost would lock in as 2, and pref would take over
> from 2.

I see, the trick is to eliminate as-in cost comparison, by setting
them to the same value.

> 
> > I hope my comments are useful. 
> 
> Yes very.  Thanks.
> 
> > I have few more questions. I am asking these as input to RPSL design:
> 
> What's an RPSL?  Sorry I'm new to this game.

I think I mentioned that we are forming a WG (and have a BOF on
thursday morning in Danvers) to develop a new policy language. We are
referring ot it as RPSL (Routing Policy Specification Language). By
the way, I have already added you to the rps at isi.edu mailing list.

Cengiz

-- 
Cengiz Alaettinoglu       Information Sciences Institute
(310) 822-1511            University of Southern California
http://www.isi.edu/div7/people/cengiz.home



-------- Logged at  Tue Mar 21 20:00:33 MET 1995  ---------