Network Working Group Z. Li Internet-Draft T. Sun Intended status: Informational China Mobile Expires: May 6, 2021 W. Cheng J. Wang Centec Networks November 2, 2020 SRv6 SPAN draft-li-spring-srv6-span-01 Abstract As an important means for operation and maintenance (O&M), mirroring is the most direct and comprehensive technology for capturing data streams and forwarding information. Compared with other visualization technologies, it can not only obtain the content of an entire packet, but also add forwarding information of a network device to a mirror packet and send the packet to a remote analysis server. 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 . 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 May 6, 2021. Li, et al. Expires May 6, 2021 [Page 1] Internet-Draft SPRING Group November 2020 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Purposes for Proposing the SRv6 SPAN Technology . . . . . . . 3 2.1. Design and Implementation of the SRv6 SPAN Technology . . 4 2.1.1. SRv6 SPAN Technology and Networking . . . . . . . . . 4 2.1.2. SRv6 SPAN Technology and Packet Formats . . . . . . . 5 2.2. Future Considerations and Enhancements of the SRv6 SPAN Technology . . . . . . . . . . . . . . . . . . . . . . . 8 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The mirroring technology is also required in network O&M and fault locating. Networking architectures and network scales vary with scenarios, and accordingly requirements for mirroring technologies are different. For example, port mirroring can meet mirroring requirements for some small and medium-sized networks. In terms of network architecture, on the physical link, a mirroring-enabled switch is directly connected to a server used to analyze mirror packets. Although it is simple to use the mirroring technology in this case, the deployment of the mirror server is greatly limited. With the expansion of the network scale, especially in a super-large data center, the overlay tunneling technology is also used for deploying the mirror server, so as to remove the limitation that the mirror server needs to be directly connected on the physical link during networking. Li, et al. Expires May 6, 2021 [Page 2] Internet-Draft SPRING Group November 2020 The conventional mirroring technology is designed and implemented based on the IPv4 network, and data stream-based remote mirroring is developed based on local port mirroring. Combined with the networking in the data center, overlay and underlay networks are connected using the GRE tunneling technology. As such, the analysis server of mirror data packets can be flexibly deployed, and requires only route reachability instead of direct connection on the physical link. In an SRv6 network, to simplify the network architecture and ensure stable running, protocol types are reduced as much as possible. If GRE is selected as the basic forwarding protocol of the mirroring technology, more restrictions will be imposed on the application scope of the mirroring technology. In addition, SRv6 is capable of connecting overlay and underlay networks, and does not need any additional forwarding protocol. To better use the mirroring technology in the SRv6 network, a native mirroring function needs to be designed based on the features of the SRv6 network. Moreover, the formats of the conventional mirror protocol packets and the existing device capabilities should be reused to the maximum extent, so that the software system of the existing mirror analysis server is compatible, thereby avoiding redeveloping the software of the mirror server due to the SRv6-based mirroring technology. This helps reduce the difficulty in implementing the SRv6 network. 2. Purposes for Proposing the SRv6 SPAN Technology Based on the IPv4 network technology, local port mirroring and data stream-based remote mirroring are developed. In the networking of the data center, the analysis server for mirror data packets should have route reachability during deployment. Therefore, the conventional far-end mirroring technology is based on GRE. There are two reasons for using GRE: One is that packets encapsulated by GRE support route-based forwarding, and only route reachability is required for the deployment of the mirror analysis server in the data center. Second, the large-scale construction of data centers coincided with the introduction of the GRE technical standards in 2016 when Microsoft deployed GRE on a large scale in its data center. Currently, two changes have taken place in the forwarding protocol technology of the data center: One is that VXLAN, as an overlay technology, exceeds GRE and is deployed in more data centers; the other is that the IPv6 development has reached a critical moment, and the SRv6 source routing technology based on the IPv6 data plane is expected to be widely deployed in the future. Therefore, the GRE- based mirroring technology deviates from the very-simple design Li, et al. Expires May 6, 2021 [Page 3] Internet-Draft SPRING Group November 2020 principle in a data center network architecture, and it is difficult to use the GRE-based mirroring technology in a data center where VXLAN has been deployed. Otherwise, the data plane and the control plane will become more complex. In view of the above, this document aims to design an SRv6 SPAN technology. On the one hand, it is born to support the SRv6 network. SRv6 is capable of connecting overlay and underlay networks and does not need IPv6 GRE, simplifying the network architecture and protocols. On the other hand, the formats of the conventional mirror protocol packets are reused to the maximum extent, so that the software system of the existing mirror analysis server is compatible, thereby avoiding redeveloping the software of the mirror server due to the SRv6 SPAN technology. This helps reduce the difficulty in implementing the SRv6 network. 2.1. Design and Implementation of the SRv6 SPAN Technology This document aims to design an SRv6 SPAN technology, so as to: 1. simplify the network architecture where the mirroring technology is used and deployed; 2. be compatible with the packet formats of conventional mirrors; 3. enhance the mirroring technology to meet new requirements. 2.1.1. SRv6 SPAN Technology and Networking SRv6 is used to connect overlay and underlay networks of mirror data packets, without needing IPv6 GRE, thereby simplifying the network architecture and protocols. However, the standard forwarding plane of SRv6 may also be divided into two types: a standard SRv6 packet carrying the SRH and a SRv6-BE packet carrying the SRH. The SRv6 SPAN technology is designed to support SRv6-BE. This is because IPv6 networks have been upgraded on a large scale, but the SRv6 network is still under development. Different from standard SRv6, SRv6-BE does not need to add the SRH but is directly borne on the IPv6 tunnel, so that the SRv6/IPv6 network can use the mirroring technology in this document to the maximum extent. Therefore, the SRv6-BE mirroring technology only needs to support IPv6 forwarding, which allows remote deployment of analysis servers for mirror packets, while requires no SRv6 SRH processing capability. This reduces the difficulty in deploying the SRv6 SPAN technology. In addition, the SRv6 SPAN technology in this document further supports the SRv6 network that carries the SRH. A network device with SRv6 SRH processing capability can implement precise path control by using a mirror packet encapsulated based on SRv6 SRH, and can capture other forwarding information when the mirroring technology is used. Li, et al. Expires May 6, 2021 [Page 4] Internet-Draft SPRING Group November 2020 Therefore, the SRv6 SPAN technology is not only compatible with a device that supports only an IPv6 network, but also matches with a network device with SRv6 SRH processing capability. It can remotely deploy an analysis server used for mirror packets, implement path control, and enable extensible forwarding information capturing. 2.1.2. SRv6 SPAN Technology and Packet Formats The protocol packet formats of the SRv6 SPAN technology are compatible with the formats of the conventional ERSPAN protocol packet as far as possible. The formats of the conventional mirror protocol packets are reused to the maximum extent, so that the software system of the existing mirror analysis server is compatible, thereby avoiding redeveloping the software of the mirror server. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Hdr=144 | Hdr Ext Len | Routing Type | Segments Left | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Entry | Flags | Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Segment List[0] (128-bit IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ... | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Segment List[n] (128-bit IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRv6 SPAN Header | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Origin Packet | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRv6 SPAN Packet Format Li, et al. Expires May 6, 2021 [Page 5] Internet-Draft SPRING Group November 2020 Based on SRv6 packet formats, Next Header 144 is used to identify SRv6 SPAN. In addition, the SRv6 SPAN Header format has been defined in the first version of this document, and includes a 4-octet sequence number and 12-octet portion forwarding information. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Increments per packet per session ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | VLAN | COS |BSO|T| Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SGT |P| FT | Hw ID |D|Gra|O| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRv6 SPAN Header Format The various fields of the above SRv6 SPAN header are described in this table: Field Length (bits) Definition Sequence 32 For SRv6 SPAN packets sequence number， number increased per packet per session， for detecting loss of mirror packet by analysis server. Ver 4 SRv6 SPAN Encapsulation version. For SRv6 SPAN packets it is set to 0x6. VLAN 12 VLAN of the frame monitored by an SRv6 SPAN source session: for ingress monitor this will be the original source VLAN whereas for egress monitor this will be the destination VLAN. COS 3 Class of Service of the monitored frame. Ingress or egress CoS value is to be used depending on the monitor type/direction. T 1 This bit indicates that the frame copy encapsulated in the SRv6 SPAN packet has been truncated. This occurs if the SRv6 SPAN encapsulated frame exceeds the configured MTU and hence has to be truncated. Li, et al. Expires May 6, 2021 [Page 6] Internet-Draft SPRING Group November 2020 Session ID 10 Identification associated with each SRv6 SPAN (ERSPAN ID) session. Must be unique between the source and the receiver(s). BSO (Bad/Short/ 2 A 2-bit value indicating the integrity of Oversized) the payload carried by SRv6 SPAN: 00 --> Good frame with no error, or unknown integrity 11 --> Payload is a Bad Frame with CRC or Alignment Error 01 --> Payload is a Short Frame 10 --> Payload is an Oversized Frame Timestamp 32 The timestamp value needs to be derived from a hardware clock which is synchronized to the system-clock. This 32- bit field should support at least a timestamp granularity of 100 microseconds (see the Timestamp Granularity field). SGT 16 Security Group Tag of the monitored frame. P 1 This bit indicates that the SRv6 SPAN payload is an Ethernet protocol frame . FT (Frame Type) 5 This field can be used to reconstruct the original frame's encapsulation if it is supported by the receiver. This field may also be used by SRv6 SPAN engines to indicate that the mirrored frame's L2 encapsulation header (or a portion of it) was skipped and not included in the SRv6 SPAN packet. 00000 --> Ethernet frame (802.3 frame) 00010 --> IP Packet Other values --> Reserved for future use Hw (Hardware) ID 6 Unique identifier of an SRv6 SPAN engine within a system. D (Direction) 1 Indicates whether the original frame was SRv6 SPAN'ed in ingress or in egress. Ingress (0) or Egress (1). Gra (Timestamp Granularity) 2 Time unit to be supported for time- stamping: 00b --> granularity = 100 microseconds Li, et al. Expires May 6, 2021 [Page 7] Internet-Draft SPRING Group November 2020 01b --> granularity = 100 nanoseconds 10b --> granularity = IEEE 1588 TimeRepresentation format (see definition below; with nanoseconds portion stored in the Timestamp field and seconds portion stored in the SRv6 SPAN platform-dependent sub-header) struct TimeRepresentation { UInteger32 seconds; UInteger32 nanoseconds; }; 11b --> user configurable time unit (platform dependent, for example specific to an isolated non-synchronized system with very high local accuracy) O (Optional Sub-header) 1 The O flag indicates whether or not the optional platform-specific sub-header is present. If it's present, the next octet indicates the platform specific format used (Platf ID). The SRv6 SPAN payload starts after the O flag when O == 0b or after 8 octets when O == 1b. SRv6 SPAN Header Description 2.2. Future Considerations and Enhancements of the SRv6 SPAN Technology In the first version of this document, the goal is to solve the problem that the conventional mirroring technology is not compatible with the existing SRv6 network. In a later version of this document, the SRv6 SPAN technology will be enhanced in three aspects: * First, different requirements for mirroring capabilities in multiple scenarios are met. * Second, the capability of controlling a forwarding path and service quality of a mirror data stream are enhanced;. * Third, the capability of capturing required information is enhanced. Li, et al. Expires May 6, 2021 [Page 8] Internet-Draft SPRING Group November 2020 SRv6 technology will be further developed, and enhancement points of the SRv6 SPAN technology will be detailed in subsequent documents. It is expected that the mirroring technology can be used as the essential means for SRv6 network O&M and fault locating, so as to facilitate the development of the SRv6 network. 3. Conclusion The implementation of the SRv6 network mirroring function through SRv6 SPAN technology is not only conducive to unifying the forwarding data plane of the SRv6 network, avoiding the additional introduction of GRE and other tunneling protocols, but also fully considering the compatibility with the traditional mirroring message format in the definition of SRv6 SPAN Header, Reduce the repeated development of image analysis software to promote the development of SRv6 networks and the deployment of SRv6 SPAN. 4. Security Considerations TBD. 5. IANA Considerations TBD. Authors' Addresses Zhiqiang Li China Mobile Beijing 100053 China Email: lizhiqiangyjy@chinamobile.com Tao Sun China Mobile Beijing 100053 China Email: suntao@chinamobile.com Li, et al. Expires May 6, 2021 [Page 9] Internet-Draft SPRING Group November 2020 Wei Cheng Centec Networks Suzhou 215000 China Email: chengw@centecnetworks.com Junjie Wang Centec Networks Suzhou 21500 China Email: wangjj@centecnetworks.com Li, et al. Expires May 6, 2021 [Page 10]