Original: Learning to Conﬁgure Computer Networks with Neural Algorithmic Reasoning
Revised: Learning to Conﬁgure Computer Networks with Neural Algorithmic Reasoning

Original: Anonymous Author(s)
Revised: Anonymous Author(s)

Original: AfﬁliationAddress email
Revised: AfﬁliationAddress email

Original: Abstract
Revised: Abstract

Original: We present a  new method for scaling automatic conﬁguration of computernetworks.
Revised: We present a radically new method for scaling automatic conﬁguration of computernetworks.

Original: The key idea is to relax the computationally hard search problem ofﬁnding a conﬁguration that satisﬁes a given speciﬁcation into an approximateobjective amenable to learning-based techniques.
Revised: The key idea is to relax the computationally hard search problem ofﬁnding a conﬁguration that satisﬁes a given speciﬁcation into an approximateobjective amenable to learning-based techniques.

Original: Based on this idea, we traina neural algorithmic model which learns to generate conﬁgurations likely to(fully or partially) satisfy a given speciﬁcation under existing routing protocols.
Revised: Based on this idea, we traina neural algorithmic model which learns to generate conﬁgurations likely to(fully or partially) satisfy a given speciﬁcation under existing routing protocols.

Original: By relaxing the rigid satisfaction guarantees, our approach (i) enables greaterﬂexibility: it is protocol-agnostic, enables cross-protocol reasoning, and does notdepend on hardcoded rules; and (ii) ﬁnds conﬁgurations for much larger computernetworks than previously possible.
Revised: By relaxing the rigid satisfaction guarantees, our approach (i) enables greaterﬂexibility: it is protocol-agnostic, enables cross-protocol reasoning, and does notdepend on hardcoded rules; and (ii) ﬁnds conﬁgurations for much larger computernetworks than previously possible.

Original: Our learned synthesizer is up to 490 × fasterthan state-of-the-art SMT-based methods, while producing conﬁgurations whichon average satisfy more than 93% of the provided requirements.
Revised: Our learned synthesizer is up to 500 × fasterthan state-of-the-art SMT-based methods, while producing conﬁgurations whichon average satisfy more than 93% of the provided requirements.

Original:  Introduction
Revised:  Introduction

Original: Conﬁguring large-scale networks is a challenging and important task as network conﬁgurationmistakes regularly lead to massive internet-wide outages affecting millions (resp.
Revised: Conﬁguring large-scale networks is a challenging and important task as network conﬁgurationmistakes regularly lead to massive internet-wide outages affecting millions (resp.

Original: billions 1 ) of
Revised: billions 1 ) of

Original: Internet users [34, 24].
Revised: Internet users [32, 23].

Original: Typically, network operators provide a router-level conﬁguration W which,after applying protocols such as shortest-path routing, induces a certain forwarding behaviour F WDas illustrated in Figure 1. As this remains a challenging task, much recent research has focused onautomating conﬁguration by leveraging synthesis techniques [15, 5, 30]: A synthesizer is used toautomatically generate a router-level conﬁguration W that, after applying  routing protocols results inforwarding behavior that satisﬁes a given speciﬁcation S on how trafﬁc should be routed.
Revised: To address this problem, much recent research has focused on automatingnetwork conﬁguration by leveraging synthesis techniques [15, 5, 28]. The idea is illustrated in Figure 1 – here, a synthesizer is used to automatically generate a router-level conﬁguration that,after applying the respective routing protocols, leads to a forwarding plane that satisﬁes a givenspeciﬁcation on how trafﬁc should be routed.

Original: SMT-based Synthesis Due to the hardness of the conﬁguration synthesis problem [7], manyeffective tools in this domain [15, 14] resort to satisﬁability modulo theory (SMT) solvers, whichemploy search-based procedures to ﬁnd a solution to a set of ﬁrst-order logic constraints.
Revised: SMT-based Synthesis Due to the hardness of the conﬁguration synthesis problem [7], manyeffective tools in this domain [15, 14] resort to satisﬁability modulo theory (SMT) solvers, whichenable comprehensive and exact synthesis.

Original: This enablescomprehensive and exact synthesis by modelling network behavior in ﬁrst-order logic.

Original: However,these tools are typically protocol-speciﬁc, hand-coded, and can exhibit discrepancies in behaviorwhen compared to actual router hardware [6].
Revised: Unfortunately, these tools are typically protocol-speciﬁc,hand-coded and can exhibit discrepancies in behavior when compared to actual router hardware [6].

Original: Most importantly, however, they can be very slow orfail to complete for large networks.
Revised: Most importantly, however, they can be very slow or fail to complete for large networks.

Original: For example, the state-of-the-art SMT-based tool NetComplete[15] requires more than 6 hours to synthesize a conﬁguration for a network with 64 nodes, for whichother SMT-based tools like SyNET [14] take even longer ( > 24 hours) 
Revised: For example,the state-of-the-art SMT-based tool NetComplete [15] requires more than 6 hours to synthesizea conﬁguration for a network with 64 nodes, for which other SMT-based tools like SyNET [14]take even longer ( > 24 hours) [15].

Original: Non-SMT-based toolssuch as Propane [4] or Zeppelin [38] have achieved better performance, but at the cost of generality.
Revised: Non-SMT-based tools such as Propane [4] or Zeppelin [36]have achieved better performance, but at the cost of generality (Propane only synthesizes BGPconﬁgurations, while Zeppelin only supports speciﬁc, hierarchical BGP/OSPF).

Original: Addressing the scalability barrier The reason for the wide-spread use ofSMT in conﬁgurationsynthesis is the inherent computational complexity of the underlying synthesis problem, parts of
Revised: Breaking the scalability barrier Because of the inherent computational complexity of the underlying synthesis problem, any exact synthesis method is bound to run into scalability issues (as doall SMT-based methods). However, to be practically useful, a synthesizer must scale to the size of

Original: A
Revised: A

Original: B
Revised: B

Original: C
Revised: C

Original: D
Revised: D

Original: E
Revised: E

Original: F
Revised: F

Original: Forwarding Plane Protocol (Graph Algorithm, e.g. OSPF)
Revised: Forwarding Plane Protocol (Graph Algorithm, e.g. OSPF)

Original: Check Consistency Configuration
Revised: Check Consistency Configuration

Original: A
Revised: A

Original: B
Revised: B

Original: C
Revised: C

Original: D
Revised: D

Original: E
Revised: E

Original: F 3fwd(A,B,N1)not fwd(C,B,N1)
Revised: F 3fwd(A,B,N1)not fwd(C,B,N1)

Original: reachable(D,A,N1)isolation(A,B,N1,N2)
Revised: reachable(D,A,N1)isolation(A,B,N1,N2)

Original: Specification S
Revised: Specification S

Original: ConfigurationSynthesis

Original: [Figure]
Revised: [Figure]

Original: which have been shown to be NP-hard [7, 16, 43].

Original: This means that any exact synthesis method isbound to run into scalability issues (as do all SMT-based methods).

Original: However, to be practically useful,a synthesizer must scale to the size of real-world networks and the frequency at which conﬁgurationsare updated.
Revised: real-world networks and the frequency at which conﬁgurations are updated.

Original: For example, in a Tier-1{+Tier-
+} ISP, network operators modify their conﬁgurations up to 20times per day, on average [35].
Revised: For example, in a {+Tier-
+} ISP, network operators modify their conﬁgurations up to 20 times per day, on average [33].

Original: We argue that one way to address this scalability barrier, is relaxingthe conﬁguration synthesis problem to admit approximate solutions with high utility – conﬁgurationswhich may not always satisfy all requirements of a given speciﬁcation but may satisfy almost all ofthem.
Revised: We arguethat one way to break the scalability barrier, is relaxing the conﬁguration synthesis problem to admitapproximate solutions with high utility – conﬁguration which may not always satisfy all requirementsof a given speciﬁcation but may satisfy almost all of them.

Original: Such a conﬁguration would be a much better starting point for a network operator than havingno automated support whatsoever.
Revised: Such a conﬁguration would be a muchbetter starting point for a network operator than having no automated support whatsoever.

Original: The core technical challenge then is coming up with a strategylikely to ﬁnd solutions with high utility.
Revised: The coretechnical challenge then is coming up with a strategy likely to ﬁnd solutions with high utility.

Original: This Work: enabling fast and scalable conﬁguration via neural algorithmic reasoning Weaddress this challenge and present the ﬁrst learning-based framework for approximate conﬁgurationsynthesis.
Revised: We address this challenge and present the ﬁrst learning-based framework for approximate conﬁguration synthesis.

