Re: [controller-dev] Container Mgr question


Madhu Venugopal
 


Hi Luis,

Yes. Having the VLAN for the flowspec is something basic that was missing. (Thanks for Alessandro for fixing that).

But having also the tag encap/decap is quite useful to support multi-tenancy use-case with overlapping vlan spaces
(and identifying them across the fabric using the external vlan - QinQ). The Tag need NOT be VLAN. It can be any other
tag that the south-bound plugin supports. QinQ is well known and supported in OF1.3 and hence we must make use of it.

My suggestion to this topic is that, OF1.0 plugin should reject a configuration that asks vlan encap.
While OF1.3 and other supporting south-bound should accept it.
Just my 2c.

-Madhu

On 10/30/13, 11:11 AM, Luis Gomez wrote:

Hi Alessandro,

 

I have another thought, given that flowspec is something invariable (does not change) across switches, could not we define a vlan-tag in the flowspec and then state that we do not support vlan encapsulation/decapsulation scenarios but instead transport a VLAN-tag flow from one port to another. Sorry to go back on this, I am just trying to gather the vlan-tag into the Container Mgr logic as this is very common way to separate traffic in real networks.

 

BR/Luis

 

 

 

From: Luis Gomez
Sent: Tuesday, October 29, 2013 5:48 PM
To: 'Alessandro Boch (aboch)'; Madhu Venguopal
Cc: 'integration-dev@...'; dev (controller-dev@...)
Subject: RE: [controller-dev] Container Mgr question

 

Thanks, I did not know about the bidirectional thing, now works after changing to:

 

Container1:

 

<flowSpecs>

    <name>h1toh3</name>

    <nwSrc>10.0.0.1</nwSrc>

    <nwDst>10.0.0.3</nwDst>

</flowSpecs>

 

Container 2:

 

<flowSpecs>

    <name>h2toh4</name>

    <nwSrc>10.0.0.2</nwSrc>

    <nwDst>10.0.0.4</nwDst>

</flowSpecs>

 

Now I also understand what you said the other day: “FRM is not auto-adding the match on the static vlan on the configured flow entries (it cannot, otherwise it would break the logic in the first hop switch, the one matching on the host traffic ingressing the of network)”. The VLAN tags can be added/removed through the data path across the different switches so maybe it is not good idea to include them in the flowspecs. They could be included or be part of the nodeconnectors, like: container1 has nodeconnector “SW2-port1-vlan10” and container2 has nodeconnector “SW2-port1-vlan20” but I do not think this definition of node connector is easy to implement on an OF switch.

 

So as a conclusion, for the bug I just opened you can just try to remove the static vlan definition (so it does not create confusion) and enforce flowspecs whenever you need to share ports.

 

BR/Luis

 

 

 

 

From: Alessandro Boch (aboch) [mailto:aboch@...]
Sent: Tuesday, October 29, 2013 3:17 PM
To: Luis Gomez; Madhu Venguopal
Cc: 'integration-dev@...'; dev (controller-dev@...)
Subject: RE: [controller-dev] Container Mgr question

 

Hi Luis,

Each flow spec configuration is by default bidirectional, backend internally generates a couple of flow specs.
The flow specs are internally represented as a Match object, which represents a set of network packets.

So, in your case:

The first slice FS says all the packets with SRC and _DST IP_ 10.0.0.1 and with with SRC and _DST IP_  10.0.0.3.

While the second slice FS says all the ones with SRC and _DST IP_ 10.0.0.2 and with with SRC and _DST IP_  10.0.0.4.

 

So there are non-empty intersections between the FSs of the two slices:

[10.0.0.1, 10.0.0.2], [10.0.0.2,10.0.0.1], [10.0.0.1,10.0.0.3], [10.0.0.3,10.0.01], ….

 

Which is why Container Manager does not allow a port to be assigned to both slices.

 

Thanks,
Alessandro

 

 

From: Luis Gomez [mailto:luis.gomez@...]
Sent: Tuesday, October 29, 2013 2:32 PM
To: Alessandro Boch (aboch); Madhu Venguopal
Cc: 'integration-dev@...'; dev (controller-dev@...)
Subject: RE: [controller-dev] Container Mgr question

 

