idnits 2.17.1 draft-zhuang-i2rs-dc-fabric-service-model-05.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 31 instances of too long lines in the document, the longest one being 23 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 (August 31, 2017) is 2423 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 1108, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 1125, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 1134, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-usecase-reqs-summary' is defined on line 1144, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-i2rs-yang-network-topo-14 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 3 errors (**), 0 flaws (~~), 14 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: March 4, 2018 R. Gu 6 China Mobile 7 August 31, 2017 9 YANG Data Model for Fabric Service delivery in Data Center Network 10 draft-zhuang-i2rs-dc-fabric-service-model-05 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 March 4, 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 . . . . . . . . . . . . . . . . . . . 24 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 76 9.2. Informative References . . . . . . . . . . . . . . . . . 25 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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-service-types@2017-08-30.yang" 619 module ietf-fabric-service-types { 621 yang-version 1.1; 622 namespace "urn:ietf:params:xml:ns:yang:ietf-fabric-service-types"; 623 prefix fst; 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; } 628 import ietf-fabric-types { prefix ft; revision-date "2016-09-29"; } 630 import ietf-yang-types { prefix "yang"; revision-date "2013-07-15";} 632 organization 633 "IETF I2RS (Interface to the Routing System) Working Group"; 635 contact 636 "WG Web: 637 WG List: 639 WG Chair: Susan Hares 640 642 WG Chair: Russ White 643 645 Editor: Yan Zhuang 646 648 Editor: Danian Shi 649 "; 651 description 652 "This module contains a collection of YANG definitions for Fabric."; 654 revision "2017-08-30" { 655 description 656 "Initial revision of service types for fabric."; 657 reference 658 "draft-zhuang-i2rs-dc-fabric-service-model-04"; 659 } 661 ///groupings for logical element 662 grouping logical-switch { 663 description "grouping attributes for a logical switch."; 665 leaf lsw-uuid { 666 type yang:uuid; 667 description "logical switch id"; 668 } 669 leaf name { 670 type string; 671 description "logical switch name"; 673 } 674 leaf segment-id { 675 type uint32; 676 description "segement id"; 677 } 678 leaf network { 679 type inet:ip-prefix; 680 description "subnet"; 681 } 682 leaf external { 683 type boolean; 684 description "whether its a lsw to external network"; 685 } 686 uses ft:acl-list; 687 } 689 grouping logical-router { 690 description "grouping atttributes for a logical router"; 691 leaf lr-uuid { 692 type yang:uuid; 693 description "logical router id"; 694 } 695 leaf name { 696 type string; 697 description "logical router name"; 698 } 699 leaf vrf-ctx { 700 type uint32; 701 description "logical router vrf id"; 702 } 704 uses ft:acl-list; 706 container routes { 707 description "routes"; 708 uses ft:route-group; 709 } 710 } 712 grouping logical-port { 713 description "grouping attributes for logical ports"; 714 leaf lport-uuid { 715 type yang:uuid; 716 description "logical port id"; 717 } 718 leaf name { 719 type string; 720 description "logical port name"; 722 } 723 container port-layer { 724 description "layer information of the lport"; 726 container layer-1-info { 727 description "layer 1 information of the lport"; 728 leaf location { 729 type nt:tp-id; 730 description "L1 tp id"; 731 } 732 } 733 container layer-2-info { 734 description "layer 2 information of the lport"; 735 leaf access-type { 736 type ft:access-type; 737 description "l2 access type"; 738 } 739 leaf access-segment { 740 type uint32; 741 description "access segement"; 742 } 743 } 744 container layer-3-info { 745 description "layer 3 information of the lport"; 746 leaf ip { 747 type inet:ip-address; 748 description "ip address"; 749 } 750 leaf network { 751 type inet:ip-prefix; 752 description "ip prefix"; 753 } 754 leaf mac { 755 type yang:mac-address; 756 description "mac address"; 757 } 758 leaf forward-enable { 759 type boolean; 760 description "whether enable forward"; 761 } 762 leaf logical-switch { 763 type nw:node-id; 764 description "lsw id"; 765 } 766 } 767 } 769 uses ft:acl-list; 770 uses ft:port-functions; 772 list underlayer-ports { 773 key port-ref; 774 description "list of the corresponding underlay ports"; 775 leaf port-ref { 776 type instance-identifier; 777 description "port reference"; 778 } 779 } 780 } 781 } 782 784 file "ietf-fabric-service@2017-08-30.yang" 785 module ietf-fabric-service { 787 yang-version 1.1; 788 namespace "urn:ietf:params:xml:ns:yang:ietf-fabric-service"; 789 prefix fabric-services; 791 import ietf-network { prefix nw; } 792 import ietf-network-topology { prefix nt; } 793 import ietf-fabric-service-types {prefix fst;} 795 organization 796 "IETF I2RS (Interface to the Routing System) Working Group"; 798 contact 799 "WG Web: 800 WG List: < mailto:i2rs@ietf.org> 802 WG Chair: Susan Hares 803 805 WG Chair: Russ White 806 808 Editor: Yan Zhuang 809 811 Editor: Danian Shi 812 "; 814 description 815 "This module contains a collection of YANG definitions for Fabric services. 816 Copyright (c) 2016 IETF Trust and the persons identified as 817 authors of the code. All rights reserved. 819 Redistribution and use in source and binary forms, with or 820 without modification, is permitted pursuant to, and subject 821 to the license terms contained in, the Simplified BSD License 822 set forth in Section 4.c of the IETF Trust's Legal Provisions 823 Relating to IETF Documents 824 (http://trustee.ietf.org/license-info). 826 This version of this YANG module is part of 827 draft-zhuang-i2rs-yang-fabric-services; 828 see the RFC itself for full legal notices."; 830 revision "2017-08-30" { 831 description 832 "refer to fabric-service-type module instead of fabric-type."; 833 reference 834 "draft-zhuang-i2rs-yang-fabric-service-04"; 835 } 837 revision "2017-03-03" { 838 description 839 "remove rpc commands"; 840 reference 841 "draft-zhuang-i2rs-yang-fabric-service-01"; 842 } 843 revision "2016-10-12" { 844 description 845 "Initial revision of fabric service."; 846 reference 847 "draft-zhuang-i2rs-yang-fabric-service-00"; 848 } 850 augment "/nw:networks/nw:network/nw:node" { 851 description "Augmentation for logic switch nodes provided by fabrices."; 853 container lsw-attribute { 855 description 856 "attributes for logical switches"; 857 uses fst:logical-switch; 858 } 859 } 861 augment "/nw:networks/nw:network/nw:node" { 862 description "Augmentation for logical router nodes provided by fabric services."; 864 container lr-attribute { 866 description "attributes for logical routers"; 868 uses fst:logical-router; 869 } 870 } 872 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 873 description "Augmentation for logical port provided by fabric services."; 875 container lport-attribute { 877 description "attributes for logical ports"; 878 uses fst:logical-port; 879 } 880 } 881 } 883 885 file "ietf-fabric-endpoint@2017-06-29.yang" 886 module ietf-fabric-endpoint { 888 yang-version 1.1; 889 namespace "urn:ietf:params:xml:ns:yang:ietf-fabric-endpoint"; 890 prefix fabric-endpoints; 892 import ietf-inet-types { prefix "inet"; revision-date "2013-07-15"; } 893 import ietf-yang-types { prefix "yang"; revision-date "2013-07-15"; } 894 import ietf-network { prefix nw; } 895 import ietf-network-topology { prefix nt; } 896 import ietf-fabric-types { prefix fabrictype;} 897 import ietf-fabric-topology { prefix fabric; } 899 organization 900 "IETF I2RS (Interface to the Routing System) Working Group"; 902 contact 903 "WG Web: 904 WG List: 906 WG Chair: Susan Hares 907 909 WG Chair: Russ White 910 912 Editor: Yan Zhuang 913 915 Editor: Danian Shi 916 "; 918 description 919 "This module contains a collection of YANG definitions for endpoints in Fabric service. 921 Copyright (c) 2016 IETF Trust and the persons identified as 922 authors of the code. All rights reserved. 924 Redistribution and use in source and binary forms, with or 925 without modification, is permitted pursuant to, and subject 926 to the license terms contained in, the Simplified BSD License 927 set forth in Section 4.c of the IETF Trust's Legal Provisions 928 Relating to IETF Documents 929 (http://trustee.ietf.org/license-info). 931 This version of this YANG module is part of 932 draft-zhuang-i2rs-yang-dc-fabric-network-topology; 933 see the RFC itself for full legal notices."; 935 revision "2017-06-29" { 936 description 937 "compliant with NMDA"; 938 reference 939 "draft-zhuang-i2rs-yang-fabric-service-03"; 940 } 942 revision "2016-10-12" { 943 description 944 "Initial revision of faas."; 945 reference 946 "draft-zhuang-i2rs-yang-fabric-service-00"; 947 } 949 grouping device-location { 950 description "the location for this endponits in the physical network."; 952 leaf node-ref { 953 type fabrictype:node-ref; 954 description "node reference"; 955 } 957 leaf tp-ref { 958 type fabrictype:tp-ref; 959 description "port reference"; 960 } 962 leaf access-type { 963 type fabrictype:access-type; 964 default "exclusive"; 965 description "access type"; 966 } 968 leaf access-segment { 969 type uint32; 970 default 0; 971 description "access segement"; 972 } 973 } 975 grouping endpoint-attributes { 976 description "endpoint attributes"; 978 leaf endpoint-uuid { 979 type yang:uuid; 980 description "endpoint id"; 981 } 983 leaf own-fabric { 984 type fabric:fabric-id; 985 description "fabric id"; 986 } 988 leaf mac-address { 989 type yang:mac-address; 990 description "mac addr"; 991 } 993 leaf ip-address { 994 type inet:ip-address; 995 description "ip addr"; 996 } 998 leaf gateway { 999 type inet:ip-address; 1000 description "gateway ip"; 1001 } 1003 leaf public-ip { 1004 type inet:ip-address; 1005 description "public ip addr"; 1006 } 1008 container location { 1009 description "physical location of the endpoint"; 1010 uses device-location; 1012 } 1014 container logical-location { 1015 description "The location for this endpoint in the logical network."; 1017 leaf node-id { 1018 type nw:node-id; 1019 description "node id"; 1020 } 1022 leaf tp-id { 1023 type nt:tp-id; 1024 description "port id"; 1025 } 1026 } 1027 } 1029 container endpoints { 1030 description "endpoints registry for faas."; 1032 list endpoint { 1033 key "endpoint-uuid"; 1034 description "endpoint list"; 1036 uses endpoint-attributes; 1037 } 1038 } 1040 /********************RPC***************************************/ 1041 rpc register-endpoint { 1042 description 1043 "Register a new endpoing into the registry."; 1045 input { 1046 leaf fabric-id { 1047 type fabric:fabric-id; 1048 description "fabric id"; 1049 } 1051 uses endpoint-attributes; 1052 } 1053 output { 1054 leaf endpoint-id { 1055 type yang:uuid; 1056 description "endpoint id"; 1057 } 1058 } 1059 } 1060 rpc unregister-endpoint { 1061 description "Unregister an endpoint or endpoints from the registry."; 1062 input { 1063 leaf fabric-id { 1064 type fabric:fabric-id; 1065 description "fabric id"; 1066 } 1068 leaf-list ids { 1069 type yang:uuid; 1070 description "a list of ids"; 1071 } 1072 } 1073 } 1075 rpc locate-endpoint { 1076 description "Set the physical location of the endpoing."; 1077 input { 1078 leaf fabric-id { 1079 type fabric:fabric-id; 1080 description "fabric id"; 1081 } 1083 leaf endpoint-id { 1084 type yang:uuid; 1085 description "endpoint id"; 1086 } 1087 container location { 1088 description "locations"; 1089 uses device-location; 1090 } 1091 } 1092 } 1093 } 1094 1096 7. Security Considerations 1098 None. 1100 8. IANA Considerations 1102 None. 1104 9. References 1106 9.1. Normative References 1108 [I-D.ietf-i2rs-yang-network-topo] 1109 Clemm, A., Medved, J., Varga, R., Bahadur, N., 1110 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 1111 Topologies", draft-ietf-i2rs-yang-network-topo-14 (work in 1112 progress), June 2017. 1114 [I-D.zhuang-i2rs-yang-dc-fabric-network-topology] 1115 Zhuangyan, Z., Shi, D., Gu, R., and H. Ananthakrishnan, "A 1116 YANG Data Model for Fabric Topology in Data Center 1117 Network", draft-zhuang-i2rs-yang-dc-fabric-network- 1118 topology-04 (work in progress), July 2017. 1120 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1121 Requirement Levels", BCP 14, RFC 2119, 1122 DOI 10.17487/RFC2119, March 1997, . 1125 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1126 Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, 1127 November 1997, . 1129 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1130 the Network Configuration Protocol (NETCONF)", RFC 6020, 1131 DOI 10.17487/RFC6020, October 2010, . 1134 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1135 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1136 . 1138 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1139 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1140 . 1142 9.2. Informative References 1144 [I-D.ietf-i2rs-usecase-reqs-summary] 1145 Hares, S. and M. Chen, "Summary of I2RS Use Case 1146 Requirements", draft-ietf-i2rs-usecase-reqs-summary-03 1147 (work in progress), November 2016. 1149 Authors' Addresses 1151 Yan Zhuang (editor) 1152 Huawei 1153 101 Software Avenue, Yuhua District 1154 Nanjing, Jiangsu 210012 1155 China 1157 Email: zhuangyan.zhuang@huawei.com 1159 Danian Shi 1160 Huawei 1161 101 Software Avenue, Yuhua District 1162 Nanjing, Jiangsu 210012 1163 China 1165 Email: shidanian@huawei.com 1167 Rong Gu 1168 China Mobile 1169 32 Xuanwumen West Ave, Xicheng District 1170 Beijing, Beijing 100053 1171 China 1173 Email: gurong_cmcc@outlook.com