SRv6 Underlay tunnel Programming

Introduction The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header as described in . Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines a new SRv6 Endpoint behavior which can be used for SRv6 underlay tunnel (e.g.L1 channel) Programming, called END.BXC, this behavior are used to bind an underlay tunnel.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Problems and Solutions

Problems

+PE2|--------->|PE3+----+P4+----+P5+----->+PE4| +-+-+ +--+ +--+ +--+ +-+-+ +-+-+ +--+ +--+ +-+-+ | Network A | | Network B | +---------------------------------+ +--------------------------+ ]]> Usecase1: The above Figure shows two different network domains. Network A deploy ITU-T MTN/OTN, and Network B deploy SRv6. Due to network evolution requirements, The edge nodes of the Network A are upgraded to support SRv6,but the forwarding node not upgraded. Services are running between PE1 and PE4. The operator need to deploy E2E SRv6 Policy across network A and network B. Since the forwarding nodes of Network A are not forwarded based on packet based, and it is also invisible to the end to end controller, so it cannot be programmed into the SRv6 Policy. The edge nodes of the Network A upgraded to SRv6 can be programmed into SRv6 Policy, and through the END.BXC behavior defined in this document, so E2E SRv6 can traverses the ITU-T MTN/OTN network. Usecase2: Network A deploy multiple Forwarding technology (like SRv6 and MTN, etc.), and Network B deploy SRv6. However, customers require meet some SLA (like low latency, etc.) in the network A. The E2E SRv6 Policy which programmed the SRv6 END.BXC to the segment list can meet some customer's SLA.

END.BXC Function The SID format is defined in . An SRv6 SID cosisits of three parts: LOC:FUNCT:ARG, The format of an SRv6 SID is shown below.

END.BXC is a variant of the End behavior. This is a SRv6 instantiation of a Binding SID. Any SID instance of this behavior is associated with an underlay tunnel(e.g.L1 channel). Typical types of the L1 channel include MTN, and OTN. This End.BXC SID can support the Penultimate Segment Pop (PSP) of the SRH, Ultimate Segment Pop (USP) of the SRH, and Ultimate Segment Decapsulation (USD) flavors defined in either individually or in combinations. The SRH processing of the End.BXC behavior with PSP, USP, and USD is the same as . This section provides two definitions of END.BXC.

Option 1: An SRv6 Endpoint behavior may require additional information for its processing (e.g., related to the flow or service), This information may be encoded in the ARG part of the SID as defined in . This section defines the ARG part of the END.BXC SID. The high bit part of ARG is used to encode Channel Type, and the low bit part of ARG is used to encapsulate Channel ID. The Channel is uniquely identified by channel type and channel ID. The format of ARG in END.BXC SID is shown in Figure 2.

The allocation of the Channel Type and the Channel ID are local to the SR Segment Endpoint Node instantiating this behavior. The ARG length is determined by the local configuration and is announced into the network. In addition, the Channel Type length and the Channel ID length are also locally configured and is announced into the network. The detailed protocol extension will be considered, and will be described in other documents. When N receives a packet destined to S and S is a local End.BXC SID, the line S14 from the End processing defined in is replaced by the following:

Option 2: In this option, ARG part are not be used.We only defines END.BXC SID. When N receives a packet destined to S and S is a local End.BXC SID, the line S15 from the End processing defined in is replaced by the following: The END.BXC behavior is advertised to the network. The detailed protocol extension will be considered, and will be described in other documents.

Procedures Here we will describe the data plane procedures by taking examples, and we will discuss the use-case mentioned under section 3. In Figure 1, Network A deploy ITU-T MTN/OTN, and Network B deploy SRv6. PE1,PE2,PE3 and PE4 are deployed SRv6, and PE1, P1 to p3,and PE3 are deployed ITU-T MTN/OTN. One END.BXC SID is assigned for the underlay tunnel P1 to P3, so the E2E SRv6 path is <PE1::END.BXC, PE2::END.X, PE3::END.B6, PE4::DT6>.

Benefits There are some obvious benefits by using the END.BXC function. Fisrtly, as shown from the usecases above, with the END.BXC function, it can build an end-to-end SRv6 tunnel even across an underlay connection (called channel). Using the END.BXC function, it is different with the END.X function, since the END.X just forwards to an endpoint with cross-connect to a 'layer-3 adjacency'. That would be more complicated for consistency of end-to-end SRv6 policy. Secondly, with the END.BXC function, it defines the separate underlay channel ID, this can differentiate the L3 adjacency and underlay connection ID to simplify the allocation of SID. This can also maintain a separate underlay ID namespace and reduce the number of L3 route tables. Thirdly, if we use the ARGs of the END.BXC option 1, it can be more easier for scalability of diversity of underlay connections.

Deployment Status The SRv6 END.BXC Function mechanism has been implemented by ZTE, and China Mobile has successfully completed the basic verification of this function. For example, In August 2022, China Mobile successfully validated SRv6 END.BXC Function in filed trail. The END.BXC function is used in the SPN domain to support steering SRv6 services to the highly reliable MTN Channel, realizing the coordination between the MTN Channel and the end-to-end SRv6 tunnel in the SPN domain, and meeting the SRv6 end-to-end low-latency and high-reliability service quality.

Acknowledgements TBD.

IANA Considerations The document defines a new SRv6 Endpoint behavior called End.BXC. This I-D requests the IANA to allocate, within the "SRv6 Endpoint Behaviors" sub-registry belonging to the top-level "Segment-routing with IPv6 dataplane (SRv6) Parameters" registry, the following allocations:

Security Considerations TBD.