Effectiveness of Segment Routing Technology in Reducing the Bandwidth and Cloud Resources Provisioning Times in Network Function Virtualization Architectures^†

Round 1

Reviewer 1 Report

The authors present a NFV orchestration architecture including an algorithm for Service function chaining and a discussion on Segment Routing adoption in SFC.

The title provides an expectation that the content does not match. It is not clear how segment routing is related to the NFV orchestration architecture. Is it just an implementation option? Is it solving a specific problem posed by the architecture?

It seems that section 4 could be removed without changing the core contribution of the work? Is it correct? In any case, the contribution of the paper should be more clearly defined.

Regarding segment routing it is not clear how routing through two consecutive VFs within a PoP is addressed. Is SR used only for interDC (ok)? how forwarding instructions internal to a PoP are managed and provided to VIM (or, in any case, the forwarding control function within a PoP)?

Section 5. cloud and bandwidth resource allocation problem seems the main contribution of the paper. If this is the case, it should be radically rewritten and the content extended to improve the technical soundness of contribution as follows:

- clarify the problem statement

- clarify the model and its relation to the simplified representation of network mentioned in the previous section

- describe the algorithm in detail and rigorously (e.g. mathematical notations). Are you minimizing the sum of cloud + bandwith cost over the whole set of requests or request by request? how do you discriminate when a VNF instance can be reused or not? How do you choose one of the paths? which level of information disclosure is provided between the NSO and RO to perform this choice?

Section 6.Simulation results

Comparative evaluation with a state of the art algorithm is done considering only the execution time metric. The findings are obvious, since as the authors state, the proposed algorithm has lower computational complexity than the one taken from the literature. What about costs? What about reuse of existing VNF instances? what about limitations with respect with algorithms that work using more knowledge on the network?

Author Response

Statement of Revision in response to comments by Reviewer #1

Reviewer’s comment (1)

The authors present a NFV orchestration architecture including an algorithm for Service function chaining and a discussion on Segment Routing adoption in SFC.

The title provides an expectation that the content does not match. It is not clear how segment routing is related to the NFV orchestration architecture. Is it just an implementation option? Is it solving a specific problem posed by the architecture?

It seems that section 4 could be removed without changing the core contribution of the work? Is it correct? In any case, the contribution of the paper should be more clearly defined.

Explanation and Revision

In the new version of the paper, we provide a new network scenario: Segment Routing is the data plane technology for both the core network and NFVI-PoP domains. In this way, we highlight that Segment Routing allows solving a specific problem posed by the architecture: the possibility of hiding the NFVI-PoP routing maintaining global identifiers for the SFs running in the different NFVI-PoPs.

More in detail, as explained in the revised Section 4, we exploit the Binding-SID (BSID) feature of Segment Routing: a BSID is an SR identifier that can be associated to a configurable Segment List. A BSID is used to identify, in the backbone network, a specific SR running in a NFVI-PoP domain. When the edge router of the NFVI-PoP domain receives a packet directed to the BSID, it performs a Segment List insertion: a new SL (associated with the BSID in the SR forwarding table) is used to reach the SR instance (instances).

To conclude, the use of SR greatly simplifies the management of the proposed NFV orchestration solution: it represents a fully compatible data plane not requiring the use of different technologies, such as Network Service Header (NSH) or Software Defined Network (SDN). It is still possible to implement the architecture with different data planes solution, such as SDN (as we did in our previous work) or NSH, but it requires to manage the interoperation among different technologies and also insert complexity overhead (NSH adopts a per-flow approach, while SR has a per-node complexity).

Reviewer’s comment (2)

Regarding segment routing it is not clear how routing through two consecutive VFs within a PoP is addressed. Is SR used only for interDC (ok)? how forwarding instructions internal to a PoP are managed and provided to VIM (or, in any case, the forwarding control function within a PoP)?

Explanation and Revision

If two consecutive VFs are present in the same PoP, two different approaches can be followed. The first one is based on the use of two different BSIDs, one for each VF. In this case, the path inside the PoP is composed of two sub-paths: i) the first one from the edge node to the first VF instance and back to the edge router; ii) the second one from the edge node to the second VF instance and back to the edge router. The second approach is based on the use of a single BSID for the ordered list of VFs; in this case, the path inside the PoP can be optimized but more BSIDs are needed, i.e. one for each combination of VFs inside the same PoP. We believe that both options can be followed, the choice depends on the PoP management strategy.

