Abstract: The potential problem of too many unique protocol independent multicast (PIM) joins (corresponding to unique (Source, Group) combinations) in PIM join/prune messages being received by a router may be solved by controlling (e.g., limiting) a number of unique PIM joins to be sent to the router from a downstream device. This may be accomplished, for example, by communicating a limit (or multiple different limits) from a PIM device to one or more downstream PIM neighbors. For example, the limit may be encoded in a PIM Hello message (e.g., as an Option Type-Length-Value (TLV)).

Abstract: The potential problem of sending (or resending) PIM join/prune messages (referred to as “PIM join(s)”) too infrequently may be solved by: (a) sending a PIM join, including a unique message identifier value, to an upstream PIM peer; (b) responsive to sending the PIM join, (1) starting a quick refresh timer, and (2) starting a standard refresh timer, which is longer than the quick refresh timer; (c) responsive to a determination that the quick refresh timer expired, (1) resending the PIM join to the upstream PIM peer, and (2) restarting the quick refresh timer; (d) responsive to a determination that the standard refresh timer expired, (1) resending the PIM join message to the upstream PIM peer, and (2) restarting the standard refresh timer; (e) receiving a PIM join response from the upstream PIM peer, wherein the PIM join response includes a unique message identifier value; (f) responsive to receiving the PIM join response and determining that the unique message identifier value in the PIM join response matches

Abstract: The potential problem of too many unique protocol independent multicast (PIM) joins (corresponding to unique (Source, Group) combinations) in PIM join/prune messages being received by a router may be solved by controlling (e.g., limiting) a number of unique PIM joins to be sent to the router from a downstream device. This may be accomplished, for example, by communicating a limit (or multiple different limits) from a PIM device to one or more downstream PIM neighbors. For example, the limit may be encoded in a PIM Hello message (e.g., as an Option Type-Length-Value (TLV)).

Abstract: Techniques are described for multicast flow prioritization in protocol independent multicast (PIM) networks with multicast flow limits. According to the disclosed techniques, once a router has reached its multicast flow limit, the router may preempt an installed lower priority multicast flow with a newly requested higher priority multicast flow. For example, if a maximum number of multicast flows are installed on the router, then, upon receiving a PIM join for a higher priority flow as compared to the installed flows, the router replaces one of the installed lower priority flows with the received higher priority flow. Furthermore, according to the disclosed techniques, priority values for multicast flows are consistent across a PIM domain and each of the routers within the PIM domain is configured to use the priority values to select a higher priority flow over a lower priority flow.

Abstract: Techniques are described for facilitating node protection for Broadcast, unknown Unicast, and Multicast (BUM) traffic for a multi-homed node failure. For example, multi-homed provider edge (PE) devices each advertise egress node protection labels to an ingress PE device. In the event one of the multi-homed PE devices fails, the ingress PE device sends a BUM packet including the egress node protection labels for the failed node. When an egress PE device receives the BUM packet, the egress PE device determines whether the BUM packet includes the egress node protection labels and whether the egress PE device is operating as a backup designated forwarder (DF) on an Ethernet segment identifier (ESI) for which the failed node was the DF. If the BUM packet includes the egress node protection labels and the egress PE device is operating as a backup DF, the egress PE device forwards the BUM traffic to the ESI.

Abstract: A device may store first information regarding a first pseudowire connection with a first device, wherein the first pseudowire connection provides access to an Ethernet virtual private network (EVPN) to communicate with a host device. The device may store second information regarding a second pseudowire connection with a second device, wherein the second pseudowire connection provides access to the EVPN to communicate with the host device. The device may receive a message that includes a configuration identifier and identify the configuration identifier. The device may change a first characteristic of the first pseudowire connection based on the configuration identifier. The device may change a second characteristic of the second pseudowire connection based on the configuration identifier. The device may receive data from the host device based on changing the first characteristic of the first pseudowire connection and changing the second characteristic of the second pseudowire connection.

