[RFE] QinQ network driver

Bug #1705719 reported by Trevor McCasland on 2017-07-21
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
neutron
Wishlist
Unassigned

Bug Description

QinQ networks allows service providers to extend it's clients virtual broadcast domains across their sites, without interfering with each others VLANs. Where the s_tag will be used to transport the traffic from the provider to the customer and the c_tag will be used for the customer's network.

We can implement this by first refactoring VLAN's allocation logic and then extending it to handle a second layer of VLAN tagging. Essentially replacing vlan_id with a s_tag:c_tag pair.

Changed in neutron:
importance: Undecided → Wishlist
status: New → Confirmed
Changed in neutron:
assignee: nobody → Trevor McCasland (twm2016)
status: Confirmed → In Progress
Kevin Benton (kevinbenton) wrote :

Moved to Triaged state so we can discuss in drivers meeting tomorrow.

Changed in neutron:
status: In Progress → Invalid
status: Invalid → Triaged
Changed in neutron:
status: Triaged → In Progress
Trevor McCasland (twm2016) wrote :

I would move it back to Triaged if I had permissions..

Changed in neutron:
status: In Progress → Triaged
Changed in neutron:
status: Triaged → In Progress
Changed in neutron:
status: In Progress → Triaged
YAMAMOTO Takashi (yamamoto) wrote :

is this about introducing a new network_type for provider network extension?
provider:segmentation_id would be a s_tag:c_tag pair? or, does s_tag come from somewhere else?

Trevor McCasland (twm2016) wrote :

@YAMAMOTO, yes. provider:segmentation_id would be a provider:s_tag:c_tag. s_tag comes from the segmentation_id. When configured for c_tags, the range of c_tags is allocated upon creation of a network with a configured s_tag matching the specified segmentation_id. Perhaps my blog on this would help explain it a bit, https://trevormccasland.wordpress.com/2017/07/21/neutron-qinq-network-type-driver-wip/

YAMAMOTO Takashi (yamamoto) wrote :

Trevor,

thank you.

what's "provider:s_tag:c_tag"?

is s_tag statically configured for each physical networks?

Trevor McCasland (twm2016) wrote :

@YAMAMOTO, yes.
what's "provider:s_tag:c_tag"?
 - This is a way to identify a specific QinQ network
"provider:s_tag:c_tag_min:c_tag_max" is configured like phynset1:1:1:1000. Both c_tags and s_tags are statically configured. Upon allocation of segmentation_id 1 on physnet1 c_tags 1-1000 will be allocated with the above example.

YAMAMOTO Takashi (yamamoto) wrote :

Trevor,

when i said "provider:segmentation_id", i meant the attribute of networks. that is, neutron_lib.api.definitions.provider_net.SEGMENTATION_ID.
you don't mean a new attribute by "provider:s_tag:c_tag", right?

in your example, the segmentation_id 1 (s_tag) is configured in neutron.conf?

a physical network (in your blog example "physnet1") and s_tag are 1:1?

Trevor McCasland (twm2016) wrote :

Yamamoto,

Right, no new attribute is needed.
They are not 1 to 1. A physical network can have many s_tags, and an s_tag can have many c_tags.

YAMAMOTO Takashi (yamamoto) wrote :

Trevor,

when a physical network have multiple s_tags, how one of them is chosen for a packet going out from a tenant network?

Trevor McCasland (twm2016) wrote :

Yamamoto,

The configuration would have an entry for every physnet and s_tag the user wishes to use.

Miguel Lavalle (minsel) wrote :

Trevor,

We discussed this yesterday during the drivers meeting. There was still some confusion as to how a tenant network would get assigned to tags: http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-11-02-22.00.log.html#l-77. Would you help us with an example of how that would happen, including the way it would be configured?

YAMAMOTO Takashi (yamamoto) wrote :

Trevor,

do you mean that "The configuration" is rich enough to describe some selection criteria?

YAMAMOTO Takashi (yamamoto) wrote :

Trevor,

i guess your blog example would be more easier to understand (for me) if you use non-overlapping values for s_tag and c_tag.

Trevor McCasland (twm2016) wrote :

I'm not really sure what to say at this point.

1. I've been reassigned since september, I shouldnt be the person working on this.
2. We only want this feature if the networking-opencontrail plugin can support it.
3. I'm ok with abandoning this. I'll remove my assignment at this point.

Changed in neutron:
assignee: Trevor McCasland (twm2016) → nobody

Change abandoned by Trevor McCasland (<email address hidden>) on branch: master
Review: https://review.openstack.org/446047
Reason: just going to abandon in case anyone else wants to work on it, go ahead.

Change abandoned by Trevor McCasland (<email address hidden>) on branch: master
Review: https://review.openstack.org/458531

Change abandoned by Trevor McCasland (<email address hidden>) on branch: master
Review: https://review.openstack.org/482307

Change abandoned by Trevor McCasland (<email address hidden>) on branch: master
Review: https://review.openstack.org/483020

Miguel Lavalle (minsel) wrote :

This RFE has been postponed for lack of implementation resources. If someone is interested in pursuing it, it can be re-considered in the future

tags: added: rfe-postponed
removed: rfe
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers