That time works for me (I fly back to America the night before) Regards, Colin
Colin McNamara People | Process | Technology -------------------------------------------- Mobile: 858-208-8105 Twitter: @colinmcnamara Linkedin: www.linkedin.com/colinmcnamara Blog: www.colinmcnamara.com Email: co...@2cups.com On Nov 8, 2013, at 2:01 PM, Pedro Roque Marques <pedro.r.marq...@gmail.com> wrote: > 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 na...@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.gro...@huawei.com> > wrote: > >> >> >> From: Pedro Roque Marques [mailto:pedro.r.marq...@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 <co...@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: co...@2cups.com >> >> >> >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
