Subject: Re: [sfc] ODL Hierarchical SFC implementation demo

From: Dave Dolson <[email-masked]>
Date: Sun, 7 Feb 2016 16:11:02 +0000

Hi Victor,
Thanks for sharing your design.
I have some comments from my perspective.

1. Your slides don't clearly show the controllers. One of the main goals of hSFC is to have independent control of the top-level domain and lower-level domains. So I think it is important to show a controller for each domain.
Note that in the top-level domain, the controller will view the sub-domain as merely an SF. In the lower-level domain, the controller deals with only what is in the sub-domain, from controller on down. The IBN is the glue between them and may be configured independently of either, in my opinion.
I think it is important to consider the controllers may be from different projects as well (e.g., not all ODL).
In fact, you should consider doing this work outside of the ODL project. It seems to be more general.

2. The use of MD-1 for the SFF IP address is troubling because (a) it doesn't work for IPv6 addresses and (b) assumes an IP encapsulation of NSH (vs. Ethernet/NSH and others). It isn't clear to me that this information needs to be saved in the packet anyhow, because the SFF is always the same. E.g., SFF2 can just be configured as the SFF for the IBN.

3. Looking at slide 10, keeping in mind the bidirectional nature of traffic, it may be useful to show classifiers on both sides of the sub-domain, or make it more clear that the red path is only for client-to-server traffic and a different path is required for server-to-client traffic.

I look forward to following your work.
Thanks,
-Dave

________________________________________
From: VictorVu [[email-masked]]
Sent: Saturday, February 06, 2016 1:47 AM
To: opendaylight sfc
Cc: Dave Dolson
Subject: ODL Hierarchical SFC implementation demo

Hi,
I m trying to implement the Hierarchical SFC concept into ODL SFC. This
is our demo
https://docs.google.com/presentation/d/1k8_LSEu9YRM4EwKtL3GCwxLLtKVQHgZ-4c7-SYWX6q4/edit?usp=sharing

I would like to ask anyone interested to help us reviewing our design.
Please give me your comment so that we can discuss further.

Best regards,

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: Dave Dolson <[email-masked]>
Date: Sun, 7 Feb 2016 17:02:00 +0000

Keith,
The hierarchical approach becomes relevant for large numbers of nodes and when independent management of domains is desired. I admit it is difficult to see the benefit in a small-scale proof of concept.

-Dave

From: Keith Burns
Sent: Sunday, February 7, 2016 11:26 AM
To: Dave Dolson
Cc: [email-masked]; opendaylight sfc; VictorVu; Colin Dixon
Subject: Re: [sfc-dev] ODL Hierarchical SFC implementation demo

I'm also curious how the same thing couldn't be handled with 3 chains and a classifier. Might be an interesting TWS talk even if it's scope is beyond ODL.

On Feb 7, 2016 5:11 PM, "Dave Dolson" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Victor,
Thanks for sharing your design.
I have some comments from my perspective.

________________________________________
From: VictorVu [[email-masked]<mailto:[email-masked]>]
Sent: Saturday, February 06, 2016 1:47 AM
To: opendaylight sfc
Cc: Dave Dolson
Subject: ODL Hierarchical SFC implementation demo

Hi,

Best regards,

---

_______________________________________________
sfc-dev mailing list
[email-masked]<mailto:[email-masked]>
https://lists.opendaylight.org/mailman/listinfo/sfc-dev

---

From: Victor Vu <[email-masked]>
Date: Mon, 08 Feb 2016 07:59:21 +0000

Hi,
Thanks for your comments.

1. Of course each domain is managed by one controller, I am sorry not
clarify that in the figure.
About IBN, I think they should be configured by the lower-level domain
controller because: (a) Independently configuring IBN would increase the
management complexity. The entity responsible for this task should know
well about all SFC domains. which is not good for security. (b) higher
level domain should not do this task because like you said, it views the
sub-domain as merely an SF.
I am not sure but I believe your idea is making an independent entity to
enable hSFC (creating connection node between domains, configuring IBN
...). But in my opinion, SFC controllers should do thisand ODL is a good
starting point since it already support SFC.

2. You are right using MD-1 for IP address will cause problem with IPv6,
but we can solve this problem in the future with NSH metadata type 2
I also understand that SFF could be shared by higher and lower domain, but
I am considering about multi-domain NFV environment, where each NFV MANO
manage their own SFC components and don't need/don't want to share them

3. Sub-domain controller will decide whether there is bi-directional path
or not in it's configuration. I mean it's up to sub-domain manager to
flexibly make the decision. I will add the reversed path for clarification.

On Sun, Feb 7, 2016 at 11:26 PM Keith Burns <[email-masked]> wrote:

> I'm also curious how the same thing couldn't be handled with 3 chains and
> a classifier. Might be an interesting TWS talk even if it's scope is beyond
> ODL.
>

In my topology, this thing could definitely be done with 3 chains and a
classifier. Like Dave said, this concept only benefit in large-scale DC.
Actually, I want to apply this concept in multi-domain NFV, so my design
might make more sense in this context.

Again, I appreciate all your comments, they help me a lot to complete the
design.
Currently my demo runs with the simplest scenario: no IPv6, sub-domain only
receives hSFC traffic, last SF decrease SI, ...
There are some discussion points in my final slide. After solving those
point I will refactor and open the demo code.

On Sun, Feb 7, 2016 at 11:10 PM Dave Dolson <[email-masked]> wrote:

> 1. Your slides don't clearly show the controllers. One of the main goals
> of hSFC is to have independent control of the top-level domain and
> lower-level domains. So I think it is important to show a controller for
> each domain.
> Note that in the top-level domain, the controller will view the sub-domain
> as merely an SF. In the lower-level domain, the controller deals with only
> what is in the sub-domain, from controller on down. The IBN is the glue
> between them and may be configured independently of either, in my opinion.
> 2. The use of MD-1 for the SFF IP address is troubling because (a) it
> doesn't work for IPv6 addresses and (b) assumes an IP encapsulation of NSH
> (vs. Ethernet/NSH and others). It isn't clear to me that this information
> needs to be saved in the packet anyhow, because the SFF is always the same.
> E.g., SFF2 can just be configured as the SFF for the IBN.
>
> 3. Looking at slide 10, keeping in mind the bidirectional nature of
> traffic, it may be useful to show classifiers on both sides of the
> sub-domain, or make it more clear that the red path is only for
> client-to-server traffic and a different path is required for
> server-to-client traffic.
>

---

From: Keith Burns <[email-masked]>
Date: Sun, 7 Feb 2016 17:26:19 +0100

I'm also curious how the same thing couldn't be handled with 3 chains and a
classifier. Might be an interesting TWS talk even if it's scope is beyond
ODL.
On Feb 7, 2016 5:11 PM, "Dave Dolson" <[email-masked]> wrote:

> [email-masked]