[RFE] Neutron API enhancement - add optional attribute to network

Bug #1664466 reported by Sukhdev Kapur
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Expired
Wishlist
Unassigned

Bug Description

Add a new "optional" attribute to network resource. This allows users/operators to optionally specify the network type, based upon the deployment use cases.

If this optional attribute is not set, the business as usual is assumed. If this attribute is set, the back-ends could use it in the packet forwarding/processing decisions.

This keeps the API backward compatible, while opening it up to accommodate more newer use cases, where operators/users/vendors can specify the type of service the network is used to deploy

Tags: rfe
tags: added: api
Revision history for this message
Reedip (reedip-banerjee-deactivatedaccount) wrote :

Any suggestions, ideas, or any specific mention of what type of netwrok-types can exist of be used ? It would give us an idea about this feature

Akihiro Motoki (amotoki)
tags: added: rfe
tags: removed: api
Revision history for this message
Sukhdev Kapur (sukhdev-8) wrote :

Some examples of the network type are:

Point-to-point networks, MPLS networks, service networks, etc...

Revision history for this message
Boden R (boden) wrote :

Sorry I must be missing something, but how is this different from the provider:network_type we have today [1]? Also if you have an example use case that might be nice.

[1] https://developer.openstack.org/api-ref/networking/v2/?expanded=update-network-detail,create-network-detail#provider-extended-attributes

Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

I agree with Boden, I am not sure I fully understand by the existing type driver doesn't fit the use case.

Changed in neutron:
status: New → Confirmed
importance: Undecided → Wishlist
status: Confirmed → Incomplete
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

Please provide more details.

Revision history for this message
Sukhdev Kapur (sukhdev-8) wrote :

@Boden, @Armando,

Per our discussion at Atlanta PTG, the provider:network_type is associated provider_net, and not the tenant networks. In other words, this attribute is supported only from the admin mode.

See here all the attributes associated with network - https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/network.py#L33

And, here to see how provider:network_type is used/specified- https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/provider_net.py#L62

Just for the fun, I tried creating a network with network_type as a tenant and it was rejected. However, when I create it as an admin, I can do it....

So, the bottom line is this only available for provider networks.

If we can make this available as a general attribute of the network, that would be great - and, that is what this RFE is all about.

As to the examples (or use cases), I provided few examples earlier, another one brought up in the Gluon meeting was MPLS/GRE - hope this answers your question.

On an orthogonal note/topic, there seems to be some confusion about the the ML2 type driver being able to specify the network type - that is really not true. ML2 type drivers specify the segmentation type for the segments or a network, and a network can have multiple segments.
For example a neutron network can have three segments like VLAN-VxLAN-VLAN.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.