idnits 2.17.1 draft-ietf-pim-msdp-yang-18.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 date (April 15, 2020) is 1471 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 (~~), 1 warning (==), 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: October 17, 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 April 15, 2020 16 A YANG Data Model for Multicast Source Discovery Protocol (MSDP) 17 draft-ietf-pim-msdp-yang-18 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 October 17, 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 . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Conventions Used in This Document . . . . . . . . . . . . 3 61 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 62 1.4. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 63 2. Design of the Data Model . . . . . . . . . . . . . . . . . . 4 64 2.1. Scope of Model . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Specification . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Module Structure . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. MSDP Configuration . . . . . . . . . . . . . . . . . . . 7 68 3.2. MSDP State . . . . . . . . . . . . . . . . . . . . . . . 8 69 4. MSDP YANG Model . . . . . . . . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 72 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 73 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 26 76 9.2. Informative References . . . . . . . . . . . . . . . . . 29 77 Appendix A. Data Tree Example . . . . . . . . . . . . . . . . . 29 78 A.1. The global and peer configuration example . . . . . . . . 29 79 A.2. The state example . . . . . . . . . . . . . . . . . . . . 31 80 A.3. The actions example . . . . . . . . . . . . . . . . . . . 34 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 83 1. Introduction 85 [RFC3618] introduces the protocol definition of MSDP. This document 86 defines a YANG data model that can be used to configure and manage 87 the MSDP protocol. The operational state data and statistics can 88 also be retrieved by this model. 90 This model is designed to be used along with other multicast YANG 91 models such as PIM [I-D.ietf-pim-yang], which are not covered in this 92 document. 94 1.1. Terminology 96 The terminology for describing YANG data models is found in [RFC6020] 97 and [RFC7950], including: 99 o action 101 o augment 103 o container 105 o choice 107 o data model 109 o data node 111 o grouping 113 o identity 115 o leaf 117 o list 119 o module 121 o uses 123 The following abbreviations are used in this document and the defined 124 model: 126 MSDP: Multicast Source Discovery Protocol [RFC3618]. 128 RP: Rendezvous Point [RFC7761] 130 RPF: Reverse Path Forwarding [RFC7761] 132 SA: Source-Active [RFC3618]. 134 1.2. Conventions Used in This Document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in BCP 139 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 1.3. Tree Diagrams 144 Tree diagrams used in this document follow the notation defined in 145 [RFC8340]. 147 1.4. Prefixes in Data Node Names 149 In this document, names of data nodes, actions, and other data model 150 objects are often used without a prefix, as long as it is clear from 151 the context in which YANG module each name is defined. Otherwise, 152 names are prefixed using the standard prefix associated with the 153 corresponding YANG module, as shown in Table 1. 155 +-----------+--------------------------+-----------+ 156 | Prefix | YANG module | Reference | 157 +-----------+--------------------------+-----------+ 158 | yang | ietf-yang-types | [RFC6991] | 159 | | | | 160 | inet | ietf-inet-types | [RFC6991] | 161 | | | | 162 | rt | ietf-routing | [RFC8349] | 163 | | | | 164 | if | ietf-interfaces | [RFC8343] | 165 | | | | 166 | ip | ietf-ip | [RFC8344] | 167 | | | | 168 | key-chain | ietf-key-chain | [RFC8177] | 169 | | | | 170 | rt-types | ietf-routing-types | [RFC8294] | 171 | | | | 172 | acl | ietf-access-control-list | [RFC8519] | 173 +-----------+--------------------------+-----------+ 175 Table 1 177 2. Design of the Data Model 179 2.1. Scope of Model 181 The model covers MSDP [RFC3618]. 183 This model can be used to configure and manage the MSDP protocol. 184 The operational state data and statistics can be retrieved by this 185 model. Even though no protocol-specific notifications are defined in 186 this model, the subscription and push mechanism defined in [RFC8639] 187 and [RFC8641] can be implemented by the user to subscribe to 188 notifications on the data nodes in this model. 190 The model contains all the basic configuration parameters to operate 191 the protocol. Depending on the implementation choices, some systems 192 may not allow some of the advanced parameters to be configurable. 193 The occasionally implemented parameters are modeled as optional 194 features in this model. This model can be extended, and it has been 195 structured in a way that such extensions can be conveniently made. 197 2.2. Specification 199 The configuration data nodes cover global configuration attributes 200 and per peer configuration attributes. The state data nodes include 201 global, per peer, and source-active information. The container 202 "msdp" is the top level container in this data model. The presence 203 of this container is expected to enable MSDP protocol functionality. 204 No notification is defined in this model. 206 3. Module Structure 208 This model imports and augments the ietf-routing YANG model defined 209 in [RFC8349]. Both configuration data nodes and state data nodes of 210 [RFC8349] are augmented. 212 The YANG data model defined in this document conforms to the Network 213 Management Datastore Architecture (NMDA) [RFC8342]. The operational 214 state data is combined with the associated configuration data in the 215 same hierarchy [RFC8407]. 217 module: ietf-msdp 218 augment /rt:routing/rt:control-plane-protocols 219 /rt:control-plane-protocol: 220 +--rw msdp 221 +--rw global 222 | +--rw tcp-connection-source? if:interface-ref 223 | +--rw default-peer* [peer-addr prefix-policy] 224 {filter-policy}? 225 | | +--rw peer-addr -> ../../../peers/peer/address 226 | | +--rw prefix-policy -> /acl:acls/acl/name 227 | +--rw originating-rp 228 | | +--rw interface? if:interface-ref 229 | +--rw sa-filter 230 | | +--rw in? -> /acl:acls/acl/name 231 | | +--rw out? -> /acl:acls/acl/name 232 | +--rw sa-limit? uint32 233 | +--rw ttl-threshold? uint8 234 +--rw peers 235 | +--rw peer* [address] 236 | +--rw address inet:ipv4-address 237 | +---x clear-peer 238 | +--rw authentication {peer-authentication}? 239 | | +--rw (authentication-type)? 240 | | +--:(key-chain) 241 | | | +--rw key-chain? key-chain:key-chain-ref 242 | | +--:(password) 243 | | +--rw key? string 244 | | +--rw crypto-algorithm? identityref 245 | +--rw enabled? boolean 246 | +--rw tcp-connection-source? if:interface-ref 247 | +--rw description? string 248 | +--rw mesh-group? string 249 | +--rw peer-as? inet:as-number 250 {peer-as-verification}? 251 | +--rw sa-filter 252 | | +--rw in? -> /acl:acls/acl/name 253 | | +--rw out? -> /acl:acls/acl/name 254 | +--rw sa-limit? uint32 255 | +--rw timer 256 | | +--rw connect-retry-interval? uint16 257 | | +--rw holdtime-interval? uint16 258 | | +--rw keepalive-interval? uint16 259 | +--rw ttl-threshold? uint8 260 | +--ro session-state? enumeration 261 | +--ro elapsed-time? yang:gauge32 262 | +--ro connect-retry-expire? uint32 263 | +--ro hold-expire? uint16 264 | +--ro is-default-peer? boolean 265 | +--ro keepalive-expire? uint16 266 | +--ro reset-count? yang:zero-based-counter32 267 | +--ro statistics 268 | +--ro discontinuity-time? yang:date-and-time 269 | +--ro error 270 | | +--ro rpf-failure? uint32 271 | +--ro queue 272 | | +--ro size-in? uint32 273 | | +--ro size-out? uint32 274 | +--ro received 275 | | +--ro keepalive? yang:counter64 276 | | +--ro notification? yang:counter64 277 | | +--ro sa-message? yang:counter64 278 | | +--ro sa-response? yang:counter64 279 | | +--ro sa-request? yang:counter64 280 | | +--ro total? yang:counter64 281 | +--ro sent 282 | +--ro keepalive? yang:counter64 283 | +--ro notification? yang:counter64 284 | +--ro sa-message? yang:counter64 285 | +--ro sa-response? yang:counter64 286 | +--ro sa-request? yang:counter64 287 | +--ro total? yang:counter64 288 +---x clear-all-peers 289 +--ro sa-cache 290 +--ro entry* [group source-addr] 291 | +--ro group 292 rt-types:ipv4-multicast-group-address 293 | +--ro source-addr 294 rt-types:ipv4-multicast-source-address 295 | +--ro origin-rp* [rp-address] 296 | | +--ro rp-address inet:ipv4-address 297 | | +--ro is-local-rp? boolean 298 | | +--ro sa-adv-expire? uint32 299 | +--ro state-attributes 300 | +--ro up-time? yang:gauge32 301 | +--ro expire? yang:gauge32 302 | +--ro holddown-interval? uint32 303 | +--ro peer-learned-from? inet:ipv4-address 304 | +--ro rpf-peer? inet:ipv4-address 305 +---x clear 306 +---w input 307 +---w entry! 308 | +---w group 309 rt-types:ipv4-multicast-group-address 310 | +---w source-addr? 311 rt-types:ipv4-multicast-source-address 312 +---w peer-address? inet:ipv4-address 313 +---w peer-as? inet:as-number 315 3.1. MSDP Configuration 317 MSDP operation requires configuration information that is distributed 318 amongst several peers. Several peers may be configured in a mesh- 319 group. The Source-Active information may be filtered by peers. 321 The configuration modeling branch is composed of MSDP global and peer 322 configurations. The two parts are the most important parts of MSDP. 324 Besides the fundamental features of MSDP protocol, several optional 325 features are included in the model. These features help the control 326 of MSDP protocol. The peer features and SA features make the 327 deployment and control easier. The connection parameters can be used 328 to control the TCP connection because MSDP protocol is based on TCP. 329 The authentication features make the protocol more secure. The 330 filter features selectively allow operators to prevent SA information 331 from being forwarded to peers. 333 3.2. MSDP State 335 MSDP states are composed of MSDP global state, MSDP peer state, 336 statistics information and SA cache information. The statistics 337 information and SA cache information helps the operator to retrieve 338 the protocol condition. 340 YANG actions are defined to clear the connection of one specific MSDP 341 peer, clear the connections of all MSDP peers, or clear some or all 342 the SA caches. 344 4. MSDP YANG Model 346 This module references [RFC3618], [RFC4271], [RFC5925], [RFC6991], 347 [RFC7761], [RFC8177], [RFC8294], [RFC8343], [RFC8344], [RFC8349], 348 [RFC8519]. 350 file "ietf-msdp@2020-04-15.yang" 351 module ietf-msdp { 353 yang-version 1.1; 355 namespace "urn:ietf:params:xml:ns:yang:ietf-msdp"; 356 prefix msdp; 358 import ietf-yang-types { 359 prefix "yang"; 360 reference "RFC 6991: Common YANG Data Types"; 361 } 363 import ietf-inet-types { 364 prefix "inet"; 365 reference "RFC 6991: Common YANG Data Types"; 366 } 368 import ietf-routing { 369 prefix "rt"; 370 reference "RFC 8349: A YANG Data Model for Routing Management 371 (NMDA Version)"; 372 } 374 import ietf-interfaces { 375 prefix "if"; 376 reference "RFC 8343: A YANG Data Model for Interface Management"; 377 } 379 import ietf-ip { 380 prefix "ip"; 381 reference "RFC 8344: A YANG Data Model for IP Management"; 382 } 384 import ietf-key-chain { 385 prefix "key-chain"; 386 reference "RFC 8177: YANG Data Model for Key Chains"; 387 } 389 import ietf-routing-types { 390 prefix "rt-types"; 391 reference "RFC 8294: Common YANG Data Types for the Routing 392 Area"; 393 } 395 import ietf-access-control-list { 396 prefix acl; 397 reference 398 "RFC 8519: YANG Data Model for Network Access Control Lists 399 (ACLs)"; 400 } 402 organization 403 "IETF PIM (Protocols for IP Multicast) Working Group"; 405 contact 406 "WG Web: 407 WG List: 409 Editor: Xufeng Liu 410 412 Editor: Zheng Zhang 413 415 Editor: Anish Peter 416 418 Editor: Mahesh Sivakumar 419 421 Editor: Feng Guo 422 424 Editor: Pete McAllister 425 "; 427 // RFC Ed.: replace XXXX with actual RFC number and remove 428 // this note 429 description 430 "The module defines the YANG model definitions for 431 Multicast Source Discovery Protocol (MSDP). 433 Copyright (c) 2020 IETF Trust and the persons identified as 434 authors of the code. All rights reserved. 436 Redistribution and use in source and binary forms, with or 437 without modification, is permitted pursuant to, and subject 438 to the license terms contained in, the Simplified BSD 439 License set forth in Section 4.c of the IETF Trust's Legal 440 Provisions Relating to IETF Documents 441 (https://trustee.ietf.org/license-info). 443 This version of this YANG module is part of RFC XXXX 444 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 445 itself for full legal notices. 447 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 448 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 449 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 450 are to be interpreted as described in BCP 14 (RFC 2119) 451 (RFC 8174) when, and only when, they appear in all 452 capitals, as shown here."; 454 revision 2020-04-15 { 455 description 456 "Initial revision."; 457 reference 458 "RFC XXXX: A YANG Data Model for MSDP."; 459 } 461 /* 462 * Features 463 */ 465 feature filter-policy { 466 description 467 "Support policy configuration of peer/message filtering."; 468 reference 469 "RFC 8519: YANG Data Model for Network Access Control 470 Lists (ACLs)"; 471 } 473 feature peer-as-verification { 474 description 475 "Support configuration of peer AS number."; 476 reference 477 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 478 } 480 feature peer-authentication { 481 description 482 "Support configuration of peer authentication."; 483 reference 484 "RFC 8177: YANG Data Model for Key Chains."; 485 } 487 /* 488 * Identities 489 */ 491 identity msdp { 492 base rt:control-plane-protocol; 493 description "Identity for the Multicast Source Discovery 494 Protocol (MSDP)."; 495 reference 496 "RFC 3618: Multicast Source Discovery Protocol (MSDP)"; 497 } 499 /* 500 * Groupings 501 */ 502 grouping authentication-container { 503 description 504 "Authentication attributes."; 505 container authentication { 506 if-feature peer-authentication; 507 description 508 "A container defining authentication attributes."; 509 choice authentication-type { 510 case key-chain { 511 leaf key-chain { 512 type key-chain:key-chain-ref; 513 description 514 "Reference to a key-chain."; 515 reference 516 "RFC 8177: YANG Data Model for Key Chains."; 517 } 518 } 519 case password { 520 leaf key { 521 type string; 522 description 523 "This leaf specifies the authentication key."; 524 } 525 leaf crypto-algorithm { 526 type identityref { 527 base key-chain:crypto-algorithm; 528 } 529 must "derived-from-or-self(., 'key-chain:md5')" { 530 error-message 531 "Only the md5 algorithm can be used for MSDP."; 532 description "Check for crypto-algorithm."; 533 } 534 description 535 "Cryptographic algorithm associated with key. 536 Only the md5 algorithm can be used for MSDP. 537 When 'md5' is specified, MSDP control messages 538 are secured by TCP MD5 signatures as described 539 in RFC 3618 and RFC 5925. Both peers of a 540 connection SHOULD be configured to the same 541 algorithm for the connection to be established. 542 When this leaf is not configured, unauthenticated 543 TCP is used."; 544 reference 545 "RFC 8177: YANG Data Model for Key Chains. 546 RFC 5925: The TCP Authentication Option."; 547 } 548 } 549 description 550 "Choice of authentication."; 551 } 552 } 553 } // authentication-container 555 grouping tcp-connect-source { 556 description 557 "Attribute to configure peer TCP connection source."; 558 leaf tcp-connection-source { 559 type if:interface-ref; 560 must "/if:interfaces/if:interface[if:name = current()]/" 561 + "ip:ipv4/ip:enabled != 'false'" { 562 error-message "The interface must have IPv4 enabled."; 563 description 564 "The interface must have IPv4 enabled."; 565 reference 566 "RFC 8343: A YANG Data Model for Interface Management"; 567 } 568 description 569 "The interface is to be the source for the TCP 570 connection. It is a reference to an entry in the global 571 interface list."; 572 } 574 } // tcp-connect-source 576 grouping global-config-attributes { 577 description "Global MSDP configuration."; 579 uses tcp-connect-source; 581 list default-peer { 582 if-feature filter-policy; 583 key "peer-addr prefix-policy"; 585 description 586 "The default peer accepts all MSDP SA messages. 587 A default peer is needed in topologies where MSDP peers 588 do not coexist with BGP peers. The reverse path 589 forwarding (RPF) check on SA messages will fail, and no 590 SA messages will be accepted. In these cases, you can 591 configure the peer as a default peer and bypass RPF checks."; 593 leaf peer-addr { 594 type leafref { 595 path "../../../peers/peer/address"; 596 } 597 mandatory true; 598 description 599 "Reference to a peer that is in the peer list."; 600 } 601 leaf prefix-policy { 602 type leafref { 603 path "/acl:acls/acl:acl/acl:name"; 604 } 605 description 606 "If specified, only those SA entries whose RP is 607 permitted in the prefix list are allowed; 608 if not specified, all SA messages from the default 609 peer are accepted."; 610 reference 611 "RFC 8519: YANG Data Model for Network Access Control 612 Lists (ACLs)"; 613 } 614 } // default-peer 616 container originating-rp { 617 description 618 "The container of Originating RP."; 619 leaf interface { 620 type if:interface-ref; 621 must "/if:interfaces/if:interface[if:name = current()]/" 622 + "ip:ipv4/ip:enabled != 'false'" { 623 error-message "The interface must have IPv4 enabled."; 624 description 625 "The interface must have IPv4 enabled."; 626 reference 627 "RFC 8343: A YANG Data Model for Interface Management"; 628 } 629 description 630 "Reference to an entry in the global interface 631 list. 632 IP address of the interface used in the RP field of 633 an SA message entry. When Anycast RPs are used, all 634 RPs use the same IP address. This parameter can be 635 used to define a unique IP address for the RP of each 636 MSDP peer. 637 By default, the software uses the RP address of the 638 local system."; 639 } 640 } // originating-rp 642 uses sa-filter-container; 644 leaf sa-limit { 645 type uint32; 646 description 647 "A limit on the number of SA entries accepted. 648 By default, there is no limit."; 649 } 650 uses ttl-threshold; 651 } // global-config-attributes 653 grouping peer-config-attributes { 654 description "Per peer configuration for MSDP."; 656 uses authentication-container; 657 leaf enabled { 658 type boolean; 659 description 660 "'true' if peer is enabled; 661 'false' if peer is disabled."; 662 } 663 uses tcp-connect-source; 665 leaf description { 666 type string; 667 description 668 "The peer description."; 669 } 670 leaf mesh-group { 671 type string; 672 description 673 "The name of mesh-group which this peer belongs to."; 674 reference 675 "RFC 3618: Multicast Source Discovery Protocol (MSDP), 676 section 10.2."; 677 } 678 leaf peer-as { 679 if-feature peer-as-verification; 680 type inet:as-number; 681 description 682 "Peer's autonomous system number (ASN). Using peer-as to 683 do verification can provide more controlled ability. 684 The value can be compared with the BGP peer AS. If they 685 are different, the SA comes from this peer may be rejected. 686 If the AS number is the same as the local AS, then the 687 peer is within the same domain; otherwise, this peer is 688 external to the domain. Like the definition and usage 689 in BGP."; 690 reference 691 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 692 } 693 uses sa-filter-container; 694 leaf sa-limit { 695 type uint32; 696 description 697 "A limit on the number of SA entries accepted from this 698 peer. By default, there is no limit."; 699 } 700 container timer { 701 description "Timer attributes."; 702 reference 703 "RFC 3618: Multicast Source Discovery Protocol (MSDP), 704 section 5."; 705 leaf connect-retry-interval { 706 type uint16; 707 units seconds; 708 default 30; 709 description "Peer timer for connect-retry. 710 By default, MSDP peers wait 30 seconds after 711 session is reset."; 712 } 713 leaf holdtime-interval { 714 type uint16 { 715 range "3..65535"; 716 } 717 units seconds; 718 default 75; 719 description "The SA hold down period of this MSDP peer."; 720 } 721 leaf keepalive-interval { 722 type uint16 { 723 range "1..65535"; 724 } 725 units seconds; 726 must '. < ../holdtime-interval' { 727 error-message 728 "The keepalive interval must be smaller than the 729 hold time interval"; 730 } 731 default 60; 732 description "The keepalive timer of this MSDP peer."; 733 } 734 } // timer 735 uses ttl-threshold; 736 } // peer-config-attributes 738 grouping peer-state-attributes { 739 description "Per peer state attributes for MSDP."; 741 leaf session-state { 742 type enumeration { 743 enum disabled { 744 description "Disabled."; 745 } 746 enum inactive { 747 description "Inactive."; 748 } 749 enum listen { 750 description "Listen."; 751 } 752 enum connecting { 753 description "Connecting."; 754 } 755 enum established { 756 description "Established."; 757 } 758 } 759 config false; 760 description 761 "Peer session state."; 762 reference 763 "RFC 3618: Multicast Source Discovery Protocol (MSDP), 764 section 11."; 765 } 766 leaf elapsed-time { 767 type yang:gauge32; 768 units seconds; 769 config false; 770 description "Elapsed time for being in a state."; 771 } 772 leaf connect-retry-expire { 773 type uint32; 774 units seconds; 775 config false; 776 description "Connect retry expire time of peer connection."; 777 } 778 leaf hold-expire { 779 type uint16; 780 units seconds; 781 config false; 782 description "Hold expire time of peer connection."; 783 } 784 leaf is-default-peer { 785 type boolean; 786 config false; 787 description "'true' if this peer is one of the default peer."; 788 } 789 leaf keepalive-expire { 790 type uint16; 791 units seconds; 792 config false; 793 description "Keepalive expire time of this peer."; 794 } 795 leaf reset-count { 796 type yang:zero-based-counter32; 797 config false; 798 description "The reset count of this peer."; 799 } 801 container statistics { 802 config false; 803 description 804 "A container defining statistics attributes."; 806 leaf discontinuity-time { 807 type yang:date-and-time; 808 description 809 "The time on the most recent occasion at which any one 810 or more of the statistic counters suffered a 811 discontinuity. If no such discontinuities have occurred 812 since the last re-initialization of the local 813 management subsystem, then this node contains the time 814 the local management subsystem re-initialized itself."; 815 } 817 container error { 818 description 819 "A grouping defining error statistics attributes."; 820 leaf rpf-failure { 821 type uint32; 822 description "Number of RPF failures."; 823 } 824 } 826 container queue { 827 description 828 "A container includes queue statistics attributes."; 829 leaf size-in { 830 type uint32; 831 description 832 "The number of messages received from the peer 833 currently queued."; 834 } 835 leaf size-out { 836 type uint32; 837 description 838 "The number of messages queued to be sent to the peer."; 839 } 840 } 842 container received { 843 description "Received message counters."; 844 uses statistics-sent-received; 845 } 846 container sent { 847 description "Sent message counters."; 848 uses statistics-sent-received; 849 } 850 } // statistics 851 } // peer-state-attributes 853 grouping sa-filter-container { 854 description "A container defining SA filters."; 855 container sa-filter { 856 description 857 "Specifies an access control list (ACL) to filter source 858 active (SA) messages coming in to or going out of the 859 peer."; 860 leaf in { 861 type leafref { 862 path "/acl:acls/acl:acl/acl:name"; 863 } 864 description 865 "Filters incoming SA messages only. 866 The value is the name to uniquely identify a 867 policy that contains one or more rules used to 868 accept or reject MSDP SA messages. 869 If the policy is not specified, all MSDP SA messages are 870 accepted."; 871 reference 872 "RFC 8519: YANG Data Model for Network Access Control 873 Lists (ACLs)"; 874 } 875 leaf out { 876 type leafref { 877 path "/acl:acls/acl:acl/acl:name"; 878 } 879 description 880 "Filters outgoing SA messages only. 881 The value is the name to uniquely identify a 882 policy that contains one or more rules used to 883 accept or reject MSDP SA messages. 884 If the policy is not specified, all MSDP SA messages are 885 sent."; 886 reference 887 "RFC 8519: YANG Data Model for Network Access Control 888 Lists (ACLs)"; 889 } 890 } // sa-filter 891 } // sa-filter-container 893 grouping ttl-threshold { 894 description "Attribute to configure TTL threshold."; 895 leaf ttl-threshold { 896 type uint8 { 897 range 1..255; 898 } 899 description "Maximum number of hops data packets can 900 traverse before being dropped."; 901 } 902 } // ttl-threshold 904 grouping statistics-sent-received { 905 description 906 "A grouping defining sent and received statistics attributes."; 907 leaf keepalive { 908 type yang:counter64; 909 description 910 "The number of keepalive messages."; 911 } 912 leaf notification { 913 type yang:counter64; 914 description 915 "The number of notification messages."; 916 } 917 leaf sa-message { 918 type yang:counter64; 919 description 920 "The number of SA messages."; 921 } 922 leaf sa-response { 923 type yang:counter64; 924 description 925 "The number of SA response messages."; 926 } 927 leaf sa-request { 928 type yang:counter64; 929 description 930 "The number of SA request messages."; 931 } 932 leaf total { 933 type yang:counter64; 934 description 935 "The number of total messages."; 936 } 937 } // statistics-sent-received 939 /* 940 * Data nodes 941 */ 942 augment "/rt:routing/rt:control-plane-protocols/" 943 + "rt:control-plane-protocol" { 944 when "derived-from-or-self(rt:type, 'msdp:msdp')" { 945 description 946 "This augmentation is only valid for a routing protocol 947 instance of MSDP."; 948 } 949 description 950 "MSDP augmentation to routing control-plane protocol 951 configuration and state."; 952 container msdp { 953 description 954 "MSDP configuration and operational state data."; 956 container global { 957 description 958 "Global attributes."; 959 uses global-config-attributes; 960 } 962 container peers { 963 description 964 "Containing a list of peers."; 965 list peer { 966 key "address"; 967 description 968 "List of MSDP peers."; 969 leaf address { 970 type inet:ipv4-address; 971 description 972 "The address of the peer"; 973 } 974 action clear-peer { 975 description 976 "Clears the TCP connection to the peer."; 977 } 978 uses peer-config-attributes; 979 uses peer-state-attributes; 980 } 981 } 983 action clear-all-peers { 984 description 985 "'All peers' TCP connection are cleared."; 986 } 988 container sa-cache { 989 config false; 990 description 991 "The SA cache information."; 992 list entry { 993 key "group source-addr"; 994 description "A list of SA cache entries."; 995 leaf group { 996 type rt-types:ipv4-multicast-group-address; 997 description "The group address of this SA cache."; 998 } 999 leaf source-addr { 1000 type rt-types:ipv4-multicast-source-address; 1001 description "Source IPv4 address."; 1002 } 1003 list origin-rp { 1004 key "rp-address"; 1005 description "Origin RP information."; 1006 leaf rp-address { 1007 type inet:ipv4-address; 1008 description 1009 "The RP address. IP address used in the RP field 1010 of an SA message entry."; 1011 } 1012 leaf is-local-rp { 1013 type boolean; 1014 description 1015 "'true' if the RP is local; 1016 'false' if The RP is not local."; 1017 } 1018 leaf sa-adv-expire { 1019 type uint32; 1020 units seconds; 1021 description 1022 "The remaining time duration before expiration 1023 of the periodic SA advertisement timer on a 1024 local RP."; 1025 } 1026 } 1028 container state-attributes { 1029 description "SA cache state attributes for MSDP."; 1031 leaf up-time { 1032 type yang:gauge32; 1033 units seconds; 1034 description 1035 "Indicates the duration time when this SA entry is 1036 created in the cache. MSDP is a periodic protocol, 1037 the value can be used to check the state of 1038 SA cache."; 1039 } 1040 leaf expire { 1041 type yang:gauge32; 1042 units seconds; 1043 description 1044 "Indicates the duration time when this SA entry in 1045 the cache times out. MSDP is a periodic protocol, 1046 the value can be used to check the state of 1047 SA cache."; 1048 } 1049 leaf holddown-interval { 1050 type uint32; 1051 units seconds; 1052 description 1053 "Hold-down timer value for SA forwarding."; 1055 reference 1056 "RFC 3618: Multicast Source Discovery Protocol 1057 (MSDP), section 5.3."; 1058 } 1059 leaf peer-learned-from { 1060 type inet:ipv4-address; 1061 description 1062 "The address of the peer that we learned this 1063 SA from."; 1064 } 1065 leaf rpf-peer { 1066 type inet:ipv4-address; 1067 description 1068 "The address is the SA's originating RP."; 1069 } 1070 } // state-attributes 1071 } // entry 1073 action clear { 1074 description 1075 "Clears MSDP source active (SA) cache entries."; 1076 input { 1077 container entry { 1078 presence "If a particular entry is cleared."; 1079 description 1080 "The SA cache (S,G) or (*,G) entry to be cleared. If 1081 this is not provided, all entries are cleared."; 1082 leaf group { 1083 type rt-types:ipv4-multicast-group-address; 1084 mandatory true; 1085 description "The group address"; 1086 } 1087 leaf source-addr { 1088 type rt-types:ipv4-multicast-source-address; 1089 description 1090 "Address of multicast source to be cleared. If this 1091 is not provided then all entries related to the 1092 given group are cleared."; 1093 } 1094 } 1095 leaf peer-address { 1096 type inet:ipv4-address; 1097 description 1098 "Peer IP address from which MSDP SA cache entries have 1099 been learned. If this is not provided, entries learned 1100 from all peers are cleared."; 1101 } 1102 leaf peer-as { 1103 type inet:as-number; 1104 description 1105 "ASN from which MSDP SA cache entries have been learned. 1106 If this is not provided, entries learned from all AS's 1107 are cleared."; 1108 } 1109 } 1110 } // clear 1111 } // sa-cache 1112 } // msdp 1113 } // augment 1114 } 1115 1117 5. Security Considerations 1119 The YANG module specified in this document defines a schema for data 1120 that is designed to be accessed via network management protocols such 1121 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1122 is the secure transport layer, and the mandatory-to-implement secure 1123 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1124 is HTTPS, and the mandatory-to-implement secure transport is TLS 1125 [RFC8446]. 1127 The NETCONF access control model [RFC8341] provides the means to 1128 restrict access for particular NETCONF or RESTCONF users to a 1129 preconfigured subset of all available NETCONF or RESTCONF protocol 1130 operations and content. 1132 There are a number of data nodes defined in this YANG module that are 1133 writable/creatable/deletable (i.e., config true, which is the 1134 default). These data nodes may be considered sensitive or vulnerable 1135 in some network environments. Write operations (e.g., edit-config) 1136 to these data nodes without proper protection can have a negative 1137 effect on network operations. These are the subtrees and data nodes 1138 and their sensitivity/vulnerability: 1140 Under /rt:routing/rt:control-plane-protocols/msdp, 1142 msdp:global 1144 This subtree specifies the configuration for the MSDP attributes 1145 at the global level. Modifying the configuration can cause MSDP 1146 default peers to be deleted or the connection to be rebuilt, and 1147 unexpected filtering of the SA. 1149 msdp:peers 1150 This subtree specifies the configuration for the MSDP attributes 1151 at the peer level. Modifying the configuration will allow 1152 unexpected MSDP peer establishment and unexpected SA information 1153 learning and advertisement. 1155 The key field writability should be controlled strictly. The key 1156 misoperation will break the existing MSDP connection, and the 1157 associated SA caches will also be deleted. 1159 Some of the readable data nodes in this YANG module may be considered 1160 sensitive or vulnerable in some network environments. It is thus 1161 important to control read access (e.g., via get, get-config, or 1162 notification) to these data nodes. These is msdp subtree and key 1163 data node and their sensitivity/vulnerability: 1165 /rt:routing/rt:control-plane-protocols/msdp, 1167 Unauthorized access to any data node of the above subtree can 1168 disclose the operational state information of MSDP on this device. 1169 For example, the peer information disclosure may lead to a forged 1170 connection attack, the ACL nodes' uncorrected modification may lead 1171 to the filter errors. 1173 The "key" field is also a sensitive readable configuration. 1174 Unauthorized reading may lead to the password leaking. Modification 1175 will allow the unexpected rebuilding of connected peers. 1177 Authentication configuration is supported via the specification of 1178 key-chains [RFC8177] or the direct specification of key and 1179 authentication algorithm. Hence, authentication configuration in the 1180 "authentication" container inherits the security considerations of 1181 [RFC8177]. This includes the considerations with respect to the 1182 local storage and handling of authentication keys. 1184 Some of the RPC operations in this YANG module may be considered 1185 sensitive or vulnerable in some network environments. It is thus 1186 important to control access to these operations. These are the 1187 operations and their sensitivity/vulnerability: 1189 /rt:routing/rt:control-plane-protocols/msdp:clear-peer, 1191 /rt:routing/rt:control-plane-protocols/msdp:clear-sa-cache, 1193 Unauthorized access to any of the above action operations can lead to 1194 the MSDP peers connection rebuilding or delete SA records on this 1195 device. 1197 6. IANA Considerations 1199 RFC Ed.: Please replace all occurrences of 'XXXX' with the actual RFC 1200 number (and remove this note). 1202 The IANA is requested to assign one new URI from the IETF XML 1203 registry [RFC3688]. Authors are suggesting the following URI: 1205 URI: urn:ietf:params:xml:ns:yang:ietf-msdp 1207 Registrant Contact: The IESG 1209 XML: N/A, the requested URI is an XML namespace 1211 This document also requests one new YANG module name in the YANG 1212 Module Names registry [RFC6020] with the following suggestion: 1214 name: ietf-msdp 1216 namespace: urn:ietf:params:xml:ns:yang:ietf-msdp 1218 prefix: msdp 1220 reference: RFC XXXX 1222 7. Contributors 1224 The authors would like to thank Yisong Liu (liuyisong@huawei.com), 1225 Benchong Xu (xu.benchong@zte.com.cn), Tanmoy Kundu 1226 (tanmoy.kundu@alcatel-lucent.com) for their valuable contributions. 1228 8. Acknowledgement 1230 The authors would like to thank Stig Venaas, Jake Holland for their 1231 valuable comments and suggestions. 1233 9. References 1235 9.1. Normative References 1237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1238 Requirement Levels", BCP 14, RFC 2119, 1239 DOI 10.17487/RFC2119, March 1997, 1240 . 1242 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 1243 Discovery Protocol (MSDP)", RFC 3618, 1244 DOI 10.17487/RFC3618, October 2003, 1245 . 1247 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1248 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1249 DOI 10.17487/RFC4271, January 2006, 1250 . 1252 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1253 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1254 June 2010, . 1256 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1257 the Network Configuration Protocol (NETCONF)", RFC 6020, 1258 DOI 10.17487/RFC6020, October 2010, 1259 . 1261 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1262 and A. Bierman, Ed., "Network Configuration Protocol 1263 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1264 . 1266 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1267 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1268 . 1270 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1271 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1272 . 1274 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1275 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1276 . 1278 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1279 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1280 . 1282 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1283 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1284 . 1286 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1287 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1288 May 2017, . 1290 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 1291 Zhang, "YANG Data Model for Key Chains", RFC 8177, 1292 DOI 10.17487/RFC8177, June 2017, 1293 . 1295 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1296 "Common YANG Data Types for the Routing Area", RFC 8294, 1297 DOI 10.17487/RFC8294, December 2017, 1298 . 1300 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1301 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1302 . 1304 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1305 Access Control Model", STD 91, RFC 8341, 1306 DOI 10.17487/RFC8341, March 2018, 1307 . 1309 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1310 and R. Wilton, "Network Management Datastore Architecture 1311 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1312 . 1314 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1315 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1316 . 1318 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 1319 RFC 8344, DOI 10.17487/RFC8344, March 2018, 1320 . 1322 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1323 Routing Management (NMDA Version)", RFC 8349, 1324 DOI 10.17487/RFC8349, March 2018, 1325 . 1327 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1328 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1329 . 1331 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1332 "YANG Data Model for Network Access Control Lists (ACLs)", 1333 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1334 . 1336 9.2. Informative References 1338 [I-D.ietf-pim-yang] 1339 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1340 Y., and f. hu, "A YANG Data Model for Protocol Independent 1341 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1342 progress), May 2018. 1344 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1345 DOI 10.17487/RFC3688, January 2004, 1346 . 1348 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1349 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1350 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1351 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1352 2016, . 1354 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1355 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1356 DOI 10.17487/RFC8407, October 2018, 1357 . 1359 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1360 E., and A. Tripathy, "Subscription to YANG Notifications", 1361 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1362 . 1364 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1365 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1366 September 2019, . 1368 Appendix A. Data Tree Example 1370 This section contains an example of an instance data tree in JSON 1371 encoding [RFC7951], containing configuration data. 1373 A.1. The global and peer configuration example 1375 { 1376 "ietf-interfaces:interfaces": { 1377 "interface": [ 1378 { 1379 "name": "eth1", 1380 "description": "An interface with MSDP enabled.", 1381 "type": "iana-if-type:ethernetCsmacd", 1382 "ietf-ip:ipv4": { 1383 "forwarding": true, 1384 "address": [ 1385 { 1386 "ip": "192.0.2.1", 1387 "prefix-length": 24 1388 } 1389 ] 1390 } 1391 } 1392 ] 1393 }, 1394 "ietf-access-control-list:acls": { 1395 "acl": [ 1396 { 1397 "name": "msdp-default-peer-policy", 1398 "type": "ietf-access-control-list:ipv4-acl-type", 1399 "aces": { 1400 "ace": [ 1401 { 1402 "name": "accept", 1403 "actions": { 1404 "forwarding": "ietf-access-control-list:accept" 1405 } 1406 } 1407 ] 1408 } 1409 } 1410 ] 1411 }, 1412 "ietf-routing:routing": { 1413 "router-id": "203.0.113.1", 1414 "control-plane-protocols": { 1415 "control-plane-protocol": [ 1416 { 1417 "type": "ietf-msdp:msdp", 1418 "name": "msdp-1", 1419 "ietf-msdp:msdp": { 1420 "global": { 1421 "tcp-connection-source": "eth1", 1422 "default-peer": [ 1423 { 1424 "peer-addr": "198.51.100.8", 1425 "prefix-policy": "msdp-default-peer-policy" 1426 } 1427 ], 1428 "originating-rp": { 1429 "interface": "eth1" 1430 }, 1431 "sa-limit": 0, 1432 "ttl-threshold": 1 1433 }, 1434 "peers":{ 1435 "peer":[ 1436 { 1437 "address": "198.51.100.8", 1438 "enabled": true, 1439 "tcp-connection-source": "eth1", 1440 "description": "x", 1441 "mesh-group": "x", 1442 "peer-as": 100, 1443 "sa-limit": 0, 1444 "timer":{ 1445 "connect-retry-interval": 0, 1446 "holdtime-interval": 3, 1447 "keepalive-interval": 1 1448 }, 1449 "ttl-threshold": 1 1450 } 1451 ] 1452 } 1453 } 1454 } 1455 ] 1456 } 1457 } 1458 } 1460 A.2. The state example 1462 { 1463 "ietf-interfaces:interfaces": { 1464 "interface": [ 1465 { 1466 "name": "eth1", 1467 "description": "An interface with MSDP enabled.", 1468 "type": "iana-if-type:ethernetCsmacd", 1469 "phys-address": "00:00:5e:00:53:01", 1470 "oper-status": "up", 1471 "statistics": { 1472 "discontinuity-time": "2020-02-22T11:22:33+02:00" 1473 }, 1474 "ietf-ip:ipv4": { 1475 "forwarding": true, 1476 "mtu": 1500, 1477 "address": [ 1478 { 1479 "ip": "192.0.2.1", 1480 "prefix-length": 24, 1481 "origin": "static" 1482 } 1483 ] 1484 } 1485 } 1486 ] 1487 }, 1488 "ietf-access-control-list:acls": { 1489 "acl": [ 1490 { 1491 "name": "msdp-default-peer-policy", 1492 "type": "ietf-access-control-list:ipv4-acl-type", 1493 "aces": { 1494 "ace": [ 1495 { 1496 "name": "accept", 1497 "actions": { 1498 "forwarding": "ietf-access-control-list:accept" 1499 } 1500 } 1501 ] 1502 } 1503 } 1504 ] 1505 }, 1506 "ietf-routing:routing": { 1507 "router-id": "203.0.113.1", 1508 "control-plane-protocols": { 1509 "control-plane-protocol": [ 1510 { 1511 "type": "ietf-msdp:msdp", 1512 "name": "msdp-1", 1513 "ietf-msdp:msdp":{ 1514 "global":{ 1515 "tcp-connection-source": "eth1", 1516 "default-peer": [ 1517 { 1518 "peer-addr": "198.51.100.8", 1519 "prefix-policy": "msdp-default-peer-policy" 1520 } 1521 ], 1522 "originating-rp": { 1523 "interface": "eth1" 1524 }, 1525 "sa-limit": 0, 1526 "ttl-threshold": 1 1527 }, 1528 "peers":{ 1529 "peer":[ 1530 { 1531 "address": "198.51.100.8", 1532 "enabled": true, 1533 "tcp-connection-source": "eth1", 1534 "description": "x", 1535 "mesh-group": "x", 1536 "peer-as": 100, 1537 "sa-limit": 0, 1538 "timer":{ 1539 "connect-retry-interval": 0, 1540 "holdtime-interval": 3, 1541 "keepalive-interval": 1 1542 }, 1543 "ttl-threshold": 1, 1544 "session-state": "established", 1545 "elapsed-time": 5, 1546 "is-default-peer": true, 1547 "keepalive-expire": 1, 1548 "reset-count": 1, 1549 "statistics": { 1550 "discontinuity-time": "2020-02-22T12:22:33+02:00" 1551 } 1552 } 1553 ] 1554 }, 1555 "sa-cache": { 1556 "entry": [ 1557 { 1558 "group": "233.252.0.23", 1559 "source-addr": "198.51.100.8", 1560 "origin-rp": [ 1561 { 1562 "rp-address": "203.0.113.10", 1563 "is-local-rp": false, 1564 "sa-adv-expire": 150 1565 } 1566 ], 1567 "state-attributes": { 1568 "up-time": 20, 1569 "expire": 120, 1570 "holddown-interval": 150, 1571 "peer-learned-from": "203.0.113.10", 1572 "rpf-peer": "203.0.113.10" 1573 } 1574 } 1575 ] 1577 } 1578 } 1579 } 1580 ] 1581 } 1582 } 1583 } 1585 A.3. The actions example 1587 This example shows the input data (in JSON) for executing an "sa- 1588 cache clear" action to clear the cache of all entries which match the 1589 group address of 233.252.0.23. 1591 { 1592 "ietf-msdp:sa-cache":{ 1593 "input":{ 1594 "entry":{ 1595 "group":"233.252.0.23" 1596 } 1597 } 1598 } 1599 } 1601 Authors' Addresses 1603 Xufeng Liu 1604 Volta Networks 1606 Email: xufeng.liu.ietf@gmail.com 1608 Zheng Zhang (editor) 1609 ZTE Corporation 1610 No. 50 Software Ave, Yuhuatai Distinct 1611 Nanjing 1612 China 1614 Email: zzhang_ietf@hotmail.com 1616 Anish Peter 1617 Individual contributor 1619 Email: anish.ietf@gmail.com 1620 Mahesh Sivakumar 1621 Juniper networks 1622 1133 Innovation Way 1623 Sunnyvale, CALIFORNIA 94089 1624 USA 1626 Email: sivakumar.mahesh@gmail.com 1628 Feng Guo 1629 Huawei Technologies 1630 Huawei Bld., No.156 Beiqing Rd. 1631 Beijing 100095 1632 China 1634 Email: guofeng@huawei.com 1636 Pete McAllister 1637 Metaswitch Networks 1638 100 Church Street 1639 Enfield EN2 6BQ 1640 UK 1642 Email: pete.mcallister@metaswitch.com