Original: Our relaxed formulation allows us, for the ﬁrst time, to apply end-to-end learning tothe problem of network conﬁguration synthesis, thereby enabling fast and scalable conﬁgurationsynthesis with almost interactive response times (<90s even for large networks).
Revised: Our relaxed formulation enables us, for the ﬁrst time, to apply end-to-end learning tothe problem of network conﬁguration synthesis, breaking the inherent scalability barrier.

Original: Technically, weleverage the observation that routing protocols can often be formulated as Bellman-Ford style graphalgorithms, a class of problems that has recently been studied in the area of neural algorithmicreasoning (NAR) [42].
Revised: Technically,we leverage the observation that routing protocols can often be formulated as Bellman-Ford stylegraph algorithms, a class of problems that has recently been studied in the area of neural algorithmicreasoning (NAR) [40].

Original: Connecting the two ﬁelds and building on ideas from NAR, we are ableto train a graph-based neural model with a strong inductive bias to learn an inverse mapping fromspeciﬁcations back to network conﬁgurations: Our model learns how to perform synthesis froma dataset of (speciﬁcation, conﬁguration) pairs obtained by simulating the involved protocols andobserving the computed forwarding state.
Revised: Connecting the two ﬁelds and building on ideas from NAR, we are ableto train a graph-based neural model with a strong inductive bias to learn an inverse mapping fromspeciﬁcations back to network conﬁgurations: Our model learns how to perform synthesis froma dataset of (speciﬁcation, conﬁguration) pairs obtained by simulating the involved protocols andobserving the computed forwarding state.

Original: With this method, we can support cross-protocol reasoningand do not have to manually provide any hardcoded synthesis rules.
Revised: With this method, we can support cross-protocol reasoningand do not have to manually provide any hardcoded synthesis rules.

Original: Concretely, we introduce ageneric embedding scheme for topologies and conﬁgurations, making our method protocol-agnostic.
Revised: Concretely, we introduce ageneric embedding scheme for topologies and conﬁgurations, making our method protocol-agnostic.

Original: During synthesis, given a speciﬁcation, our model predicts distributions of network conﬁgurationsfrom which we can sample possible results.
Revised: During synthesis, given a speciﬁcation, our model predicts distributions of network conﬁgurationsfrom which we can sample possible results.

Original: Main Contributions
Revised: Main Contributions

Original: Our core contributions are:
Revised: Our core contributions are:

Original: • We formulate a relaxation of the exact conﬁguration synthesis problem, which enables fast
Revised: • We formulate a relaxation of the exact conﬁguration synthesis problem, which enables fast

Original: and scalable network conﬁguration, amenable to learning-based techniques (Section 2).
Revised: and scalable network conﬁguration, amenable to learning-based techniques (Section 2).

Original: • We propose a NAR-based neural network architecture for learning synthesizer models thatrely on a graph-based encoding of topologies and conﬁgurations, and a strong inductive bias
Revised: • We propose a NAR-based neural network architecture for learning synthesizer models that rely on a graph-based encoding of topologies and conﬁgurations, and a strong inductive bias

Original: towards an iterative synthesis procedure (Section 4). • We conduct an extensive evaluation of our learning-based synthesizer with respect to both
Revised: towards an iterative synthesis procedure (Section 4).• We conduct an extensive evaluation of our learning-based synthesizer with respect to both

Original: precision and scalability.
Revised: precision and scalability.

Original: We demonstrate that our learned synthesizer is up to 490 × fasterthan a state-of-the-art SMT-based tool while producing high utility conﬁgurations which on
Revised: We demonstrate that our learned synthesizer is up to 500 × fasterthan a state-of-the-art SMT-based tool while producing high utility conﬁgurations which on

Original: average satisfy > 93% of provided constraints (Section 5).
Revised: average satisfy > 93% of provided constraints (Section 5).

Original:  Conﬁguration Synthesis: Exact and Learned
Revised:  Conﬁguration Synthesis: Exact and Learned

Original: We ﬁrst state the general conﬁguration synthesis problem and explain why it is hard to solve.
Revised: We ﬁrst state the general conﬁguration synthesis problem and explain why it is hard to solve.

Original: Wethen present a rather different approach based on learning that addresses the scalability barrier oftraditional synthesis.
Revised: Wethen present our radically different approach based on learning that breaks the scalability barrier.

Original: Forwarding Behavior and Speciﬁcations We focus on the level of the forwarding plane of a network.
Revised: Forwarding Behavior and Speciﬁcations We focus on the level of the forwarding plane of a network.

Original: This means we consider how a network forwards trafﬁc, given a packet with a certain destination.
Revised: This means we consider how a network forwards trafﬁc, given a packet with a certain destination.

Original: The forwarding plane is determined by a distributed computation that depends on the different routing protocols in use.
Revised: The forwarding plane is determined by a distributed computation that depends on the different routing protocols in use.

Original: More formally, we deﬁne the forwarding plane F WD as follows:
Revised: More formally, we deﬁne the forwarding plane F WD as follows:

Original: [Equation]
Revised: [Equation]

Original: Prot ( W ; T ) corresponds to the result of applying routing protocols to the network topology T
Revised: Prot ( W ; T ) corresponds to the result of applying routing protocols to the network topology T

Original: andthe conﬁguration W (e.g. link weights).
Revised: andthe conﬁguration W (e.g. link weights).

Original: In the following, we omit T as it remains ﬁxed in synthesis.
Revised: In the following, we omit T as it remains ﬁxed in synthesis.

Original: The resulting forwarding plane F WD can be understood as a directed graph superimposed on topology

Original: T .

Original: It speciﬁes a subset of links that are used to forward packets.

Original: To illustrate consider Figure 1:applying the routing protocols yields forwarding plane F WD which corresponds to the subset of links( C,A ) , ( B,A ) , ( A,E ) , ( D,F ) .

Original: The other links of the network are not part of the forwarding planeand will thus not be used to forward trafﬁc.

Original: Given F WD , we consider a forwarding speciﬁcation S ∶= { R i } i as an input to the synthesis problem.
Revised: We consider a forwarding speciﬁcation S ∶= { R i } i as an input to the synthesis problem.

Original: Each requirement in S is modelled as a function R i , where R i ( F WD )
Revised: Eachrequirement in S is modelled as a function R i , where R i ( F WD )

Original: = 1 if F WD satisﬁes therequirement and 0 otherwise.
Revised: = 1 if F WD satisﬁes the requirementand 0 otherwise.

Original: Practical example requirements include reachability, trafﬁc isolation orspecifying concrete forwarding paths.
Revised: Practical example requirements include reachability, trafﬁc isolation or specifyingconcrete forwarding paths.

Original: Exact Conﬁguration Synthesis We formulate the general conﬁguration synthesis problem as thefollowing optimization objective:
Revised: Exact Conﬁguration Synthesis We formulate the general conﬁguration synthesis problem as thefollowing optimization objective:

Original: [Equation]
Revised: [Equation]

Original: where
Revised: where

Original: [Equation]
Revised: [Equation]

Original: P ( W ) denotes the set of all possible conﬁgurations and C ( F WD ,S ) is the speciﬁcation consistencyof a forwarding plane F WD w.r.t speciﬁcation S .
Revised: P ( W ) denotes the set of all possible conﬁgurations and C ( F WD ,S ) is the speciﬁcation consistencyof a forwarding plane F WD w.r.t speciﬁcation S .

Original: In traditional, exact conﬁguration synthesis, thisobjective is solved by limiting the search to globally-optimal conﬁgurations such that C ( F WD ,S )
Revised: In traditional, exact conﬁguration synthesis, thisobjective is solved by limiting the search to globally-optimal conﬁgurations such that C ( F WD ,S )

Original: =1 . 0 , i.e. all requirements must be satisﬁed.
Revised: =1 . 0 , i.e. all requirements must be satisﬁed.

Original: Such exact methods typically resort to SMT solversbecause of the hardness of the underlying problem: conﬁgurations comprise a large number of tunableparameters, where the execution of several interacting protocols yields the overall forwarding state.
Revised: Such exact methods typically resort to SMT solversbecause of the hardness of the underlying problem: conﬁgurations comprise a large number of tunableparameters, where the execution of several interacting protocols yields the overall forwarding state.

Original: Even worse, parts of the conﬁguration synthesis problem have been shown to be NP-hard [7, 16, 43]: For example, already the subproblem of ﬁnding link weights that yield a given set of forwardingpaths under shortest-path routing is NP-hard [7]. This makes scaling exact synthesis to real-worldnetworks extremely challenging.
Revised: Even worse, parts of the conﬁguration synthesis problem have been shown to be NP-hard [7, 16, 41],which makes scaling exact synthesis to real-world networks extremely challenging.

