Generalized SRv6 Network Programming

Segment routing (SR) is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node by inserting an ordered list of instructions, called segments. When segment routing is deployed on the IPv6 data plane, it is called SRv6 . For support of SR, a new routing header called Segment Routing Header (SRH), which contains a list of SIDs and other information, has been defined in . In use cases like Traffic Engineering, an ordered SID List with multiple SIDs is inserted into the SRH to steer packets along an explicit path. As the deployment of SRv6, some new requirements are proposed, such as SRv6 compression, transporting over SR-MPLS/MPLS and IPv4 domains. Therefore, it is necessary to consider other types of segments or sub-paths in the end-to-end SRv6 network programming. This document proposes Generalized Segment Routing over IPv6 (G-SRv6) Networking Programming, which supports to encode multiple types of Segments in a SRH, called Generalized SRH (G-SRH). These Segments can be called Generalized Segment, and the ID can be Generalized Segment Identifier (G-SID), which may include an SRv6 SID(128 bits), C-SIDs, MPLS labels, or IPv4 tunnel information. This document also defines the mechanisms of Generalized SRv6 Networking Programming and the requirements of related protocol extensions of control plane and data plane.

This document makes use of the terms defined in , and , and the reader is assumed to be familiar with that terminology. This document introduces the following terms: SRv6 SID: The 128-bit segment identifier is introduced in . It is always composed by locator, function and/or arguments. C-SRv6: Compressed SRv6 Network Programming Compressable SID: It is the 128-bit SRv6 SID which can be compressed. It is composed by Common Prefix and Compressed Segment Identifier (C-SID) and optional arguments. Common Prefix: It is the same prefix shared by multiple Compressable SIDs. C-SID: Compressed Segment Identifier . It is the remaining part of Compressable SID removing Common Prefix and arguments. The recommended length of C-SIDs is 32 bits. C-SRH: Compressed Segment Routing Header. It is the enhanced SRH used for C-SRv6. G-SRv6: Generalized SRv6 Network Programming G-SID: Generalized Segment Identifier. G-SRH: Generalized Segment Routing Header. It is the enhanced SRH used for G-SRv6. Compression G-SID: It is the G-SID for encapsulating C-SIDs. MPLS G-SID: It is the G-SID for encapsulating MPLS label stack encapsulation information. IPv4 G-SID: It is the G-SID for encapsulating IPv4 tunnel information. SRv6 Compression Sub-path: It is the path for crossing the SRv6 compression domain in the end-to-end G-SRv6 path. SR-MPLS Sub-path: It is the path for crossing the SR-MPLS domain in the end-to-end G-SRv6 path. IPv4 Tunnel Sub-path: It is the IPv4 tunnel path for crossing the IPv4 domain in the end-to-end G-SRv6 path.

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 when, and only when, they appear in all capitals, as shown here.

This section describes the requirements of G-SRv6.

The overhead of SIDs (16 bytes per SID) in SRH proposes challenges for packet processing and payload efficiency. For addressing this problem, some solutions are proposed. For example, proposes Compressed SRv6 Network programming(C-SRv6). In an SRv6 domain, the SIDs will be allocated from an address block, called SID space. For routing within an SRv6 domain, the SIDs may have the same prefix (Common Prefix). defines a compressed SID (C-SID) to carry the different part of the original SRv6 SID in the SRH. The format of a compressable SRv6 SID with 32 bit C-SID is shown in Figure 1. The argument part is specified by use cases, and it is zero by default. It is shared by the compressable SRv6 SIDs in a C-SRv6 sub-path

|<-FuncID->|<--Argument -->| |<--->| | Different part of Locator Figure 1. 32 bits C-SID in Compressable SRv6 SID ]]> In C-SRv6, the common prefix can be carried by the first SID in the IPv6 destination address, while only the C-SIDs of the original SIDs are carried in the C-SRH. In this way, the overhead of SRv6 can be reduced. C-SRv6 can reduce the overhead of SRH. But the C-SRv6 requires that all the SIDs of the SRv6 path to be the compressable SRv6 SID. The limitation causes that it does not work in the following scenarios: Scenario 1-1: In a single domain owing to the incremental deployment there will be the scenario in which some nodes can support C-SRv6 while others only support SRv6. This causes that the end-to-end SRv6 path may be composed by both SRv6 SIDs and Compressable SRv6 SIDs. In this case C-SRv6 cannot work and SRH has to be used for the SRv6 path. For example, as illustrated in Figure 2, a packet is forwarded along the path A1->A2->A3->A4->A5->A6->A7, and the SRv6 SID list is [A::1:1, A::2:1, A::3:1, A::4:1, A::5:1, A6::6:1, A::7:10]. All the nodes along the path support compression except A6. In this case, the SID list can not be compressed due to A6 does not support compression.

