idnits 2.17.1 draft-ietf-teas-sf-aware-topo-model-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 4, 2018) is 2150 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3688' is mentioned on line 606, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-15 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Bryskin 3 Internet-Draft Huawei Technologies 4 Intended status: Informational X. Liu 5 Expires: December 6, 2018 Jabil 6 June 4, 2018 8 SF Aware TE Topology YANG Model 9 draft-ietf-teas-sf-aware-topo-model-00 11 Abstract 13 This document describes a YANG data model for TE network topologies 14 that are network service and function aware. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 6, 2018. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 53 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3 54 2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 3 55 3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 61 7.2. Informative References . . . . . . . . . . . . . . . . . 15 62 Appendix A. Companion YANG Model for Non-NMDA Compliant 63 Implementations . . . . . . . . . . . . . . . . . . 16 64 A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 16 65 Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 18 66 B.1. A Topology with Multiple Connected Network Functions . . 18 67 B.2. A Topology with an Encapsulated Network Service . . . . . 23 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 70 1. Introduction 72 Today a network offers to its clients far more services than just 73 connectivity across the network. Large variety of physical, logical 74 and/or virtual service functions, network functions and transport 75 functions (collectively named in this document as SFs) could be 76 allocated for and assigned to a client. As described in 77 [I-D.bryskin-teas-use-cases-sf-aware-topo-model], there are some 78 important use cases, in which the network needs to represent to the 79 client SFs at the client's disposal as topological elements in 80 relation to other elements of a topology (i.e. nodes, links, link and 81 tunnel termination points) used by the network to describe itself to 82 the client. Not only would such information allow for the client to 83 auto-discover the network's SFs available for the services 84 provisioned for the client, it would also allow for the client 85 selecting the SFs, duel-optimizing the selection on the SF location 86 on the network and connectivity means (e.g. TE tunnels) to inter- 87 connect the SFs. Consequently thus would give to both the network 88 and the client powerful means for the service function chain (SFC 89 [RFC7498] [RFC7665]) negotiation to achieve most efficient and cost 90 effective (from the network point of view) and most optimal yet 91 satisfying all necessary constraints of SFCs(from the client's point 92 of view). 94 This document defines a YANG data model that allows service functions 95 to be represented along with TE topology elements. 97 1.1. Terminology 99 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14, [RFC2119]. 104 The following terms are defined in [RFC7950] and are not redefined 105 here: 107 o augment 109 o data model 111 o data node 113 1.2. Tree Diagrams 115 A simplified graphical representation of the data model is presented 116 in this document, by using the tree format defined in 117 [I-D.ietf-netmod-yang-tree-diagrams]. 119 1.3. Prefixes in Data Node Names 121 In this document, names of data nodes, actions, and other data model 122 objects are often used without a prefix, as long as it is clear from 123 the context in which YANG module each name is defined. Otherwise, 124 names are prefixed using the standard prefix associated with the 125 corresponding YANG module, as shown in Table 1. 127 +--------+------------------+-----------------------------------+ 128 | Prefix | YANG module | Reference | 129 +--------+------------------+-----------------------------------+ 130 | inet | ietf-inet-types | [RFC6991] | 131 | nw | ietf-network | [I-D.ietf-i2rs-yang-network-topo] | 132 | nt | ietf-network- | [I-D.ietf-i2rs-yang-network-topo] | 133 | | topology | | 134 | tet | ietf-te-topology | [I-D.ietf-teas-yang-te-topo] | 135 +--------+------------------+-----------------------------------+ 137 Table 1: Prefixes and Corresponding YANG Modules 139 2. Modeling Considerations 141 The model introduced in this document is an augmentation of the TE 142 Topology model defined in [I-D.ietf-teas-yang-te-topo]. SFs are 143 modeled as child elements of a TE node similarly to how Link 144 Termination Points (LTPs) and Tunnel Termination Points (TTPs) are 145 modeled in the TE Topology model. The SFs are defined as opaque 146 objects identified via topology unique service-function-id's. Each 147 SF has one or more Connection Points (CPs) identified via SF-unique 148 sf-connection-point-id's, over which the SF could be connected to 149 other SFs resided on the same TE node, as well as to other elements 150 of the TE node, in particular, to the node's LTPs and/or TTPs. An 151 interested client may use service-function-id's to look up the SFs in 152 TOSCA or YANG data store(s) defined by [ETSI-NFV-MAN] to retrieve the 153 details of the SFs, for example, to understand the SF's mutual 154 substitutability. 156 The TE Topology model introduces a concept of Connectivity Matrix 157 (CM), and uses the CM to describe which and at what costs a TE node's 158 LTPs could be inter-connected internally across the TE node. The 159 model defined in this document heavily uses the same concept to 160 describe the SF connectivity via introducing 3 additional CMs: 162 1. SF2SF CM. This CM describes which pairs of SFs could be locally 163 inter-connected, and, if yes, in which direction, via which CPs 164 and at what costs. In other words, the SF2SF CM describes how 165 SFs residing on the same TE node could be inter-connected into 166 local from the TE node's perspective SFCs; 168 2. SF2LTP CM. This CM describes how, in which direction and at what 169 costs the TE node's SFs could be connected to the TE node's LTPs 170 and hence to SFs residing on neighboring TE nodes that are 171 connected to LTPs at the remote ends of corresponding TE links; 173 3. SF2TTP CM. This CM describes how, in which direction and at what 174 costs the TE node's SFs could be connected to the TE node's TTPs 175 and hence to SFs residing on other TE nodes on the topology that 176 could be inter-connected with the TE node in question via TE 177 tunnels terminated by the corresponding TTPs. 179 In addition to SF2SF CM, the local SF chaining could be described 180 with the help of ETSI models Virtual Links (VLs) [ETSI-NFV-MAN]. 181 This option is especially useful when the costs of the local chaining 182 are negligible as compared to ones of the end-to-end SFCs said local 183 SFCs are part of. 185 3. Model Structure 187 module: ietf-te-topology-sf 188 augment /nw:networks/nw:network/nw:network-types/tet:te-topology: 189 +--rw sf! 190 augment /nw:networks/nw:network/nw:node/tet:te 191 /tet:te-node-attributes: 192 +--rw service-function 193 +--rw connectivity-matrices 194 | +--rw connectivity-matrix* [id] 195 | +--rw id uint32 196 | +--rw from 197 | | +--rw service-function-id? string 198 | | +--rw sf-connection-point-id? string 199 | +--rw to 200 | | +--rw service-function-id? string 201 | | +--rw sf-connection-point-id? string 202 | +--rw enabled? boolean 203 | +--rw direction? connectivity-direction 204 | +--rw virtual-link-id? string 205 +--rw link-terminations 206 +--rw link-termination* [id] 207 +--rw id uint32 208 +--rw from 209 | +--rw tp-ref? -> ../../../../../../.. 210 /nt:termination-point/tp-id 211 +--rw to 212 | +--rw service-function-id? string 213 | +--rw sf-connection-point-id? string 214 +--rw enabled? boolean 215 +--rw direction? connectivity-direction 216 augment /nw:networks/nw:network/nw:node/tet:te 217 /tet:information-source-entry: 218 +--ro service-function 219 +--ro connectivity-matrices 220 | +--ro connectivity-matrix* [id] 221 | +--ro id uint32 222 | +--ro from 223 | | +--ro service-function-id? string 224 | | +--ro sf-connection-point-id? string 225 | +--ro to 226 | | +--ro service-function-id? string 227 | | +--ro sf-connection-point-id? string 228 | +--ro enabled? boolean 229 | +--ro direction? connectivity-direction 230 | +--ro virtual-link-id? string 231 +--ro link-terminations 232 +--ro link-termination* [id] 233 +--ro id uint32 234 +--ro from 235 +--ro to 236 | +--ro service-function-id? string 237 | +--ro sf-connection-point-id? string 238 +--ro enabled? boolean 239 +--ro direction? connectivity-direction 240 augment /nw:networks/nw:network/nw:node/tet:te 242 /tet:tunnel-termination-point: 243 +--rw service-function 244 +--rw tunnel-terminations 245 +--rw tunnel-termination* [id] 246 +--rw id uint32 247 +--rw service-function-id? string 248 +--rw sf-connection-point-id? string 249 +--rw enabled? boolean 250 +--rw direction? connectivity-direction 252 4. YANG Modules 254 file "ietf-te-topology-sf@2018-02-27.yang" 255 module ietf-te-topology-sf { 256 yang-version 1; 257 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf"; 259 prefix "tet-sf"; 261 import ietf-network { 262 prefix "nw"; 263 } 265 import ietf-network-topology { 266 prefix "nt"; 267 } 269 import ietf-te-topology { 270 prefix "tet"; 271 } 273 organization 274 "Traffic Engineering Architecture and Signaling (TEAS) 275 Working Group"; 277 contact 278 "WG Web: 279 WG List: 281 Editors: Igor Bryskin 282 284 Xufeng Liu 285 "; 287 description 288 "Network service and function aware aware TE topology model. 290 Copyright (c) 2018 IETF Trust and the persons identified as 291 authors of the code. All rights reserved. 293 Redistribution and use in source and binary forms, with or 294 without modification, is permitted pursuant to, and subject to 295 the license terms contained in, the Simplified BSD License set 296 forth in Section 4.c of the IETF Trust's Legal Provisions 297 Relating to IETF Documents 298 (http://trustee.ietf.org/license-info)."; 300 revision 2018-02-27 { 301 description "Initial revision"; 302 reference "TBD"; 303 } 305 /* 306 * Typedefs 307 */ 308 typedef connectivity-direction { 309 type enumeration { 310 enum "to" { 311 description 312 "The direction is uni-directional, towards the 'to' 313 entity direction."; 314 } 315 enum "from" { 316 description 317 "The direction is uni-directional, from the 'to' 318 entity direction."; 319 } 320 enum "bidir" { 321 description 322 "The direction is bi-directional."; 323 } 324 } 325 description 326 "A type used to indicates whether a connectivity is 327 uni-directional, or bi-directional. If the relation is 328 uni-directional, the value of this type indicates the 329 direction."; 330 } // connectivity-direction 332 /* 333 * Groupings 334 */ 335 grouping service-function-node-augmentation { 336 description 337 "Augmenting a TE node to be network service and function 338 aware."; 339 container service-function { 340 description 341 "Containing attributes related to network services and 342 network functions"; 343 container connectivity-matrices { 344 description 345 "Connectivity relations between network services/functions 346 on a TE node, which can be either abstract or physical."; 347 reference 348 "ETSI GS NFV-MAN 01: Network Functions Virtualisation 349 (NFV); Management and Orchestration. 350 RFC7665: Service Function Chaining (SFC) Architecture."; 351 list connectivity-matrix { 352 key "id"; 353 description 354 "Represents the connectivity relations between network 355 services/functions on a TE node."; 356 leaf id { 357 type uint32; 358 description "Identifies the connectivity-matrix entry."; 359 } 361 container from { 362 description 363 "Reference to the source network service or 364 network function."; 365 leaf service-function-id { 366 type string; 367 description 368 "Reference to a network service or a network 369 function."; 370 } 371 leaf sf-connection-point-id { 372 type string; 373 description 374 "Reference to a connection point on a network 375 service or a network function."; 376 } 377 } // from 378 container to { 379 description 380 "Reference to the destination network service or 381 network function."; 382 leaf service-function-id { 383 type string; 384 description 385 "Reference to a network service or a network 386 function."; 387 } 388 leaf sf-connection-point-id { 389 type string; 390 description 391 "Reference to a connection point on a network 392 service or a network function."; 393 } 394 } // to 395 leaf enabled { 396 type boolean; 397 description 398 "'true' if this connectivity entry is enabled."; 399 } 400 leaf direction { 401 type connectivity-direction; 402 description 403 "Indicates whether this connectivity is 404 uni-directional, or bi-directional. If the 405 relation is uni-directional, the value of 406 this leaf indicates the direction."; 407 } 408 leaf virtual-link-id { 409 type string; 410 description 411 "Reference to a virtual link that models this 412 conectivity relation in the network function 413 model."; 414 } 415 } // connectivity-matrix 416 } // connectivity-matrices 418 container link-terminations { 419 description 420 "Connectivity relations between network services/functions 421 and link termination points on a TE node, which can be 422 either abstract or physical."; 423 reference 424 "ETSI GS NFV-MAN 01: Network Functions Virtualisation 425 (NFV); Management and Orchestration. 426 RFC7665: Service Function Chaining (SFC) Architecture."; 427 list link-termination { 428 key "id"; 429 description 430 "Each entry of the list represents the connectivity 431 relation between a network service/function and 432 a link termination point on a TE node."; 433 leaf id { 434 type uint32; 435 description "Identifies the termination entry."; 436 } 438 container from { 439 description 440 "Reference to the link termination point."; 441 } // from 442 container to { 443 description 444 "Reference to the network service or network 445 function."; 446 leaf service-function-id { 447 type string; 448 description 449 "Reference to a network service or a network 450 function."; 451 } 452 leaf sf-connection-point-id { 453 type string; 454 description 455 "Reference to a connection point on a network 456 service or a network function."; 457 } 458 } // to 459 leaf enabled { 460 type boolean; 461 description 462 "'true' if this connectivity entry is enabled."; 463 } 464 leaf direction { 465 type connectivity-direction; 466 description 467 "Indicates whether this connectivity is 468 uni-directional, or bi-directional. If the 469 relation is uni-directional, the value of 470 this leaf indicates the direction."; 471 } 472 } // link-termination 473 } 474 } 475 } // service-function-node-augmentation 477 grouping service-function-ttp-augmentation { 478 description 479 "Augmenting a tunnel termination point to be network service 480 aware."; 481 container service-function { 482 description 483 "Containing attributes related to network services and 484 network functions"; 485 container tunnel-terminations { 486 description 487 "Connectivity relations between network services/functions 488 and tunnel termination points on a TE node, which can be 489 either abstract or physical."; 490 reference 491 "ETSI GS NFV-MAN 01: Network Functions Virtualisation 492 (NFV); Management and Orchestration. 493 RFC7665: Service Function Chaining (SFC) Architecture."; 494 list tunnel-termination { 495 key "id"; 496 description 497 "Each entry of the list represents the connectivity 498 relation between a network service/function and 499 a tunnel termination point on a TE node."; 500 leaf id { 501 type uint32; 502 description "Identifies the termination entry."; 503 } 505 leaf service-function-id { 506 type string; 507 description 508 "Reference to a network service or a network 509 function."; 510 } 511 leaf sf-connection-point-id { 512 type string; 513 description 514 "Reference to a connection point on a network 515 service or a network function."; 516 } 517 leaf enabled { 518 type boolean; 519 description 520 "'true' if this connectivity entry is enabled."; 521 } 522 leaf direction { 523 type connectivity-direction; 524 description 525 "Indicates whether this connectivity is 526 uni-directional, or bi-directional. If the 527 relation is uni-directional, the value of 528 this leaf indicates the direction."; 529 } 530 } // link-termination 531 } 532 } 533 } // service-function-ttp-augmentation 535 grouping sf-topology-type { 536 description 537 "Identifies the SF aware TE topology type."; 538 container sf { 539 presence "Indidates that the TE topology is SF aware."; 540 description 541 "Its presence identifies that the TE topology is SF aware."; 542 } 543 } // sf-topology-type 545 /* 546 * Augmentations 547 */ 548 /* Augmentations to network-types/te-topology */ 549 augment "/nw:networks/nw:network/nw:network-types/" 550 + "tet:te-topology" { 551 description 552 "Defines the SF aware TE topology type."; 553 uses sf-topology-type; 554 } 556 /* Augmentations to te-node-attributes */ 557 augment "/nw:networks/nw:network/nw:node/tet:te/" 558 + "tet:te-node-attributes" { 559 description 560 "Parameters for SF aware TE topology."; 561 uses service-function-node-augmentation; 562 } 564 augment "/nw:networks/nw:network/nw:node/tet:te/" 565 + "tet:information-source-entry" { 566 description 567 "Parameters for SF aware TE topology."; 568 uses service-function-node-augmentation; 569 } 571 /* Augmentations to tunnel-termination-point */ 572 augment "/nw:networks/nw:network/nw:node/tet:te/" 573 + "tet:tunnel-termination-point" { 574 description 575 "Parameters for SF aware TE topology."; 577 uses service-function-ttp-augmentation; 578 } 580 /* Augmentations to connectivity-matrix */ 581 augment "/nw:networks/nw:network/nw:node/tet:te/" 582 + "tet:te-node-attributes/tet-sf:service-function/" 583 + "tet-sf:link-terminations/tet-sf:link-termination/" 584 + "tet-sf:from" { 585 description 586 "Add reference to the link termination point. 587 This portion cannot be shared with the state module."; 588 leaf tp-ref { 589 type leafref { 590 path "../../../../../../../nt:termination-point/" 591 + "nt:tp-id"; 592 } 593 description 594 "Reference to the link termination point."; 595 } 596 } 597 } 598 600 5. IANA Considerations 602 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 603 actual RFC number (and remove this note). 605 This document registers the following namespace URIs in the IETF XML 606 registry [RFC3688]: 608 -------------------------------------------------------------------- 609 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf 610 Registrant Contact: The IESG. 611 XML: N/A, the requested URI is an XML namespace. 612 -------------------------------------------------------------------- 614 -------------------------------------------------------------------- 615 URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state 616 Registrant Contact: The IESG. 617 XML: N/A, the requested URI is an XML namespace. 618 -------------------------------------------------------------------- 620 This document registers the following YANG modules in the YANG Module 621 Names registry [RFC7950]: 623 -------------------------------------------------------------------- 624 name: ietf-te-topology-sf 625 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet 626 prefix: tet-sf 627 reference: RFC XXXX 628 -------------------------------------------------------------------- 630 -------------------------------------------------------------------- 631 name: ietf-te-topology-sf-state 632 namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-packet-state 633 prefix: tet-sf-s 634 reference: RFC XXXX 635 -------------------------------------------------------------------- 637 6. Security Considerations 639 The configuration, state, action and notification data defined in 640 this document are designed to be accessed via the NETCONF protocol 641 [RFC6241]. The data-model by itself does not create any security 642 implications. The security considerations for the NETCONF protocol 643 are applicable. The NETCONF protocol used for sending the data 644 supports authentication and encryption. 646 7. References 648 7.1. Normative References 650 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 651 Requirement Levels", BCP 14, RFC 2119, 652 DOI 10.17487/RFC2119, March 1997, 653 . 655 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 656 and A. Bierman, Ed., "Network Configuration Protocol 657 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 658 . 660 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 661 RFC 6991, DOI 10.17487/RFC6991, July 2013, 662 . 664 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 665 RFC 7950, DOI 10.17487/RFC7950, August 2016, 666 . 668 [ETSI-NFV-MAN] 669 ETSI, "Network Functions Virtualisation (NFV); Management 670 and Orchestration", ETSI GS NFV-MAN 001 V1.1.1, December 671 2014. 673 [I-D.bryskin-teas-use-cases-sf-aware-topo-model] 674 Bryskin, I., Liu, X., Guichard, J., Lee, Y., Contreras, 675 L., Ceccarelli, D., and J. Tantsura, "Use Cases for SF 676 Aware Topology Models", draft-bryskin-teas-use-cases-sf- 677 aware-topo-model-03 (work in progress), March 2018. 679 [I-D.ietf-i2rs-yang-network-topo] 680 Clemm, A., Medved, J., Varga, R., Bahadur, N., 681 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 682 Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in 683 progress), December 2017. 685 [I-D.ietf-teas-yang-te-topo] 686 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 687 O. Dios, "YANG Data Model for Traffic Engineering (TE) 688 Topologies", draft-ietf-teas-yang-te-topo-15 (work in 689 progress), February 2018. 691 [I-D.ietf-netmod-revised-datastores] 692 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 693 and R. Wilton, "Network Management Datastore 694 Architecture", draft-ietf-netmod-revised-datastores-10 695 (work in progress), January 2018. 697 7.2. Informative References 699 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 700 Service Function Chaining", RFC 7498, 701 DOI 10.17487/RFC7498, April 2015, 702 . 704 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 705 Chaining (SFC) Architecture", RFC 7665, 706 DOI 10.17487/RFC7665, October 2015, 707 . 709 [I-D.ietf-netmod-yang-tree-diagrams] 710 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 711 ietf-netmod-yang-tree-diagrams-06 (work in progress), 712 February 2018. 714 Appendix A. Companion YANG Model for Non-NMDA Compliant Implementations 716 The YANG module ietf-te-topology-sf defined in this document is 717 designed to be used in conjunction with implementations that support 718 the Network Management Datastore Architecture (NMDA) defined in 719 [I-D.ietf-netmod-revised-datastores]. In order to allow 720 implementations to use the model even in cases when NMDA is not 721 supported, the following companion module, ietf-te-topology-sf-state, 722 is defined as state model, which mirrors the module ietf-te-topology- 723 sf defined earlier in this document. However, all data nodes in the 724 companion module are non-configurable, to represent the applied 725 configuration or the derived operational states. 727 The companion module, ietf-te-topology-sf-state, is redundant and 728 SHOULD NOT be supported by implementations that support NMDA. 730 As the structure of the companion module mirrors that of the 731 coorespinding NMDA model, the YANG tree of the companion module is 732 not depicted separately. 734 A.1. SF Aware TE Topology State Module 736 file "ietf-te-topology-sf-state@2018-02-27.yang" 737 module ietf-te-topology-sf-state { 738 yang-version 1; 739 namespace "urn:ietf:params:xml:ns:yang:ietf-te-topology-sf-state"; 741 prefix "tet-sf-s"; 743 import ietf-te-topology-sf { 744 prefix "tet-sf"; 745 } 747 import ietf-network-state { 748 prefix "nw-s"; 749 } 751 import ietf-network-topology-state { 752 prefix "nt-s"; 753 } 755 import ietf-te-topology-state { 756 prefix "tet-s"; 757 } 759 organization 760 "Traffic Engineering Architecture and Signaling (TEAS) 761 Working Group"; 763 contact 764 "WG Web: 765 WG List: 767 Editors: Igor Bryskin 768 770 Xufeng Liu 771 "; 773 description 774 "Network service and function aware aware TE topology operational 775 state model for non-NMDA compliant implementations. 777 Copyright (c) 2018 IETF Trust and the persons identified as 778 authors of the code. All rights reserved. 780 Redistribution and use in source and binary forms, with or 781 without modification, is permitted pursuant to, and subject to 782 the license terms contained in, the Simplified BSD License set 783 forth in Section 4.c of the IETF Trust's Legal Provisions 784 Relating to IETF Documents 785 (http://trustee.ietf.org/license-info)."; 787 revision 2018-02-27 { 788 description "Initial revision"; 789 reference "TBD"; 790 } 792 /* 793 * Augmentations 794 */ 795 /* Augmentations to network-types/te-topology */ 796 augment "/nw-s:networks/nw-s:network/nw-s:network-types/" 797 + "tet-s:te-topology" { 798 description 799 "Defines the SF aware TE topology type."; 800 uses tet-sf:sf-topology-type; 801 } 803 /* Augmentations to connectivity-matrix */ 804 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 805 + "tet-s:te-node-attributes" { 806 description 807 "Parameters for SF aware TE topology."; 808 uses tet-sf:service-function-node-augmentation; 810 } 812 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 813 + "tet-s:information-source-entry" { 814 description 815 "Parameters for SF aware TE topology."; 816 uses tet-sf:service-function-node-augmentation; 817 } 819 /* Augmentations to tunnel-termination-point */ 820 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 821 + "tet-s:tunnel-termination-point" { 822 description 823 "Parameters for SF aware TE topology."; 824 uses tet-sf:service-function-ttp-augmentation; 825 } 827 /* Augmentations to connectivity-matrix */ 828 augment "/nw-s:networks/nw-s:network/nw-s:node/tet-s:te/" 829 + "tet-s:te-node-attributes/tet-sf-s:service-function/" 830 + "tet-sf-s:link-terminations/tet-sf-s:link-termination/" 831 + "tet-sf-s:from" { 832 description 833 "Add reference to the link termination point. 834 This portion cannot be shared with the state module."; 835 leaf tp-ref { 836 type leafref { 837 path "../../../../../../../nt-s:termination-point/" 838 + "nt-s:tp-id"; 839 } 840 description 841 "Reference to the link termination point."; 842 } 843 } 844 } 845 847 Appendix B. Data Examples 849 B.1. A Topology with Multiple Connected Network Functions 850 Node-1 851 +----o--o--------------------------o-------+ 852 | | | | | 853 | \__/ \__ | 854 | *\/ TTP-1 * * * * * * * * * *\/* | 855 LTP-4 |* * * * TTP-2 * | LTP-1 856 o------------*-----------------------------o 857 | * * | 858 LTP-3 |* * * * * *| LTP-2 859 o--- -----o 860 | \ / | 861 | \ / | 862 | \ CP01 CP02/ | 863 | +----o--------------------------o------+ | 864 | | VL1| VL4| | | 865 | | |CP11 |CP33 | | 866 | | +-o--+ +----+ +-o--+ | | 867 | | |VNF1| |VNF2| |VNF3| | | 868 | | +-o-o+ VL2 +--o-+ VL2 +-o-o+ | | 869 | |CP12| |\----------/ \---------/| |CP32| | 870 | | | |CP13 CP21 CP31| | | | 871 | | | | VL2 | | | | 872 | | | +------------------------+ | | | 873 | | +----------------------------+ | | 874 | | VL3 | | 875 | | Network Service 1 | | 876 | +--------------------------------------+ | 877 +------------------------------------------+ 879 The configuration instance data for Node-1 in the above figure could 880 be as follows: 882 { 883 "networks": { 884 "network": [ 885 { 886 "network-types": { 887 "te-topology": { 888 "sf": {} 889 } 890 }, 891 "network-id": "network-sf-aware", 892 "provider-id": 201, 893 "client-id": 300, 894 "te-topology-id": "te-topology:network-sf-aware", 895 "node": [ 896 { 897 "node-id": "Node-1", 898 "te-node-id": "2.0.1.1", 899 "te": { 900 "te-node-attributes": { 901 "domain-id": 1, 902 "is-abstract": [null], 903 "connectivity-matrices": { 904 }, 905 "service-function": { 906 "connectivity-matrices": { 907 "connectivity-matrix": [ 908 { 909 "id": 10, 910 "from": { 911 "service-function-id": "Network Service 1", 912 "sf-connection-point-id": "CP01" 913 }, 914 "to": { 915 "service-function-id": "VNF1", 916 "sf-connection-point-id": "CP11" 917 } 918 "direction": "bidir", 919 "virtual-link-id": "VL1" 920 }, 921 { 922 "id": 13, 923 "from": { 924 "service-function-id": "VNF1", 925 "sf-connection-point-id": "CP12" 926 }, 927 "to": { 928 "service-function-id": "VNF3", 929 "sf-connection-point-id": "CP32" 930 } 931 "direction": "bidir", 932 "virtual-link-id": "VL3" 933 }, 934 { 935 "id": 12, 936 "from": { 937 "service-function-id": "VNF1", 938 "sf-connection-point-id": "CP13" 939 }, 940 "to": { 941 "service-function-id": "VNF2", 942 "sf-connection-point-id": "CP21" 943 } 944 "direction": "bidir", 945 "virtual-link-id": "VL2" 947 }, 948 { 949 "id": 23, 950 "from": { 951 "service-function-id": "VNF2", 952 "sf-connection-point-id": "CP21" 953 }, 954 "to": { 955 "service-function-id": "VNF3" 956 "sf-connection-point-id": "CP31" 957 } 958 "direction": "bidir", 959 "virtual-link-id": "VL2" 960 }, 961 { 962 "id": 30, 963 "from": { 964 "service-function-id": "Network Service 1", 965 "sf-connection-point-id": "CP02" 966 }, 967 "to": { 968 "service-function-id": "VNF3", 969 "sf-connection-point-id": "CP33" 970 } 971 "direction": "bidir", 972 "virtual-link-id": "VL4" 973 } 974 ] 975 }, 976 "link-terminations": { 977 "link-termination": [ 978 { 979 "id": 2, 980 "from": { 981 "tp-ref": "LTP-2" 982 }, 983 "to": { 984 "service-function-id": "Network Service 1", 985 "sf-connection-point-id": "CP02" 986 } 987 "direction": "bidir" 988 }, 989 { 990 "id": 3, 991 "from": { 992 "tp-ref": "LTP-3" 993 }, 994 "to": { 995 "service-function-id": "Network Service 1", 996 "sf-connection-point-id": "CP01" 997 } 998 "direction": "bidir" 999 } 1000 ] 1001 } 1002 } 1003 } 1004 "tunnel-termination-point": [ 1005 { 1006 "tunnel-tp-id": 10001, 1007 "name": "TTP-1", 1008 "service-function-terminations": { 1009 } 1010 }, 1011 { 1012 "tunnel-tp-id": 10002, 1013 "name": "TTP-2", 1014 "service-function-terminations": { 1015 } 1016 } 1017 ] 1018 }, 1019 "termination-point": [ 1020 { 1021 "tp-id": "LTP-1", 1022 "te-tp-id": 10001 1023 "te": { 1024 "interface-switching-capability": [ 1025 { 1026 "switching-capability": "switching-l2sc", 1027 "encoding": "lsp-encoding-ethernet" 1028 } 1029 ] 1030 } 1031 }, 1032 { 1033 "tp-id": "LTP-2", 1034 "te-tp-id": 10002 1035 "te": { 1036 "interface-switching-capability": [ 1037 { 1038 "switching-capability": "switching-l2sc", 1039 "encoding": "lsp-encoding-ethernet" 1040 } 1041 ] 1042 } 1044 }, 1045 { 1046 "tp-id": "LTP-3", 1047 "te-tp-id": 10003 1048 "te": { 1049 "interface-switching-capability": [ 1050 { 1051 "switching-capability": "switching-l2sc", 1052 "encoding": "lsp-encoding-ethernet" 1053 } 1054 ] 1055 } 1056 }, 1057 { 1058 "tp-id": "LTP-4", 1059 "te-tp-id": 10004 1060 "te": { 1061 "interface-switching-capability": [ 1062 { 1063 "switching-capability": "switching-l2sc", 1064 "encoding": "lsp-encoding-ethernet" 1065 } 1066 ] 1067 } 1068 } 1069 ] 1070 } 1071 ] 1072 } 1073 ] 1074 } 1075 } 1077 B.2. A Topology with an Encapsulated Network Service 1079 In this example, a network service consists of several inter- 1080 connected network functions (NFs), and is represented by this model 1081 as an encapsulated opaque object without the details between its 1082 internals. 1084 Node-1 1085 +----o--o--------------------------o-------+ 1086 | | | | | 1087 | \__/ \__ | 1088 | *\/ TTP-1 * * * * * * * * * *\/* | 1089 LTP-4 |* * * * TTP-2 * | LTP-1 1090 o------------*-----------------------------o 1091 | * * | 1092 LTP-3 |* * * * * *| LTP-2 1093 o--- -----o 1094 | \ / | 1095 | \ / | 1096 | \ CP01 CP02/ | 1097 | +----o--------------------------o------+ | 1098 | | | | 1099 | | Network Service 1 | | 1100 | +--------------------------------------+ | 1101 +------------------------------------------+ 1103 The configuration instance data for Node-1 in the above figure could 1104 be as follows: 1106 { 1107 "networks": { 1108 "network": [ 1109 { 1110 "network-types": { 1111 "te-topology": { 1112 "sf": {} 1113 } 1114 }, 1115 "network-id": "network-sf-aware", 1116 "provider-id": 201, 1117 "client-id": 300, 1118 "te-topology-id": "te-topology:network-sf-aware", 1119 "node": [ 1120 { 1121 "node-id": "Node-1", 1122 "te-node-id": "2.0.1.1", 1123 "te": { 1124 "te-node-attributes": { 1125 "domain-id": 1, 1126 "is-abstract": [null], 1127 "connectivity-matrices": { 1128 }, 1129 "service-function": { 1130 "connectivity-matrices": { 1131 }, 1132 "link-terminations": { 1133 "link-termination": [ 1134 { 1135 "id": 2, 1136 "from": { 1137 "tp-ref": "LTP-2" 1138 }, 1139 "to": { 1140 "service-function-id": "Network Service 1", 1141 "sf-connection-point-id": "CP02" 1142 } 1143 "direction": "bidir" 1144 }, 1145 { 1146 "id": 3, 1147 "from": { 1148 "tp-ref": "LTP-3" 1149 }, 1150 "to": { 1151 "service-function-id": "Network Service 1", 1152 "sf-connection-point-id": "CP01" 1153 } 1154 "direction": "bidir" 1155 } 1156 ] 1157 } 1158 } 1159 } 1160 "tunnel-termination-point": [ 1161 { 1162 "tunnel-tp-id": 10001, 1163 "name": "TTP-1", 1164 "service-function-terminations": { 1165 } 1166 }, 1167 { 1168 "tunnel-tp-id": 10002, 1169 "name": "TTP-2", 1170 "service-function-terminations": { 1171 } 1172 } 1173 ] 1174 }, 1175 "termination-point": [ 1176 { 1177 "tp-id": "LTP-1", 1178 "te-tp-id": 10001 1179 "te": { 1180 "interface-switching-capability": [ 1181 { 1182 "switching-capability": "switching-l2sc", 1183 "encoding": "lsp-encoding-ethernet" 1184 } 1185 ] 1186 } 1187 }, 1188 { 1189 "tp-id": "LTP-2", 1190 "te-tp-id": 10002 1191 "te": { 1192 "interface-switching-capability": [ 1193 { 1194 "switching-capability": "switching-l2sc", 1195 "encoding": "lsp-encoding-ethernet" 1196 } 1197 ] 1198 } 1199 }, 1200 { 1201 "tp-id": "LTP-3", 1202 "te-tp-id": 10003 1203 "te": { 1204 "interface-switching-capability": [ 1205 { 1206 "switching-capability": "switching-l2sc", 1207 "encoding": "lsp-encoding-ethernet" 1208 } 1209 ] 1210 } 1211 }, 1212 { 1213 "tp-id": "LTP-4", 1214 "te-tp-id": 10004 1215 "te": { 1216 "interface-switching-capability": [ 1217 { 1218 "switching-capability": "switching-l2sc", 1219 "encoding": "lsp-encoding-ethernet" 1220 } 1221 ] 1222 } 1223 } 1224 ] 1225 } 1226 ] 1227 } 1229 ] 1230 } 1231 } 1233 Authors' Addresses 1235 Igor Bryskin 1236 Huawei Technologies 1238 EMail: Igor.Bryskin@huawei.com 1240 Xufeng Liu 1241 Jabil 1243 EMail: Xufeng_Liu@jabil.com