idnits 2.17.1 draft-li-spring-srv6-span-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (November 2, 2020) is 1270 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '0' on line 212 looks like a reference Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft T. Sun 4 Intended status: Informational China Mobile 5 Expires: May 6, 2021 W. Cheng 6 J. Wang 7 Centec Networks 8 November 2, 2020 10 SRv6 SPAN 11 draft-li-spring-srv6-span-01 13 Abstract 15 As an important means for operation and maintenance (O&M), mirroring 16 is the most direct and comprehensive technology for capturing data 17 streams and forwarding information. Compared with other 18 visualization technologies, it can not only obtain the content of an 19 entire packet, but also add forwarding information of a network 20 device to a mirror packet and send the packet to a remote analysis 21 server. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in . 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 6, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Purposes for Proposing the SRv6 SPAN Technology . . . . . . . 3 65 2.1. Design and Implementation of the SRv6 SPAN Technology . . 4 66 2.1.1. SRv6 SPAN Technology and Networking . . . . . . . . . 4 67 2.1.2. SRv6 SPAN Technology and Packet Formats . . . . . . . 5 68 2.2. Future Considerations and Enhancements of the SRv6 SPAN 69 Technology . . . . . . . . . . . . . . . . . . . . . . . 8 70 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The mirroring technology is also required in network O&M and fault 78 locating. Networking architectures and network scales vary with 79 scenarios, and accordingly requirements for mirroring technologies 80 are different. For example, port mirroring can meet mirroring 81 requirements for some small and medium-sized networks. In terms of 82 network architecture, on the physical link, a mirroring-enabled 83 switch is directly connected to a server used to analyze mirror 84 packets. Although it is simple to use the mirroring technology in 85 this case, the deployment of the mirror server is greatly limited. 87 With the expansion of the network scale, especially in a super-large 88 data center, the overlay tunneling technology is also used for 89 deploying the mirror server, so as to remove the limitation that the 90 mirror server needs to be directly connected on the physical link 91 during networking. 93 The conventional mirroring technology is designed and implemented 94 based on the IPv4 network, and data stream-based remote mirroring is 95 developed based on local port mirroring. Combined with the 96 networking in the data center, overlay and underlay networks are 97 connected using the GRE tunneling technology. As such, the analysis 98 server of mirror data packets can be flexibly deployed, and requires 99 only route reachability instead of direct connection on the physical 100 link. 102 In an SRv6 network, to simplify the network architecture and ensure 103 stable running, protocol types are reduced as much as possible. If 104 GRE is selected as the basic forwarding protocol of the mirroring 105 technology, more restrictions will be imposed on the application 106 scope of the mirroring technology. In addition, SRv6 is capable of 107 connecting overlay and underlay networks, and does not need any 108 additional forwarding protocol. 110 To better use the mirroring technology in the SRv6 network, a native 111 mirroring function needs to be designed based on the features of the 112 SRv6 network. Moreover, the formats of the conventional mirror 113 protocol packets and the existing device capabilities should be 114 reused to the maximum extent, so that the software system of the 115 existing mirror analysis server is compatible, thereby avoiding 116 redeveloping the software of the mirror server due to the SRv6-based 117 mirroring technology. This helps reduce the difficulty in 118 implementing the SRv6 network. 120 2. Purposes for Proposing the SRv6 SPAN Technology 122 Based on the IPv4 network technology, local port mirroring and data 123 stream-based remote mirroring are developed. In the networking of 124 the data center, the analysis server for mirror data packets should 125 have route reachability during deployment. Therefore, the 126 conventional far-end mirroring technology is based on GRE. There are 127 two reasons for using GRE: One is that packets encapsulated by GRE 128 support route-based forwarding, and only route reachability is 129 required for the deployment of the mirror analysis server in the data 130 center. Second, the large-scale construction of data centers 131 coincided with the introduction of the GRE technical standards in 132 2016 when Microsoft deployed GRE on a large scale in its data center. 134 Currently, two changes have taken place in the forwarding protocol 135 technology of the data center: One is that VXLAN, as an overlay 136 technology, exceeds GRE and is deployed in more data centers; the 137 other is that the IPv6 development has reached a critical moment, and 138 the SRv6 source routing technology based on the IPv6 data plane is 139 expected to be widely deployed in the future. Therefore, the GRE- 140 based mirroring technology deviates from the very-simple design 141 principle in a data center network architecture, and it is difficult 142 to use the GRE-based mirroring technology in a data center where 143 VXLAN has been deployed. Otherwise, the data plane and the control 144 plane will become more complex. In view of the above, this document 145 aims to design an SRv6 SPAN technology. On the one hand, it is born 146 to support the SRv6 network. SRv6 is capable of connecting overlay 147 and underlay networks and does not need IPv6 GRE, simplifying the 148 network architecture and protocols. On the other hand, the formats 149 of the conventional mirror protocol packets are reused to the maximum 150 extent, so that the software system of the existing mirror analysis 151 server is compatible, thereby avoiding redeveloping the software of 152 the mirror server due to the SRv6 SPAN technology. This helps reduce 153 the difficulty in implementing the SRv6 network. 155 2.1. Design and Implementation of the SRv6 SPAN Technology 157 This document aims to design an SRv6 SPAN technology, so as to: 1. 158 simplify the network architecture where the mirroring technology is 159 used and deployed; 2. be compatible with the packet formats of 160 conventional mirrors; 3. enhance the mirroring technology to meet new 161 requirements. 163 2.1.1. SRv6 SPAN Technology and Networking 165 SRv6 is used to connect overlay and underlay networks of mirror data 166 packets, without needing IPv6 GRE, thereby simplifying the network 167 architecture and protocols. However, the standard forwarding plane 168 of SRv6 may also be divided into two types: a standard SRv6 packet 169 carrying the SRH and a SRv6-BE packet carrying the SRH. 171 The SRv6 SPAN technology is designed to support SRv6-BE. This is 172 because IPv6 networks have been upgraded on a large scale, but the 173 SRv6 network is still under development. Different from standard 174 SRv6, SRv6-BE does not need to add the SRH but is directly borne on 175 the IPv6 tunnel, so that the SRv6/IPv6 network can use the mirroring 176 technology in this document to the maximum extent. Therefore, the 177 SRv6-BE mirroring technology only needs to support IPv6 forwarding, 178 which allows remote deployment of analysis servers for mirror 179 packets, while requires no SRv6 SRH processing capability. This 180 reduces the difficulty in deploying the SRv6 SPAN technology. 182 In addition, the SRv6 SPAN technology in this document further 183 supports the SRv6 network that carries the SRH. A network device 184 with SRv6 SRH processing capability can implement precise path 185 control by using a mirror packet encapsulated based on SRv6 SRH, and 186 can capture other forwarding information when the mirroring 187 technology is used. 189 Therefore, the SRv6 SPAN technology is not only compatible with a 190 device that supports only an IPv6 network, but also matches with a 191 network device with SRv6 SRH processing capability. It can remotely 192 deploy an analysis server used for mirror packets, implement path 193 control, and enable extensible forwarding information capturing. 195 2.1.2. SRv6 SPAN Technology and Packet Formats 197 The protocol packet formats of the SRv6 SPAN technology are 198 compatible with the formats of the conventional ERSPAN protocol 199 packet as far as possible. The formats of the conventional mirror 200 protocol packets are reused to the maximum extent, so that the 201 software system of the existing mirror analysis server is compatible, 202 thereby avoiding redeveloping the software of the mirror server. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Next Hdr=144 | Hdr Ext Len | Routing Type | Segments Left | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Last Entry | Flags | Tag | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | | 212 | Segment List[0] (128-bit IPv6 address) | 213 | | 214 | | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | | 217 | | 218 ... 219 | | 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | | 223 | Segment List[n] (128-bit IPv6 address) | 224 | | 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | | 228 | SRv6 SPAN Header | 229 | | 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Origin Packet | 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 SRv6 SPAN Packet Format 238 Based on SRv6 packet formats, Next Header 144 is used to identify 239 SRv6 SPAN. In addition, the SRv6 SPAN Header format has been defined 240 in the first version of this document, and includes a 4-octet 241 sequence number and 12-octet portion forwarding information. 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Sequence Number (Increments per packet per session ) | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Ver | VLAN | COS |BSO|T| Session ID | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Timestamp | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | SGT |P| FT | Hw ID |D|Gra|O| 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 SRv6 SPAN Header Format 257 The various fields of the above SRv6 SPAN header are described in 258 this table: 260 Field Length (bits) Definition 262 Sequence 32 For SRv6 SPAN packets sequence number， 263 number increased per packet per session， 264 for detecting loss of mirror packet 265 by analysis server. 267 Ver 4 SRv6 SPAN Encapsulation version. 268 For SRv6 SPAN packets it is set to 0x6. 270 VLAN 12 VLAN of the frame monitored by an SRv6 SPAN 271 source session: for ingress monitor this 272 will be the original source VLAN whereas 273 for egress monitor this will be the 274 destination VLAN. 276 COS 3 Class of Service of the monitored frame. 277 Ingress or egress CoS value is to be used 278 depending on the monitor type/direction. 280 T 1 This bit indicates that the frame copy 281 encapsulated in the SRv6 SPAN packet has 282 been truncated. This occurs if the SRv6 SPAN 283 encapsulated frame exceeds the configured 284 MTU and hence has to be truncated. 286 Session ID 10 Identification associated with each SRv6 SPAN 287 (ERSPAN ID) session. Must be unique between the source 288 and the receiver(s). 290 BSO (Bad/Short/ 2 A 2-bit value indicating the integrity of 291 Oversized) the payload carried by SRv6 SPAN: 292 00 --> Good frame with no error, or 293 unknown integrity 294 11 --> Payload is a Bad Frame with CRC or 295 Alignment Error 296 01 --> Payload is a Short Frame 297 10 --> Payload is an Oversized Frame 299 Timestamp 32 The timestamp value needs to be derived 300 from a hardware clock which is 301 synchronized to the system-clock. This 32- 302 bit field should support at least a 303 timestamp granularity of 100 microseconds 304 (see the Timestamp Granularity field). 306 SGT 16 Security Group Tag of the monitored frame. 308 P 1 This bit indicates that the SRv6 SPAN payload 309 is an Ethernet protocol frame . 311 FT (Frame Type) 5 This field can be used to reconstruct the 312 original frame's encapsulation if it is 313 supported by the receiver. 314 This field may also be used by SRv6 SPAN 315 engines to indicate that the mirrored 316 frame's L2 encapsulation header (or a 317 portion of it) was skipped and not 318 included in the SRv6 SPAN packet. 319 00000 --> Ethernet frame (802.3 frame) 320 00010 --> IP Packet 321 Other values --> Reserved for future use 323 Hw (Hardware) ID 6 Unique identifier of an SRv6 SPAN engine 324 within a system. 326 D (Direction) 1 Indicates whether the original frame was 327 SRv6 SPAN'ed in ingress or in egress. 328 Ingress (0) or Egress (1). 330 Gra (Timestamp 331 Granularity) 2 Time unit to be supported for time- 332 stamping: 333 00b --> granularity = 100 microseconds 334 01b --> granularity = 100 nanoseconds 335 10b --> granularity = IEEE 1588 336 TimeRepresentation format (see definition 337 below; with nanoseconds portion stored in 338 the Timestamp field and seconds portion 339 stored in the SRv6 SPAN platform-dependent 340 sub-header) 342 struct TimeRepresentation 343 { 344 UInteger32 seconds; 345 UInteger32 nanoseconds; 346 }; 347 11b --> user configurable time unit 348 (platform dependent, for example specific 349 to an isolated non-synchronized system 350 with very high local accuracy) 352 O (Optional 353 Sub-header) 1 The O flag indicates whether or not the 354 optional platform-specific sub-header is 355 present. If it's present, the next octet 356 indicates the platform specific format 357 used (Platf ID). The SRv6 SPAN payload 358 starts after the O flag when O == 0b 359 or after 8 octets when O == 1b. 361 SRv6 SPAN Header Description 363 2.2. Future Considerations and Enhancements of the SRv6 SPAN Technology 365 In the first version of this document, the goal is to solve the 366 problem that the conventional mirroring technology is not compatible 367 with the existing SRv6 network. 369 In a later version of this document, the SRv6 SPAN technology will be 370 enhanced in three aspects: 372 * First, different requirements for mirroring capabilities in 373 multiple scenarios are met. 375 * Second, the capability of controlling a forwarding path and service 376 quality of a mirror data stream are enhanced;. 378 * Third, the capability of capturing required information is 379 enhanced. 381 SRv6 technology will be further developed, and enhancement points of 382 the SRv6 SPAN technology will be detailed in subsequent documents. 383 It is expected that the mirroring technology can be used as the 384 essential means for SRv6 network O&M and fault locating, so as to 385 facilitate the development of the SRv6 network. 387 3. Conclusion 389 The implementation of the SRv6 network mirroring function through 390 SRv6 SPAN technology is not only conducive to unifying the forwarding 391 data plane of the SRv6 network, avoiding the additional introduction 392 of GRE and other tunneling protocols, but also fully considering the 393 compatibility with the traditional mirroring message format in the 394 definition of SRv6 SPAN Header, Reduce the repeated development of 395 image analysis software to promote the development of SRv6 networks 396 and the deployment of SRv6 SPAN. 398 4. Security Considerations 400 TBD. 402 5. IANA Considerations 404 TBD. 406 Authors' Addresses 408 Zhiqiang Li 409 China Mobile 410 Beijing 100053 411 China 413 Email: lizhiqiangyjy@chinamobile.com 415 Tao Sun 416 China Mobile 417 Beijing 100053 418 China 420 Email: suntao@chinamobile.com 421 Wei Cheng 422 Centec Networks 423 Suzhou 215000 424 China 426 Email: chengw@centecnetworks.com 428 Junjie Wang 429 Centec Networks 430 Suzhou 21500 431 China 433 Email: wangjj@centecnetworks.com