idnits 2.17.1 draft-wood-rtgwg-sdwan-ose-yang-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 513 has weird spacing: '...ss-name str...' == Line 1217 has weird spacing: '... on the path ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 29, 2019) is 1756 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4364' is defined on line 1338, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTWG Working Group S. Wood, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track B. Wu, Ed. 5 Expires: December 31, 2019 Q. Wu, Ed. 6 Huawei 7 C. Menezes 8 HPE Aruba 9 June 29, 2019 11 YANG Data Model for SD-WAN OSE service delivery 12 draft-wood-rtgwg-sdwan-ose-yang-01 14 Abstract 16 This document defines two SD-WAN OSE Open SD-WAN Exchange(OSE) 17 service YANG modules to enable the orchestrator in the enterprise 18 network to implement SD-WAN inter-domain reachability and 19 connectivity services and application aware traffic steering 20 services. 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 December 31, 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 . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. The SD-WAN OSE Service Model Requirements . . . . . . . . . . 5 62 4.1. Reachability & Route Exchange Requirements . . . . . . . 5 63 4.2. Network Segmentation Requirements . . . . . . . . . . . . 5 64 4.3. Path Management Requirements . . . . . . . . . . . . . . 6 65 5. Service Model Usage . . . . . . . . . . . . . . . . . . . . . 6 66 6. Design of the Data Model . . . . . . . . . . . . . . . . . . 8 67 6.1. OSE Gateway Service Model . . . . . . . . . . . . . . . . 8 68 6.2. OSE Path Service Model . . . . . . . . . . . . . . . . . 10 69 7. SD-WAN OSE Gateway Service YANG Module . . . . . . . . . . . 13 70 8. SD-WAN OSE Path Service YANG Module . . . . . . . . . . . . . 17 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 75 11.2. Informative References . . . . . . . . . . . . . . . . . 29 76 Appendix A. Acknowledges . . . . . . . . . . . . . . . . . . . . 30 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 79 1. Introduction 81 Software-Defined WAN networking (SDWAN) has become a major new 82 technology in Wide Area Networking. SDWAN architecture is a 83 combination of data and control plane orchestration, proprietary 84 control-plane enhancements as well as single-hop, CE-CE data-planes 85 often referred to as "fabrics". On top of this infrastructure, 86 centralized network policy administration and distribution is 87 provided to achieve a specific set of network outcomes or use-cases. 89 As a result of the use-case driven approach, SDWAN technology 90 solutions often encode choices about data-plane and protocol 91 operation into associated data-plane, control-plane and controller 92 subsystems. These choices are intended to simplify deployment of 93 SDWAN use-cases, but often result in systems that are not compatible 94 and network elements that cannot interoperate in the manner of 95 traditional, standards-based IP networks. 97 The Open SD-WAN Exchange (OSE) is an open framework to allow for one 98 vendor SD-WAN domain to communicate with another vendor SD-WAN 99 domain. The goal is to enable interworking between different SDWAN 100 domains via the definition of standard service behaviours as well as 101 standard data models to define those services. The underlying 102 service implementation in each domain is only relevant in that it 103 meets the specified service definition. To create OSE SD-WAN 104 services across domain, a higher layer orchestrator may use generic 105 API calls based on the service models to create the desired SDWAN 106 services within each domain via the serving SDWAN manager. 108 The services currently defined by specification [OSE] include: 110 o OSE Gateway Reachability services 112 o Application Path Management Services 114 This document defines two SD-WAN service YANG modules to enable the 115 orchestrator in the enterprise network to implement SD-WAN inter- 116 domain reachability and connectivity services and application aware 117 traffic steering services. The SD-WAN OSE Service Model is for 118 enterprise own network. 120 1.1. Terminology 122 The following terms are defined in [RFC6241] and are not redefined 123 here: 125 o client 127 o server 129 o configuration data 131 o state data 133 The following terms are defined in [RFC7950] and are not redefined 134 here: 136 o augment 138 o data model 140 o data node 142 The terminology for describing YANG data models is found in 143 [RFC7950]. 145 1.2. Tree diagram 147 Tree diagrams used in this document follow the notation defined in 148 [RFC8340]. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC2119 [RFC2119]. 156 3. Definitions 158 This document uses the following terms: 160 Service Provider (SP): The organization (usually a commercial 161 undertaking) responsible for operating the network that offers VPN 162 services to clients and customers. 164 Customer Edge (CE) Device: Equipment that is dedicated to a 165 particular customer and is directly connected to one or more PE 166 devices via attachment circuits. A CE is usually located at the 167 customer premises, and is usually dedicated to a single VPN, 168 although it may support multiple VPNs if each one has separate 169 attachment circuits. The CE devices can be routers, bridges, 170 switches or hosts. 172 Provider Edge (PE) Device: Equipment managed by the SP that can 173 support multiple VPNs for different customers, and is directly 174 connected to one or more CE devices via attachment circuits. A PE 175 is usually located at an SP Point of Presence (PoP) and is managed 176 by the SP. 178 SDWAN Manager: SDWAN Manager is the domain specific manager and 179 controller required to configure, manage and control a particular 180 SDWAN domain. To create OSE SDWAN services, a higher layer 181 orchestrator may use OSE defined API calls to create the desired 182 SDWAN services within each domain via the serving SDWAN manager. 184 Client Orchestration: The Client Orchestration layer is an 185 abstraction of a service level orchestrator or software that 186 implements control the the SDWAN through the defined OSE APIs. 187 The OSE service specifications do not specify the functions and 188 procedures within this entity apart from the fact that it would 189 use the OSE APIs. The client orchestration layer is a functional 190 block which would implement OSE API calls to one or more serving 191 SDWAN managers. 193 SD-WAN controller: The SD-WAN Controller is a reference block that 194 encompasses the network control-plane functions required to 195 operate the SDWAN network. The SD-WAN network controller delivers 196 control-plane/data-plane separation the is the realization of SDN 197 architecture within the SD-WAN usecase. Each SD-WAN network 198 controller is managed and configured by the SD-WAN manager. The 199 interface between SDWAN network controller and SD-WAN network 200 manager for this purpose is currently outside the scope of the 201 document. 203 4. The SD-WAN OSE Service Model Requirements 205 This section provides a common definition for service types required 206 across different SD-WAN vendor domains. The Open SD-WAN Exchange 207 (OSE) model focuses on interoperability between domains, rather than 208 specifying standard protocol and operations with each SD-WAN domain. 210 The OSE interoperability models focus on the definition of a standard 211 set of service models and parameters that can be implemented in an 212 SDWAN management system to configure interoperable services within an 213 SDWAN domain and between SDWAN domains. 215 4.1. Reachability & Route Exchange Requirements 217 In [OSE]SD-WAN reference model, it is assumed that communication 218 between sites in different domains happening via the OSE gateway 219 which suggests that traffic spanning the domains will be backhauled 220 to the OSE gateway. The interfaces between the gateways are called 221 NNI interfaces. The interconnection between OSE gateways includes 222 the following: 224 o OSE gateway interconnection: There may be multiple links between 225 OSE gateways. To mitigate the constraints of the underlying 226 network between the OSE gateway, an IP overlay tunnel needs to be 227 established, and provide simple configuration and operation. It 228 is assumed that GRE and IKE based IPsec can be used. 230 o Route exchange: Provides L3 reachability information exchange to 231 facilitate L3 connectivity between SD-WAN domains. 233 4.2. Network Segmentation Requirements 235 In addition to the basic connection, the inter-domain interconnection 236 needs to ensure the interworking of network segments. Network 237 segmentation divides an enterprise network into different traffic or 238 routing contexts to provide clear separation of traffic of each 239 segment. These are often referred to as Virtual networks. The most 240 common technology of network segmentation are virtual LANs, or VLANs, 241 for Layer 2 implementation, and virtual routing and forwarding, or 242 VRF, for Layer 3 implementation. For traffic flowing across SD-WAN 243 domains boundaries, segmentation must be preserved. A method of 244 configuration is required to ensure per segment traffic flow 245 separation while passing through SD-WAN domain boundaries. Such use 246 case is also described in Augmenting RFC4364 Technology to Provide 247 Secure Layer L3VPNs over Public Infrastructure 248 [I-D.rosen-bess-secure-l3vpn]. Therefore, as specified in BGP/MPLS 249 IP VPN [RFC4364]for Multi-AS use cases, it is assumed that MP-BGP 250 with Option B is preferred due to its ease for provisioning, 251 segmentation and operations. For some cases when Option B is not 252 available, separate instances of BGP to be configured on a per VRF 253 basis, which is Option A. This may require more involvement from the 254 provisioning systems. 256 4.3. Path Management Requirements 258 As specified in ONUG SD-WAN whitepaper[ONUG], dynamic path selection 259 is one of the core features of the SD-WAN, which site-to-site packets 260 can be distributed across multiple WAN connections in real-time, 261 based on current link metrics such as delay, loss and jitter. In 262 this model, a path is considered to be an access network and not a 263 path within an access network, although the latter is not precluded. 264 For business critical applications traversing SD-WAN domains, 265 policies via standardized APIs need to be provisioned to guarantee 266 end-to-end SLA requirements and each domain is responsible for 267 implementing consistent policy enforcement behaviour. Since inter- 268 domain traffic are all backhauled by the OSE gateways, each part of 269 the traversing path needs to be consistent. 271 Note: A method needs to be specified for budgeting end-to-end delay 272 across multiple domains - delay/loss/jitter needs to be shared so 273 that each domain can compute the total path, determine who's 274 violating and then execute path change. 276 5. Service Model Usage 277 +-------------------------------------+ 278 | Client Orchestration | 279 +-------------------------------------+ 280 | | 281 ose-path-svc | ose-reachability-svc | 282 Model | Model | 283 | | 284 +----------------+ +----------------+ 285 | SDWAN manager | | SDWAN manager | 286 +----------------+ +-------+--------+ 287 | | 288 | NETCONF/CLI ... | 289 | | 290 +-------------------------+ +------+-------------------+ 291 | SDWAN Domin #1 | | SDWAN Domin #2 | 292 | | | | 293 |++++++++ +++++++++++++ | NNI | +++++++++++++ ++++++++ | 294 |+Branch+--+OSE Gateway+--+------------+-+OSE Gateway+---+Branch+ | 295 |++++++++ +++++++++++++ | | +++++++++++++ ++++++++ | 296 | | | | 297 |Site A | | Site B | 298 +-------------------------+ +--------------------------+ 300 Figure 1 302 As shown in figure 1, communication between branch sites sitting in 303 domain#1 and domain#2 happens via a border element referred to as the 304 OSE Gateway. This border element interworks the SDWAN control and 305 data plane of the SDWAN domain to a common, defined NNI carrying 306 routing information to establish reachability between domains. It 307 also carries segmentation identifiers that are mutually agreed and 308 configured within each OSE gateway by the domain serving SDWAN 309 manager. The serving SDWAN manager in each respective domain is 310 configured by the operator with information about which segments in 311 each domain are to be connected. 313 Segment connections must be 1:1 across each OSE gateway. 315 Note: The detailed control and data plane specifications for the OSE 316 Gateway NNI will refer to the definition of the relevant SD-WAN 317 protocols in the IETF. 319 The ONUG SD-WAN service YANG model provides an abstracted interface 320 to configure, and manage the components of an SD-WAN service. The 321 components of the SD-WAN service include the OSE Gateway Service 322 component and the Path Management Service component. OSE gateway 323 service component defines Reachability and Route Exchange 324 Segmentation requirements for OSE Gateway devices while path 325 management service component defines path management policy for 326 domain serving SD-WAN managers. 328 A typical usage for this model is to generate Restconf[RFC8040] API 329 used between Client Orchestraton layer and SDWAN manager and used by 330 an enterprise operator to provision the inter-domain services. 331 Before configuring the inter-domain path management policy service, 332 the ose-reachability-svc model is used for the following 333 configuration: 335 o Create one or more OSE gateways in the serving domain. 337 o Create underlying connections between the OSE gateway and other 338 SD-WAN domain gateways, including control plane and data plane. 340 o Create overlay tunnels between the OSE gateway and other SD-WAN 341 domain gateways with Tunnel setup parameters, such as IPsec Tunnel 342 related authentication and encryption parameters. 344 o Create segment mappings between the OSE gateway and other SD-WAN 345 domain gateways with segment related parameters, such as VLAN ID 346 or VRF ID. 348 For the configuration of network elements may be done using NETCONF 349 [RFC6241] or any other configuration (or "southbound") interface such 350 as Command Line Interface (CLI) in combination with device-specific 351 and protocol-specific YANG data models. 353 The usage of this service model is not limited to this example: it 354 can be used by any component of the management system but not 355 directly by network elements. 357 6. Design of the Data Model 359 The SD-WAN OSE service model currently has two YANG modules. 361 6.1. OSE Gateway Service Model 363 The aim of OSE Gateway module is to define parameters for connection 364 setup between SD-WAN domains. As specified by RFC4364, this model 365 defines Option A and Option B to interconnect the different domain. 366 The option B allows one to minimize configuration inputs and allows 367 the solution to scale really high because only the BGP RIBs store all 368 the inter-AS / inter-SD-WAN VPN routes. MP-BGP can run a single 369 label stack within the GRE tunnel, between the NNI nodes such that 370 the MPLS label will be used for traffic segmentation. In the cases, 371 where L3VPN Inter-AS Option B is not supported, revert to MP-BGP 372 based Inter-AS VPN Option A while using MPLS labels. The option A 373 requires Orchestration layer to signal underlying SD-WAN domains to 374 configure and instantiate VRF instances per tenant, as well as MP-BGP 375 based L3VPN configuration and instantiation per tenant. This option 376 can still run on GRE or IPSec tunnels while providing isolation from 377 underlay changes and dependencies and MPLS label within the GRE 378 tunnel will provide per tenant service level separation. 380 o ose-gateway: Gateway name and Gateway ID are specified for each 381 domain. 383 o tunnel: describes encap-type in the interconnection points, and 384 authentication and encryption are also specified to secure the 385 interconnection between SD-WAN domains. 387 o ose-interworking-option: MP-BGP based L3VPN Inter-AS Option B with 388 MPLS labels and Inter-AS Option A are defined. 390 o ose-gateway control plane peering:Control Plane peering between 391 SD-WAN Edge Nodes which exchanges routes and additional 392 reachability information as well as forward transit traffic. For 393 good HA and resiliency characteristics, it is recommended to 394 establish control plane sessions between each node. 396 o segment: to guarantee end to end secure traffic, the segment 397 traffic from a specific domain needs to cross connect to the 398 target segment through an OSE gateway. 400 The complete data hierarchy is presented as follows: 402 module: ietf-ose-gateway-svc 403 +--rw ose-gateways 404 +--rw ose-gateway* [gw-id] 405 +--rw gw-id uint32 406 +--rw gw-name? string 407 +--rw peer-list* [name] 408 | +--rw name string 409 | +--rw peer-gw-id? uint32 410 | +--rw peer-gw-name? string 411 | +--rw ose-interworking-option? enumeration 412 | +--rw encap-type? enumeration 413 | +--rw auth-type? enumeration 414 | +--rw crypto-option? enumeration 415 +--rw segment-list* [segment-name] 416 +--rw segment-name string 417 +--rw vlan-id? uint16 {ose-option-a}? 418 +--rw vrf-id? uint16 {ose-option-b}? 419 +--rw segment-type? enumeration 420 +--rw crossconnects* [ccname] 421 +--rw ccname string 422 +--rw gateway-reference? 423 | -> ../../../peer-list/peer-gw-id 424 +--rw peer-seg-name? string 425 +--rw peer-seg-id-vlan? uint16 {ose-option-a}? 426 +--rw peer-seg-id-vrf? uint16 {ose-option-b}? 428 6.2. OSE Path Service Model 430 Path management module defines automatic path selection policy for 431 traffic across the domain. Policy control will take shape in the 432 form of an ordered list. Each item in the list will be evaluated to 433 match the traffic classifier. The first match will result in 434 processing the matched traffic according to the associated link & 435 path policy. In turn, the link & path policy will be framed in the 436 context of the Performance SLA associated to the links and paths. 438 +------------------+ +------------------+ +------------------+ 439 | | \| Link & Path |/ | Link&Path | 440 |Traffic Classifier+----+ Policy +------+ Performance | 441 | | /| |\ | SLAs | 442 +------------------+ +------------------+ +------------------+ 444 figure 2 446 Traffic classification rules are handled by the "traffic-class" 447 container. The traffic-classification-policy container is an ordered 448 list of rules that match a flow or application and set the 449 appropriate business-priority and make link or path selection.This 450 business priority can be factored into the path selection decision. 452 The client orchestrator can define the match using an application 453 reference or a flow definition that is more specific (e.g., based on 454 Layer 3 source and destination addresses, Layer 4 ports, and Layer 4 455 protocol). 457 The link or path selection is defined as a list of services 458 properties. Describes the policy for how links should be selected 459 for the specified traffic flow. The properties are as follows: 461 o mode: Describes the policy for how links should be selected for 462 the specified traffic flow. Values are: 1-Automatic 2-Primary/ 463 preferred 3-Lowest cost 465 o physical-port:describe the WAN port number 467 o service-type: Commodity refers to broadband Internet links; 468 Wireless refers to subset of 3G/4G/LTE and upcoming 5G; Private 469 refers to private circuits such as Ethernet, T1, etc 471 o service-provider: Specifies the name of provider per enumerated 472 list of providers globally. 474 o path-selection-mode: Describes the policy for how paths should be 475 selected for the specified traffic flow. This includes the policy 476 option for portions of traffic to not be sent across the SD-WAN 477 overlay tunnel. Values are: 1 - "Drop" 2 - "UnderNon overlay" 3 - 478 "Overlay". 480 A custom SLA profile is defined as a list of services properties. 481 The properties are as follows: 483 o delay: defines the latency constraint of a specific traffic class 484 . 486 o jitter: defines the jitter constraint of a specific traffic class. 488 o loss: defines the loss constraint of a specific traffic class. 490 The complete data hierarchy is presented as follows: 492 module: ietf-ose-path-svc 493 +--rw path-svc 494 | +--rw path-policy* [policy-name] 495 | +--rw policy-name string 496 | +--rw flow-classification* [class-name] 497 | | +--rw class-name string 498 | | +--rw dscp? inet:dscp 499 | | +--rw ipv4-src-prefix? inet:ipv4-prefix 500 | | +--rw ipv6-src-prefix? inet:ipv6-prefix 501 | | +--rw ipv4-dst-prefix? inet:ipv4-prefix 502 | | +--rw ipv6-dst-prefix? inet:ipv6-prefix 503 | | +--rw l4-src-port? inet:port-number 504 | | +--rw l4-src-port-range 505 | | | +--rw lower-port? inet:port-number 506 | | | +--rw upper-port? inet:port-number 507 | | +--rw l4-dst-port? inet:port-number 508 | | +--rw l4-dst-port-range 509 | | | +--rw lower-port? inet:port-number 510 | | | +--rw upper-port? inet:port-number 511 | | +--rw protocol-field? union 512 | +--rw application-classification* [application-class-name] 513 | | +--rw application-class-name string 514 | | +--rw category-id? uint32 515 | | +--rw application-id? uint32 516 | +--rw user* [list-name] 517 | | +--rw list-name string 518 | | +--rw user-id* string 519 | | +--rw user-group* string 520 | +--rw site* uint32 521 | +--rw link-path-policy 522 | +--rw business-priority? enumeration 523 | +--rw link-selection-mode 524 | | +--rw mode? enumeration 525 | | +--rw physical-port? uint32 526 | | +--rw service-type? enumeration 527 | | +--rw service-provider? string 528 | +--rw path-selection-mode? enumeration 529 +--rw traffic-sla 530 +--rw traffic-sla* [custom_sla_name] 531 +--rw custom_sla_name string 532 +--rw direction? identityref 533 +--rw latency? uint32 534 +--rw jitter? uint32 535 +--rw packet-loss-rate? uint32 537 7. SD-WAN OSE Gateway Service YANG Module 539 file "ietf-ose-gateway-svc@2019-06-10.yang" 540 module ietf-ose-gateway-svc { 541 namespace "urn:ietf:params:xml:ns:yang:ietf-ose-gateway-svc"; 542 prefix ose-gw-svc; 544 organization 545 "IETF foo Working Group."; 546 contact 547 "WG List: foo@ietf.org 548 Editor: "; 549 description 550 "The YANG module defines a generic service configuration 551 model for interworking between different SD-WAN domains."; 553 revision 2019-06-10 { 554 description 555 "Initial revision"; 556 reference 557 "A YANG Data Model for SD-WAN service configuration of 558 gateway-svc."; 559 } 561 feature ose-option-a { 562 description 563 "This feature means that ose reachability service option-A is 564 supported by the Serving SDWAN manager"; 565 reference "ONUG-OSE-2 SDWAN Reachability and Segmentation 566 Specification"; 567 } 569 feature ose-option-b { 570 description 571 "This feature means that ose reachability service option-B 572 is supported by the Serving SDWAN manager"; 573 reference "ONUG-OSE-2 SDWAN Reachability and Segmentation 574 Specification"; 575 } 577 container ose-gateways { 578 list ose-gateway { 579 key "gw-id"; 580 leaf gw-id { 581 type uint32; 582 description 583 "Identifier for Gateway."; 584 } 585 leaf gw-name { 586 type string; 587 description 588 "OSE gateway name."; 589 } 590 list peer-list { 591 key "name"; 592 leaf name { 593 type string; 594 description 595 "Peer Name."; 596 } 597 leaf peer-gw-id { 598 type uint32; 599 description 600 "Identifier for the remote peer gateway."; 601 } 602 leaf peer-gw-name { 603 type string; 604 description 605 "Name of remote peer gateway. "; 606 } 607 leaf ose-interworking-option { 608 type enumeration { 609 enum ose-option-a { 610 description 611 "MP-BGP based Inter-AS VPN Option A with MPLS labels."; 612 } 613 enum ose-option-b { 614 description 615 "MP-BGP based L3VPN Inter-AS Option B with MPLS 616 labels."; 617 } 618 } 619 default "ose-option-b"; 620 description 621 "OSE Gateway interworking options."; 622 } 623 leaf encap-type { 624 type enumeration { 625 enum ipsec_tunnel { 626 description 627 "The encapsulation option is IPSec Tunnel mode per 628 RFC4303."; 629 } 630 enum ipsec_transport { 631 description 632 "The encapsulation option is IPSec Transport mode 633 per RFC4303."; 634 } 635 enum gre { 636 description 637 "The encapsulation option is GRE tunnel per."; 638 } 639 } 640 description 641 "The encapsulation options of OSE Gateway interworking."; 642 } 643 leaf auth-type { 644 type enumeration { 645 enum psk { 646 description 647 "Pre-Shared Key(PSK)."; 648 } 649 enum pki { 650 description 651 "Public Key Infrastructure."; 652 } 653 } 654 description 655 "authentication type."; 656 } 657 leaf crypto-option { 658 type enumeration { 659 enum aes-128 { 660 description 661 "crypto algorithm."; 662 } 663 enum aes-256 { 664 description 665 "crypto algorithm."; 666 } 667 enum aes-256-gcm { 668 description 669 "crypto algorithm."; 670 } 671 } 672 description 673 "Crypto algorithm selection. Others to be added."; 674 } 675 description 676 "OSE Gateway peer gateway list."; 677 } 678 list segment-list { 679 key "segment-name"; 680 leaf segment-name { 681 type string; 682 description 683 "segment name."; 684 } 685 leaf vlan-id { 686 if-feature "ose-option-a"; 687 type uint16; 688 description 689 "vlan ID."; 690 } 691 leaf vrf-id { 692 if-feature "ose-option-b"; 693 type uint16; 694 description 695 "vrf ID."; 696 } 697 leaf segment-type { 698 type enumeration { 699 enum overlay { 700 description 701 "overlay NNI interworking."; 702 } 703 enum nsw { 704 description 705 "underlay NNI interworking."; 706 } 707 } 708 description 709 "segment type."; 710 } 711 list crossconnects { 712 key "ccname"; 713 leaf ccname { 714 type string; 715 description 716 "cross connection name."; 717 } 718 leaf gateway-reference { 719 type leafref { 720 path "../../../peer-list/peer-gw-id"; 721 } 722 description 723 "Specify the OSE gateway to be cross-connected 724 with the segment."; 725 } 726 leaf peer-seg-name { 727 type string; 728 description 729 "Peer segment name."; 730 } 731 leaf peer-seg-id-vlan { 732 if-feature "ose-option-a"; 733 type uint16; 734 description 735 "Peer segment vlan ID."; 736 } 737 leaf peer-seg-id-vrf { 738 if-feature "ose-option-b"; 739 type uint16; 740 description 741 "Peer Segment vrf ID."; 742 } 743 description 744 "Cross connection List"; 745 } 746 description 747 "Segment List"; 748 } 749 description 750 "OSE gateway list."; 751 } 752 description 753 "OSE gateway container."; 754 } 755 } 757 759 8. SD-WAN OSE Path Service YANG Module 761 file "ietf-ose-path-svc@2019-06-10.yang" 762 module ietf-ose-path-svc { 763 namespace "urn:ietf:params:xml:ns:yang:ietf-ose-path-svc"; 764 prefix ose-path-svc; 766 import ietf-inet-types { 767 prefix inet; 768 } 770 organization 771 "IETF foo Working Group."; 772 contact 773 "WG List: foo@ietf.org 774 Editor: "; 775 description 776 "The YANG module defines a generic service configuration 777 model for interworking between different SD-WAN domains."; 779 revision 2019-06-10 { 780 description 781 "Initial revision"; 782 reference 783 "A YANG Data Model for SD-WAN service configuration of 784 path-svc."; 785 } 787 identity traffic-direction { 788 description 789 "Base identity for traffic direction."; 790 } 792 identity upstream { 793 base traffic-direction; 794 description 795 "Identity for Site-to-WAN direction."; 796 } 798 identity downstream { 799 base traffic-direction; 800 description 801 "Identity for WAN-to-Site direction."; 802 } 804 identity both { 805 base traffic-direction; 806 description 807 "Identity for both WAN-to-Site direction 808 and Site-to-WAN direction."; 809 } 811 identity protocol-type { 812 description 813 "Base identity for protocol field type."; 814 } 816 identity tcp { 817 base protocol-type; 818 description 819 "TCP protocol type."; 820 } 822 identity udp { 823 base protocol-type; 824 description 825 "UDP protocol type."; 826 } 828 identity icmp { 829 base protocol-type; 830 description 831 "ICMP protocol type."; 832 } 834 identity icmp6 { 835 base protocol-type; 836 description 837 "ICMPv6 protocol type."; 838 } 840 identity gre { 841 base protocol-type; 842 description 843 "GRE protocol type."; 844 } 846 identity ipip { 847 base protocol-type; 848 description 849 "IP-in-IP protocol type."; 850 } 852 identity hop-by-hop { 853 base protocol-type; 854 description 855 "Hop-by-Hop IPv6 header type."; 856 } 858 identity routing { 859 base protocol-type; 860 description 861 "Routing IPv6 header type."; 862 } 864 identity esp { 865 base protocol-type; 866 description 867 "ESP header type."; 868 } 870 identity ah { 871 base protocol-type; 872 description 873 "AH header type."; 874 } 876 container path-svc { 877 description 878 "Container for application aware path selection policy."; 879 list path-policy { 880 key "policy-name"; 881 description 882 "List for path selection policy."; 883 leaf policy-name { 884 type string; 885 description 886 "Policy name."; 887 } 888 list flow-classification { 889 key "class-name"; 890 description 891 "List for traffic classification."; 892 leaf class-name { 893 type string; 894 description 895 "Traffic classification name."; 896 } 897 leaf dscp { 898 type inet:dscp; 899 description 900 "DSCP value."; 901 } 902 leaf ipv4-src-prefix { 903 type inet:ipv4-prefix; 904 description 905 "Match on IPv4 src address."; 906 } 907 leaf ipv6-src-prefix { 908 type inet:ipv6-prefix; 909 description 910 "Match on IPv6 src address."; 911 } 912 leaf ipv4-dst-prefix { 913 type inet:ipv4-prefix; 914 description 915 "Match on IPv4 dst address."; 916 } 917 leaf ipv6-dst-prefix { 918 type inet:ipv6-prefix; 919 description 920 "Match on IPv6 dst address."; 922 } 923 leaf l4-src-port { 924 type inet:port-number; 925 must 'current() < ../l4-src-port-range/lower-port or '+ 926 'current() > ../l4-src-port-range/upper-port' { 927 description 928 "If l4-src-port and l4-src-port-range/lower-port and 929 upper-port are set at the same time, l4-src-port 930 should not overlap with l4-src-port-range."; 931 } 932 description 933 "Match on Layer 4 src port."; 934 } 935 container l4-src-port-range { 936 leaf lower-port { 937 type inet:port-number; 938 description 939 "Lower boundary for port."; 940 } 941 leaf upper-port { 942 type inet:port-number; 943 must '. >= ../lower-port' { 944 description 945 "Upper boundary for port. If it 946 exists, the upper boundary must be 947 higher than the lower boundary."; 948 } 949 description 950 "Upper boundary for port."; 951 } 952 description 953 "Match on Layer 4 src port range. When 954 only the lower-port is present, it represents 955 a single port. When both the lower-port and 956 upper-port are specified, it implies 957 a range inclusive of both values."; 958 } 959 leaf l4-dst-port { 960 type inet:port-number; 961 must 'current() < ../l4-dst-port-range/lower-port or '+ 962 'current() > ../l4-dst-port-range/upper-port' { 963 description 964 "If l4-dst-port and l4-dst-port-range/lower-port 965 and upper-port are set at the same time, 966 l4-dst-port should not overlap with 967 l4-src-port-range."; 968 } 969 description 970 "Match on Layer 4 dst port."; 971 } 972 container l4-dst-port-range { 973 leaf lower-port { 974 type inet:port-number; 975 description 976 "Lower boundary for port."; 977 } 978 leaf upper-port { 979 type inet:port-number; 980 must '. >= ../lower-port' { 981 description 982 "Upper boundary must be 983 higher than lower boundary."; 984 } 985 description 986 "Upper boundary for port. If it exists, 987 upper boundary must be higher than lower 988 boundary."; 989 } 990 description 991 "Match on Layer 4 dst port range. When only 992 lower-port is present, it represents a single 993 port. When both lower-port and upper-port are 994 specified, it implies a range inclusive of both 995 values."; 996 } 997 leaf protocol-field { 998 type union { 999 type uint8; 1000 type identityref { 1001 base protocol-type; 1002 } 1003 } 1004 description 1005 "Match on IPv4 protocol or IPv6 Next Header field."; 1006 } 1007 } 1008 list application-classification { 1009 key "application-class-name"; 1010 description 1011 "List for application."; 1012 leaf application-class-name { 1013 type string; 1014 description 1015 "Application classification name."; 1016 } 1017 leaf category-id { 1018 type uint32; 1019 description 1020 "Describe the application category, e.g. Media, 1021 Peer2Peer."; 1022 } 1023 leaf application-id { 1024 type uint32; 1025 description 1026 "Describe the application and sub-application flows 1027 as well."; 1028 } 1029 } 1030 list user { 1031 key "list-name"; 1032 description 1033 "List for User."; 1034 leaf list-name { 1035 type string; 1036 description 1037 "User list name."; 1038 } 1039 leaf-list user-id { 1040 type string; 1041 description 1042 "User list."; 1043 } 1044 leaf-list user-group { 1045 type string; 1046 description 1047 "User group list."; 1048 } 1049 } 1050 leaf-list site { 1051 type uint32; 1052 description 1053 "Describe the enterprise site or set of sites."; 1054 } 1055 container link-path-policy { 1056 description 1057 "Container for path selection policy."; 1058 leaf business-priority { 1059 type enumeration { 1060 enum high { 1061 description 1062 "Refers to high priority."; 1063 } 1064 enum normal { 1065 description 1066 "Refers to normal priority."; 1067 } 1068 enum low { 1069 description 1070 "Refers to low priority.."; 1071 } 1072 enum voice { 1073 description 1074 "Refers to voice priority."; 1075 } 1076 enum critical_data { 1077 description 1078 "Refers to critical_data priority."; 1079 } 1080 enum transactional { 1081 description 1082 "Refers to transactional priority."; 1083 } 1084 enum user-defined { 1085 description 1086 "Refers to user-defined priority."; 1087 } 1088 } 1089 description 1090 "Describes the business priority for the matched traffic or 1091 application."; 1092 } 1093 container link-selection-mode { 1094 description 1095 "Describes the policy for how links should be selected for 1096 the specified traffic flow."; 1097 leaf mode { 1098 type enumeration { 1099 enum automatic { 1100 description 1101 "Refers to automatic mode with all the WAN link 1102 service."; 1103 } 1104 enum primary { 1105 description 1106 "For certain traffic requiring high security or to 1107 use a limited usage based circuit."; 1108 } 1109 enum lowest-cost { 1110 description 1111 "For certain traffic only low cost WAN link could 1112 be used."; 1113 } 1115 } 1116 description 1117 "Automatic option needs to take the SLA profile into 1118 consideration; Primary and lowest-cost are NOT 1119 automatic."; 1120 } 1121 leaf physical-port { 1122 type uint32; 1123 description 1124 "When in NOT automatic mode, specify the physical-port."; 1125 } 1126 leaf service-type { 1127 type enumeration { 1128 enum commodity { 1129 description 1130 "Refers to broadband Internet links."; 1131 } 1132 enum wireless { 1133 description 1134 "Refers to subset of 3G/4G/LTE and upcoming 5G."; 1135 } 1136 enum private { 1137 description 1138 "Refers to private circuits such as Ethernet, T1, 1139 etc."; 1140 } 1141 } 1142 description 1143 "When in NOT automatic mode, specify the physical-port, 1144 service-type."; 1145 } 1146 leaf service-provider { 1147 type string; 1148 description 1149 "When in NOT automatic mode, specify the name of 1150 provider."; 1151 } 1152 } 1153 leaf path-selection-mode { 1154 type enumeration { 1155 enum drop { 1156 description 1157 "Specify to drop the traffic."; 1158 } 1159 enum underlay { 1160 description 1161 "Specify the underlay path."; 1162 } 1163 enum overlay { 1164 description 1165 "Specify the overlay path."; 1166 } 1167 } 1168 default "overlay"; 1169 description 1170 "Describes the policy for how paths should be selected for 1171 the specified traffic flow. If a destination for a traffic 1172 flow can be reached through both the overlay as well as 1173 the underlay,specify a preference ."; 1174 } 1175 } 1176 } 1177 } 1178 container traffic-sla { 1179 description 1180 "Container for traffic SLA measurement."; 1181 list traffic-sla { 1182 key "custom_sla_name"; 1183 description 1184 "List for traffic sla profile"; 1185 leaf custom_sla_name { 1186 type string; 1187 description 1188 "customer traffic sla name"; 1189 } 1190 leaf direction { 1191 type identityref { 1192 base traffic-direction; 1193 } 1194 default "both"; 1195 description 1196 "The direction to which the QoS profile 1197 is applied: upstream or downstream."; 1198 } 1199 leaf latency { 1200 type uint32; 1201 units "msec"; 1202 description 1203 "Downstream or upstream latency observed on the path in msec"; 1204 } 1205 leaf jitter { 1206 type uint32; 1207 units "msec"; 1208 description 1209 "Jitter observed on the path in msec"; 1210 } 1211 leaf packet-loss-rate { 1212 type uint32 { 1213 range "0..100"; 1214 } 1215 units "percent"; 1216 description 1217 "Percentage of packet loss observed on the path for the 1218 upstream and downstream"; 1219 } 1220 } 1221 } 1222 } 1224 1226 9. Security Considerations 1228 The YANG module specified in this document defines a schema for data 1229 that is designed to be accessed via network management protocols such 1230 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1231 is the secure transport layer, and the mandatory-to-implement secure 1232 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1233 is HTTPS, and the mandatory-to-implement secure transport is TLS 1234 [RFC8446]. 1236 The NETCONF access control model [RFC8341] provides the means to 1237 restrict access for particular NETCONF or RESTCONF users to a 1238 preconfigured subset of all available NETCONF or RESTCONF protocol 1239 operations and content. 1241 There are a number of data nodes defined in this YANG module that are 1242 writable/creatable/deletable (i.e., config true, which is the 1243 default). These data nodes may be considered sensitive or vulnerable 1244 in some network environments. Write operations (e.g., edit-config) 1245 to these data nodes without proper protection can have a negative 1246 effect on network operations. These are the subtrees and data nodes 1247 and their sensitivity/vulnerability: 1249 o /ose-path/service 1251 The entries in the list above include the whole ose path service 1252 configurations which the customer subscribes, and indirectly 1253 create or modify the path selection configurations. Unexpected 1254 changes to these entries could lead to service disruption and/or 1255 network misbehavior. 1257 o /ose-gateways/ose-gateway 1258 The entries in the list above include the whole ose gateway 1259 service configurations which the customer subscribes, and 1260 indirectly create or modify the PE,ASBR device configurations. 1261 Unexpected changes to these entries could lead to service 1262 disruption and/or network misbehavior. 1264 o /ose-gateways/ose-gateway/peer-list 1266 The entries in the list above include the peer list 1267 configurations. As above, unexpected changes to these entries 1268 could lead to service disruption and/or network misbehavior. 1270 o /ose-gateways/ose-gateway/segment-list 1272 The entries in the list above include the segment list 1273 configurations. As above, unexpected changes to these entries 1274 could lead to service disruption and/or network misbehavior. 1276 10. IANA Considerations 1278 This document registers a URI in the IETF XML registry [RFC3688]. 1279 Following the format in [RFC3688], the following registrations are 1280 requested to be made: 1282 --------------------------------------------------------------------- 1283 URI: urn:ietf:params:xml:ns:yang:ietf-ose-path-svc 1284 Registrant Contact: The IESG 1285 XML: N/A; the requested URI is an XML namespace. 1287 URI: urn:ietf:params:xml:ns:yang:ietf-ose-gateway-svc 1288 Registrant Contact: The IESG 1289 XML: N/A; the requested URI is an XML namespace. 1290 --------------------------------------------------------------------- 1292 This document registers two YANG modules in the YANG Module Names 1293 registry [RFC6020]. 1295 --------------------------------------------------------------------- 1296 Name: ietf-ose-path-svc 1297 Namespace: urn:ietf:params:xml:ns:yang:ietf-ose-path-svc 1298 Prefix: path-svc 1299 Reference: RFC xxxx 1300 Name: ietf-ose-gateway-svc 1301 Namespace: urn:ietf:params:xml:ns:yang:ietf-ose-gateway-svc 1302 Prefix: reach-vpn 1303 Reference: RFC xxxx 1304 --------------------------------------------------------------------- 1306 11. References 1308 11.1. Normative References 1310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1311 Requirement Levels", BCP 14, RFC 2119, 1312 DOI 10.17487/RFC2119, March 1997, 1313 . 1315 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1316 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1317 . 1319 11.2. Informative References 1321 [I-D.rosen-bess-secure-l3vpn] 1322 Rosen, E. and R. Bonica, "Augmenting RFC 4364 Technology 1323 to Provide Secure Layer L3VPNs over Public 1324 Infrastructure", draft-rosen-bess-secure-l3vpn-01 (work in 1325 progress), June 2018. 1327 [ONUG] Group, O. S. W., Ed., "ONUG Software-Defned WAN Use Case: 1328 A white paper from the ONUG SD-WAN Working Group", October 1329 2014. 1331 [OSE] Group, O. O. W., Ed., "ONUG SOFTWARE DEFINED WAN (SD-WAN): 1332 NETWORK ARCHITECTURE FRAMEWORK". 1334 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1335 DOI 10.17487/RFC3688, January 2004, 1336 . 1338 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1339 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1340 2006, . 1342 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1343 the Network Configuration Protocol (NETCONF)", RFC 6020, 1344 DOI 10.17487/RFC6020, October 2010, 1345 . 1347 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1348 and A. Bierman, Ed., "Network Configuration Protocol 1349 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1350 . 1352 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1353 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1354 . 1356 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1357 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1358 . 1360 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1361 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1362 . 1364 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1365 Access Control Model", STD 91, RFC 8341, 1366 DOI 10.17487/RFC8341, March 2018, 1367 . 1369 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1370 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1371 . 1373 Appendix A. Acknowledges 1375 Authors' Addresses 1377 Steve Wood (editor) 1378 Cisco Systems 1380 Email: swood1@cisco.com 1382 Bo Wu (editor) 1383 Huawei Technologies, Co., Ltd 1385 Email: lana.wubo@huawei.com 1387 Qin Wu (editor) 1388 Huawei Technologies, Co., Ltd 1390 Email: bill.wu@huawei.com 1392 Conrad Menezes 1393 HPE Aruba 1395 Email: conrad.menezes@hpe.com