Abstract: A first network device may provide a link discovery message to a second network device, and may identify a link based on the link discovery message. The first network device may provide, to the second network device, a first control channel message that identifies the link at the first network device, a current state of the link as a power on state, and a desired state of the link as a power sleep state, and may receive, from the second network device, a second control channel message that identifies the link at the second network device, the current state of the link as the power on state, and the desired state of the link as the power sleep state. The first network device may place the link in the power sleep state based on the first control channel message and the second control channel message.

Abstract: A first network device may identify one or more components to transition to a sleep state, and may power down the one or more components to cause a link with a second network device to be in a sleep state. The first network device may provide, to the second network device, a link sleep state message identifying the link, and may provide updated link sleep state messages to the second network device while the sleep state of the link is maintained.

Abstract: A first network device may create a port group for a plurality of links directly connected to a second network device, and may select the first network device as a controller network device and the second network device as a worker network device. The first network device may rank the plurality of links of the port group to generate a list of ranked links, and may select, from the list of ranked links, a highest ranked link as a control channel. The first network device may power off one or more of the plurality of links, except the control channel, based on one of a configuration, a policy, or a traffic prediction, and may identify a termination of a time period associated with powering off the one or more of the plurality of links. The first network device may power on the one or more of the plurality of links based on the termination of the time period.

Abstract: A first network device may generate a first protocol data unit (PDU) identifying a request to transition from a power on state to a power sleep state, and may provide the first PDU to a second network device. The first network device may receive a second PDU identifying a link of the second network device to transition from the power on state to the power sleep state, and may generate a third PDU identifying a link of the first network device to transition from the power on state to the power sleep state. The first network device may provide the third PDU to the second network device, and may transition the link of the first network device and the link of the second network device from the power on state to the power sleep state based on the second PDU and the third PDU.

Abstract: A device may utilize a data modeling language to generate a request to identify components of a network device and operational dependencies of the components, and may provide the request to the network device. The device may receive, based on the request, data identifying the components and the operational dependencies of the components, and may receive power consumptions by the components and power off capabilities of the components. The device may generate a model of power consumptions by the components based on the power consumptions by the components and the power off capabilities of the components, and may identify, from the components, a component capable of powering off based on the model. The device may instruct the network device to place the component in a power save state.

Abstract: A first network device may determine a power group associating a plurality of ports of the first network device with a processing component of the first network device, and may advertise the power group to a second network device. The first network device may utilize the power group with a path placement strategy to compute a path to the second network device, and may determine a traffic load associated with the first network device. The first network device may disable the plurality of ports and the processing component based on the path and the traffic load.

Abstract: A network device may receive a border gateway protocol (BGP) flow specification route associated with creation of an overlay network slice in a network, and may create a new routing instance based on the BGP flow specification route. The network device may associate interfaces defined by the BGP flow specification route with virtual private network (VPN) members, and may determine VPN parameters based on the BGP flow specification route. The network device may advertise the VPN parameters within the network to cause the network to generate the overlay network slice.

Abstract: A disclosed computing device may include (1) a storage device configured to store a database that identifies states of nodes included in a network and (2) circuitry configured to (A) receive one or more packet fragments that account for at least one change made to a state of one of the nodes in a transaction, (B) identify, among the packet fragments, a transaction identifier corresponding to the transaction and an indication of a total number of packet fragments representing the transaction, and (C) update the database to account for the change upon ensuring receipt of all the packet fragments representing the transaction based at least in part on the transaction identifier and the indication. Various other devices, systems, and methods are also disclosed.

Abstract: A network device may receive a border gateway protocol (BGP) flow specification route associated with creation of an overlay network slice in a network, and may create a new routing instance based on the BGP flow specification route. The network device may associate interfaces defined by the BGP flow specification route with virtual private network (VPN) members, and may determine VPN parameters based on the BGP flow specification route. The network device may advertise the VPN parameters within the network to cause the network to generate the overlay network slice.

Abstract: A network device may receive a border gateway protocol (BGP) flow specification route associated with creation of an overlay network slice in a network, and may create a new routing instance based on the BGP flow specification route. The network device may associate interfaces defined by the BGP flow specification route with virtual private network (VPN) members, and may determine VPN parameters based on the BGP flow specification route. The network device may advertise the VPN parameters within the network to cause the network to generate the overlay network slice.

Abstract: An ingress network device may receive a core domain network segment identifier associated with a core domain network of the multi-domain network. The ingress network device may receive location data of an egress network device associated with a second leaf domain network of the multi-domain network, wherein the location data may include data identifying the core domain network segment identifier, a second leaf domain network segment identifier associated with the second leaf domain network, and an egress network device segment identifier associated with the egress network device. The ingress network device may store the core domain network segment identifier and the location data, and may utilize the core domain segment identifier and the location data to route traffic to the egress network device.

