idnits 2.17.1 draft-ashwood-nvo3-operational-requirement-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 (July 15, 2013) is 3938 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE802.1ah' is defined on line 649, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Ashwood-Smith 3 Internet-Draft Huawei Technologies 4 Intended status: Informational R. Iyengar 5 Expires: January 16, 2014 T. Tsou 6 Huawei Technologies USA 7 A. Sajassi 8 Cisco Technologies 9 M. Boucadair 10 C. Jacquenet 11 France Telecom 12 M. Daikoku 13 KDDI corporation 14 July 15, 2013 16 NVO3 Operational Requirements 17 draft-ashwood-nvo3-operational-requirement-03 19 Abstract 21 This document provides framework and requirements for Network 22 Virtualization over Layer 3 (NVO3) Operations, Administration, and 23 Maintenance (OAM). This document for the most part gathers 24 requirements from existing IETF drafts and RFCs which have already 25 extensively studied this subject for different data planes and 26 layering. As a result this draft is high level and broad. We begin 27 to ask which are truly required for NVO3 and expect the list to be 28 narrowed by the working group as subsequent versions of this draft 29 are created. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 16, 2014. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. OSI Definitions of OAM . . . . . . . . . . . . . . . . . 3 67 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 68 1.3. Relationship with Other OAM Work . . . . . . . . . . . . 5 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. NVO3 Reference Model . . . . . . . . . . . . . . . . . . . . 6 71 4. OAM Framework for NVO3 . . . . . . . . . . . . . . . . . . . 7 72 4.1. OAM Layering . . . . . . . . . . . . . . . . . . . . . . 7 73 4.2. OAM Domains . . . . . . . . . . . . . . . . . . . . . . . 8 74 5. NVO3 OAM Requirements . . . . . . . . . . . . . . . . . . . . 9 75 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. Connectivity Fault Management . . . . . . . . . . . . . . 9 77 5.2.1. Connectivity Fault Detection . . . . . . . . . . . . 9 78 5.2.2. Connectivity Fault Verification . . . . . . . . . . . 9 79 5.2.3. Connectivity Fault localization . . . . . . . . . . . 10 80 5.2.4. Connectivity Fault Notification and Alarm Suppression 10 81 5.3. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . 10 82 5.4. Frame Delay . . . . . . . . . . . . . . . . . . . . . . . 10 83 5.5. Frame Delay Variation . . . . . . . . . . . . . . . . . . 10 84 5.6. Frame Throughput . . . . . . . . . . . . . . . . . . . . 10 85 5.7. Frame Discard . . . . . . . . . . . . . . . . . . . . . . 10 86 5.8. Availability . . . . . . . . . . . . . . . . . . . . . . 11 87 5.9. Data Path Forwarding . . . . . . . . . . . . . . . . . . 11 88 5.10. Scalability . . . . . . . . . . . . . . . . . . . . . . . 11 89 5.11. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11 90 5.12. Security . . . . . . . . . . . . . . . . . . . . . . . . 11 91 5.13. Transport Independence . . . . . . . . . . . . . . . . . 12 92 5.14. Application Independence . . . . . . . . . . . . . . . . 12 93 5.15. Prioritization . . . . . . . . . . . . . . . . . . . . . 12 94 6. Items for Further Discussion . . . . . . . . . . . . . . . . 12 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 100 10.2. Informative References . . . . . . . . . . . . . . . . . 14 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 103 1. Introduction 105 This document provides framework and requirements for Network 106 virtualization over Layer 3(NVO3) Operation, Administration, and 107 Maintenance (OAM). Given that this OAM subject is far from new and 108 has been under extensive investigation by various IETF working groups 109 (and several other standards bodies) for many years, this document 110 draws from existing work, starting with [RFC6136]. As a result, 111 sections of [RFC6136] have been reused with minor changes with the 112 permission of the authors. 114 NVO3 OAM requirements are expected to be a subset of IETF/IEEE etc. 115 work done so far; however, we begin with a full set of requirements 116 and expect to prune them through several iterations of this document. 118 1.1. OSI Definitions of OAM 120 The scope of OAM for any service and/or transport/network 121 infrastructure technologies can be very broad in nature. OSI has 122 defined the following five generic functional areas commonly 123 abbreviated as "FCAPS" [NM-Standards]: 125 o Fault Management, 127 o Configuration Management, 129 o Accounting Management, 131 o Performance Management, and 133 o Security Management. 135 This document focuses on the Fault, Performance and to a limited 136 extent the Configuration Management aspects. Other functional 137 aspects of FCAPS and their relevance (or not) to NVO3 are for further 138 study. 140 Fault Management can typically be viewed in terms of the following 141 categories: 143 o Fault Detection; 144 o Fault Verification; 146 o Fault Isolation; 148 o Fault Notification and Alarm Suppression; 150 o Fault Recovery. 152 Fault detection deals with mechanism(s) that can detect both hard 153 failures such as link and device failures, and soft failures, such as 154 software failure, memory corruption, misconfiguration, etc. Fault 155 detection relies upon a set of mechanisms that first allow the 156 observation of an event, then the use of a protocol to dynamically 157 notify a network/system operator (or management system) about the 158 event occurrence, then the use of diagnostic tools to assess the 159 nature and severity of the fault. 161 After verifying that a fault has occurred along the data path, it is 162 important to be able to isolate the fault to the level of a given 163 device or link. Therefore, a fault isolation mechanism is needed in 164 Fault Management. A fault notification mechanism should be used in 165 conjunction with a fault detection mechanism to notify the devices 166 upstream and downstream to the fault detection point. The fault 167 notification mechanism should also notify NMS systems. 169 The terms "upstream" and "backward" are used here to denote the 170 direction(s) from which data traffic is flowing. The terms 171 "downstream" and "forward" denote the direction(s) to which data 172 traffic is forwarded. 174 For example, when there is a client/server relationship between two 175 layered networks (e.g., the NVO3 layer is a client of the outer IP 176 server layer, while the inner IP layer is a client of the NVO3 server 177 layer 2), fault detection at the server layer may result in the 178 following fault notifications: 180 o Sending a forward fault notification from the server layer to the 181 client layer network(s) using the fault notification format 182 appropriate to the client layer. 184 o Sending a backward fault notification to the server layer, if 185 applicable, in the reverse direction. 187 o Sending a backward fault notification to the client layer, if 188 applicable, in the reverse direction. 190 Finally, fault recovery deals with recovering from the detected 191 failure by switching to an alternate available data path (depending 192 on the nature of the fault) using alternate devices or links. In 193 fact, the controller can provision another virtual network, thus 194 automatically resolving the reported problem. 196 The controller may also directly monitor the status of virtual 197 network components such as Network Virtualization Edge elements 198 (NVEs) [NVO3-framework] in order to respond to their failures. In 199 addition to forward and backward fault notifications, the controller 200 may deliver notifications to a higher level orchestration component, 201 e.g., one responsible for Virtual Machine (VM) provisioning and 202 management. 204 Note, given that the IP network on which NVO3 resides is usually self 205 healing, it is expected that recovery by the NVO3 layer would not 206 normally be required, although there may be a requirement for that 207 layer to log that the problem has been detected and resolved. The 208 special cases of a static IP overlay network, or possibly of a 209 centrally controlled IP overlay network, may, however, require NVO3 210 involvement in fault recovery. 212 Performance Management deals with mechanism(s) that allow determining 213 and measuring the performance of the network/services under 214 consideration. Performance Management can be used to verify the 215 compliance to both the service-level and network-level metric 216 objectives/specifications. Performance Management typically consists 217 of measuring performance metrics, e.g., Frame Loss, Frame Delay, 218 Frame Delay Variation (aka Jitter), Frame throughput, Frame discard, 219 etc., across managed entities when the managed entities are in 220 available state. Performance Management is suspended across 221 unavailable managed entities. 223 1.2. Requirements Language 225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 227 document are to be interpreted as described in [RFC2119]. 229 1.3. Relationship with Other OAM Work 231 This document leverages requirements that originate with other OAM 232 work, specifically the following: 234 o [RFC6136] provides a template and some of the high level 235 requirements and introductory wording. 237 o [IEEE802.1ag] is expected to provide a subset of the requirements 238 for NVO3 both at the Tenant level and also within the L3 Overlay 239 network. 241 o [Y.1731] is expected to provide a subset of the requirements for 242 NVO3 at the Tenant level. 244 o Section 3.8 of [NVO3-DP-Reqs] lists several requirements 245 specifically concerning ECMP/LAG. 247 2. Terminology 249 The terminology defined in [NVO3-framework] and [NVO3-DP-Reqs] is 250 used throughout this document. We introduce no new terminology. 252 3. NVO3 Reference Model 254 Figure 1 below reproduces the generic NVO3 reference model as per 255 [NVO3-framework]. 257 +--------+ +--------+ 258 | Tenant | | Tenant | 259 | End +--+ +---| End | 260 | System | | | | System | 261 +--------+ | ................... | +--------+ 262 | +-+--+ +--+-+ | 263 | | NV | | NV | | 264 +--|Edge| |Edge|--+ 265 +-+--+ +--+-+ 266 / . L3 Overlay . \ 267 +--------+ / . Network . \ +--------+ 268 | Tenant +--+ . . +----| Tenant | 269 | End | . . | End | 270 | System | . +----+ . | System | 271 +--------+ .....| NV |........ +--------+ 272 |Edge| 273 +----+ 274 | 275 | 276 +--------+ 277 | Tenant | 278 | End | 279 | System | 280 +--------+ 282 Figure 1: Generic reference model for DC network virtualization over 283 a Layer3 infrastructure 285 Figure 2 below, reproduces the Generic reference model for the NV 286 Edge (NVE) as per [NVO3-DP-Reqs]. 288 +------- L3 Network ------+ 289 | | 290 | Tunnel Overlay | 291 +------------+---------^-+ +--------+-------------^-+ 292 | +----------+------+ | | | +------+----------+ | | 293 | | Overlay Module | | | | | Overlay Module | | | 294 | +--------+--------+ | | | +--------+--------+ | | 295 | | VNID | | | | VNID | | 296 | | OAM | | | OAM | 297 | +-------+-------+ | | | +-------+-------+ | | 298 | | VNI | | | | | VNI | | | 299 NVE1 | +-+-----------+-+ | | NVE2 | +-+-----------+-+ | | 300 | | VAPs | | | | | VAPs | | | 301 +----+-----------+-----V-+ +----+-----------+-----V-+ 302 | | | | 303 -------+-----------+--------------------+-----------+-----_-- 304 | | Tenant | | 305 | | Service IF | | 306 Tenant End Systems Tenant End Systems 308 Figure 2: Generic reference model for NV Edge 310 4. OAM Framework for NVO3 312 Figure 1 showed the generic reference model for a DC network 313 virtualization over an L3 (or L3VPN) infrastructure while Figure 2 314 showed the generic reference model for the Network Virtualization 315 (NV) Edge. 317 L3 network(s) or L3 VPN networks (either IPv6 or IPv4, or a 318 combination thereof), provide transport for an emulated layer 2 319 created by NV Edge devices. Unicast and multicast tunneling methods 320 (de-multiplexed by Virtual Network Identifier (VNID)) are used to 321 provide connectivity between the NV Edge devices. The NV Edge 322 devices then present an emulated layer 2 network to the Tenant End 323 Systems at a Virtual Network Interface (VNI) through Virtual Access 324 Points (VAPs). The NV Edge devices map layer 2 unicast to layer 3 325 unicast point-to-point tunnels and may either map layer 2 multicast 326 to layer 3 multicast tunnels or may replicate packets onto multiple 327 layer 3 unicast tunnels. 329 4.1. OAM Layering 330 The emulated layer 2 network is provided by the NV Edge devices to 331 which the Tenant End Systems are connected. This network of NV Edges 332 can be operated by a single service provider or can span across 333 multiple administrative domains. Likewise, the L3 Overlay Network 334 can be operated by a single service provider or span across multiple 335 administrative domains. 337 While each of the layers is responsible for its own OAM, each layer 338 may consist of several different administrative domains. Figure 3 339 shows an example. 341 OAM 342 --- 344 TENANT |----------------------------| TENANT {all IP/ETH} 346 NV Edge |----------------------| NV Edge {t.b.d.} 348 IP(VPN) |---| IP (VPN) |---| IP(VPN) {IP(VPN)/ETH} 350 Figure 3: OAM layers in an NVO3 network 352 For example, at the bottom, at the L3 IP overlay network layer 353 IP(VPN) and/or Ethernet OAM mechanisms are used to probe link by 354 link, node to node etc. OAM addressing here means physical node 355 loopback or interface addresses. 357 Further up, at the NV Edge layer, NVO3 OAM messages are used to probe 358 the NV Edge to NV Edge tunnels and NV Edge entity status. OAM 359 addressing here likely means the physical node loopback together with 360 the VNI (to de-multiplex the tunnels). 362 Finally, at the Tenant layer, the IP and/or Ethernet OAM mechanisms 363 are again used but here they are operating over the logical L2/L3 364 provided by the NV-Edge through the VAP. OAM addressing at this 365 layer deals with the logical interfaces on Vswitches and Virtual 366 Machines. 368 4.2. OAM Domains 370 Complex OAM relationships exist as a result of the hierarchical 371 layering of responsibility and of breaking up of end-to-end 372 responsibility. 374 The OAM domain above NVO3, is expected to be supported by existing IP 375 and L2 OAM methods and tools. 377 The OAM domain below NVO3, is expected to be supported by existing IP 378 /L2 and MPLS OAM methods and tools. Where this layer is actually 379 multiple domains spliced together, the existing methods to deal with 380 these boundaries are unchanged. Note however that exposing LAG/ECMP 381 detailed behavior may result in additional requirements to this 382 domain, the details of which will be specified in the future versions 383 of this draft. 385 When we refer to an OAM domain in this document, or just 'domain', we 386 therefore refer to a closed set of NV Edges and the tunnels which 387 interconnect them. Inter-domain OAM considerations will be specified 388 in the future versions of this draft. 390 5. NVO3 OAM Requirements 392 The following numbered requirements originate from [RFC6136]. All 393 are included however where they seem obviously not relevant (to the 394 present authors) an explanation as to why is included. 396 5.1. Discovery 398 R1) NVO3 OAM MUST allow an NV Edge device to dynamically discover 399 other NV Edge devices that share the same VNI within a given NVO3 400 domain. This may be based on a discovery mechanism used to set up 401 data path forwarding between NVEs. 403 5.2. Connectivity Fault Management 405 5.2.1. Connectivity Fault Detection 407 R2) NVO3 OAM MUST allow proactive connectivity monitoring between two 408 or more NV Edge devices that support the same VNIs within a given 409 NVO3 domain. NVO3 OAM MAY act as a protection trigger. That is, 410 automatic recovery from transmission facility failure by switchover 411 to a redundant replacement facility may be triggered by notifications 412 from NVO3 OAM. 414 R3) NVO3 OAM MUST allow monitoring/tracing of all possible paths in 415 the underlay network between a specified set of two or more NV Edge 416 devices. Using this feature, equal cost paths that traverse LAG and/ 417 or ECMP may be differentiated. 419 5.2.2. Connectivity Fault Verification 421 R4) NVO3 OAM MUST allow connectivity fault verification between two 422 or more NV Edge devices that support the same VNI within a given NVO3 423 domain. 425 5.2.3. Connectivity Fault localization 427 R5) NVO3 OAM MUST allow connectivity fault localization between two 428 or more NV Edge devices that support the same VNI within a given NVO3 429 domain. 431 5.2.4. Connectivity Fault Notification and Alarm Suppression 433 R6) NVO3 OAM MUST support fault notification to be triggered as a 434 result of the faults occurring in the underneath network 435 infrastructure. This fault notification SHOULD be used for the 436 suppression of redundant service-level alarms. 438 5.3. Frame Loss 440 R7) NVO3 OAM MUST support measurement of per VNI frame loss between 441 two NV Edge devices that support the same VNI within a given NVO3 442 domain. 444 5.4. Frame Delay 446 R8) NVO3 OAM MUST support measurement of per VNI two-way frame delay 447 between two NV edge devices that support the same VNI within a given 448 NVO3 domain. 450 R9) NVO3 OAM MUST support measurement of per VNI one-way frame delay 451 between two NV Edge devices that support the same VNI within a given 452 NVO3 domain. 454 5.5. Frame Delay Variation 456 R10) NVO3 OAM MUST support measurement of per VNI frame delay 457 variation between two NV Edge devices that support the same VNI 458 within a given NVO3 domain. 460 5.6. Frame Throughput 462 R11) NVO3 OAM MAY [*** Should this be stronger? ***] support 463 measurement of per VNI frame throughput throughput (in frames and 464 bytes) between two NV Edge devices that support the same VNI within a 465 given NVO3 domain. This feature could be an effective way to confirm 466 whether or not assigned path bandwidth conforms to service level 467 agreement before providing the path between two NV Edge devices. 469 5.7. Frame Discard 471 R12) NVO3 OAM MAY support measurement of per VNI frame discard 472 between two NV Edge devices that support the same VNI within a given 473 NVO3 domain. This feature MAY be effective to monitor bursty traffic 474 between two NV Edge devices. 476 5.8. Availability 478 A service may be considered unavailable if the service frames/packets 479 do not reach their intended destination (e.g., connectivity is down) 480 or the service is degraded (e.g., frame loss and/or frame delay and/ 481 or delay variation threshold is exceeded). Entry and exit conditions 482 may be defined for the unavailable state. Availability itself may be 483 defined in the context of a service type. Since availability 484 measurement may be associated with connectivity, frame loss, frame 485 delay, and frame delay variation measurements, no additional 486 requirements are specified currently. 488 5.9. Data Path Forwarding 490 R13) NVO3 OAM frames MUST be forwarded along the same path (i.e., 491 links (including LAG members) and nodes) as the NVO3 data frames. 493 R14) NVO3 OAM frames MUST provide a mechanism to exercise/trace all 494 data paths that result due to ECMP/LAG hops in the underlay network. 496 5.10. Scalability 498 R15) NVO3 OAM MUST be scalable such that an NV edge device can 499 support proactive OAM for each VNI that is supported by the device. 500 (Note - Likely very hard to achieve with hash based ECMP/LAG). 502 5.11. Extensibility 504 R16) NVO3 OAM should be extensible such that new functionality and 505 information elements related to this functionality can be introduced 506 in the future. 508 R17) NVO3 OAM MUST be defined such that devices not supporting the 509 OAM are able to forward the OAM frames in a similar fashion as the 510 regular NVO3 data frames/packets. 512 5.12. Security 514 R18) NVO3 OAM frames MUST be prevented from leaking outside their 515 NVO3 domain. 517 R19) NVO3 OAM frames from outside an NVO3 domain MUST be prevented 518 from entering the said NVO3 domain when such OAM frames belong to the 519 same level or to a lower-level OAM. (Trivially met because 520 hierarchical domains are independent technologies.) 521 R20) NVO3 OAM frames from outside an NVO3 domain MUST be transported 522 transparently inside the NVO3 domain when such OAM frames belong to a 523 higher-level NVO3 domain. (Trivially met because hierarchical 524 domains are independent technologies). 526 5.13. Transport Independence 528 Similar to transport requirement from [RFC6136], we expect NVO3 OAM 529 will leverage the OAM capabilities of the transport layer (e.g., IP 530 underlay). 532 R21) NVO3 OAM MAY allow adaptation/interworking with its IP underlay 533 OAM functions. For example, this would be useful to allow fault 534 notifications from the IP layer to be sent to the NVO3 layer and 535 likewise exposure of LAG / ECMP will require such non-independence. 537 5.14. Application Independence 539 R22) NVO3 OAM MUST [*** discuss -- is this too strong? ***] be 540 independent of the application technologies and specific application 541 OAM capabilities. 543 [Comment -- ECM: Noticed Nicira implementation has a dedicated NVP 544 manager node to play the role of FCAPS here. It is both application 545 layer and OAM layer. May not meet this requirement. In reality, due 546 to the nature of overlay network, very often, vendors are going to 547 make everything all together to a dedicated manager node.] 549 5.15. Prioritization 551 R23) NVO3 OAM messages MUST be preferentially treated in NVE and 552 between NVEs, since NVO3 OAM MAY be used to trigger protection 553 switching. As noted above (R2), protection switching is the 554 automatic replacement of a failed transmission facility with a 555 working one providing equal or greater capacity, typically within a 556 few tens of milliseconds from fault detection. 558 [Comment -- ECM: giving NVO3 OAM messages priority treatment may 559 interfere with measurements of frame delay and jitter.] 561 6. Items for Further Discussion 563 This section identifies a set of operational items which may be 564 elaborated further if these items fall within the scope of the NVO3. 566 o VNID renumbering support 567 * Means to change the VNID assigned to a given instance MUST [*** 568 discuss: is this too strong? ***] be supported. 570 * System convergence subsequent to VNID renumbering MUST NOT take 571 longer than a few seconds, to minimize impact on the tenant 572 systems. 574 * A VNE MUST be able to map a VNID with a virtual network 575 context. 577 o VNI migration and management operations 579 * Means to delete an existing VNI MUST be supported. 581 * Means to add a new VNI MUST be supported. 583 * Means to merge several VNIs MAY be supported. 585 * Means to retrieve reporting data per VNI MUST be supported. 587 * Means to monitor the network resources per VNI MUST be 588 supported. 590 o Support of planned maintenance operations on the NVO3 591 infrastructure 593 * Graceful procedure to allow for planned maintenance operation 594 on NVE MUST be supported. This includes undoing any 595 configuration changes made for maintenance purposes after 596 completion of the maintenance. 598 o Support for communication among virtual networks 600 * For global reachability purposes, communication among virtual 601 networks MUST be supported. This can be enforced using a NAT 602 function. 604 o Activation of new network-related services to the NVO3 606 * Means to assist in activating new network services (e.g., 607 multicast) without impacting running service should be 608 supported. 610 o Inter-operator NVO3 considerations 612 * As NVO3 may be deployed over inter-operator infrastructure, 613 coordinating OAM actions in each individual domain are required 614 to ensure an end-to-end OAM. In particular, this assumes 615 existence of agreements on the measurement and monitoring 616 methods, fault detection and repair actions, extending QoS 617 classes (e.g., DSCP mapping policies), etc. 619 [[DISCUSSION NOTE: Should inter-operator issues be declared 620 out of scope?]] 622 7. IANA Considerations 624 This memo includes no request to IANA. 626 8. Security Considerations 628 TBD 630 9. Acknowledgements 632 The authors are grateful for the contributions of David Black, Dennis 633 Qin, Erik Smith and Ziye Yang to this latest version. 635 10. References 637 10.1. Normative References 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, March 1997. 642 10.2. Informative References 644 [IEEE802.1ag] 645 IEEE, "IEEE Standard for Local and metropolitan area 646 networks - Virtual Bridged Local Area Networks, Amendment 647 5: Connectivity Fault Management", 2007. 649 [IEEE802.1ah] 650 IEEE, "IEEE Standard for Local and metropolitan area 651 networks - Virtual Bridged Local Area Networks, Amendment 652 6: Provider Backbone Bridges", 2008. 654 [NM-Standards] 655 ITU-T, "ITU-T Recommendation M.3400 (02/2000) - TMN 656 Management Functions", February 2000. 658 [NVO3-DP-Reqs] 659 Bitar, N., Lasserre, M., Balus, F., Morin, T., Jin, L., 660 and B. Khasnabish, "NVO3 Data Plane Requirements", October 661 2012. 663 [NVO3-framework] 664 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 665 Rekhter, "Framework for DC Network Virtualization", July 666 2012. 668 [RFC6136] Sajassi, A. and D. Mohan, "Layer 2 Virtual Private Network 669 (L2VPN) Operations, Administration, and Maintenance (OAM) 670 Requirements and Framework", RFC 6136, March 2011. 672 [Y.1731] ITU-T, "ITU-T Recommendation Y.1731 (02/08) - OAM 673 functions and mechanisms for Ethernet based networks", 674 February 2008. 676 Authors' Addresses 678 Peter Ashwood-Smith 679 Huawei Technologies 680 303 Terry Fox Drive, Suite 400 681 Kanata, Ontario K2K 3J1 682 Canada 684 Phone: +1 613 595-1900 685 Email: Peter.AshwoodSmith@huawei.com 687 Ranga Iyengar 688 Huawei Technologies USA 689 2330 Central Expy 690 Santa Clara, CA 95050 691 USA 693 Email: ranga.Iyengar@huawei.com 695 Tina Tsou 696 Huawei Technologies USA 697 2330 Central Expy 698 Santa Clara, CA 95050 699 USA 701 Email: Tina.Tsou.Zouting@huawei.com 702 Ali Sajassi 703 Cisco Technologies 704 170 West Tasman Drive 705 San Jose, CA 95134 706 USA 708 Email: sajassi@cisco.com 710 Mohamed Boucadair 711 France Telecom 712 Rennes 35000 713 France 715 Email: mohamed.boucadair@orange.com 717 Christian Jacquenet 718 France Telecom 719 Rennes 35000 720 France 722 Email: christian.jacquenet@orange.com 724 Masahiro Daikoku 725 KDDI corporation 726 3-10-10, Iidabashi, Chiyoda-ku 727 Tokyo 1028460 728 Japan 730 Email: ms-daikoku@kddi.com