idnits 2.17.00 (12 Aug 2021) /tmp/idnits32199/draft-qiu-spring-srv6-ioam-encap-model-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 : ---------------------------------------------------------------------------- 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 (December 13, 2021) is 152 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.ietf-6man-ipv6-alt-mark' is defined on line 362, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-16 == Outdated reference: A later version (-05) exists of draft-ali-spring-ioam-srv6-04 == Outdated reference: A later version (-14) exists of draft-ietf-6man-ipv6-alt-mark-12 Summary: 0 errors (**), 0 flaws (~~), 6 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: June 16, 2022 H3C Technology Co.LTD 6 December 13, 2021 8 Data Fields Encapsulation Model of In-situ OAM in SRv6 Network 9 draft-qiu-spring-srv6-ioam-encap-model-01 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 June 16, 2022. 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 field's 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 IOAM TLV in 129 SRv6 domain are already defined in [I-D.draft-ali-spring-ioam-srv6]. 130 It elaborates on the process of encapsulating IOAM data by 131 individual nodes of SRV6. However, it lacks a process for how to 132 perform IOAM measurement when encapsulating an SRV6 packet, for 133 example, in inter-AS scenarios and in the scenario where a protected 134 tunnel path exists. 136 This document defines two models for encapsulation operation of IOAM 137 data field : Pipe Model and Uniform Model. 139 3.1. Pipe Model 141 In the Pipe Model, the SRv6 network acts like a circuit when packets 142 carrying IOAM data traverse the network. Only the ingress and egress 143 nodes collect IOAM information and report to analyzer with the same 144 Flow Monitoring Identification (FlowMonID) and same type. It means 145 that only ingress node and egress node of SRv6 network are visible to 146 the analyzer. The analyzer can calculate the end-to-end performance 147 of the SRV6 network. 149 ========== SRv6 packet ========================> 151 +--Transit--(d)-...-Transit--(d)---+ 152 / (outer header) \ 153 (d) (d) 154 / \ 155 >--(D)--Ingress...............(D).................Egress--(D)-> 156 (Push) (inner header) (Pop) 158 (d) represents the data field values in the outer SRH 159 (D) represents the data field values in the encapsulated header 161 This picture shows data field encapsulation method of In-situ OAM 162 processing in the Pipe Model. The outer IOAM data fields in packet 163 have no relationship to the inner. 165 The network nodes encapsulate IOAM TLV according to local 166 configuration with a new FlowMonID and a new IOAM-Trace-Type value, 167 and do not care about the IOAM information that is already carried 168 in the packet. 170 The Pipe model is more suitable for the end-to-end measurement 171 scenarios, since the intermediate router does not need to collect 172 and report data. 174 Internet-Draft Data Encapsulation Model of IOAM TLV 176 3.2. Uniform Model 178 In the Uniform Model, all the nodes collect IOAM data according to 179 the same IOAM-Trace-Type, and report IOAM data to analyzer with the 180 same FlowMonID. So the analyzer can calculate hop-by-hop forwarding 181 performance based on the IOAM data received from all nodes in the 182 SRv6 network. 184 ========== SRv6 packet ========================> 186 +--Transit--(D)-...-Transit--(D)---+ 187 / (outer header) \ 188 (D) (D) 189 / \ 190 >--(D)--Ingress...............(D).................Egress--(D)-> 191 (Push) (inner header) (Pop) 193 (D) represents the data field values in the corresponding IOAM TLV 195 This picture shows data field encapsulation of In-situ OAM 196 processing for a Uniform Model. 198 With the Uniform model, the inner and outer IOAM data-fields are 199 synchronized, including FlowMonID IOAM-trace-Type IOAM-option-Types, 200 etc. The contents of IOAM fields are uniform before and after 201 tunnel encapsulation. The easy way to do it is to copy directly from 202 the inner IOAM TLV. 204 Uniform model is suitable for postcard IOAM in 205 Hop-by-Hop measurement scenario. Because cannot see how many routers 206 are contained in another autonomous system in inter-AS scenario, 207 Uniform mode is noneffective to passport IOAM measurement. 208 Postcard IOAM measurement in inter-AS scenario is outside the scope 209 of this document. 211 4. In-situ OAM Process Example For Uniform Model 213 +---------------------+ +---------------------+ 214 | AS1 | | AS2 | 215 +-+-+ | +-+-+ +-+-+ +-+-+ | | +-+-+ +-+-+ +-+-+ | +-+-+ 216 +CE1+--+-+PE1+--+P1 +--+PE2+-+--+-+PE3+--+P2 +--+PE4+-+--+CE2+ 217 +-+-+ | +-+-+ +-+-+ +-+-+ | | +-+-+ +-+-+ +-+-+ | +-+-+ 218 | | | | 219 +---------------------+ +---------------------+ 221 Figure 1: Example Inter-AS Scenario of In-situ OAM 223 Internet-Draft Data Encapsulation Model of IOAM TLV 225 This figure shows an example of In-situ OAM used in across SRv6 226 autonomous systems. PE1, P1 and PE2 are SRv6-capable nodes in 227 autonomous system AS1. PE3, P2, PE4 are SRv6-capable nodes in 228 autonomous system AS2. An SRv6 instantiation of a Binding SID (BSID) 229 of PE3 is used to cross autonomous system. When the traffic is 230 sent from CE1 to CE2, the process is: 232 1) PE1 receives the packets and encapsulates SRH with a list 233 of segments destined to BSID of PE3, which is instantiated as an 234 ordered list of SRv6 SIDs . As part of the SRH 235 encapsulation, AS1's ingress node PE1 adds IOAM TLV into the SRH of 236 the packets. The IOAM TLV contains FlowMonID and IOAM-trace-Type 237 fields. The FlowMonID is used to identify a monitored flow. 238 IOAM-Trace-Type is a 24-bit identifier which specifies which 239 information should be collected in this node. 241 2) When the packet flow arrives in P1, P1 collects the IOAM data 242 based on the IOAM-trace-Type field in IOAM TLV of the packet, 243 and reports the collected data to the analyzer. 245 3) When the packet flow arrives in PE3, PE3 also collects IOAM data 246 based on the IOAM-trace-Type field in IOAM TLV of packet, and 247 reports the collected data to the analyzer. After that PE3 matches 248 Binding SID with H.encaps behavior, and pushes a outer IPv6 header 249 with its own SRH according SRv6 policy of BSID, which contains an 250 SID list {PE3, P2, PE4}. 252 4) PE3 encapsulates an outer IOAM TLV to SRH in the outer IPv6 253 header according local configuration and the data fields of IOAM TLV 254 carried in packet. The outer IOAM data-fields synchronize IOAM 255 values from the inner IOAM TLV, such as FlowMonID, IOAM-trace-Type, 256 IOAM-option-Types and so on. 258 5) When the packet flow arrives in P2, the routers in AS2 collect 259 IOAM data based on the IOAM-trace-Type in IOAM TLV of the outer SRH. 261 6) PE4 removes the outer IPv6 header, and recovers the inner 262 packet. Subsequent devices continue to forward packet according to 263 the inner IPv6 header and collect IOAM data according to the inner 264 IOAM TLV. 266 Because the same FlowMonID is used throughout the forward path 267 across multiple autonomous systems, the analyzer detects and 268 identifies anomalies in the network based on the collected data 269 reported by each of the devices, so as to accurately detect the 270 delay and packet loss of each service, making the network quality 271 service level agreement (SLA) visible in real time, and achieving 272 rapid fault delimitation and location. 274 Internet-Draft Data Encapsulation Model of IOAM TLV 276 5. In-situ OAM Process Example For Pipe Model 278 The Pipe model is also illustrated using Figure 1. When the traffic 279 is sent from CE1 to CE2, the process is: 281 1) PE1 receives the packets and encapsulates SRH with a list 282 of segments destined to BSID of PE3, which is instantiated as an 283 ordered list of SRv6 SIDs . As part of the SRH 284 encapsulation, AS1's ingress node PE1 adds IOAM TLV to the SRH of 285 the packets. 287 2) When the packet arrives in P1 and PE2, P1 and PE2 collect 288 the IOAM data based on the IOAM-trace-Type field in IOAM TLV of the 289 packet, and report the collected data to the analyzer. 291 3) When the packet arrives in PE3, PE3 also collects IOAM data 292 based on the IOAM-trace-Type field in IOAM TLV of packet, and 293 reports the collected data to the analyzer. After that PE3 matches 294 Binding SID with H.encaps behavior, and pushes an outer IPv6 header 295 with its own SRH according SRv6 policy of BSID, which contains a 296 SID list {PE3, P2, PE4}. 298 4) If configuration requires, PE3 identifies target traffic flow 299 that requires IOAM measurement based on the local configuration, and 300 encapsulates the IOAM TLV in the outer SRH. Then PE3 assigns a new 301 FlowMonID to the target flow, populates the IOAM data fields with 302 the new IOAM-trace-Type and IOAM-option-Types. 304 5) When the packet flow arrives in P2, the routers in AS2 collect 305 IOAM data based on the IOAM-trace-Type in IOAM TLV of the outer SRH. 307 6) PE4 removes the outer IPv6 header, and recovers the inner 308 packet. Subsequent devices continue to forward packet according to 309 the inner IPv6 header and collect IOAM informantion according to the 310 inner IOAM TLV. 312 Because the two ASes use different FlowMonIDs for the same flow, 313 according to the FlowMonID identified by PE1, the analyzer can only 314 measure the forwarding performance of this flow between PE3 and 315 PE4 in AS2. It is not possible to measure performance data between 316 other nodes in AS2. 318 6. IANA Considerations 320 No requirements for IANA. 322 Internet-Draft Data Encapsulation Model of IOAM TLV 324 7. Security Considerations 326 TBA 328 8. Acknowledgements 330 The authors would like to thank people for their comments to this 331 work. 333 9. References 335 9.1. Normative References 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, 339 DOI 10.17487/RFC2119, March 1997, 340 . 342 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 343 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 344 May 2017, . 346 [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, 347 C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., 348 Mozes, D., Lapukhov, P., Chang, R., and Bernier, D., 349 "Data Fields for In-situ OAM", 350 draft-ietf-ippm-ioam-data-16 (work in progress), November 351 2021. 353 [I-D.draft-ali-spring-ioam-srv6] Ali, Z., Gandhi, R., Filsfils, C., 354 Brockners, F., Nainar, N., Pignataro, C., Li, C., 355 Chen, M., Dawra, G., "Segment Routing Header 356 encapsulation for In-situ OAM Data", 357 draft-ali-spring-ioam-srv6-04 (work in progress), July 358 2021. 360 9.2. Informative References 362 [I-D.ietf-6man-ipv6-alt-mark] 363 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 364 Pang, "IPv6 Application of the Alternate Marking Method", 365 draft-ietf-6man-ipv6-alt-mark-12 (work in progress), 366 October 2021. 368 Internet-Draft Data Encapsulation Model of IOAM TLV 370 Authors' Addresses 372 Yuanxiang Qiu 373 H3C Technology Co.LTD, No.466 Changhe Rd. 374 Hangzhou 310008 375 China 377 Email: qiuyuanxiang@h3c.com 379 Jinrong Ye 380 H3C Technology Co.LTD 382 Email: jrong.y@h3c.com 384 Hao Li 385 H3C Technology Co.LTD 387 Email: lihao@h3c.com