Original: Learning-Based Synthesis To enable fast and scalable conﬁguration synthesis, we propose to relaxboth the optimality as well as the rigid satisfaction requirements w.r.t the speciﬁcation S .
Revised: Learning-Based Synthesis To break the conﬁguration scalability barrier, we propose to relax boththe optimality as well as the rigid satisfaction requirements w.r.t the speciﬁcation S .

Original: Concretely,we relax the set of admissible solutions to include conﬁgurations that are not optimal, but still satisfya large number of provided requirements.
Revised: Concretely, werelax the set of admissible solutions to include conﬁgurations that are not optimal, but still satisfy alarge number of provided requirements.

Original: Note that this is not the same as merely allowing solutionswith C ( F WD ,S ) < 1 . 0 , because maximum satisﬁability does not relax the hardness of the problem.
Revised: Note that this is not the same as merely allowing solutionswith C ( F WD ,S ) < 1 . 0 , because maximum satisﬁability does not relax the hardness of the problem.

Original: Instead, we propose to search for near-optimal, good solutions and rely on the value of speciﬁcationconsistency C as a measure of quality.
Revised: Instead, we propose to search for near-optimal, good solutions and rely on the value of speciﬁcationconsistency C as a measure of quality.

Original: An approximate synthesis formulation relaxes the hardness of the problem, however, it also leads tothe difﬁcult technical challenge of ﬁnding solutions with high utility (e.g., where many requirementsare satisﬁed).
Revised: An approximate synthesis formulation relaxes the hardness of the problem, however, it also leads tothe difﬁcult technical challenge of ﬁnding solutions with high utility (e.g., where many requirementsare satisﬁed).

Original: To address this challenge, we propose a rather different approach where we learnsynthesis from data.
Revised: To address this challenge, we propose a radically different approach where we learn thesynthesizer from data.

Original: Concretely, we learn an inverse mapping that attempts to predict approximatesolutions ˆ W ⋆ with high utility, as guided by the following objective:
Revised: Concretely, we learn an inverse mapping that attempts to predict approximatesolutions ˆ W ⋆ with high utility, as guided by the following objective:

Original: [Equation]
Revised: [Equation]

Original: This can be implemented as a synthesizer model M Syn which produces a solution given just thetopologyT and the speciﬁcation S :
Revised: This can be implemented as a synthesizer model M Syn which produces a solution given just thetopology and the speciﬁcation:

Original: [Equation]
Revised: [Equation]

Original: We propose a learning-based approach for training such synthesizer models based on neural algorithmic reasoning (cf.
Revised: We propose a learning-based approach for training such synthesizer models based on neural algorithmic reasoning (cf.

Original: Section 4).
Revised: Section 4).

Original: First, however, we discuss the routing protocols that make up function
Revised: First, however, we discuss the routing protocols that make up function

Original: Prot and how they relate to graph algorithms and by extension to NAR.
Revised: Prot and how they relate to graph algorithms and by extension to NAR.

Original:  Routing Protocols as Graph Algorithms
Revised:  Routing Protocols as Graph Algorithms

Original: In practice, the routing protocols deﬁning Prot are implemented as distributed systems in whichmultiple peers communicate to determine the network’s forwarding state.
Revised: In practice, the routing protocols deﬁning Prot are implemented as distributed systems in whichmultiple peers communicate to determine the network’s forwarding state.

Original: However, theoretical workon routing algebras [21] has shown that the underlying computation can be understood as a traditionalmessage-passing graph algorithm.
Revised: However, theoretical work on routing algebras [20] has shown that the underlying computation can be understood as a traditionalmessage-passing graph algorithm.

Original: As a consequence, many routing protocols can be formulatedas Bellman-Ford (BF) style propagation processes.
Revised: As a consequence, many routing protocols can be formulated as Bellman-Ford (BF) style propagation processes.

Original: This class of problems has also recently beensubject to work on NAR [42, 40] and algorithmic alignment [44].
Revised: This class of problems has also recently been subjectto work on NAR [40, 38] and algorithmic alignment [42].

Original: The authors of these worksdemonstrate that neural networks are capable of closely imitating BF-style algorithms when providedwith a suitable inductive bias.
Revised: In these works, the authors demonstratethat neural networks are capable of closely imitating BF-style algorithms when provided with asuitable inductive bias.

Original: Based on this insight, NAR proposes to replace traditional algorithmswith neural networks to learn improved algorithmic procedures or extend existing algorithms to beapplicable to raw data [40].

Original: Following the idea of NAR, we implement a synthesizer modelfornetwork conﬁgurations as an iterative Graph Neural Network (GNN) to learn Prot − 1 by relying on a 
Revised: In our work we build on these results and design a synthesizer model as aniterative Graph Neural Network (GNN) to learn Prot − 1 , with a similar inductive bias.

Original: Bellman-Ford style inductive bias.

Original: Synthesis Setting While our approach is general for the domain of networks, we focus on twowidely-used routing protocols: (1) Open Shortest Path First (OSPF) [29] – it uses link weights to routetrafﬁc along the shortest path towards the destination, andthe (2) Border Gateway Protocol (BGP)[31], used to exchange reachability information, mostly on the level of larger backbone networks.
Revised: Synthesis Setting While our approach is general, for the domain of networks, we focus on twowidely-used routing protocols: (1) OSPF [27] – it uses link weights to route trafﬁc along the shortestpath towards the destination, and (2) BGP [29], used to exchange reachability information, mostly onthe level of larger backbone networks.

Original: When using BGP, a routing destination announces its existence to other networks and routers bysending out BGP announcements.
Revised: When using BGP, a routing destination announces its existenceto other networks and routers by sending out BGP announcements.

Original: Receivers of announcements then choose to pass them on to otherpeers, redistribute them internally and/or modify them according to a set of decision rules.
Revised: Receivers of announcements thenchoose to pass them on to other peers, redistribute them internally and/or modify them according toa set of decision rules.

Original: BGP and OSPF interact, for instance, BGP will consider the OSPF cost of internal destinations in its routingdecisions.
Revised: BGP and OSPF interact, for instance, BGP will consider the OSPF cost ofinternal destinations in its routing decisions.

Original: This means, that effective BGP/OSPF synthesis tools must implement cross-protocolreasoning, conﬁguring both BGP and OSPF at the same time, such that together they yield the desiredforwarding behaviour.
Revised: Conﬁguration Parameters For our purposes, we deﬁne the set of synthesized conﬁguration parameters as follows: For OSPF, we synthesize link weights as explored in existing work [15, 16]. For BGP, we focus on a setting, where we synthesize BGP import policies only. This means wesynthesize the modiﬁcations required for BGP announcements when entering the network, to satisfythe routing speciﬁcation.

Revised: Previous work has conﬁrmed that this is a realistic conﬁguration setting thatapplies to majority of real-world networks [9, 12, 35].

Original: Example  To provide a basic intuition about BGP/OSPF routing, consider the simple examplenetwork in Figure 2. We apply the two protocols to obtain the forwarding plane.
Revised: Example intuition To provide a basic intuition about BGP/OSPF routing, consider the simpleexample network in Figure 2, to which we apply the two protocols to obtain the forwarding plane.

Original: Physical OSPFedges are labelled with a corresponding link weight determining the OSPF cost of paths through thenetwork. Dotted lines represent designated BGP edges, used to propagate BGP announcements.
Revised: Physical OSPF edges are labelled with a corresponding link weight, whereas dotted lines representdesignated BGP session edges.

Original: Ournetwork imports multiple BGP announcements ∎ and ▲ from E and F respectively.
Revised: Our network imports multiple BGP announcements ∎ and ▲ from Eand F respectively.

Original: Both represent aroute to the same destination.
Revised: Both represent a route to the same destination.

Original: As shown, the announcements have a so-called BGP local preference of Distributionof SynthesizedParameters [Figure] 4x
Revised: As shown, the announcementshave a so-called BGP local preference of 2 (we ignore other BGP properties in this example).

Original: [Figure]

Original: 2 (we ignore other BGP properties in this example).

Original: The announcements are propagated through thenetwork and the best route is selected according to a designated BGP decision procedure.
Revised: Theannouncements are propagated through the network and the best route is selected according to adesignated BGP decision procedure.

Original: Figure 2shows the intermediate states of this propagation process.
Revised: Figure 2 shows the intermediate states of this propagationprocess.

