-----Original Message-----
From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Hideyuki Tai
Sent: Monday, November 18, 2013 6:23 PM
To: Anees A Shaikh; Suchi Raman; <discuss@...>
Cc: <affinity-dev@...>; integration-dev@...; <opendove-dev@...>; vtn-dev@...
Subject: Re: [OpenDaylight Discuss] [affinity-dev] [vtn-dev] [opendove-dev] [integration-dev] Virtualization Edition Guide for VTN Manager

I totally agree with Anees.

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-----
From: Anees A Shaikh [mailto:aashaikh@...]
Sent: Tuesday, November 19, 2013 10:09 AM
To: Suchi Raman
Cc: <affinity-dev@...>; <discuss@...>; Tai, Hideyuki;
integration-dev@...; Madhu Venguopal (mavenugo@...); <opendove-dev@...>;
vtn-dev@...
Subject: Re: [affinity-dev] [vtn-dev] [opendove-dev] [integration-dev] Virtualization Edition Guide for VTN Manager

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@...>
To: Hideyuki Tai <h-tai@...>,
Cc: Anees A Shaikh/Watson/IBM@IBMUS, "<affinity-
dev@...>" <affinity-dev@...>,
"<discuss@...>" <discuss@...>,
"Madhu Venguopal (mavenugo@...)" <mavenugo@...>,
"integration-dev@..." <integration-
dev@...>, "<opendove-dev@...>"
<opendove-dev@...>, "vtn-
dev@..." <vtn-dev@...>
Date: 11/18/2013 07:00 AM
Subject: Re: [affinity-dev] [vtn-dev] [opendove-dev] [integration-
dev] Virtualization Edition Guide for VTN Manager

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:

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.

Affinity is currently unaware of virtual network context (VTN or
Dove vnet) or for that matter virtual controller context (containers).

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,

It seems to me that affinity.nfchainagent and
affinity.implementation bundles depend on affinity.l2agent.
The affinity.l2agent runs as a learning switch like the one
described in the following link.
http://archive.openflow.org/wk/index.php/
OpenDayLight_Tutorial#Sample_application:_MAC_Hub_or_Learning_Switch

The affinity.l2agent installs flow entries when it receives a packet
and it knows the destination MAC address of the packet.
So the affinity.l2agent allows communication between all hosts it

detects.

L2Agent.java
https://git.opendaylight.org/gerrit/gitweb?
p=affinity.git;a=blob_plain;f=l2agent/src/main/java/org/
opendaylight/affinity/l2agent/
L2Agent.java;h=b3b285b415bb30fd732de8f6bbae8a645ca90817;hb=HEAD

Is my understanding right?


On the other hand, VTN Manager allows communication only between
hosts which belong to the same virtual tenant.

Therefore, flow entries installed by affinity service and VTN
Manager might be inconsistent.

For the second release, it's better to provide some kind of
mechanism to select which approach to use for peaceful coexistence.

In the last hackfest (September 10), I heard that Madhu planned to
add a functionality to Container Manager
which provides a way to select bundles to be copyed for a container
to be created.
I think such an approach solves the problem.

Regards,
Hideyuki Tai

-----Original Message-----
From: vtn-dev-bounces@... [mailto:vtn-dev-

bounces@...] On Behalf Of Hideyuki Tai

Sent: Monday, November 18, 2013 4:55 PM
To: Anees A Shaikh
Cc: <discuss@...>;

<affinity-dev@...

; integration-dev@...;
<opendove-dev@...>; Ed Warnicke (eaw); vtn-

dev@...

Subject: Re: [vtn-dev] [opendove-dev] [integration-dev]

Virtualization Edition Guide for VTN Manager

Hi Anees,

Are any of the virtualization services currently clients of the

affinity

service (Open DOVE is not at this point)?

VTN Manager is not also a client of the affinity service.
And, I don't know any clients of the affinity service in the

Virtualization Edition.

In my environment, I did not send any configuration to the affinity

service,

but the affinity service installed flow entries to switches when

the controller received packets.

I'll check the behavior of the affinity service and VTN Manager in

the Virtualization Edition again.

Thanks,
Hideyuki Tai

