Route Programming (was Re: bgp route-map)
Richard A Steenbergen
ras at e-gerbil.net
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)
More information about the NANOG
mailing list