Open Stack

Nachi,

I'm sorry to have missed this meeting.  In my jet-lagged state, I
somehow got it on my calendar for last night rather than last Tuesday
night (my local time, MST).  I have an interest in the dynamic routing
area of neutron and I would like to be involved.

Will this meeting be weekly?  I'll go read through the meeting log.

Carl Baldwin

On Thu, Nov 7, 2013 at 11:18 PM, Nachi Ueno <nachi at ntti3.com> wrote:
> 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
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev