MicroTap Segment in Segment Routing

Introduction Network operators may for various reasons benefit from the ability to tap packets at strategic locations within their respective networks. Segment routing technology offers the ability to both simplify and improve the operational experience of deploying targeted packet tapping. The tapping can be only for some random packets for monitoring purposes, so we use the term microTap and tap interchangeably in this document. The introduction and strategic placement within a SID-list of one or more microTap SIDs can signal the desire to tap traffic at targeted points within the network without the need for explicit configuration on those nodes. Consider an SR network in the following example diagram where traffic is steered along some paths by using a SID-list in the packets. For network debugging/monitoring purposes, the operator may at any time want for a certain node (e.g., R2 or R3) in the network to tap a copy of a packet to a monitor (e.g. connected to R6), while continue to forward the original packet along its path to the destination.

To make it very flexible and precise on specifying which packets to tap on what node and avoid the need to configure filters on the microTap node, a microTap SID can be inserted to the SID-list after a Node-SID (for the microTap node) or an Adjacency-SID (that leads to the microTap node). When the microTap SID becomes the current active SID, the node does the following: Replicate the packet, and send the copy to the remote monitor Pop the microTap SID off the original packet and continue forwarding There could be multiple monitors. A microTap SID is associated with a particular monitor (vs. a microTap node). In the above example, there could be another monitor attached to R5. In that case, there would be two microTap SIDs - one for the monitor attached at R5 (say microTap SID S5) and one for the monitor attached at R6 (say microTap SID S6). The monitor could be a separate server attached to an interface on R5 or R6, or could be an internal service entity on R5 or R6 (which can be viewed as connected via an internal interface). How that is done is outside the scope of this document. If S5 becomes the active SID in a packet arriving at R2, R2 will tap the packet to R5, by imposing R5's node SID label on top of S5. When the tapped copy arrives at R5, R5 knows that the packet should be sent to the internal or external monitor (because S5, which R5 advertises, becomes the active SID). Similarly, if S6 becomes the active SID in a packet arriving at R3, R3 will tap the packet to R6, by imposing R6's node SID label on top of S6. In case of SRv6, a separate IPv6 header is used to send the packet to the router to which the monitor is attached. It is possible that a monitor node itself may be on the path of a packet and need to do a tap. This is referred to as local tapping and a separate local microTapping SID is needed - a packet with that microTapping SID active is tapped to a local monitor. For comparison, when a packet was tapped by another node and the tapped copy arrives on the montior node, it is simply forwarded but not tapped to the monitor. A microTap SID is advertised by the router that hosts the monitor. It should only become the active SID in a packet arriving at the desired microTap node or the advertising/owning node. A node supporting microTap functionality advertises its ability to do so, so that incapable nodes will never see a microTap SID as the active SID in a packet. The SID-list may contain multiple microTap SIDs that may or may not be adjacent in the list. For nonadjacent microTap SIDs, different nodes will tap to the same or different monitors (depending on the value of microTap SIDs). For adjacent microTap SIDs in the list, they are likely for different monitors - for the "continue forwarding" part of the first microTap SID, the second microTap SID becomes active segment, leading to the second microTap operation.

Specification

SR-MPLS Signaling A node (e.g. R2/R3) supporting microTap function advertise its capability to other nodes. A node (e.g. R5/R6) hosting a monitor is provisioned with a microTap SID allocated from the SRGB. The microTap SID is advertised to other nodes. A microTap SID MUST be associated with only one specific monitor. If the same microTap SID value is advertised by more than one node, it MUST be treated by a receiving node as an error and ignored, and MUST NOT be used in the SID-List of a packet. SRv6 related signaling details will be added in future revisions.

OSPF Signaling This document defines a new TLV for the advertisement of a microTap SID (from a node hosting a monitor) and an existing TLV is leverged for the advertisement of tapping capability (from a microTap node).

MicroTap-SID TLV The microTap SID is advertised in a newly defined MicroTap-SID Sub-TLV that mimics the Prefix SID Sub-TLV as defined in Section 5 of :

The MicroTap-SID Sub-TLV MAY appear where a Prefix-SID Sub-TLV is included to advertises a node SID.

MicroTap Capability A new flag T in the Flags field of the Prefix/Adjacency-SID Sub-TLV indicates that a MicroTap SID is allowed to follow the prefix/adjacency SID in a packet:

ISIS Signaling ISIS signaling is similar to OSPF, as specified in the following sections.

MicroTap-SID The microTap SID is advertised in a newly defined MicroTap-SID Sub-TLV that mimics the Prefix SID Sub-TLV as defined in Section 2.1 of :

