Thank you so much for your comments to improve the quality of this research work. It is noteworthy that most recommendations will be incorporated in the final version of our submitted paper (in case it is accepted)

### Abstraction Mechanism

>**R3:** *The proposed "abstracted network inventory" does not really abstract but rather filters the existing infrastructure wrt the necessary conditions. This gives the impression that all kinds of complex mechanisms abstract the infrastructure, while it is actually a very simple filtering mechanism*
- A subset is a standard abstraction mechanism [1] to filter vertices and edges. The proposal in our work provides a novel approach that uses service requirements as an input to generate an abstract representation (LNI)

>**R3:** *The related work could (should?) refer to a paper which did actually propose abstraction mechanisms for the infrastructure and explain pro/con wrt to this work: [2]*
- Aggregation (as [2] uses), subset (as ANI/LNI uses), transformation, grouping, among others, are all considered standard abstraction mechanisms [1]. However, our paper definitively will include [2] as related work, and pro/con in both approaches will be explained

*[1] Angles et al. "Survey of graph database models." CSUR 2008
[2] A model to select the right infrastructure abstraction for service function chaining*

### Related Work
>**R2:** *It would be beneficial to give more examples, and describe other approaches that use abstraction principles to improve scalability/manageability, so that readers can better understand the impact of the proposed work contributions*
- We will include one/two paragraphs for each related work (and a couple more also will be added) to describe the benefits of using an abstract representation.
- In order to readers can better understand such benefits, we will move the Related Work section after the Introduction.

### Network Model
>**R2:** *The network model is shown for a basic scenario with only one CPU and bandwidth constraints. More details are needed to understand how this assumption is justified and what is needed to extend the model for more capabilities and resources*
- We will include more details and references to justify: (i) why only one constraint per node/link, and (ii) what is needed to extend the model. In the case of the first one, our network model is easy and totally extensible to consider other constraints. We only consider one property per node/link to simplify the model for presentation purposes.
- **Any other suggestions here? (Christian -> just added a few words above, Pedro, Mateus)**

>**R2:** *Related works discussion is satisfactory but the state-of-the-art is not well detailed to clearly understand the timeliness and significance of the work*
- We will include some paragraphs (or a sub-section) to discuss in detail the benefits of an ANI, e.g., privacy (not expose the exact network inventory structure), incremental updates (because not all infrastructure changes will affect an ANI), optimal placement/management (because an ANI is a reduced representation of a network inventory).
- Most of the current related work is focused on finding an optimal mapping. The problem of creating optimal network inventory abstractions is still unexplored, and none of the existing work considers service requirements as an input.

### Experimental Evaluation

>**R3:** *In the evaluation time saving rates are calculated, but it is not mentioned how timing is considered, i.e. it is not clear if the time needed for generating the abstractions (filterings) is also accounted here*
- The evaluation only considers the time needed for placing the service. Camera-ready version will include an analysis of the total time of (1) generating the LNI and (2) placing the service in the LNI, and compare that to placing the service directly in the full topology

>**R3:** *The paper would benefit from a more extensive evaluation on more complex services and more complex infrastructures, in which the assessed KPIs are clearly explained (time saving of what aspects) and fair*
- There is ongoing work using real/complex topologies (e.g., ITDK-CAIDA). If we get the results in time for the camera ready (if accepted), we will certainly include them.
- **Any other suggestions here? (Christian, Pedro, Mateus)**

>**R3:** *The evaluation only considered very simplistic services consisting of 2 NFs, therefore it is hard to make very strong statements on the resulting efficiency as adequate filtering of the topology becomes much harder if you more complex services involving multiple VNFs and multiple interconnections*
- Fig. 6b already shows the effect (average degree) of different amounts of NFs (from 2 to 6) on the LNI generation. However, we could consider more complex services and extend it for the service provisioning time experiment.

>**R1:** *the presented work has been implemented and experiments has been conducted to evaluate the ANI procedures. Even though the qualitative evaluation of the LNI creation is presented and discussed, it would have been nice to evaluate ANI and LNI with respect to exiting models to show the brought value. This comment is important as the related work analysis is detailed in the paper and many different works has tried to deal with network inventories and abstractions.*
- In the 2nd experiment, ESCAPE orchestrator uses the UNIFY abstraction model. We will include more information to make clear that LNI is evaluated/compared with existing abstraction models (i.e., UNIFY).

>**R2:** *The current details presented in related work and experimental evaluations show that this work is incremental in terms of its contributions compared to the state-of-the-art*
- We will move the Related Work discussion after the introduction and clarify wrt the advances compared to the state-of-the-art, which can be seen as incremental but noteworthy regarding their broad and benefitial applicability in real, high scale SDN/NFV systems. If the timely publication permits, we will include a reference to the novelties of the work as per patent application PCT/EP2019/058274, filed on April, entitled "TECHNIQUE FOR SIMPLIFYING MANAGEMENT OF A SERVICE IN A CLOUD COMPUTING ENVIRONMENT"
- **Any suggestions here? (Christian->done, Pedro, Mateus)**

### Dataset:
>**R1:** *The authors claim using a real graph dataset but do not explain further how this is used. Please detail the use of the real graph dataset in the experiments*
- We will include more information about how the Interoute topology dataset is pre-processed (formating, filtering), and how it is uploaded/used into the ESCAPE orchestrator. Also, code documentation and a comprehensive user guide will be uploaded into our Github repo.

### Clarifications/Typos:
>**R2:** *Also paper writing needs to be improved e.g., there are typos and some sentences need to be simplified*

The manuscript will be carefully reviewed. Typo corrections, along with re-writing of unclear paragraphs, will be incorporated.

~~R3:
The motivation that latency-intensive services have a huge number of potential placement options is a bit contradictory to the fact that only a very limited number of resources are close enough (low enough latency) to provide required QoS. Nevertheless the huge scale in general of available resources is valid motivation.~~
**To be answered?**