Hi Matt,

 

Thanks for the explanation. One thing that brings a little confusion is the terminology “provider network”:

·        In StarlingX, the so-called “provider network” is more related w/ physical network, like a superset of “upstream provider networks”, which addresses the values that are currently stored in configuration file parameters only;

·        while in upstream neutron, what distinguishes provider networks from tenant networks is who (admin/user) actually creates them and how.

Just correct me if I’m wrong.

 

If my understanding is correct, yes, I agree with Ian’s response. We’ll work on removing the Neutron configuration file based approach to MTU management and exposing it via a RESTful API as the benefits are clear to us. Thanks again!

 

BR,

Kailun

 

From: Peters, Matt [mailto:Matt.Peters@windriver.com]
Sent: Wednesday, August 8, 2018 9:05 PM
To: Qin, Kailun <kailun.qin@intel.com>; Jolliffe, Ian <Ian.Jolliffe@windriver.com>
Cc: Troyer, Dean <dean.troyer@intel.com>; Jones, Bruce E <bruce.e.jones@intel.com>; Chilcote Bacco, Derek A <derek.a.chilcote.bacco@intel.com>; Le, Huifeng <huifeng.le@intel.com>; Xu, Chenjie <chenjie.xu@intel.com>; Zhao, Forrest <forrest.zhao@intel.com>; Guo, Ruijing <ruijing.guo@intel.com>; Rowsell, Brent <Brent.Rowsell@windriver.com>
Subject: RE: Questions about Provider MTU feature for StarlingX upstreaming

 

HI Kailun,

I’m not sure from your reply if you are agreeing or disagreeing with Ian’s response.

 

The intent was to show that the business case for the provider network MTU configuration is to remove the Neutron configuration file based approach to MTU management and expose it via a RESTful API.  This is a similar business case for the managed provider networks as a whole.

 

It is understood that upstream neutron already supports MTU configuration at the tenant network level, but was trying to show that the provider network MTU configuration addresses the values that are current stored in configuration file parameters only.

 

Regards, Matt

 

From: Qin, Kailun [mailto:kailun.qin@intel.com]
Sent: Wednesday, August 08, 2018 1:34 AM
To: Jolliffe, Ian
Cc: Troyer, Dean; Jones, Bruce E; Chilcote Bacco, Derek A; Le, Huifeng; Xu, Chenjie; Zhao, Forrest; Guo, Ruijing; Rowsell, Brent; Peters, Matt
Subject: RE: Questions about Provider MTU feature for StarlingX upstreaming

 

Hi Ian,

 

Thanks for the feedback.

 

The upstream neutron supports:

·        Set/modify a specific MTU on a (provider/tenant) network via REST API. This was introduced via “net-mtu-writable” API extension [1][2]. The requested MTU will work together w/ the MTU configuration options (global_physnet_mtu, physical_network_mtus and path_mtu) to configure the network MTU [3].

However, it does *NOT* support:

·        Dynamic MTU configuration options (global_physnet_mtu, physical_network_mtus and path_mtu) set/modify via REST API.

 

[1] https://bugs.launchpad.net/neutron/+bug/1671634

[2] https://review.openstack.org/#/c/483518/

[3] https://docs.openstack.org/neutron/latest/admin/config-mtu.html

 

So with the current upstream neutron implementation, the MTU configurations options still play a part at the deployment level. They serve as global maximum permissible and default values for network MTUs (of different network types). Meanwhile, neutron does support a dynamic alternative for users to set/modify specific MTUs across their networks. What do you think? Any use case that the current neutron is not able to cover?

 

Let me know if anything unclear. Great thanks!

 

BR,

Kailun

 

From: Jolliffe, Ian [mailto:Ian.Jolliffe@windriver.com]
Sent: Wednesday, August 8, 2018 9:52 AM
To: Qin, Kailun <kailun.qin@intel.com>
Cc: Troyer, Dean <dean.troyer@intel.com>; Jones, Bruce E <bruce.e.jones@intel.com>; Chilcote Bacco, Derek A <derek.a.chilcote.bacco@intel.com>; Le, Huifeng <huifeng.le@intel.com>; Xu, Chenjie <chenjie.xu@intel.com>; Zhao, Forrest <forrest.zhao@intel.com>; Guo, Ruijing <ruijing.guo@intel.com>; Rowsell, Brent <Brent.Rowsell@windriver.com>; Peters, Matt <Matt.Peters@windriver.com>
Subject: Re: Questions about Provider MTU feature for StarlingX upstreaming

 

Hi Kailun;

 

The provider network MTU goes along with the business case for managed provider networks.

 

The feature comparison should not be between provider network MTUs and tenant network MTUs, but more about whether we support MTU values via provider network configuration (REST API).

 

The comparable feature in OpenStack is the support for the ML2 global_physnet_mtu, physical_network_mtus and path_mtu configuration options.

 

https://blueprints.launchpad.net/neutron/+spec/mtu-selection-and-advertisement

 

Regards;

 

Ian

 

From: "Qin, Kailun" <kailun.qin@intel.com>
Date: Monday, August 6, 2018 at 3:01 AM
To: Ian Jolliffe <
Ian.Jolliffe@windriver.com>
Cc: "Troyer, Dean" <
dean.troyer@intel.com>, "Jones, Bruce E" <bruce.e.jones@intel.com>, "Chilcote Bacco, Derek A" <derek.a.chilcote.bacco@intel.com>, "Le, Huifeng" <huifeng.le@intel.com>, "Qin, Kailun" <kailun.qin@intel.com>, "Xu, Chenjie" <chenjie.xu@intel.com>, "Zhao, Forrest" <forrest.zhao@intel.com>, "Guo, Ruijing" <ruijing.guo@intel.com>
Subject: Questions about Provider MTU feature for StarlingX upstreaming

 

Hi Ian,

 

We are analyzing the provider MTU feature for StarlingX upstreaming, in which case the patch 021ae1a introduced providernet MTU and c647127 introduced the port granularity bindings for MTU.

 

Since the upstream neutron already has the network granularity MTU implemented [1] and made it available to be created or updated [2], would you please kindly help check whether we need to upstream this feature?

If so, would you please share some business use cases or user stories related with us?

 

[1] https://review.openstack.org/#/c/480738/

[2] https://review.openstack.org/#/c/483091/

 

Let me know if any question. Thanks a lot!

 

BR,

Kailun