What a Juniper MPLS solution actually includes

MPLS is often described simply as label switching, but a production network is a coordinated system of routing, label distribution, service signaling, policy and operations. In Junos, MPLS can be enabled on selected interfaces so that labeled traffic is forwarded across the core. The underlay still requires dependable IP reachability, normally provided by an interior gateway protocol such as IS-IS or OSPF. On top of that underlay, labels can be distributed or paths can be signaled using technologies such as LDP, RSVP or segment routing, subject to the capabilities of the chosen platform and software release. BGP commonly carries VPN reachability for L3VPN and other services. The resulting network can keep customer or service routing state concentrated at provider-edge devices while transit devices focus on core forwarding.

For a business buyer, this distinction matters because “MPLS support” on a data sheet does not by itself define the solution. A complete design has to answer how sites are attached, which device is the customer edge, which device is the provider edge, what the provider core knows, how routes are imported and exported, how labels are assigned, what happens when a link fails, how bandwidth classes are treated and how operations teams will verify the data plane. The hardware purchase follows those decisions rather than replacing them.

Juniper’s Junos documentation supports both MPLS-based Layer 2 and Layer 3 VPN models. Junos Layer 3 VPNs are based on the RFC 4364 BGP/MPLS model, where BGP distributes VPN routing information and MPLS carries traffic across the provider backbone. Junos also supports Layer 2 VPN services in which customer Layer 2 traffic can be transported transparently across an IP/MPLS backbone. This gives architects several ways to deliver private connectivity without forcing every application or branch into the same routing model.

Core architecture building blocks

Choose the MPLS service model before choosing the router

The service model is the first major buyer decision because it determines what state the provider edge must hold, what the customer controls and how sites communicate. A network that only needs transparent point-to-point Ethernet has different requirements from one that must carry thousands of IP routes across many isolated business units. The following options are not interchangeable labels for the same service.

Transport signaling: LDP, RSVP and SR-MPLS are different operational choices

A major architecture decision is how transport labels and paths are established. In a traditional MPLS core, LDP is often used to create label-switched forwarding that follows the IGP shortest path. This can be straightforward to understand and remains relevant in many installed networks. Its simplicity, however, does not provide the same explicit traffic-engineering behavior as an RSVP-signaled LSP or an SR-TE policy. If the main requirement is basic scalable VPN transport and the existing environment already operates LDP successfully, a migration does not need to replace it merely because newer options exist.

RSVP can signal LSPs and supports traffic-engineering concepts in Junos. It is also associated with established protection methods such as link protection and fast reroute designs. RSVP is useful where the operator wants explicit LSP control, bandwidth or constraint-aware path selection, and mature operational processes around signaled tunnels. The tradeoff is additional control-plane state and protocol operations across the network. An existing RSVP deployment may still be the right architecture when its capabilities map well to operational requirements.

SR-MPLS takes a different approach. Segment routing can express a path through segment identifiers and can reduce the need to maintain per-LSP signaling state in every transit node. Juniper’s segment-routing documentation describes SR-MPLS as capable of supporting shortest-path tunnels that can underpin services such as EVPN and L3VPN, while also enabling traffic-engineering techniques. This can simplify some core designs, but it is not a “no planning required” technology. The IGP, SID plan, label space, topology, controller strategy where used, fast-reroute behavior, migration coexistence and support matrix all need to be validated.

For a Dubai organisation with an existing MPLS estate, the best transport choice is often evolutionary. LDP, RSVP and segment routing can coexist in carefully designed migrations on supported platforms, but the coexistence plan should be tested against actual Junos versions and hardware roles. The objective is not protocol novelty; it is a transport layer that the operations team can understand, troubleshoot and recover under failure.

Traffic engineering, fast convergence and resilience

MPLS becomes especially valuable when the network operator needs more control than destination-only forwarding through the default IGP path. Traffic engineering can steer selected traffic onto paths that satisfy topology or policy constraints, protect important services from congested links, or make use of otherwise underutilised capacity. The precise method depends on the transport design: RSVP-TE and SR-TE achieve policy-controlled paths differently, and the chosen Juniper platform must support the intended feature combination.

