[Starlingx-discuss] Questions about Provider MTU feature for StarlingX upstreaming

Wed Aug 8 23:18:40 UTC 2018

Hi Matt,

Thanks a lot for the detailed clarification. It is clear enough to me now.

BR,
Kailun

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

Hi Kailun,
I’m not aware of provider networks being referred to as “admin” networks.  The provider network terminology comes from the neutron extension (“providernet”) that defines the attributes for the physical network (“provider:network_type”, “provider:physical_network”, etc).  I agree that the StarlingX definition is of greater scope since it also covers the related configuration file values.

The only distinction that I am aware of between “admin” and “tenant” for provider networks is that they are only exposed to a user with administrative rights (enforced by policy).

I hope that clarifies what I refer to as a provider network.

Regards, Matt

From: Qin, Kailun [mailto:kailun.qin at intel.com]
Sent: Wednesday, August 08, 2018 12:01 PM
To: Peters, Matt; Jolliffe, Ian; starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>
Cc: Troyer, Dean; Jones, Bruce E; Chilcote Bacco, Derek A; Le, Huifeng; Xu, Chenjie; Zhao, Forrest; Guo, Ruijing; Rowsell, Brent
Subject: RE: Questions about Provider MTU feature for StarlingX upstreaming

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 at windriver.com]
Sent: Wednesday, August 8, 2018 9:05 PM
To: Qin, Kailun <kailun.qin at intel.com<mailto:kailun.qin at intel.com>>; Jolliffe, Ian <Ian.Jolliffe at windriver.com<mailto:Ian.Jolliffe at windriver.com>>
Cc: Troyer, Dean <dean.troyer at intel.com<mailto:dean.troyer at intel.com>>; Jones, Bruce E <bruce.e.jones at intel.com<mailto:bruce.e.jones at intel.com>>; Chilcote Bacco, Derek A <derek.a.chilcote.bacco at intel.com<mailto:derek.a.chilcote.bacco at intel.com>>; Le, Huifeng <huifeng.le at intel.com<mailto:huifeng.le at intel.com>>; Xu, Chenjie <chenjie.xu at intel.com<mailto:chenjie.xu at intel.com>>; Zhao, Forrest <forrest.zhao at intel.com<mailto:forrest.zhao at intel.com>>; Guo, Ruijing <ruijing.guo at intel.com<mailto:ruijing.guo at intel.com>>; Rowsell, Brent <Brent.Rowsell at windriver.com<mailto:Brent.Rowsell at 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 at 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 at windriver.com]
Sent: Wednesday, August 8, 2018 9:52 AM
To: Qin, Kailun <kailun.qin at intel.com<mailto:kailun.qin at intel.com>>
Cc: Troyer, Dean <dean.troyer at intel.com<mailto:dean.troyer at intel.com>>; Jones, Bruce E <bruce.e.jones at intel.com<mailto:bruce.e.jones at intel.com>>; Chilcote Bacco, Derek A <derek.a.chilcote.bacco at intel.com<mailto:derek.a.chilcote.bacco at intel.com>>; Le, Huifeng <huifeng.le at intel.com<mailto:huifeng.le at intel.com>>; Xu, Chenjie <chenjie.xu at intel.com<mailto:chenjie.xu at intel.com>>; Zhao, Forrest <forrest.zhao at intel.com<mailto:forrest.zhao at intel.com>>; Guo, Ruijing <ruijing.guo at intel.com<mailto:ruijing.guo at intel.com>>; Rowsell, Brent <Brent.Rowsell at windriver.com<mailto:Brent.Rowsell at windriver.com>>; Peters, Matt <Matt.Peters at windriver.com<mailto:Matt.Peters at 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 at intel.com<mailto:kailun.qin at intel.com>>
Date: Monday, August 6, 2018 at 3:01 AM
To: Ian Jolliffe <Ian.Jolliffe at windriver.com<mailto:Ian.Jolliffe at windriver.com>>
Cc: "Troyer, Dean" <dean.troyer at intel.com<mailto:dean.troyer at intel.com>>, "Jones, Bruce E" <bruce.e.jones at intel.com<mailto:bruce.e.jones at intel.com>>, "Chilcote Bacco, Derek A" <derek.a.chilcote.bacco at intel.com<mailto:derek.a.chilcote.bacco at intel.com>>, "Le, Huifeng" <huifeng.le at intel.com<mailto:huifeng.le at intel.com>>, "Qin, Kailun" <kailun.qin at intel.com<mailto:kailun.qin at intel.com>>, "Xu, Chenjie" <chenjie.xu at intel.com<mailto:chenjie.xu at intel.com>>, "Zhao, Forrest" <forrest.zhao at intel.com<mailto:forrest.zhao at intel.com>>, "Guo, Ruijing" <ruijing.guo at intel.com<mailto:ruijing.guo at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20180808/63ed5600/attachment-0001.html>