In the short re-charter discussion there was a proposal to offer lisp architecture (with multi encapsulations option) as one of the possible control planes for nvo3.
There was a comment regarding inter-networking with legacy vpn. We recently faced such a requirement for service provider-anchored VPN overlays. These VPN overlays are implemented such that the "real" XTRs are in the provider regional data centers, while "satellite" XTRs at customer premise use them as anchors and do not use the mapping directly. Much like Vina's NAT traversal draft. This makes it easier to cluster virtual network functions next to the "real" XTRs, same rack, and share their capacity across XTRs over the high speed core underlay. The point is that the inter-networking - into and out of the VPN Overlay - is handled, much like any other "extra" functionality over basic lisp. It is handled the NFV way. This means that the complexity of external BGP talkers to other VPNs or to the Internet routers is locked inside the VNFs, and the capacity of these VNFs is shared across the VPN held by the XTRs using the mapping service as global locator. Similar to the multicast replication function proposal, or similar to how firewall functions are chained, using SFC. Is there interest in such a draft? There should probably be a common part applicable to any function, eg the Schema for instances, scoping of each, affinity for the return path, and locations (as in RLOCs), in the mapping. Then specifically for the inter VPN VNF what is the lisp FlowMapping behavior in each of the XTRs to accommodate. Alternately we can also take it a function at a time. --szb _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
