Hi, I am observing that here there are overlapping functionality between Routing and Topology ..
1. Adding Routing into OpenStack ( by link state protocol : OSPF/other) to learn prefix of underlay network and inject into overlay network. Builds for CN + Physical Switch/Router .. 2. Use topology ( build by OSPF) for any other purpose, including Traffic Engineer if required later. 3. Export this topology information to ODL (Open daylight) later to build " Service Chaining across underlay and Overlay network". So in my opinion adding the routing in the underlay network and 'topology as service' can be interlinked and needs consider many aspects considering further upcoming requirements .. Thanks & regards, Keshava.A -----Original Message----- From: Isaku Yamahata [mailto:isaku.yamah...@gmail.com] Sent: Monday, May 26, 2014 5:02 PM To: OpenStack Development Mailing List Cc: isaku.yamah...@intel.com; kpr...@yahoo.com; isaku.yamah...@gmail.com Subject: [openstack-dev] [neutron][ironic] topology as a service (physical network topology): design summit follow up Hi. As discussed at the summit[1], there are much requirement for topology as a service that stores/provides information of physical network topology in one place. In order to make progress, I'd like to discuss issues which were raised at the summit. I also created etherpad page and wiki page for this[2][3]. - IRC meeting For starter, how about having IRC meeting? I propose this time slot June 4 Wednesday: 5:00am UTC- #openstack-meeting-3 My time zone is JST(UTC+9) - Should this service be a separated service from Neutron? Although I originally created blueprint/specs for neutron extension[4][5], it was argued that this service should be a separated service from neutron because it is useful not only for neutron, but also for nova, ironic, gantt and so on without neutron. To be honest I don't have strong opinion on this and I'm fine to start incubation process. Are there anyone who helps as core-reviewer? I need help for incubation process. Otherwise I have no choice except staying in Neutron. - TripleO link aggrigation > TripleO has a need to configure link aggregation. Will this > provide enough info/capability? - ChuckC Chuck, could you please elaborate on it and/or provide any pointers for it? http://lists.openstack.org/pipermail/openstack-dev/2014-February/026868.html I found only the pointer. As long as I understand from this link, what TripleO needs is something like - compute-node has multiple nics - those nics are connected to same switch - the configuration of the switch (properly configured) - API and data models are under review as [5] [1] https://etherpad.openstack.org/p/hierarchical_network_topology [2] https://wiki.openstack.org/wiki/Topology-as-a-service [3] https://etherpad.openstack.org/p/topology-as-a-service [4] https://blueprints.launchpad.net/neutron/+spec/physical-network-topology [5] https://review.openstack.org/#/c/91275/ thanks, -- Isaku Yamahata <isaku.yamah...@gmail.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