In reply to Aluri John.

Thanks for the complements!

Aluri John,
There are a couple of link directions you might be asking, so I'll answer both and hopefully that gives you the info you're looking for.

Link from NSX to tetration:
Tetration can gather information and flow data from the workload instances, thus there is no required linkage from Tetration to ANY underlying physical or virtual infrastructure.
Note: Having said that, in the instances where there is an environment with some specific Cisco hardware, we can gather a significantly deeper level of telemetry to provide hop-by-hop performance and diagnostics information related to every flow observed.

Link from Tetration to NSX:
What Tetration does at the core is analyze millions or billions of flow records and perform the difficult task of providing the logical mapping of what types of communications are happening in that sea of data. It starts by arranging the communicating members of the conversations into logical groupings. Another thing that Tetration does is analyze the conversations that happen between those cluster groupings. From there, Tetration will provide a detailed analysis of how the relevant policy for these clusters and conversations would be expressed. This policy information is available via 1) direct export from the UI, 2) direct access via API, or 3) streamed via a policy message bus. From that point, any enforcement control system (such as ACI, SourceFire, AWS Security Groups, Azure Security groups, NSX DFW, etc.) can use that policy information for enforcement.
We are working with a number of companies to provide supported integration models that can ingest the policy, normalize it, then push it to the enforcement system to execute that policy.
In the specific case of NSX DFW, the policy that Tetration generates would need to be extracted from the cluster via one of the three methods listed above, normalized via program or script and then pushed into NSX.

Hope that answers your Q…

Thanks!