We have made clear this aspect by adding text in the Section 4 of the manuscript.

Reviewer’s comment (3)

Section 5. cloud and bandwidth resource allocation problem seems the main contribution of the paper. If this is the case, it should be radically rewritten and the content extended to improve the technical soundness of contribution as follows:

- clarify the problem statement

- clarify the model and its relation to the simplified representation of network mentioned in the previous section

- describe the algorithm in detail and rigorously (e.g. mathematical notations). Are you minimizing the sum of cloud + bandwith cost over the whole set of requests or request by request? how do you discriminate when a VNF instance can be reused or not? How do you choose one of the paths? which level of information disclosure is provided between the NSO and RO to perform this choice?

Explanation and Revision

The section 5 has been revised. At the beginning of the Subsection 5.2 we have better clarified the operation mode of the SRCBA algorithm as well as its objective.

An example has been introduced to make clearer the description of the SFC Routing and Cloud and Bandwidth resource Allocation (SRCBA) algorithm in the Traditional and Scalable Orchestration solutions. Four Figures have been introduced (Figs 4-7) in which we clearly illustrate the operation mode of the algorithm. We highlight how the algorithm takes into account both the cloud and bandwidth costs and when it re-uses VNFI already instantiated.

Reviewer’s comment (4)

Section 6. Simulation results

Comparative evaluation with a state of the art algorithm is done considering only the execution time metric. The findings are obvious, since as the authors state, the proposed algorithm has lower computational complexity than the one taken from the literature. What about costs? What about reuse of existing VNF instances? what about limitations with respect with algorithms that work using more knowledge on the network?

Explanation and Revision

A new Figure (Fig. 14) has been introduced in which the TO and SO solutions have been compared from the point of view of the total cost. This cost is given by the sum of the cloud and bandwidth resource costs. From Fig. 14 we verify how the less knowledge on the NFVI-PoP infrastructure of SO does not lead to a penalty in terms of total cost. We have the same costs for the two solutions. Finally notice how the aggregate knowledge of the resources of SO may lead to higher loss of SFC requests when the NFVI-PoP bandwidth and cloud resources are limited. This analysis is out of the scope of this work and we believe that the problem is of little interest since the NFVI-PoP resources are over-dimensioned with respect to the network ones.

Author Response File: Author Response.pdf

Reviewer 2 Report

- Around 200 grammar, spelling and punctuation mistakes (I would guess)

- Structure, problem desc, method and results looks good. However, I did not have the time to fully understand or verify the method.

Author Response

Statement of Revision in response to comments by Reviewer #2

Reviewer’s comment (1)

Around 200 grammar, spelling and punctuation mistakes (I would guess)

- Structure, problem desc, method and results looks good. However, I did not have the time to fully understand or verify the method.

Explanation and Revision

English and writing style has been improved in the new version of the manuscript.

Reviewer 3 Report

The authors build on their preceding work (reference [25]) to investigate the effectiveness of Segment Routing  to support SVF routing in cloud infrastructure.  I agree with them that SR is a promising technology to support emerging  traffic management via NVFs. What I do not understand is why there would be any need to still rely on SDN/OpenFlow while current equipment supports SR -based (SRv6 or SR-MPLS) traffic handling directly. This is in my opinion is a major flaw of this article which I would like to see addressed and explained. The insertion of segments of the ingress of the network would obviously still require a proper calculation of the path desired to optimally exploit the NVFs, but the use of OpenFlow and a controller seems to me unnecessary if one embraces truly SR.

I have a number of other questions, which I wish to see implemented in a revised version of the paper suitable for publication:

- the number of self references is very high and indicative of a lack of knowledge beyond own work; for example, it is quite surprising that Olivier Bonaventure is mentioned at all. I suggest a thorough search on both NVFs and Segment Routing to expand on the current Related work;

- I wonder why both evaluated topologies are made up of four cloud infrastructures, hence four NVFI-POPs. Why haven't you tried different types of topologies? What would be the results in those cases? The 90% improvement in computation times you quote in the abstract is therefore a very specific result of no use for generalization.