Scenario 1-2: In C-SRv6, Common Prefix must be designed for the Compressable SRv6 SIDs. But in the scenario of crossing multiple SRv6 domains, it is very difficult to design the unified Common Prefix. It can be easy to design its own Common Prefix in a single domain. Thus an SRv6 path crossing multiple domains may be composed by different groups of Compressable SRv6 SIDs with different Common Prefixes, and they can not be encoded in a single C-SRH. For example, as illustrated in Figure 3, , a packet is forwarded along the path A1->A2->A3->A4->B1->B2->B3->B4, and the SRv6 SID list is [A::1:1, A::2:1, A::3:1, A:4:1, B::1:1, B::2:1, B::3:1, B:4:1]. The Common Prefix of the sub-path A1->A2->A3->A4 is A and the Common Prefix of the sub-path B1->B2->B3->B4 is B. But the end-to-end SRv6 path cannot be compressed in a single C-SRH.

For addressing above problems, a mechanism of encoding SRv6 SIDs and SRv6 C-SIDs in any order in an SRH should be provided, which does not require all the nodes along the path to support SRv6 compression.

In SRv6, END.BM SID can be used for indicating an SR-MPLS Policy. Therefore, when an SRv6 packet needs to travel an SR-MPLS path, the associated END.BM SID should be encoded in the SID list. When the packet arrives at the ingress node of the SR-MPLS path, an MPLS label stack will be encapsulated to the packet according to the END.BM, and the packet will be forwarded in the SR-MPLS domain based on the MPLS labels. End.BM hides the details of the SR-MPLS path, which brings benefits on security and privacy. But it brings more network states to the intermediate nodes of the SRv6 path. Also, when operators can manage both the SRv6 networks and SR-MPLS networks, it can program an end-to-end path under specific SLA assurance. If the existing SR-MPLS path associated with END.BM can not meet the SLA requirement, then a new END.BM SID should be configured and advertised among the networks. This procedure increases the complexities of deploying services. For example, as illustrated in Figure 4, when a packet is sent from CE1 to CE3, it may choose several paths in SR-MPLS domain, which provide different SLA assurance. Therefore, state of multiple SR-MPLS paths should be maintained at the node A1 and A2. - SR-MPLS Path 1: A1->A4->A5 - SR-MPLS Path 2: A1->A2->A3->A6 - SR-MPLS Path 3: A1->A2->A3->A6->A5 - SR-MPLS Path 4: A2->A3->A6 - SR-MPLS Path 5: A2->A1->A4->A5 - SR-MPLS Path 6: A2->A1->A4->A5->A6 There will be more states of path should be maintained when the scale of SR-MPLS domain is large.

In order to program SR-MPLS sub-path more flexible and reduce the states on the intermediate nodes, a mechanism for encoding SRv6 SID and MPLS labels should be provided. In this way, the ingress node of the path can program the end-to-end path including the SRv6 sub-path and the SR-MPLS sub-path, and no state of MPLS sub-path will be maintained.

In some scenarios such as SD-WAN an SRv6 packet may cross an IPv4 domain, and the SRv6 packets will be transported by the IPv6 over IPv4 tunnel. Similar to SR-MPLS, there can be two options for indicating the IPv4 tunnel. Option A: the IPv4 tunnel binding SID in SRH Option B: the IPv4 tunnel parameters in SRH For IPv4 tunnel binding SID, the ingress node of IPv4 tunnel should maintain the states of this tunnel. For example, as illustrated in Figure 5, when a packet is sent from CE1 to CE3, it may choose several paths in the IPv4 domain. Therefore, state of multiple IPv4 tunnels should be maintained at the node A1 and A2. - IPv4 Tunnel 1: Source Address A1, Destination Address A5 - IPv4 Tunnel 2: Source Address A1, Destination Address A6 - IPv4 Tunnel 3: Source Address A2, Destination Address A5 - IPv4 Tunnel 4: Source Address A2, Destination Address A6 There will be more states of IPv4 tunnels should be maintained when the scale of the IPv4 domain is large.

