Internet DRAFT - draft-han-spring-srv6-underlay-tunnel-programming
draft-han-spring-srv6-underlay-tunnel-programming
SPRING L. Han
Internet-Draft M. Wang
Intended status: Standards Track China mobile
Expires: 16 November 2023 R. Chen
A. Liu
ZTE Corporation
15 May 2023
SRv6 Underlay tunnel Programming
draft-han-spring-srv6-underlay-tunnel-programming-03
Abstract
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.
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 16 November 2023.
Copyright Notice
Copyright (c) 2023 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.
Han, et al. Expires 16 November 2023 [Page 1]
Internet-Draft Underlay tunnel Programming with SRv6 May 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Problems and Solutions . . . . . . . . . . . . . . . . . . . 2
3.1. Problems . . . . . . . . . . . . . . . . . . . . . . . . 2
3.2. END.BXC Function . . . . . . . . . . . . . . . . . . . . 3
3.2.1. END.BXC with ARG: . . . . . . . . . . . . . . . . . . 4
3.2.2. END.BXC without ARG: . . . . . . . . . . . . . . . . 5
3.2.3. Procedures . . . . . . . . . . . . . . . . . . . . . 5
4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Deployment Status . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. 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.
2. 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 [RFC2119].
3. Problems and Solutions
3.1. Problems
Han, et al. Expires 16 November 2023 [Page 2]
Internet-Draft Underlay tunnel Programming with SRv6 May 2023
+---------------------------------------------------------------------------+
| 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 |
+---------------------------------+ +--------------------------+
Figure 1
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.
3.2. 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.
Han, et al. Expires 16 November 2023 [Page 3]
Internet-Draft Underlay tunnel Programming with SRv6 May 2023
+------------------------------------------------------------------+
| Locator | Function | ARG |
+------------------------------------------------------------------+
Figure 2
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].
End.BXC can support ARG identifying different channel types and
channel ID spaces or no ARG, it is up to the controller to decide
whether if the ARG to use.
3.2.1. END.BXC with ARG:
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 |
+------------------------------------------------+
Figure 3
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.
Han, et al. Expires 16 November 2023 [Page 4]
Internet-Draft Underlay tunnel Programming with SRv6 May 2023
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.
3.2.2. END.BXC without ARG:
In this section，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.
3.2.3. 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>.
4. 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, it can be
Han, et al. Expires 16 November 2023 [Page 5]
Internet-Draft Underlay tunnel Programming with SRv6 May 2023
more easier for scalability of diversity of underlay connections.
5. 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 field trail， and In
March 2023, China Mobile successfully validated the orchestrates end-
to-end SRv6 path (include end. BXC )functions in field 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.
6. Acknowledgements
The authors would like to thank Jianzhong Wen for valuable
suggestions.
7. 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" registry in the "Segment Routing" registry group, 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]
8. Security Considerations
TBD.
9. 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,
<https://www.rfc-editor.org/info/rfc2119>.
Han, et al. Expires 16 November 2023 [Page 6]
Internet-Draft Underlay tunnel Programming with SRv6 May 2023
[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,
<https://www.rfc-editor.org/info/rfc8986>.
Authors' Addresses
Liuyan Han
China mobile
Beijing
China
Email: hanliuyan@chinamobile.com
Minxue Wang
China mobile
Beijing
China
Email: wangminxue@chinamobile.com
Ran Chen
ZTE Corporation
Nanjing
China
Email: chen.ran@zte.com.cn
aihua Liu
ZTE Corporation
Shenzhen
China
Email: liu.aihua@zte.com.cn
Han, et al. Expires 16 November 2023 [Page 7]