Abstract: A device may store first information regarding a first pseudowire connection with a first device, wherein the first pseudowire connection provides access to an Ethernet virtual private network (EVPN) to communicate with a host device. The device may store second information regarding a second pseudowire connection with a second device, wherein the second pseudowire connection provides access to the EVPN to communicate with the host device. The device may receive a message that includes a configuration identifier and identify the configuration identifier. The device may change a first characteristic of the first pseudowire connection based on the configuration identifier. The device may change a second characteristic of the second pseudowire connection based on the configuration identifier. The device may receive data from the host device based on changing the first characteristic of the first pseudowire connection and changing the second characteristic of the second pseudowire connection.

Abstract: In general, techniques are described for enabling a network of network devices (or “nodes”) to provide redundant multicast streams from redundant multicast sources to an egress network node. In some examples, the egress network node (or a controller for the network) computes maximally redundant trees (MRTs) from the egress network node to a virtual proxy node virtually added to the network topology by the egress network node for redundant multicast sources of redundant multicast streams.

Abstract: In some examples, a method includes receiving, by a first ingress network device for a network, a source tree join route message from an egress network device for the network, specifying a multicast source and a multicast group, and in response to receiving the source tree join route message, determining, by the ingress network device, whether the multicast source is multi-homed to the network via the first ingress network device and a second ingress network device for the network. The method includes, in response to determining that the multicast source is not multi-homed, forwarding traffic for the multicast source on an inclusive provider tunnel without initiating setup of a selective provider tunnel to the egress network device, and in response to determining that the multicast source is multi-homed, initiating setup of a selective provider tunnel to the egress network device and terminating forwarding multicast traffic on the inclusive provider tunnel.

Abstract: Techniques are described for facilitating node protection for Broadcast, unknown Unicast, and Multicast (BUM) traffic for a multi-homed node failure. For example, multi-homed provider edge (PE) devices each advertise egress node protection labels to an ingress PE device. In the event one of the multi-homed PE devices fails, the ingress PE device sends a BUM packet including the egress node protection labels for the failed node. When an egress PE device receives the BUM packet, the egress PE device determines whether the BUM packet includes the egress node protection labels and whether the egress PE device is operating as a backup designated forwarder (DF) on an Ethernet segment identifier (ESI) for which the failed node was the DF. If the BUM packet includes the egress node protection labels and the egress PE device is operating as a backup DF, the egress PE device forwards the BUM traffic to the ESI.

Abstract: Techniques are described for facilitating node protection for Broadcast, unknown Unicast, and Multicast (BUM) traffic for a multi-homed node failure. For example, each VTEP (e.g., PE device) may advertise a protected VTEP address that indicates an IP address of a remote PE device that is to be protected in the event of a node failure. In the event a multi-homed PE device fails, the ingress PE device sends a BUM packet including the protected VTEP address for the failed node. When an egress PE device receives the BUM packet, the egress PE device determines whether the BUM packet includes the protected VTEP address and whether the egress PE device is operating as a backup designated forwarder (DF). If the BUM packet includes the protected VTEP address and the egress PE device is a backup DF, the egress PE device forwards the BUM traffic to the ESI.

Abstract: In general, techniques are described for enabling a network of network devices (or “nodes”) to provide redundant multicast streams from redundant multicast sources to an egress network node. In some examples, the egress network node (or a controller for the network) computes maximally redundant trees (MRTs) from the egress network node to a virtual proxy node virtually added to the network topology by the egress network node for redundant multicast sources of redundant multicast streams.

Abstract: A device may store first information regarding a first pseudowire connection with a first device, wherein the first pseudowire connection provides access to an Ethernet virtual private network (EVPN) to communicate with a host device. The device may store second information regarding a second pseudowire connection with a second device, wherein the second pseudowire connection provides access to the EVPN to communicate with the host device. The device may receive a message that includes a configuration identifier and identify the configuration identifier. The device may change a first characteristic of the first pseudowire connection based on the configuration identifier. The device may change a second characteristic of the second pseudowire connection based on the configuration identifier. The device may receive data from the host device based on changing the first characteristic of the first pseudowire connection and changing the second characteristic of the second pseudowire connection.

