Individual Submission Abhishek. Garg Internet-Draft Vivek. Joshi Intended status: Informational Ciena Expires: 5 March 2027 1 September 2026 Method to enable signaling of L2VPN services using SRv6 extensions draft-garg-l2vpn-over-srv6-02 Abstract This document describes a mechanism to provide L2VPN services using Segment Routing over IPv6 (SRv6), eliminating the need for a separate signaling protocol for VPN label distribution. In current deployments, L2VPN services rely on dedicated protocols such as the Label Distribution Protocol (LDP) or Border Gateway Protocol (BGP) for service label signaling, which adds control-plane complexity. The proposed mechanism introduces an SRv6-based extension that enables L2VPN service identification within the SRv6 framework, reducing control-plane overhead and providing a simplified and efficient solution for L2VPN service delivery. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Garg & Joshi Expires 5 March 2027 [Page 1] Internet-Draft L2VPN over SRv6 September 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 5. Detailed Mechanism . . . . . . . . . . . . . . . . . . . . . 4 5.1. End.L2VPN SID: End.DX2, End.DT2U, and End.DT2M . . . . . 4 5.2. SID Generation . . . . . . . . . . . . . . . . . . . . . 5 5.3. Signaling of L2VPN . . . . . . . . . . . . . . . . . . . 6 5.3.1. SRv6 Service Data Sub-TLV . . . . . . . . . . . . . . 8 5.3.2. SRv6 BUM Service Data Sub-TLV . . . . . . . . . . . . 9 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8.1. IS-IS TLV Codepoints Registry . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Layer 2 Virtual Private Network (L2VPN) services are widely deployed across service provider (SP) and data center (DC) networks to provide connectivity between geographically distributed sites. These services typically rely on two separate mechanisms for transport and service signaling. The transport layer is provided by protocols such as MPLS or IP, while the service label (or pseudowire identifier) is distributed using dedicated control-plane protocols such as LDP or BGP. With the evolution of networking technologies, Segment Routing over IPv6 (SRv6) has emerged as a flexible and scalable approach for traffic engineering and service delivery, as described in [RFC8402] and [RFC8986]. Garg & Joshi Expires 5 March 2027 [Page 2] Internet-Draft L2VPN over SRv6 September 2026 In parallel, network environments continue to include a mix of modern and legacy devices with varying capabilities and scalability constraints. In many deployments, lightweight L2VPN services are needed for use cases such as management traffic or small-scale data center interconnect (DCI), where existing BGP-based solutions may be overly complex. This document focuses on improving L2VPN services by introducing an SRv6 extension that carries L2VPN service identification natively, without requiring a separate service signaling protocol. 2. Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Problem Statement L2VPN services are widely deployed across SP and DC networks. Existing solutions typically require separate mechanisms for transport and service identification, resulting in additional label overhead and dependency on multiple control-plane protocols. These protocols must remain synchronized for correct operation, which increases operational complexity and may lead to service issues in case of inconsistency. Current approaches, such as Ethernet VPN (EVPN) over SRv6, reduce data-plane complexity but rely heavily on BGP, which can introduce scalability challenges, particularly on resource-constrained devices. In many deployments, lightweight L2VPN services are required for use cases such as management traffic or small-scale DCI, where existing solutions may be overly complex. Therefore, there is a need for a simplified and scalable L2VPN mechanism with reduced control-plane overhead and improved operational efficiency. 4. Proposed Solution This document proposes a simplified L2VPN mechanism based on SRv6, eliminating the need for separate signaling protocols for transport and service identification. Garg & Joshi Expires 5 March 2027 [Page 3] Internet-Draft L2VPN over SRv6 September 2026 In the proposed approach, SRv6 is used for both transport and pseudowire (PW) signaling, thereby reducing the dependency on multiple control-plane protocols. This unification simplifies service provisioning and reduces operational overhead. In a typical SRv6 deployment, an Endpoint SID (End SID) derived from an SRv6 locator is used to provide end-to-end transport connectivity. This document extends the same concept to L2VPN services by introducing SRv6 endpoint functions that represent the L2VPN service. These functions include End.DX2 for E-LINE forwarding and End.DT2U or End.DT2M for ELAN forwarding, depending on whether the traffic requires unicast or broadcast/multicast lookup. They enable both service identification and forwarding behavior within the SRv6 framework. By leveraging SRv6 for both transport and service layers, the proposed mechanism reduces control-plane complexity and avoids the need for maintaining separate label spaces or signaling protocols. 5. Detailed Mechanism Throughout this document, the term "End.L2VPN SID" is used as a generic reference to the SRv6 L2VPN endpoint SID. It refers to End.DX2, End.DT2U, or End.DT2M depending on the service type and forwarding behavior indicated by the L2VPN SRv6 Service TLV and its sub-TLVs (see Section 5.3). Readers SHOULD interpret End.L2VPN SID accordingly wherever it appears in this document. 5.1. End.L2VPN SID: End.DX2, End.DT2U, and End.DT2M The SRv6 endpoint behavior assigned to the L2VPN SID depends on the L2VPN service type, as follows: * End.DX2 (Endpoint with decapsulation and Layer-2 cross-connect), as defined in Section 4.8 of [RFC8986]: Used for E-LINE (point-to- point) services. The receiving PE decapsulates the SRv6 header and forwards the L2 payload directly to the attachment circuit associated with the specific pseudowire. This behavior is applicable when there is a single, known next-hop L2 destination. * End.DT2U (Endpoint with decapsulation and unicast MAC L2 table lookup), as defined in Section 4.10 of [RFC8986]: Used for ELAN (multipoint) services. The receiving PE decapsulates the SRv6 header and performs a unicast MAC address lookup in the L2 forwarding table associated with the VPN instance. This behavior is applicable when the destination MAC needs to be resolved from a shared L2 forwarding table. Garg & Joshi Expires 5 March 2027 [Page 4] Internet-Draft L2VPN over SRv6 September 2026 * End.DT2M (Endpoint with decapsulation and multicast MAC table lookup), as defined in [RFC8986]: Used for ELAN broadcast, unknown-unicast, and multicast (BUM) traffic. The receiving PE decapsulates the SRv6 header and performs multicast Layer-2 lookup or replication in the ELAN forwarding context. The Service-Type field in the L2VPN SRv6 Service TLV identifies the base L2VPN service model, while the SRv6 service sub-TLVs identify the exact forwarding behaviors in use. Together, these fields allow the receiving PE to correctly interpret and install the forwarding state. 5.2. SID Generation A PW-ID that is unique within an L2VPN instance is used to generate an End.L2VPN SID. In the model used by this document, the service- specific portion of the SID (the function value) is derived by combining the PW-ID with a behavior-type discriminator. This same construction is used for both E-LINE and ELAN services, so that each advertised SRv6 endpoint behavior has a distinct SID. In one example encoding, the higher-order function bits carry the PW- ID and the lower-order 4 bits carry a behavior-type value. An implementation could use behavior-type value 0x1 for End.DX2, 0x2 for End.DT2U, and 0x3 for End.DT2M. Under this model, the function value can be computed as: Function = (PW-ID << 4) | behavior-type. For example, if the Function field is 16 bits long, the lower 4 bits are used for the behavior-type discriminator and the upper 12 bits are used for the PW-ID. In that case, the usable PW-ID range is 1 through 4095. For PW-ID 11 (0xB), the resulting function values are 0xB1 for End.DX2, 0xB2 for End.DT2U, and 0xB3 for End.DT2M. Therefore, an E-LINE service that uses End.DX2 advertises a SID whose function value is 0xB1, while an ELAN service can advertise 0xB2 for End.DT2U and 0xB3 for End.DT2M. If the local locator is 2001:db8:bbbb:C::/64, the corresponding SIDs are 2001:db8:bbbb:C:B1::, 2001:db8:bbbb:C:B2::, and 2001:db8:bbbb:C:B3::. The exact encoding of the behavior-type discriminator is implementation-defined, but the resulting function values MUST be distinct for each advertised behavior associated with the same service. The resulting SID is then advertised via the mechanism described in Section 5.3. Garg & Joshi Expires 5 March 2027 [Page 5] Internet-Draft L2VPN over SRv6 September 2026 5.3. Signaling of L2VPN To signal L2VPN services, this document introduces a new IGP TLV that carries L2VPN pseudowire information. In the example described here, the signaling is carried in IS-IS. Equivalent advertisement in other IGPs is outside the scope of this document. An IS-IS LSP carries the L2VPN information in a new TLV, defined as the L2VPN SRv6 Service TLV. The TLV format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Neighbor IP Address (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encap-Type | Service-Type | Layer-2 MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SRv6 Service Data Sub-TLV (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SRv6 BUM Service Data Sub-TLV (optional, ELAN only) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ PW Interface Parameters Sub-TLV (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ PW Status Sub-TLV (optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (8 bits): The IS-IS TLV type codepoint assigned by IANA (TBD; see Section 8). Length (8 bits): The total length of the TLV value field in octets, not including the Type and Length fields. Flags (8 bits): Bit 7 (C): Control Word. When set to 1, indicates that the control word is enabled for this pseudowire. Both PEs MUST agree on the value of this bit before the pseudowire can be placed in service. Garg & Joshi Expires 5 March 2027 [Page 6] Internet-Draft L2VPN over SRv6 September 2026 Bits 6-0 (Reserved): MUST be set to zero on transmission and MUST be ignored on receipt. Reserved (8 bits): MUST be set to zero on transmission and MUST be ignored on receipt. PW-ID (32 bits): A 32-bit unsigned integer that uniquely identifies the pseudowire instance within the L2VPN domain. The value MUST be non-zero. A receiving PE MUST verify that this value matches a locally configured PW before installing any forwarding state. Neighbor IP Address (128 bits): The IPv6 loopback address of the advertising PE. A receiving PE MUST verify that this address matches the expected peer address of the locally configured pseudowire before installing forwarding state. Encap-Type (8 bits): Indicates the pseudowire encapsulation type. Values are consistent with the IANA "Pseudowire Types" registry [RFC4446]. Common values include: * 0x01: Ethernet (port mode) * 0x04: Ethernet VLAN Service-Type (8 bits): Indicates the L2VPN service type: * 0x01: E-LINE (point-to-point). The End.L2VPN SID uses End.DX2 behavior as defined in [RFC8986]. * 0x02: ELAN (multipoint). The End.L2VPN SID uses End.DT2U for unicast traffic and MAY additionally use End.DT2M for broadcast, unknown-unicast, and multicast traffic when the optional SRv6 BUM Service Data Sub-TLV is present. Other values are reserved and MUST NOT be used. Layer-2 MTU (16 bits): The maximum transmission unit of the attachment circuit in bytes. A receiving PE SHOULD verify that this value matches its locally configured MTU before installing forwarding state. Garg & Joshi Expires 5 March 2027 [Page 7] Internet-Draft L2VPN over SRv6 September 2026 SRv6 Service Data Sub-TLV: A mandatory sub-TLV carrying the End.L2VPN SID and associated SRv6 service parameters. Format is defined in Section 5.3.1. SRv6 BUM Service Data Sub-TLV (optional, ELAN only): An optional sub-TLV carrying the End.DT2M SID and associated SRv6 service parameters for ELAN BUM traffic. Format is defined in Section 5.3.2. PW Interface Parameters Sub-TLV (optional): An optional sub-TLV carrying legacy pseudowire interface parameters, encoded using the format defined in [RFC4446]. PW Status Sub-TLV (optional): An optional sub-TLV that carries pseudowire operational state, indicating whether the pseudowire is forwarding and whether attachment-circuit or PSN-facing faults have been detected. A receiving PE MUST verify that PW-ID, Neighbor IP Address, Service- Type, Encap-Type, Layer-2 MTU, and Control Word flag are consistent with the locally configured service before installing forwarding state for the remote End.L2VPN SID. If the SRv6 BUM Service Data Sub-TLV is present, the receiving PE MUST process it only for Service-Type 0x02 (ELAN). 5.3.1. SRv6 Service Data Sub-TLV The SRv6 Service Data Sub-TLV carries the End.L2VPN SID value and its associated SID structure. The format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type | Length | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRv6 SID Value (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loc-Block-Len | Loc-Node-Len | Func-Len | Arg-Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-TLV Type (8 bits): The sub-TLV type codepoint (TBD; see Section 8). Garg & Joshi Expires 5 March 2027 [Page 8] Internet-Draft L2VPN over SRv6 September 2026 Length (8 bits): The total length of the sub-TLV value field in octets, not including the Sub-TLV Type and Length fields. Endpoint Behavior (16 bits): The SRv6 endpoint behavior code for the advertised SID, taken from the IANA "SRv6 Endpoint Behaviors" registry as defined in [RFC8986]. The value MUST be consistent with the Service-Type in the enclosing L2VPN SRv6 Service TLV: * End.DX2: for E-LINE service (Service-Type 0x01) * End.DT2U: for ELAN service (Service-Type 0x02) SRv6 SID Value (128 bits): The SRv6 SID representing the End.L2VPN endpoint function on the advertising PE for the associated pseudowire. The function portion of the SID is derived from the PW-ID and behavior-type discriminator as described in Section 5.2. Loc-Block-Len (8 bits): Length in bits of the locator block portion of the SID. Loc-Node-Len (8 bits): Length in bits of the locator node ID portion of the SID. Func-Len (8 bits): Length in bits of the function portion of the SID. This portion encodes the PW-ID value. Arg-Len (8 bits): Length in bits of the argument portion of the SID. Set to zero if no argument is present. 5.3.2. SRv6 BUM Service Data Sub-TLV The SRv6 BUM Service Data Sub-TLV carries the End.DT2M SID value and associated SID structure for ELAN broadcast, unknown-unicast, and multicast traffic. This sub-TLV MUST be advertised only when Service-Type is 0x02 (ELAN). The format is as follows: Garg & Joshi Expires 5 March 2027 [Page 9] Internet-Draft L2VPN over SRv6 September 2026 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV Type | Length | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | BUM SRv6 SID Value (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loc-Block-Len | Loc-Node-Len | Func-Len | Arg-Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-TLV Type (8 bits): The sub-TLV type codepoint (TBD; see Section 8). Length (8 bits): The total length of the sub-TLV value field in octets, not including the Sub-TLV Type and Length fields. Endpoint Behavior (16 bits): The SRv6 endpoint behavior code for End.DT2M, taken from the IANA "SRv6 Endpoint Behaviors" registry as defined in [RFC8986]. BUM SRv6 SID Value (128 bits): The SRv6 SID representing the End.DT2M endpoint function on the advertising PE for ELAN BUM traffic. This SID MAY be derived from the PW-ID using the same local function construction rules as the End.DT2U SID, with a distinct behavior-type discriminator. Loc-Block-Len (8 bits): Length in bits of the locator block portion of the SID. Loc-Node-Len (8 bits): Length in bits of the locator node ID portion of the SID. Func-Len (8 bits): Length in bits of the function portion of the SID. Arg-Len (8 bits): Length in bits of the argument portion of the SID. Set to zero if no argument is present. 6. Example Consider a topology with three PE devices (PE1, PE2, PE3) connected through one P device. IS-IS and SRv6 are configured on all nodes, and PW configuration is present on the PE devices. Garg & Joshi Expires 5 March 2027 [Page 10] Internet-Draft L2VPN over SRv6 September 2026 +--------+ | PE1 | +--------+ | | +--------+ | P | +--------+ / \ / \ / \ +--------+ +--------+ | PE2 | | PE3 | +--------+ +--------+ IS-IS IPv6 and SRv6 are configured on all nodes: * PW 10 is configured between PE1 and PE2 (E-LINE, End.DX2) * PW 11 is configured between PE1 and PE3 (E-LINE, End.DX2) * PW 12 is configured between PE3 and PE2 (E-LINE, End.DX2) Node addressing: * PE1 loopback: 1::1/128, End SID locator: 2001:db8:bbbb:A::/64 * PE2 loopback: 2::2/128, End SID locator: 2001:db8:bbbb:B::/64 * PE3 loopback: 3::3/128, End SID locator: 2001:db8:bbbb:C::/64 The example below focuses on PW 11 (E-LINE) between PE1 and PE3. PE1 configuration: #L2VPN-srv6 pw-id 11 neighbor 3::3 service-type eline PE3 configuration: #L2VPN-srv6 pw-id 11 neighbor 1::1 service-type eline SID derivation: * PE1 End.DX2 SID for PW 11: 2001:db8:bbbb:A:B1:: (locator 2001:db8:bbbb:A::/64, function = 0xB1, where 0xB is the PW-ID value and 0x1 identifies End.DX2) Garg & Joshi Expires 5 March 2027 [Page 11] Internet-Draft L2VPN over SRv6 September 2026 * PE3 End.DX2 SID for PW 11: 2001:db8:bbbb:C:B1:: (locator 2001:db8:bbbb:C::/64, function = 0xB1, where 0xB is the PW-ID value and 0x1 identifies End.DX2) 6.1. Control Plane After pseudowire configuration, each PE advertises an IS-IS LSP containing an L2VPN SRv6 Service TLV for the configured PW. When PE1 receives the IS-IS update from PE3, it examines the L2VPN SRv6 Service TLV and verifies the following parameters against its local configuration: * PW-ID matches a locally configured pseudowire (PW 11) * Neighbor IP Address matches the expected peer (3::3 for PE1, 1::1 for PE3) * Service-Type, Encap-Type, Layer-2 MTU, and Control Word flag are consistent with the local service parameters If all parameters are consistent, PE1 installs PE3's End.DX2 SID 2001:db8:bbbb:C:B1:: in its SRv6 forwarding table, mapped to the PW 11 attachment circuit. The same process occurs on PE3 when it receives the matching advertisement from PE1: PE3 installs 2001:db8:bbbb:A:B1:: in its SRv6 forwarding table. 6.2. Data Plane When PE1 detects traffic on the attachment circuit for PW 11, it looks up PW 11 in its SRv6 forwarding table, retrieves PE3's End.DX2 SID 2001:db8:bbbb:C:B1::, and creates an IPv6 packet with that destination address. The L2VPN payload is encapsulated as the IPv6 payload. When the P device receives the IPv6 packet, it performs a longest- prefix match on the destination SID. Because the SRv6 locator for PE3, 2001:db8:bbbb:C::/64, is present in the forwarding table, the packet is forwarded toward PE3. When PE3 receives the packet, it matches the destination address 2001:db8:bbbb:C:B1:: against its End.DX2 SID for PW 11, decapsulates the IPv6 header, and forwards the L2 payload toward the PW 11 attachment circuit. Garg & Joshi Expires 5 March 2027 [Page 12] Internet-Draft L2VPN over SRv6 September 2026 7. Security Considerations This document introduces a new signaling element that can influence pseudowire forwarding state. Incorrect, spoofed, or unauthorized L2VPN SRv6 Service TLV advertisements could redirect traffic, blackhole traffic, or cause unintended pseudowire bindings to be installed. A receiving PE MUST validate that the advertised PW-ID, Neighbor IP Address, Service-Type, Encap-Type, Layer-2 MTU, and Control Word flag match locally provisioned state before installing any forwarding state derived from the received advertisement. Implementations and deployments SHOULD use the authentication and integrity mechanisms available for the underlying IGP carrying this information (e.g., IS-IS authentication as described in [RFC5304]). Operators SHOULD also consider the impact of stale advertisements, replayed information, and excessive service advertisements on nodes with constrained resources. 8. IANA Considerations This document requests the following allocations from IANA. 8.1. IS-IS TLV Codepoints Registry This document requests one new codepoint from the "IS-IS TLV Codepoints" registry: +=======+=============+=====+=====+=====+=======+===========+ | Value | Name | IIH | LSP | SNP | Purge | Reference | +=======+=============+=====+=====+=====+=======+===========+ | TBD | L2VPN SRv6 | No | Yes | No | No | This | | | Service TLV | | | | | document | +-------+-------------+-----+-----+-----+-------+-----------+ Table 1 The TLV carries L2VPN pseudowire service information for an SRv6-based L2VPN signaling mechanism, including PW-ID, Neighbor IP Address, End.L2VPN SID, Encap-Type, Service-Type, Layer-2 MTU, Control Word flag, and optional sub-TLVs. This document does not request any sub-TLV codepoint assignment. Such allocations MAY be defined by future documents if needed. 9. References Garg & Joshi Expires 5 March 2027 [Page 13] Internet-Draft L2VPN over SRv6 September 2026 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . 9.2. Informative References [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . Authors' Addresses Abhishek Garg Ciena Email: abhishekgarg.vip@gmail.com Vivek Joshi Ciena Email: vjoshi@ciena.com Garg & Joshi Expires 5 March 2027 [Page 14]