idnits 2.17.1 draft-zhuang-i2rs-dc-fabric-service-model-03.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 41 instances of too long lines in the document, the longest one being 56 characters in excess of 72. ** The abstract seems to contain references ([I-D.zhuang-i2rs-yang-dc-fabric-network-topology]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 477 has weird spacing: '...cl-name str...' == Line 484 has weird spacing: '...cl-name str...' == Line 488 has weird spacing: '...-prefix ine...' == Line 510 has weird spacing: '...cl-name str...' == Line 515 has weird spacing: '...rnal-ip ine...' == (1 more instance...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 2, 2017) is 2490 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-i2rs-yang-network-topo' is defined on line 1350, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 1367, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 1376, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-usecase-reqs-summary' is defined on line 1386, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-i2rs-yang-network-topo-14 == Outdated reference: A later version (-04) exists of draft-zhuang-i2rs-yang-dc-fabric-network-topology-03 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 3 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 i2rs Y. Zhuang, Ed. 3 Internet-Draft D. Shi 4 Intended status: Informational Huawei 5 Expires: January 3, 2018 R. Gu 6 China Mobile 7 July 2, 2017 9 YANG Data Model for Fabric Service delivery in Data Center Network 10 draft-zhuang-i2rs-dc-fabric-service-model-03 12 Abstract 14 This document defines a YANG data model that can be used to deliver 15 fabric service for users within a data center network. This model is 16 intended to be instantiated by management system. It provides an 17 abstraction of services for a fabric network to be used by users. 18 However it is not a configuration model used directly onto network 19 infrastructures. It should be used combining with such as fabric 20 topology data model defined in 21 [I-D.zhuang-i2rs-yang-dc-fabric-network-topology] with specific 22 fabric topology information to generate required configuration onto 23 the related network elements to deliver the service. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 3, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Concept and Terminology . . . . . . . . . . . . . . . . . . . 4 61 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Fabric service framework overview . . . . . . . . . . . . . . 4 63 3.1. Service element . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Functionality of connections . . . . . . . . . . . . . . 6 65 4. Fabric service model usage . . . . . . . . . . . . . . . . . 7 66 4.1. Usage architecture . . . . . . . . . . . . . . . . . . . 7 67 4.2. Multi-Layer interconnection . . . . . . . . . . . . . . . 8 68 5. Design of the data model . . . . . . . . . . . . . . . . . . 10 69 5.1. Fabric service module . . . . . . . . . . . . . . . . . . 10 70 5.2. Endpoint module . . . . . . . . . . . . . . . . . . . . . 12 71 6. Fabric Service YANG Modules . . . . . . . . . . . . . . . . . 14 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 76 9.2. Informative References . . . . . . . . . . . . . . . . . 30 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 79 1. Introduction 81 Network service provisioning is currently coupled with specific 82 network topology and technology applied, which is technology and 83 device oriented. 85 In the area of data center, this approach makes the management 86 complex due to massive network devices involved and various 87 applications deployed by multiple users (also known as tenants). 89 In the traditional way, the administrator has to be aware of the 90 entire data center network before delivering services for users. 91 When service request comes up, administrator has to divide the 92 request into appropriate configurations and operations for all 93 involved devices manually. Finally, these configurations are 94 deployed onto network infrastructure, which requires personnel 95 skills. 97 Actually different users share the same network infrastructure. A 98 more dynamical way to deploy and manage the network is eager to be 99 found out. Here we decompose the network management system into 100 several layers in order to have network service provision more 101 flexible and automatic. Each network layer is dedicated to be 102 managed. What is more, all the layers can be combined to fulfill the 103 delivery of the user's service. 105 We can use three layers in data center network. The bottom one is 106 physical infrastructure with massive devices. The middle one is 107 fabric topology defined in [I-D.zhuang-i2rs-yang-dc-fabric-network- 108 topology]. Unlike the physical layer, the fabric layer is used to 109 display a fabric-based network view. In the fabric layer, a set of 110 fabrics can exist with each managed independently. Furthermore, a 111 bottom-up abstraction of fabric service is proposed to provide 112 application centric interfaces facing to users which define network 113 services regardless of beneath fabric topology and physical 114 connections in the up layer. 116 This document defines a YANG [RFC6020] [RFC7950] data model focusing 117 on the fabric service interfaces to define user fabric network 118 services regardless of specific beneath network topology and devices. 119 This model defines the generic configuration for fabric services 120 within DC networks. 122 For example, this model can be used by the network orchestrator in 123 which the fabric service interfaces are exposed. When a service from 124 user application is requested, orchestrator adopts this model 125 including service information and processes it into the topology 126 layer through a DC controller. Thus a service is automatically and 127 dynamically provided. 129 The service data model includes two main modules: 131 (a)Module "ietf-fabric-service" defines a module for user network 132 service over fabric networks from the application centric view. To 133 do so, it augments general network topology model defined in [I- 134 D.ietf-i2rs-yang-network-topo] with logical components such as 135 logical switches, logical routers as well as logical ports to carry 136 network services requested by user applications. 138 (b)Module "ietf-fabric-endpoint" defines a module for hosts that run 139 applications and generate traffics. The major usage of this module 140 is to indicate the attachment points of a host in a user service 141 network as well as in a physical network when it is initialed, so as 142 to build bindings between physical layer and topology layer 143 dynamically. 145 Besides, the model "ietf-fabric-topology" defined in [I-D.zhuang- 146 i2rs-yang-dc-fabric-network-topology] with topology and resource as 147 well as technology information is used to work together to implement 148 configurations and operations of the fabric service onto the specific 149 fabric infrastructure. 151 2. Concept and Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 2.1. Terminology 159 Fabric topology: a data center network can be decomposed to a set of 160 fabric networks, while each of these fabrics composes a set of 161 physical nodes/links of the physical infrastructure to form a fabric 162 network. The fabric topology includes attributes of fabrics, such as 163 gateway mode, involved nodes, roles of involved nodes etc al. 165 Fabric Service: it is used as a service interface of fabric networks 166 to users, which uses logical elements to represent network 167 connections between hosts for applications, regardless of a specific 168 fabric topology deployment. Each service instance is based on a 169 fabric topology, while a fabric can provide multiple service 170 instances for different users, each of which is isolated to others. 172 Endpoint: an endpoint represents a host, which can be a virtual 173 machine on a server or a bare-metal server. 175 Fabric capable device: a physical device (e.g. a switch) that 176 supports fabric service and fabric topology models. 178 3. Fabric service framework overview 180 This draft provides a network service interface on top of fabrics 181 network layer. Users can use these network service interfaces to 182 deploy their applications over a data center network automatically 183 and dynamically. 185 From the application centric point of view, user hosts can be 186 considered to connect with other hosts through a switch if they are 187 L2 reachable, alternatively, connect through a router if they are L3 188 reachable simply. So a user network can be abstracted into a logical 189 network where L2 reachable represents logical switches connecting 190 hosts and L3 reachable represents logical routers connecting 191 switches. 193 With this concept, a user can use appropriate logical elements to 194 define their networks and configure attributes of these elements such 195 as vlan id, gateway etc al. All of these form a network service. 196 For example, a fabric service diagram for a user is shown as below. 198 |C3 - L3 Interconnect 199 | 200 |logical port- external gateway 201 +-----------|------------+ 202 | | 203 | Logical Router | 204 | | 205 +---|--------------|-----+ 206 | |logical port-gateway port 207 | |C2 208 | | 209 | | 210 +-----------|----+ +-|--------------+ 211 | | | | Logical port-Access port 212 | Logical Switch | | Logical Switch ------ 213 | | | | C4 - L2 Interconnect 214 +-|---------|----+ +-|---------|----+ 215 | | |C1 | 216 | | | | 217 +-----|---+ +--|------+ +----|----+ +-|-------+ 218 | Endpoint| | Endpoint| | Endpoint| | Endpoint| 219 +---------+ +---------+ +---------+ +---------+ 221 Figure 1: Diagram of a fabric service 223 In the diagram, abstraction of network connections is focused as a 224 very initial effort to abstract services for fabric-based DC 225 networks. Based on the connection, we can add other network 226 appliance for which the fabric service should be extended. 228 3.1. Service element 230 There are four major components regarding as service elements within 231 a fabric service as depicted in Figure 1. 233 Logical Switch: 235 Works as a switch within a logical fabric network to provide L2 236 connections between hosts or to a logical router or to external 237 networks. It can be bounded to one or several physical switches. 239 Logical Router: 241 Works as a router to provide L3 connections between logical switches 242 or to external networks. 244 Logical Port: 246 Provides port function on logical switches and logical routers which 247 claims their connections to others. 249 Endpoint: 251 Represents user hosts which can be a VM or a bare-metal server. 253 3.2. Functionality of connections 255 There are 4 connections between elements within the fabric service 256 framework listed as follows: 258 C1: Endpoint attachment. It is used by an endpoint to connect to a 259 logical switch. 261 C2: L2 to L3 attachment. Interface between a logical switch and a 262 logical router within the same fabric. 264 C3: L3 interconnection which connects to a logical router. 266 C4: L2 interconnection which connects to a logical switch in another 267 fabric. 269 Thinking of the functionality of different connections, a logical 270 port can act as an access port (which provides C1/C4/C3 connection to 271 a network element), or a service port (which provide C2 gateway 272 connection) as shown in Figure 2. 274 +---------------+ 275 | Logical Port | 276 +--+----------+-+ 277 | | 278 | | 279 | | 280 | | 281 +--------------+-+ `````````````````` 282 | Access Port | ` Service Port ` 283 +----------------+ ```|```````````|`` 284 | | 285 | | 286 | | 287 | | 288 +------------+--+ +--+------------+ 289 | Gateway Port | | External GW | 290 +---------------+ +---------------+ 292 Figure 2: Types of Logical port 294 When a logical port is noticed as an access port, there will be a 295 corresponding physical port. In this situation, the required access 296 configuration can be deployed on this physical port directly. 297 However, there will be a gateway service if a logical port is noticed 298 as a service port. In this situation, the management system should 299 combine the gateway function and fabric territory at fabric topology 300 layer together with the gateway configuration on the service port. 301 By the combination, it is easy to figure out the appropriate devices 302 in the physical infrastructure and their configurations for these 303 devices respectively. 305 4. Fabric service model usage 307 4.1. Usage architecture 309 In section 3, a fabric service interface is provided for users to 310 define their networks in a more concentrated and intuitive way. To 311 be detailed, when a fabric service comes, the topology manager will 312 parse services into configuration/operations onto specific devices 313 automatically. In this process, service interface information and 314 fabric topology information defined in [I-D.zhuang-i2rs-yang-dc- 315 fabric-network-topology] is needed. 317 The whole process is shown in Fig.3. Fabric service module is used 318 define network services for applications maybe by an orchestration 319 for example, according to the topology architecture stated in [I- 320 D.draft-ietf-i2rs-usecase-reqs-summary]. The topology information 321 maintenance should be done by a topology manager. By combining 322 information from different layers, a topology manager automatically 323 generates configurations and operations of related devices and 324 deploys them respectively over the physical fabric infrastructures. 326 +-------------------+ 327 | | 328 | Orchestrator | 329 | | 330 +---------|---------+ 331 | 332 | Fabric service 333 | 334 | 335 +---------V---------+ 336 | | 337 | Topology Manager | Network Provider 338 | | 339 +--------^----------+ 340 | 341 | 342 |Fabric Topology information 343 | 344 ...........................|............................. 345 | 346 +----------------+ 347 +----------------+| 348 +----------------+|| 349 | ||| Network 350 | Device ||+ 351 | |+ 352 +----------------+ 354 Figure 3: Fabric service Usage architecture 356 4.2. Multi-Layer interconnection 358 There are three layers in this usage. 360 At the service layer, a fabric service model is abstracted from 361 fabric network used as an application-centric interface to define 362 user networks. It focuses on the connection services from users' 363 perspective. Using the fabric service interface, an administrator 364 can define a logical network for each user over a single fabric 365 network while each logical networks can be managed separately. 367 For the fabric topology layer, it collects and maintains the fabric 368 topology information (including territory of the physical fabric, 369 connections, gateway functions, roles of devices within the fabric 370 and specific technologies for each fabric) upon the physical network 371 layer. 373 With information provided by both fabric service as well as fabric 374 topology, a fabric topology manager will calculates and generates 375 configuration and operation for involved network devices in the 376 physical layer so as to distribute and deploy them onto network 377 infrastructure. The implementation of device configuration can be 378 done in several ways, such as using defined data models for specific 379 attributes, command lines. We will not limite any implemenation 380 here. 382 The diagram of the management architecture and its relationship is 383 depicted as below. 385 +----------+ 386 | | 387 | LR-1 |................ 388 | | 389 +--/---\---+ 390 gateway: / \ gateway: 391 10.0.35.1 / \ 10.0.36.1````` Fabric Service Layer 392 / \ ` 393 +---------+ +---------+ ` 394 | | | | ` 395 +---| LSW-11 | | LSW-12 | ` 396 | +-----|---+ +---------+ ` 397 | | | ` 398 | | | ` +--------+ 399 | | | ` | | 400 | | | ` |Fabric-3| 401 | | | ` | | 402 | | | ` +-/ ---\-+ 403 | | | ` / \ 404 | | | ` / \ 405 | | | ` +------ /+ +\ ------+ 406 | | | ` | | | | 407 | | | ` |Fabric-1|--------|Fabric-2| 408 | | | ` | | | | 409 | | | ` +--------+ +--------+ 410 | | | `````gateway/roles 411 | +-----------------------+ of nodes 412 | | | ` Fabric Topology Layer 413 | Fabric-1 | | ` 414 | +-------+ | | ` 415 | +--------+|`````````````````````` 416 | +--------+|| | | 417 | | ||+ | | 418 | | SPINE |+ | | 419 | +--------+ | | 420 | |||| | | 421 | |||-------+ | | 422 | +|||------+| | | Physcial Layer 423 | +-||------+|| | | 424 | +--|------+||+ | | 425 | +---------+||+ | | 426 | | LEAF ||+\ | | 427 | | device |+ \ | | 428 | +---------+ \| | 429 | / \ \ | 430 | / \ |\ | 431 | / \ | \ | 432 | +/-+ +-\+ | \ +-|+ 433 +--------| | | |---+ \| | 434 +--+ +--+ +--+ 435 H1:10.0.35.2 H2:10.0.36.2 H3:10.0.35.3 437 Figure 4: Multi-layer interconnection 439 The mapping of nodes with access logical ports is realized by 440 endpoints e.g. H1,H2 and H3 in Fig.4. An endpoint is instantiated 441 by the orchestrator to indicate the locations of a host both in the 442 logical layer as well as in the physical layer, so as to deliver 443 services requested from the logical port onto the physical port in a 444 dynamic manner. For H1 and H3, they are considered to connect to the 445 same switch for user in the logical layer, even they attach to the 446 different devices. 448 Besides, gateway configuration is defined at service layer while the 449 gateway mode and gateway devices (for distributed gateway, the 450 gateway should be deployed on LEAF devices, while for centralized 451 gateway, the configuration should be on SPINE) are defined in fabric 452 topology layer. By combing the gateway information from both layers, 453 the system can automatically figure out the involved devices and 454 generate appropriate configurations onto them. 456 5. Design of the data model 458 5.1. Fabric service module 460 As explained previously, network service for user network can be 461 abstracted to sets of logical switches, logical routers and logical 462 ports. Upon these logical elements, acl policies and gateway 463 functions can be attached. 465 The fabric service module is defined by YANG module "ietf-fabric- 466 service". The module is depicted in the following diagram. 468 module: ietf-fabric-service 469 augment /nw:networks/nw:network/nw:node: 470 +--rw lsw-attribute 471 +--rw lsw-uuid? yang:uuid 472 +--rw name? string 473 +--rw segment-id? uint32 474 +--rw network? inet:ip-prefix 475 +--rw external? boolean 476 +--rw fabric-acl* [fabric-acl-name] 477 +--rw fabric-acl-name string 478 augment /nw:networks/nw:network/nw:node: 479 +--rw lr-attribute 480 +--rw lr-uuid? yang:uuid 481 +--rw name? string 482 +--rw vrf-ctx? uint32 483 +--rw fabric-acl* [fabric-acl-name] 484 | +--rw fabric-acl-name string 485 +--rw routes 486 +--rw route* [destination-prefix] 487 +--rw description? string 488 +--rw destination-prefix inet:ipv4-prefix 489 +--rw (next-hop-options)? 490 +--:(simple-next-hop) 491 +--rw next-hop? inet:ipv4-address 492 +--rw outgoing-interface? nt:tp-id 493 augment /nw:networks/nw:network/nw:node/nt:termination-point: 494 +--rw lport-attribute 495 +--rw lport-uuid? yang:uuid 496 +--rw name? string 497 +--rw port-layer 498 | +--rw layer-1-info 499 | | +--rw location? nt:tp-id 500 | +--rw layer-2-info 501 | | +--rw access-type? access-type 502 | | +--rw access-segment? uint32 503 | +--rw layer-3-info 504 | +--rw ip? inet:ip-address 505 | +--rw network? inet:ip-prefix 506 | +--rw mac? yang:mac-address 507 | +--rw forward-enable? boolean 508 | +--rw logical-switch? nw:node-id 509 +--rw fabric-acl* [fabric-acl-name] 510 | +--rw fabric-acl-name string 511 +--rw port-function 512 | +--rw (function-type)? 513 | +--:(ip-mapping) 514 | +--rw ip-mapping-entry* [external-ip] 515 | +--rw external-ip inet:ipv4-address 516 | +--rw internal-ip? inet:ipv4-address 517 +--rw underlayer-ports* [port-ref] 518 +--rw port-ref instance-identifier 520 Figure 5: Fabric Service Module 522 To provide a logical network topology for DC fabric network, the 523 module augments the original ietf-network and ietf-network-topology 524 modules: 526 o New nodes for logical switch and logical router with additional 527 data objects are introduced by augmenting the "node" list of the 528 network module. 530 o Termination points for logical ports are augmented with logical 531 port information and its reference to termination ports in the 532 underlay topologies. As stated in section 3, the logical port may 533 act as an access port which will be bounded to some physical port, 534 or else it may be as a service point which connects to internal 535 gateway or external gateway. Besides, it can also be attached 536 with ACL rules. 538 5.2. Endpoint module 540 To represent user attachments points and map logical fabric 541 configurations and operations of applications onto the physical 542 fabric infrastructure, an endpoint is instantiated to represent a 543 host of a user that runs applications. 545 The fabric endpoint module is defined by YANG module "ietf-fabric- 546 endpoint". The module is depicted as follows: 548 module: ietf-fabric-endpoint 549 +--rw endpoints 550 +--rw endpoint* [endpoint-uuid] 551 +--rw endpoint-uuid yang:uuid 552 +--rw own-fabric? fabric:fabric-id 553 +--rw mac-address? yang:mac-address 554 +--rw ip-address? inet:ip-address 555 +--rw gateway? inet:ip-address 556 +--rw public-ip? inet:ip-address 557 +--rw location 558 | +--rw node-ref? fabrictype:node-ref 559 | +--rw tp-ref? fabrictype:tp-ref 560 | +--rw access-type? fabrictype:access-type 561 | +--rw access-segment? uint32 562 +--rw logical-location 563 +--rw node-id? nw:node-id 564 +--rw tp-id? nt:tp-id 566 Figure 6: Fabric endpoint module 568 By indicating locations of an endpoint in "location" container, the 569 logical network elements such as logical nodes and logical 570 termination points are bounded to the network elements in a specific 571 fabric. Then the network configurations and operations from the 572 logical network together with its belonged fabric topology 573 information will further be distributed onto the bounding/related 574 physical elements by the network topology manager. 576 Besides, the module defines three rpc commands to register, 577 unregister and locate the endpoint onto both logical network and 578 physical network shown as follows. 580 rpcs: 581 +---x register-endpoint 582 | +---w input 583 | | +---w fabric-id? fabric:fabric-id 584 | | +---w endpoint-uuid? yang:uuid 585 | | +---w own-fabric? fabric:fabric-id 586 | | +---w mac-address? yang:mac-address 587 | | +---w ip-address? inet:ip-address 588 | | +---w gateway? inet:ip-address 589 | | +---w public-ip? inet:ip-address 590 | | +---w location 591 | | | +---w node-ref? fabrictype:node-ref 592 | | | +---w tp-ref? fabrictype:tp-ref 593 | | | +---w access-type? fabrictype:access-type 594 | | | +---w access-segment? uint32 595 | | +---w logical-location 596 | | +---w node-id? nw:node-id 597 | | +---w tp-id? nt:tp-id 598 | +--ro output 599 | +--ro endpoint-id? yang:uuid 600 +---x unregister-endpoint 601 | +---w input 602 | +---w fabric-id? fabric:fabric-id 603 | +---w ids* yang:uuid 604 +---x locate-endpoint 605 +---w input 606 +---w fabric-id? fabric:fabric-id 607 +---w endpoint-id? yang:uuid 608 +---w location 609 +---w node-ref? fabrictype:node-ref 610 +---w tp-ref? fabrictype:tp-ref 611 +---w access-type? fabrictype:access-type 612 +---w access-segment? uint32 614 Figure 7: Fabric endpoint module RPC 616 6. Fabric Service YANG Modules 618 file "ietf-fabric-types@2016-10-13.yang" 619 module ietf-fabric-types { 621 yang-version 1.1; 622 namespace "urn:ietf:params:xml:ns:yang:ietf-fabric-types"; 623 prefix fabrictypes; 625 import ietf-inet-types { prefix "inet"; revision-date "2013-07-15"; } 626 import ietf-network-topology { prefix nt; } 627 import ietf-network { prefix nw; } 629 import ietf-yang-types { prefix "yang"; revision-date "2013-07-15";} 631 organization 632 "IETF I2RS (Interface to the Routing System) Working Group"; 634 contact 635 "WG Web: 636 WG List: 638 WG Chair: Susan Hares 639 641 WG Chair: Russ White 642 644 Editor: Yan Zhuang 645 647 Editor: Danian Shi 648 "; 650 description 651 "This module contains a collection of YANG definitions for Fabric."; 653 revision "2016-10-13" { 654 description 655 "Initial revision of faas."; 656 reference "draft-zhuang-i2rs-yang-dc-fabric-network-topology-02 and draft-zhuang-i2rs-dc-fabric-service-model-00"; 657 } 659 identity fabric-type { 660 description 661 "base type for fabric networks"; 662 } 664 identity vxlan-fabric { 665 base fabric-type; 666 description 667 "vxlan fabric"; 668 } 670 identity vlan-fabric { 671 base fabric-type; 672 description 673 "vlan fabric"; 674 } 676 typedef service-capabilities { 677 type enumeration { 678 enum ip-mapping { 679 description "NAT"; 680 } 681 enum acl-redirect{ 682 description "acl redirect, which can provide SFC function"; 683 } 684 enum dynamic-route-exchange{ 685 description "dynamic route exchange"; 686 } 687 } 688 description 689 "capability of the device"; 690 } 691 /* 692 * Typedefs 693 */ 694 typedef node-ref { 695 type instance-identifier; 696 description "A reference to a node in topology"; 697 } 699 typedef tp-ref { 700 type instance-identifier; 701 description "A reference to a termination point in topology"; 702 } 704 typedef link-ref { 705 type instance-identifier; 706 description "A reference to a link in topology"; 707 } 709 typedef device-role { 710 type enumeration { 711 enum SPINE { 712 description "a spine node"; 713 } 714 enum LEAF { 715 description "a leaf node"; 716 } 717 enum BORDER { 718 description "a border node"; 719 } 720 } 721 default "LEAF"; 722 description "device role type"; 723 } 725 typedef fabric-port-role { 726 type enumeration { 727 enum internal { 728 description "the port used for devices to access each other."; 729 } 730 enum external { 731 description "the port used for fabric to access outside network."; 732 } 733 enum access { 734 description "the port used for Endpoint to access fabric."; 735 } 736 enum reserved { 737 description " not decided yet. "; 738 } 739 } 740 description "the role of the physical port "; 741 } 743 typedef fabric-port-type { 744 type enumeration { 745 enum layer2interface { 746 description "l2 if"; 747 } 748 enum layer3interface { 749 description "l3 if"; 750 } 751 enum layer2Tunnel { 752 description "l2 tunnel"; 753 } 754 enum layer3Tunnel { 755 description "l3 tunnel"; 756 } 757 } 758 description 759 "fabric port type"; 760 } 762 typedef underlayer-network-type { 763 type enumeration { 764 enum VXLAN { 765 description "vxlan"; 766 } 767 enum TRILL { 768 description "trill"; 770 } 771 enum VLAN { 772 description "vlan"; 773 } 774 } 775 description ""; 776 } 778 typedef layer2-protocol-type-enum { 779 type enumeration { 780 enum VLAN{ 781 description "vlan"; 782 } 783 enum VXLAN{ 784 description "vxlan"; 785 } 786 enum TRILL{ 787 description "trill"; 788 } 789 enum NvGRE{ 790 description "nvgre"; 791 } 792 } 793 description ""; 794 } 796 typedef access-type { 797 type enumeration { 798 enum exclusive{ 799 description "exclusive"; 800 } 801 enum vlan{ 802 description "vlan"; 803 } 804 } 805 description ""; 806 } 808 grouping fabric-port { 809 description 810 "attributes of a fabric port"; 811 leaf name { 812 type string; 813 description "name of the port"; 814 } 815 leaf role { 816 type fabric-port-role; 817 description "role of the port in a fabric"; 819 } 820 leaf type { 821 type fabric-port-type; 822 description "type of the port"; 823 } 824 leaf device-port { 825 type tp-ref; 826 description "the device port it mapped to"; 827 } 828 choice tunnel-option { 829 description "tunnel options"; 831 case gre { 832 leaf src-ip { 833 type inet:ip-prefix; 834 description "source address"; 835 } 836 leaf dest-ip { 837 type inet:ip-address; 838 description "destination address"; 839 } 840 } 841 } 842 } 844 grouping route-group { 845 description 846 "route attributes"; 847 list route { 848 key "destination-prefix"; 849 description "route list"; 851 leaf description { 852 type string; 853 description "Textual description of the route."; 854 } 855 leaf destination-prefix { 856 type inet:ipv4-prefix; 857 mandatory true; 858 description "IPv4 destination prefix."; 859 } 860 choice next-hop-options { 861 description "choice of next hop options"; 862 case simple-next-hop { 863 leaf next-hop { 864 type inet:ipv4-address; 865 description "IPv4 address of the next hop."; 866 } 867 leaf outgoing-interface { 868 type nt:tp-id; 869 description "Name of the outgoing interface."; 870 } 871 } 872 } 873 } 874 } 876 grouping port-functions { 877 description 878 "port functions"; 880 container port-function { 881 description "port functions"; 882 choice function-type { 883 description "type of functions"; 884 case ip-mapping { 885 list ip-mapping-entry { 886 key "external-ip"; 887 description "list of NAT entry"; 888 leaf external-ip { 889 type inet:ipv4-address; 890 description "external address"; 891 } 892 leaf internal-ip { 893 type inet:ipv4-address; 894 description "internal address"; 895 } 896 } 897 } 898 } 899 } 900 } 901 grouping acl-list { 902 description "acl list"; 903 list fabric-acl { 904 key fabric-acl-name; 905 description "fabric acl list"; 906 leaf fabric-acl-name { 907 type string; 908 description "acl name"; 909 } 910 } 911 } 912 ///groupings for logical element 913 grouping logical-switch { 914 description "grouping attributes for a logical switch."; 916 leaf lsw-uuid { 917 type yang:uuid; 918 description "logical switch id"; 919 } 920 leaf name { 921 type string; 922 description "logical switch name"; 923 } 924 leaf segment-id { 925 type uint32; 926 description "segement id"; 927 } 928 leaf network { 929 type inet:ip-prefix; 930 description "subnet"; 931 } 932 leaf external { 933 type boolean; 934 description "whether its a lsw to external network"; 935 } 936 uses acl-list; 937 } 939 grouping logical-router { 940 description "grouping atttributes for a logical router"; 941 leaf lr-uuid { 942 type yang:uuid; 943 description "logical router id"; 944 } 945 leaf name { 946 type string; 947 description "logical router name"; 948 } 949 leaf vrf-ctx { 950 type uint32; 951 description "logical router vrf id"; 952 } 954 uses acl-list; 956 container routes { 957 description "routes"; 958 uses route-group; 959 } 960 } 962 grouping logical-port { 963 description "grouping attributes for logical ports"; 965 leaf lport-uuid { 966 type yang:uuid; 967 description "logical port id"; 968 } 969 leaf name { 970 type string; 971 description "logical port name"; 972 } 973 container port-layer { 974 description "layer information of the lport"; 976 container layer-1-info { 977 description "layer 1 information of the lport"; 978 leaf location { 979 type nt:tp-id; 980 description "L1 tp id"; 981 } 982 } 983 container layer-2-info { 984 description "layer 2 information of the lport"; 985 leaf access-type { 986 type access-type; 987 description "l2 access type"; 988 } 989 leaf access-segment { 990 type uint32; 991 description "access segement"; 992 } 993 } 994 container layer-3-info { 995 description "layer 3 information of the lport"; 996 leaf ip { 997 type inet:ip-address; 998 description "ip address"; 999 } 1000 leaf network { 1001 type inet:ip-prefix; 1002 description "ip prefix"; 1003 } 1004 leaf mac { 1005 type yang:mac-address; 1006 description "mac address"; 1007 } 1008 leaf forward-enable { 1009 type boolean; 1010 description "whether enable forward"; 1011 } 1012 leaf logical-switch { 1013 type nw:node-id; 1014 description "lsw id"; 1015 } 1016 } 1017 } 1019 uses acl-list; 1020 uses port-functions; 1022 list underlayer-ports { 1023 key port-ref; 1024 description "list of the corresponding underlay ports"; 1025 leaf port-ref { 1026 type instance-identifier; 1027 description "port reference"; 1028 } 1029 } 1030 } 1031 } 1032 1034 file "ietf-fabric-service@2017-03-03.yang" 1035 module ietf-fabric-service { 1037 yang-version 1.1; 1038 namespace "urn:ietf:params:xml:ns:yang:ietf-fabric-service"; 1039 prefix fabric-services; 1041 import ietf-network { prefix nw; } 1042 import ietf-network-topology { prefix nt; } 1043 import ietf-fabric-types { prefix fabrictype; revision-date "2016-10-13"; } 1045 organization 1046 "IETF I2RS (Interface to the Routing System) Working Group"; 1048 contact 1049 "WG Web: 1050 WG List: < mailto:i2rs@ietf.org> 1052 WG Chair: Susan Hares 1053 1055 WG Chair: Russ White 1056 1058 Editor: Yan Zhuang 1059 1061 Editor: Danian Shi 1062 "; 1064 description 1065 "This module contains a collection of YANG definitions for Fabric services. 1066 Copyright (c) 2016 IETF Trust and the persons identified as 1067 authors of the code. All rights reserved. 1069 Redistribution and use in source and binary forms, with or 1070 without modification, is permitted pursuant to, and subject 1071 to the license terms contained in, the Simplified BSD License 1072 set forth in Section 4.c of the IETF Trust's Legal Provisions 1073 Relating to IETF Documents 1074 (http://trustee.ietf.org/license-info). 1076 This version of this YANG module is part of 1077 draft-zhuang-i2rs-yang-fabric-services; 1078 see the RFC itself for full legal notices."; 1080 revision "2017-03-03" { 1081 description 1082 "remove rpc commands"; 1083 reference 1084 "draft-zhuang-i2rs-yang-fabric-service-01"; 1085 } 1086 revision "2016-10-12" { 1087 description 1088 "Initial revision of fabric service."; 1089 reference 1090 "draft-zhuang-i2rs-yang-fabric-service-00"; 1091 } 1093 augment "/nw:networks/nw:network/nw:node" { 1094 description "Augmentation for logic switch nodes provided by fabrices."; 1096 container lsw-attribute { 1098 description "attributes for logical switches"; 1099 uses fabrictype:logical-switch; 1100 } 1101 } 1103 augment "/nw:networks/nw:network/nw:node" { 1104 description "Augmentation for logical router nodes provided by fabric services."; 1106 container lr-attribute { 1108 description "attributes for logical routers"; 1110 uses fabrictype:logical-router; 1111 } 1112 } 1114 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 1115 description "Augmentation for logical port provided by fabric services."; 1117 container lport-attribute { 1119 description "attributes for logical ports"; 1120 uses fabrictype:logical-port; 1121 } 1122 } 1123 } 1125 1127 file "ietf-fabric-endpoint@2017-06-29.yang" 1128 module ietf-fabric-endpoint { 1130 yang-version 1.1; 1131 namespace "urn:ietf:params:xml:ns:yang:ietf-fabric-endpoint"; 1132 prefix fabric-endpoints; 1134 import ietf-inet-types { prefix "inet"; revision-date "2013-07-15"; } 1135 import ietf-yang-types { prefix "yang"; revision-date "2013-07-15"; } 1136 import ietf-network { prefix nw; } 1137 import ietf-network-topology { prefix nt; } 1138 import ietf-fabric-types { prefix fabrictype; revision-date "2016-10-13"; } 1139 import ietf-fabric-topology { prefix fabric; } 1141 organization 1142 "IETF I2RS (Interface to the Routing System) Working Group"; 1144 contact 1145 "WG Web: 1146 WG List: 1148 WG Chair: Susan Hares 1149 1151 WG Chair: Russ White 1152 1154 Editor: Yan Zhuang 1155 1157 Editor: Danian Shi 1158 "; 1160 description 1161 "This module contains a collection of YANG definitions for endpoints in Fabric service. 1163 Copyright (c) 2016 IETF Trust and the persons identified as 1164 authors of the code. All rights reserved. 1166 Redistribution and use in source and binary forms, with or 1167 without modification, is permitted pursuant to, and subject 1168 to the license terms contained in, the Simplified BSD License 1169 set forth in Section 4.c of the IETF Trust's Legal Provisions 1170 Relating to IETF Documents 1171 (http://trustee.ietf.org/license-info). 1173 This version of this YANG module is part of 1174 draft-zhuang-i2rs-yang-dc-fabric-network-topology; 1175 see the RFC itself for full legal notices."; 1177 revision "2017-06-29" { 1178 description 1179 "compliant with NMDA"; 1180 reference 1181 "draft-zhuang-i2rs-yang-fabric-service-03"; 1182 } 1184 revision "2016-10-12" { 1185 description 1186 "Initial revision of faas."; 1187 reference 1188 "draft-zhuang-i2rs-yang-fabric-service-00"; 1189 } 1191 grouping device-location { 1192 description "the location for this endponits in the physical network."; 1194 leaf node-ref { 1195 type fabrictype:node-ref; 1196 description "node reference"; 1197 } 1199 leaf tp-ref { 1200 type fabrictype:tp-ref; 1201 description "port reference"; 1202 } 1204 leaf access-type { 1205 type fabrictype:access-type; 1206 default "exclusive"; 1207 description "access type"; 1208 } 1210 leaf access-segment { 1211 type uint32; 1212 default 0; 1213 description "access segement"; 1214 } 1215 } 1217 grouping endpoint-attributes { 1218 description "endpoint attributes"; 1220 leaf endpoint-uuid { 1221 type yang:uuid; 1222 description "endpoint id"; 1223 } 1225 leaf own-fabric { 1226 type fabric:fabric-id; 1227 description "fabric id"; 1228 } 1230 leaf mac-address { 1231 type yang:mac-address; 1232 description "mac addr"; 1233 } 1235 leaf ip-address { 1236 type inet:ip-address; 1237 description "ip addr"; 1238 } 1240 leaf gateway { 1241 type inet:ip-address; 1242 description "gateway ip"; 1243 } 1245 leaf public-ip { 1246 type inet:ip-address; 1247 description "public ip addr"; 1248 } 1250 container location { 1251 description "physical location of the endpoint"; 1252 uses device-location; 1254 } 1256 container logical-location { 1257 description "The location for this endpoint in the logical network."; 1259 leaf node-id { 1260 type nw:node-id; 1261 description "node id"; 1262 } 1264 leaf tp-id { 1265 type nt:tp-id; 1266 description "port id"; 1267 } 1268 } 1269 } 1271 container endpoints { 1272 description "endpoints registry for faas."; 1274 list endpoint { 1275 key "endpoint-uuid"; 1276 description "endpoint list"; 1278 uses endpoint-attributes; 1279 } 1280 } 1282 /********************RPC***************************************/ 1283 rpc register-endpoint { 1284 description 1285 "Register a new endpoing into the registry."; 1287 input { 1288 leaf fabric-id { 1289 type fabric:fabric-id; 1290 description "fabric id"; 1291 } 1293 uses endpoint-attributes; 1294 } 1295 output { 1296 leaf endpoint-id { 1297 type yang:uuid; 1298 description "endpoint id"; 1299 } 1300 } 1301 } 1302 rpc unregister-endpoint { 1303 description "Unregister an endpoint or endpoints from the registry."; 1304 input { 1305 leaf fabric-id { 1306 type fabric:fabric-id; 1307 description "fabric id"; 1308 } 1310 leaf-list ids { 1311 type yang:uuid; 1312 description "a list of ids"; 1313 } 1314 } 1315 } 1317 rpc locate-endpoint { 1318 description "Set the physical location of the endpoing."; 1319 input { 1320 leaf fabric-id { 1321 type fabric:fabric-id; 1322 description "fabric id"; 1323 } 1325 leaf endpoint-id { 1326 type yang:uuid; 1327 description "endpoint id"; 1328 } 1329 container location { 1330 description "locations"; 1331 uses device-location; 1332 } 1333 } 1334 } 1335 } 1336 1338 7. Security Considerations 1340 None. 1342 8. IANA Considerations 1344 None. 1346 9. References 1348 9.1. Normative References 1350 [I-D.ietf-i2rs-yang-network-topo] 1351 Clemm, A., Medved, J., Varga, R., Bahadur, N., 1352 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 1353 Topologies", draft-ietf-i2rs-yang-network-topo-14 (work in 1354 progress), June 2017. 1356 [I-D.zhuang-i2rs-yang-dc-fabric-network-topology] 1357 Zhuangyan, Z., Shi, D., Gu, R., and H. Ananthakrishnan, "A 1358 YANG Data Model for Fabric Topology in Data Center 1359 Network", draft-zhuang-i2rs-yang-dc-fabric-network- 1360 topology-03 (work in progress), March 2017. 1362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1363 Requirement Levels", BCP 14, RFC 2119, 1364 DOI 10.17487/RFC2119, March 1997, 1365 . 1367 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1368 Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, 1369 November 1997, . 1371 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1372 the Network Configuration Protocol (NETCONF)", RFC 6020, 1373 DOI 10.17487/RFC6020, October 2010, 1374 . 1376 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1377 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1378 . 1380 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1381 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1382 . 1384 9.2. Informative References 1386 [I-D.ietf-i2rs-usecase-reqs-summary] 1387 Hares, S. and M. Chen, "Summary of I2RS Use Case 1388 Requirements", draft-ietf-i2rs-usecase-reqs-summary-03 1389 (work in progress), November 2016. 1391 Authors' Addresses 1393 Yan Zhuang (editor) 1394 Huawei 1395 101 Software Avenue, Yuhua District 1396 Nanjing, Jiangsu 210012 1397 China 1399 Email: zhuangyan.zhuang@huawei.com 1401 Danian Shi 1402 Huawei 1403 101 Software Avenue, Yuhua District 1404 Nanjing, Jiangsu 210012 1405 China 1407 Email: shidanian@huawei.com 1409 Rong Gu 1410 China Mobile 1411 32 Xuanwumen West Ave, Xicheng District 1412 Beijing, Beijing 100053 1413 China 1415 Email: gurong_cmcc@outlook.com