Abstract: An example network element includes one or more interfaces and a control unit, the control unit includes one or more processors configured to determine an egress network domain identifier (ID) and determine an abstracted interdomain network topology. The one or more processors are also configured to determine one or more interdomain paths from an abstracted ingress domain node to an abstracted egress domain node and determine whether an abstracted domain node is on the one or more interdomain paths. The one or more processors are configured to, based on the abstracted domain node being on the one or more interdomain paths, include one or more resources within a network domain in a filtered traffic engineering database (TED) and compute a path from an ingress node within the ingress network domain to an egress node within the egress network domain based on the filtered TED.

Abstract: A disclosed method may include (1) receiving, at a network node within a network, a packet from another network node within the network, (2) identifying, within the packet, a slice label that indicates a network slice that has been logically partitioned on the network, (3) determining a QoS policy that corresponds to the network slice indicated by the slice label, (4) applying the QoS policy to the packet, and then upon applying the QoS policy to the packet, (5) forwarding the packet to an additional network node within the network. Various other apparatuses, systems, and methods are also disclosed.

Abstract: A network device may receive an MPLS packet destined for a destination via a label-switched path (LSP), and may determine whether to apply a first special purpose label (SPL) option or a second SPL option for a label stack of the MPLS packet. The network device may apply, when the first SPL option is determined to be applied, one of a first type of the first SPL option for the label stack via a policy data indicator (PDI) and policy data (PD), or a second type of the first SPL option for the label stack via the PDI and the PD. The network device may forward the MPLS packet to a hop of the LSP based on the first type of the first SPL option or the second type of the first SPL option applied to the MPLS packet.

Abstract: An ingress network device may receive a core domain network segment identifier associated with a core domain network of the multi-domain network. The ingress network device may receive location data of an egress network device associated with a second leaf domain network of the multi-domain network, wherein the location data may include data identifying the core domain network segment identifier, a second leaf domain network segment identifier associated with the second leaf domain network, and an egress network device segment identifier associated with the egress network device. The ingress network device may store the core domain network segment identifier and the location data, and may utilize the core domain segment identifier and the location data to route traffic to the egress network device.

Abstract: An ingress network device may receive a core domain network segment identifier associated with a core domain network of the multi-domain network. The ingress network device may receive location data of an egress network device associated with a second leaf domain network of the multi-domain network, wherein the location data may include data identifying the core domain network segment identifier, a second leaf domain network segment identifier associated with the second leaf domain network, and an egress network device segment identifier associated with the egress network device. The ingress network device may store the core domain network segment identifier and the location data, and may utilize the core domain segment identifier and the location data to route traffic to the egress network device.

Abstract: This disclosure describes techniques for scaling resources that handle, participate, and/or control routing protocol sessions. In one example, this disclosure describes a method that includes instantiating a plurality of containerized routing protocol modules, each capable of storing routing information about a network having a plurality of routers; performing network address translation to enable each of the containerized routing protocol modules to communicate with each of the plurality of routers using a public address associated with the computing system; configuring each of the containerized routing protocol modules to peer with a different subset of the plurality of routers so that each of the containerized routing protocol modules share routing information with a respective different subset of the plurality of routers; and configuring each of the containerized routing protocol modules to peer with each other to share routing information received from the different subsets of the plurality of routers.

Abstract: A tactical solution to network congestion is provided by a data forwarding device having (1) a first interface with a first link to a downstream data forwarding device and (2) second interface with a second link to a downstream data forwarding device, and executing a method comprising: (a) configuring the second interface as part of a loop-free alternate (LFA) path to a destination device, wherein the first interface is part of a shortest/preferred path to the destination device; (b) monitoring congestion at the first interface to determine whether or not the congestion exceeds a first threshold; and (c) responsive to a determination that the congestion exceeds the first threshold, forwarding at least some data addressed to the destination device, over the LFA path via the second interface instead of over the shortest/preferred path via the first interface, thereby alleviating congestion at the first interface, and otherwise, responsive to a determination that the congestion does not exceed the first threshol

Abstract: Support is provided for flexible algorithms, used by the border gateway protocol (BGP) route selection process, in the context of segment routing (SR) Prefix segment identifiers (SIDS) advertised using BGP.

Abstract: A device may identify a plurality of first values associated with network traffic of a label-switched path of a plurality of label-switched paths. The device may determine an adjustment policy based on the plurality of first values. The adjustment policy may include one or more factors associated with a plurality of second values. The plurality of second values may be determined based on the plurality of first values. The device may implement the adjustment policy in association with the label-switched path. A bandwidth reservation of the label-switched path may be adjusted based on the adjustment policy. The adjustment policy may be implemented for fewer than all of the plurality of label-switched paths.