Abstract: An example method includes exchanging targeted hello messages to establish a targeted neighbor connection between a first routing device and a second routing device, wherein one of the routing devices comprises a central routing device, and wherein another one of the routing devices comprises an ingress routing device. The example method further includes processing a source-active register message that specifies a source address and an identifier that are collectively associated with a multicast stream, and wherein the source-active register message further indicates whether the multicast stream is active or withdrawn.

Abstract: In some examples, a method includes receiving, by a first ingress network device of a network, a source tree join route message from an egress network device of the network, the source tree join route message specifying a multicast source and a multicast group, and in response to receiving, by the first ingress network device, a source active auto-discovery route message from a second ingress network device of the network indicating that the second ingress network device has switched from using a shared multicast tree to using a shortest path tree to deliver multicast traffic from the multicast source, electing one of the first ingress network device or the second ingress network device as a single active forwarder for forwarding the multicast traffic received from the multicast source for the multicast group.

Abstract: In some examples, a customer edge device (CE) is configured to receive configuration data for multi-homed connectivity for a local layer 2 (L2) network with a L2 virtual private network (L2VPN) for a layer 3 (L3) network for switching L2 packet data units (PDUs) among two or more L2 networks connected to the L3 network including the local L2 network, wherein the configuration data for multi-homed connectivity configures the CE with a primary attachment circuit to a primary neighbor provider edge device (PE) for the L2VPN and with a backup attachment circuit to a backup neighbor PE for the L2VPN; and generate and send, in response to snooping a multicast join message indicating a multicast group, a control plane message via the backup attachment circuit to the backup neighbor PE for the L2VPN, wherein the control plane message is destined for the backup neighbor PE for the L2VPN.

Abstract: Techniques are described for grouping related flows using a flow attribute value indicated by a modified protocol independent multicast (PIM) join request. According to techniques of this disclosure, a network device is configured to receive, from a downstream network device, two or more first PIM join requests indicating two or more multicast groups. In response to determining that each first PIM join request of the two or more first PIM join requests indicates a common first flow attribute value, the network device is configured to select a common path. The network device is further configured to send two or more second PIM join requests indicating the two or more multicast groups to an upstream network device along the selected common path and toward the source. Each second PIM join request of the two or more second PIM join requests includes a common second flow attribute value.

Abstract: In some examples, a method includes receiving, by a first ingress network device for a network, a source tree join route message from an egress network device for the network, specifying a multicast source and a multicast group, and in response to receiving the source tree join route message, determining, by the ingress network device, whether the multicast source is multi-homed to the network via the first ingress network device and a second ingress network device for the network. The method includes, in response to determining that the multicast source is not multi-homed, forwarding traffic for the multicast source on an inclusive provider tunnel without initiating setup of a selective provider tunnel to the egress network device, and in response to determining that the multicast source is multi-homed, initiating setup of a selective provider tunnel to the egress network device and terminating forwarding multicast traffic on the inclusive provider tunnel.

Abstract: In general, the disclosure describes techniques for communicating multicast group leave requests between two or more load-balanced, multi-homed PE routers included in an Ethernet Virtual Private Network (EVPN). The techniques of the disclosure enable the two or more PE routers to synchronize IGMP state and routing information amongst one another to ensure that the one of the multi-homed PE routers elected as the designated forwarder (DF) ceases forwarding the multicast group traffic to the CE router, even if it is not the PE router that receives the IGMP leave request.

Abstract: In general, techniques are described for enabling a network of network devices (or “nodes”) to provide redundant multicast streams from redundant multicast sources to an egress network node. In some examples, the egress network node (or a controller for the network) computes maximally redundant trees (MRTs) from the egress network node to a virtual proxy node virtually added to the network topology by the egress network node for redundant multicast sources of redundant multicast streams.