Original: As both announcements have the samelocal preference value, the decision cannot eliminate based on that.
Revised: As both announcements have the same local preference value, the decision cannot eliminatebased on that.

Original: Instead, in round 2, node Bselects ∎ over ▲ due to a lower OSPF cost(shorter path) of 2 via nodeA as compared to 3 via node D.
Revised: Instead, in round 2, node B selects ∎ over ▲ due to a lower OSPF cost of 2 via node

Original:  Node D selects ▲ over ∎ , since it learns this route directly from an external peer which is preferredin BGP.
Revised: Aas compared to 3 via node D. Node D selects ▲ over ∎ , since it learns this route directly from anexternal peer which is preferred in BGP.

Original: After Round 3, the BGP propagation process converges to a stable state and we can derivethe forwarding plane as shown on the left in Figure 2.
Revised: After Round 3, the BGP propagation process converges to astable state and we can derive the forwarding plane as shown on the left in Figure 2.

Original: For completeness, we include the full BGPdecision process in Appendix A.3.
Revised: For completeness,we include the full BGP decision process in Appendix A.3.

Original: Conﬁguration Parameters For our purposes, we deﬁne the set of synthesized conﬁguration parameters as follows:
Revised: Based on the observation that routing protocols such as OSPF and BGP can be expressed as graphalgorithms, we heavily rely on GNNs/NAR for the design of our synthesizer model as discussednext.

Original: For OSPF, we synthesize link weights as explored in existing work [15, 16]. For BGP, we focus on a setting, where we synthesize BGP import policies only.
Revised: In our evaluation, we then train such a model for the concrete case of BGP/OSPF and comparesynthesis performance with a traditional SMT-based tool.

Original: This means wesynthesize the modiﬁcations required for BGP announcements when entering the network, to satisfythe routing speciﬁcation. Previous work has conﬁrmed that this is a realistic conﬁguration setting thatapplies to a majority of real-world networks [9, 12, 37].
Revised: Distributionof SynthesizedParameters [Figure]

Original: Based on the observation that routing protocols such as OSPF and BGP can be expressed asmessage-passing algorithms, we heavily rely on GNNs/NAR for the design of our synthesizer modelas discussed next.
Revised: 4x

Original: In our evaluation, we then train such a model for the concrete case of BGP/OSPFand compare synthesis performance with a traditional SMT-based tool.
Revised: [Figure]

Original:  Neural Conﬁguration Synthesis Model
Revised:  Neural Conﬁguration Synthesis Model

Original: We train a graph neural network (GNN) as the neural synthesis conﬁguration model.
Revised: We train a graph neural network (GNN) as the neural synthesis conﬁguration model.

Original: The model’sinput consists of a topology, a speciﬁcation, and a conﬁguration sketch where to-be-synthesizedparameters are omitted.
Revised: The model’sinput consists of a topology, a speciﬁcation, and a conﬁguration sketch where to-be-synthesizedparameters are omitted.

Original: Following the NAR paradigm, we ﬁrst encode this synthesizer input in latentspace.
Revised: Following the NAR paradigm, we ﬁrst encode this synthesizer input in latentspace.

Original: Then, we apply an iterative processor network based on the graph attention mechanism [41].
Revised: Then, we apply an iterative processor network based on the graph attention mechanism [39].

Original: Last, we apply a decoder network to predict the values of omitted conﬁguration parameters, therebysynthesizing a conﬁguration.
Revised: Last, we apply a decoder network to predict the values of omitted conﬁguration parameters, therebysynthesizing a conﬁguration.

Original: To remain protocol-agnostic, our model is generic with respect to theinput format, using an intermediate representation based on Datalog-like facts.
Revised: To remain protocol-agnostic, our model is generic with respect to theinput format, using an intermediate representation based on Datalog-like facts.

Original: Figure 3 provides anoverview of our graph-based neural synthesizer architecture.
Revised: Figure 3 provides anoverview of our graph-based neural synthesizer architecture.

Original: 4.1 Training Dataset of Inverse Pairs
Revised: 4.1 Training Dataset of Inverse Pairs

Original: A learning-based synthesizer model is formulated as a supervised learning problem.
Revised: A learning-based synthesizer model is formulated as a simple input-output mapping.

Original: Thus, wecan directly train a neural network to learn the inverse mapping, given a dataset of correspondinginput-output pairs.
Revised: Thus, wecan directly train a neural network to learn the inverse mapping, given a dataset of correspondinginput-output pairs.

Original: To obtain such a dataset, we sample a random network conﬁguration for sometopology using a uniform generative process.
Revised: To obtain such a dataset, we sample a random network conﬁguration for sometopology using a uniform generative process.

Original: Then, we simulate the involved protocols using Prot ,to obtain the corresponding forwarding plane.
Revised: Then, we simulate the involved protocols using Prot ,to obtain the corresponding forwarding plane.

Original: Next, we extract a speciﬁcation by randomly selectingproperties that hold for the computed forwarding plane.
Revised: Next, we extract a speciﬁcation by randomly selectingproperties that hold for the computed forwarding plane.

Original: This leaves us with a pair of speciﬁcationand topology as input, and a corresponding conﬁguration as output.[Figure] [Figure]
Revised: This leaves us with a pair of speciﬁcationand topology as input, and a corresponding conﬁguration as output.

Original: The key to constructing the dataset is the implementation of Prot .
Revised: The key to constructing the dataset is the implementation of Prot .

Original: Even though Prot is protocolspeciﬁc, it turns out the overall implementation effort is comparatively low, especially when comparedto SMT-based synthesis methods.
Revised: Even though Prot is protocolspeciﬁc, it turns out the overall implementation effort is comparatively low, especially when comparedto SMT-based synthesis methods.

Original: Protocols are well-deﬁned algorithms that can be easily simulated,whereas the alternative of implementing hardcoded synthesis rules directly often requires expertknowledge of SMT solvers.
Revised: Protocols are well-deﬁned algorithms that can be easily simulated,whereas the alternative of implementing hardcoded synthesis rules directly often requires expertknowledge of SMT solvers.

Original: This process may also be adapted to rely on actual router hardware tocompute the result of Prot , thereby capturing real-world behavior precisely.
Revised: This process may also be adapted to rely on actual router hardware tocompute the result of Prot , thereby capturing real-world behavior precisely.

Original: 4.2 Embedding Topologies, Speciﬁcations and Conﬁgurations
Revised: 4.2 Embedding Topologies, Speciﬁcations and Conﬁgurations

Original: To remain agnostic with respect to routing protocols, our model architecture implements a genericgraph-based encoding of Datalog-like facts, similar to knowledge graphs [32]: we ﬁrst encodetopologies, conﬁgurations and speciﬁcations as a set of Datalog-like facts and then employ a genericembedding scheme to embed these facts into latent space.
Revised: To remain agnostic with respect to routing protocols, our model architecture implements a genericgraph-based encoding of Datalog-like facts, similar to knowledge graphs [30]: we ﬁrst encodetopologies, conﬁgurations and speciﬁcations as a set of Datalog-like facts and then employ a genericembedding scheme to embed these facts into latent space.

Original: Fact Base A set of Datalog-like facts, as depicted in Figure 4, serves as the input fact base Fto our synthesizer model.
Revised: Fact Base A set of Datalog-like facts, as depicted in Figure 4, serves as the input fact base Fto our synthesizer model.

Original: F is a set of facts f ( a 0 ,...,a n ) where arguments may be constants(e.g.
Revised: F is a set of facts f ( a 0 ,...,a n ) where arguments may be constants(e.g.

Original: A or B) or integer literals.
Revised: A or B) or integer literals.

Original: Each fact has a corresponding boolean truth value denoted as[ f ( a )] B .
Revised: Each fact has a corresponding boolean truth value denoted as[ f ( a )] B .

Original: For instance, from the fact base in Figure 4 we can derive [ fwd ( A,B,N 1 )]
Revised: For instance, from the fact base in Figure 4 we can derive [ fwd ( A,B,N 1 )]

Original: B = true and[ fwd ( B,A,N 1 )]
Revised: B = true and[ fwd ( B,A,N 1 )]

Original: B = false .
Revised: B = false .

Original: Synthesis as
Revised: Synthesis as

Original: Completion Task
Revised: Completion Task

Original: A network’s topology, protocol conﬁguration, parameters, andthe speciﬁcation are all represented in a single fact base.
Revised: A network’s topology, protocol conﬁguration, parameters, andthe speciﬁcation are all represented in a single fact base.