Resilience must be engineered at more than one layer. A dual-homed customer site provides little value if both access circuits share a conduit. Two PE routers do not provide meaningful isolation if both depend on one aggregation switch or power domain. MPLS link protection can reroute around a failed link in supported RSVP designs, but end-to-end service availability also depends on IGP convergence, BGP convergence, customer-edge behavior, physical path diversity, device redundancy and the application’s tolerance for packet loss during a transition.

Four practical targets should be written into the design: which failures must be survived, what restoration interval the business expects, whether sessions are allowed to reset, and what capacity remains after the failure. “High availability” without these targets is not a testable requirement. A network may converge quickly yet still overload the surviving path. Capacity planning therefore needs both normal and failure-state calculations.

Shared Risk Link Groups can be relevant when links that appear separate in the logical topology share a real-world risk, such as the same duct, fibre route or facility. The design should model those dependencies rather than assuming two links equal two independent paths. This is particularly important for business-critical connectivity between Dubai offices, data centers, carrier points of presence and regional sites where the physical carrier path may not be obvious from a logical circuit diagram.

Selecting the Juniper platform family by network role

A solution page should not pretend that one Juniper router fits every MPLS deployment. Juniper offers routing platforms across edge, aggregation and core roles, and specific MPLS features vary by platform, line card and Junos release. The right procurement process starts with the required role and scale, then checks the current Juniper support matrix for the exact hardware and software combination.

Do not interpret these families as interchangeable. An edge router that must hold large VPN tables, terminate many services and apply complex policy is a different purchase from a transit node that mainly swaps labels at high speed. Likewise, a compact aggregation platform may have the right port count but not the feature or scale required for the intended PE role. FourTeck can map the requirement to a shortlist, after which the exact Juniper data sheet, licensing documentation and feature explorer should be checked for the proposed Junos release.

Sizing: capacity is more than interface speed

MPLS sizing should consider forwarding, control-plane scale and service scale separately. A router can have physically fast ports while still being the wrong choice for a PE role if the expected route count, VRF count, service labels, policies or convergence workload exceed the supported design. Conversely, buying the largest chassis for a modest two-site private network can add cost and operational complexity without improving the business outcome.

Start with traffic. Record sustained and peak throughput for each site, expected annual growth, east-west versus north-south patterns, backup or replication windows, real-time traffic such as voice, and the amount of traffic that must continue after a link or router failure. The requirement should state whether interface speeds are committed service rates or merely physical handoff speeds. A 10GbE interface does not mean the business needs 10 Gbit/s of forwarded application traffic, but it does affect port selection and optics.

Then size the control plane. Count IPv4 and IPv6 routes in the global table and each VPN context, BGP peers, IGP adjacencies, route-reflector relationships, routing policies, MAC routes for Ethernet services, number of LSPs or SR policies and operational telemetry. Large enterprises should include merger, cloud and regional expansion scenarios rather than sizing only for current-day steady state.

Finally, size failure conditions. If a dual-core design is expected to survive one core node or link loss, the surviving path must carry the redirected traffic without violating the performance target. This is where oversubscription assumptions need to be explicit. Capacity models that work only while every link and device is healthy are not high-availability capacity models.

Interfaces, optics, MTU and physical design

Physical interfaces are among the most common sources of avoidable procurement errors. A requirement such as “two 10G links” is incomplete until the transceiver form factor, fibre type, reach, connector, carrier handoff and redundancy arrangement are known. Juniper platforms may support multiple interface types, but the optics and cabling must be selected for the actual link budget and facility. Compatible transceivers should be treated as explicit bill-of-material items rather than assumed accessories.

MPLS also adds headers, and VPN or tunneling services may add further encapsulation. End-to-end MTU planning is therefore important. The core should be able to carry the intended labeled packet without unexpected fragmentation or drops. If Ethernet services must transparently carry customer frames, the permitted frame size and handoff MTU must be agreed. During migration, mismatched MTUs can create intermittent symptoms that appear to be routing faults but are actually data-plane size problems.

For high availability, confirm whether redundant links terminate on independent line cards, routers, power feeds and physical paths. Link aggregation can increase bandwidth and protect against some interface failures, but it does not automatically create site or path diversity. Carrier diversity should be verified at the physical level where business continuity depends on it.

Environmental and rack requirements also matter. Power feeds, rack depth, airflow direction, acoustic limitations, operating temperature, grounding and console or management access should be included in the implementation checklist. A technically correct MPLS design still fails if the selected hardware cannot be installed cleanly in the intended Dubai facility or remote equipment room.

