idnits 2.17.1 draft-ietf-pim-msdp-yang-13.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 (February 5, 2020) is 1541 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: August 8, 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 February 5, 2020 16 A YANG Data Model for Multicast Source Discovery Protocol (MSDP) 17 draft-ietf-pim-msdp-yang-13 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 August 8, 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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 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 protocol. 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 | +--rw default-peer* [peer-addr prefix-policy] 202 {filter-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 208 | | +--rw in? -> /acl:acls/acl/name 209 | | +--rw out? -> /acl:acls/acl/name 210 | +--rw sa-limit? uint32 211 | +--rw ttl-threshold? uint8 212 +--rw peers 213 | +--rw peer* [address] 214 | +--rw address inet:ipv4-address 215 | +--rw authentication {peer-authentication}? 216 | | +--rw (authentication-type)? 217 | | +--:(key-chain) 218 | | | +--rw key-chain? key-chain:key-chain-ref 219 | | +--:(password) 220 | | +--rw key? string 221 | | +--rw crypto-algorithm? identityref 222 | +--rw enabled? boolean 223 | +--rw tcp-connection-source? if:interface-ref 224 | +--rw description? string 225 | +--rw mesh-group? string 226 | +--rw peer-as? inet:as-number 227 {peer-as-verification}? 228 | +--rw sa-filter 229 | | +--rw in? -> /acl:acls/acl/name 230 | | +--rw out? -> /acl:acls/acl/name 231 | +--rw sa-limit? uint32 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 268 rt-types:ipv4-multicast-group-address 269 | +--ro source-addr 270 rt-types:ipv4-multicast-source-address 271 | +--ro origin-rp* [rp-address] 272 | | +--ro rp-address inet:ipv4-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 281 +---x clear-peer 282 | +---w input 283 | +---w (peer) 284 | +--:(peer-address) 285 | | +---w peer-address? inet:ipv4-address 286 | +--:(all) 287 | +---w all-peers? empty 288 +---x clear-sa-cache 289 +---w input 290 +---w entry! 291 | +---w group 292 rt-types:ipv4-multicast-group-address 293 | +---w source-addr? 294 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 [RFC3618], [RFC4271], [RFC6991], [RFC8177], 333 [RFC8343], [RFC8344], [RFC8349], [RFC8294], [RFC8519]. 335 file "ietf-msdp@2020-01-29.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: Common YANG Data Types"; 346 } 348 import ietf-inet-types { 349 prefix "inet"; 350 reference "RFC 6991: Common YANG Data Types"; 351 } 353 import ietf-routing { 354 prefix "rt"; 355 reference "RFC 8349: A YANG Data Model for Routing Management 356 (NMDA Version)"; 357 } 359 import ietf-interfaces { 360 prefix "if"; 361 reference "RFC 8343: A YANG Data Model for Interface Management"; 362 } 364 import ietf-ip { 365 prefix "ip"; 366 reference "RFC 8344: A YANG Data Model for IP Management"; 367 } 369 import ietf-key-chain { 370 prefix "key-chain"; 371 reference "RFC 8177: YANG Data Model for Key Chains"; 372 } 374 import ietf-routing-types { 375 prefix "rt-types"; 376 reference "RFC 8294: Common YANG Data Types for the Routing 377 Area"; 378 } 380 import ietf-access-control-list { 381 prefix acl; 382 reference 383 "RFC 8519: YANG Data Model for Network Access Control Lists 384 (ACLs)"; 385 } 387 organization 388 "IETF PIM (Protocols for IP Multicast) Working Group"; 390 contact 391 "WG Web: 392 WG List: 394 Editor: Xufeng Liu 395 397 Editor: Zheng Zhang 398 400 Editor: Anish Peter 401 403 Editor: Mahesh Sivakumar 404 406 Editor: Feng Guo 407 409 Editor: Pete McAllister 410 "; 412 // RFC Ed.: replace XXXX with actual RFC number and remove 413 // this note 415 description 416 "The module defines the YANG model definitions for 417 Multicast Source Discovery Protocol (MSDP). 419 Copyright (c) 2020 IETF Trust and the persons identified as 420 authors of the code. All rights reserved. 422 Redistribution and use in source and binary forms, with or 423 without modification, is permitted pursuant to, and subject 424 to the license terms contained in, the Simplified BSD 425 License set forth in Section 4.c of the IETF Trust's Legal 426 Provisions Relating to IETF Documents 427 (https://trustee.ietf.org/license-info). 429 This version of this YANG module is part of RFC XXXX 430 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 431 itself for full legal notices. 433 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 434 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 435 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 436 are to be interpreted as described in BCP 14 (RFC 2119) 437 (RFC 8174) when, and only when, they appear in all 438 capitals, as shown here."; 440 revision 2020-02-05 { 441 description 442 "Initial revision."; 443 reference 444 "RFC XXXX: A YANG Data Model for MSDP."; 445 } 447 /* 448 * Features 449 */ 451 feature filter-policy { 452 description 453 "Support policy configuration of peer/message filtering."; 454 reference 455 "RFC 8519: YANG Data Model for Network Access Control 456 Lists (ACLs)"; 457 } 459 feature peer-as-verification { 460 description 461 "Support configuration of peer AS number."; 462 reference 463 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 464 } 466 feature peer-authentication { 467 description 468 "Support configuration of peer authentication."; 469 reference 470 "RFC 8177: YANG Data Model for Key Chains."; 471 } 473 /* 474 * Identities 475 */ 477 identity msdp { 478 base rt:control-plane-protocol; 479 description "Identity for the Multicast Source Discovery 480 Protocol (MSDP)."; 481 reference 482 "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; 483 } 485 /* 486 * Groupings 487 */ 488 grouping authentication-container { 489 description 490 "Authentication attributes."; 491 container authentication { 492 if-feature peer-authentication; 493 description 494 "A container defining authentication attributes."; 495 choice authentication-type { 496 case key-chain { 497 leaf key-chain { 498 type key-chain:key-chain-ref; 499 description 500 "Reference to a key-chain."; 501 reference 502 "RFC 8177: YANG Data Model for Key Chains."; 503 } 504 } 505 case password { 506 leaf key { 507 type string; 508 description 509 "This leaf describes the authentication key."; 510 reference 511 "RFC 8177: YANG Data Model for Key Chains."; 512 } 513 leaf crypto-algorithm { 514 type identityref { 515 base key-chain:crypto-algorithm; 516 } 517 description 518 "Cryptographic algorithm associated with key."; 519 reference 520 "RFC 8177: YANG Data Model for Key Chains."; 521 } 522 } 523 description 524 "Choice of authentication."; 525 } 526 } 527 } // authentication-container 529 grouping tcp-connect-source { 530 description 531 "Attribute to configure peer TCP connection source."; 532 leaf tcp-connection-source { 533 type if:interface-ref; 534 must "/if:interfaces/if:interface[if:name = current()]/" 535 + "ip:ipv4/ip:enabled != 'false'" { 536 error-message "The interface must have IPv4 enabled."; 537 description 538 "The interface must have IPv4 enabled."; 539 reference 540 "RFC 8343: A YANG Data Model for Interface Management"; 541 } 542 description 543 "The interface is to be the source for the TCP 544 connection. It is a reference to an entry in the global 545 interface list."; 546 } 547 } // tcp-connect-source 549 grouping global-config-attributes { 550 description "Global MSDP configuration."; 552 uses tcp-connect-source; 554 list default-peer { 555 if-feature filter-policy; 556 key "peer-addr prefix-policy"; 558 description 559 "The default peer accepts all MSDP SA messages. 560 A default peer is needed in topologies where MSDP peers 561 do not coexist with BGP peers. The reverse path 562 forwarding (RPF) check on SA messages can fail, and no 563 SA messages are accepted. In these cases, you can configure 564 the peer as a default peer and bypass RPF checks."; 566 leaf peer-addr { 567 type leafref { 568 path "../../../peers/peer/address"; 569 } 570 mandatory true; 571 description 572 "Reference to a peer that is in the peer list."; 573 } 574 leaf prefix-policy { 575 type leafref { 576 path "/acl:acls/acl:acl/acl:name"; 577 } 578 description 579 "If specified, only those SA entries whose RP is 580 permitted in the prefix list are allowed; 581 if not specified, all SA messages from the default 582 peer are accepted."; 583 reference 584 "RFC 8519: YANG Data Model for Network Access Control 585 Lists (ACLs)"; 586 } 587 } // default-peer 589 container originating-rp { 590 description 591 "The container of Originating RP."; 592 leaf interface { 593 type if:interface-ref; 594 must "/if:interfaces/if:interface[if:name = current()]/" 595 + "ip:ipv4/ip:enabled != 'false'" { 596 error-message "The interface must have IPv4 enabled."; 597 description 598 "The interface must have IPv4 enabled."; 599 reference 600 "RFC 8343: A YANG Data Model for Interface Management"; 601 } 602 description 603 "Reference to an entry in the global interface 604 list. 605 IP address of the interface used in the RP field of 606 an SA message entry. When Anycast RPs are used, all 607 RPs use the same IP address. This parameter can be 608 used to define a unique IP address for the RP of each 609 MSDP peer. 610 By default, the software uses the RP address of the 611 local system."; 612 } 613 } // originating-rp 615 uses sa-filter-container; 617 leaf sa-limit { 618 type uint32; 619 description 620 "A limit on the number of SA entries accepted. 621 By default, there is no limit."; 622 } 623 uses ttl-threshold; 624 } // global-config-attributes 626 grouping peer-config-attributes { 627 description "Per peer configuration for MSDP."; 629 uses authentication-container; 630 leaf enabled { 631 type boolean; 632 description 633 "'true' if peer is enabled; 634 'false' if peer is disabled."; 635 } 636 uses tcp-connect-source; 638 leaf description { 639 type string; 640 description 641 "The peer description."; 642 } 643 leaf mesh-group { 644 type string; 645 description 646 "Configure this peer to be a member of a mesh group"; 647 reference 648 "RFC 3618: Multicast Source Discovery Protocol (MSDP), 649 section 10.2."; 650 } 651 leaf peer-as { 652 if-feature peer-as-verification; 653 type inet:as-number; 654 description 655 "Peer's autonomous system number (ASN). Using peer-as to 656 do verification can provide more controlled ability. 657 If the AS number is the same as the local AS, then the 658 peer is within the same domain; otherwise, this peer is 659 external to the domain. Like the definition and usage 660 in BGP protocol."; 661 reference 662 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 663 } 664 uses sa-filter-container; 665 leaf sa-limit { 666 type uint32; 667 description 668 "A limit on the number of SA entries accepted from this 669 peer. By default, there is no limit."; 670 } 671 container timer { 672 description "Timer attributes."; 673 reference 674 "RFC 3618: Multicast Source Discovery Protocol (MSDP), 675 section 5."; 676 leaf connect-retry-interval { 677 type uint16; 678 units seconds; 679 default 30; 680 description "Peer timer for connect-retry. 681 By default, MSDP peers wait 30 seconds after 682 session is reset."; 683 } 684 leaf holdtime-interval { 685 type uint16 { 686 range "3..65535"; 687 } 688 units seconds; 689 must "(../keepalive-interval and . > ../keepalive-interval) " 690 + "or (not(../keepalive-interval) and . > 60)" { 691 error-message "The keep alive interval must be " 692 + "smaller than the hold time interval"; 693 } 694 default 75; 695 description "The SA hold down period of this MSDP peer."; 696 } 697 leaf keepalive-interval { 698 type uint16 { 699 range "1..65535"; 700 } 701 units seconds; 702 must "(../holdtime-interval and . < ../holdtime-interval) " 703 + "or (not(../holdtime-interval) and . < 75)" { 704 error-message "The keep alive interval must be " 705 + "smaller than the hold time interval"; 706 } 707 default 60; 708 description "The keepalive timer of this MSDP peer."; 709 } 710 } // timer 711 uses ttl-threshold; 712 } // peer-config-attributes 714 grouping peer-state-attributes { 715 description "Per peer state attributes for MSDP."; 717 leaf session-state { 718 type enumeration { 719 enum disabled { 720 description "Disabled."; 721 } 722 enum inactive { 723 description "Inactive."; 724 } 725 enum listen { 726 description "Listen."; 727 } 728 enum connecting { 729 description "Connecting."; 730 } 731 enum established { 732 description "Established."; 733 } 734 } 735 config false; 736 description 737 "Peer session state."; 738 reference 739 "RFC 3618: Multicast Source Discovery Protocol (MSDP), 740 section 11."; 741 } 742 leaf elapsed-time { 743 type uint32; 744 units seconds; 745 config false; 746 description "Elapsed time for being in a state."; 747 } 748 leaf connect-retry-expire { 749 type uint32; 750 units seconds; 751 config false; 752 description "Connect retry expire time of peer connection."; 753 } 754 leaf hold-expire { 755 type uint16; 756 units seconds; 757 config false; 758 description "Hold expire time of peer connection."; 759 } 760 leaf is-default-peer { 761 type boolean; 762 config false; 763 description "'true' if this peer is a default peer."; 764 } 765 leaf keepalive-expire { 766 type uint16; 767 units seconds; 768 config false; 769 description "Keepalive expire time of this peer."; 770 } 771 leaf reset-count { 772 type uint32; 773 config false; 774 description "The reset count of this peer."; 775 } 777 container statistics { 778 config false; 779 description 780 "A container defining statistics attributes."; 782 leaf discontinuity-time { 783 type yang:date-and-time; 784 description 785 "The time on the most recent occasion at which any one 786 or more of the statistic counters suffered a 787 discontinuity. If no such discontinuities have occurred 788 since the last re-initialization of the local 789 management subsystem, then this node contains the time 790 the local management subsystem re-initialized itself."; 791 } 793 container error { 794 description 795 "A grouping defining error statistics attributes."; 796 leaf rpf-failure { 797 type uint32; 798 description "Number of RPF failures."; 799 } 800 } 802 container queue { 803 description 804 "A container includes queue statistics attributes."; 805 leaf size-in { 806 type uint32; 807 description 808 "The size of the input queue."; 809 } 810 leaf size-out { 811 type uint32; 812 description 813 "The size of the output queue."; 814 } 815 } 817 container received { 818 description "Received message counters."; 819 uses statistics-sent-received; 820 } 821 container sent { 822 description "Sent message counters."; 823 uses statistics-sent-received; 824 } 825 } // statistics 826 } // peer-state-attributes 828 grouping sa-filter-container { 829 description "A container defining SA filters."; 830 container sa-filter { 831 description 832 "Specifies an access control list (ACL) to filter source 833 active (SA) messages coming in to or going out of the 834 peer."; 835 leaf in { 836 type leafref { 837 path "/acl:acls/acl:acl/acl:name"; 838 } 839 description 840 "Filters incoming SA messages only. 841 The value is the name to uniquely identify a 842 policy that contains one or more rules used to 843 accept or reject MSDP SA messages. 844 If the policy is not specified, all MSDP SA messages are 845 accepted."; 846 reference 847 "RFC 8519: YANG Data Model for Network Access Control 848 Lists (ACLs)"; 849 } 850 leaf out { 851 type leafref { 852 path "/acl:acls/acl:acl/acl:name"; 853 } 854 description 855 "Filters outgoing SA messages only. 856 The value is the name to uniquely identify a 857 policy that contains one or more rules used to 858 accept or reject MSDP SA messages. 859 If the policy is not specified, all MSDP SA messages are 860 sent."; 861 reference 862 "RFC 8519: YANG Data Model for Network Access Control 863 Lists (ACLs)"; 864 } 865 } // sa-filter 866 } // sa-filter-container 868 grouping ttl-threshold { 869 description "Attribute to configure TTL threshold."; 870 leaf ttl-threshold { 871 type uint8 { 872 range 1..255; 873 } 874 description "Maximum number of hops data packets can 875 traverse before being dropped."; 876 } 877 } // ttl-threshold 879 grouping statistics-sent-received { 880 description 881 "A grouping defining sent and received statistics attributes."; 882 leaf keepalive { 883 type yang:counter64; 884 description 885 "The number of keepalive messages."; 886 } 887 leaf notification { 888 type yang:counter64; 889 description 890 "The number of notification messages."; 891 } 892 leaf sa-message { 893 type yang:counter64; 894 description 895 "The number of SA messages."; 896 } 897 leaf sa-response { 898 type yang:counter64; 899 description 900 "The number of SA response messages."; 901 } 902 leaf sa-request { 903 type yang:counter64; 904 description 905 "The number of SA request messages."; 906 } 907 leaf total { 908 type yang:counter64; 909 description 910 "The number of total messages."; 911 } 912 } // statistics-sent-received 914 /* 915 * Data nodes 916 */ 917 augment "/rt:routing/rt:control-plane-protocols/" 918 + "rt:control-plane-protocol" { 919 when "derived-from-or-self(rt:type, 'msdp:msdp')" { 920 description 921 "This augmentation is only valid for a routing protocol 922 instance of MSDP."; 923 } 924 description 925 "MSDP augmentation to routing control-plane protocol 926 configuration and state."; 927 container msdp { 928 description 929 "MSDP configuration and operational state data."; 931 container global { 932 description 933 "Global attributes."; 934 uses global-config-attributes; 935 } 937 container peers { 938 description 939 "Containing a list of peers."; 940 list peer { 941 key "address"; 942 description 943 "List of MSDP peers."; 944 leaf address { 945 type inet:ipv4-address; 946 description 947 "The address of the peer"; 948 } 949 uses peer-config-attributes; 950 uses peer-state-attributes; 951 } 952 } 954 container sa-cache { 955 config false; 956 description 957 "The SA cache information."; 958 list entry { 959 key "group source-addr"; 960 description "A list of SA cache entries."; 961 leaf group { 962 type rt-types:ipv4-multicast-group-address; 963 description "The group address of this SA cache."; 964 } 965 leaf source-addr { 966 type rt-types:ipv4-multicast-source-address; 967 description "Source IPv4 address."; 968 } 969 list origin-rp { 970 key "rp-address"; 971 description "Origin RP address."; 972 leaf rp-address { 973 type inet:ipv4-address; 974 description "The RP address."; 975 } 976 leaf is-local-rp { 977 type boolean; 978 description "The RP is local."; 979 } 980 leaf sa-adv-expire { 981 type uint32; 982 units seconds; 983 description 984 "The remaining time duration before expiration 985 of the periodic SA advertisement timer on a 986 local RP."; 987 } 988 } 990 container state-attributes { 991 description "SA cache state attributes for MSDP."; 993 leaf up-time { 994 type uint32; 995 units seconds; 996 description "Indicates the time when this SA entry is 997 created in the cache. MSDP is a periodic 998 protocol, the up-time value can be 999 used to check the state of SA cache."; 1000 } 1001 leaf expire { 1002 type uint32; 1003 units seconds; 1004 description "Indicates the time when this SA entry in 1005 the cache times out. MSDP is a periodic 1006 protocol, the expire value can be 1007 used to check the state of SA cache."; 1008 } 1009 leaf holddown-interval { 1010 type uint32; 1011 units seconds; 1012 description "Hold-down timer value for SA 1013 forwarding."; 1014 reference 1015 "RFC 3618: Multicast Source Discovery Protocol 1016 (MSDP), section 5.3."; 1017 } 1018 leaf peer-learned-from { 1019 type inet:ipv4-address; 1020 description 1021 "The address of the peer that we learned this 1022 SA from."; 1023 } 1024 leaf rpf-peer { 1025 type inet:ipv4-address; 1026 description 1027 "The address is used to find the SA's 1028 originating RP."; 1029 } 1030 } // state-attributes 1031 } // entry 1032 } // sa-cache 1034 /* 1035 * Actions 1036 */ 1037 action clear-peer { 1038 description 1039 "Clears the TCP connection to the peer."; 1040 input { 1041 choice peer { 1042 mandatory true; 1043 description 1044 "Address of peer to be cleared."; 1045 case peer-address { 1046 leaf peer-address { 1047 type inet:ipv4-address; 1048 description 1049 "Address of peer to be cleared."; 1050 } 1051 } 1052 case all { 1053 leaf all-peers { 1054 type empty; 1055 description 1056 "All peers' TCP connection are cleared."; 1057 } 1058 } 1059 } 1060 } 1061 } // clear-peer 1063 action clear-sa-cache { 1064 description 1065 "Clears MSDP source active (SA) cache entries."; 1066 input { 1067 container entry { 1068 presence "If a particular entry is cleared."; 1069 description 1070 "The SA cache (S,G) or (*,G) entry to be cleared. If 1071 this is not provided, all entries are cleared."; 1072 leaf group { 1073 type rt-types:ipv4-multicast-group-address; 1074 mandatory true; 1075 description "The group address"; 1076 } 1077 leaf source-addr { 1078 type rt-types:ipv4-multicast-source-address; 1079 description 1080 "Address of multicast source to be cleared. If this 1081 is not provided then all entries related to the 1082 given group are cleared."; 1083 } 1084 } 1085 leaf peer-address { 1086 type inet:ipv4-address; 1087 description 1088 "Peer IP address from which MSDP SA cache entries have 1089 been learned. If this is not provided, entries learned 1090 from all peers are cleared."; 1092 } 1093 leaf peer-as { 1094 type inet:as-number; 1095 description 1096 "ASN from which MSDP SA cache entries have been learned. 1097 If this is not provided, entries learned from all AS's 1098 are cleared."; 1099 } 1100 } 1101 } // clear-sa-cache 1102 } // msdp 1103 } // augment 1104 } 1105 1107 5. Security Considerations 1109 The YANG module specified in this document defines a schema for data 1110 that is designed to be accessed via network management protocols such 1111 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1112 is the secure transport layer, and the mandatory-to-implement secure 1113 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1114 is HTTPS, and the mandatory-to-implement secure transport is TLS 1115 [RFC8446]. 1117 The NETCONF access control model [RFC8341] provides the means to 1118 restrict access for particular NETCONF or RESTCONF users to a 1119 preconfigured subset of all available NETCONF or RESTCONF protocol 1120 operations and content. 1122 There are a number of data nodes defined in this YANG module that are 1123 writable/creatable/deletable (i.e., config true, which is the 1124 default). These data nodes may be considered sensitive or vulnerable 1125 in some network environments. Write operations (e.g., edit-config) 1126 to these data nodes without proper protection can have a negative 1127 effect on network operations. These are the subtrees and data nodes 1128 and their sensitivity/vulnerability: 1130 Under /rt:routing/rt:control-plane-protocols/msdp, 1132 msdp:global 1134 This subtree specifies the configuration for the MSDP attributes 1135 at the global level. Modifying the configuration can cause MSDP 1136 default peers to be deleted or reconstructed, and the SA's 1137 unexpected filtering. 1139 msdp:peers 1140 This subtree specifies the configuration for the MSDP attributes 1141 at the peer level. The modification configuration will allow the 1142 unexpected MSDP peer establishment and unexpected SA information 1143 learning and advertisement. 1145 The "key" field is also a sensitive readable configuration, the 1146 unauthorized reading function may lead to the password leaking. 1147 The modification will allow the unexpected peer reconstruction. 1149 Some of the readable data nodes in this YANG module may be considered 1150 sensitive or vulnerable in some network environments. It is thus 1151 important to control read access (e.g., via get, get-config, or 1152 notification) to these data nodes. These are the subtrees and data 1153 nodes and their sensitivity/vulnerability: 1155 /rt:routing/rt:control-plane-protocols/msdp, 1157 Unauthorized access to any data node of the above subtree can 1158 disclose the operational state information of MSDP on this device. 1160 Some of the RPC operations in this YANG module may be considered 1161 sensitive or vulnerable in some network environments. It is thus 1162 important to control access to these operations. These are the 1163 operations and their sensitivity/vulnerability: 1165 /rt:routing/rt:control-plane-protocols/msdp:clear-peer, 1167 /rt:routing/rt:control-plane-protocols/msdp:clear-sa-cache, 1169 Unauthorized access to any of the above action operations can 1170 reconstruct the MSDP peers or delete SA records on this device. 1172 6. IANA Considerations 1174 RFC Ed.: Please replace all occurrences of 'XXXX' with the actual RFC 1175 number (and remove this note). 1177 The IANA is requested to assign one new URI from the IETF XML 1178 registry [RFC3688]. Authors are suggesting the following URI: 1180 URI: urn:ietf:params:xml:ns:yang:ietf-msdp 1182 Registrant Contact: The IESG 1184 XML: N/A, the requested URI is an XML namespace 1186 This document also requests one new YANG module name in the YANG 1187 Module Names registry [RFC6020] with the following suggestion: 1189 name: ietf-msdp 1191 namespace: urn:ietf:params:xml:ns:yang:ietf-msdp 1193 prefix: msdp 1195 reference: RFC XXXX 1197 7. Contributors 1199 The authors would like to thank Yisong Liu (liuyisong@huawei.com), 1200 Benchong Xu (xu.benchong@zte.com.cn), Tanmoy Kundu 1201 (tanmoy.kundu@alcatel-lucent.com) for their valuable contributions. 1203 8. Acknowledgement 1205 The authors would like to thank Stig Venaas, Jake Holland for their 1206 valuable comments and suggestions. 1208 9. References 1210 9.1. Normative References 1212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1213 Requirement Levels", BCP 14, RFC 2119, 1214 DOI 10.17487/RFC2119, March 1997, 1215 . 1217 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 1218 Discovery Protocol (MSDP)", RFC 3618, 1219 DOI 10.17487/RFC3618, October 2003, 1220 . 1222 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1223 DOI 10.17487/RFC3688, January 2004, 1224 . 1226 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1227 the Network Configuration Protocol (NETCONF)", RFC 6020, 1228 DOI 10.17487/RFC6020, October 2010, 1229 . 1231 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1232 and A. Bierman, Ed., "Network Configuration Protocol 1233 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1234 . 1236 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1237 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1238 . 1240 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1241 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1242 . 1244 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1245 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1246 . 1248 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1249 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1250 . 1252 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1253 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1254 May 2017, . 1256 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 1257 Zhang, "YANG Data Model for Key Chains", RFC 8177, 1258 DOI 10.17487/RFC8177, June 2017, 1259 . 1261 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1262 "Common YANG Data Types for the Routing Area", RFC 8294, 1263 DOI 10.17487/RFC8294, December 2017, 1264 . 1266 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1267 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1268 . 1270 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1271 Access Control Model", STD 91, RFC 8341, 1272 DOI 10.17487/RFC8341, March 2018, 1273 . 1275 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1276 and R. Wilton, "Network Management Datastore Architecture 1277 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1278 . 1280 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1281 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1282 . 1284 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 1285 RFC 8344, DOI 10.17487/RFC8344, March 2018, 1286 . 1288 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1289 Routing Management (NMDA Version)", RFC 8349, 1290 DOI 10.17487/RFC8349, March 2018, 1291 . 1293 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1294 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1295 . 1297 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1298 "YANG Data Model for Network Access Control Lists (ACLs)", 1299 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1300 . 1302 9.2. Informative References 1304 [I-D.ietf-pim-yang] 1305 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1306 Y., and f. hu, "A YANG Data Model for Protocol Independent 1307 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1308 progress), May 2018. 1310 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1311 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1312 DOI 10.17487/RFC4271, January 2006, 1313 . 1315 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1316 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1317 DOI 10.17487/RFC8407, October 2018, 1318 . 1320 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1321 E., and A. Tripathy, "Subscription to YANG Notifications", 1322 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1323 . 1325 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1326 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1327 September 2019, . 1329 Authors' Addresses 1331 Xufeng Liu 1332 Volta Networks 1334 Email: xufeng.liu.ietf@gmail.com 1336 Zheng Zhang (editor) 1337 ZTE Corporation 1338 No. 50 Software Ave, Yuhuatai Distinct 1339 Nanjing 1340 China 1342 Email: zzhang_ietf@hotmail.com 1344 Anish Peter 1345 Individual contributor 1347 Email: anish.ietf@gmail.com 1349 Mahesh Sivakumar 1350 Juniper networks 1351 1133 Innovation Way 1352 Sunnyvale, CALIFORNIA 94089 1353 USA 1355 Email: sivakumar.mahesh@gmail.com 1357 Feng Guo 1358 Huawei Technologies 1359 Huawei Bld., No.156 Beiqing Rd. 1360 Beijing 100095 1361 China 1363 Email: guofeng@huawei.com 1365 Pete McAllister 1366 Metaswitch Networks 1367 100 Church Street 1368 Enfield EN2 6BQ 1369 UK 1371 Email: pete.mcallister@metaswitch.com