Bare metal could be plugged into VXLAN type of tenant network, similar to VMs.

A simple and often lost reality of large scale networking in data centers is that communication between switches in the environment is increasingly taking the form of VXLAN instead of VLAN traffic. Where operators are using L2VNIs to move traffic with efficiency, while keeping hosts on the same logical L3 segment. This is largely different than VLAN where all switches share either fabric wise or VLAN wide spanning trees which ultimately determines a single switch as a root bridge which traffic is forwarded to. This creates hot spots, especially with the traffic flow demands of high end data centers.

Customers who are deploying bare metal as a service also find the need to manage VLANs as cumbersome and ultimately in-efficient. It can be done, its just not ideal and prevents a lot of complications because all of a sudden you need a set of local VLANs to the switch for VXLAN network terminations, and a set of VLANs which span beyond the switch, which is also problematic because then each switch needs its own vlans as well.

Ultimately, large scale operators are also seeking to be able to leverage more than 4094 (Or whatever their networking vendor actually supports) in terms of vlans. Hence, VXLAN which is a 24 bit range in operational reality.

This item is likely to cover work related to:

• Ironic
• Neutron
• Networking-Generic-Switch (Ironic deliverable)
• Networking-Baremetal (Ironic deliverable)

Feature Overview (mandatory - Complete while in New status)

As a large scale user, I need simple and effective ways to support binding physical bare metal machines to virtual networks inside OVN in an OpenStack context. The use of VLANs is onerous and problematic in my large scale network, and the physical machines are likely to need to send more traffic than a single switch bridge can handle, so realistically, I need to support the same basic means the rest of my switches support to exchange traffic between logical segments.

Goals (mandatory - Complete while in New status)
Provide high-level goal statement, providing user context and expected user outcome(s) for this Feature

• Large scale Operators with a need for more than a few thousand networks who also want/need bare metal instances.
• Currently we support only VLAN which is constrainted to no more than 4094 networks, but this model conflicts with modern datacetner network management, and thus VXLAN support is viewed as a minimal expectation.

Requirements (mandatory -_ Complete while in Refinement status):
A list of specific needs, capabilities, or objectives that a Feature must deliver to satisfy the Feature. Some requirements will be flagged as MVP. If an MVP gets shifted, the Feature shifts. If a non MVP requirement slips, it does not shift the feature.

 
Done - Acceptance Criteria (mandatory - Complete while in Refinement status):
Acceptance Criteria articulates and defines the value proposition - what is required to meet the goal and intent of this Feature. The Acceptance Criteria provides a detailed definition of scope and the expected outcomes - from a users point of view
…
<your text here>
Use Cases - i.e. User Experience & Workflow: (Initial completion while in Refinement status):
Include use case diagrams, main success scenarios, alternative flow scenarios.
<your text here>
Out of Scope __(Initial completion while in Refinement status):
High-level list of items or persona’s that are out of scope.
<your text here>
Documentation Considerations __(Initial completion while in Refinement status):
Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation..
<your text here>
 
Questions to Answer __(Initial completion while in Refinement status):
Include a list of refinement / architectural questions that may need to be answered before coding can begin.
<your text here>
Background and Strategic Fit (Initial completion while in Refinement status):
Provide any additional context is needed to frame the feature.
<your text here>
Customer Considerations __(Initial completion while in Refinement status):
Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.
<your text here>
Team Sign Off (Completion while in Planning status)

• All required Epics (known at the time) are linked to the this Feature
• All required Stories, Tasks (known at the time) for the most immediate Epics have been created and estimated
• Add - Reviewers name, Team Name
• Acceptance == Feature as “Ready” - well understood and scope is clear - Acceptance Criteria (scope) is elaborated, well defined, and understood
• Note: Only set FixVersion/s: on a Feature if the delivery team agrees they have the capacity and have committed that capability for that milestone

  Reviewed By	Team Name	Accepted	Notes