idnits 2.17.1 draft-ooamdt-rtgwg-demand-cc-cv-03.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 10, 2017) is 2594 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) == Outdated reference: A later version (-12) exists of draft-ietf-bier-mpls-encapsulation-06 == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-03 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-03 ** Downref: Normative reference to an Informational draft: draft-ietf-nvo3-vxlan-gpe (ref. 'I-D.ietf-nvo3-vxlan-gpe') == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-12 == Outdated reference: A later version (-04) exists of draft-ooamdt-rtgwg-ooam-header-02 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track N. Kumar 5 Expires: September 11, 2017 D. Kumar 6 Cisco Systems, Inc. 7 M. Chen 8 Y. Li 9 Huawei Technologies 10 D. Dolson 11 Sandvine 12 March 10, 2017 14 Echo Request and Echo Reply for Overlay Networks 15 draft-ooamdt-rtgwg-demand-cc-cv-03 17 Abstract 19 This document defines Overlay Echo Request and Echo Reply that enable 20 on-demand Continuity Check, Connectivity Verification among other 21 operations in overlay networks. 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 http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 11, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Conventions used in this document . . . . . . . . . . . . 2 59 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 2 60 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 61 2. On-demand Continuity Check and Connectivity Verification . . 3 62 2.1. Requirements Towards On-demand CC/CV OAM . . . . . . . . 3 63 2.2. Proposed Solution . . . . . . . . . . . . . . . . . . . . 4 64 2.3. Overlay Echo Request Transmission . . . . . . . . . . . . 5 65 2.4. Overlay Echo Request Reception . . . . . . . . . . . . . 6 66 2.5. Overlay Echo Reply Transmission . . . . . . . . . . . . . 6 67 2.6. Overlay Echo Reply Reception . . . . . . . . . . . . . . 6 68 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Overlay Echo Request/Echo Reply Type . . . . . . . . . . 6 70 3.2. Overlay Ping Parameters . . . . . . . . . . . . . . . . . 6 71 3.3. Overlay Echo Request/Echo Reply Message Types . . . . . . 6 72 3.4. Overlay Echo Reply Modes . . . . . . . . . . . . . . . . 7 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 9 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 7.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 Operations, Administration, and Maintenance (OAM) toolset provides 84 methods for fault management and performance monitoring in each layer 85 of the network, in order to improve their ability to support services 86 with guaranteed and strict Service Level Agreements (SLAs) while 87 reducing operational costs. 89 1.1. Conventions used in this document 91 1.1.1. Terminology 93 Term "Overlay OAM" used in this document interchangeably with longer 94 version "set of OAM protocols, methods and tools for Overlay 95 networks". And "Overlay ping" is used interchangeably with longer 96 version Overlay Echo Request/Reply. 98 CC Continuity Check 100 CV Connectivity Verification 102 ECMP Equal Cost Multipath 104 FM Fault Management 106 Geneve Generic Network Virtualization Encapsulation 108 GUE Generic UDP Encapsulation 110 MPLS Multiprotocol Label Switching 112 NVO3 Network Virtualization Overlays 114 OAM Operations, Administration, and Maintenance 116 SFC Service Function Chaining 118 SFP Service Function Path 120 VXLAN Virtual eXtensible Local Area Network 122 VXLAN-GPE Generic Protocol Extension for VXLAN 124 1.1.2. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 [RFC2119]. 131 2. On-demand Continuity Check and Connectivity Verification 133 2.1. Requirements Towards On-demand CC/CV OAM 135 Availability, not as performance metric, is understood as ability to 136 reach the node, i.e. the fact that path between ingress and egress 137 does exist. Such OAM mechanism also referred as Continuity Check 138 (CC). Connectivity Verification (CV) extends Continuity Check 139 functionality in order to provide confirmation that the desired 140 source is connected to the desired sink. 142 Echo Request/Reply OAM mechanism enables detection of the loss of 143 continuity defect, its localization and collection information in 144 order to discover root cause. These are requirements considered: 146 REQ#1: MUST support fault localization of Loss of Continuity check 147 at Overlay layer. 149 REQ#2: MAY support fault localization of Loss of Continuity check 150 at transport layer. 152 REQ#3: MUST support tracing path in overlay network through the 153 overlay nodes. 155 REQ#4: MAY support tracing path in underlay network connecting 156 overlay border nodes. 158 REQ#5: MAY support verification of the mapping between its data 159 plane state and client layer services. 161 REQ#6: MUST have the ability to discover and exercise equal cost 162 multipath (ECMP) paths in its underlay network. 164 REQ#7: MUST be able to trigger on-demand FM with responses being 165 directed towards initiator of such proxy request. 167 2.2. Proposed Solution 169 The format of the Echo Request/Echo Reply control packet is to 170 support ping and traceroute functionality in overlay networks 171 Figure 1 resembles the format of MPLS LSP Ping [RFC4379] with some 172 exceptions. 174 0 1 2 3 175 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Version Number | Global Flags | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Message Type | Reply mode | Return Code | Return S.code | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Sender's Handle | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Sequence Number | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 ~ TLVs ~ 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 1: Overlay OAM Ping format 190 The interpretation of the fields is as following: 192 The Version reflects the current version. The version number is 193 to be incremented whenever a change is made that affects the 194 ability of an implementation to correctly parse or process control 195 packet. 197 The Global Flags is a bit vector field 199 The Message Type filed reflects the type of the packet. Value 200 TBA2 identifies Echo Request and TBA3 - Echo Reply 202 The Reply Mode defines the type of the return path requested by 203 the sender of the Echo Request. 205 Return Codes and Subcodes can be used to inform the sender about 206 result of processing its request. 208 The Sender's Handle is filled in by the sender, and returned 209 unchanged by the receiver in the Echo Reply. 211 The Sequence Number is assigned by the sender and can be (for 212 example) used to detect missed replies. 214 TLVs (Type-Length-Value tuples) have the two octets long Type 215 field, two octets long Length field that is length of the Value 216 field in octets. 218 2.3. Overlay Echo Request Transmission 220 Overlay Echo Request control packet MUST use the appropriate 221 encapsulation of the monitored overlay network. Overlay network 222 encapsulation MUST identify Echo Request as OAM packet. Overlay 223 encapsulation uses different methods to identify OAM payload 224 [I-D.ietf-nvo3-vxlan-gpe], [I-D.ietf-nvo3-gue], 225 [I-D.ietf-nvo3-geneve], 226 [I-D.ietf-sfc-nsh],[I-D.ietf-bier-mpls-encapsulation]. Overlay 227 network's header MUST be immediately followed by the Overlay OAM 228 Header [I-D.ooamdt-rtgwg-ooam-header]. Message Type field in the 229 Overlay OAM Header MUST be set to Overlay Echo Request value (TBA2). 231 Value of the Reply Mode field MAY be set to: 233 o Do Not Reply (TBA4) if one-way monitoring is desired. If Echo 234 Request is used to measure synthetic packet loss, the receiver MAY 235 report loss measurement results to a remote node. 237 o Reply via an IPv4/IPv6 UDP Packet (TBA5) value likely will be the 238 most used. 240 o Reply via Application Level Control Channel (TBA6) value if the 241 overlay network MAY have bi-directional paths. 243 o Reply via Specified Path (TBA7) value in order to enforce use of 244 the particular return path specified in the included TLV to verify 245 bi-directional continuity and also increase robustness of the 246 monitoring by selecting more stable path. 248 2.4. Overlay Echo Request Reception 250 2.5. Overlay Echo Reply Transmission 252 The Reply Mode field directs whether and how the Echo Reply message 253 should be sent. The sender of the Echo Request MAY use TLVs to 254 request that corresponding Echo Reply be sent using the specified 255 path. Value TBA3 is referred as "Do not reply" mode and suppresses 256 transmission of Echo Reply packet. Default value (TBA5) for the 257 Reply mode field requests the responder to send the Echo Reply packet 258 out-of-band as IPv4 or IPv6 UDP packet. [Selection of destination 259 and source IP addresses and UDP port numbers to be provided in the 260 next update.] 262 2.6. Overlay Echo Reply Reception 264 3. IANA Considerations 266 3.1. Overlay Echo Request/Echo Reply Type 268 IANA is requested to assign new type from the Overlay OAM Protocol 269 Types registry as follows: 271 +-------+---------------------------------+---------------+ 272 | Value | Description | Reference | 273 +-------+---------------------------------+---------------+ 274 | TBA1 | Overlay Echo Request/Echo Reply | This document | 275 +-------+---------------------------------+---------------+ 277 Table 1: Overlay Echo Request/Echo Reply Type 279 3.2. Overlay Ping Parameters 281 IANA is requested to create new Overlay Echo Request/Echo Reply 282 Parameters registry. 284 3.3. Overlay Echo Request/Echo Reply Message Types 286 IANA is requested to create in the Overlay Echo Request/Echo Reply 287 Parameters registry the new sub-registry Message Types. All code 288 points in the range 1 through 191 in this registry shall be allocated 289 according to the "IETF Review" procedure as specified in [RFC5226] 290 and assign values as follows: 292 +------------+----------------------+-------------------------+ 293 | Value | Description | Reference | 294 +------------+----------------------+-------------------------+ 295 | 0 | Reserved | | 296 | TBA2 | Overlay Echo Request | This document | 297 | TBA3 | Overlay Echo Reply | This document | 298 | TBA3+1-191 | Unassigned | IETF Review | 299 | 192-251 | Unassigned | First Come First Served | 300 | 252-254 | Unassigned | Private Use | 301 | 255 | Reserved | | 302 +------------+----------------------+-------------------------+ 304 Table 2: Overlay Echo Request/Echo Reply Message Types 306 3.4. Overlay Echo Reply Modes 308 IANA is requested to create in the Overlay Echo Request/Echo Reply 309 Parameters registry the new sub-registry Reply Modes All code points 310 in the range 1 through 191 in this registry shall be allocated 311 according to the "IETF Review" procedure as specified in [RFC5226] 312 and assign values as follows: 314 +------------+---------------------------------+--------------------+ 315 | Value | Description | Reference | 316 +------------+---------------------------------+--------------------+ 317 | 0 | Reserved | | 318 | TBA4 | Do Not Reply | This document | 319 | TBA5 | Reply via an IPv4/IPv6 UDP | This document | 320 | | Packet | | 321 | TBA6 | Reply via Application Level | This document | 322 | | Control Channel | | 323 | TBA7 | Reply via Specified Path | This document | 324 | TBA7+1-191 | Unassigned | IETF Review | 325 | 192-251 | Unassigned | First Come First | 326 | | | Served | 327 | 252-254 | Unassigned | Private Use | 328 | 255 | Reserved | | 329 +------------+---------------------------------+--------------------+ 331 Table 3: Overlay Echo Reply Modes 333 4. Security Considerations 335 Overlay Echo Request/Reply operates within the domain of the overlay 336 network and thus inherits any security considerations that apply to 337 the use of that overlay technology and, consequently, underlay data 338 plane. Also, the security needs for Overlay Echo Request/Reply are 339 similar to those of ICMP ping [RFC0792], [RFC4443] and MPLS LSP ping 340 [I-D.ietf-mpls-rfc4379bis]. 342 There are at least three approaches of attacking a node in the 343 overlay network using the mechanisms defined in the document. One is 344 a Denial-of-Service attack, by sending Overlay ping to overload a 345 node in the overlay network. The second may use spoofing, hijacking, 346 replying, or otherwise tampering with Overlay Echo Requests and/or 347 Replies to misrepresent, alter operator's view of the state of the 348 overlay network. The third is an unauthorized source using an 349 Overlay Echo Request/Reply to obtain information about the overlay 350 and/or underlay network. 352 To mitigate potential Denial-of-Service attacks, it is RECOMMENDED 353 that implementations throttle the Overlay ping traffic going to the 354 control plane. 356 Reply and spoofing attacks involving faking or replying Overlay Echo 357 Reply messages would have to match the Sender's Handle and Sequence 358 Number of an outstanding Overlay Echo Request message which is highly 359 unlikely. Thus the non-matching reply would be discarded. But since 360 "even a broken clock is right twice a day" implementations MAY use 361 Timestamp control block [I-D.ooamdt-rtgwg-ooam-header] to validate 362 the TimeStamp Sent by requiring an exact match on this field. 364 To protect against unauthorized sources trying to obtain information 365 about the overlay and/or underlay an implementation MAY check that 366 the source of the Echo Request is indeed part of the overlay domain. 368 5. Contributors 370 Work on this documented started by Overlay OAM Design Team with 371 contributions from: 373 Carlos Pignataro 375 Cisco Systems, Inc. 377 cpignata@cisco.com 379 Santosh Pallagatti 381 santosh.pallagatti@gmail.com 383 Erik Nordmark 385 Arista Networks 386 nordmark@acm.org 388 Ignas Bagdonas 390 ibagdona@gmail.com 392 David Mozes 394 Mellanox Technologies Ltd. 396 davidm@mellanox.com 398 6. Acknowledgment 400 TBD 402 7. References 404 7.1. Normative References 406 [I-D.ietf-bier-mpls-encapsulation] 407 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., 408 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 409 Explicit Replication in MPLS and non-MPLS Networks", 410 draft-ietf-bier-mpls-encapsulation-06 (work in progress), 411 December 2016. 413 [I-D.ietf-nvo3-geneve] 414 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 415 Network Virtualization Encapsulation", draft-ietf- 416 nvo3-geneve-03 (work in progress), September 2016. 418 [I-D.ietf-nvo3-gue] 419 Herbert, T., Yong, L., and O. Zia, "Generic UDP 420 Encapsulation", draft-ietf-nvo3-gue-05 (work in progress), 421 October 2016. 423 [I-D.ietf-nvo3-vxlan-gpe] 424 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 425 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-03 (work 426 in progress), October 2016. 428 [I-D.ietf-sfc-nsh] 429 Quinn, P. and U. Elzur, "Network Service Header", draft- 430 ietf-sfc-nsh-12 (work in progress), February 2017. 432 [I-D.ooamdt-rtgwg-ooam-header] 433 Mirsky, G., Kumar, N., Kumar, D., Chen, M., Yizhou, L., 434 Mozes, D., and D. Dolson, "OAM Header for use in Overlay 435 Networks", draft-ooamdt-rtgwg-ooam-header-02 (work in 436 progress), February 2017. 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, 440 DOI 10.17487/RFC2119, March 1997, 441 . 443 7.2. Informative References 445 [I-D.ietf-mpls-rfc4379bis] 446 Kompella, K., Swallow, G., Pignataro, C., Kumar, N., 447 Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label 448 Switched (MPLS) Data Plane Failures", draft-ietf-mpls- 449 rfc4379bis-09 (work in progress), October 2016. 451 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 452 RFC 792, DOI 10.17487/RFC0792, September 1981, 453 . 455 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 456 Label Switched (MPLS) Data Plane Failures", RFC 4379, 457 DOI 10.17487/RFC4379, February 2006, 458 . 460 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 461 Control Message Protocol (ICMPv6) for the Internet 462 Protocol Version 6 (IPv6) Specification", RFC 4443, 463 DOI 10.17487/RFC4443, March 2006, 464 . 466 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 467 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 468 DOI 10.17487/RFC5226, May 2008, 469 . 471 Authors' Addresses 473 Greg Mirsky 474 ZTE Corp. 476 Email: gregimirsky@gmail.com 477 Nagendra Kumar 478 Cisco Systems, Inc. 480 Email: naikumar@cisco.com 482 Deepak Kumar 483 Cisco Systems, Inc. 485 Email: dekumar@cisco.com 487 Mach Chen 488 Huawei Technologies 490 Email: mach.chen@huawei.com 492 Yizhou Li 493 Huawei Technologies 495 Email: liyizhou@huawei.com 497 David Dolson 498 Sandvine 500 Email: ddolson@sandvine.com