idnits 2.17.1 draft-ietf-pim-msdp-yang-11.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 22, 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 25, 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 22, 2020 16 A YANG Data Model for Multicast Source Discovery Protocol (MSDP) 17 draft-ietf-pim-msdp-yang-11 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 25, 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4. MSDP YANG Model . . . . . . . . . . . . . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 73 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 74 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 27 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 27 77 9.2. Informative References . . . . . . . . . . . . . . . . . 29 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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 /rt:control-plane-protocol: 198 +--rw msdp! 199 +--rw global 200 | +--rw tcp-connection-source? if:interface-ref 201 {global-tcp-connect-source}? 202 | +--rw default-peer* [peer-addr prefix-policy] 203 {global-default-peer, 204 global-default-peer-policy}? 205 | | +--rw peer-addr -> ../../../peers/peer/address 206 | | +--rw prefix-policy -> /acl:acls/acl/name 207 | +--rw originating-rp 208 | | +--rw interface? if:interface-ref 209 | +--rw sa-filter {global-sa-filter}? 210 | | +--rw in? -> /acl:acls/acl/name 211 | | +--rw out? -> /acl:acls/acl/name 212 | +--rw sa-limit? uint32 {global-sa-limit}? 213 | +--rw ttl-threshold? uint8 {global-ttl-threshold}? 214 +--rw peers 215 | +--rw peer* [address] 216 | +--rw address inet:ipv4-address 217 | +--rw authentication 218 | | +--rw (authentication-type)? 219 | | +--:(key-chain) {peer-key-chain}? 220 | | | +--rw key-chain? key-chain:key-chain-ref 221 | | +--:(password) 222 | | +--rw key? string 223 | | +--rw crypto-algorithm? identityref 224 | +--rw enable? boolean {peer-admin-enable}? 225 | +--rw tcp-connection-source? if:interface-ref 226 {peer-tcp-connect-source}? 227 | +--rw description? string {peer-description}? 228 | +--rw mesh-group? string 229 | +--rw peer-as? inet:as-number {peer-as}? 230 | +--rw sa-filter 231 | | +--rw in? -> /acl:acls/acl/name 232 | | +--rw out? -> /acl:acls/acl/name 233 | +--rw sa-limit? uint32 {peer-sa-limit}? 234 | +--rw timer 235 | | +--rw connect-retry-interval? uint16 236 | | +--rw holdtime-interval? uint16 237 | | +--rw keepalive-interval? uint16 238 | +--rw ttl-threshold? uint8 239 | +--ro session-state? enumeration 240 | +--ro elapsed-time? uint32 241 | +--ro connect-retry-expire? uint32 242 | +--ro hold-expire? uint16 243 | +--ro is-default-peer? boolean 244 | +--ro keepalive-expire? uint16 245 | +--ro reset-count? uint32 246 | +--ro statistics 247 | +--ro discontinuity-time? yang:date-and-time 248 | +--ro error 249 | | +--ro rpf-failure? uint32 250 | +--ro queue 251 | | +--ro size-in? uint32 252 | | +--ro size-out? uint32 253 | +--ro received 254 | | +--ro keepalive? yang:counter64 255 | | +--ro notification? yang:counter64 256 | | +--ro sa-message? yang:counter64 257 | | +--ro sa-response? yang:counter64 258 | | +--ro sa-request? yang:counter64 259 | | +--ro total? yang:counter64 260 | +--ro sent 261 | +--ro keepalive? yang:counter64 262 | +--ro notification? yang:counter64 263 | +--ro sa-message? yang:counter64 264 | +--ro sa-response? yang:counter64 265 | +--ro sa-request? yang:counter64 266 | +--ro total? yang:counter64 267 +--ro sa-cache 268 +--ro entry* [group source-addr] 269 +--ro group inet:ipv4-address 270 +--ro source-addr union 271 +--ro origin-rp* [rp-address] 272 | +--ro rp-address inet:ip-address 273 | +--ro is-local-rp? boolean 274 | +--ro sa-adv-expire? uint32 275 +--ro state-attributes 276 +--ro up-time? uint32 277 +--ro expire? uint32 278 +--ro holddown-interval? uint32 279 +--ro peer-learned-from? inet:ipv4-address 280 +--ro rpf-peer? inet:ipv4-address 282 rpcs: 283 +---x clear-peer 284 | +---w input 285 | +---w (peer) 286 | +--:(peer-address) 287 | | +---w peer-address? inet:ipv4-address 288 | +--:(all) 289 | +---w all-peers? empty 290 +---x clear-sa-cache {rpc-clear-sa-cache}? 291 +---w input 292 +---w entry! 293 | +---w group rt-types:ipv4-multicast-group-address 294 | +---w source-addr? rt-types:ipv4-multicast-source-address 295 +---w peer-address? inet:ipv4-address 296 +---w peer-as? inet:as-number 298 3.1. MSDP Configuration 300 MSDP configurations require peer configurations. Several peers may 301 be configured in a mesh-group. The Source-Active information may be 302 filtered by peers. 304 The configuration modeling branch is composed of MSDP global and peer 305 configurations. The two parts are the most important parts of MSDP. 307 Besides the fundamental features of MSDP protocol, several optional 308 features are included in the model. These features help the control 309 of MSDP protocol. The peer features and SA features make the 310 deployment and control easier. The connection parameters can be used 311 to control the TCP connection because MSDP protocol is based on TCP. 312 The authentication features make the protocol more secure. The 313 filter features selectively allow operators to prevent SA information 314 from being forwarded to peers. 316 3.2. MSDP State 318 MSDP states are composed of MSDP global state, MSDP peer state, 319 statistics information and SA cache information. The statistics 320 information and SA cache information helps the operator to retrieve 321 the protocol condition. 323 3.3. MSDP RPC 325 The RPC part is used to define some useful and ordinary operations of 326 protocol management. Network managers can delete all the information 327 from a given peer by using the clear-peer rpc. And network managers 328 can delete a given SA cache information by clear-sa-cache rpc. 330 4. MSDP YANG Model 332 This module references [RFC6991], [RFC8349], [RFC8343], [RFC8344], 333 [RFC8177], [RFC3618], [RFC8294], [RFC8519]. 335 file "ietf-msdp@2020-01-23.yang" 336 module ietf-msdp { 338 yang-version 1.1; 340 namespace "urn:ietf:params:xml:ns:yang:ietf-msdp"; 341 prefix msdp; 343 import ietf-yang-types { 344 prefix "yang"; 345 reference "RFC 6991"; 346 } 348 import ietf-inet-types { 349 prefix "inet"; 350 reference "RFC 6991"; 351 } 353 import ietf-routing { 354 prefix "rt"; 355 reference "RFC 8349"; 356 } 358 import ietf-interfaces { 359 prefix "if"; 360 reference "RFC 8343"; 361 } 363 import ietf-ip { 364 prefix "ip"; 365 reference "RFC 8344"; 366 } 368 import ietf-key-chain { 369 prefix "key-chain"; 370 reference "RFC 8177"; 372 } 374 import ietf-routing-types { 375 prefix "rt-types"; 376 reference "RFC 8294"; 377 } 379 import ietf-access-control-list { 380 prefix acl; 381 reference 382 "RFC 8519"; 383 } 385 organization 386 "IETF PIM (Protocols for IP Multicast) Working Group"; 388 contact 389 "WG Web: 390 WG List: 392 Editor: Xufeng Liu 393 395 Editor: Zheng Zhang 396 398 Editor: Anish Peter 399 401 Editor: Mahesh Sivakumar 402 404 Editor: Feng Guo 405 407 Editor: Pete McAllister 408 "; 410 description 411 "The module defines the YANG model definitions for 412 Multicast Source Discovery Protocol (MSDP). 414 Copyright (c) 2020 IETF Trust and the persons identified as 415 authors of the code. All rights reserved. 417 Redistribution and use in source and binary forms, with or 418 without modification, is permitted pursuant to, and subject 419 to the license terms contained in, the Simplified BSD 420 License set forth in Section 4.c of the IETF Trust's Legal 421 Provisions Relating to IETF Documents 422 (https://trustee.ietf.org/license-info). 424 This version of this YANG module is part of RFC XXXX 425 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 426 itself for full legal notices. 428 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 429 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 430 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 431 are to be interpreted as described in BCP 14 (RFC 2119) 432 (RFC 8174) when, and only when, they appear in all 433 capitals, as shown here."; 435 revision 2020-01-23 { 436 description 437 "Initial revision."; 438 reference 439 "RFC XXXX: A YANG Data Model for MSDP."; 440 } 442 /* 443 * Features 444 */ 445 feature feature-msdp { 446 description 447 "Support MSDP protocol for IPv4 multicast source discovery."; 448 reference 449 "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; 450 } 452 feature global-tcp-connect-source { 453 description 454 "Support configuration of global tcp connect source."; 455 } 457 feature global-default-peer { 458 description 459 "Support configuration of global default peer."; 460 } 462 feature global-default-peer-policy { 463 description 464 "Support policy configuration of global default peer."; 465 reference 466 "RFC 8519: YANG Data Model for Network Access Control 467 Lists (ACLs)"; 469 } 471 feature global-sa-filter { 472 description 473 "Support configuration of global SA filter."; 474 } 476 feature global-sa-limit { 477 description 478 "Support configuration of global limit on SA entries."; 479 } 481 feature global-ttl-threshold { 482 description 483 "Support configuration of global TTL threshold."; 484 } 486 feature rpc-clear-sa-cache { 487 description 488 "Support the RPC to clear SA cache."; 489 } 491 feature peer-admin-enable { 492 description 493 "Support configuration of peer administrative enabling."; 494 } 496 feature peer-as { 497 description 498 "Support configuration of peer AS number."; 499 } 501 feature peer-tcp-connect-source { 502 description 503 "Support configuration of peer tcp connect source."; 504 } 506 feature peer-description { 507 description 508 "Support configuration of peer description."; 509 } 511 feature peer-key-chain { 512 description 513 "Support configuration of peer key-chain."; 514 reference 515 "RFC 8177: YANG Data Model for Key Chains."; 516 } 517 feature peer-sa-limit { 518 description 519 "Support configuration of per peer limit on SA entries."; 520 } 522 /* 523 * Identities 524 */ 526 identity msdp { 527 if-feature "feature-msdp"; 528 base rt:control-plane-protocol; 529 description "MSDP protocol."; 530 reference 531 "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; 532 } 534 /* 535 * Groupings 536 */ 537 grouping authentication-container { 538 description 539 "Authentication attributes."; 540 container authentication { 541 description 542 "A container defining authentication attributes."; 543 choice authentication-type { 544 case key-chain { 545 if-feature peer-key-chain; 546 leaf key-chain { 547 type key-chain:key-chain-ref; 548 description 549 "Reference to a key-chain."; 550 reference 551 "RFC 8177: YANG Data Model for Key Chains."; 552 } 553 } 554 case password { 555 leaf key { 556 type string; 557 description 558 "This leaf describes the authentication key."; 559 reference 560 "RFC 8177: YANG Data Model for Key Chains."; 561 } 562 leaf crypto-algorithm { 563 type identityref { 564 base key-chain:crypto-algorithm; 566 } 567 description 568 "Cryptographic algorithm associated with key."; 569 reference 570 "RFC 8177: YANG Data Model for Key Chains."; 571 } 572 } 573 description 574 "Choice of authentication."; 575 } 576 } 577 } // authentication-container 579 grouping tcp-connect-source { 580 description 581 "Attribute to configure peer TCP connection source."; 582 leaf tcp-connection-source { 583 type if:interface-ref; 584 must "/if:interfaces/if:interface[if:name = current()]/" 585 + "ip:ipv4" { 586 error-message "The interface must have IPv4 enabled."; 587 description 588 "The interface must have IPv4 enabled."; 589 } 590 description 591 "The interface is to be the source for the TCP 592 connection. It is a reference to an entry in the global 593 interface list."; 594 } 595 } // tcp-connection-source 597 grouping global-config-attributes { 598 description "Global MSDP configuration."; 600 uses tcp-connect-source { 601 if-feature global-tcp-connect-source; 602 } 603 list default-peer { 604 if-feature global-default-peer; 605 if-feature global-default-peer-policy; 606 key "peer-addr prefix-policy"; 608 description 609 "The default peer accepts all MSDP SA messages. 610 A default peer is needed in topologies where MSDP peers 611 do not coexist with BGP peers. The reverse path 612 forwarding (RPF) check on SA messages can fail, and no 613 SA messages are accepted. In these cases, you can configure 614 the peer as a default peer and bypass RPF checks."; 616 leaf peer-addr { 617 type leafref { 618 path "../../../peers/peer/address"; 619 } 620 mandatory true; 621 description 622 "Reference to a peer that is in the peer list."; 623 } 624 leaf prefix-policy { 625 type leafref { 626 path "/acl:acls/acl:acl/acl:name"; 627 } 628 description 629 "If specified, only those SA entries whose RP is 630 permitted in the prefix list are allowed; 631 if not specified, all SA messages from the default 632 peer are accepted."; 633 reference 634 "RFC 8519: YANG Data Model for Network Access Control 635 Lists (ACLs)"; 636 } 637 } // default-peer 639 container originating-rp { 640 description 641 "The container of Originating RP."; 642 leaf interface { 643 type if:interface-ref; 644 must "/if:interfaces/if:interface[if:name = current()]/" 645 + "ip:ipv4" { 646 description 647 "The interface must have IPv4 enabled."; 648 } 649 description 650 "Reference to an entry in the global interface 651 list. 652 IP address of the interface used in the RP field of 653 an SA message entry. When Anycast RPs are used, all 654 RPs use the same IP address. This parameter can be 655 used to define a unique IP address for the RP of each 656 MSDP peer. 657 By default, the software uses the RP address of the 658 local system."; 659 } 660 } // originating-rp 661 uses sa-filter-container { 662 if-feature global-sa-filter; 663 } 664 leaf sa-limit { 665 if-feature global-sa-limit; 666 type uint32; 667 description 668 "A limit on the number of SA entries accepted. 669 By default, there is no limit."; 670 } 671 uses ttl-threshold { 672 if-feature global-ttl-threshold; 673 } 674 } // global-config-attributes 676 grouping peer-config-attributes { 677 description "Per peer configuration for MSDP."; 679 uses authentication-container; 680 leaf enable { 681 if-feature peer-admin-enable; 682 type boolean; 683 description 684 "'true' if peer is enabled; 685 'false' if peer is disabled."; 686 } 687 uses tcp-connect-source { 688 if-feature peer-tcp-connect-source; 689 } 690 leaf description { 691 if-feature peer-description; 692 type string; 693 description 694 "The peer description."; 695 } 696 leaf mesh-group { 697 type string; 698 description 699 "Configure this peer to be a member of a mesh group"; 700 } 701 leaf peer-as { 702 if-feature peer-as; 703 type inet:as-number; 704 description 705 "Peer's autonomous system number (ASN). Using peer-as to 706 do verification can provide more controlled ability."; 707 } 708 uses sa-filter-container; 709 leaf sa-limit { 710 if-feature peer-sa-limit; 711 type uint32; 712 description 713 "A limit on the number of SA entries accepted from this 714 peer. By default, there is no limit."; 715 } 716 container timer { 717 description "Timer attributes."; 718 leaf connect-retry-interval { 719 type uint16; 720 units seconds; 721 default 30; 722 description "Peer timer for connect-retry. 723 By default, MSDP peers wait 30 seconds after 724 session is reset."; 725 } 726 leaf holdtime-interval { 727 type uint16 { 728 range "3..65535"; 729 } 730 units seconds; 731 must "(../keepalive-interval and . > ../keepalive-interval) 732 or "+"(not(../keepalive-interval) and . > 60)" { 733 error-message "The keep alive interval must be " 734 + "smaller than the hold time interval"; 735 } 736 default 75; 737 description "The SA hold down period of this MSDP peer."; 738 } 739 leaf keepalive-interval { 740 type uint16 { 741 range "1..65535"; 742 } 743 units seconds; 744 must "(../holdtime-interval and . < ../holdtime-interval) 745 or "+"(not(../holdtime-interval) and . < 75)" { 746 error-message "The keep alive interval must be " 747 + "smaller than the hold time interval"; 748 } 749 default 60; 750 description "The keepalive timer of this MSDP peer."; 751 } 752 } // timer 753 uses ttl-threshold; 754 } // peer-config-attributes 756 grouping peer-state-attributes { 757 description "Per peer state attributes for MSDP."; 759 leaf session-state { 760 type enumeration { 761 enum disabled { 762 description "Disabled."; 763 } 764 enum inactive { 765 description "Inactive."; 766 } 767 enum listen { 768 description "Listen."; 769 } 770 enum connecting { 771 description "Connecting."; 772 } 773 enum established { 774 description "Established."; 775 } 776 } 777 config false; 778 description 779 "Peer session state."; 780 reference 781 "RFC 3618: Multicast Source Discovery Protocol (MSDP)."; 782 } 783 leaf elapsed-time { 784 type uint32; 785 units seconds; 786 config false; 787 description "Elapsed time for being in a state."; 788 } 789 leaf connect-retry-expire { 790 type uint32; 791 units seconds; 792 config false; 793 description "Connect retry expire time of peer connection."; 794 } 795 leaf hold-expire { 796 type uint16; 797 units seconds; 798 config false; 799 description "Hold expire time of peer connection."; 800 } 801 leaf is-default-peer { 802 type boolean; 803 config false; 804 description "'true' if this peer is a default peer."; 806 } 807 leaf keepalive-expire { 808 type uint16; 809 units seconds; 810 config false; 811 description "Keepalive expire time of this peer."; 812 } 813 leaf reset-count { 814 type uint32; 815 config false; 816 description "The reset count of this peer."; 817 } 819 container statistics { 820 config false; 821 description 822 "A container defining statistics attributes."; 824 leaf discontinuity-time { 825 type yang:date-and-time; 826 description 827 "The time on the most recent occasion at which any one 828 or more of the statistic counters suffered a 829 discontinuity. If no such discontinuities have occurred 830 since the last re-initialization of the local 831 management subsystem, then this node contains the time 832 the local management subsystem re-initialized itself."; 833 } 835 container error { 836 description 837 "A grouping defining error statistics attributes."; 838 leaf rpf-failure { 839 type uint32; 840 description "Number of RPF failures."; 841 } 842 } // statistics-error 844 container queue { 845 description 846 "A container includes queue statistics attributes."; 847 leaf size-in { 848 type uint32; 849 description 850 "The size of the input queue."; 851 } 852 leaf size-out { 853 type uint32; 854 description 855 "The size of the output queue."; 856 } 857 } // statistics-queue 859 container received { 860 description "Received message counters."; 861 uses statistics-sent-received; 862 } 863 container sent { 864 description "Sent message counters."; 865 uses statistics-sent-received; 866 } 867 } // statistics-container 868 } // peer-state-attributes 870 grouping sa-filter-container { 871 description "A container defining SA filters."; 872 container sa-filter { 873 description 874 "Specifies an access control list (ACL) to filter source 875 active (SA) messages coming in to or going out of the 876 peer."; 877 leaf in { 878 type leafref { 879 path "/acl:acls/acl:acl/acl:name"; 880 } 881 description 882 "Filters incoming SA messages only. 883 The value is the name to uniquely identify a 884 policy that contains one or more rules used to 885 accept or reject MSDP SA messages. 886 If the policy is not specified, all MSDP SA messages are 887 accepted."; 888 reference 889 "RFC 8519: YANG Data Model for Network Access Control 890 Lists (ACLs)"; 891 } 892 leaf out { 893 type leafref { 894 path "/acl:acls/acl:acl/acl:name"; 895 } 896 description 897 "Filters outgoing SA messages only. 898 The value is the name to uniquely identify a 899 policy that contains one or more rules used to 900 accept or reject MSDP SA messages. 901 If the policy is not specified, all MSDP SA messages are 902 sent."; 903 reference 904 "RFC 8519: YANG Data Model for Network Access Control 905 Lists (ACLs)"; 906 } 907 } // sa-filter 908 } // sa-filter-container 910 grouping ttl-threshold { 911 description "Attribute to configure TTL threshold."; 912 leaf ttl-threshold { 913 type uint8 { 914 range 1..255; 915 } 916 description "Maximum number of hops data packets can 917 traverse before being dropped."; 918 } 919 } // ttl-threshold 921 grouping statistics-sent-received { 922 description 923 "A grouping defining sent and received statistics attributes."; 924 leaf keepalive { 925 type yang:counter64; 926 description 927 "The number of keepalive messages."; 928 } 929 leaf notification { 930 type yang:counter64; 931 description 932 "The number of notification messages."; 933 } 934 leaf sa-message { 935 type yang:counter64; 936 description 937 "The number of SA messages."; 938 } 939 leaf sa-response { 940 type yang:counter64; 941 description 942 "The number of SA response messages."; 943 } 944 leaf sa-request { 945 type yang:counter64; 946 description 947 "The number of SA request messages."; 948 } 949 leaf total { 950 type yang:counter64; 951 description 952 "The number of total messages."; 953 } 954 } // statistics-sent-received 956 /* 957 * Data nodes 958 */ 959 augment "/rt:routing/rt:control-plane-protocols/" 960 + "rt:control-plane-protocol" { 961 description 962 "MSDP augmentation to routing instance. This augmentation 963 is only valid for a routing protocol instance of MSDP."; 965 container msdp { 966 presence "Container for MSDP protocol."; 967 description 968 "MSDP configuration data."; 970 container global { 971 description 972 "Global attributes."; 973 uses global-config-attributes; 974 } 976 container peers { 977 description 978 "Containing a list of peers."; 979 list peer { 980 key "address"; 981 description 982 "List of MSDP peers."; 983 leaf address { 984 type inet:ipv4-address; 985 description 986 "The address of the peer"; 987 } 988 uses peer-config-attributes; 989 uses peer-state-attributes; 990 } // peer 991 } // peers 993 container sa-cache { 994 config false; 995 description 996 "The SA cache information."; 997 list entry { 998 key "group source-addr"; 999 description "A list of SA cache entries."; 1000 leaf group { 1001 type inet:ipv4-address; 1002 description "The group address of this SA cache."; 1003 } 1004 leaf source-addr { 1005 type union { 1006 type enumeration { 1007 enum '*' { 1008 description "Any source address."; 1009 } 1010 } 1011 type inet:ipv4-address; 1012 } 1013 description "Source IPv4 address."; 1014 } 1015 list origin-rp { 1016 key "rp-address"; 1017 description "Origin RP address."; 1018 leaf rp-address { 1019 type inet:ip-address; 1020 description "The RP address."; 1021 } 1022 leaf is-local-rp { 1023 type boolean; 1024 description "The RP is local."; 1025 } 1026 leaf sa-adv-expire { 1027 type uint32; 1028 units seconds; 1029 description 1030 "The remaining time duration before expiration 1031 of the periodic SA advertisement timer on a 1032 local RP."; 1033 } 1034 } 1036 container state-attributes { 1037 description "SA cache state attributes for MSDP."; 1039 leaf up-time { 1040 type uint32; 1041 units seconds; 1042 description "The duration time of receiving this 1043 SA cache."; 1044 } 1045 leaf expire { 1046 type uint32; 1047 units seconds; 1048 description "The duration time since this SA cache 1049 expires."; 1050 } 1051 leaf holddown-interval { 1052 type uint32; 1053 units seconds; 1054 description "Hold-down timer value for SA 1055 forwarding."; 1056 } 1057 leaf peer-learned-from { 1058 type inet:ipv4-address; 1059 description 1060 "The address of the peer that we learned this 1061 SA from."; 1062 } 1063 leaf rpf-peer { 1064 type inet:ipv4-address; 1065 description 1066 "The address is used to find the SA's 1067 originating RP."; 1068 } 1069 } // sa-cache-state-attributes 1070 } // entry 1071 } // sa-cache 1072 } // msdp 1073 } // augment 1075 /* 1076 * RPCs 1077 */ 1078 rpc clear-peer { 1079 description 1080 "Clears the TCP connection to the peer."; 1081 input { 1082 choice peer { 1083 mandatory true; 1084 description 1085 "Address of peer to be cleared."; 1086 case peer-address { 1087 leaf peer-address { 1088 type inet:ipv4-address; 1089 description 1090 "Address of peer to be cleared."; 1091 } 1092 } 1093 case all { 1094 leaf all-peers { 1095 type empty; 1096 description 1097 "All peers' TCP connection are cleared."; 1098 } 1099 } 1100 } 1101 } 1102 } 1104 rpc clear-sa-cache { 1105 if-feature rpc-clear-sa-cache; 1106 description 1107 "Clears MSDP source active (SA) cache entries."; 1108 input { 1109 container entry { 1110 presence "If a particular entry is cleared."; 1111 description 1112 "The SA cache (S,G) or (*,G) entry to be cleared. If 1113 this is not provided, all entries are cleared."; 1114 leaf group { 1115 type rt-types:ipv4-multicast-group-address; 1116 mandatory true; 1117 description "The group address"; 1118 } 1119 leaf source-addr { 1120 type rt-types:ipv4-multicast-source-address; 1121 description 1122 "Address of multicast source to be cleared. If this 1123 is not provided then all entries related to the 1124 given group are cleared."; 1125 } 1126 } // s-g 1127 leaf peer-address { 1128 type inet:ipv4-address; 1129 description 1130 "Peer IP address from which MSDP SA cache entries have 1131 been learned. If this is not provided, entries learned 1132 from all peers are cleared."; 1133 } 1134 leaf peer-as { 1135 type inet:as-number; 1136 description 1137 "ASN from which MSDP SA cache entries have been learned. 1138 If this is not provided, entries learned from all AS's 1139 are cleared."; 1140 } 1141 } 1143 } 1144 } 1145 1147 5. Security Considerations 1149 The YANG module specified in this document defines a schema for data 1150 that is designed to be accessed via network management protocols such 1151 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1152 is the secure transport layer, and the mandatory-to-implement secure 1153 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1154 is HTTPS, and the mandatory-to-implement secure transport is TLS 1155 [RFC8446]. 1157 The NETCONF access control model [RFC8341] provides the means to 1158 restrict access for particular NETCONF or RESTCONF users to a 1159 preconfigured subset of all available NETCONF or RESTCONF protocol 1160 operations and content. 1162 There are a number of data nodes defined in this YANG module that are 1163 writable/creatable/deletable (i.e., config true, which is the 1164 default). These data nodes may be considered sensitive or vulnerable 1165 in some network environments. Write operations (e.g., edit-config) 1166 to these data nodes without proper protection can have a negative 1167 effect on network operations. These are the subtrees and data nodes 1168 and their sensitivity/vulnerability: 1170 Under /rt:routing/rt:control-plane-protocols/msdp, 1172 msdp:global 1174 This subtree specifies the configuration for the MSDP attributes 1175 at the global level. Modifying the configuration can cause MSDP 1176 default peers to be deleted or reconstructed, and the SA's 1177 unexpected filtering. 1179 msdp:peers 1181 This subtree specifies the configuration for the MSDP attributes 1182 at the peer level. The modification configuration will allow the 1183 unexpected MSDP peer establishment and unexpected SA information 1184 learning and advertisement. 1186 The "key" field is also a sensitive readable configuration, the 1187 unauthorized reading function may lead to the password leaking. 1188 The modification will allow the unexpected peer reconstruction. 1190 Some of the readable data nodes in this YANG module may be considered 1191 sensitive or vulnerable in some network environments. It is thus 1192 important to control read access (e.g., via get, get-config, or 1193 notification) to these data nodes. These are the subtrees and data 1194 nodes and their sensitivity/vulnerability: 1196 /rt:routing/rt:control-plane-protocols/msdp, 1198 Unauthorized access to any data node of the above subtree can 1199 disclose the operational state information of MSDP on this device. 1201 Some of the RPC operations in this YANG module may be considered 1202 sensitive or vulnerable in some network environments. It is thus 1203 important to control access to these operations. These are the 1204 operations and their sensitivity/vulnerability: 1206 /rt:routing/rt:control-plane-protocols/msdp:clear-peer, 1208 /rt:routing/rt:control-plane-protocols/msdp:clear-sa-cache, 1210 Unauthorized access to any of the above action operations can 1211 reconstruct the MSDP peers or delete SA records on this device. 1213 6. IANA Considerations 1215 The IANA is requested to assign one new URIs from the IETF XML 1216 registry [RFC3688]. Authors are suggesting the following URI: 1218 URI: urn:ietf:params:xml:ns:yang:ietf-msdp 1220 Registrant Contact: The IESG 1222 XML: N/A, the requested URI is an XML namespace 1224 This document also requests one new YANG module name in the YANG 1225 Module Names registry [RFC6020] with the following suggestion: 1227 name: ietf-msdp 1229 namespace: urn:ietf:params:xml:ns:yang:ietf-msdp 1231 prefix: msdp 1233 reference: RFC XXXX 1235 7. Contributors 1237 The authors would like to thank Yisong Liu (liuyisong@huawei.com), 1238 Benchong Xu (xu.benchong@zte.com.cn), Tanmoy Kundu 1239 (tanmoy.kundu@alcatel-lucent.com) for their valuable contributions. 1241 8. Acknowledgement 1243 The authors would like to thank Stig Venaas, Jake Holland for their 1244 valuable comments and suggestions. 1246 9. References 1248 9.1. Normative References 1250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1251 Requirement Levels", BCP 14, RFC 2119, 1252 DOI 10.17487/RFC2119, March 1997, 1253 . 1255 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 1256 Discovery Protocol (MSDP)", RFC 3618, 1257 DOI 10.17487/RFC3618, October 2003, 1258 . 1260 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1261 DOI 10.17487/RFC3688, January 2004, 1262 . 1264 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1265 the Network Configuration Protocol (NETCONF)", RFC 6020, 1266 DOI 10.17487/RFC6020, October 2010, 1267 . 1269 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1270 and A. Bierman, Ed., "Network Configuration Protocol 1271 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1272 . 1274 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1275 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1276 . 1278 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1279 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1280 . 1282 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1283 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1284 . 1286 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1287 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1288 . 1290 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1291 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1292 May 2017, . 1294 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 1295 Zhang, "YANG Data Model for Key Chains", RFC 8177, 1296 DOI 10.17487/RFC8177, June 2017, 1297 . 1299 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1300 "Common YANG Data Types for the Routing Area", RFC 8294, 1301 DOI 10.17487/RFC8294, December 2017, 1302 . 1304 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1305 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1306 . 1308 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1309 Access Control Model", STD 91, RFC 8341, 1310 DOI 10.17487/RFC8341, March 2018, 1311 . 1313 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1314 and R. Wilton, "Network Management Datastore Architecture 1315 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1316 . 1318 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1319 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1320 . 1322 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 1323 RFC 8344, DOI 10.17487/RFC8344, March 2018, 1324 . 1326 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1327 Routing Management (NMDA Version)", RFC 8349, 1328 DOI 10.17487/RFC8349, March 2018, 1329 . 1331 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1332 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1333 . 1335 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1336 "YANG Data Model for Network Access Control Lists (ACLs)", 1337 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1338 . 1340 9.2. Informative References 1342 [I-D.ietf-pim-yang] 1343 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1344 Y., and f. hu, "A YANG Data Model for Protocol Independent 1345 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1346 progress), May 2018. 1348 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1349 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1350 DOI 10.17487/RFC8407, October 2018, 1351 . 1353 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1354 E., and A. Tripathy, "Subscription to YANG Notifications", 1355 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1356 . 1358 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1359 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1360 September 2019, . 1362 Authors' Addresses 1364 Xufeng Liu 1365 Volta Networks 1367 Email: xufeng.liu.ietf@gmail.com 1369 Zheng Zhang (editor) 1370 ZTE Corporation 1371 No. 50 Software Ave, Yuhuatai Distinct 1372 Nanjing 1373 China 1375 Email: zzhang_ietf@hotmail.com 1376 Anish Peter 1377 Individual contributor 1379 Email: anish.ietf@gmail.com 1381 Mahesh Sivakumar 1382 Juniper networks 1383 1133 Innovation Way 1384 Sunnyvale, CALIFORNIA 94089 1385 USA 1387 Email: sivakumar.mahesh@gmail.com 1389 Feng Guo 1390 Huawei Technologies 1391 Huawei Bld., No.156 Beiqing Rd. 1392 Beijing 100095 1393 China 1395 Email: guofeng@huawei.com 1397 Pete McAllister 1398 Metaswitch Networks 1399 100 Church Street 1400 Enfield EN2 6BQ 1401 UK 1403 Email: pete.mcallister@metaswitch.com