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@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@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org