idnits 2.17.1 draft-zhang-i2rs-l1-topo-yang-model-01.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 32 has weird spacing: '... months and ...' == Line 33 has weird spacing: '... at any time...' == Line 34 has weird spacing: '...ference mate...' == Line 144 has weird spacing: '...opo-ref lea...' == Line 155 has weird spacing: '...ace-ref lea...' == (7 more instances...) -- The document date (March 9, 2015) is 3335 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) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 I2RS Working Group Xian Zhang 2 Internet-Draft Baoquan Rao 3 Intended status: Standards Track Huawei 4 Xufeng Liu 5 Ericsson 7 Expires: September 9, 2015 March 9, 2015 9 A YANG Data Model for Layer 1 Network Topology 11 draft-zhang-i2rs-l1-topo-yang-model-01.txt 13 Abstract 15 This draft describes a YANG data model to manipulate the topologies 16 of a layer 1 network. It is independent of data plan technologies 17 and control plane protocols. It can be augmented to include 18 technology-specific data, such as for Optical Transport Networks 19 (OTN). 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with 24 the provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet-Drafts 34 as reference material or to cite them other than as "work in 35 progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 9, 2015. 45 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction ................................................ 2 62 2. Conventions used in this document............................ 3 63 3. Terminology and Notations.................................... 3 64 4. YANG Data Model for Layer 1 Topology......................... 4 65 4.1. YANG Tree ............................................. 4 66 4.1.1. The node and link list............................. 5 67 4.1.2. Notification....................................... 5 68 4.2. YANG Code .............................................. 5 69 5. Security Considerations .....................................21 70 6. Manageability Considerations ................................21 71 7. IANA Considerations ........................................ 21 72 8. Acknowledgements ........................................... 21 73 9. References ................................................. 22 74 9.1. Normative References .................................. 22 75 9.2. Informative References ................................ 22 76 10. Contributors' Addresses ....................................22 77 11. Authors' Addresses .........................................22 79 1. Introduction 81 This document defines a data model of a layer one network topology, 82 using YANG [RFC6020]. The model can be used by an application via 83 the I2RS interface [draft-ietf-i2rs-architecture], in the following 84 ways (but not limited to): 86 o to obtain a whole view of the network topology information of 87 its interest; 89 o to receive notifications with regard to the information of the 90 change of the network topology of its interest; 91 o to enforce the establishment/update of a network topology with 92 the characteristic specified in the data model; 94 This model is confined to describe layer 1 networks, but it is data 95 plane technology independent and can be augmented to specify the 96 topology for networks such as Optical Transport networks (OTN), 97 Synchronous Digital Network/ (SDH/SONET) DWDM (Dense Wavelength 98 Division Multiplexing). 100 [Editor's Note: The authors are aware that there are other drafts 101 closely relating to this draft. Coordination works have been 102 undergoing to get these drafts aligned. The authors are working on 103 obtaining layer one topology by augmenting the data model proposed 104 in draft-clemm-i2rs-yang-network-topo in the next version of this 105 draft.] 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC-2119 [RFC2119]. 113 3. Terminology and Notations 115 A simplified graphical representation of the data model is used in 116 this document. The meaning of the symbols in the YANG data tree 117 presented later in this draft is defined in [ietf-netmod-rfc6087bis]. 118 They are provided below for reference. 120 o Brackets "[" and "]" enclose list keys. 122 o Abbreviations before data node names: "rw" means configuration 123 (read-write) and "ro" state data (read-only). 125 o Symbols after data node names: "?" means an optional node, "!" 126 means a presence container, and "*" denotes a list and leaf-list. 128 o Parentheses enclose choice and case nodes, and case nodes are 129 also marked with a colon (":"). 131 o Ellipsis ("...") stands for contents of subtrees that are not 132 shown. 134 4. YANG Data Model for Layer 1 Topology 136 4.1. YANG Tree 138 module: ietf-layer1topology 139 +--rw layer-one-topology 140 +--rw topology* [topology-id] 141 +--rw topology-id topology-id 142 +--rw name? string 143 +--rw supporting-topology* [topo-ref] 144 | +--rw topo-ref leafref 145 +--rw node* [node-id] 146 | +--rw node-id node-id 147 | +--rw interface* [interface-id] 148 | | +--rw interface-id interface-id 149 | | +--rw interface-name? if:interface-state-ref 150 | | +--rw adaptation-capability 151 | +--rw connectivity-matrix* [id] 152 | +--rw id uint32 153 | +--rw type? enumeration 154 | +--rw in-interface* [interface-ref] 155 | | +--rw interface-ref leafref 156 | +--rw out-interface* [interface-ref] 157 | | +--rw interface-ref leafref 158 | +--rw dir? enumeration 159 +--rw link* [link-id] 160 +--rw link-id link-id 161 +--rw local 162 | +--rw local-node leafref 163 | +--rw local-interface leafref 164 +--rw remote 165 | +--rw remote-node leafref 166 | +--rw remote-interface leafref 167 +--rw supporting-path* [supporting-path-index] 168 | +--rw supporting-path-index uint32 169 | +--rw topo-ref? leafref 170 | +--rw server-path-identifier 171 | +--rw server-path-srlg 172 | +--rw srlg-values* [srlg-value] 173 | +--rw srlg-value uint32 174 +--rw attributes 175 +--ro information-source? enumeration 176 +--ro credibility-preference? uint16 177 +--rw admin-status? enumeration 178 +--ro oper-status? enumeration 179 +--rw area-id? binary 180 +--rw max-link-bandwidth? decimal64 181 +--rw unreserved-bandwidth* [priority] 182 | +--rw priority uint8 183 | +--rw bandwidth? decimal64 184 +--ro distance? uint32 185 +--rw te-metric? uint32 186 +--rw link-protection-type? enumeration 187 +--rw switching-capability? switching- 188 capabilities 189 +--rw encoding? encoding-types 190 +--rw switching-capability-specific 191 +--rw srlg 192 +--rw srlg-values* [srlg-value] 193 +--rw srlg-value uint32 194 notifications: 195 +---n link-failure 196 | +--ro topology-id leafref 197 | +--ro link-id leafref 198 | +--ro admin-status? leafref 199 | +--ro oper-status leafref 200 +---n node-failure 201 +--ro topology-id leafref 202 +--ro link-id leafref 204 4.1.1. The node and link list 205 The Layer One Topology module contains all the nodes and links 206 information pertaining to a layer one network. The node is 207 identified by the node-id, which is unique within the network. 208 Within the nodes, all the interfaces pertaining to this node and 209 their potential capabilities/constraints SHOULD be present. Besides 210 this, the constraints associated with a node as a whole SHOULD also 211 be present, such as the connectivity constraints introduced due to 212 abstraction or due to the hardware limitations. The link is 213 identified by the link-id, which is unique within a node. It 214 includes the association with nodes as well as interfaces. Moreover, 215 it includes information that is of interest to the I2RS client, for 216 purposes, such as path computation, monitoring etc. 218 4.1.2. Notification 220 Two types of notifications are introduced: node failure and link 221 failure. 223 4.2. YANG Code 225 file "l1topo.yang" 226 module ietf-layer1topology { 227 yang-version 1; 229 namespace 230 "urn:ietf:params:xml:ns:yang:ietf-layer1topology"; 231 prefix "l1topo"; 233 import ietf-inet-types { 234 prefix "inet"; 235 } 236 import ietf-interfaces { 237 prefix "if"; 238 } 240 organization 241 "Internet Engineering Task Force (IETF) I2RS WG"; 242 contact 243 "ID-draft editor: zhang.xian@huawei.com"; 245 description 246 "This module defines a data-plan technology/protocol 247 independent Layer One topology data model."; 249 revision 2015-03-09 { 250 description 251 "Initial version."; 252 reference 253 "draft-zhang-i2rs-l1-topo-yang-model-01.txt"; 254 } 256 /* 257 * Typedefs 258 */ 260 typedef topology-id { 261 type inet:uri; 262 description "the identifier for a topology"; 263 } 265 typedef node-id { 266 type inet:ip-address; 267 description 268 "the identifier for a node"; 269 } 271 typedef interface-id { 272 type union { 273 type inet:ip-address; // IPv4 or IPv6 address 274 type int32; // Un-numbered 275 } 276 description 277 "the identifier of an interface within a node, supporting both 278 numbered/unnumbered"; 279 } 281 typedef link-id { 282 type inet:ip-address; // IPv4 or IPv6 address 283 description "the identifier of a link"; 284 } 286 typedef switching-capabilities { 287 type enumeration { 288 enum "psc-1" { 289 value 1; 290 description 291 "Packet-Switch Capable-1 (PSC-1)"; 292 } 293 enum "evpl" { 294 value 30; 295 description 296 "Ethernet Virtual Private Line (EVPL)"; 297 } 299 enum "pbb-te"{ 300 value 40; 301 description 302 "802_1 PBB-TE"; 303 } 305 enum "l2sc" { 306 value 51; 307 description 308 "Layer-2 Switch Capable (L2SC)"; 309 } 310 enum "tdm" { 311 value 100; 312 description 313 "Time-Division-Multiplex Capable (TDM)"; 314 } 315 enum "otn-tdm" { 316 value 110; 317 description 318 "OTN-TDM Capable"; 319 } 320 enum "lsc" { 321 value 150; 322 description 323 "Lambda-Switch Capable (LSC)"; 324 } 325 enum "fsc" { 326 value 200; 327 description 328 "Fiber-Switch Capable (FSC)"; 329 } 330 } 332 description 333 "Switching capability of an interface. 334 Only a subset of the above-mentioned values are applicable 335 to Layer 1 network. 336 Here it is included for completeness and will later be 337 updated if a base model is augmented to create layer 1 338 network topology YANG data model."; 340 reference 341 "The definition of switching types, their values and the 342 relevant RFCs can be found at: 343 http://www.iana.org/assignments/gmpls-sig-parameters/gmpls 344 -sig-parameters.xhtml#gmpls-sig-parameters-3"; 345 } 347 typedef encoding-types { 348 type enumeration { 349 enum "packet" { 350 value 1; 351 description "Packet"; 352 } 353 enum "ethernet" { 354 value 2; 355 description "Ethernet"; 356 } 357 enum "pdh" { 358 value 3; 359 description "PDH"; 360 } 361 enum "sdh-sonet" { 362 value 5; 363 description "SDH/SONET"; 364 } 365 enum "digital-wrapper" { 366 value 7; 367 description "Digital Wrapper"; 368 } 369 enum "lambda" { 370 value 8; 371 description "Lambda(photonic)"; 372 } 373 enum "fiber" { 374 value 9; 375 description "Fiber"; 376 } 377 enum "fiber-channel" { 378 value 11; 379 description "FiberChannel"; 380 } 381 enum "oduk" { 382 value 12; 383 description 384 "G.709 OKUk (Digital Path)"; 385 } 386 enum "optical-channel" { 387 value 13; 388 description "G.709 Optical Channel"; 389 } 390 enum "line" { 391 value 14; 392 description "Line (e.g., 8B/10B)"; 393 } 394 } 395 description 396 "The encoding type supported by an interface or link. 397 Not all encoding types are applicable to Layer one network 398 nodes. They are included here for completeness and will be 399 updated if a base model is available to augment 400 so as to build a layer-one specific YANG data model."; 401 reference 402 "The definition of encoding types, their values and the 403 relevant RFCs can be found at http://www.iana.org/ 404 assignments/gmpls-sig-parameters/gmpls-sig-parameters.xhtml# 405 gmpls-sig-parameters-3"; 406 } 408 /* 409 * Groupings 410 */ 412 grouping srlg-attribute { 413 description 414 "Shared Risk Link Group Attributes"; 415 reference 416 "RFC 4203: OSPF Extensions in Support of Generalized 417 Multi-Protocol Label Switching (GMPLS)"; 418 list srlg-values { 419 key "srlg-value"; 420 leaf srlg-value { 421 type uint32; 422 description "SRLG value"; 423 } 424 description 425 "the SRLG value list"; 426 } 427 } 429 /* 430 * Configuration data nodes 431 */ 433 container layer-one-topology { 434 description 435 "this container holds all the inforamtion to layer 436 one network. It includes one or multiple topologies"; 438 list topology { 439 key "topology-id"; 441 description 442 "This contains all the information to one topoogy"; 444 leaf topology-id { 445 type topology-id; 446 description "topology identifier"; 447 } 449 leaf name { 450 type string; 451 description "topology name"; 452 } 454 list supporting-topology { 455 key "topo-ref"; 456 leaf topo-ref { 457 type leafref { 458 path "/layer-one-topology/topology/topology-id"; 459 } 460 description 461 "a Layer-One network might be supported by a lower 462 layer network and this is a pointer to the suporting 463 topology if there is one"; 464 } 465 description "underlaying topology information"; 466 } 468 list node { 469 key "node-id"; 470 description "the list of nodes within the topology"; 472 leaf node-id { 473 type node-id; 474 description "node identifier"; 475 } 477 list interface { 478 key "interface-id"; 479 leaf interface-id { 480 type interface-id; 481 description "interface identifier"; 482 } 483 leaf interface-name { 484 type if:interface-state-ref; 485 description 486 "Name of the incoming interface."; 487 } 488 container adaptation-capability { 489 description 490 "TBD -to add for technology specific information"; 491 } 492 description "interface list pertaining to a node"; 493 } 495 list connectivity-matrix { 496 key "id"; 498 description 499 "This describes the connectivity contraints within 500 a node in the network. It can be one matrix or a set 501 of matrixes. Further details, read the reference 502 provided below."; 503 reference 504 "https://tools.ietf.org/html/draft-ietf-ccamp-general 505 -constraint-encode-16 Section 2.1"; 507 leaf id { 508 type uint32; 509 description "matrix id"; 510 } 511 leaf type { 512 type enumeration { 513 enum fixed { 514 value 0; 515 description "Fixed"; 516 } 517 enum dynamic { 518 value 1; 519 description "Dynamic/changeable"; 520 } 521 } 522 description 523 "This field describes the attribute of a 524 connectivity matrix, i.e., whether it is 525 fixed or switched."; 526 } 527 list in-interface { 528 key "interface-ref"; 530 description 531 "This list describes a (sub)-set of ingoing 532 interfaces within a node that may have 533 connectivity constraints. 534 Note: directionality may not be relevant 535 and it is decided by the dir parameter."; 537 leaf interface-ref { 538 type leafref { 539 path "/layer-one-topology/topology/node/" + 540 "interface/interface-id"; 541 } 542 description "reference to an incoming interface"; 543 } 544 } 545 list out-interface { 546 key "interface-ref"; 548 description 549 "This list describes a (sub)-set of outgoing 550 interfaces within a node that may have 551 connectivity constraints. 552 Note: directionality may not be relevant and 553 it is decided by the dir parameter."; 555 leaf interface-ref { 556 type leafref { 557 path "/layer-one-topology/topology/node/"+ 558 "interface/interface-id"; 559 } 560 description "reference to an outgoing interface"; 561 } 562 } 563 leaf dir{ 564 type enumeration{ 565 enum "uni-dir"{ 566 description 567 "the matrix is unidirectional."; 568 } 569 enum "bi-dir"{ 570 description 571 "this matrix is bidirecdtional."; 572 } 573 } 574 description 575 "the directionality attribute of a connc. matrix."; 576 } 577 } 578 }// end of node data node 580 list link { 581 key "link-id"; 583 description "list of the links within a topology"; 585 leaf link-id { 586 type link-id; 587 description 588 "remaining issue: if there is no IP addresses 589 associated with this link, what would be the key?"; 590 } 592 container local { 593 description "near end information for this link"; 595 leaf local-node { 596 type leafref { 597 path "/l1topo:layer-one-topology/topology"+ 598 "/node/node-id"; 599 } 600 mandatory true; 601 description "refence to the local node"; 603 } 604 leaf local-interface { 605 type leafref { 606 path "/l1topo:layer-one-topology/topology/node/" 607 +"interface/interface-id"; 608 } 609 mandatory true; 610 description "reference to the local interface"; 611 } 612 } 613 container remote { 614 description "far end information of this link"; 616 leaf remote-node { 617 type leafref { 618 path "/l1topo:layer-one-topology/topology"+ 619 "/node/node-id"; 620 } 621 mandatory true; 622 description "reference to the remote node"; 623 } 624 leaf remote-interface { 625 type leafref { 626 path "/l1topo:layer-one-topology/topology/node/" 627 + "interface/interface-id"; 628 } 629 mandatory true; 630 description "reference to the remote interface"; 631 } 632 } 633 list supporting-path { 634 key "supporting-path-index"; 636 description 637 "information pertaining to the underlying path if 638 there is any"; 640 leaf supporting-path-index { 641 type uint32; 642 description "the identifer of the supporting path"; 643 } 644 leaf topo-ref { 645 type leafref { 646 path "/l1topo:layer-one-topology/"+ 647 "topology/topology-id"; 648 } 649 description "reference to the underlying topology"; 651 } 652 container server-path-identifier { 653 description "TBD"; 654 } 655 container server-path-srlg { 656 uses srlg-attribute; 657 description "the SRLG values of the server path"; 658 } 659 } 661 container attributes { 663 description "additional information of the link"; 665 leaf information-source { 666 type enumeration { 667 enum "unknown" { 668 description "The source is unknown"; 669 } 670 enum "locally-configured" { 671 description "Configured TE link"; 672 } 673 enum "ospfv2" { 674 description "OSPFv2"; 675 } 676 enum "ospfv3" { 677 description "OSPFv3"; 678 } 679 enum "isis" { 680 description "ISIS"; 681 } 682 } 683 config false; 685 description 686 "Indicates the source of the information about 687 the link. remaining issue: if configuration of 688 a link is allowed, what additional types are 689 needed to add?"; 690 } 691 leaf credibility-preference { 692 type uint16; 693 config false; 694 description "the level of credibility"; 695 } 696 leaf admin-status { 697 type enumeration { 698 enum up { 699 value 1; 700 description "up"; 701 } 702 enum down { 703 value 2; 704 description "down"; 705 } 706 enum testing { 707 value 3; 708 description "testing - in some test mode."; 709 } 710 } 711 description 712 "The adminstrative state of the link."; 713 reference 714 "RFC2863: The Interfaces Group MIB."; 715 } 716 leaf oper-status { 717 type enumeration { 718 enum up { 719 value 1; 720 description "up"; 721 } 722 enum down { 723 value 2; 724 description "down"; 725 } 726 enum testing { 727 value 3; 728 description "testing - in some test mode"; 729 } 730 enum unknown { 731 value 4; 732 description "unknown - status cannot be 733 determined for some reason."; 734 } 735 enum dormant{ 736 value 5; 737 description "dormant"; 738 } 739 } 740 config false; 741 description 742 "The current operational state of the link."; 743 reference 744 "RFC2863: The Interfaces Group MIB."; 746 } 747 leaf area-id { 748 type binary { 749 length 1..13; 750 } 751 description 752 "This object indicates the area identifier of 753 the IGP. If OSPF is used to advertise LSA, 754 this represents an ospfArea. If IS-IS is used, 755 this represents an area address. 756 Otherwise, this is zero."; 757 reference 758 "RFC4920: Crankback Signaling Extensions for MPLS 759 and GMPLS RSVP-TE."; 760 } 762 leaf max-link-bandwidth { 763 type decimal64 { 764 fraction-digits 2; 765 } 766 description 767 "the max bandwidth supported by this link"; 768 } 770 list unreserved-bandwidth { 771 key "priority"; 772 max-elements "8"; 774 description 775 "This describes the unreserved bandwidth (in 776 Bytes/second) on a level basis ( level 0-7)."; 778 leaf priority { 779 type uint8{ 780 range "0..7"; 781 } 782 description "priority level"; 783 } 784 leaf bandwidth { 785 type decimal64 { 786 fraction-digits 2; 787 } 788 description "badnwidth per priority"; 789 } 790 } 792 leaf distance { 793 type uint32; 794 units "kilometers"; 796 config false; 797 description 798 "the distance this link spans."; 799 } 800 leaf te-metric { 801 type uint32; 802 description "the metric supported by the link"; 803 } 805 leaf link-protection-type { 806 type enumeration { 807 enum "extra-traffic" { 808 value 1; 809 description "Extra traffic"; 810 } 811 enum "unprotected" { 812 value 2; 813 description "unprotected"; 814 } 815 enum "shared" { 816 value 4; 817 description "Shared"; 818 } 819 enum "1-for-1" { 820 value 8; 821 description "Dedicated one for one protection"; 822 } 823 enum "1-plus-1" { 824 value 16; 825 description "Dedicated one plus one protection"; 826 } 827 enum "enhanced" { 828 value 32; 829 description "a protection type that is 830 more reliable than Dedicated 1+1, 831 e.g.,4 fiber BLSR/MS-SPRING."; 832 } 833 } 834 description 835 "Link Protection Type configured for this link"; 836 reference 837 "RFC3471: Generalized MUlti-Protocol Label 838 Switching (GMPLS) Signaling Functional 839 Description."; 841 } 843 leaf switching-capability { 844 type switching-capabilities; 845 description 846 "the switching capability supported by the link"; 847 } 848 leaf encoding { 849 type encoding-types; 850 description 851 "the encoding type supported by this link."; 852 } 854 container switching-capability-specific { 855 description 856 "TBD - to add for technology specific information"; 857 } 858 container srlg { 859 uses srlg-attribute; 860 description " the SRLG values of a link"; 861 } 862 }// end of link attributes 863 }// end of link leaf data node 864 } 865 }// end of configuring data nodes 867 /* 868 * notifications - only provide operational change information. 869 * reply to topology/node/link creation is acked via rpc-reply. 870 */ 872 notification link-failure { 873 leaf topology-id { 874 type leafref { 875 path "/layer-one-topology/topology/topology-id"; 876 } 877 mandatory true; 878 description ""; 879 } 880 leaf link-id { 881 type leafref { 882 path 883 "/layer-one-topology/topology[topology-id="+ 884 "current ()/../topology-id]/link/link-id"; 885 } 886 mandatory true; 887 description ""; 889 } 890 leaf admin-status { 891 type leafref { 892 path 893 "/layer-one-topology/topology/link[link-id =" + 894 "current()/../link-id]/attributes/admin-status"; 895 } 896 description ""; 897 } 898 leaf oper-status { 899 type leafref { 900 path 901 "/layer-one-topology/topology/" + 902 "link[link-id = current()/../link-id]" 903 + "/attributes/oper-status"; 904 } 905 mandatory true; 906 description ""; 907 } 908 description 909 "link failure information"; 910 } //notification 912 notification node-failure { 913 leaf topology-id { 914 type leafref { 915 path "/layer-one-topology/topology/topology-id"; 916 } 917 mandatory true; 918 description ""; 919 } 920 leaf link-id { 921 type leafref { 922 path 923 "/layer-one-topology/topology[topology-id= " 924 + "current ()/../topology-id]/node/node-id"; 925 } 926 mandatory true; 927 description ""; 928 } 929 description 930 "node failure information"; 931 } //notification 932 }//module 934 935 5. Security Considerations 937 Since the data model defined in this draft is manipulated vis the 938 I2RS interface. The security concerns mentioned in [draft-ietf-i2rs- 939 architecture] also applies to this draft. 941 The YANG module defined in this memo is designed to be accessed via 942 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 943 secure transport layer and the mandatory-to-implement secure 944 transport is SSH [RFC6242]. The NETCONF access control model 945 [RFC6536] provides the means to restrict access for particular 946 NETCONF users to a pre-configured subset of all available NETCONF 947 protocol operations and content. 949 There are a number of data nodes defined in the YANG module which 950 are writable/creatable/deletable (i.e., config true, which is the 951 default). These data nodes may be considered sensitive or ulnerable 952 in some network environments. Write operations (e.g., ) 953 to these data nodes without proper protection can have a negative 954 effect on network operations. 956 [Editor's note: to List specific subtrees and data nodes and their 957 sensitivity/vulnerability.] 959 6. Manageability Considerations 961 TBD. 963 7. IANA Considerations 965 TBD. 967 8. Acknowledgements 969 The initial YANG model specified in this draft is based on draft- 970 clemm-i2rs-yang-network-topo but it is modified according to the 971 features of the layer one networks. 973 We would like to thank the authors of the above mentioned draft for 974 their helpful discussion during the creation of this draft. 976 9. References 978 9.1. Normative References 980 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 981 requirements levels", RFC 2119, March 1997. 983 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 984 Network Configuration Protocol (NETCONF)", RFC 6020, 985 October 2010. 987 9.2. Informative References 989 [draft-ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., 990 Ward, D., Nadeau T., "An Architecture for the Interface to 991 the Routing System", draft-ietf-i2rs-architecture-08, work 992 in progress, January 2015; 994 [draft-clemm-i2rs-yang-network-topo] Clemm A., Medved J., Tkacik T., 995 Varga R., et al, "A YANG Data Model for Network 996 Topologies", draft-clemm-i2rs-yang-network-topo-01, work 997 in progress, October 2014; 999 [ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors and 1000 Reviewers of YANG Data Model Documents", draft-ietf- 1001 netmod-rfc6087bis-01, work in progress, October 2014. 1003 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1004 Bierman, "Network Configuration Protocol (NETCONF)", 1005 RFC6241, June 2011. 1007 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1008 Shell (SSH)", RFC 6242, June 2011. 1010 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1011 Protocol (NETCONF) Access Control Model", RFC 6536, March 1012 2012. 1014 10. Contributors' Addresses 1016 TBD. 1018 11. Authors' Addresses 1020 Xian Zhang 1021 Huawei Technologies 1022 Email: zhang.xian@huawei.com 1023 Baoquan Rao 1024 Huawei Technologies 1025 raobaoquan@huawei.com 1027 Xufeng Liu 1028 Ericsson 1029 xufeng.liu@ericsson.com