idnits 2.17.1 draft-zhuang-i2rs-dc-fabric-service-model-02.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 51 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 481 has weird spacing: '...cl-name str...' == Line 488 has weird spacing: '...cl-name str...' == Line 492 has weird spacing: '...-prefix ine...' == Line 514 has weird spacing: '...cl-name str...' == Line 519 has weird spacing: '...rnal-ip ine...' == (4 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2017) is 2601 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 1638, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 1655, but no explicit reference was found in the text == Unused Reference: 'RFC6991' is defined on line 1664, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-usecase-reqs-summary' is defined on line 1674, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-i2rs-yang-network-topo-12 == 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: September 12, 2017 R. Gu 6 China Mobile 7 March 11, 2017 9 YANG Data Model for Fabric Service delivery in Data Center Network 10 draft-zhuang-i2rs-dc-fabric-service-model-02 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 September 12, 2017. 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 5.3. Fabric capable device module . . . . . . . . . . . . . . 14 72 6. Fabric Service YANG Modules . . . . . . . . . . . . . . . . . 16 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 36 77 9.2. Informative References . . . . . . . . . . . . . . . . . 36 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 80 1. Introduction 82 Network service provisioning is currently coupled with specific 83 network topology and technology applied, which is technology and 84 device oriented. 86 In the area of data center, this approach makes the management 87 complex due to massive network devices involved and various 88 applications deployed by multiple users (also known as tenants). 90 In the traditional way, the administrator has to be aware of the 91 entire data center network before delivering services for users. 92 When service request comes up, administrator has to divide the 93 request into appropriate configurations and operations for all 94 involved devices manually. Finally, these configurations are 95 deployed onto network infrastructure, which requires personnel 96 skills. 98 Actually different users share the same network infrastructure. A 99 more dynamical way to deploy and manage the network is eager to be 100 found out. Here we decompose the network management system into 101 several layers in order to have network service provision more 102 flexible and automatic. Each network layer is dedicated to be 103 managed. What is more, all the layers can be combined to fulfill the 104 delivery of the user's service. 106 We can use three layers in data center network. The bottom one is 107 physical infrastructure with massive devices. The middle one is 108 fabric topology defined in [I-D.zhuang-i2rs-yang-dc-fabric-network- 109 topology]. Unlike the physical layer, the fabric layer is used to 110 display a fabric network including features and boundaries. In the 111 fabric layer, a set of fabrics can exist with each managed 112 independently. Furthermore, a bottom-up abstraction of fabric 113 service is proposed to provide application centric interfaces facing 114 to users which define network services regardless of beneath fabric 115 topology and physical connections in the up layer. 117 This document defines a YANG [RFC6020] [RFC7950] data model focusing 118 on the fabric service interfaces to define user fabric network 119 services regardless of specific beneath network topology and devices. 120 This model defines the generic configuration for fabric services 121 within DC networks. 123 For example, this model can be used by the network orchestrator in 124 which the fabric service interfaces are exposed. When a service from 125 user application is requested, orchestrator adopts this model 126 including service information and processes it into the topology 127 layer through a DC controller. Thus a service is automatically and 128 dynamically provided. 130 The service data model includes three main modules: 132 (a)Module "ietf-fabric-service" defines a module for user network 133 service over fabric networks from the application centric view. To 134 do so, it augments general network topology model defined in [I- 135 D.ietf-i2rs-yang-network-topo] with logical components such as 136 logical switches, logical routers as well as logical ports to carry 137 network services requested by user applications. 139 (b)Module "ietf-fabric-endpoint" defines a module for hosts that run 140 applications and generate traffics. The major usage of this module 141 is to indicate the attachment points of a host in a user service 142 network as well as in a physical network when it is initialed, so as 143 to build bindings between physical layer and topology layer 144 dynamically. 146 (c) Module "ietf-fabric-capable-device" defines a module for 147 configuration and operation onto network devices generated based on 148 information in fabric topology and fabric service modules. 150 Besides, the model "ietf-fabric-topology" defined in [I-D.zhuang- 151 i2rs-yang-dc-fabric-network-topology] with topology and resource as 152 well as technology information is used to work together to implement 153 configurations and operations of the fabric service onto the specific 154 fabric infrastructure. 156 2. Concept and Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 2.1. Terminology 164 Fabric topology: a data center network can be decomposed to a set of 165 fabric networks, while each of these fabrics composes a set of 166 physical nodes/links of the physical infrastructure to form a fabric 167 network. The fabric topology includes attributes of fabrics, such as 168 gateway mode, involved nodes, roles of involved nodes etc al. 170 Fabric Service: it is used as a service interface of fabric networks 171 to users, which uses logical elements to represent network 172 connections between hosts for applications, regardless of a specific 173 fabric topology deployment. Each service instance is based on a 174 fabric topology, while a fabric can provide multiple service 175 instances for different users, each of which is isolated to others. 177 Endpoint: an endpoint represents a host, which can be a virtual 178 machine on a server or a bare-metal server. 180 Fabric capable device: a physical device (e.g. a switch) that 181 supports fabric service and fabric topology models. 183 3. Fabric service framework overview 185 This draft provides a network service interface on top of fabrics 186 network layer. Users can use these network service interfaces to 187 deploy their applications over a data center network automatically 188 and dynamically. 190 From the application centric point of view, user hosts can be 191 considered to connect with other hosts through a switch if they are 192 L2 reachable, alternatively, connect through a router if they are L3 193 reachable simply. So a user network can be abstracted into a logical 194 network where L2 reachable represents logical switches connecting 195 hosts and L3 reachable represents logical routers connecting 196 switches. 198 With this concept, a user can use appropriate logical elements to 199 define their networks and configure attributes of these elements such 200 as vlan id, gateway etc al. All of these form a network service. 201 For example, a fabric service diagram for a user is shown as below. 203 |C3 - L3 Interconnect 204 | 205 |logical port- external gateway 206 +-----------|------------+ 207 | | 208 | Logical Router | 209 | | 210 +---|--------------|-----+ 211 | |logical port-gateway port 212 | |C2 213 | | 214 | | 215 +-----------|----+ +-|--------------+ 216 | | | | Logical port-Access port 217 | Logical Switch | | Logical Switch ------ 218 | | | | C4 - L2 Interconnect 219 +-|---------|----+ +-|---------|----+ 220 | | |C1 | 221 | | | | 222 +-----|---+ +--|------+ +----|----+ +-|-------+ 223 | Endpoint| | Endpoint| | Endpoint| | Endpoint| 224 +---------+ +---------+ +---------+ +---------+ 226 Figure 1: Diagram of a fabric service 228 In the diagram, abstraction of network connections is focused as a 229 very initial effort to abstract services for fabric-based DC 230 networks. Based on the connection, we can add other network 231 appliance for which the fabric service should be extended. 233 3.1. Service element 235 There are four major components regarding as service elements within 236 a fabric service as depicted in Figure 1. 238 Logical Switch: 240 Works as a switch within a logical fabric network to provide L2 241 connections between hosts or to a logical router or to external 242 networks. It can be bounded to one or several physical switches. 244 Logical Router: 246 Works as a router to provide L3 connections between logical switches 247 or to external networks. 249 Logical Port: 251 Provides port function on logical switches and logical routers which 252 claims their connections to others. 254 Endpoint: 256 Represents user hosts which can be a VM or a bare-metal server. 258 3.2. Functionality of connections 260 There are 4 connections between elements within the fabric service 261 framework listed as follows: 263 C1: Endpoint attachment. It is used by an endpoint to connect to a 264 logical switch. 266 C2: L2 to L3 attachment. Interface between a logical switch and a 267 logical router within the same fabric. 269 C3: L3 interconnection which connects to a logical router. 271 C4: L2 interconnection which connects to a logical switch in another 272 fabric. 274 Thinking of the functionality of different connections, a logical 275 port can act as an access port (which provides C1/C4/C3 connection to 276 a network element), or a service port (which provide C2 gateway 277 connection) as shown in Figure 2. 279 +---------------+ 280 | Logical Port | 281 +--+----------+-+ 282 | | 283 | | 284 | | 285 | | 286 +--------------+-+ `````````````````` 287 | Access Port | ` Service Port ` 288 +----------------+ ```|```````````|`` 289 | | 290 | | 291 | | 292 | | 293 +------------+--+ +--+------------+ 294 | Gateway Port | | External GW | 295 +---------------+ +---------------+ 297 Figure 2: Types of Logical port 299 When a logical port is noticed as an access port, there will be a 300 corresponding physical port. In this situation, the required access 301 configuration can be deployed on this physical port directly. 302 However, there will be a gateway service if a logical port is noticed 303 as a service port. In this situation, the management system should 304 combine the gateway function and fabric territory at fabric topology 305 layer together with the gateway configuration on the service port. 306 By the combination, it is easy to figure out the appropriate devices 307 in the physical infrastructure and their configurations for these 308 devices respectively. 310 4. Fabric service model usage 312 4.1. Usage architecture 314 In section 3, a fabric service interface is provided for users to 315 define their networks in a more concentrated and intuitive way. To 316 be detailed, when a fabric service comes, the topology manager will 317 parse services into configuration/operations of specific network 318 devices automatically. In this process, service interface 319 information and topology information from fabric topology defined in 320 [I-D.zhuang-i2rs-yang-dc-fabric-network-topology] is needed. 322 The whole process is shown in Fig.3. Fabric service module is used 323 define network services for applications maybe by an orchestration 324 for example, according to the topology architecture stated in [I- 325 D.draft-ietf-i2rs-usecase-reqs-summary]. The topology information 326 maintenance should be done by a topology manager. By combining 327 information from different layers, a topology manager automatically 328 generates configurations and operations of related devices and 329 deploys them respectively over the physical fabric infrastructures. 330 Here, the fabric-capable-device module can be used to configure 331 involved devices. 333 +-------------------+ 334 | | 335 | Orchestrator | 336 | | 337 +---------|---------+ 338 | 339 | Fabric service data 340 | module 341 | 342 +---------V---------+ 343 | | 344 | Topology Manager | Network Provider 345 | | 346 +-----+---^---------+ 347 | | 348 | | 349 Fabric Capable | |Fabric Topology data 350 Device module | | module 351 ........................|...|............................. 352 | | 353 +--+---V---------+ 354 +---V------------+| 355 +----------------+|| 356 | ||| Network 357 | Device ||+ 358 | |+ 359 +----------------+ 361 Figure 3: Fabric service Usage architecture 363 4.2. Multi-Layer interconnection 365 There are three layers in this usage. 367 At the service layer, a fabric service model is abstracted from 368 fabric network used as an application-centric interface to define 369 user networks. It focuses on the connection services from users' 370 perspective. Using the fabric service interface, an administrator 371 can define a logical network for each user over a single fabric 372 network while each logical networks can be managed separately. 374 For the fabric topology layer, it collects and maintains the fabric 375 topology information (including territory of the physical fabric, 376 connections, gateway functions, roles of devices within the fabric 377 and specific technologies for each fabric) upon the physical network 378 layer. 380 With information provided by both fabric service as well as fabric 381 topology, a fabric topology manager will calculates and generates 382 configuration and operation for involved network devices in the 383 physical layer so as to distribute and deploy them onto network 384 infrastructure. 386 The diagram of the management architecture and its relationship is 387 depicted as below. 389 +----------+ 390 | | 391 | LR-1 |................ 392 | | 393 +--/---\---+ 394 gateway: / \ gateway: 395 10.0.35.1 / \ 10.0.36.1````` Fabric Service Layer 396 / \ ` 397 +---------+ +---------+ ` 398 | | | | ` 399 +---| LSW-11 | | LSW-12 | ` 400 | +-----|---+ +---------+ ` 401 | | | ` 402 | | | ` +--------+ 403 | | | ` | | 404 | | | ` |Fabric-3| 405 | | | ` | | 406 | | | ` +-/ ---\-+ 407 | | | ` / \ 408 | | | ` / \ 409 | | | ` +------ /+ +\ ------+ 410 | | | ` | | | | 411 | | | ` |Fabric-1|--------|Fabric-2| 412 | | | ` | | | | 413 | | | ` +--------+ +--------+ 414 | | | `````gateway/roles 415 | +-----------------------+ of nodes 416 | | | ` Fabric Topology Layer 417 | Fabric-1 | | ` 418 | +-------+ | | ` 419 | +--------+|`````````````````````` 420 | +--------+|| | | 421 | | ||+ | | 422 | | SPINE |+ | | 423 | +--------+ | | 424 | |||| | | 425 | |||-------+ | | 426 | +|||------+| | | Physcial Layer 427 | +-||------+|| | | 428 | +--|------+||+ | | 429 | +---------+||+ | | 430 | | LEAF ||+\ | | 431 | | device |+ \ | | 432 | +---------+ \| | 433 | / \ \ | 434 | / \ |\ | 435 | / \ | \ | 436 | +/-+ +-\+ | \ +-|+ 437 +--------| | | |---+ \| | 438 +--+ +--+ +--+ 439 H1:10.0.35.2 H2:10.0.36.2 H3:10.0.35.3 441 Figure 4: Multi-layer interconnection 443 The mapping of nodes with access logical ports is realized by 444 endpoints e.g. H1,H2 and H3 in Fig.4. An endpoint is instantiated 445 by the orchestrator to indicate the locations of a host both in the 446 logical layer as well as in the physical layer, so as to deliver 447 services requested from the logical port onto the physical port in a 448 dynamic manner. For H1 and H3, they are considered to connect to the 449 same switch for user in the logical layer, even they attach to the 450 different devices. 452 Besides, gateway configuration is defined at service layer while the 453 gateway mode and gateway devices (for distributed gateway, the 454 gateway should be deployed on LEAF devices, while for centralized 455 gateway, the configuration should be on SPINE) are defined in fabric 456 topology layer. By combing the gateway information from both layers, 457 the system can automatically figure out the involved devices and 458 generate appropriate configurations onto them. 460 5. Design of the data model 462 5.1. Fabric service module 464 As explained previously, network service for user network can be 465 abstracted to sets of logical switches, logical routers and logical 466 ports. Upon these logical elements, acl policies and gateway 467 functions can be attached. 469 The fabric service module is defined by YANG module "ietf-fabric- 470 service". The module is depicted in the following diagram. 472 module: ietf-fabric-service 473 augment /nw:networks/nw:network/nw:node: 474 +--ro lsw-attribute 475 +--ro lsw-uuid? yang:uuid 476 +--ro name? string 477 +--ro segment-id? uint32 478 +--ro network? inet:ip-prefix 479 +--ro external? boolean 480 +--ro fabric-acl* [fabric-acl-name] 481 +--ro fabric-acl-name string 482 augment /nw:networks/nw:network/nw:node: 483 +--ro lr-attribute 484 +--ro lr-uuid? yang:uuid 485 +--ro name? string 486 +--ro vrf-ctx? uint32 487 +--ro fabric-acl* [fabric-acl-name] 488 | +--ro fabric-acl-name string 489 +--ro routes 490 +--ro route* [destination-prefix] 491 +--ro description? string 492 +--ro destination-prefix inet:ipv4-prefix 493 +--ro (next-hop-options)? 494 +--:(simple-next-hop) 495 +--ro next-hop? inet:ipv4-address 496 +--ro outgoing-interface? nt:tp-id 497 augment /nw:networks/nw:network/nw:node/nt:termination-point: 498 +--ro lport-attribute 499 +--ro lport-uuid? yang:uuid 500 +--ro name? string 501 +--ro port-layer 502 | +--ro layer-1-info 503 | | +--ro location? nt:tp-id 504 | +--ro layer-2-info 505 | | +--ro access-type? access-type 506 | | +--ro access-segment? uint32 507 | +--ro layer-3-info 508 | +--ro ip? inet:ip-address 509 | +--ro network? inet:ip-prefix 510 | +--ro mac? yang:mac-address 511 | +--ro forward-enable? boolean 512 | +--ro logical-switch? nw:node-id 513 +--ro fabric-acl* [fabric-acl-name] 514 | +--ro fabric-acl-name string 515 +--ro port-function 516 | +--ro (function-type)? 517 | +--:(ip-mapping) 518 | +--ro ip-mapping-entry* [external-ip] 519 | +--ro external-ip inet:ipv4-address 520 | +--ro internal-ip? inet:ipv4-address 521 +--ro underlayer-ports* [port-ref] 522 +--ro port-ref instance-identifier 524 Figure 5: Fabric Service Module 526 To provide a logical network topology for DC fabric network, the 527 module augments the original ietf-network and ietf-network-topology 528 modules: 530 o New nodes for logical switch and logical router with additional 531 data objects are introduced by augmenting the "node" list of the 532 network module. 534 o Termination points for logical ports are augmented with logical 535 port information and its reference to termination ports in the 536 underlay topologies. As stated in section 3, the logical port may 537 act as an access port which will be bounded to some physical port, 538 or else it may be as a service point which connects to internal 539 gateway or external gateway. Besides, it can also be attached 540 with ACL rules. 542 5.2. Endpoint module 544 To represent user attachments points and map logical fabric 545 configurations and operations of applications onto the physical 546 fabric infrastructure, an endpoint is instantiated to represent a 547 host of a user that runs applications. 549 The fabric endpoint module is defined by YANG module "ietf-fabric- 550 endpoint". The module is depicted as follows: 552 module: ietf-fabric-endpoint 553 +--ro endpoints 554 +--ro endpoint* [endpoint-uuid] 555 +--ro endpoint-uuid yang:uuid 556 +--ro own-fabric? fabric:fabric-id 557 +--ro mac-address? yang:mac-address 558 +--ro ip-address? inet:ip-address 559 +--ro gateway? inet:ip-address 560 +--ro public-ip? inet:ip-address 561 +--ro location 562 | +--ro node-ref? fabrictype:node-ref 563 | +--ro tp-ref? fabrictype:tp-ref 564 | +--ro access-type? fabrictype:access-type 565 | +--ro access-segment? uint32 566 +--ro logical-location 567 +--ro node-id? nw:node-id 568 +--ro tp-id? nt:tp-id 570 Figure 6: Fabric endpoint module 572 By indicating locations of an endpoint in "location" container, the 573 logical network elements such as logical nodes and logical 574 termination points are bounded to the network elements in a specific 575 fabric. Then the network configurations and operations from the 576 logical network together with its belonged fabric topology 577 information will further be distributed onto the bounding/related 578 physical elements by the network topology manager. 580 Besides, the module defines three rpc commands to register, 581 unregister and locate the endpoint onto both logical network and 582 physical network shown as follows. 584 rpcs: 585 +---x register-endpoint 586 | +---w input 587 | | +---w fabric-id? fabric:fabric-id 588 | | +---w endpoint-uuid? yang:uuid 589 | | +---w own-fabric? fabric:fabric-id 590 | | +---w mac-address? yang:mac-address 591 | | +---w ip-address? inet:ip-address 592 | | +---w gateway? inet:ip-address 593 | | +---w public-ip? inet:ip-address 594 | | +---w location 595 | | | +---w node-ref? fabrictype:node-ref 596 | | | +---w tp-ref? fabrictype:tp-ref 597 | | | +---w access-type? fabrictype:access-type 598 | | | +---w access-segment? uint32 599 | | +---w logical-location 600 | | +---w node-id? nw:node-id 601 | | +---w tp-id? nt:tp-id 602 | +--ro output 603 | +--ro endpoint-id? yang:uuid 604 +---x unregister-endpoint 605 | +---w input 606 | +---w fabric-id? fabric:fabric-id 607 | +---w ids* yang:uuid 608 +---x locate-endpoint 609 +---w input 610 +---w fabric-id? fabric:fabric-id 611 +---w endpoint-id? yang:uuid 612 +---w location 613 +---w node-ref? fabrictype:node-ref 614 +---w tp-ref? fabrictype:tp-ref 615 +---w access-type? fabrictype:access-type 616 +---w access-segment? uint32 618 Figure 7: Fabric endpoint module RPC 620 5.3. Fabric capable device module 622 The fabric-capable-device module is to configure individual network 623 elements i.e. devices of physical network based on belonged fabric 624 topology and fabric services expressed by users. This module can be 625 used by a topology manager. 627 The structure of "ietf-fabric-capable-device" data model is depicted 628 in the following diagram. 630 module: ietf-fabric-capable-device 631 augment /nw:networks/nw:network/nw:node: 632 +--rw supported-fabric* identityref 633 +--rw capability-supported* fabrictype:service-capabilities 634 +--ro attributes 635 | +--ro fabric-id? nw:node-id 636 | +--ro fabric-ref? fabrictype:node-ref 637 +--rw config 638 +--rw bridge-domain* [id] 639 | +--rw id string 640 | +--rw flood? boolean 641 | +--rw arp? boolean 642 | +--rw segment? uint32 643 +--rw bd-port* [bd-port-id] 644 | +--rw bd-port-id string 645 | +--rw bdid? string 646 | +--rw ref-tp-id? nw:node-id 647 | +--rw access-type? fabrictype:access-type 648 | +--rw access-tag? uint32 649 | +--rw fabric-acl* [fabric-acl-name] 650 | +--rw fabric-acl-name string 651 +--rw vrf* [id] 652 | +--rw id string 653 | +--rw name? string 654 | +--rw vrf-ctx? int32 655 +--rw bdif* [id] 656 +--rw id string 657 +--rw bdid? string 658 +--rw vrf? int32 659 +--rw ip-address? inet:ip-address 660 +--rw mask? int32 661 +--rw mac-address? yang:mac-address 662 +--rw fabric-acl* [fabric-acl-name] 663 | +--rw fabric-acl-name string 664 +--rw port-function 665 +--rw (function-type)? 666 +--:(ip-mapping) 667 +--rw ip-mapping-entry* [external-ip] 668 +--rw external-ip inet:ipv4-address 669 +--rw internal-ip? inet:ipv4-address 670 augment /nw:networks/nw:network/nw:node/nt:termination-point: 671 +--rw port-role? fabrictype:fabric-port-role 672 +--rw port-ref? fabrictype:tp-ref 673 augment /nw:networks/nw:network/nw:node/nt:termination-point: 674 +--rw bd-ids* instance-identifier 676 Figure 8: Fabric capable device module 678 The ietf-fabric-capable-device augments the generic ietf-network and 679 ietf-network-topology modules with specific attributes for fabric 680 services as follows: 682 o Additional data objects for nodes are introduced by augmenting the 683 "node" list of the network module to carry specific fabric 684 features for a fabric capable device. New objects include type of 685 supported fabric such as VXLAN fabric or VLAN fabric, supported 686 capability such as whether the device supports Network Address 687 Transformation or Service Function Chain functions. Also, the 688 "host" fabric is indicated to show which fabric the device 689 belonged to. 691 o Besides, new objects for configuring the device are contained in 692 the "config" container, which includes the L2 attributes and L3 693 attributes of the bridge. 695 o Termination points are also augmented with attributes to indicate 696 the role of the device port in a fabric and its role in the bridge 697 network. 699 6. Fabric Service YANG Modules 701 file "ietf-fabric-types@2016-10-13.yang" 702 module ietf-fabric-types { 704 yang-version 1.1; 705 namespace "urn:ietf:params:xml:ns:yang:ietf-fabric-types"; 706 prefix fabrictypes; 708 import ietf-inet-types { prefix "inet"; revision-date "2013-07-15"; } 710 import ietf-network-topology { prefix nt; } 711 import ietf-network { prefix nw; } 713 import ietf-yang-types { prefix "yang"; revision-date "2013-07-15";} 715 organization 716 "IETF I2RS (Interface to the Routing System) Working Group"; 718 contact 719 "WG Web: 720 WG List: 722 WG Chair: Susan Hares 723 725 WG Chair: Russ White 726 728 Editor: Yan Zhuang 729 731 Editor: Danian Shi 732 "; 734 description 735 "This module contains a collection of YANG definitions for Fabric."; 737 revision "2016-10-13" { 738 description 739 "Initial revision of faas."; 740 reference "draft-zhuang-i2rs-yang-dc-fabric-network-topology-02 and draft-zhuang-i2rs-dc-fabric-service-model-00"; 741 } 743 identity fabric-type { 744 description 745 "base type for fabric networks"; 746 } 748 identity vxlan-fabric { 749 base fabric-type; 750 description 751 "vxlan fabric"; 752 } 754 identity vlan-fabric { 755 base fabric-type; 756 description 757 "vlan fabric"; 758 } 760 typedef service-capabilities { 761 type enumeration { 762 enum ip-mapping { 763 description "NAT"; 764 } 765 enum acl-redirect{ 766 description "acl redirect, which can provide SFC function"; 767 } 768 enum dynamic-route-exchange{ 769 description "dynamic route exchange"; 770 } 771 } 772 description 773 "capability of the device"; 774 } 775 /* 776 * Typedefs 777 */ 778 typedef node-ref { 779 type instance-identifier; 780 description "A reference to a node in topology"; 781 } 783 typedef tp-ref { 784 type instance-identifier; 785 description "A reference to a termination point in topology"; 786 } 788 typedef link-ref { 789 type instance-identifier; 790 description "A reference to a link in topology"; 791 } 793 typedef device-role { 794 type enumeration { 795 enum SPINE { 796 description "a spine node"; 797 } 798 enum LEAF { 799 description "a leaf node"; 800 } 801 enum BORDER { 802 description "a border node"; 803 } 804 } 805 default "LEAF"; 806 description "device role type"; 807 } 809 typedef fabric-port-role { 810 type enumeration { 811 enum internal { 812 description "the port used for devices to access each other."; 813 } 814 enum external { 815 description "the port used for fabric to access outside network."; 816 } 817 enum access { 818 description "the port used for Endpoint to access fabric."; 819 } 820 enum reserved { 821 description " not decided yet. "; 822 } 823 } 824 description "the role of the physical port "; 825 } 827 typedef fabric-port-type { 828 type enumeration { 829 enum layer2interface { 830 description "l2 if"; 831 } 832 enum layer3interface { 833 description "l3 if"; 834 } 835 enum layer2Tunnel { 836 description "l2 tunnel"; 837 } 838 enum layer3Tunnel { 839 description "l3 tunnel"; 840 } 841 } 842 description 843 "fabric port type"; 844 } 846 typedef underlayer-network-type { 847 type enumeration { 848 enum VXLAN { 849 description "vxlan"; 850 } 851 enum TRILL { 852 description "trill"; 853 } 854 enum VLAN { 855 description "vlan"; 856 } 857 } 858 description ""; 859 } 861 typedef layer2-protocol-type-enum { 862 type enumeration { 863 enum VLAN{ 864 description "vlan"; 865 } 866 enum VXLAN{ 867 description "vxlan"; 869 } 870 enum TRILL{ 871 description "trill"; 872 } 873 enum NvGRE{ 874 description "nvgre"; 875 } 876 } 877 description ""; 878 } 880 typedef access-type { 881 type enumeration { 882 enum exclusive{ 883 description "exclusive"; 884 } 885 enum vlan{ 886 description "vlan"; 887 } 888 } 889 description ""; 890 } 892 grouping fabric-port { 893 description 894 "attributes of a fabric port"; 895 leaf name { 896 type string; 897 description "name of the port"; 898 } 899 leaf role { 900 type fabric-port-role; 901 description "role of the port in a fabric"; 902 } 903 leaf type { 904 type fabric-port-type; 905 description "type of the port"; 906 } 907 leaf device-port { 908 type tp-ref; 909 description "the device port it mapped to"; 910 } 911 choice tunnel-option { 912 description "tunnel options"; 914 case gre { 915 leaf src-ip { 916 type inet:ip-prefix; 917 description "source address"; 918 } 919 leaf dest-ip { 920 type inet:ip-address; 921 description "destination address"; 922 } 923 } 924 } 925 } 927 grouping route-group { 928 description 929 "route attributes"; 930 list route { 931 key "destination-prefix"; 932 description "route list"; 934 leaf description { 935 type string; 936 description "Textual description of the route."; 937 } 938 leaf destination-prefix { 939 type inet:ipv4-prefix; 940 mandatory true; 941 description "IPv4 destination prefix."; 942 } 943 choice next-hop-options { 944 description "choice of next hop options"; 945 case simple-next-hop { 946 leaf next-hop { 947 type inet:ipv4-address; 948 description "IPv4 address of the next hop."; 949 } 950 leaf outgoing-interface { 951 type nt:tp-id; 952 description "Name of the outgoing interface."; 953 } 954 } 955 } 956 } 957 } 959 grouping port-functions { 960 description 961 "port functions"; 963 container port-function { 964 description "port functions"; 966 choice function-type { 967 description "type of functions"; 968 case ip-mapping { 969 list ip-mapping-entry { 970 key "external-ip"; 971 description "list of NAT entry"; 972 leaf external-ip { 973 type inet:ipv4-address; 974 description "external address"; 975 } 976 leaf internal-ip { 977 type inet:ipv4-address; 978 description "internal address"; 979 } 980 } 981 } 982 } 983 } 984 } 985 grouping acl-list { 986 description "acl list"; 987 list fabric-acl { 988 key fabric-acl-name; 989 description "fabric acl list"; 990 leaf fabric-acl-name { 991 type string; 992 description "acl name"; 993 } 994 } 995 } 996 ///groupings for logical element 997 grouping logical-switch { 998 description "grouping attributes for a logical switch."; 1000 leaf lsw-uuid { 1001 type yang:uuid; 1002 description "logical switch id"; 1003 } 1004 leaf name { 1005 type string; 1006 description "logical switch name"; 1007 } 1008 leaf segment-id { 1009 type uint32; 1010 description "segement id"; 1011 } 1012 leaf network { 1013 type inet:ip-prefix; 1014 description "subnet"; 1015 } 1016 leaf external { 1017 type boolean; 1018 description "whether its a lsw to external network"; 1019 } 1020 uses acl-list; 1021 } 1023 grouping logical-router { 1024 description "grouping atttributes for a logical router"; 1025 leaf lr-uuid { 1026 type yang:uuid; 1027 description "logical router id"; 1028 } 1029 leaf name { 1030 type string; 1031 description "logical router name"; 1032 } 1033 leaf vrf-ctx { 1034 type uint32; 1035 description "logical router vrf id"; 1036 } 1038 uses acl-list; 1040 container routes { 1041 description "routes"; 1042 uses route-group; 1043 } 1044 } 1046 grouping logical-port { 1047 description "grouping attributes for logical ports"; 1048 leaf lport-uuid { 1049 type yang:uuid; 1050 description "logical port id"; 1051 } 1052 leaf name { 1053 type string; 1054 description "logical port name"; 1055 } 1056 container port-layer { 1057 description "layer information of the lport"; 1059 container layer-1-info { 1060 description "layer 1 information of the lport"; 1061 leaf location { 1062 type nt:tp-id; 1063 description "L1 tp id"; 1064 } 1065 } 1066 container layer-2-info { 1067 description "layer 2 information of the lport"; 1068 leaf access-type { 1069 type access-type; 1070 description "l2 access type"; 1071 } 1072 leaf access-segment { 1073 type uint32; 1074 description "access segement"; 1075 } 1076 } 1077 container layer-3-info { 1078 description "layer 3 information of the lport"; 1079 leaf ip { 1080 type inet:ip-address; 1081 description "ip address"; 1082 } 1083 leaf network { 1084 type inet:ip-prefix; 1085 description "ip prefix"; 1086 } 1087 leaf mac { 1088 type yang:mac-address; 1089 description "mac address"; 1090 } 1091 leaf forward-enable { 1092 type boolean; 1093 description "whether enable forward"; 1094 } 1095 leaf logical-switch { 1096 type nw:node-id; 1097 description "lsw id"; 1098 } 1099 } 1100 } 1102 uses acl-list; 1103 uses port-functions; 1105 list underlayer-ports { 1106 key port-ref; 1107 description "list of the corresponding underlay ports"; 1108 leaf port-ref { 1109 type instance-identifier; 1110 description "port reference"; 1111 } 1112 } 1113 } 1114 } 1115 1117 file "ietf-fabric-service@2017-03-03.yang" 1118 module ietf-fabric-service { 1120 yang-version 1.1; 1121 namespace "urn:ietf:params:xml:ns:yang:ietf-fabric-service"; 1122 prefix fabric-services; 1124 import ietf-network { prefix nw; } 1125 import ietf-network-topology { prefix nt; } 1126 import ietf-fabric-types { prefix fabrictype; revision-date "2016-10-13"; } 1128 organization 1129 "IETF I2RS (Interface to the Routing System) Working Group"; 1131 contact 1132 "WG Web: 1133 WG List: < mailto:i2rs@ietf.org> 1135 WG Chair: Susan Hares 1136 1138 WG Chair: Russ White 1139 1141 Editor: Yan Zhuang 1142 1144 Editor: Danian Shi 1145 "; 1147 description 1148 "This module contains a collection of YANG definitions for Fabric services. 1149 Copyright (c) 2016 IETF Trust and the persons identified as 1150 authors of the code. All rights reserved. 1152 Redistribution and use in source and binary forms, with or 1153 without modification, is permitted pursuant to, and subject 1154 to the license terms contained in, the Simplified BSD License 1155 set forth in Section 4.c of the IETF Trust's Legal Provisions 1156 Relating to IETF Documents 1157 (http://trustee.ietf.org/license-info). 1158 This version of this YANG module is part of 1159 draft-zhuang-i2rs-yang-fabric-services; 1160 see the RFC itself for full legal notices."; 1162 revision "2017-03-03" { 1163 description 1164 "remove rpc commands"; 1165 reference 1166 "draft-zhuang-i2rs-yang-fabric-service-01"; 1167 } 1168 revision "2016-10-12" { 1169 description 1170 "Initial revision of fabric service."; 1171 reference 1172 "draft-zhuang-i2rs-yang-fabric-service-00"; 1173 } 1175 augment "/nw:networks/nw:network/nw:node" { 1176 description "Augmentation for logic switch nodes provided by fabrices."; 1178 container lsw-attribute { 1180 description "attributes for logical switches"; 1181 uses fabrictype:logical-switch; 1182 } 1183 } 1185 augment "/nw:networks/nw:network/nw:node" { 1186 description "Augmentation for logical router nodes provided by fabric services."; 1188 container lr-attribute { 1190 description "attributes for logical routers"; 1191 uses fabrictype:logical-router; 1192 } 1193 } 1195 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 1196 description "Augmentation for logical port provided by fabric services."; 1198 container lport-attribute { 1200 description "attributes for logical ports"; 1201 uses fabrictype:logical-port; 1202 } 1203 } 1204 } 1205 1207 file "ietf-fabric-endpoint@2016-10-12.yang" 1208 module ietf-fabric-endpoint { 1210 yang-version 1.1; 1211 namespace "urn:ietf:params:xml:ns:yang:ietf-fabric-endpoint"; 1212 prefix fabric-endpoints; 1214 import ietf-inet-types { prefix "inet"; revision-date "2013-07-15"; } 1215 import ietf-yang-types { prefix "yang"; revision-date "2013-07-15"; } 1216 import ietf-network { prefix nw; } 1217 import ietf-network-topology { prefix nt; } 1218 import ietf-fabric-types { prefix fabrictype; revision-date "2016-10-13"; } 1219 import ietf-fabric-topology { prefix fabric; } 1221 organization 1222 "IETF I2RS (Interface to the Routing System) Working Group"; 1224 contact 1225 "WG Web: 1226 WG List: 1228 WG Chair: Susan Hares 1229 1231 WG Chair: Russ White 1232 1234 Editor: Yan Zhuang 1235 1237 Editor: Danian Shi 1238 "; 1240 description 1241 "This module contains a collection of YANG definitions for endpoints in Fabric service. 1243 Copyright (c) 2016 IETF Trust and the persons identified as 1244 authors of the code. All rights reserved. 1246 Redistribution and use in source and binary forms, with or 1247 without modification, is permitted pursuant to, and subject 1248 to the license terms contained in, the Simplified BSD License 1249 set forth in Section 4.c of the IETF Trust's Legal Provisions 1250 Relating to IETF Documents 1251 (http://trustee.ietf.org/license-info). 1252 This version of this YANG module is part of 1253 draft-zhuang-i2rs-yang-dc-fabric-network-topology; 1254 see the RFC itself for full legal notices."; 1256 revision "2016-10-12" { 1257 description 1258 "Initial revision of faas."; 1259 reference 1260 "draft-zhuang-i2rs-yang-fabric-service-00"; 1261 } 1263 grouping device-location { 1264 description "the location for this endponits in the physical network."; 1266 leaf node-ref { 1267 type fabrictype:node-ref; 1268 description "node reference"; 1269 } 1271 leaf tp-ref { 1272 type fabrictype:tp-ref; 1273 description "port reference"; 1274 } 1276 leaf access-type { 1277 type fabrictype:access-type; 1278 default "exclusive"; 1279 description "access type"; 1280 } 1282 leaf access-segment { 1283 type uint32; 1284 default 0; 1285 description "access segement"; 1286 } 1287 } 1289 grouping endpoint-attributes { 1290 description "endpoint attributes"; 1292 leaf endpoint-uuid { 1293 type yang:uuid; 1294 description "endpoint id"; 1295 } 1297 leaf own-fabric { 1298 type fabric:fabric-id; 1299 description "fabric id"; 1301 } 1303 leaf mac-address { 1304 type yang:mac-address; 1305 description "mac addr"; 1306 } 1308 leaf ip-address { 1309 type inet:ip-address; 1310 description "ip addr"; 1311 } 1313 leaf gateway { 1314 type inet:ip-address; 1315 description "gateway ip"; 1316 } 1318 leaf public-ip { 1319 type inet:ip-address; 1320 description "public ip addr"; 1321 } 1323 container location { 1324 description "physical location of the endpoint"; 1325 uses device-location; 1326 } 1328 container logical-location { 1329 description "The location for this endpoint in the logical network."; 1331 leaf node-id { 1332 type nw:node-id; 1333 description "node id"; 1334 } 1336 leaf tp-id { 1337 type nt:tp-id; 1338 description "port id"; 1339 } 1340 } 1341 } 1343 container endpoints { 1344 config false; 1345 description "endpoints registry for faas."; 1347 list endpoint { 1348 key "endpoint-uuid"; 1349 description "endpoint list"; 1351 uses endpoint-attributes; 1352 } 1353 } 1355 /********************RPC***************************************/ 1356 rpc register-endpoint { 1357 description 1358 "Register a new endpoing into the registry."; 1360 input { 1361 leaf fabric-id { 1362 type fabric:fabric-id; 1363 description "fabric id"; 1364 } 1366 uses endpoint-attributes; 1367 } 1368 output { 1369 leaf endpoint-id { 1370 type yang:uuid; 1371 description "endpoint id"; 1372 } 1373 } 1374 } 1376 rpc unregister-endpoint { 1377 description "Unregister an endpoint or endpoints from the registry."; 1378 input { 1379 leaf fabric-id { 1380 type fabric:fabric-id; 1381 description "fabric id"; 1382 } 1384 leaf-list ids { 1385 type yang:uuid; 1386 description "a list of ids"; 1387 } 1388 } 1389 } 1391 rpc locate-endpoint { 1392 description "Set the physical location of the endpoing."; 1393 input { 1394 leaf fabric-id { 1395 type fabric:fabric-id; 1396 description "fabric id"; 1398 } 1400 leaf endpoint-id { 1401 type yang:uuid; 1402 description "endpoint id"; 1403 } 1404 container location { 1405 description "locations"; 1406 uses device-location; 1407 } 1408 } 1409 } 1410 } 1411 1413 file "ietf-fabric-capable-device@2016-09-29.yang" 1414 module ietf-fabric-capable-device { 1415 yang-version 1.1; 1416 namespace "urn:ietf:params:xml:ns:yang:ietf-fabric-capable-device"; 1417 prefix fabric-device; 1419 import ietf-inet-types { prefix "inet"; revision-date "2013-07-15"; } 1420 import ietf-network { prefix "nw"; } 1421 import ietf-network-topology { prefix nt; } 1422 import ietf-yang-types { prefix "yang"; revision-date "2013-07-15"; } 1423 import ietf-fabric-types { prefix fabrictype; revision-date "2016-09-29"; } 1425 organization 1426 "IETF I2RS (Interface to the Routing System) Working Group"; 1428 contact 1429 "WG Web: 1430 WG List: 1432 WG Chair: Susan Hares 1433 1435 WG Chair: Russ White 1436 1438 Editor: Yan Zhuang 1439 1441 Editor: Danian Shi 1442 "; 1444 description 1445 "This module contains a collection of YANG definitions for Fabric."; 1447 revision "2016-09-29" { 1448 description 1449 "Initial revision of faas."; 1450 reference 1451 "draft-zhuang-i2rs-yang-dc-fabric-network-topology-02"; 1452 } 1454 identity fabric-capable-device-context { 1455 description 1456 "identity of fabric capable device"; 1457 } 1459 grouping fabric-capable-device-attribute { 1460 description 1461 "attributes of fabric capable device"; 1463 leaf fabric-id { 1464 type nw:node-id; 1465 description "fabric id"; 1466 } 1467 leaf fabric-ref { 1468 type fabrictype:node-ref; 1469 description "fabric reference"; 1470 } 1471 } 1473 grouping fabric-capable-device-config { 1474 description 1475 "fabric service configuration of fabric capable device"; 1477 list bridge-domain { 1478 key id; 1479 description "list of bridge domains"; 1480 leaf id { 1481 type string; 1482 description "id of the device"; 1483 } 1484 leaf flood { 1485 type boolean; 1486 default false; 1487 description "flood"; 1488 } 1489 leaf arp { 1490 type boolean; 1491 default false; 1492 description "arp"; 1493 } 1494 leaf segment { 1495 type uint32; 1496 description "segment"; 1497 } 1498 } 1500 list bd-port { 1501 key bd-port-id; 1502 description "bridge port list"; 1503 leaf bd-port-id { 1504 type string; 1505 description "bridge port id"; 1506 } 1507 leaf bdid { 1508 type string; 1509 description "bridge id"; 1510 } 1511 leaf ref-tp-id { 1512 type nt:tp-id; 1513 description "reference of termination port id"; 1514 } 1515 leaf access-type { 1516 type fabrictype:access-type; 1517 description "access type"; 1518 } 1519 leaf access-tag { 1520 type uint32; 1521 description "access tag"; 1522 } 1523 uses fabrictype:acl-list; 1524 } 1526 list vrf { 1527 key id; 1528 description "vrf list"; 1529 leaf id { 1530 type string; 1531 description "vrf id"; 1532 } 1533 leaf name { 1534 type string; 1535 description "name"; 1536 } 1537 leaf vrf-ctx { 1538 type int32; 1539 description "context"; 1540 } 1541 } 1542 list bdif { 1543 key id; 1544 description "bridge interface list"; 1545 leaf id { 1546 type string; 1547 description "bridge interface id"; 1548 } 1549 leaf bdid { 1550 type string; 1551 description "bridge id"; 1552 } 1553 leaf vrf { 1554 type int32; 1555 description "vrf"; 1556 } 1557 leaf ip-address { 1558 type inet:ip-address; 1559 description "ip address"; 1560 } 1561 leaf mask { 1562 type int32; 1563 description "mask"; 1564 } 1565 leaf mac-address { 1566 type yang:mac-address; 1567 description "mac address"; 1568 } 1569 uses fabrictype:acl-list; 1570 uses fabrictype:port-functions; 1571 } 1572 } 1574 augment "/nw:networks/nw:network/nw:node" { 1575 description "augmentation for fabric capable device nodes"; 1576 leaf-list supported-fabric { 1577 type identityref { 1578 base fabrictype:fabric-type; 1579 } 1580 description "supported fabric types"; 1581 } 1583 leaf-list capability-supported { 1584 type fabrictype:service-capabilities; 1585 description "service capability list"; 1586 } 1588 container attributes { 1589 config false; 1590 description "attributes of the device"; 1591 uses fabric-capable-device-attribute; 1592 } 1594 container config { 1595 description "configuration of the device"; 1596 uses fabric-capable-device-config; 1597 } 1598 } 1600 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 1601 description 1602 "References a termination point to a tp in a fabric"; 1604 leaf port-role { 1605 type fabrictype:fabric-port-role; 1606 description "role in a fabric"; 1607 } 1608 leaf port-ref { 1609 type fabrictype:tp-ref; 1610 description "port reference in fabric"; 1611 } 1612 } 1614 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 1615 description 1616 "References a termination point to a tp in bridges"; 1617 leaf-list bd-ids { 1618 type instance-identifier; 1619 description "bridge id list"; 1620 } 1621 } 1622 } 1624 1626 7. Security Considerations 1628 None. 1630 8. IANA Considerations 1632 None. 1634 9. References 1636 9.1. Normative References 1638 [I-D.ietf-i2rs-yang-network-topo] 1639 Clemm, A., Medved, J., Varga, R., Bahadur, N., 1640 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 1641 Topologies", draft-ietf-i2rs-yang-network-topo-12 (work in 1642 progress), March 2017. 1644 [I-D.zhuang-i2rs-yang-dc-fabric-network-topology] 1645 Zhuangyan, Z., Shi, D., Gu, R., and H. Ananthakrishnan, "A 1646 YANG Data Model for Fabric Topology in Data Center 1647 Network", draft-zhuang-i2rs-yang-dc-fabric-network- 1648 topology-03 (work in progress), March 2017. 1650 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1651 Requirement Levels", BCP 14, RFC 2119, 1652 DOI 10.17487/RFC2119, March 1997, 1653 . 1655 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1656 Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, 1657 November 1997, . 1659 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1660 the Network Configuration Protocol (NETCONF)", RFC 6020, 1661 DOI 10.17487/RFC6020, October 2010, 1662 . 1664 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1665 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1666 . 1668 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1669 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1670 . 1672 9.2. Informative References 1674 [I-D.ietf-i2rs-usecase-reqs-summary] 1675 Hares, S. and M. Chen, "Summary of I2RS Use Case 1676 Requirements", draft-ietf-i2rs-usecase-reqs-summary-03 1677 (work in progress), November 2016. 1679 Authors' Addresses 1681 Yan Zhuang (editor) 1682 Huawei 1683 101 Software Avenue, Yuhua District 1684 Nanjing, Jiangsu 210012 1685 China 1687 Email: zhuangyan.zhuang@huawei.com 1689 Danian Shi 1690 Huawei 1691 101 Software Avenue, Yuhua District 1692 Nanjing, Jiangsu 210012 1693 China 1695 Email: shidanian@huawei.com 1697 Rong Gu 1698 China Mobile 1699 32 Xuanwumen West Ave, Xicheng District 1700 Beijing, Beijing 100053 1701 China 1703 Email: gurong_cmcc@outlook.com