SRv6 Underlay tunnel Programming
Internet-Draft draft-han-spring-srv6-underlay-tunnel-programming-00
Liuyan Han
China mobile
China
hanliuyan@chinamobile.com
Minxue Wang
China mobile
China
wangminxue@chinamobile.com
Ran Chen
ZTE Corporation
Nanjing
China
chen.ran@zte.com.cn
aihua Liu
ZTE Corporation
Shenzhen
China
liu.aihua@zte.com.cn
2022
Routing
SPRING
Internet Draft
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.
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 [RFC8986].
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

     +---------------------------------------------------------------------------+
     |          E2E SRv6 Policy                                                  |
   +-+-+                             +-+-+         +-+-+                       +-+-+
   |PE1+-----------------------------+PE2|---------|PE3+-----------------------+PE4|
   +-+-+                             +-+-+         +-+-+                       +-+-+
     |                                                                           |
     +---------------------------------------------------------------------------+

	 +---------------------------------+              +--------------------------+
     |       MTN/FGU Channel           |              |      SRv6 Policy         |
   +-+-+   +--+    +--+    +--+      +-+-+          +-+-+    +--+    +--+      +-+-+
   |PE1+---+P1+----+P2+--- +P3+----->+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 [RFC8986]. An SRv6 SID cosisits of three parts: LOC:FUNCT:ARG, The format of an SRv6 SID is shown below.

     +------------------------------------------------------------------+
     |     Locator          |        Function     |         ARG         |
     +------------------------------------------------------------------+

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 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 [RFC8986]. 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.

     +------------------------------------------------+
     |channel Type|    channel ID                     |
     +------------------------------------------------+

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 [RFC8986] is replaced by the following:

S14.   Get the channel type and channel ID from the lower bit of S.
S15.   Find channel X based on channel type and channel ID
S16.   Update IPv6 DA with Segment List[Segments Left]
S17.   Forward the packet to the new destination via channel X.

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 [RFC8986] is replaced by the following:

S15  Forward the packet to the new destination via channel X.

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.
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:

	Value      Description                               Reference
    ---------------------------------------------------------------
     TBA1      End.BXC - SRv6 underlay tunnel behavior    [This.ID]

Security Considerations
TBD.
Normative References
[RFC8986]