idnits 2.17.1 draft-bryskin-teas-service-tunnel-steering-model-02.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 310 has weird spacing: '...n-point str...' -- The document date (February 26, 2019) is 1884 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3688' is mentioned on line 723, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-19 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-19 Summary: 2 errors (**), 0 flaws (~~), 5 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: August 30, 2019 Juniper Networks 6 T. Saad 7 Cisco Systems Inc 8 X. Liu 9 Volta Networks 10 Y. Lee 11 Huawei Technologies 12 February 26, 2019 14 Basic YANG Model for Steering Client Services To Server Tunnels 15 draft-bryskin-teas-service-tunnel-steering-model-02 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 August 30, 2019. 39 Copyright Notice 41 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . 18 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) provisioned 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 an 96 IP network; 98 o Mapping client services to tunnels provisioned 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 [I-D.ietf-teas-yang-te-topo], such a description would 106 be verbose, cumbersome, difficult to expand to accommodate 107 additional client signals and unnecessary, because the client 108 layer topologies would have zero switching flexibility inside the 109 network (i.e. contain only unrelated links connecting access 110 points across respective layer networks), and all what is required 111 to know from the point of view of a management application is what 112 ODUk tunnels are established or required, which client signals the 113 tunnels could carry and at which network border nodes and how the 114 client signals could be bound (i.e. 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 It is important to bear in mind that service2tunnel mappings could be 124 very complex: large number of instances of services of the same or 125 different types (possibly governed by different models) could be 126 mapped on the same set of tunnels, with the latter being set in 127 different network layers and of either TE or non-TE nature, P2P or 128 P2MP or MP2MP type. Furthermore, the mappings could be hierarchical: 129 tunnels carrying services could be clients of other tunnels. 131 Despite of the differences of transport tunnels and of services they 132 carry the srvice2tunnel mappings could be modeled in a simple uniform 133 way. Access to a data store of such mappings could be beneficial to 134 network management applications. It would be possible, for example, 135 to discover which services depend on which tunnels, which services 136 will be affected if a given tunnel goes out of service, how many more 137 services could be placed onto a given TE tunnel without the latter 138 violating its TE commitments (such as bandwidth and delay). It would 139 be also possible to demand in a single request moving numerous 140 (ranges of) service instances from one set of tunnels to another. 142 This document defines a YANG data model for facilitating said 143 xervice2tunnel mappings. 145 The YANG model in this document conforms to the Network Management 146 Datastore Architecture (NMDA) [RFC8342]. 148 1.1. Terminology 150 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14, [RFC2119]. 155 The following terms are defined in [RFC7950] and are not redefined 156 here: 158 o augment 160 o data model 162 o data node 164 1.2. Tree Diagrams 166 A simplified graphical representation of the data model is presented 167 in this document, by using the tree format defined in [RFC8340]. 169 1.3. Prefixes in Data Node Names 171 In this document, names of data nodes, actions, and other data model 172 objects are often used without a prefix, as long as it is clear from 173 the context in which YANG module each name is defined. Otherwise, 174 names are prefixed using the standard prefix associated with the 175 corresponding YANG module, as shown in Table 1. 177 +----------+-----------------+-------------------------+ 178 | Prefix | YANG module | Reference | 179 +----------+-----------------+-------------------------+ 180 | inet | ietf-inet-types | [RFC6991] | 181 | te-types | ietf-te-types | [I-D.ietf-teas-yang-te] | 182 +----------+-----------------+-------------------------+ 184 Table 1: Prefixes and Corresponding YANG Modules 186 2. Explicit vs. Implicit Service2tunnel Mapping. Steering Services to 187 Transport Tunnel Pools 189 There are use cases in which client services require hard separation 190 of the transport carrying them from the transport carrying other 191 services. However, environment in which the services may share the 192 same transport tunnels is far more common. For this reason the model 193 defined in this document suggests replacing (or at least augmenting) 194 the explicit service2tunnel mapping configuration (in which the 195 tunnels are referred to by their IDs/names) with an implicit mapping. 196 Specifically, the model introduces the notion of tunnel pool. A 197 tunnel pool could be referred to by its network unique color and 198 requires a service2tunnel mapping configuration to specify the tunnel 199 pool color(s) instead of tunnel IDs/names. The model governs tunnel 200 pool data store independently from the services steered on the 201 tunnels. It is assumed (although not required) that the tunnels - 202 constituents/components of a tunnel pool - are of the same type, 203 provisioned using a common template. Importantly they could be 204 dynamically added to/removed from the pool without necessitating 205 service2tunnel mapping re-configuration. Such a service to tunnel 206 pool steering approach has the following advantages: 208 o Scalability and efficiency: pool component bandwidth utilization 209 could be monitored, tunnels could be added to/removed from the 210 pool if/when detected that current component bandwidth utilization 211 has crossed certain thresholds. This allows for a very efficient 212 network resource utilization and obviates the network management 213 application from a very difficult task of service to tunnel 214 mapping planning; 216 o Automation and elasticity: pool component attributes could be 217 modified - bandwidth auto-adjusted, protection added, delay 218 constrained, etc.. The tunnels could be completely or partially 219 replaced with tunnels of different types (e.g. TE vs. non-TE, P2P 220 vs. P2MP, etc.) or even provisioned in different network layers 221 (OTN/ODUk tunnels replacing IP TE tunnels). Importantly, all such 222 modifications do not require service2tunell mapping re- 223 configurations as long as the modified or new tunnels remain 224 within the same tunnel pool(s); 226 o Transparency: new service sites supported by additional PEs could 227 be added without service2tunnel mapping re-configuration. 229 3. The purpose of the model 231 The model is targeted to facilitate for network management 232 applications, such as service orchestrators, the control of pools of 233 transport tunnels and steering onto them client services 234 independently of network technology/layer specifics of both the 235 services and the tunnels. The model could be applied to/implemented 236 on physical devices, such as IP routers, as well as on abstract 237 topology nodes. Furthermore, the model could be supported by a 238 network (domain) controller, such as ACTN PNC, to act as a proxy 239 server on behalf of any network element/node (physical or abstract) 240 under its control. 242 4. Model Design 244 The data store described/governed by the model is comprised of a 245 single top level list - TunnelPools. A TunnelPool, list element, is 246 a container describing a set of transport tunnels (presumably with 247 similar characteristics) identified by a network unique ID (color). 249 The TunnelPool container has the following fields: 251 o Color [uint32 list key]; 253 o Tunnels list; 255 o Services list. 257 The Tunnels list describes the pool constituents - active transport 258 tunnels. The list members - Tunnel containers - include the 259 following information: 261 o tunnel type [e.g. P2P-TE, P2MP-TE, SR-TE, SR P2P, LDP P2P, LDP 262 MP2MP, GRE, PBB, etc] 264 o tunnel type specific tunnel ID [provided that a data store of the 265 tunnel type, e.g. TE tunnels, is supported, the tunnelID allows 266 for the management application to look up the tunnel in question 267 to obtain detailed information about the tunnel]; 269 o topology ID [ identifies the topology over which the tunnel's 270 connection paths are defined]; 272 o tunnel encapsulation [e.g. MPLS label stack, Ethernet STAGs, GRE 273 header, PBB header, etc]. 275 The Services list describes services currently steered on the tunnel 276 pool. The list members - Service containers - have the following 277 attributes: 279 o service type [e.g. fixed/transparent, L3VPN, L2VPN, EVPN, ELINE, 280 EPL, EVPL, L1VPN, ACTN VN, etc.]; 282 o service type specific service ID [provided that a data store of 283 the service type, e.g. L2VPN, is supported, the service ID allows 284 for the management application to look up the service in question 285 to obtain detailed information about the service]; 287 o client ports (source/destination node LTPs over which the service 288 enters/exits the node/network, relevant only for fixed/transparent 289 services); 291 o service encapsulation [e.g. MPLS label stack, Ethernet CTAGs, 292 etc.] - for service multiplexing/de-multiplexing on/from a 293 statistically shared tunnel]. 295 5. Tree Structure 297 module: ietf-tunnel-steering 298 +--rw tunnel-pools 299 +--rw tunnel-pool* [color] 300 +--rw color uint32 301 +--rw description? string 302 +--rw service* [service-type id] 303 | +--rw service-type identityref 304 | +--rw id string 305 | +--rw encapsulation 306 | | +--rw type? identityref 307 | | +--rw value? binary 308 | +--rw access-point* [node-address link-termination-point] 309 | +--rw node-address inet:ip-address 310 | +--rw link-termination-point string 311 | +--rw direction? enumeration 312 +--rw tunnel* 313 [provider-id client-id topology-id tunnel-type source 314 destination tunnel-id] 315 +--rw provider-id te-types:te-global-id 316 +--rw client-id te-types:te-global-id 317 +--rw topology-id te-types:te-topology-id 318 +--rw tunnel-type identityref 319 +--rw source inet:ip-address 320 +--rw destination inet:ip-address 321 +--rw tunnel-id binary 322 +--rw encapsulation 323 +--rw type? identityref 324 +--rw value? binary 326 6. YANG Modules 328 file "ietf-tunnel-steering@2019-02-15.yang" 329 module ietf-tunnel-steering { 330 yang-version 1; 331 namespace "urn:ietf:params:xml:ns:yang:ietf-tunnel-steering"; 333 prefix "tnl-steer"; 334 import ietf-inet-types { 335 prefix inet; 336 } 338 import ietf-te-types { 339 prefix "te-types"; 340 } 342 organization 343 "IETF Traffic Engineering Architecture and Signaling (TEAS) 344 Working Group"; 346 contact 347 "WG Web: 348 WG List: 350 Editors: Igor Bryskin 351 353 Editor: Vishnu Pavan Beeram 354 356 Editor: Tarek Saad 357 359 Editor: Xufeng Liu 360 362 Editor: Young Lee 363 "; 365 description 366 "This data model is for steering client service to server 367 tunnels. 369 Copyright (c) 2018 IETF Trust and the persons identified as 370 authors of the code. All rights reserved. 372 Redistribution and use in source and binary forms, with or 373 without modification, is permitted pursuant to, and subject to 374 the license terms contained in, the Simplified BSD License set 375 forth in Section 4.c of the IETF Trust's Legal Provisions 376 Relating to IETF Documents 377 (http://trustee.ietf.org/license-info)."; 379 revision 2019-02-15 { 380 description "Initial revision"; 381 reference "TBD"; 383 } 385 /* 386 * Typedefs 387 */ 389 /* 390 * Identities 391 */ 392 identity service-type { 393 description "Base identity for client service type."; 394 } 395 identity service-type-l3vpn { 396 base service-type; 397 description 398 "L3VPN service."; 399 } 400 identity service-type-l2vpn { 401 base service-type; 402 description 403 "L2VPN service."; 404 } 405 identity service-type-evpn { 406 base service-type; 407 description 408 "EVPN service."; 409 } 410 identity service-type-eline { 411 base service-type; 412 description 413 "ELINE service."; 414 } 415 identity service-type-epl { 416 base service-type; 417 description 418 "EPL service."; 419 } 420 identity service-type-evpl { 421 base service-type; 422 description 423 "EVPL service."; 424 } 425 identity service-type-l1vpn { 426 base service-type; 427 description 428 "L1VPN service."; 429 } 430 identity service-type-actn-vn { 431 base service-type; 432 description 433 "ACTN VN service."; 434 } 435 identity service-type-transparent { 436 base service-type; 437 description 438 "Transparent LAN service."; 439 } 441 identity tunnel-type { 442 description "Base identity for tunnel type."; 443 } 444 identity tunnel-type-te-p2p { 445 base tunnel-type; 446 description 447 "TE point-to-point tunnel type."; 448 } 449 identity tunnel-type-te-p2mp { 450 base tunnel-type; 451 description 452 "TE point-to-multipoint tunnel type."; 453 reference "RFC4875"; 454 } 455 identity tunnel-type-te-sr { 456 base tunnel-type; 457 description 458 "Segment Rouging TE tunnel type."; 459 } 460 identity tunnel-type-sr { 461 base tunnel-type; 462 description 463 "Segment Rouging tunnel type."; 464 } 465 identity tunnel-type-ldp-p2p { 466 base tunnel-type; 467 description 468 "LDP point-to-point tunnel type."; 469 } 470 identity tunnel-type-ldp-mp2mp { 471 base tunnel-type; 472 description 473 "Multicast LDP multipoint-to-multipoint tunnel type."; 474 } 475 identity tunnel-type-gre { 476 base tunnel-type; 477 description 478 "GRE tunnel type."; 480 } 481 identity tunnel-type-pbb { 482 base tunnel-type; 483 description 484 "PBB tunnel type."; 485 } 487 identity service-encapsulation-type { 488 description "Base identity for tunnel encapsulation."; 489 } 490 identity service-encapsulation-type-mpls-label { 491 base service-encapsulation-type; 492 description 493 "Encapsulated by MPLS label stack, as an inner lable to 494 identify the customer service."; 495 } 496 identity service-encapsulation-type-ethernet-c-tag { 497 base service-encapsulation-type; 498 description 499 "Encapsulated by Ethernet C-TAG, to identify the customer 500 service."; 501 } 503 identity tunnel-encapsulation-type { 504 description "Base identity for tunnel encapsulation."; 505 } 506 identity tunnel-encapsulation-type-mpls-label { 507 base tunnel-encapsulation-type; 508 description 509 "Encapsulated by MPLS label stack, as an outer label to 510 be pushed into the tunnel."; 511 } 512 identity tunnel-encapsulation-type-ethernet-s-tag { 513 base tunnel-encapsulation-type; 514 description 515 "Encapsulated by Ethernet S-TAG."; 516 } 517 identity tunnel-encapsulation-type-pbb { 518 base tunnel-encapsulation-type; 519 description 520 "Encapsulated by PBB header."; 521 } 522 identity tunnel-encapsulation-type-gre { 523 base tunnel-encapsulation-type; 524 description 525 "Encapsulated by GRE header."; 526 } 527 /* 528 * Groupings 529 */ 531 /* 532 * Configuration data and operational state data nodes 533 */ 534 container tunnel-pools { 535 description 536 "A list of mappings that steer client services to transport 537 tunnel pools. The tunnel pools are managed independently from 538 the services steered on them."; 540 list tunnel-pool { 541 key "color"; 542 description 543 "A set of transport tunnels (presumably with similar 544 characteristics) identified by a network unique ID, named 545 'color'."; 546 leaf color { 547 type uint32; 548 description 549 "Unique ID of a tunnel pool."; 550 } 551 leaf description { 552 type string; 553 description 554 "Client provided description of the tunnel pool."; 555 } 556 list service { 557 key "service-type id"; 558 description 559 "A list of client services that are steered on this tunnel 560 pool."; 561 leaf service-type { 562 type identityref { 563 base service-type; 564 } 565 description 566 "Service type required by the client."; 567 } 568 leaf id { 569 type string; 570 description 571 "Unique ID of a client service for the specified 572 service type."; 573 } 574 container encapsulation { 575 description 576 "The encapsulation information used to identify the 577 customer service for multiplexing over shared tunnels."; 578 leaf type { 579 type identityref { 580 base service-encapsulation-type; 581 } 582 description 583 "The encapsulation type used to identify the customer 584 service for multiplexing over shared tunnels."; 585 } 586 leaf value { 587 type binary; 588 description 589 "The encapsulation value pushed to the tunnel to 590 identify this service. 591 If not specified, the system decides what 592 value to be used for multiplexing."; 593 } 594 } 595 list access-point { 596 key "node-address link-termination-point"; 597 description 598 "A list of client ports (Link Termination Points) for the 599 service to enter or exist."; 600 leaf node-address { 601 type inet:ip-address; 602 description 603 "Node over which the service enters or exists."; 604 } 605 leaf link-termination-point { 606 type string; 607 description 608 "Client port (Link Termination Point) over which the 609 service enters or exits."; 610 } 611 leaf direction { 612 type enumeration { 613 enum "in" { 614 description "The service enters to the network."; 615 } 616 enum "out" { 617 description "The service exists from the network."; 618 } 619 enum "in-out" { 620 description 621 "The service enters to and exists from the 622 network."; 624 } 625 } 626 description 627 "Whether the service enters to or exits from the 628 network."; 629 } 630 } 631 } 632 list tunnel { 633 key "provider-id client-id topology-id tunnel-type source " 634 + "destination tunnel-id"; 635 description 636 "A list of tunnels in the tunnel pool."; 638 leaf provider-id { 639 type te-types:te-global-id; 640 description 641 "An identifier to uniquely identify a provider."; 642 } 643 leaf client-id { 644 type te-types:te-global-id; 645 description 646 "An identifier to uniquely identify a client."; 647 } 648 leaf topology-id { 649 type te-types:te-topology-id; 650 description 651 "It is presumed that a datastore will contain many 652 topologies. To distinguish between topologies it is 653 vital to have UNIQUE topology identifiers."; 654 } 655 leaf tunnel-type { 656 type identityref { 657 base tunnel-type; 658 } 659 description 660 "Tunnel type based on constructing technologies and 661 multipoint types, including P2P-TE, P2MP-TE, SR-TE, 662 SR P2P, LDP P2P, LDP MP2MP, GRE, PBB, etc"; 663 } 664 leaf source { 665 type inet:ip-address; 666 description 667 "For a p2p or p2mp tunnel, this is the source address; 668 for a mp2mp tunnel, this is the root address."; 669 reference "RFC3209, RFC4875, RFC6388, RFC7582."; 670 } 671 leaf destination { 672 type inet:ip-address; 673 description 674 "For a p2p tunnel, this is the tunnel endpoint address 675 extracted from SESSION object; 676 for a p2mp tunnel, this identifies the destination 677 group, or p2mp-id; 678 for a mp2mp tunnel identified by root and opaque-value, 679 this value is set to '0.0.0.0'."; 680 reference "RFC3209, RFC4875, RFC6388, RFC7582."; 681 } 682 leaf tunnel-id { 683 type binary; 684 description 685 "For a p2p or p2mp tunnel, this is the tunnel identifier 686 used in the SESSION that remains constant over the life 687 of the tunnel; 688 for a mp2mp tunnel, this is the opaque-value in the 689 FEC element."; 690 reference "RFC3209, RFC4875, RFC6388, RFC7582."; 691 } 692 container encapsulation { 693 description 694 "The encapsulation information used by the tunnel."; 695 leaf type { 696 type identityref { 697 base service-encapsulation-type; 698 } 699 description 700 "The encapsulation type used by the tunnel."; 701 } 702 leaf value { 703 type binary; 704 description 705 "The encapsulation value pushed to the tunnel data to 706 identify the traffic in this tunnel. 707 If not specified, the system decides what 708 value to be used."; 709 } 710 } 711 } 712 } 713 } 714 } 715 717 7. IANA Considerations 719 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 720 actual RFC number (and remove this note). 722 This document registers the following namespace URIs in the IETF XML 723 registry [RFC3688]: 725 -------------------------------------------------------------------- 726 URI: urn:ietf:params:xml:ns:yang:ietf-tunnel-steering 727 Registrant Contact: The IESG. 728 XML: N/A, the requested URI is an XML namespace. 729 -------------------------------------------------------------------- 731 This document registers the following YANG modules in the YANG Module 732 Names registry [RFC7950]: 734 -------------------------------------------------------------------- 735 name: ietf-tunnel-steering 736 namespace: urn:ietf:params:xml:ns:yang:ietf-tunnel-steering 737 prefix: tnl-steer 738 reference: RFC XXXX 739 -------------------------------------------------------------------- 741 8. Security Considerations 743 The YANG module specified in this document defines a schema for data 744 that is designed to be accessed via network management protocols such 745 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 746 is the secure transport layer, and the mandatory-to-implement secure 747 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 748 is HTTPS, and the mandatory-to-implement secure transport is TLS 749 [RFC5246]. 751 The NETCONF access control model [RFC6536] provides the means to 752 restrict access for particular NETCONF or RESTCONF users to a 753 preconfigured subset of all available NETCONF or RESTCONF protocol 754 operations and content. 756 There are a number of data nodes defined in this YANG module that are 757 writable/creatable/deletable (i.e., config true, which is the 758 default). These data nodes may be considered sensitive or vulnerable 759 in some network environments. Write operations (e.g., edit-config) 760 to these data nodes without proper protection can have a negative 761 effect on network operations. These are the subtrees and data nodes 762 and their sensitivity/vulnerability: 764 /tunnel-pools/tunnel-pool 765 This subtree specifies a list of tunnel pools. Modifying the 766 configurations cause interruption to related services and tunnels. 768 Some of the readable data nodes in this YANG module may be considered 769 sensitive or vulnerable in some network environments. It is thus 770 important to control read access (e.g., via get, get-config, or 771 notification) to these data nodes. These are the subtrees and data 772 nodes and their sensitivity/vulnerability: 774 /tunnel-pools/tunnel-pool 775 Unauthorized access to this subtree can disclose the information 776 of related services and tunnels. 778 9. References 780 9.1. Normative References 782 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 783 Requirement Levels", BCP 14, RFC 2119, 784 DOI 10.17487/RFC2119, March 1997, 785 . 787 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 788 (TLS) Protocol Version 1.2", RFC 5246, 789 DOI 10.17487/RFC5246, August 2008, 790 . 792 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 793 and A. Bierman, Ed., "Network Configuration Protocol 794 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 795 . 797 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 798 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 799 . 801 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 802 Protocol (NETCONF) Access Control Model", RFC 6536, 803 DOI 10.17487/RFC6536, March 2012, 804 . 806 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 807 RFC 6991, DOI 10.17487/RFC6991, July 2013, 808 . 810 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 811 RFC 7950, DOI 10.17487/RFC7950, August 2016, 812 . 814 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 815 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 816 . 818 [I-D.ietf-teas-yang-te-topo] 819 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 820 O. Dios, "YANG Data Model for Traffic Engineering (TE) 821 Topologies", draft-ietf-teas-yang-te-topo-19 (work in 822 progress), February 2019. 824 [I-D.ietf-teas-yang-te] 825 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 826 "A YANG Data Model for Traffic Engineering Tunnels and 827 Interfaces", draft-ietf-teas-yang-te-19 (work in 828 progress), February 2019. 830 9.2. Informative References 832 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 833 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 834 . 836 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 837 and R. Wilton, "Network Management Datastore Architecture 838 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 839 . 841 Authors' Addresses 843 Igor Bryskin 844 Huawei Technologies 846 EMail: Igor.Bryskin@huawei.com 848 Vishnu Pavan Beeram 849 Juniper Networks 851 EMail: vbeeram@juniper.net 853 Tarek Saad 854 Cisco Systems Inc 856 EMail: tsaad@cisco.com 857 Xufeng Liu 858 Volta Networks 860 EMail: xufeng.liu.ietf@gmail.com 862 Young Lee 863 Huawei Technologies 865 EMail: leeyoung@huawei.com