idnits 2.17.1 draft-ietf-pim-msdp-yang-10.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-10 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 } 467 feature global-sa-filter { 468 description 469 "Support configuration of global SA filter."; 470 } 472 feature global-sa-limit { 473 description 474 "Support configuration of global limit on SA entries."; 475 } 477 feature global-ttl-threshold { 478 description 479 "Support configuration of global TTL threshold."; 480 } 482 feature rpc-clear-sa-cache { 483 description 484 "Support the RPC to clear SA cache."; 485 } 487 feature peer-admin-enable { 488 description 489 "Support configuration of peer administrative enabling."; 490 } 492 feature peer-as { 493 description 494 "Support configuration of peer AS number."; 495 } 497 feature peer-tcp-connect-source { 498 description 499 "Support configuration of peer tcp connect source."; 500 } 502 feature peer-description { 503 description 504 "Support configuration of peer description."; 505 } 507 feature peer-key-chain { 508 description 509 "Support configuration of peer key-chain."; 510 } 512 feature peer-password { 513 description 514 "Support configuration of peer password."; 515 } 516 feature peer-sa-limit { 517 description 518 "Support configuration of per peer limit on SA entries."; 519 } 521 /* 522 * Identities 523 */ 525 identity msdp { 526 if-feature "feature-msdp"; 527 base rt:control-plane-protocol; 528 description "MSDP protocol."; 529 reference 530 "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; 531 } 533 /* 534 * Groupings 535 */ 536 grouping authentication-container { 537 description 538 "Authentication attributes."; 539 container authentication { 540 description 541 "A container defining authentication attributes."; 542 choice authentication-type { 543 case key-chain { 544 if-feature peer-key-chain; 545 leaf key-chain { 546 type key-chain:key-chain-ref; 547 description 548 "Reference to a key-chain."; 549 reference 550 "RFC 8177: YANG Data Model for Key Chains."; 551 } 552 } 553 case password { 554 leaf key { 555 type string; 556 description 557 "This leaf describes the authentication key."; 558 reference 559 "RFC 8177: YANG Data Model for Key Chains."; 560 } 561 leaf crypto-algorithm { 562 type identityref { 563 base key-chain:crypto-algorithm; 565 } 566 description 567 "Cryptographic algorithm associated with key."; 568 reference 569 "RFC 8177: YANG Data Model for Key Chains."; 570 } 571 } 572 description 573 "Choice of authentication."; 574 } 575 } 576 } // authentication-container 578 grouping tcp-connect-source { 579 description 580 "Attribute to configure peer TCP connection source."; 581 leaf tcp-connection-source { 582 type if:interface-ref; 583 must "/if:interfaces/if:interface[if:name = current()]/" 584 + "ip:ipv4" { 585 error-message "The interface must have IPv4 enabled."; 586 description 587 "The interface must have IPv4 enabled."; 588 } 589 description 590 "The interface is to be the source for the TCP 591 connection. It is a reference to an entry in the global 592 interface list."; 593 } 594 } // tcp-connection-source 596 grouping global-config-attributes { 597 description "Global MSDP configuration."; 599 uses tcp-connect-source { 600 if-feature global-tcp-connect-source; 601 } 602 list default-peer { 603 if-feature global-default-peer; 604 if-feature global-default-peer-policy; 605 key "peer-addr prefix-policy"; 607 description 608 "The default peer accepts all MSDP SA messages. 609 A default peer is needed in topologies where MSDP peers 610 do not coexist with BGP peers. The reverse path 611 forwarding (RPF) check on SA messages can fail, and no 612 SA messages are accepted. In these cases, you can configure 613 the peer as a default peer and bypass RPF checks."; 615 leaf peer-addr { 616 type leafref { 617 path "../../../peers/peer/address"; 618 } 619 mandatory true; 620 description 621 "Reference to a peer that is in the peer list."; 622 } 623 leaf prefix-policy { 624 type leafref { 625 path "/acl:acls/acl:acl/acl:name"; 626 } 627 description 628 "If specified, only those SA entries whose RP is 629 permitted in the prefix list are allowed; 630 if not specified, all SA messages from the default 631 peer are accepted."; 632 reference 633 "RFC 8519: YANG Data Model for Network Access Control 634 Lists (ACLs)"; 635 } 636 } // default-peer 638 container originating-rp { 639 description 640 "The container of Originating RP."; 641 leaf interface { 642 type if:interface-ref; 643 must "/if:interfaces/if:interface[if:name = current()]/" 644 + "ip:ipv4" { 645 description 646 "The interface must have IPv4 enabled."; 647 } 648 description 649 "Reference to an entry in the global interface 650 list. 651 IP address of the interface used in the RP field of 652 an SA message entry. When Anycast RPs are used, all 653 RPs use the same IP address. This parameter can be 654 used to define a unique IP address for the RP of each 655 MSDP peer. 656 By default, the software uses the RP address of the 657 local system."; 658 } 659 } // originating-rp 660 uses sa-filter-container { 661 if-feature global-sa-filter; 662 } 663 leaf sa-limit { 664 if-feature global-sa-limit; 665 type uint32; 666 description 667 "A limit on the number of SA entries accepted. 668 By default, there is no limit."; 669 } 670 uses ttl-threshold { 671 if-feature global-ttl-threshold; 672 } 673 } // global-config-attributes 675 grouping peer-config-attributes { 676 description "Per peer configuration for MSDP."; 678 uses authentication-container; 679 leaf enable { 680 if-feature peer-admin-enable; 681 type boolean; 682 description 683 "'true' if peer is enabled; 684 'false' if peer is disabled."; 685 } 686 uses tcp-connect-source { 687 if-feature peer-tcp-connect-source; 688 } 689 leaf description { 690 if-feature peer-description; 691 type string; 692 description 693 "The peer description."; 694 } 695 leaf mesh-group { 696 type string; 697 description 698 "Configure this peer to be a member of a mesh group"; 699 } 700 leaf peer-as { 701 if-feature peer-as; 702 type inet:as-number; 703 description 704 "Peer's autonomous system number (ASN). Using peer-as to 705 do verification can provide more controlled ability."; 706 } 707 uses sa-filter-container; 708 leaf sa-limit { 709 if-feature peer-sa-limit; 710 type uint32; 711 description 712 "A limit on the number of SA entries accepted from this 713 peer. By default, there is no limit."; 714 } 715 container timer { 716 description "Timer attributes."; 717 leaf connect-retry-interval { 718 type uint16; 719 units seconds; 720 default 30; 721 description "Peer timer for connect-retry. 722 By default, MSDP peers wait 30 seconds after 723 session is reset."; 724 } 725 leaf holdtime-interval { 726 type uint16 { 727 range "3..65535"; 728 } 729 units seconds; 730 must "(../keepalive-interval and . > ../keepalive-interval) 731 or "+"(not(../keepalive-interval) and . > 60)" { 732 error-message "The keep alive interval must be " 733 + "smaller than the hold time interval"; 734 } 735 default 75; 736 description "The SA hold down period of this MSDP peer."; 737 } 738 leaf keepalive-interval { 739 type uint16 { 740 range "1..65535"; 741 } 742 units seconds; 743 must "(../holdtime-interval and . < ../holdtime-interval) 744 or "+"(not(../holdtime-interval) and . < 75)" { 745 error-message "The keep alive interval must be " 746 + "smaller than the hold time interval"; 747 } 748 default 60; 749 description "The keepalive timer of this MSDP peer."; 750 } 751 } // timer 752 uses ttl-threshold; 753 } // peer-config-attributes 755 grouping peer-state-attributes { 756 description "Per peer state attributes for MSDP."; 758 leaf session-state { 759 type enumeration { 760 enum disabled { 761 description "Disabled."; 762 } 763 enum inactive { 764 description "Inactive."; 765 } 766 enum listen { 767 description "Listen."; 768 } 769 enum connecting { 770 description "Connecting."; 771 } 772 enum established { 773 description "Established."; 774 } 775 } 776 config false; 777 description 778 "Peer session state."; 779 reference 780 "RFC 3618: Multicast Source Discovery Protocol (MSDP)."; 781 } 782 leaf elapsed-time { 783 type uint32; 784 units seconds; 785 config false; 786 description "Elapsed time for being in a state."; 787 } 788 leaf connect-retry-expire { 789 type uint32; 790 units seconds; 791 config false; 792 description "Connect retry expire time of peer connection."; 793 } 794 leaf hold-expire { 795 type uint16; 796 units seconds; 797 config false; 798 description "Hold expire time of peer connection."; 799 } 800 leaf is-default-peer { 801 type boolean; 802 config false; 803 description "'true' if this peer is a default peer."; 805 } 806 leaf keepalive-expire { 807 type uint16; 808 units seconds; 809 config false; 810 description "Keepalive expire time of this peer."; 811 } 812 leaf reset-count { 813 type uint32; 814 config false; 815 description "The reset count of this peer."; 816 } 818 container statistics { 819 config false; 820 description 821 "A container defining statistics attributes."; 823 leaf discontinuity-time { 824 type yang:date-and-time; 825 description 826 "The time on the most recent occasion at which any one 827 or more of the statistic counters suffered a 828 discontinuity. If no such discontinuities have occurred 829 since the last re-initialization of the local 830 management subsystem, then this node contains the time 831 the local management subsystem re-initialized itself."; 832 } 834 container error { 835 description 836 "A grouping defining error statistics attributes."; 837 leaf rpf-failure { 838 type uint32; 839 description "Number of RPF failures."; 840 } 841 } // statistics-error 843 container queue { 844 description 845 "A container includes queue statistics attributes."; 846 leaf size-in { 847 type uint32; 848 description 849 "The size of the input queue."; 850 } 851 leaf size-out { 852 type uint32; 853 description 854 "The size of the output queue."; 855 } 856 } // statistics-queue 858 container received { 859 description "Received message counters."; 860 uses statistics-sent-received; 861 } 862 container sent { 863 description "Sent message counters."; 864 uses statistics-sent-received; 865 } 866 } // statistics-container 867 } // peer-state-attributes 869 grouping sa-filter-container { 870 description "A container defining SA filters."; 871 container sa-filter { 872 description 873 "Specifies an access control list (ACL) to filter source 874 active (SA) messages coming in to or going out of the 875 peer."; 876 leaf in { 877 type leafref { 878 path "/acl:acls/acl:acl/acl:name"; 879 } 880 description 881 "Filters incoming SA messages only. 882 The value is the name to uniquely identify a 883 policy that contains one or more rules used to 884 accept or reject MSDP SA messages. 885 If the policy is not specified, all MSDP SA messages are 886 accepted."; 887 reference 888 "RFC 8519: YANG Data Model for Network Access Control 889 Lists (ACLs)"; 890 } 891 leaf out { 892 type leafref { 893 path "/acl:acls/acl:acl/acl:name"; 894 } 895 description 896 "Filters outgoing SA messages only. 897 The value is the name to uniquely identify a 898 policy that contains one or more rules used to 899 accept or reject MSDP SA messages. 900 If the policy is not specified, all MSDP SA messages are 901 sent."; 902 reference 903 "RFC 8519: YANG Data Model for Network Access Control 904 Lists (ACLs)"; 905 } 906 } // sa-filter 907 } // sa-filter-container 909 grouping ttl-threshold { 910 description "Attribute to configure TTL threshold."; 911 leaf ttl-threshold { 912 type uint8 { 913 range 1..255; 914 } 915 description "Maximum number of hops data packets can 916 traverse before being dropped."; 917 } 918 } // ttl-threshold 920 grouping statistics-sent-received { 921 description 922 "A grouping defining sent and received statistics attributes."; 923 leaf keepalive { 924 type yang:counter64; 925 description 926 "The number of keepalive messages."; 927 } 928 leaf notification { 929 type yang:counter64; 930 description 931 "The number of notification messages."; 932 } 933 leaf sa-message { 934 type yang:counter64; 935 description 936 "The number of SA messages."; 937 } 938 leaf sa-response { 939 type yang:counter64; 940 description 941 "The number of SA response messages."; 942 } 943 leaf sa-request { 944 type yang:counter64; 945 description 946 "The number of SA request messages."; 947 } 948 leaf total { 949 type yang:counter64; 950 description 951 "The number of total messages."; 952 } 953 } // statistics-sent-received 955 /* 956 * Data nodes 957 */ 958 augment "/rt:routing/rt:control-plane-protocols/" 959 + "rt:control-plane-protocol" { 960 description 961 "MSDP augmentation to routing instance. This augmentation 962 is only valid for a routing protocol instance of MSDP."; 964 container msdp { 965 presence "Container for MSDP protocol."; 966 description 967 "MSDP configuration data."; 969 container global { 970 description 971 "Global attributes."; 972 uses global-config-attributes; 973 } 975 container peers { 976 description 977 "Containing a list of peers."; 978 list peer { 979 key "address"; 980 description 981 "List of MSDP peers."; 982 leaf address { 983 type inet:ipv4-address; 984 description 985 "The address of the peer"; 986 } 987 uses peer-config-attributes; 988 uses peer-state-attributes; 989 } // peer 990 } // peers 992 container sa-cache { 993 config false; 994 description 995 "The SA cache information."; 996 list entry { 997 key "group source-addr"; 998 description "A list of SA cache entries."; 999 leaf group { 1000 type inet:ipv4-address; 1001 description "The group address of this SA cache."; 1002 } 1003 leaf source-addr { 1004 type union { 1005 type enumeration { 1006 enum '*' { 1007 description "Any source address."; 1008 } 1009 } 1010 type inet:ipv4-address; 1011 } 1012 description "Source IPv4 address."; 1013 } 1014 list origin-rp { 1015 key "rp-address"; 1016 description "Origin RP address."; 1017 leaf rp-address { 1018 type inet:ip-address; 1019 description "The RP address."; 1020 } 1021 leaf is-local-rp { 1022 type boolean; 1023 description "The RP is local."; 1024 } 1025 leaf sa-adv-expire { 1026 type uint32; 1027 units seconds; 1028 description 1029 "The remaining time duration before expiration 1030 of the periodic SA advertisement timer on a 1031 local RP."; 1032 } 1033 } 1035 container state-attributes { 1036 description "SA cache state attributes for MSDP."; 1038 leaf up-time { 1039 type uint32; 1040 units seconds; 1041 description "The duration time of receiving this 1042 SA cache."; 1043 } 1044 leaf expire { 1045 type uint32; 1046 units seconds; 1047 description "The duration time since this SA cache 1048 expires."; 1049 } 1050 leaf holddown-interval { 1051 type uint32; 1052 units seconds; 1053 description "Hold-down timer value for SA 1054 forwarding."; 1055 } 1056 leaf peer-learned-from { 1057 type inet:ipv4-address; 1058 description 1059 "The address of the peer that we learned this 1060 SA from."; 1061 } 1062 leaf rpf-peer { 1063 type inet:ipv4-address; 1064 description 1065 "The address is used to find the SA's 1066 originating RP."; 1067 } 1068 } // sa-cache-state-attributes 1069 } // entry 1070 } // sa-cache 1071 } // msdp 1072 } // augment 1074 /* 1075 * RPCs 1076 */ 1077 rpc clear-peer { 1078 description 1079 "Clears the TCP connection to the peer."; 1080 input { 1081 choice peer { 1082 mandatory true; 1083 description 1084 "Address of peer to be cleared."; 1085 case peer-address { 1086 leaf peer-address { 1087 type inet:ipv4-address; 1088 description 1089 "Address of peer to be cleared."; 1090 } 1091 } 1092 case all { 1093 leaf all-peers { 1094 type empty; 1095 description 1096 "All peers' TCP connection are cleared."; 1097 } 1098 } 1099 } 1100 } 1101 } 1103 rpc clear-sa-cache { 1104 if-feature rpc-clear-sa-cache; 1105 description 1106 "Clears MSDP source active (SA) cache entries."; 1107 input { 1108 container entry { 1109 presence "If a particular entry is cleared."; 1110 description 1111 "The SA cache (S,G) or (*,G) entry to be cleared. If 1112 this is not provided, all entries are cleared."; 1113 leaf group { 1114 type rt-types:ipv4-multicast-group-address; 1115 mandatory true; 1116 description "The group address"; 1117 } 1118 leaf source-addr { 1119 type rt-types:ipv4-multicast-source-address; 1120 description 1121 "Address of multicast source to be cleared. If this 1122 is not provided then all entries related to the 1123 given group are cleared."; 1124 } 1125 } // s-g 1126 leaf peer-address { 1127 type inet:ipv4-address; 1128 description 1129 "Peer IP address from which MSDP SA cache entries have 1130 been learned. If this is not provided, entries learned 1131 from all peers are cleared."; 1132 } 1133 leaf peer-as { 1134 type inet:as-number; 1135 description 1136 "ASN from which MSDP SA cache entries have been learned. 1137 If this is not provided, entries learned from all AS's 1138 are cleared."; 1139 } 1140 } 1142 } 1143 } 1144 1146 5. Security Considerations 1148 The YANG module specified in this document defines a schema for data 1149 that is designed to be accessed via network management protocols such 1150 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1151 is the secure transport layer, and the mandatory-to-implement secure 1152 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1153 is HTTPS, and the mandatory-to-implement secure transport is TLS 1154 [RFC8446]. 1156 The NETCONF access control model [RFC8341] provides the means to 1157 restrict access for particular NETCONF or RESTCONF users to a 1158 preconfigured subset of all available NETCONF or RESTCONF protocol 1159 operations and content. 1161 There are a number of data nodes defined in this YANG module that are 1162 writable/creatable/deletable (i.e., config true, which is the 1163 default). These data nodes may be considered sensitive or vulnerable 1164 in some network environments. Write operations (e.g., edit-config) 1165 to these data nodes without proper protection can have a negative 1166 effect on network operations. These are the subtrees and data nodes 1167 and their sensitivity/vulnerability: 1169 Under /rt:routing/rt:control-plane-protocols/msdp, 1171 msdp:global 1173 This subtree specifies the configuration for the MSDP attributes 1174 at the global level. Modifying the configuration can cause MSDP 1175 default peers to be deleted or reconstructed, and the SA's 1176 unexpected filtering. 1178 msdp:peers 1180 This subtree specifies the configuration for the MSDP attributes 1181 at the peer level. The modification configuration will allow the 1182 unexpected MSDP peer establishment and unexpected SA information 1183 learning and advertisement. 1185 The "key" field is also a sensitive readable configuration, the 1186 unauthorized reading function may lead to the password leaking. 1187 The modification will allow the unexpected peer reconstruction. 1189 Some of the readable data nodes in this YANG module may be considered 1190 sensitive or vulnerable in some network environments. It is thus 1191 important to control read access (e.g., via get, get-config, or 1192 notification) to these data nodes. These are the subtrees and data 1193 nodes and their sensitivity/vulnerability: 1195 /rt:routing/rt:control-plane-protocols/msdp, 1197 Unauthorized access to any data node of the above subtree can 1198 disclose the operational state information of MSDP on this device. 1200 Some of the RPC operations in this YANG module may be considered 1201 sensitive or vulnerable in some network environments. It is thus 1202 important to control access to these operations. These are the 1203 operations and their sensitivity/vulnerability: 1205 /rt:routing/rt:control-plane-protocols/msdp:clear-peer, 1207 /rt:routing/rt:control-plane-protocols/msdp:clear-sa-cache, 1209 Unauthorized access to any of the above action operations can 1210 reconstruct the MSDP peers or delete SA records on this device. 1212 6. IANA Considerations 1214 The IANA is requested to assign one new URIs from the IETF XML 1215 registry [RFC3688]. Authors are suggesting the following URI: 1217 URI: urn:ietf:params:xml:ns:yang:ietf-msdp 1219 Registrant Contact: The IESG 1221 XML: N/A, the requested URI is an XML namespace 1223 This document also requests one new YANG module name in the YANG 1224 Module Names registry [RFC6020] with the following suggestion: 1226 name: ietf-msdp 1228 namespace: urn:ietf:params:xml:ns:yang:ietf-msdp 1230 prefix: msdp 1232 reference: RFC XXXX 1234 7. Contributors 1236 The authors would like to thank Yisong Liu (liuyisong@huawei.com), 1237 Benchong Xu (xu.benchong@zte.com.cn), Tanmoy Kundu 1238 (tanmoy.kundu@alcatel-lucent.com) for their valuable contributions. 1240 8. Acknowledgement 1242 The authors would like to thank Stig Venaas, Jake Holland for their 1243 valuable comments and suggestions. 1245 9. References 1247 9.1. Normative References 1249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1250 Requirement Levels", BCP 14, RFC 2119, 1251 DOI 10.17487/RFC2119, March 1997, 1252 . 1254 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 1255 Discovery Protocol (MSDP)", RFC 3618, 1256 DOI 10.17487/RFC3618, October 2003, 1257 . 1259 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1260 DOI 10.17487/RFC3688, January 2004, 1261 . 1263 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1264 the Network Configuration Protocol (NETCONF)", RFC 6020, 1265 DOI 10.17487/RFC6020, October 2010, 1266 . 1268 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1269 and A. Bierman, Ed., "Network Configuration Protocol 1270 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1271 . 1273 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1274 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1275 . 1277 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1278 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1279 . 1281 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1282 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1283 . 1285 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1286 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1287 . 1289 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1290 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1291 May 2017, . 1293 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 1294 Zhang, "YANG Data Model for Key Chains", RFC 8177, 1295 DOI 10.17487/RFC8177, June 2017, 1296 . 1298 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1299 "Common YANG Data Types for the Routing Area", RFC 8294, 1300 DOI 10.17487/RFC8294, December 2017, 1301 . 1303 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1304 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1305 . 1307 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1308 Access Control Model", STD 91, RFC 8341, 1309 DOI 10.17487/RFC8341, March 2018, 1310 . 1312 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1313 and R. Wilton, "Network Management Datastore Architecture 1314 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1315 . 1317 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1318 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1319 . 1321 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 1322 RFC 8344, DOI 10.17487/RFC8344, March 2018, 1323 . 1325 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1326 Routing Management (NMDA Version)", RFC 8349, 1327 DOI 10.17487/RFC8349, March 2018, 1328 . 1330 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1331 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1332 . 1334 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1335 "YANG Data Model for Network Access Control Lists (ACLs)", 1336 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1337 . 1339 9.2. Informative References 1341 [I-D.ietf-pim-yang] 1342 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1343 Y., and f. hu, "A YANG Data Model for Protocol Independent 1344 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1345 progress), May 2018. 1347 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1348 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1349 DOI 10.17487/RFC8407, October 2018, 1350 . 1352 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1353 E., and A. Tripathy, "Subscription to YANG Notifications", 1354 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1355 . 1357 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1358 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1359 September 2019, . 1361 Authors' Addresses 1363 Xufeng Liu 1364 Volta Networks 1366 Email: xufeng.liu.ietf@gmail.com 1368 Zheng Zhang (editor) 1369 ZTE Corporation 1370 No. 50 Software Ave, Yuhuatai Distinct 1371 Nanjing 1372 China 1374 Email: zzhang_ietf@hotmail.com 1375 Anish Peter 1376 Individual contributor 1378 Email: anish.ietf@gmail.com 1380 Mahesh Sivakumar 1381 Juniper networks 1382 1133 Innovation Way 1383 Sunnyvale, CALIFORNIA 94089 1384 USA 1386 Email: sivakumar.mahesh@gmail.com 1388 Feng Guo 1389 Huawei Technologies 1390 Huawei Bld., No.156 Beiqing Rd. 1391 Beijing 100095 1392 China 1394 Email: guofeng@huawei.com 1396 Pete McAllister 1397 Metaswitch Networks 1398 100 Church Street 1399 Enfield EN2 6BQ 1400 UK 1402 Email: pete.mcallister@metaswitch.com