idnits 2.17.1 draft-xwu-bmwg-nslam-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 : ---------------------------------------------------------------------------- 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 (November 15, 2017) is 2353 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'L2SM' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'RFC8049' is defined on line 620, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 8049 (Obsoleted by RFC 8299) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Benchmarking Workgroup S. Wu 3 Internet-Draft Juniper Networks 4 Intended status: Informational November 15, 2017 5 Expires: May 19, 2018 7 Network Service Layer Abstract Model 8 draft-xwu-bmwg-nslam-00 10 Abstract 12 While the networking technologies have evolved over the years, the 13 layered approach has been dominant in many network solutions. Each 14 layer may have multiple interchangeable, competing alternatives that 15 deliver a similar set of functionality. In order to provide an 16 objective benchmarking data among various implementations, the need 17 arises for a common abstract model for each network service layer, 18 with a set of required and optional specifications in respective 19 layers. Many overlay and or underlay solutions can be described 20 using these models. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 19, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Purpose of The Document . . . . . . . . . . . . . . . . . 3 59 1.3. Conventions Used in This Document . . . . . . . . . . . . 3 60 2. Network Service Framework . . . . . . . . . . . . . . . . . . 3 61 2.1. Node . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.3. Infrastructure . . . . . . . . . . . . . . . . . . . . . 7 64 2.4. Services . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3. Service Models . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. Layer 2 Ethernet Service Model . . . . . . . . . . . . . 9 67 3.2. Layer 3 Service Model . . . . . . . . . . . . . . . . . . 10 68 3.3. Infrastructure Service Model . . . . . . . . . . . . . . 10 69 3.4. Node Level Features . . . . . . . . . . . . . . . . . . . 11 70 3.5. Common Service Specification . . . . . . . . . . . . . . 11 71 3.6. Comment Network Events . . . . . . . . . . . . . . . . . 12 72 4. Use of Network Service Layer Abstract Model . . . . . . . . . 12 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 8.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 This document provides a reference model for common network service 84 framework. The main purpose is to abstract service model for each 85 network layer with a small set of key specifications. This is 86 essential to characterize the capability and capacity of a production 87 network, a target network design. A complete service model mainly 88 includes 90 Infrastructure - devices, links, and other equipment. 92 Services - network applications provisioned. It is often defined 93 as device configuration and or resource allocation. 95 Capacity - A set of objects dynamically created for both control 96 and forwarding planes, such as routes, traffic, subscribers and 97 etc. In some cases, the amount and types of traffic may impact 98 control plane objects, such as multicast or ethernet networks. 100 Performance Metrics - infrastructure resource utilization. 102 1.1. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 1.2. Purpose of The Document 110 Many efforts to YANG model and OpenConfig collaboration are well 111 under way. This document specifies a higher layer abstraction that 112 reuses a small subset of YANG keywords for service description 113 purpose. It SHALL NOT be used for production provisioning purpose. 114 Instead, it can be adopted for design spec, capacity planning, 115 product benchmarking and test setup. 117 The specification described in this document SHALL be used for 118 outline service requirements from customer perspective, instead of 119 network implementation mechanism from operators perspective. 121 1.3. Conventions Used in This Document 123 Descriptive terms can quickly become overloaded. For consistency, 124 the following definitions are used. 126 o Node - The name for an attrubute. 128 o Brackets "[" and "]" enclose list keys. 130 o Abbreviations before data node names: "rw" means configuration 131 data (read-write), and "ro" means state data (read-only). 133 o Parentheses enclose choice and case nodes, and case nodes are also 134 marked with a colon (":"). 136 2. Network Service Framework 138 The network service layer abstract model is illustrated by Figure 1. 139 This shows a stack of components to enable end-to-end services. Not 140 all components are required for a given service. A common use case 141 is to pick one component as target service with a detailed profile, 142 with the remaining components as supporting technologies using 143 default profiles. 145 Network Service Layer Abstract Model 147 +---+-+-+-+---+-+-+-+-+ 148 | S |L|L| | |L| |L| | 149 | E |2|2|V| E |3|M|U|6| 150 | R |V|C|P| V |V|V|B|P| 151 | V |P|K|L| P |P|P|G|E| 152 | I |N|T|S| N |N|N|P| | 153 | C +-+-+-+-+-+-+-+-+-+ 154 | E | L2SVC | L3SVC | 155 +---+-------+---------+ 156 | | BGP | 157 | I +-----------------+ 158 | N | Transport | 159 | F +-----------------+ 160 | R | IGP | 161 | A +-----------------+ 162 | | Bridging | 163 +---+---------+-------+ 164 | T | | Active| 165 | O | Logical |Standby| 166 | P +---------+ M-Home| 167 | O | Physical| L/B | 168 +---+-+-+-+-+-+-+-+-+-+ 169 | N |I| | | | |C| | |I| 170 | O |N|F|Q| | |G|N|N|S| 171 | D |T|A|O|F|G|S|S|S|S| 172 | E |F|B|S|W|R|S|R|F|U| 173 +---+-+-+-+-+-+-+-+-+-+ 175 Figure 1 177 2.1. Node 179 A network node or a network device processes and forwards traffic 180 based on predefined or dynamically learned policies. This section 181 covers standalone features like the following: 183 o INTF - Network interfaces that provides internal or external 184 connectivity to adjacent devices. Only physical properties of the 185 interfaces are of concern in this level. The interfaces can be 186 physical or logical, wired or wireless. 188 o FAB - Fabric capacity. It provides redundancy and cross connect 189 within the same network device among various linecards or 190 interfaces 192 o QOS - Quality of Services. Traffic queuing, buffering, and 193 congestion management technologies are used in this level 195 o FW - Firewall filters or access control list. This commonly 196 refers to stateless packet inspection and filtering. Stateful 197 firewall is out of scope of this document. Number of filters 198 daisy chained on a given protocol family, number of terms within 199 same filter, and depth of packet inspection can all affect speed 200 and latency of traffic forwarding. It also provides necessary 201 security protection of node, where protocol traffic may be 202 affected. 204 o GR - Graceful Restart per protocol. It needs to cooperate with 205 adjacent node 207 o CGSS - Controller Graceful / Stateful Switchover. A network 208 device often has two redundant controllers to minimize the 209 disruption in event of catastrophic failure on the primary 210 controller. This is accomplished via real time state 211 synchronization from the primary to the backup controller. It, 212 however, should be used along with either NSR or NSF to achieve 213 optimal redundancy. 215 o NSR - Non-Stop Routing - hitless failover of route processor. It 216 maintains an active copy of route information base (RIB) as well 217 as state for protocol exchange so that the protocol adjacency is 218 not reset. 220 o NSF - Non-Stop Forwarding for layer 2 traffic, including layer 2 221 protocols such as spanning tree state 223 o ISSU - In Service Software Upgrade - Sub-second traffic loss in 224 many modern routing platforms. The demand for this feature 225 continues to grow from the field. Some study shows that the 226 downtime due to software upgrade is greater than that caused by 227 unplanned outages. 229 2.2. Topology 231 Placement of network devices and corresponding links plays an 232 important role for optimal traffic forwarding. There are two types 233 of topologies: 235 o Physical Topology - Actual physical connectivity via fiber, coax, 236 cat5 or even wireless. That could be a ring, bus, star or matrix 237 topology. Even though all can be modeled using point-to-point 238 connections. 240 o Logical Topology - With aggregated ethernet, extended dot1q 241 tunneling, or VxLAN, a logical or virtual topology can be easily 242 created spanning across geography boundaries. Recent development 243 of multi-chassis, virtual-chassis, node-slicing technologies, and 244 multiple logical units within a single physical node have enabled 245 logical topology deployment more flexible and agile. 247 With various topology, the following funtionalities need to be taken 248 into consideration for feature design and validation. 250 o Active-Standby - 1:1 or 1:n support. The liveness detection is 251 essential to trigger failover. 253 o M-Home - Multi-homing support. A customer edge (CE) device can be 254 homed to 2 or more Provider Edge (PE) devices at the same time. 255 This is a common redundancy design in layer 2 service offering 257 o L/B - Load Balancing - When multiple diverse paths exist for a 258 given destination, it is important to achieve load balancing based 259 on multiple criteria, such as per packet, or per prefix. 260 Sometimes, cascading effect can make issues more complex and 261 harder to resolve 263 The topology, regardless of physical or virtual, can be better 264 depicted using a collection of nodes and point-to-point links. Some 265 broadcast network, or ring topology, can also be abstracted using 266 same collection of point-to-point links. For example, in a wireless 267 LAN network, each client is a node with wireless LAN NIC as its 268 physical interface. The access point is the node, at which all WLAN 269 cients terminate with airwaves. The Service Set IDentifier (SSID) on 270 this access point can be considered as part of broadcast domain with 271 many pseudo-ports taking airwave terminations from clients. 273 The default link id can use srcnode-dstnode-linkseq to uniquely 274 identify a link in this topology. If this is a link connecting two 275 ports on the same node, it can use link-id of srcnode-srcnode- 276 linkseq-portseq. Additional attributes of the node can be added with 277 proper placement for auto topology diagram. 279 Network Topology Definition 281 node-id-1 { 282 maker: maker_name, 283 model: model_name, 284 controller: controller-type, 285 mgmt_ip: mgmt_ip_address, 286 links: { 287 link-id-1 { 288 name: link_name, 289 connector: 'sfpp', 290 attr: ['10G', 'Ethernet'], 291 node_dst: destination node-id, 292 link_seq: sequence number for links between the node pair 293 ... 294 } 295 } 296 ... 297 } 298 node-id-2 { 299 ... 300 } 302 Figure 2 304 2.3. Infrastructure 306 Network infrastructure here refers to a list of protocols and 307 policies for a data center network, an enterprise network, or a core 308 backbone in a service provider network. 310 o Bridging - Spanning Tree Protocol (STP) and its various flavors, 311 802.1q tunneling, Q-in-Q, VRRP and etc 313 o IGP - Interior Gateway Protocol - some common choices are OSPF, 314 IS-IS, RIP, RIPng. For multicast, choices are PIM and its various 315 flavors including MSDP, Bootstrap, DVMRP 317 o Transport - Tunnel technologies including 319 * MPLS - Multi-Protocol Label Switching - most commonly used in 320 service provider network 322 + LDP - Label distribution protocol - including mLDP and LDP 323 Tunneling through RSVP LSPs 325 + RSVP - Resource Reservation Protocol - including P2MP and 326 its various features like Fast ReRoute - FRR. 328 * IPSec - IPSec Tunnel with AH or ESP 330 * GRE - Generic Routing Encapsulation (GRE) tunnels provides a 331 flexible direct adjacency between two remote routers 333 * VxLAN - In data center interconnect (DCI) solutions, VxLAN 334 encapsulation provides data plane for layer 2 frames 336 o BGP - Define families and their sub-SAFI deployed, as well as 337 route reflector topology. 339 2.4. Services 341 Previous sections mostly outline an operator's implementation of the 342 network, while customers may not necessarily care about these. This 343 section defines service profiles from customer's view. 345 o Layer 2 Services 347 * Layer 2 VPN - RFC 6624 349 * Martini Layer 2 Circuit - RFC 4906 351 * Virtual Private LAN Services - RFC 4761 353 * Ethernet VPN - RFC 7432 355 o Layer 3 Services 357 * Type 5 Route for EVPN - draft-ietf-bess-evpn-prefix- 358 advertisement-05 360 * Layer 3 VPN - RFC 4364 362 * Labled Unicast BGP - RFC 3107 364 * Draft Rosen MVPN - RFC 6037 366 * NG MVPN - RFC 6513 368 * 6PE - RFC 4798 370 In next section, an abstract model is proposed to identify key 371 metrics for both layer 2 and layer 3 model 373 3. Service Models 375 A service model is a high level abstraction of network deployment 376 from bottom up. It defines a set of common key characteristics of 377 customer traffic profile in both control and forwarding planes. The 378 network itself should be considered as a blackbox and deliver the 379 services regardless of types of network equipment vendor or network 380 technologies. 382 The abstraction removes some details like specific IP address 383 assignment, and favors address range and its distribution. The goal 384 is to describe aggregated network behavior instead of granular 385 network element configuration. It is up to implementation to map 386 aggregated metrics to actual configuration for the network devices, 387 protocol emulator and traffic genrator. 389 A single network may be comprised of multiple instances of service 390 models defined below. 392 3.1. Layer 2 Ethernet Service Model 394 The metrics outlined below are for layer 2 network services typically 395 within a data center, data center interconnect, metro ethernet, or 396 layer 2 domain over WAN or even inter-carrier. 398 o service-type: identityref, ELAN, ELINE, ETREE 399 o sites-per-instance: uint32, an avrage number of sites a layer 2 400 instance may span across 401 o global-mac-count: uint32, Global MAC from all attachment circuits, 402 local and remote. This is probably the most important metric that 403 determines the capacity requirements in layer 2 for both control 404 and forwarding planes 405 o interface-mac-max: uint32, maxiumum number of locally learned MAC 406 addresses per logical interface, aka attachment circuit 407 o single-home-segments: uint32, number of single homed ethernet 408 segments per service instance 409 o multi-home-segments: uint32, number of multi homed ethernet 410 segments per layer 2 service instance 411 o service-instance-count: uint32, total number of layer 2 service 412 instances. Typically, one customer is 413 o traffic-type: list, {known-unicast: %, multicast, %, broadcast: %, 414 unknown-unicast: %} 415 o traffic-frame-size: list, predefined mixture of traffic frame size 416 distribution 417 o traffic-load: speed of traffic being sent towards the network. 418 This can be defined as frame per second (fps), or actual speed in 419 bps. This is particular important whenever some component along 420 forwarding path is implemented in software, the throughput might 421 be affected significantly at high speed 422 o traffic-flow: A distribution of flows. This may affect efficient 423 use of load-balancing techniques and resource consumption. More 424 details discussed in later section of this document. 425 o layer3-gateway-count: uint32, number of layer 2 service instances 426 that also provide layer 3 gateway service 427 o arpnp-table-size: uint32. This is only relevant with presence of 428 layer 3 gateway 430 Integrated routing and bridging (IRB) and EVPN Type 5 route have 431 blurred boundaries between layer 2 and layer 3 services. 433 3.2. Layer 3 Service Model 435 This section outlines traffic type, layer 3 protocol families, layer 436 3 prefixes distribution, layer 3 traffic flow and packet size 437 distributions. 439 o proto-family: protocol family are defined with three sub- 440 attributes. The list may grow as the complexity 442 * proto - list: inet, inet6, iso 443 * type - list: unicast, mcast, segment, labeled 444 * vpn - list, true, false 445 o prefix-count, uint32, total unique prefixes 446 o prefix-distrib, list of prefix length size and percentage. This 447 could be a distribution pattern, such as uniform, random. Or 448 simply top representation of prefix lengths 449 o bgp-path-count, uint32, total BGP paths 450 o bgp-path-distrib, top representation of number of paths per prefix 451 o traffic-frame-size, similar to traffic-frame-size in layer 2 452 model. The focus is on the MTU size on each protocol interfaces 453 and the impact of fragmentation 454 o traffic-flow, similar to traffic-flow in layer 2 model, it focuses 455 on a set of labels, source and destination addresses as well as 456 ports 457 o traffic-load, similar to traffic-load in layer 2 model 458 o ifl-count, uint32, 459 o vpn-count, uint32, 461 3.3. Infrastructure Service Model 463 o bgp-peer-ext-count, uint32, number of eBGP peers 464 o bgp-peer-int-count, uint32, number of iBGP peers 465 o bgp-path-mtu, list, true or false. Larger path mtu helps 466 convergence 468 o bgp-hold-time-distrib, list of top hold-time values and their 469 respective percentage out of all peers. 470 o bgp-as-path-distrib, list of top as-path lengths and their 471 respective percentage of all BGP paths 472 o bgp-community-distrib, list of top community size and their 473 respective percentage out of all BGP paths 474 o mpls-sig, list, MPLS signaling protocol, rsvp or ldp 475 o rsvp-lsp-count-ingress, uint32, total ingress lsp count 476 o rsvp-lsp-count-transit, uint32, total transit lsp count 477 o rsvp-lsp-count-egress, uint32, total egress lsp count 478 o ldp-fec-count, uint32, total forwarding equivalence class 479 o rsvp-lsp-protection, list, link-node, link, frr 480 o ospf-interface-type, list, point-to-point, broadcast, non- 481 broadcast multi-access 482 o ospf-lsa-distrib, list. OSPF Link Statement Advertisement 483 distribution is comprised of those for core router in backbone 484 area, and internal router in non-Backbone areas. A common 485 modeling can include number of LSAs per OSPF LSA type 486 o ospf-route-count, list, total OSPF routes in both backbone and 487 non-backbone areas 488 o isis-lsp-distrib, list, similar to ospf-lsa-distrib 489 o isis-route-count, list, total IS-IS routes in both level-1 and 490 level-2 areas 492 TODO: bridging, OAM, EOAM, BFD and etc 494 3.4. Node Level Features 496 TODO: node level feature set 498 3.5. Common Service Specification 500 For most network services, regardless of layer 2 or layer 3, protocol 501 families, the following needs to be considered when measuring network 502 capacity and baseline. 504 o rib-learning-time, uint32 in seconds. This indicates show quickly 505 the route processor learns routing objects either locally and 506 remotely 507 o fib-learning-time. In large routing system, forwarding engine 508 residing on separate hardware from controller, takes additional 509 time to install all forwarding entries learned by controller. 510 o convergence-time, this is could be as a result of many events, 511 such as uplink failure, ae member link failure, fast reroute, 512 local repair, upstream node failure and etc 513 o multihome-failover-time, this refers to traffic convergence in a 514 topology where a customer edge (CE) device is connected to two or 515 more provider edge (PE) devices. 517 o issu-dark-window-size. Unlike NSR, the goal of ISSU is not zero 518 packet loss. Instead, there will be a few seconds, or in some 519 cases, sub-second dark window where it sees both total packet loss 520 for both transit and or host bound protocol traffic. 521 o cpu-util, total CPU utilization of the controllers in stead state 522 o cpu-util-peak, Peak CPU utilization on the controller in event of 523 failure, and convergence 524 o mem-util, total memory utilization of the controllers in steady 525 state 526 o mem-util-peak, total memory utilization on the controller in event 527 of failure and convergence 528 o processes, list of top processes running on the controllers with 529 their CPU and memory utilization. 530 o lc-cpu-util, top CPU utilization on the line cards 531 o lc-cpu-util-peak, maximum peak CPU utilization among all line 532 cards in event of failure and convergence 533 o lc-mem-util, top memory utilization on the line cards 534 o lc-mem-util-peak, maximum peak memory utilization among all line 535 cards in event of failure and convergence 536 o throughout, in both pps and bps. This is measured with zero 537 packet loss. For virtualized environment, throughput is sometimes 538 measured with a small loss tolerance given the nature of shared 539 resource 540 o traffic performance, in both pps and bps. It is measured the rate 541 of traffic received by pumping oversubscribed traffic at ingress 542 o latency in us. this is more important within a local data center 543 environment rather than DCI over wide area network. Use of 544 extensive firewall filter or access control lists may affect 545 latency 546 o Out of Order Packet - This can happen in intra-node or over ECMP 547 where different paths have large latency/delay variations. 549 The list of metrics can be used for network monitoring during network 550 resiliency test. This is to understand how quickly a network service 551 can restore during various events and failures 553 3.6. Comment Network Events 555 TODO: A list of events to be defined to characterize network 556 resiliency. These attributes require the provider networks have 557 diverse paths and node redundancy built-in. These numbers affect 558 service level agreement and network availability 560 4. Use of Network Service Layer Abstract Model 562 The primary goal is to characterize and document a complex network 563 using a simplified service model. While eliminating many details 564 such as address assignment, actual route or mac entries, it retains a 565 set of key network information, including services, scale, and 566 performance profiles. This can be used to validate how well each 567 underlying solution performs when delivering same set of services. 569 The model can also be used to build a virtualized topology with both 570 static and dynamic scale closely resemble to a real network. This 571 eases network design and benchmarking, and helps capacity planning by 572 studying the impact with changes to a specific dimension. 574 5. Acknowledgements 576 The authors appreciate and acknowledge comments from Al Morton and 577 others based on initial discussions. 579 6. IANA Considerations 581 This memo includes no request to IANA. 583 All drafts are required to have an IANA considerations section (see 584 Guidelines for Writing an IANA Considerations Section in RFCs 585 [RFC5226] for a guide). If the draft does not require IANA to do 586 anything, the section contains an explicit statement that this is the 587 case (as above). If there are no requirements for IANA, the section 588 will be removed during conversion into an RFC by the RFC Editor. 590 7. Security Considerations 592 All drafts are required to have a security considerations section. 593 See RFC 3552 [RFC3552] for a guide. 595 8. References 597 8.1. Normative References 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, 601 DOI 10.17487/RFC2119, March 1997, . 604 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 605 Text on Security Considerations", BCP 72, RFC 3552, 606 DOI 10.17487/RFC3552, July 2003, . 609 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 610 IANA Considerations Section in RFCs", RFC 5226, 611 DOI 10.17487/RFC5226, May 2008, . 614 8.2. Informative References 616 [L2SM] B. Wu et al, "A Yang Data Model for L2VPN Service 617 Delivery", 2017, . 620 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 621 Model for L3VPN Service Delivery", RFC 8049, 622 DOI 10.17487/RFC8049, February 2017, . 625 Author's Address 627 Sean Wu 628 Juniper Networks 629 2251 Corporate Park Dr. 630 Suite #200 631 Herndon, VA 20171 632 US 634 Phone: +1 571 203 1898 635 Email: xwu@juniper.net