Open Stack

I have a couple concerns that I don’t feel I clearly communicated during the L3 advanced features session. I’d like to take this opportunity to both clearly communicate my thoughts, as well as start a discussion around them.

Building to the edge of the "autonomous system"
The current state of neutron implementation is functionally the l2 domain and simple l3 services that are part of a larger autonomous system. The routers and switches northbound of the OpenStack networking layer handled the abstraction and integration of the components.
Note, I use the term “Autonomous System” to describe more then the notion of BGP AS, but more broadly in the term of a system that is controlled within a common framework and methodology, and integrates with a peer system that doesn’t not share that same scope or method of control
These components that composed the autonomous system boundary implement protocols and standards that map into IETF and IEEE standards. The reasoning for this is interoperability. Before vendors utilize IETF for interoperability at this layer, the provider experience was horrible (this was my personal experience in the late 90’s).
 
Wednesdays discussions in the Neutron Design Sessions
A couple of the discussions, most notably the extension of l3 functionality fell within the scope of starting the process of extending Neutron with functionality that will result (eventually) in the ability for an OpenStack installation to operate as it’s own Autonomous System.
The discussions that occurred to support L3 advanced functionality (northbound boundary), and the QOS extension functionality both fell into the scope of Northbound and Southbound boundaries of this system.
My comments in the session
My comments in the session, while clouded with jet-lag were specifically around two concepts that are used when integrating other types of systems 
1. In a simple (1-8) tenant environment integration with a northbound AS is normally done in a PE-CE model that generally centers around mapping dot1q tags into the appropriate northbound l3 segments and then handling the availability of the L2 path that traverses with port channeling, MLAG, STP, Etc.
2. In a complex environment (8+ for discussion) different Carrier Supporting Carrier (CSC) methods defined in IETF RFC 4364 Section 10 type A, B or C are used. These allow the mapping of segregated tenant networks together and synchronizing between distributed systems. This normally extends the tagging or tunneling mechanism and then allows for BGP to synchronize NLRI information between AS’s.
These are the standard ways of integrating between carriers, but also components of these implementations are used to integrate and scale inside of a single web scale data center. Commonly when you scale beyond a certain physical port boundary (1000is edge ports in many implementations, much larger in current implementations) the same designs for C2C integrations are used to create network availability zones inside a web scale data center. 
Support of these IETF and IEEE standard integrations are necessary for brown field installations
In a green field installation, diverging from IETF and IEEE standards on the north bound edge while not a great idea, can result in a functional implementation. In a brown field implementation where OpenStack Neutron will be integrated into an existing network core. This boundary layer is where we move from a controlled system into a distributed system. The cleanly integrate into this system, IETF and IEEE protocols and standards have to be followed. 
 
When we diverge from this standards based integration at the north edge of our autonomous system we lose the ability to integrate without introducing major changes (and risk), into our core. In my experience this is sufficient to either slow or stall adoption. This is a major risk, that I believe can be mitigated.
My thoughts on mitigating this risk
We need to at least map and track the relevant IETF RFC’s that define the internet standards for integration at the AS boundary. I know that many of the network vendor developers that contribute to Neutron have access to people who both have deep knowledge of these standards, and also participate in the IETF working groups. I would hope that these resources could be leveraged to at least give a sanity check, at best ensure a compliant northbound interface to other systems.
Side benefit of engaging IETF members in this discussion
The other side benefit of this is that inventions inside of Neutron can also be communicated as standards to the rest of the world in the form of net new RFC’s. In OVS this has already happened, as OVS has emerged to be a common component in many network devices, and the need to establish and reference a common standard has risen it’s head. I would think that inventions within Neutron would follow this same path.

Regards,

Colin

Colin McNamara
People | Process | Technology
--------------------------------------------
Mobile: 	858-208-8105
Twitter:	@colinmcnamara
Linkedin:	www.linkedin.com/colinmcnamara
Blog:	www.colinmcnamara.com
Email:	colin at 2cups.com	






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131107/b908db9b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8DB71B56-CDE5-42D5-870E-CF94157510F8.png
Type: image/png
Size: 56849 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131107/b908db9b/attachment-0001.png>