From e3448d10dcd973e60b6b2819bbc2dba8455b9c11 Mon Sep 17 00:00:00 2001 From: Georg Kunz Date: Fri, 22 Jul 2016 17:38:22 +0200 Subject: Incorporating further review comments Change-Id: I65fa2036f32c018c3d9cda46a82c6f1e2d4e6323 Signed-off-by: Georg Kunz --- docs/requirements/use_cases/l3vpn_ecmp.rst | 7 +- .../requirements/use_cases/l3vpn_hub_and_spoke.rst | 12 +- .../use_cases/programmable_provisioning.rst | 28 +-- .../use_cases/service-binding-pattern.rst | 199 --------------------- .../use_cases/service_binding_pattern.rst | 198 ++++++++++++++++++++ 5 files changed, 225 insertions(+), 219 deletions(-) delete mode 100644 docs/requirements/use_cases/service-binding-pattern.rst create mode 100644 docs/requirements/use_cases/service_binding_pattern.rst (limited to 'docs/requirements/use_cases') diff --git a/docs/requirements/use_cases/l3vpn_ecmp.rst b/docs/requirements/use_cases/l3vpn_ecmp.rst index b3d5b63..7bcb64f 100644 --- a/docs/requirements/use_cases/l3vpn_ecmp.rst +++ b/docs/requirements/use_cases/l3vpn_ecmp.rst @@ -31,15 +31,16 @@ subnet 10.1.1.0/24 and assigned the same IP addresses 10.1.1.5. VNF 2 and VNF 3 on host A and B respectively, attached to subnet 10.1.1.0/24, and assigned different IP addresses 10.1.1.6 and 10.1.1.3 respectively. -Here, the Network VRF Policy Resource is ``ECMP/AnyCast``. Traffic to **Anycast 10.1.1.5** -can be load split from either WAN GW or another VM like G5. +Here, the Network VRF Policy Resource is ``ECMP/AnyCast``. Traffic to the +anycast IP **10.1.1.5** can be load split from either WAN GW or another VM like +G5. Current implementation ~~~~~~~~~~~~~~~~~~~~~~ -Support for creating and managing L3VPNs is in general available in OpenStack +Support for creating and managing L3VPNs is, in general, available in OpenStack Neutron by means of the BGPVPN project [BGPVPN]_. However, the BGPVPN project does not yet fully support ECMP as described in the following. diff --git a/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst b/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst index 07004ef..17459b6 100644 --- a/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst +++ b/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst @@ -8,12 +8,12 @@ Hub and Spoke Case Description ~~~~~~~~~~~ -A Hub-and-spoke topology comprises two types of network entities: a central hub -and multiple spokes. The corresponding VRFs of the hub and the spokes are -configured to import and export routes such that all traffic is routed through -the hub. As a result, spokes cannot communicate with each other directly, but -only indirectly via the central hub. Hence, the hub typically hosts central network -functions such firewalls. +In a traditional Hub-and-spoke topology there are two types of network entities: +a central hub and multiple spokes. The corresponding VRFs of the hub and the +spokes are configured to import and export routes such that all traffic is +directed through the hub. As a result, spokes cannot communicate with each other +directly, but only indirectly via the central hub. Hence, the hub typically +hosts central network functions such firewalls. Furthermore, there is no layer 2 connectivity between the VNFs. diff --git a/docs/requirements/use_cases/programmable_provisioning.rst b/docs/requirements/use_cases/programmable_provisioning.rst index 8d143f3..d66a54c 100644 --- a/docs/requirements/use_cases/programmable_provisioning.rst +++ b/docs/requirements/use_cases/programmable_provisioning.rst @@ -1,24 +1,27 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 -Programmable Provisioning of Provider networks +Programmable Provisioning of Provider Networks ---------------------------------------------- Description ~~~~~~~~~~~ -In NFV environment the VNFM (consumer of OpenStack IaaS API) have no -administrative rights, however in the telco domain provider networks are used in -some cases. When a provider network is created administrative rights are needed -what in the case of a VNFM without administrative rights needs manual work. -It shall be possible to configure provider networks without administrative rights. -It should be possible to assign the capability to create provider networks to -any roles. + +In a NFV environment the VNFMs (Virtual Network Function Manager) are consumers +of the OpenStack IaaS API. They are often deployed without administrative rights +on top of the NFVI platform. Furthermore, in the telco domain provider networks +are often used. However, when a provider network is created administrative +rights are needed what in the case of a VNFM without administrative rights +requires additional manual configuration work. It shall be possible to +configure provider networks without administrative rights. It should be +possible to assign the capability to create provider networks to any roles. + Derived Requirements ~~~~~~~~~~~~~~~~~~~~~ - Authorize the possibility of provider network creation based on policy - There should be a new entry in :code:`policy.json` which controls the provider network creation - Default policy of this new entry should be :code:`rule:admin_or_owner`. - - This policy should be respected by neutron API + - This policy should be respected by the Neutron API Northbound API / Workflow +++++++++++++++++++++++++ @@ -34,5 +37,8 @@ Only admin users can manage provider networks [OS-NETWORKING-GUIDE-ML2]_. Potential implementation ~~~~~~~~~~~~~~~~~~~~~~~~ - - Policy engine shall be able to handle a new provider network creation and modification related policy - - When a provider network is created or modified neutron should check the authority with the policy engine instead of requesting administrative rights + - Policy engine shall be able to handle a new provider network creation and + modification related policy. + - When a provider network is created or modified neutron should check the + authority with the policy engine instead of requesting administrative + rights. diff --git a/docs/requirements/use_cases/service-binding-pattern.rst b/docs/requirements/use_cases/service-binding-pattern.rst deleted file mode 100644 index a5088a3..0000000 --- a/docs/requirements/use_cases/service-binding-pattern.rst +++ /dev/null @@ -1,199 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) Georg Kunz - - -Service Binding Design Pattern ------------------------------- - -Description -^^^^^^^^^^^ - -This use case aims at binding multiple networks or network services to a single -vNIC (port) of a given VM. There are several specific application scenarios for -this use case: - -* Shared Service Functions: A service function connects to multiple networks of - a tenant by means of a single vNIC. - - Typically, a vNIC is bound to a single network. Hence, in order to directly - connect a service function to multiple networks at the same time, multiple vNICs - are needed - each vNIC binding the service function to a separate network. For - service functions requiring connectivity to a large number of networks, this - approach does not scale as the number of vNICs per VM is limited and additional - vNICs occupy additional resources on the hypervisor. - - A more scalable approach is to bind multiple networks to a single vNIC - and let the service function, which is now shared among multiple networks, - handle the separation of traffic itself. - - -* Multiple network services: A service function connects to multiple different - network types such as a L2 network, a L3(-VPN) network, a SFC domain or - services such as DHCP, IPAM, firewall/security, etc. - - -In order to achieve a flexible binding of multiple services to vNICs, a logical -separation between a vNIC (instance port) - that is, the entity that is used by -the compute service as hand-off point between the network and the VM - and a -service interface - that is, the interface a service binds to - is needed. - -Furthermore, binding network services to service interfaces instead of to the -vNIC directly enables a more dynamic management of the network connectivity of -network functions as there is no need to add or remove vNICs. - - -Requirements -^^^^^^^^^^^^ - -Data model -"""""""""" - -This section describes a general concept for a data model and a corresponding -API. It is not intended that these entities are to be implemented exactly as -described. Instead, they are meant to show a design pattern for future network -service models and their corresponding APIs. For example, the "service" entity -should hold all required attributes for a specific service, for instance a given -L3VPN service. Hence, there would be no entity "service" but rather "L3VPN". - - -* ``instance-port`` - - An instance port object represents a vNIC which is bindable to an OpenStack - instance by the compute service (Nova). - - *Attributes:* Since an instance-port is a layer 2 device, its attributes - include the MAC address, MTU and others. - - -* ``interface`` - - An interface object is a logical abstraction of an instance-port. It allows to - build hierarchies of interfaces by means of a reference to a parent interface. - Each interface represents a subset of the packets traversing a given port or - parent interface after applying a layer 2 segmentation mechanism specific to the - interface type. - - *Attributes:* The attributes are specific to the type of interface. - - *Examples:* trunk interface, VLAN interface, VxLAN interface, MPLS interface - - -* ``service`` - - A service object represents a specific networking service. - - *Attributes:* The attributes of the service objects are service specific and - valid for given service instance. - - *Examples:* L2, L3VPN, SFC - - -* ``service-port`` - - A service port object binds an interface to a service. - - *Attributes:* The attributes of a service-port are specific for the bound - service. - - *Examples:* port services (IPAM, DHCP, security), L2 interfaces, L3VPN - interfaces, SFC interfaces. - - - -Northbound API -"""""""""""""" - -An exemplary API for manipulating the data model is described below. As for the -data model, this API is not intended to be a concrete API, but rather an example -for a design pattern that clearly separates ports from services and service -bindings. - -* ``instance-port-{create,delete} `` - - Creates or deletes an instance port object that represents a vNIC in a VM. - - -* ``interface-{create,delete} [interface type specific parameters]`` - - Creates or deletes an interface object. - - -* ``service-{create,delete} [service specific parameters]`` - - Create a specific service object, for instance a L3VPN, a SFC domain, or a L2 network. - - -* ``service-port-{create,delete} [service specific parameters]`` - - Creates a service port object, thereby binding an interface to a given service. - - - -Orchestration -""""""""""""" - -None. - - -Dependencies on other resources -""""""""""""""""""""""""""""""" - -The compute service needs to be enabled to consume instance ports instead of -classic Neutron ports. - - -Current Implementation -^^^^^^^^^^^^^^^^^^^^^^ - -The core Neutron API [**describe what is meant by that**] does not follow the -service binding design pattern. For example, a port has to exist in a Neutron -network - specifically it has to be created for a particular Neutron network. It -is not possible to create just a port and assign it to a network later on as -needed. As a result, a port cannot be moved from one network to another, for -instance. - -Regarding the shared service function use case outlined above, there is an -ongoing activity in Neutron [VLAN-AWARE-VMs]_. The solution proposed by this -activity allows for creating a trunk-port and multiple sub-ports per Neutron -port which can be bound to multiple networks (one network per sub-port). This -allows for binding a single VNIC to multiple networks and allow the -corresponding VMs to handle the network segmentation (VLAN tagged traffic) -itself. While this is a step in the direction of binding multiple services -(networks) to a port, it is limited by the fundamental assumption of Neutron -that a port has to exist on a given network. - -There are extensions of Neutron that follow the service binding design pattern -more closely. An example is the BGPVPN project. A rough mapping of the service -binding design pattern to the data model of the BGPVPN project is as follows: - -* instance-port -> Neutron port - -* service -> VPN - -* service-port -> network association - -This example shows that extensions of Neutron can in fact follow the described -design pattern in their respective data model and APIs. - - - -Conclusions -^^^^^^^^^^^ - -In conclusion, the design decisions taken for the core Neutron API and data -model do not follow the service binding model. As a result, it is hard to -implement certain use cases which rely on a flexible binding of services to -ports. Due to the backwards compatibility to the large amount of existing -Neutron code, it is unlikely that the core Neutron API will adapt to this design -pattern. - -New extension to Neutron however are relatively free to choose their data model -and API - within the architectural boundaries of Neutron of course. In order to -provide the flexibility needed, extensions shall aim for following the service -binding design pattern if possible. - -For the same reason, new networking frameworks complementing Neutron, such as -Gluon, shall follow this design pattern and create the foundation for -implementing networking services accordingly. - diff --git a/docs/requirements/use_cases/service_binding_pattern.rst b/docs/requirements/use_cases/service_binding_pattern.rst new file mode 100644 index 0000000..8abcf7a --- /dev/null +++ b/docs/requirements/use_cases/service_binding_pattern.rst @@ -0,0 +1,198 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Georg Kunz + + +Service Binding Design Pattern +------------------------------ + +Description +^^^^^^^^^^^ + +This use case aims at binding multiple networks or network services to a single +vNIC (port) of a given VM. There are several specific application scenarios for +this use case: + +* Shared Service Functions: A service function connects to multiple networks of + a tenant by means of a single vNIC. + + Typically, a vNIC is bound to a single network. Hence, in order to directly + connect a service function to multiple networks at the same time, multiple vNICs + are needed - each vNIC binds the service function to a separate network. For + service functions requiring connectivity to a large number of networks, this + approach does not scale as the number of vNICs per VM is limited and additional + vNICs occupy additional resources on the hypervisor. + + A more scalable approach is to bind multiple networks to a single vNIC + and let the service function, which is now shared among multiple networks, + handle the separation of traffic itself. + + +* Multiple network services: A service function connects to multiple different + network types such as a L2 network, a L3(-VPN) network, a SFC domain or + services such as DHCP, IPAM, firewall/security, etc. + + +In order to achieve a flexible binding of multiple services to vNICs, a logical +separation between a vNIC (instance port) - that is, the entity that is used by +the compute service as hand-off point between the network and the VM - and a +service interface - that is, the interface a service binds to - is needed. + +Furthermore, binding network services to service interfaces instead of to the +vNIC directly enables a more dynamic management of the network connectivity of +network functions as there is no need to add or remove vNICs. + + +Requirements +^^^^^^^^^^^^ + +Data model +"""""""""" + +This section describes a general concept for a data model and a corresponding +API. It is not intended that these entities are to be implemented exactly as +described. Instead, they are meant to show a design pattern for future network +service models and their corresponding APIs. For example, the "service" entity +should hold all required attributes for a specific service, for instance a given +L3VPN service. Hence, there would be no entity "service" but rather "L3VPN". + + +* ``instance-port`` + + An instance port object represents a vNIC which is bindable to an OpenStack + instance by the compute service (Nova). + + *Attributes:* Since an instance-port is a layer 2 device, its attributes + include the MAC address, MTU and others. + + +* ``interface`` + + An interface object is a logical abstraction of an instance-port. It allows to + build hierarchies of interfaces by means of a reference to a parent interface. + Each interface represents a subset of the packets traversing a given port or + parent interface after applying a layer 2 segmentation mechanism specific to the + interface type. + + *Attributes:* The attributes are specific to the type of interface. + + *Examples:* trunk interface, VLAN interface, VxLAN interface, MPLS interface + + +* ``service`` + + A service object represents a specific networking service. + + *Attributes:* The attributes of the service objects are service specific and + valid for given service instance. + + *Examples:* L2, L3VPN, SFC + + +* ``service-port`` + + A service port object binds an interface to a service. + + *Attributes:* The attributes of a service-port are specific for the bound + service. + + *Examples:* port services (IPAM, DHCP, security), L2 interfaces, L3VPN + interfaces, SFC interfaces. + + + +Northbound API +"""""""""""""" + +An exemplary API for manipulating the data model is described below. As for the +data model, this API is not intended to be a concrete API, but rather an example +for a design pattern that clearly separates ports from services and service +bindings. + +* ``instance-port-{create,delete} `` + + Creates or deletes an instance port object that represents a vNIC in a VM. + + +* ``interface-{create,delete} [interface type specific parameters]`` + + Creates or deletes an interface object. + + +* ``service-{create,delete} [service specific parameters]`` + + Create a specific service object, for instance a L3VPN, a SFC domain, or a L2 network. + + +* ``service-port-{create,delete} [service specific parameters]`` + + Creates a service port object, thereby binding an interface to a given service. + + + +Orchestration +""""""""""""" + +None. + + +Dependencies on other resources +""""""""""""""""""""""""""""""" + +The compute service needs to be enabled to consume instance ports instead of +classic Neutron ports. + + +Current Implementation +^^^^^^^^^^^^^^^^^^^^^^ + +The core Neutron API does not follow the service binding design pattern. For +example, a port has to exist in a Neutron network - specifically it has to be +created for a particular Neutron network. It is not possible to create just a +port and assign it to a network later on as needed. As a result, a port cannot +be moved from one network to another, for instance. + +Regarding the shared service function use case outlined above, there is an +ongoing activity in Neutron [VLAN-AWARE-VMs]_. The solution proposed by this +activity allows for creating a trunk-port and multiple sub-ports per Neutron +port which can be bound to multiple networks (one network per sub-port). This +allows for binding a single VNIC to multiple networks and allow the +corresponding VMs to handle the network segmentation (VLAN tagged traffic) +itself. While this is a step in the direction of binding multiple services +(networks) to a port, it is limited by the fundamental assumption of Neutron +that a port has to exist on a given network. + +There are extensions of Neutron that follow the service binding design pattern +more closely. An example is the BGPVPN project. A rough mapping of the service +binding design pattern to the data model of the BGPVPN project is as follows: + +* instance-port -> Neutron port + +* service -> VPN + +* service-port -> network association + +This example shows that extensions of Neutron can in fact follow the described +design pattern in their respective data model and APIs. + + + +Conclusions +^^^^^^^^^^^ + +In conclusion, the design decisions taken for the core Neutron API and data +model do not follow the service binding model. As a result, it is hard to +implement certain use cases which rely on a flexible binding of services to +ports. Due to the backwards compatibility to the large amount of existing +Neutron code, it is unlikely that the core Neutron API will adapt to this design +pattern. + +New extension to Neutron however are relatively free to choose their data model +and API - within the architectural boundaries of Neutron of course. In order to +provide the flexibility needed, extensions shall aim for following the service +binding design pattern if possible. + +For the same reason, new networking frameworks complementing Neutron, such as +Gluon, shall follow this design pattern and create the foundation for +implementing networking services accordingly. + -- cgit 1.2.3-korg