idnits 2.17.1 draft-xie-l3sm-l2vpn-service-model-01.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 == Line 223 has weird spacing: '...pend on depen...' == Line 394 has weird spacing: '...-bitmap str...' == Line 395 has weird spacing: '...-bitmap str...' == Line 396 has weird spacing: '...-bitmap str...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 1, 2015) is 3071 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) ** Downref: Normative reference to an Informational RFC: RFC 3809 ** Downref: Normative reference to an Informational RFC: RFC 4664 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3SM Working Group C. Xie 3 Internet-Draft A. Wang 4 Intended status: Standards Track China Telecom 5 Expires: May 4, 2016 R. Schott 6 Deutsche Telekom 7 D. Zhang 8 November 1, 2015 10 YANG Data Model for L2VPN service 11 draft-xie-l3sm-l2vpn-service-model-01 13 Abstract 15 This document provides an example of service yang data model for 16 layer 2 provider provisioned VPN service. Unlike L3VPN, L2VPN 17 doesn't provide L3 interface to customer using IP infrastructure or 18 doesn't provide IP connectivity between pairs of customer sites. 19 Therefore straight augment the l3vpn model with l2vpn parameters may 20 not be appropriate. However [draft-ietf-l3sm-l3vpn-service-model] 21 has defined a lot of reusable groupings such as operational- 22 requirements, customer-location-info, site-diversity ,site- 23 availability,etc. In this document, we reuse these common groupings 24 and add some l2vpn parameters to develop the l2vpn service model. 26 Similar to the l3vpn service model, this model provides an abstracted 27 view of the Layer 2 service configuration components. It will be up 28 to a management system to take this as an input and use specific 29 configurations models to configure the different network elements to 30 deliver the service. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 4, 2016. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 68 2.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 4 69 3. L2VPN and L3VPN comparison . . . . . . . . . . . . . . . . . 5 70 4. Layer 2 VPN service model design . . . . . . . . . . . . . . 7 71 4.1. Reuse the groupings defined in L3SM service model . . . . 7 72 4.2. Customer lan connection . . . . . . . . . . . . . . . . . 7 73 4.3. Attachment . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.4. QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 78 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 80 10. Normative References . . . . . . . . . . . . . . . . . . . . 23 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 83 1. Introduction 85 Layer 2 VPN emulates the behavior of a local area network (LAN) 86 across an internet protocol (IP) or MPLS-enabled IP network allowing 87 Ethernet devices to communicate with each other as if they were 88 connected to a common LAN segment[RFC4664]. Building a L2VPN system 89 requires coordination between the Service Provider and the customer. 90 The Service Provider provides L2 connectivity; the customer builds a 91 network using data link resources obtained from the Service Provider. 92 In an L2VPN service, the Service Provider does not require 93 information about a customer's network topology, policies, routing 94 information, point-to-point links. 96 The Service Provider only requires Provider Edge (PE) routers with 97 the following capabilities: 99 o Encapsulation of L2 protocol data units (PDU) into layer 3 packets 101 o Inter-connection of any-to-any L2 transports. 103 o Emulation of L2 quality-of-service (QoS) over a packet switch 104 network. 106 o Ease of configuration of the L2 service. 108 o Support for different types of tunneling mechanisms (MPLS, L2TPv3, 109 IPSec, GRE, and others) 111 o L2VPN process databases include all information related to 112 circuits and their connections. 114 This document provides an example of service model for Layer 2 VPN 115 service. It can be used by a management system as an input then 116 choice suited configurations models to configure the different 117 network elements to deliver the service. 119 2. Conventions and Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 The following notations are used within the data tree and carry the 126 meaning as below. 128 Each node is printed as: 129 131 is one of: 132 + for current 133 x for deprecated 134 o for obsolete 135 is one of: 136 rw for configuration data 137 ro for non-configuration data 138 -x for rpcs 139 -n for notifications 140 is the name of the node 142 If the node is augmented into the tree from another module, its name 143 is printed as :. 144 is one of: 145 ? for an optional leaf or choice 146 ! for a presence container 147 * for a leaf-list or list 148 [] for a list's keys 149 is the name of the type for leafs and leaf-lists 151 In this document, these words will appear with that interpretation 152 only when in ALL CAPS. Lower case uses of these words are not to be 153 interpreted as carrying RFC-2119 significance. 155 2.1. Terminologies 157 VPLS A VPLS is a provider service that emulates the full 158 functionality of a traditional Local Area Network (LAN). A VPLS 159 makes it possible to interconnect several LAN segments over a 160 packet switched network (PSN) and makes the remote LAN segments 161 behave as one single LAN. 163 VPW A Virtual Private Wire Service (VPWS) is a point-to-point 164 circuit (link) connecting two Customer Edge devices. The link is 165 established as a logical through a packet switched network. The 166 CE in the customer network is connected to a PE in the provider 167 network via an Attachment Circuit; the Attachment Circuit is 168 either a physical or a logical circuit. 170 3. L2VPN and L3VPN comparison 172 There are two fundamentally different kinds of Layer 2 VPN service 173 that a service provider could offer to a customer: Virtual Private 174 Wire Service (VPWS) and Virtual Private LAN Service (VPLS). There is 175 also the possibility of an IP-only LAN-like Service (IPLS)[RFC4664]. 176 The VPN service must match the type of service required by the VPN 177 user. Different VPN solutions offer either layer 2 or layer 3 178 connectivity between VPN sites. 180 Below is a table for comparison analysis between L2VPN and L3VPN 181 service. 183 ---------------|-----------------------------+----------------------| 184 | PE-based Layer 2 | PE-based Layer 3 | 185 | | | 186 ---------------|---------+---------+---------+----------+-----------+ 187 |VPWs | VPLS | IPLS |RFC4364 | vRouter | 188 ---------------+---------+---------+---------+----------+-----------+ 189 Traffic Types |ATM/FR | Ethernet| IP over | IPv4 and IPv6 | 190 | | |Ethernet | | 191 ---------------+---------+---------+---------+----------+-----------+ 192 VLAN support | Depends | Yes | Depends | No | 193 | | | | | 194 --------------------------------------------------------------------+ 195 Topology | any to any| Depends | any to any,hub spoke | 196 paradigm | p2p |hub spoke| | hub spoke disjoint | 197 --------------------------------------------------------------------+ 198 TE support | | | | | | 199 through provider Yes | Yes | Yes | Yes | Yes | 200 network | | | | | | 201 --------------------------------------------------------------------+ 202 Routing | No | No | No | Yes | 203 Interaction | | | | | 204 --------------------------------------------------------------------+ 205 VPN capable | | | | | | 206 on CE | No | No | No | No | No | 207 | | | | | | 208 --------------------------------------------------------------------+ 209 VPN capable | Yes | Yes | Yes | Yes | Yes | 210 on PE | | | | | | 211 --------------------------------------------------------------------+ 212 VPN config | some | No | No | No | No | 213 on CE | | | | | | 214 --------------------------------------------------------------------+ 215 Scale for PE | well |not well | well | well | not well | 216 | |unless | | | 217 distributed | 219 --------------------------------------------------------|-----------+ 220 Scale for Sites| Poorly | 10s of 100s of | well | 100s of | 221 | | sites | sites | | site | 222 ---------------|-------------------|---------|----------|-----------+ 223 Security |depend on|depend on|depend on depend on| depend on | 224 |tunnel | tunnel | tunnel | tunnel | tunnel | 225 --------------------------------------------------------------------+ 227 ---------------|----------------------| 228 | CE based VPN | 229 | | 230 ---------------+----------------------+ 231 Traffic Types | L2 or L3 | 232 | | 233 ---------------+----------------------+ 234 VLAN Support | Required in L2 | 235 | | 236 ---------------+----------------------+ 237 Topo paradigm | depends | 238 | | 239 ---------------+----------------------+ 240 TE support | | 241 through provider No | 242 network | | 243 --------------------------------------+ 244 Routing | required in L3 | 245 Interaction | | 246 --------------------------------------+ 247 VPN capable | Yes | 248 on CE | | 249 | | 250 --------------------------------------+ 251 VPN capable | No | 252 on PE | | 253 --------------------------------------+ 254 VPN config | Yes | 255 on CE | | 256 --------------------------------------+ 257 Scale for PE | N/A | 258 | | 259 -------------------------- -----------+ 260 Scale for Sites| N/A | 261 | | 262 ---------------|---------- -----------+ 263 Security | depend on | 264 | tunnel | 265 --------------------------------------+ 266 Compared with L3VPN, L2VPN has High scalability sinceMPLS L2VPN 267 establishes only Layer 2 connections and It does not involve the 268 routing information of users. This greatly reduces the load of the 269 PEs and even the load of the whole service provider network, enabling 270 carriers to support more VPNs and more users. In addition, L2VPN 271 provides Guaranteed reliability and private routing information 272 security since no routing information of users is involved, L2VPN 273 neither tries to obtain nor processes the routing information of 274 users, guaranteeing the security of the user VPN routing information. 276 4. Layer 2 VPN service model design 278 4.1. Reuse the groupings defined in L3SM service model 280 [RFC3809] provides requirements that are generic to both Layer 2 281 Virtual Private Networks (L2VPN) and Layer 3 Virtual Private Networks 282 (L3VPN).These requirements are independent of any particular type of 283 PPVPN technology and include service, provider and engineering 284 requirements. In this document, we reuse some common groupings 285 corresponding to these requirements which are defined in the [L3VPN- 286 svc]. 288 The following table summarizes the common grouping which are used in 289 this document: 291 grouping name: 293 vpn-svc-cfg 294 operational-requirements 295 customer-location-info 296 site-diversity 297 site-availability 298 site-management 299 site-vpn-policy 300 site-security-authentication 301 site-security-encryption 302 site-security-acl 303 site-service-protection 304 site-service-mpls 305 site-service-multicast 307 4.2. Customer lan connection 309 In this document, we analyzed the different of L2VPN and L3VPN in 310 section 2. The major differences are traffic type and connectivity 311 type, e.g., Layer 2 services is usually based on frame relay and 312 asynchronous transfer mode (ATM) while Layer 3 service is based on 313 IPv4 and IPv6. 315 In Layer 2 VPN, The VC labels are used by the PE routers for 316 demultiplexing traffic arriving from different L2VPN services over 317 the same set of tunnel/PW. And the MAC address also be used in the 318 layer 2 customer lan connection: 320 | +--rw customer-specific-information 321 | | ...... 322 | | +--rw customer-lan-connection* [address] 323 | | | +--rw address union 324 | | | +--rw lan-protocol? identityref 325 | | | +--rw vc-label? string 326 | | | +--rw mac-address? yang:mac-address 328 4.3. Attachment 330 In layer 2 VPN, the physical parameters of the attachment may be a 331 Frame Relay DLCI, an ATM VPI/VCI, an Ethernet port, a VLAN, a PPP 332 connection on a physical interface, etc. To make it easy to be 333 extended, in this document we define a bearer identity and several 334 other identities which are base on the bearer identity: 336 identity bearer{ 337 description 338 "base identity of bearer."; 339 } 341 identity ems{ 342 base bearer; 343 description 344 "identity of vpls ethernet mulitpoint service."; 345 } 347 identity emrs{ 348 base bearer; 349 description 350 "identity of vpls ethernet multipoint relay service."; 351 } 353 identity fr{ 354 base bearer; 355 description 356 "identity of Frame Relay"; 357 } 359 identity ethernet{ 360 base bearer; 361 description 362 "identity of ethernet."; 363 } 365 identity atm{ 366 base bearer; 367 description 368 "identity of ATM."; 369 } 371 identity ppp-or-hdlc{ 372 base bearer; 373 description 374 "identity of PPP/HDLC."; 375 } 377 4.4. QoS 379 For QoS service, the match-flow of L2VPN are quite different from 380 L3VPN's. The source/destination MAC address, local/remote label, 381 vlan id may be used: 383 +--rw service 384 ...... 385 +--rw qos 386 | +--rw qos-classification-policy 387 | +--rw rules* [id] 388 | +--rw id uint16 389 | +--rw match-flow 390 | | +--rw dest-mac-address? yang:mac-address 391 | | +--rw src-mac-address? yang:mac-address 392 | | +--rw local-label? string 393 | | +--rw remote-label? string 394 | | +--rw dot1q-vlan-bitmap string 395 | | +--rw qinq-svlan-bitmap string 396 | | +--rw qinq-cvlan-bitmap string 397 | | +--rw target-class-id? string 398 | +--rw std-qos-profile? string 399 ...... 401 5. YANG Module 403 file "ietf-l2vpn-svc.yang" 404 module ietf-l2vpn-svc { 405 namespace "urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc"; 407 prefix l2vpn-svc; 409 import ietf-routing { 410 prefix "rt"; 411 } 413 import ietf-inet-types { 414 prefix inet; 415 } 417 import ietf-yang-types { 418 prefix yang; 419 } 421 import ietf-l3vpn-svc{ 422 prefix l3vpn-svc; 423 } 425 organization 426 "IETF L3SM Working Group"; 428 contact 429 "WG List: 430 Editor: 432 "; 434 description 435 "The YANG module defines a generic service configuration 436 model for Layer 2 VPN common across all of the vendor 437 implementations."; 439 revision 2015-10-12 { 440 description 441 "l2vpn first version."; 442 reference ""; 443 } 445 /*identity*/ 446 identity bearer{ 447 description 448 "base identity of bearer."; 449 } 451 identity ems{ 452 base bearer; 453 description 454 "identity of vpls ethernet mulitpoint service."; 455 } 457 identity emrs{ 458 base bearer; 459 description 460 "identity of vpls ethernet multipoint relay service."; 461 } 463 identity fr{ 464 base bearer; 465 description 466 "identity of Frame Relay"; 467 } 469 identity ethernet{ 470 base bearer; 471 description 472 "identity of ethernet."; 473 } 475 identity atm{ 476 base bearer; 477 description 478 "identity of ATM."; 479 } 481 identity ppp-or-hdlc{ 482 base bearer; 483 description 484 "identity of PPP/HDLC."; 485 } 486 /* Groupings */ 488 container l2vpn-svc{ 489 description 490 "this container contains several " 491 +"l2vpn service parameters"; 492 list vpn-svc{ 493 key "name"; 494 description 495 "list of layer 2 vpn service"; 496 uses l3vpn-svc:vpn-svc-cfg; 497 } 499 list sites{ 500 key "site-id"; 501 description 502 "list of layer 2 vpn sites"; 503 leaf site-id{ 504 type string; 505 description 506 "site identifier"; 507 } 509 // apply-template 511 uses l3vpn-svc:operational-requirements; 512 uses l3vpn-svc:customer-location-info; 513 uses l3vpn-svc:site-diversity; 514 uses l3vpn-svc:site-availability; 515 uses l3vpn-svc:site-management; 516 uses l3vpn-svc:site-vpn-policy; 517 container customer-specific-information { 518 leaf name { 519 type string; 520 description 521 "Name of the customer router."; 522 } 523 leaf autonomous-system { 524 type uint32; 525 description 526 "AS number."; 527 } 528 leaf interface { 529 type string; 530 description 531 "Interface reference of the access."; 532 } 533 list customer-lan-connection { 534 key "address"; 535 leaf address { 536 type union { 537 type inet:ipv4-address; 538 type inet:ipv6-address; 539 } 540 description 541 "Address given by the customer on its LAN 542 for the SP router."; 543 } 544 leaf lan-protocol { 545 type identityref { 546 base rt:address-family; 547 } 548 description 549 "Transport protocol used on LAN."; 550 } 551 leaf vc-label{ 552 type string; 553 description 554 "the vc label of l2vpn"; 555 } 556 leaf mac-address{ 557 type yang:mac-address; 558 description 559 "mac address"; 560 } 561 description 562 "List of customer LAN to be connected 563 directly on the CE."; 564 } 565 container cascaded-lan-prefixes { 566 list ipv4-lan-prefixes { 567 key lan; 569 leaf lan { 570 type inet:ipv4-prefix; 571 description 572 "Lan prefixes."; 573 } 574 leaf lan-tag { 575 type string; 576 description 577 "Internal tag to be used in vpn 578 policies."; 579 } 580 leaf next-hop { 581 type inet:ipv4-address; 582 description 583 "Nexthop address to use at customer 584 side."; 585 } 586 description " 587 List of LAN prefixes for 588 the site. 589 "; 590 } 591 list ipv6-lan-prefixes { 592 key lan; 594 leaf lan { 595 type inet:ipv6-prefix; 596 description 597 "Lan prefixes."; 598 } 599 leaf lan-tag { 600 type string; 601 description 602 "Internal tag to be used 603 in vpn policies."; 604 } 605 leaf next-hop { 606 type inet:ipv6-address; 607 description 608 "Nexthop address to use at 609 customer side."; 610 } 611 description " 612 List of LAN prefixes for the site. 613 "; 614 } 615 description 616 "LAN prefixes from the customer."; 617 } 619 description 620 "Customer premise configuration."; 621 } 623 container security{ 624 description 625 "layer 2 vpn security parameters."; 627 uses l3vpn-svc:site-security-authentication; 628 uses l3vpn-svc:site-security-encryption; 629 uses l3vpn-svc:site-security-acl; 630 } 632 container attachment{ 633 description 634 "TBD"; 635 container bearer { 636 leaf type { 637 type identityref{ 638 base bearer; 639 } 640 description 641 "Type of bearer Ethernet ... 642 Operator specific."; 643 } 644 leaf bearer-reference { 645 type string; 646 description 647 "This is an internal reference for the 648 service provider."; 649 } 650 description 651 "Bearer specific parameters. 652 To be augmented."; 653 } 654 container l2-connection{ 655 leaf peer-id{ 656 type inet:ip-address; 657 description 658 "peer ip address.";} 659 container ipv4{ 660 leaf address-allocation-type { 661 type identityref { 662 base l3vpn-svc:address-allocation-type; 663 } 664 description 665 "Defines how addresses are allocated. 666 Need to be detailed further."; 667 } 669 leaf subnet-prefix { 670 type inet:ipv4-prefix; 671 description 672 "Interco subnet."; 673 } 674 description 675 "IPv4 specific parameters"; 676 } 677 container ipv6 { 678 leaf address-allocation-type { 679 type string; 680 description 681 "Defines how addresses are allocated. 682 Need to be detailled further."; 683 } 684 leaf subnet-prefix { 685 type inet:ipv6-prefix; 686 description 687 "Interco subnet."; 688 } 689 description 690 "IPv6 specific parameters"; 691 } 692 container oam { 693 container bfd { 694 leaf bfd-enabled { 695 type boolean; 696 description 697 "BFD activation"; 698 } 699 choice holdtime { 700 case profile { 701 leaf profile-name { 702 type string; 703 description 704 "Service provider well known profile."; 705 } 706 description 707 "Service provider well 708 known profile."; 709 } 710 case fixed { 711 leaf fixed-value { 712 type uint32; 713 units msec; 714 description 715 "Expected holdtime 716 expressed 717 in msec."; 718 } 719 } 720 description 721 "Choice for holdtime flavor.";} 722 description 723 "Container for BFD.";} 724 description 725 "Define the OAM used on the connection.";} 726 list routing-protocols { 727 key type; 728 leaf type { 729 type identityref { 730 base l3vpn-svc:routing-protocol-type; 731 } 732 description 733 "Type of routing protocol."; 734 } 736 container ospf { 737 when "type = 'ospf'" { 738 description 739 "Only applies 740 when protocol is OSPF."; 741 } 742 leaf-list address-family { 743 type identityref { 744 base rt:address-family; 745 } 746 description 747 "Address family to be activated."; 748 } 749 leaf area-address { 750 type yang:dotted-quad; 751 description 752 "Area address."; 753 } 754 leaf metric { 755 type uint16; 756 description 757 "Metric of PE-CE link."; 758 } 759 list sham-link { 760 key target-site; 762 leaf target-site { 763 type leafref { 764 path "../../../../../../" 765 +"../sites/site-id"; 766 } 767 description 768 "Target site for the sham link 769 connection."; 770 } 771 leaf metric { 772 type uint16; 773 description 774 "Metric of the sham link."; 775 } 776 description 777 "Creates a shamlink with another 778 site"; 779 } 780 description 781 "OSPF specific configuration."; 782 } 784 container bgp { 785 when "type = 'bgp'" { 786 description 787 "Only applies when 788 protocol is BGP."; 789 } 790 leaf-list address-family { 791 type identityref { 792 base rt:address-family; 793 } 794 description 795 "Address family to be activated."; 796 } 797 description 798 "BGP specific configuration."; 799 } 800 container static { 801 when "type = 'static'" { 802 description 803 "Only applies when protocol 804 is static."; 805 } 806 leaf-list address-family { 807 type identityref { 808 base rt:address-family; 809 } 810 description 811 "Address family to be activated."; 812 } 813 description 814 "Static routing 815 specific configuration."; 816 } 817 container rip { 818 when "type = 'rip'" { 819 description 820 "Only applies when 821 protocol is RIP."; 822 } 823 leaf-list address-family { 824 type identityref { 825 base rt:address-family; 826 } 827 description 828 "Address family to be 829 activated."; 830 } 832 description 833 "RIP routing specific 834 configuration."; 835 } 837 container vrrp { 838 when "type = 'vrrp'" { 839 description 840 "Only applies when 841 protocol is VRRP."; 842 } 843 leaf-list address-family { 844 type identityref { 845 base rt:address-family; 846 } 847 description 848 "Address family to be activated."; 849 } 850 description 851 "VRRP routing specific configuration."; 852 } 853 description 854 "List of routing protocols used 855 on the site. 856 Need to be augmented."; 857 } 858 description 859 "Defines connection parameters."; 861 } 862 } 863 } 865 container service{ 866 description 867 "Service parameters on the attachement."; 868 uses l3vpn-svc:site-service-basic; 869 container qos{ 870 description 871 "TBD."; 872 container qos-classification-policy { 873 description 874 "QoS configuration"; 875 list rules { 876 key id; 877 description 878 "list of qos rules."; 879 leaf id { 880 type uint16; 881 description 882 "ID of the rule."; 883 } 884 container match-flow{ 885 description 886 "container of match flow."; 887 leaf dest-mac-address{ 888 type yang:mac-address; 889 description 890 "destination mac address."; 891 } 893 leaf src-mac-address{ 894 type yang:mac-address; 895 description 896 "source mac address."; 897 } 899 leaf local-label{ 900 type string; 901 description 902 "local label."; 903 } 905 leaf remote-label{ 906 type string; 907 description 908 "remote label."; 910 } 912 leaf dot1q-vlan-bitmap { 913 type string; 914 mandatory true; 915 description "Dot1Q Vlan Bitmap." ; 916 } 918 leaf qinq-svlan-bitmap { 919 type string; 920 mandatory true; 921 description "QinQ svlan Bitmap." ; 922 } 924 leaf qinq-cvlan-bitmap { 925 type string; 926 mandatory true; 927 description "QinQ cvlan Bitmap." ; 928 } 929 leaf target-class-id { 930 type string; 931 description 932 "Identification of the 933 class of service. 934 This identifier is internal to 935 the administration."; } 936 } 937 leaf std-qos-profile { 938 type string; 939 description 940 "QoS profile to be used"; 941 } 942 container custom-qos-profile { 943 list class { 944 key class-id; 946 leaf class-id { 947 type string; 948 description 949 "Identification of the 950 class of service. 951 This identifier is internal to 952 the administration."; 953 } 954 leaf rate-limit { 955 type uint8; 956 units percent; 957 description 958 "To be used if class must 959 be rate 960 limited. Expressed as 961 percentage of the svc-bw."; 962 } 963 leaf priority-level { 964 type uint8; 965 description 966 "Defines the level of the 967 class in 968 term of priority queueing. 969 The higher the level is the 970 higher 971 is the priority."; 972 } 973 leaf guaranteed-bw-percent { 974 type uint8; 975 units percent; 976 description 977 "To be used to define the 978 guaranteed 979 BW in percent of the svc-bw 980 available at the priority-level."; 981 } 982 description 983 "List of class of services."; 984 } 985 description 986 "Custom qos profile."; 987 } 988 } 989 } 990 } 991 uses l3vpn-svc:site-service-protection; 992 uses l3vpn-svc:site-service-mpls; 993 uses l3vpn-svc:site-service-multicast; 994 } 995 } 997 } 998 1000 6. Security Considerations 1002 TBC. 1004 7. IANA Considerations 1006 TBC. 1008 8. Conclusion 1010 This document intends to trigger a discussion at IETF 94 meeting in 1011 Yokohama on other VPN service modeling. It uses L2VPN service model 1012 as an example to explore how L3VPN service model can be used as basis 1013 to define other type of VPN service models such as Cloud VPN service 1014 model, OTT VPN service model, Hybrid VPN service model. Right now 1015 L3VPN service model defined in L3SM WG follows modularity approach 1016 and has been defined in more extensible way, therefore other VPN 1017 service model can reuse building blocks defined in L3SM service model 1018 without need of reinventing a new wheel. However L3VPN service model 1019 can not be directly extended to other VPN service model since it 1020 include L3VPN specific aspect, e.g., IP connection, QoS filter and 1021 Routing filter that are applied to IP network. Therefore we can not 1022 use L3VPN service model structure as a common structure for other VPN 1023 service models. 1025 9. Acknowledgements 1027 The authors would like to thank Zitao Wang for the very fruitful 1028 discussions and useful suggestions in the initial version. 1030 10. Normative References 1032 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1033 Requirement Levels", March 1997. 1035 [RFC3809] Nagarajan, A., Ed., "Generic Requirements for Provider 1036 Provisioned Virtual Private Networks (PPVPN)", RFC 3809, 1037 DOI 10.17487/RFC3809, June 2004, 1038 . 1040 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 1041 2 Virtual Private Networks (L2VPNs)", RFC 4664, 1042 DOI 10.17487/RFC4664, September 2006, 1043 . 1045 Authors' Addresses 1046 Chongfeng Xie 1047 China Telecom 1048 No.118 Xizhimennei street, Xicheng District 1049 Beijing 100035 1050 China 1052 Email: xiechf@ctbri.com.cn 1054 Aijun Wang 1055 China Telecom 1056 No.118 Xizhimennei street, Xicheng District 1057 Beijing 100035 1058 China 1060 Email: wangaj@ctbri.com.cn 1062 Roland Schott 1063 Deutsche Telekom 1064 Deutsche-Telekom-Allee 7 1065 Darmstadt 64295 1066 Germany 1068 Email: Roland.Schott@telekom.de 1070 Dacheng Zhang 1072 Email: dacheng.zhang@gmail.com