Briefing Other Suppliers

Informing other suppliers of your requirements

There are very few projects where you will be the sole supplier of everything. Some very large companies may have this capability, but even in these cases, they must coordinate across multiple teams and business units. The requirement here is the same, you must be capable of briefing other suppliers as to what the requirements are for the components you are providing.

In this scenario, let’s imagine that we are providing host servers, virtual machines, and their configuration and integration, a typical scope of supply in a private cloud exercise. We might need to brief a range of other suppliers on what we need from them, and what we will be providing to them. For example, the network supplier would need to know our physical connectivity requirements.

1. Which cabinet will servers be located in?

2. How many connections do your servers need, with what properties?

   1. Speed

   2. Media type

   3. Connectors

3. Will there be redundancy and if so, how will it work?

4. Are these connections access ports or trunks/tagged and are there implications? Many students miss this. A network supplier might block ports which behave like switches.

5. Any there any other port characteristics like QoS?

6. What port security settings should be provided?

On a real project, I would provide a network supplier with a physical diagram showing the interfaces of my server and what I require them to connect to.

Regarding logical connectivity:

1. What VLANs should connections be in?

2. For tagged connections, what VLANs should be allowed and what should be pruned?

3. If you are using redundant connections, is there any sort of load balancing?

4. What network services exist, where, who supplies them?

   1. DNS

   2. DHCP

   3. Time/NTP/PtP

   4. Logging

   5. AAA

The contents of a briefing document from one supplier to another, will depend on who is supplying what to whom. The example given here is one possible scenario only.