idnits 2.17.1 draft-bryskin-teas-service-tunnel-steering-model-04.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 321 has weird spacing: '...n-point str...' -- The document date (January 12, 2020) is 1566 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-22 Summary: 0 errors (**), 0 flaws (~~), 3 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 Individual 4 Intended status: Informational V. Beeram 5 Expires: July 15, 2020 T. Saad 6 Juniper Networks 7 X. Liu 8 Volta Networks 9 Y. Lee 10 Sung Kyun Kwan University 11 A. Guo 12 Futurewei 13 January 12, 2020 15 Basic YANG Model for Steering Client Services To Server Tunnels 16 draft-bryskin-teas-service-tunnel-steering-model-04 18 Abstract 20 This document describes a YANG data model for managing pools of 21 transport tunnels and steering client services on them. 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 July 15, 2020. 40 Copyright Notice 42 Copyright (c) 2020 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 60 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 61 2. Explicit vs. Implicit Service2tunnel Mapping. Steering 62 Services to Transport Tunnel Pools . . . . . . . . . . . . . 5 63 3. The purpose of the model . . . . . . . . . . . . . . . . . . 5 64 4. Model Design . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Tree Structure . . . . . . . . . . . . . . . . . . . . . . . 7 66 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 71 9.2. Informative References . . . . . . . . . . . . . . . . . 19 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 74 1. Introduction 76 Client layer services/signals are normally mapped onto carrying them 77 across the network transport tunnels via client/server layer 78 adaptation relationships. Such relationships are usually modeled as 79 multi-layer topologies, whereas tunnels set up in underlay (server) 80 topologies support links in respective overlay (client) topologies. 81 In this respect having a link in a client topology means that the 82 client layer traffic could be forwarded between link termination 83 points (LTPs) terminating the link on opposite sides by the 84 supporting tunnel(s) provisioned in the server layer topology. 86 This said there are numerous use cases in which describing the client 87 service to server tunnel bindings via the topology formalism is 88 impractical. Below are some examples of such use cases: 90 o Mapping client services onto tunnels within the same network 91 layer, for example, mapping L3 VPNs or MPLS-SR services onto IP 92 MPLS tunnels; 94 o Mapping client services onto tunnels provisioned in the highest 95 layer topology supported by the network. For example, mapping 96 L2VPNs or E(V)PL services onto IP MPLS tunnels provisioned in an 97 IP network; 99 o Mapping client services to tunnels provisioned in separate network 100 layers at the network's access points. Consider, for example, an 101 OTN/ODUk network that is used to carry client signals of, say, 20 102 different types (e.g. Ethernet, SDH, FKON, etc.) entering and 103 exiting the network over client facing interfaces. Although it is 104 possible to describe such a network as a 21-layer TE topology with 105 the OTN/ODUk topology serving each of the 20 client layer 106 topologies [I-D.ietf-teas-yang-te-topo], such a description would 107 be verbose, cumbersome, difficult to expand to accommodate 108 additional client signals and unnecessary, because the client 109 layer topologies would have zero switching flexibility inside the 110 network (i.e. contain only unrelated links connecting access 111 points across respective layer networks), and all what is required 112 to know from the point of view of a management application is what 113 ODUk tunnels are established or required, which client signals the 114 tunnels could carry and at which network border nodes and how the 115 client signals could be bound (i.e. adopted) to the tunnels. 117 It is worth noting that such non-topological client-service-to- 118 server-tunnel mapping almost always happens on network border nodes. 119 However, there are also important use cases where such a mapping is 120 required in the middle of the network. One such use case is 121 controlling on IP/MPLS FRR PLRs which LSPs are mapped onto which 122 backup tunnels. 124 It is important to bear in mind that service2tunnel mappings could be 125 very complex: large number of instances of services of the same or 126 different types (possibly governed by different models) could be 127 mapped on the same set of tunnels, with the latter being set in 128 different network layers and of either TE or non-TE nature, P2P or 129 P2MP or MP2MP type. Furthermore, the mappings could be hierarchical: 130 tunnels carrying services could be clients of other tunnels. 132 Despite of the differences of transport tunnels and of services they 133 carry the srvice2tunnel mappings could be modeled in a simple uniform 134 way. Access to a data store of such mappings could be beneficial to 135 network management applications. It would be possible, for example, 136 to discover which services depend on which tunnels, which services 137 will be affected if a given tunnel goes out of service, how many more 138 services could be placed onto a given TE tunnel without the latter 139 violating its TE commitments (such as bandwidth and delay). It would 140 be also possible to demand in a single request moving numerous 141 (ranges of) service instances from one set of tunnels to another. 143 This document defines a YANG data model for facilitating said 144 xervice2tunnel mappings. 146 The YANG model in this document conforms to the Network Management 147 Datastore Architecture (NMDA) [RFC8342]. 149 1.1. Terminology 151 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14, [RFC2119]. 156 The following terms are defined in [RFC7950] and are not redefined 157 here: 159 o augment 161 o data model 163 o data node 165 1.2. Tree Diagrams 167 A simplified graphical representation of the data model is presented 168 in this document, by using the tree format defined in [RFC8340]. 170 1.3. Prefixes in Data Node Names 172 In this document, names of data nodes, actions, and other data model 173 objects are often used without a prefix, as long as it is clear from 174 the context in which YANG module each name is defined. Otherwise, 175 names are prefixed using the standard prefix associated with the 176 corresponding YANG module, as shown in Table 1. 178 +----------+-----------------+-------------------------+ 179 | Prefix | YANG module | Reference | 180 +----------+-----------------+-------------------------+ 181 | inet | ietf-inet-types | [RFC6991] | 182 | te-types | ietf-te-types | [I-D.ietf-teas-yang-te] | 183 +----------+-----------------+-------------------------+ 185 Table 1: Prefixes and Corresponding YANG Modules 187 2. Explicit vs. Implicit Service2tunnel Mapping. Steering Services to 188 Transport Tunnel Pools 190 There are use cases in which client services require hard separation 191 of the transport carrying them from the transport carrying other 192 services. However, environment in which the services may share the 193 same transport tunnels is far more common. For this reason the model 194 defined in this document suggests replacing (or at least augmenting) 195 the explicit service2tunnel mapping configuration (in which the 196 tunnels are referred to by their IDs/names) with an implicit mapping. 197 Specifically, the model introduces the notion of tunnel pool. A 198 tunnel pool could be referred to by its network unique color and 199 requires a service2tunnel mapping configuration to specify the tunnel 200 pool color(s) instead of tunnel IDs/names. The model governs tunnel 201 pool data store independently from the services steered on the 202 tunnels. It is assumed (although not required) that the tunnels - 203 constituents/components of a tunnel pool - are of the same type, 204 provisioned using a common template. Importantly they could be 205 dynamically added to/removed from the pool without necessitating 206 service2tunnel mapping re-configuration. Such a service to tunnel 207 pool steering approach has the following advantages: 209 o Scalability and efficiency: pool component bandwidth utilization 210 could be monitored, tunnels could be added to/removed from the 211 pool if/when detected that current component bandwidth utilization 212 has crossed certain thresholds. This allows for a very efficient 213 network resource utilization and obviates the network management 214 application from a very difficult task of service to tunnel 215 mapping planning; 217 o Automation and elasticity: pool component attributes could be 218 modified - bandwidth auto-adjusted, protection added, delay 219 constrained, etc.. The tunnels could be completely or partially 220 replaced with tunnels of different types (e.g. TE vs. non-TE, P2P 221 vs. P2MP, etc.) or even provisioned in different network layers 222 (OTN/ODUk tunnels replacing IP TE tunnels). Importantly, all such 223 modifications do not require service2tunell mapping re- 224 configurations as long as the modified or new tunnels remain 225 within the same tunnel pool(s); 227 o Transparency: new service sites supported by additional PEs could 228 be added without service2tunnel mapping re-configuration. 230 3. The purpose of the model 232 The model is targeted to facilitate for network management 233 applications, such as service orchestrators, the control of pools of 234 transport tunnels and steering onto them client services 235 independently of network technology/layer specifics of both the 236 services and the tunnels. The model could be applied to/implemented 237 on physical devices, such as IP routers, as well as on abstract 238 topology nodes. Furthermore, the model could be supported by a 239 network (domain) controller, such as ACTN PNC, to act as a proxy 240 server on behalf of any network element/node (physical or abstract) 241 under its control. 243 4. Model Design 245 The data store described/governed by the model is comprised of a 246 single top level list - TunnelPools. A TunnelPool, list element, is 247 a container describing a set of transport tunnels (presumably with 248 similar characteristics) identified by a network unique ID (color). 249 A given TunnelPool could be generic to the entire network or specific 250 to a particular netwrok slice or network abstract topology. 251 Furthermore, a TunnelPool may have no tunnels (i.e. may have empty 252 Tunnels list). Service steered onto such a TunnelPool will be 253 carried by best effort forwarding technique and flexibility available 254 in the slice/topology the TunnelPool is assigned to or generally in 255 the network 257 The TunnelPool container has the following fields: 259 o Color [uint32 list key]; 261 o Slice/Abstract topology ID (if zero, the TunnelPool is generic to 262 the network). 264 o Tunnels list; 266 o Services list. 268 The Tunnels list describes the pool constituents - active transport 269 tunnels. The list members - Tunnel containers - include the 270 following information: 272 o tunnel type [e.g. P2P-TE, P2MP-TE, SR-TE, SR P2P, LDP P2P, LDP 273 MP2MP, GRE, PBB, etc] 275 o tunnel type specific tunnel ID [provided that a data store of the 276 tunnel type, e.g. TE tunnels, is supported, the tunnelID allows 277 for the management application to look up the tunnel in question 278 to obtain detailed information about the tunnel]; 280 o tunnel encapsulation [e.g. MPLS label stack, Ethernet STAGs, GRE 281 header, PBB header, etc]. 283 The Services list describes services currently steered on the tunnel 284 pool. The list members - Service containers - have the following 285 attributes: 287 o service type [e.g. fixed/transparent, L3VPN, L2VPN, EVPN, ELINE, 288 EPL, EVPL, L1VPN, ACTN VN, etc.]; 290 o service type specific service ID [provided that a data store of 291 the service type, e.g. L2VPN, is supported, the service ID allows 292 for the management application to look up the service in question 293 to obtain detailed information about the service]; 295 o client ports (source/destination node LTPs over which the service 296 enters/exits the node/network, relevant only for fixed/transparent 297 services); 299 o service encapsulation [e.g. MPLS label stack, Ethernet CTAGs, 300 etc.] - for service multiplexing/de-multiplexing on/from a 301 statistically shared tunnel]. 303 5. Tree Structure 304 module: ietf-tunnel-steering 305 +--rw tunnel-pools 306 +--rw tunnel-pool* [color] 307 +--rw color uint32 308 +--rw description? string 309 +--rw te-topology-identifier 310 | +--rw provider-id? te-types:te-global-id 311 | +--rw client-id? te-types:te-global-id 312 | +--rw topology-id? te-types:te-topology-id 313 +--rw service* [service-type id] 314 | +--rw service-type identityref 315 | +--rw id string 316 | +--rw encapsulation 317 | | +--rw type? identityref 318 | | +--rw value? binary 319 | +--rw access-point* [node-address link-termination-point] 320 | +--rw node-address inet:ip-address 321 | +--rw link-termination-point string 322 | +--rw direction? enumeration 323 +--rw tunnel* [tunnel-type source destination tunnel-id] 324 +--rw tunnel-type identityref 325 +--rw source inet:ip-address 326 +--rw destination inet:ip-address 327 +--rw tunnel-id binary 328 +--rw encapsulation 329 +--rw type? identityref 330 +--rw value? binary 332 6. YANG Modules 334 file "ietf-tunnel-steering@2020-01-05.yang" 335 module ietf-tunnel-steering { 336 yang-version 1; 337 namespace "urn:ietf:params:xml:ns:yang:ietf-tunnel-steering"; 339 prefix "tnl-steer"; 341 import ietf-inet-types { 342 prefix inet; 343 } 345 import ietf-te-types { 346 prefix "te-types"; 347 } 348 organization 349 "IETF Traffic Engineering Architecture and Signaling (TEAS) 350 Working Group"; 352 contact 353 "WG Web: 354 WG List: 356 Editors: Igor Bryskin 357 359 Editor: Vishnu Pavan Beeram 360 362 Editor: Tarek Saad 363 365 Editor: Xufeng Liu 366 368 Editor: Young Lee 369 "; 371 description 372 "This data model is for steering client service to server 373 tunnels. 375 Copyright (c) 2020 IETF Trust and the persons identified as 376 authors of the code. All rights reserved. 378 Redistribution and use in source and binary forms, with or 379 without modification, is permitted pursuant to, and subject to 380 the license terms contained in, the Simplified BSD License set 381 forth in Section 4.c of the IETF Trust's Legal Provisions 382 Relating to IETF Documents 383 (http://trustee.ietf.org/license-info). 385 This version of this YANG module is part of RFC XXXX; see the 386 RFC itself for full legal notices."; 388 revision 2020-01-05 { 389 description "Initial revision"; 390 reference "TBD"; 391 } 393 /* 394 * Typedefs 395 */ 397 /* 398 * Identities 399 */ 400 identity service-type { 401 description "Base identity for client service type."; 402 } 403 identity service-type-l3vpn { 404 base service-type; 405 description 406 "L3VPN service."; 407 } 408 identity service-type-l2vpn { 409 base service-type; 410 description 411 "L2VPN service."; 412 } 413 identity service-type-evpn { 414 base service-type; 415 description 416 "EVPN service."; 417 } 418 identity service-type-eline { 419 base service-type; 420 description 421 "ELINE service."; 422 } 423 identity service-type-epl { 424 base service-type; 425 description 426 "EPL service."; 427 } 428 identity service-type-evpl { 429 base service-type; 430 description 431 "EVPL service."; 432 } 433 identity service-type-l1vpn { 434 base service-type; 435 description 436 "L1VPN service."; 437 } 438 identity service-type-actn-vn { 439 base service-type; 440 description 441 "ACTN VN service."; 442 } 443 identity service-type-transparent { 444 base service-type; 445 description 446 "Transparent LAN service."; 447 } 449 identity tunnel-type { 450 description "Base identity for tunnel type."; 451 } 452 identity tunnel-type-te-p2p { 453 base tunnel-type; 454 description 455 "TE point-to-point tunnel type."; 456 } 457 identity tunnel-type-te-p2mp { 458 base tunnel-type; 459 description 460 "TE point-to-multipoint tunnel type."; 461 reference "RFC4875"; 462 } 463 identity tunnel-type-te-sr { 464 base tunnel-type; 465 description 466 "Segment Rouging TE tunnel type."; 467 } 468 identity tunnel-type-sr { 469 base tunnel-type; 470 description 471 "Segment Rouging tunnel type."; 472 } 473 identity tunnel-type-ldp-p2p { 474 base tunnel-type; 475 description 476 "LDP point-to-point tunnel type."; 477 } 478 identity tunnel-type-ldp-mp2mp { 479 base tunnel-type; 480 description 481 "Multicast LDP multipoint-to-multipoint tunnel type."; 482 } 483 identity tunnel-type-gre { 484 base tunnel-type; 485 description 486 "GRE tunnel type."; 487 } 488 identity tunnel-type-pbb { 489 base tunnel-type; 490 description 491 "PBB tunnel type."; 492 } 493 identity service-encapsulation-type { 494 description "Base identity for tunnel encapsulation."; 495 } 496 identity service-encapsulation-type-mpls-label { 497 base service-encapsulation-type; 498 description 499 "Encapsulated by MPLS label stack, as an inner lable to 500 identify the customer service."; 501 } 502 identity service-encapsulation-type-ethernet-c-tag { 503 base service-encapsulation-type; 504 description 505 "Encapsulated by Ethernet C-TAG, to identify the customer 506 service."; 507 } 509 identity tunnel-encapsulation-type { 510 description "Base identity for tunnel encapsulation."; 511 } 512 identity tunnel-encapsulation-type-mpls-label { 513 base tunnel-encapsulation-type; 514 description 515 "Encapsulated by MPLS label stack, as an outer label to 516 be pushed into the tunnel."; 517 } 518 identity tunnel-encapsulation-type-ethernet-s-tag { 519 base tunnel-encapsulation-type; 520 description 521 "Encapsulated by Ethernet S-TAG."; 522 } 523 identity tunnel-encapsulation-type-pbb { 524 base tunnel-encapsulation-type; 525 description 526 "Encapsulated by PBB header."; 527 } 528 identity tunnel-encapsulation-type-gre { 529 base tunnel-encapsulation-type; 530 description 531 "Encapsulated by GRE header."; 532 } 534 /* 535 * Groupings 536 */ 538 /* 539 * Configuration data and operational state data nodes 540 */ 542 container tunnel-pools { 543 description 544 "A list of mappings that steer client services to transport 545 tunnel pools. The tunnel pools are managed independently from 546 the services steered on them."; 548 list tunnel-pool { 549 key "color"; 550 description 551 "A set of transport tunnels (presumably with similar 552 characteristics) identified by a network unique ID, named 553 'color'."; 554 leaf color { 555 type uint32; 556 description 557 "Unique ID of a tunnel pool."; 558 } 559 leaf description { 560 type string; 561 description 562 "Client provided description of the tunnel pool."; 563 } 564 uses te-types:te-topology-identifier; 566 list service { 567 key "service-type id"; 568 description 569 "A list of client services that are steered on this tunnel 570 pool."; 571 leaf service-type { 572 type identityref { 573 base service-type; 574 } 575 description 576 "Service type required by the client."; 577 } 578 leaf id { 579 type string; 580 description 581 "Unique ID of a client service for the specified 582 service type."; 583 } 584 container encapsulation { 585 description 586 "The encapsulation information used to identify the 587 customer service for multiplexing over shared tunnels."; 588 leaf type { 589 type identityref { 590 base service-encapsulation-type; 591 } 592 description 593 "The encapsulation type used to identify the customer 594 service for multiplexing over shared tunnels."; 595 } 596 leaf value { 597 type binary; 598 description 599 "The encapsulation value pushed to the tunnel to 600 identify this service. 601 If not specified, the system decides what 602 value to be used for multiplexing."; 603 } 604 } 605 list access-point { 606 key "node-address link-termination-point"; 607 description 608 "A list of client ports (Link Termination Points) for the 609 service to enter or exist."; 610 leaf node-address { 611 type inet:ip-address; 612 description 613 "Node over which the service enters or exists."; 614 } 615 leaf link-termination-point { 616 type string; 617 description 618 "Client port (Link Termination Point) over which the 619 service enters or exits."; 620 } 621 leaf direction { 622 type enumeration { 623 enum "in" { 624 description "The service enters to the network."; 625 } 626 enum "out" { 627 description "The service exists from the network."; 628 } 629 enum "in-out" { 630 description 631 "The service enters to and exists from the 632 network."; 633 } 634 } 635 description 636 "Whether the service enters to or exits from the 637 network."; 639 } 640 } 641 } 642 list tunnel { 643 key "tunnel-type source destination tunnel-id"; 644 description 645 "A list of tunnels in the tunnel pool."; 647 leaf tunnel-type { 648 type identityref { 649 base tunnel-type; 650 } 651 description 652 "Tunnel type based on constructing technologies and 653 multipoint types, including P2P-TE, P2MP-TE, SR-TE, 654 SR P2P, LDP P2P, LDP MP2MP, GRE, PBB, etc"; 655 } 656 leaf source { 657 type inet:ip-address; 658 description 659 "For a p2p or p2mp tunnel, this is the source address; 660 for a mp2mp tunnel, this is the root address."; 661 reference "RFC3209, RFC4875, RFC6388, RFC7582."; 662 } 663 leaf destination { 664 type inet:ip-address; 665 description 666 "For a p2p tunnel, this is the tunnel endpoint address 667 extracted from SESSION object; 668 for a p2mp tunnel, this identifies the destination 669 group, or p2mp-id; 670 for a mp2mp tunnel identified by root and opaque-value, 671 this value is set to '0.0.0.0'."; 672 reference "RFC3209, RFC4875, RFC6388, RFC7582."; 673 } 674 leaf tunnel-id { 675 type binary; 676 description 677 "For a p2p or p2mp tunnel, this is the tunnel identifier 678 used in the SESSION that remains constant over the life 679 of the tunnel; 680 for a mp2mp tunnel, this is the opaque-value in the 681 FEC element."; 682 reference "RFC3209, RFC4875, RFC6388, RFC7582."; 683 } 684 container encapsulation { 685 description 686 "The encapsulation information used by the tunnel."; 688 leaf type { 689 type identityref { 690 base service-encapsulation-type; 691 } 692 description 693 "The encapsulation type used by the tunnel."; 694 } 695 leaf value { 696 type binary; 697 description 698 "The encapsulation value pushed to the tunnel data to 699 identify the traffic in this tunnel. 700 If not specified, the system decides what 701 value to be used."; 702 } 703 } 704 } 705 } 706 } 707 } 708 710 7. IANA Considerations 712 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 713 actual RFC number (and remove this note). 715 This document registers the following namespace URIs in the IETF XML 716 registry [RFC3688]: 718 -------------------------------------------------------------------- 719 URI: urn:ietf:params:xml:ns:yang:ietf-tunnel-steering 720 Registrant Contact: The IESG. 721 XML: N/A, the requested URI is an XML namespace. 722 -------------------------------------------------------------------- 724 This document registers the following YANG modules in the YANG Module 725 Names registry [RFC7950]: 727 -------------------------------------------------------------------- 728 name: ietf-tunnel-steering 729 namespace: urn:ietf:params:xml:ns:yang:ietf-tunnel-steering 730 prefix: tnl-steer 731 reference: RFC XXXX 732 -------------------------------------------------------------------- 734 8. Security Considerations 736 The YANG module specified in this document defines a schema for data 737 that is designed to be accessed via network management protocols such 738 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 739 is the secure transport layer, and the mandatory-to-implement secure 740 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 741 is HTTPS, and the mandatory-to-implement secure transport is TLS 742 [RFC8446]. 744 The NETCONF access control model [RFC8341] provides the means to 745 restrict access for particular NETCONF or RESTCONF users to a 746 preconfigured subset of all available NETCONF or RESTCONF protocol 747 operations and content. 749 There are a number of data nodes defined in this YANG module that are 750 writable/creatable/deletable (i.e., config true, which is the 751 default). These data nodes may be considered sensitive or vulnerable 752 in some network environments. Write operations (e.g., edit-config) 753 to these data nodes without proper protection can have a negative 754 effect on network operations. These are the subtrees and data nodes 755 and their sensitivity/vulnerability: 757 /tunnel-pools/tunnel-pool 758 This subtree specifies a list of tunnel pools. Modifying the 759 configurations cause interruption to related services and tunnels. 761 Some of the readable data nodes in this YANG module may be considered 762 sensitive or vulnerable in some network environments. It is thus 763 important to control read access (e.g., via get, get-config, or 764 notification) to these data nodes. These are the subtrees and data 765 nodes and their sensitivity/vulnerability: 767 /tunnel-pools/tunnel-pool 768 Unauthorized access to this subtree can disclose the information 769 of related services and tunnels. 771 9. References 773 9.1. Normative References 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", BCP 14, RFC 2119, 777 DOI 10.17487/RFC2119, March 1997, 778 . 780 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 781 DOI 10.17487/RFC3688, January 2004, 782 . 784 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 785 and A. Bierman, Ed., "Network Configuration Protocol 786 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 787 . 789 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 790 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 791 . 793 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 794 RFC 6991, DOI 10.17487/RFC6991, July 2013, 795 . 797 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 798 RFC 7950, DOI 10.17487/RFC7950, August 2016, 799 . 801 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 802 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 803 . 805 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 806 Access Control Model", STD 91, RFC 8341, 807 DOI 10.17487/RFC8341, March 2018, 808 . 810 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 811 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 812 . 814 [I-D.ietf-teas-yang-te-topo] 815 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 816 O. Dios, "YANG Data Model for Traffic Engineering (TE) 817 Topologies", draft-ietf-teas-yang-te-topo-22 (work in 818 progress), June 2019. 820 [I-D.ietf-teas-yang-te] 821 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 822 "A YANG Data Model for Traffic Engineering Tunnels and 823 Interfaces", draft-ietf-teas-yang-te-22 (work in 824 progress), November 2019. 826 9.2. Informative References 828 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 829 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 830 . 832 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 833 and R. Wilton, "Network Management Datastore Architecture 834 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 835 . 837 Authors' Addresses 839 Igor Bryskin 840 Individual 842 EMail: i_bryskin@yahoo.com 844 Vishnu Pavan Beeram 845 Juniper Networks 847 EMail: vbeeram@juniper.net 849 Tarek Saad 850 Juniper Networks 852 EMail: tsaad@juniper.net 854 Xufeng Liu 855 Volta Networks 857 EMail: xufeng.liu.ietf@gmail.com 859 Young Lee 860 Sung Kyun Kwan University 862 EMail: younglee.tx@gmail.com 864 Aihua Guo 865 Futurewei 867 EMail: aihuaguo@futurewei.com