Open Stack

Hi folks

let's use #openstack-meeting on the meetings.

I have also created an etherpad for this discussion
(If you have any slide, please link to the page)

https://etherpad.openstack.org/p/NeutronDynamicRoutingIceHouse

Best
Nachi



2013/11/8 Pedro Roque Marques <pedro.r.marques at gmail.com>:
> What about an IRC meeting on this topic 11/19 at 9 p.m. PST ? This is 2 p.m
> in Japan and 6 a.m CET on the 20th.
> It is not ideal but i suspect we will have interest in participating from
> both Europe and Asia.
> I volunteer myself and Nachi Ueno nachi at ntti3.com (the author of the BGP
> MPLS blueprint) as agenda organizers; please drop us a note if you intend to
> attend and wether you would like to present something to the group.
>
>   Pedro.
>
> On Nov 7, 2013, at 11:27 AM, Rochelle.Grober <Rochelle.Grober at huawei.com>
> wrote:
>
>
>
> From: Pedro Roque Marques [mailto:pedro.r.marques at gmail.com]
> Colin,
> "The nice thing about standards is that there are so many of them to choose
> from."
>
> For instance, if you take this Internet Draft:
> http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02 which is based on
> RFC4364.
>
> It has already been implemented as a Neutron plugin via OpenContrail
> (http://juniper.github.io/contrail-vnc/README.html); With this
> implementation each OpenStack cluster can be configured as its own
> Autonomous System.
>
> There is a blueprint
> https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn
> that is discussing adding the provisioning of the autonomous system and
> peering to Neutron.
>
> Please note that the work above does interoperate with 4364 using option B.
> Option C is possible but not that practical (as an operator you probably
> don't want to expose your internal topology between clusters).
>
> If you want to give it a try you can use this devstack fork:
> https://github.com/dsetia/devstack.
> You can use it to interoperate with a standard router that implements 4364
> and support MPLS over GRE. Products from cisco/juniper/ALU/huwawei etc do.
>
> I believe that the work i'm referencing implements interoperability while
> having very minimal changes to Neutron. It is based on the same concept of
> neutron virtual network and it hides the BGP/MPLS functionality from the
> user by translating policies that establish connectivity between virtual
> networks into RFC 4364 concepts.
> Please refer to:
> https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
>
> Would it make sense to have an IRC/Web meeting around interoperability with
> RFC4364 an OpenStack managed clusters ? I believe that there is a lot of
> work that has already been done there by multiple vendors as well as some
> carriers.
>
> +1  And it should be scheduled and announced a reasonable time in advance
> developers can plan to participate.
>
> --Rocky
>
>   Pedro.
>
> On Nov 7, 2013, at 12:35 AM, Colin McNamara <colin at 2cups.com> wrote:
>
> 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.
>
>
>
> <8DB71B56-CDE5-42D5-870E-CF94157510F8.png>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
>
>
>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>