Date
1 - 5 of 5
[affinity-dev] [vtn-dev] [opendove-dev] Virtualization Edition Guide for VTN Manager
|
Suchi Raman <suchi.raman@...>
Hideyuki is exactly right -- we added southbound actions for one example affinity -- redirecting a path of flows through a function chain and set openflow priority = 3 to give it higher priority above basic l2 forwarding.
A few possibilities on how to move forward:
(API service): * affinities as being within a virtual network context. We'll need to add a virtual context name or identifier to the API. I believe the NB api for VTN and Dove have unique identifiers for this.
(L2 service): * Traffic redirection uses L2agent to perform mac rewrites - since there is no default L2 implementation, adapting the demo L2agent from the tutorial was a quick way to get going. L2agent is also a single tenant implementation.
My understanding is that Dove and VTN only control edge OVS switches and do not control L2 forwarding of the physical switches -- please correct me here if this is incorrect. Or are we saying that VTN manager has its own connectivity implementation and perhaps Dove has one too. If this is the case using Hideyuki and Madhu's suggestion to select the correct L2 service provider seems like the right thing. There is one method in particular used for Mac re-writes -- not sure how easy this is to implement in the VTN or Dove L2 service.
I think this integration is important for first release, so would appreciate a quick resolution to this.... Suchi
On Mon, Nov 18, 2013 at 4:38 AM, Hideyuki Tai <h-tai@...> wrote: Hi all,
|
|
|
|
Suchi Raman <suchi.raman@...>
Correction: We don't do mac re-writes. The traffic redirection service in the affinity repository used to implement the southbound data path for path redirect affinity does not do mac re-writes. It consults the L2 service to do a MAC address to output port lookup for the waypoint server's address and proceeds to forward it toward the waypoint. The MAC addresses on the frame remain unchanged.
On Mon, Nov 18, 2013 at 9:41 AM, Suchi Raman <suchi.raman@...> wrote:
|
|
|
|
Anees A Shaikh <aashaikh@...>
Suchi, I see several issues brewing here (and I don't think an integration
is really feasible for Hydrogen). If affinity is just doing L2 redirection as an *example* to support such an affinity, shouldn't these rules be off by default? In other words, if affinity is a companion service for virtual networking, my view is that it should work within the context of the implementations providing the actual virtual network support. In that case, your first suggested alternative would make the most sense IMO. If you want to focus on the L2 service (your second option), then I'm not sure what the connection would be to virtual networking since as you said, this would be a single tenant example. Regarding your questions: DOVE does only control edge OVS switches, but VTN can (and does) program physical OF switches based on what I know about it. And yes, both have their own connectivity implementation and would need to be integrated to use a third-party redirection such as the one Affinity is trying to do in this example. But to be honest, I was expecting affinity to primarily provide a relationship database of sorts that other services could use to then implement those relationships on the network. The redirection stuff seems to go way beyond this scope. thanks. -- Anees Suchi Raman <suchi.raman@...> wrote on 11/18/2013 07:00:45 AM: From: Suchi Raman <suchi.raman@...> On Mon, Nov 18, 2013 at 9:41 AM, Suchi Raman <suchi.raman@...>wrote:
On Mon, Nov 18, 2013 at 4:38 AM, Hideyuki Tai <h-tai@...>wrote: Hi all,detects. <affinity-dev@... affinity; integration-dev@...;dev@... service,Virtualization Edition.service (Open DOVE is not at this point)?VTN Manager is not also a client of the affinity service. <discuss@...but the affinity service installed flow entries to switches whenthe controller received packets.the Virtualization Edition again. opendove-dev-bounces@...;; Tai, Hideyuki(田井, 秀幸);dev@...>;integration-dev@...; <opendove- between theEdition Guide for VTN Managervtn-dev@... release ,VTN/OpenDOVE/OVSDB virtualization implementations in the first needed tofor example. I was always expecting some kind of configuration withselect which approach to use based on the user environment. Using andOpenStack, which I don't think we've figured out yet. pick upother services are essentially clients of the affinity service and incompatibility alsowhat the user has specified. Is the nature of the breaking)? Aredocumented somewhere (assuming we have some idea of what is 11:09:53any of the virtualization services currently clients of the affinity "<opendove-dev@...>"PM:From: "Ed Warnicke (eaw)" <eaw@...> Edition<opendove-dev@...>, "vtn- <h-tai@...>Guide for VTN Manager are(VTN):Installation:Virtualization_Editionwrote:OpenDaylight_Virtual_Tenant_Network_trouble in the Virtualization Edition needrunning:* arphandler bundle (org.opendaylight.controller.arphandler)(org.opendaylight.controller.samples.simpleforwarding) sets OpenDaylight_Virtual_Tenant_Network_(VTN):Installation:VTN_Coordinator48 # to be started manually or in other way like osgi.bundles yet, ______________________________________________________________________________________________but I believe that it will be included soon._______________________________________________
|
|
|
|
Suchi Raman <suchi.raman@...>
Agreed -- we should proceed as discussed on the call today. To summarize for those who didn't attend: The traffic redirection service currently implemented by us is for demo/test only and will be maintained as a separate service -- not required as a dependency for affinity metadata service. The open question which we may have to punt to next release is exactly how real L2/L3 connectivity services (Dove, VTN) will interact with this metadata. Also using the "container" as the tenant context seemed to be a reasonable assumption for first release. How to map container to virtual network context is up to the data path implementation. Suchi
On Mon, Nov 18, 2013 at 8:08 PM, Anees A Shaikh <aashaikh@...> wrote: Suchi, I see several issues brewing here (and I don't think an integration
|
|
|
|
Hideyuki Tai <h-tai@...>
I totally agree with Anees.
toggle quoted messageShow quoted text
I don't think more peaceful integration is really feasible for Hydrogen. Actually, there are already severl ways to select services. One way is to edit configuration file to filter bundles as I show in the wiki page. Other way is to start/stop bundles on OSGi console after start up a controller. Regarding Suchi questions: Anees is right. VTN Manager controls not only edge OVS switches, but it controls edge/core physical/virtual OpenFlow switches. Thanks, Hideyuki Tai
-----Original Message-----
|
|
|