Original: To predict the value of unknown, to-besynthesized parameters, we support the notion of unknown parameters as illustrated at (cid:202) in Figure 4,where the link weight between router nodes A and C is omitted.
Revised: To predict the value of unknown, to-be- [Figure] synthesized parameters, we support the notion of unknown parameters as illustrated at (cid:202) in Figure 4,where the link weight between router nodes A and C is omitted.

Original: Based on this input format, synthesiscorresponds to using our model to predict the value of unknown parameters in a provided fact base.
Revised: Based on this input format, synthesiscorresponds to using our model to predict the value of unknown parameters in a provided fact base.

Original: Embedding To transform a fact base into a graph with node features, we apply a structurally-deﬁnedembedding scheme.
Revised: Embedding To transform a fact base into a graph with node features, we apply a structurallydeﬁned embedding scheme.

Original: An example of this embedding scheme is given in Figure 5.

Original: As shown, weembed topology, speciﬁcation and conﬁguration all into a single graph.

Original: This places network routers,the related speciﬁcation predicates as well as conﬁguration parameters in close adjacency to eachother, simplifying the synthesis procedure for the processor network.

Original: In our scheme, both facts andconstants are represented as distinct nodes.
Revised: In the resulting graph, both facts and constants are represented as distinctnodes.

Original: The relationships between facts and constants are encodedas node adjacency as deﬁned by neighborhood functions
Revised: The relationships between facts and constants are encoded as node adjacency as deﬁned byneighborhood functions

Original: N i .
Revised: N i .

Original: We use multiple neighborhoods, i.e.multiple types of edges, to encode the argument position of a constant occurring in a fact.
Revised: We use multiple neighborhoods, i.e. multiple types of edges, to encodethe argument position of a constant occurring in a fact.

Original: To handle unknown parameters, we replace the corresponding embedding with a learned V hole embedding.
Revised: To handle unknown parameters, we replacethe corresponding embedding with a learned V hole embedding.

Original: Overall, the embedding function E MB relies on a set of learned parameters, including V f ∈ R D perfact type inF , W bool ∈
Revised: Overall, the embedding function E MB relies on a set of learned parameters, including V f ∈ R D per fact type in

Original:  R D × 2 for boolean values, W f i ∈
Revised: F , W bool ∈ R D × 2for boolean values, W f i ∈

Original: R D × N per integer argument of fact type fand V hole ∈ R D to represent unknown parameters.
Revised: R D × N per integer argument of fact type f and V hole ∈ R D to representunknown parameters.

Original: D is the dimensionality of the latent space and Nspeciﬁes the number of supported integer values.
Revised: D is the dimensionality of the latent space and N speciﬁes the number ofsupported integer values.

Original: For the complete embedding scheme, please see Appendix A.1.
Revised: For the complete embedding scheme, please see Appendix A.1.

Original: 4.3 A NAR-based Synthesizer Model
Revised: 4.3 A NAR-based Synthesizer Model

Original: Our synthesizer model employs an encode-process-decode architecture, inspired by neural algorithmicreasoning [40].
Revised: Our synthesizer model employs an encode-process-decode architecture, inspired by neural algorithmicreasoning [38].

Original: It employs four main components to produce the output distribution for an unknownparameter in a fact base F : The fact base embedding E MB , the encoder E NC GAT , the processor
Revised: It employs four main components to produce the output distribution for an unknownparameter in a fact base F : The fact base embedding E MB , the encoder E NC GAT , the processor

Original: P ROC GAT and the fact-type speciﬁc decoder network D EC f i .
Revised: P ROC GAT and the fact-type speciﬁc decoder network D EC f i .

Original: Overall, the model can be expressed as follows, where X j and H j refer to the intermediate noderepresentations per node j in the graph constructed via our fact base embedding.
Revised: Overall, the model can be expressed as follows, where X j and H j refer to the intermediate noderepresentations per node j in the graph constructed via our fact base embedding.

Original: [Equation]
Revised: [Equation]

Original: E NC GAT is a GNN relying on Graph Attention Layers (GAT) [41] for propagation.
Revised: E NC GAT is a GNN relying on Graph Attention Layers (GAT) [39] for propagation.

Original: We additionallyapply noise to the latent node representation X j via z as a source of non-determinism, anticipatingthe fact that the synthesis problem often has more than one solution.
Revised: We additionallyapply noise to the latent node representation X j via z as a source of non-determinism, anticipatingthe fact that the synthesis problem often has more than one solution.

Original: The processor P ROC GAT ismodelled as an iterative process.
Revised: The processor P ROC GAT ismodelled as an iterative process.

Original: It consists of a 6-layer graph attention module which we applyfor a total of 4 iterations.
Revised: It consists of a 6-layer graph attention module which we applyfor a total of 4 iterations.

Original: According to the NAR paradigm, this computational structure encodes aninductive bias towards an iterative solution to the synthesis problem.
Revised: According to the NAR paradigm, this computational structure encodes aninductive bias towards an iterative solution to the synthesis problem.

Original: In the encoder and processor GNNs, we rely on a composed variant of the graph attention layer asintroduced by [41].
Revised: In the encoder and processor GNNs, we rely on a composed variant of the graph attention layer asintroduced by [39].

Original: We employ multiple graph attention layers in lockstep, one per neighborhood N ideﬁned by our graph embedding (cf.
Revised: We employ multiple graph attention layers in lockstep, one per neighborhood N ideﬁned by our graph embedding (cf.

Original: Section 4.2), and combine the intermediate results after eachstep by summation.
Revised: Section 4.2), and combine the intermediate results after eachstep by summation.

Original: For details on the graph attention module, please refer to Appendix A.2.
Revised: For details on the graph attention module, please refer to Appendix A.2.

Original: Finally, an argument decoder D EC f
Revised: Finally, an argument decoder D EC f

Original: i is used, to produce the output distribution
Revised: i is used, to produce the output distribution

Original: O f j ( a 0 ,...,a i − 1 , ? ,...,a n ) 232 for an unknown parameter at position i of fact f j ∈ F , corresponding to node j .
Revised: O f j ( a 0 ,...,a i − 1 , ? ,...,a n ) 209 for an unknown parameter at position i of fact f j ∈ F , corresponding to node j .

Original: For this, thesynthesizer model provides one decoder per integer argument, per supported fact type.
Revised: For this, thesynthesizer model provides one decoder per integer argument, per supported fact type.

Original: For example,a model for the fact base in Figure 4 would provide a decoder network D conn∶ R D
Revised: For example, amodel for the fact base in Figure 4 would provide a decoder network D connected∶ R D

Original: → R N to decodevalues for the third argument of a conn fact.
Revised: → R N to decodevalues for the third argument of a connected fact.

Original: Decoder networks are implemented as simple multi-layerperceptron models.
Revised: Decoder networks are implemented as simplemulti-layer perceptron models.

Revised: [Table]

Original: Supervision Signal
Revised: Supervision Signal

Original: During training, we mask all fact arguments that represent to-be-synthesizedconﬁguration parameters in our synthesis setting as unknown parameters.
Revised: During training, we mask all fact arguments that represent to-be-synthesizedconﬁguration parameters in our synthesis setting as unknown parameters.

Original: As a supervision signalwe use the masked values as the ground-truth and apply a negative log-likelihood loss to the outputdistribution of the corresponding argument decoder networks.
Revised: As a supervision signalwe use the masked values as the ground-truth and apply a negative log-likelihood loss to the outputdistribution of the corresponding argument decoder networks.

Original: Multi-Shot Sampling To sample values from the output distributions of unknown parameters, weapply a multi-shot sampling strategy.
Revised: Multi-Shot Sampling To sample values from the output distributions of unknown parameters, weapply a multi-shot sampling strategy.

Original: We sample values only for a subset of unknown parameters,insert them in the input fact base and run the synthesizer again.
Revised: We sample values only for a subset of unknown parameters,insert them in the input fact base and run the synthesizer again.

Original: We repeat until no more unknownparameters remain.
Revised: We repeat until no more unknownparameters remain.

Original: This multi-shot strategy allows the model to incorporate concrete values ofpreviously synthesized parameters in its computation.
Revised: This multi-shot strategy allows the model to incorporate concrete values ofpreviously synthesized parameters in its computation.

Original: In our evaluation, we compare this approach tosampling all parameters at once.
Revised: In our evaluation, we compare this approach tosampling all parameters at once.

Original:  Evaluation
Revised:  Evaluation

Original: In this section, we assess the performance of our model trained for BGP/OSPF synthesis.
Revised: In this section, we assess the performance of our model trained for BGP/OSPF synthesis.

