neutron

Integrated APIs for specification of connectivity (L2 and L3) as well as network services (FW, LB, NAT, QoS... )

Registered by Sasha Ratkovic

Integrated APIs for specification of connectivity services (L2 and L3) as well as network services (FW, LB, NAT, QoS, ...). Abstractions used are:

- Port/EndPoint – an abstraction for tenant or provider end point that participates in NaaS (Port in API v2)

- Groups - aggregation of EndPoints used for managing them as a single entity ( there is no equivalent resource in API v2). “Managing” here is means: providing a connectivity service (L2, L3) to a group and applying a one or more Policies (security, qos, load balancing, NAT, …) which defines desired network service to be provided to a group

- Network/L2Domain – has the same semantics as Network in API v2

- L3Domain – provides L3 connectivity to L2Domains which are underlying it

- Policy is an abstraction for a collection of Rules that jointly define/affect the expected behavior of the object it is applied to. Examples are SecurityPolicy (which is similar to the concept of SecurityGroup), LoadBalancingPolicy, etc ...

- Rule - is contained in the policy and its specification follows “condition followed by an action” pattern. Condition usually implies some sort of traffic matching expression expressed as triplet consisting of parameter, followed by an operator, followed by a value.

Blueprint information

Status:
Complete
Approver:
dan wendlandt
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
Sasha Ratkovic
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Armando Migliaccio

Related branches

Sprints

Whiteboard

I think this blueprint will end up being part of many other more targeted blueprints.

Agreed, given that "being part of many other ..." means leveraging commonality to tie those other blueprints coherently. For example (still early example as blueprints are still evolving, but good for illustration), I see in LBaaS "pool member" as extension of "port/endpoint", "pool" as an extension of group, and "VIP" an extension of policy. Similarily for ports/securitygroups etc ... I think we may want to avoid the situation where each service models the same abstractions independently of each other.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.