Hi Matt, Thanks a lot for the detailed clarification. It is clear enough to me now. BR, Kailun From: Peters, Matt [mailto:Matt.Peters@windriver.com] Sent: Thursday, August 9, 2018 12:33 AM To: Qin, Kailun <kailun.qin@intel.com>; starlingx-discuss@lists.starlingx.io 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>; Jolliffe, Ian <Ian.Jolliffe@windriver.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 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@intel.com] Sent: Wednesday, August 08, 2018 12:01 PM To: Peters, Matt; Jolliffe, Ian; starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@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@windriver.com] Sent: Wednesday, August 8, 2018 9:05 PM To: Qin, Kailun <kailun.qin@intel.com<mailto:kailun.qin@intel.com>>; Jolliffe, Ian <Ian.Jolliffe@windriver.com<mailto:Ian.Jolliffe@windriver.com>> Cc: Troyer, Dean <dean.troyer@intel.com<mailto:dean.troyer@intel.com>>; Jones, Bruce E <bruce.e.jones@intel.com<mailto:bruce.e.jones@intel.com>>; Chilcote Bacco, Derek A <derek.a.chilcote.bacco@intel.com<mailto:derek.a.chilcote.bacco@intel.com>>; Le, Huifeng <huifeng.le@intel.com<mailto:huifeng.le@intel.com>>; Xu, Chenjie <chenjie.xu@intel.com<mailto:chenjie.xu@intel.com>>; Zhao, Forrest <forrest.zhao@intel.com<mailto:forrest.zhao@intel.com>>; Guo, Ruijing <ruijing.guo@intel.com<mailto:ruijing.guo@intel.com>>; Rowsell, Brent <Brent.Rowsell@windriver.com<mailto: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<mailto:kailun.qin@intel.com>> Cc: Troyer, Dean <dean.troyer@intel.com<mailto:dean.troyer@intel.com>>; Jones, Bruce E <bruce.e.jones@intel.com<mailto:bruce.e.jones@intel.com>>; Chilcote Bacco, Derek A <derek.a.chilcote.bacco@intel.com<mailto:derek.a.chilcote.bacco@intel.com>>; Le, Huifeng <huifeng.le@intel.com<mailto:huifeng.le@intel.com>>; Xu, Chenjie <chenjie.xu@intel.com<mailto:chenjie.xu@intel.com>>; Zhao, Forrest <forrest.zhao@intel.com<mailto:forrest.zhao@intel.com>>; Guo, Ruijing <ruijing.guo@intel.com<mailto:ruijing.guo@intel.com>>; Rowsell, Brent <Brent.Rowsell@windriver.com<mailto:Brent.Rowsell@windriver.com>>; Peters, Matt <Matt.Peters@windriver.com<mailto: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-advertiseme... Regards; Ian From: "Qin, Kailun" <kailun.qin@intel.com<mailto:kailun.qin@intel.com>> Date: Monday, August 6, 2018 at 3:01 AM To: Ian Jolliffe <Ian.Jolliffe@windriver.com<mailto:Ian.Jolliffe@windriver.com>> Cc: "Troyer, Dean" <dean.troyer@intel.com<mailto:dean.troyer@intel.com>>, "Jones, Bruce E" <bruce.e.jones@intel.com<mailto:bruce.e.jones@intel.com>>, "Chilcote Bacco, Derek A" <derek.a.chilcote.bacco@intel.com<mailto:derek.a.chilcote.bacco@intel.com>>, "Le, Huifeng" <huifeng.le@intel.com<mailto:huifeng.le@intel.com>>, "Qin, Kailun" <kailun.qin@intel.com<mailto:kailun.qin@intel.com>>, "Xu, Chenjie" <chenjie.xu@intel.com<mailto:chenjie.xu@intel.com>>, "Zhao, Forrest" <forrest.zhao@intel.com<mailto:forrest.zhao@intel.com>>, "Guo, Ruijing" <ruijing.guo@intel.com<mailto: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