idnits 2.17.1 draft-song-ippm-ioam-tunnel-mode-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. 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 25, 2018) is 2130 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-brockners-ippm-ioam-geneve-01 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-02 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ippm H. Song, Ed. 3 Internet-Draft Z. Li 4 Intended status: Informational T. Zhou 5 Expires: December 27, 2018 Z. Wang 6 Huawei 7 June 25, 2018 9 In-situ OAM Processing in Tunnels 10 draft-song-ippm-ioam-tunnel-mode-00 12 Abstract 14 This document describes the In-situ OAM (iOAM) processing behavior in 15 a network with tunnels. Specifically, the iOAM processing in tunnels 16 with the uniform model and the pipe model is discussed. The 17 procedure is applicable to different type of tunnel protocols. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 27, 2018. 42 Copyright Notice 44 Copyright (c) 2018 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 respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Uniform Model . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. U1: IOAM Domain Starts and Ends outside of a Tunnel . . . 3 62 2.2. U2: IOAM Domain Starts and Ends within a Tunnel . . . . . 4 63 2.3. U3: IOAM Domain Starts and Ends at any Nodes . . . . . . 4 64 2.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Pipe Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. P1: IOAM Domain Starts and Ends outside of a Tunnel . . . 5 67 3.2. P2: IOAM Domain Starts and Ends within a Tunnel . . . . . 5 68 3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 72 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 9.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Motivation 81 In-situ OAM (iOAM) records OAM data associated with user packets 82 while these packets traverse a network 83 [I-D.brockners-inband-oam-requirements]. The iOAM instruction and 84 data are kept in an iOAM header which is defined in 85 [I-D.ietf-ippm-ioam-data]. The iOAM header needs to be encapsulated 86 in a packet's transport protocol header in order to be processed by 87 the network nodes who are capable of iOAM processing. So far, the 88 iOAM header encapsulation methods have been defined for several 89 protocols, including IPv6, VXLAN-GPE, NSH, SRv6 90 [I-D.brockners-inband-oam-transport],[I-D.ietf-sfc-ioam-nsh], GENEVE 91 [I-D.brockners-ippm-ioam-geneve], GRE [I-D.weis-ippm-ioam-gre], and 92 some others. 94 While the original scope of iOAM is purposely confined to a single 95 network domain for simplicity, the authentic E2E data collection 96 capability of iOAM is invaluable to network operators. In reality, 97 especially in carrier networks, a user packet may traverse several 98 network domains and pass through various tunnels for QoS, traffic 99 engineering, or public network traversal. To extend the scope of 100 iOAM's applicability and fully realize iOAM's potential, we need to 101 consider various network conditions. In this document, we describe 102 how iOAM should be processed in a network with tunnels. 104 A tunneling protocol usually needs to add another layer of protocol 105 header (i.e., the tunnel header) over the original packet. Within a 106 tunnel, only the outermost tunnel header is supposed to be processed 107 by a network node. Therefore, depending on the locations where the 108 iOAM header is encapsulated/decapsulated and the tunnel operation 109 mode, the iOAM processing is also different. 111 In general, there are two modes of tunnel operations: the Uniform 112 Model and the Pipe Model. The Uniform Model treats the nodes in a 113 tunnel uniformly as the nodes outside of the tunnel on an E2E path. 114 On the contrary, the Pipe Model abstracts all the nodes between the 115 tunnel ingress and egress as a circuit so no nodes in the tunnel is 116 visible to the nodes outside of the tunnel. The iOAM processing 117 behavior is discussed for each mode as follows. 119 2. Uniform Model 121 2.1. U1: IOAM Domain Starts and Ends outside of a Tunnel 123 In this case, a tunnel is fully in between the head node and the end 124 node of an iOAM path. This includes the situation that the tunnel 125 ingress coincides with the iOAM head node and/or the tunnel egress 126 coincides with the iOAM end node. The iOAM header handling for 127 different situation is described as follows: 129 o iOAM head node is outside of the tunnel: The iOAM header is 130 encapsulated into the original packet and processed. 132 o iOAM head node is the tunnel ingress: The iOAM header is 133 encapsulated into the original packet and processed. The iOAM 134 header is copied from the original packet and encapsulated into 135 the underlay protocol header. 137 o iOAM end node is outside of the tunnel: The iOAM header is 138 decapsulated from the original packet after iOAM processing. 140 o iOAM end node is the tunnel egress: The iOAM header in the 141 underlay protocol header is processed as usual. After the tunnel 142 header is removed and the original packet is exposed, the iOAM 143 header is copied to overwrite the original packet's iOAM header. 145 After the iOAM processing is finished, the iOAM header is removed 146 from the original packet. 148 o Other nodes in the iOAM domain: If the node is outside or inside 149 of the tunnel, the iOAM header encapsulated in the outermost 150 protocol header is processed. If the node is the tunnel ingress, 151 the iOAM header in the original packet needs to be copied and 152 encapsulated into the underlay protocol header. If the node is 153 the tunnel egress, the iOAM header in the underlay protocol header 154 needs to be copied to overwrite the iOAM header in the original 155 packet. 157 2.2. U2: IOAM Domain Starts and Ends within a Tunnel 159 There is nothing special about this case since the transport network 160 will not be aware of the tunnel. In this case, the iOAM is processed 161 as usual. 163 2.3. U3: IOAM Domain Starts and Ends at any Nodes 165 For extra flexibility, the iOAM domain can be configured to start and 166 end at any node (e.g., in or out of a tunnel). The iOAM header 167 handling for different situation is described as follows: 169 o iOAM head node is outside of the tunnel: The iOAM header is 170 encapsulated in the original packet. 172 o iOAM head node is the tunnel ingress: The iOAM header is 173 encapsulated in the original packet first and processed. Then the 174 iOAM header is copied from the original packet and encapsulated 175 into the underlay protocol header. Meanwhile, the iOAM header in 176 the original packet must be removed. 178 o iOAM head node is in the tunnel: The iOAM header is encapsulated 179 in the underlay protocol header and processed. 181 o iOAM head node is the tunnel egress: The iOAM header is 182 encapsulated in the underlay protocol header first and processed. 183 When the tunnel header is removed, the iOAM header is copied from 184 the underlay protocol header and encapsulated into the original 185 packet. 187 o iOAM end node is outside of the tunnel: The iOAM header is 188 decapsulated from the original packet. 190 o iOAM end node is the tunnel ingress: The iOAM header is 191 decapsulated from the original packet. 193 o iOAM end node is in the tunnel: The iOAM header is decapsulated 194 from the underlay protocol header. 196 o iOAM end node is the tunnel egress: The iOAM header is removed 197 with the underlay protocol header. 199 o Tunnel ingress is in the IOAM domain: The iOAM header is 200 decapsulated from the original packet and encapsulated in the 201 underlay protocol header. 203 o Tunnel egress is in the iOAM domain: The iOAM header in the 204 underlay protocol header is encapsulated into the original packet. 206 2.4. Discussion 208 U1 achieves the best implementation efficiency since it eliminates 209 one encapsulation or decapsulation operation while U3 achieves the 210 best flexibility and reduces the packet overhead. 212 Since a tunnel usually aggregates multiple flows, so U2 (or U3 when 213 the iOAM head node is in a tunnel) can only conduct iOAM at the 214 tunnel granularity and on aggregated flows. 216 3. Pipe Model 218 3.1. P1: IOAM Domain Starts and Ends outside of a Tunnel 220 This case includes the situation that the tunnel ingress coincides 221 with the iOAM head node and/or the tunnel egress coincides with the 222 iOAM end node. 224 In this mode, the iOAM header only exists in the original packet. It 225 is not copied to the tunnel header. Within the tunnel, the iOAM 226 header is invisible to the underlay network so it is not processed. 227 At the tunnel ingress, the iOAM header is processed before the tunnel 228 header is applied. At the tunnel egress, the iOAM header is 229 processed after the tunnel header is removed. To the iOAM header, 230 the entire tunnel appears to be just one hop. 232 3.2. P2: IOAM Domain Starts and Ends within a Tunnel 234 This mode is identical to U2. 236 3.3. Discussion 238 In P1, the hop-by-hop iOAM data is missing for the tunnel. However, 239 this mode also provides a convenient way to pass through third party 240 tunnels in which either the iOAM is not supported or the tunnel 241 operators do not participate in the iOAM service. 243 On the other hand, the tunnel operators can support iOAM 244 independently to monitor the tunnel performance using the mode of P2. 245 In this case, U1 can also be applied without any confliction, so both 246 underlay and overlay can be monitored by different entities. 248 When iOAM works in the E2E operation mode as described in 249 [I-D.ietf-ippm-ioam-data], any tunnel on the path should be 250 configured to the Pipe model in order to avoid the unnecessary iOAM 251 header encapsulation/decapsulation. 253 4. Examples 255 Examples will be added in future revisions. 257 5. Security Considerations 259 TBD 261 6. IANA Considerations 263 N/A 265 7. Contributors 267 TBD. 269 8. Acknowledgments 271 TBD. 273 9. References 275 9.1. Normative References 277 [I-D.brockners-inband-oam-transport] 278 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 279 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 280 D., Lapukhov, P., and R. Chang, "Encapsulations for In- 281 situ OAM Data", draft-brockners-inband-oam-transport-05 282 (work in progress), July 2017. 284 [I-D.brockners-ippm-ioam-geneve] 285 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 286 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 287 D., Lapukhov, P., and R. Chang, "Geneve encapsulation for 288 In-situ OAM Data", draft-brockners-ippm-ioam-geneve-01 289 (work in progress), June 2018. 291 [I-D.ietf-ippm-ioam-data] 292 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 293 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 294 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 295 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 296 data-02 (work in progress), March 2018. 298 [I-D.ietf-sfc-ioam-nsh] 299 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 300 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 301 D., Lapukhov, P., and R. Chang, "NSH Encapsulation for In- 302 situ OAM Data", draft-ietf-sfc-ioam-nsh-00 (work in 303 progress), May 2018. 305 [I-D.weis-ippm-ioam-gre] 306 Weis, B., Brockners, F., crhill@cisco.com, c., Bhandari, 307 S., Govindan, V., Pignataro, C., Gredler, H., Leddy, J., 308 Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, 309 P., and M. Spiegel, "GRE Encapsulation for In-situ OAM 310 Data", draft-weis-ippm-ioam-gre-00 (work in progress), 311 March 2018. 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, 315 DOI 10.17487/RFC2119, March 1997, 316 . 318 9.2. Informative References 320 [I-D.brockners-inband-oam-requirements] 321 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 322 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 323 T., <>, P., and r. remy@barefootnetworks.com, 324 "Requirements for In-situ OAM", draft-brockners-inband- 325 oam-requirements-03 (work in progress), March 2017. 327 Authors' Addresses 328 Haoyu Song (editor) 329 Huawei 330 2330 Central Expressway 331 Santa Clara 332 USA 334 Email: haoyu.song@huawei.com 336 Zhenbin Li 337 Huawei 338 156 Beiqing Road 339 Beijing, 100095 340 P.R. China 342 Email: lizhenbin@huawei.com 344 Tianran Zhou 345 Huawei 346 156 Beiqing Road 347 Beijing, 100095 348 P.R. China 350 Email: zhoutianran@huawei.com 352 Zhongzhen Wang 353 Huawei 354 156 Beiqing Road 355 Beijing, 100095 356 P.R. China 358 Email: wangzhongzhen@huawei.com