Re: [openflowplugin-dev] Openflow version negotiation during Handshake query

2018-05-18 Thread Dayavanti Gopal Kamath
Yeah,  makes sense. In absence of a bitmap, the plugin should assume 1.3 will 
be used as soon as it gets 1.4 from the switch, and not wait for another hello 
msg.

Thanks,
daya

From: Vishal Thapar [mailto:vtha...@redhat.com]
Sent: Friday, May 18, 2018 12:39 PM
To: Dayavanti Gopal Kamath <dayavanti.gopal.kam...@ericsson.com>
Cc: D Arunprakash <d.arunprak...@ericsson.com>; Brady Johnson 
<bjohn...@inocybe.ca>; Gobinath . <gobin...@ericsson.com>; 
netvirt-...@lists.opendaylight.org; openflowplugin-dev@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] Openflow version negotiation during Handshake 
query

As per section 6.3.3 of spec [checking the latest one], there is no ACK for 
successful version negotiation, only NACK. It has always been this way, just 
wanted to confirm in latest one.

If OVS sends 1.4 without version bitmap, it means it supports 1.4 and all 
earlier versions. Moment controller sends 1.3, with or without bitmap, it 
should assume 1.3 will be version used by switch and not wait for positive ACK. 
Negative ACK comes in when controller [or switch] sends HELLO before getting 
version from other side. It is mainly relevant when bitmap is used and there 
may not be a common version between the two.

So, if OFP is waiting for OVS hello to come first, it should be able to make 
the call on negotiation success based on that. OFP Sending hello with its 
version/bitmap is more about letting other side know which one to use.

There is no back and forth coz no additional information is needed by either 
side beyond the first HELLO received.

Regards,
Vishal.

On Fri, May 18, 2018 at 10:49 AM, Dayavanti Gopal Kamath 
<dayavanti.gopal.kam...@ericsson.com<mailto:dayavanti.gopal.kam...@ericsson.com>>
 wrote:
+netvirt-dev

Thanks,
daya

From: D Arunprakash
Sent: Friday, May 18, 2018 9:13 AM
To: Brady Johnson <bjohn...@inocybe.ca<mailto:bjohn...@inocybe.ca>>; Gobinath . 
<gobin...@ericsson.com<mailto:gobin...@ericsson.com>>
Cc: 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>;
 Dayavanti Gopal Kamath 
<dayavanti.gopal.kam...@ericsson.com<mailto:dayavanti.gopal.kam...@ericsson.com>>
Subject: RE: [openflowplugin-dev] Openflow version negotiation during Handshake 
query

Hi Brady,
Even we are setting the protocol manually after creating the bridge. But there 
is a functionality available in openflowplugin which will negotiate the 
protocol version.

If we connect ovs2.8 and above, by default it sends HELLO message with Openflow 
1.4(It doesn’t sent bitmap with this message, bitmap will have details of the 
protocol versions supported by ovs).

Once plugin receives HELLO message with version higher than the supported 
version and if there is no bitmap, OFP send HELLO message with version 1.3 and 
bitmap (1.0, 1.3).

When this OF1.3 message hello message reaches OVS, it assumes that the 
negotiation went fine and makes the TCP channel connected.

But openflowplugin waits for the switch to send HELLO message with next lower 
version ie. 1.3 here.

Sequence diagram of the current handshake implementation:
https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin::Sequence_Diagrams#Connection_Sequence_.28Handshake.29_Diagram

We wanted to know what is the expected behavior and how should be negotiation 
work between openflow switch and odl controller.


Regards,
Arun
From: 
openflowplugin-dev-boun...@lists.opendaylight.org<mailto:openflowplugin-dev-boun...@lists.opendaylight.org>
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Brady 
Johnson
Sent: Friday, May 18, 2018 12:18 AM
To: Gobinath . <gobin...@ericsson.com<mailto:gobin...@ericsson.com>>
Cc: 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] Openflow version negotiation during Handshake 
query

Gobinath,

Im not sure if ODL should automatically negotiate this during the initial 
capability negotiations. Ive seen similar problems with OVS 2.8 and 2.9, and 
when I manually create the bridge, I had to do the following:

$ sudo ovs-vsctl add-br br0
$ sudo ovs-vsctl set bridge br0 
protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13