The second option can be adopted to carry the IPv4 tunnel information explicitly in the SRH. At the ingress of the IPv4 tunnel, an IPv4 tunnel header will be encapsulated to the packet according to the IPv4 tunnel information in the SRH. In order to support encoding IPv4 tunnel information in SRH, new mechanisms are required.

According to the requirements described above, this document proposes Generalized SRv6, which supports to encode multiple types of Segment ID in a single SRH for an end-to-end Generalized SRv6 path that travels multiple types of networks, such as SRv6 domains, Compressed SRv6 domains, SR-MPLS domains and IPv4 domains. In order to support G-SRv6, this document proposes some enhancements of SRH. This enhanced SRH is called Generalized SRH (G-SRH). The Segments encoded in a G-SRH is called General Segments and its ID is called Generalized SID (G-SID). A G-SID is a 128 bits value, and it may contain: an SRv6 SID a compression G-SID an MPLS G-SID an IPv4 G-SID

SRv6 SID is a type of G-SID. A G-SID contains a single SRv6 SID, and does not change anything of SRv6 SID.

As per , a C-SID is a sub-set of a compressable SRv6 SID, which can be used for routing the packets in compressed SRv6 network programming. A compression G-SID shown in Figure 6 may contains several C-SIDs and optional padding. When C-SID is a 32 bits value, a compression G-SID can consist of 4 C-SIDs. If the length of C-SIDs in a G-SID is less than 128 bits, then padding is required.

An MPLS G-SID shown in Figure 7 may contains 4 MPLS Label Encapsulations, if number of MPLS Label Encapsulations is less than 4, then padding is required in G-SID for aligning with 128 bits.

In order to indicate the MPLS G-SID, this document proposes a END.M (End function with SR-MPLS path instantiation), this will be described in section 6. An MPLS G-SID appears after the END.M SID, and it can not be the last G-SID in the G-SID list.

An IPv4 G-SID shown in Figure 8 contains 128 bits IPv4 tunnel related information. The format of IPv4 G-SID is shown below.

In order to indicate the IPv4 G-SID, this document proposes a END.4 (End function with IPv4 tunnel instantiation), this will be described in section 7. The detailed encoding of IPv4 tunnel G-SID is also described in section 7. An IPv4 G-SID appears after the End.4 SID, and it can not be the last G-SID in the G-SID list.

This section describes the mechanism of G-SRv6 for crossing SRv6 Compression Domains.

The path for crossing SRv6 Compression Domain is called Compressed SRv6 sub-path. It should be encoded in any location of a G-SRH. There are following aspects should be considered in this mechanism: Compression SID indication C-SID length indication Start of C-SIDs indication End of C-SIDs indication

A new flavor can be introduced to indicate that an SRv6 SID is compressable. There are two options for the definition of the flavor: Option A: If the Compressable flavor is set for a specific SRv6 SID, it means that the SRv6 SID can be used as normal SRv6 SID and also can be used as Compressable SRv6 SID. Option B: If the Compressable flavor is set for a specific SRv6 SID, it means that the SRv6 SID can only be used as Compressable SRv6 SID. In this option, if an SRv6 SID is already allocated and the compression requirement is proposed, a new SRv6 SID has to be allocated as the Compressable SRv6 SID for the same function. Though the Option B may use more SRv6 SIDs for the purpose of compression, it has much advantages in the incremental deployment. This document recommends the Option B.

Compresable SRv6 SID can be represented as Common Prefix + C-SID+(Optional) Argument. There can be multiple options for the length of C-SID as follows: Option A: a variable length in bytes Option B: optional length such as 16/32/64 bits Option C: only one option, 32 bits Though the length of C-SID can be configured locally or advertised by protocol extensions, the different length of C-SID will increase the complexity of process of control plane and data plane which is not necessary. This document recommends Option C which is a ideal tradeoff between the compression and the enough space for node ID and SRv6 Function.

In G-SRv6, if the SID list of an SRv6 sub-path consists of a list of compressable SIDs, it can be programmed as follows: the first compressable SID indicates the start of C-SRv6 sub-path, followed by compressable G-SIDs, which includes C-SIDs and padding if the number of (32 bits) C-SIDs is less than 4 in a G-SID. The format of programmed SRv6 compression sub-path is shown in Figure 9.

