idnits 2.17.00 (12 Aug 2021) /tmp/idnits42479/draft-wang-i2rs-yang-service-topo-dm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 5 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 231 has weird spacing: '...ork-ref lea...' == Line 235 has weird spacing: '...ork-ref lea...' == Line 264 has weird spacing: '... rw for c...' == Line 265 has weird spacing: '... ro for n...' == Line 305 has weird spacing: '...fier-id node-...' == (11 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 5, 2015) is 2627 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: 'Z' is mentioned on line 98, but not defined == Unused Reference: 'RFC6020' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'RFC6536' is defined on line 646, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-clemm-i2rs-yang-network-topo-02 == Outdated reference: draft-ietf-idr-ls-distribution has been published as RFC 7752 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS Z. Wang 3 Internet-Draft Q. Wu 4 Intended status: Standards Track S. Hares 5 Expires: September 6, 2015 Huawei 6 March 5, 2015 8 A YANG Data Model for Service Topology 9 draft-wang-i2rs-yang-service-topo-dm-01 11 Abstract 13 This document defines a YANG data model for Service Function Forward 14 Topology. This I2RS yang data model is part of the I2RS protocol 15 independent topology set of data models. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 6, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4 53 3. SFF Topology Data Model . . . . . . . . . . . . . . . . . . . 5 54 3.1. Model Overview . . . . . . . . . . . . . . . . . . . . . 5 55 3.2. SFF Topology Yang . . . . . . . . . . . . . . . . . . . . 7 56 3.3. SFF topology Model Description . . . . . . . . . . . . . 8 57 4. SFF Topology YANG Module . . . . . . . . . . . . . . . . . . 11 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 60 7. Normative References . . . . . . . . . . . . . . . . . . . . 15 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 63 1. Introduction 65 An overlay network consists of tunnels established among designated 66 nodes to traverse segments of networks. 68 This draft describes a protocol independent topology of service 69 function forwarder nodes which augments the 70 [I-D.clemm-i2rs-yang-network-topo] model as a specific service 71 topology (SFF). Figure 1 shows how the SFF is an extension of the 72 service forwarded nodes. 74 +---------------------------------------+ 75 / _[X1]_ "Service" / 76 / _/ : \_ (SFF) / 77 / _/ : \_ / 78 / _/ : \_ / 79 / / : \ / 80 / [X2]__________________[X3] / 81 +---------:--------------:------:-------+ 82 : : : 83 +----:--------------:----:--------------+ 84 / : : : "L3" / 85 / : : : / 86 / : : : / 87 / [Y1]_____________[Y2] tunnels / 88 / * * * / 89 / * * * / 90 +--------------*-------------*--*-------+ 91 * * * 92 +--------*----------*----*--------------+ 93 / [Z1]_______________[Z1] "Optical" / 94 / \_ * _/ / 95 / \_ * _/ / 96 / \_ * _/ / 97 / \ * / / 98 / [Z] / 99 +---------------------------------------+ 101 Figure 1 103 There can be many types of protocol independent service topologies 104 such as: L2VPN, L3VPN, MPLS, EVPN, and others. The Service Function 105 Chaining services consists of a topology of Service Function 106 Forwarder nodes connected by links which are tunnels that connect the 107 service nodes. Each Service Forwarder node has service functions 108 attached to the Service Function Forwarder node. 110 The SFF topology is built on top of one or several underlying 111 networks (see figure 1). In case multi-tenancy is needed, multiple 112 SFF topologies can be built on top of the same underlying network. 113 Each tenant can only see its own service topology. But all the 114 tenant's service topology can be mapped into the same L3 network 115 topology. 117 The I2RS protocol independent topologies are abstractions created by 118 the I2RS Client directly or by instructions to I2RS agent to import 119 network topologies or aggregations of the network topology. The I2RS 120 protocol independent L3 topology is created by the client or the 121 clients instruction to import specific information from the I2RS 122 Agent from static configuration or IGPs (E.g. OSPF or ISIS) or 123 information passed in EGPs (e.g. [I-D.ietf-idr-ls-distribution]. 124 Similarly, the protocol independent SFF topology is abstraction of 125 network topology information. Since SFF has no another control plane 126 protocol running on top of the underlying networks, this information 127 will need to be gathered from other sources. 129 This document defines a Yang data model for the SFF protocol 130 independent topology. 132 2. Definitions and Acronyms 134 Datastore: A conceptual store of instantiated management information, 135 with individual data items represented by data nodes which are 136 arranged in hierarchical manner. 138 Data subtree: An instantiated data node and the data nodes that are 139 hierarchically contained within it. 141 NETCONF: Network Configuration Protocol. 143 URI: Uniform Resource Identifier. 145 YANG: A data definition language for NETCONF. 147 Classification: Locally instantiated policy and customer/network/ 148 service profile matching of traffic flows for identification of 149 appropriate outbound forwarding actions. 151 Classifier: An element that performs Classification. 153 Service Function Chain (SFC): A service function chain defines a set 154 of abstract service functions and ordering constraints that must be 155 applied to packets and/or frames selected as a result of 156 classification. 158 Service Function (SF): A function that is responsible for specific 159 treatment of received packets. 161 Service Function Forwarder (SFF): A service function forwarder is 162 responsible for delivering traffic received from the network to one 163 or more connected service functions according to information carried 164 in the SFC encapsulation, as well as handling traffic coming back 165 from the SF. 167 Metadata: provides the ability to exchange context information 168 between classifiers and SFs and among SFs. 170 Service Function Path (SFP): The SFP provides a level of indirection 171 between the fully abstract notion of service chain as a sequence of 172 abstract service functions to be delivered, and the fully specified 173 notion of exactly which SFF/SFs the packet will visit when it 174 actually traverses the network. 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 178 document are to be interpreted as described in [RFC2119]. 180 3. SFF Topology Data Model 182 This section describe the architecture and the tree diagram of the 183 service topology yang data model. 185 3.1. Model Overview 187 The abstract Topology yang Model contain a set of abstract nodes and 188 a list of abstract links. Service Function Chain Topo yang model and 189 other service topo model can be augumented from the abstract topology 190 model with SFC base topology specifics. 192 The following Figure depicts the relationship of service topology 193 yang model to the abstract topology yang model. 195 +-----------------+ 196 | Abstract | 197 | Topology Model | 198 | | 199 +--------|--------+ 200 | 201 +-----------------------+ 202 | ..... | 203 | 204 +------V----------+ 205 | Service | 206 | Topology models | 207 | | 208 +--------|--------- 209 | 210 +----|------------------------|---+ 211 | | 212 +--------V--------+ +--------V-----------+ 213 |Service Function | | Another protocol | 214 | Forwarder | | Independent Service| 215 | Topology Models | | Topology Models | 216 +-----------------+ +--------------------+ 218 Figure 2 220 The relationship of service topology yang model to the abstract 221 topology yang model 223 The following is the generic topology module 225 module: network 226 +--rw network* [network-id] 227 +--rw network-id network-id 228 +--ro server-provided? boolean 229 +--rw network-types 230 +--rw supporting-network* [network-ref] 231 | +--rw network-ref leafref 232 +--rw node* [node-id] 233 +--rw node-id node-id 234 +--rw supporting-node* [network-ref node-ref] 235 +--rw network-ref leafref 236 +--rw node-ref leafref 238 The service modules augments the network types and this data structures. 239 To provide context for this model, this sample augment for the 240 types is provided (but not normative for this draft). 242 module: Service Topologies 243 augment /nt:network-topology/nt:topology/nt:topology-types 244 +--rw Service-Topologies 245 +--rw SFF-topology 246 +--rw L3VPN-Service-topology 247 +--rw EVPN-Service-topology 249 Figure 3: The structure of the abstract (base) network model 251 3.2. SFF Topology Yang 253 The following figure provide the structure of service topology yang 254 model. Each node is printed as: 256 258 is one of: 259 + for current 260 x for deprecated 261 o for obsolete 263 is one of: 264 rw for configuration data 265 ro for non-configuration data 266 -x for rpcs 267 -n for notification 269 is the name of the node 270 If the node is augmented into the tree from another module, its 271 name is printed as :. 273 is one of: 274 ? for an optional leaf or choice 275 ! for a presence container 276 * for a leaf-list or list 277 [] for a list's keys 279 is the name of the type for leafs and leaf-lists 281 Figure 4 283 3.3. SFF topology Model Description 285 SFF Topology Module 287 module: SFF topology 288 augment /nt:network-topology/nt:topology/nt:topology-types 289 +--rw Service-Topologies 290 +--SFF Topology! 291 augment /nt:network-topology/nt:topology 292 +--rw service-topo-id network-id 293 +--rw service-topology-attributes 294 +--rw node-count uint32 295 +--rw topology-extension! 296 augment /nt:network-topology/nt:topology/nt:node 297 +--rw node-type! 298 | +--rw classifier-node? string 299 | +--rw sf-node? string 300 | +--rw sff-node? string 301 +--rw next-hop*[hop-id] 302 | +--hop-id node-id 303 +--rw node-extension! 304 +--rw classifier-extension! 305 | +--rw classifier-id node-id 306 | +--rw sfc-policy uint32 307 | +--rw sfp! 308 | +--rw sfp-id uint32 309 | +--rw sf-list*[sf-id] 310 | +--rw sf-id node-id 311 | +--rw sff-list*[sff-id] 312 | +--rw sff-id node-id 313 +--rw sf-node-extension! 314 | +--rw sf-id node-id 315 | +--rw sf-node-locator uint32 316 | +--rw sf-type! 317 | | +--rw firewall? uint32 318 | | +--rw loadbalancer? uint32 319 | | +--rw NAT44? uint32 320 | | +--rw NAT64? uint32 321 | | +--rw DPI? uint32 322 | +--rw sf-inventory-data! 323 +--rw sff-node-extension! 324 +--rw sff-id node-id 325 +--rw (sffn-address)? 326 | +--:(ipv4-address) 327 | | +--rw ipv4-address? inet:ipv4-address 328 | +--:(ipv6-address) 329 | +--rw ipv6-address? inet:ipv6-address 330 +--rw sffn-virtual-context! 331 | +--rw context-id uint32 332 +--rw Attached-service-address! 333 | +--rw service-node*[service-node-id] 334 | | +--rw service-node-id node-id 335 | +--rw host-system*[host-system-id] 336 | +--rw host-system-id uint32 337 +--rw customer-support*[customer-id] 338 | +--rw customer-id uint32 339 +--rw customer-service-resource*[customer-resource-id] 340 | +--rw customer-resource-id node-id 341 +--rw sffn-vntopo! 343 Figure 5 345 The service topo yang model contains a service-topology structure. 346 Based on the base model, this can be a list. 348 topology model 350 The generic model contains a topology leaf. The SFF augments the 351 topology types leaf within this topology life with the SFF-topology 352 type. The SFF module also augments the topology with topology-id 353 leaf, and a topology attributes leaf that contains node count leaf 354 and topology-extension container. The node-count leaf can be used to 355 indicate the number of nodes which contained in the service-topology 356 list. The topology-extension container can be used to augment the 357 service topology model by topology specifics. 359 node structure 361 The generic topology structure also contains a node (nt:node), and 362 this structure has been augmented by containers for node type, a 363 next-hop container, and a node-extensions. The node-type container 364 can used to indicate the type node, such classifier, a sf or a sff. 365 The node-extension container can be used to augment the node list by 366 node specifics, for example: classifier extension, sf extension, sff 367 extension. 369 link structure 371 The generic link topology structure contains a link (nt:link) 372 structure, and this generic link structure has been augmented to 373 include a sff-link-type leaf, sff-direction container, and an 374 segment-extension leaf. The segment-extension container can be used 375 to augment the segment list by segment specifics. Such as netconf 376 segment extension, i2rs segment extension. 378 classifier extension 380 In SFC, the classifier is used to locally instantiated policy and 381 customer/network/service profile matching of traffic flows for 382 identification of appropriate outbound forwarding actions. 384 sf-node-extension 386 The sf is a function that is responsible for specific treatment of 387 received packets. As a logical component. 389 sff-node-extension 391 The service function forwarder is responsible for delivering traffic 392 received from the network to one or more connected service functions 393 according to information carried in the SFC encapsulation, as well as 394 handling traffic coming back from the SF. 396 4. SFF Topology YANG Module 398 file "sff-topology.yang" 399 module sff-topology{ 400 yang-version 1; 401 namespace "urn:TBD:params:xml:ns:yang:sff-topology"; 402 prefix "sff-topo"; 404 organization "TBD"; 406 contact 407 "wangzitao@huawei.com"; 409 description 410 "This module defines sff topology yang data model"; 412 import network-topology { 413 prefix "nt"; 414 } 416 import ietf-inet-types { 417 prefix "inet"; 418 } 420 import network { prefix nd; } 422 //import service-topologies{ prefix st;} 424 organization "IETF I2RS Working Group"; 425 contact 426 "wangzitao@huawei.com"; 427 description 428 "This module defines sfc topology yang data model"; 430 typedef node-id { 431 type inet:uri; 432 } 434 augment "/nt:network-topology/nt:topology/nt:topology-types"{ 435 container Service-Topologies{ 436 container SFF-Topology{ 437 description 438 "SFF topology."; 439 } 440 } 441 } 442 augment "/nt:network-topology/nt:topology"{ 443 leaf service-topo-id{ 444 type network-id; 445 } 446 container service-topology-attributes{ 447 leaf node-count{ 448 type uint32; 449 } 450 container topology-extension{ 451 description 452 "can be augment/extension."; 453 } 454 } 455 } 457 augment "/nt:network-topology/nt:topology/nt:node"{ 458 container node-type{ 459 leaf classifier-node{ 460 type string; 461 } 462 leaf sf-node{ 463 type string; 464 } 465 leaf sff-node{ 466 type string; 467 } 468 } 470 list next-hop{ 471 key "hop-id"; 472 leaf hop-id{ 473 type node-id; 474 } 475 } 477 container node-extension{ 478 container classifier-extension{ 479 leaf classifier-id{ 480 type node-id; 481 description 482 "The identifier of the classifier.";} 483 leaf sfc-policy{ 484 type uint32; 485 description 486 "Indicate the policy of sfc.";} 487 container sfp{ 488 description 489 "contains several sfps."; 490 leaf sfp-id{ 491 type uint32; 492 description 493 "The identifier of the sfp.";} 494 list sf-list{ 495 key "sf-id"; 496 leaf sf-id{ 497 type node-id; 498 description 499 "The identifier of the sf which include in the sfp.";} 500 } 501 list sff-list{ 502 key "sff-id"; 503 leaf sff-id{ 504 type node-id; 505 description 506 "The identifier of the sff which include in the sfp.";} 507 } 508 }//end the sfp container 509 } 511 container sf-node-extension{ 512 leaf sf-id{ 513 type node-id; 514 description 515 "The identifier of the service function(sf).";} 516 leaf sf-node-locator{ 517 type uint32; 518 description 519 "To indicate the service function (sf) locator";} 520 container sf-type{ 521 leaf firewall{ 522 type uint32; 523 description 524 "To indicate the service function (sf) is firewall.";} 525 leaf loadbalancer{ 526 type uint32; 527 description 528 "To indicate the service function (sf) is loadbalancer.";} 529 leaf NAT44{ 530 type uint32; 531 description 532 "To indicate the service function (sf) is NAT44.";} 533 leaf NAT64{ 534 type uint32; 535 description 536 "To indicate the service function (sf) is NAT64.";} 537 leaf DPI{ 538 type uint32; 539 description 540 "To indicate the service function (sf) is DPI.";} 541 }//end the sf-type container 542 container sf-inventory-data{ 543 description 544 "The container of the inventory data of service function (sf)."; 545 } 546 } 548 container sff-node-extension{ 549 leaf sff-id{ 550 type node-id; 551 description 552 "The identifier of the service function forward (sff).";} 553 choice sffn-address{ 554 description 555 "The address of the service function forward (sff) node"; 556 case ipv4-address{ 557 leaf ipv4-address{ 558 type inet:ipv4-address;} 559 } 560 case ipv6-address{ 561 leaf ipv6-address{ 562 type inet:ipv6-address;} 563 } 564 }//end the choice sffn-address 565 container sffn-virtual-context{ 566 leaf context-id{ 567 type uint32; 568 description 569 "the identifier of the sffn virtual context.";} 570 } 571 container Attached-service-address{ 572 list service-node{ 573 key "service-node-id"; 574 leaf service-node-id{ 575 type node-id; 576 description 577 "The identifier of the service node.";} 578 }//end the service-node list 579 list host-system{ 580 key "host-system-id"; 581 leaf host-system-id{ 582 type uint32; 583 description 584 "The identifier of the host system.";} 585 }//end the service-node list 587 } //end the attached-service-address container 588 list customer-support{ 589 key "customer-id"; 590 leaf customer-id{ 591 type uint32; 592 description 593 "The identifier of the customer.";} 594 }//end the customer-support list 595 list customer-service-resource{ 596 key "customer-resource-id"; 597 leaf customer-resource-id{ 598 type node-id; 599 description 600 "The identifier of the customer resource.";} 601 }//end the customer-service-resource list 602 container sffn-vntopo{ 603 description 604 "This container can be use to contain the virtual network topology of 605 Sffn. And it can be augment by specific virtual network topology."; 606 } 607 } 608 } 609 } 610 } 611 613 5. Security Considerations 615 TBD. 617 6. IANA Considerations 619 TBD. 621 7. Normative References 623 [I-D.clemm-i2rs-yang-network-topo] 624 Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N., 625 and H. Ananthakrishnan, "A Data Model for Network 626 Topologies", draft-clemm-i2rs-yang-network-topo-02 (work 627 in progress), December 2014. 629 [I-D.ietf-idr-ls-distribution] 630 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 631 Ray, "North-Bound Distribution of Link-State and TE 632 Information using BGP", draft-ietf-idr-ls-distribution-10 633 (work in progress), January 2015. 635 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 636 Requirement Levels", BCP 14, RFC 2119, March 1997. 638 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 639 Network Configuration Protocol (NETCONF)", RFC 6020, 640 October 2010. 642 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 643 Bierman, "Network Configuration Protocol (NETCONF)", RFC 644 6241', June 2011. 646 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 647 Protocol (NETCONF) Access Control Model", RFC 6536, March 648 2012. 650 [draft-ietf-sfc-architecture-02] 651 Halpern, J., "Service Function Chaining (SFC) 652 Architecture", ID draft-ietf-sfc-architecture-02, May 653 2014. 655 Authors' Addresses 657 Zitao(Michael) Wang 658 Huawei Technologies,Co.,Ltd 659 101 Software Avenue, Yuhua District 660 Nanjing 210012 661 China 663 Email: wangzitao@huawei.com 665 Qin Wu 666 Huawei Technologies,Co.,Ltd 667 101 Software Avenue, Yuhua District 668 Nanjing 210012 669 China 671 Phone: +86 25 56623633 672 Email: bill.wu@huawei.com 674 Susan Hares 675 Huawei Technologies,Co.,Ltd 676 7453 Hickory Hill 677 Saline, MI 48176 678 USA 680 Email: Email: shares@ndzh.com