North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Route Programming (was Re: bgp route-map)
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: [email protected] 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 - [email protected] - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - [email protected], www.tmbg.org
|