Deployment patterns for Dubai organisations

Routing policy and VPN isolation

The value of an MPLS VPN depends on controlled separation. In L3VPN, route distinguishers allow routes from separate VPNs to remain unique, while route targets influence which VPN routes are imported and exported between routing instances. These mechanisms enable overlapping address space and flexible topologies, but they also make policy design a critical security and availability function. A route-target mistake can leak reachability between environments that were intended to remain separate.

The design should therefore define route policy in business terms before converting it to configuration. Which sites can reach shared services? Which environments are isolated? Is there a central firewall or services VRF? Are management networks reachable from every PE? Is internet access centralised or local? Are mergers or partner networks allowed to exchange only specific prefixes? These decisions should be represented as an explicit connectivity matrix.

For PE-CE routing, eBGP is common because it creates a clear administrative boundary and policy point, but static routing may be appropriate for simple sites. OSPF or other supported protocols can also be used in certain L3VPN designs. The choice affects troubleshooting, convergence, route filtering and the amount of coordination between network teams. It should not be made solely because one protocol is already familiar.

Route reflectors, if used for MP-BGP scale, should be designed for redundancy and policy clarity. Their placement affects control-plane resilience even though they are not normally in the data forwarding path. A resilient MPLS backbone therefore includes both forwarding redundancy and control-plane redundancy.

Security boundaries: MPLS isolation is not the same as encryption

Private MPLS VPN services provide traffic separation through network forwarding and routing mechanisms, but buyers should not equate that isolation with cryptographic encryption. If the risk model requires confidentiality against access to the transport network, encryption should be evaluated separately. Depending on architecture, this can mean IPsec at the customer edge, MACsec on appropriate Ethernet links, an overlay security solution or other supported methods.

Security design should also protect the routing infrastructure itself. Management access needs role-based controls, dedicated management reachability where practical, authenticated administrative sessions, configuration logging and a clear process for software updates. Routing protocol adjacencies and BGP sessions should be limited to intended peers and protected using the mechanisms supported by the selected design. The operational team should have a documented procedure for responding to route leaks, unexpected label behavior, flapping sessions and control-plane resource exhaustion.

Segmentation policy needs independent review. MPLS can create many logical networks over one backbone, which is powerful but increases the importance of consistent templates. Shared services such as DNS, identity, monitoring, backup and security inspection often need controlled reachability across multiple VPNs. Rather than broadly importing all routes, use a deliberate shared-services design with least-necessary reachability and traceable policy.

If compliance requirements apply, translate them into technical controls: encryption scope, logging retention, administrative access, change approval, redundancy, data-path location and incident evidence. The MPLS architecture can then be assessed against those controls instead of being labelled generically “secure.”

Quality of service and application treatment

MPLS networks often carry mixed traffic: interactive voice, video, transactional applications, backups, storage replication, monitoring and internet-bound traffic. Quality of service should be based on business classes rather than an excessive number of queues. The design must identify which applications require low latency or low loss, where classification occurs, how markings are trusted or rewritten, how classes map across the MPLS backbone and what happens during congestion.

A common mistake is to configure prioritisation without capacity engineering. QoS controls who is affected first when a link is congested; it does not create bandwidth. If backup traffic regularly consumes the entire inter-site path, the solution may require scheduling, rate control or more capacity in addition to queue policy. During a failure, the surviving link may carry traffic from two normal paths, so the QoS policy must also be evaluated under degraded topology.

The provider and customer marking models need agreement. If a managed service uses one class mapping and the enterprise uses another, the handoff policy should document translation. Where MPLS traffic-class bits are used within the backbone, the implementation should maintain consistent per-hop behavior across the relevant Juniper devices. Exact scheduler, classifier and rewrite support varies by platform and interface, so the design should be verified against the selected hardware.

For business applications, the useful output is a service-class table that states application examples, marking, queue treatment, bandwidth expectation and drop priority. That table can be tested during acceptance and revisited when application patterns change.

Management, telemetry and operational assurance

An MPLS network should be designed for operators who will diagnose it at 2 a.m., not only for architects who can read the initial diagram. The operational model should identify the source of truth for device inventory, interface descriptions, IP addressing, circuit IDs, VRFs, route targets, LSPs, policies and software versions. Naming conventions matter because they make cross-device troubleshooting faster and reduce mistakes in automation.

