idnits 2.17.1 draft-mirsky-detnet-ip-oam-02.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 date (March 23, 2020) is 1488 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-05 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Informational M. Chen 5 Expires: September 24, 2020 Huawei 6 D. Black 7 Dell EMC 8 March 23, 2020 10 Operations, Administration and Maintenance (OAM) for Deterministic 11 Networks (DetNet) with IP Data Plane 12 draft-mirsky-detnet-ip-oam-02 14 Abstract 16 This document defines the principals for using Operations, 17 Administration, and Maintenance protocols and mechanisms in the 18 Deterministic Networking networks with IP data plane. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 24, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions used in this document . . . . . . . . . . . . . . 2 56 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Active OAM for DetNet Networks with IP Data Plane . . . . . . 3 59 3.1. Active OAM Using DetNet-in-UDP Encapsulation . . . . . . 4 60 3.2. Mapping Active OAM and IP DetNet flows . . . . . . . . . 4 61 3.3. Active OAM Using GRE-in-UDP Encapsulation . . . . . . . . 5 62 4. Use of Hybrid OAM in DetNet . . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informational References . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 [RFC8655] introduces and explains Deterministic Networks (DetNet) 74 architecture. 76 Operations, Administration and Maintenance (OAM) protocols are used 77 to detect, localize defects in the network, and monitor network 78 performance. Some OAM functions, e.g., failure detection, work in 79 the network proactively, while others, e.g., defect localization, 80 usually performed on-demand. These tasks achieved by a combination 81 of active and hybrid, as defined in [RFC7799], OAM methods. 83 [I-D.mirsky-detnet-mpls-oam] lists the functional requirements toward 84 OAM for DetNet domain. The list can further be used for gap analysis 85 of available OAM tools to identify possible enhancements of existing 86 or whether new OAM tools are required to support proactive and on- 87 demand path monitoring and service validation. Also, the document 88 defines the OAM use principals for the DetNet networks with IP data 89 plane. 91 2. Conventions used in this document 92 2.1. Terminology 94 The term "DetNet OAM" used in this document interchangeably with 95 longer version "set of OAM protocols, methods and tools for 96 Deterministic Networks". 98 DetNet Deterministic Networks 100 DiffServ Differentiated Services 102 OAM: Operations, Administration and Maintenance 104 PREF Packet Replication and Elimination Function 106 POF Packet Ordering Function 108 RDI Remote Defect Indication 110 ICMP Internet Control Message Protocol 112 Underlay Network or Underlay Layer: The network that provides 113 connectivity between the DetNet nodes. MPLS network providing LSP 114 connectivity between DetNet nodes is an example of the underlay 115 layer. 117 DetNet Node - a node that is an actor in the DetNet domain. DetNet 118 domain edge node and node that performs PREF within the domain are 119 examples of DetNet node. 121 2.2. Keywords 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 3. Active OAM for DetNet Networks with IP Data Plane 131 OAM protocols and mechanisms act within the data plane of the 132 particular networking layer. And thus it is critical that the data 133 plane encapsulation supports OAM mechanisms in such a way that DetNet 134 OAM packets are in-band with a DetNet flow being monitored, i.e., 135 DetNet OAM test packets follow precisely the same path as DetNet data 136 plane traffic both for unidirectional and bi-directional DetNet 137 paths. 139 The DetNet data plane encapsulation in a transport network with IP 140 encapsulations specified in Section 6 of [I-D.ietf-detnet-ip]. For 141 the IP underlay network, DetNet flows are identified by the ordered 142 match to the provisioned information set that, among other elements, 143 includes the IP protocol, source port number, destination port 144 number. Active IP OAM protocols like Bidirectional Forwarding 145 Detection (BFD) [RFC5880] or STAMP [RFC8762], use UDP transport and 146 the well-known UDP port numbers as the destination port. Thus a 147 DetNet node MUST be able to associate an IP DetNet flow with the 148 particular test session to ensure that test packets experience the 149 same treatment as the DetNet flow packets. 151 Most of on-demand failure detection and localization in IP networks 152 is being done by using the Internet Control Message Protocol (ICMP) 153 Echo Request, Echo Reply and the set of defined error messages, e.g., 154 Destination Unreachable, with the more detailed information provided 155 through code points. [RFC0792] and [RFC4443] define the ICMP for 156 IPv4 and IPv6 networks, respectively. Because ICMP is another IP 157 protocol like, for example, UDP, a DetNet node MUST able to associate 158 an ICMP packet generated by the specified IP DetNet node and 159 addressed to the another IP DetnNet node with an IP DetNet flow 160 between this pair of endpoints. 162 3.1. Active OAM Using DetNet-in-UDP Encapsulation 164 Active OAM in IP DetNet can be realized using DetNet-in-UDP 165 encapsulation [Ed.note: Do we define it in this document or start a 166 new one?]. Using DetNet-in-UDP tunnel between IP DetNet nodes 167 ensures that active OAM test packets are fate-sharing with the 168 packets of the being monitored IP DetNet flow. As a result, a test 169 packet shares the tunnel with IP DetNet flow and shares the fate, 170 statistically speaking, of the IP DetNet flow being monitored. 172 3.2. Mapping Active OAM and IP DetNet flows 174 IP OAM protocols that use UDP transport, e.g., BFD and STAMP, can be 175 used to detect failures or performance degradation that affects an IP 176 DetNet flow. When the UDP destination port number used by the OAM 177 protocol is one of the assigned by IANA, then the UDP source port can 178 be used to achieve co-routedness of OAM, and the monitored IP DetNet 179 flow in the multipath environments, e.g., LAG or ECMP. To maximize 180 the accuracy of OAM results in detecting failures and monitoring 181 performance of IP DetNet, test packets should receive the same 182 treatment by the nodes as experienced by the IP DetNet packet. 183 Hence, the DSCP value used for a test packet MUST be mapped to 184 DetNet. 186 3.3. Active OAM Using GRE-in-UDP Encapsulation 188 [RFC8086] has defined the method of encapsulating GRE (Generic 189 Routing Encapsulation) headers in UDP. GRE-in-UDP encapsulation can 190 be used for IP DetNet OAM as it eases the task of mapping an OAM test 191 session to a particular IP DetNet flow that is identified by N-tuple. 192 Matching a GRE-in-UDP tunnel to the monitored IP DetNet flow enables 193 the use of Y.1731/G.8013 [ITU-T.1731] as a comprehensive toolset of 194 OAM. The Protocol Type field in GRE header MUST be set to 0x8902 195 assigned by IANA to IEEE 802.1ag Connectivity Fault Management (CFM) 196 Protocol / ITU-T Recommendation Y.1731. Y.1731/G.8013 supports 197 necessary for IP DetNet OAM functions, i.e., continuity check, one- 198 way packet loss and packet delay measurement. 200 4. Use of Hybrid OAM in DetNet 202 Hybrid OAM methods are used in performance monitoring and defined in 203 [RFC7799] as: 205 Hybrid Methods are Methods of Measurement that use a combination 206 of Active Methods and Passive Methods. 208 A hybrid measurement method may produce metrics as close to passive, 209 but it still alters something in a data packet even if that is the 210 value of a designated field in the packet encapsulation. One example 211 of such a hybrid measurement method is the Alternate Marking method 212 (AMM) described in [RFC8321]. One of the advantages of the use of 213 AMM in a DetNet domain with IP data plane is that the marking is 214 applied to a data flow, thus ensuring that a measured metrics are 215 directly applicable to the DetNet flow. 217 5. IANA Considerations 219 This document does not have any requests for IANA allocation. This 220 section can be deleted before the publication of the draft. 222 6. Security Considerations 224 This document describes the applicability of the existing Fault 225 Management and Performance Monitoring IP OAM protocols, and does not 226 raise any security concerns or issues in addition to ones common to 227 networking or already documented for the referenced DetNet and OAM 228 protocols. 230 7. Acknowledgment 232 TBA 234 8. References 236 8.1. Normative References 238 [I-D.ietf-detnet-ip] 239 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 240 and S. Bryant, "DetNet Data Plane: IP", draft-ietf-detnet- 241 ip-05 (work in progress), February 2020. 243 [I-D.mirsky-detnet-mpls-oam] 244 Mirsky, G. and M. Chen, "Operations, Administration and 245 Maintenance (OAM) for Deterministic Networks (DetNet) with 246 MPLS Data Plane", draft-mirsky-detnet-mpls-oam-01 (work in 247 progress), January 2020. 249 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 250 RFC 792, DOI 10.17487/RFC0792, September 1981, 251 . 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, 255 DOI 10.17487/RFC2119, March 1997, 256 . 258 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 259 Control Message Protocol (ICMPv6) for the Internet 260 Protocol Version 6 (IPv6) Specification", STD 89, 261 RFC 4443, DOI 10.17487/RFC4443, March 2006, 262 . 264 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 265 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 266 March 2017, . 268 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 269 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 270 May 2017, . 272 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 273 "Deterministic Networking Architecture", RFC 8655, 274 DOI 10.17487/RFC8655, October 2019, 275 . 277 8.2. Informational References 279 [ITU-T.1731] 280 ITU-T, "Operations, administration and maintenance (OAM) 281 functions and mechanisms for Ethernet-based networks", 282 ITU-T G.8013/Y.1731, August 2015. 284 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 285 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 286 . 288 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 289 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 290 May 2016, . 292 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 293 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 294 "Alternate-Marking Method for Passive and Hybrid 295 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 296 January 2018, . 298 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 299 Two-Way Active Measurement Protocol", RFC 8762, 300 DOI 10.17487/RFC8762, March 2020, 301 . 303 Authors' Addresses 305 Greg Mirsky 306 ZTE Corp. 308 Email: gregimirsky@gmail.com 310 Mach(Guoyi) Chen 311 Huawei 313 Email: mach.chen@huawei.com 315 David Black 316 Dell EMC 317 176 South Street 318 Hopkinton, MA 01748 319 United States of America 321 Email: david.black@dell.com