Original: For this,we trained a synthesizer model on a dataset of 10 , 240 samples, constructed by randomly samplingtopologies, corresponding speciﬁcations and BGP/OSPF conﬁgurations as described in Section 4.1.
Revised: For this,we trained a synthesizer model on a dataset of 10 , 240 samples, constructed by randomly samplingtopologies, corresponding speciﬁcations and BGP/OSPF conﬁgurations as described in Section 4.1.

Original: For details on BGP/OSPF dataset generation and training, please see Appendix A.3.
Revised: For details on BGP/OSPF dataset generation and training, please see Appendix A.3.

Original: Lastly, we alsoevaluate our architectural design decisions in an ablation and parameter study in Appendix D.

Original: [Table] [Table] Dataset and Metrics We compare using datasets Small (S), Medium (M), and Large (L).
Revised: Dataset and Metrics We compare using datasets Small (S), Medium (M), and Large (L).

Original: Eachdataset comprises 8 real-world topologies taken from the Topology Zoo [28], where the number ofnodes lies between 0-18, 18-39, and 39-153, respectively.
Revised: Eachdataset comprises 8 real-world topologies taken from the Topology Zoo [26], where the number ofnodes lies between 0-18, 18-39, and 39-153, respectively.

Original: To obtain random forwarding speciﬁcationswe use the same generative pipeline as discussed in Section 4.1.
Revised: To obtain random forwarding speciﬁcationswe use the same generative pipeline as discussed in Section 4.1.

Original: Regarding forwarding requirements,we implement support for three speciﬁcation facts: fwd requirements to set/block forwarding paths,reachable to specify reachability and trafficIsolation to induce trafﬁc isolation among trafﬁcclasses (no shared links).
Revised: Regarding forwarding requirements,we implement support for three speciﬁcation facts: fwd requirements to set/block forwarding paths,reachable to specify reachability and trafficIsolation to induce trafﬁc isolation among trafﬁcclasses (no shared links).

Original: In each topology, we do synthesis for 4 different trafﬁc classes (routingdestinations) at a time.
Revised: In each topology, we do synthesis for 4 different trafﬁc classes (routingdestinations) at a time.

Original: Overall, this results in 3 datasets x 8 topologies per dataset x 3 differentlysize speciﬁcations = 72 synthesis tasks.

Original: To assess synthesis quality, we determine speciﬁcationconsistency as the relative number of speciﬁcation facts in a fact base that are satisﬁed by thesynthesized conﬁguration.
Revised: To assess synthesis quality, we determine speciﬁcation consistency as therelative number of speciﬁcation facts in a fact base that are satisﬁed by the synthesized conﬁguration.

Original: Experimental Setup We run all experiments on an Intel(R) Core(TM) i9-9900X @ 3.5GHzmachine with 64GB of system memory and an NVIDIA  RTX 3080 GPU with 10GB of video memory.
Revised: Experimental Setup We run all experiments on an Intel(R) Core(TM) i9-9900X @ 3.5GHzmachine with 64GB of system memory and an NVIDIA GeForce RTX 3080 GPU with 10GB ofvideo memory.

Original: 5.1 Synthesis Quality
Revised: 5.1 Synthesis Quality

Original: To assess the quality of synthesized network conﬁgurations, we examine speciﬁcation consistencywith increasingly large topologies and speciﬁcations.
Revised: To assess the quality of synthesized network conﬁgurations, we examine speciﬁcation consistencywith increasingly large topologies and speciﬁcations.

Original: For each synthesis task, we run our synthesizer 5times using 4-shot sampling and report the network conﬁgurations with the highest overall consistency.
Revised: For each synthesis task, we run our synthesizer 5times using 4-shot sampling and report the network conﬁgurations with the highest overall consistency.

Original: Table 2 documents the results.
Revised: Table 2 documents the results.

Original: On average, our synthesis model achieves > 93% speciﬁcationconsistency for all datasets and speciﬁcations.
Revised: On average, our synthesis model achieves > 93% speciﬁcationconsistency for all datasets and speciﬁcations.

Original: With few requirements, the synthesizer model evensucceeds in producing fully-consistent conﬁgurations (cf.
Revised: With few requirements, the synthesizer model evensucceeds in producing fully-consistent conﬁgurations (cf.

Original: Full Matches in Table 2).
Revised: Full Matches in Table 2).

Original: We observe aslight decrease in consistency with increasingly large topologies.
Revised: We observe aslight decrease in consistency with increasingly large topologies.

Original: Multi-Shot Sampling To determine the effect of multi-shot-sampling, we report consistency whenusing 1-shot, 4-shot and 8-shot sampling in Table 1.
Revised: Multi-Shot Sampling To determine the effect of multi-shot-sampling, we report consistency whenusing 1-shot, 4-shot and 8-shot sampling in Table 1.

Original: As a baseline, we also show consistency whensampling conﬁgurations from a uniform distribution (per parameter).
Revised: As a baseline, we also show consistency whensampling conﬁgurations from a uniform distribution (per parameter).

Original: This simple method can achievesuprisingly good results, as parts of a speciﬁcation may be satisﬁed naturally by the mechanicsof shortest-path routing.

Original: Still, competing with this baseline our synthesizer model shows clearimprovements and multi-shot sampling further increases consistency.
Revised: Compared to this baseline, oursynthesizer model shows clear improvement and multi-shot sampling further increases consistency.

Original: Number of Samples We also consider the number of times we sample from our synthesizermodel.
Revised: Number of Samples We also consider the number of times we sample from our synthesizer model.

Original: We observe that sampling more than one alternative conﬁguration can lead to improved
Revised: We observe that sampling more than once improves the average best speciﬁcation consistency across

Original: [Table]
Revised: [Table]

Original: best-of speciﬁcation consistency across all datasets. Based on this observation, we boost synthesispeformance by sampling multiple times per synthesis task. For each conﬁguration that we obtainin this way, we simulate the routing protocols, obtain the forwarding plane and check speciﬁcationconsistency. This fully automated process allows us to determine the best result without consultingthe user.
Revised: [Table]

Original: We select the best result as the overall output for synthesis, dismissing the other samples.
Revised: all datasets.

Original: We experiment how the number of times we sample affects the resulting consistency in Appendix B. Overall, sampling more than once is beneﬁcial for all datasets. Average best consistency values appearto be reached after 4-5 samples for 3 × 16 BGP/OSPF requirements.
Revised: For a detailed result, please see Appendix B. Overall, sampling more than once isbeneﬁcial for all datasets, where average best consistency values appear to be reached after 4-5samples for 3 × 16 BGP/OSPF requirements.

Original: Hence, we rely on 5 samples inall other experiments as a trade-off of fast synthesis time and good speciﬁcation consistency.
Revised: Hence, we rely on 4-5 samples in our other experimentsas a trade-off of fast synthesis time and good speciﬁcation consistency.

Original: Unsatiﬁable Speciﬁcations
Revised: Unsatiﬁable Speciﬁcations

Original: In practice, network operators may sometimes provide unsatisﬁablespeciﬁcations.
Revised: In practice, network operators may sometimes provide unsatisﬁablespeciﬁcations.

Original: While exact methods will typically return an error for such inputs, our relaxedsetting enables us to consider partial solutions, i.e. conﬁgurations that still achieve high speciﬁcationconsistency while ignoring unsat requirements.
Revised: While exact methods will typically return an error for such inputs, our relaxedsetting enables us to consider partial solutions, i.e. conﬁgurations that still achieve high speciﬁcationconsistency while ignoring unsat requirements.

Original: This may be preferable in some scenarios, especiallywhen perfect speciﬁcation consistency is not critical anyway.
Revised: This may be preferable in some scenarios, especiallywhen perfect speciﬁcation consistency is not critical anyway.

Original: To simulate this scenario, we evaluatespeciﬁcation consistency for OSPF-only synthesis tasks, which were all veriﬁed to be unsatisﬁableusing the SMT-based synthesizer NetComplete [15].
Revised: To simulate this scenario, we evaluatespeciﬁcation consistency for OSPF-only synthesis tasks, which were all veriﬁed to be unsatisﬁableusing the SMT-based synthesizer NetComplete [15].

Original: We still observe a comparatively high averageconsistency of 0 .
Revised: We still observe a comparatively high averageconsistency of 0 .

Original: 90 for our learned synthesizer.
Revised: 90 for our learned synthesizer.

Original: This suggests that our model is indeed capable ofhandling unsatisﬁable speciﬁcations, while still producing good, partial solutions.
Revised: This suggests that our model is indeed capable ofhandling unsatisﬁable speciﬁcations, while still producing good, partial solutions.