Since C-SIDs and SRv6 SIDs can be encoded in any order in an SRH, a mechanism for indicating the end of compression is needed. There are mainly two options for the indication of the end of compression as follows: Option A: an EOC (End of Compression) flavor is introduced when advertise Compressable SRv6 SID. When the node determines the IPv6 destination address of SRv6 packet is the Compresable SRv6 SID with EOC flavor, meaning the associated C-SID is the last C-SID in the G-SID, and it will skip the G-SID in which the corresponding C-SID located and read the following 128-bit SRv6 SID. Option B: an EOC C-SID is introduced in the G-SID to indicate the end of the compression. The length of EOC C-SID is a 32 bits value, and the it's value can be a well-known value such as 0 or a node allocated value. If the number of C-SIDs in a Compression G-SID is less than 4, the EOC can be used as the . If there are 4 C-SIDs in the last G-SID of Compressed SRv6 sub-path, it has to insert a G-SID composed by 4 EOCs. The different options for indication of end of compression are shown in Figure 10.

The Micro SID instruction is proposed at , and it can be used for forwarding SRv6 packets by shifting the IPv6 DA. The Micro SID Carrier can be seen as a type of G-SID and can be directly used for G-SRv6 as shown in Figure 11 (a). The compressable SRv6 SID can also be used as the Micro SID and encapsulated in the Micro SID Carrier. As shown in Figure 11 (b), the first compressable SRv6 SID for the sub-path crossing SRv6 compression domain can be changed to a Micro SID carrier with the locator block and multiple uSIDs which are also C-SIDs. Therefore, multiple C-SIDs can be updated to the IPv6 DA in a single time. After shifting the Micro SIDs in IPv6 DA and if the last Micro SID is the C-SID without EOC flavor, the following multiple C-SIDs (Micro segments) in the G-SID will be updated to the IPv6 DA instead of the Micro SID carrier and the location of the C-SIDs in the G-SID is recorded. If the rest C-SIDs in the current G-SID is less than the C-SIDs should be copied to the IPv6 DA using as the Micro SID carrier in a single time, only the rest C-SIDs will be copied to the IPv6 DA. The next copy will begin with the first C-SID in the next G-SID. The end of the C-SIDs shifting is indicated by a EOC flavor C-SID. When an EOC flavor C-SID is processed, the next 128-bits G-SID will be updated to the IPv6 DA.

In this mechanism, more SRH overhead can be reduced but it also brings limitation of address planning and extra complexities. The details will be discussed in the future version.

According to the above mechanisms, the scenarios shown in the section 3.1 can be encoded as follows: Scenario 1-1: Assuming that A::1:1, A::2:1, A::3:1, A::4:1, A::5:1 are the Compressable SIDs. A::1:2, A::2:2, A::3:2, A::4:2, A::5:2 are the Compressable SIDs with EOC flavor. The programmed G-SRv6 path A1->A2->A3->A4->A5->A6->A7 is shown in Figure 12:

Scenario 1-2: The programmed G-SRv6 path A1->A2->A3->A4->B1->B2->B3->B4 is shown in Figure 13:

In reduced mode, the SID A::1:1 can be removed from the G-SRH. The mechanism of indicating the C-SIDs within the G-SID will be described in the document of G-SRH.

G-SRv6 provides the flexibility of encoding SRv6 SID and SRv6 C-SID in a single SRH, which supports to program an SRv6 path that consists of compression capable and compression incapable nodes. In this case, G-SRv6 solves the problem of SRv6 overhead with a limited effect on SRv6. Independent with SRv6: G-SRv6 does not require that the SRv6 SID Space has the common prefix for supporting compression. A new address block can be allocated for compressable SID, and the common prefix of Compressable SIDs can be configured with appropriate length. Incremental upgrade: G-SRv6 does not require to upgrade all the nodes along the path to support SRv6 compression, they can be upgraded on demand to support compression.

This section describes the protocol extension requirements.

REQ1-01: An SRv6 compression path can be represented as a G-SID list consists of a compressable SRv6 SID and Compression G-SIDs. REQ1-02: A Compression G-SID consists of at most 4 (32-bits) C-SIDs, if the number of C-SID is less than 4, then padding is required to align with 128 bits. REQ1-03: If the first Compressable SID is copied to the IPv6 DA, then the C-SIDs of the following G-SIDs should be read by the nodes along the SRv6 compression sub-path and the C-SID part in IPv6 DA should be replaced accordingly. REQ1-04: The last C-SID in the G-SIDs for the SRv6 compression sub-path should be the Compressable SRv6 SID with EOC flavor. REQ1-05: When process the Compressalbe SRv6 SID with EOC flavor in the IPv6 DA, the corresponding G-SID in the G-SRH should be skipped and the IPv6 DA should be updated by the following SRv6 SID if exists.