Hi Madhu and Alessandro,

 

I have opened bug #127 for the container Mgr improvement. Now I have another question when I played with the flowspecs:

 

I configured the following flowspecs for container 1:

 

<flowSpecs>

    <name>toh1</name>

    <nwDst>10.0.0.1</nwDst>

</flowSpecs>

<flowSpecs>

    <name>toh3</name>

    <nwDst>10.0.0.3</nwDst>

</flowSpecs>

</container-config>

 

And the following for container 2:

 

<flowSpecs>

    <name>toh2</name>

    <nwDst>10.0.0.2</nwDst>

</flowSpecs>

<flowSpecs>

    <name>toh4</name>

    <nwDst>10.0.0.4</nwDst>

</flowSpecs>

</container-config>

 

For me it is like they are all different flowspecs however when I try to share a port I get: “Port OF|3@OF|00:00:00:00:00:00:00:02 is shared and other container has common flow spec”

 

Is this expected behavior? if so what makes a flowspec different from another flowspec?

 

Thanks/Luis

 

 

From: Alessandro Boch (aboch) [mailto:aboch@...]
Sent: Monday, October 28, 2013 9:57 AM
To: Madhu Venguopal; Luis Gomez; dev (controller-dev@...)
Cc: 'integration-dev@...'
Subject: RE: [controller-dev] Container Mgr question

 

Inline @ A#

 

Thanks,
Alessandro

 

From: Madhu Venguopal [mailto:mavenugo@...]
Sent: Monday, October 28, 2013 6:18 AM
To: Luis Gomez; dev (controller-dev@...); Alessandro Boch (aboch)
Cc: 'integration-dev@...'
Subject: Re: [controller-dev] Container Mgr question

 

Hi Luis,

Comments inline.

On 10/28/13, 2:00 AM, Luis Gomez wrote:

Hi controller experts,

 

I am configuring containers in OpenDaylight controller, and observed the following:

 

1) Containers using different ports is no problem (no flowspec needed)

2) If containers share one or more host ports, I need flowspecs (different on both containers) to separate traffic

3) If containers share only network ports, it is enough if they have different staticVlan

M# Yes. Your observations are inline with the design intent.

 

Then my questions:

 

- In scenario 2) if a host uses VLAN tags for different traffics or a regular switch trunk port is connected to host port, how can I put each VLAN on a different container? the existing implementation does not seem to deal with this situation.

M# Yes. this is a missing item on the Flow-Spec. We need to add the Vlan based isolation. Please open a Bugzilla item.

 

- In scenario 3) how is the “staticVlan” setting used to separate traffic in the network ports? I have created flows in the containers but I do not see any vlan being automatically applied or enforced on the network ports.

M# This is supposed to work as you expect. But, I think this was disabled some time ago due to a few observed issues.
      Will let the other controller-devs to get the reason. Also, I have a basic concern with this feature. Since OF1.0 doesnt support QinQ, this staticVlan
      addition will overwrite any vlan that is already present in the packet. So, not having this feature right now, is not a problem :-)
      But certainly the above vlan presence in flow-spec is missing.
A# Right,  in order to make use of the Static Vlan, the application needs to have the topology view. The application needs to push/pop the container static vlan on traffic ingressing/egressing the openflow network. The application needs to know if a port is a host-facing port. FRM cannot blindly set/unset this vlan because it works on per-flow basis, it has no topology information.

In a scenario where containers do not share host-facing ports (but they can share inter-switch links), using the static vlan assures traffic isolation without the need of configuring container flows ( flow specs).

 

But given the switch interconnections and host attachments are dynamic in nature, given this works only if hosts send untagged frames, and given FRM is not auto-adding the match on the static vlan on the configured flow entries (it cannot, otherwise it would break the logic in the first hop switch, the one matching on the host traffic ingressing the of network), I would not put much effort in testing this.

 

Thanks/Luis

 

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

 


Join integration-dev@lists.opendaylight.org to automatically receive all group messages.