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