The MicroTap-SID Sub-TLV MAY appear where a Prefix-SID Sub-TLV is included to advertises a node SID.

Tapping Capability Similar to OSPF, a new flag T in the Flags field of the Prefix/Adjacency-SID Sub-TLV indicates that a MicroTap SID is allowed to follow the prefix/adjacency SID in a packet:

BGP Signaling

MicroTap-SID A new MicroTap-SID TLV is defined to advertise a microTap SID. It has the same encoding as the Label-Index TLV except with a different type. The following is copied verbatim from :

A MicroTap-SID TLV MAY be included in the BGP Prefix-SID attribute.

Tapping Capability A 'T' flag is defined for the existing Originator SRGB TLV's Flags field to indicate that the originator supports microTapping functionality. Exact bit position for the flag is to be assigned by IANA and registered in the "BGP Prefix-SID Originator SRGB TLV Flags" registry.

Controller Signaling A controller needs to know about the nodes (e.g. R2/R3) that support tapping function, and the nodes (e.g. R5/R6) hosting a monitor & relavant microTap SID. This information is advertised to the controller by the link-state routing protocols (ISIS and OSPF) or BGP-LS. The signaling for OSPF and ISIS has been covered in the previous sections of this document. This section covers signaling for BGP-LS and PCEP.

BGP-LS This document defines a new TLV for the advertisement of a microTap SID (from a node hosting a monitor) and an existing TLV is leverged for the advertisement of tapping capability (from a microTap node).

MicroTap SID The microTap SID is advertised in a newly defined MicroTap-SID TLV that mimics the Prefix SID TLV as defined in Section 2.3.1 of :

The Flags and, as an extension, the SID/Index/Label fields of this TLV are interpreted according to the respective underlying IS-IS, OSPFv2, or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI is used to determine the underlying protocol specification for parsing these fields. The MicroTap-SID TLV MAY appear where a Prefix-SID TLV advertises a node SID.

Tapping Capability The Flags of Prefix/Adjacency-SID TLV are interpreted according to the respective underlying IGP specification. The new flag T in the Flags field of the Prefix/Adjacency-SID TLV indicates that a MicroTap SID is allowed to follow the prefix/adjacency SID in a packet.

PCEP An SR-TE path consists of one or more SIDs and may contain one or more microTap SIDs. The SR-TE path information is exchanged between the PCE and PCC in ERO and RRO subobjects. The SR-ERO subobject and SR-RRO subobject defined in are used to carry a SID which can be a microTap SID.

Procedures The node hosting a monitor treats a microTap SID that it advertises as an adjacency SID. In other words, it sets up its forwarding state for the microTap SID such that packets with the microTap SID as current active SID will be sent to the monitor (after popping the microTap SID). It is the responsibility of the monitor to parse the packet (including the remaining SID-list). A node supporting microTap functionality sets up its forwarding state for each microTap SID that it receives, such that packets with the microTap SID as current active SID are processed as following: Make a copy and send it to the advertising node of the microTap SID. In case of SR-MPLS, this is done by imposing the advertising node's node SID (optionally after imposing the node SID of the microTap node so that the monitor knows the microTap node). In case of SRv6, this is done by imposing an outer IPv6 encapsulation with the destination address being the advertising node's address. Forward the original packet after popping the microTap SID If a node does not support microtapping but does recognize the microtap SID signaling, the forwarding behavior for the SID is simply pop on that node. This is to safeguard the situation in case the node received a packet with the active SID being a microtap SID. The ingress node may add microTap SIDs to the SID-list of a packet based on its monitoring/debugging needs or based on SR policies programmed from a controller. A microTap SID MUST not be placed in the SID-list after a node or adjacency SID that is for or leads to a node that does not advertise microTap capability. Otherwise, the packet with that SID-list will be discarded by the node. In case of SRv6, the microTap SID and its preceding node SID MAY be merged into a single IPv6 address in SRH: the locator part identifies the microTap SID and the function part is the 3-octet or 4-octet microTap SID.