Monitoring should cover physical health, interface errors, optical levels where available, routing adjacency changes, BGP session state, VPN route counts, LSP state, label forwarding, CPU and memory, environmental alarms, traffic utilisation, loss and latency. Baselines are useful: an alarm that a route count changed is more meaningful when the expected range is known for that VPN.

Junos provides operational commands and management interfaces that can be incorporated into automation and assurance workflows. The exact management stack may include Juniper tools, standards-based telemetry, NETCONF/YANG or third-party monitoring depending on the environment. Buyers should decide whether they need only device management or broader service assurance that correlates customer services with the transport paths underneath them.

Change control is equally important. MPLS configuration often has network-wide dependencies, so a small policy change on one PE can alter reachability for many sites. Good operations use peer review, pre-change validation, configuration backups, staged rollout and post-change verification. For larger networks, automation should reduce repetitive configuration while still preserving approval and auditability.

Migration from an existing MPLS or multi-vendor network

Replacing or modernising an MPLS network is normally safer as a staged migration than as a single cutover. The first step is discovery: document the current IGP, LDP or RSVP topology, BGP sessions, VPNs, route targets, route distinguishers, customer attachments, QoS classes, MTUs, authentication, multicast dependencies, management reachability and failure behavior. Configuration files alone may not reveal undocumented business dependencies, so traffic observations and stakeholder interviews can be necessary.

A multi-vendor environment adds interoperability considerations. Standards such as RFC 4364 enable BGP/MPLS L3VPN interoperability in principle, but implementations can differ in defaults, route-policy behavior, label allocation, BGP attributes, OAM and optional features. The migration plan should identify a small, representative service for a lab or pilot, including dual-stack requirements and any unusual PE-CE protocols. Do not make the most complex customer VPN the first production test.

Transport migration can be separated from service migration. For example, an operator may first introduce new Juniper P or PE devices into the existing IGP and MPLS domain, verify label reachability, and then migrate VPN services individually. Where segment routing is a future objective, a coexistence design can be evaluated instead of forcing every site and router to change at once. The supported coexistence options must be confirmed for the exact Junos releases.

Routing policy deserves special attention during cutover. A new PE may correctly establish MP-BGP yet still import the wrong routes because route-target policy differs from the legacy configuration. Before migration, create expected route lists for each pilot VPN and compare them before and after the change. Also test the reverse path, not just ping from one direction.

Failure testing should be part of the pilot. Disconnect an access link, core link and selected peer under controlled conditions; confirm convergence, packet loss, route changes and capacity on surviving paths. If the business requires fast recovery, measure it rather than inferring it from protocol state. Verify that monitoring alarms arrive and that the operations team can identify the root cause using the planned tools.

A rollback plan should specify the decision point, configuration restore procedure, physical patching changes, routing timers and service verification needed to return to the prior state. “Restore backup” is not enough when routing adjacencies, carrier circuits and multiple devices are involved. A rehearsed rollback is part of a professional migration, not an admission that the design is uncertain.

Interoperability with carriers, firewalls, SD-WAN and cloud connectivity

Most enterprise MPLS deployments do not exist in isolation. A Dubai site may receive an MPLS handoff from a carrier, pass traffic through a firewall, connect to SD-WAN edge devices and reach cloud environments through separate private or internet connections. The design should define these boundaries explicitly so that route ownership, MTU, QoS and failover behavior are predictable.

At a carrier handoff, confirm interface speed and media, VLAN tagging, IP addressing, routing protocol, BGP autonomous-system information where relevant, route limits, communities, QoS markings, MTU, demarcation responsibility and service-level measurement. If dual carriers are used, decide whether both advertise the same routes, whether local preference or communities steer traffic, and what happens if one carrier remains up but its upstream VPN service is impaired.

Firewalls introduce another routing boundary. Decide whether the firewall participates in dynamic routing or receives static routes, whether it is inside or outside the MPLS VPN, how asymmetric paths are prevented and how security zones align with VRFs. A resilient network can unintentionally create asymmetric traffic through stateful firewalls if failover paths are not modeled.

For cloud connectivity and SD-WAN, avoid duplicated control. If SD-WAN overlays already provide segmentation and application-aware path selection, determine what MPLS must still provide underneath: private transport, predictable performance, route exchange or access to non-SD-WAN sites. The combined design should be simpler to operate than two overlapping policy systems.

