idnits 2.17.1 draft-hwyh-ippm-ps-inband-flow-learning-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 (July 08, 2021) is 1022 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-6man-ipv6-alt-mark-04 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-inband-pm-encapsulation-01 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group L. Han 3 Internet-Draft M. Wang 4 Intended status: Informational China Mobile 5 Expires: January 9, 2022 F. Yang 6 J. Huang 7 Huawei Technologies 8 July 08, 2021 10 Problem Statement and Requirement for Inband Flow Learning 11 draft-hwyh-ippm-ps-inband-flow-learning-00 13 Abstract 15 Alternate-Marking (coloring) provides a method to perform packet 16 loss, delay, and jitter measurements on live traffic. At the same 17 time, on-path telemetry techniques are used to enable the collection 18 and correlation of performance information to further support 19 autonomous network operations. However, network operators still face 20 the challenge of inband flow identification in large scale 21 deployment. This document addresses the problems by introducing the 22 real network scenarios, and proposes the requirements of supporting 23 inband flow learning of flow information telemetry. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 29 "OPTIONAL" in this document are to be interpreted as described in BCP 30 14 [RFC2119] [RFC8174] when, and only when, they appear in all 31 capitals, as shown here. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 9, 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Frequent and Dynamic Change of Flows . . . . . . . . . . 3 71 3.1.1. Tidal Effect . . . . . . . . . . . . . . . . . . . . 4 72 3.1.2. UPF Expansion . . . . . . . . . . . . . . . . . . . . 4 73 3.2. Enterprise Service Demand . . . . . . . . . . . . . . . . 4 74 3.3. Large Scale Network Monitor Deployment and Maintenance . 4 75 3.4. Service Flow Path Change . . . . . . . . . . . . . . . . 5 76 4. Requirement . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 4.1. Ingress Flow Learning . . . . . . . . . . . . . . . . . . 5 78 4.2. Egress Flow Learning . . . . . . . . . . . . . . . . . . 5 79 4.3. Hop-by-Hop Path Learning . . . . . . . . . . . . . . . . 6 80 4.4. Auto Flow Aging . . . . . . . . . . . . . . . . . . . . . 6 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 85 7.2. Informative References . . . . . . . . . . . . . . . . . 6 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 88 1. Introduction 90 Alternate-Marking (coloring) [RFC8321] provides a method to perform 91 packet loss, delay, and jitter measurements on live traffic. 92 [I-D.ietf-mpls-inband-pm-encapsulation] and 93 [I-D.ietf-6man-ipv6-alt-mark] introduce the MPLS and IPv6 performance 94 measurement applications of alternate marking method respectively, 95 and specifies the encapsulations for MPLS and IPv6. On-path 96 telemetry techniques are used to enable the collection and 97 correlation of performance information from the network. By coloring 98 the real service flow and telemetry flow statistics, per-flow SLA 99 compliance monitoring becomes available and scalable for network 100 operators. When deployed in network, per-flow monitoring can be 101 applied based on CLI configuration or via Netconf YANG. 103 However, even though Netconf YANG can provide feasibility to network 104 administration, the characteristic of a flow (e.g. IP 5-tupe) can 105 vary dynamically and mislead the service flow identification. Inband 106 flow learning becomes a challenge in large scale deployment to 107 network operators. This document addresses the problems by 108 introducing the real network scenarios, and proposes the requirements 109 of supporting inband flow learning of flow information telemetry. 111 2. Terminology 113 OAM: Operations, Administration, and Maintenance 115 SLA: Service Level Agreement 117 NFV: Network Function Virtualization 119 UNI: User-Network-Interface 121 CN: Core Network 123 3. Problem Statement 125 In an alternate marking application, it is usually to utilize the 126 characteristic fields of packet to identify a service flow. For 127 example, IP 5-tuple is usually to be used as the identifier of a 128 service flow at source node. A concept of flow identifier, such as 129 Flow-ID Label Indicator [I-D.ietf-mpls-inband-pm-encapsulation] or 130 FlowMonID [I-D.ietf-6man-ipv6-alt-mark] is used to identify service 131 flow at transit or egress nodes. The change of packet data fields 132 would mislead the flow identification for flow monitoring and 133 statistics telemetry in large scale. 135 3.1. Frequent and Dynamic Change of Flows 137 In 4G/5G mobile backhaul networks, IP address of one service can be 138 changed based on location, time or even with business growth. The 139 following scenarios describes the challenges which 4G/5G mobile 140 service encounters. 142 3.1.1. Tidal Effect 144 A Tidal Effect phenomenon has been recognized as traffics between 145 base station and Core Network (CN) show repetitive patterns with 146 spatio-temporal variations. A typical example of Tidal phenomenon is 147 the traffic difference happened in day and night time of a commercial 148 and business area. In day time, eNodeB allocates more core network 149 resources when a large number of user equipment accesses eNodeB, and 150 less resources at night accordingly. The change of the number of UEs 151 and the core network resources may affect the change on source and 152 destination IP address of service flows. 154 Moreover, NFV used in core network makes the traffic change even 155 worse as the IP address at CN cannot be manually configured or even 156 predicted. In this case, it is impossible for operators to 157 statically deploy flow monitoring and statistics telemetry. 159 3.1.2. UPF Expansion 161 In 5G deployment, the increase of number of subscribers triggers the 162 expansion of UPF resources on data plane of 5G core network. After 163 new UPF resource is added, eNodeB sets up a connection to the new 164 UPF. Correspondingly, a new IP flow is created in mobile bearer 165 network. In this scenario, if flow monitoring and statistics 166 telemetry is deployed in a static mode, operators would need to 167 manually add related configurations to mobile bearer network after 168 the core network capacity is expanded, which is very difficult to 169 deploy in practice. 171 3.2. Enterprise Service Demand 173 The enterprise services usually connect different private networks 174 between Headquarter and Branches, Branches and Branches. Network 175 operator has very limited or even no information about end users. 176 Besides, information from one site could be changed from time to 177 time. Unpredictable information on enterprise customer side makes 178 impossible for network operators to set up real time flow monitoring, 179 and to avoid the omission of flow monitoring. 181 3.3. Large Scale Network Monitor Deployment and Maintenance 183 In a large-scale mobile bearer network, a large number of base 184 stations and corresponding access points may lead to a large number 185 of IP addresses in core network. From network maintenance 186 perspective, when flow monitoring and statistics telemetry is 187 deployed in a static mode, network operator had to manually set up 188 each monitoring instance between base station and core network, then 189 separately delegate configurations to a large number of network 190 entities. It is difficult for network operators to find an effective 191 way of monitoring creation and maintenance. 193 Note that traffic monitoring is comprised of uplink and downlink 194 directions, which makes twice of workload on configurations. 196 3.4. Service Flow Path Change 198 When a hop-by-hop flow monitoring is required by critical traffic for 199 deep SLA investigation, the actual forwarding path of service flow 200 and the every forwarding nodes along the path are obtained. Network 201 operator delegates different configurations to each node including 202 ingress, transit, and egress nodes on the path. 204 Once the traffic forwarding path is changed because of service flow 205 switching or route convergence, the monitoring instance on each node 206 needs to be re-deployed on the new path. In this situation, a 207 flexible and efficient deployment approach is required by network 208 operators. 210 4. Requirement 212 To face the flow deployment challenges mentioned in preceding 213 section, an approach of inband flow learning is required. It should 214 simplify the deployment of flow monitoring and achieve an automatic 215 mode of telemetry in large scale networks. 217 4.1. Ingress Flow Learning 219 On the UNI side of network node, ingress flow learning can help to 220 capture the characteristic data fields of packet and create the 221 monitoring instance when the flow is created from base station. 222 Flexible policy based on access control list (ACL) can facilitate the 223 identification of flow characteristic. For example, IP 2-tuple 224 (DIP+SIP), DSCP value, etc. 226 4.2. Egress Flow Learning 228 Similar to the requirement on ingress node, traffic egress node 229 should support the same capability of inband flow learning to create 230 traffic monitoring instance for completing a monitor. When the 231 egress node or egress port of a service flow is changed, the egress 232 node or egress port of service flow can be triggered to re-learn and 233 re-monitor the service flow. 235 4.3. Hop-by-Hop Path Learning 237 When hop-by-hop flow monitoring and telemetry is required, the flow 238 learning and monitor deployment should be created on all the ingress, 239 transit, and egress nodes that service flows pass through. When the 240 path of a service flow changes due to the service switching or 241 network convergence, the service flow re-triggers the flow learning 242 on the new path and starts the new monitoring of service flow. 244 4.4. Auto Flow Aging 246 In all the inband flow learning scenarios described above, when the 247 path of a service flow changes, the flow learning on new path is 248 triggered and new monitoring instances are created on devices. 249 Regarding the monitoring instances that have been created before the 250 path change, if there is no traffic detected within a certain period 251 of time, automatic aging and resource recycle should be supported. 253 5. IANA Considerations 255 This document has no request to IANA 257 6. Security Considerations 259 TBD 261 7. References 263 7.1. Normative References 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, 267 DOI 10.17487/RFC2119, March 1997, 268 . 270 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 271 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 272 May 2017, . 274 7.2. Informative References 276 [I-D.ietf-6man-ipv6-alt-mark] 277 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 278 Pang, "IPv6 Application of the Alternate Marking Method", 279 draft-ietf-6man-ipv6-alt-mark-04 (work in progress), March 280 2021. 282 [I-D.ietf-mpls-inband-pm-encapsulation] 283 Cheng, W., Min, X., Zhou, T., Dong, X., and Y. Peleg, 284 "Encapsulation For MPLS Performance Measurement with 285 Alternate Marking Method", draft-ietf-mpls-inband-pm- 286 encapsulation-01 (work in progress), April 2021. 288 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 289 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 290 "Alternate-Marking Method for Passive and Hybrid 291 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 292 January 2018, . 294 Authors' Addresses 296 Liuyan Han 297 China Mobile 298 Beijing 299 China 301 Email: hanliuyan@chinamobile.com 303 Minxue Wang 304 China Mobile 305 Beijing 306 China 308 Email: wangminxue@chinamobile.com 310 Fan Yang 311 Huawei Technologies 312 Beijing 313 China 315 Email: shirley.yangfan@huawei.com 317 Jinming Huang 318 Huawei Technologies 319 Dongguan 320 China 322 Email: zhangshengli4@huawei.com