idnits 2.17.1 draft-jags-spring-sr-service-programming-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 21 instances of too long lines in the document, the longest one being 53 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 250 has weird spacing: '...nstance uin...' == Line 254 has weird spacing: '...oc-mode sr-...' == Line 378 has weird spacing: '...ce-name str...' == Line 385 has weird spacing: '...s-label rt-...' == Line 390 has weird spacing: '...rv6-sid srv...' == (2 more instances...) == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (November 2, 2020) is 1270 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) == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-03 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SPRING Working Group J. Rajamanickam 2 Internet-Draft K. Raza 3 Intended status: Standards Track Cisco Systems 4 Expires: May 6, 2021 5 D. Bernier 6 Bell Canada 8 November 2, 2020 10 YANG Data Model for SR Service Programming 11 draft-jags-spring-sr-service-programming-yang-00 13 Abstract 15 This document describes a YANG data model for Segment Routing (SR) 16 Service Programming. The model serves as a base framework for 17 configuring and managing an SR based service programming. 18 Additionally, this document specifies the model for a Service Proxy 19 for SR-unaware services. 21 The YANG modules in this document conform to the Network Management 22 Datastore Architecture (NMDA). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 6, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 60 3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Service Function Types . . . . . . . . . . . . . . . . . 4 63 3.3. SR Service Programming Types . . . . . . . . . . . . . . 5 64 3.4. SR Service Programming Base . . . . . . . . . . . . . . . 5 65 3.4.1. Configuration . . . . . . . . . . . . . . . . . . . . 5 66 3.4.2. Operational State . . . . . . . . . . . . . . . . . . 6 67 3.4.3. Notification . . . . . . . . . . . . . . . . . . . . 7 68 3.5. SR Service Proxy . . . . . . . . . . . . . . . . . . . . 7 69 3.5.1. Static Proxy . . . . . . . . . . . . . . . . . . . . 8 70 3.5.2. Dynamic Proxy . . . . . . . . . . . . . . . . . . . . 9 71 3.5.3. Masquerading Proxy . . . . . . . . . . . . . . . . . 10 72 4. YANG Specification . . . . . . . . . . . . . . . . . . . . . 11 73 4.1. Service Types . . . . . . . . . . . . . . . . . . . . . . 11 74 4.2. SR Service Programming Types . . . . . . . . . . . . . . 13 75 4.3. SR Service Programming Base . . . . . . . . . . . . . . . 17 76 4.4. SR Service Proxy . . . . . . . . . . . . . . . . . . . . 23 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 80 8. Normative References . . . . . . . . . . . . . . . . . . . . 30 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 83 1. Introduction 85 The Network Configuration Protocol (NETCONF) [RFC6241] is one of the 86 network management protocols that defines mechanisms to manage 87 network devices. YANG [RFC6020] is a modular language that 88 represents data structures in an XML tree format, and is used as a 89 data modeling language for the NETCONF. 91 Segment Routing is an architecture based on the source routing 92 paradigm that seeks the right balance between distributed 93 intelligence and centralized programmability. SR can be used with an 94 MPLS or an IPv6 data plane to steer packets through an ordered list 95 of instructions, called segments. These segments may encode simple 96 routing instructions for forwarding packets along a specific network 97 path, but also steer them through Virtual Network Function (VNF) or 98 physical service appliances available in the network. 100 In an SR network, each of these services, running either on a 101 physical appliance or in a virtual environment, are associated with a 102 segment identifier (SID). These service SIDs are then leveraged as 103 part of a SID-list to steer packets through the desired services in 104 the service chain. Service SIDs may be combined together in a SID- 105 list to achieve the service programming, but also with other types of 106 segments as defined in [RFC8402]. SR thus provides a fully 107 integrated solution for overlay, underlay and service programming. 108 Furthermore, the IPv6 instantiation of SR (SRv6) supports metadata 109 transportation in the Segment Routing header [RFC8754], either 110 natively in the tag field or with extensions such as TLVs. 112 This document describes how a service can be associated with a SID, 113 including legacy services with no SR capabilities, and how these 114 service SIDs are integrated within an SR policy. The definition of 115 an SR Policy and the traffic steering mechanisms are covered in 116 [I-D.ietf-spring-segment-routing-policy] and hence outside the scope 117 of this document. 119 This document introduces a YANG data model for the SR based service 120 programming configuration and management. Furthermore, this document 121 also covers the basic SR unaware behaviours as defined in 122 [I-D.ietf-spring-sr-service-programming]. 124 This document does not cover the following: 126 o SR-aware service specific management parameters 128 The model currently defines the following constructs that are used 129 for managing SR based service programming: 131 o Configuration 133 o Operational State 135 o Notifications 137 2. Specification of Requirements 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in BCP 14 [RFC2119] 142 [RFC8174] when, and only when, they appear in all capitals, as shown 143 here. 145 3. YANG Model 147 3.1. Overview 149 This document defines the following four new YANG modules: 151 o ietf-service-function-types: Defines common service function types 153 o ietf-sr-service-programming-types: Defines common type definitions 154 used for SR based service programming YANG model 156 o ietf-sr-service-programming: Defines management model for SR based 157 service programming framework. This is a base and common 158 framework for both SR-aware and SR-unaware services. 160 o ietf-sr-service-programming-proxy: Defines management model for SR 161 service proxy for SR unaware services 163 The modelling in this document complies with the Network Management 164 Datastore Architecture (NMDA) defined in [RFC8342]. The operational 165 state data is combined with the associated configuration data in the 166 same hierarchy [RFC8407]. When protocol states are retrieved from 167 the NMDA operational state datastore, the returned states cover all 168 "config true" (rw) and "config false" (ro) nodes defined in the 169 schema. 171 In this document, when a simplified graphical representation of YANG 172 model is presented in a tree diagram, the meaning of the symbols in 173 these tree diagrams is defined in [RFC8340]. 175 3.2. Service Function Types 177 A service is identified by (type, instance). The type represents the 178 type of service functions (such as Firewall, DPI IPS etc.), whereas 179 instance is used to refer to a specific instance of the same service. 181 We define a new YANG module ietf-service-function-types to specify 182 common definitions and types for service and service function. The 183 types and definitions are generic and hence can be used in any (SR 184 based or non-SR) YANG models. 186 The main definitions and types defined in ietf-service-function-types 187 module include: 189 o service-function-type: A new identity type to specify service 190 function types, such as firewall, dpi etc. Other identities can 191 be define by other modules in future. 193 3.3. SR Service Programming Types 195 The types required to model SR based service programming are defined 196 in a new module ietf-sr-service-programming-types. 198 The main types defined in this module includes: 200 o service-program-behaviour-type: Defines SR service program 201 behaviours like sr-aware, static-proxy etc... 203 o service-program-oper-status-type: Defines SR service programming 204 operational status. This includes the reason for down status as 205 well 207 o service-proxy-inner-pkt-type: Defines SR service proxy inner 208 packet types 210 3.4. SR Service Programming Base 212 The base model and framework for SR based service programming is 213 defined in a new module ietf-sr-service-programming. This module 214 provides a common base for both the SR-aware and SR-unaware service 215 programming in terms of configuration, operation state and 216 notifications. The ietf-sr-service-programming module hangs off main 217 SR parent by augmenting "/rt:routing/sr:segment-routing". 219 3.4.1. Configuration 221 This module defines some fundamental items required to configure SR 222 based service programming. In particular, it defins service program 223 provisioning as follows: 225 o service program behaviour: Defining a service program behaviour 227 o service offered: Defining a specific service (type, instance) 228 offered this service programming 230 o Assigning a SR service SID: Defining SID data plane, method to 231 allocate the SID etc.. 233 o service program enablement: Administratively Enable/Disable a 234 service program 236 o SR services: Defining a base container which could be augmented to 237 define SR-aware or SR-unaware (via service-proxy) service specific 238 parameters 240 Following is a simplified graphical tree representation of the data 241 model for SR service programming base configuration only 243 module: ietf-sr-service-programming 244 augment /rt:routing/sr:segment-routing: 245 +--rw service-programming 246 +--rw service-program* [name] 247 +--rw name string 248 +--rw behaviour identityref 249 +--rw service-type identityref 250 +--rw service-instance uint32 251 +--rw dataplane sr-svc-pgm-types:dataplane-type 252 +--rw admin-status? sr-svc-pgm-types:admin-status-type 253 +--rw sid-binding 254 | +--rw alloc-mode sr-svc-pgm-types:sid-alloc-mode-type 255 | +--rw mpls 256 | | +--rw sid? rt-types:mpls-label 257 | +--rw srv6 258 | +--rw sid? srv6-types:srv6-sid 259 | +--rw locator? -> /rt:routing/sr:segment-routing/ 260 | srv6:srv6/locators/locator/name 261 | 262 +--rw sr-services 264 Figure 1: SR Service Programming Config Tree 266 3.4.2. Operational State 268 As per NMDA model, the state related to configuration items specified 269 in above section Section 3.4.1 can be retrieved from the same tree. 270 This section defines other operational state items related to SR 271 based service programming. 273 The operational state corresponding to an SR based service program 274 includes: 276 o Operational status: Provides detail information on the operational 277 state of the SR service program. 279 o statistics: Provides the statistics details such as number of 280 packets/bytes received, processed and dropped corresponding to a 281 SR service program. 283 Following is a simplified graphical tree representation of the data 284 model for the SR service programming base operational state (for 285 read-only items): 287 module: ietf-sr-service-programming 288 augment /rt:routing/sr:segment-routing: 289 +--rw service-programming 290 +--rw service-program* [name] 291 +--ro oper-status? identityref 292 +--ro statistics 293 +--ro in-packet-count? yang:counter64 294 +--ro in-bytes-count? yang:counter64 295 +--ro out-packet-count? yang:counter64 296 +--ro out-bytes-count? yang:counter64 297 +--ro in-drop-packet-count? yang:counter64 298 +--ro out-drop-packet-count? yang:counter64 300 Figure 2: SR Service Programming Operational State Tree 302 3.4.3. Notification 304 This model defines a list of notifications to inform an operator of 305 important events detected during the SR service programming 306 operation. These events are: 308 o SR service program operational state changes: This would also give 309 the reason for the state change when it is down 311 Following is a simplified graphical tree representation of the data 312 model for the SR service programming notification: 314 module: ietf-sr-service-programming 315 notifications: 316 +---n service-program-oper-status 317 +--ro name -> /rt:routing/sr:segment-routing/ 318 sr-svc-pgm:service-programming/ 319 service-program/name 320 +--ro oper-status -> /rt:routing/sr:segment-routing/ 321 sr-svc-pgm:service-programming/ 322 service-program/oper-status 324 Figure 3: SR Service Programming Notification Tree 326 3.5. SR Service Proxy 328 This document also defines a separate and new YANG data model for 329 Service Proxy for SR unaware services. The model defines the 330 configuration and operational state related to different proxy 331 behaviours defined earlier in ietf-sr-service-programming-types. The 332 model is defined in a new module ietf-sr-service-programming proxy. 333 This module augments the SR service program tree (/rt:routing/ 334 sr:segment-routing/sr-svc-pgm:service-programming/ sr-svc- 335 pgm:service-program/sr-svc-pgm:sr-services) as defined earlier in 336 ietf-sr-service-programming module. 338 The following sections describe different types of proxy behaviours 339 and associated YANG modelling constructs. 341 3.5.1. Static Proxy 343 The static proxy is an SR endpoint behaviour for processing SR-MPLS 344 or SRv6 encapsulated traffic on behalf of an SR-unaware services. 346 The following parameters are required to provision the SR static 347 proxy: 349 o inner-packet-type: Inner packet type 351 o next-hop: Next hop Ethernet address (only for the inner type is 352 IPv4 or IPv6) 354 o out-interface-name: Local interface for sending traffic towards 355 the service Endpoint 357 o in-interface-name: Local interface receiving traffic coming back 358 from the service Endpoint 360 o packet-cache-info: SR information to be attached on the traffic 361 coming back from the service. This could be list of MPLS Label 362 stack or SRv6 SIDs 364 Following is a simplified graphical tree representation of the data 365 model for the SR static proxy: 367 module: ietf-sr-service-programming-proxy 368 augment /rt:routing/sr:segment-routing/ 369 sr-svc-pgm:service-programming/ 370 sr-svc-pgm:service-program/ 371 sr-svc-pgm:sr-services: 372 +--rw service-proxy 373 +--rw (proxy-type) 374 +--:(static) 375 +--rw static-proxy 376 +--rw inner-packet-type identityref 377 +--rw next-hop? yang:mac-address 378 +--rw out-interface-name string 379 +--rw in-interface-name string 380 +--rw packet-cache-info 381 +--rw (cache-type) 382 +--:(mpls) 383 | +--rw mpls-sids* [index] 384 | +--rw index uint8 385 | +--rw mpls-label rt-types:mpls-label 386 +--:(srv6) 387 +--rw ipv6-source-address? inet:ipv6-address 388 +--rw srv6-sids* [index] 389 +--rw index uint8 390 +--rw srv6-sid srv6-types:srv6-sid 392 Figure 4: SR Static Proxy Tree 394 3.5.2. Dynamic Proxy 396 The dynamic proxy is an improvement over the static proxy that 397 dynamically learns the SR information before removing it from the 398 incoming traffic. The same information can be re-attached to the 399 traffic returning from the service Endpoints. The dynamic proxy 400 relies on the local caching. 402 The following parameters are required to provision the SR dynamic 403 proxy: 405 o out-interface-name: Local interface for sending traffic towards 406 the service Endpoint 408 o in-interface-name: Local interface receiving traffic coming back 409 from the service Endpoint 411 Following is a simplified graphical tree representation of the data 412 model for the SR static proxy: 414 module: ietf-sr-service-programming-proxy 415 augment /rt:routing/sr:segment-routing/ 416 sr-svc-pgm:service-programming/ 417 sr-svc-pgm:service-program/ 418 sr-svc-pgm:sr-services: 419 +--rw service-proxy 420 +--rw (proxy-type) 421 +--:(dynamic) 422 +--rw dynamic-proxy 423 +--rw out-interface-name string 424 +--rw in-interface-name string 426 Figure 5: SR Dynamic Proxy Tree 428 3.5.3. Masquerading Proxy 430 The masquerading proxy is an SR endpoint behaviour for processing 431 SRv6 traffic on behalf of an SR-unaware service. This masquerading 432 behaviour is independent from the inner payload type. 434 The following parameters are required to provision the SR 435 masquerading proxy 437 o next-hop: Next hop Ethernet address 439 o out-interface-name: Local interface for sending traffic towards 440 the service Endpoint 442 o in-interface-name: Local interface receiving traffic coming back 443 from the service Endpoint 445 Following is a simplified graphical tree representation of the data 446 model for the SR masquerading proxy: 448 module: ietf-sr-service-programming-proxy 449 augment /rt:routing/sr:segment-routing/ 450 sr-svc-pgm:service-programming/ 451 sr-svc-pgm:service-program/ 452 sr-svc-pgm:sr-services: 453 +--rw service-proxy 454 +--rw (proxy-type) 455 +--:(masquerading) 456 +--rw masquerading-proxy 457 +--rw next-hop? yang:mac-address 458 +--rw out-interface-name string 459 +--rw in-interface-name string 461 Figure 6: SR masquerading Proxy Tree 463 4. YANG Specification 465 Following are actual YANG definition for SR service programming 466 modules defined earlier in the document. 468 4.1. Service Types 470 Following are the Service Types definitions. 472 file "ietf-service-function-types.yang" --> 474 module ietf-service-function-types { 475 yang-version 1.1; 477 namespace "urn:ietf:params:xml:ns:yang:ietf-service-function-types"; 478 prefix "service-types"; 480 organization "IETF SPRING Working Group"; 482 contact 483 "WG Web: 484 WG List: 486 Editor: Jaganbabu Rajamanickam 487 489 Editor: Kamran Raza 490 492 Editor: Daniel Bernier 493 "; 495 /* 496 * Below are the definition for the service types 497 * Any new service type could added by extending 498 * this identity 499 */ 500 identity service-function-type { 501 description 502 "Base identity from which specific service function 503 types are derived."; 504 } 506 identity firewall { 507 base service-function-type; 508 description 509 "Firewall Service type"; 510 } 512 identity dpi { 513 base service-function-type; 514 description 515 "Deep Packet Inspection Service type"; 516 } 518 identity napt44 { 519 base service-function-type; 520 description 521 "Network Address and Port Translation 44 522 Service type"; 523 } 525 identity classifier { 526 base service-function-type; 527 description 528 "classifier Service type"; 529 } 531 identity load-balancer { 532 base service-function-type; 533 description 534 "load-balancer Service type"; 535 } 537 identity ips { 538 base service-function-type; 539 description 540 "Intrusion Prevention System Service type (Ex: Snort)"; 541 } 543 } 545 547 Figure 7: ietf-service-function-types.yang 549 4.2. SR Service Programming Types 551 Following are the SR service programming specific types definitions. 553 file "ietf-sr-service-programming-types.yang" --> 555 module ietf-sr-service-programming-types { 556 yang-version 1.1; 558 namespace "urn:ietf:params:xml:ns:yang:ietf-sr-service-programming-types"; 559 prefix "sr-service-types"; 561 organization "IETF SPRING Working Group"; 563 contact 564 "WG Web: 565 WG List: 567 Editor: Jaganbabu Rajamanickam 568 570 Editor: Kamran Raza 571 573 Editor: Daniel Bernier 574 "; 576 /* 577 * SR Service programming behaviour 578 */ 579 identity service-program-behaviour-type { 580 description 581 "Base identity for SR service programming behaviour"; 582 } 584 identity sr-aware { 585 base service-program-behaviour-type; 586 description 587 "SR aware native applications."; 588 } 589 identity static-proxy { 590 base service-program-behaviour-type; 591 description 592 "Static Proxy"; 593 } 595 identity dynamic-proxy { 596 base service-program-behaviour-type; 597 description 598 "Dynamic Proxy"; 599 } 601 identity Masquerading-proxy { 602 base service-program-behaviour-type; 603 description 604 "Masquerading Proxy"; 605 } 607 identity Masquerading-NAT-proxy { 608 base service-program-behaviour-type; 609 description 610 "Masquerading Proxy with NAT flavor"; 611 } 613 identity Masquerading-caching-proxy { 614 base service-program-behaviour-type; 615 description 616 "Masquerading Proxy with caching flavor"; 617 } 619 identity Masquerading-NAT-caching-proxy { 620 base service-program-behaviour-type; 621 description 622 "Masquerading Proxy with caching flavor"; 623 } 625 /* 626 * Below are the definition for the service proxy inner packet types 627 * Any new service proxy inner packet type could added by extending 628 * this identity 629 */ 630 identity service-proxy-inner-pkt-type { 631 description 632 "Base identity from which SR service proxy types are derived."; 633 } 635 identity Ethernet { 636 base service-proxy-inner-pkt-type; 637 description 638 "Expected inner packet type as Ethernet - derived from 639 service-proxy-inner-pkt-type"; 640 } 642 identity IPv4 { 643 base service-proxy-inner-pkt-type; 644 description 645 "Expected inner packet type as IPv4 - derived from 646 service-proxy-inner-pkt-type"; 647 } 649 identity IPv6 { 650 base service-proxy-inner-pkt-type; 651 description 652 "Expected inner packet type as IPv6 - derived from 653 service-proxy-inner-pkt-type"; 654 } 656 /* 657 * SR Service SID operational status 658 */ 659 identity service-program-oper-status-type { 660 description 661 "Base identity from which SR service program operational 662 status types are derived."; 663 } 665 identity up { 666 base service-program-oper-status-type; 667 description 668 "Service program status is operational"; 669 } 671 identity down-unknown { 672 base service-program-oper-status-type; 673 description 674 "Service program status is down because of unknown reason"; 675 } 677 identity sid-allocation-pending { 678 base service-program-oper-status-type; 679 description 680 "Service program status is down because of SID allocation is pending"; 681 } 682 identity sid-allocation-conflict { 683 base service-program-oper-status-type; 684 description 685 "Service program status is down because of SID conflict"; 686 } 688 identity sid-out-of-bound { 689 base service-program-oper-status-type; 690 description 691 "Service program status is down because of SID is out of bound"; 692 } 694 identity interface-down { 695 base service-program-oper-status-type; 696 description 697 "Service program status is down because of out/in interface is down"; 698 } 700 identity admin-forced-down { 701 base service-program-oper-status-type; 702 description 703 "Service program status is administratively forced down"; 704 } 706 /* 707 * Typedefs 708 */ 709 typedef admin-status-type { 710 type enumeration { 711 enum up { 712 description "Admin Up"; 713 } 714 enum down { 715 description "Admin Down"; 716 } 717 } 718 } 720 typedef dataplane-type { 721 type enumeration { 722 enum mpls { 723 description "MPLS dataplane"; 724 } 725 enum srv6 { 726 description "SRv6 dataplane"; 727 } 728 } 729 } 730 typedef sid-alloc-mode-type { 731 type enumeration { 732 enum static { 733 description "Static SID allocation"; 734 } 735 enum dynamic { 736 description "Dynamic SID allocation"; 737 } 738 } 739 } 740 } 742 744 Figure 8: ietf-sr-service-programming-types.yang 746 4.3. SR Service Programming Base 748 Following are the SR service programming base model definition. 750 file "ietf-sr-service-programming.yang" --> 752 module ietf-sr-service-programming { 753 yang-version 1.1; 755 namespace "urn:ietf:params:xml:ns:yang:ietf-sr-service-programming"; 756 prefix "sr-svc-pgm"; 758 import ietf-yang-types { 759 prefix "yang"; 760 } 762 import ietf-srv6-base { 763 prefix "srv6"; 764 } 766 import ietf-routing { 767 prefix rt; 768 reference "RFC 8349: A YANG Data Model for Routing 769 Management (NMDA Version)"; 770 } 772 import ietf-service-function-types { 773 prefix "service-types"; 774 } 775 import ietf-segment-routing { 776 prefix sr; 777 } 779 import ietf-sr-service-programming-types { 780 prefix "sr-svc-pgm-types"; 781 } 783 import ietf-routing-types { 784 prefix "rt-types"; 785 } 787 import ietf-srv6-types { 788 prefix "srv6-types"; 789 } 791 organization "IETF SPRING Working Group"; 793 contact 794 "WG Web: 795 WG List: 797 Editor: Jaganbabu Rajamanickam 798 800 Editor: Kamran Raza 801 803 Editor: Daniel Bernier 804 "; 806 grouping service-statistics { 808 container statistics { 810 config false; 811 description "Service statistics"; 813 leaf in-packet-count { 814 type yang:counter64; 815 description 816 "Total number of packets processed by this service"; 817 } 819 leaf in-bytes-count { 820 type yang:counter64; 821 description 822 "Total number of bytes processed by this service"; 824 } 826 leaf out-packet-count { 827 type yang:counter64; 828 description 829 "Total number of packets end out after processing by this service"; 830 } 832 leaf out-bytes-count { 833 type yang:counter64; 834 description 835 "Total number of bytes end out after processing by this service"; 836 } 838 leaf in-drop-packet-count { 839 type yang:counter64; 840 description 841 "Total number of packets dropped while processing by this service"; 842 } 844 leaf out-drop-packet-count { 845 type yang:counter64; 846 description 847 "Total number of packets dropped while this service try to 848 forward to its destination"; 849 } 850 } 851 } 853 grouping service-mpls-sid-binding { 854 container mpls { 855 description 856 "MPLS Service SID binding Container"; 858 when "../../dataplane = 'mpls'"; 860 leaf sid { 861 type rt-types:mpls-label; 862 description 863 "MPLS SID value."; 864 } 865 } 866 } 868 grouping service-srv6-sid-binding { 869 container srv6 { 870 description 871 "SRv6 Service SID binding Container"; 873 when "../../dataplane = 'srv6'"; 875 leaf sid { 876 type srv6-types:srv6-sid; 877 description 878 "SRv6 SID value."; 879 } 881 leaf locator { 882 type leafref { 883 path "/rt:routing/sr:segment-routing" 884 + "/srv6:srv6/srv6:locators/srv6:locator/srv6:name"; 885 } 886 description 887 "Reference to a SRv6 locator. This is valid only when 888 the SID allocation mode is dynamic"; 889 } 890 } 891 } 893 grouping service-sid-binding { 894 container sid-binding { 895 description 896 "Service SID binding Container"; 898 leaf alloc-mode { 899 mandatory true; 900 type sr-svc-pgm-types:sid-alloc-mode-type; 901 description 902 "Service SID allocation mode"; 903 } 905 uses service-mpls-sid-binding; 906 uses service-srv6-sid-binding; 907 } 908 } 910 grouping service-programming { 911 container service-programming { 912 description 913 "service programming container. 914 Any new services programming added could augment 915 this container to support that specific services. 916 Currently in this model, only service proxy 917 is defined. (i.e) For example if 918 a Firewall services needs to be added then 919 they could augment this container and 920 extend this model"; 922 list service-program { 923 key "name"; 924 description 925 "Service program is keyed by the service program name"; 927 leaf name { 928 type string; 929 description 930 "Service program name to identify a specific program."; 931 } 933 leaf behaviour { 934 mandatory true; 935 type identityref { 936 base sr-svc-pgm-types:service-program-behaviour-type; 937 } 938 description 939 "SR program behaviour"; 940 } 942 leaf service-type { 943 mandatory true; 944 type identityref { 945 base service-types:service-function-type; 946 } 947 description 948 "Service-Type defined by IANA (STT). This is either the SR-aware 949 service of SR-unaware service offered by an SR proxy"; 950 } 952 leaf service-instance { 953 mandatory true; 954 type uint32; 955 description 956 "Service instance which differentiates the same service -- e.g. 957 same Firewall service could have several instances available. 958 The type and the instance would 959 describe a specific instance which the application would 960 like to choose"; 961 } 963 leaf dataplane { 964 mandatory true; 965 type sr-svc-pgm-types:dataplane-type; 966 description 967 "Service SID dataplane."; 968 } 969 leaf admin-status { 970 type sr-svc-pgm-types:admin-status-type; 971 default down; 972 description 973 "Admin Status"; 974 } 976 leaf oper-status { 977 config false; 978 type identityref { 979 base sr-svc-pgm-types:service-program-oper-status-type; 980 } 981 description 982 "Service SID operational mode."; 983 } 985 uses service-sid-binding; 986 uses service-statistics; 988 container sr-services { 990 description 991 "Any SR-aware or AR-unaware services could augment this container"; 992 reference "Segment Routing Service Programming Architecture."; 993 } 994 } 995 } 996 } 998 augment "/rt:routing/sr:segment-routing" { 999 description 1000 "Augmenting the segment-routing bindings to add SR service programming"; 1002 uses service-programming; 1003 } 1005 notification service-program-oper-status { 1006 description 1007 "This notification is sent when there is a change in the service 1008 program oper status."; 1009 leaf name { 1010 mandatory true; 1011 type leafref { 1012 path "/rt:routing/sr:segment-routing/" 1013 + "sr-svc-pgm:service-programming/" 1014 + "sr-svc-pgm:service-program/" 1015 + "sr-svc-pgm:name"; 1016 } 1017 description 1018 "Service program name to identify a specific programming."; 1019 } 1021 leaf oper-status { 1022 mandatory true; 1023 type leafref { 1024 path "/rt:routing/sr:segment-routing/" 1025 + "sr-svc-pgm:service-programming/" 1026 + "sr-svc-pgm:service-program/" 1027 + "sr-svc-pgm:oper-status"; 1028 } 1029 description 1030 "Service program operational status."; 1031 } 1033 } 1034 } 1036 1038 Figure 9: ietf-sr-service-programming.yang 1040 4.4. SR Service Proxy 1042 Following are the SR service programming service proxy model 1043 definition. 1045 file "ietf-sr-service-programming-proxy.yang" --> 1046 module ietf-sr-service-programming-proxy { 1047 yang-version 1.1; 1049 namespace "urn:ietf:params:xml:ns:yang:ietf-sr-service-programming-proxy"; 1050 prefix "sr-svc-proxy"; 1052 import ietf-yang-types { 1053 prefix yang; 1054 } 1056 import ietf-routing { 1057 prefix rt; 1058 reference "RFC 8349: A YANG Data Model for Routing 1059 Management (NMDA Version)"; 1060 } 1062 import ietf-inet-types { 1063 prefix "inet"; 1064 } 1066 import ietf-segment-routing { 1067 prefix sr; 1068 } 1070 import ietf-sr-service-programming { 1071 prefix "sr-svc-pgm"; 1072 } 1074 import ietf-sr-service-programming-types { 1075 prefix "sr-svc-pgm-types"; 1076 } 1078 import ietf-routing-types { 1079 prefix "rt-types"; 1080 } 1082 import ietf-srv6-types { 1083 prefix "srv6-types"; 1084 } 1086 organization "IETF SPRING Working Group"; 1088 contact 1089 "WG Web: 1090 WG List: 1092 Editor: Jaganbabu Rajamanickam 1093 1095 Editor: Kamran Raza 1096 1098 Editor: Daniel Bernier 1099 "; 1101 grouping service-proxy-parameters { 1103 leaf out-interface-name { 1104 mandatory true; 1105 type string; 1106 description 1107 "Interface name on which the packet sent to the service endpoint"; 1108 } 1110 leaf in-interface-name { 1111 mandatory true; 1112 type string; 1113 description 1114 "Interface name on which the packet received from the service endpoint"; 1115 } 1116 } 1118 grouping mpls-packet-cache-info { 1119 description 1120 "MPLS Label stack"; 1122 list mpls-sids { 1123 key "index"; 1125 leaf index { 1126 type uint8 { 1127 range "1..16"; 1128 } 1129 description 1130 "cache index - MPLS Label stack index"; 1131 } 1133 leaf mpls-label { 1134 mandatory true; 1135 type rt-types:mpls-label; 1136 description 1137 "MPLS Label value."; 1138 } 1139 } 1140 } 1142 grouping srv6-packet-cache-info { 1143 description 1144 "SRv6 SID stack"; 1146 leaf ipv6-source-address { 1147 type inet:ipv6-address; 1148 description 1149 "IPv6 source address that needs in the case if SRv6."; 1150 } 1151 list srv6-sids { 1152 key "index"; 1154 leaf index { 1155 type uint8 { 1156 range "1..16"; 1157 } 1158 description 1159 "cache index - SRv6 SID index"; 1160 } 1162 leaf srv6-sid { 1163 mandatory true; 1164 type srv6-types:srv6-sid; 1165 description 1166 "SRv6 SID."; 1167 } 1168 } 1169 } 1171 grouping service-proxy-packet-cache-info { 1172 description 1173 "SRv6 Proxy header cache"; 1175 container packet-cache-info { 1177 choice cache-type { 1178 mandatory true; 1179 case mpls { 1181 when "/rt:routing/sr:segment-routing/sr-svc-pgm:service-programming 1182 /sr-svc-pgm:service-program 1183 /sr-svc-pgm:dataplane = 'mpls'"; 1185 uses mpls-packet-cache-info; 1186 } 1187 case srv6 { 1189 when "/rt:routing/sr:segment-routing/sr-svc-pgm:service-programming 1190 /sr-svc-pgm:service-program 1191 /sr-svc-pgm:dataplane = 'srv6'"; 1193 uses srv6-packet-cache-info; 1194 } 1195 } 1196 // uses mpls-packet-cache-info; 1197 // uses srv6-packet-cache-info; 1198 } 1199 } 1201 grouping static-service-proxy { 1202 container static-proxy { 1203 description 1204 "Parameters related to static service proxy"; 1206 leaf inner-packet-type { 1207 mandatory true; 1208 type identityref { 1209 base sr-svc-pgm-types:service-proxy-inner-pkt-type; 1210 } 1211 description 1212 "Defines the expected inner packet type"; 1213 } 1215 leaf next-hop { 1216 when "(../inner-packet-type = 'IPv4' or ../inner-packet-type = 'IPv6')"; 1217 type yang:mac-address; 1218 description 1219 "Nexthop Ethernet address for inner packet type IPv4/IPv6"; 1220 } 1221 uses service-proxy-parameters; 1222 uses service-proxy-packet-cache-info; 1223 } 1224 } 1226 grouping dynamic-service-proxy { 1227 container dynamic-proxy { 1228 description 1229 "Parameters related to dynamic service proxy"; 1230 uses service-proxy-parameters; 1231 } 1232 } 1234 grouping masquerading-service-parameters { 1236 leaf next-hop { 1237 mandatory true; 1238 type yang:mac-address; 1239 description 1240 "Nexthop Ethernet address"; 1241 } 1242 uses service-proxy-parameters; 1243 } 1245 grouping masquerading-service-proxy { 1246 container masquerading-proxy { 1247 description 1248 "Parameters related to masquerading service proxy"; 1250 when "/rt:routing/sr:segment-routing/sr-svc-pgm:service-programming 1251 /sr-svc-pgm:service-program 1252 /sr-svc-pgm:dataplane = 'srv6'"; 1254 uses masquerading-service-parameters; 1256 } 1257 } 1259 grouping service-proxy-programming { 1261 container service-proxy { 1263 choice proxy-type { 1264 mandatory true; 1265 case static { 1266 when "/rt:routing/sr:segment-routing/ 1267 sr-svc-pgm:service-programming 1268 /sr-svc-pgm:service-program 1269 /sr-svc-pgm:dataplane = 'srv6'"; 1270 uses static-service-proxy; 1271 } 1272 case dynamic { 1273 uses dynamic-service-proxy; 1274 } 1275 case masquerading { 1276 uses masquerading-service-proxy; 1277 } 1278 } 1279 //uses dynamic-service-proxy; 1280 } 1281 } 1283 augment "/rt:routing/sr:segment-routing/sr-svc-pgm:service-programming/sr-svc-pgm:service-program/sr-svc-pgm:sr-services" { 1284 description 1285 "Augmenting the segment-routing bindings to add SR-unaware 1286 service programming"; 1288 uses service-proxy-programming; 1289 } 1291 } 1293 1295 Figure 10: ietf-sr-service-programming-proxy.yang 1297 5. Security Considerations 1299 The YANG module specified in this document defines a schema for data 1300 that is designed to be accessed via network management protocols such 1301 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1302 is the secure transport layer, and the mandatory-to-implement secure 1303 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1304 is HTTPS, and the mandatory-to-implement secure transport is TLS 1305 [RFC8446]. 1307 The Network Configuration Access Control Model (NACM) [RFC8341] 1308 provides the means to restrict access for particular NETCONF or 1309 RESTCONF users to a preconfigured subset of all available NETCONF or 1310 RESTCONF protocol operations and content. 1312 There are a number of data nodes defined in this YANG module that are 1313 writable/creatable/ deletable (i.e., config true, which is the 1314 default). These data nodes may be considered sensitive or vulnerable 1315 in some network environments. Write operations (e.g., edit-config) 1316 to these data nodes without proper protection can have a negative 1317 effect on network operations. 1319 Some of the readable data nodes in this YANG module may be considered 1320 sensitive or vulnerable in some network environments. It is thus 1321 important to control read access (e.g., via get, get-config, or 1322 notification) to these data nodes. 1324 It goes without saying that this specification also inherits the 1325 security considerations captured in the SRv6 specification document 1326 [I-D.ietf-spring-sr-service-programming]. 1328 6. IANA Considerations 1330 This document requests the registration of the following URIs in the 1331 IETF "XML registry" [RFC3688]: 1333 +--------------------------------------------------+----------+-----+ 1334 | URI | Registra | XML | 1335 | | nt | | 1336 +--------------------------------------------------+----------+-----+ 1337 | urn:ietf:params:xml:ns:yang:ietf-service- | The IESG | N/A | 1338 | function-types | | | 1339 | urn:ietf:params:xml:ns:yang:ietf-sr-service- | The IESG | N/A | 1340 | programming-types | | | 1341 | | | | 1342 | urn:ietf:params:xml:ns:yang:ietf-sr-service- | The IESG | N/A | 1343 | programming | | | 1344 | urn:ietf:params:xml:ns:yang:ietf-sr-service- | The IESG | N/A | 1345 | programming-proxy | | | 1346 +--------------------------------------------------+----------+-----+ 1348 This document requests the registration of the following YANG modules 1349 in the "YANG Module Names" registry [RFC6020]: 1351 +---------------+--------------------------+----------------+-------+ 1352 | Name | Namespace | Prefix | Refer | 1353 | | | | ence | 1354 +---------------+--------------------------+----------------+-------+ 1355 | ietf-service- | urn:ietf:params:xml:ns:y | service- | This | 1356 | function- | ang:ietf-service- | function-types | docum | 1357 | types | function-types | | ent | 1358 | | | | | 1359 | ietf-sr- | urn:ietf:params:xml:ns:y | ietf-sr- | This | 1360 | service- | ang:ietf-sr-service- | service- | docum | 1361 | programming- | programming-types | programming- | ent | 1362 | types | | types | | 1363 | | | | | 1364 | ietf-sr- | urn:ietf:params:xml:ns:y | ietf-sr- | This | 1365 | service- | ang:ietf-sr-service- | service- | docum | 1366 | programming | programming | programming | ent | 1367 | | | | | 1368 | ietf-sr- | urn:ietf:params:xml:ns:y | ietf-sr- | This | 1369 | service- | ang:ietf-sr-service- | service- | docum | 1370 | programming- | programming-proxy | programming- | ent | 1371 | proxy | | proxy | | 1372 +---------------+--------------------------+----------------+-------+ 1374 -- RFC Editor: Replace "This document" with the document RFC number 1375 at time of publication, and remove this note. 1377 7. Acknowledgments 1379 The authors would like to acknowledge Francois Clad, Ketan 1380 Talaulikar, and Darren Dukes for their review of some of the contents 1381 in this document. 1383 8. Normative References 1385 [I-D.ietf-spring-segment-routing-policy] 1386 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1387 P. Mattes, "Segment Routing Policy Architecture", draft- 1388 ietf-spring-segment-routing-policy-09 (work in progress), 1389 November 2020. 1391 [I-D.ietf-spring-sr-service-programming] 1392 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1393 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1394 Henderickx, W., and S. Salsano, "Service Programming with 1395 Segment Routing", draft-ietf-spring-sr-service- 1396 programming-03 (work in progress), September 2020. 1398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1399 Requirement Levels", BCP 14, RFC 2119, 1400 DOI 10.17487/RFC2119, March 1997, 1401 . 1403 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1404 DOI 10.17487/RFC3688, January 2004, 1405 . 1407 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1408 the Network Configuration Protocol (NETCONF)", RFC 6020, 1409 DOI 10.17487/RFC6020, October 2010, 1410 . 1412 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1413 and A. Bierman, Ed., "Network Configuration Protocol 1414 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1415 . 1417 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1418 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1419 . 1421 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1422 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1423 . 1425 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1426 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1427 May 2017, . 1429 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1430 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1431 . 1433 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1434 Access Control Model", STD 91, RFC 8341, 1435 DOI 10.17487/RFC8341, March 2018, 1436 . 1438 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1439 and R. Wilton, "Network Management Datastore Architecture 1440 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1441 . 1443 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1444 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1445 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1446 July 2018, . 1448 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1449 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1450 DOI 10.17487/RFC8407, October 2018, 1451 . 1453 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1454 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1455 . 1457 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1458 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1459 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1460 . 1462 Authors' Addresses 1464 Jaganbabu Rajamanickam 1465 Cisco Systems 1467 Email: jrajaman@cisco.com 1469 Kamran Raza 1470 Cisco Systems 1472 Email: skraza@cisco.com 1474 Daniel Bernier 1475 Bell Canada 1477 Email: daniel.bernier@bell.ca