Optional IOM header As replicated packets traverse the network from the microtap node to the monitor nodes, packet loss, packet reordering and buffering can occur. To allow packet analysis equipment that receives these replicated packets to accurately analyze the replicated packet flow, additional information is needed in the replicated packet header to recreate the original conditions of the flow. RFC9197] defines a header with data fields well suited for this purpose. IOAM includes timestamp data, indicating the arrival time the replicated packet was received at the microtap node. This timestamp can be used to reproduce accurate inter-packet gaps during packet analysis. IOAM also includes a sequence number, indicating the order of replicated packets received by the microtap node. This sequence number can be used by the packet analysis equipment to reorder packets, remove duplicated packets, and to alarm on the condition that replicated packets were lost in transit. The microTap node MAY include an IOAM header in the replicated packet with following fields: Timestamp Seconds Timestamp Fraction 64-bit sequence number It is RECOMMENDED that all nodes that perform microtap packet replication be Time of Day (ToD) synchronized via Precision Time Protocol (PTP) for the most accurate recreation of packet conditions during analysis. The added IOAM header is Edge-to-Edge Option-Type, and in addition to possible IOAM header already present when the packet arrives at the microtap node. In case of MPLS, the added IOAM header is an MPLS extension header that follows the Node SID of the node that originated the microtap SID. The extension header is followed by the original label stack and its OUL field (Original Upper Layer protocol type) MUST be set to MPLS. In other words, there may be two label stacks in the packet arriving at the node hosting the monitoring station. If MTU is a concern, the original label stack (except the microTap SID) and extension headers MAY be removed.

MicroTapping with SRv6 introduced the concepts of Global Identifiers Block (GIB) for the pool of Compressed SID (C-SID) values available for global allocation and Local Identifiers Block (LIB) for the pool of C-SID values available for local allocation. This document extends the GIB/LIB concepts to traditional non-compressed full SRv6 SID as well. A Global ID can be allocated from the the GIB and used as C-SID or to construct non-compressed SRv6 SIDs. Each monitor node MUST advertise a GIB ID for other microTapping nodes to tap traffic to this monitor node. If the monitor node may be on the normal forwarding path of packets and need to tap locally, it MUST also advertises a LIB ID. This GID ID or LIB ID is referred to as the Tapping ID (TID), and is used by relevant nodes to construct an uncompressed full microTapping SID or as a C-SID for microTapping purposes, as explained below.

ISIS Signaling A new flag bit, the T-flag, is defined for the Flags field of the locator entry in the SRv6 Locator TLV :

For the SRv6 End SID sub-TLV, two new Endpoint Behaviors are defined for global microTapping End.TAP (by a tapping node to a monitor via a monitnor node) or local microTapping End.TAP.X (by a monitor node to its local monitor) respectively. Each is advertised by the monitor node with a 128-bit End SID in the LB:LN:FUNC:ARG format where the FUNC bits encode the GIB/LIB TID respectively. An SRv6 SID Structure sub-sub-TLV MUST be included to identify the FUNC bits. The monitor node M installs an IPv6 route LB:LN:GIB-TID::/prefixLength with the End.TAP endpoint behavior for a monitor node and an IPv6 route LB:LN:LIB-TID::/prefixLength with the End.TAP.X endpoint behavior for a monitor node. When a node N supporting microTapping receives an End.TAP SID advertised by a monitor node M, for each locator that N advertises with the T-flag, N installs an IPv6 route locator:TID::/prefixLength with the End.TAP behavior for a microTapping node, where the prefixLength is (LBL+LNL+FL). . In the uncompressed SID case, the locator:TID:: is a SID that an ingress node can insert to instruct N to microTap to M. In the C-SID case, the TID is a C-SID that can follow any locator C-SID that is advertised with the T-flag. When a node N receives an End.TAP.X SID advertised by a monitor node M, it does not install any corresponding forwarding state, except that it notes that the LIB TID in the End.TAP.X SID can be used as C-SID or to construct non-compressed SRv6 SIDs that can be inserted in to the SID list of a packet to instruct M to do local microTapping. If the End.TAP or End.TAP.X SID is advertised with FlexAlgo 0, it MAY be used together with locators of any FlexAlgo if the locator has the T-flag set. Otherwise, it MUST only be used together with locators of corresponding FlexAlgo that has the T-flag set.

OSPFv3 Signaling To be added.

End.TAP (Full SID) Endpoint Behavior If a node N receives a packet whose IPv6 DA D matches a route with the End.TAP endpoint behavior, N does:

End.TAP.X (Full SID) Endpoint Behavior This is for a monitor node to tap a packet to its local monitor. If a node N receives a packet whose IPv6 DA D matches a route with the End.TAP.X endpoint behavior, N does:

End.TAP (C-SID) Endpoint Behavior When the microTap node N receives a packet whose IPv6 DA matches a route with the End.TAP endpoint behavior, N does:

End.TAP.X (C-SID) Endpoint Behavior This is for a monitor node to tap a packet to its local monitor. If a node N receives a packet whose IPv6 DA D matches a route with the End.TAP.X endpoint behavior, N does:

Security Considerations To be added.

IANA Assignments To be added.

Contributors The following also contributed to this document:

Appendix A: MicroTap Use Cases This appendix provides example use cases for MicroTap with SRv6 uSID using the F3216 format (32-bit uSID Block + 16-bit uSID). In this format, the Locator length L=48, leaving 16 bits for the first uSID, and up to 6 × 16-bit uSIDs per container (one IPv6 DA). Normative Note on SID Structure Advertisement: Per RFC 9352 §9 (IS-IS), RFC 9513 §10 (OSPFv3), and RFC 9514 §8 (BGP-LS), every SRv6 SID advertisement SHOULD include the SID Structure sub-TLV (or sub-sub-TLV) to indicate the exact split of LB/LN/FUNC/ARG bits. For domains using F3216, the values are: LB Length = 32 bits LN Length = 16 bits Function Length = 16 bits Argument Length = 0 bits This ensures that receivers parse each 16-bit uSID correctly as one CSID, and that addresses like …:200:050c:300:050c:4:: are unambiguous.

A.1 Use Case 1: Multiple Tapping Nodes with Single Monitor

A.1.1 Scenario Description In this use case, multiple tapping nodes (R2 and R3) are configured to tap traffic to the same monitor node (R5/Monitor-1) using the same Tapping ID (TID). This scenario is useful when network operators want to collect traffic samples from multiple strategic points in the network for centralized analysis.

A.1.2 Network Topology Src ---- R1 ---- R2 ---- R3 ---- R4 ---- Dst | | | | R5 ---- R6 Monitor-1

A.1.3 Configuration Details Monitor Node (R5) Configuration: - Allocates Tapping ID (TID): 0x050c - Advertises End.TAP behavior with GIB-TID 0x050c (Include the SRv6 SID Structure so sources can compress this SID; see RFC 9800 §9.1/§10.) - Installs route: 2001:cafe:500:050c::/64 with End.TAP behavior Tapping Nodes (R2 & R3) Configuration: - Both nodes advertise locators with T-flag set - R2: 2001:cafe:200::/48 with T-flag - R3: 2001:cafe:300::/48 with T-flag - Both nodes install routes for the same TID: - R2: 2001:cafe:200:050c::/64 with End.TAP behavior - R3: 2001:cafe:300:050c::/64 with End.TAP behavior

A.1.4 Packet Flow Analysis Initial Packet from R1: IPv6 Header: SA: 2001::1 DA: <LB>:200:050c:300:050c:4:: Payload: IPv4 SA=A.A.A.A, DA=B.B.B.B At R2 (First Tapping Node): 1. R2 processes the End.TAP C-SID (050c) 2. Duplicates the packet for monitoring 3. For the replicated packet: - Performs H.encap behavior (RFC 8986) - Creates new IPv6 header with monitor destination - Encapsulates original packet with full context - Sends to monitor: DA=<LB>:500:050c 4. For the original packet: - Advance to the next 16-bit uSID per RFC 9800 NEXT-uSID procedure (advance to next uSID) - Continues forwarding: DA becomes <LB>:300:060c:4:: At R3 (Second Tapping Node): 1. R3 processes the End.TAP C-SID (060c) 2. Duplicates the packet for monitoring 3. For the replicated packet: - Performs H.encap behavior (RFC 8986) - Creates new IPv6 header with monitor destination - Encapsulates original packet with full context - Sends to monitor: DA=<LB>:500:050c 4. For the original packet: - Advance to the next 16-bit uSID per RFC 9800 NEXT-uSID procedure (advance to next uSID) - Continues forwarding: DA=<LB>:4:: At Monitor Node (R5): - Receives tapped packets from both R2 and R3 - Processes End.TAP behavior, the outer IPv6 header is removed, leaving the original inner IPv6/SRH stack intact, and forwards the original packet (or metadata) to the local monitor.

A.2 Use Case 2: Local Monitor with End.TAP.X

A.2.1 Scenario Description In this use case, a node (R2) performs local tapping using the End.TAP.X behavior. The tapped traffic is sent directly to a local monitor without traversing the network to a remote monitoring node. This is ideal for real-time analysis or when network bandwidth to remote monitors is limited.

A.2.2 Network Topology Src ---- R1 ---- R2 ---- R3 ---- R4 ---- Dst | Local Monitor

A.2.3 Configuration Details Local Monitor Node (R2) Configuration: - Allocates Local Tapping ID (TID): 0x0d (from LIB) - Advertises End.TAP.X behavior with LIB-TID 0x0d - Locator: 2001:cafe:200::/48 with T-flag - Local monitor address: 2001:1:1:1::1 - Installs route: 2001:cafe:200:0d::/64 with End.TAP.X behavior