Or, when creating the bridge from ODL, the following:

public ListenableFuture createOvsBridge(IpAddress ovsMgrIp, String 
ovsBridgeName) {
OvsdbBridgeAugmentationBuilder ovsBridge = new 
OvsdbBridgeAugmentationBuilder();
ovsBridge.setBridgeName(new OvsdbBridgeName(ovsBridgeName));
ovsBridge.setProtocolEntry(Arrays.asList(
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow10.class).build(),
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow11.class).build(),
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow12.class).build

Re: [openflowplugin-dev] Openflow version negotiation during Handshake query

2018-05-18 Thread Vishal Thapar
As per section 6.3.3 of spec [checking the latest one], there is no ACK for
successful version negotiation, only NACK. It has always been this way,
just wanted to confirm in latest one.

If OVS sends 1.4 without version bitmap, it means it supports 1.4 and all
earlier versions. Moment controller sends 1.3, with or without bitmap, it
should assume 1.3 will be version used by switch and not wait for positive
ACK. Negative ACK comes in when controller [or switch] sends HELLO before
getting version from other side. It is mainly relevant when bitmap is used
and there may not be a common version between the two.

So, if OFP is waiting for OVS hello to come first, it should be able to
make the call on negotiation success based on that. OFP Sending hello with
its version/bitmap is more about letting other side know which one to use.

There is no back and forth coz no additional information is needed by
either side beyond the first HELLO received.

Regards,
Vishal.

On Fri, May 18, 2018 at 10:49 AM, Dayavanti Gopal Kamath <
dayavanti.gopal.kam...@ericsson.com> wrote:

