idnits 2.17.1 draft-wood-rtgwg-sdwan-ose-yang-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 37 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 548 has weird spacing: '...percent dec...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2019) is 1866 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) == Missing Reference: 'RFC8174' is mentioned on line 152, but not defined == Missing Reference: 'RFC8340' is mentioned on line 156, but not defined == Unused Reference: 'RFC4364' is defined on line 1275, but no explicit reference was found in the text == Unused Reference: 'RFC6370' is defined on line 1298, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 3 errors (**), 0 flaws (~~), 7 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: September 12, 2019 Q. Wu, Ed. 6 Huawei 7 C. Menezes 8 HPE Aruba 9 March 11, 2019 11 YANG Data Model for SD-WAN OSE service delivery 12 draft-wood-rtgwg-sdwan-ose-yang-00 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 September 12, 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.1.1. Requirements Language . . . . . . . . . . . . . . . . 4 59 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. The SD-WAN OSE Service Model Requirements . . . . . . . . . . 5 62 3.1. Reachability & Router Exchange Requirements . . . . . . . 5 63 3.2. Path management Requirements . . . . . . . . . . . . . . 5 64 3.3. Network Segmentation Requirements . . . . . . . . . . . . 6 65 4. Service Model Usage . . . . . . . . . . . . . . . . . . . . . 6 66 5. Design of the Data Model . . . . . . . . . . . . . . . . . . 8 67 5.1. OSE Gateway module . . . . . . . . . . . . . . . . . . . 8 68 5.2. path-management module . . . . . . . . . . . . . . . . . 9 69 6. SD-WAN OSE Path Management YANG Module . . . . . . . . . . . 12 70 7. SD-WAN OSE Reachability Service YANG Module . . . . . . . . . 21 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 75 10.2. Informative References . . . . . . . . . . . . . . . . . 28 76 Appendix A. Acknowledges . . . . . . . . . . . . . . . . . . . . 28 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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.1.1. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 1.2. Tree diagram 155 Tree diagrams used in this document follow the notation defined in 156 [RFC8340]. 158 2. Definitions 160 This document uses the following terms: 162 Service Provider (SP): The organization (usually a commercial 163 undertaking) responsible for operating the network that offers VPN 164 services to clients and customers. 166 Customer Edge (CE) Device: Equipment that is dedicated to a 167 particular customer and is directly connected to one or more PE 168 devices via attachment circuits. A CE is usually located at the 169 customer premises, and is usually dedicated to a single VPN, 170 although it may support multiple VPNs if each one has separate 171 attachment circuits. The CE devices can be routers, bridges, 172 switches or hosts. 174 Provider Edge (PE) Device: Equipment managed by the SP that can 175 support multiple VPNs for different customers, and is directly 176 connected to one or more CE devices via attachment circuits. A PE 177 is usually located at an SP Point of Presence (PoP) and is managed 178 by the SP. 180 SDWAN Manager: SDWAN Manager is the domain specific manager and 181 controller required to configure, manage and control a particular 182 SDWAN domain. To create OSE SDWAN services, a higher layer 183 orchestrator may use OSE defined API calls to create the desired 184 SDWAN services within each domain via the serving SDWAN manager. 186 Client Orchestration: The Client Orchestration layer is an 187 abstraction of a service level orchestrator or software that 188 implements control the the SDWAN through the defined OSE APIs. 189 The OSE service specifications do not specify the functions and 190 procedures within this entity apart from the fact that it would 191 use the OSE APIs. The client orchestration layer is a functional 192 block which would implement OSE API calls to one or more serving 193 SDWAN managers. 195 SD-WAN controller: The SD-WAN Controller is a reference block that 196 encompasses the network control-plane functions required to 197 operate the SDWAN network. The SD-WAN network controller delivers 198 control-plane/data-plane separation the is the realization of SDN 199 architecture within the SD-WAN usecase. Each SD-WAN network 200 controller is managed and configured by the SD-WAN manager. The 201 interface between SDWAN network controller and SD-WAN network 202 manager for this purpose is currently outside the scope of the 203 document. 205 3. The SD-WAN OSE Service Model Requirements 207 This section provides a common definition for service types required 208 across different SD-WAN vendor domains. The Open SD-WAN Exchange 209 (OSE) model focuses on interoperability between domains, rather than 210 specifying standard protocol and operations with each SD-WAN domain. 212 The OSE interoperability models focus on the definition of a standard 213 set of service models and parameters that can be implemented in an 214 SDWAN management system to configure interoperable services within an 215 SDWAN domain and between SDWAN domains. 217 3.1. Reachability & Router Exchange Requirements 219 In [OSE]SD-WAN reference model, it is assumed that communication 220 between sites sitting in different domains happening via the OSE 221 gateway which suggests that traffic spanning the domains will be 222 backhauled to the OSE gateway. 224 Requirements for reachability and route exchange services are split 225 into control plane and data plane requirements. Control plane 226 requirements cover information exchange between sd-wan islands while 227 data plane requirements cover the requirements of the actual data 228 plane encapsulation. 230 3.2. Path management Requirements 232 As specified in ONUG SD-WAN whitepaper[ONUG], dynamic path selection 233 is one of the core features of the SD-WAN, which site-to-site packets 234 can be distributed across multiple WAN connections in real-time, 235 based on current link metrics such as delay, loss and jitter. In 236 this model, a path is considered to be an access network and not a 237 path within an access network, although the latter is not precluded. 238 For business critical applications traversing SD-WAN domains, 239 policies via standardized APIs need to be provisioned to guarantee 240 end-to-end SLA requirements and each domain is responsible for 241 implementing consistent policy enforcement behaviour. Since inter- 242 domain traffic are all backhauled by the OSE gateways, each part of 243 the traversing path needs to be consistent. 245 Note: A method needs to be specified for budgeting end-to-end delay 246 across multiple domains - delay/loss/jitter needs to be shared so 247 that each domain can compute the total path, determine who's 248 violating and then execute path change. 250 3.3. Network Segmentation Requirements 252 Network segmentation divides an enterprise network into different 253 traffic or routing contexts to provide clear separation of traffic of 254 each segment. These are often referred to as Virtual networks. The 255 most common technology of network segmentation are virtual LANs, or 256 VLANs, for Layer 2 implementation, and virtual routing and 257 forwarding, or VRF, for Layer 3 implementation. For traffic flowing 258 across SD-WAN domains boundaries, segmentation must be preserved. A 259 method of configuration is required to ensure per segment traffic 260 flow separation while passing through SD-WAN domain boundaries. 262 4. Service Model Usage 264 +-------------------------------------+ 265 | Client Orchestration | 266 +-------------------------------------+ 267 | | 268 ose-path-svc | ose-reachability-svc | 269 Model | Model | 270 | | 271 +----------------+ +----------------+ 272 | SDWAN manager | | SDWAN manager | 273 +----------------+ +-------+--------+ 274 | | 275 | NETCONF/CLI ... | 276 | | 277 +-------------------------+ +------+-------------------+ 278 | SDWAN Domin #1 | | SDWAN Domin #2 | 279 | | | | 280 |++++++++ +++++++++++++ | NNI | +++++++++++++ ++++++++ | 281 |+Branch+--+OSE Gateway+--+------------+-+OSE Gateway+---+Branch+ | 282 |++++++++ +++++++++++++ | | +++++++++++++ ++++++++ | 283 | | | | 284 |Site A | | Site B | 285 +-------------------------+ +--------------------------+ 287 Figure 1 289 As shown in figure 1, communication between branch sites sitting in 290 domain#1 and domain#2 happens via a border element referred to as the 291 OSE Gateway. This border element interworks the SDWAN control and 292 data plane of the SDWAN domain to a common, defined NNI carrying 293 routing information to establish reachability between domains. It 294 also carries segmentation identifiers that are mutually agreed and 295 configured within each OSE gateway by the domain serving SDWAN 296 manager. The serving SDWAN manager in each respective domain is 297 configured by the operator with information about which segments in 298 each domain are to be connected. 300 Segment connections must be 1:1 across each OSE gateway. 302 Note: The detailed control and data plane specifications for the OSE 303 Gateway NNI will refer to the definition of the relevant SD-WAN 304 protocols in the IETF. 306 The ONUG SD-WAN service YANG model provides an abstracted interface 307 to configure, and manage the components of an SD-WAN service. The 308 components of the SD-WAN service include the OSE Gateway Service 309 component and the Path Management Service component. OSE gateway 310 service component defines Reachability and Route Exchange 311 Segmentation requirements for OSE Gateway devices while path 312 management service component defines path management policy for 313 domain serving SD-WAN managers. 315 A typical usage for this model is to generate Restconf[RFC8040] API 316 used between Client Orchestraton layer and SDWAN manager and used by 317 an enterprise operator to provision the inter-domain services. 318 Before configuring the inter-domain path management policy service, 319 the ose-reachability-svc model is used for the following 320 configuration: 322 o Create one or more OSE gateways in the serving domain. 324 o Create underlying connections between the OSE gateway and other 325 SD-WAN domain gateways, including control plane and data plane. 327 o Create overlay tunnels between the OSE gateway and other SD-WAN 328 domain gateways with Tunnel setup parameters, such as IPsec Tunnel 329 related authentication and encryption parameters. 331 o Create segment mappings between the OSE gateway and other SD-WAN 332 domain gateways with segment related parameters, such as VLAN ID 333 or VRF ID. 335 For the configuration of network elements may be done using NETCONF 336 [RFC6241] or any other configuration (or "southbound") interface such 337 as Command Line Interface (CLI) in combination with device-specific 338 and protocol-specific YANG data models. 340 The usage of this service model is not limited to this example: it 341 can be used by any component of the management system but not 342 directly by network elements. 344 5. Design of the Data Model 346 The SD-WAN OSE service model currently has two YANG modules. 348 5.1. OSE Gateway module 350 The aim of OSE Gateway module is to define parameters for connection 351 setup between SD-WAN domains. As specified by RFC4364, this model 352 defines Option A and Option B to interconnect the different domain. 353 The option B allows one to minimize configuration inputs and allows 354 the solution to scale really high because only the BGP RIBs store all 355 the inter-AS / inter-SD-WAN VPN routes. MP-BGP can run a single 356 label stack within the GRE tunnel, between the NNI nodes such that 357 the MPLS label will be used for traffic segmentation. In the cases, 358 where L3VPN Inter-AS Option B is not supported, revert to MP-BGP 359 based Inter-AS VPN Option A while using MPLS labels. The option A 360 requires Orchestration layer to signal underlying SD-WAN domains to 361 configure and instantiate VRF instances per tenant, as well as MP-BGP 362 based L3VPN configuration and instantiation per tenant. This option 363 can still run on GRE or IPSec tunnels while providing isolation from 364 underlay changes and dependencies and MPLS label within the GRE 365 tunnel will provide per tenant service level separation. 367 o ose-gateway: Gateway name and Gateway ID are specified for each 368 domain. 370 o tunnel: describes encap-type in the interconnection points, and 371 authentication and encryption are also specified to secure the 372 interconnection between SD-WAN domains. 374 o ose-interworking-option: MP-BGP based L3VPN Inter-AS Option B with 375 MPLS labels and Inter-AS Option A are defined. 377 o ose-gateway control plane peering:Control Plane peering between 378 SD-WAN Edge Nodes which exchanges routes and additional 379 reachability information as well as forward transit traffic. For 380 good HA and resiliency characteristics, it is recommended to 381 establish control plane sessions between each node. 383 o segment: to guarantee end to end secure traffic, the segment 384 traffic from a specific domain needs to cross connect to the 385 target segment through an OSE gateway. 387 The complete data hierarchy is presented as follows: 389 module: ietf-ose-reachability-svc 390 +--rw ose-gateways 391 +--rw ose-gateway* [gw-name] 392 +--rw gw-name string 393 +--rw gw-id? uint32 394 +--rw ose-interworking-option? enumeration 395 +--rw encap-type? enumeration 396 +--rw auth-type? enumeration 397 +--rw crypto? enumeration 398 +--rw peer-list* [name] 399 | +--rw name string 400 | +--rw Local-gw-id? uint32 401 | +--rw peer-gw-id? uint32 402 | +--rw peer-gw-name? string 403 | +--rw authType? enumeration 404 | +--rw crypto-option? enumeration 405 | +--rw ose-interworking-option? enumeration 406 +--rw segment-list* [segment-name] 407 +--rw segment-name string 408 +--rw vlan-id? uint16 409 +--rw vrf-id? uint16 410 +--rw segment-type? enumeration 411 +--rw CrossConnects 412 +--rw CCname? string 413 +--rw local-seg-name? string 414 +--rw local-Seg-id-vlan? uint16 {ose-option-A}? 415 +--rw local-seg-id-vrf? uint16 {ose-option-B}? 416 +--rw peer-seg-name? string 417 +--rw peer-seg-id-vlan? uint16 {ose-option-A}? 418 +--rw peer-seg-id-vrf? uint16 {ose-option-B}? 420 5.2. path-management module 422 Path management module defines automatic path selection policy for 423 traffic across the domain. Policy control will take shape in the 424 form of an ordered list. Each item in the list will be evaluated to 425 match the traffic classifier. The first match will result in 426 processing the matched traffic according to the associated link & 427 path policy. In turn, the link & path policy will be framed in the 428 context of the Performance SLA associated to the links and paths. 430 +------------------+ +------------------+ +------------------+ 431 | | \| Link & Path |/ | Link&Path | 432 |Traffic Classifier+----+ Policy +------+ Performance | 433 | | /| |\ | SLAs | 434 +------------------+ +------------------+ +------------------+ 436 figure 2 438 Traffic classification rules are handled by the "traffic-class" 439 container. The traffic-classification-policy container is an ordered 440 list of rules that match a flow or application and set the 441 appropriate business-priority and make link or path selection.This 442 business priority can be factored into the path selection decision. 444 The client orchestrator can define the match using an application 445 reference or a flow definition that is more specific (e.g., based on 446 Layer 3 source and destination addresses, Layer 4 ports, and Layer 4 447 protocol). 449 The link or path selection is defined as a list of services 450 properties. Describes the policy for how links should be selected 451 for the specified traffic flow. The properties are as follows: 453 o mode:Describes the policy for how links should be selected for the 454 specified traffic flow. Values are: 1-Automatic 2-Primary/ 455 preferred 3-Lowest cost 457 o physical-port:describe the WAN port number 459 o service-type:Commodity - referring to broadband Internet 460 links,Wireless - referring to subset of 3G/4G/LTE and upcoming 461 5G,Private - referring to private circuits such as Ethernet, T1, 462 etc 464 o service-provider:specifying the name of provider per enumerated 465 list of providers globally 467 o path-selection-mode:Describes the policy for how paths should be 468 selected for the specified traffic flow. This includes the policy 469 option for portions of traffic to not be sent across the SD-WAN 470 overlay tunnel. Values are: 1 - "Drop" 2 - "UnderNon overlay" 3 - 471 "Overlay" 473 A custom SLA profile is defined as a list of services properties. 474 The properties are as follows: 476 o delay:used to define the latency constraint of a specific traffic 477 class . 479 o jitter:used to define the jitter constraint of a specific traffic 480 class. 482 o bandwidth usage:used to define the bandwidth constraint of a 483 specific traffic class. 485 The complete data hierarchy is presented as follows: 487 module: ietf-ose-path-svc 488 +--rw path-svc 489 | +--rw service* [name] 490 | +--rw name string 491 | +--rw class-id? string 492 | +--rw traffic-class* [name] 493 | | +--rw name string 494 | | +--rw dscp? inet:dscp 495 | | +--rw dot1p? uint8 496 | | +--rw ipv4-src-prefix? inet:ipv4-prefix 497 | | +--rw ipv6-src-prefix? inet:ipv6-prefix 498 | | +--rw ipv4-dst-prefix? inet:ipv4-prefix 499 | | +--rw ipv6-dst-prefix? inet:ipv6-prefix 500 | | +--rw l4-src-port? inet:port-number 501 | | +--rw l4-src-port-range 502 | | | +--rw lower-port? inet:port-number 503 | | | +--rw upper-port? inet:port-number 504 | | +--rw l4-dst-port? inet:port-number 505 | | +--rw l4-dst-port-range 506 | | | +--rw lower-port? inet:port-number 507 | | | +--rw upper-port? inet:port-number 508 | | +--rw protocol-field? union 509 | +--rw application* [name] 510 | | +--rw name string 511 | | +--rw category-id? uint32 512 | | +--rw application-id? uint32 513 | +--rw user 514 | | +--rw list-name? string 515 | | +--rw user-id* string 516 | | +--rw group* string 517 | +--rw site-id* uint32 518 | +--rw business-priority? enumeration 519 | +--rw link-selection-mode 520 | | +--rw mode? enumeration 521 | | +--rw physical-port? uint32 522 | | +--rw service-type? enumeration 523 | | +--rw service-provider? string 524 | +--rw path-selection-mode? enumeration 525 +--rw traffic-profile 526 +--rw (qos-profile)? 527 +--:(standard) 528 | +--rw profile? string 529 +--:(custom) 530 +--rw classes {qos-custom}? 531 +--rw class* [class-id] 532 +--rw class-id string 533 +--rw direction? identityref 534 +--rw rate-limit? decimal64 535 +--rw latency 536 | +--rw (flavor)? 537 | +--:(lowest) 538 | | +--rw use-lowest-latency? em 539 | +--:(boundary) 540 | +--rw latency-boundary? ui 541 +--rw jitter 542 | +--rw (flavor)? 543 | +--:(lowest) 544 | | +--rw use-lowest-jitter? emp 545 | +--:(boundary) 546 | +--rw latency-boundary? uin 547 +--rw bandwidth 548 +--rw guaranteed-bw-percent decim 549 +--rw end-to-end? empty 551 6. SD-WAN OSE Path Management YANG Module 553 file "ietf-ose-path-svc.yang" 554 module ietf-ose-path-svc { 555 namespace "urn:ietf:params:xml:ns:yang:ietf-ose-path-svc"; 556 prefix path-svc; 558 import ietf-inet-types { 559 prefix inet; 560 } 562 feature qos-custom { 563 description 564 "Enables support of the custom QoS profile."; 565 } 567 identity qos-profile-direction { 568 description 569 "Base identity for QoS profile direction."; 570 } 572 identity site-to-wan { 573 base qos-profile-direction; 574 description 575 "Identity for Site-to-WAN direction."; 576 } 578 identity wan-to-site { 579 base qos-profile-direction; 580 description 581 "Identity for WAN-to-Site direction."; 582 } 584 identity both { 585 base qos-profile-direction; 586 description 587 "Identity for both WAN-to-Site direction 588 and Site-to-WAN direction."; 589 } 591 identity protocol-type { 592 description 593 "Base identity for protocol field type."; 594 } 596 identity tcp { 597 base protocol-type; 598 description 599 "TCP protocol type."; 600 } 602 identity udp { 603 base protocol-type; 604 description 605 "UDP protocol type."; 606 } 608 identity icmp { 609 base protocol-type; 610 description 611 "ICMP protocol type."; 612 } 614 identity icmp6 { 615 base protocol-type; 616 description 617 "ICMPv6 protocol type."; 618 } 620 identity gre { 621 base protocol-type; 622 description 623 "GRE protocol type."; 624 } 626 identity ipip { 627 base protocol-type; 628 description 629 "IP-in-IP protocol type."; 630 } 632 identity hop-by-hop { 633 base protocol-type; 634 description 635 "Hop-by-Hop IPv6 header type."; 636 } 638 identity routing { 639 base protocol-type; 640 description 641 "Routing IPv6 header type."; 642 } 644 identity esp { 645 base protocol-type; 646 description 647 "ESP header type."; 648 } 650 identity ah { 651 base protocol-type; 652 description 653 "AH header type."; 654 } 656 container path-svc { 657 list service { 658 key "name"; 659 leaf name { 660 type string; 661 } 662 leaf class-id { 663 type string; 664 } 665 list traffic-class { 666 key "name"; 667 leaf name { 668 type string; 669 } 670 leaf dscp { 671 type inet:dscp; 672 description 673 "DSCP value."; 674 } 675 leaf dot1p { 676 type uint8 { 677 range "0..7"; 678 } 679 description 680 "802.1p matching."; 681 } 682 leaf ipv4-src-prefix { 683 type inet:ipv4-prefix; 684 description 685 "Match on IPv4 src address."; 686 } 687 leaf ipv6-src-prefix { 688 type inet:ipv6-prefix; 689 description 690 "Match on IPv6 src address."; 691 } 692 leaf ipv4-dst-prefix { 693 type inet:ipv4-prefix; 694 description 695 "Match on IPv4 dst address."; 696 } 697 leaf ipv6-dst-prefix { 698 type inet:ipv6-prefix; 699 description 700 "Match on IPv6 dst address."; 701 } 702 leaf l4-src-port { 703 type inet:port-number; 704 must 'current() < ../l4-src-port-range/lower-port or current() > ../l4-src-port-range/upper-port' { 705 description 706 "If l4-src-port and l4-src-port-range/lower-port and 707 upper-port are set at the same time, l4-src-port 708 should not overlap with l4-src-port-range."; 709 } 710 description 711 "Match on Layer 4 src port."; 712 } 713 container l4-src-port-range { 714 leaf lower-port { 715 type inet:port-number; 716 description 717 "Lower boundary for port."; 718 } 719 leaf upper-port { 720 type inet:port-number; 721 must '. >= ../lower-port' { 722 description 723 "Upper boundary for port. If it 724 exists, the upper boundary must be 725 higher than the lower boundary."; 726 } 727 description 728 "Upper boundary for port."; 729 } 730 description 731 "Match on Layer 4 src port range. When 732 only the lower-port is present, it represents 733 a single port. When both the lower-port and 734 upper-port are specified, it implies 735 a range inclusive of both values."; 736 } 737 leaf l4-dst-port { 738 type inet:port-number; 739 must 'current() < ../l4-dst-port-range/lower-port or current() > ../l4-dst-port-range/upper-port' { 740 description 741 "If l4-dst-port and l4-dst-port-range/lower-port 742 and upper-port are set at the same time, 743 l4-dst-port should not overlap with 744 l4-src-port-range."; 745 } 746 description 747 "Match on Layer 4 dst port."; 748 } 749 container l4-dst-port-range { 750 leaf lower-port { 751 type inet:port-number; 752 description 753 "Lower boundary for port."; 754 } 755 leaf upper-port { 756 type inet:port-number; 757 must '. >= ../lower-port' { 758 description 759 "Upper boundary must be 760 higher than lower boundary."; 761 } 762 description 763 "Upper boundary for port. If it exists, 764 upper boundary must be higher than lower 765 boundary."; 766 } 767 description 768 "Match on Layer 4 dst port range. When only 769 lower-port is present, it represents a single 770 port. When both lower-port and upper-port are 771 specified, it implies a range inclusive of both 772 values."; 773 } 774 leaf protocol-field { 775 type union { 776 type uint8; 777 type identityref { 778 base protocol-type; 779 } 780 } 781 description 782 "Match on IPv4 protocol or IPv6 Next Header field."; 783 } 784 } 785 list application { 786 key "name"; 787 leaf name { 788 type string; 789 } 790 leaf category-id { 791 type uint32; 792 } 793 leaf application-id { 794 type uint32; 795 } 796 } 797 container user { 798 leaf list-name { 799 type string; 800 } 801 leaf-list user-id { 802 type string; 803 } 804 leaf-list group { 805 type string; 806 } 807 } 808 leaf-list site-id { 809 type uint32; 810 } 811 leaf business-priority { 812 type enumeration { 813 enum high; 814 enum normal; 815 enum low; 816 enum Voice; 817 enum Critical_Data; 818 enum Transactional; 819 enum user-defined; 820 } 821 } 822 container link-selection-mode { 823 leaf mode { 824 type enumeration { 825 enum automatic; 826 enum preferred; 827 enum lowest-cost; 828 } 829 } 830 leaf physical-port { 831 type uint32; 832 } 833 leaf service-type { 834 type enumeration { 835 enum commodity; 836 enum wireless; 837 enum private; 838 } 839 } 840 leaf service-provider { 841 type string; 842 } 843 } 844 leaf path-selection-mode { 845 type enumeration { 846 enum drop; 847 enum underlay; 848 enum overlay; 849 } 850 } 851 } 852 } 853 container traffic-profile { 854 choice qos-profile { 855 description 856 "Choice for traffic QoS profile. 857 Can be standard profile or customized profile."; 858 case standard { 859 description 860 "Standard QoS profile."; 861 leaf profile { 862 type string; 863 description 864 "QoS profile to be used."; 865 } 866 } 867 case custom { 868 description 869 "Customized QoS profile."; 870 container classes { 871 if-feature "qos-custom"; 872 list class { 873 key "class-id"; 874 leaf class-id { 875 type string; 876 description 877 "Identification of the class of service. 878 This identifier is internal to the 879 administration."; 880 } 881 leaf direction { 882 type identityref { 883 base qos-profile-direction; 884 } 885 default "both"; 886 description 887 "The direction to which the QoS profile 888 is applied."; 889 } 890 leaf rate-limit { 891 type decimal64 { 892 fraction-digits 5; 893 range "0..100"; 894 } 895 units "percent"; 896 description 897 "To be used if the class must be rate-limited. 898 Expressed as percentage of the service 899 bandwidth."; 900 } 901 container latency { 902 choice flavor { 903 case lowest { 904 leaf use-lowest-latency { 905 type empty; 906 description 907 "The traffic class should use the path with the 908 lowest latency."; 909 } 910 } 911 case boundary { 912 leaf latency-boundary { 913 type uint16; 914 units "msec"; 915 default "400"; 916 description 917 "The traffic class should use a path with a 918 defined maximum latency."; 919 } 920 } 921 description 922 "Latency constraint on the traffic class."; 923 } 924 description 925 "Latency constraint on the traffic class."; 926 } 927 container jitter { 928 choice flavor { 929 case lowest { 930 leaf use-lowest-jitter { 931 type empty; 932 description 933 "The traffic class should use the path with the 934 lowest jitter."; 935 } 936 } 937 case boundary { 938 leaf latency-boundary { 939 type uint32; 940 units "usec"; 941 default "40000"; 942 description 943 "The traffic class should use a path with a 944 defined maximum jitter."; 945 } 946 } 947 description 948 "Jitter constraint on the traffic class."; 949 } 950 description 951 "Jitter constraint on the traffic class."; 952 } 953 container bandwidth { 954 leaf guaranteed-bw-percent { 955 type decimal64 { 956 fraction-digits 5; 957 range "0..100"; 958 } 959 units "percent"; 960 mandatory true; 961 description 962 "To be used to define the guaranteed bandwidth 963 as a percentage of the available service bandwidth."; 964 } 965 leaf end-to-end { 966 type empty; 967 description 968 "Used if the bandwidth reservation 969 must be done on the MPLS network too."; 970 } 971 description 972 "Bandwidth constraint on the traffic class."; 973 } 974 } 975 } 976 } 977 } 978 } 979 } 980 982 7. SD-WAN OSE Reachability Service YANG Module 984 file "ietf-ose-reachability-svc.yang" 985 module ietf-ose-reachability-svc { 986 namespace "urn:ietf:params:xml:ns:yang:ietf-ose-reachability-svc"; 987 prefix reach-svc; 989 import ietf-inet-types { 990 prefix inet; 991 } 992 import ietf-yang-types { 993 prefix yang; 994 } 996 feature ose-option-A { 997 description 998 "This feature means that ose reachability service option-A is supported by the Serving SDWAN manager"; 999 reference 1000 "ONUG-OSE-2 SDWAN Reachability and Segmentation Specification"; 1001 } 1003 feature ose-option-B { 1004 description 1005 "This feature means that ose reachability service option-B is supported by the Serving SDWAN manager"; 1006 reference 1007 "ONUG-OSE-2 SDWAN Reachability and Segmentation Specification"; 1008 } 1010 container ose-gateways { 1011 list ose-gateway { 1012 key "gw-name"; 1013 leaf gw-name { 1014 type string; 1015 description 1016 "OSE gateway name."; 1017 } 1018 leaf gw-id { 1019 type uint32; 1020 description 1021 "Identifier for Gateway."; 1022 } 1023 leaf ose-interworking-option { 1024 type enumeration { 1025 enum ose-option-A; 1026 enum ose-option-B; 1027 } 1028 description 1029 "OSE interworking options."; 1030 } 1031 leaf encap-type { 1032 type enumeration { 1033 enum IPSEC_TUNNEL; 1034 enum IPSEC_TRANSPORT; 1035 enum GRE; 1036 } 1037 description 1038 "encapsulation type of tunnel."; 1039 } 1040 leaf auth-type { 1041 type enumeration { 1042 enum PSK; 1043 enum PKI; 1044 } 1045 description 1046 "authentication type."; 1047 } 1048 leaf crypto { 1049 type enumeration { 1050 enum AES-128; 1051 enum AES-256; 1052 enum AES-256-GCM; 1053 } 1054 description 1055 "crypto algorithm type."; 1056 } 1057 list peer-list { 1058 key "name"; 1059 leaf name { 1060 type string; 1061 description 1062 "peer index."; 1063 } 1064 leaf Local-gw-id { 1065 type uint32; 1066 description 1067 "Identifier for the local gateway."; 1068 } 1069 leaf peer-gw-id { 1070 type uint32; 1071 description 1072 "Identifier for the remote peer gateway."; 1073 } 1074 leaf peer-gw-name { 1075 type string; 1076 description 1077 "Name of remote peer gateway. "; 1078 } 1079 leaf authType { 1080 type enumeration { 1081 enum PSK; 1082 enum PKI; 1083 } 1084 description 1085 "authentication type."; 1086 } 1087 leaf crypto-option { 1088 type enumeration { 1089 enum AES-256; 1090 enum AES-128; 1091 enum AES-256-GCM; 1092 } 1093 description 1094 "Crypto algorithm selection. Others to be added"; 1095 } 1096 leaf ose-interworking-option { 1097 type enumeration { 1098 enum ose-option-A; 1099 enum ose-option-B; 1100 } 1101 description 1102 "ose interworking options."; 1104 } 1105 } 1106 list segment-list { 1107 key "segment-name"; 1108 leaf segment-name { 1109 type string; 1110 description 1111 "segment name."; 1112 } 1113 leaf vlan-id { 1114 type uint16; 1115 description 1116 "vlan ID."; 1117 } 1118 leaf vrf-id { 1119 type uint16; 1120 description 1121 "vrf ID."; 1122 } 1123 leaf segment-type { 1124 type enumeration { 1125 enum overlay; 1126 enum nsw; 1127 } 1128 description 1129 "segment type."; 1130 } 1131 container CrossConnects { 1132 leaf CCname { 1133 type string; 1134 description 1135 "cross connection name."; 1136 } 1137 leaf local-seg-name { 1138 type string; 1139 description 1140 "local segment name."; 1141 } 1142 leaf local-Seg-id-vlan { 1143 if-feature "ose-option-A"; 1144 type uint16; 1145 description 1146 "local segment VLAN ID."; 1147 } 1148 leaf local-seg-id-vrf { 1149 if-feature "ose-option-B"; 1150 type uint16; 1151 description 1152 "lcoal segment vrf ID."; 1153 } 1154 leaf peer-seg-name { 1155 type string; 1156 description 1157 "Peer segment name."; 1158 } 1159 leaf peer-seg-id-vlan { 1160 if-feature "ose-option-A"; 1161 type uint16; 1162 description 1163 "Peer segment vlan ID."; 1164 } 1165 leaf peer-seg-id-vrf { 1166 if-feature "ose-option-B"; 1167 type uint16; 1168 description 1169 "Peer Segment vrf ID."; 1170 } 1171 } 1172 } 1173 description 1174 "Segment List"; 1175 } 1176 description 1177 "OSE gateway."; 1178 } 1179 } 1181 1183 8. Security Considerations 1185 The YANG module specified in this document defines a schema for data 1186 that is designed to be accessed via network management protocols such 1187 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1188 is the secure transport layer, and the mandatory-to-implement secure 1189 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1190 is HTTPS, and the mandatory-to-implement secure transport is TLS 1191 [RFC5246]. 1193 The NETCONF access control model [RFC6536] provides the means to 1194 restrict access for particular NETCONF or RESTCONF users to a 1195 preconfigured subset of all available NETCONF or RESTCONF protocol 1196 operations and content. 1198 There are a number of data nodes defined in this YANG module that are 1199 writable/creatable/deletable (i.e., config true, which is the 1200 default). These data nodes may be considered sensitive or vulnerable 1201 in some network environments. Write operations (e.g., edit-config) 1202 to these data nodes without proper protection can have a negative 1203 effect on network operations. These are the subtrees and data nodes 1204 and their sensitivity/vulnerability: 1206 o /ose-path/service 1208 The entries in the list above include the whole ose path service 1209 configurations which the customer subscribes, and indirectly 1210 create or modify the path selection configurations. Unexpected 1211 changes to these entries could lead to service disruption and/or 1212 network misbehavior. 1214 o /path-svc/ose-gateway 1216 The entries in the list above include the whole ose gateway 1217 service configurations which the customer subscribes, and 1218 indirectly create or modify the PE,ASBR device configurations. 1219 Unexpected changes to these entries could lead to service 1220 disruption and/or network misbehavior. 1222 o /ose-gateways/ose-gateway/peer-list 1224 The entries in the list above include the peer list 1225 configurations. As above, unexpected changes to these entries 1226 could lead to service disruption and/or network misbehavior. 1228 o /ose-gateways/ose-gateway/segment-list 1230 The entries in the list above include the segment list 1231 configurations. As above, unexpected changes to these entries 1232 could lead to service disruption and/or network misbehavior. 1234 9. IANA Considerations 1236 This document registers a URI in the IETF XML registry [RFC3688]. 1237 Following the format in [RFC3688], the following registrations are 1238 requested to be made: 1240 --------------------------------------------------------------------- 1241 URI: urn:ietf:params:xml:ns:yang:ietf-ose-path-svc 1242 Registrant Contact: The IESG 1243 XML: N/A; the requested URI is an XML namespace. 1245 URI: urn:ietf:params:xml:ns:yang:ietf-ose-reachability-svc 1246 Registrant Contact: The IESG 1247 XML: N/A; the requested URI is an XML namespace. 1248 --------------------------------------------------------------------- 1250 This document registers two YANG modules in the YANG Module Names 1251 registry [RFC6020]. 1253 --------------------------------------------------------------------- 1254 Name: ietf-ose-path-svc 1255 Namespace: urn:ietf:params:xml:ns:yang:ietf-ose-path-svc 1256 Prefix: path-svc 1257 Reference: RFC xxxx 1258 Name: ietf-ose-reachability-svc 1259 Namespace: urn:ietf:params:xml:ns:yang:ietf-ose-reachability-svc 1260 Prefix: reach-vpn 1261 Reference: RFC xxxx 1262 --------------------------------------------------------------------- 1264 10. References 1266 10.1. Normative References 1268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1269 Requirement Levels", March 1997. 1271 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1272 DOI 10.17487/RFC3688, January 2004, 1273 . 1275 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1276 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1277 2006, . 1279 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1280 (TLS) Protocol Version 1.2", RFC 5246, 1281 DOI 10.17487/RFC5246, August 2008, 1282 . 1284 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1285 the Network Configuration Protocol (NETCONF)", RFC 6020, 1286 DOI 10.17487/RFC6020, October 2010, 1287 . 1289 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1290 and A. Bierman, Ed., "Network Configuration Protocol 1291 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1292 . 1294 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1295 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1296 . 1298 [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport 1299 Profile (MPLS-TP) Identifiers", RFC 6370, 1300 DOI 10.17487/RFC6370, September 2011, 1301 . 1303 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1304 Protocol (NETCONF) Access Control Model", RFC 6536, 1305 DOI 10.17487/RFC6536, March 2012, 1306 . 1308 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1309 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1310 . 1312 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1313 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1314 . 1316 10.2. Informative References 1318 [ONUG] Group, O. S. W., Ed., "ONUG Software-Defned WAN Use Case: 1319 A white paper from the ONUG SD-WAN Working Group", October 1320 2014. 1322 [OSE] Group, O. O. W., Ed., "ONUG SOFTWARE DEFINED WAN (SD-WAN): 1323 NETWORK ARCHITECTURE FRAMEWORK". 1325 Appendix A. Acknowledges 1327 Authors' Addresses 1329 Steve Wood (editor) 1330 Cisco Systems 1332 Email: swood1@cisco.com 1333 Bo Wu (editor) 1334 Huawei Technologies, Co., Ltd 1336 Email: lana.wubo@huawei.com 1338 Qin Wu (editor) 1339 Huawei Technologies, Co., Ltd 1341 Email: bill.wu@huawei.com 1343 Conrad Menezes 1344 HPE Aruba 1346 Email: conrad.menezes@hpe.com