-----Original Message-----
From: Anees A Shaikh [mailto:aashaikh@...]
Sent: Monday, November 18, 2013 9:03 AM
To: Ed Warnicke (eaw)
Cc: <affinity-dev@...>;

<discuss@...

; Tai, Hideyuki;

integration-dev@...; <opendove-

dev@...>;

opendove-dev-bounces@...;

vtn-dev@...
Subject: Re: [opendove-dev] [integration-dev] Virtualization

Edition Guide for VTN Manager

I don't expect we will be able to get simultaneous coexistence

between the

VTN/OpenDOVE/OVSDB virtualization implementations in the first

release ,

for example. I was always expecting some kind of configuration

needed to

select which approach to use based on the user environment. Using
multiple implementations also has implication on NB integrations

with

OpenStack, which I don't think we've figured out yet.

That said, it seems odd to me that affinity would be an issue -- my
impression was that it provides a way to specify relationships --

and

other services are essentially clients of the affinity service and

pick up

what the user has specified. Is the nature of the

incompatibility also

documented somewhere (assuming we have some idea of what is

breaking)? Are

any of the virtualization services currently clients of the affinity
service (Open DOVE is not at this point)?

thanks.

-- Anees

opendove-dev-bounces@... wrote on 11/15/2013

11:09:53

PM:

From: "Ed Warnicke (eaw)" <eaw@...>
To: Hideyuki Tai <h-tai@...>,
Cc: "<affinity-dev@...>" <affinity-
dev@...>, "<discuss@...>"
<discuss@...>, "integration-
dev@..." <integration-
dev@...>,

"<opendove-dev@...>"

<opendove-dev@...>, "vtn-
dev@..." <vtn-dev@...>
Date: 11/15/2013 11:19 PM
Subject: Re: [opendove-dev] [integration-dev] Virtualization

Edition

Guide for VTN Manager
Sent by: opendove-dev-bounces@...

Hideyuki,

This is a problem as affinity is also part of the virtualization
edition... what can be done to allow peaceful coexistence?

Ed

On Nov 15, 2013, at 12:00 AM, "Hideyuki Tai"

<h-tai@...>

wrote:

Hi all,

I've written the procedure how to run VTN Manager without any

trouble in the Virtualization Edition

in the following page.

https://wiki.opendaylight.org/view/

OpenDaylight_Virtual_Tenant_Network_

(VTN):Installation:Virtualization_Edition

VTN Manager does not work correctly when the following bundles

are

running:

* arphandler bundle (org.opendaylight.controller.arphandler)
* sample bundles (org.opendaylight.controller.samples.*)
* affinity bundles (org.opendaylight.affinity.*)

For example, simpleforwarding

(org.opendaylight.controller.samples.simpleforwarding) sets

flow entries automatically after detecting host information.
These flow entries might be inconsistent with flow entries

installed by VTN Manager.

To let VTN Manager work correctly in the Virtualization Edition,
you have to stop the above bundles.
For example, to prevent OSGi framework from automatically

installing and starting the above bundles,

please edit configuration/config.ini as follows.

47 # Avoid to auto-install following bundles, that means those

need

48 # to be started manually or in other way like osgi.bundles
49 #felix.fileinstall.filter=^(?!org.apache.felix.fileinstall).*
50 felix.fileinstall.filter=\
51 ^(?!org\\.(apache\\.felix\\.fileinstall|\
52 opendaylight\\.(affinity|\
53 controller\\.(arphandler|samples)))).*
54


Installation Guide for VTN Coordinator is available here:
https://wiki.opendaylight.org/view/

OpenDaylight_Virtual_Tenant_Network_(VTN):Installation:VTN_Coordinator

To test VTN Coordinator, please check the above guide.
VTN Coordinator is not included in the Virtualization Edition

yet,

but I believe that it will be included soon.

Regards,
Hideyuki Tai

_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev

_______________________________________________
opendove-dev mailing list
opendove-dev@...
https://lists.opendaylight.org/mailman/listinfo/opendove-dev

_______________________________________________
vtn-dev mailing list
vtn-dev@...
https://lists.opendaylight.org/mailman/listinfo/vtn-dev

_______________________________________________
affinity-dev mailing list
affinity-dev@...
https://lists.opendaylight.org/mailman/listinfo/affinity-dev

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss