search

h2020-endeavour / endeavour

The ENDEAVOUR platform
Apache License 2.0
8 stars 3 forks source link

Make UMBRELLA impl. work with the iSDX config files and implement the UMBRELLA table #15

Closed mcanini closed 8 years ago

ederlf commented 8 years ago

Pushed the initial version of a standalone app that comunicates with the iSDX reference controller. For this, I created an iSDX configuration file with elements needed for umbrella. I showed it to Than (because it is related to issue #12). In case of any necessary change, it should not be hard to change the code used for parsing .

mcanini commented 8 years ago

@marchiesa please review whether this format is okay

marchiesa commented 8 years ago

Great work! It seems to me the only difference is that in the config file there should be just one entry for each participant and not one entry per participant's port. I can fix that, unless there is a specific reason for having it.

mcanini commented 8 years ago

@ederlf see @marchiesa question

ederlf commented 8 years ago

He is right. I did not noticed they were the same.
However, on the topology, they are two different routers. Not sure if it is possible at the IXP. We better ask @TribuneX.

thanh-nguyen-dang commented 8 years ago

@ederlf : in config file, you have something: "Peers": ["a1", "b2"] for entry c1 and c2 of participants list. But there is no "b2" entry

mcanini commented 8 years ago

@TribuneX your inputs kindly requested

TribuneX commented 8 years ago

Let me recap: The question is if we can have a participant with two ports, where each port is connected to a different edge switch. Then the answer is yes! However, I am not sure yet how this influences the config file scheme regarding ports and participants.

ederlf commented 8 years ago

Thanks @TribuneX! Do you know if they can also have different policies for different ports? Does it make sense?

On Wed, 27 Apr 2016, 08:51 TribuneX, notifications@github.com wrote:

Let me recap: The question is if we can have a participant with two ports, where each port is connected to a different edge switch. Then the answer is yes! However, I am not sure yet how this influences the config file scheme regarding ports and participants.

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/h2020-endeavour/endeavour/issues/15#issuecomment-214998068

TribuneX commented 8 years ago

I would say we should support that to allow participants to configure their ports as they were from different participants. A policy could be something like please only send me this kind of traffic (HTTP) to only this port correct? @ederlf @marchiesa

ederlf commented 8 years ago

I like this idea too. To handle ports in different colocations as an individual participant. The only thing I do not know is how much it would impact iSDX. For example, how much is the participant AS number related to the policy handling in the fabric? Would be a problem if they are binded.

On Wed, Apr 27, 2016 at 9:05 AM TribuneX notifications@github.com wrote:

I would say we should support that to allow participants to configure their ports as they were from different participants. A policy could be something like please only send me this kind of traffic (HTTP) to only this port correct? @ederlf https://github.com/ederlf @marchiesa https://github.com/marchiesa

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/h2020-endeavour/endeavour/issues/15#issuecomment-215003315

marchiesa commented 8 years ago

@ederlf @TribuneX iSDX can handle policies at the per-IXP-member-port granularity so this is perfectly fine but we need to keep the same structure of the "sdx_global.cfg" config file that is currently used in the iSDX. Namely, each "participant" item contains a list of its ports. The policies of all the participant's ports are defined in its "participant_x.py" file.

marchiesa commented 8 years ago

@ederlf @TribuneX After discussing with the iSDX developers, I understood that each participant can indeed specify its inbound policies at the per-port level of granularity. However, outbound policies are shared among all the ports of a single participant. That is, we cannot have different outbound policies for different ports of a single participant. I would suggest to stick with the structure of the current "sdx_global.cfg" configuration file and leave the job of improving outbound policies to the iSDX developers. By the way, @TribuneX , can you imagine any practical use case in which a participant would like to have different outbound policies for each of its ports?

mcanini commented 8 years ago

@marchiesa Sounds good to me.

@ederlf Can we close this issue? Has anyone performed testing of this new code?

ederlf commented 8 years ago

It can be closed. The code, so far, sends flows to the refmon module of iSDX., but refmon cannot does not accept topologies different than the ones already define. Just start to work on this, so it can accept a multi-hop topology. I will open a new issue for the task i'm currently working.

On Thu, Apr 28, 2016 at 2:59 PM Marco Canini notifications@github.com wrote:

@marchiesa https://github.com/marchiesa Sounds good to me.

@ederlf https://github.com/ederlf Can we close this issue? Has anyone performed testing of this new code?

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/h2020-endeavour/endeavour/issues/15#issuecomment-215432323

mcanini commented 8 years ago

@ederlf perfect!