Abstract: A network device may receive RSVP path request messages from an upstream ingress network device, and may generate an RSVP path error message, with an overload error code and a timeout period, after the network device is online within the configured timeout period. The network device may provide the RSVP path error message to the ingress network devices to cause the ingress network devices to wait for expiration of the timeout period, after the network device is fully online, until resending the RSVP path request messages. The network device may receive new RSVP path request messages from the ingress network devices after expiration of the timeout period after the network device is fully online, and may establish, based on the new RSVP path request messages, label-switched paths from the ingress network devices.

Abstract: A network device receives an attribute identifying paths associated with an open shortest path first (OSPF) domain of a network and an intermediate system to intermediate system (ISIS) domain of the network, and provides the attribute to other network devices of the network. The network device receives traffic destined for one of the other network devices of the network, and determines that a primary path is unavailable for routing the traffic to the one of the other network devices. The network device selects a secondary path from the paths identified by the attribute. The secondary path is selected based on determining that the primary path is unavailable, and the secondary path is associated with the OSPF domain or the ISIS domain of the network. The network device provides the traffic to the one of the other network devices via the secondary path.

Abstract: Responsive to receiving the BGP UPDATE message, a route reflector may (1) update a CLUSTER_LIST value and, if needed, an ORIGINATOR_ID value, in a path attribute section in the BGP UPDATE message to generate a revised BGP UPDATE message, and (2) send the revised BGP UPDATE message to a client of the route reflector, regardless of whether or not one of (A) field validity checking of the BGP UPDATE message, (B) Adj-RIBS-In update using the BGP UPDATE message, (C) decision processing for route selection using information in the BGP UPDATE message, or (D) Adj-RIBS-Out update using the BGP UPDATE message, is completed (or perhaps even started). This provides faster route propagation and avoids delays associated with processing BGP UPDATE messages (NLRI with advertisements and withdrawals) at each hop the NLRIs using conventional BGP such as next-hop validation, best path selection, etc.

Abstract: A node of an LSP may inform the ingress node of the LSP, for example via RSVP signaling, about its temporary unavailability for a certain time. In response, the ingress node can stop using any affected LSP(s) and divert the traffic to other LSPs. This provides a faster mechanism to signal traffic shift then traditional IGP overload which causes considerable churn into the network as all the nodes need to compute the SPF. It is sufficient for ingress node to be aware of this node maintenance and it can use information to divert the traffic to other equal cost multipath (ECMP) LSP(s), or other available LSP(s). If no alternative LSP path exists when the ingress node receives such a message, a new LSP can be built during this time and traffic diverted smoothly (e.g., in a make-before-break manner) before the node goes offline for maintenance.

Abstract: Techniques are described for automatic discovery and provisioning of an IP fabric underlay network for use by an overlay network of a data center. The techniques provide mechanisms for management of the IP fabric underlay network, particularly as network devices are added to the underlay network topology for use by the overlay network. The techniques enable a control plane of a network device in the IP fabric underlay network to monitor discovery of neighbor network devices and link local addresses for the neighbor network devices. The disclosed techniques further enable a control plane of the network device to configure routing sessions between the network device and each of the discovered neighbor network devices based on the link local addresses for the neighbor network devices. The configuration of the routing sessions may include an exchange of loopback addresses for the network devices used by the overlay network.

Abstract: Responsive to receiving the BGP UPDATE message, a route reflector may (1) update a CLUSTER_LIST value and, if needed, an ORIGINATOR_ID value, in a path attribute section in the BGP UPDATE message to generate a revised BGP UPDATE message, and (2) send the revised BGP UPDATE message to a client of the route reflector, regardless of whether or not one of (A) field validity checking of the BGP UPDATE message, (B) Adj-RIBS-In update using the BGP UPDATE message, (C) decision processing for route selection using information in the BGP UPDATE message, or (D) Adj-RIBS-Out update using the BGP UPDATE message, is completed (or perhaps even started). This provides faster route propagation and avoids delays associated with processing BGP UPDATE messages (NLRI with advertisements and withdrawals) at each hop the NLRIs using conventional BGP such as next-hop validation, best path selection, etc.

Abstract: A network device receives an attribute identifying paths associated with an open shortest path first (OSPF) domain of a network and an intermediate system to intermediate system (ISIS) domain of the network, and provides the attribute to other network devices of the network. The network device receives traffic destined for one of the other network devices of the network, and determines that a primary path is unavailable for routing the traffic to the one of the other network devices. The network device selects a secondary path from the paths identified by the attribute. The secondary path is selected based on determining that the primary path is unavailable, and the secondary path is associated with the OSPF domain or the ISIS domain of the network. The network device provides the traffic to the one of the other network devices via the secondary path.

Abstract: A node of an LSP may inform the ingress node of the LSP, for example via RSVP signaling, about its temporary unavailability for a certain time. In response, the ingress node can stop using any affected LSP(s) and divert the traffic to other LSPs. This provides a faster mechanism to signal traffic shift then traditional IGP overload which causes considerable churn into the network as all the nodes need to compute the SPF. It is sufficient for ingress node to be aware of this node maintenance and it can use information to divert the traffic to other equal cost multipath (ECMP) LSP(s), or other available LSP(s). If no alternative LSP path exists when the ingress node receives such a message, a new LSP can be built during this time and traffic diverted smoothly (e.g., in a make-before-break manner) before the node goes offline for maintenance.

