idnits 2.17.1 draft-wang-i2rs-yang-sff-dm-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 6 instances of too long lines in the document, the longest one being 46 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 242 has weird spacing: '...ork-ref lea...' == Line 246 has weird spacing: '...ork-ref lea...' == Line 275 has weird spacing: '... rw for c...' == Line 276 has weird spacing: '... ro for n...' == Line 317 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 8, 2015) is 3337 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 106, but not defined == Unused Reference: 'RFC6020' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'RFC6536' is defined on line 867, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-clemm-i2rs-yang-network-topo-03 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-10 == Outdated reference: A later version (-15) exists of draft-penno-sfc-yang-13 == Outdated reference: A later version (-05) exists of draft-xia-sfc-yang-oam-02 ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS Z. Wang 3 Internet-Draft S. Hares 4 Intended status: Standards Track Huawei 5 Expires: September 9, 2015 J. Tantsura 6 R. White 7 Ericsson 8 Q. Wu 9 L. Dunbar 10 Huawei 11 March 8, 2015 13 A YANG Data Model for Protocol Independent Service Topology: SFF 14 Forwarder 15 draft-wang-i2rs-yang-sff-dm-00 17 Abstract 19 This document defines a YANG data model for Service Function Forward 20 Topology. This I2RS yang data model is part of the I2RS protocol 21 independent topology set of data models. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 9, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4 59 3. SFF Topology Data Model . . . . . . . . . . . . . . . . . . . 5 60 3.1. Model Overview . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. SFF Topology Yang . . . . . . . . . . . . . . . . . . . . 7 62 3.3. SFF topology Model Description . . . . . . . . . . . . . 8 63 3.4. Comparison with SFC WG Yang Modules . . . . . . . . . . . 10 64 4. Service Topology YANG Module . . . . . . . . . . . . . . . . 11 65 5. SFC Topology YANG Module . . . . . . . . . . . . . . . . . . 16 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 68 8. Normative References . . . . . . . . . . . . . . . . . . . . 19 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 71 1. Introduction 73 An overlay network consists of tunnels established among designated 74 nodes to traverse segments of networks. 76 This draft describes a protocol independent topology of service 77 function forwarder nodes which augments the 78 [I-D.clemm-i2rs-yang-network-topo] model as a specific service 79 topology (SFF). Figure 1 shows how the SFF is an extension of the 80 service forwarded nodes. 82 +---------------------------------------+ 83 / _[X1]_ "Service" / 84 / _/ : \_ (SFF) / 85 / _/ : \_ / 86 / _/ : \_ / 87 / / : \ / 88 / [X2]__________________[X3] / 89 +---------:--------------:------:-------+ 90 : : : 91 +----:--------------:----:--------------+ 92 / : : : "L3" / 93 / : : : / 94 / : : : / 95 / [Y1]_____________[Y2] tunnels / 96 / * * * / 97 / * * * / 98 +--------------*-------------*--*-------+ 99 * * * 100 +--------*----------*----*--------------+ 101 / [Z1]_______________[Z1] "Optical" / 102 / \_ * _/ / 103 / \_ * _/ / 104 / \_ * _/ / 105 / \ * / / 106 / [Z] / 107 +---------------------------------------+ 109 Figure 1 111 There can be many types of protocol independent service topologies 112 such as: L2VPN, L3VPN, MPLS, EVPN, and others. The Service Function 113 Chaining services consists of a topology of Service Function 114 Forwarder nodes connected by links which are tunnels that connect the 115 service nodes. Each Service Forwarder node has service functions 116 attached to the Service Function Forwarder node. 118 The SFF topology is built on top of one or several underlying 119 networks (see figure 1). In case multi-tenancy is needed, multiple 120 SFF topologies can be built on top of the same underlying network. 121 Each tenant can only see its own service topology. But all the 122 tenant's service topology can be mapped into the same L3 network 123 topology. 125 The I2RS protocol independent topologies are abstractions created by 126 the I2RS Client directly or by instructions to I2RS agent to import 127 network topologies or aggregations of the network topology. The I2RS 128 protocol independent L3 topology is created by the client or the 129 clients instruction to import specific information from the I2RS 130 Agent from static configuration or IGPs (E.g. OSPF or ISIS) or 131 information passed in EGPs (e.g. [I-D.ietf-idr-ls-distribution]. 132 Similarly, the protocol independent SFF topology is abstraction of 133 network topology information. Since SFF has no another control plane 134 protocol running on top of the underlying networks, this information 135 will need to be gathered from other sources. 137 This document defines a Yang data model for the SFF protocol 138 independent topology. This draft will need to be harmonized with the 139 configuration and status yang modules from SFC WG. This draft has 140 been reviewed against the following drafts: [I-D.penno-sfc-yang] and 141 [I-D.xia-sfc-yang-oam]. 143 2. Definitions and Acronyms 145 Datastore: A conceptual store of instantiated management information, 146 with individual data items represented by data nodes which are 147 arranged in hierarchical manner. 149 Data subtree: An instantiated data node and the data nodes that are 150 hierarchically contained within it. 152 NETCONF: Network Configuration Protocol. 154 URI: Uniform Resource Identifier. 156 YANG: A data definition language for NETCONF. 158 Classification: Locally instantiated policy and customer/network/ 159 service profile matching of traffic flows for identification of 160 appropriate outbound forwarding actions. 162 Classifier: An element that performs Classification. 164 Service Function Chain (SFC): A service function chain defines a set 165 of abstract service functions and ordering constraints that must be 166 applied to packets and/or frames selected as a result of 167 classification. 169 Service Function (SF): A function that is responsible for specific 170 treatment of received packets. 172 Service Function Forwarder (SFF): A service function forwarder is 173 responsible for delivering traffic received from the network to one 174 or more connected service functions according to information carried 175 in the SFC encapsulation, as well as handling traffic coming back 176 from the SF. 178 Metadata: provides the ability to exchange context information 179 between classifiers and SFs and among SFs. 181 Service Function Path (SFP): The SFP provides a level of indirection 182 between the fully abstract notion of service chain as a sequence of 183 abstract service functions to be delivered, and the fully specified 184 notion of exactly which SFF/SFs the packet will visit when it 185 actually traverses the network. 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in [RFC2119]. 191 3. SFF Topology Data Model 193 This section describe the architecture and the tree diagram of the 194 service topology yang data model. 196 3.1. Model Overview 198 The abstract Topology yang Model contain a set of abstract nodes and 199 a list of abstract links. Service Function Chain Topo yang model and 200 other service topo model can be augumented from the abstract topology 201 model with SFC base topology specifics. 203 The following Figure depicts the relationship of service topology 204 yang model to the abstract topology yang model. 206 +-----------------+ 207 | Abstract | 208 | Topology Model | 209 | | 210 +--------|--------+ 211 | 212 +-----------------------+ 213 | ..... | 214 | 215 +------V----------+ 216 | Service | 217 | Topology models | 218 | | 219 +--------|--------- 220 | 221 +----|------------------------|---+ 222 | | 223 +--------V--------+ +--------V-----------+ 224 |Service Function | | Another protocol | 225 | Forwarder | | Independent Service| 226 | Topology Models | | Topology Models | 227 +-----------------+ +--------------------+ 229 Figure 2 231 The relationship of service topology yang model to the abstract 232 topology yang model 234 The following is the generic topology module 236 module: network 237 +--rw network* [network-id] 238 +--rw network-id network-id 239 +--ro server-provided? boolean 240 +--rw network-types 241 +--rw supporting-network* [network-ref] 242 | +--rw network-ref leafref 243 +--rw node* [node-id] 244 +--rw node-id node-id 245 +--rw supporting-node* [network-ref node-ref] 246 +--rw network-ref leafref 247 +--rw node-ref leafref 249 The service modules augments the network types and this data structures. 250 To provide context for this model, this sample augment for the 251 types is provided (but not normative for this draft). 253 module: Service Topologies 254 augment /nt:network-topology/nt:topology/nt:topology-types 255 +--rw Service-Topologies 256 +--rw SFF-topology 257 +--rw L3VPN-Service-topology 258 +--rw EVPN-Service-topology 260 Figure 3: The structure of the abstract (base) network model 262 3.2. SFF Topology Yang 264 The following figure provide the structure of service topology yang 265 model. Each node is printed as: 267 269 is one of: 270 + for current 271 x for deprecated 272 o for obsolete 274 is one of: 275 rw for configuration data 276 ro for non-configuration data 277 -x for rpcs 278 -n for notification 280 is the name of the node 281 If the node is augmented into the tree from another module, its 282 name is printed as :. 284 is one of: 285 ? for an optional leaf or choice 286 ! for a presence container 287 * for a leaf-list or list 288 [] for a list's keys 290 is the name of the type for leafs and leaf-lists 292 Figure 4 294 3.3. SFF topology Model Description 296 SFF Topology Module 298 module: SFF topology 299 augment /nt:network-topology/nt:topology/nt:topology-types 300 +--rw Service-Topologies 301 +--SFF Topology! 302 augment /nt:network-topology/nt:topology 303 +--rw service-topo-id network-id 304 +--rw service-topology-attributes 305 +--rw node-count uint32 ! augments model 306 +--rw topology-extension! 307 augment /nt:network-topology/nt:topology/nt:node 308 +--rw node-type! 309 +--rw classifier-node? string 310 +--rw sf-node? string 311 +--rw sff-node? string 312 +--rw next-hop*[hop-id] 313 +--hop-id node-id 315 +--rw node-extension! 316 +--rw classifier-extension! 317 +--rw classifier-id node-id 318 +--rw sfc-policy uint32 319 +--rw sfp! 320 +--rw sfp-id uint32 321 +--rw sf-list*[sf-id] 322 +--rw sf-id node-id 323 +--rw sff-list*[sff-id] 324 +--rw sff-id node-id 325 +--rw sf-node-extension! 326 +--rw sf-node-extension! 327 +--rw sf-id node-id 328 +--rw sf-node-locator uint32 329 +--rw sf-type? sft:service-function-type 330 +--rw sf-inventory-data! 331 +--rw sff-node-extension! 332 +--rw sff-id node-id 333 +--rw (sffn-address)? 334 +--:(ipv4-address) 335 | +--rw ipv4-address? inet:ipv4-address 336 +--:(ipv6-address) 337 | +--rw ipv6-address? inet:ipv6-address 338 +--rw sffn-virtual-context! 339 | +--rw context-id uint32 340 +--rw Attached-service-address! 341 | +--rw service-node*[service-node-id] 342 | | +--rw service-node-id node-id 343 | +--rw host-system*[host-system-id] 344 | +--rw host-system-id uint32 345 +--rw customer-support*[customer-id] 346 | +--rw customer-id uint32 347 +--rw customer-service-resource*[customer-resource-id] 348 | +--rw customer-resource-id node-id 349 +--rw sffn-vntopo! 351 Figure 5 353 The service topo yang model contains a service-topology structure. 354 Based on the generic topology model, this can be a list. 356 topology model 358 The generic model contains a topology leaf. The SFF augments the 359 topology types leaf within this topology life with the SFF-topology 360 type. The SFF module also augments the topology with topology-id 361 leaf, and a topology attributes leaf that contains node count leaf 362 and topology-extension container. The node-count leaf can be used to 363 indicate the number of nodes which contained in the service-topology 364 list. The topology-extension container can be used to augment the 365 service topology model by topology specifics. 367 node structure 369 The generic topology structure also contains a node (nt:node), and 370 this structure has been augmented by containers for node type, a 371 next-hop container, and a node-extensions. The node-type container 372 can used to indicate the type node, such classifier, a sf or a sff. 373 The node-extension container can be used to augment the node list by 374 node specifics, for example: classifier extension, sf extension, sff 375 extension. 377 link structure 379 The generic link topology structure contains a link (nt:link) 380 structure, and this generic link structure has been augmented to 381 include a sff-link-type leaf, sff-direction container, and an 382 segment-extension leaf. The segment-extension container can be used 383 to augment the segment list by segment specifics. Such as netconf 384 segment extension, i2rs segment extension. 386 classifier extension 388 In SFC, the classifier is used to locally instantiated policy and 389 customer/network/service profile matching of traffic flows for 390 identification of appropriate outbound forwarding actions. 392 sf-node-extension 394 The sf is a function that is responsible for specific treatment of 395 received packets. As a logical component. 397 sff-node-extension 399 The service function forwarder is responsible for delivering traffic 400 received from the network to one or more connected service functions 401 according to information carried in the SFC encapsulation, as well as 402 handling traffic coming back from the SF. 404 3.4. Comparison with SFC WG Yang Modules 406 The following entities have modules in [I-D.penno-sfc-yang] 408 o classifier-extensions - may link to Service Function Classifier 409 (SCF), no equivalent policy structures exist in that module. 411 o sff-node-extensions - may link to Service Function Forwarder 412 (SFF), but it is difficult to determine if the sff-data-plane- 413 locator or the ip-mgt-address could be used as the virtual 414 address. All portions of this structure do not exist in the 415 service functgion forwarder configuration and status structure. 417 o service-function-type (SFT) has been utilized as a definition in 418 the sf-node extension structure. 420 No appropriate entities were found in the SFC OAM draft 421 [I-D.xia-sfc-yang-oam]. 423 4. Service Topology YANG Module 425 file "service-topo.yang" 426 module service-topo { 427 yang-version 1; 428 namespace "urn:TBD:params:xml:ns:yang:service-topo"; 429 prefix stopo; 431 import network { 432 prefix "nt"; 433 } 434 import ietf-inet-types { 435 prefix inet; 436 } 438 import ietf-service-function-type { 439 prefix sft; 440 ; 442 organization "IETF I2RS Working Group"; 443 contact 444 "wangzitao@huawei.com"; 445 "shares@ndzh.com"; 447 description 448 "This module defines service topology yang data model"; 449 typedef node-id { 450 type inet:uri; 451 } 452 typedef network-id { 453 type inet:uri; 454 } 455 typedef link-id { 456 type inet:uri; 457 } 458 container service-topologies { 459 description 460 "Contains configuration related data. Within the container 461 is list of service topologies."; 463 list service-topology{ 464 key "service-topo-id"; 465 description 466 "Define the list of service-topology within the network"; 468 leaf service-topo-id{ 469 type network-id; 470 description 471 "the identifier for a service topology";} 473 leaf node-count{ 474 type uint32; 475 description 476 "Number of nodes within a service topology.";} 478 container topology-type{ 479 description 480 " This container contains several leaf to specify the topology type, 481 such as NETCONF or I2RS. A service topology can even have 482 multiple types simultaneously. And this container can 483 be used to augment the service topology model by topology specifics.";} 485 container topology-extension{ 486 description 487 " The topology-extension container can be used to augment 488 the service topology model by topology specifics.";} 490 list underlay-topologies { 491 key "topology-id"; 492 description 493 "Define the list of underlay-topologies within the service-topology list"; 495 leaf topology-id { 496 type network-id; 497 description 498 "It is presumed that a datastore will contain many topologies. To 499 distinguish between topologies it is vital to have UNIQUE 500 topology identifiers.";} 501 } 503 list node { 504 key "node-id"; 505 description 506 "Define the list of node within the service-topology list"; 507 leaf node-id { 508 type node-id; 509 description 510 "The identifier of a node in the service topology.";} 512 list termination-point{ 513 key "termination-point-id"; 514 description 515 "Define the list of termination-point within the node list"; 517 leaf termination-point-id { 518 type node-id; 519 description 520 "The identifier of the termination point of the node";} 522 list support-termination-points{ 523 key "support-point-id"; 524 description 525 "Define the list of support-point-id within the termination-point list"; 527 leaf support-point-id { 528 type node-id; 529 description 530 "the identifier of the support node of the termination point";} 531 } 533 container termination-point-extension{ 534 description 535 "The termination-point-extension container can be used to augment 536 the service topology model by topology specifics.";} 537 } 539 container node-type{ 540 description 541 "The node-type container can used to indicate the type node, 542 such classifier, a sf or a sff. And this container can be used 543 to augment the service topology model by topology specifics. "; 545 leaf classifier-node { 546 type string; 547 description 548 "To indicate the node is a classifier";} 550 leaf sf-node { 551 type string; 552 description 553 "To indicate the node is a service function(sf)";} 554 leaf sff-node { 555 type string; 556 description 557 " To indicate the node is a service function forward(sff)";} 558 } 560 list next-hop{ 561 key "hop-id"; 562 description 563 "Define the list of next-hop within the node list"; 565 leaf hop-id { 566 type node-id; 567 description 568 "The identifier of the next hop of the node";} 569 } 571 container node-extension{ 572 description 573 " The node-extension container can be used to augment 574 the service topology model by topology specific nodes."; 576 container classifier-extension { 577 description 578 "The classifier-extension container contains the extensions 579 of the classifier";} 581 container sf-node-extension { 582 description 583 "The sf-extension container contains the extensions of the sf.";} 585 container sff-node-extension { 586 description 587 " The sff-extension container contains the extensions of the sff. ";} 588 } 589 } //end the node list 591 list segment{ 592 key "segment-id"; 593 description 594 "Define the list of segment within the service-topology list."; 596 leaf segment-id{ 597 type link-id; 598 description 599 " The segment-id leaf can be used to distinguish 600 the different service segment.";} 602 container source{ 603 description 604 "The source container contains the source node 605 and the termination point reference list."; 607 leaf source-id{ 608 type node-id; 609 description 610 "The identifier of the source node of the segment.";} 611 list termination-point-reference{ 613 key "source-support-id"; 614 leaf source-support-id{ 615 type node-id; 616 description 617 "The identifier of the termination point of the source node.";} 618 }//end the termination-point-reference list 619 }//end the source container 621 container destination{ 622 description 623 "The destination container contains the source node 624 and the termination point reference list."; 626 leaf destination-id{ 627 type node-id; 628 description 629 "The identifier of the destination node of the segment.";} 630 list termination-point-reference{ 631 key "destination-support-id"; 632 leaf destination-support-id{ 633 type node-id; 634 description 635 "The identifier of the termination point of the source node.";} 636 }//end the termination-point-reference list 637 }//end the destination container 639 container direction{ 640 leaf unidirection{ 641 type boolean; 642 description 643 "Indicates whether the segment is unidirection or not.";} 644 leaf bidirection{ 645 type boolean; 646 description 647 "Indicates whether the segment is bidirection or not.";} 648 } //end the direction container 650 container segment-extension{ 651 description 652 "The segment-extension container can be used to augment 653 the segment list by segment specifics. Such as 654 netconf segment extension, i2rs segment extension."; 656 container netconf-segment-extension { 657 description 658 "To contain the netconf segment extension.";} 659 container i2rs-segment-extension { 660 description 661 "To contain the i2rs segment extension.";} 662 } //end the segment-extension container 663 }//end the segment list 664 }//end the service-topology list 665 } 666 } 667 669 5. SFC Topology YANG Module 671 file "sfc-topo@2013-12-23.yang" 672 module sfc-topo { 673 yang-version 1; 674 namespace "urn:TBD:params:xml:ns:yang:sfc-topology"; 675 prefix "sfc-topo"; 676 import service-topo { 677 prefix "stopo"; 678 } 679 import ietf-inet-types { 680 prefix "inet"; 681 } 682 organization "IETF I2RS Working Group"; 683 contact 684 "wangzitao@huawei.com"; 685 description 686 "This module defines sfc topology yang data model"; 687 typedef node-id { 688 type inet:uri; 689 } 690 augment "/stopo:service-topologies/stopo:service-topology/stopo:node/stopo:node-extension/stopo:classifier-extension"{ 691 leaf classifier-id{ 692 type node-id; 693 description 694 "The identifier of the classifier.";} 695 leaf sfc-policy{ 696 type uint32; 697 description 698 "Indicate the policy of sfc.";} 700 container sfp{ 701 description 702 "contains several sfps."; 703 leaf sfp-id{ 704 type uint32; 705 description 706 "The identifier of the sfp.";} 707 list sf-list{ 708 key "sf-id"; 709 leaf sf-id{ 710 type node-id; 711 description 712 "The identifier of the sf which include in the sfp.";} 713 } 714 list sff-list{ 715 key "sff-id"; 716 leaf sff-id{ 717 type node-id; 718 description 719 "The identifier of the sff which include in the sfp.";} 720 } 721 }//end the sfp container 722 }//end the classifier-extension 724 augment "/stopo:service-topologies/stopo:service-topology/stopo:node/stopo:node-extension/stopo:sf-node-extension"{ 725 leaf sf-id{ 726 type node-id; 727 description 728 "The identifier of the service function(sf).";} 729 leaf sf-node-locator{ 730 type sft:service-function-type; 731 description 732 "To indicate the service function (sf) locator";} 733 container sf-type{ 734 leaf firewall{ 735 type sft:-service-function-type; 736 description 737 "To indicate the service function (sf) is firewall.";} 738 leaf loadbalancer{ 739 type sft:-service-function-type; 740 description 741 "To indicate the service function (sf) is loadbalancer.";} 742 leaf NAT44{ 743 type sft:-service-function-type; 744 description 745 "To indicate the service function (sf) is NAT44.";} 746 leaf NAT64{ 747 type sft:-service-function-type; 748 description 749 "To indicate the service function (sf) is NAT64.";} 750 leaf DPI{ 751 type sft:-service-function-type; 752 description 753 "To indicate the service function (sf) is DPI.";} 754 }//end the sf-type container 755 container sf-inventory-data{ 756 description 757 "The container of the inventory data of service function (sf)."; 758 } 759 }//end the sf-node-extension 761 augment "/stopo:service-topologies/stopo:service-topology/stopo:node/stopo:node-extension/stopo:sff-node-extension"{ 762 leaf sff-id{ 763 type node-id; 764 description 765 "The identifier of the service function forward (sff).";} 766 choice sffn-address{ 767 description 768 "The address of the service function forward (sff) node"; 769 case ipv4-address{ 770 leaf ipv4-address{ 771 type inet:ipv4-address;} 772 } 773 case ipv6-address{ 774 leaf ipv6-address{ 775 type inet:ipv6-address;} 776 } 777 }//end the choice sffn-address 778 container sffn-virtual-context{ 779 leaf context-id{ 780 type uint32; 781 description 782 "the identifier of the sffn virtual context.";} 783 } 784 container Attached-service-address{ 785 list service-node{ 786 key "service-node-id"; 787 leaf service-node-id{ 788 type node-id; 789 description 790 "The identifier of the service node.";} 791 }//end the service-node list 792 list host-system{ 793 key "host-system-id"; 794 leaf host-system-id{ 795 type uint32; 796 description 797 "The identifier of the host system.";} 798 }//end the service-node list 799 } //end the attached-service-address container 800 list customer-support{ 801 key "customer-id"; 802 leaf customer-id{ 803 type uint32; 804 description 805 "The identifier of the customer.";} 806 }//end the customer-support list 807 list customer-service-resource{ 808 key "customer-resource-id"; 809 leaf customer-resource-id{ 810 type node-id; 811 description 812 "The identifier of the customer resource.";} 813 }//end the customer-service-resource list 814 container sffn-vntopo{ 815 description 816 "This container can be use to contain the virtual network topology of 817 Sffn. And it can be augment by specific virtual network topology."; 818 }//end the sffn-vntopo container 819 }//end the sff-node-extension 820 } 821 823 6. Security Considerations 825 TBD. 827 7. IANA Considerations 829 TBD. 831 8. Normative References 833 [I-D.clemm-i2rs-yang-network-topo] 834 Clemm, A., Medved, J., Varga, R., Tkacik, T., Bahadur, N., 835 and H. Ananthakrishnan, "A Data Model for Network 836 Topologies", draft-clemm-i2rs-yang-network-topo-03 (work 837 in progress), March 2015. 839 [I-D.ietf-idr-ls-distribution] 840 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 841 Ray, "North-Bound Distribution of Link-State and TE 842 Information using BGP", draft-ietf-idr-ls-distribution-10 843 (work in progress), January 2015. 845 [I-D.penno-sfc-yang] 846 Penno, R., Quinn, P., Zhou, D., and J. Li, "Yang Data 847 Model for Service Function Chaining", draft-penno-sfc- 848 yang-13 (work in progress), March 2015. 850 [I-D.xia-sfc-yang-oam] 851 Xia, L., Wu, Q., Kumar, D., Boucadair, M., and Z. Wang, 852 "YANG Data Model for SFC Operations, Administration, and 853 Maintenance (OAM)", draft-xia-sfc-yang-oam-02 (work in 854 progress), March 2015. 856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 857 Requirement Levels", BCP 14, RFC 2119, March 1997. 859 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 860 Network Configuration Protocol (NETCONF)", RFC 6020, 861 October 2010. 863 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 864 Bierman, "Network Configuration Protocol (NETCONF)", RFC 865 6241', June 2011. 867 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 868 Protocol (NETCONF) Access Control Model", RFC 6536, March 869 2012. 871 [draft-ietf-sfc-architecture-02] 872 Halpern, J., "Service Function Chaining (SFC) 873 Architecture", ID draft-ietf-sfc-architecture-02, May 874 2014. 876 Authors' Addresses 878 Zitao(Michael) Wang 879 Huawei Technologies,Co.,Ltd 880 101 Software Avenue, Yuhua District 881 Nanjing 210012 882 China 884 Email: wangzitao@huawei.com 885 Susan Hares 886 Huawei Technologies,Co.,Ltd 887 7453 Hickory Hill 888 Saline, MI 48176 889 USA 891 Email: Email: shares@ndzh.com 893 Jeff Tantsura 894 Ericsson 896 Email: Jeff Tantsura jeff.tantsura@ericsson.com 898 Russ White 899 Ericsson 901 Email: russw@riw.us 903 Qin Wu 904 Huawei Technologies,Co.,Ltd 905 101 Software Avenue, Yuhua District 906 Nanjing 210012 907 China 909 Phone: +86 25 56623633 910 Email: bill.wu@huawei.com 912 Linda Dunbar 913 Huawei Technologies,Co.,Ltd 915 Email: Email: Linda.Dunbar@huawei.com