Route Programming (was Re: bgp route-map)

Mon Aug 25 20:52:39 UTC 2003

On Mon, Aug 25, 2003 at 04:02:22PM -0400, Leo Bicknell wrote:
> 
> This reminds me of something I've wanted to bring up to the community
> for a long time.  I'd like to see a "route programming language" that
> gets implemented in a multi-vendor way.  No, I'm not talking about like
> RPSL, but rather, let me give some examples:

I'll half agree with this. If you can't get the necessary functionality 
out of your existing policy language, you probably need a better policy 
language. However, if all you're going to do is "if" and "then", an actual 
programming language is probably not going to be in your best interests.

Let's just discard Cisco route-maps as nearly useless for the moment, and
talk about Juniper policies for a second. They're mostly reasonable as a 
policy language... They do if-then, subroutines, chained statements, and 
they let you write some fairly complex things which mostly get the job 
done. Slapping an if () {} around it probably isn't going to do much to 
improve things, as the areas that need improvement are not (mainly) based 
in the syntax.

Let's take an example of something that they need to add... Say I have a
BGP community structure which let's a customer tag a route with a specific
community to make it do a specific thing (lower localpref, only announce
to certain people, set nexthop to something that discards, whatever). Now
let's say that I want to extend this functionality so that they can do
similar things on a per-ASN basis, as in let them specify two out of five
transits or peers which they don't want to announce the route to. Under 
the current policy language, you would have to either write a policy 
statement per ASN (as well as an as-path statement) and apply it to every 
session, or add a term to a policy statement which is applied to a policy 
statement which is applies to every session. There is no way to have the 
policy parse "6461:666" into "6461" and "666", check against the 
configured asn of the peer this policy is being applied to, and correctly 
take action.

Now, nothing about the above example requires if () { }, variables, memory 
allocation, or anything else even halfway complicated. All it requires is 
a little bit more  thought in the design of the existing policy language, 
and of course the common sense to realize that maybe you should listen to 
all those engineers on nanog 'cause they might actually know something 
about operating networks.

> Sadly, while I can think of many cool things you could do, I know
> little about how to really design a languge.  I also have no idea
> how bad other people want this, how hard it would be to get vendors
> to implement, etc.  Feel free to add your support, or call me a
> crackpot.

Be my luck some tard would write it in perl or tcl anyways...

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)