Original: For more detailedunsat results and methodology, see Appendix B.2.
Revised: For more detailedunsat results and methodology, see Appendix B.2.

Original: 5.2 Comparison to SMT-based Synthesis
Revised: 5.2 Comparison to SMT-based Synthesis

Original: We also compare the synthesis time of our learned synthesizer with that of NetComplete, a state-of-artconﬁguration synthesis tool based on SMT [15].
Revised: We also compare the synthesis time of our learned synthesizer with that of NetComplete, a state-of-artconﬁguration synthesis tool based on SMT [15].

Original: We compare both BGP/OSPF and OSPF-onlysynthesis time.
Revised: We compare both BGP/OSPF and OSPF-onlysynthesis time.

Original: For each topology/speciﬁcation, we report the total time of running our synthesizer 4times using 4-shot sampling, whereas for consistency we report the best out of the 4 runs.
Revised: For each topology/speciﬁcation, we report the total time of running our synthesizer 4times using 4-shot sampling, whereas for consistency we report the best out of the 4 runs.

Original: In case afully consistent conﬁguration is found, we do not continue to sample and only report time until then.
Revised: In case afully consistent conﬁguration is found, we do not continue to sample and only report time until then.

Original: For NetComplete, we time out at 25 minutes and report that as a lower bound if exceeded.
Revised: For NetComplete, we time out at 25 minutes and report that as a lower bound if exceeded.

Original: We restrictour comparison to speciﬁcations that only include forwarding paths (i.e. fwd facts), as the type ofsupported requirements in NetComplete does not fully align with our model.
Revised: We restrictour comparison to speciﬁcations that only include forwarding paths (i.e. fwd facts), as the type ofsupported requirements in NetComplete does not fully align with our model.

Original:  Table 3 shows how our synthesizer model outperforms NetComplete by multiple orders of magnitude.
Revised: As documented in Table 3, our synthesizer model outperforms NetComplete by multiple orders ofmagnitude.

Original: We observe a speedup of 20 − 490 × which increases with the size of topology/speciﬁcation.
Revised: We observe a speedup of 20 − 560 × which increases with the size of topology/speciﬁcation.

Original: Theentailed loss of precision due to approximation remains moderate, with the average consistency ofthe synthesized conﬁgurations being greater than 92% across all datasets, even for large topologies.
Revised: The average consistency of the synthesized conﬁgurations is greater than 92% across all datasets,even for large topologies.

Original: In comparison, NetComplete times out on more than half of the synthesis tasks, which means thatwe actually only observe a lower bound for speedup.
Revised: In comparison, NetComplete times out on more than half of the synthesistasks, which means that we only observe a lower bound for speedup.

Original: Running our model on a GPU can result ineven greater speedups (up to 900 × given enough GPU memory, cf.
Revised: Running our model on a GPUcan result in even greater speedups (up to 1000 × given enough GPU memory, cf.

Original: Appendix B.3).
Revised: Appendix B.3).

Original: Comparing OSPF-only synthesis time, our synthesizer model achieves a speedup of 2-10x over NetComplete.
Revised: Comparing OSPF-only synthesis time, our synthesizer model achieves a speedup of 2-10x over NetComplete.

Original: With 16 requirements on dataset L this can also increase up to 500 × .
Revised: With 16 requirements on dataset Large this even increases to 2000 × .

Original: Further, our model produces fully-consistent OSPF conﬁgurations even more often than for BGP/OSPF.
Revised: Further, ourmodel produces fully-consistent OSPF conﬁgurations even more often than for BGP/OSPF.

Original: See Appendix B.4 for thefull OSPF-only synthesis comparison.
Revised: For thefull OSPF-only synthesis comparison, see Appendix B.4.

Original: 5.3 Discussion
Revised: 5.3 Discussion

Original: We  demonstrated that our learning-based synthesizer reaches a very high degree of consistency, oftenproducing fully-consistent  conﬁgurations.
Revised: We have demonstrated that our learning-based synthesizer reaches a very high degree of consistency,often producing fully-consistent BGP/OSPF conﬁgurations.

Original: With respect to synthesis time, we outperform SMT-basedmethods by a large margin, especially for larger topologies.
Revised: With respect to synthesis time, weoutperform SMT-based methods by a large margin, especially for larger topologies.

Original: However, this comes at a price: ourmodel sometimes fails to produce fully consistent conﬁgurations, especially for large topologieswith many requirements.
Revised: However, thiscomes at a price: our model sometimes fails to produce fully consistent conﬁgurations, especiallyfor large topologies with many requirements.

Original: In comparison, SMT-based synthesis will always produce fully consistentconﬁgurations if and once it completes.
Revised: In comparison, SMT-based synthesis will alwaysproduce fully consistent conﬁgurations if and once it completes.

Original: We, therefore, observe a trade-off between consistency andsynthesis time.
Revised: We, therefore, observe a trade-offbetween consistency and synthesis time.

Original: We also note that this evaluation considers real topologies (Topology Zoo [28]) butnot real speciﬁcations.

Original: This is due to the lack of a large, practical dataset thereof.

Original: Still, we experimentwith robustness (Appendix D) by introducing distribution shift regarding the size of speciﬁcationsduring training and achieve comparable performance.

Original: Lastly, the Topology Zoo [28] provides a goodreference for realistically-sized networks.

Original: However, if we also consider synthesis with 150 + routers,we note scalability limits: (1) Our models can consume a lot of video memory, reaching beyond theamounts available on common GPUs ( > 12 GB).

Original: And (2), the distance that information can travel inthe GNN is ﬁnite (ﬁxed number of iterations).

Original: This means that in very large networks, our synthesizermodel will only be capable of deriving solutions by local reasoning, which is very likely to impactsynthesis quality.

Original: Nonetheless, we envision a wide range of practically-relevant applications for fast,approximate synthesis, including ML-guided synthesis, unsatisﬁable speciﬁcations, as well as hybridsynthesizers leveraging both learning and SMT.
Revised: Nonetheless, we envision a wide range of practicallyrelevant applications for fast but approximate synthesis, including ML-guided synthesis, unsatisﬁablespeciﬁcations, as well as hybrid synthesizers leveraging both learning and SMT.

Original: We expand on future directions in Appendix C.
Revised: We expand on futuredirections in Appendix C.

Original:  Related Work
Revised:  Related Work

Original: Traditional Conﬁguration Synthesis Next to methods based on compilation such as
Revised: Traditional Conﬁguration Synthesis Next to methods based on compilation such as

Original: Propane/PropaneAT
Revised: Propane/PropaneAT

Original: [5], there is a number of exact conﬁguration synthesis methods based onconstraint solving, e.g. ConﬁgAssure [30], SyNet [14] and NetComplete [15].
Revised: [5], there is a number of exact conﬁguration synthesis methods based onconstraint solving, e.g. ConﬁgAssure [28], SyNet [14] and NetComplete [15].

Original: These tools aretypically hand-coded, very protocol-speciﬁc, and can be slow due to the solvers they employ.
Revised: These tools aretypically hand-coded, very protocol-speciﬁc, and can be slow due to the solvers they employ.

Original: Incontrast, our approach is approximate but scales to much larger networks.
Revised: Incontrast, our approach is approximate but scales to much larger networks.

Original: Further, as a side-productof our learning-based approach, we can easily adapt to new protocols and allow for transparentcross-protocol reasoning, merely by training on different protocol data.
Revised: Further, as a side-productof our learning-based approach, we can easily adapt to new protocols and allow for transparentcross-protocol reasoning, merely by training on different protocol data.

Original: GNNs and Networking DeepBGP [2] relies on GNNs and reinforcement learning to do conﬁguration synthesis.
Revised: GNNs and Networking DeepBGP [2] relies on GNNs and reinforcement learning to do conﬁguration synthesis.

Original: However, it is limited to BGP conﬁguration and is slower than SMT-based synthesis.
Revised: However, it is limited to BGP conﬁguration and is slower than SMT-based synthesis.

Original: In contrast, our learning-based framework is cross-protocol, does not rely on reinforcement learningand provides better synthesis times.
Revised: In contrast, our learning-based framework is cross-protocol, does not rely on reinforcement learningand provides better synthesis times.

Original: Apart from conﬁguration synthesis, GNNs have also been appliedto other problems in the networking domain.
Revised: Apart from conﬁguration synthesis, GNNs have also been appliedto other problems in the networking domain.

Original: For example, the authors of RouteNet [33] use GNNs topredict networking performance metrics.
Revised: For example, the authors of RouteNet [31] use GNNs topredict networking performance metrics.

