rfc8944.original   rfc8944.txt 
Network Working Group J. Dong Internet Engineering Task Force (IETF) J. Dong
Internet-Draft X. Wei Request for Comments: 8944 X. Wei
Intended status: Standards Track Q. Wu Category: Standards Track Q. Wu
Expires: March 14, 2021 Huawei ISSN: 2070-1721 Huawei
M. Boucadair M. Boucadair
Orange Orange
A. Liu A. Liu
Tecent Tecent
September 10, 2020 November 2020
A YANG Data Model for Layer 2 Network Topologies A YANG Data Model for Layer 2 Network Topologies
draft-ietf-i2rs-yang-l2-network-topology-18
Abstract Abstract
This document defines a YANG data model for Layer 2 network This document defines a YANG data model for Layer 2 network
topologies. In particular, this data model augments the generic topologies. In particular, this data model augments the generic
network and network topology data models with Layer 2 specific network and network topology data models with topology attributes
topology attributes. that are specific to Layer 2.
Editorial Note (To be removed by RFC Editor)
Please update these statements within the document with the RFC
number to be assigned to this document:
o "This version of this YANG module is part of RFC XXXX;"
o "RFC XXXX: A YANG Data Model for Layer 2 Network Topologies";
o reference: RFC XXXX
Please update the "revision" date of the YANG module.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc8944.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Layer 2 Topology Model . . . . . . . . . . . . . . . . . . . 3 3. Layer 2 Topology Model
4. Layer 2 Topology YANG Module . . . . . . . . . . . . . . . . 7 4. Layer 2 Topology YANG Module
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 21 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Companion YANG Module for Non-NMDA-Compliant
Appendix A. Companion YANG Module for Non-NMDA Compliant Implementations
Implementations . . . . . . . . . . . . . . . . . . 24 Appendix B. An Example
Appendix B. An Example . . . . . . . . . . . . . . . . . . . . . 28 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses
1. Introduction 1. Introduction
[RFC8345] defines the YANG [RFC6020] [RFC7950] data models of the [RFC8345] defines the YANG [RFC6020] [RFC7950] data models of the
abstract (generic) network and network topology. Such models can be abstract (generic) network and network topology. Such models can be
augmented with technology-specific details to build more specific augmented with technology-specific details to build more specific
topology models. topology models.
This document defines the YANG data model for Layer 2 (L2) network This document defines the YANG data model for Layer 2 (L2) network
topologies by augmenting the generic network (Section 6.1 of topologies by augmenting the generic network (Section 6.1 of
skipping to change at page 3, line 28 skipping to change at line 103
model can be applied are described in [I2RS-UR]. model can be applied are described in [I2RS-UR].
This document uses the common YANG types defined in [RFC6991] and This document uses the common YANG types defined in [RFC6991] and
adopts the Network Management Datastore Architecture (NMDA) adopts the Network Management Datastore Architecture (NMDA)
[RFC8342]. [RFC8342].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The terminology for describing YANG modules is defined in [RFC7950]. The terminology for describing YANG modules is defined in [RFC7950].
The meanings of the symbols used in the tree diagram are defined in The meanings of the symbols used in the tree diagram are defined in
[RFC8340]. [RFC8340].
3. Layer 2 Topology Model 3. Layer 2 Topology Model
The Layer 2 network topology YANG module is designed to be generic The Layer 2 network topology YANG module is designed to be generic
and applicable to Layer 2 networks built with different Layer 2 and applicable to Layer 2 networks built with different Layer 2
technologies. It can be used to describe both the physical and the technologies. It can be used to describe both the physical and the
logical (virtual) Layer 2 network topologies. logical (virtual) Layer 2 network topologies.
The relationship between the Layer 2 topology module and the generic The relationship between the Layer 2 topology module and the generic
network and network topology module is shown in Figure 1. In order network and network topology module is shown in Figure 1. In order
to represent a Layer 2 network topology, the generic network and to represent a Layer 2 network topology, the generic network and
topology models are augmented with Layer 2 specific information, such topology models are augmented with L2-specific information, such as
as the identifiers, identities (e.g., Provider Backbone Bridging the identifiers, identities (e.g., Provider Backbone Bridging
[IEEE802.1ah], QinQ [IEEE802.1ad], or VXLAN [RFC7348]), attributes, [IEEE802.1ah], QinQ [IEEE802.1ad], or Virtual eXtensible Local Area
and states of the Layer 2 networks, nodes, links, and termination Network (VXLAN) [RFC7348]), attributes, and states of the Layer 2
points. Some of the information may be collected via Link Layer networks, nodes, links, and termination points. Some of the
Discovery Protocol (LLDP) [IEEE802.1AB] or other Layer 2 protocols, information may be collected via Link Layer Discovery Protocol (LLDP)
and some of them may be locally configured. [IEEE802.1AB] or other Layer 2 protocols, and some of them may be
locally configured.
+---------------------+ +---------------------+
| ietf-network | | ietf-network |
+----------^----------+ +----------^----------+
| |
| |
+---------------------+ +---------------------+
|ietf-network-topology| |ietf-network-topology|
+----------^----------+ +----------^----------+
| |
| |
+----------^----------+ +----------^----------+
| ietf-l2-topology | | ietf-l2-topology |
+---------------------+ +---------------------+
Figure 1: Layer 2 Topology YANG Module Structure Figure 1: Layer 2 Topology YANG Module Structure
The structure of the "ietf-l2-topology" YANG module is depicted in The structure of the "ietf-l2-topology" YANG module is depicted in
the following tree diagram: the following tree diagram:
module: ietf-l2-topology module: ietf-l2-topology
augment /nw:networks/nw:network/nw:network-types: augment /nw:networks/nw:network/nw:network-types:
+--rw l2-topology! +--rw l2-topology!
augment /nw:networks/nw:network: augment /nw:networks/nw:network:
+--rw l2-topology-attributes +--rw l2-topology-attributes
+--rw name? string +--rw name? string
+--rw flags* l2-flag-type +--rw flags* l2-flag-type
augment /nw:networks/nw:network/nw:node: augment /nw:networks/nw:network/nw:node:
+--rw l2-node-attributes +--rw l2-node-attributes
+--rw name? string +--rw name? string
+--rw flags* node-flag-type +--rw flags* node-flag-type
+--rw bridge-id* string +--rw bridge-id* string
+--rw management-address* inet:ip-address +--rw management-address* inet:ip-address
+--rw management-mac? yang:mac-address +--rw management-mac? yang:mac-address
+--rw management-vlan? string +--rw management-vlan? string
augment /nw:networks/nw:network/nt:link: augment /nw:networks/nw:network/nt:link:
+--rw l2-link-attributes +--rw l2-link-attributes
+--rw name? string +--rw name? string
+--rw flags* link-flag-type +--rw flags* link-flag-type
+--rw rate? uint64 +--rw rate? uint64
+--rw delay? uint32 +--rw delay? uint32
+--rw auto-nego? boolean +--rw auto-nego? boolean
+--rw duplex? duplex-mode +--rw duplex? duplex-mode
augment /nw:networks/nw:network/nw:node/nt:termination-point: augment /nw:networks/nw:network/nw:node/nt:termination-point:
+--rw l2-termination-point-attributes +--rw l2-termination-point-attributes
+--rw interface-name? string +--rw interface-name? string
+--rw mac-address? yang:mac-address +--rw mac-address? yang:mac-address
+--rw port-number* uint32 +--rw port-number* uint32
+--rw unnumbered-id* uint32 +--rw unnumbered-id* uint32
+--rw encapsulation-type? identityref +--rw encapsulation-type? identityref
+--rw outer-tag? dot1q-types:vid-range-type {VLAN}? +--rw outer-tag? dot1q-types:vid-range-type {VLAN}?
+--rw outer-tpid? dot1q-types:dot1q-tag-type {QinQ}? +--rw outer-tpid? dot1q-types:dot1q-tag-type {QinQ}?
+--rw inner-tag? dot1q-types:vid-range-type {VLAN}? +--rw inner-tag? dot1q-types:vid-range-type {VLAN}?
+--rw inner-tpid? dot1q-types:dot1q-tag-type {QinQ}? +--rw inner-tpid? dot1q-types:dot1q-tag-type {QinQ}?
+--rw lag? boolean +--rw lag? boolean
+--rw member-link-tp* -> /nw:networks/network/node/nt:termination-point/tp-id +--rw member-link-tp*
+--rw vxlan {VXLAN}? -> /nw:networks/network/node/nt:termination-point/tp-id
+--rw vni-id? vni +--rw vxlan {VXLAN}?
+--rw vni-id? vni
notifications: notifications:
+---n l2-node-event +---n l2-node-event
| +--ro event-type? l2-network-event-type | +--ro event-type? l2-network-event-type
| +--ro node-ref? -> /nw:networks/network[nw:network-id=current() | +--ro node-ref?
/../network-ref]/node/node-id -> /nw:networks/network[nw:network-id=current()
| +--ro network-ref? -> /nw:networks/network/network-id /../network-ref]/node/node-id
| +--ro l2-topology! | +--ro network-ref? -> /nw:networks/network/network-id
| +--ro l2-node-attributes | +--ro l2-topology!
| +--ro name? string | +--ro l2-node-attributes
| +--ro flags* node-flag-type | +--ro name? string
| +--ro bridge-id* uint64 | +--ro flags* node-flag-type
| +--ro management-address* inet:ip-address | +--ro bridge-id* uint64
| +--ro management-mac? yang:mac-address | +--ro management-address* inet:ip-address
| +--ro management-vlan? string | +--ro management-mac? yang:mac-address
+---n l2-link-event | +--ro management-vlan? string
| +--ro event-type? l2-network-event-type +---n l2-link-event
| +--ro link-ref? -> /nw:networks/network[nw:network-id=current() | +--ro event-type? l2-network-event-type
/../network-ref]/nt:link/link-id | +--ro link-ref?
| +--ro network-ref? -> /nw:networks/network/network-id -> /nw:networks/network[nw:network-id=current()
| +--ro l2-topology! /../network-ref]/nt:link/link-id
| +--ro l2-link-attributes | +--ro network-ref? -> /nw:networks/network/network-id
| +--ro name? string | +--ro l2-topology!
| +--ro flags* link-flag-type | +--ro l2-link-attributes
| +--ro rate? uint64 | +--ro name? string
| +--ro delay? uint32 | +--ro flags* link-flag-type
| +--ro auto-nego? boolean | +--ro rate? uint64
| +--ro duplex? duplex-mode | +--ro delay? uint32
+---n l2-termination-point-event | +--ro auto-nego? boolean
+--ro event-type? l2-network-event-type | +--ro duplex? duplex-mode
+--ro tp-ref? -> /nw:networks/network[nw:network-id=current() +---n l2-termination-point-event
/../network-ref]/node[nw:node-id=current() +--ro event-type? l2-network-event-type
/../node-ref]/nt:termination-point/tp-id +--ro tp-ref?
+--ro node-ref? -> /nw:networks/network[nw:network-id=current() -> /nw:networks/network[nw:network-id=current()
/../network-ref]/node/node-id /../network-ref]/node[nw:node-id=current()
+--ro network-ref? -> /nw:networks/network/network-id /../node-ref]/nt:termination-point/tp-id
+--ro l2-topology! +--ro node-ref?
+--ro l2-termination-point-attributes -> /nw:networks/network[nw:network-id=current()
+--ro interface-name? string /../network-ref]/node/node-id
+--ro mac-address? yang:mac-address +--ro network-ref? -> /nw:networks/network/network-id
+--ro port-number* uint32 +--ro l2-topology!
+--ro unnumbered-id* uint32 +--ro l2-termination-point-attributes
+--ro encapsulation-type? identityref +--ro interface-name? string
+--ro outer-tag? dot1q-types:vid-range-type {VLAN}? +--ro mac-address? yang:mac-address
+--ro outer-tpid? dot1q-types:dot1q-tag-type {QinQ}? +--ro port-number* uint32
+--ro inner-tag? dot1q-types:vid-range-type {VLAN}? +--ro unnumbered-id* uint32
+--ro inner-tpid? dot1q-types:dot1q-tag-type {QinQ}? +--ro encapsulation-type? identityref
+--ro lag? boolean +--ro outer-tag? dot1q-types:vid-range-type {VLAN}?
+--ro member-link-tp* -> /nw:networks/network/node/nt:termination-point/tp-id +--ro outer-tpid? dot1q-types:dot1q-tag-type {QinQ}?
+--ro vxlan {VXLAN}? +--ro inner-tag? dot1q-types:vid-range-type {VLAN}?
+--ro vni-id? vni +--ro inner-tpid? dot1q-types:dot1q-tag-type {QinQ}?
+--ro lag? boolean
+--ro member-link-tp*
-> /nw:networks/network/node/nt:termination-point/tp-id
+--ro vxlan {VXLAN}?
+--ro vni-id? vni
The Layer 2 topology YANG module augments the "ietf-network" and The Layer 2 Topology YANG module augments the "ietf-network" and
"ietf-network-topology" YANG modules as follows: "ietf-network-topology" YANG modules as follows:
o A new network type "l2-network-type" is introduced. This is * A new network type "l2-network-type" is introduced. This is
represented by a container object, and is inserted under the represented by a container object and is inserted under the
"network-types" container of the generic "ietf-network" module "network-types" container of the generic "ietf-network" module
defined in Section 6.1 of [RFC8345]. defined in Section 6.1 of [RFC8345].
o Additional network attributes are introduced in a grouping "l2- * Additional network attributes are introduced in a grouping "l2-
network-attributes", which augments the "network" list of the network-attributes", which augments the "network" list of the
"ietf-network" module. The attributes include Layer 2 network "ietf-network" module. The attributes include the Layer 2 network
name and a set of flags. Each type of flag is represented by a name and a set of flags. Each type of flag is represented by a
separate identity. separate identity.
o Additional data objects for Layer 2 nodes are introduced by * Additional data objects for Layer 2 nodes are introduced by
augmenting the "node" list of the generic "ietf-network" module. augmenting the "node" list of the generic "ietf-network" module.
New objects include Layer 2 node identifier, management address, New objects include Layer 2 node identifier, management address,
management mac, mangement vlan and a set of flags. management mac, management vlan, and a set of flags.
o Additional data objects for Layer 2 termination points are * Additional data objects for Layer 2 termination points are
introduced by augmenting the "termination-point" list of the introduced by augmenting the "termination-point" list of the
"ietf-network-topology" module defined in Section 6.2 of "ietf-network-topology" module defined in Section 6.2 of
[RFC8345]. New objects include interface name, encapsulation [RFC8345]. New objects include interface name, encapsulation
type, lag support and Layer 2 termination point type specific type, lag support, and attributes that are specific to the Layer 2
attributes. termination point type.
o Links in the "ietf-network-topology" module are augmented as well * Links in the "ietf-network-topology" module are augmented as well
with a set of Layer 2 parameters, allowing to associate a link with a set of Layer 2 parameters, allowing to associate a link
with a name, a set of Layer 2 link attributes, and flags. with a name, a set of Layer 2 link attributes, and flags.
o Some optional Layer 2 technology specific attributes are * Some optional Layer 2 technology-specific attributes are
introduced in this module as Layer 2 features because these introduced in this module as Layer 2 features because these
attributes may be useful to expose to above services/applications. attributes may be useful to expose to above services/applications.
Note that learning or configuring advanced Layer 2 technology- Note that learning or configuring advanced Layer 2 technology-
specific attributes is not within the scope of the Layer 2 specific attributes is not within the scope of the Layer 2
Topology YANG module; dedicated YANG modules should be used Topology YANG module; dedicated YANG modules should be used
instead (e.g., [I-D.ietf-trill-yang]). instead (e.g., [TRILL-YANG]).
4. Layer 2 Topology YANG Module 4. Layer 2 Topology YANG Module
This module uses types defined in [RFC6991], [RFC7224], This module uses types defined in [RFC6991], [RFC7224],
[IEEE802.1Qcp], and [RFC8345]. It also references [RFC4761], [IEEE802.1Qcp], and [RFC8345]. It also references [IEEE802.1Q-2014],
[RFC4762], and [RFC4202]. [IEEE802.1ad], [RFC7348], and [RFC7727].
<CODE BEGINS> file "ietf-l2-topology@2020-06-29.yang"
module ietf-l2-topology {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology";
prefix l2t;
import ietf-network { <CODE BEGINS> file "ietf-l2-topology@2020-11-02.yang"
prefix nw; module ietf-l2-topology {
reference yang-version 1.1;
"RFC 8345: A YANG Data Model for Network Topologies"; namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology";
} prefix l2t;
import ietf-network-topology {
prefix nt;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991:Common YANG Data Types";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991:Common YANG Data Types";
}
import iana-if-type {
prefix ianaift;
reference
"RFC 7224: IANA Interface Type YANG Module";
}
import ieee802-dot1q-types {
prefix dot1q-types;
reference
"IEEE Std 802.1Qcp-2018: Bridges and Bridged
Networks - Amendment: YANG Data Model";
}
organization import ietf-network {
"IETF I2RS (Interface to the Routing System) Working Group"; prefix nw;
contact reference
"WG Web: <http://tools.ietf.org/wg/i2rs/> "RFC 8345: A YANG Data Model for Network Topologies";
WG List: <mailto:i2rs@ietf.org> }
import ietf-network-topology {
prefix nt;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991:Common YANG Data Types";
}
import ietf-yang-types {
prefix yang;
reference
"RFC 6991:Common YANG Data Types";
}
import iana-if-type {
prefix ianaift;
reference
"RFC 7224: IANA Interface Type YANG Module";
}
import ieee802-dot1q-types {
prefix dot1q-types;
reference
"IEEE Std 802.1Qcp-2018: Bridges and Bridged
Networks - Amendment: YANG Data Model";
}
Editor: Jie Dong organization
<mailto:jie.dong@huawei.com> "IETF I2RS (Interface to the Routing System) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org>
Editor: Xiugang Wei Editor: Jie Dong
<mailto:weixiugang@huawei.com> <mailto:jie.dong@huawei.com>
Editor: Qin Wu Editor: Xiugang Wei
<mailto:bill.wu@huawei.com> <mailto:weixiugang@huawei.com>
Editor: Mohamed Boucadair Editor: Qin Wu
<mailto:mohamed.boucadair@orange.com> <mailto:bill.wu@huawei.com>
Editor: Anders Liu Editor: Mohamed Boucadair
<andersliu@tencent.com>"; <mailto:mohamed.boucadair@orange.com>
description
"This module defines a basic model for the Layer 2 topology
of a network.
Copyright (c) 2020 IETF Trust and the persons identified as Editor: Anders Liu
authors of the code. All rights reserved. <mailto:andersliu@tencent.com>";
description
"This module defines a basic model for the Layer 2 topology
of a network.
Redistribution and use in source and binary forms, with or Copyright (c) 2020 IETF Trust and the persons identified as
without modification, is permitted pursuant to, and subject authors of the code. All rights reserved.
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 RFC XXXX; see Redistribution and use in source and binary forms, with or
the RFC itself for full legal notices."; 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).
revision 2020-06-29 { This version of this YANG module is part of RFC 8944; see
description the RFC itself for full legal notices.";
"Initial revision";
reference
"RFC XXXX: A YANG Data Model for Layer 2
Network Topologies";
}
feature VLAN { revision 2020-11-02 {
description description
"Enables VLAN tag support as defined in IEEE 802.1Q."; "Initial revision.";
reference reference
"IEEE Std 802.1Q-2014: Bridges and Bridged Networks"; "RFC 8944: A YANG Data Model for Layer 2
} Network Topologies";
}
feature QinQ { feature VLAN {
description description
"Enables QinQ double tag support as defined in IEEE 802.1ad."; "Enables VLAN tag support, as defined in IEEE 802.1Q.";
reference reference
"IEEE Std 802.1ad: Provider Bridges"; "IEEE Std 802.1Q-2014: Bridges and Bridged Networks";
} }
feature VXLAN { feature QinQ {
description description
"Enables VXLAN support as defined in RFC7348."; "Enables QinQ double tag support, as defined in IEEE 802.1ad.";
reference reference
"RFC 7348: Virtual eXtensible Local Area Network (VXLAN): "IEEE Std 802.1ad: Provider Bridges";
A Framework for Overlaying Virtualized Layer 2 }
Networks over Layer 3 Networks";
}
identity flag-identity { feature VXLAN {
description description
"Base type for flags."; "Enables VXLAN support, as defined in RFC7348.";
} reference
"RFC 7348: Virtual eXtensible Local Area Network (VXLAN):
A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks";
}
identity eth-encapsulation-type { identity flag-identity {
base ianaift:iana-interface-type; description
description "Base type for flags.";
"Base identity from which specific Ethernet }
encapsulation types are derived.";
reference
"RFC 7224: IANA Interface Type YANG Module";
}
identity ethernet { identity eth-encapsulation-type {
base eth-encapsulation-type; base ianaift:iana-interface-type;
description description
"Native Ethernet encapsulation."; "Base identity from which specific Ethernet
} encapsulation types are derived.";
reference
"RFC 7224: IANA Interface Type YANG Module";
}
identity vlan { identity ethernet {
base eth-encapsulation-type; base eth-encapsulation-type;
description description
"VLAN encapsulation."; "Native Ethernet encapsulation.";
} }
identity qinq { identity vlan {
base eth-encapsulation-type; base eth-encapsulation-type;
description description
"QinQ encapsulation."; "VLAN encapsulation.";
} }
identity pbb { identity qinq {
base eth-encapsulation-type; base eth-encapsulation-type;
description description
"Provider-backbone-bridging (PBB) encapsulation. "QinQ encapsulation.";
The PBB functions are developed in IEEE 802.1ah."; }
}
identity trill { identity pbb {
base eth-encapsulation-type; base eth-encapsulation-type;
description description
"TRILL encapsulation."; "Provider-Backbone-Bridging (PBB) encapsulation.
} The PBB functions are developed in IEEE 802.1ah.";
}
identity vpls { identity trill {
base eth-encapsulation-type; base eth-encapsulation-type;
description description
"Ethernet VPLS interface encapsulation."; "Transparent Interconnection of Lots of Links (TRILL)
} encapsulation.";
}
identity vxlan { identity vpls {
base eth-encapsulation-type; base eth-encapsulation-type;
description description
"VXLAN MAC in UDP encapsulation."; "Ethernet Virtual Private LAN Service (VPLS)
reference interface encapsulation.";
"RFC 7348: Virtual eXtensible Local Area Network (VXLAN): }
A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks";
}
typedef vni { identity vxlan {
type uint32 { base eth-encapsulation-type;
range "0..16777215"; description
} "VXLAN Media Access Control (MAC) in UDP encapsulation.";
description reference
"VXLAN Network Identifier or VXLAN Segment ID. "RFC 7348: Virtual eXtensible Local Area Network (VXLAN):
It allows up to 16 M VXLAN segments to coexist A Framework for Overlaying Virtualized Layer 2
within the same administrative domain. Networks over Layer 3 Networks";
}
The use of value '0' is implementation-specific."; typedef vni {
reference type uint32 {
"RFC 7348: Virtual eXtensible Local Area Network (VXLAN): range "0..16777215";
A Framework for Overlaying Virtualized Layer 2 }
Networks over Layer 3 Networks"; description
} "VXLAN Network Identifier or VXLAN Segment ID.
typedef l2-flag-type { It allows up to 16 M VXLAN segments to coexist
type identityref { within the same administrative domain.
base flag-identity;
}
description
"Base type for L2 flags. One example of L2 flag
type is trill which represents trill topology
type.";
}
typedef node-flag-type { The use of value '0' is implementation specific.";
type identityref { reference
base flag-identity; "RFC 7348: Virtual eXtensible Local Area Network (VXLAN):
} A Framework for Overlaying Virtualized Layer 2
description Networks over Layer 3 Networks";
"Node flag attributes. The physical node can be }
one example of node flag attribute.";
}
typedef link-flag-type { typedef l2-flag-type {
type identityref { type identityref {
base flag-identity; base flag-identity;
} }
description description
"Link flag attributes. One example of link flag "Base type for L2 flags. One example of L2 flag
attribute is the pseudowire."; type is trill, which represents the trill topology
} type.";
}
typedef l2-network-event-type { typedef node-flag-type {
type enumeration { type identityref {
enum addition { base flag-identity;
value 0; }
description description
"A Layer 2 node or link or termination-point "Node flag attributes. The physical node can be
has been added."; one example of a node flag attribute.";
} }
enum removal {
value 1;
description
"A Layer 2 node or link or termination-point
has been removed.";
}
enum update {
value 2;
description
"A Layer 2 node or link or termination-point
has been updated.";
}
} typedef link-flag-type {
description type identityref {
"Layer 2 network event type for notifications."; base flag-identity;
} }
description
"Link flag attributes. One example of a link flag
attribute is the pseudowire.";
}
typedef duplex-mode { typedef l2-network-event-type {
type enumeration { type enumeration {
enum full-duplex { enum addition {
description value 0;
"Indicates full-duplex mode."; description
} "A Layer 2 node or link or termination-point
enum half-duplex { has been added.";
description }
"Indicates half-duplex mode."; enum removal {
} value 1;
} description
description "A Layer 2 node or link or termination-point
"Indicates the type of the duplex mode."; has been removed.";
} }
enum update {
value 2;
description
"A Layer 2 node or link or termination-point
has been updated.";
}
}
description
"Layer 2 network event type for notifications.";
}
grouping l2-network-type { typedef duplex-mode {
description type enumeration {
"Indicates the topology type to be L2."; enum full-duplex {
container l2-topology { description
presence "Indicates L2 Network Topology."; "Indicates full-duplex mode.";
description }
"The presence of the container node indicates enum half-duplex {
L2 Network Topology."; description
} "Indicates half-duplex mode.";
} }
}
description
"Indicates the type of the duplex mode.";
}
grouping l2-topology-attributes { grouping l2-network-type {
description description
"L2 Topology scope attributes."; "Indicates the topology type to be L2.";
container l2-topology-attributes { container l2-topology {
description presence "Indicates L2 Network Topology.";
"Contains L2 topology attributes."; description
leaf name { "The presence of the container node indicates
type string; L2 Network Topology.";
description }
"Name of the topology."; }
}
leaf-list flags {
type l2-flag-type;
description
"Topology flags.";
}
}
} grouping l2-topology-attributes {
description
"L2 topology scope attributes.";
container l2-topology-attributes {
description
"Contains L2 topology attributes.";
leaf name {
type string;
description
"Name of the topology.";
}
leaf-list flags {
type l2-flag-type;
description
"Topology flags.";
}
}
}
grouping l2-node-attributes { grouping l2-node-attributes {
description description
"L2 node attributes"; "L2 node attributes.";
container l2-node-attributes { container l2-node-attributes {
description description
"Contains L2 node attributes."; "Contains L2 node attributes.";
leaf name { leaf name {
type string; type string;
description description
"Node name."; "Node name.";
} }
leaf-list flags { leaf-list flags {
type node-flag-type; type node-flag-type;
description description
"Node flags. It can be used to indicates "Node flags. It can be used to indicate
node flag attributes."; node flag attributes.";
} }
leaf-list bridge-id { leaf-list bridge-id {
type string { type string {
pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){7}'; pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){7}';
} }
description description
"This is the bridge identifier represented as "This is the bridge identifier represented as a
hexadecimal 8 octet string. It has 4 bits of hexadecimal 8-octet string. It has 4 bits of
priority, 12 bits of MSTI-ID and the base bridge priority, 12 bits of Multiple Spanning Tree
identifier. There may be multiple one for each Instance Identifier (MSTI-ID), and the base bridge
spanning tree instance."; identifier. There may be multiple for each
reference spanning tree instance.";
"RFC 7727: Spanning Tree Protocol (STP) Application of reference
the Inter-Chassis Communication Protocol (ICCP)"; "RFC 7727: Spanning Tree Protocol (STP) Application of
} the Inter-Chassis Communication Protocol (ICCP)";
leaf-list management-address { }
type inet:ip-address; leaf-list management-address {
description type inet:ip-address;
"IP address used for management purpose."; description
} "IP address used for management purpose.";
leaf management-mac { }
type yang:mac-address; leaf management-mac {
description type yang:mac-address;
"This is a MAC address used the bridge management. description
It can be the Bridge Base VID, interface "This is a MAC address using the bridge management.
MAC address or other. "; It can be the Bridge Base VLAN ID (VID), interface
} MAC address, or other. ";
leaf management-vlan { }
type string; leaf management-vlan {
description type string;
"This is a VLAN that supports the Management address. description
The actual VLAN ID type and value would be a member of "This is a VLAN that supports the management address.
this VLAN."; The actual VLAN ID type and value would be a member of
} this VLAN.";
} }
} }
}
grouping l2-link-attributes { grouping l2-link-attributes {
description description
"L2 link attributes"; "L2 link attributes.";
container l2-link-attributes { container l2-link-attributes {
description description
"Contains L2 link attributes."; "Contains L2 link attributes.";
leaf name { leaf name {
type string; type string;
description description
"Link name."; "Link name.";
} }
leaf-list flags { leaf-list flags {
type link-flag-type; type link-flag-type;
description description
"Link flags. It can be used to indicate "Link flags. It can be used to indicate
link flag attributes."; link flag attributes.";
} }
leaf rate { leaf rate {
type uint64; type uint64;
units "Kbps"; units "Kbps";
description description
"Link rate. It specifies bandwidth requirements "Link rate. It specifies bandwidth requirements
associated with the specific link. The link associated with the specific link. The link
contains a source and a destination."; contains a source and a destination.";
} }
leaf delay { leaf delay {
type uint32; type uint32;
units "microseconds"; units "microseconds";
description description
"Unidirectional Link delay in "Unidirectional link delay in
microseconds."; microseconds.";
} }
leaf auto-nego { leaf auto-nego {
type boolean; type boolean;
default "true"; default "true";
description description
"Set to true if auto negotiation is supported. "Set to true if auto-negotiation is supported.
Set to false if auto negotiation is not supported."; Set to false if auto-negotiation is not supported.";
} }
leaf duplex { leaf duplex {
type duplex-mode; type duplex-mode;
description description
"Expose the duplex mode, full duplex or half-duplex."; "Expose the duplex mode, full-duplex or half-duplex.";
} }
} }
} }
grouping l2-termination-point-attributes { grouping l2-termination-point-attributes {
description description
"L2 termination point attributes"; "L2 termination point attributes.";
container l2-termination-point-attributes { container l2-termination-point-attributes {
description description
"Containing L2 termination point attributes."; "Containing L2 termination point attributes.";
leaf interface-name { leaf interface-name {
type string; type string;
description description
"Name of the interface. The name can (but does not "Name of the interface. The name can (but does not
have to) correspond to an interface reference of a have to) correspond to an interface reference of a
containing node's interface, i.e., the path name of a containing node's interface, i.e., the path name of a
corresponding interface data node on the containing corresponding interface data node on the containing
node reminiscent of data type interface-ref defined node is reminiscent of data type interface-ref defined
in RFC 8343. It should be noted that data type in RFC 8343. It should be noted that data type
interface-ref of RFC 8343 cannot be used directly, interface-ref of RFC 8343 cannot be used directly,
as this data type is used to reference an interface as this data type is used to reference an interface
in a datastore of a single node in the network, not in a datastore of a single node in the network, not
to uniquely reference interfaces across a network."; to uniquely reference interfaces across a network.";
} }
leaf mac-address { leaf mac-address {
type yang:mac-address; type yang:mac-address;
description description
"Interface MAC address for logical link control."; "Interface MAC address for logical link control.";
} }
leaf-list port-number { leaf-list port-number {
type uint32; type uint32;
description description
" List of port numbers of the Bridge ports for which each " List of port numbers of the bridge ports for which each
entry contains Bridge management information."; entry contains bridge management information.";
} }
leaf-list unnumbered-id { leaf-list unnumbered-id {
type uint32; type uint32;
description description
"List of unnumbered interface identifiers. "List of unnumbered interface identifiers.
The unnumbered interface identifier will correspond to The unnumbered interface identifier will correspond to
the ifIndex value of the interface, i.e., the ifIndex value the ifIndex value of the interface, i.e., the ifIndex
of the ifEntry that represents the interface in value of the ifEntry that represents the interface in
implementations where the Interfaces Group MIB implementations where the Interfaces Group MIB
(RFC 2863) is supported."; (RFC 2863) is supported.";
} }
leaf encapsulation-type { leaf encapsulation-type {
type identityref { type identityref {
base eth-encapsulation-type; base eth-encapsulation-type;
} }
description description
"Encapsulation type of this "Encapsulation type of this
termination point."; termination point.";
} }
leaf outer-tag { leaf outer-tag {
if-feature "VLAN"; if-feature "VLAN";
type dot1q-types:vid-range-type; type dot1q-types:vid-range-type;
description description
"The outermost VLAN tag. It may include a list of VLAN "The outermost VLAN tag. It may include a list of VLAN
Ids, or non overlapping VLAN ranges."; Ids or nonoverlapping VLAN ranges.";
} }
leaf outer-tpid { leaf outer-tpid {
if-feature "QinQ"; if-feature "QinQ";
type dot1q-types:dot1q-tag-type; type dot1q-types:dot1q-tag-type;
description description
"Identifies a specific 802.1Q tag type of outermost VLAN tag."; "Identifies a specific 802.1Q tag type of outermost VLAN
} tag.";
leaf inner-tag { }
if-feature "VLAN"; leaf inner-tag {
type dot1q-types:vid-range-type; if-feature "VLAN";
description type dot1q-types:vid-range-type;
"The inner VLAN tag. It may include a list of VLAN description
Ids, or non overlapping VLAN ranges."; "The inner VLAN tag. It may include a list of VLAN
} Ids or nonoverlapping VLAN ranges.";
leaf inner-tpid { }
if-feature "QinQ"; leaf inner-tpid {
type dot1q-types:dot1q-tag-type; if-feature "QinQ";
description type dot1q-types:dot1q-tag-type;
"Identifies a specific 802.1Q tag type of inner VLAN tag."; description
} "Identifies a specific 802.1Q tag type of inner VLAN tag.";
leaf lag { }
type boolean; leaf lag {
default "false"; type boolean;
description default "false";
"Defines whether lag is supported or not. description
When it is set to true, the lag is supported."; "Defines whether lag is supported or not.
} When it is set to true, the lag is supported.";
leaf-list member-link-tp { }
when "../lag = 'true'" { leaf-list member-link-tp {
description when "../lag = 'true'" {
"Relevant only when the lag interface is supported."; description
} "Relevant only when the lag interface is supported.";
type leafref { }
path "/nw:networks/nw:network/nw:node/nt:termination-point/nt:tp-id"; type leafref {
} path "/nw:networks/nw:network/nw:node/"
description + "nt:termination-point/nt:tp-id";
"List of member link termination points associated with }
specific l2 termination point."; description
} "List of member link termination points associated with
container vxlan { specific L2 termination point.";
when "derived-from-or-self(../encapsulation-type, 'l2t:vxlan')" { }
description container vxlan {
"Only applies when the type of the Ethernet when "derived-from-or-self(../encapsulation-type, "
encapsulation is 'vxlan'."; + "'l2t:vxlan')" {
} description
if-feature "VXLAN"; "Only applies when the type of the Ethernet
leaf vni-id { encapsulation is 'vxlan'.";
type vni; }
description if-feature "VXLAN";
"VXLAN Network Identifier (VNI)."; leaf vni-id {
} type vni;
description description
"Vxlan encapsulation type."; "VXLAN Network Identifier (VNI).";
} }
} description
} "Vxlan encapsulation type.";
}
}
}
augment "/nw:networks/nw:network/nw:network-types" { augment "/nw:networks/nw:network/nw:network-types" {
description description
"Introduces new network type for L2 topology."; "Introduces new network type for L2 topology.";
uses l2-network-type; uses l2-network-type;
} }
augment "/nw:networks/nw:network" { augment "/nw:networks/nw:network" {
when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' { when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
description description
"Augmentation parameters apply only for networks "Augmentation parameters apply only for networks
with L2 topology."; with L2 topology.";
} }
description description
"Configuration parameters for the L2 network "Configuration parameters for the L2 network
as a whole."; as a whole.";
uses l2-topology-attributes; uses l2-topology-attributes;
} }
augment "/nw:networks/nw:network/nw:node" { augment "/nw:networks/nw:network/nw:node" {
when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' { when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
description description
"Augmentation parameters apply only for networks "Augmentation parameters apply only for networks
with L2 topology."; with L2 topology.";
} }
description description
"Configuration parameters for L2 at the node "Configuration parameters for L2 at the node
level."; level.";
uses l2-node-attributes; uses l2-node-attributes;
}
augment "/nw:networks/nw:network/nt:link" {
when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
description
"Augmentation parameters apply only for networks
with L2 topology.";
}
description
"Augments L2 topology link information.";
uses l2-link-attributes;
}
augment "/nw:networks/nw:network/nw:node/nt:termination-point" {
when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
description
"Augmentation parameters apply only for networks
with L2 topology.";
}
description
"Augments L2 topology termination point information.";
uses l2-termination-point-attributes;
}
} notification l2-node-event {
augment "/nw:networks/nw:network/nt:link" { description
when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' { "Notification event for L2 node.";
description leaf event-type {
"Augmentation parameters apply only for networks type l2-network-event-type;
with L2 topology."; description
} "Event type.";
description }
"Augments L2 topology link information."; uses nw:node-ref;
uses l2-link-attributes; uses l2-network-type;
} uses l2-node-attributes;
augment "/nw:networks/nw:network/nw:node/nt:termination-point" { }
when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' {
description
"Augmentation parameters apply only for networks
with L2 topology.";
}
description
"Augments L2 topology termination point information.";
uses l2-termination-point-attributes;
}
notification l2-node-event { notification l2-link-event {
description description
"Notification event for L2 node."; "Notification event for L2 link.";
leaf event-type { leaf event-type {
type l2-network-event-type; type l2-network-event-type;
description description
"Event type."; "Event type.";
} }
uses nw:node-ref; uses nt:link-ref;
uses l2-network-type; uses l2-network-type;
uses l2-node-attributes; uses l2-link-attributes;
} }
notification l2-link-event { notification l2-termination-point-event {
description description
"Notification event for L2 link."; "Notification event for L2 termination point.";
leaf event-type { leaf event-type {
type l2-network-event-type; type l2-network-event-type;
description description
"Event type."; "Event type.";
} }
uses nt:link-ref; uses nt:tp-ref;
uses l2-network-type; uses l2-network-type;
uses l2-link-attributes; uses l2-termination-point-attributes;
} }
notification l2-termination-point-event { }
description <CODE ENDS>
"Notification event for L2 termination point.";
leaf event-type {
type l2-network-event-type;
description
"Event type.";
}
uses nt:tp-ref;
uses l2-network-type;
uses l2-termination-point-attributes;
}
}
<CODE ENDS>
5. IANA Considerations 5. IANA Considerations
This document requests IANA to register the following URIs in the IANA has registered the following URIs in the "ns" subregistry within
"ns" subregistry within the "IETF XML Registry" [RFC3688]: "The IETF XML Registry" [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG modules in IANA has registered the following YANG modules in the "YANG Module
the "YANG Module Names" subregistry [RFC6020] within the "YANG Names" subregistry [RFC6020] within the "YANG Parameters" registry.
Parameters" registry.
name: ietf-l2-topology Name: ietf-l2-topology
namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology Namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology
prefix: l2t Prefix: l2t
reference: RFC XXXX Reference: RFC 8944
name: ietf-l2-topology-state Name: ietf-l2-topology-state
namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state Namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state
prefix: l2t-s Prefix: l2t-s
reference: RFC XXXX Reference: RFC 8944
These modules are not maintained by IANA. These modules are not maintained by IANA.
6. Security Considerations 6. Security Considerations
The YANG module specified in this document defines a schema for data The YANG modules specified in this document define a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols,
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer such as Network Configuration Protocol (NETCONF) [RFC6241] or
is the secure transport layer, and the mandatory-to-implement secure RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer layer, and the mandatory-to-implement secure transport is Secure
is HTTPS, and the mandatory-to-implement secure transport is TLS Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the
[RFC8446]. mandatory-to-implement secure transport is TLS [RFC8446].
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content. RESTCONF protocol operations and content.
The Layer 2 topology module defines information that can be The Layer 2 topology module defines information that can be
configurable in certain instances, for example in the case of virtual configurable in certain instances, for example, in the case of
topologies that can be created by client applications. In such virtual topologies that can be created by client applications. In
cases, a malicious client could introduce topologies that are such cases, a malicious client could introduce topologies that are
undesired. Specifically, a malicious client could attempt to remove undesired. Specifically, a malicious client could attempt to remove
or add a node, a link, a termination point, by creating or deleting or add a node, a link, or a termination point by creating or deleting
corresponding elements in the node, link, and termination point corresponding elements in the node, link, and termination point
lists, respectively. In the case of a topology that is learned, the lists, respectively. In the case of a topology that is learned, the
server will automatically prohibit such misconfiguration attempts. server will automatically prohibit such misconfiguration attempts.
In the case of a topology that is configured, i.e. whose origin is In the case of a topology that is configured, i.e., whose origin is
"intended", the undesired configuration could become effective and be "intended", the undesired configuration could become effective and be
reflected in the operational state datastore [RFC8342], leading to reflected in the operational state datastore [RFC8342], leading to
disruption of services provided via this topology. For those disruption of services provided via this topology. For those
reasons, it is important that the NACM is vigorously applied to reasons, it is important that the NACM is vigorously applied to
prevent topology misconfiguration by unauthorized clients. prevent topology misconfiguration by unauthorized clients.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
o l2-network-attributes: A malicious client could attempt to l2-network-attributes:
sabotage the configuration of any of the contained attributes, A malicious client could attempt to sabotage the configuration of
such as the name or the flag data nodes. any of the contained attributes, such as the name or the flag data
nodes.
o l2-node-attributes: A malicious client could attempt to sabotage l2-node-attributes:
the configuration of important node attributes, such as the name A malicious client could attempt to sabotage the configuration of
or the management-address. important node attributes, such as the name or the management-
address.
o l2-link-attributes: A malicious client could attempt to sabotage l2-link-attributes:
the configuration of important link attributes, such as the rate A malicious client could attempt to sabotage the configuration of
or the delay data nodes. important link attributes, such as the rate or the delay data
nodes.
o l2-termination-point-attributes: A malicious client could attempt l2-termination-point-attributes:
to sabotage the configuration of important termination point A malicious client could attempt to sabotage the configuration of
attributes (e.g., 'maximum-frame-size'). important termination point attributes (e.g., 'maximum-frame-
size').
Some of the readable data nodes in this YANG module may be considered Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. In particular, the YANG model for notification) to these data nodes. In particular, the YANG module
layer 2 topology may expose sensitive information, for example the for Layer 2 topology may expose sensitive information, for example,
MAC addresses of devices, VLAN/VXLAN identifiers. Unrestricted use the MAC addresses of devices or VLAN/VXLAN identifiers. Unrestricted
of such information can lead to privacy violations. For example, use of such information can lead to privacy violations. For example,
listing MAC addresses in a network allows monitoring of devices and listing MAC addresses in a network allows monitoring of devices and
their movements. Location information can be derived from MAC their movements. Location information can be derived from MAC
addresses of network devices, bypassing protection of location addresses of network devices, bypassing protection of location
information by the Operating System. information by the Operating System.
7. Acknowledgements 7. References
The authors would like to acknowledge the comments and suggestions
received from Susan Hares, Alia Atlas, Juergen Schoenwaelder, Mach
Chen, Alexander Clemm, Sriganesh Kini, Oscar Gonzalez de Dios, Stig
Venaas, Christian Huitema, and Meral Shirazipour,Benjamin Kaduk,Don
Fedyk.
Many thanks to Ladislav Lhotka for the yang-doctors review.
8. References
8.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<https://www.rfc-editor.org/info/rfc4202>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
RFC 7224, DOI 10.17487/RFC7224, May 2014, RFC 7224, DOI 10.17487/RFC7224, May 2014,
<https://www.rfc-editor.org/info/rfc7224>. <https://www.rfc-editor.org/info/rfc7224>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
8.2. Informative References 7.2. Informative References
[I-D.ietf-trill-yang]
Weiguo, H., Yizhou, L., Kumar, D., Durrani, M., Zhai, H.,
and L. Xia, "TRILL YANG Data Model", draft-ietf-trill-
yang-04 (work in progress), December 2015.
[I2RS-UR] Hares, S. and M. Chen, "Summary of I2RS Use Case [I2RS-UR] Hares, S. and M. Chen, "Summary of I2RS Use Case
Requirements", draft-ietf-i2rs-usecase-reqs-summary-03 Requirements", Work in Progress, Internet-Draft, draft-
(work in progress), November 2016. ietf-i2rs-usecase-reqs-summary-03, 15 November 2016,
<https://tools.ietf.org/html/draft-ietf-i2rs-usecase-reqs-
summary-03>.
[IEEE802.1AB] [IEEE802.1AB]
"Station and Media Access Control Connectivity Discovery", IEEE, "IEEE Standard for Local and metropolitan area
IEEE Std 802.1AB-2016, March 2016. networks - Station and Media Access Control Connectivity
Discovery", IEEE Std 802.1AB-2016,
DOI 10.1109/IEEESTD.2016.7433915, March 2016,
<https://doi.org/10.1109/IEEESTD.2016.7433915>.
[IEEE802.1ad] [IEEE802.1ad]
"Virtual Bridged Local Area Networks Amendment 4: Provider IEEE, "IEEE Standard for Local and Metropolitan Area
Bridges", IEEE Std 802.1ad-2005, May 2006. Networks--Virtual Bridged Local Area Networks--Amendment
4: Provider Bridges", IEEE Std 802.1ad-2005,
DOI 10.1109/IEEESTD.2006.6044678, May 2006,
<https://doi.org/10.1109/IEEESTD.2006.6044678>.
[IEEE802.1ah] [IEEE802.1ah]
"Virtual Bridged Local Area Networks Amendment 4: Provider IEEE, "IEEE Standard for Local and metropolitan area
Bridges", IEEE Std 802.1ah-2008, August 2008. networks -- Virtual Bridged Local Area Networks Amendment
7: Provider Backbone Bridges", IEEE Std 802.1ah-2008,
DOI 10.1109/IEEESTD.2008.4602826, August 2008,
<https://doi.org/10.1109/IEEESTD.2008.4602826>.
[IEEE802.1Qcp] [IEEE802.1Q-2014]
"Bridges and Bridged Networks - Amendment: YANG Data IEEE, "IEEE Standard for Local and metropolitan area
Model", IEEE Std 802.1Qcp-2018, September 2018. networks--Bridges and Bridged Networks", IEEE 802.1Q-2014,
DOI 10.1109/IEEESTD.2014.6991462, December 2014,
<https://doi.org/10.1109/IEEESTD.2014.6991462>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [IEEE802.1Qcp]
and A. Bierman, Ed., "Network Configuration Protocol IEEE, "IEEE Standard for Local and metropolitan area
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, networks--Bridges and Bridged Networks--Amendment 30: YANG
<https://www.rfc-editor.org/info/rfc6241>. Data Model", IEEE Std 802.1Qcp-2018,
DOI 10.1109/IEEESTD.2018.8467507, September 2018,
<https://doi.org/10.1109/IEEESTD.2018.8467507>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC7727] Zhang, M., Wen, H., and J. Hu, "Spanning Tree Protocol
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, (STP) Application of the Inter-Chassis Communication
<https://www.rfc-editor.org/info/rfc6242>. Protocol (ICCP)", RFC 7727, DOI 10.17487/RFC7727, January
2016, <https://www.rfc-editor.org/info/rfc7727>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016, RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/info/rfc7951>. <https://www.rfc-editor.org/info/rfc7951>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
Appendix A. Companion YANG Module for Non-NMDA Compliant [TRILL-YANG]
Hao, W., Li, Y., Kumar, D., Durrani, M., Zhai, H., and L.
Xia, "TRILL YANG Data Model", Work in Progress, Internet-
Draft, draft-ietf-trill-yang-04, 20 December 2015,
<https://tools.ietf.org/html/draft-ietf-trill-yang-04>.
Appendix A. Companion YANG Module for Non-NMDA-Compliant
Implementations Implementations
The YANG module ietf-l2-topology defined in this document augments The YANG module ietf-l2-topology defined in this document augments
two modules, "ietf-network" and "ietf-network-topology", that are two modules, "ietf-network" and "ietf-network-topology", that are
designed to be used in conjunction with implementations that support designed to be used in conjunction with implementations that support
the Network Management Datastore Architecture (NMDA) defined in the Network Management Datastore Architecture (NMDA) defined in
[RFC8342]. In order to allow implementations to use the model even [RFC8342]. In order to allow implementations to use the model even
in cases when NMDA is not supported, a set of companion modules have in cases when NMDA is not supported, a set of companion modules have
been defined that represent a state model of networks and network been defined that represent a state model of networks and network
topologies, "ietf-network-state" and "ietf-network-topology-state", topologies, "ietf-network-state" and "ietf-network-topology-state",
respectively. respectively.
In order to be able to use the model for layer 2 topologies defined In order to be able to use the model for Layer 2 topologies defined
in this document in conjunction with non-NMDA compliant in this document in conjunction with non-NMDA-compliant
implementations, a corresponding companion module is defined that implementations, a corresponding companion module is defined that
represents the operational state of layer 2 network topologies. The represents the operational state of Layer 2 network topologies. The
module "ietf-l2-topology-state" mirrors the module "ietf-l2-topology" module "ietf-l2-topology-state" mirrors the module "ietf-l2-topology"
defined in Section 4. However, it augments "ietf-network-state" and defined in Section 4. However, it augments "ietf-network-state" and
"ietf-network-topology-state" (instead of "ietf-network" and "ietf- "ietf-network-topology-state" (instead of "ietf-network" and "ietf-
network-topology") and all its data nodes are non-configurable. network-topology") and all its data nodes are nonconfigurable.
The companion module "ietf-l2-topology" SHOULD NOT be supported by The companion module "ietf-l2-topology" SHOULD NOT be supported by
implementations that support NMDA. It is for this reason that this implementations that support NMDA. It is for this reason that this
module is defined in the informative Appendix. module is defined in the informative appendix.
As the structure of this modules mirrors that of its underlying As the structure of this module mirrors that of its underlying
modules, the YANG tree is not depicted separately. modules, the YANG tree is not depicted separately.
<CODE BEGINS> file "ietf-l2-topology-state@2020-06-29.yang" <CODE BEGINS> file "ietf-l2-topology-state@2020-11-02.yang"
module ietf-l2-topology-state { module ietf-l2-topology-state {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology-state"; namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology-state";
prefix l2t-s; prefix l2t-s;
import ietf-network-state { import ietf-network-state {
prefix nw-s; prefix nw-s;
reference reference
"RFC 8345: A YANG Data Model for Network Topologies"; "RFC 8345: A YANG Data Model for Network Topologies";
} }
import ietf-network-topology-state { import ietf-network-topology-state {
prefix nt-s; prefix nt-s;
reference reference
"RFC 8345: A YANG Data Model for Network Topologies"; "RFC 8345: A YANG Data Model for Network Topologies";
} }
import ietf-l2-topology { import ietf-l2-topology {
prefix l2t; prefix l2t;
reference reference
"RFC XXXX: A YANG Data Model for Layer 2 Network "RFC 8944: A YANG Data Model for Layer 2 Network
Topologies"; Topologies";
} }
organization organization
"IETF I2RS (Interface to the Routing System) Working Group"; "IETF I2RS (Interface to the Routing System) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/i2rs/> "WG Web: <http://tools.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org> WG List: <mailto:i2rs@ietf.org>
Editor: Jie Dong Editor: Jie Dong
skipping to change at page 26, line 7 skipping to change at line 1200
Copyright (c) 2020 IETF Trust and the persons identified as Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 8944; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2020-06-29 { revision 2020-11-02 {
description description
"Initial revision"; "Initial revision.";
reference reference
"RFC XXXX: A YANG Data Model for Layer 2 Network "RFC 8944: A YANG Data Model for Layer 2 Network
Topologies"; Topologies";
} }
/* /*
* Data nodes * Data nodes
*/ */
augment "/nw-s:networks/nw-s:network/nw-s:network-types" { augment "/nw-s:networks/nw-s:network/nw-s:network-types" {
description description
"Introduces a new network type for L2 topology."; "Introduces a new network type for L2 topology.";
skipping to change at page 27, line 46 skipping to change at line 1287
description description
"Event type."; "Event type.";
} }
uses nw-s:node-ref; uses nw-s:node-ref;
uses l2t:l2-network-type; uses l2t:l2-network-type;
uses l2t:l2-node-attributes; uses l2t:l2-node-attributes;
} }
notification l2-link-event { notification l2-link-event {
description description
"Notification event for a L2 link."; "Notification event for an L2 link.";
leaf event-type { leaf event-type {
type l2t:l2-network-event-type; type l2t:l2-network-event-type;
description description
"Event type."; "Event type.";
} }
uses nt-s:link-ref; uses nt-s:link-ref;
uses l2t:l2-network-type; uses l2t:l2-network-type;
uses l2t:l2-link-attributes; uses l2t:l2-link-attributes;
} }
skipping to change at page 28, line 33 skipping to change at line 1322
Appendix B. An Example Appendix B. An Example
This section contains an example of an instance data tree in JSON This section contains an example of an instance data tree in JSON
encoding [RFC7951]. The example instantiates "ietf-l2-topology" for encoding [RFC7951]. The example instantiates "ietf-l2-topology" for
the topology that is depicted in the following diagram. There are the topology that is depicted in the following diagram. There are
three nodes: D1, D2, and D3. D1 has three termination points: 1-0-1, three nodes: D1, D2, and D3. D1 has three termination points: 1-0-1,
1-2-1, and 1-3-1. D2 has three termination points as well: 2-1-1, 1-2-1, and 1-3-1. D2 has three termination points as well: 2-1-1,
2-0-1, and 2-3-1. D3 has two termination points: 3-1-1 and 3-2-1. 2-0-1, and 2-3-1. D3 has two termination points: 3-1-1 and 3-2-1.
For termination point 1-0-1, it provides lag support and has two For termination point 1-0-1, it provides lag support and has two
member link termination points: 1-0-1-1,1-0-1-2. In addition, there member link termination points: 1-0-1-1 and 1-0-1-2. In addition,
are six links, two between each pair of nodes, with one going in each there are six links, two between each pair of nodes with one going in
direction. each direction.
+------------+ +------------+ +------------+ +------------+
| D1 | | D2 | | D1 | | D2 |
1-0-1-1 /-\ /-\ /-\ /-\ 1-0-1-1 /-\ /-\ /-\ /-\
<--------->| | 1-0-1 | |---------------->| | 2-1-1 | | <--------->| | 1-0-1 | |---------------->| | 2-1-1 | |
1-0-1-2 | | 1-2-1 | |<----------------| | 2-0-1 | | 1-0-1-2 | | 1-2-1 | |<----------------| | 2-0-1 | |
<--------> \-/ 1-3-1 \-/ \-/ 2-3-1 \-/ <--------> \-/ 1-3-1 \-/ \-/ 2-3-1 \-/
| /----\ | | /----\ | | /----\ | | /----\ |
+---| |---+ +---| |---+ +---| |---+ +---| |---+
\----/ \----/ \----/ \----/
skipping to change at page 29, line 26 skipping to change at line 1347
| | | | | | | |
| | +------------+ | | | | +------------+ | |
| | | D3 | | | | | | D3 | | |
| | /-\ /-\ | | | | /-\ /-\ | |
| +----->| | 3-1-1 | |-------+ | | +----->| | 3-1-1 | |-------+ |
+---------| | 3-2-1 | |<---------+ +---------| | 3-2-1 | |<---------+
\-/ \-/ \-/ \-/
| | | |
+------------+ +------------+
Figure 2. A Network Topology Example Figure 2: A Network Topology Example
The corresponding instance data tree is depicted below: The corresponding instance data tree is depicted below:
{ {
"ietf-network:networks": { "ietf-network:networks": {
"network": [ "network": [
{ {
"network-id": "l2-topo-example", "network-id": "l2-topo-example",
"node": [ "node": [
{ {
skipping to change at page 33, line 34 skipping to change at line 1547
"ietf-l2-topology:l2-link-attributes": { "ietf-l2-topology:l2-link-attributes": {
"rate": "1000" "rate": "1000"
} }
} }
] ]
} }
] ]
} }
} }
Acknowledgements
The authors would like to acknowledge the comments and suggestions
received from Susan Hares, Alia Atlas, Juergen Schoenwaelder, Mach
Chen, Alexander Clemm, Sriganesh Kini, Oscar Gonzalez de Dios, Stig
Venaas, Christian Huitema, Meral Shirazipour, Benjamin Kaduk, and Don
Fedyk.
Many thanks to Ladislav Lhotka for the yang-doctors review.
Authors' Addresses Authors' Addresses
Jie Dong Jie Dong
Huawei Huawei
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus
Beijing 100095 No. 156 Beiqing Rd.
Beijing
100095
China China
Email: jie.dong@huawei.com Email: jie.dong@huawei.com
Xiugang Wei Xiugang Wei
Huawei Huawei
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus
Beijing 100095 No. 156 Beiqing Rd.
Beijing
100095
China China
Email: weixiugang@huawei.com Email: weixiugang@huawei.com
Qin Wu Qin Wu
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue
Nanjing 210012 Yuhua District
Nanjing
210012
China China
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
Mohamed Boucadair Mohamed Boucadair
Orange Orange
Rennes 35000 Rennes 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Anders Liu Anders Liu
Tecent Tecent
Yinke Building 38 Haidian St, Haidian District Yinke Building
Beijing 100080 38 Haidian St
Haidian District
Beijing
100080
China China
Email: andersliu@tencent.com Email: andersliu@tencent.com
 End of changes. 117 change blocks. 
844 lines changed or deleted 863 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/