REQ1-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for SRv6 compression capabilities REQ1-12: ISIS/OSPF/BGP-LS/BGP extensions for advertising the Compression flavor for Compressable SIDs. REQ1-13: ISIS/OSPF/BGP-LS extensions for advertising the End-of-compression(EOC) flavor for Compressable SIDs. REQ1-14: ISIS/OSPF/BGP-LS/BGP extensions for advertising the format of Compressable SIDs. REQ1-21: BGP SRv6 Policy extensions for advertising the G-SRv6 for SRv6 compression capabilities. REQ1-22: BGP SR Policy extensions for programming a G-SRv6 path combining with Compressable SRv6 SIDs and SRv6 SIDs. REQ1-31: PCEP SRv6 Policy extensions for advertising the G-SRv6 for SRv6 compression capabilities. REQ1-32: PCEP SR Policy extension for programming a G-SRv6 path combining with Compressable SRv6 SIDs and SRv6 SIDs. REQ1-33: PCEP extensions for programming a G-SRv6 path combining with Compressable SRv6 SIDs and SRv6 SIDs.

This section describes the mechanism for encoding SRv6 SIDs and MPLS G-SID in a single G-SRH.

The path for crossing SR-MPLS domain is called SR-MPLS sub-path. It can be encoded in any location of G-SRH. There are two aspects should be considered in this mechanism: Start of MPLS G-SIDs indication End of MPLS G-SIDs indication

In order to indicate the start of MPLS G-SIDs, new SRv6 SIDs types should be defined. This document defines an SID function to indicate the start of MPLS G-SIDs, called End.M ( End with MPLS labels). An SR-MPLS sub-path can be encoded in the G-SRH as follows:

When a node processes an End.M SID, it copies the following MPLS label stack encapsulation information of SR-MPLS sub-path in the MPLS G-SIDs to the MPLS header, and set the IPv6 DA as the SRv6 SID following the last MPLS G-SID of the SR-MPLS sub-path, and then forward the packet according to the active MPLS label.

The S-bit in the MPLS label indicates the end of the MPLS label within the current MPLS G-SIDs sub-list. When the ingress node of the SR-MPLS sub-path reads the MPLS label stack encapsulation information until the Label with S-bit set. If the S-bit is set for the label encapsulation, it will skip the G-SID in which the label locates and set the IPv6 DA of the SRv6 packet as the SRv6 SID following the G-SID if exists.

According to the above mechanisms, the scenarios shown in the section 3.2 can be encoded as follows: Assuming that A::1:100 is the End.M SID allocated by the node A1 for crossing SR-MPLS domain. Label 1001, 1002, 1003, 1004, 1005 and 1006 are allocated as the node segment for A1/A2/A3/A4/A5/A6. The programmed G-SRv6 path B1->A1->A2->A3->A6->A5->B4 is shown in Figure 15:

G-SRv6 supports to program the SRv6 SID and SR-MPLS SID/MPLS label in a single G-SRH, which provides to encode the end-to-end G-SRv6 path across SRv6 domains and SR-MPLS/MPLS domains explicitly at the ingress node. However, it also brings complexities of network programming, so this document suggests to upgrade the SR-MPLS nodes to support SRv6.

This section describes the protocol extension requirements of G-SRv6 for MPLS G-SID.

REQ2-01: An MPLS path can be encoded in G-SRH as a series of G-SIDs including a 128-bit End.M SRv6 SID and a set of MPLS G-SIDs. REQ2-02: An MPLS G-SID can consist of up to 4 MPLS label/SR-MPLS SID, if the number of MPLS label/SR-MPLS SID is less than 4, padding is required to align with 128 bits. REQ2-03: An End.M SRv6 SID indicates the start of MPLS G-SID. REQ2-04: The SRv6 packet can be encapsulated with an outer MPLS header, and the MPLS header contains the MPLS labels carried by the MPLS G-SIDs. REQ2-05: When the label encapsulation with S-bit is set is read by the ingress node of the SR-MPLS sub-path, the corresponding G-SID should be skipped and the IPv6 DA should be updated by the following SRv6 SID if exists.