Original: Other work focuses on learning improved protocols like
Revised: Other work focuses on learning improved protocols like

Original: Q-Routing [8] and Graph-Query Neural Networks [18].
Revised: Q-Routing [8] and Graph-Query Neural Networks [18].

Original: Neural Algorithmic Reasoning NAR [40] refers to the idea of replacing algorithms with neuralnetworks to learn improved algorithmic procedures.
Revised: NAR [38] describes the idea of replacing algorithms with neural networks to learn improved algorithmic procedures.

Original: Related work includes graph algorithms [42]and solvers for combinatorial optimization problems [10, 25, 36].
Revised: Exemplary work includes graph-relatedalgorithms [40] and solvers for combinatorial optimization problems [10, 24, 34].

Original: Our synthesis framework is theﬁrst application of NAR to the networking domain and relies on the NAR-native encode-processdecode architecture.
Revised: Our synthesisframework is the ﬁrst application of NAR to the networking domain and relies on the NAR-nativeencode-process-decode architecture.

Original: In the hierarchy of NAR approaches in [10], our method is an algorithm-levelapproach, as we do not supervise on intermediate steps.
Revised: In the hierarchy of NAR approaches in [10], our method is analgorithm-level approach, as we do not supervise on intermediate steps.

Original: Although step-level methods promise bettergeneralization, it is not clear what an intermediate result of a general synthesis procedure would be.
Revised: Although step-level methods promise better generalization, it is not clear what an intermediate result of a general synthesisprocedure would be.

Original: Future work on a step-level approach may further improve our model.
Revised: Future work on a step-level approach may further improve our model.

Original:  Conclusion
Revised:  Conclusion

Original: We presented a learning-based method to enable approximate but scalable computer network conﬁguration synthesis.
Revised: We presented a learning-based method to enable approximate but scalable computer networkconﬁguration synthesis.

Original: For BGP/OSPF routing, our neural synthesizer is up to 490 × faster than SMT-basedmethods, while producing conﬁgurations with very high speciﬁcation consistency.
Revised: For BGP/OSPF routing, our neural synthesizer is up to 500 × faster than SMT-based methods, while producing conﬁgurations with very high speciﬁcation consistency.

Original: We believe there ismuch future research that can be explored in the direction of learning-based synthesis and ML-guidednetwork conﬁguration.Ethical Issues
Revised: Webelieve there is much future research that can be explored in the direction of learning-based synthesisand ML-guided network conﬁguration.

Original: This work does not raise any ethical issues.

Original: Checklist
Revised: Checklist

Original: The checklist follows the references.
Revised: The checklist follows the references.

Original: Please read the checklist guidelines carefully for information onhow to answer these questions.
Revised: Please read the checklist guidelines carefully for information onhow to answer these questions.

Original: For each question, change the default [TODO] to [Yes] , [No] , or[N/A] .
Revised: For each question, change the default [TODO] to [Yes] , [No] , or[N/A] .

Original: You are strongly encouraged to include a justiﬁcation to your answer , either by referencingthe appropriate section of your paper or providing a brief inline description.
Revised: You are strongly encouraged to include a justiﬁcation to your answer , either by referencingthe appropriate section of your paper or providing a brief inline description.

Original: For example:
Revised: For example:

Original: • Did you include the license to the code and datasets
Revised: • Did you include the license to the code and datasets?

Original: [Yes ] We plan to publish our code anddataset under an open source license and make it available to others.
Revised: [Yes] We plan to publish our code anddataset under an open source license and make it available to others.

Original: Please do not modify the questions and only use the provided macros for your answers.
Revised: Please do not modify the questions and only use the provided macros for your answers.

Original: Note that the
Revised: Note that the

Original: Checklist section does not count towards the page limit.
Revised: Checklist section does not count towards the page limit.

Original: In your paper, please delete this instructionsblock and only keep the Checklist section heading above along with the questions/answers below.
Revised: In your paper, please delete this instructionsblock and only keep the Checklist section heading above along with the questions/answers below.

Original: For all authors...
Revised: For all authors...

Original: (a) Do the main claims made in the abstract and introduction accurately reﬂect the paper’s contributions and scope?
Revised: (a) Do the main claims made in the abstract and introduction accurately reﬂect the paper’scontributions and scope?

Original: [Yes]
Revised: [Yes]

Original: (b) Did you describe 
Revised: (b) Did you describe the limitations of your work?

Original: Yes any
Revised: [Yes]

Revised: (c) Did you discuss any potential negative societal impacts of your work?

Revised: [N/A]

Original: (d) Have you read the ethics review guidelines and ensured that your paper conforms tothem?
Revised: (d) Have you read the ethics review guidelines and ensured that your paper conforms to them?

Original: [Yes]
Revised: [Yes]

Original: If you are including theoretical results...
Revised: If you are including theoretical results...

Original: (a) Did you state the full set of assumptions of all theoretical results?
Revised: (a) Did you state the full set of assumptions of all theoretical results?

Original: [N/A]
Revised: [N/A]

Original: (b) Did you include complete proofs of all theoretical results?
Revised: (b) Did you include complete proofs of all theoretical results?

Original: [N/A]
Revised: [N/A]

Original: If you ran experiments...
Revised: If you ran experiments...

Original: (a) Did you include the code, data, and instructions needed to reproduce the main experi-
Revised: (a) Did you include the code, data, and instructions needed to reproduce the main experi-

Original: mental results (either in the supplemental material or as a URL)?
Revised: mental results (either in the supplemental material or as a URL)?

Original: [Yes]
Revised: [Yes]

Original: (b) Did you specify all the training details (e.g., data splits, hyperparameters,
Revised: (b) Did you specify all the training details (e.g., data splits, hyperparameters,

Original: how they
Revised: how they

Original: were chosen)?
Revised: were chosen)?

Original: [Yes]
Revised: [Yes]

Original: (c) Did you report error bars (e.g., with respect to the random seed after running experi-
Revised: (c) Did you report error bars (e g., with respect to the random seed after running experi-

Original: ments multiple times)?
Revised: ments multiple times)?

Original: [Yes]
Revised: [Yes]

Original: (d) Did you include the total amount of compute and the type of resources used (e.g., typeof GPUs, internal cluster, or cloud provider)?
Revised: (d) Did you include the total amount of compute and the type of resources used (e g., typeof GPUs, internal cluster, or cloud provider)?

Original: [Yes]
Revised: [Yes]

Original: If you are using existing assets (e.g., code, data, models) or curating/releasing new assets...
Revised: If you are using existing assets (e g., code, data, models) or curating/releasing new assets...

Original: (a) If your work uses existing assets, did you cite the creators?
Revised: (a) If your work uses existing assets, did you cite the creators?

Original: [N/A]
Revised: [N/A]

Original: (b) Did you mention the license of the assets?
Revised: (b) Did you mention the license of the assets?

Original: [N/A]
Revised: [N/A]

Original: (c) Did you include any new assets either in the supplemental material or as a URL?
Revised: (c) Did you include any new assets either in the supplemental material or as a URL?

Original: [Yes]
Revised: [Yes]

Original: (d) Did you discuss whether and how consent was obtained from people whose data you’re using/curating?
Revised: (d) Did you discuss whether and how consent was obtained from people whose data you’reusing/curating?

Original: [N/A]
Revised: [N/A]

Original: (e) Did you discuss whether the data you are using/curating contains personally identiﬁableinformation or offensive content?
Revised: (e) Did you discuss whether the data you are using/curating contains personally identiﬁable information or offensive content?

Original: [N/A]
Revised: [N/A]

Original: If you used crowdsourcing or conducted research with human subjects...
Revised: If you used crowdsourcing or conducted research with human subjects...

Original: (a) Did you include the full text of instructions given to participants and screenshots, if applicable?
Revised: (a) Did you include the full text of instructions given to participants and screenshots, ifapplicable?

Original: [N/A]
Revised: [N/A]

Original: (b) Did you describe any potential participant risks, with links to Institutional Review
Revised: (b) Did you describe any potential participant risks, with links to Institutional Review

Original: Board (IRB) approvals, if applicable?
Revised: Board (IRB) approvals, if applicable?

Original: [N/A](
Revised: [N/A]

Original: [Table]

Original: ) Did you include the estimated hourly wage paid to participants and the total amount
Revised: (c) Did you include the estimated hourly wage paid to participants and the total amount

Original: spent on participant compensation?
Revised: spent on participant compensation?

Original: [N/A]
Revised: [N/A]