-  the article misses completely the Future work section, which is actually promised in the Introduction. There is therefore no reflection on the limitation of this work, and its potential shortcoming (see also my comment on the 90% improvement).

Author Response

Statement of Revision in response to comments by Reviewer #3

Reviewer’s comment (1)

The authors build on their preceding work (reference [25]) to investigate the effectiveness of Segment Routing  to support SVF routing in cloud infrastructure.  I agree with them that SR is a promising technology to support emerging  traffic management via NVFs. What I do not understand is why there would be any need to still rely on SDN/OpenFlow while current equipment supports SR -based (SRv6 or SR-MPLS) traffic handling directly. This is in my opinion is a major flaw of this article which I would like to see addressed and explained. The insertion of segments of the ingress of the network would obviously still require a proper calculation of the path desired to optimally exploit the NVFs, but the use of OpenFlow and a controller seems to me unnecessary if one embraces truly SR.

Explanation and Revision

We fully agree with the reviewer: for this reason we modified the architecture proposed in Section 4, extending the SR to NFVI-PoPs domains. In this way the use of SDN is not more needed. Moreover, we also introduced the BSID concept to make the data plane fully compatible with the proposed architecture.

Reviewer’s comment (2)

I have a number of other questions, which I wish to see implemented in a revised version of the paper suitable for publication:

- the number of self references is very high and indicative of a lack of knowledge beyond own work; for example, it is quite surprising that Olivier Bonaventure is mentioned at all. I suggest a thorough search on both NVFs and Segment Routing to expand on the current Related work;

Explanation and Revision

We fully agree with the reviewer consideration. We extended the Related work section with more references to Segment Routing. We have also deleted three self-references [2,26,27] of the old version  of the manuscript.

Reviewer’s comment (3)

I wonder why both evaluated topologies are made up of four cloud infrastructures, hence four NVFI-POPs. Why haven't you tried different types of topologies? What would be the results in those cases? The 90% improvement in computation times you quote in the abstract is therefore a very specific result of no use for generalization.

Explanation and Revision

To make the results more general, we have change the network scenario in the case of NSFNET network. In particular we have varied the number of NFVI-PoPs beyond 4. We have introduced the new Fig. 9 in which four NSFNET network scenario are considered with 4, 7, 10 and 14 NFVI-PoPs. The NFVI-PoPs are located as illustrated in Figs 9.a, 9.b, 9.c and 9.d respectively. The SRCBA execution time is reported in Fig. 13 for these scenarios. The advantage of the SO solution is confirmed in all of the cases.

Finally we have also introduced Fig. 14 to compare TO and SO solution from the point of view of total cost given by the sum of the cloud and bandwidth resource costs. We can observe from Fig. 14 how the limited knowledge of the network in the SO case does not lead to a penalty in terms of total cost with respect to the TO solution.

Reviewer’s comment (4)

the article misses completely the Future work section, which is actually promised in the Introduction. There is therefore no reflection on the limitation of this work, and its potential shortcoming (see also my comment on the 90% improvement).

Explanation and Revision

In the conclusion we highlight the future steps of our research work: we will compare the SR-based architecture with a different one, based on NSH protocol; moreover, our aim is to realize an experimental testbed based on Cisco's Vector Packet Processing (VPP) open source technology.

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

The work has improved a lot.

Please consider enhancing the discussion about related work with recent works using multi-layer and/or abstract topology:

- Pei, P. Hong, K. Xue and D. Li, "Efficiently Embedding Service Function Chains with Dynamic Virtual Network Function Placement in Geo-distributed Cloud System"

- "VNF placement for service chaining in a distributed cloud environment with multiple stakeholders", P Cappanera, F Paganelli, F Paradiso

Author Response

The multi-layer graph approach proposed in solving the SFC routing and resource allocation problems in NFV environments has been mentioned and the two suggested references have been inserted.

Reviewer 3 Report

Dear authors

I appreciated your work to incorporate my suggestions and I am now better convinced that this work presents a reasonable motivation for use of SR. I think the community will benefit from this read.

Author Response

Thanks for appreciating the work.