[RFE] QinQ network driver

[Trevor McCasland]

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.

[Kevin Benton (kevinbenton)]

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

[Trevor McCasland (twm2016)]

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

[YAMAMOTO Takashi (yamamoto)]

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)]

@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)]

Trevor,

thank you.

what's "provider:s_tag:c_tag"?

is s_tag statically configured for each physical networks?

[Trevor McCasland (twm2016)]

@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)]

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)]

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)]

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)]

Yamamoto,

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

[Miguel Lavalle (minsel)]

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)]

Trevor,

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

[YAMAMOTO Takashi (yamamoto)]

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)]

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.

[OpenStack Infra (hudson-openstack)]

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.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[Miguel Lavalle (minsel)]

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

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Bug closed due to lack of activity, please feel free to reopen if needed.