idnits 2.17.1 draft-ietf-pim-msdp-yang-09.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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 21, 2020) is 1556 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 Experimental RFC: RFC 3618 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM WG X. Liu 3 Internet-Draft Volta Networks 4 Intended status: Standards Track Z. Zhang, Ed. 5 Expires: July 24, 2020 ZTE Corporation 6 A. Peter 7 Individual contributor 8 M. Sivakumar 9 Juniper networks 10 F. Guo 11 Huawei Technologies 12 P. McAllister 13 Metaswitch Networks 14 January 21, 2020 16 A YANG Data Model for Multicast Source Discovery Protocol (MSDP) 17 draft-ietf-pim-msdp-yang-09 19 Abstract 21 This document defines a YANG data model for the configuration and 22 management of Multicast Source Discovery Protocol (MSDP) Protocol. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 24, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.2. Conventions Used in This Document . . . . . . . . . . . . 3 61 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 62 1.4. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3 63 2. Design of the Data Model . . . . . . . . . . . . . . . . . . 4 64 2.1. Scope of Model . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Specification . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Module Structure . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. MSDP Configuration . . . . . . . . . . . . . . . . . . . 7 68 3.2. MSDP State . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.3. MSDP RPC . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. MSDP YANG Model . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 73 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 74 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 26 77 9.2. Informative References . . . . . . . . . . . . . . . . . 28 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 80 1. Introduction 82 [RFC3618] introduces the protocol definition of MSDP. This document 83 defines a YANG data model that can be used to configure and manage 84 the MSDP protocol. The operational state data and statistics can 85 also be retrieved by this model. 87 This model is designed to be used along with other multicast YANG 88 models such as PIM [I-D.ietf-pim-yang], which are not covered in this 89 document. 91 1.1. Terminology 93 The terminology for describing YANG data models is found in [RFC6020] 94 and [RFC7950], including: 96 o augment 97 o data model 99 o data node 101 o identity 103 o module 105 The following abbreviations are used in this document and the defined 106 model: 108 MSDP: Multicast Source Discovery Protocol [RFC3618]. 110 SA: Source-Active [RFC3618]. 112 1.2. Conventions Used in This Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 1.3. Tree Diagrams 122 Tree diagrams used in this document follow the notation defined in 123 [RFC8340]. 125 1.4. Prefixes in Data Node Names 127 In this document, names of data nodes, actions, and other data model 128 objects are often used without a prefix, as long as it is clear from 129 the context in which YANG module each name is defined. Otherwise, 130 names are prefixed using the standard prefix associated with the 131 corresponding YANG module, as shown in Table 1. 133 +-----------+--------------------------+-----------+ 134 | Prefix | YANG module | Reference | 135 +-----------+--------------------------+-----------+ 136 | yang | ietf-yang-types | [RFC6991] | 137 | | | | 138 | inet | ietf-inet-types | [RFC6991] | 139 | | | | 140 | rt | ietf-routing | [RFC8349] | 141 | | | | 142 | if | ietf-interfaces | [RFC8343] | 143 | | | | 144 | ip | ietf-ip | [RFC8344] | 145 | | | | 146 | key-chain | ietf-key-chain | [RFC8177] | 147 | | | | 148 | rt-types | ietf-routing-types | [RFC8294] | 149 | | | | 150 | acl | ietf-access-control-list | [RFC8519] | 151 +-----------+--------------------------+-----------+ 153 Table 1 155 2. Design of the Data Model 157 2.1. Scope of Model 159 The model covers MSDP [RFC3618]. 161 This model can be used to configure and manage MSDP protocols. The 162 operational state data and statistics can be retrieved by this model. 163 Even though no protocol-specific notifications are defined in this 164 model, the subscription and push mechanism defined in [RFC8639] and 165 [RFC8641] can be implemented by the user to subscribe to 166 notifications on the data nodes in this model. 168 The model contains all the basic configuration parameters to operate 169 the protocol. Depending on the implementation choices, some systems 170 may not allow some of the advanced parameters to be configurable. 171 The occasionally implemented parameters are modeled as optional 172 features in this model. This model can be extended, and it has been 173 structured in a way that such extensions can be conveniently made. 175 2.2. Specification 177 The configuration data nodes cover global configuration attributes 178 and per peer configuration attributes. The state data nodes include 179 global, per peer, and source-active information. The container 180 "msdp" is the top level container in this data model. The presence 181 of this container is expected to enable MSDP protocol functionality. 182 No notification is defined in this model. 184 3. Module Structure 186 This model imports and augments the ietf-routing YANG model defined 187 in [RFC8349]. Both configuration data nodes and state data nodes of 188 [RFC8349] are augmented. 190 The YANG data model defined in this document conforms to the Network 191 Management Datastore Architecture (NMDA) [RFC8342]. The operational 192 state data is combined with the associated configuration data in the 193 same hierarchy [RFC8407]. 195 module: ietf-msdp 196 augment /rt:routing/rt:control-plane-protocols: 197 +--rw msdp! 198 +--rw global 199 | +--rw tcp-connection-source? if:interface-ref 200 {global-tcp-connect-source}? 201 | +--rw default-peer* [peer-addr prefix-policy] 202 {global-default-peer,global-default-peer-policy}? 203 | | +--rw peer-addr -> ../../../peers/peer/address 204 | | +--rw prefix-policy -> /acl:acls/acl/name 205 | +--rw originating-rp 206 | | +--rw interface? if:interface-ref 207 | +--rw sa-filter {global-sa-filter}? 208 | | +--rw in? -> /acl:acls/acl/name 209 | | +--rw out? -> /acl:acls/acl/name 210 | +--rw sa-limit? uint32 {global-sa-limit}? 211 | +--rw ttl-threshold? uint8 {global-ttl-threshold}? 212 +--rw peers 213 | +--rw peer* [address] 214 | +--rw address inet:ipv4-address 215 | +--rw authentication 216 | | +--rw (authentication-type)? 217 | | +--:(key-chain) {peer-key-chain}? 218 | | | +--rw key-chain? key-chain:key-chain-ref 219 | | +--:(password) 220 | | +--rw key? string 221 | | +--rw crypto-algorithm? identityref 222 | +--rw enable? boolean {peer-admin-enable}? 223 | +--rw tcp-connection-source? 224 if:interface-ref {peer-tcp-connect-source}? 225 | +--rw description? string {peer-description}? 226 | +--rw mesh-group? string 227 | +--rw peer-as? inet:as-number {peer-as}? 228 | +--rw sa-filter 229 | | +--rw in? -> /acl:acls/acl/name 230 | | +--rw out? -> /acl:acls/acl/name 231 | +--rw sa-limit? uint32 {peer-sa-limit}? 232 | +--rw timer 233 | | +--rw connect-retry-interval? uint16 234 | | +--rw holdtime-interval? uint16 235 | | +--rw keepalive-interval? uint16 236 | +--rw ttl-threshold? uint8 237 | +--ro session-state? enumeration 238 | +--ro elapsed-time? uint32 239 | +--ro connect-retry-expire? uint32 240 | +--ro hold-expire? uint16 241 | +--ro is-default-peer? boolean 242 | +--ro keepalive-expire? uint16 243 | +--ro reset-count? uint32 244 | +--ro statistics 245 | +--ro discontinuity-time? yang:date-and-time 246 | +--ro error 247 | | +--ro rpf-failure? uint32 248 | +--ro queue 249 | | +--ro size-in? uint32 250 | | +--ro size-out? uint32 251 | +--ro received 252 | | +--ro keepalive? yang:counter64 253 | | +--ro notification? yang:counter64 254 | | +--ro sa-message? yang:counter64 255 | | +--ro sa-response? yang:counter64 256 | | +--ro sa-request? yang:counter64 257 | | +--ro total? yang:counter64 258 | +--ro sent 259 | +--ro keepalive? yang:counter64 260 | +--ro notification? yang:counter64 261 | +--ro sa-message? yang:counter64 262 | +--ro sa-response? yang:counter64 263 | +--ro sa-request? yang:counter64 264 | +--ro total? yang:counter64 265 +--ro sa-cache 266 +--ro entry* [group source-addr] 267 +--ro group inet:ipv4-address 268 +--ro source-addr union 269 +--ro origin-rp* [rp-address] 270 | +--ro rp-address inet:ip-address 271 | +--ro is-local-rp? boolean 272 | +--ro sa-adv-expire? uint32 273 +--ro state-attributes 274 +--ro up-time? uint32 275 +--ro expire? uint32 276 +--ro holddown-interval? uint32 277 +--ro peer-learned-from? inet:ipv4-address 278 +--ro rpf-peer? inet:ipv4-address 280 rpcs: 281 +---x clear-peer 282 | +---w input 283 | +---w peer-address? inet:ipv4-address 284 +---x clear-sa-cache {rpc-clear-sa-cache}? 285 +---w input 286 +---w entry! 287 | +---w group rt-types:ipv4-multicast-group-address 288 | +---w source-addr? rt-types:ipv4-multicast-source-address 289 +---w peer-address? inet:ipv4-address 290 +---w peer-as? inet:as-number 292 3.1. MSDP Configuration 294 MSDP configurations require peer configurations. Several peers may 295 be configured in a mesh-group. The Source-Active information may be 296 filtered by peers. 298 The configuration modeling branch is composed of MSDP global and peer 299 configurations. The two parts are the most important parts of MSDP. 301 Besides the fundamental features of MSDP protocol, several optional 302 features are included in the model. These features help the control 303 of MSDP protocol. The peer features and SA features make the 304 deployment and control easier. The connection parameters can be used 305 to control the TCP connection because MSDP protocol is based on TCP. 306 The authentication features make the protocol more secure. The 307 filter features selectively allow operators to prevent SA information 308 from being forwarded to peers. 310 3.2. MSDP State 312 MSDP states are composed of MSDP global state, MSDP peer state, 313 statistics information and SA cache information. The statistics 314 information and SA cache information helps the operator to retrieve 315 the protocol condition. 317 3.3. MSDP RPC 319 The RPC part is used to define some useful and ordinary operations of 320 protocol management. Network managers can delete all the information 321 from a given peer by using the clear-peer rpc. And network managers 322 can delete a given SA cache information by clear-sa-cache rpc. 324 4. MSDP YANG Model 326 This module references [RFC6991], [RFC8349], [RFC8343], [RFC8344], 327 [RFC8177], [RFC3618], [RFC8294], [RFC8519]. 329 file "ietf-msdp@2020-01-21.yang" 330 module ietf-msdp { 332 yang-version 1.1; 334 namespace "urn:ietf:params:xml:ns:yang:ietf-msdp"; 335 prefix msdp; 337 import ietf-yang-types { 338 prefix "yang"; 339 reference "RFC6991"; 340 } 342 import ietf-inet-types { 343 prefix "inet"; 344 reference "RFC6991"; 345 } 347 import ietf-routing { 348 prefix "rt"; 349 reference "RFC8349"; 350 } 352 import ietf-interfaces { 353 prefix "if"; 354 reference "RFC8343"; 355 } 357 import ietf-ip { 358 prefix "ip"; 359 reference "RFC8344"; 360 } 362 import ietf-key-chain { 363 prefix "key-chain"; 364 reference "RFC8177"; 365 } 367 import ietf-routing-types { 368 prefix "rt-types"; 369 reference "RFC8294"; 370 } 371 import ietf-access-control-list { 372 prefix acl; 373 reference 374 "RFC 8519"; 375 } 377 organization 378 "IETF PIM (Protocols for IP Multicast) Working Group"; 380 contact 381 "WG Web: 382 WG List: 384 Editor: Xufeng Liu 385 387 Editor: Zheng Zhang 388 390 Editor: Anish Peter 391 393 Editor: Mahesh Sivakumar 394 396 Editor: Feng Guo 397 399 Editor: Pete McAllister 400 "; 402 description 403 "The module defines the YANG model definitions for MSDP 404 [RFC3618]. 406 Copyright (c) 2020 IETF Trust and the persons identified as 407 authors of the code. All rights reserved. 409 Redistribution and use in source and binary forms, with or 410 without modification, is permitted pursuant to, and subject to 411 the license terms contained in, the Simplified BSD License set 412 forth in Section 4.c of the IETF Trust's Legal Provisions 413 Relating to IETF Documents 414 (https://trustee.ietf.org/license-info). 416 This version of this YANG module is part of RFC XXXX 417 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 418 for full legal notices. 420 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 421 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 422 'MAY', and 'OPTIONAL' in this document are to be interpreted as 423 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 424 they appear in all capitals, as shown here."; 426 revision 2020-01-21 { 427 description 428 "Initial revision."; 429 reference 430 "RFC XXXX: A YANG Data Model for MSDP."; 431 } 433 /* 434 * Features 435 */ 436 feature global-tcp-connect-source { 437 description 438 "Support configuration of global tcp connect source."; 439 } 441 feature global-default-peer { 442 description 443 "Support configuration of global default peer."; 444 } 446 feature global-default-peer-policy { 447 description 448 "Support policy configuration of global default peer."; 449 } 451 feature global-sa-filter { 452 description 453 "Support configuration of global SA filter."; 454 } 456 feature global-sa-limit { 457 description 458 "Support configuration of global limit on SA entries."; 459 } 461 feature global-ttl-threshold { 462 description 463 "Support configuration of global TTL threshold."; 464 } 466 feature rpc-clear-sa-cache { 467 description 468 "Support the RPC to clear SA cache."; 469 } 471 feature peer-admin-enable { 472 description 473 "Support configuration of peer administrative enabling."; 474 } 476 feature peer-as { 477 description 478 "Support configuration of peer AS number."; 479 } 481 feature peer-tcp-connect-source { 482 description 483 "Support configuration of peer tcp connect source."; 484 } 486 feature peer-description { 487 description 488 "Support configuration of peer description."; 489 } 491 feature peer-key-chain { 492 description 493 "Support configuration of peer key-chain."; 494 } 496 feature peer-password { 497 description 498 "Support configuration of peer password."; 499 } 501 feature peer-sa-limit { 502 description 503 "Support configuration of per peer limit on SA entries."; 504 } 506 /* 507 * Groupings 508 */ 509 grouping authentication-container { 510 description 511 "Authentication attributes."; 512 container authentication { 513 description 514 "A container defining authentication attributes."; 515 choice authentication-type { 516 case key-chain { 517 if-feature peer-key-chain; 518 leaf key-chain { 519 type key-chain:key-chain-ref; 520 description 521 "Reference to a key-chain. The key-chain model is 522 defined in RFC8177."; 523 } 524 } 525 case password { 526 leaf key { 527 type string; 528 description 529 "This leaf describes the authentication key."; 530 } 531 leaf crypto-algorithm { 532 type identityref { 533 base key-chain:crypto-algorithm; 534 } 535 description 536 "Cryptographic algorithm associated with key."; 537 } 538 } 539 description 540 "Choice of authentication."; 541 } 542 } 543 } // authentication-container 545 grouping tcp-connect-source { 546 description 547 "Attribute to configure peer TCP connection source."; 548 leaf tcp-connection-source { 549 type if:interface-ref; 550 must "/if:interfaces/if:interface[if:name = current()]/" 551 + "ip:ipv4" { 552 description 553 "The interface must have IPv4 enabled."; 554 } 555 description 556 "The interface is to be the source for the TCP 557 connection. It is a reference to an entry in the global 558 interface list."; 559 } 560 } // tcp-connection-source 562 grouping global-config-attributes { 563 description "Global MSDP configuration."; 564 uses tcp-connect-source { 565 if-feature global-tcp-connect-source; 566 } 567 list default-peer { 568 if-feature global-default-peer; 569 if-feature global-default-peer-policy; 570 key "peer-addr prefix-policy"; 572 description 573 "The default peer accepts all MSDP SA messages. 574 A default peer is needed in topologies where MSDP peers 575 do not coexist with BGP peers. The reverse path 576 forwarding (RPF) check on SA messages can fail, and no 577 SA messages are accepted. In these cases, you can configure 578 the peer as a default peer and bypass RPF checks."; 580 leaf peer-addr { 581 type leafref { 582 path "../../../peers/peer/address"; 583 } 584 mandatory true; 585 description 586 "Reference to a peer that is in the peer list."; 587 } 588 leaf prefix-policy { 589 type leafref { 590 path "/acl:acls/acl:acl/acl:name"; 591 } 592 description 593 "If specified, only those SA entries whose RP is 594 permitted in the prefix list are allowed; 595 if not specified, all SA messages from the default 596 peer are accepted."; 597 reference 598 "RFC 8519: YANG Data Model for Network Access Control 599 Lists (ACLs)"; 600 } 601 } // default-peer 603 container originating-rp { 604 description 605 "The container of Originating RP."; 606 leaf interface { 607 type if:interface-ref; 608 must "/if:interfaces/if:interface[if:name = current()]/" 609 + "ip:ipv4" { 610 description 611 "The interface must have IPv4 enabled."; 613 } 614 description 615 "Reference to an entry in the global interface 616 list. 617 IP address of the interface used in the RP field of 618 an SA message entry. When Anycast RPs are used, all 619 RPs use the same IP address. This parameter can be 620 used to define a unique IP address for the RP of each 621 MSDP peer. 622 By default, the software uses the RP address of the 623 local system."; 624 } 625 } // originating-rp 627 uses sa-filter-container { 628 if-feature global-sa-filter; 629 } 630 leaf sa-limit { 631 if-feature global-sa-limit; 632 type uint32; 633 description 634 "A limit on the number of SA entries accepted. 635 By default, there is no limit."; 636 } 637 uses ttl-threshold { 638 if-feature global-ttl-threshold; 639 } 640 } // global-config-attributes 642 grouping peer-config-attributes { 643 description "Per peer configuration for MSDP."; 645 uses authentication-container; 646 leaf enable { 647 if-feature peer-admin-enable; 648 type boolean; 649 description 650 "'true' if peer is enabled; 651 'false' if peer is disabled."; 652 } 653 uses tcp-connect-source { 654 if-feature peer-tcp-connect-source; 655 } 656 leaf description { 657 if-feature peer-description; 658 type string; 659 description 660 "The peer description."; 662 } 663 leaf mesh-group { 664 type string; 665 description 666 "Configure this peer to be a member of a mesh group"; 667 } 668 leaf peer-as { 669 if-feature peer-as; 670 type inet:as-number; 671 description 672 "Peer's autonomous system number (ASN). Using peer-as to 673 do verification can provide more controlled ability."; 674 } 675 uses sa-filter-container; 676 leaf sa-limit { 677 if-feature peer-sa-limit; 678 type uint32; 679 description 680 "A limit on the number of SA entries accepted from this 681 peer. By default, there is no limit."; 682 } 683 container timer { 684 description "Timer attributes."; 685 leaf connect-retry-interval { 686 type uint16; 687 units seconds; 688 default 30; 689 description "Peer timer for connect-retry. 690 By default, MSDP peers wait 30 seconds after 691 session is reset."; 692 } 693 leaf holdtime-interval { 694 type uint16 { 695 range "3..65535"; 696 } 697 units seconds; 698 must "(../keepalive-interval and . > ../keepalive-interval) 699 or "+"(not(../keepalive-interval) and . > 60)" { 700 error-message "The keep alive interval must be " 701 + "smaller than the hold time interval"; 702 } 703 default 75; 704 description "The SA hold down period of this MSDP peer."; 705 } 706 leaf keepalive-interval { 707 type uint16 { 708 range "1..65535"; 709 } 710 units seconds; 711 must "(../holdtime-interval and . < ../holdtime-interval) 712 or "+"(not(../holdtime-interval) and . < 75)" { 713 error-message "The keep alive interval must be " 714 + "smaller than the hold time interval"; 715 } 716 default 60; 717 description "The keepalive timer of this MSDP peer."; 718 } 719 } // timer 720 uses ttl-threshold; 721 } // peer-config-attributes 723 grouping peer-state-attributes { 724 description "Per peer state attributes for MSDP."; 726 leaf session-state { 727 type enumeration { 728 enum disabled { 729 description "Disabled."; 730 } 731 enum inactive { 732 description "Inactive."; 733 } 734 enum listen { 735 description "Listen."; 736 } 737 enum connecting { 738 description "Connecting."; 739 } 740 enum established { 741 description "Established."; 742 } 743 } 744 config false; 745 description 746 "Peer session state."; 747 reference 748 "RFC3618: Multicast Source Discovery Protocol (MSDP)."; 749 } 750 leaf elapsed-time { 751 type uint32; 752 units seconds; 753 config false; 754 description "Elapsed time for being in a state."; 755 } 756 leaf connect-retry-expire { 757 type uint32; 758 units seconds; 759 config false; 760 description "Connect retry expire time of peer connection."; 761 } 762 leaf hold-expire { 763 type uint16; 764 units seconds; 765 config false; 766 description "Hold expire time of peer connection."; 767 } 768 leaf is-default-peer { 769 type boolean; 770 config false; 771 description "'true' if this peer is a default peer."; 772 } 773 leaf keepalive-expire { 774 type uint16; 775 units seconds; 776 config false; 777 description "Keepalive expire time of this peer."; 778 } 779 leaf reset-count { 780 type uint32; 781 config false; 782 description "The reset count of this peer."; 783 } 785 container statistics { 786 config false; 787 description 788 "A container defining statistics attributes."; 790 leaf discontinuity-time { 791 type yang:date-and-time; 792 description 793 "The time on the most recent occasion at which any one 794 or more of the statistic counters suffered a 795 discontinuity. If no such discontinuities have occurred 796 since the last re-initialization of the local 797 management subsystem, then this node contains the time 798 the local management subsystem re-initialized itself."; 799 } 801 container error { 802 description 803 "A grouping defining error statistics attributes."; 804 leaf rpf-failure { 805 type uint32; 806 description "Number of RPF failures."; 807 } 808 } // statistics-error 810 container queue { 811 description 812 "A container includes queue statistics attributes."; 813 leaf size-in { 814 type uint32; 815 description 816 "The size of the input queue."; 817 } 818 leaf size-out { 819 type uint32; 820 description 821 "The size of the output queue."; 822 } 823 } // statistics-queue 825 container received { 826 description "Received message counters."; 827 uses statistics-sent-received; 828 } 829 container sent { 830 description "Sent message counters."; 831 uses statistics-sent-received; 832 } 833 } // statistics-container 834 } // peer-state-attributes 836 grouping sa-filter-container { 837 description "A container defining SA filters."; 838 container sa-filter { 839 description 840 "Specifies an access control list (ACL) to filter source 841 active (SA) messages coming in to or going out of the 842 peer."; 843 leaf in { 844 type leafref { 845 path "/acl:acls/acl:acl/acl:name"; 846 } 847 description 848 "Filters incoming SA messages only. 849 The value is the name to uniquely identify a 850 policy that contains one or more rules used to 851 accept or reject MSDP SA messages. 852 If the policy is not specified, all MSDP SA messages are 853 accepted."; 855 reference 856 "RFC 8519: YANG Data Model for Network Access Control 857 Lists (ACLs)"; 858 } 859 leaf out { 860 type leafref { 861 path "/acl:acls/acl:acl/acl:name"; 862 } 863 description 864 "Filters outgoing SA messages only. 865 The value is the name to uniquely identify a 866 policy that contains one or more rules used to 867 accept or reject MSDP SA messages. 868 If the policy is not specified, all MSDP SA messages are 869 sent."; 870 reference 871 "RFC 8519: YANG Data Model for Network Access Control 872 Lists (ACLs)"; 873 } 874 } // sa-filter 875 } // sa-filter-container 877 grouping ttl-threshold { 878 description "Attribute to configure TTL threshold."; 879 leaf ttl-threshold { 880 type uint8 { 881 range 1..255; 882 } 883 description "Maximum number of hops data packets can 884 traverse before being dropped."; 885 } 886 } // ttl-threshold 888 grouping statistics-sent-received { 889 description 890 "A grouping defining sent and received statistics attributes."; 891 leaf keepalive { 892 type yang:counter64; 893 description 894 "The number of keepalive messages."; 895 } 896 leaf notification { 897 type yang:counter64; 898 description 899 "The number of notification messages."; 900 } 901 leaf sa-message { 902 type yang:counter64; 903 description 904 "The number of SA messages."; 905 } 906 leaf sa-response { 907 type yang:counter64; 908 description 909 "The number of SA response messages."; 910 } 911 leaf sa-request { 912 type yang:counter64; 913 description 914 "The number of SA request messages."; 915 } 916 leaf total { 917 type yang:counter64; 918 description 919 "The number of total messages."; 920 } 921 } // statistics-sent-received 923 /* 924 * Data nodes 925 */ 926 augment "/rt:routing/rt:control-plane-protocols" { 927 description 928 "MSDP augmentation to routing instance. This augmentation 929 is only valid for a routing protocol instance of MSDP."; 931 container msdp { 932 presence "Container for MSDP protocol."; 933 description 934 "MSDP configuration data."; 936 container global { 937 description 938 "Global attributes."; 939 uses global-config-attributes; 940 } 942 container peers { 943 description 944 "Containing a list of peers."; 945 list peer { 946 key "address"; 947 description 948 "List of MSDP peers."; 949 leaf address { 950 type inet:ipv4-address; 951 description 952 "The address of the peer"; 953 } 954 uses peer-config-attributes; 955 uses peer-state-attributes; 956 } // peer 957 } // peers 959 container sa-cache { 960 config false; 961 description 962 "The SA cache information."; 963 list entry { 964 key "group source-addr"; 965 description "A list of SA cache entries."; 966 leaf group { 967 type inet:ipv4-address; 968 description "The group address of this SA cache."; 969 } 970 leaf source-addr { 971 type union { 972 type enumeration { 973 enum '*' { 974 description "Any source address."; 975 } 976 } 977 type inet:ipv4-address; 978 } 979 description "Source IPv4 address."; 980 } 981 list origin-rp { 982 key "rp-address"; 983 description "Origin RP address."; 984 leaf rp-address { 985 type inet:ip-address; 986 description "The RP address."; 987 } 988 leaf is-local-rp { 989 type boolean; 990 description "The RP is local."; 991 } 992 leaf sa-adv-expire { 993 type uint32; 994 units seconds; 995 description 996 "The remaining time duration before expiration 997 of the periodic SA advertisement timer on a 998 local RP."; 1000 } 1001 } 1003 container state-attributes { 1004 description "SA cache state attributes for MSDP."; 1006 leaf up-time { 1007 type uint32; 1008 units seconds; 1009 description "The duration time of receiving this 1010 SA cache."; 1011 } 1012 leaf expire { 1013 type uint32; 1014 units seconds; 1015 description "The duration time since this SA cache 1016 expires."; 1017 } 1018 leaf holddown-interval { 1019 type uint32; 1020 units seconds; 1021 description "Hold-down timer value for SA 1022 forwarding."; 1023 } 1024 leaf peer-learned-from { 1025 type inet:ipv4-address; 1026 description 1027 "The address of the peer that we learned this 1028 SA from."; 1029 } 1030 leaf rpf-peer { 1031 type inet:ipv4-address; 1032 description 1033 "The address is used to find the SA's 1034 originating RP."; 1035 } 1036 } // sa-cache-state-attributes 1037 } // entry 1038 } // sa-cache 1039 } // msdp 1040 } // augment 1042 /* 1043 * RPCs 1044 */ 1045 rpc clear-peer { 1046 description 1047 "Clears the TCP connection to the peer."; 1049 input { 1050 leaf peer-address { 1051 type inet:ipv4-address; 1052 description 1053 "Address of peer to be cleared. If this is not 1054 provided then all peers are cleared."; 1055 } 1056 } 1057 } 1059 rpc clear-sa-cache { 1060 if-feature rpc-clear-sa-cache; 1061 description 1062 "Clears MSDP source active (SA) cache entries."; 1063 input { 1064 container entry { 1065 presence "If a particular entry is cleared."; 1066 description 1067 "The SA cache (S,G) or (*,G) entry to be cleared. If 1068 this is not provided, all entries are cleared."; 1069 leaf group { 1070 type rt-types:ipv4-multicast-group-address; 1071 mandatory true; 1072 description "The group address"; 1073 } 1074 leaf source-addr { 1075 type rt-types:ipv4-multicast-source-address; 1076 description 1077 "Address of multicast source to be cleared. If this 1078 is not provided then all entries related to the 1079 given group are cleared."; 1080 } 1081 } // s-g 1082 leaf peer-address { 1083 type inet:ipv4-address; 1084 description 1085 "Peer IP address from which MSDP SA cache entries have 1086 been learned. If this is not provided, entries learned 1087 from all peers are cleared."; 1088 } 1089 leaf peer-as { 1090 type inet:as-number; 1091 description 1092 "ASN from which MSDP SA cache entries have been learned. 1093 If this is not provided, entries learned from all AS's 1094 are cleared."; 1095 } 1096 } 1098 } 1099 } 1100 1102 5. Security Considerations 1104 The YANG module specified in this document defines a schema for data 1105 that is designed to be accessed via network management protocols such 1106 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1107 is the secure transport layer, and the mandatory-to-implement secure 1108 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1109 is HTTPS, and the mandatory-to-implement secure transport is TLS 1110 [RFC8446]. 1112 The NETCONF access control model [RFC8341] provides the means to 1113 restrict access for particular NETCONF or RESTCONF users to a 1114 preconfigured subset of all available NETCONF or RESTCONF protocol 1115 operations and content. 1117 There are a number of data nodes defined in this YANG module that are 1118 writable/creatable/deletable (i.e., config true, which is the 1119 default). These data nodes may be considered sensitive or vulnerable 1120 in some network environments. Write operations (e.g., edit-config) 1121 to these data nodes without proper protection can have a negative 1122 effect on network operations. These are the subtrees and data nodes 1123 and their sensitivity/vulnerability: 1125 Under /rt:routing/rt:control-plane-protocols/msdp, 1127 msdp:global 1129 This subtree specifies the configuration for the MSDP attributes 1130 at the global level. Modifying the configuration can cause MSDP 1131 default peers to be deleted or reconstructed, and the SA's 1132 unexpected filtering. 1134 msdp:peers 1136 This subtree specifies the configuration for the MSDP attributes 1137 at the peer level. The modification configuration will allow the 1138 unexpected MSDP peer establishment and unexpected SA information 1139 learning and advertisement. 1141 The "key" field is also a sensitive readable configuration, the 1142 unauthorized reading function may lead to the password leaking. 1143 The modification will allow the unexpected peer reconstruction. 1145 Some of the readable data nodes in this YANG module may be considered 1146 sensitive or vulnerable in some network environments. It is thus 1147 important to control read access (e.g., via get, get-config, or 1148 notification) to these data nodes. These are the subtrees and data 1149 nodes and their sensitivity/vulnerability: 1151 /rt:routing/rt:control-plane-protocols/msdp, 1153 Unauthorized access to any data node of the above subtree can 1154 disclose the operational state information of MSDP on this device. 1156 Some of the RPC operations in this YANG module may be considered 1157 sensitive or vulnerable in some network environments. It is thus 1158 important to control access to these operations. These are the 1159 operations and their sensitivity/vulnerability: 1161 /rt:routing/rt:control-plane-protocols/msdp:clear-peer, 1163 /rt:routing/rt:control-plane-protocols/msdp:clear-sa-cache, 1165 Unauthorized access to any of the above action operations can 1166 reconstruct the MSDP peers or delete SA records on this device. 1168 6. IANA Considerations 1170 The IANA is requested to assign one new URIs from the IETF XML 1171 registry [RFC3688]. Authors are suggesting the following URI: 1173 URI: urn:ietf:params:xml:ns:yang:ietf-msdp 1175 Registrant Contact: The IESG 1177 XML: N/A, the requested URI is an XML namespace 1179 This document also requests one new YANG module name in the YANG 1180 Module Names registry [RFC6020] with the following suggestion: 1182 name: ietf-msdp 1184 namespace: urn:ietf:params:xml:ns:yang:ietf-msdp 1186 prefix: msdp 1188 reference: RFC XXXX 1190 7. Contributors 1192 The authors would like to thank Yisong Liu (liuyisong@huawei.com), 1193 Benchong Xu (xu.benchong@zte.com.cn), Tanmoy Kundu 1194 (tanmoy.kundu@alcatel-lucent.com) for their valuable contributions. 1196 8. Acknowledgement 1198 The authors would like to thank Stig Venaas, Jake Holland for their 1199 valuable comments and suggestions. 1201 9. References 1203 9.1. Normative References 1205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1206 Requirement Levels", BCP 14, RFC 2119, 1207 DOI 10.17487/RFC2119, March 1997, 1208 . 1210 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 1211 Discovery Protocol (MSDP)", RFC 3618, 1212 DOI 10.17487/RFC3618, October 2003, 1213 . 1215 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1216 DOI 10.17487/RFC3688, January 2004, 1217 . 1219 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1220 the Network Configuration Protocol (NETCONF)", RFC 6020, 1221 DOI 10.17487/RFC6020, October 2010, 1222 . 1224 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1225 and A. Bierman, Ed., "Network Configuration Protocol 1226 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1227 . 1229 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1230 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1231 . 1233 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1234 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1235 . 1237 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1238 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1239 . 1241 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1242 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1243 . 1245 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1246 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1247 May 2017, . 1249 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 1250 Zhang, "YANG Data Model for Key Chains", RFC 8177, 1251 DOI 10.17487/RFC8177, June 2017, 1252 . 1254 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1255 "Common YANG Data Types for the Routing Area", RFC 8294, 1256 DOI 10.17487/RFC8294, December 2017, 1257 . 1259 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1260 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1261 . 1263 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1264 Access Control Model", STD 91, RFC 8341, 1265 DOI 10.17487/RFC8341, March 2018, 1266 . 1268 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1269 and R. Wilton, "Network Management Datastore Architecture 1270 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1271 . 1273 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1274 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1275 . 1277 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 1278 RFC 8344, DOI 10.17487/RFC8344, March 2018, 1279 . 1281 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1282 Routing Management (NMDA Version)", RFC 8349, 1283 DOI 10.17487/RFC8349, March 2018, 1284 . 1286 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1287 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1288 DOI 10.17487/RFC8407, October 2018, 1289 . 1291 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1292 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1293 . 1295 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1296 "YANG Data Model for Network Access Control Lists (ACLs)", 1297 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1298 . 1300 9.2. Informative References 1302 [I-D.ietf-pim-yang] 1303 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1304 Y., and f. hu, "A YANG Data Model for Protocol Independent 1305 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1306 progress), May 2018. 1308 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1309 E., and A. Tripathy, "Subscription to YANG Notifications", 1310 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1311 . 1313 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1314 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1315 September 2019, . 1317 Authors' Addresses 1319 Xufeng Liu 1320 Volta Networks 1322 Email: xufeng.liu.ietf@gmail.com 1324 Zheng Zhang (editor) 1325 ZTE Corporation 1326 No. 50 Software Ave, Yuhuatai Distinct 1327 Nanjing 1328 China 1330 Email: zzhang_ietf@hotmail.com 1331 Anish Peter 1332 Individual contributor 1334 Email: anish.ietf@gmail.com 1336 Mahesh Sivakumar 1337 Juniper networks 1338 1133 Innovation Way 1339 Sunnyvale, CALIFORNIA 94089 1340 USA 1342 Email: sivakumar.mahesh@gmail.com 1344 Feng Guo 1345 Huawei Technologies 1346 Huawei Bld., No.156 Beiqing Rd. 1347 Beijing 100095 1348 China 1350 Email: guofeng@huawei.com 1352 Pete McAllister 1353 Metaswitch Networks 1354 100 Church Street 1355 Enfield EN2 6BQ 1356 UK 1358 Email: pete.mcallister@metaswitch.com