A.2.4 Packet Flow Analysis Initial Packet from R1: IPv6 Header: SA: 2001::1 DA: <LB>:200:0d:4:: Payload: IPv4 SA=A.A.A.A, DA=B.B.B.B At R2 (Local Tapping and Monitor Node): 1. R2 processes the End.TAP.X C-SID (0x0d) 2. Duplicates the packet for local monitoring 3. For the replicated packet: - Transmits directly to local monitor (no H.Insert) - No network traversal required 4. For the original packet: - Advance to the next 16-bit uSID per RFC 9800 NEXT-uSID procedure (advance to next uSID) - Continues forwarding: DA=<LB>:4::

A.3 Use Case 3: Single Tapping Node with Multiple Monitors

A.3.1 Scenario Description In this use case, a single tapping node (R2) is configured to tap traffic to multiple monitor nodes (R5 and R6) simultaneously. This scenario is particularly useful when different types of analysis are required or when traffic needs to be distributed across multiple monitoring systems for load balancing or specialized processing.

A.3.2 Network Topology Src ---- R1 ---- R2 ---- R3 ---- R4 ---- Dst | |---- R5 ---- Monitor-1 | |---- R6 ---- Monitor-2

A.3.3 Configuration Details Monitor Node R5 Configuration: - Allocates Tapping ID (TID): 0x050c - Advertises End.TAP behavior with GIB-TID 0x050c (Include the SRv6 SID Structure so sources can compress this SID; see RFC 9800 §9.1/§10.) - Locator: 2001:cafe:500::/48 - Installs route: 2001:cafe:500:050c::/64 with End.TAP behavior - Monitor address: 2001:1:1:1::1 Monitor Node R6 Configuration: - Allocates Tapping ID (TID): 0x060c - Advertises End.TAP behavior with GIB-TID 0x060c (Include the SRv6 SID Structure so sources can compress this SID; see RFC 9800 §9.1/§10.) - Locator: 2001:cafe:600::/48 - Installs route: 2001:cafe:600:060c::/64 with End.TAP behavior - Monitor address: 2001:1:1:2::1 Tapping Node R2 Configuration: - Advertises locator with T-flag set: 2001:cafe:200::/48 - Installs routes for both TIDs: - 2001:cafe:200:050c::/64 with End.TAP behavior (for R5) - 2001:cafe:200:060c::/64 with End.TAP behavior (for R6)

A.3.4 Packet Flow Analysis Because the two MicroTap CSIDs are adjacent, R2 will execute two replicate-and-forward actions before advancing the original. Initial Packet from R1: IPv6 Header: SA: 2001::1 DA: <LB>:200:050c:060c:4:: Payload: IPv4 SA=A.A.A.A, DA=B.B.B.B At R2 (Tapping Node with Multiple Monitors): 1. R2 processes the first End.TAP C-SID (050c) 2. Creates first duplicated packet (Dup-P1) for R5: - Performs H.encap behavior (RFC 8986) with (500:050c) - Creates new IPv6 header with monitor destination - Encapsulates original packet with full context - Sends to R5: DA=<LB>:500:050c Creates second duplicated packet (Dup-P2) for R6: Performs H.encap behavior (RFC 8986) with (600:060c) Creates new IPv6 header with monitor destination Encapsulates original packet with full context Sends to R6: DA=<LB>:600:060c For the original packet: Advance to the next 16-bit uSID per RFC 9800 NEXT-uSID procedure (advance to next uSID) Continues forwarding: DA=<LB>:4:: At R5 (Monitor Node 1): - Receives tapped packet from R2 - Processes End.TAP behavior, removes the outer encapsulation (H.encap), and forwards the original packet (or metadata) to the local monitoring process at 2001:1:1:1::1 At R6 (Monitor Node 2): - Receives tapped packet from R2 - Processes End.TAP behavior, removes the outer encapsulation (H.encap), and forwards the original packet (or metadata) to the local monitoring process at 2001:1:1:2::1

A.4 Use Case Combinations and Real-World Deployments

A.4.1 Combining Multiple Use Cases The three use cases described above can be combined in real-world network deployments to create comprehensive monitoring solutions: Hybrid Deployment Example: Src ---- R1 ---- R2 ---- R3 ---- R4 ---- Dst | | | |---- R6 ---- Monitor-2 | |---- R5 ---- Monitor-1 | Local Monitor In this scenario: - R2 performs local tapping (Use Case 2) to its local monitor - R2 also taps to R5 (Use Case 3 - multiple monitors) - R3 taps to R6 (Use Case 1 - single monitor) - R5 can receive traffic from multiple sources (Use Case 1)