Abstract: Network interworking with no cross-domain state may be provided. First, an edge node may receive a packet from an intermediate node in a first domain. The edge node may be between the first domain and a second domain. Next, the edge node may pop, in response to a first Service Identifier (SID) in the packet, headers corresponding to the first domain from the packet. The edge node may then push, in response to the first SID, a label stack corresponding to the second domain onto the packet. The first SID may include data corresponding to the label stack. Then the edge node may route the packet to the second domain destine to an end node in the second domain.

Abstract: In one embodiment, a method by an apparatus of a Border Gateway Protocol (BGP) network includes accessing an attestation token for the apparatus. The method further includes encoding the attestation token in a BGP signaling message. The method further includes sending the BGP signaling message with the encoded attestation token to a second apparatus of the BGP network.

Abstract: In one embodiment, a network comprises a first forwarding domain using a first data plane forwarding protocol and a second forwarding domain using a second data plane forwarding protocol different than the first data forwarding plane forwarding protocol. The first forwarding domain includes a first path node and a particular border node. The second forwarding domain includes a second path node and the particular border node. The particular border node performs Segment Routing or other protocol interworking between the different data plane forwarding domains, such as for transporting packets through a different forwarding domain or translating a packet to use a different data forwarding protocol. These forwarding domains typically include Segment Routing (SR) and SR-Multiprotocol Label Switching (SR-MPLS). Paths through the network are determined by a Path Computation Engine and/or based on route advertisements such associated with Binding Segment Identifiers (BSIDs) (e.g.

Abstract: A computer network efficiently provides a multicast network flow to a multicast recipient across a multihomed network element. The multihomed network element includes network devices that receive multicast data from a source of a multicast network flow. Each particular network device that received the multicast data publishes a notification indicating that the multicast network flow is available from the particular network device. The computer network receives a subscription to the multicast network flow from a multicast recipient, and determines whether to bridge the multicast data across the multihomed network element based on a multicast configuration of the computer network. The multihomed network element provides the multicast data to the multicast recipient from at least one of the particular network devices that received the multicast data from the source of the multicast network flow.

Abstract: In a network environment using a PIM (Protocol Independent Multicast) multicast routing protocol, an Assert mechanism is implemented wherein a provider-edge (PE) device sends an Assert message on the Default MDT (multicast distribution tree) and causes selection of an Assert winner, wherein any ingress PE not selected as the Assert winner stops forwarding the data packets on the Data MDT; and the Assert winner sends periodic PIM control messages on the Default MDT to maintain the Assert state on all ingress PE routers until canceled or timed out. The Assert message is created in response to MDT Mapping from at least one other ingress PE device. The PIM control messages may contain a special bit extension which forces an RPF (reverse path forwarding) neighbor to keep pointing to the Assert winner until a PIM neighborship-down event is detected. This obviates the need for periodic Assert messaging and/or data packet punting.