idnits 2.17.1 draft-bryskin-teas-service-tunnel-steering-model-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 == Line 325 has weird spacing: '...n-point str...' -- The document date (October 16, 2018) is 2016 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3688' is mentioned on line 720, but not defined == Unused Reference: 'I-D.ietf-teas-yang-te-topo' is defined on line 769, but no explicit reference was found in the text == Unused Reference: 'RFC8342' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'RFC8345' is defined on line 792, 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-16 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: April 19, 2019 Juniper Networks 6 T. Saad 7 Cisco Systems Inc 8 X. Liu 9 Volta Networks 10 Y. Lee 11 Huawei Technologies 12 October 16, 2018 14 Basic YANG Model for Steering Client Services To Server Tunnels 15 draft-bryskin-teas-service-tunnel-steering-model-00 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 April 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 70 9.2. Informative References . . . . . . . . . . . . . . . . . 17 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 | +--rw access-point* [node-address link-termination-point] 324 | | +--rw node-address inet:ip-address 325 | | +--rw link-termination-point string 326 | | +--rw direction? enumeration 327 | +--rw switching-type? identityref 328 | +--rw protection-type? identityref 329 | +--rw encapsulation? identityref 330 | +--rw performance-metric-one-way 331 | | +--rw one-way-delay? uint32 332 | | +--rw one-way-min-delay? uint32 333 | | +--rw one-way-max-delay? uint32 334 | | +--rw one-way-delay-variation? uint32 335 | | +--rw one-way-packet-loss? decimal64 336 | | +--rw one-way-residual-bandwidth? 337 | | | rt-types:bandwidth-ieee-float32 338 | | +--rw one-way-available-bandwidth? 339 | | | rt-types:bandwidth-ieee-float32 340 | | +--rw one-way-utilized-bandwidth? 341 | | rt-types:bandwidth-ieee-float32 342 | +--rw performance-metric-two-way 343 | +--rw two-way-delay? uint32 344 | +--rw two-way-min-delay? uint32 345 | +--rw two-way-max-delay? uint32 346 | +--rw two-way-delay-variation? uint32 347 | +--rw 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 tunnel-type? identityref 356 +--rw source inet:ip-address 357 +--rw destination inet:ip-address 358 +--rw tunnel-id binary 359 +--rw switching-type? identityref 360 +--rw protection-type? identityref 361 +--rw encapsulation? identityref 362 +--rw performance-metric-one-way 363 | +--rw one-way-delay? uint32 364 | +--rw one-way-min-delay? uint32 365 | +--rw one-way-max-delay? uint32 366 | +--rw one-way-delay-variation? uint32 367 | +--rw one-way-packet-loss? decimal64 368 | +--rw one-way-residual-bandwidth? 369 | | rt-types:bandwidth-ieee-float32 370 | +--rw one-way-available-bandwidth? 371 | | rt-types:bandwidth-ieee-float32 372 | +--rw one-way-utilized-bandwidth? 373 | rt-types:bandwidth-ieee-float32 374 +--rw performance-metric-two-way 375 +--rw two-way-delay? uint32 376 +--rw two-way-min-delay? uint32 377 +--rw two-way-max-delay? uint32 378 +--rw two-way-delay-variation? uint32 379 +--rw two-way-packet-loss? decimal64 381 6. YANG Modules 383 file "ietf-tunnel-steering@2018-10-15.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-10-15 { 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 description 569 "A list of client ports (Link Termination Points) for the 570 service to enter or exist."; 571 leaf node-address { 572 type inet:ip-address; 573 description 574 "Node over which the service enters or exists."; 575 } 576 leaf link-termination-point { 577 type string; 578 description 579 "Client port (Link Termination Point) over which the 580 service enters or exits."; 581 } 582 leaf direction { 583 type enumeration { 584 enum "in" { 585 description "The service enters to the network."; 586 } 587 enum "out" { 588 description "The service exists from the network."; 589 } 590 enum "in-out" { 591 description 592 "The service enters to and exists from the 593 network."; 594 } 595 } 596 description 597 "Whether the service enters to or exits from the 598 network."; 599 } 600 } 601 leaf switching-type { 602 type identityref { 603 base te-types:switching-capabilities; 604 } 605 description 606 "Tunnel switching type required by the client."; 607 reference "RFC3945"; 608 } 609 leaf protection-type { 610 type identityref { 611 base te-types:lsp-protection-type; 612 } 613 description 614 "The protection type required by the client."; 615 } 616 leaf encapsulation { 617 type identityref { 618 base encapsulation-type; 619 } 620 description 621 "The encapsulation type used by the tunnel."; 623 } 624 uses te-types:performance-metric-container; 625 } 626 list tunnel { 627 key "provider-id client-id topology-id source destination " 628 + "tunnel-id"; 629 description 630 "A list of tunnels in the tunnel pool."; 632 leaf provider-id { 633 type te-types:te-global-id; 634 description 635 "An identifier to uniquely identify a provider."; 636 } 637 leaf client-id { 638 type te-types:te-global-id; 639 description 640 "An identifier to uniquely identify a client."; 641 } 642 leaf topology-id { 643 type te-types:te-topology-id; 644 description 645 "It is presumed that a datastore will contain many 646 topologies. To distinguish between topologies it is 647 vital to have UNIQUE topology identifiers."; 648 } 649 leaf tunnel-type { 650 type identityref { 651 base te-types:te-tunnel-type; 652 } 653 description 654 "Tunnel type based on constructing technologies and 655 multipoint types, including P2P-TE, P2MP-TE, SR-TE, 656 SR P2P, LDP P2P, LDP MP2MP, GRE, PBB, etc"; 657 } 658 leaf source { 659 type inet:ip-address; 660 description 661 "For a p2p or p2mp tunnel, this is the source address; 662 for a mp2mp tunnel, this is the root address."; 663 reference "RFC3209, RFC4875, RFC6388, RFC7582."; 664 } 665 leaf destination { 666 type inet:ip-address; 667 description 668 "For a p2p tunnel, this is the tunnel endpoint address 669 extracted from SESSION object; 670 for a p2mp tunnel, this identifies the destination 671 group, or p2mp-id; 672 for a mp2mp tunnel identified by root and opaque-value, 673 this value is set to '0'."; 674 reference "RFC3209, RFC4875, RFC6388, RFC7582."; 675 } 676 leaf tunnel-id { 677 type binary; 678 description 679 "For a p2p or p2mp tunnel, this is the tunnel identifier 680 used in the SESSION that remains constant over the life 681 of the tunnel; 682 for a mp2mp tunnel, this is the opaque-value in the 683 FEC element."; 684 reference "RFC3209, RFC4875, RFC6388, RFC7582."; 685 } 686 leaf switching-type { 687 type identityref { 688 base te-types:switching-capabilities; 689 } 690 description "Tunnel switching type"; 691 reference "RFC3945"; 692 } 693 leaf protection-type { 694 type identityref { 695 base te-types:lsp-protection-type; 696 } 697 description 698 "The protection type provided by this tunnel."; 699 } 700 leaf encapsulation { 701 type identityref { 702 base encapsulation-type; 703 } 704 description 705 "The encapsulation type used by the tunnel."; 706 } 707 uses te-types:performance-metric-container; 708 } 709 } 710 } 711 } 712 714 7. IANA Considerations 716 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 717 actual RFC number (and remove this note). 719 This document registers the following namespace URIs in the IETF XML 720 registry [RFC3688]: 722 -------------------------------------------------------------------- 723 URI: urn:ietf:params:xml:ns:yang:ietf-tunnel-steering 724 Registrant Contact: The IESG. 725 XML: N/A, the requested URI is an XML namespace. 726 -------------------------------------------------------------------- 728 This document registers the following YANG modules in the YANG Module 729 Names registry [RFC7950]: 731 -------------------------------------------------------------------- 732 name: ietf-tunnel-steering 733 namespace: urn:ietf:params:xml:ns:yang:ietf-tunnel-steering 734 prefix: tnl-steer 735 reference: RFC XXXX 736 -------------------------------------------------------------------- 738 8. Security Considerations 740 The configuration, state, action and notification data defined in 741 this document are designed to be accessed via the NETCONF protocol 742 [RFC6241]. The data-model by itself does not create any security 743 implications. The security considerations for the NETCONF protocol 744 are applicable. The NETCONF protocol used for sending the data 745 supports authentication and encryption. 747 9. References 749 9.1. Normative References 751 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 752 Requirement Levels", BCP 14, RFC 2119, 753 DOI 10.17487/RFC2119, March 1997, 754 . 756 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 757 and A. Bierman, Ed., "Network Configuration Protocol 758 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 759 . 761 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 762 RFC 6991, DOI 10.17487/RFC6991, July 2013, 763 . 765 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 766 RFC 7950, DOI 10.17487/RFC7950, August 2016, 767 . 769 [I-D.ietf-teas-yang-te-topo] 770 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 771 O. Dios, "YANG Data Model for Traffic Engineering (TE) 772 Topologies", draft-ietf-teas-yang-te-topo-18 (work in 773 progress), June 2018. 775 [I-D.ietf-teas-yang-te] 776 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and 777 I. Bryskin, "A YANG Data Model for Traffic Engineering 778 Tunnels and Interfaces", draft-ietf-teas-yang-te-16 (work 779 in progress), July 2018. 781 9.2. Informative References 783 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 784 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 785 . 787 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 788 and R. Wilton, "Network Management Datastore Architecture 789 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 790 . 792 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 793 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 794 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 795 2018, . 797 Authors' Addresses 799 Igor Bryskin 800 Huawei Technologies 802 EMail: Igor.Bryskin@huawei.com 804 Vishnu Pavan Beeram 805 Juniper Networks 807 EMail: vbeeram@juniper.net 808 Tarek Saad 809 Cisco Systems Inc 811 EMail: tsaad@cisco.com 813 Xufeng Liu 814 Volta Networks 816 EMail: xufeng.liu.ietf@gmail.com 818 Young Lee 819 Huawei Technologies 821 EMail: leeyoung@huawei.com