idnits 2.17.1 draft-www-bess-yang-vpn-service-pm-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 : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 22 characters in excess of 72. ** The abstract seems to contain references ([RFC8345]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2013 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: 'RFC8299' is mentioned on line 89, but not defined == Missing Reference: 'RFC8194' is mentioned on line 215, but not defined == Missing Reference: 'I-D.ietf-netconf-yang-push' is mentioned on line 230, but not defined == Missing Reference: 'RFC8040' is mentioned on line 731, but not defined == Missing Reference: 'RFC5246' is mentioned on line 735, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Unused Reference: 'RFC6370' is defined on line 805, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'RFC7952' is defined on line 824, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group M. Wang 3 Internet-Draft Q. Wu 4 Intended status: Standards Track R. Even 5 Expires: April 25, 2019 Huawei 6 B. Wen 7 Comcast 8 October 22, 2018 10 A YANG Model for VPN Service Performance Monitoring 11 draft-www-bess-yang-vpn-service-pm-01 13 Abstract 15 As specified in [RFC8345], the data model defined in [RFC8345] 16 introduces vertical layering relationships between networks that can 17 be augmented to cover network/service topologies. This document 18 defines a YANG Model for VPN Service Performance Monitoring that can 19 be used to monitor and manage network Performance between VPN sites 20 and it is an augmentation to the I2RS network topology YANG data 21 model. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 25, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 3. VPN Service Topology Overview . . . . . . . . . . . . . . . . 4 60 4. VPN service assurance model . . . . . . . . . . . . . . . . . 5 61 5. Model Usage Guideline . . . . . . . . . . . . . . . . . . . . 5 62 5.1. Performance Monitoring Data Source . . . . . . . . . . . 5 63 5.2. Retrieval via I2RS Pub/Sub . . . . . . . . . . . . . . . 5 64 5.3. On demand Retrieval via RPC model . . . . . . . . . . . . 6 65 6. Design of the Data Model . . . . . . . . . . . . . . . . . . 6 66 6.1. Network Level . . . . . . . . . . . . . . . . . . . . . . 6 67 6.2. Node Level . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.3. Link and Termination Point Level . . . . . . . . . . . . 7 69 7. Example of I2RS Pub/Sub Retrieval . . . . . . . . . . . . . . 8 70 8. Example of RPC model based Retrieval . . . . . . . . . . . . 9 71 9. VPN Service Assurance YANG Module . . . . . . . . . . . . . . 9 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 74 12. Normative References . . . . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 77 1. Introduction 79 [RFC8345] defines an abstract YANG data model for network/service 80 topologies and inventories. Service topology in [RFC8345] includes 81 the a virtual topology for a service layer above the L1, L2, and L3 82 layers. This virtual topology has the generic topology elements of 83 node,link, and terminating point. One typical example of a service 84 topology is described in figure 3 of [RFC8345],two VPN service 85 topologies instantiated over a common L3 topology. Each VPN service 86 topology is mapped onto a subset of nodes from the common L3 87 topology. 89 In [RFC8299], the 3 types of VPN service topologies proposed for 90 L3VPN service data model are any to any, hub and spoke, hub and spoke 91 disjoint. These VPN topology types can be used to describe how VPN 92 sites are communicating with each other. 94 This document defines a YANG Model for VPN Service Performance 95 Monitoring that can be used to monitor and manage network Performance 96 between VPN sites and it is an augmentation to the I2RS network 97 topology YANG data model. 99 2. Conventions used in this document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. In this 104 document, these words will appear with that interpretation only when 105 in ALL CAPS. Lower case uses of these words are not to be 106 interpreted as carrying [RFC2119] significance. 108 The following notations are used within the data tree and carry the 109 meaning as below. 111 Each node is printed as: 113 115 is one of: 116 + for current 118 is one of: 120 rw for configuration data 121 ro for non-configuration data 122 -x for rpcs 123 -n for notifications 124 -w for writable 126 is the name of the node 128 If the node is augmented into the tree from another module, its name 129 is printed as :. 131 is one of: 133 ? for an optional leaf or choice 134 ! for a presence container 135 * for a leaf-list or list 136 [] for a list's keys 137 (choice)/:(case) Parentheses enclose choice and case nodes, 138 and case nodes are also marked with a colon (":") 139 is the name of the type for leafs and leaf-lists 141 3. VPN Service Topology Overview 143 As specified in [RFC8345], the data model defined in [RFC8345] can 144 describe vertical layering relationships between networks that can be 145 augmented to cover network/service topologies. The following figure 146 describes relationships between L3VPN Service Topo and Underlying 147 network: 149 VPN-1 VPN-2 150 / \ 151 L3VPN-Service-topology 1 L3VPN-Service-topology-2 152 / | \ / | \ 153 Site-1A site-1B site1-C site-2A Site-2B Site-2C Top-Down 154 | | | | | | Service Topo 155 CE CE CE CE CE CE 156 | | | | | | 157 PE PE PE PE PE PE 158 ====|==========|=======|=======|=========|=====|=================== 159 +-------+ | \ / / | 160 Bottoms-up | | \ / / | 161 Network | | /\ / | 162 topology | | / \ | | 163 | | | | | | 164 node1 node2 node3 node4 node5 node6 166 layering relationships between L3VPN Service Topo and Underlying 167 network 169 As shown in figure 1, the Site-1,A,B,C are mapped to node 1,2,3 while 170 Site-2 A,B,C are mapped to node 4,5,6 in the underlying physical 171 network. In this figure, an L3SM has two VPN services topologies 172 with both built on top of one common underlying physical network. 174 VPN-svc 1: supporting hub-spoke communication for Customer 1 175 connecting the customers access at 3 sites 177 VPN-svc 2: supporting hub-spoke disjoint communication for 178 Customer 2 connecting the customers access at 3 sites 180 L3VPN service topology 1 is hub and spoke topology while L3VPN 181 service topology 2 is hub and spoke disjoint topology. In L3VPN 182 service topology1, Site-1 A plays the role of hub while Site-2 B and 183 C plays the role of spoke. In L3VPN service topoogy2, Site-2 A and B 184 play the role of hub while Site-2 C plays the role of spoke. 186 4. VPN service assurance model 188 This module describes VPN Service assurance that can be used to 189 monitor and manage network Performance between VPN sites and it is a 190 augmentation to the I2RS network topology YANG data model. The 191 performance monitoring data is augmented to service topology. 193 +------------+ +---------------------+ 194 |I2RS Network| | VPN Service | 195 |Topo Model |<---------|Peformance Monitoring| 196 +------------+ augments | Model | 197 +---------------------+ 199 5. Model Usage Guideline 201 An SP must be able to manage the capabilities and characteristics of 202 their VPN services when VPN sites are setup to communicate with each 203 other. VPN service topology such as hub and spoke describes how 204 these VPN sites are communicating with each other. 206 5.1. Performance Monitoring Data Source 208 As described in section 2, once the mapping between VPN Service 209 topology and underlying physical network has been setup, the 210 performance monitoring data per link in the underlying network can be 211 collected using network performance measurement method such as MPLS 212 Loss and Delay Measurement [RFC6374]. The performance monitoring 213 information reflecting the quality of the VPN service such as end to 214 end network performance data between VPN sites can be aggregated or 215 calculated using PCEP solution [RFC5440] or LMAP solution [RFC8194]. 216 The information can be fed into data source such as the management 217 system or network devices. The measurement interval and report 218 interval associated with these performance data usually depends on 219 configuration parameters. 221 5.2. Retrieval via I2RS Pub/Sub 223 Some applications such as service-assurance applications, which must 224 maintain a continuous view of operational data and state, can use 225 subscription model [I-D.ietf-netconf-yang-push] to subscribe to the 226 VPN service performance data they are interested in, at the data 227 source. 229 The data source can then use VPN service assurance model and push 230 model [I-D.ietf-netconf-yang-push] to publish specific telemetry data 231 to target recipients. 233 5.3. On demand Retrieval via RPC model 235 To obtain a snapshot of a large amount of performance data from the 236 network element, service-assurance applications can also use polling 237 based solution such as RPC model to fetch performance data on demand. 239 6. Design of the Data Model 241 This document defines the YANG module "ietf-vpn-svc-pm", which has 242 the following structure 244 6.1. Network Level 246 module: ietf-vpn-svc-pm 247 augment /nw:networks/nw:network/nw:network-types: 248 +--rw svc-topo-type? identityref 249 augment /nw:networks/nw:network: 250 +--rw svc-topo-attributes 251 +--rw vpn-topo? identityref 253 Network Level View of the hierarchies 255 The VPN service performance monitoring model defines only the 256 following minimal set of Network level service topology attributes: 258 o svc-topo-type: Indicate the network type is service topology type 259 such as L3VPN service topology, L2VPN service topology. 261 o vpn-topo: The type of VPN service topology, Ourproposed model 262 supports any-to-any, Hub and Spoke (where Hubs can exchange 263 traffic), and "Hub and Spoke disjoint" (where Hubs cannot exchange 264 traffic). 266 6.2. Node Level 268 augment /nw:networks/nw:network/nw:node: 269 +--rw node-attributes 270 +--rw node-type? identityref 271 +--rw site-id? string 272 +--rw site-role? Identityref 274 Node Level View of the hierarchies 276 The VPN service performance monitoring model defines only the 277 following minimal set of Node level service topology attributes and 278 constraints: 280 o Node-type (Attribute): Indicate the type of the node, such as PE 281 or ASBR. 283 o Site-id (Constraint): Uniquely identifies the site within the 284 overall network infrastructure. 286 o Site-role (Constraint):Defines the role of the site in a 287 particular VPN topology. 289 6.3. Link and Termination Point Level 291 augment /nw:networks/nw:network/nt:link: 292 +--ro svc-telemetry-attributes 293 +--ro loss-statistics 294 | +--ro direction identityref 295 | +--ro packet-loss-count? uint32 296 | +--ro loss-ratio? percentage 297 | +--ro packet-reorder-count? uint32 298 | +--ro packets-out-of-seq-count? uint32 299 | +--ro packets-dup-count? uint32 300 +--ro delay-statistics 301 | +--ro direction? identityref 302 | +--ro min-delay-value? uint32 303 | +--ro max-delay-value? uint32 304 | +--ro average-delay-value? uint32 305 +--ro jitter-statistics 306 +--ro direction? identityref 307 +--ro min-jitter-value? uint32 308 +--ro max-jitter-value? uint32 309 +--ro average-jitter-value? uint32 311 Link and Termination point Level View of the hierarchies 313 The VPN service performance monitoring model defines only the 314 following minimal set of Link level service topology attributes: 316 Loss Statistics: A set of loss statistics attributes that are used 317 to measure end to end loss between VPN sites. 319 Delay Statistics: A set of delay statistics attributes that are 320 used to measure end to end latency between VPN sites. 322 Jitter Statistics: A set of jitter statistics attributes that are 323 used to measure end to end jitter between VPN sites. 325 7. Example of I2RS Pub/Sub Retrieval 327 This example shows the way for a client to subscribe for the 328 Performance monitoring information for VPN service between VPN sites. 329 The performance monitoring parameter that the client is interested in 330 is end to end loss attribute. 332 334 336 337 338 339 vpn1 340 341 A 342 pe 343 344 345 B 346 pe 347 348 349 A-B 350 351 A 352 353 354 B 355 356 358 359 360 361 362 363 364 365 366 500 367 368 370 8. Example of RPC model based Retrieval 372 This example shows the way for the client to use RPC model to fetch 373 performance data on demand,e.g., the client requests packet-loss- 374 count between PE1 in site 1 and PE2 in site 2 belonging to VPN1. 376 378 379 380 381 vpn1 382 383 A 384 pe 385 386 387 B 388 pe 389 390 A-B 391 392 A 393 394 395 B 396 397 398 399 400 401 402 403 404 406 9. VPN Service Assurance YANG Module 408 file "ietf-vpn-svc-pm.yang" 409 module ietf-vpn-svc-pm { 410 yang-version 1.1; 411 namespace "urn:ietf:params:xml:ns:yang:ietf-vpn-svc-pm"; 412 prefix svc-topo; 413 import ietf-network { 414 prefix nw; 415 } 416 import ietf-network-topology { 417 prefix nt; 419 } 420 import ietf-l3vpn-svc { 421 prefix l3vpn-svc; 422 } 423 organization 424 "IETF xxx Working Group"; 425 contact 426 "Zitao Wang: wangzitao@huawei.com 427 Qin Wu: bill.wu@huawei.com"; 428 description 429 "This module defines a model for the service topology."; 431 revision 2018-08-29 { 432 description 433 "Initial revision."; 434 reference "foo"; 435 } 437 identity service-type { 438 description 439 "Base type for service topology"; 440 } 442 identity l3vpn-svc { 443 base service-type; 444 description 445 "Indentity for layer3 vpn service"; 446 } 448 identity l2vpn-svc { 449 base service-type; 450 description 451 "Identity for layer2 vpn service"; 452 } 454 identity node-type { 455 description 456 "Base identity for node type"; 457 } 459 identity pe { 460 base node-type; 461 description 462 "Identity for PE type"; 463 } 465 identity ce { 466 base node-type; 467 description 468 "Identity for CE type"; 469 } 471 identity asbr { 472 base node-type; 473 description 474 "Identity for ASBR type"; 475 } 477 identity p { 478 base node-type; 479 description 480 "Identity for P type"; 481 } 483 identity direction { 484 description 485 "Base Identity for measurement direction including 486 one way measurement and two way measurement."; 487 } 489 identity oneway { 490 base direction; 491 description 492 "Identity for one way measurement."; 493 } 495 identity twoway { 496 base direction; 497 description 498 "Identity for two way measurement."; 499 } 501 typedef percentage { 502 type decimal64 { 503 fraction-digits 5; 504 range "0..100"; 505 } 506 description 507 "Percentage."; 508 } 510 grouping link-error-statistics { 511 description 512 "Grouping for per link error statistics"; 513 container loss-statistics { 514 description 515 "Per link loss statistics."; 516 leaf direction { 517 type identityref { 518 base direction; 519 } 520 default "oneway"; 521 description 522 "Define measurement direction including one way 523 measurement and two way measurement."; 524 } 525 leaf packet-loss-count { 526 type uint32 { 527 range "0..4294967295"; 528 } 529 default "0"; 530 description 531 "Total received packet drops count. 532 The value of count will be set to zero (0) 533 on creation and will thereafter increase 534 monotonically until it reaches a maximum value 535 of 2^32-1 (4294967295 decimal), when it wraps 536 around and starts increasing again from zero."; 537 } 538 leaf loss-ratio { 539 type percentage; 540 description 541 "Loss ratio of the packets. Express as percentage 542 of packets lost with respect to packets sent."; 543 } 544 leaf packet-reorder-count { 545 type uint32 { 546 range "0..4294967295"; 547 } 548 default "0"; 549 description 550 "Total received packet reordered count. 551 The value of count will be set to zero (0) 552 on creation and will thereafter increase 553 monotonically until it reaches a maximum value 554 of 2^32-1 (4294967295 decimal), when it wraps 555 around and starts increasing again from zero."; 556 } 557 leaf packets-out-of-seq-count { 558 type uint32 { 559 range "0..4294967295"; 560 } 561 description 562 "Total received out of sequence count. 564 The value of count will be set to zero (0) 565 on creation and will thereafter increase 566 monotonically until it reaches a maximum value 567 of 2^32-1 (4294967295 decimal), when it wraps 568 around and starts increasing again from zero.."; 569 } 570 leaf packets-dup-count { 571 type uint32 { 572 range "0..4294967295"; 573 } 574 description 575 "Total received packet duplicates count. 576 The value of count will be set to zero (0) 577 on creation and will thereafter increase 578 monotonically until it reaches a maximum value 579 of 2^32-1 (4294967295 decimal), when it wraps 580 around and starts increasing again from zero."; 581 } 582 } 583 } 585 grouping link-delay-statistics { 586 description 587 "Grouping for per link delay statistics"; 588 container delay-statistics { 589 description 590 "Link delay summarised information. By default, 591 one way measurement protocol (e.g., OWAMP) is used 592 to measure delay."; 593 leaf direction { 594 type identityref { 595 base direction; 596 } 597 default "oneway"; 598 description 599 "Define measurement direction including one way 600 measurement and two way measurement."; 601 } 602 leaf min-delay-value { 603 type uint32; 604 description 605 "Minimum delay value observed."; 606 } 607 leaf max-delay-value { 608 type uint32; 609 description 610 "Maximum delay value observed."; 611 } 612 leaf average-delay-value { 613 type uint32; 614 description 615 "Average delay value observed."; 616 } 617 } 618 } 620 grouping link-jitter-statistics { 621 description 622 "Grouping for per link jitter statistics"; 623 container jitter-statistics { 624 description 625 "Link jitter summarised information. By default, 626 jitter is measured using IP Packet Delay Variation 627 (IPDV) as defined in RFC3393."; 628 leaf direction { 629 type identityref { 630 base direction; 631 } 632 default "oneway"; 633 description 634 "Define measurement direction including one way 635 measurement and two way measurement."; 636 } 637 leaf min-jitter-value { 638 type uint32; 639 description 640 "Minimum jitter value observed."; 641 } 642 leaf max-jitter-value { 643 type uint32; 644 description 645 "Maximum jitter value observed."; 646 } 647 leaf average-jitter-value { 648 type uint32; 649 description 650 "Average jitter value observed."; 651 } 652 } 653 } 655 augment "/nw:networks/nw:network/nw:network-types" { 656 description 657 "Augment the network-types with service topologyies types"; 658 leaf svc-topo-type { 659 type identityref { 660 base service-type; 661 } 662 description 663 "Identify the topology type to be composited service topology"; 664 } 665 } 666 augment "/nw:networks/nw:network" { 667 description 668 "Augment the network with service topology attributes"; 669 container svc-topo-attributes { 670 leaf vpn-topology { 671 type identityref { 672 base l3vpn-svc:vpn-topology; 673 } 674 description 675 "VPN service topology, e.g. hub-spoke, any-to-any, hub-spoke-disjoint, etc"; 676 } 677 description 678 "Container for vpn services"; 679 } 680 } 681 augment "/nw:networks/nw:network/nw:node" { 682 description 683 "Augment the network node with serice attributes"; 684 container node-attributes { 685 leaf node-type { 686 type identityref { 687 base node-type; 688 } 689 description 690 "Node type, e.g. PE, P, ASBR, etc"; 691 } 692 leaf site-id { 693 type string; 694 description 695 "Asscoiated vpn site"; 696 } 697 leaf site-role { 698 type identityref { 699 base l3vpn-svc:site-role; 700 } 701 default "l3vpn-svc:any-to-any-role"; 702 description 703 "Role of the site in the IP VPN."; 704 } 705 description 706 "Container for service topology attributes"; 707 } 709 } 710 augment "/nw:networks/nw:network/nt:link" { 711 description 712 "Augment the network topology link with vpn service attributes"; 713 container svc-telemetry-attributes { 714 config false; 715 uses link-error-statistics; 716 uses link-delay-statistics; 717 uses link-jitter-statistics; 718 description 719 "Container for service telemetry attributes"; 720 } 721 } 722 } 723 725 10. Security Considerations 727 The YANG modules defined in this document MAY be accessed via the 728 RESTCONF protocol [RFC8040] or NETCONF protocol ([RFC6241]). The 729 lowest RESTCONF or NETCONF layer requires that the transport-layer 730 protocol provides both data integrity and confidentiality, see 731 Section 2 in [RFC8040] and [RFC6241]. The lowest NETCONF layer is 732 the secure transport layer, and the mandatory-to-implement secure 733 transport is Secure Shell (SSH)[RFC6242] . The lowest RESTCONF layer 734 is HTTPS, and the mandatory-to-implement secure transport is TLS 735 [RFC5246]. 737 The NETCONF access control model [RFC6536] provides the means to 738 restrict access for particular NETCONF or RESTCONF users to a 739 preconfigured subset of all available NETCONF or RESTCONF protocol 740 operations and content. 742 There are a number of data nodes defined in this YANG module that are 743 writable/creatable/deletable (i.e., config true, which is the 744 default). These data nodes may be considered sensitive or vulnerable 745 in some network environments. Write operations (e.g., edit-config) 746 to these data nodes without proper protection can have a negative 747 effect on network operations. These are the subtrees and data nodes 748 and their sensitivity/vulnerability: 750 o /ni:network-instances/ni:network-instance/svc-topo:svc-telemetry- 751 attributes 753 11. IANA Considerations 755 This document registers a URI in the IETF XML registry [RFC3688]. 756 Following the format in [RFC3688], the following registration is 757 requested to be made: 759 --------------------------------------------------------------------- 760 URI: urn:ietf:params:xml:ns:yang:ietf-vpn-svc-pm 762 Registrant Contact: The IESG. 764 XML: N/A, the requested URI is an XML namespace. 765 --------------------------------------------------------------------- 767 This document registers a YANG module in the YANG Module Names 768 registry [RFC6020]. 770 --------------------------------------------------------------------- 771 Name: ietf-vpn-svc-pm 772 Namespace: urn:ietf:params:xml:ns:yang:ietf-vpn-svc-pm 773 Prefix: vnrsc 774 Reference: RFC xxxx 775 --------------------------------------------------------------------- 777 12. Normative References 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", March 1997. 782 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 783 DOI 10.17487/RFC3688, January 2004, 784 . 786 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 787 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 788 DOI 10.17487/RFC5440, March 2009, 789 . 791 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 792 the Network Configuration Protocol (NETCONF)", RFC 6020, 793 DOI 10.17487/RFC6020, October 2010, 794 . 796 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 797 and A. Bierman, Ed., "Network Configuration Protocol 798 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 799 . 801 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 802 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 803 . 805 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 806 Profile (MPLS-TP) Identifiers", RFC 6370, 807 DOI 10.17487/RFC6370, September 2011, 808 . 810 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 811 Measurement for MPLS Networks", RFC 6374, 812 DOI 10.17487/RFC6374, September 2011, 813 . 815 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 816 Protocol (NETCONF) Access Control Model", RFC 6536, 817 DOI 10.17487/RFC6536, March 2012, 818 . 820 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 821 RFC 7950, DOI 10.17487/RFC7950, August 2016, 822 . 824 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 825 RFC 7952, DOI 10.17487/RFC7952, August 2016, 826 . 828 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 829 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 830 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 831 2018, . 833 Authors' Addresses 835 Michael Wang 836 Huawei Technologies,Co.,Ltd 837 101 Software Avenue, Yuhua District 838 Nanjing 210012 839 China 841 Email: wangzitao@huawei.com 842 Qin Wu 843 Huawei 844 101 Software Avenue, Yuhua District 845 Nanjing, Jiangsu 210012 846 China 848 Email: bill.wu@huawei.com 850 Roni Even 851 Huawei Technologies,Co.,Ltd 852 Tel Aviv 853 Israel 855 Email: roni.even@huawei.com 857 Bin Wen 858 Comcast 860 Email: bin_wen@comcast.com