| SPRING Working Group | H. Tian |
| Internet-Draft | F. Zhao |
| Intended status: Informational | CAICT |
| Expires: July 13, 2020 | C. Xie |
| China Telecom | |
| T. Li | |
| J. Ma | |
| China Unicom | |
| S. Peng | |
| Z. Li | |
| Huawei Technologies | |
| J. Guichard | |
| Futurewei Technologies Ltd. | |
| January 10, 2020 |
SRv6 Compatibility with Legacy Devices
draft-peng-spring-srv6-compatibility-02
When deploying SRv6 on legacy devices, there are some compatibility challenges that must be addressed such as the support for SRH processing.
This document identifies some of the major challenges, and provides solutions that can mitigate those challenges and smooth the migration towards SRv6 deployment.
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.
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 July 13, 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) is a source routing paradigm, which allows a headend node to steer packets into an SR policy which is instantiated through an ordered list of instructions, i.e. segments [RFC8402]. A segment can either be topological or service based. SR over IPv6 (SRv6) [I-D.ietf-spring-srv6-network-programming] is the instantiation of SR on the IPv6 data plane with a new type of routing extension header, i.e. SR Header (SRH) [I-D.ietf-6man-segment-routing-header]. An SRv6 segment, also called SRv6 SID, is a 128-bit value, represented as LOC:FUNCT:ARGS (ARGS is optional), and is encoded as an IPv6 address. An ordered list of SRv6 SIDs forms an SR Policy, which can be used for Traffic Engineering (TE), Service Function Chaining (SFC), and In-situ Operations, Administration, and Maintenance (IOAM). Meanwhile, the deployment of SRv6 will bring challenges for legacy devices that do not natively support SRv6.
This document provides solutions that can mitigate the identified compatibility challenges and ease the evolution towards SRv6 deployment.
By adopting SR Policy, state in the network devices can be greatly reduced, which ultimately evolves the network into a stateless fabric. However, it also brings compatibility challenges on the legacy devices. In particular, the legacy devices need to upgrade software and/or hardware in order to support the processing of SRH.
Furthermore, as the segments in the segment list increase the SR Policy incrementally expands, the encapsulation header overhead increases, which imposes high performance requirements on the performance of hardware forwarding (i.e. the capability of the chipset).
This section identifies the challenges for legacy devices imposed by SRv6 in the following SPRING use cases.
FRR is deployed to cope with link or node failures by precomputing backup paths. By relying on SR, Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) [I-D.ietf-rtgwg-segment-routing-ti-lfa] provides a local repair mechanism with the ability to activate the data plane switch-over on to a loop-free backup path irrespective of topologies prior and after the failure.
Using SR, there is no need to create state in the network in order to enforce FRR behavior. Correspondingly, the Point of Local Repair, i.e. the protecting router, needs to insert a repair list at the head of the segment list in the SRH, encoding the explicit post-convergence path to the destination. This action will increase the length of the segment list in the SRH as shown in Figure 1.
TE enables network operators to control specific traffic flows going through configured explicit paths. There are loose and strict options. With the loose option, only a small number of hops along the path is explicitly expressed, while the strict option specifies each individual hop in the explicit path, e.g. to encode a low latency path from one network node to another.
With SRv6, the strict source-routed explicit paths will result in a long segment list in the SRH as shown in Figure 1, which places high requirements on the devices.
The SR segments can also encode instructions, called service segments, for steering packets through services running on physical service appliances or virtual network functions (VNF) running in a virtual environment [I-D.ietf-spring-sr-service-programming]. These service segments can also be integrated in an SR policy along with node and adjacency segments. This feature of SR will further increase the length of the segment list in the SRH as shown in Figure 1.
In terms of SR awareness, there are two types of services, i.e. SR-aware and SR-unaware services, which both impose new requirements on the hardware. The SR-aware service needs to be fully capable of processing SR traffic, while for the SR-unaware services, an SR proxy function needs to be defined.
If the Network Service Header (NSH) based SFC [RFC8300] has already been deployed in the network, the compatibility with existing NSH is required.
IOAM, i.e. "in-situ" Operations, Administration, and Maintenance (OAM), encodes telemetry and operational information within the data packets to complement other "out-of-band" OAM mechanisms, e.g. ICMP and active probing. The IOAM data fields, i.e. a node data list, hold the information collected as the packets traverse the IOAM domain [I-D.ietf-ippm-ioam-data], which is populated iteratively starting with the last entry of the list.
The IOAM data can be embedded into a variety of transports. To support the IOAM on the SRv6 data plane, the O-flag in the SRH is defined [I-D.ali-spring-srv6-oam], which implements the "punt a timestamped copy and forward" or "forward and punt a timestamped copy" behavior. The IOAM data fields, i.e. the node data list, are encapsulated in the IOAM TLV in SRH, which further increases the length of the SRH as shown in Figure 1.
+-----------+
|IPv6 packet|
+-----------+
/ /
+-----------+ / IOAM Info /
|IPv6 packet| / /
+-----------+ +-----------+ +-----------+
|IPv6 packet| / / / /
+-----------+ +-----------+ / / / /
|IPv6 packet| / / / SF Chain / / SF Chain /
+-----------+ +-----------+ / TE Path / / / / /
|IPv6 packet| /TI-LFA Path/ / / / / / /
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+
|SA,DA | |SA,DA | |SA,DA | |SA,DA | |SA,DA |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+
SRv6 BE SRv6 BE+ SRv6 TE SRv6 SFC SRv6 SFC+
TI-LFA IOAM
Compatibility challenges for legacy devices can be summarized as follows:
This section provides solutions to mitigate the challenges outlined in section 2.
With strict traffic engineering, the resultant long SID list in the SRH raises high requirements on the hardware chipset, which can be mitigated by the following solutions.
Binding SID [RFC8402] involves a list of SIDs and is bound to an SR Policy. The node(s) that imposes the bound policy needs to store the SID list. When a node receives a packet with its active segment as a BSID, the node will steer the packet in to the bound policy accordingly.
To reduce the long SID list of a strict TE explicit path, BSID can be used at selective nodes, maybe according to the processing capacity of the hardware chipset. BSID can also be used to impose the repair list in the TI-LFA as described in Section 2.1.
When the SR architecture adopts a centralized model, the SDN controller (e.g. Path Computation Element (PCE)) only needs to apply the SR policy at the head-end. There is no state maintained at midpoints and tail-ends. Eliminating state in the network (midpoints and tail-points) is a key benefit of utilizing SR. However, it also leads to a long SID list for expressing a strict TE path.
PCEP FlowSpec [I-D.ietf-pce-pcep-flowspec] provides a trade-off solution. PCEP FlowSpec is able to disseminate Flow Specifications (i.e. filters and actions) to indicate how the classified traffic flows will be treated. In an SR-enabled network, PCEP FlowSpec can be applied at the midpoints to enforce traffic engineering policies where it is needed. In that case, state needs to be maintained at the corresponding midpoints of a TE explicit path, but the SID list can be shortened.
Currently two approaches are proposed to support SFC over SRv6, i.e. stateless SFC [I-D.ietf-spring-sr-service-programming] and stateful SFC [I-D.ietf-spring-nsh-sr].
A service can also be assigned an SRv6 SID which is integrated into an SR policy and used to steer traffic to it. In terms of the capability of processing the SR information in the received packets, there are two types of services, i.e. SR-aware service and SR-unware service. An SR-aware service can process the SRH in the received packets. An SR-unaware service, i.e. legacy service, is not able to process the SR information in the traffic it receives, and may drop the received packets. In order to support such services in an SRv6 domain, the SR proxy is introduced to handle the processing of SRH on behalf of the SR-unware service. The service SID associated with the SR-unaware service is instantiated on the SR proxy, which is used to steer traffic to the service.
The SR proxy intercepts the SR traffic destined for the service via the locally instantiated service SID, removes the SR information, and sends the non-SR traffic out on a given interface to the service. When receiving the traffic coming back from the service, the SR proxy will restore the SR information and forwards it to the next segment in the segment list.
The NSH and SR can be integrated in order to support SFC in an efficient and cost-effective manner while maintaining separation of the service and transport planes.
In this NSH-SR integration solution, NSH and SR work jointly and complement each other. Specifically, SR is responsible for steering packets along a given Service Function Path (SFP) while NSH is for maintaining the SFC instance context, i.e. Service Path Identifier (SPI), Service Index (SI), and any associated metadata.
When a service chain is established, a packet associated with that chain will be first encapsulated with an NSH and then an SRH, and forwarded in the SR domain. When the packet arrives at an SFF and needs to be forwarded to an SF, the SFF performs a lookup based on the service SID associated with the SF to retrieve the next-hop context (a MAC address) between the SFF and SF. Then the SFF strips the SRH and forwards the packet with NSH carrying metadata to the SF where the packet will be processed as specified in [RFC8300]. In this case, the SF is not required to be capable of the SR operation, neither is the SR proxy. Meanwhile, the stripped SRH will be updated and stored in a cache in the SFF, indexed by the NSH SPI for the forwarding of the packet coming back from the SF.
In most cases, after the IPv6 Destination Address (DA) is updated according to the active segment in the SRH, the SID in the SRH will not be used again. However, the entire SID list in the SRH will still be carried in the packet along the path till a PSP/USP is enforced.
The light weight IOAM method [I-D.li-spring-passive-pm-for-srv6-np] makes use of the used segments in the SRH to carry the IOAM information, which saves the extra space in the SRH and mitigate the requirements on the hardware.
Existing in-situ OAM techniques incur encapsulation and header overhead issues as described in section 2. Postcard-based Telemetry with Packet Marking for SRv6 on-path OAM[I-D.song-ippm-postcard-based-telemetry], provides a solution that avoids the extra overhead for encapsulating telemetry-related instruction and metadata in SRv6 packets.
The SRH enables a great number of features for SRv6 and opens new network programming possibilities. By using SRH, it relieves the network devices from state, evolving towards stateless fabric, while the complexity in the control plane increases. The corresponding challenges imposed on the hardware chipset become high as the SRH expands when supporting the diverse use cases. The trade-off solutions presented in this document can mitigate these challenges and smooth the evolution in operators' networks.
There are no IANA considerations in this document.
Note to RFC Editor: this section may be removed on publication as an RFC.
TBD
Hailong Bai China Unicom China
Ruizhao Hu Huawei China
Email: huruizhao@huawei.com
Jianwei Mao Huawei China
Email: maojianwei@huawei.com