idnits 2.17.1 draft-ietf-i2rs-yang-l2-network-topology-18.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 11 instances of too long lines in the document, the longest one being 23 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2020) is 1323 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 (~~), 1 warning (==), 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: March 14, 2021 Huawei 6 M. Boucadair 7 Orange 8 A. Liu 9 Tecent 10 September 10, 2020 12 A YANG Data Model for Layer 2 Network Topologies 13 draft-ietf-i2rs-yang-l2-network-topology-18 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 March 14, 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 . . . . . . . . . . . . . . . . . . . . . 19 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 77 8.2. Informative References . . . . . . . . . . . . . . . . . 23 78 Appendix A. Companion YANG Module for Non-NMDA Compliant 79 Implementations . . . . . . . . . . . . . . . . . . 24 80 Appendix B. An Example . . . . . . . . . . . . . . . . . . . . . 28 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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-topology! 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 flags* node-flag-type 175 +--rw bridge-id* string 176 +--rw management-address* inet:ip-address 177 +--rw management-mac? yang:mac-address 178 +--rw management-vlan? string 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 +--rw auto-nego? boolean 186 +--rw duplex? duplex-mode 187 augment /nw:networks/nw:network/nw:node/nt:termination-point: 188 +--rw l2-termination-point-attributes 189 +--rw interface-name? string 190 +--rw mac-address? yang:mac-address 191 +--rw port-number* uint32 192 +--rw unnumbered-id* uint32 193 +--rw encapsulation-type? identityref 194 +--rw outer-tag? dot1q-types:vid-range-type {VLAN}? 195 +--rw outer-tpid? dot1q-types:dot1q-tag-type {QinQ}? 196 +--rw inner-tag? dot1q-types:vid-range-type {VLAN}? 197 +--rw inner-tpid? dot1q-types:dot1q-tag-type {QinQ}? 198 +--rw lag? boolean 199 +--rw member-link-tp* -> /nw:networks/network/node/nt:termination-point/tp-id 200 +--rw vxlan {VXLAN}? 201 +--rw vni-id? vni 203 notifications: 204 +---n l2-node-event 205 | +--ro event-type? l2-network-event-type 206 | +--ro node-ref? -> /nw:networks/network[nw:network-id=current() 207 /../network-ref]/node/node-id 208 | +--ro network-ref? -> /nw:networks/network/network-id 209 | +--ro l2-topology! 210 | +--ro l2-node-attributes 211 | +--ro name? string 212 | +--ro flags* node-flag-type 213 | +--ro bridge-id* uint64 214 | +--ro management-address* inet:ip-address 215 | +--ro management-mac? yang:mac-address 216 | +--ro management-vlan? string 217 +---n l2-link-event 218 | +--ro event-type? l2-network-event-type 219 | +--ro link-ref? -> /nw:networks/network[nw:network-id=current() 220 /../network-ref]/nt:link/link-id 221 | +--ro network-ref? -> /nw:networks/network/network-id 222 | +--ro l2-topology! 223 | +--ro l2-link-attributes 224 | +--ro name? string 225 | +--ro flags* link-flag-type 226 | +--ro rate? uint64 227 | +--ro delay? uint32 228 | +--ro auto-nego? boolean 229 | +--ro duplex? duplex-mode 230 +---n l2-termination-point-event 231 +--ro event-type? l2-network-event-type 232 +--ro tp-ref? -> /nw:networks/network[nw:network-id=current() 233 /../network-ref]/node[nw:node-id=current() 234 /../node-ref]/nt:termination-point/tp-id 235 +--ro node-ref? -> /nw:networks/network[nw:network-id=current() 236 /../network-ref]/node/node-id 237 +--ro network-ref? -> /nw:networks/network/network-id 238 +--ro l2-topology! 239 +--ro l2-termination-point-attributes 240 +--ro interface-name? string 241 +--ro mac-address? yang:mac-address 242 +--ro port-number* uint32 243 +--ro unnumbered-id* uint32 244 +--ro encapsulation-type? identityref 245 +--ro outer-tag? dot1q-types:vid-range-type {VLAN}? 246 +--ro outer-tpid? dot1q-types:dot1q-tag-type {QinQ}? 247 +--ro inner-tag? dot1q-types:vid-range-type {VLAN}? 248 +--ro inner-tpid? dot1q-types:dot1q-tag-type {QinQ}? 249 +--ro lag? boolean 250 +--ro member-link-tp* -> /nw:networks/network/node/nt:termination-point/tp-id 251 +--ro vxlan {VXLAN}? 252 +--ro vni-id? vni 254 The Layer 2 topology YANG module augments the "ietf-network" and 255 "ietf-network-topology" YANG modules as follows: 257 o A new network type "l2-network-type" is introduced. This is 258 represented by a container object, and is inserted under the 259 "network-types" container of the generic "ietf-network" module 260 defined in Section 6.1 of [RFC8345]. 262 o Additional network attributes are introduced in a grouping "l2- 263 network-attributes", which augments the "network" list of the 264 "ietf-network" module. The attributes include Layer 2 network 265 name and a set of flags. Each type of flag is represented by a 266 separate identity. 268 o Additional data objects for Layer 2 nodes are introduced by 269 augmenting the "node" list of the generic "ietf-network" module. 270 New objects include Layer 2 node identifier, management address, 271 management mac, mangement vlan and a set of flags. 273 o Additional data objects for Layer 2 termination points are 274 introduced by augmenting the "termination-point" list of the 275 "ietf-network-topology" module defined in Section 6.2 of 276 [RFC8345]. New objects include interface name, encapsulation 277 type, lag support and Layer 2 termination point type specific 278 attributes. 280 o Links in the "ietf-network-topology" module are augmented as well 281 with a set of Layer 2 parameters, allowing to associate a link 282 with a name, a set of Layer 2 link attributes, and flags. 284 o Some optional Layer 2 technology specific attributes are 285 introduced in this module as Layer 2 features because these 286 attributes may be useful to expose to above services/applications. 287 Note that learning or configuring advanced Layer 2 technology- 288 specific attributes is not within the scope of the Layer 2 289 Topology YANG module; dedicated YANG modules should be used 290 instead (e.g., [I-D.ietf-trill-yang]). 292 4. Layer 2 Topology YANG Module 294 This module uses types defined in [RFC6991], [RFC7224], 295 [IEEE802.1Qcp], and [RFC8345]. It also references [RFC4761], 296 [RFC4762], and [RFC4202]. 298 file "ietf-l2-topology@2020-06-29.yang" 299 module ietf-l2-topology { 300 yang-version 1.1; 301 namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology"; 302 prefix l2t; 304 import ietf-network { 305 prefix nw; 306 reference 307 "RFC 8345: A YANG Data Model for Network Topologies"; 308 } 309 import ietf-network-topology { 310 prefix nt; 311 reference 312 "RFC 8345: A YANG Data Model for Network Topologies"; 313 } 314 import ietf-inet-types { 315 prefix inet; 316 reference 317 "RFC 6991:Common YANG Data Types"; 318 } 319 import ietf-yang-types { 320 prefix yang; 321 reference 322 "RFC 6991:Common YANG Data Types"; 323 } 324 import iana-if-type { 325 prefix ianaift; 326 reference 327 "RFC 7224: IANA Interface Type YANG Module"; 328 } 329 import ieee802-dot1q-types { 330 prefix dot1q-types; 331 reference 332 "IEEE Std 802.1Qcp-2018: Bridges and Bridged 333 Networks - Amendment: YANG Data Model"; 334 } 336 organization 337 "IETF I2RS (Interface to the Routing System) Working Group"; 338 contact 339 "WG Web: 340 WG List: 342 Editor: Jie Dong 343 345 Editor: Xiugang Wei 346 348 Editor: Qin Wu 349 351 Editor: Mohamed Boucadair 352 354 Editor: Anders Liu 355 "; 356 description 357 "This module defines a basic model for the Layer 2 topology 358 of a network. 360 Copyright (c) 2020 IETF Trust and the persons identified as 361 authors of the code. All rights reserved. 363 Redistribution and use in source and binary forms, with or 364 without modification, is permitted pursuant to, and subject 365 to the license terms contained in, the Simplified BSD License 366 set forth in Section 4.c of the IETF Trust's Legal Provisions 367 Relating to IETF Documents 368 (http://trustee.ietf.org/license-info). 370 This version of this YANG module is part of RFC XXXX; see 371 the RFC itself for full legal notices."; 373 revision 2020-06-29 { 374 description 375 "Initial revision"; 376 reference 377 "RFC XXXX: A YANG Data Model for Layer 2 378 Network Topologies"; 379 } 381 feature VLAN { 382 description 383 "Enables VLAN tag support as defined in IEEE 802.1Q."; 384 reference 385 "IEEE Std 802.1Q-2014: Bridges and Bridged Networks"; 386 } 388 feature QinQ { 389 description 390 "Enables QinQ double tag support as defined in IEEE 802.1ad."; 391 reference 392 "IEEE Std 802.1ad: Provider Bridges"; 393 } 395 feature VXLAN { 396 description 397 "Enables VXLAN support as defined in RFC7348."; 398 reference 399 "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): 400 A Framework for Overlaying Virtualized Layer 2 401 Networks over Layer 3 Networks"; 402 } 404 identity flag-identity { 405 description 406 "Base type for flags."; 407 } 409 identity eth-encapsulation-type { 410 base ianaift:iana-interface-type; 411 description 412 "Base identity from which specific Ethernet 413 encapsulation types are derived."; 414 reference 415 "RFC 7224: IANA Interface Type YANG Module"; 416 } 418 identity ethernet { 419 base eth-encapsulation-type; 420 description 421 "Native Ethernet encapsulation."; 422 } 424 identity vlan { 425 base eth-encapsulation-type; 426 description 427 "VLAN encapsulation."; 428 } 430 identity qinq { 431 base eth-encapsulation-type; 432 description 433 "QinQ encapsulation."; 434 } 436 identity pbb { 437 base eth-encapsulation-type; 438 description 439 "Provider-backbone-bridging (PBB) encapsulation. 440 The PBB functions are developed in IEEE 802.1ah."; 441 } 443 identity trill { 444 base eth-encapsulation-type; 445 description 446 "TRILL encapsulation."; 447 } 449 identity vpls { 450 base eth-encapsulation-type; 451 description 452 "Ethernet VPLS interface encapsulation."; 453 } 455 identity vxlan { 456 base eth-encapsulation-type; 457 description 458 "VXLAN MAC in UDP encapsulation."; 459 reference 460 "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): 461 A Framework for Overlaying Virtualized Layer 2 462 Networks over Layer 3 Networks"; 463 } 465 typedef vni { 466 type uint32 { 467 range "0..16777215"; 468 } 469 description 470 "VXLAN Network Identifier or VXLAN Segment ID. 471 It allows up to 16 M VXLAN segments to coexist 472 within the same administrative domain. 474 The use of value '0' is implementation-specific."; 475 reference 476 "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): 477 A Framework for Overlaying Virtualized Layer 2 478 Networks over Layer 3 Networks"; 479 } 480 typedef l2-flag-type { 481 type identityref { 482 base flag-identity; 483 } 484 description 485 "Base type for L2 flags. One example of L2 flag 486 type is trill which represents trill topology 487 type."; 488 } 490 typedef node-flag-type { 491 type identityref { 492 base flag-identity; 493 } 494 description 495 "Node flag attributes. The physical node can be 496 one example of node flag attribute."; 497 } 499 typedef link-flag-type { 500 type identityref { 501 base flag-identity; 502 } 503 description 504 "Link flag attributes. One example of link flag 505 attribute is the pseudowire."; 506 } 508 typedef l2-network-event-type { 509 type enumeration { 510 enum addition { 511 value 0; 512 description 513 "A Layer 2 node or link or termination-point 514 has been added."; 515 } 516 enum removal { 517 value 1; 518 description 519 "A Layer 2 node or link or termination-point 520 has been removed."; 521 } 522 enum update { 523 value 2; 524 description 525 "A Layer 2 node or link or termination-point 526 has been updated."; 527 } 529 } 530 description 531 "Layer 2 network event type for notifications."; 532 } 534 typedef duplex-mode { 535 type enumeration { 536 enum full-duplex { 537 description 538 "Indicates full-duplex mode."; 539 } 540 enum half-duplex { 541 description 542 "Indicates half-duplex mode."; 543 } 544 } 545 description 546 "Indicates the type of the duplex mode."; 547 } 549 grouping l2-network-type { 550 description 551 "Indicates the topology type to be L2."; 552 container l2-topology { 553 presence "Indicates L2 Network Topology."; 554 description 555 "The presence of the container node indicates 556 L2 Network Topology."; 557 } 558 } 560 grouping l2-topology-attributes { 561 description 562 "L2 Topology scope attributes."; 563 container l2-topology-attributes { 564 description 565 "Contains L2 topology attributes."; 566 leaf name { 567 type string; 568 description 569 "Name of the topology."; 570 } 571 leaf-list flags { 572 type l2-flag-type; 573 description 574 "Topology flags."; 575 } 576 } 578 } 580 grouping l2-node-attributes { 581 description 582 "L2 node attributes"; 583 container l2-node-attributes { 584 description 585 "Contains L2 node attributes."; 586 leaf name { 587 type string; 588 description 589 "Node name."; 590 } 591 leaf-list flags { 592 type node-flag-type; 593 description 594 "Node flags. It can be used to indicates 595 node flag attributes."; 596 } 597 leaf-list bridge-id { 598 type string { 599 pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){7}'; 600 } 601 description 602 "This is the bridge identifier represented as 603 hexadecimal 8 octet string. It has 4 bits of 604 priority, 12 bits of MSTI-ID and the base bridge 605 identifier. There may be multiple one for each 606 spanning tree instance."; 607 reference 608 "RFC 7727: Spanning Tree Protocol (STP) Application of 609 the Inter-Chassis Communication Protocol (ICCP)"; 610 } 611 leaf-list management-address { 612 type inet:ip-address; 613 description 614 "IP address used for management purpose."; 615 } 616 leaf management-mac { 617 type yang:mac-address; 618 description 619 "This is a MAC address used the bridge management. 620 It can be the Bridge Base VID, interface 621 MAC address or other. "; 622 } 623 leaf management-vlan { 624 type string; 625 description 626 "This is a VLAN that supports the Management address. 627 The actual VLAN ID type and value would be a member of 628 this VLAN."; 629 } 630 } 631 } 633 grouping l2-link-attributes { 634 description 635 "L2 link attributes"; 636 container l2-link-attributes { 637 description 638 "Contains L2 link attributes."; 639 leaf name { 640 type string; 641 description 642 "Link name."; 643 } 644 leaf-list flags { 645 type link-flag-type; 646 description 647 "Link flags. It can be used to indicate 648 link flag attributes."; 649 } 650 leaf rate { 651 type uint64; 652 units "Kbps"; 653 description 654 "Link rate. It specifies bandwidth requirements 655 associated with the specific link. The link 656 contains a source and a destination."; 657 } 658 leaf delay { 659 type uint32; 660 units "microseconds"; 661 description 662 "Unidirectional Link delay in 663 microseconds."; 664 } 665 leaf auto-nego { 666 type boolean; 667 default "true"; 668 description 669 "Set to true if auto negotiation is supported. 670 Set to false if auto negotiation is not supported."; 671 } 672 leaf duplex { 673 type duplex-mode; 674 description 675 "Expose the duplex mode, full duplex or half-duplex."; 676 } 677 } 678 } 680 grouping l2-termination-point-attributes { 681 description 682 "L2 termination point attributes"; 683 container l2-termination-point-attributes { 684 description 685 "Containing L2 termination point attributes."; 686 leaf interface-name { 687 type string; 688 description 689 "Name of the interface. The name can (but does not 690 have to) correspond to an interface reference of a 691 containing node's interface, i.e., the path name of a 692 corresponding interface data node on the containing 693 node reminiscent of data type interface-ref defined 694 in RFC 8343. It should be noted that data type 695 interface-ref of RFC 8343 cannot be used directly, 696 as this data type is used to reference an interface 697 in a datastore of a single node in the network, not 698 to uniquely reference interfaces across a network."; 699 } 700 leaf mac-address { 701 type yang:mac-address; 702 description 703 "Interface MAC address for logical link control."; 704 } 705 leaf-list port-number { 706 type uint32; 707 description 708 " List of port numbers of the Bridge ports for which each 709 entry contains Bridge management information."; 710 } 711 leaf-list unnumbered-id { 712 type uint32; 713 description 714 "List of unnumbered interface identifiers. 715 The unnumbered interface identifier will correspond to 716 the ifIndex value of the interface, i.e., the ifIndex value 717 of the ifEntry that represents the interface in 718 implementations where the Interfaces Group MIB 719 (RFC 2863) is supported."; 720 } 721 leaf encapsulation-type { 722 type identityref { 723 base eth-encapsulation-type; 724 } 725 description 726 "Encapsulation type of this 727 termination point."; 728 } 729 leaf outer-tag { 730 if-feature "VLAN"; 731 type dot1q-types:vid-range-type; 732 description 733 "The outermost VLAN tag. It may include a list of VLAN 734 Ids, or non overlapping VLAN ranges."; 735 } 736 leaf outer-tpid { 737 if-feature "QinQ"; 738 type dot1q-types:dot1q-tag-type; 739 description 740 "Identifies a specific 802.1Q tag type of outermost VLAN tag."; 741 } 742 leaf inner-tag { 743 if-feature "VLAN"; 744 type dot1q-types:vid-range-type; 745 description 746 "The inner VLAN tag. It may include a list of VLAN 747 Ids, or non overlapping VLAN ranges."; 748 } 749 leaf inner-tpid { 750 if-feature "QinQ"; 751 type dot1q-types:dot1q-tag-type; 752 description 753 "Identifies a specific 802.1Q tag type of inner VLAN tag."; 754 } 755 leaf lag { 756 type boolean; 757 default "false"; 758 description 759 "Defines whether lag is supported or not. 760 When it is set to true, the lag is supported."; 761 } 762 leaf-list member-link-tp { 763 when "../lag = 'true'" { 764 description 765 "Relevant only when the lag interface is supported."; 766 } 767 type leafref { 768 path "/nw:networks/nw:network/nw:node/nt:termination-point/nt:tp-id"; 769 } 770 description 771 "List of member link termination points associated with 772 specific l2 termination point."; 773 } 774 container vxlan { 775 when "derived-from-or-self(../encapsulation-type, 'l2t:vxlan')" { 776 description 777 "Only applies when the type of the Ethernet 778 encapsulation is 'vxlan'."; 779 } 780 if-feature "VXLAN"; 781 leaf vni-id { 782 type vni; 783 description 784 "VXLAN Network Identifier (VNI)."; 785 } 786 description 787 "Vxlan encapsulation type."; 788 } 789 } 790 } 792 augment "/nw:networks/nw:network/nw:network-types" { 793 description 794 "Introduces new network type for L2 topology."; 795 uses l2-network-type; 796 } 797 augment "/nw:networks/nw:network" { 798 when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' { 799 description 800 "Augmentation parameters apply only for networks 801 with L2 topology."; 802 } 803 description 804 "Configuration parameters for the L2 network 805 as a whole."; 806 uses l2-topology-attributes; 807 } 808 augment "/nw:networks/nw:network/nw:node" { 809 when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' { 810 description 811 "Augmentation parameters apply only for networks 812 with L2 topology."; 813 } 814 description 815 "Configuration parameters for L2 at the node 816 level."; 817 uses l2-node-attributes; 819 } 820 augment "/nw:networks/nw:network/nt:link" { 821 when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' { 822 description 823 "Augmentation parameters apply only for networks 824 with L2 topology."; 825 } 826 description 827 "Augments L2 topology link information."; 828 uses l2-link-attributes; 829 } 830 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 831 when '/nw:networks/nw:network/nw:network-types/l2t:l2-topology' { 832 description 833 "Augmentation parameters apply only for networks 834 with L2 topology."; 835 } 836 description 837 "Augments L2 topology termination point information."; 838 uses l2-termination-point-attributes; 839 } 841 notification l2-node-event { 842 description 843 "Notification event for L2 node."; 844 leaf event-type { 845 type l2-network-event-type; 846 description 847 "Event type."; 848 } 849 uses nw:node-ref; 850 uses l2-network-type; 851 uses l2-node-attributes; 852 } 854 notification l2-link-event { 855 description 856 "Notification event for L2 link."; 857 leaf event-type { 858 type l2-network-event-type; 859 description 860 "Event type."; 861 } 862 uses nt:link-ref; 863 uses l2-network-type; 864 uses l2-link-attributes; 865 } 866 notification l2-termination-point-event { 867 description 868 "Notification event for L2 termination point."; 869 leaf event-type { 870 type l2-network-event-type; 871 description 872 "Event type."; 873 } 874 uses nt:tp-ref; 875 uses l2-network-type; 876 uses l2-termination-point-attributes; 877 } 878 } 879 881 5. IANA Considerations 883 This document requests IANA to register the following URIs in the 884 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 886 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology 887 Registrant Contact: The IESG. 888 XML: N/A; the requested URI is an XML namespace. 890 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 891 Registrant Contact: The IESG. 892 XML: N/A; the requested URI is an XML namespace. 894 This document requests IANA to register the following YANG modules in 895 the "YANG Module Names" subregistry [RFC6020] within the "YANG 896 Parameters" registry. 898 name: ietf-l2-topology 899 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology 900 prefix: l2t 901 reference: RFC XXXX 903 name: ietf-l2-topology-state 904 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 905 prefix: l2t-s 906 reference: RFC XXXX 908 These modules are not maintained by IANA. 910 6. Security Considerations 912 The YANG module specified in this document defines a schema for data 913 that is designed to be accessed via network management protocols such 914 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 915 is the secure transport layer, and the mandatory-to-implement secure 916 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 917 is HTTPS, and the mandatory-to-implement secure transport is TLS 918 [RFC8446]. 920 The Network Configuration Access Control Model (NACM) [RFC8341] 921 provides the means to restrict access for particular NETCONF or 922 RESTCONF users to a preconfigured subset of all available NETCONF or 923 RESTCONF protocol operations and content. 925 The Layer 2 topology module defines information that can be 926 configurable in certain instances, for example in the case of virtual 927 topologies that can be created by client applications. In such 928 cases, a malicious client could introduce topologies that are 929 undesired. Specifically, a malicious client could attempt to remove 930 or add a node, a link, a termination point, by creating or deleting 931 corresponding elements in the node, link, and termination point 932 lists, respectively. In the case of a topology that is learned, the 933 server will automatically prohibit such misconfiguration attempts. 934 In the case of a topology that is configured, i.e. whose origin is 935 "intended", the undesired configuration could become effective and be 936 reflected in the operational state datastore [RFC8342], leading to 937 disruption of services provided via this topology. For those 938 reasons, it is important that the NACM is vigorously applied to 939 prevent topology misconfiguration by unauthorized clients. 941 There are a number of data nodes defined in this YANG module that are 942 writable/creatable/deletable (i.e., config true, which is the 943 default). These data nodes may be considered sensitive or vulnerable 944 in some network environments. Write operations (e.g., edit-config) 945 to these data nodes without proper protection can have a negative 946 effect on network operations. These are the subtrees and data nodes 947 and their sensitivity/vulnerability: 949 o l2-network-attributes: A malicious client could attempt to 950 sabotage the configuration of any of the contained attributes, 951 such as the name or the flag data nodes. 953 o l2-node-attributes: A malicious client could attempt to sabotage 954 the configuration of important node attributes, such as the name 955 or the management-address. 957 o l2-link-attributes: A malicious client could attempt to sabotage 958 the configuration of important link attributes, such as the rate 959 or the delay data nodes. 961 o l2-termination-point-attributes: A malicious client could attempt 962 to sabotage the configuration of important termination point 963 attributes (e.g., 'maximum-frame-size'). 965 Some of the readable data nodes in this YANG module may be considered 966 sensitive or vulnerable in some network environments. It is thus 967 important to control read access (e.g., via get, get-config, or 968 notification) to these data nodes. In particular, the YANG model for 969 layer 2 topology may expose sensitive information, for example the 970 MAC addresses of devices, VLAN/VXLAN identifiers. Unrestricted use 971 of such information can lead to privacy violations. For example, 972 listing MAC addresses in a network allows monitoring of devices and 973 their movements. Location information can be derived from MAC 974 addresses of network devices, bypassing protection of location 975 information by the Operating System. 977 7. Acknowledgements 979 The authors would like to acknowledge the comments and suggestions 980 received from Susan Hares, Alia Atlas, Juergen Schoenwaelder, Mach 981 Chen, Alexander Clemm, Sriganesh Kini, Oscar Gonzalez de Dios, Stig 982 Venaas, Christian Huitema, and Meral Shirazipour,Benjamin Kaduk,Don 983 Fedyk. 985 Many thanks to Ladislav Lhotka for the yang-doctors review. 987 8. References 989 8.1. Normative References 991 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 992 Requirement Levels", BCP 14, RFC 2119, 993 DOI 10.17487/RFC2119, March 1997, 994 . 996 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 997 DOI 10.17487/RFC3688, January 2004, 998 . 1000 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 1001 in Support of Generalized Multi-Protocol Label Switching 1002 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 1003 . 1005 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1006 LAN Service (VPLS) Using BGP for Auto-Discovery and 1007 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1008 . 1010 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1011 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1012 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1013 . 1015 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1016 the Network Configuration Protocol (NETCONF)", RFC 6020, 1017 DOI 10.17487/RFC6020, October 2010, 1018 . 1020 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1021 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1022 . 1024 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1025 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1026 . 1028 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1029 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1030 eXtensible Local Area Network (VXLAN): A Framework for 1031 Overlaying Virtualized Layer 2 Networks over Layer 3 1032 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1033 . 1035 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1036 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1037 . 1039 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1040 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1041 May 2017, . 1043 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1044 Access Control Model", STD 91, RFC 8341, 1045 DOI 10.17487/RFC8341, March 2018, 1046 . 1048 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1049 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1050 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1051 2018, . 1053 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1054 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1055 . 1057 8.2. Informative References 1059 [I-D.ietf-trill-yang] 1060 Weiguo, H., Yizhou, L., Kumar, D., Durrani, M., Zhai, H., 1061 and L. Xia, "TRILL YANG Data Model", draft-ietf-trill- 1062 yang-04 (work in progress), December 2015. 1064 [I2RS-UR] Hares, S. and M. Chen, "Summary of I2RS Use Case 1065 Requirements", draft-ietf-i2rs-usecase-reqs-summary-03 1066 (work in progress), November 2016. 1068 [IEEE802.1AB] 1069 "Station and Media Access Control Connectivity Discovery", 1070 IEEE Std 802.1AB-2016, March 2016. 1072 [IEEE802.1ad] 1073 "Virtual Bridged Local Area Networks Amendment 4: Provider 1074 Bridges", IEEE Std 802.1ad-2005, May 2006. 1076 [IEEE802.1ah] 1077 "Virtual Bridged Local Area Networks Amendment 4: Provider 1078 Bridges", IEEE Std 802.1ah-2008, August 2008. 1080 [IEEE802.1Qcp] 1081 "Bridges and Bridged Networks - Amendment: YANG Data 1082 Model", IEEE Std 802.1Qcp-2018, September 2018. 1084 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1085 and A. Bierman, Ed., "Network Configuration Protocol 1086 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1087 . 1089 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1090 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1091 . 1093 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1094 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1095 . 1097 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1098 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1099 . 1101 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1102 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1103 . 1105 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1106 and R. Wilton, "Network Management Datastore Architecture 1107 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1108 . 1110 Appendix A. Companion YANG Module for Non-NMDA Compliant 1111 Implementations 1113 The YANG module ietf-l2-topology defined in this document augments 1114 two modules, "ietf-network" and "ietf-network-topology", that are 1115 designed to be used in conjunction with implementations that support 1116 the Network Management Datastore Architecture (NMDA) defined in 1117 [RFC8342]. In order to allow implementations to use the model even 1118 in cases when NMDA is not supported, a set of companion modules have 1119 been defined that represent a state model of networks and network 1120 topologies, "ietf-network-state" and "ietf-network-topology-state", 1121 respectively. 1123 In order to be able to use the model for layer 2 topologies defined 1124 in this document in conjunction with non-NMDA compliant 1125 implementations, a corresponding companion module is defined that 1126 represents the operational state of layer 2 network topologies. The 1127 module "ietf-l2-topology-state" mirrors the module "ietf-l2-topology" 1128 defined in Section 4. However, it augments "ietf-network-state" and 1129 "ietf-network-topology-state" (instead of "ietf-network" and "ietf- 1130 network-topology") and all its data nodes are non-configurable. 1132 The companion module "ietf-l2-topology" SHOULD NOT be supported by 1133 implementations that support NMDA. It is for this reason that this 1134 module is defined in the informative Appendix. 1136 As the structure of this modules mirrors that of its underlying 1137 modules, the YANG tree is not depicted separately. 1139 file "ietf-l2-topology-state@2020-06-29.yang" 1140 module ietf-l2-topology-state { 1141 yang-version 1.1; 1142 namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology-state"; 1143 prefix l2t-s; 1145 import ietf-network-state { 1146 prefix nw-s; 1147 reference 1148 "RFC 8345: A YANG Data Model for Network Topologies"; 1150 } 1151 import ietf-network-topology-state { 1152 prefix nt-s; 1153 reference 1154 "RFC 8345: A YANG Data Model for Network Topologies"; 1155 } 1156 import ietf-l2-topology { 1157 prefix l2t; 1158 reference 1159 "RFC XXXX: A YANG Data Model for Layer 2 Network 1160 Topologies"; 1161 } 1163 organization 1164 "IETF I2RS (Interface to the Routing System) Working Group"; 1165 contact 1166 "WG Web: 1167 WG List: 1169 Editor: Jie Dong 1170 1171 Editor: Xiugang Wei 1172 1173 Editor: Qin Wu 1174 1175 Editor: Mohamed Boucadair 1176 1177 Editor: Anders Liu 1178 "; 1179 description 1180 "This module defines a model for Layer 2 Network Topology 1181 state, representing topology that either is learned or 1182 results from applying topology that has been configured per 1183 the 'ietf-l2-topology' model, mirroring the 1184 corresponding data nodes in this model. 1186 This model mirrors 'ietf-l2-topology' but contains only 1187 read-only state data. The model is not needed when the 1188 underlying implementation infrastructure supports the 1189 Network Management Datastore Architecture (NMDA). 1191 Copyright (c) 2020 IETF Trust and the persons identified as 1192 authors of the code. All rights reserved. 1194 Redistribution and use in source and binary forms, with or 1195 without modification, is permitted pursuant to, and subject 1196 to the license terms contained in, the Simplified BSD License 1197 set forth in Section 4.c of the IETF Trust's Legal Provisions 1198 Relating to IETF Documents 1199 (http://trustee.ietf.org/license-info). 1201 This version of this YANG module is part of RFC XXXX; see 1202 the RFC itself for full legal notices."; 1204 revision 2020-06-29 { 1205 description 1206 "Initial revision"; 1207 reference 1208 "RFC XXXX: A YANG Data Model for Layer 2 Network 1209 Topologies"; 1210 } 1212 /* 1213 * Data nodes 1214 */ 1216 augment "/nw-s:networks/nw-s:network/nw-s:network-types" { 1217 description 1218 "Introduces a new network type for L2 topology."; 1219 uses l2t:l2-network-type; 1220 } 1222 augment "/nw-s:networks/nw-s:network" { 1223 when 'nw-s:network-types/l2t-s:l2-topology' { 1224 description 1225 "Augmentation parameters apply only for networks 1226 with L2 topology."; 1227 } 1228 description 1229 "Configuration parameters for the L2 network 1230 as a whole."; 1231 uses l2t:l2-topology-attributes; 1232 } 1234 augment "/nw-s:networks/nw-s:network/nw-s:node" { 1235 when '../nw-s:network-types/l2t-s:l2-topology' { 1236 description 1237 "Augmentation parameters apply only for networks 1238 with L2 topology."; 1239 } 1240 description 1241 "Configuration parameters for L2 at the node 1242 level."; 1243 uses l2t:l2-node-attributes; 1244 } 1245 augment "/nw-s:networks/nw-s:network/nt-s:link" { 1246 when '../nw-s:network-types/l2t-s:l2-topology' { 1247 description 1248 "Augmentation parameters apply only for networks 1249 with L2 topology."; 1250 } 1251 description 1252 "Augments L2 topology link information."; 1253 uses l2t:l2-link-attributes; 1254 } 1256 augment "/nw-s:networks/nw-s:network/nw-s:node/" 1257 + "nt-s:termination-point" { 1258 when '../../nw-s:network-types/l2t-s:l2-topology' { 1259 description 1260 "Augmentation parameters apply only for networks 1261 with L2 topology."; 1262 } 1263 description 1264 "Augments L2 topology termination point information."; 1265 uses l2t:l2-termination-point-attributes; 1266 } 1268 /* 1269 * Notifications 1270 */ 1272 notification l2-node-event { 1273 description 1274 "Notification event for L2 node."; 1275 leaf event-type { 1276 type l2t:l2-network-event-type; 1277 description 1278 "Event type."; 1279 } 1280 uses nw-s:node-ref; 1281 uses l2t:l2-network-type; 1282 uses l2t:l2-node-attributes; 1283 } 1285 notification l2-link-event { 1286 description 1287 "Notification event for a L2 link."; 1288 leaf event-type { 1289 type l2t:l2-network-event-type; 1290 description 1291 "Event type."; 1292 } 1293 uses nt-s:link-ref; 1294 uses l2t:l2-network-type; 1295 uses l2t:l2-link-attributes; 1296 } 1298 notification l2-termination-point-event { 1299 description 1300 "Notification event for L2 termination point."; 1301 leaf event-type { 1302 type l2t:l2-network-event-type; 1303 description 1304 "Event type."; 1305 } 1306 uses nt-s:tp-ref; 1307 uses l2t:l2-network-type; 1308 uses l2t:l2-termination-point-attributes; 1309 } 1310 } 1311 1313 Appendix B. An Example 1315 This section contains an example of an instance data tree in JSON 1316 encoding [RFC7951]. The example instantiates "ietf-l2-topology" for 1317 the topology that is depicted in the following diagram. There are 1318 three nodes: D1, D2, and D3. D1 has three termination points: 1-0-1, 1319 1-2-1, and 1-3-1. D2 has three termination points as well: 2-1-1, 1320 2-0-1, and 2-3-1. D3 has two termination points: 3-1-1 and 3-2-1. 1321 For termination point 1-0-1, it provides lag support and has two 1322 member link termination points: 1-0-1-1,1-0-1-2. In addition, there 1323 are six links, two between each pair of nodes, with one going in each 1324 direction. 1326 +------------+ +------------+ 1327 | D1 | | D2 | 1328 1-0-1-1 /-\ /-\ /-\ /-\ 1329 <--------->| | 1-0-1 | |---------------->| | 2-1-1 | | 1330 1-0-1-2 | | 1-2-1 | |<----------------| | 2-0-1 | | 1331 <--------> \-/ 1-3-1 \-/ \-/ 2-3-1 \-/ 1332 | /----\ | | /----\ | 1333 +---| |---+ +---| |---+ 1334 \----/ \----/ 1335 A | A | 1336 | | | | 1337 | | | | 1338 | | +------------+ | | 1339 | | | D3 | | | 1340 | | /-\ /-\ | | 1341 | +----->| | 3-1-1 | |-------+ | 1342 +---------| | 3-2-1 | |<---------+ 1343 \-/ \-/ 1344 | | 1345 +------------+ 1347 Figure 2. A Network Topology Example 1349 The corresponding instance data tree is depicted below: 1351 { 1352 "ietf-network:networks": { 1353 "network": [ 1354 { 1355 "network-id": "l2-topo-example", 1356 "node": [ 1357 { 1358 "node-id": "D1", 1359 "ietf-network-topology:termination-point": [ 1360 { 1361 "tp-id": "1-0-1", 1362 "ietf-l2-topology:l2-termination-point-attributes": { 1363 "mac-address": "00:00:5e:00:53:d0", 1364 "lag": true, 1365 "member-link-tp": [ 1366 "1-0-1-1", 1367 "1-0-1-2" 1368 ] 1369 } 1370 }, 1371 { 1372 "tp-id": "1-0-1-1", 1373 "ietf-l2-topology:l2-termination-point-attributes": { 1374 "mac-address": "00:00:5e:00:53:d3" 1375 } 1376 }, 1377 { 1378 "tp-id": "1-0-1-2", 1379 "ietf-l2-topology:l2-termination-point-attributes": { 1380 "mac-address": "00:00:5e:00:53:d4" 1381 } 1382 }, 1383 { 1384 "tp-id": "1-2-1", 1385 "ietf-l2-topology:l2-termination-point-attributes": { 1386 "mac-address": "00:00:5e:00:53:d1" 1387 } 1388 }, 1389 { 1390 "tp-id": "1-3-1", 1391 "ietf-l2-topology:l2-termination-point-attributes": { 1392 "mac-address": "00:00:5e:00:53:d2" 1393 } 1394 } 1395 ], 1396 "ietf-l2-topology:l2-node-attributes": { 1397 "management-address": [ 1398 "192.0.2.1", 1399 "2001:db8:0:1::" 1400 ] 1401 } 1402 }, 1403 { 1404 "node-id": "D2", 1405 "ietf-network-topology:termination-point": [ 1406 { 1407 "tp-id": "2-0-1", 1408 "ietf-l2-topology:l2-termination-point-attributes": { 1409 "mac-address": "00:00:5e:00:53:e0" 1410 } 1411 }, 1412 { 1413 "tp-id": "2-1-1", 1414 "ietf-l2-topology:l2-termination-point-attributes": { 1415 "mac-address": "00:00:5e:00:53:e1" 1416 } 1417 }, 1418 { 1419 "tp-id": "2-3-1", 1420 "ietf-l2-topology:l2-termination-point-attributes": { 1421 "mac-address": "00:00:5e:00:53:e2" 1423 } 1424 } 1425 ], 1426 "ietf-l2-topology:l2-node-attributes": { 1427 "management-address": [ 1428 "192.0.2.2", 1429 "2001:db8:0:2::" 1430 ] 1431 } 1432 }, 1433 { 1434 "node-id": "D3", 1435 "ietf-network-topology:termination-point": [ 1436 { 1437 "tp-id": "3-1-1", 1438 "ietf-l2-topology:l2-termination-point-attributes": { 1439 "mac-address": "00:00:5e:00:53:f0" 1440 } 1441 }, 1442 { 1443 "tp-id": "3-2-1", 1444 "ietf-l2-topology:l2-termination-point-attributes": { 1445 "mac-address": "00:00:5e:00:53:f1" 1446 } 1447 } 1448 ], 1449 "ietf-l2-topology:l2-node-attributes": { 1450 "management-address": [ 1451 "192.0.2.3", 1452 "2001:db8:0:3::" 1453 ] 1454 } 1455 } 1456 ], 1457 "ietf-network-topology:link": [ 1458 { 1459 "link-id": "D1,1-2-1,D2,2-1-1", 1460 "source": { 1461 "source-node": "D1", 1462 "source-tp": "1-2-1" 1463 }, 1464 "destination": { 1465 "dest-node": "D2", 1466 "dest-tp": "2-1-1" 1467 }, 1468 "ietf-l2-topology:l2-link-attributes": { 1469 "rate": "1000" 1470 } 1472 }, 1473 { 1474 "link-id": "D2,2-1-1,D1,1-2-1", 1475 "source": { 1476 "source-node": "D2", 1477 "source-tp": "2-1-1" 1478 }, 1479 "destination": { 1480 "dest-node": "D1", 1481 "dest-tp": "1-2-1" 1482 }, 1483 "ietf-l2-topology:l2-link-attributes": { 1484 "rate": "1000" 1485 } 1486 }, 1487 { 1488 "link-id": "D1,1-3-1,D3,3-1-1", 1489 "source": { 1490 "source-node": "D1", 1491 "source-tp": "1-3-1" 1492 }, 1493 "destination": { 1494 "dest-node": "D3", 1495 "dest-tp": "3-1-1" 1496 }, 1497 "ietf-l2-topology:l2-link-attributes": { 1498 "rate": "1000" 1499 } 1500 }, 1501 { 1502 "link-id": "D3,3-1-1,D1,1-3-1", 1503 "source": { 1504 "source-node": "D3", 1505 "source-tp": "3-1-1" 1506 }, 1507 "destination": { 1508 "dest-node": "D1", 1509 "dest-tp": "1-3-1" 1510 }, 1511 "ietf-l2-topology:l2-link-attributes": { 1512 "rate": "1000" 1513 } 1514 }, 1515 { 1516 "link-id": "D2,2-3-1,D3,3-2-1", 1517 "source": { 1518 "source-node": "D2", 1519 "source-tp": "2-3-1" 1521 }, 1522 "destination": { 1523 "dest-node": "D3", 1524 "dest-tp": "3-2-1" 1525 }, 1526 "ietf-l2-topology:l2-link-attributes": { 1527 "rate": "1000" 1528 } 1529 }, 1530 { 1531 "link-id": "D3,3-2-1,D2,2-3-1", 1532 "source": { 1533 "source-node": "D3", 1534 "source-tp": "3-2-1" 1535 }, 1536 "destination": { 1537 "dest-node": "D2", 1538 "dest-tp": "2-3-1" 1539 }, 1540 "ietf-l2-topology:l2-link-attributes": { 1541 "rate": "1000" 1542 } 1543 } 1544 ] 1545 } 1546 ] 1547 } 1548 } 1550 Authors' Addresses 1552 Jie Dong 1553 Huawei 1554 Huawei Campus, No. 156 Beiqing Rd. 1555 Beijing 100095 1556 China 1558 Email: jie.dong@huawei.com 1560 Xiugang Wei 1561 Huawei 1562 Huawei Campus, No. 156 Beiqing Rd. 1563 Beijing 100095 1564 China 1566 Email: weixiugang@huawei.com 1567 Qin Wu 1568 Huawei 1569 101 Software Avenue, Yuhua District 1570 Nanjing 210012 1571 China 1573 Email: bill.wu@huawei.com 1575 Mohamed Boucadair 1576 Orange 1577 Rennes 35000 1578 France 1580 Email: mohamed.boucadair@orange.com 1582 Anders Liu 1583 Tecent 1584 Yinke Building 38 Haidian St, Haidian District 1585 Beijing 100080 1586 China 1588 Email: andersliu@tencent.com