idnits 2.17.1 draft-ietf-i2rs-yang-l2-network-topology-14.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 201 has weird spacing: '...vlan-id dot...' == Line 202 has weird spacing: '...vlan-id dot...' == Line 256 has weird spacing: '...vlan-id dot...' == Line 257 has weird spacing: '...vlan-id dot...' -- The document date (June 29, 2020) is 1396 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 5 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: December 31, 2020 Huawei 6 M. Boucadair 7 Orange 8 A. Liu 9 Tecent 10 June 29, 2020 12 A YANG Data Model for Layer 2 Network Topologies 13 draft-ietf-i2rs-yang-l2-network-topology-14 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 December 31, 2020. 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 (L2) network topology YANG module is designed to be 130 generic and applicable to Layer 2 networks built with different L2 131 technologies. It can be used to describe both the physical and the 132 logical (virtual) L2 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-network-attributes 169 +--rw name? string 170 +--rw flag* 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-vid? dot1q-types:vlanid {VLAN}? 178 +--rw flag* node-flag-type 179 augment /nw:networks/nw:network/nt:link: 180 +--rw l2-link-attributes 181 +--rw name? string 182 +--rw flag* link-flag-type 183 +--rw rate? decimal64 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* leafref 195 | | +--rw mode? neg-mode 196 | | +--rw port-vlan-id? dot1q-types:vlanid {VLAN}? 197 | | +--rw vlan-id-name* [vlan-id] {VLAN}? 198 | | | +--rw vlan-id dot1q-types:vlanid 199 | | | +--rw vlan-name? string 200 | | +--rw qinq* [svlan-id cvlan-id] {QinQ}? 201 | | | +--rw svlan-id dot1q-types:vlanid 202 | | | +--rw cvlan-id dot1q-types:vlanid 203 | | +--rw vxlan {VXLAN}? 204 | | +--rw vni-id? vni 205 | +--:(legacy) 206 | +--rw layer-2-address? yang:phys-address 207 | +--rw encapsulation? identityref 208 +--ro tp-state? enumeration 210 notifications: 211 +---n l2-node-event 212 | +--ro event-type? l2-network-event-type 213 | +--ro node-ref? leafref 214 | +--ro network-ref? -> /nw:networks/network/network-id 215 | +--ro l2-network! 216 | +--ro l2-node-attributes 217 | +--ro name? string 218 | +--ro description? string 219 | +--ro management-address* inet:ip-address 220 | +--ro sys-mac-address? yang:mac-address 221 | +--ro management-vid? dot1q-types:vlanid {VLAN}? 222 | +--ro flag* node-flag-type 223 +---n l2-link-event 224 | +--ro event-type? l2-network-event-type 225 | +--ro link-ref? leafref 226 | +--ro network-ref? -> /nw:networks/network/network-id 227 | +--ro l2-network! 228 | +--ro l2-link-attributes 229 | +--ro name? string 230 | +--ro flag* link-flag-type 231 | +--ro rate? decimal64 232 | +--ro delay? uint32 233 +---n l2-termination-point-event 234 +--ro event-type? l2-network-event-type 235 +--ro tp-ref? leafref 236 +--ro node-ref? leafref 237 +--ro network-ref? 238 | -> /nw:networks/network/network-id 239 +--ro l2-network! 240 +--ro l2-termination-point-attributes 241 +--ro description? string 242 +--ro maximum-frame-size? uint32 243 +--ro (l2-termination-point-type)? 244 | +--:(ethernet) 245 | | +--ro mac-address? yang:mac-address 246 | | +--ro eth-encapsulation? identityref 247 | | +--ro lag? boolean 248 | | +--ro member-link-tp* leafref 249 | | +--ro mode? neg-mode 250 | | +--ro port-vlan-id? dot1q-types:vlanid 251 | | | {VLAN}? 252 | | +--ro vlan-id-name* [vlan-id] {VLAN}? 253 | | | +--ro vlan-id dot1q-types:vlanid 254 | | | +--ro vlan-name? string 255 | | +--ro qinq* [svlan-id cvlan-id] {QinQ}? 256 | | | +--ro svlan-id dot1q-types:vlanid 257 | | | +--ro cvlan-id dot1q-types:vlanid 258 | | +--ro vxlan {VXLAN}? 259 | | +--ro vni-id? vni 260 | +--:(legacy) 261 | +--ro layer-2-address? yang:phys-address 262 | +--ro encapsulation? identityref 263 +--ro tp-state? enumeration 265 The Layer 2 topology YANG module augments the "ietf-network" and 266 "ietf-network-topology" YANG modules as follows: 268 o A new network type "l2-network-type" is introduced. This is 269 represented by a container object, and is inserted under the 270 "network-types" container of the generic "ietf-network" module 271 defined in Section 6.1 of [RFC8345]. 273 o Additional network attributes are introduced in a grouping "l2- 274 network-attributes", which augments the "network" list of the 275 "ietf-network" module. The attributes include Layer 2 network 276 name and a set of flags. Each type of flag is represented by a 277 separate identity. 279 o Additional data objects for Layer 2 nodes are introduced by 280 augmenting the "node" list of the generic "ietf-network" module. 281 New objects include Layer 2 node identifier, description, 282 management address, and a set of flags. 284 o Additional data objects for Layer 2 termination points are 285 introduced by augmenting the "termination-point" list of the 286 "ietf-network-topology" module defined in Section 6.2 of 287 [RFC8345]. New objects include Layer 2 termination point 288 descriptions, Layer 2 termination point type specific attributes 289 and Layer 2 termination point states. 291 o Links in the "ietf-network-topology" module are augmented as well 292 with a set of Layer 2 parameters, allowing to associate a link 293 with a name, a set of Layer 2 link attributes, and flags. 295 o Some optional L2 technology specific attributes are introduced in 296 this module as Layer 2 features because these attributes may be 297 useful to expose to above services/applications. Note that 298 learning or configuring advanced L2 technology-specific attributes 299 is not within the scope of the Layer 2 Topology YANG module; 300 dedicated YANG modules should be used instead (e.g., 301 [I-D.ietf-trill-yang]). 303 4. Layer 2 Topology YANG Module 305 This module uses types defined in [RFC6991], [RFC7224], 306 [IEEE802.1Qcp], and [RFC8345]. It also references [RFC4761], 307 [RFC4762], and [RFC4202]. 309 file "ietf-l2-topology@2020-06-29.yang" 310 module ietf-l2-topology { 311 yang-version 1.1; 312 namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology"; 313 prefix l2t; 315 import ietf-network { 316 prefix nw; 317 reference 318 "RFC 8345: A YANG Data Model for Network Topologies"; 319 } 320 import ietf-network-topology { 321 prefix nt; 322 reference 323 "RFC 8345: A YANG Data Model for Network Topologies"; 324 } 325 import ietf-inet-types { 326 prefix inet; 327 reference 328 "Section 4 of RFC 6991"; 329 } 330 import ietf-yang-types { 331 prefix yang; 332 reference 333 "Section 3 of RFC 6991"; 334 } 335 import iana-if-type { 336 prefix ift; 337 reference 338 "RFC 7224: IANA Interface Type YANG Module"; 339 } 340 import ieee802-dot1q-types { 341 prefix dot1q-types; 342 reference 343 "IEEE Std 802.1Qcp-2018: Bridges and Bridged 344 Networks - Amendment: YANG Data Model"; 345 } 347 organization 348 "IETF I2RS (Interface to the Routing System) Working Group"; 349 contact 350 "WG Web: 351 WG List: 353 Editor: Jie Dong 354 356 Editor: Xiugang Wei 357 359 Editor: Qin Wu 360 362 Editor: Mohamed Boucadair 363 365 Editor: Anders Liu 366 "; 367 description 368 "This module defines a basic model for the Layer 2 topology 369 of a network. 371 Copyright (c) 2020 IETF Trust and the persons identified as 372 authors of the code. All rights reserved. 374 Redistribution and use in source and binary forms, with or 375 without modification, is permitted pursuant to, and subject 376 to the license terms contained in, the Simplified BSD License 377 set forth in Section 4.c of the IETF Trust's Legal Provisions 378 Relating to IETF Documents 379 (http://trustee.ietf.org/license-info). 381 This version of this YANG module is part of RFC XXXX; see 382 the RFC itself for full legal notices."; 384 revision 2020-06-29 { 385 description 386 "Initial revision"; 387 reference 388 "RFC XXXX: A YANG Data Model for Layer 2 Network 389 Topologies"; 390 } 392 /* 393 * Typedefs 394 */ 396 typedef vni { 397 type uint32 { 398 range "0..16777215"; 399 } 400 description 401 "VXLAN Network Identifier or VXLAN Segment ID. 402 It allows up to 16 M VXLAN segments to coexist 403 within the same administrative domain. 405 The use of value '0' is implementation-specific."; 406 reference 407 "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): 408 A Framework for Overlaying Virtualized Layer 2 409 Networks over Layer 3 Networks"; 410 } 412 typedef l2-flag-type { 413 type identityref { 414 base flag-identity; 415 } 416 description 417 "Base type for L2 flags. One example of L2 flag 418 type is trill which represents trill topology 419 type."; 420 } 422 typedef node-flag-type { 423 type identityref { 424 base flag-identity; 425 } 426 description 427 "Node flag attributes. The physical node can be 428 one example of node flag attribute."; 429 } 431 typedef link-flag-type { 432 type identityref { 433 base flag-identity; 434 } 435 description 436 "Link flag attributes. One example of link flag 437 attribute is the pseudowire."; 438 } 440 typedef l2-network-event-type { 441 type enumeration { 442 enum add { 443 value 0; 444 description 445 "A Layer 2 node or link or termination-point 446 has been added."; 447 } 448 enum remove { 449 value 1; 450 description 451 "A Layer 2 node or link or termination-point 452 has been removed."; 453 } 454 enum update { 455 value 2; 456 description 457 "A Layer 2 node or link or termination-point 458 has been updated."; 459 } 460 } 461 description 462 "Layer 2 network event type for notifications."; 463 } 465 typedef neg-mode { 466 type enumeration { 467 enum full-duplex { 468 description 469 "Indicates full-duplex mode."; 470 } 471 enum auto-neg { 472 description 473 "Indicates auto-negotiation mode."; 474 } 475 enum half-duplex { 476 description 477 "Indicates half-duplex mode."; 478 } 479 } 480 description 481 "Indicates the type of the negotiation mode."; 482 } 484 /* 486 * Features 487 */ 489 feature VLAN { 490 description 491 "Indicates that the system supports the 492 vlan functions (also known as an IEEE 802.1Q tag)."; 493 } 495 feature QinQ { 496 description 497 "Indicates that the system supports the 498 qinq functions (also known as IEEE 802.1ad double tag)."; 499 } 501 feature VXLAN { 502 description 503 "Indicates that the device supports VXLAN functions."; 504 reference 505 "RFC 7348: Virtual eXtensible Local Area Network (VXLAN): 506 A Framework for Overlaying Virtualized Layer 2 507 Networks over Layer 3 Networks"; 508 } 510 /* 511 * Identities 512 */ 514 identity flag-identity { 515 description 516 "Base type for flags."; 517 } 519 identity eth-encapsulation-type { 520 base ift:iana-interface-type; 521 description 522 "Base identity from which specific Ethernet 523 encapsulation types are derived."; 524 reference 525 "RFC 7224: IANA Interface Type YANG Module"; 526 } 527 identity ethernet { 528 base eth-encapsulation-type; 529 description 530 "Native Ethernet encapsulation."; 531 } 533 identity vlan { 534 base eth-encapsulation-type; 535 description 536 "VLAN encapsulation."; 537 } 539 identity qinq { 540 base eth-encapsulation-type; 541 description 542 "QinQ encapsulation."; 543 } 545 identity pbb { 546 base eth-encapsulation-type; 547 description 548 "Provider-backbone-bridging (PBB) encapsulation. 549 The PBB functions are developed in IEEE 802.1ah."; 550 } 552 identity trill { 553 base eth-encapsulation-type; 554 description 555 "TRILL encapsulation."; 556 } 558 identity vpls { 559 base eth-encapsulation-type; 560 description 561 "Ethernet VPLS interface encapsulation."; 562 } 564 identity vxlan { 565 base eth-encapsulation-type; 566 description 567 "VXLAN MAC in UDP encapsulation."; 568 } 570 /* 571 * Groupings 572 */ 574 grouping l2-network-type { 575 description 576 "Indicates the topology type to be L2."; 577 container l2-network { 578 presence "Indicates L2 Network"; 579 description 580 "The presence of the container node indicates 581 L2 Topology."; 582 } 583 } 585 grouping l2-network-attributes { 586 description 587 "L2 Topology scope attributes."; 588 container l2-network-attributes { 589 description 590 "Contains L2 network attributes."; 591 leaf name { 592 type string; 593 description 594 "Name of the L2 network."; 595 } 596 leaf-list flag { 597 type l2-flag-type; 598 description 599 "L2 network flags."; 600 } 601 } 602 } 604 grouping l2-node-attributes { 605 description 606 "L2 node attributes"; 607 container l2-node-attributes { 608 description 609 "Contains L2 node attributes."; 610 leaf name { 611 type string; 612 description 613 "Node name."; 614 } 615 leaf description { 616 type string; 617 description 618 "Node description."; 619 } 620 leaf-list management-address { 621 type inet:ip-address; 622 description 623 "System management address."; 624 } 625 leaf sys-mac-address { 626 type yang:mac-address; 627 description 628 "System MAC address."; 629 } 630 leaf management-vid { 631 if-feature "VLAN"; 632 type dot1q-types:vlanid; 633 description 634 "System management VID."; 635 } 636 leaf-list flag { 637 type node-flag-type; 638 description 639 "Node operational flags."; 640 } 641 } 642 } 644 grouping l2-link-attributes { 645 description 646 "L2 link attributes"; 647 container l2-link-attributes { 648 description 649 "Contains L2 link attributes."; 650 leaf name { 651 type string; 652 description 653 "Link name."; 654 } 655 leaf-list flag { 656 type link-flag-type; 657 description 658 "Link flags."; 659 } 660 leaf rate { 661 type decimal64 { 662 fraction-digits 2; 663 } 664 units "Mbps"; 665 description 666 "Link rate."; 667 } 668 leaf delay { 669 type uint32; 670 units "microseconds"; 671 description 672 "Link delay in microseconds."; 673 } 674 } 675 } 677 grouping l2-termination-point-attributes { 678 description 679 "L2 termination point attributes"; 680 container l2-termination-point-attributes { 681 description 682 "Containing L2 termination point attributes."; 683 leaf description { 684 type string; 685 description 686 "Port description."; 687 } 688 leaf maximum-frame-size { 689 type uint32; 690 description 691 "Maximum L2 frame size. If L2 frame is an Ethernet 692 frame, the Ethernet header should be included; 693 if L2 frame is other type (e.g., PPP), the L2 694 header should be included."; 695 } 696 choice l2-termination-point-type { 697 description 698 "Indicates termination-point type 699 specific attributes."; 700 case ethernet { 701 leaf mac-address { 702 type yang:mac-address; 703 description 704 "Interface MAC address."; 705 } 706 leaf eth-encapsulation { 707 type identityref { 708 base eth-encapsulation-type; 709 } 710 description 711 "Encapsulation type of this 712 termination point."; 713 } 714 leaf lag { 715 type boolean; 716 default "false"; 717 description 718 "Defines whether lag is supported or not."; 720 } 721 leaf-list member-link-tp { 722 when "../lag = 'true'" { 723 description 724 "Relevant only when the lag interface is supported."; 725 } 726 type leafref { 727 path "/nw:networks/nw:network/nw:node/" 728 + "nt:termination-point/nt:tp-id"; 729 } 730 description 731 "Member link termination points."; 732 } 733 leaf mode { 734 type neg-mode; 735 default "auto-neg"; 736 description 737 "Exposes the negotiation mode."; 738 } 739 leaf port-vlan-id { 740 when "derived-from-or-self(../eth-encapsulation" 741 + ", 'l2t:vlan')" { 742 description 743 "Only applies when the type of the Ethernet 744 encapsulation is 'vlan'."; 745 } 746 if-feature "VLAN"; 747 type dot1q-types:vlanid; 748 description 749 "Port VLAN ID is the VLAN identifier that 750 will be assigned to any untagged frames entering 751 the switch on the specific port."; 752 } 753 list vlan-id-name { 754 when "derived-from-or-self(../eth-encapsulation" 755 + ", 'l2t:vlan')" { 756 description 757 "Only applies when the type of the Ethernet 758 encapsulation is 'vlan'."; 759 } 760 if-feature "VLAN"; 761 key "vlan-id"; 762 description 763 "Interface configured VLANs."; 764 leaf vlan-id { 765 type dot1q-types:vlanid; 766 description 767 "VLAN ID."; 769 } 770 leaf vlan-name { 771 type string { 772 length "1..31"; 773 } 774 description 775 "VLAN name."; 776 } 777 } 778 list qinq { 779 when "derived-from-or-self(../eth-encapsulation" 780 + ", 'l2t:qinq')" { 781 description 782 "Only applies when the type of the Ethernet 783 encapsulation is 'qinq'."; 784 } 785 if-feature "QinQ"; 786 key "svlan-id cvlan-id"; 787 description 788 "Interface configured SVLANs and CVLANs."; 789 leaf svlan-id { 790 type dot1q-types:vlanid; 791 description 792 "SVLAN ID."; 793 } 794 leaf cvlan-id { 795 type dot1q-types:vlanid; 796 description 797 "CVLAN ID."; 798 } 799 } 800 container vxlan { 801 when "derived-from-or-self(../eth-encapsulation" 802 + ", 'l2t:vxlan')" { 803 description 804 "Only applies when the type of the Ethernet 805 encapsulation is 'vxlan'."; 806 } 807 if-feature "VXLAN"; 808 leaf vni-id { 809 type vni; 810 description 811 "VXLAN Network Identifier (VNI)."; 812 } 813 description 814 "Vxlan encapsulation type."; 815 } 816 } 817 //case ethernet 818 case legacy { 819 leaf layer-2-address { 820 type yang:phys-address; 821 description 822 "Interface Layer 2 address."; 823 } 824 leaf encapsulation { 825 type identityref { 826 base ift:iana-interface-type; 827 } 828 description 829 "Other legacy encapsulation type of this 830 termination point."; 831 } 832 } 833 //case legacy such as atm, ppp, hdlc, etc. 834 } 835 //choice termination-point-type 836 leaf tp-state { 837 type enumeration { 838 enum in-use { 839 value 1; 840 description 841 "The termination point is in forwarding state."; 842 } 843 enum blocking { 844 value 2; 845 description 846 "The termination point is in blocking state."; 847 } 848 enum down { 849 value 3; 850 description 851 "The termination point is in down state."; 852 } 853 enum others { 854 value 4; 855 description 856 "The termination point is in other state."; 857 } 858 } 859 config false; 860 description 861 "State of the termination point."; 862 } 863 } 864 } 865 /* 866 * Data nodes 867 */ 869 augment "/nw:networks/nw:network/nw:network-types" { 870 description 871 "Introduces new network type for L2 topology."; 872 uses l2-network-type; 873 } 875 augment "/nw:networks/nw:network" { 876 when '/nw:networks/nw:network/nw:network-types/l2t:l2-network' { 877 description 878 "Augmentation parameters apply only for networks 879 with L2 topology."; 880 } 881 description 882 "Configuration parameters for the L2 network 883 as a whole."; 884 uses l2-network-attributes; 885 } 887 augment "/nw:networks/nw:network/nw:node" { 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 L2 at the node 895 level."; 896 uses l2-node-attributes; 897 } 899 augment "/nw:networks/nw:network/nt:link" { 900 when '/nw:networks/nw:network/nw:network-types/l2t:l2-network' { 901 description 902 "Augmentation parameters apply only for networks 903 with L2 topology."; 904 } 905 description 906 "Augments L2 topology link information."; 907 uses l2-link-attributes; 908 } 910 augment "/nw:networks/nw:network/nw:node/nt:termination-point" { 911 when '/nw:networks/nw:network/nw:network-types/l2t:l2-network' { 912 description 913 "Augmentation parameters apply only for networks 914 with L2 topology."; 915 } 916 description 917 "Augments L2 topology termination point information."; 918 uses l2-termination-point-attributes; 919 } 921 /* 922 * Notifications 923 */ 925 notification l2-node-event { 926 description 927 "Notification event for L2 node."; 928 leaf event-type { 929 type l2-network-event-type; 930 description 931 "Event type."; 932 } 933 uses nw:node-ref; 934 uses l2-network-type; 935 uses l2-node-attributes; 936 } 938 notification l2-link-event { 939 description 940 "Notification event for L2 link."; 941 leaf event-type { 942 type l2-network-event-type; 943 description 944 "Event type."; 945 } 946 uses nt:link-ref; 947 uses l2-network-type; 948 uses l2-link-attributes; 949 } 951 notification l2-termination-point-event { 952 description 953 "Notification event for L2 termination point."; 954 leaf event-type { 955 type l2-network-event-type; 956 description 957 "Event type."; 958 } 959 uses nt:tp-ref; 960 uses l2-network-type; 961 uses l2-termination-point-attributes; 962 } 963 } 964 966 5. IANA Considerations 968 This document requests IANA to register the following URIs in the 969 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 971 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology 972 Registrant Contact: The IESG. 973 XML: N/A; the requested URI is an XML namespace. 975 URI: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 976 Registrant Contact: The IESG. 977 XML: N/A; the requested URI is an XML namespace. 979 This document requests IANA to register the following YANG modules in 980 the "YANG Module Names" subregistry [RFC6020] within the "YANG 981 Parameters" registry. 983 name: ietf-l2-topology 984 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology 985 prefix: l2t 986 reference: RFC XXXX 988 name: ietf-l2-topology-state 989 namespace: urn:ietf:params:xml:ns:yang:ietf-l2-topology-state 990 prefix: l2t-s 991 reference: RFC XXXX 993 These modules are not maintained by IANA. 995 6. Security Considerations 997 The YANG module specified in this document defines a schema for data 998 that is designed to be accessed via network management protocols such 999 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1000 is the secure transport layer, and the mandatory-to-implement secure 1001 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1002 is HTTPS, and the mandatory-to-implement secure transport is TLS 1003 [RFC8446]. 1005 The Network Configuration Access Control Model (NACM) [RFC8341] 1006 provides the means to restrict access for particular NETCONF or 1007 RESTCONF users to a preconfigured subset of all available NETCONF or 1008 RESTCONF protocol operations and content. 1010 The Layer 2 topology module defines information that can be 1011 configurable in certain instances, for example in the case of virtual 1012 topologies that can be created by client applications. In such 1013 cases, a malicious client could introduce topologies that are 1014 undesired. Specifically, a malicious client could attempt to remove 1015 or add a node, a link, a termination point, by creating or deleting 1016 corresponding elements in the node, link, and termination point 1017 lists, respectively. In the case of a topology that is learned, the 1018 server will automatically prohibit such misconfiguration attempts. 1019 In the case of a topology that is configured, i.e. whose origin is 1020 "intended", the undesired configuration could become effective and be 1021 reflected in the operational state datastore, leading to disruption 1022 of services provided via this topology might be disrupted. For those 1023 reasons, it is important that the NETCONF access control model is 1024 vigorously applied to prevent topology misconfiguration by 1025 unauthorized clients. 1027 There are a number of data nodes defined in this YANG module that are 1028 writable/creatable/deletable (i.e., config true, which is the 1029 default). These data nodes may be considered sensitive or vulnerable 1030 in some network environments. Write operations (e.g., edit-config) 1031 to these data nodes without proper protection can have a negative 1032 effect on network operations. These are the subtrees and data nodes 1033 and their sensitivity/vulnerability: 1035 o l2-network-attributes: A malicious client could attempt to 1036 sabotage the configuration of any of the contained attributes, 1037 such as the name or the flag data nodes. 1039 o l2-node-attributes: A malicious client could attempt to sabotage 1040 the configuration of important node attributes, such as the name 1041 or the management-address. 1043 o l2-link-attributes: A malicious client could attempt to sabotage 1044 the configuration of important link attributes, such as the rate 1045 or the delay data nodes. 1047 o l2-termination-point-attributes: A malicious client could attempt 1048 to sabotage the configuration of important termination point 1049 attributes (e.g., 'maximum-frame-size'). 1051 Some of the readable data nodes in this YANG module may be considered 1052 sensitive or vulnerable in some network environments. It is thus 1053 important to control read access (e.g., via get, get-config, or 1054 notification) to these data nodes. In particular, the YANG model for 1055 layer 2 topology may expose sensitive information, for example the 1056 MAC addresses of devices. Unrestricted use of such information can 1057 lead to privacy violations. For example, listing MAC addresses in a 1058 network allows monitoring of devices and their movements. Location 1059 information can be derived from MAC addresses of network devices, 1060 bypassing protection of location information by the Operating System. 1062 7. Acknowledgements 1064 The authors would like to acknowledge the comments and suggestions 1065 received from Susan Hares, Alia Atlas, Juergen Schoenwaelder, Mach 1066 Chen, Alexander Clemm, Sriganesh Kini, Oscar Gonzalez de Dios, Stig 1067 Venaas, Christian Huitema, and Meral Shirazipour. 1069 Many thanks to Ladislav Lhotka for the yang-doctors review. 1071 8. References 1073 8.1. Normative References 1075 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1076 Requirement Levels", BCP 14, RFC 2119, 1077 DOI 10.17487/RFC2119, March 1997, 1078 . 1080 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1081 DOI 10.17487/RFC3688, January 2004, 1082 . 1084 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 1085 in Support of Generalized Multi-Protocol Label Switching 1086 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 1087 . 1089 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1090 LAN Service (VPLS) Using BGP for Auto-Discovery and 1091 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1092 . 1094 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1095 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1096 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1097 . 1099 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1100 the Network Configuration Protocol (NETCONF)", RFC 6020, 1101 DOI 10.17487/RFC6020, October 2010, 1102 . 1104 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1105 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1106 . 1108 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1109 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1110 . 1112 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1113 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1114 . 1116 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1117 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1118 . 1120 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1121 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1122 May 2017, . 1124 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1125 Access Control Model", STD 91, RFC 8341, 1126 DOI 10.17487/RFC8341, March 2018, 1127 . 1129 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 1130 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 1131 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 1132 2018, . 1134 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1135 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1136 . 1138 8.2. Informative References 1140 [I-D.ietf-trill-yang] 1141 Weiguo, H., Yizhou, L., Kumar, D., Durrani, M., Zhai, H., 1142 and L. Xia, "TRILL YANG Data Model", draft-ietf-trill- 1143 yang-04 (work in progress), December 2015. 1145 [I2RS-UR] Hares, S. and M. Chen, "Summary of I2RS Use Case 1146 Requirements", draft-ietf-i2rs-usecase-reqs-summary-03 1147 (work in progress), November 2016. 1149 [IEEE802.1AB] 1150 "Station and Media Access Control Connectivity Discovery", 1151 IEEE Std 802.1AB-2016, March 2016. 1153 [IEEE802.1ad] 1154 "Virtual Bridged Local Area Networks Amendment 4: Provider 1155 Bridges", IEEE Std 802.1ad-2005, May 2006. 1157 [IEEE802.1ah] 1158 "Virtual Bridged Local Area Networks Amendment 4: Provider 1159 Bridges", IEEE Std 802.1ah-2008, August 2008. 1161 [IEEE802.1Qcp] 1162 "Bridges and Bridged Networks - Amendment: YANG Data 1163 Model", IEEE Std 802.1Qcp-2018, September 2018. 1165 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1166 and A. Bierman, Ed., "Network Configuration Protocol 1167 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1168 . 1170 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1171 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1172 . 1174 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1175 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1176 eXtensible Local Area Network (VXLAN): A Framework for 1177 Overlaying Virtualized Layer 2 Networks over Layer 3 1178 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1179 . 1181 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1182 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1183 . 1185 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1186 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1187 . 1189 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1190 and R. Wilton, "Network Management Datastore Architecture 1191 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1192 . 1194 Appendix A. Companion YANG Module for Non-NMDA Compliant 1195 Implementations 1197 The YANG module ietf-l2-topology defined in this document augments 1198 two modules, "ietf-network" and "ietf-network-topology", that are 1199 designed to be used in conjunction with implementations that support 1200 the Network Management Datastore Architecture (NMDA) defined in 1202 [RFC8342]. In order to allow implementations to use the model even 1203 in cases when NMDA is not supported, a set of companion modules have 1204 been defined that represent a state model of networks and network 1205 topologies, "ietf-network-state" and "ietf-network-topology-state", 1206 respectively. 1208 In order to be able to use the model for layer 2 topologies defined 1209 in this document in conjunction with non-NMDA compliant 1210 implementations, a corresponding companion module is defined that 1211 represents the operational state of layer 2 network topologies. The 1212 module "ietf-l2-topology-state" mirrors the module "ietf-l2-topology" 1213 defined in Section 4. However, it augments "ietf-network-state" and 1214 "ietf-network-topology-state" (instead of "ietf-network" and "ietf- 1215 network-topology") and all its data nodes are non-configurable. 1217 The companion module "ietf-l2-topology" SHOULD NOT be supported by 1218 implementations that support NMDA. It is for this reason that this 1219 module is defined in the informative Appendix. 1221 As the structure of this modules mirrors that of its underlying 1222 modules, the YANG tree is not depicted separately. 1224 file "ietf-l2-topology-state@2020-06-29.yang" 1225 module ietf-l2-topology-state { 1226 yang-version 1.1; 1227 namespace "urn:ietf:params:xml:ns:yang:ietf-l2-topology-state"; 1228 prefix l2t-s; 1230 import ietf-network-state { 1231 prefix nw-s; 1232 reference 1233 "RFC 8345: A YANG Data Model for Network Topologies"; 1234 } 1235 import ietf-network-topology-state { 1236 prefix nt-s; 1237 reference 1238 "RFC 8345: A YANG Data Model for Network Topologies"; 1239 } 1240 import ietf-l2-topology { 1241 prefix l2t; 1242 reference 1243 "RFC XXXX: A YANG Data Model for Layer 2 Network 1244 Topologies"; 1245 } 1247 organization 1248 "IETF I2RS (Interface to the Routing System) Working Group"; 1249 contact 1250 "WG Web: 1251 WG List: 1253 Editor: Jie Dong 1254 1255 Editor: Xiugang Wei 1256 1257 Editor: Qin Wu 1258 1259 Editor: Mohamed Boucadair 1260 1261 Editor: Anders Liu 1262 "; 1263 description 1264 "This module defines a model for Layer 2 Network Topology 1265 state, representing topology that either is learned or 1266 results from applying topology that has been configured per 1267 the 'ietf-l2-topology' model, mirroring the 1268 corresponding data nodes in this model. 1270 This model mirrors 'ietf-l2-topology' but contains only 1271 read-only state data. The model is not needed when the 1272 underlying implementation infrastructure supports the 1273 Network Management Datastore Architecture (NMDA). 1275 Copyright (c) 2020 IETF Trust and the persons identified as 1276 authors of the code. All rights reserved. 1278 Redistribution and use in source and binary forms, with or 1279 without modification, is permitted pursuant to, and subject 1280 to the license terms contained in, the Simplified BSD License 1281 set forth in Section 4.c of the IETF Trust's Legal Provisions 1282 Relating to IETF Documents 1283 (http://trustee.ietf.org/license-info). 1285 This version of this YANG module is part of RFC XXXX; see 1286 the RFC itself for full legal notices."; 1288 revision 2020-06-29 { 1289 description 1290 "Initial revision"; 1291 reference 1292 "RFC XXXX: A YANG Data Model for Layer 2 Network 1293 Topologies"; 1294 } 1296 /* 1297 * Data nodes 1298 */ 1300 augment "/nw-s:networks/nw-s:network/nw-s:network-types" { 1301 description 1302 "Introduces a new network type for L2 topology."; 1303 uses l2t:l2-network-type; 1304 } 1306 augment "/nw-s:networks/nw-s:network" { 1307 when '/nw-s:networks/nw-s:network/nw-s:network-types/' 1308 + 'l2t-s:l2-network' { 1309 description 1310 "Augmentation parameters apply only for networks 1311 with L2 topology."; 1312 } 1313 description 1314 "Configuration parameters for the L2 network 1315 as a whole."; 1316 uses l2t:l2-network-attributes; 1317 } 1319 augment "/nw-s:networks/nw-s:network/nw-s:node" { 1320 when '../nw-s:network-types/l2t-s:l2-network' { 1321 description 1322 "Augmentation parameters apply only for networks 1323 with L2 topology."; 1324 } 1325 description 1326 "Configuration parameters for L2 at the node 1327 level."; 1328 uses l2t:l2-node-attributes; 1329 } 1331 augment "/nw-s:networks/nw-s:network/nt-s:link" { 1332 when '../nw-s:network-types/l2t-s:l2-network' { 1333 description 1334 "Augmentation parameters apply only for networks 1335 with L2 topology."; 1336 } 1337 description 1338 "Augments L2 topology link information."; 1339 uses l2t:l2-link-attributes; 1340 } 1342 augment "/nw-s:networks/nw-s:network/nw-s:node/" 1343 + "nt-s:termination-point" { 1344 when '../../nw-s:network-types/l2t-s:l2-network' { 1345 description 1346 "Augmentation parameters apply only for networks 1347 with L2 topology."; 1348 } 1349 description 1350 "Augments L2 topology termination point information."; 1351 uses l2t:l2-termination-point-attributes; 1352 } 1354 /* 1355 * Notifications 1356 */ 1358 notification l2-node-event { 1359 description 1360 "Notification event for L2 node."; 1361 leaf event-type { 1362 type l2t:l2-network-event-type; 1363 description 1364 "Event type."; 1365 } 1366 uses nw-s:node-ref; 1367 uses l2t:l2-network-type; 1368 uses l2t:l2-node-attributes; 1369 } 1371 notification l2-link-event { 1372 description 1373 "Notification event for a L2 link."; 1374 leaf event-type { 1375 type l2t:l2-network-event-type; 1376 description 1377 "Event type."; 1378 } 1379 uses nt-s:link-ref; 1380 uses l2t:l2-network-type; 1381 uses l2t:l2-link-attributes; 1382 } 1384 notification l2-termination-point-event { 1385 description 1386 "Notification event for L2 termination point."; 1387 leaf event-type { 1388 type l2t:l2-network-event-type; 1389 description 1390 "Event type."; 1391 } 1392 uses nt-s:tp-ref; 1393 uses l2t:l2-network-type; 1394 uses l2t:l2-termination-point-attributes; 1395 } 1396 } 1397 1399 Appendix B. An Example 1401 This section contains an example of an instance data tree in JSON 1402 encoding [RFC7951]. The example instantiates "ietf-l2- topology" for 1403 the topology that is depicted in the following diagram. There are 1404 three nodes: D1, D2, and D3. D1 has three termination points: 1-0-1, 1405 1-2-1, and 1-3-1. D2 has three termination points as well: 2-1-1, 1406 2-0-1, and 2-3-1. D3 has two termination points: 3-1-1 and 3-2-1. 1407 In addition, there are six links, two between each pair of nodes, 1408 with one going in each direction. 1410 +------------+ +------------+ 1411 | D1 | | D2 | 1412 /-\ /-\ /-\ /-\ 1413 | | 1-0-1 | |---------------->| | 2-1-1 | | 1414 | | 1-2-1 | |<----------------| | 2-0-1 | | 1415 \-/ 1-3-1 \-/ \-/ 2-3-1 \-/ 1416 | /----\ | | /----\ | 1417 +---| |---+ +---| |---+ 1418 \----/ \----/ 1419 A | A | 1420 | | | | 1421 | | | | 1422 | | +------------+ | | 1423 | | | D3 | | | 1424 | | /-\ /-\ | | 1425 | +----->| | 3-1-1 | |-------+ | 1426 +---------| | 3-2-1 | |<---------+ 1427 \-/ \-/ 1428 | | 1429 +------------+ 1431 Figure 2. A Network Topology Example 1433 The corresponding instance data tree is depicted below: 1435 { 1436 "ietf-network:networks": { 1437 "network": [ 1438 { 1439 "network-types": { 1440 "ietf-l2-topology:l2-network": {} 1441 }, 1442 "network-id": "l2-topo-example", 1443 "node": [ 1444 { 1445 "node-id": "D1", 1446 "ietf-network-topology:termination-point": [ 1447 { 1448 "tp-id": "1-0-1", 1449 "ietf-l2-topology:l2-termination-point-attributes": { 1450 "mac-address": "00:00:5E:00:53:D0" 1451 } 1452 }, 1453 { 1454 "tp-id": "1-2-1", 1455 "ietf-l2-topology:l2-termination-point-attributes": { 1456 "mac-address": "00:00:5E:00:53:D1" 1457 } 1458 }, 1459 { 1460 "tp-id": "1-3-1", 1461 "ietf-l2-topology:l2-termination-point-attributes": { 1462 "mac-address": "00:00:5E:00:53:D2" 1463 } 1464 } 1465 ], 1466 "ietf-l2-topology:l2-node-attributes": { 1467 "management-address": [ 1468 "192.0.2.1" 1469 ] 1470 } 1471 }, 1472 { 1473 "node-id": "D2", 1474 "ietf-network-topology:termination-point": [ 1475 { 1476 "tp-id": "2-0-1", 1477 "ietf-l2-topology:l2-termination-point-attributes": { 1478 "mac-address": "00:00:5E:00:53:E0" 1479 } 1480 }, 1481 { 1482 "tp-id": "2-1-1", 1483 "ietf-l2-topology:l2-termination-point-attributes": { 1484 "mac-address": "00:00:5E:00:53:E1" 1485 } 1486 }, 1487 { 1488 "tp-id": "2-3-1", 1489 "ietf-l2-topology:l2-termination-point-attributes": { 1490 "mac-address": "00:00:5E:00:53:E2" 1491 } 1492 } 1493 ], 1494 "ietf-l2-topology:l2-node-attributes": { 1495 "management-address": [ 1496 "192.0.2.2" 1497 ] 1498 } 1499 }, 1500 { 1501 "node-id": "D3", 1502 "ietf-network-topology:termination-point": [ 1503 { 1504 "tp-id": "3-1-1", 1505 "ietf-l2-topology:l2-termination-point-attributes": { 1506 "mac-address": "00:00:5E:00:53:F0" 1507 } 1508 }, 1509 { 1510 "tp-id": "3-2-1", 1511 "ietf-l2-topology:l2-termination-point-attributes": { 1512 "mac-address": "00:00:5E:00:53:F1" 1513 } 1514 } 1515 ], 1516 "ietf-l2-topology:l2-node-attributes": { 1517 "management-address": [ 1518 "192.0.2.3" 1519 ] 1520 } 1521 } 1522 ], 1523 "ietf-network-topology:link": [ 1524 { 1525 "link-id": "D1,1-2-1,D2,2-1-1", 1526 "source": { 1527 "source-node": "D1", 1528 "source-tp": "1-2-1" 1529 }, 1530 "destination": { 1531 "dest-node": "D2", 1532 "dest-tp": "2-1-1" 1533 }, 1534 "ietf-l2-topology:l2-link-attributes": { 1535 "rate": "1000" 1536 } 1537 }, 1538 { 1539 "link-id": "D2,2-1-1,D1,1-2-1", 1540 "source": { 1541 "source-node": "D2", 1542 "source-tp": "2-1-1" 1543 }, 1544 "destination": { 1545 "dest-node": "D1", 1546 "dest-tp": "1-2-1" 1547 }, 1548 "ietf-l2-topology:l2-link-attributes": { 1549 "rate": "1000" 1550 } 1551 }, 1552 { 1553 "link-id": "D1,1-3-1,D3,3-1-1", 1554 "source": { 1555 "source-node": "D1", 1556 "source-tp": "1-3-1" 1557 }, 1558 "destination": { 1559 "dest-node": "D3", 1560 "dest-tp": "3-1-1" 1561 }, 1562 "ietf-l2-topology:l2-link-attributes": { 1563 "rate": "1000" 1564 } 1565 }, 1566 { 1567 "link-id": "D3,3-1-1,D1,1-3-1", 1568 "source": { 1569 "source-node": "D3", 1570 "source-tp": "3-1-1" 1571 }, 1572 "destination": { 1573 "dest-node": "D1", 1574 "dest-tp": "1-3-1" 1575 }, 1576 "ietf-l2-topology:l2-link-attributes": { 1577 "rate": "1000" 1578 } 1579 }, 1580 { 1581 "link-id": "D2,2-3-1,D3,3-2-1", 1582 "source": { 1583 "source-node": "D2", 1584 "source-tp": "2-3-1" 1585 }, 1586 "destination": { 1587 "dest-node": "D3", 1588 "dest-tp": "3-2-1" 1589 }, 1590 "ietf-l2-topology:l2-link-attributes": { 1591 "rate": "1000" 1592 } 1593 }, 1594 { 1595 "link-id": "D3,3-2-1,D2,2-3-1", 1596 "source": { 1597 "source-node": "D3", 1598 "source-tp": "3-2-1" 1599 }, 1600 "destination": { 1601 "dest-node": "D2", 1602 "dest-tp": "2-3-1" 1603 }, 1604 "ietf-l2-topology:l2-link-attributes": { 1605 "rate": "1000" 1606 } 1607 } 1608 ] 1609 } 1610 ] 1611 } 1612 } 1614 Authors' Addresses 1616 Jie Dong 1617 Huawei 1618 Huawei Campus, No. 156 Beiqing Rd. 1619 Beijing 100095 1620 China 1622 Email: jie.dong@huawei.com 1624 Xiugang Wei 1625 Huawei 1626 Huawei Campus, No. 156 Beiqing Rd. 1627 Beijing 100095 1628 China 1630 Email: weixiugang@huawei.com 1631 Qin Wu 1632 Huawei 1633 101 Software Avenue, Yuhua District 1634 Nanjing 210012 1635 China 1637 Email: bill.wu@huawei.com 1639 Mohamed Boucadair 1640 Orange 1641 Rennes 35000 1642 France 1644 Email: mohamed.boucadair@orange.com 1646 Anders Liu 1647 Tecent 1648 Yinke Building 38 Haidian St, Haidian District 1649 Beijing 100080 1650 China 1652 Email: andersliu@tencent.com