| Internet-Draft | Underlay tunnel Programming with SRv6 | November 2022 |
| Han, et al. | Expires 25 May 2023 | [Page] |
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.¶
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 25 May 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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 [RFC2119].¶
+---------------------------------------------------------------------------+
| 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.¶
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 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 [RFC8986] either individually or in combinations. The SRH processing of the End.BXC behavior with PSP, USP, and USD is the same as [RFC8986].¶
This section provides two definitions of END.BXC.¶
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.¶
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.¶
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>.¶
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.¶
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.¶
TBD.¶
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 Endpoint Behavior Reference
---------------------------------------------------------------
TBD1 End.BXC [This.ID]
TBD2 End.BXC with PSP [This.ID]
TBD3 End.BXC with USP [This.ID]
TBD4 End.BXC with USD [This.ID]
TBD5 End.BXC with PSP, USP & USD [This.ID]
¶