Route Programming (was Re: bgp route-map)

Mon Aug 25 20:12:13 UTC 2003

Hello,

The reason for me to come up with this idea/question was so that IRR information
can be used on a seperate box acting as a "Prefix-list server", which would be
basically a route server that distributes prefixes that should be filtered on
inbound announcements..

It would be great for integration with RPSL perhaps; RtConfig already does it,
but need something that's distributed/dynamic/automated; publishing filtering
information over BGP sounds interesting to me..

-hc

-- 
Sincerely,
  Haesu C.
  TowardEX Technologies, Inc.
  WWW: http://www.towardex.com
  E-mail: haesu at towardex.com
  Cell: (978) 394-2867

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:
> 
> 1) Pull out session details via "variables":
> 
>       route-statement foo {
>           if ($route has community(1234:$session{'asn'})) {
>               set_asprepend($route, "1234 1234")
>           }
>       }
> 
> 2) Check for the route in other routing tables:
> 
>       route-statement bar {
>           if ($route in ospf) {
>              set_localpref($route, 10)
>           }
>           if ($route in bgp && $route has communty(1234:666)) 
>              drop($route)
>           }
>           set_localpref($route, 100)
>       }
> 
> 3) Scan other route tables:
> 
>       route-statement baz {
>           if ($route supernet-in bgp) {
>               drop($route);
>           }
>       }
> 
> 4) Other weird stuff:
> 
>       route-statement hack {
>           if ($route = "1.2.3.0/24") {
>               announce_route("1.2.3.10/32", "192.168.1.1")
>           }
>       }
> 
> Basically all the data on the box would be made available via global
> variables (eg, session IP, session ASN, bgp version, etc), and all
> dynamic data would have interfaces (eg scan other routing tables,
> acl's, etc).  You'd write a "function" which would get passed a
> route object, and act on it.  Functions could further pass that
> route on calling other functions (allowing you to create common
> policy).
> 
> 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.
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org