REQ2-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for MPLS capabilities REQ2-12: ISIS/OSPF/BGP-LS extensions for advertising the End.M SRv6 SID. REQ2-21: BGP SR Policy extensions for advertising the G-SRv6 for MPLS capabilities REQ2-22: BGP SR Policy extensions for encoding G-SID list with SRv6 SID and MPLS G-SID for G-SRv6 path. REQ2-31: PCEP SR Policy extensions for advertising the G-SRv6 for MPLS capabilities REQ2-31: PCEP SR Policy extensions for encoding G-SID list with SRv6 SID and MPLS G-SID for G-SRv6 path. REQ2-33: PCEP extensions for encoding G-SID list with SRv6 SID and MPLS G-SID for G-SRv6 path.

This section describes the mechanism of G-SRv6 for crossing IPv4 domain.

The path for crossing IPv4 domain is called IPv4 tunnel sub-path. It should be encoded in any location of G-SRH. There are two aspects should be considered in this mechanism: Start of IPv4 G-SID IPv4 G-SID encoding

In order to indicate the start of IPv4 G-SIDs, new SRv6 SIDs types should be defined. This document defines an SID function to indicate the start of IPv4 G-SIDs, called End.4( End with IPv4 tunnel). When a node processes the End.4 SID, it encapsulates an outer IPv4 tunnel header for the SRv6 packet based on the tunnel information carried by the following IPv4 G-SID, and set the IPv6 DA as the SRv6 SID following the IPv4 G-SID, and then forwards the packet according to the IPv4 DA. An IPv4 tunnel sub-path can be encoded in the G-SRH as follows:

Also, this document proposes the END.B4 (End bound to an IPv4 tunnel) SID. A End.B4 is bound to an IPv4 tunnel. When the node receives a packet with End.B4 SID, the packet should be steered into the binding IPv4 tunnel.

An IPv4 GID contains the IPv4 tunnel information including tunnel type, source IPv4 address, destination IPv4 address and tunnel parameters. Different types of IPv4 tunnels have specific parameters: IPv4 UDP tunnel: the tunnel parameters includes source port and destination port. IPv4 VXLAN tunnel: the tunnel parameters includes source port, destination port and VN ID. The detailed encapsulation formats for different types of IPv4 tunnel is out of scope of the document.

According to the above mechanisms, the scenarios shown in the section 3.3 can be encoded as follows: Assuming that A::1:200 is the End.4 SID allocated by the node A1 for crossing IPv4 domain. The programmed G-SRv6 path B1->A1->A6->B4 is shown in Figure 17:

G-SRv6 provides the capabilities for encoding IPv4 tunnel information and SRv6 SID within a single G-SRH, which brings benefits on end-to-end network programming on scenarios of packets traveling SRv6 domains and IPv4 domains. However, it also brings new complexities, so this document suggests to upgrade the IPv4 nodes to support IPv6 or SRv6.

This section describes the protocol extension requirements of G-SRv6 for IPv4 G-SID.

REQ3-01: An IPv4 tunnel can be encoded in G-SRH as series of G-SIDs including a 128 bit End.4 SRv6 SID and a set of IPv4 G-SIDs. REQ3-02: An IPv4 G-SID can consist of multiple IPv4 tunnel information, such as IPv4 source address and destination address of the tunnel endpoint. REQ3-03: An End.4 SRv6 SID indicates the start of IPv4 G-SID. REQ3-04: An End.B4 SRv6 SID indicates the IPv4 tunnel. REQ3-05: The SRv6 packet can be encapsulated with an outer IPv4 tunnel header based on the parameters in the IPv4 G-SID. REQ3-06: After the tunnel information is read by the ingress node of the IPv4 tunnel sub-path, the corresponding G-SID should be skipped and the IPv6 DA should be updated by the following SRv6 SID if exists.

REQ3-11: ISIS/OSPF/BGP-LS extensions for advertising the G-SRv6 for IPv4 capabilities REQ3-12: ISIS/OSPF/BGP-LS extensions for advertising the End.4 SRv6 SID. REQ3-13: ISIS/OSPF/BGP-LS extensions for advertising the End.B4 SRv6 SID. REQ3-21: BGP SR Policy extensions for advertising the G-SRv6 for IPv4 capabilities REQ3-22: BGP SR Policy extensions for encoding G-SID list with SRv6 SID and IPv4 G-SID for G-SRv6 path. REQ3-31: PCEP SR Policy extensions for advertising the G-SRv6 for IPv4 capabilities REQ3-31: PCEP SR Policy extensions for encoding G-SID list with SRv6 SID and IPv4 G-SID for G-SRv6 path. REQ3-33: PCEP extensions for encoding G-SID list with SRv6 SID and IPv4 G-SID for G-SRv6 path.

TBD