> +netvirt-dev
>
>
>
> Thanks,
>
> daya
>
>
>
> *From:* D Arunprakash
> *Sent:* Friday, May 18, 2018 9:13 AM
> *To:* Brady Johnson <bjohn...@inocybe.ca>; Gobinath . <
> gobin...@ericsson.com>
> *Cc:* openflowplugin-dev@lists.opendaylight.org; Dayavanti Gopal Kamath <
> dayavanti.gopal.kam...@ericsson.com>
> *Subject:* RE: [openflowplugin-dev] Openflow version negotiation during
> Handshake query
>
>
>
> Hi Brady,
>
> Even we are setting the protocol manually after creating the bridge. But
> there is a functionality available in openflowplugin which will negotiate
> the protocol version.
>
>
>
> If we connect ovs2.8 and above, by default it sends HELLO message with
> Openflow 1.4(It doesn’t sent bitmap with this message, bitmap will have
> details of the protocol versions supported by ovs).
>
>
>
> Once plugin receives HELLO message with version higher than the supported
> version and if there is no bitmap, OFP send HELLO message with version 1.3
> and bitmap (1.0, 1.3).
>
>
>
> When this OF1.3 message hello message reaches OVS, it assumes that the
> negotiation went fine and makes the TCP channel connected.
>
>
>
> But openflowplugin waits for the switch to send HELLO message with next
> lower version ie. 1.3 here.
>
>
>
> Sequence diagram of the current handshake implementation:
>
> https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_
> Plugin::Sequence_Diagrams#Connection_Sequence_.28Handshake.29_Diagram
>
>
>
> We wanted to know what is the expected behavior and how should be
> negotiation work between openflow switch and odl controller.
>
>
>
>
>
> Regards,
>
> Arun
>
> *From:* openflowplugin-dev-boun...@lists.opendaylight.org [
> mailto:openflowplugin-dev-boun...@lists.opendaylight.org
> <openflowplugin-dev-boun...@lists.opendaylight.org>] *On Behalf Of *Brady
> Johnson
> *Sent:* Friday, May 18, 2018 12:18 AM
> *To:* Gobinath . <gobin...@ericsson.com>
> *Cc:* openflowplugin-dev@lists.opendaylight.org
> *Subject:* Re: [openflowplugin-dev] Openflow version negotiation during
> Handshake query
>
>
>
> Gobinath,
>
>
>
> Im not sure if ODL should automatically negotiate this during the initial
> capability negotiations. Ive seen similar problems with OVS 2.8 and 2.9,
> and when I manually create the bridge, I had to do the following:
>
>
>
> $ sudo ovs-vsctl add-br br0
>
> $ sudo ovs-vsctl set bridge br0 protocols=OpenFlow10,
> OpenFlow11,OpenFlow12,OpenFlow13
>
>
>
> Or, when creating the bridge from ODL, the following:
>
>
>
> public ListenableFuture createOvsBridge(IpAddress ovsMgrIp,
> String ovsBridgeName) {
>
> OvsdbBridgeAugmentationBuilder ovsBridge = new
> OvsdbBridgeAugmentationBuilder();
>
> ovsBridge.setBridgeName(new OvsdbBridgeName(ovsBridgeName));
>
> ovsBridge.setProtocolEntry(Arrays.asList(
>
> new ProtocolEntryBuilder().setProtocol(
> OvsdbBridgeProtocolOpenflow10.class).build(),
>
> new ProtocolEntryBuilder().setProtocol(
> OvsdbBridgeProtocolOpenflow11.class).build(),
>
> new ProtocolEntryBuilder().setProtocol(
> OvsdbBridgeProtocolOpenflow12.class).build(),
>
> new ProtocolEntryBuilder().setProtocol(
> OvsdbBridgeProtocolOpenflow13.class).build()));
>
> ovsBridge.setManagedBy(new OvsdbNodeRef(InstanceIdentifier.create(
> NetworkTopology.class)
>
> .child(Topology.class, new TopologyKey(
> SouthboundConstants.OVSDB_TOPOLOGY_ID))
>
> .child(Node.class, new NodeKey(new 

Re: [openflowplugin-dev] Openflow version negotiation during Handshake query

2018-05-17 Thread Dayavanti Gopal Kamath
+netvirt-dev

Thanks,
daya

From: D Arunprakash
Sent: Friday, May 18, 2018 9:13 AM
To: Brady Johnson <bjohn...@inocybe.ca>; Gobinath . <gobin...@ericsson.com>
Cc: openflowplugin-dev@lists.opendaylight.org; Dayavanti Gopal Kamath 
<dayavanti.gopal.kam...@ericsson.com>
Subject: RE: [openflowplugin-dev] Openflow version negotiation during Handshake 
query

Hi Brady,
Even we are setting the protocol manually after creating the bridge. But there 
is a functionality available in openflowplugin which will negotiate the 
protocol version.

If we connect ovs2.8 and above, by default it sends HELLO message with Openflow 
1.4(It doesn’t sent bitmap with this message, bitmap will have details of the 
protocol versions supported by ovs).

Once plugin receives HELLO message with version higher than the supported 
version and if there is no bitmap, OFP send HELLO message with version 1.3 and 
bitmap (1.0, 1.3).

When this OF1.3 message hello message reaches OVS, it assumes that the 
negotiation went fine and makes the TCP channel connected.

But openflowplugin waits for the switch to send HELLO message with next lower 
version ie. 1.3 here.

Sequence diagram of the current handshake implementation:
https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin::Sequence_Diagrams#Connection_Sequence_.28Handshake.29_Diagram

We wanted to know what is the expected behavior and how should be negotiation 
work between openflow switch and odl controller.


Regards,
Arun
From: 
openflowplugin-dev-boun...@lists.opendaylight.org<mailto:openflowplugin-dev-boun...@lists.opendaylight.org>
 [mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Brady 
Johnson
Sent: Friday, May 18, 2018 12:18 AM
To: Gobinath . <gobin...@ericsson.com<mailto:gobin...@ericsson.com>>
Cc: 
openflowplugin-dev@lists.opendaylight.org<mailto:openflowplugin-dev@lists.opendaylight.org>
Subject: Re: [openflowplugin-dev] Openflow version negotiation during Handshake 
query

Gobinath,

Im not sure if ODL should automatically negotiate this during the initial 
capability negotiations. Ive seen similar problems with OVS 2.8 and 2.9, and 
when I manually create the bridge, I had to do the following:

$ sudo ovs-vsctl add-br br0
$ sudo ovs-vsctl set bridge br0 
protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13

Or, when creating the bridge from ODL, the following:

public ListenableFuture createOvsBridge(IpAddress ovsMgrIp, String 
ovsBridgeName) {
OvsdbBridgeAugmentationBuilder ovsBridge = new 
OvsdbBridgeAugmentationBuilder();
ovsBridge.setBridgeName(new OvsdbBridgeName(ovsBridgeName));
ovsBridge.setProtocolEntry(Arrays.asList(
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow10.class).build(),
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow11.class).build(),
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow12.class).build(),
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow13.class).build()));
ovsBridge.setManagedBy(new 
OvsdbNodeRef(InstanceIdentifier.create(NetworkTopology.class)
.child(Topology.class, new 
TopologyKey(SouthboundConstants.OVSDB_TOPOLOGY_ID))
.child(Node.class, new NodeKey(new 
NodeId(createNodeIdStr(ovsMgrIp));

NodeBuilder ovsBridgeNode = new NodeBuilder();
ovsBridgeNode.addAugmentation(OvsdbBridgeAugmentation.class, 
ovsBridge.build());
ovsBridgeNode.setNodeId(new NodeId(createNodeIdStr(ovsMgrIp, 
ovsBridgeName)));
ovsBridgeNode.setKey(new NodeKey(ovsBridgeNode.getNodeId()));




Regards,

Brady Johnson
bjohn...@inocybe.ca<mailto:bjohn...@inocybe.ca>


[http://www.inocybe.com/wp-content/uploads/2014/09/default-login-image.png]

[https://lh5.googleusercontent.com/4bsvmVYKzg5a_jM7_OOqbLXBSi8HbyuNfXuS5cO9eUpXgLzSUKrmdqdSOFmdShqIg0hX4xUHo2nYSUAlBC7KRnN3-COAkcx0CLOUEQrHCx9TVrQ2-0MP_qR0XpR22Kc8sdAQzZc1]<https://twitter.com/inocybetech>[https://lh3.googleusercontent.com/mkQzuX53_XbTrmTqeiS_gh2tauU4wJ_poqn7v-NSdKZoLI0jbWxdIIhrHZh7rSB-xpU7e2SqYDhcNfE8-rxzlQn15KaqJ9BqWOl65BakoHsKrbcCMhcdsnyrJAVuUV5SIFoazHIr]<http://www.inocybe.com/>[https://lh3.googleusercontent.com/Nzy3ZqITNZfRZ_hT9N3dh7K8ow5sF68e-qmL_5CFjka1oWK2XSfPZOUN6S9gp9k84l1KWTwDPCOb2Vbh0Oi6pVm4Nl7IpXp1QrTI6gkLNcWtMNpHMq2o2CxCfgqTPDA6pKBxNwhY]<https://www.linkedin.com/company/2661537?trk=tyah=clickedVertical%3Acompany%2CclickedEntityId%3A2661537%2Cidx%3A1-1-1%2CtarId%3A1441300264767%2Ctas%3Ainocybe>[Screenshot
 2017-02-14 at 10.43.55 
AM.png]<https://www.youtube.com/channel/UC9uUWABdPR0Je9Du_15FCkw>



On Thu, May 17, 2018 at 6:52 AM, Gobinath . 
<gobin...@ericsson.com<mailto:gobin...@ericsson.com>> wrote:
Hi All,

We tried to connect the OVS2.8.2 with the ODL controller. Though the TCP 
connection is established b/w the OVS and the 

Re: [openflowplugin-dev] Openflow version negotiation during Handshake query

2018-05-17 Thread D Arunprakash
Hi Brady,
Even we are setting the protocol manually after creating the bridge. But there 
is a functionality available in openflowplugin which will negotiate the 
protocol version.

If we connect ovs2.8 and above, by default it sends HELLO message with Openflow 
1.4(It doesn’t sent bitmap with this message, bitmap will have details of the 
protocol versions supported by ovs).

Once plugin receives HELLO message with version higher than the supported 
version and if there is no bitmap, OFP send HELLO message with version 1.3 and 
bitmap (1.0, 1.3).

When this OF1.3 message hello message reaches OVS, it assumes that the 
negotiation went fine and makes the TCP channel connected.

But openflowplugin waits for the switch to send HELLO message with next lower 
version ie. 1.3 here.

Sequence diagram of the current handshake implementation:
https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin::Sequence_Diagrams#Connection_Sequence_.28Handshake.29_Diagram

We wanted to know what is the expected behavior and how should be negotiation 
work between openflow switch and odl controller.


Regards,
Arun
From: openflowplugin-dev-boun...@lists.opendaylight.org 
[mailto:openflowplugin-dev-boun...@lists.opendaylight.org] On Behalf Of Brady 
Johnson
Sent: Friday, May 18, 2018 12:18 AM
To: Gobinath . <gobin...@ericsson.com>
Cc: openflowplugin-dev@lists.opendaylight.org
Subject: Re: [openflowplugin-dev] Openflow version negotiation during Handshake 
query

Gobinath,

Im not sure if ODL should automatically negotiate this during the initial 
capability negotiations. Ive seen similar problems with OVS 2.8 and 2.9, and 
when I manually create the bridge, I had to do the following:

$ sudo ovs-vsctl add-br br0
$ sudo ovs-vsctl set bridge br0 
protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13

Or, when creating the bridge from ODL, the following:

public ListenableFuture createOvsBridge(IpAddress ovsMgrIp, String 
ovsBridgeName) {
OvsdbBridgeAugmentationBuilder ovsBridge = new 
OvsdbBridgeAugmentationBuilder();
ovsBridge.setBridgeName(new OvsdbBridgeName(ovsBridgeName));
ovsBridge.setProtocolEntry(Arrays.asList(
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow10.class).build(),
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow11.class).build(),
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow12.class).build(),
new 
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow13.class).build()));
ovsBridge.setManagedBy(new 
OvsdbNodeRef(InstanceIdentifier.create(NetworkTopology.class)
.child(Topology.class, new 
TopologyKey(SouthboundConstants.OVSDB_TOPOLOGY_ID))
.child(Node.class, new NodeKey(new 
NodeId(createNodeIdStr(ovsMgrIp));

NodeBuilder ovsBridgeNode = new NodeBuilder();
ovsBridgeNode.addAugmentation(OvsdbBridgeAugmentation.class, 
ovsBridge.build());
ovsBridgeNode.setNodeId(new NodeId(createNodeIdStr(ovsMgrIp, 
ovsBridgeName)));
ovsBridgeNode.setKey(new NodeKey(ovsBridgeNode.getNodeId()));




Regards,

Brady Johnson
bjohn...@inocybe.ca<mailto:bjohn...@inocybe.ca>


[http://www.inocybe.com/wp-content/uploads/2014/09/default-login-image.png]

[https://lh5.googleusercontent.com/4bsvmVYKzg5a_jM7_OOqbLXBSi8HbyuNfXuS5cO9eUpXgLzSUKrmdqdSOFmdShqIg0hX4xUHo2nYSUAlBC7KRnN3-COAkcx0CLOUEQrHCx9TVrQ2-0MP_qR0XpR22Kc8sdAQzZc1]<https://twitter.com/inocybetech>[https://lh3.googleusercontent.com/mkQzuX53_XbTrmTqeiS_gh2tauU4wJ_poqn7v-NSdKZoLI0jbWxdIIhrHZh7rSB-xpU7e2SqYDhcNfE8-rxzlQn15KaqJ9BqWOl65BakoHsKrbcCMhcdsnyrJAVuUV5SIFoazHIr]<http://www.inocybe.com/>[https://lh3.googleusercontent.com/Nzy3ZqITNZfRZ_hT9N3dh7K8ow5sF68e-qmL_5CFjka1oWK2XSfPZOUN6S9gp9k84l1KWTwDPCOb2Vbh0Oi6pVm4Nl7IpXp1QrTI6gkLNcWtMNpHMq2o2CxCfgqTPDA6pKBxNwhY]<https://www.linkedin.com/company/2661537?trk=tyah=clickedVertical%3Acompany%2CclickedEntityId%3A2661537%2Cidx%3A1-1-1%2CtarId%3A1441300264767%2Ctas%3Ainocybe>[Screenshot
 2017-02-14 at 10.43.55 
AM.png]<https://www.youtube.com/channel/UC9uUWABdPR0Je9Du_15FCkw>



On Thu, May 17, 2018 at 6:52 AM, Gobinath . 
<gobin...@ericsson.com<mailto:gobin...@ericsson.com>> wrote:
Hi All,

We tried to connect the OVS2.8.2 with the ODL controller. Though the TCP 
connection is established b/w the OVS and the controller, the connected node 
was not present in the DS.

The issue seem to be due to incomplete handshake b/w the switch and the 
controller. This issue in handshake is due to the following :

By default the Openflow version in OVS2.8.2 switches are OF1.4.

Since OF1.4 not supported by the controller, version negotiation process takes 
place to agree on a OF version wherein


a)   If the HELLO msg sent by the switch has version bitmap(field 
containing info about support for all the OF versions), the negotiation is done 
in 

Re: [openflowplugin-dev] Openflow version negotiation during Handshake query

2018-05-17 Thread Brady Johnson
Gobinath,

Im not sure if ODL should automatically negotiate this during the initial
capability negotiations. Ive seen similar problems with OVS 2.8 and 2.9,
and when I manually create the bridge, I had to do the following:

$ sudo ovs-vsctl add-br br0
$ sudo ovs-vsctl set bridge br0
protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13


Or, when creating the bridge from ODL, the following:

public ListenableFuture createOvsBridge(IpAddress ovsMgrIp,
String ovsBridgeName) {
OvsdbBridgeAugmentationBuilder ovsBridge = new
OvsdbBridgeAugmentationBuilder();
ovsBridge.setBridgeName(new OvsdbBridgeName(ovsBridgeName));
ovsBridge.setProtocolEntry(Arrays.asList(
new
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow10.class).build(),
new
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow11.class).build(),
new
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow12.class).build(),
new
ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow13.class).build()));
ovsBridge.setManagedBy(new
OvsdbNodeRef(InstanceIdentifier.create(NetworkTopology.class)
.child(Topology.class, new
TopologyKey(SouthboundConstants.OVSDB_TOPOLOGY_ID))
.child(Node.class, new NodeKey(new
NodeId(createNodeIdStr(ovsMgrIp));

NodeBuilder ovsBridgeNode = new NodeBuilder();
ovsBridgeNode.addAugmentation(OvsdbBridgeAugmentation.class,
ovsBridge.build());
ovsBridgeNode.setNodeId(new NodeId(createNodeIdStr(ovsMgrIp,
ovsBridgeName)));
ovsBridgeNode.setKey(new NodeKey(ovsBridgeNode.getNodeId()));




Regards,

*Brady Johnson*
bjohn...@inocybe.ca

 

[image:
Screenshot 2017-02-14 at 10.43.55 AM.png]




On Thu, May 17, 2018 at 6:52 AM, Gobinath .  wrote:

> Hi All,
>
>
>
> We tried to connect the OVS2.8.2 with the ODL controller. Though the TCP
> connection is established b/w the OVS and the controller, the connected
> node was not present in the DS.
>
>
>
> The issue seem to be due to incomplete handshake b/w the switch and the
> controller. This issue in handshake is due to the following :
>
>
>
> By default the Openflow version in OVS2.8.2 switches are OF1.4.
>
>
>
> Since OF1.4 not supported by the controller, version negotiation process
> takes place to agree on a OF version wherein
>
>
>
> a)   If the HELLO msg sent by the switch has version bitmap(field
> containing info about support for all the OF versions), the negotiation is
> done in a single step with the highest version supported by both switch &
> controller as the agreed version.
>
> b)  In case of absence of the version bitmap, the negotiation happens
> in steps in which the controller sends its version bitmap to the switch and
> expects the switch to send the HELLO msg with a version supported by the
> controller.
>
>
>
> However, if all versions until a version say X is supported, the OVS
> switch doesn’t send the version bitmap as it implies that all versions till
> X are supported (version bitmap unnecessary here ?).
>
> On receiving the HELLO msg from the controller (with the version bitmap)
> it assumes that the controller has already decided upon the version and
> doesn’t send further HELLO messages.
>
>
>
> *So, does the absence of the version bitmap always mean that all the
> versions till the version of the HELLO msg are supported by the switch(or
> controller).*
>
> *Could there be switches just without the version bitmap capability ? If
> there are such switches, how could we differentiate b/w them?*
>
>
>
> Note: Currently, we are using a workaround wherein we implicitly the
> Openflow version in the version(to OF13).
>
>
>
> Thanks and Regards,
>
> Gobinath
>
> ___
> openflowplugin-dev mailing list
> openflowplugin-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
>
>
___
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev