idnits 2.17.1 draft-qiu-spring-srv6-ioam-encap-model-00.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 : ---------------------------------------------------------------------------- No issues found here. 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 seems to have RFC 2119 boilerplate text. -- The document date (June 3, 2021) is 1055 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.6man-extension-header-insertion' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-ipv6-alt-mark' is defined on line 364, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-6man-ipv6-alt-mark-04 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Y.Qiu 3 Internet-Draft J.Ye 4 Intended status: Standards Track H.Li 5 Expires: December 5, 2021 H3C Technology Co.LTD 6 June 3, 2021 8 Data Fields Encapsulation Model of In-situ OAM in SRv6 Network 9 draft-qiu-spring-srv6-ioam-encap-model-00 11 Abstract 13 OAM and PM information from the SR endpoints can be piggybacked in 14 the data packet. The OAM and PM information piggybacking in the 15 data packets is also known as In-situ OAM (IOAM). IOAM records 16 OAM information within the packet while the packet traverses a 17 particular network domain. The term "in-situ" refers to the fact 18 that the IOAM data fields are added to the data packets rather than 19 being sent within probe packets specifically dedicated to OAM. 20 This document defines the data fields encapsulation model of IOAM 21 TLV in SRv6 network. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 15, 2021. 40 Internet-Draft Data Encapsulation Model of IOAM TLV 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with 52 respect to this document. Code Components extracted from this 53 document must include Simplified BSD License text as described in 54 Section 4.e of the Trust Legal Provisions and are provided without 55 warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Data Encapsulation Model of In-situ OAM . . . . . . . . . . . 4 64 3.1. Pipe Model . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Uniform Model . . . . . . . . . . . . . . . . . . . . . . 5 66 4. In-situ OAM Process Example For Uniform Model . . . . . . . . 5 67 5. In-situ OAM Process Example For Pipe Model . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 9.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 Internet-Draft Data Encapsulation Model of IOAM TLV 78 1. Introduction 80 OAM and PM information from the SR endpoints can be piggybacked in 81 the data packet. The OAM and PM information piggybacking in the 82 data packets is also known as In-situ OAM (IOAM). IOAM records 83 OAM information within the packet while the packet traverses a 84 particular network domain. The term "in-situ" refers to the fact 85 that the IOAM data fields are added to the data packets rather than 86 being sent within probe packets specifically dedicated to OAM. 88 This document defines the data fields encapsulation model of IOAM 89 TLV for the Segment Routing headend with H.Encaps encapsulation 90 behavior in SRv6 network. 92 The IOAM data fields carried are defined in 93 [I-D.ietf-ippm-ioam-data], and can be used for various use-cases 94 including Performance Measurement(PM) and Proof-of-Transit (PoT). 96 2. Conventions 98 2.1. Requirement Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in 103 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 2.2. Abbreviations 108 Abbreviations used in this document: 110 IOAM In-situ Operations, Administration, and Maintenance 112 OAM Operations, Administration, and Maintenance 114 PM Performance Measurement 116 PoT Proof-of-Transit 118 SR Segment Routing 120 SRH SRv6 Header 122 SRv6 Segment Routing with IPv6 Data plane 124 Internet-Draft Data Encapsulation Model of IOAM TLV 126 3. Data Encapsulation Model of In-situ OAM 128 The encapsulation format of IOAM TLV and where to fill it in SRv6 129 network are already defined in [I-D.draft-ali-spring-ioam-srv6]. It 130 elaborates on the process of encapsulating IOAM data by individual 131 nodes of SRV6. However, it lacks a process for how to perform IOAM 132 detection when encapsulating an SRV6 packet, For example, in 133 inter-AS scenarios and in scenarios exist to protect tunnel paths. 135 This document defines two models for IOAM data fields encapsulation 136 operation: Pipe and Uniform Models. 138 3.1. Pipe Model 140 In the Pipe Model, the SRv6 network acts like a circuit when IOAM 141 data packets traverse the network such that only the IOAM data of 142 ingress and egress nodes are collected to report to analyzer with 143 the same Flow Monitoring Identification (FlowMonID) and same type. 144 It means that only ingress node and egress node of SRv6 network are 145 visible to the analyzer. The analyzer can only calculate the 146 end-to-end performance of the SRV6 network. 148 ========== SRv6 packet ========================> 150 +--Transit--(d)-...-Transit--(d)---+ 151 / (outer header) \ 152 (d) (d) 153 / \ 154 >--(D)--Ingress...............(D).................Egress--(D)-> 155 (Push) (inner header) (Pop) 157 (d) represents the data field values in the outer SRH 158 (D) represents the data field values in the encapsulated header 160 This picture shows data field encapsulation mothod of In-situ OAM 161 processing in the Pipe Model. The outer IOAM data fields in packet 162 have no relationship to the inner. 164 The network nodes encapsulate IOAM TLV according to local 165 configuration with a new FlowMonID and a new IOAM-Trace-Type value, 166 and do not care about the IOAM information that is already carried 167 in the packet. 169 The Pipe model is more suitable for end-to-end measurement 170 scenarios, since the intermediate router does not need to collect 171 and report data. 173 Internet-Draft Data Encapsulation Model of IOAM TLV 175 3.2. Uniform Model 177 In the Uniform Model, all the nodes collect IOAM data according to 178 the same IOAM-Trace-Type, and report IOAM data to analyzer with the 179 same FlowMonID. So the analyzer can calculate hop-by-hop forwarding 180 performance based on the IOAM data received from all nodes in the 181 SRv6 network. 183 ========== SRv6 packet ========================> 185 +--Transit--(D)-...-Transit--(D)---+ 186 / (outer header) \ 187 (D) (D) 188 / \ 189 >--(D)--Ingress...............(D).................Egress--(D)-> 190 (Push) (inner header) (Pop) 192 (D) represents the data field values in the corresponding IOAM TLV 194 This picture shows data field encapsulation of In-situ OAM 195 processing for a Uniform Model. 197 With the Uniform model, the inner and outer IOAM data-fields are 198 synchronized, including FlowMonID IOAM-trace-Type IOAM-option-Types, 199 etc. The contents of IOAM fields are uniform before and after 200 tunnel encapsulation. The easy way to do it is to copy directly form 201 the inner IOAM TLV. 203 Uniform model is suitable for postcard IOAM in 204 Hop-by-Hop measurement scenario. Because cannot see how many routers 205 are contained in another autonomous system in inter-AS scenario, 206 Uniform mode is not applicable to passport IOAM measurement. 207 Postcard IOAM measurement in inter-AS scenario is outside the scope 208 of this document. 210 4. In-situ OAM Process Example For Uniform Model 212 +---------------------+ +---------------------+ 213 | AS1 | | AS2 | 214 +-+-+ | +-+-+ +-+-+ +-+-+ | | +-+-+ +-+-+ +-+-+ | +-+-+ 215 +CE1+--+-+PE1+--+P1 +--+PE2+-+--+-+PE3+--+P2 +--+PE4+-+--+CE2+ 216 +-+-+ | +-+-+ +-+-+ +-+-+ | | +-+-+ +-+-+ +-+-+ | +-+-+ 217 | | | | 218 +---------------------+ +---------------------+ 220 Figure 1: Example Inter-AS Scenario of In-situ OAM 222 Internet-Draft Data Encapsulation Model of IOAM TLV 224 This figure shows an example of In-situ OAM used in across SRv6 225 autonomous systems. PE1, P1 and PE2 are SRv6-capable nodes in 226 autonomous system AS1. PE3, P2, PE4 are SRv6-capable nodes in 227 autonomous system AS2. An SRv6 instantiation of a Binding SID (BSID) 228 of PE3 is used to cross autonomous system. When the traffic is 229 sent from CE1 to CE2, the process is: 231 1) PE1 receives the packets and encapsulates SRH with a list 232 of segments destined to BSID of PE3, which is instantiated as an 233 ordered list of SRv6 SIDs . As part of the SRH 234 encapsulation, AS1's ingress node PE1 adds IOAM TLV to the SRH of 235 the packets. The IOAM TLV contains FlowMonID and IOAM-trace-Type 236 fields. The FlowMonID is used to identify a monitored flow. 237 IOAM-Trace-Type is a 24-bit identifier which specifies which data 238 types are used in this node. 240 2) When the packet flow arrives in P1, P1 collects the IOAM data 241 based on the IOAM-trace-Type field in IOAM TLV of the packet, 242 and reports the collected data to the analyzer. 244 3) When the packet flow arrives in PE3, PE3 also collects IOAM data 245 based on the IOAM-trace-Type field in IOAM TLV of packet, and 246 reports the collected data to the analyzer. After that PE3 matches 247 Binding SID with H.encaps behavior, and pushes a outer IPv6 header 248 with its own SRH according SRv6 policy of BSID, which contains an 249 SID list {PE3, P2, PE4}. 251 4) PE3 encapsulates an outer IOAM TLV to SRH in the outer IPv6 252 header according local configuration and the data fields of IOAM TLV 253 carried in packet. The outer IOAM data-fields synchronize IOAM 254 information from the inner IOAM TLV, such as FlowMonID, 255 IOAM-trace-Type, IOAM-option-Types and so on. 257 5) When the packet flow arrives in P2, the routers in AS2 collect 258 IOAM data based on the IOAM-trace-Type in IOAM TLV of the outer SRH. 260 6) PE4 removes the outer IPv6 header, and recovers the inner 261 packet. Subsequent devices continue to forward packet according to 262 the inner IPv6 header and collect IOAM data according to the inner 263 IOAM TLV. 265 Because the same FlowMonID is used throughout the forward path 266 across multiple autonomous systems, the analyzer detects and 267 identifies anomalies in the network based on the collected data 268 reported by each of the devices, so as to accurately detect the 269 delay and packet loss of each service, making the network quality 270 service level agreement (SLA) visible in real time, and achieving 271 rapid fault delimitation and location. 273 Internet-Draft Data Encapsulation Model of IOAM TLV 275 5. In-situ OAM Process Example For Pipe Model 277 The Pipe model is also illustrated using Figure 1. When the traffic 278 is sent from CE1 to CE2, the process is: 280 1) PE1 receives the packets and encapsulates SRH with a list 281 of segments destined to BSID of PE3, which is instantiated as an 282 ordered list of SRv6 SIDs . As part of the SRH 283 encapsulation, AS1's ingress node PE1 adds IOAM TLV to the SRH of 284 the packets. 286 2) When the packet flow arrives in P1 and PE2, P1 and PE2 collect 287 the IOAM data based on the IOAM-trace-Type field in IOAM TLV of the 288 packet, and report the collected data to the analyzer. 290 3) When the packet flow arrives in PE3, PE3 also collects IOAM data 291 based on the IOAM-trace-Type field in IOAM TLV of packet, and 292 reports the collected data to the analyzer. After that PE3 matches 293 Binding SID with H.encaps behavior, and pushes a outer IPv6 header 294 with its own SRH according SRv6 policy of BSID, which contains an 295 SID list {PE3, P2, PE4}. 297 4) If configuration requires, PE3 identifies target traffic flow 298 that require IOAM detection based on the local configuration, and 299 encapsulates the IOAM TLV in the outer SRH. Then PE3 assigns a new 300 FlowMonID to the target flow, populates the IOAM data fields with 301 the new IOAM-trace-Type and IOAM-option-Types. 303 5) When the packet flow arrives in P2, the routers in AS2 collect 304 IOAM data based on the IOAM-trace-Type in IOAM TLV of the outer SRH. 306 6) PE4 removes the outer IPv6 header, and recovers the inner 307 packet. Subsequent devices continue to forward packet according to 308 the inner IPv6 header and collect IOAM data according to the inner 309 IOAM TLV. 311 Because the two AS's use different FlowMonIDs for the same flow, 312 according to the FlowMonID identified by PE1, the analyzer can only 313 calculate the forwarding performance of this flow between PE3 and 314 PE4 in AS2. It is not possible to measure performance data between 315 other nodes in AS2. 317 6. IANA Considerations 319 No requirements for IANA. 321 Internet-Draft Data Encapsulation Model of IOAM TLV 323 7. Security Considerations 325 TBA 327 8. Acknowledgements 329 The authors would like to thank people for their comments to this 330 work. 332 9. References 334 9.1. Normative References 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, 338 DOI 10.17487/RFC2119, March 1997, 339 . 341 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 342 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 343 May 2017, . 345 [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, 346 C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., 347 Mozes, D., Lapukhov, P., Chang, R., and Bernier, D., 348 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-data, 349 work in progress. 351 [I-D.draft-ali-spring-ioam-srv6] Ali, Z., Gandhi, R., Filsfils, C., 352 Brockners, F., Nainar, N., Pignataro, C., Li, C., 353 Chen, M., Dawra, G., "Segment Routing Header 354 encapsulation for In-situ OAM Data", 355 draft-ali-spring-ioam-srv6, work in progress. 357 9.2. Informative References 359 [I-D.6man-extension-header-insertion] D. Voyer, et al., "Insertion 360 of IPv6 Segment Routing Headers in a Controlled Domain", 361 draft-voyer-6man-extension-header-insertion, work in 362 progress. 364 [I-D.ietf-6man-ipv6-alt-mark] 365 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 366 Pang, "IPv6 Application of the Alternate Marking Method", 367 draft-ietf-6man-ipv6-alt-mark-04 (work in progress), 368 March 2021. 370 Internet-Draft Data Encapsulation Model of IOAM TLV 372 Authors' Addresses 374 Yuanxiang Qiu 375 H3C Technology Co.LTD, No.466 Changhe Rd. 376 Hangzhou 310008 377 China 379 Email: qiuyuanxiang@h3c.com 381 Jinrong Ye 382 H3C Technology Co.LTD 384 Email: jrong.y@h3c.com 386 Hao Li 387 H3C Technology Co.LTD 389 Email: lihao@h3c.com