idnits 2.17.1 draft-bryskin-teas-service-tunnel-steering-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 325 has weird spacing: '...n-point str...' -- The document date (November 5, 2018) is 1999 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3688' is mentioned on line 742, but not defined == Unused Reference: 'I-D.ietf-teas-yang-te-topo' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'RFC8342' is defined on line 809, but no explicit reference was found in the text == Unused Reference: 'RFC8345' is defined on line 814, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-18 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-17 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Bryskin 3 Internet-Draft Huawei Technologies 4 Intended status: Informational V. Beeram 5 Expires: May 9, 2019 Juniper Networks 6 T. Saad 7 Cisco Systems Inc 8 X. Liu 9 Volta Networks 10 Y. Lee 11 Huawei Technologies 12 November 5, 2018 14 Basic YANG Model for Steering Client Services To Server Tunnels 15 draft-bryskin-teas-service-tunnel-steering-model-01 17 Abstract 19 This document describes a YANG data model for managing pools of 20 transport tunnels and steering client services on them. 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 https://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 9, 2019. 39 Copyright Notice 41 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 60 2. Explicit vs. Implicit Service2tunnel Mapping. Steering 61 Services to Transport Tunnel Pools . . . . . . . . . . . . . 4 62 3. The purpose of the model . . . . . . . . . . . . . . . . . . 5 63 4. Model Design . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 70 9.2. Informative References . . . . . . . . . . . . . . . . . 17 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 73 1. Introduction 75 Client layer services/signals are normally mapped onto carrying them 76 across the network transport tunnels via client/server layer 77 adaptation relationships. Such relationships are usually modeled as 78 multi-layer topologies, whereas tunnels set up in underlay (server) 79 topologies support links in respective overlay (client) topologies. 80 In this respect having a link in a client topology means that the 81 client layer traffic could be forwarded between link termination 82 points (LTPs) terminating the link on opposite sides by the 83 supporting tunnel(s) configured in the server layer topology. 85 This said there are numerous use cases in which describing the client 86 service to server tunnel bindings via the topology formalism is 87 impractical. Below are some examples of such use cases: 89 o Mapping client services onto tunnels within the same network 90 layer, for example, mapping L3 VPNs or MPLS-SR services onto IP 91 MPLS tunnels; 93 o Mapping client services onto tunnels provisioned in the highest 94 layer topology supported by the network. For example, mapping 95 L2VPNs or E(V)PL services onto IP MPLS tunnels provisioned in IP 96 network; 98 o Mapping client services to tunnels configured in separate network 99 layers at the network's access points. Consider, for example, an 100 OTN/ODUk network that is used to carry client signals of, say, 20 101 different types (e.g. Ethernet, SDH, FKON, etc.) entering and 102 exiting the network over client facing interfaces. Although it is 103 possible to describe such a network as a 21-layer TE topology with 104 the OTN/ODUk topology serving each of the 20 client layer 105 topologies, such a description would be verbose, cumbersome, 106 difficult to expand to accommodate additional client signals and 107 unnecessary, because the client layer topologies would have zero 108 switching flexibility inside the network (i.e. contain only 109 unrelated links connecting access points across respective layer 110 networks), and all what is required to know from the point of view 111 of a management application is what ODUk tunnels are established 112 or required, which client signals the tunnels could carry and at 113 which network border nodes and how the client signals could be 114 bound (adopted) to the tunnels. 116 It is worth noting that such non-topological client-service-to- 117 server-tunnel mapping almost always happens on network border nodes. 118 However, there are also important use cases where such a mapping is 119 required in the middle of the network. One such use case is 120 controlling on IP/MPLS FRR PLRs which LSPs are mapped onto which 121 backup tunnels. 123 Service2tunnel mappings could be very complex: large number of 124 instances of services of the same or different types (possibly 125 governed by different models) could be mapped on the same set of 126 tunnels, which could be set in different network layers and could be 127 either TE or non-TE, P2P or P2MP or MP2MP. Furthermore, the mappings 128 could be hierarchical: tunnels carrying services could be clients of 129 other tunnels. 131 Despite of the differences of transport tunnels and of services they 132 carry the srvice2tunnel mappings could be described in a simple 133 uniform way. Access to a data store of such mappings could be 134 beneficial to network management applications. It would be possible, 135 for example, to discover which services depend on which tunnels, 136 which services will be affected if a given tunnel goes out of 137 service, how many more services could be placed onto a given TE 138 tunnel without the latter violating its TE commitments (e.g. 139 bandwidth, delay). It would be also possible to demand in a single 140 request moving numerous (ranges of) service instances from one set of 141 tunnels to another. 143 This document defines a YANG data model for such mappings. 145 1.1. Terminology 147 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14, [RFC2119]. 152 The following terms are defined in [RFC7950] and are not redefined 153 here: 155 o augment 157 o data model 159 o data node 161 1.2. Tree Diagrams 163 A simplified graphical representation of the data model is presented 164 in this document, by using the tree format defined in [RFC8340]. 166 1.3. Prefixes in Data Node Names 168 In this document, names of data nodes, actions, and other data model 169 objects are often used without a prefix, as long as it is clear from 170 the context in which YANG module each name is defined. Otherwise, 171 names are prefixed using the standard prefix associated with the 172 corresponding YANG module, as shown in Table 1. 174 +----------+-----------------+-------------------------+ 175 | Prefix | YANG module | Reference | 176 +----------+-----------------+-------------------------+ 177 | inet | ietf-inet-types | [RFC6991] | 178 | te-types | ietf-te-types | [I-D.ietf-teas-yang-te] | 179 +----------+-----------------+-------------------------+ 181 Table 1: Prefixes and Corresponding YANG Modules 183 2. Explicit vs. Implicit Service2tunnel Mapping. Steering Services to 184 Transport Tunnel Pools 186 There are use cases in which client services require hard separation 187 of the transport carrying them from the transport carrying other 188 services. However, the environment in which the services may share 189 the same transport tunnels is far more common. For this reason the 190 model defined in this document suggests replacing (or at least 191 augmenting) the explicit service2tunnel mapping configuration (in 192 which the tunnels are referred to by their IDs/names) with implicit 193 mapping. Specifically, the model introduces the notion of tunnel 194 pool. A tunnel pool could be referred to by its network unique color 195 and requires service2tunnel mapping configuration to specify tunnel 196 pool color(s) instead of tunnel IDs/names. The model governs tunnel 197 pool data store independently from the services steered on them. It 198 is presumed (although not required) that the tunnels - components of 199 a tunnel pool - are of the same type, provisioned using a common 200 template and could be dynamically added to/removed from the pool 201 without necessitating service2tunnel mapping re-configuration. Such 202 a service to tunnel pool steering approach has the following 203 advantages: 205 o Scalability and efficiency: pool component bandwidth utilization 206 could be monitored, tunnels could be added to/removed from the 207 pool if/when it is detected that current component bandwidth 208 utilization has crossed certain thresholds. This allows for a 209 very efficient network resource utilization and obviates the 210 network management application from a very difficult task of 211 service to tunnel mapping planning; 213 o Automation and elasticity: pool component attributes could be 214 modified - bandwidth auto-adjusted, protection added, delay 215 constrained, etc.. The tunnels could be completely or partially 216 replaced with tunnels of different types (e.g. TE vs. non-TE, P2P 217 vs. P2MP, etc.) or even provisioned in different network layers 218 (OTN/ODUk tunnels replacing IP TE tunnels). All such 219 modifications do not require service2tunell mapping re- 220 configurations as long as the modified or new tunnels remain 221 within the same tunnel pool(s); 223 o Transparency: new service sites supported by additional PEs could 224 be added without service2tunnel mapping re-configuration. 226 3. The purpose of the model 228 To facilitate for network management applications, such as service 229 orchestrators, managing pools of transport tunnels and steering on 230 them client services independently of network technology/layer 231 specifics of the services and the tunnels. The model could be 232 applied to/implemented on physical devices, such as IP routers, as 233 well as on abstract topology nodes. Furthermore, the model could be 234 supported by a network (domain) controller, such as ACTN PNC, to act 235 as a proxy server on behalf of any network element/node (physical or 236 abstract) under its control. 238 4. Model Design 240 The data store described/governed by the model is comprised of a 241 single top level list - TunnelPools. A TunnelPool, list element, is 242 a container describing a set of transport tunnels (presumably with 243 similar characteristics) identified by a network unique ID (color). 245 The TunnelPool container has the following fields: 247 o Color [uint32 list key]; 249 o Tunnels list; 251 o Services list. 253 The Tunnels list describes the pool constituents - active transport 254 tunnels. The list members - Tunnel containers - include the 255 following infoemation: 257 o tunnel type [e.g. P2P-TE, P2MP-TE, SR-TE, SR P2P, LDP P2P, LDP 258 MP2MP, GRE, PBB, etc] 260 o tunnel type specific tunnel ID [provided that a data store of the 261 tunnel type, e.g. TE tunnels, is supported, the tunnelID allows 262 for the management application to look up the tunnel in question 263 to obtain detailed information about the tunnel]; 265 o topology ID [ identifies the topology over which the tunnel's 266 connection paths are defined]; 268 o tunnel source topology node ID; 270 o tunnel destination topology node ID; 272 o tunnel layer ID; 274 o maximal and available/resolvable bandwidth; 276 o e2e cost; 278 o e2e one way and round trip delay metrics; 280 o tunnel protection/restoration capabilities; 282 o tunnel encapsulation [e.g. MPLS label stack, Ethernet STAGs, GRE 283 header, PBB header, etc]. 285 The Services list describes services currently steered on the tunnel 286 pool. The list members - Service containers - have the following 287 attributes: 289 o service type [e.g. fixed/transparent, L3VPN, L2VPN, EVPN, ELINE, 290 EPL, EVPL, L1VPN, ACTN VN, etc.]; 292 o service type specific service ID [provided that a data store of 293 the service type, e.g. L2VPN, is supported, the service ID allows 294 for the management application to look up the service in question 295 to obtain detailed information about the service]; 297 o client ports (source/destination node LTPs over which the service 298 enters/exits the node/network, relevant only for fixed/transparent 299 services); 301 o service layer ID; 303 o minimal bandwidth expectations; 305 o maximal delay expectations; 307 o minimal protection requirements; 309 o service encapsulation [e.g. MPLS label stack, Ethernet CTAGs, 310 etc.] - for service multiplexing/de-multiplexing on/from a 311 statistically shared tunnel]. 313 5. Tree Structure 315 module: ietf-tunnel-steering 316 +--rw tunnel-pools 317 +--rw tunnel-pool* [color] 318 +--rw color uint32 319 +--rw description? string 320 +--rw service* [service-type id] 321 | +--rw service-type identityref 322 | +--rw id string 323 | +--ro access-point* [node-address link-termination-point] 324 | | +--ro node-address inet:ip-address 325 | | +--ro link-termination-point string 326 | | +--ro direction? enumeration 327 | +--ro switching-type? identityref 328 | +--ro protection-type? identityref 329 | +--ro encapsulation? identityref 330 | +--ro performance-metric-one-way 331 | | +--ro one-way-delay? uint32 332 | | +--ro one-way-min-delay? uint32 333 | | +--ro one-way-max-delay? uint32 334 | | +--ro one-way-delay-variation? uint32 335 | | +--ro one-way-packet-loss? decimal64 336 | | +--ro one-way-residual-bandwidth? 337 | | | rt-types:bandwidth-ieee-float32 338 | | +--ro one-way-available-bandwidth? 339 | | | rt-types:bandwidth-ieee-float32 340 | | +--ro one-way-utilized-bandwidth? 341 | | rt-types:bandwidth-ieee-float32 342 | +--ro performance-metric-two-way 343 | +--ro two-way-delay? uint32 344 | +--ro two-way-min-delay? uint32 345 | +--ro two-way-max-delay? uint32 346 | +--ro two-way-delay-variation? uint32 347 | +--ro two-way-packet-loss? decimal64 348 +--rw tunnel* 349 [provider-id client-id topology-id source destination 350 tunnel-id] 351 +--rw provider-id te-types:te-global-id 352 +--rw client-id te-types:te-global-id 353 +--rw topology-id 354 | te-types:te-topology-id 355 +--rw source inet:ip-address 356 +--rw destination inet:ip-address 357 +--rw tunnel-id binary 358 +--ro tunnel-type? identityref 359 +--ro switching-type? identityref 360 +--ro protection-type? identityref 361 +--ro encapsulation? identityref 362 +--ro performance-metric-one-way 363 | +--ro one-way-delay? uint32 364 | +--ro one-way-min-delay? uint32 365 | +--ro one-way-max-delay? uint32 366 | +--ro one-way-delay-variation? uint32 367 | +--ro one-way-packet-loss? decimal64 368 | +--ro one-way-residual-bandwidth? 369 | | rt-types:bandwidth-ieee-float32 370 | +--ro one-way-available-bandwidth? 371 | | rt-types:bandwidth-ieee-float32 372 | +--ro one-way-utilized-bandwidth? 373 | rt-types:bandwidth-ieee-float32 374 +--ro performance-metric-two-way 375 +--ro two-way-delay? uint32 376 +--ro two-way-min-delay? uint32 377 +--ro two-way-max-delay? uint32 378 +--ro two-way-delay-variation? uint32 379 +--ro two-way-packet-loss? decimal64 381 6. YANG Modules 383 file "ietf-tunnel-steering@2018-11-03.yang" 384 module ietf-tunnel-steering { 385 yang-version 1; 386 namespace "urn:ietf:params:xml:ns:yang:ietf-tunnel-steering"; 388 prefix "tnl-steer"; 390 import ietf-inet-types { 391 prefix inet; 392 } 394 import ietf-te-types { 395 prefix "te-types"; 396 } 398 organization 399 "IETF Traffic Engineering Architecture and Signaling (TEAS) 400 Working Group"; 402 contact 403 "WG Web: 404 WG List: 406 Editors: Igor Bryskin 407 409 Editor: Vishnu Pavan Beeram 410 412 Editor: Tarek Saad 413 415 Editor: Xufeng Liu 416 "; 418 description 419 "This data model is for steering client service to server 420 tunnels. 422 Copyright (c) 2018 IETF Trust and the persons identified as 423 authors of the code. All rights reserved. 425 Redistribution and use in source and binary forms, with or 426 without modification, is permitted pursuant to, and subject to 427 the license terms contained in, the Simplified BSD License set 428 forth in Section 4.c of the IETF Trust's Legal Provisions 429 Relating to IETF Documents 430 (http://trustee.ietf.org/license-info)."; 432 revision 2018-11-03 { 433 description "Initial revision"; 434 reference "TBD"; 435 } 437 /* 438 * Typedefs 439 */ 441 /* 442 * Identities 443 */ 444 identity service-type { 445 description "Base identity for client service type."; 446 } 447 identity service-type-l3vpn { 448 base service-type; 449 description 450 "L3VPN service."; 451 } 452 identity service-type-l2vpn { 453 base service-type; 454 description 455 "L2VPN service."; 456 } 457 identity service-type-evpn { 458 base service-type; 459 description 460 "EVPN service."; 461 } 462 identity service-type-eline { 463 base service-type; 464 description 465 "ELINE service."; 466 } 467 identity service-type-epl { 468 base service-type; 469 description 470 "EPL service."; 471 } 472 identity service-type-evpl { 473 base service-type; 474 description 475 "EVPL service."; 477 } 478 identity service-type-l1vpn { 479 base service-type; 480 description 481 "L1VPN service."; 482 } 483 identity service-type-actn-vn { 484 base service-type; 485 description 486 "ACTN VN service."; 487 } 488 identity service-type-transparent { 489 base service-type; 490 description 491 "Transparent LAN service."; 492 } 494 identity encapsulation-type { 495 description "Base identity for tunnel encapsulation."; 496 } 497 identity encapsulation-type-mpls-label { 498 base encapsulation-type; 499 description 500 "Encapsulated by MPLS label stack."; 501 } 502 identity encapsulation-type-ethernet-s-tag { 503 base encapsulation-type; 504 description 505 "Encapsulated by Ethernet S-TAG."; 506 } 507 identity encapsulation-type-pbb { 508 base encapsulation-type; 509 description 510 "Encapsulated by PBB header."; 511 } 512 identity encapsulation-type-gre { 513 base encapsulation-type; 514 description 515 "Encapsulated by GRE header."; 516 } 518 /* 519 * Groupings 520 */ 522 /* 523 * Configuration data and operational state data nodes 524 */ 526 container tunnel-pools { 527 description 528 "A list of mappings that steer client services to transport 529 tunnel pools. The tunnel pools are managed independently from 530 the services steered on them."; 532 list tunnel-pool { 533 key "color"; 534 description 535 "A set of transport tunnels (presumably with similar 536 characteristics) identified by a network unique ID, named 537 'color'."; 538 leaf color { 539 type uint32; 540 description 541 "Unique ID of a tunnel pool."; 542 } 543 leaf description { 544 type string; 545 description 546 "Client provided description of the tunnel pool."; 547 } 548 list service { 549 key "service-type id"; 550 description 551 "A list of client services that are steered on this tunnel 552 pool."; 553 leaf service-type { 554 type identityref { 555 base service-type; 556 } 557 description 558 "Service type required by the client."; 559 } 560 leaf id { 561 type string; 562 description 563 "Unique ID of a client service for the specified 564 service type."; 565 } 566 list access-point { 567 key "node-address link-termination-point"; 568 config false; 569 description 570 "A list of client ports (Link Termination Points) for the 571 service to enter or exist."; 572 leaf node-address { 573 type inet:ip-address; 574 description 575 "Node over which the service enters or exists."; 576 } 577 leaf link-termination-point { 578 type string; 579 description 580 "Client port (Link Termination Point) over which the 581 service enters or exits."; 582 } 583 leaf direction { 584 type enumeration { 585 enum "in" { 586 description "The service enters to the network."; 587 } 588 enum "out" { 589 description "The service exists from the network."; 590 } 591 enum "in-out" { 592 description 593 "The service enters to and exists from the 594 network."; 595 } 596 } 597 description 598 "Whether the service enters to or exits from the 599 network."; 600 } 601 } 602 leaf switching-type { 603 type identityref { 604 base te-types:switching-capabilities; 605 } 606 config false; 607 description 608 "Tunnel switching type required by the client."; 609 reference "RFC3945"; 610 } 611 leaf protection-type { 612 type identityref { 613 base te-types:lsp-protection-type; 614 } 615 config false; 616 description 617 "The protection type required by the client."; 618 } 619 leaf encapsulation { 620 type identityref { 621 base encapsulation-type; 623 } 624 config false; 625 description 626 "The encapsulation type used by the tunnel."; 627 } 628 uses te-types:performance-metric-container { 629 refine performance-metric-one-way { 630 config false; 631 } 632 refine performance-metric-two-way { 633 config false; 634 } 635 } 636 } 637 list tunnel { 638 key "provider-id client-id topology-id source destination " 639 + "tunnel-id"; 640 description 641 "A list of tunnels in the tunnel pool."; 643 leaf provider-id { 644 type te-types:te-global-id; 645 description 646 "An identifier to uniquely identify a provider."; 647 } 648 leaf client-id { 649 type te-types:te-global-id; 650 description 651 "An identifier to uniquely identify a client."; 652 } 653 leaf topology-id { 654 type te-types:te-topology-id; 655 description 656 "It is presumed that a datastore will contain many 657 topologies. To distinguish between topologies it is 658 vital to have UNIQUE topology identifiers."; 659 } 660 leaf source { 661 type inet:ip-address; 662 description 663 "For a p2p or p2mp tunnel, this is the source address; 664 for a mp2mp tunnel, this is the root address."; 665 reference "RFC3209, RFC4875, RFC6388, RFC7582."; 666 } 667 leaf destination { 668 type inet:ip-address; 669 description 670 "For a p2p tunnel, this is the tunnel endpoint address 671 extracted from SESSION object; 672 for a p2mp tunnel, this identifies the destination 673 group, or p2mp-id; 674 for a mp2mp tunnel identified by root and opaque-value, 675 this value is set to '0'."; 676 reference "RFC3209, RFC4875, RFC6388, RFC7582."; 677 } 678 leaf tunnel-id { 679 type binary; 680 description 681 "For a p2p or p2mp tunnel, this is the tunnel identifier 682 used in the SESSION that remains constant over the life 683 of the tunnel; 684 for a mp2mp tunnel, this is the opaque-value in the 685 FEC element."; 686 reference "RFC3209, RFC4875, RFC6388, RFC7582."; 687 } 688 leaf tunnel-type { 689 type identityref { 690 base te-types:te-tunnel-type; 691 } 692 config false; 693 description 694 "Tunnel type based on constructing technologies and 695 multipoint types, including P2P-TE, P2MP-TE, SR-TE, 696 SR P2P, LDP P2P, LDP MP2MP, GRE, PBB, etc"; 697 } 698 leaf switching-type { 699 type identityref { 700 base te-types:switching-capabilities; 701 } 702 config false; 703 description "Tunnel switching type"; 704 reference "RFC3945"; 705 } 706 leaf protection-type { 707 type identityref { 708 base te-types:lsp-protection-type; 709 } 710 config false; 711 description 712 "The protection type provided by this tunnel."; 713 } 714 leaf encapsulation { 715 type identityref { 716 base encapsulation-type; 717 } 718 config false; 719 description 720 "The encapsulation type used by the tunnel."; 721 } 722 uses te-types:performance-metric-container { 723 refine performance-metric-one-way { 724 config false; 725 } 726 refine performance-metric-two-way { 727 config false; 728 } 729 } 730 } 731 } 732 } 733 } 734 736 7. IANA Considerations 738 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 739 actual RFC number (and remove this note). 741 This document registers the following namespace URIs in the IETF XML 742 registry [RFC3688]: 744 -------------------------------------------------------------------- 745 URI: urn:ietf:params:xml:ns:yang:ietf-tunnel-steering 746 Registrant Contact: The IESG. 747 XML: N/A, the requested URI is an XML namespace. 748 -------------------------------------------------------------------- 750 This document registers the following YANG modules in the YANG Module 751 Names registry [RFC7950]: 753 -------------------------------------------------------------------- 754 name: ietf-tunnel-steering 755 namespace: urn:ietf:params:xml:ns:yang:ietf-tunnel-steering 756 prefix: tnl-steer 757 reference: RFC XXXX 758 -------------------------------------------------------------------- 760 8. Security Considerations 762 The configuration, state, action and notification data defined in 763 this document are designed to be accessed via the NETCONF protocol 764 [RFC6241]. The data-model by itself does not create any security 765 implications. The security considerations for the NETCONF protocol 766 are applicable. The NETCONF protocol used for sending the data 767 supports authentication and encryption. 769 9. References 771 9.1. Normative References 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, 775 DOI 10.17487/RFC2119, March 1997, 776 . 778 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 779 and A. Bierman, Ed., "Network Configuration Protocol 780 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 781 . 783 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 784 RFC 6991, DOI 10.17487/RFC6991, July 2013, 785 . 787 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 788 RFC 7950, DOI 10.17487/RFC7950, August 2016, 789 . 791 [I-D.ietf-teas-yang-te-topo] 792 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 793 O. Dios, "YANG Data Model for Traffic Engineering (TE) 794 Topologies", draft-ietf-teas-yang-te-topo-18 (work in 795 progress), June 2018. 797 [I-D.ietf-teas-yang-te] 798 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and 799 I. Bryskin, "A YANG Data Model for Traffic Engineering 800 Tunnels and Interfaces", draft-ietf-teas-yang-te-17 (work 801 in progress), October 2018. 803 9.2. Informative References 805 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 806 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 807 . 809 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 810 and R. Wilton, "Network Management Datastore Architecture 811 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 812 . 814 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 815 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 816 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 817 2018, . 819 Authors' Addresses 821 Igor Bryskin 822 Huawei Technologies 824 EMail: Igor.Bryskin@huawei.com 826 Vishnu Pavan Beeram 827 Juniper Networks 829 EMail: vbeeram@juniper.net 831 Tarek Saad 832 Cisco Systems Inc 834 EMail: tsaad@cisco.com 836 Xufeng Liu 837 Volta Networks 839 EMail: xufeng.liu.ietf@gmail.com 841 Young Lee 842 Huawei Technologies 844 EMail: leeyoung@huawei.com