This event has ended. View the official site or create your own event → Check it out
This event has ended. Create your own
Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.
View analytic
Friday, November 8 • 4:10pm - 4:50pm
Network Mini Sessions

Sign up or log in to save this to your schedule and see who's attending!

This session will include the following subject(s):

ML2: Multiple Backend Support:

ML2 plugin potentially supports multiple backend technologies. In Havana, we can use a single backend at the same time.

Considering usecases in cloud data centers or NFV, there are cases where one VM want to connect multiple networks with different networok backend. For example, one interface is connected to Linux Bridge with VLAN for a frontend network and another interface is connected to OVS controlled by SDN controllers for internal network. (We already see a similar case in br-int and br-ex on l3-agent.)

To achieve it, the following topics needs to be considered:
- How to specify backend technologies when creating a network (through extension)
- Machanism driver support
- Nova VIF driver determines a bridge connected to a VIF based on information from Neutron (by extending the port binding extension)

It is somthing different from provider:network_type. network_type specified which protocol (VLAN, GRE, VXLAN, ...) is used for a tenant network and it can work on a single backend technology such as Linux Bridge or OVS.

It may not be specific to ML2 topic but I think ML2 is a good start point of this topic.

(Session proposed by Akihiro Motoki)

Improving the Provider API:

So far in Neutron, there has been more focus on the tenant-facing API than the provider's. For Icehouse, we believe that Neutron API should evolve to provide richer capabilities for the providers. In this session, we would like to discuss the following topics:

Provider Router:

Neutron should let the provider and tenants own their own routers, and they should be able to link the routers together. This enables the model of tenants linking their routers to the provider-owned uplink router. This gives the providers more control over the internet/inter-tenant traffic that passes through its edge router.

(Session proposed by Ryu Ishimoto)

Friday November 8, 2013 4:10pm - 4:50pm
AWE Level 2, Room 201C

Attendees (56)