Include the URL of your launchpad blueprint:
The Link Layer Discovery Protocol (LLDP) is a vendor-neutral link layer protocol in the Internet Protocol Suite used by network devices for advertising their identity, capabilities, and neighbors on an IEEE 802 local area network, principally wired Ethernet. 
The Link Layer Discover Protocol (LLDP) helps identify layer 1/2 connections between hosts and switches. The switch port, chassis ID, VLANs trunked, and other info is available, for planning or troubleshooting a deployment. For instance, a deployer may validate that the proper VLANs are supplied on a link, or that all hosts are connected to the Provisioning network.
A detailed description of the problem:
The goal is to expose LLDP data that is collected during introspection, and provide this data in a format that is useful for the deployer. This work depends on the LLDP collection work being done in ironic-python-agent .
There is work being done to implement LLDP data collection for Ironic/ Neutron integration. Although this work is primarily focused on features for bare-metal Ironic instances, there will be some overlap with the way TripleO uses Ironic to provision overcloud servers.
There are many network management utilities that use CDP or LLDP data to validate the physical networking. Some of these are open source, but none are integrated with OpenStack.
Alternative approaches that do not use LLDP are typically vendor-specific and require specific hardware support. Cumulus has a solution which works with multiple vendors’ hardware, but that solution requires running their custom OS on the Ethernet switches.
Another approach which is common is to perform collection of the switch configurations to a central location, where port configurations can be viewed, or in some cases even altered and remotely pushed. The problem with this approach is that the switch configurations are hardware and vendor-specific, and typically a network engineer is required to read and interpret the configuration. A unified approach that works for all common switch vendors is preferred, along with a unified reporting format.
The physical network report provides a roadmap to the underlying network structure. This could prove handy to an attacker who was unaware of the existing topology. On the other hand, the information about physical network topology is less valuable than information about logical topology to an attacker. LLDP contains some information about both physical and logical topology, but the logical topology is limited to VLAN IDs.
The network topology report should be considered sensitive but not critical. No credentials or shared secrets are revealed in the data collected by ironic-inspector.
This report will hopefully reduce the troubleshooting time for nodes with failed network deployments.
If this report is produced as part of the ironic-inspector workflow, then it will increase the time taken to introspect each node by a negligible amount, perhaps a few seconds.
If this report is called by the operator on demand, it will have no performance impact on other components.
Deployers may want additional information than the per-node LLDP report. There may be some use in providing aggregate reports, such as the number of nodes with a specific configuration of interfaces and trunked VLANs. This would help to highlight outliers or misconfigured nodes.
There have been discussions about adding automated switch configuration in TripleO. This would be a mechanism whereby deployers could produce the Ethernet switch configuration with a script based on a configuration template. The deployer would provide specifics like the number of nodes and the configuration per node, and the script would generate the switch configuration to match. In that case, the LLDP collection and analysis would function as a validator for the automatically generated switch port configurations.
The initial work will be to fill in fixed fields such as Chassis ID and switch port. An LLDP packet can contain additional data on a per-vendor basis, however.
The long-term plan is to store the entire LLDP packet in the metadata. This will have to be parsed out. We may have to work with switch vendors to figure out how to interpret some of the data if we want to make full use of it.
Some notes about implementation:
Since this is a report that is supposed to benefit the operator, perhaps the best way to include it in CI is to make sure that the report gets logged by the Undercloud. Then the report can be reviewed in the log output from the CI run.
In fact, this might benefit the TripleO CI process, since hardware issues on the network would be easier to troubleshoot without having access to the bare metal console.
Documentation will need to be written to cover making use of the new LLDP reporting tool. This should cover running the tool by hand and interpreting the data.