idnits 2.17.1 draft-ietf-pim-msdp-yang-16.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 (March 8, 2020) is 1509 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: September 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 March 8, 2020 16 A YANG Data Model for Multicast Source Discovery Protocol (MSDP) 17 draft-ietf-pim-msdp-yang-16 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 September 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. 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 . . . . . . . . . . . . . . . . . . . . . 25 72 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 73 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 26 76 9.2. Informative References . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . . . 33 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 The actions can be used to clear the connection of one specific MSDP 341 peer, or clear the connections of all the MSDP peers, or clear some 342 or all the SA caches. 344 4. MSDP YANG Model 346 This module references [RFC3618], [RFC4271], [RFC6991], [RFC7761], 347 [RFC8177], [RFC8294], [RFC8343], [RFC8344], [RFC8349], [RFC8519]. 349 file "ietf-msdp@2020-03-08.yang" 350 module ietf-msdp { 352 yang-version 1.1; 354 namespace "urn:ietf:params:xml:ns:yang:ietf-msdp"; 355 prefix msdp; 357 import ietf-yang-types { 358 prefix "yang"; 359 reference "RFC 6991: Common YANG Data Types"; 360 } 362 import ietf-inet-types { 363 prefix "inet"; 364 reference "RFC 6991: Common YANG Data Types"; 365 } 367 import ietf-routing { 368 prefix "rt"; 369 reference "RFC 8349: A YANG Data Model for Routing Management 370 (NMDA Version)"; 371 } 373 import ietf-interfaces { 374 prefix "if"; 375 reference "RFC 8343: A YANG Data Model for Interface Management"; 376 } 378 import ietf-ip { 379 prefix "ip"; 380 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-03-08 { 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 reference 538 "RFC 8177: YANG Data Model for Key Chains."; 539 } 540 } 541 description 542 "Choice of authentication."; 543 } 544 } 545 } // authentication-container 547 grouping tcp-connect-source { 548 description 549 "Attribute to configure peer TCP connection source."; 550 leaf tcp-connection-source { 551 type if:interface-ref; 552 must "/if:interfaces/if:interface[if:name = current()]/" 553 + "ip:ipv4/ip:enabled != 'false'" { 554 error-message "The interface must have IPv4 enabled."; 555 description 556 "The interface must have IPv4 enabled."; 557 reference 558 "RFC 8343: A YANG Data Model for Interface Management"; 559 } 560 description 561 "The interface is to be the source for the TCP 562 connection. It is a reference to an entry in the global 563 interface list."; 564 } 565 } // tcp-connect-source 567 grouping global-config-attributes { 568 description "Global MSDP configuration."; 570 uses tcp-connect-source; 572 list default-peer { 573 if-feature filter-policy; 574 key "peer-addr prefix-policy"; 576 description 577 "The default peer accepts all MSDP SA messages. 578 A default peer is needed in topologies where MSDP peers 579 do not coexist with BGP peers. The reverse path 580 forwarding (RPF) check on SA messages will fail, and no 581 SA messages will be accepted. In these cases, you can 582 configure the peer as a default peer and bypass RPF checks."; 584 leaf peer-addr { 585 type leafref { 586 path "../../../peers/peer/address"; 587 } 588 mandatory true; 589 description 590 "Reference to a peer that is in the peer list."; 591 } 592 leaf prefix-policy { 593 type leafref { 594 path "/acl:acls/acl:acl/acl:name"; 595 } 596 description 597 "If specified, only those SA entries whose RP is 598 permitted in the prefix list are allowed; 599 if not specified, all SA messages from the default 600 peer are accepted."; 601 reference 602 "RFC 8519: YANG Data Model for Network Access Control 603 Lists (ACLs)"; 604 } 605 } // default-peer 607 container originating-rp { 608 description 609 "The container of Originating RP."; 610 leaf interface { 611 type if:interface-ref; 612 must "/if:interfaces/if:interface[if:name = current()]/" 613 + "ip:ipv4/ip:enabled != 'false'" { 614 error-message "The interface must have IPv4 enabled."; 615 description 616 "The interface must have IPv4 enabled."; 617 reference 618 "RFC 8343: A YANG Data Model for Interface Management"; 619 } 620 description 621 "Reference to an entry in the global interface 622 list. 623 IP address of the interface used in the RP field of 624 an SA message entry. When Anycast RPs are used, all 625 RPs use the same IP address. This parameter can be 626 used to define a unique IP address for the RP of each 627 MSDP peer. 628 By default, the software uses the RP address of the 629 local system."; 630 } 631 } // originating-rp 633 uses sa-filter-container; 635 leaf sa-limit { 636 type uint32; 637 description 638 "A limit on the number of SA entries accepted. 639 By default, there is no limit."; 640 } 641 uses ttl-threshold; 642 } // global-config-attributes 644 grouping peer-config-attributes { 645 description "Per peer configuration for MSDP."; 647 uses authentication-container; 648 leaf enabled { 649 type boolean; 650 description 651 "'true' if peer is enabled; 652 'false' if peer is disabled."; 653 } 654 uses tcp-connect-source; 656 leaf description { 657 type string; 658 description 659 "The peer description."; 660 } 661 leaf mesh-group { 662 type string; 663 description 664 "The name of mesh-group which this peer belongs to."; 665 reference 666 "RFC 3618: Multicast Source Discovery Protocol (MSDP), 667 section 10.2."; 668 } 669 leaf peer-as { 670 if-feature peer-as-verification; 671 type inet:as-number; 672 description 673 "Peer's autonomous system number (ASN). Using peer-as to 674 do verification can provide more controlled ability. 675 The value can be compared with the BGP peer AS. If they 676 are different, the SA comes from this peer may be rejected. 677 If the AS number is the same as the local AS, then the 678 peer is within the same domain; otherwise, this peer is 679 external to the domain. Like the definition and usage 680 in BGP."; 681 reference 682 "RFC 4271: A Border Gateway Protocol 4 (BGP-4)"; 683 } 684 uses sa-filter-container; 685 leaf sa-limit { 686 type uint32; 687 description 688 "A limit on the number of SA entries accepted from this 689 peer. By default, there is no limit."; 690 } 691 container timer { 692 description "Timer attributes."; 693 reference 694 "RFC 3618: Multicast Source Discovery Protocol (MSDP), 695 section 5."; 696 leaf connect-retry-interval { 697 type uint16; 698 units seconds; 699 default 30; 700 description "Peer timer for connect-retry. 701 By default, MSDP peers wait 30 seconds after 702 session is reset."; 703 } 704 leaf holdtime-interval { 705 type uint16 { 706 range "3..65535"; 707 } 708 units seconds; 709 default 75; 710 description "The SA hold down period of this MSDP peer."; 711 } 712 leaf keepalive-interval { 713 type uint16 { 714 range "1..65535"; 715 } 716 units seconds; 717 must '. < ../holdtime-interval' { 718 error-message 719 "The keepalive interval must be smaller than the 720 hold time interval"; 721 } 722 default 60; 723 description "The keepalive timer of this MSDP peer."; 724 } 725 } // timer 726 uses ttl-threshold; 727 } // peer-config-attributes 729 grouping peer-state-attributes { 730 description "Per peer state attributes for MSDP."; 732 leaf session-state { 733 type enumeration { 734 enum disabled { 735 description "Disabled."; 736 } 737 enum inactive { 738 description "Inactive."; 739 } 740 enum listen { 741 description "Listen."; 742 } 743 enum connecting { 744 description "Connecting."; 745 } 746 enum established { 747 description "Established."; 748 } 749 } 750 config false; 751 description 752 "Peer session state."; 753 reference 754 "RFC 3618: Multicast Source Discovery Protocol (MSDP), 755 section 11."; 756 } 757 leaf elapsed-time { 758 type yang:gauge32; 759 units seconds; 760 config false; 761 description "Elapsed time for being in a state."; 762 } 763 leaf connect-retry-expire { 764 type uint32; 765 units seconds; 766 config false; 767 description "Connect retry expire time of peer connection."; 768 } 769 leaf hold-expire { 770 type uint16; 771 units seconds; 772 config false; 773 description "Hold expire time of peer connection."; 774 } 775 leaf is-default-peer { 776 type boolean; 777 config false; 778 description "'true' if this peer is one of the default peer."; 779 } 780 leaf keepalive-expire { 781 type uint16; 782 units seconds; 783 config false; 784 description "Keepalive expire time of this peer."; 785 } 786 leaf reset-count { 787 type yang:zero-based-counter32; 788 config false; 789 description "The reset count of this peer."; 790 } 792 container statistics { 793 config false; 794 description 795 "A container defining statistics attributes."; 797 leaf discontinuity-time { 798 type yang:date-and-time; 799 description 800 "The time on the most recent occasion at which any one 801 or more of the statistic counters suffered a 802 discontinuity. If no such discontinuities have occurred 803 since the last re-initialization of the local 804 management subsystem, then this node contains the time 805 the local management subsystem re-initialized itself."; 806 } 808 container error { 809 description 810 "A grouping defining error statistics attributes."; 811 leaf rpf-failure { 812 type uint32; 813 description "Number of RPF failures."; 814 } 815 } 817 container queue { 818 description 819 "A container includes queue statistics attributes."; 820 leaf size-in { 821 type uint32; 822 description 823 "The number of messages received from the peer 824 currently queued."; 825 } 826 leaf size-out { 827 type uint32; 828 description 829 "The number of messages queued to be sent to the peer."; 830 } 831 } 833 container received { 834 description "Received message counters."; 835 uses statistics-sent-received; 836 } 837 container sent { 838 description "Sent message counters."; 839 uses statistics-sent-received; 840 } 841 } // statistics 842 } // peer-state-attributes 844 grouping sa-filter-container { 845 description "A container defining SA filters."; 846 container sa-filter { 847 description 848 "Specifies an access control list (ACL) to filter source 849 active (SA) messages coming in to or going out of the 850 peer."; 851 leaf in { 852 type leafref { 853 path "/acl:acls/acl:acl/acl:name"; 854 } 855 description 856 "Filters incoming SA messages only. 857 The value is the name to uniquely identify a 858 policy that contains one or more rules used to 859 accept or reject MSDP SA messages. 860 If the policy is not specified, all MSDP SA messages are 861 accepted."; 862 reference 863 "RFC 8519: YANG Data Model for Network Access Control 864 Lists (ACLs)"; 865 } 866 leaf out { 867 type leafref { 868 path "/acl:acls/acl:acl/acl:name"; 869 } 870 description 871 "Filters outgoing SA messages only. 872 The value is the name to uniquely identify a 873 policy that contains one or more rules used to 874 accept or reject MSDP SA messages. 875 If the policy is not specified, all MSDP SA messages are 876 sent."; 877 reference 878 "RFC 8519: YANG Data Model for Network Access Control 879 Lists (ACLs)"; 880 } 881 } // sa-filter 882 } // sa-filter-container 884 grouping ttl-threshold { 885 description "Attribute to configure TTL threshold."; 886 leaf ttl-threshold { 887 type uint8 { 888 range 1..255; 889 } 890 description "Maximum number of hops data packets can 891 traverse before being dropped."; 892 } 893 } // ttl-threshold 895 grouping statistics-sent-received { 896 description 897 "A grouping defining sent and received statistics attributes."; 898 leaf keepalive { 899 type yang:counter64; 900 description 901 "The number of keepalive messages."; 902 } 903 leaf notification { 904 type yang:counter64; 905 description 906 "The number of notification messages."; 907 } 908 leaf sa-message { 909 type yang:counter64; 910 description 911 "The number of SA messages."; 912 } 913 leaf sa-response { 914 type yang:counter64; 915 description 916 "The number of SA response messages."; 917 } 918 leaf sa-request { 919 type yang:counter64; 920 description 921 "The number of SA request messages."; 922 } 923 leaf total { 924 type yang:counter64; 925 description 926 "The number of total messages."; 927 } 928 } // statistics-sent-received 930 /* 931 * Data nodes 932 */ 933 augment "/rt:routing/rt:control-plane-protocols/" 934 + "rt:control-plane-protocol" { 935 when "derived-from-or-self(rt:type, 'msdp:msdp')" { 936 description 937 "This augmentation is only valid for a routing protocol 938 instance of MSDP."; 939 } 940 description 941 "MSDP augmentation to routing control-plane protocol 942 configuration and state."; 943 container msdp { 944 description 945 "MSDP configuration and operational state data."; 947 container global { 948 description 949 "Global attributes."; 950 uses global-config-attributes; 951 } 953 container peers { 954 description 955 "Containing a list of peers."; 956 list peer { 957 key "address"; 958 description 959 "List of MSDP peers."; 960 leaf address { 961 type inet:ipv4-address; 962 description 963 "The address of the peer"; 964 } 965 action clear-peer { 966 description 967 "Clears the TCP connection to the peer."; 968 } 969 uses peer-config-attributes; 970 uses peer-state-attributes; 971 } 972 } 974 action clear-all-peers { 975 description 976 "'All peers' TCP connection are cleared."; 977 } 979 container sa-cache { 980 config false; 981 description 982 "The SA cache information."; 983 list entry { 984 key "group source-addr"; 985 description "A list of SA cache entries."; 986 leaf group { 987 type rt-types:ipv4-multicast-group-address; 988 description "The group address of this SA cache."; 989 } 990 leaf source-addr { 991 type rt-types:ipv4-multicast-source-address; 992 description "Source IPv4 address."; 993 } 994 list origin-rp { 995 key "rp-address"; 996 description "Origin RP information."; 997 leaf rp-address { 998 type inet:ipv4-address; 999 description 1000 "The RP address. IP address used in the RP field 1001 of an SA message entry."; 1002 } 1003 leaf is-local-rp { 1004 type boolean; 1005 description 1006 "'true' if the RP is local; 1007 'false' if The RP is not local."; 1008 } 1009 leaf sa-adv-expire { 1010 type uint32; 1011 units seconds; 1012 description 1013 "The remaining time duration before expiration 1014 of the periodic SA advertisement timer on a 1015 local RP."; 1016 } 1017 } 1019 container state-attributes { 1020 description "SA cache state attributes for MSDP."; 1022 leaf up-time { 1023 type yang:gauge32; 1024 units seconds; 1025 description 1026 "Indicates the duration time when this SA entry is 1027 created in the cache. MSDP is a periodic protocol, 1028 the value can be used to check the state of 1029 SA cache."; 1030 } 1031 leaf expire { 1032 type yang:gauge32; 1033 units seconds; 1034 description 1035 "Indicates the duration time when this SA entry in 1036 the cache times out. MSDP is a periodic protocol, 1037 the value can be used to check the state of 1038 SA cache."; 1039 } 1040 leaf holddown-interval { 1041 type uint32; 1042 units seconds; 1043 description 1044 "Hold-down timer value for SA forwarding."; 1045 reference 1046 "RFC 3618: Multicast Source Discovery Protocol 1047 (MSDP), section 5.3."; 1048 } 1049 leaf peer-learned-from { 1050 type inet:ipv4-address; 1051 description 1052 "The address of the peer that we learned this 1053 SA from."; 1054 } 1055 leaf rpf-peer { 1056 type inet:ipv4-address; 1057 description 1058 "The address is the SA's originating RP."; 1059 } 1060 } // state-attributes 1061 } // entry 1063 action clear { 1064 description 1065 "Clears MSDP source active (SA) cache entries."; 1066 input { 1067 container entry { 1068 presence "If a particular entry is cleared."; 1069 description 1070 "The SA cache (S,G) or (*,G) entry to be cleared. If 1071 this is not provided, all entries are cleared."; 1072 leaf group { 1073 type rt-types:ipv4-multicast-group-address; 1074 mandatory true; 1075 description "The group address"; 1076 } 1077 leaf source-addr { 1078 type rt-types:ipv4-multicast-source-address; 1079 description 1080 "Address of multicast source to be cleared. If this 1081 is not provided then all entries related to the 1082 given group are cleared."; 1083 } 1084 } 1085 leaf peer-address { 1086 type inet:ipv4-address; 1087 description 1088 "Peer IP address from which MSDP SA cache entries have 1089 been learned. If this is not provided, entries learned 1090 from all peers are cleared."; 1091 } 1092 leaf peer-as { 1093 type inet:as-number; 1094 description 1095 "ASN from which MSDP SA cache entries have been learned. 1096 If this is not provided, entries learned from all AS's 1097 are cleared."; 1098 } 1099 } 1100 } // clear 1102 } // sa-cache 1103 } // msdp 1104 } // augment 1105 } 1106 1108 5. Security Considerations 1110 The YANG module specified in this document defines a schema for data 1111 that is designed to be accessed via network management protocols such 1112 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 1113 is the secure transport layer, and the mandatory-to-implement secure 1114 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1115 is HTTPS, and the mandatory-to-implement secure transport is TLS 1116 [RFC8446]. 1118 The NETCONF access control model [RFC8341] provides the means to 1119 restrict access for particular NETCONF or RESTCONF users to a 1120 preconfigured subset of all available NETCONF or RESTCONF protocol 1121 operations and content. 1123 There are a number of data nodes defined in this YANG module that are 1124 writable/creatable/deletable (i.e., config true, which is the 1125 default). These data nodes may be considered sensitive or vulnerable 1126 in some network environments. Write operations (e.g., edit-config) 1127 to these data nodes without proper protection can have a negative 1128 effect on network operations. These are the subtrees and data nodes 1129 and their sensitivity/vulnerability: 1131 Under /rt:routing/rt:control-plane-protocols/msdp, 1133 msdp:global 1135 This subtree specifies the configuration for the MSDP attributes 1136 at the global level. Modifying the configuration can cause MSDP 1137 default peers to be deleted or the connection to be rebuilt, and 1138 the SA's unexpected filtering. 1140 msdp:peers 1142 This subtree specifies the configuration for the MSDP attributes 1143 at the peer level. Modifying the configuration will allow 1144 unexpected MSDP peer establishment and unexpected SA information 1145 learning and advertisement. 1147 Some of the readable data nodes in this YANG module may be considered 1148 sensitive or vulnerable in some network environments. It is thus 1149 important to control read access (e.g., via get, get-config, or 1150 notification) to these data nodes. These are the subtrees and data 1151 nodes and their sensitivity/vulnerability: 1153 /rt:routing/rt:control-plane-protocols/msdp, 1155 Unauthorized access to any data node of the above subtree can 1156 disclose the operational state information of MSDP on this device. 1157 For example, the peer information disclosure may lead to forged 1158 connection attack, the ACL nodes uncorrected modification may lead to 1159 the filter errors. 1161 The "key" field is also a sensitive readable configuration. The 1162 unauthorized reading function may lead to the password leaking. 1163 Modification will allow the unexpected peer connection rebuilding. 1164 Authentication configuration is supported via the specification of 1165 key-chains [RFC8177] or the direct specification of key and 1166 authentication algorithm. Hence, authentication configuration in the 1167 "authentication" container inherits the security considerations of 1168 [RFC8177]. This includes the considerations with respect to the 1169 local storage and handling of authentication keys. 1171 Some of the RPC operations in this YANG module may be considered 1172 sensitive or vulnerable in some network environments. It is thus 1173 important to control access to these operations. These are the 1174 operations and their sensitivity/vulnerability: 1176 /rt:routing/rt:control-plane-protocols/msdp:clear-peer, 1178 /rt:routing/rt:control-plane-protocols/msdp:clear-sa-cache, 1180 Unauthorized access to any of the above action operations can lead to 1181 the MSDP peers connection rebuilding or delete SA records on this 1182 device. 1184 6. IANA Considerations 1186 RFC Ed.: Please replace all occurrences of 'XXXX' with the actual RFC 1187 number (and remove this note). 1189 The IANA is requested to assign one new URI from the IETF XML 1190 registry [RFC3688]. Authors are suggesting the following URI: 1192 URI: urn:ietf:params:xml:ns:yang:ietf-msdp 1194 Registrant Contact: The IESG 1196 XML: N/A, the requested URI is an XML namespace 1197 This document also requests one new YANG module name in the YANG 1198 Module Names registry [RFC6020] with the following suggestion: 1200 name: ietf-msdp 1202 namespace: urn:ietf:params:xml:ns:yang:ietf-msdp 1204 prefix: msdp 1206 reference: RFC XXXX 1208 7. Contributors 1210 The authors would like to thank Yisong Liu (liuyisong@huawei.com), 1211 Benchong Xu (xu.benchong@zte.com.cn), Tanmoy Kundu 1212 (tanmoy.kundu@alcatel-lucent.com) for their valuable contributions. 1214 8. Acknowledgement 1216 The authors would like to thank Stig Venaas, Jake Holland for their 1217 valuable comments and suggestions. 1219 9. References 1221 9.1. Normative References 1223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1224 Requirement Levels", BCP 14, RFC 2119, 1225 DOI 10.17487/RFC2119, March 1997, 1226 . 1228 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 1229 Discovery Protocol (MSDP)", RFC 3618, 1230 DOI 10.17487/RFC3618, October 2003, 1231 . 1233 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1234 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1235 DOI 10.17487/RFC4271, January 2006, 1236 . 1238 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1239 the Network Configuration Protocol (NETCONF)", RFC 6020, 1240 DOI 10.17487/RFC6020, October 2010, 1241 . 1243 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1244 and A. Bierman, Ed., "Network Configuration Protocol 1245 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1246 . 1248 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1249 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1250 . 1252 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1253 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1254 . 1256 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1257 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1258 . 1260 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1261 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1262 . 1264 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1265 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1266 . 1268 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1269 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1270 May 2017, . 1272 [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. 1273 Zhang, "YANG Data Model for Key Chains", RFC 8177, 1274 DOI 10.17487/RFC8177, June 2017, 1275 . 1277 [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, 1278 "Common YANG Data Types for the Routing Area", RFC 8294, 1279 DOI 10.17487/RFC8294, December 2017, 1280 . 1282 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1283 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1284 . 1286 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1287 Access Control Model", STD 91, RFC 8341, 1288 DOI 10.17487/RFC8341, March 2018, 1289 . 1291 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1292 and R. Wilton, "Network Management Datastore Architecture 1293 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1294 . 1296 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1297 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1298 . 1300 [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", 1301 RFC 8344, DOI 10.17487/RFC8344, March 2018, 1302 . 1304 [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for 1305 Routing Management (NMDA Version)", RFC 8349, 1306 DOI 10.17487/RFC8349, March 2018, 1307 . 1309 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1310 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1311 . 1313 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1314 "YANG Data Model for Network Access Control Lists (ACLs)", 1315 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1316 . 1318 9.2. Informative References 1320 [I-D.ietf-pim-yang] 1321 Liu, X., McAllister, P., Peter, A., Sivakumar, M., Liu, 1322 Y., and f. hu, "A YANG Data Model for Protocol Independent 1323 Multicast (PIM)", draft-ietf-pim-yang-17 (work in 1324 progress), May 2018. 1326 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1327 DOI 10.17487/RFC3688, January 2004, 1328 . 1330 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1331 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1332 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1333 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1334 2016, . 1336 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1337 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1338 DOI 10.17487/RFC8407, October 2018, 1339 . 1341 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 1342 E., and A. Tripathy, "Subscription to YANG Notifications", 1343 RFC 8639, DOI 10.17487/RFC8639, September 2019, 1344 . 1346 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 1347 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 1348 September 2019, . 1350 Appendix A. Data Tree Example 1352 This section contains an example of an instance data tree in JSON 1353 encoding [RFC7951], containing configuration data. 1355 A.1. The global and peer configuration example 1357 { 1358 "ietf-interfaces:interfaces": { 1359 "interface": [ 1360 { 1361 "name": "eth1", 1362 "description": "An interface with MSDP enabled.", 1363 "type": "iana-if-type:ethernetCsmacd", 1364 "ietf-ip:ipv4": { 1365 "forwarding": true, 1366 "address": [ 1367 { 1368 "ip": "192.0.2.1", 1369 "prefix-length": 24 1370 } 1371 ] 1372 } 1373 } 1374 ] 1375 }, 1376 "ietf-access-control-list:acls": { 1377 "acl": [ 1378 { 1379 "name": "msdp-default-peer-policy", 1380 "type": "ietf-access-control-list:ipv4-acl-type", 1381 "aces": { 1382 "ace": [ 1383 { 1384 "name": "accept", 1385 "actions": { 1386 "forwarding": "ietf-access-control-list:accept" 1387 } 1388 } 1389 ] 1390 } 1391 } 1392 ] 1393 }, 1394 "ietf-routing:routing": { 1395 "router-id": "203.0.113.1", 1396 "control-plane-protocols": { 1397 "control-plane-protocol": [ 1398 { 1399 "type": "ietf-msdp:msdp", 1400 "name": "msdp-1", 1401 "ietf-msdp:msdp": { 1402 "global": { 1403 "tcp-connection-source": "eth1", 1404 "default-peer": [ 1405 { 1406 "peer-addr": "198.51.100.8", 1407 "prefix-policy": "msdp-default-peer-policy" 1408 } 1409 ], 1410 "originating-rp": { 1411 "interface": "eth1" 1412 }, 1413 "sa-limit": 0, 1414 "ttl-threshold": 1 1415 }, 1416 "peers":{ 1417 "peer":[ 1418 { 1419 "address": "198.51.100.8", 1420 "enabled": true, 1421 "tcp-connection-source": "eth1", 1422 "description": "x", 1423 "mesh-group": "x", 1424 "peer-as": 100, 1425 "sa-limit": 0, 1426 "timer":{ 1427 "connect-retry-interval": 0, 1428 "holdtime-interval": 3, 1429 "keepalive-interval": 1 1430 }, 1431 "ttl-threshold": 1 1433 } 1434 ] 1435 } 1436 } 1437 } 1438 ] 1439 } 1440 } 1441 } 1443 A.2. The state example 1445 { 1446 "ietf-interfaces:interfaces": { 1447 "interface": [ 1448 { 1449 "name": "eth1", 1450 "description": "An interface with MSDP enabled.", 1451 "type": "iana-if-type:ethernetCsmacd", 1452 "phys-address": "00:00:5e:00:53:01", 1453 "oper-status": "up", 1454 "statistics": { 1455 "discontinuity-time": "2020-02-22T11:22:33+02:00" 1456 }, 1457 "ietf-ip:ipv4": { 1458 "forwarding": true, 1459 "mtu": 1500, 1460 "address": [ 1461 { 1462 "ip": "192.0.2.1", 1463 "prefix-length": 24, 1464 "origin": "static" 1465 } 1466 ] 1467 } 1468 } 1469 ] 1470 }, 1471 "ietf-access-control-list:acls": { 1472 "acl": [ 1473 { 1474 "name": "msdp-default-peer-policy", 1475 "type": "ietf-access-control-list:ipv4-acl-type", 1476 "aces": { 1477 "ace": [ 1478 { 1479 "name": "accept", 1480 "actions": { 1481 "forwarding": "ietf-access-control-list:accept" 1482 } 1483 } 1484 ] 1485 } 1486 } 1487 ] 1488 }, 1489 "ietf-routing:routing": { 1490 "router-id": "203.0.113.1", 1491 "control-plane-protocols": { 1492 "control-plane-protocol": [ 1493 { 1494 "type": "ietf-msdp:msdp", 1495 "name": "msdp-1", 1496 "ietf-msdp:msdp":{ 1497 "global":{ 1498 "tcp-connection-source": "eth1", 1499 "default-peer": [ 1500 { 1501 "peer-addr": "198.51.100.8", 1502 "prefix-policy": "msdp-default-peer-policy" 1503 } 1504 ], 1505 "originating-rp": { 1506 "interface": "eth1" 1507 }, 1508 "sa-limit": 0, 1509 "ttl-threshold": 1 1510 }, 1511 "peers":{ 1512 "peer":[ 1513 { 1514 "address": "198.51.100.8", 1515 "enabled": true, 1516 "tcp-connection-source": "eth1", 1517 "description": "x", 1518 "mesh-group": "x", 1519 "peer-as": 100, 1520 "sa-limit": 0, 1521 "timer":{ 1522 "connect-retry-interval": 0, 1523 "holdtime-interval": 3, 1524 "keepalive-interval": 1 1525 }, 1526 "ttl-threshold": 1, 1527 "session-state": "established", 1528 "elapsed-time": 5, 1529 "is-default-peer": true, 1530 "keepalive-expire": 1, 1531 "reset-count": 1, 1532 "statistics": { 1533 "discontinuity-time": "2020-02-22T12:22:33+02:00" 1534 } 1535 } 1536 ] 1537 }, 1538 "sa-cache": { 1539 "entry": [ 1540 { 1541 "group": "238.202.233.23", 1542 "source-addr": "198.51.100.8", 1543 "origin-rp": [ 1544 { 1545 "rp-address": "203.0.113.10", 1546 "is-local-rp": false, 1547 "sa-adv-expire": 150 1548 } 1549 ], 1550 "state-attributes": { 1551 "up-time": 20, 1552 "expire": 120, 1553 "holddown-interval": 150, 1554 "peer-learned-from": "203.0.113.10", 1555 "rpf-peer": "203.0.113.10" 1556 } 1557 } 1558 ] 1559 } 1560 } 1561 } 1562 ] 1563 } 1564 } 1565 } 1567 A.3. The actions example 1569 { 1570 "ietf-msdp:input":{ 1571 "entry":{ 1572 "group":"238.202.233.23" 1573 } 1574 } 1575 } 1577 Authors' Addresses 1579 Xufeng Liu 1580 Volta Networks 1582 Email: xufeng.liu.ietf@gmail.com 1584 Zheng Zhang (editor) 1585 ZTE Corporation 1586 No. 50 Software Ave, Yuhuatai Distinct 1587 Nanjing 1588 China 1590 Email: zzhang_ietf@hotmail.com 1592 Anish Peter 1593 Individual contributor 1595 Email: anish.ietf@gmail.com 1597 Mahesh Sivakumar 1598 Juniper networks 1599 1133 Innovation Way 1600 Sunnyvale, CALIFORNIA 94089 1601 USA 1603 Email: sivakumar.mahesh@gmail.com 1605 Feng Guo 1606 Huawei Technologies 1607 Huawei Bld., No.156 Beiqing Rd. 1608 Beijing 100095 1609 China 1611 Email: guofeng@huawei.com 1613 Pete McAllister 1614 Metaswitch Networks 1615 100 Church Street 1616 Enfield EN2 6BQ 1617 UK 1619 Email: pete.mcallister@metaswitch.com