idnits 2.17.1 draft-ietf-i2rs-yang-l2-network-topology-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 15 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 200 has weird spacing: '...vlan-id dot...' == Line 203 has weird spacing: '...vlan-id dot...' == Line 204 has weird spacing: '...vlan-id dot...' == Line 261 has weird spacing: '...vlan-id dot...' == Line 264 has weird spacing: '...vlan-id dot...' == (1 more instance...) -- The document date (July 12, 2020) is 1384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7348 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft X. Wei 4 Intended status: Standards Track Q. Wu 5 Expires: January 13, 2021 Huawei 6 M. Boucadair 7 Orange 8 A. Liu 9 Tecent 10 July 12, 2020 12 A YANG Data Model for Layer 2 Network Topologies 13 draft-ietf-i2rs-yang-l2-network-topology-15 15 Abstract 17 This document defines a YANG data model for Layer 2 network 18 topologies. In particular, this data model augments the generic 19 network and network topology data models with Layer 2 specific 20 topology attributes. 22 Editorial Note (To be removed by RFC Editor) 24 Please update these statements within the document with the RFC 25 number to be assigned to this document: 27 o "This version of this YANG module is part of RFC XXXX;" 29 o "RFC XXXX: A YANG Data Model for Layer 2 Network Topologies"; 31 o reference: RFC XXXX 33 Please update the "revision" date of the YANG module. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 13, 2021. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Layer 2 Topology Model . . . . . . . . . . . . . . . . . . . 3 71 4. Layer 2 Topology YANG Module . . . . . . . . . . . . . . . . 7 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 77 8.2. Informative References . . . . . . . . . . . . . . . . . 24 78 Appendix A. Companion YANG Module for Non-NMDA Compliant 79 Implementations . . . . . . . . . . . . . . . . . . 25 80 Appendix B. An Example . . . . . . . . . . . . . . . . . . . . . 30 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 83 1. Introduction 85 [RFC8345] defines the YANG [RFC6020] [RFC7950] data models of the 86 abstract (generic) network and network topology. Such models can be 87 augmented with technology-specific details to build more specific 88 topology models. 90 This document defines the YANG data model for Layer 2 (L2) network 91 topologies by augmenting the generic network (Section 6.1 of 92 [RFC8345]) and network topology (Section 6.2 of [RFC8345]) data 93 models with L2-specific topology attributes. An example is provided 94 in Appendix B. 96 There are multiple applications for such a data model. For example, 97 within the context of Interface to the Routing System (I2RS), nodes 98 within the network can use the data model to capture their 99 understanding of the overall network topology and expose it to a 100 network controller. A network controller can then use the 101 instantiated topology data to compare and reconcile its own view of 102 the network topology with that of the network elements that it 103 controls. Alternatively, nodes within the network may compare and 104 reconcile this understanding either among themselves or with the help 105 of a controller. Beyond the network element and the immediate 106 context of I2RS itself, a network controller might even use the data 107 model to represent its view of the topology that it controls and 108 expose it to external applications. Further use cases where the data 109 model can be applied are described in [I2RS-UR]. 111 This document uses the common YANG types defined in [RFC6991] and 112 adopts the Network Management Datastore Architecture (NMDA) 113 [RFC8342]. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 The terminology for describing YANG modules is defined in [RFC7950]. 124 The meanings of the symbols used in the tree diagram are defined in 125 [RFC8340]. 127 3. Layer 2 Topology Model 129 The Layer 2 network topology YANG module is designed to be generic 130 and applicable to Layer 2 networks built with different Layer 2 131 technologies. It can be used to describe both the physical and the 132 logical (virtual) Layer 2 network topologies. 134 The relationship between the Layer 2 topology module and the generic 135 network and network topology module is shown in Figure 1. In order 136 to represent a Layer 2 network topology, the generic network and 137 topology models are augmented with Layer 2 specific information, such 138 as the identifiers, identities (e.g., Provider Backbone Bridging 139 [IEEE802.1ah], QinQ [IEEE802.1ad], or VXLAN [RFC7348]), attributes, 140 and states of the Layer 2 networks, nodes, links, and termination 141 points. Some of the information may be collected via Link Layer 142 Discovery Protocol (LLDP) [IEEE802.1AB] or other Layer 2 protocols, 143 and some of them may be locally configured. 145 +---------------------+ 146 | ietf-network | 147 +----------^----------+ 148 | 149 | 150 +---------------------+ 151 |ietf-network-topology| 152 +----------^----------+ 153 | 154 | 155 +----------^----------+ 156 | ietf-l2-topology | 157 +---------------------+ 159 Figure 1: Layer 2 Topology YANG Module Structure 161 The structure of the "ietf-l2-topology" YANG module is depicted in 162 the following tree diagram: 164 module: ietf-l2-topology 165 augment /nw:networks/nw:network/nw:network-types: 166 +--rw l2-network! 167 augment /nw:networks/nw:network: 168 +--rw l2-topology-attributes 169 +--rw name? string 170 +--rw flags* l2-flag-type 171 augment /nw:networks/nw:network/nw:node: 172 +--rw l2-node-attributes 173 +--rw name? string 174 +--rw description? string 175 +--rw management-address* inet:ip-address 176 +--rw sys-mac-address? yang:mac-address 177 +--rw management-vlan-id? dot1q-types:vlanid {VLAN}? 178 +--rw flags* node-flag-type 179 augment /nw:networks/nw:network/nt:link: 180 +--rw l2-link-attributes 181 +--rw name? string 182 +--rw flags* link-flag-type 183 +--rw rate? uint64 184 +--rw delay? uint32 185 augment /nw:networks/nw:network/nw:node/nt:termination-point: 186 +--rw l2-termination-point-attributes 187 +--rw description? string 188 +--rw maximum-frame-size? uint32 189 +--rw (l2-termination-point-type)? 190 | +--:(ethernet) 191 | | +--rw mac-address? yang:mac-address 192 | | +--rw eth-encapsulation? identityref 193 | | +--rw lag? boolean 194 | | +--rw member-link-tp* -> /nw:networks/network 195 /node/nt:termination-point/tp-id 196 | | +--rw auto-negotiation? boolean 197 | | +--rw duplex? duplex-mode 198 | | +--rw default-untagged-vlan? dot1q-types:vlanid {VLAN}? 199 | | +--rw vlans* [vlan-id] {VLAN}? 200 | | | +--rw vlan-id dot1q-types:vlanid 201 | | | +--rw name? string 202 | | +--rw qinq* [svlan-id cvlan-id] {QinQ}? 203 | | | +--rw svlan-id dot1q-types:vlanid 204 | | | +--rw cvlan-id dot1q-types:vlanid 205 | | +--rw vxlan {VXLAN}? 206 | | +--rw vni-id? vni 207 | +--:(legacy) 208 | +--rw layer-2-address? yang:phys-address 209 | +--rw encapsulation? identityref 210 +--ro tp-state? identityref 212 notifications: 213 +---n l2-node-event 214 | +--ro event-type? l2-network-event-type 215 | +--ro node-ref? -> /nw:networks/network 216 [nw:network-id=current()/../network-ref]/node/node-id 217 | +--ro network-ref? -> /nw:networks/network/network-id 218 | +--ro l2-network! 219 | +--ro l2-node-attributes 220 | +--ro name? string 221 | +--ro description? string 222 | +--ro management-address* inet:ip-address 223 | +--ro sys-mac-address? yang:mac-address 224 | +--ro management-vlan-id? dot1q-types:vlanid {VLAN}? 225 | +--ro flags* node-flag-type 226 +---n l2-link-event 227 | +--ro event-type? l2-network-event-type 228 | +--ro link-ref? -> /nw:networks/network 229 [nw:network-id=current()/../network-ref]/nt:link/link-id 230 | +--ro network-ref? -> /nw:networks/network/network-id 231 | +--ro l2-network! 232 | +--ro l2-link-attributes 233 | +--ro name? string 234 | +--ro flags* link-flag-type 235 | +--ro rate? uint64 236 | +--ro delay? uint32 237 +---n l2-termination-point-event 238 +--ro event-type? l2-network-event-type 239 +--ro tp-ref? -> /nw:networks/network 240 [nw:network-id=current()/../network-ref]/node 242 [nw:node-id=current()/../node-ref]/nt:termination-point/tp-id 243 +--ro node-ref? -> /nw:networks/network 244 [nw:network-id=current()/../network-ref]/node/node-id 245 +--ro network-ref? -> /nw:networks/network/network-id 246 +--ro l2-network! 247 +--ro l2-termination-point-attributes 248 +--ro description? string 249 +--ro maximum-frame-size? uint32 250 +--ro (l2-termination-point-type)? 251 | +--:(ethernet) 252 | | +--ro mac-address? yang:mac-address 253 | | +--ro eth-encapsulation? identityref 254 | | +--ro lag? boolean 255 | | +--ro member-link-tp* -> /nw:networks/network 256 /node/nt:termination-point/tp-id 257 | | +--ro auto-nego? boolean 258 | | +--ro duplex? duplex-mode 259 | | +--ro default-untagged-vlan? dot1q-types:vlanid {VLAN}? 260 | | +--ro vlans* [vlan-id] {VLAN}? 261 | | | +--ro vlan-id dot1q-types:vlanid 262 | | | +--ro name? string 263 | | +--ro qinq* [svlan-id cvlan-id] {QinQ}? 264 | | | +--ro svlan-id dot1q-types:vlanid 265 | | | +--ro cvlan-id dot1q-types:vlanid 266 | | +--ro vxlan {VXLAN}? 267 | | +--ro vni-id? vni 268 | +--:(legacy) 269 | +--ro layer-2-address? yang:phys-address 270 | +--ro encapsulation? identityref 271 +--ro tp-state? identityref 273 The Layer 2 topology YANG module augments the "ietf-network" and 274 "ietf-network-topology" YANG modules as follows: 276 o A new network type "l2-network-type" is introduced. This is 277 represented by a container object, and is inserted under the 278 "network-types" container of the generic "ietf-network" module 279 defined in Section 6.1 of [RFC8345]. 281 o Additional network attributes are introduced in a grouping "l2- 282 network-attributes", which augments the "network" list of the 283 "ietf-network" module. The attributes include Layer 2 network 284 name and a set of flags. Each type of flag is represented by a 285 separate identity. 287 o Additional data objects for Layer 2 nodes are introduced by 288 augmenting the "node" list of the generic "ietf-network" module. 290 New objects include Layer 2 node identifier, description, 291 management address, and a set of flags. 293 o Additional data objects for Layer 2 termination points are 294 introduced by augmenting the "termination-point" list of the 295 "ietf-network-topology" module defined in Section 6.2 of 296 [RFC8345]. New objects include Layer 2 termination point 297 descriptions, Layer 2 termination point type specific attributes 298 and Layer 2 termination point states. 300 o Links in the "ietf-network-topology" module are augmented as well 301 with a set of Layer 2 parameters, allowing to associate a link 302 with a name, a set of Layer 2 link attributes, and flags. 304 o Some optional Layer 2 technology specific attributes are 305 introduced in this module as Layer 2 features because these 306 attributes may be useful to expose to above services/applications. 307 Note that learning or configuring advanced Layer 2 technology- 308 specific attributes is not within the scope of the Layer 2 309 Topology YANG module; dedicated YANG modules should be used 310 instead (e.g., [I-D.ietf-trill-yang]). 312 4. Layer 2 Topology YANG Module 314 This module uses types defined in [RFC6991], [RFC7224], 315 [IEEE802.1Qcp], and [RFC8345]. It also references [RFC4761], 316 [RFC4762], and [RFC4202]. 318 file "ietf-l2-topology@2020-06-29.yang" 319 module ietf-l2-topology { 320 yang-version 1.1; 321 namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology"; 322 prefix l2t; 324 import ietf-network { 325 prefix nw; 326 reference 327 "RFC 8345: A YANG Data Model for Network Topologies"; 328 } 329 import ietf-network-topology { 330 prefix nt; 331 reference 332 "RFC 8345: A YANG Data Model for Network Topologies"; 333 } 334 import ietf-inet-types { 335 prefix inet; 336 reference 337 "RFC 6991:Common YANG Data Types"; 339 } 340 import ietf-yang-types { 341 prefix yang; 342 reference 343 "RFC 6991:Common YANG Data Types"; 344 } 345 import iana-if-type { 346 prefix ift; 347 reference 348 "RFC 7224: IANA Interface Type YANG Module"; 349 } 350 import ieee802-dot1q-types { 351 prefix dot1q-types; 352 reference 353 "IEEE Std 802.1Qcp-2018: Bridges and Bridged 354 Networks - Amendment: YANG Data Model"; 355 } 357 organization 358 "IETF I2RS (Interface to the Routing System) Working Group"; 359 contact 360 "WG Web: 361 WG List: 363 Editor: Jie Dong 364 366 Editor: Xiugang Wei 367 369 Editor: Qin Wu 370 372 Editor: Mohamed Boucadair 373 375 Editor: Anders Liu 376 "; 377 description 378 "This module defines a basic model for the Layer 2 topology 379 of a network. 381 Copyright (c) 2020 IETF Trust and the persons identified as 382 authors of the code. All rights reserved. 384 Redistribution and use in source and binary forms, with or 385 without modification, is permitted pursuant to, and subject 386 to the license terms contained in, the Simplified BSD License 387 set forth in Section 4.c of the IETF Trust's Legal Provisions 388 Relating to IETF Documents 389 (http://trustee.ietf.org/license-info). 391 This version of this YANG module is part of RFC XXXX; see 392 the RFC itself for full legal notices."; 394 revision 2020-06-29 { 395 description 396 "Initial revision"; 397 reference 398 "RFC XXXX: A YANG Data Model for Layer 2 399 Network Topologies"; 400 } 402 feature VLAN { 403 description 404 "Enables VLAN tag support as defined in IEEE 802.1Q."; 405 reference 406 "IEEE Std 802.1Q-2014: Bridges and Bridged Networks"; 407 } 409 feature QinQ { 410 description 411 "Enables QinQ double tag support as defined in IEEE 802.1ad."; 412 reference 413 "IEEE Std 802.1ad: Provider Bridges"; 414 } 416 feature VXLAN { 417 description 418 "Enables VXLAN support as defined in RFC7348."; 419 reference 420 "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): 421 A Framework for Overlaying Virtualized Layer 2 422 Networks over Layer 3 Networks"; 423 } 425 identity flag-identity { 426 description 427 "Base type for flags."; 428 } 430 identity eth-encapsulation-type { 431 base ift:iana-interface-type; 432 description 433 "Base identity from which specific Ethernet 434 encapsulation types are derived."; 436 reference 437 "RFC 7224: IANA Interface Type YANG Module"; 438 } 440 identity ethernet { 441 base eth-encapsulation-type; 442 description 443 "Native Ethernet encapsulation."; 444 } 446 identity vlan { 447 base eth-encapsulation-type; 448 description 449 "VLAN encapsulation."; 450 } 452 identity qinq { 453 base eth-encapsulation-type; 454 description 455 "QinQ encapsulation."; 456 } 458 identity pbb { 459 base eth-encapsulation-type; 460 description 461 "Provider-backbone-bridging (PBB) encapsulation. 462 The PBB functions are developed in IEEE 802.1ah."; 463 } 465 identity trill { 466 base eth-encapsulation-type; 467 description 468 "TRILL encapsulation."; 469 } 471 identity vpls { 472 base eth-encapsulation-type; 473 description 474 "Ethernet VPLS interface encapsulation."; 475 } 477 identity vxlan { 478 base eth-encapsulation-type; 479 description 480 "VXLAN MAC in UDP encapsulation."; 481 reference 482 "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): 483 A Framework for Overlaying Virtualized Layer 2 484 Networks over Layer 3 Networks"; 485 } 487 identity tp-state-type { 488 description 489 "Base type for termination point state."; 490 } 492 identity inuse { 493 base tp-state-type; 494 description 495 "The termination point is in forwarding state."; 496 } 498 identity blocking { 499 base tp-state-type; 500 description 501 "The termination point is in blocking state."; 502 } 504 identity down { 505 base tp-state-type; 506 description 507 "The termination point is in down state."; 508 } 510 identity unknown { 511 base tp-state-type; 512 description 513 "The termination point is in unknown state."; 514 } 516 typedef vni { 517 type uint32 { 518 range "0..16777215"; 519 } 520 description 521 "VXLAN Network Identifier or VXLAN Segment ID. 522 It allows up to 16 M VXLAN segments to coexist 523 within the same administrative domain. 525 The use of value '0' is implementation-specific."; 526 reference 527 "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): 528 A Framework for Overlaying Virtualized Layer 2 529 Networks over Layer 3 Networks"; 530 } 531 typedef l2-flag-type { 532 type identityref { 533 base flag-identity; 534 } 535 description 536 "Base type for L2 flags. One example of L2 flag 537 type is trill which represents trill topology 538 type."; 539 } 541 typedef node-flag-type { 542 type identityref { 543 base flag-identity; 544 } 545 description 546 "Node flag attributes. The physical node can be 547 one example of node flag attribute."; 548 } 550 typedef link-flag-type { 551 type identityref { 552 base flag-identity; 553 } 554 description 555 "Link flag attributes. One example of link flag 556 attribute is the pseudowire."; 557 } 559 typedef l2-network-event-type { 560 type enumeration { 561 enum addition { 562 value 0; 563 description 564 "A Layer 2 node or link or termination-point 565 has been added."; 566 } 567 enum removal { 568 value 1; 569 description 570 "A Layer 2 node or link or termination-point 571 has been removed."; 572 } 573 enum update { 574 value 2; 575 description 576 "A Layer 2 node or link or termination-point 577 has been updated."; 578 } 580 } 581 description 582 "Layer 2 network event type for notifications."; 583 } 585 typedef duplex-mode { 586 type enumeration { 587 enum full-duplex { 588 description 589 "Indicates full-duplex mode."; 590 } 591 enum half-duplex { 592 description 593 "Indicates half-duplex mode."; 594 } 595 } 596 description 597 "Indicates the type of the duplex mode."; 598 } 600 grouping l2-network-type { 601 description 602 "Indicates the topology type to be L2."; 603 container l2-network { 604 presence "Indicates L2 Network"; 605 description 606 "The presence of the container node indicates 607 L2 Topology."; 608 } 609 } 611 grouping l2-topology-attributes { 612 description 613 "L2 Topology scope attributes."; 614 container l2-topology-attributes { 615 description 616 "Contains L2 topology attributes."; 617 leaf name { 618 type string; 619 description 620 "Name of the topology."; 621 } 622 leaf-list flags { 623 type l2-flag-type; 624 description 625 "Topology flags."; 626 } 627 } 629 } 631 grouping l2-node-attributes { 632 description 633 "L2 node attributes"; 634 container l2-node-attributes { 635 description 636 "Contains L2 node attributes."; 637 leaf name { 638 type string; 639 description 640 "Node name."; 641 } 642 leaf description { 643 type string; 644 description 645 "Node description."; 646 } 647 leaf-list management-address { 648 type inet:ip-address; 649 description 650 "IP address used for 651 management purpose."; 652 } 653 leaf sys-mac-address { 654 type yang:mac-address; 655 description 656 "MAC address used to identify layer 2 node. 657 This MAC address can be used as interface 658 MAC address."; 659 } 660 leaf management-vlan-id { 661 if-feature "VLAN"; 662 type dot1q-types:vlanid; 663 description 664 "VLAN ID used for management 665 purpose."; 666 } 667 leaf-list flags { 668 type node-flag-type; 669 description 670 "Node flags. It can be used to indicates 671 node flag attributes."; 672 } 673 } 674 } 676 grouping l2-link-attributes { 677 description 678 "L2 link attributes"; 679 container l2-link-attributes { 680 description 681 "Contains L2 link attributes."; 682 leaf name { 683 type string; 684 description 685 "Link name."; 686 } 687 leaf-list flags { 688 type link-flag-type; 689 description 690 "Link flags. It can be used to indicate 691 link flag attributes."; 692 } 693 leaf rate { 694 type uint64; 695 units "Kbps"; 696 description 697 "Link rate. It specifies bandwidth requirements 698 associated with the specific link. The link 699 contains a source and a destination."; 700 } 701 leaf delay { 702 type uint32; 703 units "microseconds"; 704 description 705 "Unidirectional Link delay in 706 microseconds."; 707 } 708 } 709 } 711 grouping l2-termination-point-attributes { 712 description 713 "L2 termination point attributes"; 714 container l2-termination-point-attributes { 715 description 716 "Containing L2 termination point attributes."; 717 leaf description { 718 type string; 719 description 720 "L2 termination point description. It also 721 can be seen as port description."; 722 } 723 leaf maximum-frame-size { 724 type uint32; 725 description 726 "Maximum L2 frame size that can be transported on 727 the data link layer, e.g. Ethernet frame. 728 If L2 frame is an Ethernet frame, the maximum frame size 729 should include Frame Check Sequence(FCS) and should not 730 include preamble,Start Frame Delimiter and Inter frame 731 gap."; 732 } 733 choice l2-termination-point-type { 734 description 735 "Indicates termination-point type 736 specific attributes."; 737 case ethernet { 738 leaf mac-address { 739 type yang:mac-address; 740 description 741 "Interface MAC address."; 742 } 743 leaf eth-encapsulation { 744 type identityref { 745 base eth-encapsulation-type; 746 } 747 description 748 "Encapsulation type of this 749 termination point."; 750 } 751 leaf lag { 752 type boolean; 753 default "false"; 754 description 755 "Defines whether lag is enabled or disabled. 756 When it is set to true, the lag is enabled."; 757 } 758 leaf-list member-link-tp { 759 when "../lag = 'true'" { 760 description 761 "Relevant only when the lag interface is enabled."; 762 } 763 type leafref { 764 path "/nw:networks/nw:network/nw:node/nt:termination-point/nt:tp-id"; 765 } 766 description 767 "Member link termination points."; 768 } 769 leaf auto-nego { 770 type boolean; 771 default "true"; 772 description 773 "Set to true if auto negotiation is supported. 774 Set to false if auto negotiation is not supported."; 775 } 776 leaf duplex { 777 type duplex-mode; 778 description 779 "Expose the duplex mode, full duplex or half-duplex."; 780 } 781 leaf default-untagged-vlan { 782 when "derived-from-or-self(../eth-encapsulation, 'l2t:vlan')" { 783 description 784 "Only applies when the type of the Ethernet 785 encapsulation is 'vlan'."; 786 } 787 if-feature "VLAN"; 788 type dot1q-types:vlanid; 789 description 790 "Port VLAN ID is the VLAN identifier that 791 will be assigned to any untagged frames entering 792 the switch on the specific port."; 793 } 794 list vlans { 795 when "derived-from-or-self(../eth-encapsulation, 'l2t:vlan')" { 796 description 797 "Only applies when the type of the Ethernet 798 encapsulation is 'vlan'."; 799 } 800 if-feature "VLAN"; 801 key "vlan-id"; 802 description 803 "Interface configured VLANs."; 804 leaf vlan-id { 805 type dot1q-types:vlanid; 806 description 807 "VLAN ID."; 808 } 809 leaf name { 810 type string { 811 length "1..31"; 812 } 813 description 814 "VLAN name."; 815 } 816 } 817 list qinq { 818 when "derived-from-or-self(../eth-encapsulation, 'l2t:qinq')" { 819 description 820 "Only applies when the type of the Ethernet 821 encapsulation is 'qinq'."; 822 } 823 if-feature "QinQ"; 824 key "svlan-id cvlan-id"; 825 description 826 "Interface configured SVLANs and CVLANs."; 827 leaf svlan-id { 828 type dot1q-types:vlanid; 829 description 830 "Service VLAN ID."; 831 } 832 leaf cvlan-id { 833 type dot1q-types:vlanid; 834 description 835 "Customer VLAN ID."; 836 } 837 } 838 container vxlan { 839 when "derived-from-or-self(../eth-encapsulation, 'l2t:vxlan')" { 840 description 841 "Only applies when the type of the Ethernet 842 encapsulation is 'vxlan'."; 843 } 844 if-feature "VXLAN"; 845 leaf vni-id { 846 type vni; 847 description 848 "VXLAN Network Identifier (VNI)."; 849 } 850 description 851 "Vxlan encapsulation type."; 852 } 853 } 854 case legacy { 855 leaf layer-2-address { 856 type yang:phys-address; 857 description 858 "Interface Layer 2 address."; 859 } 860 leaf encapsulation { 861 type identityref { 862 base ift:iana-interface-type; 863 } 864 description 865 "Other legacy encapsulation type of this 866 termination point."; 867 } 868 } 870 } 871 leaf tp-state { 872 type identityref { 873 base tp-state-type; 874 } 875 config false; 876 description 877 "State of the termination point."; 878 } 879 } 880 } 882 augment "/nw:networks/nw:network/nw:network-types" { 883 description 884 "Introduces new network type for L2 topology."; 885 uses l2-network-type; 886 } 887 augment "/nw:networks/nw:network" { 888 when '/nw:networks/nw:network/nw:network-types/l2t:l2-network' { 889 description 890 "Augmentation parameters apply only for networks 891 with L2 topology."; 892 } 893 description 894 "Configuration parameters for the L2 network 895 as a whole."; 896 uses l2-topology-attributes; 897 } 898 augment "/nw:networks/nw:network/nw:node" { 899 when '/nw:networks/nw:network/nw:network-types/l2t:l2-network' { 900 description 901 "Augmentation parameters apply only for networks 902 with L2 topology."; 903 } 904 description 905 "Configuration parameters for L2 at the node 906 level."; 907 uses l2-node-attributes; 908 } 909 augment "/nw:networks/nw:network/nt:link" { 910 when '/nw:networks/nw:network/nw:network-types/l2t:l2-network' { 911 description 912 "Augmentation parameters apply only for networks 913 with L2 topology."; 914 } 915 description 916 "Augments L2 topology link information."; 917 uses l2-link-attributes; 919 } 920 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 921 when '/nw:networks/nw:network/nw:network-types/l2t:l2-network' { 922 description 923 "Augmentation parameters apply only for networks 924 with L2 topology."; 925 } 926 description 927 "Augments L2 topology termination point information."; 928 uses l2-termination-point-attributes; 929 } 931 notification l2-node-event { 932 description 933 "Notification event for L2 node."; 934 leaf event-type { 935 type l2-network-event-type; 936 description 937 "Event type."; 938 } 939 uses nw:node-ref; 940 uses l2-network-type; 941 uses l2-node-attributes; 942 } 944 notification l2-link-event { 945 description 946 "Notification event for L2 link."; 947 leaf event-type { 948 type l2-network-event-type; 949 description 950 "Event type."; 951 } 952 uses nt:link-ref; 953 uses l2-network-type; 954 uses l2-link-attributes; 955 } 957 notification l2-termination-point-event { 958 description 959 "Notification event for L2 termination point."; 960 leaf event-type { 961 type l2-network-event-type; 962 description 963 "Event type."; 964 } 965 uses nt:tp-ref; 966 uses l2-network-type; 967 uses l2-termination-point-attributes; 968 } 969 } 971 973 5. IANA Considerations 975 This document requests IANA to register the following URIs in the 976 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 978 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology 979 Registrant Contact: The IESG. 980 XML: N/A; the requested URI is an XML namespace. 982 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 983 Registrant Contact: The IESG. 984 XML: N/A; the requested URI is an XML namespace. 986 This document requests IANA to register the following YANG modules in 987 the "YANG Module Names" subregistry [RFC6020] within the "YANG 988 Parameters" registry. 990 name: ietf-l2-topology 991 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology 992 prefix: l2t 993 reference: RFC XXXX 995 name: ietf-l2-topology-state 996 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 997 prefix: l2t-s 998 reference: RFC XXXX 1000 These modules are not maintained by IANA. 1002 6. Security Considerations 1004 The YANG module specified in this document defines a schema for data 1005 that is designed to be accessed via network management protocols such 1006 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1007 is the secure transport layer, and the mandatory-to-implement secure 1008 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1009 is HTTPS, and the mandatory-to-implement secure transport is TLS 1010 [RFC8446]. 1012 The Network Configuration Access Control Model (NACM) [RFC8341] 1013 provides the means to restrict access for particular NETCONF or 1014 RESTCONF users to a preconfigured subset of all available NETCONF or 1015 RESTCONF protocol operations and content. 1017 The Layer 2 topology module defines information that can be 1018 configurable in certain instances, for example in the case of virtual 1019 topologies that can be created by client applications. In such 1020 cases, a malicious client could introduce topologies that are 1021 undesired. Specifically, a malicious client could attempt to remove 1022 or add a node, a link, a termination point, by creating or deleting 1023 corresponding elements in the node, link, and termination point 1024 lists, respectively. In the case of a topology that is learned, the 1025 server will automatically prohibit such misconfiguration attempts. 1026 In the case of a topology that is configured, i.e. whose origin is 1027 "intended", the undesired configuration could become effective and be 1028 reflected in the operational state datastore [RFC8342], leading to 1029 disruption of services provided via this topology. For those 1030 reasons, it is important that the NACM is vigorously applied to 1031 prevent topology misconfiguration by unauthorized clients. 1033 There are a number of data nodes defined in this YANG module that are 1034 writable/creatable/deletable (i.e., config true, which is the 1035 default). These data nodes may be considered sensitive or vulnerable 1036 in some network environments. Write operations (e.g., edit-config) 1037 to these data nodes without proper protection can have a negative 1038 effect on network operations. These are the subtrees and data nodes 1039 and their sensitivity/vulnerability: 1041 o l2-network-attributes: A malicious client could attempt to 1042 sabotage the configuration of any of the contained attributes, 1043 such as the name or the flag data nodes. 1045 o l2-node-attributes: A malicious client could attempt to sabotage 1046 the configuration of important node attributes, such as the name 1047 or the management-address. 1049 o l2-link-attributes: A malicious client could attempt to sabotage 1050 the configuration of important link attributes, such as the rate 1051 or the delay data nodes. 1053 o l2-termination-point-attributes: A malicious client could attempt 1054 to sabotage the configuration of important termination point 1055 attributes (e.g., 'maximum-frame-size'). 1057 Some of the readable data nodes in this YANG module may be considered 1058 sensitive or vulnerable in some network environments. It is thus 1059 important to control read access (e.g., via get, get-config, or 1060 notification) to these data nodes. In particular, the YANG model for 1061 layer 2 topology may expose sensitive information, for example the 1062 MAC addresses of devices, VLAN/VXLAN identifiers. Unrestricted use 1063 of such information can lead to privacy violations. For example, 1064 listing MAC addresses in a network allows monitoring of devices and 1065 their movements. Location information can be derived from MAC 1066 addresses of network devices, bypassing protection of location 1067 information by the Operating System. 1069 7. Acknowledgements 1071 The authors would like to acknowledge the comments and suggestions 1072 received from Susan Hares, Alia Atlas, Juergen Schoenwaelder, Mach 1073 Chen, Alexander Clemm, Sriganesh Kini, Oscar Gonzalez de Dios, Stig 1074 Venaas, Christian Huitema, and Meral Shirazipour,Benjamin Kaduk. 1076 Many thanks to Ladislav Lhotka for the yang-doctors review. 1078 8. References 1080 8.1. Normative References 1082 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1083 Requirement Levels", BCP 14, RFC 2119, 1084 DOI 10.17487/RFC2119, March 1997, 1085 . 1087 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 1088 in Support of Generalized Multi-Protocol Label Switching 1089 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 1090 . 1092 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1093 LAN Service (VPLS) Using BGP for Auto-Discovery and 1094 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1095 . 1097 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1098 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1099 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1100 . 1102 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1103 the Network Configuration Protocol (NETCONF)", RFC 6020, 1104 DOI 10.17487/RFC6020, October 2010, 1105 . 1107 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1108 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1109 . 1111 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1112 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1113 . 1115 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1116 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1117 eXtensible Local Area Network (VXLAN): A Framework for 1118 Overlaying Virtualized Layer 2 Networks over Layer 3 1119 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1120 . 1122 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1123 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1124 . 1126 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1127 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1128 May 2017, . 1130 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1131 Access Control Model", STD 91, RFC 8341, 1132 DOI 10.17487/RFC8341, March 2018, 1133 . 1135 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1136 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1137 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1138 2018, . 1140 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1141 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1142 . 1144 8.2. Informative References 1146 [I-D.ietf-trill-yang] 1147 Weiguo, H., Yizhou, L., Kumar, D., Durrani, M., Zhai, H., 1148 and L. Xia, "TRILL YANG Data Model", draft-ietf-trill- 1149 yang-04 (work in progress), December 2015. 1151 [I2RS-UR] Hares, S. and M. Chen, "Summary of I2RS Use Case 1152 Requirements", draft-ietf-i2rs-usecase-reqs-summary-03 1153 (work in progress), November 2016. 1155 [IEEE802.1AB] 1156 "Station and Media Access Control Connectivity Discovery", 1157 IEEE Std 802.1AB-2016, March 2016. 1159 [IEEE802.1ad] 1160 "Virtual Bridged Local Area Networks Amendment 4: Provider 1161 Bridges", IEEE Std 802.1ad-2005, May 2006. 1163 [IEEE802.1ah] 1164 "Virtual Bridged Local Area Networks Amendment 4: Provider 1165 Bridges", IEEE Std 802.1ah-2008, August 2008. 1167 [IEEE802.1Qcp] 1168 "Bridges and Bridged Networks - Amendment: YANG Data 1169 Model", IEEE Std 802.1Qcp-2018, September 2018. 1171 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1172 DOI 10.17487/RFC3688, January 2004, 1173 . 1175 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1176 and A. Bierman, Ed., "Network Configuration Protocol 1177 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1178 . 1180 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1181 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1182 . 1184 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1185 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1186 . 1188 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1189 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1190 . 1192 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1193 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1194 . 1196 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1197 and R. Wilton, "Network Management Datastore Architecture 1198 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1199 . 1201 Appendix A. Companion YANG Module for Non-NMDA Compliant 1202 Implementations 1204 The YANG module ietf-l2-topology defined in this document augments 1205 two modules, "ietf-network" and "ietf-network-topology", that are 1206 designed to be used in conjunction with implementations that support 1207 the Network Management Datastore Architecture (NMDA) defined in 1208 [RFC8342]. In order to allow implementations to use the model even 1209 in cases when NMDA is not supported, a set of companion modules have 1210 been defined that represent a state model of networks and network 1211 topologies, "ietf-network-state" and "ietf-network-topology-state", 1212 respectively. 1214 In order to be able to use the model for layer 2 topologies defined 1215 in this document in conjunction with non-NMDA compliant 1216 implementations, a corresponding companion module is defined that 1217 represents the operational state of layer 2 network topologies. The 1218 module "ietf-l2-topology-state" mirrors the module "ietf-l2-topology" 1219 defined in Section 4. However, it augments "ietf-network-state" and 1220 "ietf-network-topology-state" (instead of "ietf-network" and "ietf- 1221 network-topology") and all its data nodes are non-configurable. 1223 The companion module "ietf-l2-topology" SHOULD NOT be supported by 1224 implementations that support NMDA. It is for this reason that this 1225 module is defined in the informative Appendix. 1227 As the structure of this modules mirrors that of its underlying 1228 modules, the YANG tree is not depicted separately. 1230 file "ietf-l2-topology-state@2020-06-29.yang" 1231 module ietf-l2-topology-state { 1232 yang-version 1.1; 1233 namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology-state"; 1234 prefix l2t-s; 1236 import ietf-network-state { 1237 prefix nw-s; 1238 reference 1239 "RFC 8345: A YANG Data Model for Network Topologies"; 1240 } 1241 import ietf-network-topology-state { 1242 prefix nt-s; 1243 reference 1244 "RFC 8345: A YANG Data Model for Network Topologies"; 1245 } 1246 import ietf-l2-topology { 1247 prefix l2t; 1248 reference 1249 "RFC XXXX: A YANG Data Model for Layer 2 Network 1250 Topologies"; 1251 } 1253 organization 1254 "IETF I2RS (Interface to the Routing System) Working Group"; 1256 contact 1257 "WG Web: 1258 WG List: 1260 Editor: Jie Dong 1261 1262 Editor: Xiugang Wei 1263 1264 Editor: Qin Wu 1265 1266 Editor: Mohamed Boucadair 1267 1268 Editor: Anders Liu 1269 "; 1270 description 1271 "This module defines a model for Layer 2 Network Topology 1272 state, representing topology that either is learned or 1273 results from applying topology that has been configured per 1274 the 'ietf-l2-topology' model, mirroring the 1275 corresponding data nodes in this model. 1277 This model mirrors 'ietf-l2-topology' but contains only 1278 read-only state data. The model is not needed when the 1279 underlying implementation infrastructure supports the 1280 Network Management Datastore Architecture (NMDA). 1282 Copyright (c) 2020 IETF Trust and the persons identified as 1283 authors of the code. All rights reserved. 1285 Redistribution and use in source and binary forms, with or 1286 without modification, is permitted pursuant to, and subject 1287 to the license terms contained in, the Simplified BSD License 1288 set forth in Section 4.c of the IETF Trust's Legal Provisions 1289 Relating to IETF Documents 1290 (http://trustee.ietf.org/license-info). 1292 This version of this YANG module is part of RFC XXXX; see 1293 the RFC itself for full legal notices."; 1295 revision 2020-06-29 { 1296 description 1297 "Initial revision"; 1298 reference 1299 "RFC XXXX: A YANG Data Model for Layer 2 Network 1300 Topologies"; 1301 } 1303 /* 1304 * Data nodes 1305 */ 1307 augment "/nw-s:networks/nw-s:network/nw-s:network-types" { 1308 description 1309 "Introduces a new network type for L2 topology."; 1310 uses l2t:l2-network-type; 1311 } 1313 augment "/nw-s:networks/nw-s:network" { 1314 when '/nw-s:networks/nw-s:network/nw-s:network-types/' 1315 + 'l2t-s:l2-network' { 1316 description 1317 "Augmentation parameters apply only for networks 1318 with L2 topology."; 1319 } 1320 description 1321 "Configuration parameters for the L2 network 1322 as a whole."; 1323 uses l2t:l2-network-attributes; 1324 } 1326 augment "/nw-s:networks/nw-s:network/nw-s:node" { 1327 when '../nw-s:network-types/l2t-s:l2-network' { 1328 description 1329 "Augmentation parameters apply only for networks 1330 with L2 topology."; 1331 } 1332 description 1333 "Configuration parameters for L2 at the node 1334 level."; 1335 uses l2t:l2-node-attributes; 1336 } 1338 augment "/nw-s:networks/nw-s:network/nt-s:link" { 1339 when '../nw-s:network-types/l2t-s:l2-network' { 1340 description 1341 "Augmentation parameters apply only for networks 1342 with L2 topology."; 1343 } 1344 description 1345 "Augments L2 topology link information."; 1346 uses l2t:l2-link-attributes; 1347 } 1349 augment "/nw-s:networks/nw-s:network/nw-s:node/" 1350 + "nt-s:termination-point" { 1351 when '../../nw-s:network-types/l2t-s:l2-network' { 1352 description 1353 "Augmentation parameters apply only for networks 1354 with L2 topology."; 1355 } 1356 description 1357 "Augments L2 topology termination point information."; 1358 uses l2t:l2-termination-point-attributes; 1359 } 1361 /* 1362 * Notifications 1363 */ 1365 notification l2-node-event { 1366 description 1367 "Notification event for L2 node."; 1368 leaf event-type { 1369 type l2t:l2-network-event-type; 1370 description 1371 "Event type."; 1372 } 1373 uses nw-s:node-ref; 1374 uses l2t:l2-network-type; 1375 uses l2t:l2-node-attributes; 1376 } 1378 notification l2-link-event { 1379 description 1380 "Notification event for a L2 link."; 1381 leaf event-type { 1382 type l2t:l2-network-event-type; 1383 description 1384 "Event type."; 1385 } 1386 uses nt-s:link-ref; 1387 uses l2t:l2-network-type; 1388 uses l2t:l2-link-attributes; 1389 } 1391 notification l2-termination-point-event { 1392 description 1393 "Notification event for L2 termination point."; 1394 leaf event-type { 1395 type l2t:l2-network-event-type; 1396 description 1397 "Event type."; 1398 } 1399 uses nt-s:tp-ref; 1400 uses l2t:l2-network-type; 1401 uses l2t:l2-termination-point-attributes; 1402 } 1403 } 1404 1406 Appendix B. An Example 1408 This section contains an example of an instance data tree in JSON 1409 encoding [RFC7951]. The example instantiates "ietf-l2-topology" for 1410 the topology that is depicted in the following diagram. There are 1411 three nodes: D1, D2, and D3. D1 has three termination points: 1-0-1, 1412 1-2-1, and 1-3-1. D2 has three termination points as well: 2-1-1, 1413 2-0-1, and 2-3-1. D3 has two termination points: 3-1-1 and 3-2-1. 1414 In addition, there are six links, two between each pair of nodes, 1415 with one going in each direction. 1417 +------------+ +------------+ 1418 | D1 | | D2 | 1419 /-\ /-\ /-\ /-\ 1420 | | 1-0-1 | |---------------->| | 2-1-1 | | 1421 | | 1-2-1 | |<----------------| | 2-0-1 | | 1422 \-/ 1-3-1 \-/ \-/ 2-3-1 \-/ 1423 | /----\ | | /----\ | 1424 +---| |---+ +---| |---+ 1425 \----/ \----/ 1426 A | A | 1427 | | | | 1428 | | | | 1429 | | +------------+ | | 1430 | | | D3 | | | 1431 | | /-\ /-\ | | 1432 | +----->| | 3-1-1 | |-------+ | 1433 +---------| | 3-2-1 | |<---------+ 1434 \-/ \-/ 1435 | | 1436 +------------+ 1438 Figure 2. A Network Topology Example 1440 The corresponding instance data tree is depicted below: 1442 { 1443 "ietf-network:networks": { 1444 "network": [ 1445 { 1446 "network-types": { 1447 "ietf-l2-topology:l2-network": {} 1449 }, 1450 "network-id": "l2-topo-example", 1451 "node": [ 1452 { 1453 "node-id": "D1", 1454 "ietf-network-topology:termination-point": [ 1455 { 1456 "tp-id": "1-0-1", 1457 "ietf-l2-topology:l2-termination-point-attributes": { 1458 "mac-address": "00:00:5E:00:53:D0" 1459 } 1460 }, 1461 { 1462 "tp-id": "1-2-1", 1463 "ietf-l2-topology:l2-termination-point-attributes": { 1464 "mac-address": "00:00:5E:00:53:D1" 1465 } 1466 }, 1467 { 1468 "tp-id": "1-3-1", 1469 "ietf-l2-topology:l2-termination-point-attributes": { 1470 "mac-address": "00:00:5E:00:53:D2" 1471 } 1472 } 1473 ], 1474 "ietf-l2-topology:l2-node-attributes": { 1475 "management-address": [ 1476 "192.0.2.1", 1477 "2001:db8:0:1::/64" 1478 ] 1479 } 1480 }, 1481 { 1482 "node-id": "D2", 1483 "ietf-network-topology:termination-point": [ 1484 { 1485 "tp-id": "2-0-1", 1486 "ietf-l2-topology:l2-termination-point-attributes": { 1487 "mac-address": "00:00:5E:00:53:E0" 1488 } 1489 }, 1490 { 1491 "tp-id": "2-1-1", 1492 "ietf-l2-topology:l2-termination-point-attributes": { 1493 "mac-address": "00:00:5E:00:53:E1" 1494 } 1495 }, 1496 { 1497 "tp-id": "2-3-1", 1498 "ietf-l2-topology:l2-termination-point-attributes": { 1499 "mac-address": "00:00:5E:00:53:E2" 1500 } 1501 } 1502 ], 1503 "ietf-l2-topology:l2-node-attributes": { 1504 "management-address": [ 1505 "192.0.2.2", 1506 "2001:db8:0:2::/64" 1507 ] 1508 } 1509 }, 1510 { 1511 "node-id": "D3", 1512 "ietf-network-topology:termination-point": [ 1513 { 1514 "tp-id": "3-1-1", 1515 "ietf-l2-topology:l2-termination-point-attributes": { 1516 "mac-address": "00:00:5E:00:53:F0" 1517 } 1518 }, 1519 { 1520 "tp-id": "3-2-1", 1521 "ietf-l2-topology:l2-termination-point-attributes": { 1522 "mac-address": "00:00:5E:00:53:F1" 1523 } 1524 } 1525 ], 1526 "ietf-l2-topology:l2-node-attributes": { 1527 "management-address": [ 1528 "192.0.2.3", 1529 "2001:db8:0:3::/64" 1530 ] 1531 } 1532 } 1533 ], 1534 "ietf-network-topology:link": [ 1535 { 1536 "link-id": "D1,1-2-1,D2,2-1-1", 1537 "source": { 1538 "source-node": "D1", 1539 "source-tp": "1-2-1" 1540 }, 1541 "destination": { 1542 "dest-node": "D2", 1543 "dest-tp": "2-1-1" 1544 }, 1545 "ietf-l2-topology:l2-link-attributes": { 1546 "rate": "1000" 1547 } 1548 }, 1549 { 1550 "link-id": "D2,2-1-1,D1,1-2-1", 1551 "source": { 1552 "source-node": "D2", 1553 "source-tp": "2-1-1" 1554 }, 1555 "destination": { 1556 "dest-node": "D1", 1557 "dest-tp": "1-2-1" 1558 }, 1559 "ietf-l2-topology:l2-link-attributes": { 1560 "rate": "1000" 1561 } 1562 }, 1563 { 1564 "link-id": "D1,1-3-1,D3,3-1-1", 1565 "source": { 1566 "source-node": "D1", 1567 "source-tp": "1-3-1" 1568 }, 1569 "destination": { 1570 "dest-node": "D3", 1571 "dest-tp": "3-1-1" 1572 }, 1573 "ietf-l2-topology:l2-link-attributes": { 1574 "rate": "1000" 1575 } 1576 }, 1577 { 1578 "link-id": "D3,3-1-1,D1,1-3-1", 1579 "source": { 1580 "source-node": "D3", 1581 "source-tp": "3-1-1" 1582 }, 1583 "destination": { 1584 "dest-node": "D1", 1585 "dest-tp": "1-3-1" 1586 }, 1587 "ietf-l2-topology:l2-link-attributes": { 1588 "rate": "1000" 1589 } 1590 }, 1591 { 1592 "link-id": "D2,2-3-1,D3,3-2-1", 1593 "source": { 1594 "source-node": "D2", 1595 "source-tp": "2-3-1" 1596 }, 1597 "destination": { 1598 "dest-node": "D3", 1599 "dest-tp": "3-2-1" 1600 }, 1601 "ietf-l2-topology:l2-link-attributes": { 1602 "rate": "1000" 1603 } 1604 }, 1605 { 1606 "link-id": "D3,3-2-1,D2,2-3-1", 1607 "source": { 1608 "source-node": "D3", 1609 "source-tp": "3-2-1" 1610 }, 1611 "destination": { 1612 "dest-node": "D2", 1613 "dest-tp": "2-3-1" 1614 }, 1615 "ietf-l2-topology:l2-link-attributes": { 1616 "rate": "1000" 1617 } 1618 } 1619 ] 1620 } 1621 ] 1622 } 1623 } 1625 Authors' Addresses 1627 Jie Dong 1628 Huawei 1629 Huawei Campus, No. 156 Beiqing Rd. 1630 Beijing 100095 1631 China 1633 Email: jie.dong@huawei.com 1634 Xiugang Wei 1635 Huawei 1636 Huawei Campus, No. 156 Beiqing Rd. 1637 Beijing 100095 1638 China 1640 Email: weixiugang@huawei.com 1642 Qin Wu 1643 Huawei 1644 101 Software Avenue, Yuhua District 1645 Nanjing 210012 1646 China 1648 Email: bill.wu@huawei.com 1650 Mohamed Boucadair 1651 Orange 1652 Rennes 35000 1653 France 1655 Email: mohamed.boucadair@orange.com 1657 Anders Liu 1658 Tecent 1659 Yinke Building 38 Haidian St, Haidian District 1660 Beijing 100080 1661 China 1663 Email: andersliu@tencent.com