Abstract: A network device receives an attribute identifying paths associated with an open shortest path first (OSPF) domain of a network and an intermediate system to intermediate system (ISIS) domain of the network, and provides the attribute to other network devices of the network. The network device receives traffic destined for one of the other network devices of the network, and determines that a primary path is unavailable for routing the traffic to the one of the other network devices. The network device selects a secondary path from the paths identified by the attribute. The secondary path is selected based on determining that the primary path is unavailable, and the secondary path is associated with the OSPF domain or the ISIS domain of the network. The network device provides the traffic to the one of the other network devices via the secondary path.

Abstract: An enhanced, flooding-based routing protocol is described that provides label switched path session information. In one example, a transit router is intermediately positioned between at least two label edge routers. The transit router is configured to determine a maximum number of LSPs concurrently supported by the transit router and determine a number of LSPs concurrently established by the transit router and for which the transit router is responsible for switching packets to one or more of the two label edge routers. The transit router generates, in accordance with a link state routing protocol, a link state routing protocol message that specifies the LSP session information as the maximum number of LSP and the number of LSPs concurrently established. The transit router further transmits, to the label edge routers, the link state routing protocol message.

Abstract: In one example, a method includes receiving, by a network device, first data defining a group of LSPs, receiving second data defining one or more constraints for one or more bypass LSPs, and receiving third data defining a mapping between the group of LSPs and the one or more bypass LSPs. The method also includes, in response to receiving the third data, automatically signaling, by the network device, a bypass LSP in accordance with the one or more constraints, selecting, by the network device and based on the mapping, a respective alternate next hop for rerouting network traffic received on each LSP of the group of LSPs to the signaled bypass LSP, and programming a forwarding component of the network device to install each of the respective alternate next hops as alternate next hops to primary next hops for the LSPs of the group of LSPs.

Abstract: Techniques are described for avoiding traffic loss in a network when a designated router (DR) for a L2 broadcast communication domain loses its route toward a multicast traffic source. The disclosed techniques may be utilized in a scenario where a receiver is multi-homed to a DR network device and a non-DR network device by a L2 broadcast communication domain. Both the DR and the non-DR network devices receive a request from the receiver identifying a multicast group in which the receiver is interested. The non-DR network device monitors traffic injected into the L2 broadcast communication domain by the DR in order to determine whether the DR has lost the route to the source of the multicast group. If the DR has lost the route, the non-DR network device performs a repair by sending the multicast data traffic for the multicast group to the receiver on the L2 broadcast communication domain.

Abstract: Techniques are described for enhancements to Protocol Independent Multicast (PIM) to support multicast only fast re-route (MoFRR) over a remote loop free alternate (RLFA) backup path in a network. This disclosure describes a modified PIM control message having a new PIM message type and an additional field to indicate an address of a RLFA network device in the RLFA backup path. According to techniques of this disclosure, network devices along the RLFA backup path are configured to forward the modified PIM control message toward the RLFA network device instead of toward a source of a requested multicast group. When the RLFA network device receives the modified PIM control message, the RLFA network device is configured to forward a conventional PIM control message towards the source of the requested multicast group. In this way, PIM can be used to provide MoFRR over a RLFA backup path.

Abstract: Techniques are described for enhancements to Protocol Independent Multicast (PIM) to support multicast only fast re-route (MoFRR) over a remote loop free alternate (RLFA) backup path in a network. This disclosure describes a modified PIM control message having a new PIM message type and an additional field to indicate an address of a RLFA network device in the RLFA backup path. According to techniques of this disclosure, network devices along the RLFA backup path are configured to forward the modified PIM control message toward the RLFA network device instead of toward a source of a requested multicast group. When the RLFA network device receives the modified PIM control message, the RLFA network device is configured to forward a conventional PIM control message towards the source of the requested multicast group. In this way, PIM can be used to provide MoFRR over a RLFA backup path.

Abstract: In one example, a method includes receiving, by a network device, first data defining a group of LSPs, receiving second data defining one or more constraints for one or more bypass LSPs, and receiving third data defining a mapping between the group of LSPs and the one or more bypass LSPs. The method also includes, in response to receiving the third data, automatically signaling, by the network device, a bypass LSP in accordance with the one or more constraints, selecting, by the network device and based on the mapping, a respective alternate next hop for rerouting network traffic received on each LSP of the group of LSPs to the signaled bypass LSP, and programming a forwarding component of the network device to install each of the respective alternate next hops as alternate next hops to primary next hops for the LSPs of the group of LSPs.

Abstract: Techniques are described for enhancements to Protocol Independent Multicast (PIM) to support multicast only fast re-route (MoFRR) over a remote loop free alternate (RLFA) backup path in a network. This disclosure describes a modified PIM control message having a new PIM message type and an additional field to indicate an address of a RLFA network device in the RLFA backup path. According to techniques of this disclosure, network devices along the RLFA backup path are configured to forward the modified PIM control message toward the RLFA network device instead of toward a source of a requested multicast group. When the RLFA network device receives the modified PIM control message, the RLFA network device is configured to forward a conventional PIM control message towards the source of the requested multicast group. In this way, PIM can be used to provide MoFRR over a RLFA backup path.

Abstract: Techniques are described for enhancements to Protocol Independent Multicast (PIM) to support multicast only fast re-route (MoFRR) over a remote loop free alternate (RLFA) backup path in a network. This disclosure describes a modified PIM control message having a new PIM message type and an additional field to indicate an address of a RLFA network device in the RLFA backup path. According to techniques of this disclosure, network devices along the RLFA backup path are configured to forward the modified PIM control message toward the RLFA network device instead of toward a source of a requested multicast group. When the RLFA network device receives the modified PIM control message, the RLFA network device is configured to forward a conventional PIM control message towards the source of the requested multicast group. In this way, PIM can be used to provide MoFRR over a RLFA backup path.