Hi all, As requested in the ML2 meeting I worked out a new blueprint [1] specifying a subset of the Campus Network one eventually able to hit H3. I tried to make this blueprint the most generic I could, so I changed the concepts just a little bit. If you agree with this (even if not for H3) I will change the Campus Network BP accordingly.
[1] https://blueprints.launchpad.net/neutron/+spec/ml2-external-port Thank you all Regards Filipe Manco http://about.me/fmanco 2013/7/10 Filipe Manco <filipe.ma...@gmail.com> > I will join you. Thanks! > > Filipe Manco > http://about.me/fmanco > > > 2013/7/10 Kyle Mestery (kmestery) <kmest...@cisco.com> > > On Jul 9, 2013, at 8:40 PM, Filipe Manco <filipe.ma...@gmail.com> wrote: >> > >> > Hi Kyle >> > >> > I already looked at the blueprints and I want to integrate my work with >> ML2, mainly because I want users to able to keep the traditional networking >> models working in parallel (and I think ML2 is the best way to do this >> comparing with the meta plugin). >> > >> > To be honest, the integration with Neutron and the ML2 was what took >> most of the time when writing the blueprint, but although I talk about it >> on the blueprint I still not sure about the best way to do it. >> > >> > About the concept of segments I don't think they fit. From what I >> understand a segment, in the context of ML2, represents part of the virtual >> network that uses some technology to connect a set of VMs, so if I delete a >> segment those VMs will loose connectivity. In the context of my blueprint a >> segment (or cSegment as I called it) represents a domain where I can create >> virtual links across a set of nodes. If I delete a cSegment that doesn't >> mean any VM will loose connectivity, what will happen is that the network >> is remapped and the traffic will cross another cSegment or another set of >> cSegments. >> > >> I think what you've mentioned here is valid, yes, and is a slight >> deviation between the way segments in ML2 work on your cSegments. It looks >> like we would need to add your new constructs into the ML2 API to achieve >> what you're looking for. >> >> > Something that I would like you (or other guys from ML2) to comment is >> how to integrate new operations (beyond the ones related with the base data >> model) in the ML2 interfaces. The MechanismDriver interface supports >> operations on ports and networks, but as you can see I have new entities. >> My idea is that there should be no changes to the original interfaces, >> because this are specific to a type of network. What do you think? >> > >> I'll have a look at this tomorrow and give you more detailed feedback. If >> you want, you can join us in the ML2 meeting at 1400UTV meeting on >> #openstack-meeting and I'll save some time at the end of the meeting to >> discuss your blueprint. >> >> Thanks! >> Kyle >> >> > It would help me if you have the time to take a look at the blueprint >> and comment on the ML2 parts. >> > >> > Thanks for your help! >> > >> > Filipe Manco >> > http://about.me/fmanco >> > >> > >> > 2013/7/9 Kyle Mestery (kmestery) <kmest...@cisco.com> >> > On Jul 9, 2013, at 11:18 AM, Filipe Manco <filipe.ma...@gmail.com> >> wrote: >> > > >> > > Hi all, >> > > >> > > Just published a blueprint for some work I'm starting right now. I >> would appreciate if someone can take a look and give some comments. >> > > >> > > https://blueprints.launchpad.net/neutron/+spec/campus-network >> > > >> > > Thank you >> > > >> > Hi Filipe: >> > >> > At first glance, there appears to be a lot of overlap with ML2 here. >> Have you looked at the ML2 blueprints, and the specific use case of >> multi-segment networks? The ML2 team is working hard to close ML2 >> blueprints in H2/H3, perhaps some of your ideas could be incorporated here? >> > >> > Here is the ML2 Meeting page which has links to the blueprints we're >> tracking: >> > >> > https://wiki.openstack.org/wiki/Meetings/ML2 >> > >> > Thanks, >> > Kyle >> > >> > > >> > > Filipe Manco >> > > http://about.me/fmanco >> > > _______________________________________________ >> > > 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 >> > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
