| SPRING WG | W. Cheng |
| Internet-Draft | China Mobile |
| Intended status: Informational | C. Xie |
| Expires: September 9, 2020 | China Telecom |
| R. Pang | |
| China Unicom | |
| Z. Li | |
| Huawei Technologies | |
| R. Chen | |
| ZTE Corporation | |
| L. Zu | |
| Unionpay | |
| X. Duan | |
| China Mobile | |
| G. Mirsky | |
| ZTE Corporation | |
| March 8, 2020 |
Shorter SRv6 SID Requirements
draft-cheng-spring-shorter-srv6-sid-requirement-01
This document describes a list of requirements for the use of a shortened identifier in a segment routing network with the IPv6 data plane.
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 September 9, 2020.
Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Segment routing (SR) [RFC8402] 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.
A segment can be encoded as a Multi-Protocol Label Switching (MPLS) label, IPv4 address（确定吗）, or IPv6 address. Segment Routing can be deployed on the MPLS data plane by encoding 32-bits SIDs in MPLS label stack [RFC8660]. It also can be deployed on the IPv6 data plane by encoding a list of 128-bits SRv6 SIDs in IPv6 Segment Routing Extension Header (SRH)[I-D.ietf-6man-segment-routing-header].
The SRv6 Network Programming [I-D.ietf-spring-srv6-network-programming] specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.
However, the size of the SRv6 SID presents a scalabilities challenge to use topological instructions that define a strict explicitly routed path in combination with service-based instructions. At the same time, the size of the SRH/SID may be a challenge for some data plane processors and traffic overhead. Meanwhile, SR-MPLS currently, more often than SRv6, is used in metro networks. With the gradual deployment of SRv6 in the core networks, it becomes necessary to support interworking between SR-MPLS and SRv6 and upgrading to SRv6 from SR-MPLS. It requires some solutions to resolve these problems.
SR: Segment Routing
SRH: Segment Routing Extension Header
MPLS: Multiprotocol Label Switching
SR-MPLS: Segment Routing over MPLS data plane
SID: Segment Identifier
SRv6: Segment Routing over IPv6
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
At present, only typical application scenarios are discussed, and other scenarios will be considered in the next version.
In the scenario of the mobile backhaul network shown in Figure 1, the eNodeB communicates with RC (Radio Controller). SRv6 path can be set up between the ASGs (Access Site Gateway) and the RSG (RC Site Gateway) to bear mobile services. For a strict SRv6 TE path in this scenarios, the typical number of the SIDs in the SRH is about 5 to 8 and the maximum is 10.
In the scenario of the mobile backhaul network, there are two different domains. The domain between the ASGs and the AGGs (Aggregation Gateway) is the access domain. And the domain between the AGGs and the RSGs is the aggregation domain. The locators of the SRv6 SIDs in each domain can share the common prefix. But the locators of different domains may be different, meaning they cannot share the common prefix.
eNodB2---ASG2-------AGG1------P1------RSG1------RC1
| | |
| | |
eNodB1---ASG1 | |
| | |
| | |
eNodB1---ASG3-------AGG2------P2------RC2-------RC2
Figure 1. Mobile Backhaul Network
In the scenario of multiple netowrk domains shown in Figure 2, the typical case is that Domain 1 and Domain 3 can be the mubile backhaul networks and the Domain 2 can be the IP backbone network. An SRv6 path can be set up from the node in Domain 1 and end up at the node in Domain 2 for bearing mobile services, which will travel multiple network domains. In this case, the typical number of the SIDs in the SRH for the E2E SRv6 path may be up to 15, that is, for each network domain, the typical number of the SIDs in SRH for each network domain is 5. Though Binding SIDs [RFC8402] can be used for shortening the SIDs List.
In the scenario of multiple network domains, the locators of the SRv6 SIDs in each network domain can share the common prefix. But the locators of different network domains may be different, meaning they does not share the common prefix.
A1--A3--ASBR11--ASBR21---P3--ASBR23--ASBR31--B3--B1
| | | | | |
| | | | | |
| Domain1 | | Domain2 | | Domain3 |
| | | | | |
| | | | | |
A2--A4--ASBR12--ASBR22--P4---ASBR24--ASBR32--B4--B2
Figure 2. Multiple Network Domains
There are three major concerns about SRH overhead:
1. Path MTU
Since an SRv6 SID is a 128-bits value, when many SRv6 SIDs are carried within an SRH, the large size overhead introduced by the SRH increases the size of the packet which may exceed the Path MTU so that the packet will be dropped.
In the current network, the PMTU of most UNI (User-to-Network Interface) is configured as 1500 Bytes, due to the old link layer technology in the user side. In most scenarios, such as IP WAN and DCN, the PMTU of most NNI(Network-to-Network Interface) is configured as 9000 bytes, since most vendors have to support Jumpo frame(>9000 Bytes). Therefore, when a packet come from the UNI, the packet size is under 1500 bytes, which is far away from 9000 bytes even include the overhead of SRH. So the Path MTU is not a critical issue in the current network.
2. Forwarding Performance
As the size of the SRH overhead increases, it will bring burdens to the hardware forwarding or software forwarding, and it will have effect on the forwarding performance.
SRv6 can be deployed step-by-step in the networks while the hardware capability is being developed. Given the fact some vendors already supports the forwarding capability of up to 10 SIDs in the SRH now, the challenges can be mitigated in the near future. But SRv6 will be deployed in the wide network domains, the challenges to support more SIDs in SRH still exist.
3. Payload Efficiency
As the size of the SRH overhead increases, the ratio of the effective payload of a packet will be decreased. The SRH overhead will cause the waste of bandwidth.
According to the statistics information from AMS-IX <https://stats.ams-ix.net/sflow/index.html?type=;interval=monthly;counter=bps>, the average packet size is about 512 Bytes. From throughput (in bps) point of view, the packets large than 1024 bytes are more than 87% among the traffic. Given the typical packet size and traffic statistics information, the effect of payload efficiency can be under control with gradually introducing of SRv6. However, in the long term there may be requirements to insert up to 10 or more SIDs in an SRH which will low down the payload efficiency.
In summary, according to the above analysis, the issue of SRv6 SRH overhead can be under control in the short time. However, as the development of SRv6 in the wider network domains, more SIDs will be inserted in the SRH to support strict TE and other functionalities, it will propose more challenges for the haraware.
The Binding SID [RFC8402] is bound to an SR Policy, instantiation of which may involve a list of SIDs. Using BSID can shorten the SID list [I-D.peng-spring-srv6-compatibility], and BSID is wide deployed in the SR and SRv6 networks. However, the node that imposes the bound policy needs to store the SID list, meaning the node should maintain more states.
For example, the strict TE path <R1, R2, R3, R4, R5, R6, R7, R8, R9, R10> can be represented as a seriels of END.X SIDs allocated by the nodes, and the SID list can be represented as <R1-R2, R2-R3, R3-R4, R4-R5, R5-R6, R6-R7, R7-R8, R8-R9, R9-R10>. BSID1 is bound to an SID list <R2-R3, R3-R4, R4-R5, R5-R6>, BSID2 is bound to an SID list <R6-R7, R7-R8, R8-R9, R9-R10>. Therefore, the path can be represented as <R1-R2, BSID1, BSID2> by using the Binding SIDs. In this way, the SID number in the SRH is reduced form 9 to 3. While the drawback is that the states of Binding SIDs should be maintained at the mapping nodes R2 and R6.
++++++++++++++++++++++++++++++++++++++++++++++++++++
+ +
+ +
+ BSID1 BSID2 +
CPE1---R1---R2----R3----R4----R5----R6----R7----R8----R9--R10--CPE2
+ +
+ +
+ +
++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 2. Binding SID for Shorter the SID List
In some cases, if the strict TE path represented by an adjacency SID list is the same as the loose TE path represented by a node SID or prefix SID, the adjacency SID list can be replaced by the node SID or the prefix SID to reduce the number of SIDs. However, loose path TE can not guarantee the SLA of per-hop processing(bandwidth, delay, etc.) for the traffic.
For example, an SRv6 policy explicitly indicates a strict TE path by SID list <R1-R2, R2-R3, R3-R4, R4-R5, R5-R6, R6-R7, R7-R8, R8-R9, R9-R10>. If this path is the same as the SPF path of an END SID S10 of node R10, then this END SID S10 can be used for forwarding the traffic instead of the long SID list. However, if there are some SLA policy associated to the Adjacency SIDs along the path, then it can not be assured in best effert forwarding by using the END SID, even the packet is forwarded following the same path.
++++++++++++++++++++++++++++++++++++++++++++++++++++
+ R11-------R12----R13 +
+ | | | +
+ | | | + END SID S10
CPE1---R1---R2----R3----R4----R5----R6----R7----R8----R9--R10--CPE2
+ | | +
+ | | +
+ R14-------------------------------R15 +
++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 3. Binding SID for Shorter the SID List
Based on the above typical scenario and gap analysis of existing solutions , this section lists the suggested requirements for Shorter SRv6 SID, which can be used to help the WG evaluate against the proposed solutions:
REQ#1: The Shorter SRv6 solution MUST be compatible with the basic SRv6. There are three basic Segment Routing over the IPv6 data-plane (SRv6) documents:
The Shorter SRv6 SID solution MUST be compatible with the above listed SRv6 documents.
REQ#2: The Shorter SRv6 SID solution MUST support Efficient SRv6 header compression.
When SRv6 is deployed, the SRv6 header overhead must be considered, as the size of the SRH may affect the forwarding performance. The solution MUST reduce the SRv6 SID size effectively.
REQ#3: The Shorter SRv6 SID solution MUST support source routing, SHOULD NOT introduce per-flow states on middle nodes.
Reducing the states on the middle nodes is the advantage of SR, and it should be maintained. New states should be introduced after carefully consideration if they are really needed.
REQ#4: The Shorter SRv6 SID solution SHOULD be routable as a Native IPv6 address for currently typical application.
It is the key feature of SRv6 that SRv6 SID can be routable as a native IPv6 address:
1. The feature guarantees the compatibility of SRv6 to IPv6.
2. SRv6 SID is routable as a normal native IPv6 address, so the traffic can be forwarded as the normal IPv6 traffic on the SRv6 unaware nodes. it simplifies the service provision that SRv6-based services can take use of the basic IPv6 reachability.
3. The routes of SRv6 SIDs can be aggregated since SRv6 SID can be routed as a native IPv6 address. This can reduce the number of forwarding entries and improve the scalability, especially in inter-AS networks scenarios. Based on the native IPv6 routing, the SRv6 BE VPN can be deployed by only upgrading the VPN endpoint nodes. Also, SRv6 VPN traffic can be forwarded as the native IPv6 address without difficult configurations on the edge nodes in inter-domain scenarios.
Therefore, the shorter SID SHOULD be routable as a Native IPv6 address.
Other scenarios will be considered in future, the solution should have the forward compabilities to support other scenarios.
REQ#5: The Shorter SRv6 SID solution CAN NOT require specific address planning or address type.
When deploying SRv6 in a network, the SIDs can be allocated from a SID space, the address block managed by the operators. The Shorter SID solution should support this as well. It MUST support flexible address planning as different networks have their own address allocation policy. The Shorter SID MUST NOT depend on some specific address type, and it SHOULD NOT introduce new address type in the network since this increases the complexities of configurations and operations, which will also bring troubles of OAM due to operators may have limited experience of it.
REQ#6: The Shorter SRv6 SID solution MUST be a Loseless Compression mechanism. The information carried by the shorter SID list in SRH MUST equal to the original SID list.
The information can not be lost in compression since each SID represents the action and related services on a node, the Shorter SID solution MUST represent the same function. The format of the Shorter SID may be different with the original SRv6 SID, while the related function should be identical.
REQ#7: The Shorter SRv6 SID solution SHOULD support multiple functions, including END, END.X and END.T but not limit to them.
The solution MUST be scalable to support multiple functions and it SHOULD NOT be limited in only END, END.X and END.T, since there will be multiple SIDs to be introduced in the future, the solution should have the forward compabilities to support the new SIDs.
REQ#8: The Shorter SRv6 SID solution MUST be easy to implement and hardware-friendly(Including ASIC-based and NP-based hardware)
The Shorter SRv6 SID solution MUST be simple and easy to implement based on existing commercial hardware, which can be supported by multiple vendors instead of some specific vendors.
REQ#9: The Shorter SRv6 SID solution MUST be compatible with SRv6 header(SRH).
For support of the SRv6 network, Segment Routing Header (SRH) has been defined in [I-D.ietf-6man-segment-routing-header]. The Shorter SRv6 SID solution MUST be compatible with SRH.
REQ#10: The Shorter SRv6 SID solution SHOULD support to encode Compressed SRv6 Network Programming SIDs and SRv6 SIDs in a single SRH.
In an SR domain, there will be a scenario in which some nodes support Compressed SRv6, while others support IPv6 without SR extensions. The proposed solution MUST support this scenario.
REQ#11: The Shorter SRv6 SID solution MUST support super-large-scale networking and address planning.
Note: The operator suggest to reuse the current address assignment and planning, thus minimizing the impact on the network.
REQ#12: The Shorter SRv6 SID solution MUST have the ability to upgrade smoothly from SR-MPLS to SRv6.
2G/3G/4G backhaul networks widely deploy MPLS to connect wireless services. Many operators are already deploying 5G networks. To optimize the operation of the network, many operators intent to adopt the segment routing. Currently, given the maturity of SR-MPLS, it has been deployed on a large scale. Meanwhile the requirements of 5G super-large-scale number of connections accelerate the deployment of IPv6 networks. Thus, logically, operators consider SRv6 solution to fulfill the 5G backhaul requirement. But the backhaul network could not deploy SRv6 in one day, especially if it has already been using MPLS and SR-MPLS. It might be reasonable to upgrade from MPLS to SR-MPLS and then to SRv6.
REQ#13: The Shorter SRv6 SID solution MUST support interworking between SRv6 and SR-MPLS domains in the network.
SR-MPLS currently, more often than SRv6, is used in metro networks. With the gradual deployment of SRv6 in the core networks, it becomes necessary to support interworking between SR-MPLS and SRv6.
As we know, there several proposals in the called ‘shorter SRv6 SID’topic. This document tries to summarize these proposals here. Then we can discuss whether all the proposals can meet the requirements. And then we can look at the merits and costs of each solution. After that, we will possibly refine them, possibly converge on a single one, and probably drop multiples.
Here are the solutions that have been proposed:
This document has no requests to IANA.
This document does not change the security considerations of SRv6, please refers to [RFC8402], [I-D.ietf-6man-segment-routing-header] and [I-D.ietf-spring-srv6-network-programming].
| [I-D.ietf-6man-segment-routing-header] | Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S. and D. Voyer, "IPv6 Segment Routing Header (SRH)", Internet-Draft draft-ietf-6man-segment-routing-header-26, October 2019. |
| [I-D.ietf-spring-srv6-network-programming] | Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S. and Z. Li, "SRv6 Network Programming", Internet-Draft draft-ietf-spring-srv6-network-programming-12, March 2020. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [RFC8402] | Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018. |
| [RFC8660] | Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019. |
| [I-D.bonica-6man-comp-rtg-hdr] | Bonica, R., Kamite, Y., Niwa, T., Alston, A. and L. Jalil, "The IPv6 Compressed Routing Header (CRH)", Internet-Draft draft-bonica-6man-comp-rtg-hdr-13, March 2020. |
| [I-D.cl-spring-generalized-srv6-np] | Cheng, W., Li, Z., Li, C., Xie, C., Cong, L., Tian, H. and F. Zhao, "Generalized SRv6 Network Programming", Internet-Draft draft-cl-spring-generalized-srv6-np-00, February 2020. |
| [I-D.decraene-spring-srv6-vlsid] | Decraene, B. and R. Raszuk, "SRv6 vSID: Network Programming extension for variable length SIDs", Internet-Draft draft-decraene-spring-srv6-vlsid-02, February 2020. |
| [I-D.filsfils-spring-net-pgm-extension-srv6-usid] | Filsfils, C., Camarillo, P., Cai, D., Voyer, D., Meilik, I., Patel, K., Henderickx, W., Jonnalagadda, P. and D. Melman, "Network Programming extension: SRv6 uSID instruction", Internet-Draft draft-filsfils-spring-net-pgm-extension-srv6-usid-04, February 2020. |
| [I-D.ietf-spring-sr-service-programming] | Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W. and S. Salsano, "Service Programming with Segment Routing", Internet-Draft draft-ietf-spring-sr-service-programming-01, November 2019. |
| [I-D.li-spring-compressed-srv6-np] | Li, Z., Li, C., Xie, C., LEE, K., Tian, H., Zhao, F., Guichard, J., Cong, L. and S. Peng, "Compressed SRv6 Network Programming", Internet-Draft draft-li-spring-compressed-srv6-np-02, February 2020. |
| [I-D.mirsky-6man-unified-id-sr] | Cheng, W., Mirsky, G., Peng, S., Aihua, L., Wan, X., Wei, C. and S. Shay, "Unified Identifier in IPv6 Segment Routing Networks", Internet-Draft draft-mirsky-6man-unified-id-sr-05, February 2020. |
| [I-D.peng-spring-srv6-compatibility] | Tian, H., Zhao, F., Xie, C., Li, T., Ma, J., Peng, S., Li, Z. and J. Guichard, "SRv6 Compatibility with Legacy Devices", Internet-Draft draft-peng-spring-srv6-compatibility-02, January 2020. |