To add to Dino's comment, based on implementation experience (which can be referenced in ODL open source), at the physical to virtual network infrastructure definitions level..
a (lisp) re-tunneling element, with an underlay address and access to (cached) global mapping information.. can be used to: - map flows to function chains by load and tenancy according to a specified (per source and or dest) itinerary, in a self balanced manner - map flows to programable segmented paths in the underlay, for application aware core balancing e.g streamer accessing content real-time vs content being replicated in the background - replicate flows for multicasting to multiple rlocs, or for tapping / debugging / wiresharking / calea Plus a few more utilities. So LISP RTR is a recommended very practical "base-class" --szb > On Nov 4, 2013, at 2:00 PM, Dino Farinacci <[email protected]> wrote: > > Could someone explain to me how to use LISP solution to provide route path > control? For example, in a VN, ingress NVE MUST forward the packets to > another NVE at which a tenant system runs firewall software. The second NVE > then forwards to the packets to the third NVE where an attached TS has the > address that matches the destination address in the inner address on the > packets. > > Lucy LISP has a decapsaltor/encasulator component called an RTR. An RTR can give you suboptimal paths by choice if you want to route around failures, congestion points, or use policy paths. You can find details in http://datatracker.ietf.org/doc/draft-farinacci-lisp-te. But yes, you can have an RTR co-located with a firewall, laod-balancer, and NAT type middle devices. Dino _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