Software, feature support and lifecycle decisions

MPLS feature support must be checked against the exact Juniper platform and Junos release proposed for the project. A capability that exists in Junos documentation may not be available on every model, line card or release, and some combinations can have scale or feature-interaction limitations. Procurement should therefore record the required functions first and use the current Juniper feature documentation to validate the chosen bill of materials.

Software lifecycle also affects the design. A production network should use a release strategy aligned with Juniper support guidance and the organisation’s change windows. The project plan should include image standardisation, upgrade paths, rollback methods, maintenance access and compatibility with automation or monitoring systems. If a network is being refreshed from older Junos versions, configuration syntax and default behavior should be tested rather than assumed identical.

Licensing requirements vary by product and feature bundle. Buyers should not assume that hardware purchase alone enables every advanced routing, automation or service capability. The quotation should identify any required software subscription, term, support contract or feature license for the exact proposed platform. Where license tiers exist, the design should map each required function to the tier rather than purchasing a higher level “just in case.”

Lifecycle planning should include expected service life, software support horizon, spares policy and replacement strategy. Core and provider-edge routers are infrastructure investments; selecting a platform with no headroom for a known two-year expansion can create a disruptive second migration. At the same time, excessive unused capacity can tie up budget. A growth model gives the purchase a defensible middle ground.

High-availability design beyond “two routers”

High availability is an end-to-end property. Two Juniper routers provide device redundancy only if the rest of the service path also avoids common failure points. For each critical site, map the customer-edge devices, PE routers, access circuits, provider-core paths, route reflectors, power systems, racks and upstream services. Then identify which failures are independent and which are shared.

At the access layer, dual-homing can be built with separate PE routers, routing sessions or Ethernet multihoming depending on the service. The design should define active/active versus active/standby behavior and ensure both paths have enough capacity when one fails. If BGP is used, routing policy should make the preferred path explicit and prevent accidental traffic blackholing during partial failures.

In the core, fast reroute and link or node protection can reduce traffic loss for supported MPLS transport designs. These mechanisms protect the data path, while IGP and BGP convergence restore the steady-state control plane. Timers should not be reduced blindly; aggressive timers can increase instability on poor links or overloaded devices. The target should be measured recovery that remains stable under realistic faults.

Operational redundancy matters too. Maintain configuration backups, out-of-band or resilient management where feasible, spare optics, documented replacement procedures and a tested escalation path. A router that can fail over in milliseconds is still difficult to support if the team cannot reach the surviving device or identify which physical circuit failed.

Where Juniper MPLS can fit well—and where another approach may be better

MPLS compared with common alternatives

These approaches can be complementary. A Juniper MPLS backbone can carry enterprise VPNs while SD-WAN runs at branches, and an EVPN-VXLAN data-center fabric can connect to an EVPN-MPLS or L3VPN WAN. The right architecture assigns a clear responsibility to each layer instead of using several technologies to solve the same problem.

A practical Juniper MPLS implementation journey

Common design mistakes that increase MPLS risk

Buying by port count only. Two routers with the same number of interfaces can differ materially in service scale, forwarding architecture and supported features. Start with the service and control-plane requirements, then confirm ports.

Assuming all Junos features exist on every platform. Junos is consistent in operating model, but feature availability still depends on platform and release. Validate the proposed combination against current Juniper documentation before ordering.

Ignoring MTU across labeled paths. Additional encapsulation changes packet size. A path that works for small pings can still fail for larger application traffic if the effective MTU is inconsistent.

Using route targets without a connectivity model. Route import/export should represent an approved business policy. Broadly reusing targets to make reachability “work” can create hidden cross-VPN dependencies and later security incidents.

Calling logical redundancy physical diversity. Two circuits can share fibre or a carrier facility. Request route-diversity information when business continuity requires independence.

Testing only steady state. A production-ready MPLS design must be tested under link, node and routing failures. Capacity, convergence and monitoring should be validated while the network is degraded.

Overcomplicating the protocol stack. More protocols and features do not automatically improve the network. Use LDP, RSVP, SR-MPLS, EVPN and automation where they solve defined requirements. Operational simplicity is itself a design objective.

Procurement and quotation guidance for Dubai

