The document discusses how Calico interprets various Neutron API objects differently than a traditional OpenStack deployment. It explains that in Calico, Neutron networks simply contain subnets and do not define layer 2 connectivity domains. Security groups provide both packet filtering and connectivity limiting functions. Layer 3 routing objects like routers and floating IPs are not supported in Calico. Load balancers also do not function in a Calico network.

1. Calico and how Interprets Neutron API
Rajesh Kumar

2. 2
What is Neutron API / Networking API
The Networking API / Neutron API is a ReSTful HTTP service that uses all aspects
of the HTTP protocol including methods, URIs, media types, response codes, and
so on. Providers can use existing features of the protocol including caching,
persistent connections, and content compression. For example, providers who
employ a caching layer can respond with a 203 code instead of a 200 code when a
request is served from the cache. Additionally, providers can offer support for
conditional GET requests by using ETags, or they may send a redirect in response
to a GET request. Create clients so that these differences are accounted for.

3. 3
Networks
Networks are the basic networking concept in Neutron. A Neutron network is
considered to be roughly equivalent to a physical network in terms of function: it
defines a single layer 2 connectivity graph.
In vanilla Neutron, these can map to the underlay network in various ways, either by
being encapsulated over it or by being directly mapped to it.
Generally speaking, Neutron networks can be created by all tenants. The
administrator tenant will generally create some public Neutron networks that map to
the underlay physical network directly for providing floating IPs: other tenants will
create their own private Neutron networks as necessary.

4. 4
Networks
In Calico, because all traffic is L3 and routed, the role of Neutron network as L2
connectivity domain is not helpful. Therefore, in Calico, Neutron networks are simply
containers for subnets. Best practices for operators configuring Neutron networks in
Calico deployments can be found in this document.
It is not useful for non-administrator tenants to create their own Neutron networks.
Although Calico will allow non-administrator tenants to create Neutron networks,
generally speaking administrators should use Neutron quotas to prevent non-
administrator tenants from doing this.
Network creation events on the API are no-op events in Calico: a positive (2XX)
response will be sent but no programming will actually occur.

5. 5
Extended Attributes: Provider Networks
Neutron Provider networks are not used in Calico deployments. Setting provider
network extended attributes will have no effect. See this document to understand
why Neutron provider networks are not needed.
Subnets
Neutron subnets are child objects of Neutron networks. In vanilla Neutron, a subnet
is a collection of IP addresses and other network configuration (e.g. DNS servers)
that is associated with a single Neutron network. A single Neutron network may
have multiple Neutron subnets associated with it. Each Neutron subnet represents
either an IPv4 or IPv6 block of addresses.
Best practices for configuring Neutron subnets in Calico deployments can be
found here.
In Calico, these roles for the Neutron subnet are preserved in their entirety. All
properties associated with these Neutron subnets are preserved and remain
meaningful except for:
host_routes
These have no effect, as the compute nodes will route traffic immediately after it
egresses the VM.

6. 6
Ports
In vanilla Neutron, a port represents a connection from a VM to a single layer 2
Neutron network. Obviously, the meaning of this object changes in a Calico
deployment: instead, a port is a connection from a VM to the shared layer 3 network
that Calico builds in Neutron.
All properties on a port work as normal, except for the following:
network_id
The network ID still controls which Neutron network the port is attached to, and
therefore still controls which Neutron subnets it will be placed in. However, as per
the note above, the Neutron network that a port is placed in does not affect which
machines in the deployment it can contact.

7. 7
Security Groups
Security groups in vanilla OpenStack provide packet filtering processing to individual
ports. They can be used to limit the traffic a port may issue.
In Calico, security groups have all the same function. Additionally, they serve to
provide the connectivity-limiting function that in vanilla OpenStack is provided by
Neutron networks.
All the attributes of security groups remain unchanged in Calico.

8. 8
Security Groups
Layer 3 Routing: Routers and Floating Ips
Layer 3 routing objects are divided into two categories: routers and floating IPs.
Neither of these objects are supported by Calico: they simply aren’t required. For
more information, see this document.
Any attempt to create these objects will fail, as Calico does not set up any Neutron
L3 Agents.
LBaaS (Load Balancer as a Service)
Load Balancer as a Service does not function in a Calico network. Any attempt to
create one will fail.
Note: It is possible that in a future version of Calico LBaaS may be functional. Watch this space.

9. THANK YOU

10. THANK YOU