Internet DRAFT - draft-zhuang-i2rs-dc-fabric-service-model
draft-zhuang-i2rs-dc-fabric-service-model
i2rs Y. Zhuang, Ed.
Internet-Draft D. Shi
Intended status: Informational Huawei
Expires: March 4, 2018 R. Gu
China Mobile
August 31, 2017
YANG Data Model for Fabric Service delivery in Data Center Network
draft-zhuang-i2rs-dc-fabric-service-model-05
Abstract
This document defines a YANG data model that can be used to deliver
fabric service for users within a data center network. This model is
intended to be instantiated by management system. It provides an
abstraction of services for a fabric network to be used by users.
However it is not a configuration model used directly onto network
infrastructures. It should be used combining with such as fabric
topology data model defined in
[I-D.zhuang-i2rs-yang-dc-fabric-network-topology] with specific
fabric topology information to generate required configuration onto
the related network elements to deliver the service.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 4, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Zhuang, et al. Expires March 4, 2018 [Page 1]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Concept and Terminology . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Fabric service framework overview . . . . . . . . . . . . . . 4
3.1. Service element . . . . . . . . . . . . . . . . . . . . . 5
3.2. Functionality of connections . . . . . . . . . . . . . . 6
4. Fabric service model usage . . . . . . . . . . . . . . . . . 7
4.1. Usage architecture . . . . . . . . . . . . . . . . . . . 7
4.2. Multi-Layer interconnection . . . . . . . . . . . . . . . 8
5. Design of the data model . . . . . . . . . . . . . . . . . . 10
5.1. Fabric service module . . . . . . . . . . . . . . . . . . 10
5.2. Endpoint module . . . . . . . . . . . . . . . . . . . . . 12
6. Fabric Service YANG Modules . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
Network service provisioning is currently coupled with specific
network topology and technology applied, which is technology and
device oriented.
In the area of data center, this approach makes the management
complex due to massive network devices involved and various
applications deployed by multiple users (also known as tenants).
In the traditional way, the administrator has to be aware of the
entire data center network before delivering services for users.
When service request comes up, administrator has to divide the
request into appropriate configurations and operations for all
involved devices manually. Finally, these configurations are
deployed onto network infrastructure, which requires personnel
skills.
Zhuang, et al. Expires March 4, 2018 [Page 2]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
Actually different users share the same network infrastructure. A
more dynamical way to deploy and manage the network is eager to be
found out. Here we decompose the network management system into
several layers in order to have network service provision more
flexible and automatic. Each network layer is dedicated to be
managed. What is more, all the layers can be combined to fulfill the
delivery of the user's service.
We can use three layers in data center network. The bottom one is
physical infrastructure with massive devices. The middle one is
fabric topology defined in [I-D.zhuang-i2rs-yang-dc-fabric-network-
topology]. Unlike the physical layer, the fabric layer is used to
display a fabric-based network view. In the fabric layer, a set of
fabrics can exist with each managed independently. Furthermore, a
bottom-up abstraction of fabric service is proposed to provide
application centric interfaces facing to users which define network
services regardless of beneath fabric topology and physical
connections in the up layer.
This document defines a YANG [RFC6020] [RFC7950] data model focusing
on the fabric service interfaces to define user fabric network
services regardless of specific beneath network topology and devices.
This model defines the generic configuration for fabric services
within DC networks.
For example, this model can be used by the network orchestrator in
which the fabric service interfaces are exposed. When a service from
user application is requested, orchestrator adopts this model
including service information and processes it into the topology
layer through a DC controller. Thus a service is automatically and
dynamically provided.
The service data model includes two main modules:
(a)Module "ietf-fabric-service" defines a module for user network
service over fabric networks from the application centric view. To
do so, it augments general network topology model defined in [I-
D.ietf-i2rs-yang-network-topo] with logical components such as
logical switches, logical routers as well as logical ports to carry
network services requested by user applications.
(b)Module "ietf-fabric-endpoint" defines a module for hosts that run
applications and generate traffics. The major usage of this module
is to indicate the attachment points of a host in a user service
network as well as in a physical network when it is initialed, so as
to build bindings between physical layer and topology layer
dynamically.
Zhuang, et al. Expires March 4, 2018 [Page 3]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
Besides, the model "ietf-fabric-topology" defined in [I-D.zhuang-
i2rs-yang-dc-fabric-network-topology] with topology and resource as
well as technology information is used to work together to implement
configurations and operations of the fabric service onto the specific
fabric infrastructure.
2. Concept and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.1. Terminology
Fabric topology: a data center network can be decomposed to a set of
fabric networks, while each of these fabrics composes a set of
physical nodes/links of the physical infrastructure to form a fabric
network. The fabric topology includes attributes of fabrics, such as
gateway mode, involved nodes, roles of involved nodes etc al.
Fabric Service: it is used as a service interface of fabric networks
to users, which uses logical elements to represent network
connections between hosts for applications, regardless of a specific
fabric topology deployment. Each service instance is based on a
fabric topology, while a fabric can provide multiple service
instances for different users, each of which is isolated to others.
Endpoint: an endpoint represents a host, which can be a virtual
machine on a server or a bare-metal server.
Fabric capable device: a physical device (e.g. a switch) that
supports fabric service and fabric topology models.
3. Fabric service framework overview
This draft provides a network service interface on top of fabrics
network layer. Users can use these network service interfaces to
deploy their applications over a data center network automatically
and dynamically.
From the application centric point of view, user hosts can be
considered to connect with other hosts through a switch if they are
L2 reachable, alternatively, connect through a router if they are L3
reachable simply. So a user network can be abstracted into a logical
network where L2 reachable represents logical switches connecting
hosts and L3 reachable represents logical routers connecting
switches.
Zhuang, et al. Expires March 4, 2018 [Page 4]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
With this concept, a user can use appropriate logical elements to
define their networks and configure attributes of these elements such
as vlan id, gateway etc al. All of these form a network service.
For example, a fabric service diagram for a user is shown as below.
|C3 - L3 Interconnect
|
|logical port- external gateway
+-----------|------------+
| |
| Logical Router |
| |
+---|--------------|-----+
| |logical port-gateway port
| |C2
| |
| |
+-----------|----+ +-|--------------+
| | | | Logical port-Access port
| Logical Switch | | Logical Switch ------
| | | | C4 - L2 Interconnect
+-|---------|----+ +-|---------|----+
| | |C1 |
| | | |
+-----|---+ +--|------+ +----|----+ +-|-------+
| Endpoint| | Endpoint| | Endpoint| | Endpoint|
+---------+ +---------+ +---------+ +---------+
Figure 1: Diagram of a fabric service
In the diagram, abstraction of network connections is focused as a
very initial effort to abstract services for fabric-based DC
networks. Based on the connection, we can add other network
appliance for which the fabric service should be extended.
3.1. Service element
There are four major components regarding as service elements within
a fabric service as depicted in Figure 1.
Logical Switch:
Works as a switch within a logical fabric network to provide L2
connections between hosts or to a logical router or to external
networks. It can be bounded to one or several physical switches.
Logical Router:
Zhuang, et al. Expires March 4, 2018 [Page 5]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
Works as a router to provide L3 connections between logical switches
or to external networks.
Logical Port:
Provides port function on logical switches and logical routers which
claims their connections to others.
Endpoint:
Represents user hosts which can be a VM or a bare-metal server.
3.2. Functionality of connections
There are 4 connections between elements within the fabric service
framework listed as follows:
C1: Endpoint attachment. It is used by an endpoint to connect to a
logical switch.
C2: L2 to L3 attachment. Interface between a logical switch and a
logical router within the same fabric.
C3: L3 interconnection which connects to a logical router.
C4: L2 interconnection which connects to a logical switch in another
fabric.
Thinking of the functionality of different connections, a logical
port can act as an access port (which provides C1/C4/C3 connection to
a network element), or a service port (which provide C2 gateway
connection) as shown in Figure 2.
Zhuang, et al. Expires March 4, 2018 [Page 6]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
+---------------+
| Logical Port |
+--+----------+-+
| |
| |
| |
| |
+--------------+-+ ``````````````````
| Access Port | ` Service Port `
+----------------+ ```|```````````|``
| |
| |
| |
| |
+------------+--+ +--+------------+
| Gateway Port | | External GW |
+---------------+ +---------------+
Figure 2: Types of Logical port
When a logical port is noticed as an access port, there will be a
corresponding physical port. In this situation, the required access
configuration can be deployed on this physical port directly.
However, there will be a gateway service if a logical port is noticed
as a service port. In this situation, the management system should
combine the gateway function and fabric territory at fabric topology
layer together with the gateway configuration on the service port.
By the combination, it is easy to figure out the appropriate devices
in the physical infrastructure and their configurations for these
devices respectively.
4. Fabric service model usage
4.1. Usage architecture
In section 3, a fabric service interface is provided for users to
define their networks in a more concentrated and intuitive way. To
be detailed, when a fabric service comes, the topology manager will
parse services into configuration/operations onto specific devices
automatically. In this process, service interface information and
fabric topology information defined in [I-D.zhuang-i2rs-yang-dc-
fabric-network-topology] is needed.
The whole process is shown in Fig.3. Fabric service module is used
define network services for applications maybe by an orchestration
for example, according to the topology architecture stated in [I-
D.draft-ietf-i2rs-usecase-reqs-summary]. The topology information
maintenance should be done by a topology manager. By combining
Zhuang, et al. Expires March 4, 2018 [Page 7]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
information from different layers, a topology manager automatically
generates configurations and operations of related devices and
deploys them respectively over the physical fabric infrastructures.
+-------------------+
| |
| Orchestrator |
| |
+---------|---------+
|
| Fabric service
|
|
+---------V---------+
| |
| Topology Manager | Network Provider
| |
+--------^----------+
|
|
|Fabric Topology information
|
...........................|.............................
|
+----------------+
+----------------+|
+----------------+||
| ||| Network
| Device ||+
| |+
+----------------+
Figure 3: Fabric service Usage architecture
4.2. Multi-Layer interconnection
There are three layers in this usage.
At the service layer, a fabric service model is abstracted from
fabric network used as an application-centric interface to define
user networks. It focuses on the connection services from users'
perspective. Using the fabric service interface, an administrator
can define a logical network for each user over a single fabric
network while each logical networks can be managed separately.
For the fabric topology layer, it collects and maintains the fabric
topology information (including territory of the physical fabric,
Zhuang, et al. Expires March 4, 2018 [Page 8]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
connections, gateway functions, roles of devices within the fabric
and specific technologies for each fabric) upon the physical network
layer.
With information provided by both fabric service as well as fabric
topology, a fabric topology manager will calculates and generates
configuration and operation for involved network devices in the
physical layer so as to distribute and deploy them onto network
infrastructure. The implementation of device configuration can be
done in several ways, such as using defined data models for specific
attributes, command lines. We will not limite any implemenation
here.
The diagram of the management architecture and its relationship is
depicted as below.
+----------+
| |
| LR-1 |................
| |
+--/---\---+
gateway: / \ gateway:
10.0.35.1 / \ 10.0.36.1````` Fabric Service Layer
/ \ `
+---------+ +---------+ `
| | | | `
+---| LSW-11 | | LSW-12 | `
| +-----|---+ +---------+ `
| | | `
| | | ` +--------+
| | | ` | |
| | | ` |Fabric-3|
| | | ` | |
| | | ` +-/ ---\-+
| | | ` / \
| | | ` / \
| | | ` +------ /+ +\ ------+
| | | ` | | | |
| | | ` |Fabric-1|--------|Fabric-2|
| | | ` | | | |
| | | ` +--------+ +--------+
| | | `````gateway/roles
| +-----------------------+ of nodes
| | | ` Fabric Topology Layer
| Fabric-1 | | `
| +-------+ | | `
| +--------+|``````````````````````
Zhuang, et al. Expires March 4, 2018 [Page 9]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
| +--------+|| | |
| | ||+ | |
| | SPINE |+ | |
| +--------+ | |
| |||| | |
| |||-------+ | |
| +|||------+| | | Physcial Layer
| +-||------+|| | |
| +--|------+||+ | |
| +---------+||+ | |
| | LEAF ||+\ | |
| | device |+ \ | |
| +---------+ \| |
| / \ \ |
| / \ |\ |
| / \ | \ |
| +/-+ +-\+ | \ +-|+
+--------| | | |---+ \| |
+--+ +--+ +--+
H1:10.0.35.2 H2:10.0.36.2 H3:10.0.35.3
Figure 4: Multi-layer interconnection
The mapping of nodes with access logical ports is realized by
endpoints e.g. H1,H2 and H3 in Fig.4. An endpoint is instantiated
by the orchestrator to indicate the locations of a host both in the
logical layer as well as in the physical layer, so as to deliver
services requested from the logical port onto the physical port in a
dynamic manner. For H1 and H3, they are considered to connect to the
same switch for user in the logical layer, even they attach to the
different devices.
Besides, gateway configuration is defined at service layer while the
gateway mode and gateway devices (for distributed gateway, the
gateway should be deployed on LEAF devices, while for centralized
gateway, the configuration should be on SPINE) are defined in fabric
topology layer. By combing the gateway information from both layers,
the system can automatically figure out the involved devices and
generate appropriate configurations onto them.
5. Design of the data model
5.1. Fabric service module
As explained previously, network service for user network can be
abstracted to sets of logical switches, logical routers and logical
Zhuang, et al. Expires March 4, 2018 [Page 10]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
ports. Upon these logical elements, acl policies and gateway
functions can be attached.
The fabric service module is defined by YANG module "ietf-fabric-
service". The module is depicted in the following diagram.
module: ietf-fabric-service
augment /nw:networks/nw:network/nw:node:
+--rw lsw-attribute
+--rw lsw-uuid? yang:uuid
+--rw name? string
+--rw segment-id? uint32
+--rw network? inet:ip-prefix
+--rw external? boolean
+--rw fabric-acl* [fabric-acl-name]
+--rw fabric-acl-name string
augment /nw:networks/nw:network/nw:node:
+--rw lr-attribute
+--rw lr-uuid? yang:uuid
+--rw name? string
+--rw vrf-ctx? uint32
+--rw fabric-acl* [fabric-acl-name]
| +--rw fabric-acl-name string
+--rw routes
+--rw route* [destination-prefix]
+--rw description? string
+--rw destination-prefix inet:ipv4-prefix
+--rw (next-hop-options)?
+--:(simple-next-hop)
+--rw next-hop? inet:ipv4-address
+--rw outgoing-interface? nt:tp-id
augment /nw:networks/nw:network/nw:node/nt:termination-point:
+--rw lport-attribute
+--rw lport-uuid? yang:uuid
+--rw name? string
+--rw port-layer
| +--rw layer-1-info
| | +--rw location? nt:tp-id
| +--rw layer-2-info
| | +--rw access-type? access-type
| | +--rw access-segment? uint32
| +--rw layer-3-info
| +--rw ip? inet:ip-address
| +--rw network? inet:ip-prefix
| +--rw mac? yang:mac-address
| +--rw forward-enable? boolean
| +--rw logical-switch? nw:node-id
+--rw fabric-acl* [fabric-acl-name]
Zhuang, et al. Expires March 4, 2018 [Page 11]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
| +--rw fabric-acl-name string
+--rw port-function
| +--rw (function-type)?
| +--:(ip-mapping)
| +--rw ip-mapping-entry* [external-ip]
| +--rw external-ip inet:ipv4-address
| +--rw internal-ip? inet:ipv4-address
+--rw underlayer-ports* [port-ref]
+--rw port-ref instance-identifier
Figure 5: Fabric Service Module
To provide a logical network topology for DC fabric network, the
module augments the original ietf-network and ietf-network-topology
modules:
o New nodes for logical switch and logical router with additional
data objects are introduced by augmenting the "node" list of the
network module.
o Termination points for logical ports are augmented with logical
port information and its reference to termination ports in the
underlay topologies. As stated in section 3, the logical port may
act as an access port which will be bounded to some physical port,
or else it may be as a service point which connects to internal
gateway or external gateway. Besides, it can also be attached
with ACL rules.
5.2. Endpoint module
To represent user attachments points and map logical fabric
configurations and operations of applications onto the physical
fabric infrastructure, an endpoint is instantiated to represent a
host of a user that runs applications.
The fabric endpoint module is defined by YANG module "ietf-fabric-
endpoint". The module is depicted as follows:
Zhuang, et al. Expires March 4, 2018 [Page 12]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
module: ietf-fabric-endpoint
+--rw endpoints
+--rw endpoint* [endpoint-uuid]
+--rw endpoint-uuid yang:uuid
+--rw own-fabric? fabric:fabric-id
+--rw mac-address? yang:mac-address
+--rw ip-address? inet:ip-address
+--rw gateway? inet:ip-address
+--rw public-ip? inet:ip-address
+--rw location
| +--rw node-ref? fabrictype:node-ref
| +--rw tp-ref? fabrictype:tp-ref
| +--rw access-type? fabrictype:access-type
| +--rw access-segment? uint32
+--rw logical-location
+--rw node-id? nw:node-id
+--rw tp-id? nt:tp-id
Figure 6: Fabric endpoint module
By indicating locations of an endpoint in "location" container, the
logical network elements such as logical nodes and logical
termination points are bounded to the network elements in a specific
fabric. Then the network configurations and operations from the
logical network together with its belonged fabric topology
information will further be distributed onto the bounding/related
physical elements by the network topology manager.
Besides, the module defines three rpc commands to register,
unregister and locate the endpoint onto both logical network and
physical network shown as follows.
Zhuang, et al. Expires March 4, 2018 [Page 13]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
rpcs:
+---x register-endpoint
| +---w input
| | +---w fabric-id? fabric:fabric-id
| | +---w endpoint-uuid? yang:uuid
| | +---w own-fabric? fabric:fabric-id
| | +---w mac-address? yang:mac-address
| | +---w ip-address? inet:ip-address
| | +---w gateway? inet:ip-address
| | +---w public-ip? inet:ip-address
| | +---w location
| | | +---w node-ref? fabrictype:node-ref
| | | +---w tp-ref? fabrictype:tp-ref
| | | +---w access-type? fabrictype:access-type
| | | +---w access-segment? uint32
| | +---w logical-location
| | +---w node-id? nw:node-id
| | +---w tp-id? nt:tp-id
| +--ro output
| +--ro endpoint-id? yang:uuid
+---x unregister-endpoint
| +---w input
| +---w fabric-id? fabric:fabric-id
| +---w ids* yang:uuid
+---x locate-endpoint
+---w input
+---w fabric-id? fabric:fabric-id
+---w endpoint-id? yang:uuid
+---w location
+---w node-ref? fabrictype:node-ref
+---w tp-ref? fabrictype:tp-ref
+---w access-type? fabrictype:access-type
+---w access-segment? uint32
Figure 7: Fabric endpoint module RPC
6. Fabric Service YANG Modules
<CODE BEGINS> file "ietf-fabric-service-types@2017-08-30.yang"
module ietf-fabric-service-types {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-fabric-service-types";
prefix fst;
import ietf-inet-types { prefix "inet"; revision-date "2013-07-15"; }
Zhuang, et al. Expires March 4, 2018 [Page 14]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
import ietf-network-topology { prefix nt; }
import ietf-network { prefix nw; }
import ietf-fabric-types { prefix ft; revision-date "2016-09-29"; }
import ietf-yang-types { prefix "yang"; revision-date "2013-07-15";}
organization
"IETF I2RS (Interface to the Routing System) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/i2rs/ >
WG List: <mailto:i2rs@ietf.org>
WG Chair: Susan Hares
<mailto:shares@ndzh.com>
WG Chair: Russ White
<mailto:russ@riw.us>
Editor: Yan Zhuang
<mailto:zhuangyan.zhuang@huawei.com>
Editor: Danian Shi
<mailto:shidanian@huawei.com>";
description
"This module contains a collection of YANG definitions for Fabric.";
revision "2017-08-30" {
description
"Initial revision of service types for fabric.";
reference
"draft-zhuang-i2rs-dc-fabric-service-model-04";
}
///groupings for logical element
grouping logical-switch {
description "grouping attributes for a logical switch.";
leaf lsw-uuid {
type yang:uuid;
description "logical switch id";
}
leaf name {
type string;
description "logical switch name";
Zhuang, et al. Expires March 4, 2018 [Page 15]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
}
leaf segment-id {
type uint32;
description "segement id";
}
leaf network {
type inet:ip-prefix;
description "subnet";
}
leaf external {
type boolean;
description "whether its a lsw to external network";
}
uses ft:acl-list;
}
grouping logical-router {
description "grouping atttributes for a logical router";
leaf lr-uuid {
type yang:uuid;
description "logical router id";
}
leaf name {
type string;
description "logical router name";
}
leaf vrf-ctx {
type uint32;
description "logical router vrf id";
}
uses ft:acl-list;
container routes {
description "routes";
uses ft:route-group;
}
}
grouping logical-port {
description "grouping attributes for logical ports";
leaf lport-uuid {
type yang:uuid;
description "logical port id";
}
leaf name {
type string;
description "logical port name";
Zhuang, et al. Expires March 4, 2018 [Page 16]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
}
container port-layer {
description "layer information of the lport";
container layer-1-info {
description "layer 1 information of the lport";
leaf location {
type nt:tp-id;
description "L1 tp id";
}
}
container layer-2-info {
description "layer 2 information of the lport";
leaf access-type {
type ft:access-type;
description "l2 access type";
}
leaf access-segment {
type uint32;
description "access segement";
}
}
container layer-3-info {
description "layer 3 information of the lport";
leaf ip {
type inet:ip-address;
description "ip address";
}
leaf network {
type inet:ip-prefix;
description "ip prefix";
}
leaf mac {
type yang:mac-address;
description "mac address";
}
leaf forward-enable {
type boolean;
description "whether enable forward";
}
leaf logical-switch {
type nw:node-id;
description "lsw id";
}
}
}
uses ft:acl-list;
Zhuang, et al. Expires March 4, 2018 [Page 17]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
uses ft:port-functions;
list underlayer-ports {
key port-ref;
description "list of the corresponding underlay ports";
leaf port-ref {
type instance-identifier;
description "port reference";
}
}
}
}
<CODE ENDS>
<CODE BEGINS> file "ietf-fabric-service@2017-08-30.yang"
module ietf-fabric-service {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-fabric-service";
prefix fabric-services;
import ietf-network { prefix nw; }
import ietf-network-topology { prefix nt; }
import ietf-fabric-service-types {prefix fst;}
organization
"IETF I2RS (Interface to the Routing System) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/i2rs/ >
WG List: < mailto:i2rs@ietf.org>
WG Chair: Susan Hares
<mailto:shares@ndzh.com>
WG Chair: Russ White
<mailto:russ@riw.us>
Editor: Yan Zhuang
<mailto:zhuangyan.zhuang@huawei.com>
Editor: Danian Shi
<mailto:shidanian@huawei.com >";
description
"This module contains a collection of YANG definitions for Fabric services.
Copyright (c) 2016 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Zhuang, et al. Expires March 4, 2018 [Page 18]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of
draft-zhuang-i2rs-yang-fabric-services;
see the RFC itself for full legal notices.";
revision "2017-08-30" {
description
"refer to fabric-service-type module instead of fabric-type.";
reference
"draft-zhuang-i2rs-yang-fabric-service-04";
}
revision "2017-03-03" {
description
"remove rpc commands";
reference
"draft-zhuang-i2rs-yang-fabric-service-01";
}
revision "2016-10-12" {
description
"Initial revision of fabric service.";
reference
"draft-zhuang-i2rs-yang-fabric-service-00";
}
augment "/nw:networks/nw:network/nw:node" {
description "Augmentation for logic switch nodes provided by fabrices.";
container lsw-attribute {
description
"attributes for logical switches";
uses fst:logical-switch;
}
}
augment "/nw:networks/nw:network/nw:node" {
description "Augmentation for logical router nodes provided by fabric services.";
container lr-attribute {
description "attributes for logical routers";
Zhuang, et al. Expires March 4, 2018 [Page 19]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
uses fst:logical-router;
}
}
augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
description "Augmentation for logical port provided by fabric services.";
container lport-attribute {
description "attributes for logical ports";
uses fst:logical-port;
}
}
}
<CODE ENDS>
<CODE BEGINS> file "ietf-fabric-endpoint@2017-06-29.yang"
module ietf-fabric-endpoint {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-fabric-endpoint";
prefix fabric-endpoints;
import ietf-inet-types { prefix "inet"; revision-date "2013-07-15"; }
import ietf-yang-types { prefix "yang"; revision-date "2013-07-15"; }
import ietf-network { prefix nw; }
import ietf-network-topology { prefix nt; }
import ietf-fabric-types { prefix fabrictype;}
import ietf-fabric-topology { prefix fabric; }
organization
"IETF I2RS (Interface to the Routing System) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/i2rs/ >
WG List: <mailto:i2rs@ietf.org>
WG Chair: Susan Hares
<mailto:shares@ndzh.com>
WG Chair: Russ White
<mailto:russ@riw.us>
Editor: Yan Zhuang
<mailto:zhuangyan.zhuang@huawei.com>
Editor: Danian Shi
Zhuang, et al. Expires March 4, 2018 [Page 20]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
<mailto:shidanian@huawei.com>";
description
"This module contains a collection of YANG definitions for endpoints in Fabric service.
Copyright (c) 2016 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of
draft-zhuang-i2rs-yang-dc-fabric-network-topology;
see the RFC itself for full legal notices.";
revision "2017-06-29" {
description
"compliant with NMDA";
reference
"draft-zhuang-i2rs-yang-fabric-service-03";
}
revision "2016-10-12" {
description
"Initial revision of faas.";
reference
"draft-zhuang-i2rs-yang-fabric-service-00";
}
grouping device-location {
description "the location for this endponits in the physical network.";
leaf node-ref {
type fabrictype:node-ref;
description "node reference";
}
leaf tp-ref {
type fabrictype:tp-ref;
description "port reference";
}
leaf access-type {
Zhuang, et al. Expires March 4, 2018 [Page 21]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
type fabrictype:access-type;
default "exclusive";
description "access type";
}
leaf access-segment {
type uint32;
default 0;
description "access segement";
}
}
grouping endpoint-attributes {
description "endpoint attributes";
leaf endpoint-uuid {
type yang:uuid;
description "endpoint id";
}
leaf own-fabric {
type fabric:fabric-id;
description "fabric id";
}
leaf mac-address {
type yang:mac-address;
description "mac addr";
}
leaf ip-address {
type inet:ip-address;
description "ip addr";
}
leaf gateway {
type inet:ip-address;
description "gateway ip";
}
leaf public-ip {
type inet:ip-address;
description "public ip addr";
}
container location {
description "physical location of the endpoint";
uses device-location;
Zhuang, et al. Expires March 4, 2018 [Page 22]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
}
container logical-location {
description "The location for this endpoint in the logical network.";
leaf node-id {
type nw:node-id;
description "node id";
}
leaf tp-id {
type nt:tp-id;
description "port id";
}
}
}
container endpoints {
description "endpoints registry for faas.";
list endpoint {
key "endpoint-uuid";
description "endpoint list";
uses endpoint-attributes;
}
}
/********************RPC***************************************/
rpc register-endpoint {
description
"Register a new endpoing into the registry.";
input {
leaf fabric-id {
type fabric:fabric-id;
description "fabric id";
}
uses endpoint-attributes;
}
output {
leaf endpoint-id {
type yang:uuid;
description "endpoint id";
}
}
}
Zhuang, et al. Expires March 4, 2018 [Page 23]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
rpc unregister-endpoint {
description "Unregister an endpoint or endpoints from the registry.";
input {
leaf fabric-id {
type fabric:fabric-id;
description "fabric id";
}
leaf-list ids {
type yang:uuid;
description "a list of ids";
}
}
}
rpc locate-endpoint {
description "Set the physical location of the endpoing.";
input {
leaf fabric-id {
type fabric:fabric-id;
description "fabric id";
}
leaf endpoint-id {
type yang:uuid;
description "endpoint id";
}
container location {
description "locations";
uses device-location;
}
}
}
}
<CODE ENDS>
7. Security Considerations
None.
8. IANA Considerations
None.
Zhuang, et al. Expires March 4, 2018 [Page 24]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
9. References
9.1. Normative References
[I-D.ietf-i2rs-yang-network-topo]
Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A Data Model for Network
Topologies", draft-ietf-i2rs-yang-network-topo-14 (work in
progress), June 2017.
[I-D.zhuang-i2rs-yang-dc-fabric-network-topology]
Zhuangyan, Z., Shi, D., Gu, R., and H. Ananthakrishnan, "A
YANG Data Model for Fabric Topology in Data Center
Network", draft-zhuang-i2rs-yang-dc-fabric-network-
topology-04 (work in progress), July 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234,
November 1997, <https://www.rfc-editor.org/info/rfc2234>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, <https://www.rfc-
editor.org/info/rfc6020>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
9.2. Informative References
[I-D.ietf-i2rs-usecase-reqs-summary]
Hares, S. and M. Chen, "Summary of I2RS Use Case
Requirements", draft-ietf-i2rs-usecase-reqs-summary-03
(work in progress), November 2016.
Zhuang, et al. Expires March 4, 2018 [Page 25]
Internet-Draft YANG for Fabric Service delivery in DC August 2017
Authors' Addresses
Yan Zhuang (editor)
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: zhuangyan.zhuang@huawei.com
Danian Shi
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: shidanian@huawei.com
Rong Gu
China Mobile
32 Xuanwumen West Ave, Xicheng District
Beijing, Beijing 100053
China
Email: gurong_cmcc@outlook.com
Zhuang, et al. Expires March 4, 2018 [Page 26]
