idnits 2.17.1 draft-jain-nvo3-vxlan-ping-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 06, 2013) is 3949 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) == Missing Reference: 'NTP' is mentioned on line 264, but not defined == Unused Reference: 'I-D.draft-lasserre-nvo3-framework' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'RFC4330' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC4379' is defined on line 499, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-lasserre-nvo3-framework (ref. 'I-D.draft-lasserre-nvo3-framework') ** Downref: Normative reference to an Informational draft: draft-mahalingam-dutt-dcops-vxlan (ref. 'I-D.draft-mahalingam-dutt-dcops-vxlan') -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 P. Jain 3 Internet-Draft K. Singh 4 Intended status: Standards Track F. Balus 5 Expires: December 8, 2013 Nuage Networks 6 W. Henderickx 7 Alcatel-Lucent 8 V. Bannai 9 PayPal 10 June 06, 2013 12 Detecting VXLAN Segment Failure 13 draft-jain-nvo3-vxlan-ping-00 15 Abstract 17 This proposal describes a mechanism that can be used to detect Data 18 Path Failures and sanity of VXLAN Control and Data Plane for a given 19 VXLAN Segment. This document defines the following: 21 o Information carried in a VXLAN "Echo Request", and 23 o "Echo Reply" for the purposes of fault detection and isolation, 24 and mechanisms for reliably sending the Echo Request and reply. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 8, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Need for VXLAN Ping . . . . . . . . . . . . . . . . . . . . . 6 66 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Return Codes . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 6. Procedure for VXLAN Ping . . . . . . . . . . . . . . . . . . . 12 71 6.1. Sending VXLAN Echo Request . . . . . . . . . . . . . . . . 12 72 6.2. Receiving VXLAN Echo Request . . . . . . . . . . . . . . . 13 73 6.3. Sending VXLAN Echo Reply . . . . . . . . . . . . . . . . . 13 74 6.4. Receiving VXLAN Echo Reply . . . . . . . . . . . . . . . . 14 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 8. Management Considerations . . . . . . . . . . . . . . . . . . 16 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 19 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC2119 [RFC2119]. 93 When used in lower case, these words convey their typical use in 94 common language, and are not to be interpreted as described in 95 RFC2119 [RFC2119]. 97 1. Introduction 99 VXLAN [I-D.draft-mahalingam-dutt-dcops-vxlan]is a tunneling mechanism 100 to overlay Layer 2 networks on top of Layer 3 networks. In most 101 cases the end point of the tunnel (VTEP) is intended to be at the 102 edge of the network, typically connecting an access switch to an IP 103 transport network. The access switch could be a physical or a 104 virtual switch located within the hypervisor on the server which is 105 connected to End System which is a VM. 107 This document describes a mechanism that can be used to detect Data 108 Plane failures and sanity of VXLAN Control and Data Plane for a given 109 VXLAN Segment. 111 There proposal describes: 113 o Information carried in VXLAN "Echo Request", 115 o Information carried in VXLAN "Echo Reply", and 117 o the mechanism to transport the "Echo Request" and "Echo Reply". 119 The proposal defines the information to check correct operation of 120 the Data Plane, as well as a mechanism to verify the Data Plane 121 against the Control Plane for a given VXLAN Segment. 123 Its is important consideration in this proposal to carry VXLAN Echo 124 Request along same data path that normal VXLAN Packets would 125 traverse. 127 The tenants VM(s) are not aware of the Virtualization Overlays and as 128 such the need for the verification of the Data Path MUST solely rest 129 with the Cloud Provider. The use cases where the Tenant VM(s) need 130 to be aware of the Data Plane failures is beyond the scope of this 131 document. 133 2. Terminology 135 Terminology used in this document: 137 VXLAN: Virtual eXtensible Local Area Network. 139 VTEP: VXLAN Tunnel End Point. 141 VM: Virtual Machine. 143 VNI: VXLAN Network Identifier (or VXLAN Segment ID) 145 NVE: Network Virtulalized Edge 147 End System: Could be VM etc. - System whose data is expected to go 148 over VXLAN Segment. 150 Other terminologies are as defined in 151 [I-D.draft-mahalingam-dutt-dcops-vxlan]. 153 3. Need for VXLAN Ping 155 When a VXLAN Segment fails to deliver user traffic, there is a need 156 to provide a tool that would enable users, as Cloud Providers to 157 detect such failures, and a mechanism to isolate faults. It may also 158 be desirable to test the data path before mapping End System traffic 159 to the VXLAN Segment. 161 The basic idea is to facilitate following verifications:- 163 o Packets that are expected to go over a particular VXLAN Segment 164 actually ends up going over the correct VXLAN Segment to the 165 correct VXLAN Terminating VTEP. 167 o To verify the correct value of VXLAN VN-ID is programmed at 168 Originating and Terminating VXLAN VTEP(s) for a given VXLAN 169 Segment. 171 To facilitate verification of the above requirements, this document 172 proposes sending of a Packet (called an "VXLAN Echo Request") along 173 the same data path as other Packets belonging to this Segment. VXLAN 174 Echo Request also carries information about the VXLAN Segment whose 175 Data Path is to be verified. This Echo Request is forwarded just 176 like any other End System Data Packet belonging to that VXLAN 177 Segment, as it contains the same VXLAN Encapsulation as regular End 178 System's data which uses the given VXLAN Segment. 180 On receiving VXLAN Echo Request at the end of the VXLAN Segment, it 181 is sent to the Control Plane of the Terminating VTEP, which in-turn 182 would respond with VXLAN Echo Reply. 184 +------- L3 Network ------+ 185 | | 186 | Tunnel Overlay | 187 +------------+---------+ +---------+------------+ 188 | +----------+-------+ | | +---------+--------+ | 189 | | Overlay Module | | | | Overlay Module | | 190 NVE1 | | +-----------+ | | | | +-----------+ | | NVE2 191 | | | OAM Module| | | | | | OAM Module| | | 192 | | +-----------+ | | | | +-----------+ | | 193 | +------------------+ | | +------------------+ | 194 +----+------------+----+ +----+-----------+-----+ 195 | | | | 196 -------+------------+-----------------+-----------+------- 197 | | | | 198 | | | | 199 Tenant Systems Tenant Systems 200 Fig 1 202 As depicted in Fig 1, VXLAN OAM Module SHOULD reside at NVE device 203 and Echo Request and Reply SHOULD be handled at the NVE. 205 4. Packet Format 207 VXLAN Echo Request/Reply is a IPv4 UDP Packet. Following is the 208 format of VXLAN Echo Packet: 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Message Type | Reply mode | Return Code | Return Subcode| 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Originator Handle | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Sequence Number | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | TimeStamp Sent (seconds) | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | TimeStamp Sent (microseconds) | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | TimeStamp Received (seconds) | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | TimeStamp Received (microseconds) | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | TLVs ... | 228 . . 229 . . 230 . . 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 The Message Type is one of the following:- 236 Value What it means 237 ----- ------------------ 238 1 VXLAN Echo Request 240 2 VXLAN Echo Reply 241 Reply Mode Values:- 243 Value What it means 244 ----- --------------------------------- 245 1 Do not reply 247 2 Reply via an IPv4/IPv6 UDP Packet 249 VXLAN Echo Request with 1 (Do not reply) in the Reply Mode field may 250 be used for one-way connectivity tests; the receiving node may log 251 gaps in the Sequence Numbers and/or maintain delay/jitter statistics. 252 For normal operation VXLAN Echo Request would have 2 (Reply via an 253 IPv4 UDP Packet) in the Reply Mode field. 255 The Originator's Handle is filled in by the Originator, and returned 256 unchanged by the receiver in the Echo Reply (if any). There value 257 used for this field can be implementation dependent, this MAY be used 258 by the Originator for matching up requests with replies. 260 The Sequence Number is assigned by the sender of the VXLAN echo 261 request and can be (for example) used to detect missed replies. 263 The TimeStamp Sent is the time-of-day (in seconds and microseconds, 264 according to the sender's clock) in NTP format [NTP] when the VXLAN 265 Echo Request is sent. The TimeStamp Received in an Echo Reply is the 266 time-of-day (according to the receiver's clock) in NTP format that 267 the corresponding Echo Request was received. 269 TLVs (Type-Length-Value tuples) have the following format: 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Type | Length | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Value | 277 . . 278 . . 279 . . 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Types are defined below; Length is the length of the Value field in 284 octets. The Value field depends on the Type; it is zero padded to 285 align to a 4-octet boundary. 287 Example of the TLV for VXLAN ping is as follows. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Type = 1 (VXLAN ping) | Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | VXLAN VNI | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | IPv4 Sender Address | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 TLV if Sender Address is IPv4 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type = 1 (VXLAN ping) | Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | VXLAN VNI | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 | IPv6 Sender Address | 310 | | 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 TLV if Sender Address is IPv6 316 5. Return Codes 318 Sender MUST always set the Return Code set to zero. The receiver can 319 set it to one of the values listed below when replying back to Echo- 320 Request. 322 Following are the Return Codes (Suggested):- 324 Value What it means 325 ----- ------------------------------- 326 0 No return code 328 1 Malformed Echo Request Received 330 2 No VN-ID Present 332 3 Return-Code-OK 334 6. Procedure for VXLAN Ping 336 VXLAN Echo Request is used to test Data Plane and its view of Control 337 Plane for particular VXLAN Segment. The VXLAN Segment to be verified 338 is identified by the "VN-ID". For the Data Plane verification, the 339 complete VXLAN Echo Request Packet would be encapsulated with the 340 VXLAN header of the given VXLAN Segment. For control plane's view of 341 the given VXLAN Segment at the Terminating VTEP, the TLV will be 342 encoded under Echo Request Packet, to identify presence of given 343 VXLAN Segment. 345 When VXLAN Echo Request is received, the Terminating VTEP is expected 346 to verify the consistency of the Control Plane and Data Plane for the 347 VXLAN Segment identified by the VN-ID. 349 6.1. Sending VXLAN Echo Request 351 Inner Ethernet Header for the VXLAN Echo Request Packet should have 352 the Destination Mac set to 00-00-5E-90-XX-XX (to be assigned IANA); 353 the Source Mac is set to Mac Address of the Originating VTEP. In the 354 payload portion of this VXLAN Frame. The IP header is set as 355 follows: the source IP Address is a routable Address of the sender; 356 the destination IP Address is a (randomly chosen) IPv4 Address from 357 the range 127/8, IPv6 addresses are chosen from the range 0:0:0:0:0: 358 FFFF:127/104. The IP TTL is set to 255. The UDP header is set as 359 follows: the source UDP port is chosen by the sender. It is desired 360 to choose the Source UDP port so as to exercise the entropy for ECMP/ 361 load balancing across the VXLAN Overlay, and it left to the 362 implementation; the destination UDP port is set to xxxx (assigned by 363 IANA for VXLAN Echo Requests). The rest of the Echo Request is 364 encoded as define in above section "Packet Format", VN-ID in the TLV 365 for Echo Request MUST be same as the VN-ID for the VXLAN Segment. 366 The IPv4 Sender Address is set to the Address of Originating VTEP's 367 IP Address. The VXLAN Router Alert option 368 [I-D.draft-singh-nvo3-vxlan-router-alert] MUST be set in the VXLAN 369 header as shown below. A VXLAN Echo Request is sent encapsulated 370 with the VXLAN header corresponding to the VXLAN Segment being 371 tested. 373 VXLAN Header: 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 |R|R|R|R|I|R|R|RA| Reserved | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | VXLAN Network Identifier (VNI) | Reserved | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 RA: Router Alter Bit (Proposed) 382 The sender chooses a Originator's Handle and a Sequence Number. When 383 sending subsequent VXLAN Echo Requests, the sender SHOULD increment 384 the Sequence Number by 1. 386 The TimeStamp Sent is set to the time-of-day (in seconds and 387 microseconds) that the Echo Request is sent. The TimeStamp Received 388 is set to zero. Also, the Reply Mode must be set to the desired 389 reply mode. The Return Code and Subcode are set to zero. 391 6.2. Receiving VXLAN Echo Request 393 At the Terminating VTEP, sending VXLAN Echo Request to the Control 394 Plane is triggered by one of the following Packet processing 395 exceptions: VXLAN Router Alert option, 396 [I-D.draft-singh-nvo3-vxlan-router-alert] the Inner Destination MAC 397 Address of 00-00-5E-90-XX-XX as defined in above section, and the 398 Destination IP Address in the 127/8 Address range for IPv4 Address, 399 or 0:0:0:0:0:FFFF:127/104 for IPv6 Address. The Control Plane 400 further identifies the VXLAN Echo Request by UDP destination port 401 xxxx. 403 Once the VXLAN Echo Request Packed is identified at Control Plane, it 404 is processed as follows:- 406 o General Packet sanity is verified. If the Packet is not well- 407 formed, VTEP SHOULD send VXLAN Echo Reply with the Return Code set 408 to "Malformed Echo Request received" and the Subcode to zero. The 409 header fields Originator's Handle, Sequence Number, and Timestamp 410 Sent are not examined, but are included in the VXLAN Echo Reply 411 message 413 o VNI Validation: If there is no entry for VN-ID, it indicates that 414 there could be a transient or permanent disconnect between Control 415 Plane and data palne and VTEP needs to report an error with Return 416 Code of "No VN-ID Present" and a Return Subcode of Zero. If the 417 mapping exists then send VXLAN Echo Reply with a Return Code of 418 "Return-Code-OK", and a Return Subcode of Zero. The procedures 419 for sending the Echo Reply are found in subsection below section. 421 6.3. Sending VXLAN Echo Reply 423 VXLAN Echo Reply is a UDP Packet. It MUST ONLY be sent in response 424 to VXLAN Echo Request. The Source IP Address is a routable Address 425 of the replier; the source port is the well-known UDP port for VXLAN 426 ping. The Destination IP Address and UDP port are copied from the 427 Source IP Address and UDP port of the Echo Request. The IP TTL is 428 set to 255. 430 The format of the Echo Reply is the same as the Echo Request. The 431 Originator Handle, the Sequence Number, and TimeStamp Sent are copied 432 from the Echo Request; the TimeStamp Received is set to the time-of- 433 day that the Echo Request is received (note that this information is 434 most useful if the time-of-day clocks on the requester and the 435 replier are synchronized).The replier MUST fill in the Return Code 436 and Subcode, as determined in the previous subsection. 438 6.4. Receiving VXLAN Echo Reply 440 An Originating VTEP should only receive VXLAN Echo Reply in response 441 to an VXLAN Echo Request that it sent. Thus, on receipt of VXLAN 442 echo reply, Originating VTEP should parse the Packet to ensure that 443 it is well-formed, then attempt to match up the Echo Reply with an 444 Echo Request that it had previously sent, using the destination UDP 445 port and the Originator Handle. If no match is found, then VTEP 446 should drop the Echo Reply Packet; otherwise, it checks the Sequence 447 Number to see if it matches. 449 7. Security Considerations 451 TBD 453 8. Management Considerations 455 None 457 9. Acknowledgements 459 This document is the outcome of many discussions among many people, 460 including Diego Garcia Del Rio, Saurabh Shrivastava and Suresh 461 Boddapati of Nuage Networks and Jorge Rabadan of Alcatel-Lucent, Inc. 463 10. IANA Considerations 465 Action-1: This specification reserves a IANA UDP Port Number to be 466 used when sending the VXLAN Echo Request Packet. 468 Action-2: This specification reserves a IANA Ethernet unicast Address 469 for VXLAN Exception handling. This Address needs to be reserved from 470 the block. "IANA Ethernet Address block - Unicast Use" 472 11. References 474 11.1. Normative References 476 [I-D.draft-lasserre-nvo3-framework] 477 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 478 Rekhter, "Framework for DC Network Virtualization", 479 September 2011. 481 [I-D.draft-mahalingam-dutt-dcops-vxlan] 482 Mahalingam, M., Dutt, D., Agarwal, P., Kreeger, L., 483 Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A 484 Framework for Overlaying Virtualized Layer 2 Networks 485 over Layer 3 Networks", May 2013. 487 [I-D.draft-singh-nvo3-vxlan-router-alert] 488 Singh, K., Jain, P., Balus, F., and W. Henderickx, "VxLAN 489 Router Alert Option", May 2013. 491 11.2. Informative References 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 497 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 499 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 500 Label Switched (MPLS) Data Plane Failures", RFC 4379, 501 February 2006. 503 Authors' Addresses 505 Pradeep Jain 506 Nuage Networks 507 755 Ravendale Drive 508 Mountain View, CA 94043 509 USA 511 Email: pradeep@nuagenetworks.net 513 Kanwar Singh 514 Nuage Networks 515 755 Ravendale Drive 516 Mountain View, CA 94043 517 USA 519 Email: kanwar@nuagenetworks.net 521 Florin Balus 522 Nuage Networks 523 755 Ravendale Drive 524 Mountain View, CA 94043 525 USA 527 Email: florin@nuagenetworks.net 529 Wim Henderickx 530 Alcatel-Lucent 531 Copernicuslaan 50 532 Antwerp 2018 533 Belgium 535 Email: wim.henderickx@alcatel-lucent.be 537 Vinay Bannai 538 PayPal 539 2211 N. First St, 540 San Jose 95131 541 USA 543 Email: vbannai@paypal.com