An accurate quotation requires more than the phrase “Juniper MPLS router.” FourTeck needs enough information to determine the device role, scale and interface mix. For each location, provide the number and speed of WAN and LAN interfaces, media type, expected throughput, current and projected route counts, VRF or service count, high-availability requirement and the preferred form factor. If the network already uses Juniper, include the current platform models and Junos versions.

For service-provider or large enterprise PE requirements, document the number of customers or business domains, attachment circuits, VPN routes, BGP peers and required Layer 2 or Layer 3 service types. State whether IPv6, multicast, EVPN, traffic engineering, segment routing or advanced protection is mandatory. If these are future requirements rather than day-one functions, identify the expected date and scale so hardware headroom can be evaluated rationally.

For optics, provide fibre type, reach, connector and remote-side interface information. If the carrier hands off copper Ethernet, that should also be stated. For redundant designs, specify whether links and devices must be physically diverse. Include rack and power constraints, especially for branches or facilities with limited depth or power capacity.

Commercial scope should separate hardware, software or subscriptions where required, support, installation, migration, configuration, testing and documentation. This makes quotations easier to compare and reduces the risk that a lower initial price excludes optics, licensing or professional services that are essential for deployment.

Frequently asked buyer questions

Acceptance testing should prove the service, not only device status

A router with all interfaces up is not proof that the MPLS service is ready. Acceptance should test each layer of the design. At the underlay, verify IGP neighbors, loopback reachability, expected metrics and failure paths. At the MPLS layer, confirm labels or segment-routing state, intended LSPs, forwarding entries and protection behavior. At the service layer, verify VPN routes, route-target imports, customer attachments and end-to-end reachability.

For L3VPN, test representative prefixes from each VRF and confirm that routes which should remain isolated are not reachable. For Layer 2 services, verify VLAN handling, MAC learning, MTU and protocol transparency required by the application. For EVPN, verify the control-plane routes and multihoming behavior relevant to the design. QoS tests should generate enough traffic to exercise congestion policy rather than only checking configuration statements.

Failure testing should include link loss, PE loss where redundancy exists, route-reflector or BGP session loss where applicable, and access-circuit failure. Record packet loss, convergence time and resulting path. Confirm that monitoring detects the event and that the operations team can distinguish a local interface failure from a remote service problem.

The final acceptance pack should include an as-built diagram, addressing plan, circuit references, configuration backups, software versions, license records, support information, test results and a known-good operational baseline. This documentation reduces risk long after the implementation team has left the project.

Planning for IPv6 and future network evolution

Even when the current customer services are mainly IPv4, a new MPLS design should explicitly address IPv6. The requirement may include IPv6 customer VPNs, IPv6 infrastructure, dual-stack management or a future IPv6 underlay. Juniper supports multiple IPv6-related MPLS and VPN capabilities, but the exact design depends on the platform and software release. Treat IPv6 as an architecture decision rather than a later configuration add-on.

Segment routing can also be part of long-term evolution. Juniper documentation describes SR-MPLS features that can support VPN services and traffic-engineered paths. Organisations with mature RSVP or LDP networks can evaluate segment routing where it reduces operational state or better aligns with controller-driven traffic engineering. A migration case should compare operational benefits, staff readiness and coexistence complexity rather than assuming new is automatically better.

Data-center evolution is another consideration. If the organisation is moving toward EVPN-VXLAN fabrics, the WAN and data-center teams should agree how routes and Ethernet services cross the boundary. EVPN-MPLS interconnect can be relevant, but an L3VPN handoff may be simpler when only routed connectivity is needed. Extending Layer 2 merely because it is technically possible can expand fault domains and complicate operations.

Future-proofing therefore means preserving useful options with measured headroom, not purchasing every possible feature. Document what is likely within the platform’s service life, confirm that the selected hardware supports those functions, and keep the current design as simple as the business allows.

Decision recap: the six choices that shape the solution

What FourTeck needs for an accurate Juniper MPLS consultation

Build the MPLS architecture before locking the bill of materials

The most reliable Juniper MPLS purchase begins with a service definition: what must connect, what must remain isolated, what scale is expected, what failures the network must survive and who will operate it. From there, FourTeck can help translate the requirement into Juniper platform roles, validated Junos features, interfaces and optics, a migration plan and a quotation that reflects the complete deployment rather than only the router chassis.