idnits 2.17.00 (12 Aug 2021) /tmp/idnits12861/draft-sdry-bmwg-mvpnscale-02.txt: -(1052): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2486. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 41 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.5, updated by RFC 4748 boilerplate, a section with a similar start was also found: This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 1075 has weird spacing: '...nstance is us...' == Line 1200 has weird spacing: '...figured on DU...' == Line 1243 has weird spacing: '...tion of mrout...' == Line 1644 has weird spacing: '...tes are in en...' == Line 1652 has weird spacing: '...tes are in de...' == (2 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Sources emulated by test apparatus ports that are physically directly connected to DUT (port A1 in Figures 1 and 2) not have IP address from DUT's connected subnets, i.e. the DUT MUST not be the first hop router. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 16, 2007) is 5391 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) == Missing Reference: 'MVPN-DEPLOY' is mentioned on line 134, but not defined == Missing Reference: 'Br97' is mentioned on line 292, but not defined == Missing Reference: 'RFC1242' is mentioned on line 464, but not defined == Missing Reference: 'RFC2432' is mentioned on line 642, but not defined == Missing Reference: 'RFC2285' is mentioned on line 675, but not defined == Unused Reference: 'RFC4364' is defined on line 2419, but no explicit reference was found in the text == Unused Reference: 'MVPN-BCP' is defined on line 2430, but no explicit reference was found in the text == Outdated reference: draft-ietf-l3vpn-ppvpn-mcast-reqts has been published as RFC 4834 ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-ppvpn-mcast-reqts (ref. 'MVPN-REQ') == Outdated reference: draft-ietf-l3vpn-2547bis-mcast has been published as RFC 6513 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: draft-rosen-vpn-mcast has been published as RFC 6037 Summary: 5 errors (**), 0 flaws (~~), 21 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Dry 2 F. Calabria 3 I.Y Fung 4 Internet Draft Cisco 5 M. Napierala 6 AT&T 7 Y. Kamite 8 NTT Corporation 10 Expires: February 2008 August 16, 2007 12 Multicast VPN Scalability Benchmarking 13 draft-sdry-bmwg-mvpnscale-02.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that 18 any applicable patent or other IPR claims of which he or she is 19 aware have been or will be disclosed, and any of which he or she 20 becomes aware will be disclosed, in accordance with Section 6 of 21 BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on February 16, 2008. 41 Abstract 42 Multicast VPN (MVPN) is a service deployed by VPN service providers 43 to enable their customers to use IP multicast applications over VPNs. 44 With the increased popularity the scalability of deploying such a 45 service is becoming of a great interest. This document defines 46 standard metric and test methodology for characterizing and comparing 47 control plane MVPN scalability of Provider Edge (PE) devices that 48 implement MVPN service. 50 Table of Contents 52 1 Introduction...................................................3 53 2 Document Scope.................................................4 54 3 Terminology....................................................5 55 4 Key Words to Reflect Requirements..............................7 56 5 MVPN Metric Definition.........................................7 57 6 Test Environment...............................................8 58 6.1 Test Topologies..........................................9 59 6.2 Unicast Control Plane Setup..............................9 60 6.3 Multicast Control Plane Setup...........................10 61 6.4 Data Traffic Characteristics............................11 62 6.5 Test Apparatus Considerations...........................11 63 6.6 Considerations for distributed architecture platforms...12 64 7 Test Categories, Stimulus and Execution Methodology...........12 65 7.1 Steady State Testing Execution Methodology..............13 66 7.2 Failure Recovery Testing Execution Methodology..........14 67 8 Results Content and Reporting Format..........................15 68 8.1 Steady State Testing....................................15 69 8.2 Failure Recovery Testing................................16 70 9 Test Cases....................................................17 71 9.1 ''Empty'' MVPNs Scale.....................................18 72 9.2 PIM Enabled VPN C-Interfaces Scale......................20 73 9.3 PIM Neighborships Scale.................................22 74 9.4 Default MDT's (MI-PMSI's) PIM P-Instance Mroutes Scale..25 75 9.5 PIM C-instances Mroutes Scale...........................27 76 9.6 PIM C-Instances OIF Scale...............................30 77 9.7 Joined S-PMSI (Data MDT) Scale..........................32 78 9.8 Sourced S-PMSI (Data MDT) Scale.........................35 79 9.9 Data MDT (S-PMSI) Reuse.................................37 80 9.10 PIM C-instances J/P Suppression Effectiveness...........39 81 9.11 Additional Tests and Considerations for Devices Lacking 82 ''Efficient'' Join/Prune Suppression............................42 83 9.12 Scale of mVPNs spanning large number of PEs.............43 84 9.13 Scale of mVPNs with larger amount of state..............46 85 9.14 Scale of ''average'' size mVPNs...........................48 86 9.15 S-PMSI Switching Delay..................................50 87 9.16 Convergence of C-Instance PIM Joins.....................51 88 9.17 Effect of Co-locating C-RPs on a PE.....................53 89 10 Security Considerations....................................55 90 11 IANA Considerations........................................55 91 12 Acknowledgments............................................55 92 13 References.................................................56 93 13.1 Normative References....................................56 94 13.2 Informative References..................................56 95 Author's Addresses...............................................57 96 Intellectual Property Statement..................................57 97 Disclaimer of Validity...........................................58 98 Copyright Statement..............................................58 99 Acknowledgment...................................................58 101 1 Introduction 103 Multicast Virtual Private Network (MVPN) is a service offered by 104 BGP/MPLS VPN service providers, that provides a way for IP multicast 105 traffic to travel from one customer site to another. [L3VPN-MCAST] is 106 the framework describing how various protocols fit together to enable 107 such functionality. 109 With the increased popularity, the scalability of deploying MVPN is 110 becoming of a great interest. There is, however, no standard method 111 defined to measure and compare different implementations. This 112 document proposes a MVPN scalability metric and methodology for 113 testing and comparing control plane MVPN scalability of (Provider 114 Edge) PE devices in a standardized way. 116 Before describing the detailed test methodology, it is important to 117 review the key factors that impact the scalability of MVPN 118 deployments: 120 o The MVPN Metric is 14-tuple comprised of a set of variables that 121 indicate the overall scalability capabilities of a PE device 122 implementation in various dimensions. MVPN scalability is multi- 123 dimensional and can not be quantified with single parameter, thus 124 defining such a metric set is necessary. MVPN Metric will be 125 defined in section 5. The remaining of this document focuses on a 126 methodology that characterizes different dimensions of MVPN 127 Metric. 128 o MVPN design and operational choices (such as selection of PIM 129 protocol variant or extent of S-PMSI (data MDT) usage) SP makes, 130 impact the overall MVPN scalability of a PE device. Typically 131 there is a tradeoff between optimality and scalability. More 132 details on these choices with their tradeoffs are discussed in 134 [MVPN-DEPLOY] and [L3VPN-MCAST]. In this document design choices 135 most suitable for a goal of any given test case will be used which 136 may not necessarily be the same as recommended design choice for a 137 realistic deployment. 138 o MVPN is a service that is never deployed in isolation as it 139 requires underlying unicast VPN offering. Typically SPs add MVPN 140 service on PE devices that are already deployed and are providing 141 a large number of other services such as unicast L3VPNs, L2VPNs, 142 internet access, etc. Therefore, when considering MVPN scalability 143 in realistic deployments one needs to take into consideration the 144 level to which PE resources are already utilized and the available 145 headroom amount remaining. In this document it will be assumed 146 that MVPN service is deployed as an addition of a ''minimized'' 147 unicast control plane. 148 o MVPN Scalability of a PE device is different when the system is 149 subjected to different stimuli. For example overall scalability 150 achieved in steady state can be typically higher than when the 151 system is subjected to a network and/or device specific failures. 152 In this document a limited set of mandatory test stimuli will be 153 defined. 155 2 Document Scope 157 In IETF currently there are multiple proposals on architectures and 158 protocols for implementing MVPN service, as documented in [L3VPN- 159 MCAST]. The scope of this document is on benchmarking MVPN 160 scalability for the MVPN architecture described in [L3VPN-MCAST] 161 which uses PIM protocol for both PE-PE transmission of C-Multicast 162 routing information and to create 'tunnels' that instantiate 163 Multidirectional Inclusive P-Multicast Service Interfaces (MI-PMSIs) 164 and Selective P-Multicast Service Interfaces (S-PMSIs). The same 165 architecture is also described in [ROSEN-8] which is obsoleted by 166 [L3VPN-MCAST]. In the rest of the document this architecture will be 167 referred to as a ''ROSEN-8'' architecture. 169 In addition, test methodology and a good portion of the test cases 170 from this document can be used to assess a great deal but not all of 171 scalability aspects of other MVPN architectures from [L3VPN-MCAST]. 172 Thus, it can easily be used as a base for any future supplemental 173 benchmarking documents addressing other MVPN architectures. We 174 explicitly identified text applicable to all architectures from 175 [L3VPN-MCAST]. 177 Scope of this document is to address comparison between different 178 implementations of the same MVPN architecture, and not between 179 different MVPN architectures defined in [L3VPN-MCAST]. 181 This document proposes a MVPN metric and a test methodology to 182 compare the MVPN control plane scalability of PE devices in a 183 standardized way. In contrast, forwarding performance benchmarking is 184 not within the scope of this document. 186 Test methodology defines a standard set of test cases, their test 187 execution procedures, results content and reporting format. Standard 188 test environment is also defined for each test case. 190 Test cases 9.1-9.11 focus on determining implementation limits 191 individually for each of the key MVPN variables in a standard way. 192 Test cases (9.12-9.17) focus on determining implementation limits for 193 combination of all MVPN variables and will be helpful to operators 194 with network engineering for their deployments. Choices of values of 195 variables in test cases 9.12-9.17 were made using information from 196 the MVPN requirements survey conducted as part of [MVPN-REQ]. 198 Each test case addresses following two major testing types: 200 . Steady State Testing: Device Under Test (DUT) and network as a 201 whole are not subject to any failure stimulus/control plane events. 202 . Failure Recovery Testing: DUT and or network components are subject 203 to different failure stimulus that introduces one or more control 204 plane instability events. 206 In this document limited set of mandatory test stimuli is also 207 defined. 209 Note that the deployment of MVPN also consumes resources on P devices 210 in support of creation and maintenance of PMSIs / MDTs (Multicast 211 Distribution Trees). But, since MVPN functionality does not reside on 212 P and CE routers, they are beyond the scope of this document. 214 3 Terminology 216 DUT (Device Under Test) term will be used interchangeably with MVPN 217 PE device. 219 We will use term ''MVPN architecture'' to describe any specific subset 220 of protocols and procedures from [L3VPN-MCAST] that can enable MVPN 221 functionality on PE device. In contrast, we will use term ''MVPN 222 implementations'' to describe practical implementations of such ''MVPN 223 architectures''. 225 VPN related terms used in this document are defined in RFC4364 and 226 RFC2547bis. MVPN related terms used in this document are defined in 227 [L3VPN-MCAST]. 229 PIM (Protocol Independent Multicast) related terms are defined in 230 RFC4601. 232 For the reader's convenience, here is review of some key terms used 233 in this document: 235 MVPN (Multicast Virtual Private Network): VPN that supports transport 236 of IP multicast traffic from one site to another. 238 PMSI (P-Multicast Service Interface): A PMSI is a conceptual 239 "overlay" on the P network with the following property: a PE in a 240 given MVPN can give a packet to the PMSI, and the packet will be 241 delivered to some or all of the other PEs in the MVPN, such that any 242 PE receiving such a packet will be able to tell which MVPN the 243 packet belongs to. 245 MI-PMSI (Multidirectional Inclusive PMSI): PMSI which enables ANY PE 246 attaching to a particular MVPN to transmit a message such that it 247 will be received by EVERY other PE attaching to that MVPN. 249 S-PMSI (Selective PMSI): PMSI which enables PE attaching to a MVPN to 250 transmit a message such that it will be received by subset of other 251 PEs attaching to that same MVPN. 253 Default MDT (Default Multicast Distribution Tree): Multicast 254 distribution tree through the SP core that connects ALL PEs which 255 belong to given MVPN. This is [ROSEN-8] terminology for transport 256 service of MI-PMSIs. In this document we will use this term 257 interchangeably with MI-PMSI. 259 Data MDT (Data Multicast Distribution Tree): Multicast distribution 260 tree through the SP core that delivers VPN data traffic for a 261 particular multicast group only to those PE routers which are on the 262 path to receivers of that group. This is [ROSEN-8] terminology for 263 transport service of S-PMSIs. In this document we will use this term 264 interchangeably with S-PMSI. 266 ASM (Any Source Multicast): Multicast service model in which a 267 receiver subscribes to a multicast group to receive traffic sent to 268 the group by any source. 270 SSM (Source Specific Multicast): Multicast service model in which a 271 receiver subscribes to a multicast group to receive traffic sent to 272 the group by the specific source. 274 Mroute: Multicast route. Term ''state'' will used interchangeable with 275 ''mroute'' and ''multicast route''. 277 ''ROSEN-8'' architecture: architecture described in [L3VPN-MCAST] which 278 uses PIM protocol for both PE-PE Transmission of C-Multicast Routing 279 and to create 'tunnels' that instantiate Multidirectional Inclusive 280 P-Multicast Service Interfaces (MI-PMSIs) and Selective P-Multicast 281 Service Interfaces (S-PMSIs). This is a same as architecture 282 described in [ROSEN-8]. 284 4 Key Words to Reflect Requirements 286 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 287 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 288 document are to be interpreted as described in BCP 14, RFC 2119 289 [Br97]. RFC 2119 defines the use of these key words to help make the 290 intent of standards track documents as clear as possible. While this 291 document uses these keywords, this document is not a standards track 293 5 MVPN Metric Definition 295 MVPN control plane scalability of PE device can not be described as a 296 single parameter but it requires a set of variables. We call such a 297 set ''MVPN Metric'' and define it further in this section. 299 When providing scalability capabilities of a PE device one MUST 300 provide values for all of the MVPN metric variables that were used 301 during the test. For example, one should never claim that a PE device 302 supports X number of MVPNs without disclosing the values of other 303 MVPN Metric variables. 305 The MVPN Metric is defined as a tuple of the following 14 variables: 307 Variables Applicable to all MVPN architectures 309 1. Num_mVPN: Number of multicast VPN routing instances configured on 310 DUT that have MI-PMSI (default MDT) active and forwarding. 311 2. Num_MC_C_ints: Number of PIM C-interfaces on DUT 312 3. Num_PIM_C_neigh: Total number of PIM neighbors in PIM C-instances 313 across all mVPNs on DUT not including any PIM neighborships 314 established over MI-PMSIs. 315 4. Num_*G_C: Total number of (*,G) multicast routes across all MVPNs 316 on DUT capable of forwarding and created by PIM C-instances. 317 5. Num_SG_C: Total number of (S,G) multicast routes across all MVPNs 318 on DUT capable of forwarding and created by PIM C-instances. 319 6. Num_OIF_C: Total number of OIFs on DUT across all multicast routes 320 created by PIM C-instances. 321 7. Num_SPMSI_Src: Total number of data MDTs (S-PMSIs) across all mVPNs 322 on DUT that are sourced by DUT. 323 8. Num_SPMSI_Rx: Total number of data MDTs (S-PMSIs)across all mVPNs 324 on DUT for which DUT is a receiver. 325 9. Num_SPMSI_SrcFlows: Total number of C-instance (S,G) flows across 326 all mVPNs on DUT that are mapped to Num_SPMSI_Src. 327 10. Num_SPMSI_RxFlows: Total number of C-instance (S,G) flows 328 across all mVPNs on DUT that are mapped to Num_SPMSI_Rx. 330 Additional variables applicable to ''ROSEN-8'' architecture: 332 1. Num_PIM_MI_PMSI_neigh: Total number of PIM neighbors in PIM C- 333 instances across all mVPNs on DUT established over MI-PMSIs. 334 2. Num_*G_P: Total number of (*,G) multicast routes on DUT capable of 335 forwarding and created by PIM P-instance on DUT. 336 3. Num_SG_P: Total number of (S,G) multicast routes on DUT capable of 337 forwarding and created by PIM P-instance. 338 4. Num_OIF_P: Total number of OIFs (outgoing interfaces) on DUT 339 across all multicast routes created by PIM P-instance. 341 6 Test Environment 343 Note that all considerations in this sections except for ones related 344 to PIM P-instances for default (MI-PMSI) and data MDTs (SI-PMSI) are 345 applicable to all MVPN architectures defined in [L3VPN-MCAST]. 347 All protocols involved MUST be deployed with default timers as 348 specified by their corresponding RFC / standards. 350 6.1 Test Topologies 352 ___________ _________ ________ ________ ___________ 353 / \ / \ / \ / \ / \ 354 | Test |A1 | (DUT) |D2 | RR |B2 | |B4 | Test | 355 | Apparatus |====| PE1 |====| P |====| PE2 |====| Apparatus | 356 | | D1| | B1| | B3| | A2| | 357 \___________/ \_________/ \________/ \________/ \___________/ 358 || 359 || _____________ 360 || / \ 361 || A3| Test | 362 ++======================| Apparatus | 363 | (Emulating | 364 |_PE routers)_| 365 \_____________/ 367 Figure 1. Test Topology 1 369 Legend: 371 D1 (DUT's C-facing interface): DUT's interface that connects to 372 customer premise router (C-router). 374 D2 (DUT's P-facing interface): DUT's interface that connects to SP's 375 core router (P-router). 377 RR/P (Route Reflector/P-router): single router that will be 378 performing roles of both P-router and route reflector 380 PE2: Will also be referred to as Remote PE and is the router 381 performing PE functionality to assist with evaluation of DUT PE 382 router. 384 6.2 Unicast Control Plane Setup 386 All P facing interfaces MUST use OSPF as IGP. This requirement is 387 made to provide a standard way to compare end to end convergence 388 times which depend on the underlying unicast protocol. Only a minimum 389 number of IGP routes required to establish connectivity should be 390 seen on the DUT. 392 All PE routers in the topology including the DUT and emulated PE's 393 MUST have one iBGP peer to the Route Reflector. DUT SHOULD NOT have 394 any additional iBGP peering. Only the minimum number of VPNv4 iBGP 395 routes required to establish site to site VPN connectivity should be 396 imported on the DUT. There SHOULD NOT be any internet/ipv4 routes 397 seen on the DUT. 399 A DUT MUST use static unicast routing on all C facing VPN interfaces. 400 Only the minimum number of static routes required to establish end to 401 end connectivity should be seen on the DUT. No dynamic unicast 402 routing protocol is used in order to minimize processing overhead. 404 6.3 Multicast Control Plane Setup 406 In any given test, all MI-PMSI (default MDT) groups MUST use the same 407 multicast routing protocol variant. Different tests may require 408 different protocol variants for MI-PMSI (default MDT) groups, so 409 refer to individual test cases for the appropriate multicast 410 configuration. In any test case where ASM (Any Source Multicast) mode 411 of PIM-SM (Protocol Independent Multicast - Sparse mode) is the 412 multicast routing protocol used for MI-PMSI (default MDT), a DUT 413 SHOULD NOT be the RP (Rendezvous Point). Also dynamic RP discovery 414 protocols SHOULD NOT be used for default MDT groups. 416 For S-PMSI (data MDT) groups PIM-SSM (Source Specific Multicast) 417 routing protocol MUST be used. 419 Sources emulated by test apparatus ports that are physically directly 420 connected to DUT (port A1 in Figures 1 and 2) not have IP address 421 from DUT's connected subnets, i.e. the DUT MUST not be the first hop 422 router. 424 For consistency, it is recommended for test apparatus ports that are 425 physically directly connected to DUT (port A1 in Figures 1 and 2) not 426 to use IGMP protocol to emulate multicast receivers. Instead PIM 427 protocol must be used, i.e. the DUT should not be the last hop 428 router. 430 As an exception to previous paragraph it may exist specific network 431 design requirement to deploy IGMP receivers connected directly to the 432 DUT in which case test results MUST specify number of C-interfaces 433 with IGMP receivers. Regardless the IGMP protocol variant to be 434 deployed (IGMPV2 / V3); receivers MUST be emulated by the test 435 apparatus and NOT defined on the DUT in the form of static group 436 reports. Test apparatus MUST be capable to emulate an IGMP Host or 437 Querier and set a maximum Timer Interval between messages of 1/10th 438 of a second. 440 6.4 Data Traffic Characteristics 442 For every C-instance multicast route there MUST be traffic flow 443 associated with it and forwarded by DUT. 445 All C-instance flows SHOULD be transmitted with the same traffic rate 446 and packet size. 448 As the focus of this document is on the control plane scalability and 449 not on forwarding performance the data rate and packet size of 450 traffic flows can be chosen by user but it MUST be reported in the 451 test results. However it is suggested to use 10% of ''idle system'' 452 throughput [RFC1242] so that it can be easily detected if hardware 453 forwarding platforms start forwarding in software and at the same 454 time in case of software forwarding platforms there will be enough 455 processor headroom left for control plane scaling. By ''idle system'' 456 we refer to system with all of MVPN metric variables minimized and 457 single VPN traffic flow in each direction. 459 As an additional requirement, the reader of this document may also be 460 interested in analyzing the ''impact'' that high traffic rate may have 461 on the control plane. This would be of interest mostly for software 462 forwarding platforms. For this specific requirement additional test 463 cases SHOULD be performed increasing the rate of multicast traffic to 464 20%, 50% and 90% of ''idle system'' throughput [RFC1242]. 466 6.5 Test Apparatus Considerations 468 Different test tools must generate PIM protocol control messages in a 469 consistent way since they are directly connected to the DUT. 471 The following MUST be implemented on all PIM sessions on the test 472 apparatus: 474 1) PIM Join/Prune aggregation MUST be utilized and set such that 80 475 PIM J/P messages are aggregated in each PDU 477 2) PIM Join/Prune aggregated PDUs MUST be sent at 10 PDUs/sec rate 478 per PIM session, i.e. this translates to maximum of 479 80*10*60=48,000 state per minute. 481 3) PIM Register messages MUST be sent at 100 PDUs/sec rate. 483 4) In order to closer mimic realistic deployments test apparatus 484 SHOULD send all control plane messages in 10 equal size batches 485 with at least 5 seconds between each batch. 487 6.6 Considerations for distributed architecture platforms 489 To fairly evaluate platforms with distributed architectures one MUST 490 utilize at least two C-facing line cards in the system. 491 Configuration MUST be such that total number of mVPNs is distributed 492 evenly across multiple line cards. 494 7 Test Categories, Stimulus and Execution Methodology 496 Note that everything in this section except for verification of PIM 497 neighborships over MI-PMSI is applicable to all MVPN architectures 498 defined in [L3VPN-MCAST]. 500 Each test case specified in section 9 MUST be executed for steady 501 state and for each of six mandatory failure stimulus listed below. 502 Optionally one can use methodology defined in this document for 503 additional stimulus. 505 Mandatory failure stimulus: 507 1) DUT Power Cycle: Physical power cycle of DUT. All convergence 508 times MUST be measured from the time DUT's power is turned back 509 on. This time instance will be referred to as Tf (the time of 510 failure recovery action) for this failure stimulus. 512 2) Main Processor Card Switchover: Physical removal of the active 513 main processor card in the redundant system. All convergence times 514 should be measured from the time active processor card is 515 physically disconnected from the chassis (Tf). This stimulus can 516 be omitted only for platforms that do not support redundant main 517 processor cards. 519 3) P-facing Line Card OIR (online insertion and removal): Physical 520 removal and insertion of P-facing line card. Time between removal 521 and insertion SHOULD be at least 300 seconds. All convergence 522 times should be measured from the time line card is physically 523 inserted into chassis (Tf). 525 4) C-facing Line Card OIR: Physical removal and insertion of C-facing 526 line card. Time between removal and insertion SHOULD be at least 527 300 seconds. All convergence times should be measured from the 528 time line card is physically re-inserted into chassis (Tf). 530 5) P-facing Link Flap: Physical removal and insertion of the cable 531 from P router side that is connected to P-facing interface of DUT. 532 Time between removal and insertion SHOULD be at least 300 seconds. 533 All convergence times should be measured from the time cable is 534 physically re-inserted (Tf). 536 6) C-facing Link Flap: Physical removal and insertion of the cable 537 from test apparatus side that is connected to C-facing interface 538 of DUT. Time between removal and insertion SHOULD be at least 300 539 seconds. All convergence times should be measured from the time 540 cable is physically re-inserted (Tf). 542 Since the test execution methodology is similar for all test cases we 543 will describe it here for both steady state and failure recovery 544 testing. Any deviation from this will be specified per test case in 545 section 9. 547 Multiple iterations of each test are required to determine maximum 548 value for certain set of variables. A single iteration will be 549 referred to as a ''Test Case Instance''. 551 7.1 Steady State Testing Execution Methodology 553 The following test execution procedure MUST be used for all Test Case 554 Instances during steady state testing of each test case defined in 555 section 9 of this document: 557 1) Ensure the testbed is setup according to Test Setup instructions 558 of individual test case 560 2) All Tunnel interfaces MUST be operational and MI-PMSIs (default 561 MDTs) required by the test case MUST be built as expected. 562 Verification can be done by DUT internal tools. 564 3) All real and emulated PE devices required by test cases MUST 565 have all C-instance PIM neighborships (including over MI-PMSIs) 566 operational in both directions. Verification MUST be done by 567 both external test apparatus and DUT internal tools. 569 4) All destination test apparatus ports configured to receive 570 multicast traffic should join all configured multicast groups. 572 5) All source test apparatus ports configured to transmit multicast 573 traffic should start transmitting to all multicast groups. 575 6) All multicast traffic MUST be received at all expected 576 destination test ports without any packet drops. This MUST be 577 verified using external test apparatus. If this state can not be 578 reached within 10 minutes of execution of step 5, continue to 579 next test case instance with reduced value of scaled variable/s 580 . 582 7) After state in previous step is reached wait 10 minutes and 583 start collecting data for this test instance required by 584 individual test case. This time instance is considered steady 585 state. 587 8) If any one of following conditions are reached continue to next 588 test case instance with reduced value of scaled variable/s: 590 o 100% utilization of system resources (memory, processor, 591 etc.) 593 o Failing of any of test case specific criteria or criteria in 594 steps 1-6 above 596 The number of Test Case Instances per test case is left to 597 tester's discretion. However, it is DESIRABLE to have results for 598 at least 5 test case instances. Having a range of values will help 599 in variable's characterization. The characterization of a variable 600 cannot be achieved with only one test case instance result. 602 7.2 Failure Recovery Testing Execution Methodology 604 The following test execution procedure MUST be used for all Test Case 605 Instances during failure recovery testing of each test case defined 606 in section 9 of this document: 608 1) Execute steps 1-6 from section 7.1 610 2) After steady state in previous step is reached wait 10 minutes 611 to initiate one of mandatory failure stimulus listed in section 612 7. Note the time of failure recovery action (Tf) as displayed by 613 the external test apparatus that is measuring the received 614 multicast traffic. 616 3) Using the external test apparatus note the time when THE FIRST 617 multicast packet has been received on at least ONE of expected 618 ports. Refer to this time instance as Tre for the first such 619 encapsulated packet and Trd for the first such decapsulated 620 packet. 622 4) Using the external test apparatus note the time when ALL 623 multicast traffic has been received on ALL expected ports, i.e. 625 it has returned to the same initial rate (in pps). Refer to this 626 time instance Trall. 628 5) After state in previous step is reached execute steps 2-3 from 629 7.1. 631 6) If all data verified in step 5 is the same as before failure 632 wait 10 minutes and start collecting data for this test instance 633 required by each individual test case 635 7) If any one of following conditions are reached continue to next 636 test case instance with reduced value of scaled variable/s: 638 a. Value of MVPN metric in steady state reached after failure 639 stimuli (step 6 above) is not the same as in original 640 steady state. 642 b. Multicast latency [RFC2432] averaged over all C-instance 643 multicast flows in steady state after failure recovery 644 stimuli is more than 10% larger than in original steady 645 state 647 c. Failing of any of test case specific criteria or criteria 648 in steps 1-6 above 650 The number of Test Case Instances per test case is left to 651 tester's discretion. However, it is DESIRABLE to have results for 652 at least 5 test case instances. Having a range of values will help 653 in variable's characterization. The characterization of a variable 654 cannot be achieved with only one test case instance result. 656 8 Results Content and Reporting Format 658 Note that everything in this section except for ''MI-PMSI PIM 659 neighborhsip convergence time'' is applicable to all MVPN 660 architectures defined in [L3VPN-MCAST]. 662 8.1 Steady State Testing 664 For steady state portion of testing for each test case the following 665 results MUST be included in the test case report: 667 1. Maximum value achieved for variables requested to be varied in 668 individual test case 670 2. Values of MVPN Metric variables in the test instance in which item 671 1 of this report was achieved. The MVPN Metric as defined in 672 section 5 of this document MUST be used 673 3. Forwarding rate(in pps)[RFC2285] and packet sizes (in bytes) of all 674 flows in encapsulation direction at DUT 675 4. Forwarding rate(in pps)[RFC2285] and packet sizes (in bytes) of all 676 flows in decapsulation direction at DUT 677 5. Multicast Latency [RFC2432]averaged over all C-instance multicast 678 flows in encapsulation direction 679 6. Multicast Latency [RFC2432]averaged over all C-instance multicast 680 flows in decapsulation direction 681 7. Utilization of all processors in the system including the main 682 processor and line card processors where applicable. A description 683 of the way processor utilization is measured SHOULD be included in 684 the report. 685 8. Utilization of all relevant DUT memory components including the 686 main route processor memory and line cards where applicable. 687 9. Utilization of any relevant hardware components where applicable 688 10. Any deviations in DUT configuration from the configuration 689 defined in this document. 690 11. Any deviations in test execution procedure 692 It is DESIRABLE to include in the report items 1-9 above for all 693 optional test case instances executed, where instead of maximum value 694 achieved one would report tested value for each test case instance. 696 8.2 Failure Recovery Testing 698 In addition to data included in steady state reports defined in the 699 previous section the following MUST be included in the result report 700 of each failure recovery test case: 702 1. The worst case end to end traffic convergence time (Trall-Tf) 703 2. The best case end to end traffic convergence time ((Tre-Tf) for 704 encapsulation and (Trd-Tf) for decapsulation) 706 Note: Determination of whether all multicast flows had recovered to 707 the original traffic rate MUST be made by external test tools and 708 not by any available tools internal to the DUT or other routers in 709 the test topology. 711 It is DESIRABLE to include: 713 1. A graph from all test tool ports showing transmitted and received 714 packet rate starting from 60 seconds prior to failure action to 60 715 seconds after all multicast flows had recovered to the traffic rate 716 they had prior to the failure. 717 2. The best case MI-PMSI PIM neighborship convergence time: time 718 interval from instance Tf to instance when the first C-instance PIM 719 neighbor across one of MI-PMSIs comes up on both DUT and 720 neighboring device (i.e. ''bi-directional'' neighborships are 721 established). 722 3. The worst case MI-PMSI PIM neighborship convergence time: time 723 interval from instance Tf to instance when all expected C-instance 724 PIM neighbors across one of MI-PMSIs comes up on both DUT and 725 neighboring device (i.e. ''bi-directional'' neighborships are 726 established). 728 9 Test Cases 730 There are 16 test cases defined in this section. All test cases 731 except for 9.3, 9.4 and 9.10 can be used for any MVPN architecture 732 from [L3VPN-MCAST]. However, as noted in section 2, architectures 733 other than ''ROSEN-8'' might require additional test cases that are 734 beyond scope of this document. As [L3VPN-MCAST] specifies use of S- 735 PMSIs as optional, test cases 9.7-9.9 can be omitted for implementers 736 that don't support S-PMSIs. For such implementers test cases 9.12-17 737 SHOULD still be executed but without use of S-PMSIs and the exception 738 MUST be documented in the test report. 740 In Test Setup portion of each test case section ''P-instance Multicast 741 Configuration'' is not applicable to all MVPN architectures from 742 [L3VPN-MCAST] but only to those using PIM protocol to create 743 'tunnels' that instantiate MI-PMSI (such as ''ROSEN-8'' architecture). 744 All other portions of Test Setup are applicable to all MVPN 745 architectures. 747 Note that following relationships exist between ''Multicast Control 748 Plane Profile'' variables in ''Test Setup'' of each test case in section 749 9 and metric defined in section 5: 751 a. Number of MVPNs configured on DUT = Num_mVPN 752 b. Number of PIM VPN C-interfaces = Num_MC_C_ints/Num_mVPN 753 c. Number of remote PEs = Num_PIM_MI_PMSI_neigh/Num_mVPN 754 d. Num_*G_C = Num_mVPN *((Number of C-instance multicast groups in 755 encap direction) + (Number of C-instance multicast groups in 756 decap direction)) 757 e. Num_SG_C = Num_mVPN * ((Number of C-instance sources per group 758 in encap direction)*(Number of C-instance multicast groups in 759 encap direction) + (Number of C-instance sources per group in 760 decap direction)*( Number of C-instance multicast groups in 761 decap direction)) 762 f. Num_OIF_C = Num_mVPN*((Number of C-instance OIFs per (S,G) in 763 encap direction* Number of C-instance multicast groups in encap 764 direction *(1+ Number of C-instance sources per group in encap 765 direction)+ Number of C-instance OIFs per (S,G) in decap 766 direction* Number of C-instance multicast groups in decap 767 direction *(1+ Number of C-instance sources per group in decap 768 direction)) 769 g. Number of data MDTs (S-PMSIs) sourced from DUT = 770 Num_SPMSI_Src/Num_mVPN 771 h. Number of data MDTs (S-PMSIs) with receivers behind DUT = 772 Num_SPMSI_Rx/Num_mVPN 773 i. Number of C-instance (S,G) flows using sourced data MDTs (S- 774 PMSIs) = Num_SPMSI_SrcFlows/Num_mVPN 775 j. Number of C-instance (S,G) flows using received data MDTs (S- 776 PMSIs) = Num_SPMSI_RxFlows/Num_mVPN 778 9.1''Empty'' MVPNs Scale 780 Test Objective: 782 To determine maximum number of MVPN instances that can be 783 configured and operational on the MVPN PE router. Note that we 784 refer here to mVPNs as ''empty'' as amount of PIM neighborships, 785 interfaces, C-instances multicast routes and SI-PMSIs associated 786 with given mVPN is negligible or zero in this test case. 788 Metric Variables Relationships: 790 Num_mVPN=Num_MC_C_ints=Num_PIM_C_neigh=Num_PIM_MI_PMSI_Neigh 792 Num_*G_C=Num_SG_C=2*Num_mVPN 794 Num_OIF_C=4*Num_mVPN 796 Test Setup: 798 Following test setup MUST be performed prior to executing this test 799 case 801 1. Topology: Reference Topology #1 802 2. P-instance Multicast Configuration: 803 a. Protocol for Default MDT groups: PIM-SM (ASM) 804 b. RP location for Default MDT groups: P router 805 c. SPT (Shortest Path Tree) threshold for Default MDT 806 groups: infinity 807 3. S-PMSI (Data MDT) Configuration: 808 a. S-PMSI used: NO 809 b. Protocol instantiating S-PMSIs: NA 810 4. C-instance Multicast Configuration: 811 a. Protocol for PIM C-instances: PIM-SM (ASM) 812 b. RP Location for PIM C-instances: Test apparatus port 813 closest to the source. 814 c. SPT threshold for PIM C-instances: zero 816 5. Multicast Control Plane Profile (all per mVPN except a.; all 817 from DUT's perspective): 818 a. Number of MVPNs configured on DUT(Num_mVPN): varies 819 b. Number of PIM VPN C-interfaces: 1 820 c. Number of remote PEs: 1 821 d. Number of C-instance multicast groups in encap direction:1 822 e. Number of C-instance sources per group in encap direction:1 823 f. Number of C-instance OIFs per (S,G) in encap direction:1 824 g. Number of C-instance multicast groups in decap direction:1 825 h. Number of C-instance sources per group in decap direction:1 826 i. Number of C-instance OIFs per (S,G) in decap direction:1 827 j. Maximum allowed number of sourced data MDTs (S-PMSIs) 828 configured on DUT: 0 829 k. Number of data MDTs (S-PMSIs) sourced from DUT:0 830 l. Number of data MDTs (S-PMSIs) with receivers behind DUT:0 831 m. Number of C-instance (S,G) flows using sourced data MDTs 832 (S-PMSIs):0 833 n. Number of C-instance (S,G) flows using received data MDTs 834 (S-PMSIs):0 836 Test Execution Procedure: 838 Execute number of test case instances where in each test case 839 instance number of configured mVPNs is varied with the goal of 840 finding maximum number of mVPNs that can be configured and 841 operational on DUT. Configured mVPN will be considered operational 842 if it satisfies all of following: 844 o Tunnel interface associated with this mVPN is operational 846 o Default MDT (MI-PMSI) associated with this mVPN is built 847 correctly according to core transport protocol rules (PIM for 848 ''ROSEN-8'' architecture) 850 o On both DUT and Remote PE there is at least one PIM neighbor on 851 MI-PMSI. This condition is specific to MVPN architectures from 852 [L3VPN-MCAST] that use PIM as PE-PE signaling protocol, such as 853 ''ROSEN-8''. 855 o There is at least one PIM neighbor on respective DUT's L3VPN C- 856 interface. 858 o All traffic flows are being received on ALL expected ports 859 without any drops. 861 For each test case instance perform steps 1-8 from section 7.1. and 862 1-7 from section 7.2 for all mandatory stimuli in section 7. 864 Test Result Report: 866 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 867 at least maximum value of number of mVPNs achieved. It is DESIRABLE 868 to include the same data for at least 5 different values of number 869 of mVPNs (i.e. for at least 5 test case instances). 871 9.2 PIM Enabled VPN C-Interfaces Scale 873 Test Objective: 875 To determine maximum number of PIM enabled VPN C-interfaces that 876 can be operational on the MVPN PE router for couple of fixed values 877 of number of mVPNs. Amount of all other MVPN Metric such as PIM 878 neighborships and C-instances multicast routes is minimized in this 879 test case. 881 Metric Variables Relationships: 883 Num_MC_C_ints=Num_PIM_C_neigh >= Num_mVPN 884 Num_PIM_MI_PMSI_Neigh=Num_mVPN 886 Num_*G_P=Num_mVPN 888 Num_*G_C=Num_SG_C=Num_OIF_C=0 890 Test Setup: 892 Following test setup MUST be performed prior to executing this test 893 case 895 1. Topology: Reference Topology #1 896 2. P-instance Multicast Configuration: 897 a. Protocol for Default MDT groups: PIM-SM (ASM) 898 b. RP location for Default MDT groups: P router 899 c. SPT threshold for Default MDT groups: infinity 900 3. S-PMSI (Data MDT) Configuration: 901 a. S-PMSIs used: NO 902 b. Protocol instantiating S-PMSIs : NA 904 4. C- instance Multicast Configuration: 905 a.Protocol for PIM C-instances: PIM-SM (ASM) 906 b.RP Location for PIM C-instances: Test apparatus port closest 907 to the source. 908 c.SPT (Shortest Path Tree)threshold for PIM C-instances: zero 909 5. Multicast Control Plane Profile (all per mVPN except a.; all 910 from DUT's perspective): 911 a. Number of MVPNs configured on DUT (Num_mVPN): varies 912 b. Number of PIM VPN C-interfaces: varies 913 c. Number of remote PEs: 1 914 d. Number of C-instance multicast groups in encap 915 direction:0 916 e. Number of C-instance sources per group in encap 917 direction:0 918 f. Number of C-instance OIFs per (S,G) in encap direction:0 919 g. Number of C-instance multicast groups in decap 920 direction:0 921 h. Number of C-instance sources per group in decap 922 direction:0 923 i. Number of C-instance OIFs per (S,G) in decap direction:0 924 j. Maximum allowed number of sourced data MDTs (S-PMSIs) 925 configured on DUT: 0 927 k. Number of data MDTs(S-PMSIs) sourced from DUT:0 928 l. Number of data MDTs(S-PMSIs) with receivers behind DUT:0 929 m. Number of C-instance (S,G) flows using sourced data MDTs 930 (S-PMSIs):0 931 n. Number of C-instance (S,G) flows using received data MDTs 932 (S-PMSIs):0 934 Test Execution Procedure: 936 Following are steps to execute this test case: 938 1. Configure 100 mVPNs on DUT and PE2. Execute number of test case 939 instances where in each test case instance number of PIM enabled 940 VPN C-interfaces per mVPN is varied with the goal of finding 941 maximum number of PIM enabled VPN C-interfaces that can be 942 configured and operational on DUT. Configured VPN C-interface will 943 be considered operational if there is at least one bidirectional 944 PIM neighbor in VPN C-instance on configured C-interface. 946 2. Repeat step 1 for 100*I mVPNs where ''i=2…N'' where N is integer 947 value for which either maximum number of PIM enabled VPN C- 948 interfaces per mVPN becomes smaller than one or maximum number of 949 mVPNs found in test case 8.1 is reached. 951 Note that in this test case there SHOULD NOT be any multicast C- 952 instance traffic sources or receivers thus one MUST modify test 953 execution procedure from 7.1 and 7.2. For each test case instance 954 perform steps 1-3,7 from section 7.1. and 1-2,5-7 from section 7.2 955 for all mandatory stimuli in section 7. 957 Test Result Report: 959 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 960 at least maximum achieved value of number of PIM enabled VPN C- 961 interfaces. It is DESIRED to include the same data for at least 5 962 different values of PIM enabled VPN C-interfaces (i.e. for at least 963 5 test case instances). 965 9.3 PIM Neighborships Scale 967 Test Objective: 969 To determine maximum number of PIM C-instance neighborships across 970 MI-PMSIs that PE router can create and maintain. Amount of most of 971 other MVPN Metric such as C-instance multicast routes is minimized 972 in this test case. 974 Metric Variables Relationships: 976 Num_PIM_MI_PMSI_Neigh > Num_mVPN 978 Num_MC_C_ints = Num_PIM_C_neigh = Num_mVPN 980 Num_*G_C = Num_SG_C = 2*Num_mVPN 982 Num_OIF_C = 4*Num_mVPN 984 Num_*G_P = Num_SG_P = Num_mVPN 986 Test Setup: 988 Following test setup MUST be performed prior to executing this test 989 case 991 1. Topology: Reference Topology #1 992 2. P-instance Multicast Configuration: 993 a. Protocol for Default MDT groups: PIM-SM (ASM) 994 b. RP location for Default MDT groups: P router 995 c. SPT (Shortest Path Tree) threshold for Default MDT groups: 996 infinity 997 3. S-PMSI (Data MDT) Configuration: 998 a.S-PMSI used: NO 999 b.Protocol instantiating S-PMSIs: NA 1000 4. C- instance Multicast Configuration: 1001 a.Protocol for PIM C-instances: PIM-SM (ASM) 1002 b.RP Location for PIM C-instances: Test apparatus port closest 1003 to the source. 1004 c.SPT threshold for PIM C-instances: zero 1006 5. Multicast Control Plane Profile (all per mVPN except a.; all 1007 from DUT's perspective): 1008 a. Number of MVPNs configured on DUT (Num_mVPN): varies 1009 b. Number of PIM VPN C-interfaces: 1 1010 c. Number of remote PEs: varies 1011 d. Number of C-instance multicast groups in encap direction:1 1012 e. Number of C-instance sources per group in encap direction:1 1013 f. Number of C-instance OIFs per (S,G) in encap direction:1 1014 g. Number of C-instance multicast groups in decap direction:1 1015 h. Number of C-instance sources per group in decap direction:1 1016 i. Number of C-instance OIFs per (S,G) in decap direction:1 1017 j. Maximum allowed number of sourced data MDTs (S-PMSIs) 1018 configured on DUT: 0 1019 k. Number of data MDTs (S-PMSIs) sourced from DUT:0 1020 l. Number of data MDTs (S-PMSIs) with receivers behind DUT:0 1021 m. Number of C-instance (S,G) flows using sourced data MDTs 1022 (S-PMSIs):0 1023 n. Number of C-instance (S,G) flows using received data MDTs 1024 (S-PMSIs):0 1026 Test Execution Procedure: 1028 Number of C-instance PIM neigborships across MI-PMSIs is 1029 proportional to product of number of mVPNs DUT belongs to and 1030 average number of PEs belonging to the same mVPNs. Depending on 1031 implementation, it is possible that total number of PIM 1032 nieghborships across MI-PMSIs that platform can scale to depends on 1033 distribution of number of PE routers over mVPNs. For example, it is 1034 possible that 100 mVPNs with average of 100 PEs per mVPN (which 1035 results in 10,000 PIM neighbors) doesn't consume same DUT resources 1036 as 50 mVPNs with average of 200 PEs per mVPN (which also results in 1037 10,000 PIM neighbors). In order to identify whether this is the 1038 case for given implementation, in this test case we will vary both 1039 number of mVPNs per DUT (Num_mVPN) as well as average number of PE 1040 routers per mVPN. 1042 Test will consist of finding maximum number of C-instance PIM 1043 neighborships across MDTs by varying average number of PEs per mVPN 1044 for set of fixed values of number of mVPNs. Procedure is as 1045 follows: 1047 1. Configure 100 mVPNs on DUT. Execute number of test case 1048 instances where in each test case instance number of PE routers 1049 belonging to each mVPN is varied until maximum number of such 1050 PE's is found. All mVPNs should have same number of PE routers. 1052 2. Repeat step 1 for 100*I mVPNs where ''i=2…N'' where N is integer 1053 value for which either maximum number of PEs per mVPN becomes 1054 smaller than one or maximum number of mVPNs found in test case 9.1 1055 is reached. 1057 For each test case instance perform steps 1-8 from section 7.1. and 1058 1-7 from section 7.2 for all mandatory stimuli in section 7. 1060 Test Result Report: 1062 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1063 at least maximum value of average number of PE's for every tested 1064 value of number of mVPNs per PE (Num_mVPN). It is DESIRED to 1065 include the same data for at least 5 different values of number of 1066 PEs for each of tested values of number of mVPNs per PE(i.e. for at 1067 least 5 test case instances per each tested value of number of 1068 mVPNs). 1070 9.4 Default MDT's (MI-PMSI's) PIM P-Instance Mroutes Scale 1072 Test Objective: 1074 To determine maximum number of mVPNs and PE routers per mVPN when 1075 PIM P-instance is using protocol variant that generates maximum 1076 amount of PIM P-instance mroutes. Amount of most of other MVPN 1077 Metric such C-instance multicast mroutes is minimized in this test 1078 case. 1080 Metric Variables Relationships: 1082 Num_SG_P >= 2*Num_mVPN 1084 Num_*G_P = Num_mVPN 1086 Num_PIM_MI_PMSI_Neigh > Num_mVPN 1088 Num_MC_C_ints = Num_PIM_C_neigh = Num_mVPN 1090 Num_*G_C = Num_SG_C = 2*Num_mVPN 1092 Num_OIF_C = 4*Num_mVPN 1094 Test Setup: 1096 Following test setup MUST be performed prior to executing this test 1097 case 1099 1. Topology: Reference Topology #1 1100 2. P-instance Multicast Configuration: 1101 a. Protocol for Default MDT groups: PIM-SSM 1102 b. RP location for Default MDT groups: NA 1103 c. SPT (Shortest Path Tree) threshold for Default MDT groups: 1104 NA 1105 3. S-PMSI (Data MDT) Configuration: 1106 a.S-PMSI used: NO 1107 b.Protocol instantiating S-PMSIs: NA 1109 4. C- instance Multicast Configuration: 1110 a.Protocol for PIM C-instances: PIM-SM (ASM) 1111 b.RP Location for PIM C-instances: Test apparatus port closest 1112 to the source. 1113 d. SPT (Shortest Path Tree)threshold for PIM C-instances: zero 1114 5.Multicast Control Plane Profile (all per mVPN except a.; all from 1115 DUT's perspective): 1116 a. Number of MVPNs (Num_mVPN) configured on DUT: varies 1117 b. Number of PIM VPN C-interfaces: 1 1118 c. Number of remote PEs: varies 1119 d. Number of C-instance multicast groups in encap direction:1 1120 e. Number of C-instance sources per group in encap direction:1 1121 f. Number of C-instance OIFs per (S,G) in encap direction:1 1122 g. Number of C-instance multicast groups in decap direction:1 1123 h. Number of C-instance sources per group in decap direction:1 1124 i. Number of C-instance OIFs per (S,G) in decap direction:1 1125 j. Maximum allowed number of sourced data MDTs (S-PMSIs) 1126 configured on DUT: 0 1127 k. Number of data MDTs(S-PMSIs) sourced from DUT:0 1128 l. Number of data MDTs (S-PMSIs) with receivers behind DUT:0 1129 m. Number of C-instance (S,G) flows using sourced data MDTs 1130 (S-PMSIs):0 1131 n. Number of C-instance (S,G) flows using received data MDTs 1132 (S-PMSIs):0 1134 Test Execution Procedure: 1136 Amount of PIM P-instance mroutes on PE router created by default 1137 MDTs (MI-PMSIs) depends in general on choice of PIM protocol 1138 variant, number of mVPNs and average number of PE routers per mVPN. 1139 In order to assess the impact of PIM P-instance mroutes created by 1140 MVPN default MDTs (MI-PMSIs) has on resources. Test case 9.4 will 1141 be repeated with changing PIM P-instance protocol mode to SSM. Note 1142 that test cases 9.1-9.3 use PIM-SM (ASM) with SPT threshold of 1143 infinity in order to minimize impact PIM P-instance mroutes has on 1144 resources while focusing on characterizing other variables 1145 described in test cases 9.1-9.3 1147 Test Result Report: 1149 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1150 at least maximum value of average number of PEs for every tested 1151 value of number of mVPNs per PE. It is DESIRED to include the same 1152 data for at least 5 different values of number of PEs for each of 1153 tested values of number of mVPNs per PE(i.e. for at least 5 test 1154 case instances per each tested value of number of mVPNs). 1156 9.5 PIM C-instances Mroutes Scale 1158 Test Objective: 1160 To determine the maximum amount of PIM C-instance mroutes that a PE 1161 router can create, maintain and forward on. Amount of most of other 1162 MVPN Metric such as PIM neighborships and P-instance PIM mroutes is 1163 minimized in this test case. 1165 Metric Variables Relationships: 1167 (Num_*G_C + Num_SG_C)>> Num_mVPN 1169 Num_OIF_C >> Num_mVPN 1171 Num_SG_P = 2*Num_mVPN 1173 Num_*G_P = Num_mVPN 1175 Num_PIM_MI_PMSI_Neigh = Num_MC_C_ints = Num_PIM_C_neigh = Num_mVPN 1177 Test Setup: 1179 Following test setup MUST be performed prior to executing this test 1180 case 1182 1. Topology: Reference Topology #1 1183 2. P-instance Multicast Configuration: 1184 a. Protocol for Default MDT groups: PIM-SM (ASM) 1185 b. RP location for Default MDT groups: P router 1186 c. SPT (Shortest Path Tree) threshold for Default MDT groups: 1187 infinity 1189 3. S-PMSI (Data MDT) Configuration: 1190 a.S-PMSI used: NO 1191 b.Protocol instantiating S-PMSIs: NA 1193 4. C- instance Multicast Configuration: 1194 a.Protocol for PIM C-instances: PIM-SM (ASM) 1195 b.RP Location for PIM C-instances: Test apparatus port closest 1196 to the source. 1197 c.SPT (Shortest Path Tree) threshold for PIM C-instances: zero 1198 5. Multicast Control Plane Profile (all per mVPN except a.; all 1199 from DUT's perspective): 1200 a. Number of MVPNs (Num_mVPN) configured on DUT: varies 1201 b. Number of PIM VPN C-interfaces: 1 1202 c. Number of remote PEs: 1 1203 d. Number of C-instance multicast groups in encap direction: 1204 varies 1205 e. Number of C-instance sources per group in encap 1206 direction:50 1207 f. Number of C-instance OIFs per (S,G) in encap direction:1 1208 g. Number of C-instance multicast groups in decap direction: 1209 varies 1210 h. Number of C-instance sources per group in decap 1211 direction:50 1212 i. Number of C-instance OIFs per (S,G) in decap direction:1 1213 j. Maximum allowed number of sourced data MDTs (S-PMSIs) 1214 configured on DUT: 0 1215 k. Number of data MDTs (S-PMSIs) sourced from DUT:0 1216 l. Number of data MDTs(S-PMSIs) with receivers behind DUT:0 1217 m. Number of C-instance (S,G) flows using sourced data MDTs 1218 (S-PMSIs):0 1219 n. Number of C-instance (S,G) flows using received data MDTs 1220 (S-PMSIs):0 1222 Test Execution Procedure: 1224 Total number of C-instance PIM mroutes is proportional to product 1225 of number of mVPNs DUT belongs to and average number of C-instance 1226 PIM mroutes per mVPN. There are four distinct C-instance mroute 1227 types that depending on implementation might be utilizing platform 1228 resources in different way: (S,G) mroute with MDT Tunnel interface 1229 in OIL (Outgoing Interface List); (*,G) mroute with MDT Tunnel 1230 interface in OIL; (S,G) mroute with MDT Tunnel interface as IIF 1231 (Incoming Interface) and (*,G) mroute with MDT Tunnel interface as 1232 IIF. We will refer to mroute with MDT Tunnel in OIL as ''encap 1233 mroute'' and to one with MDT Tunnel as IIF as ''decap mroute''. 1234 In order to simplify testing we will assume a fixed number of S per 1235 each G and thus will not exploit impact ratio of (S,G) to (*,G) 1236 mroutes has on platform resources. However we will address couple 1237 of scenarios with respect to ratio of encapsulation to 1238 decapsulation C-instance mroutes. 1239 Note that size of OIL can have significant impact on platform 1240 resources and will be addressed in a separate test case: 9.6. 1241 In addition depending on implementation it is possible that total 1242 number of C-instance mroutes that platform can support depends on 1243 distribution of mroutes over number of mVPNs. For example, it is 1244 possible that 100 mVPNs with average of 100 C-instance mroutes per 1245 mVPN (which results in total of 10,000 C-instance PIM mroutes ) 1246 doesn't consume same DUT resources as 50 mVPNs with average of 200 1247 mroutes per mVPN (which also results in total of 10,000 C-instance 1248 PIM mroutes ). In order to identify whether this is the case for 1249 given implementation, in this test case we will vary both number of 1250 mVPNs per DUT as well as average number of PIM C-instance mroutes 1251 per mVPN. 1253 Test will consist of finding maximum number of C-instance PIM 1254 mroutes by varying average number of C-instance PIM mroutes per 1255 mVPN for set of fixed values of number of mVPNs. Procedure is as 1256 follows: 1258 1. On DUT and PE2 configure 100 mVPNs. Setup environment such that 1259 all PIM C-instance mroutes are in encap direction. Execute 1260 number of test case instances using steps 1-7 in section 7.1 1261 where in each test case instance number of C-instance PIM groups 1262 is varied until maximum number of C-instance PIM mroutes is 1263 found. 1265 2. Repeat step 1 for 100*I mVPNs where ''i=2…N'' where N is integer 1266 value for which either maximum number of C-instance PIM mroutes per 1267 mVPN becomes smaller than one or maximum number of mVPNs found in 1268 test case 9.1 is reached. 1270 3. Repeat steps 1 and 2 for two more cases of ratios of encap:decap 1271 C-instance mroutes: 100% mroutes are in decap direction; 1272 10%encap+90%decap. 1274 For each test case instance perform steps 1-8 from section 7.1. and 1275 1-7 from section 7.2 for all mandatory stimuli in section 7. 1277 Test Result Report: 1279 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1280 at least maximum value of average number of PIM C-instance mroutes 1281 for every tested value of number of mVPNs per PE. It is DESIRED to 1282 include the same data for at least 5 different values of number of 1283 PIM C-instance mroutes per mVPN for each of tested values of number 1284 of mVPNs per PE(i.e. for at least 5 test case instances per each 1285 tested value of number of mVPNs). 1287 9.6 PIM C-Instances OIF Scale 1289 Test Objective: 1291 To determine the maximum amount of PIM C-instance OIFs that a PE 1292 router can create and maintain. Amount of some of other MVPN Metric 1293 such as PIM neighborships and P-instance PIM mroutes is minimized 1294 in this test case. 1296 Metric Variables Relationships: 1298 Num_MC_C_ints = Num_PIM_C_neigh > Num_mVPN 1300 (Num_*G_C + Num_SG_C)>> Num_mVPN 1302 Num_OIF_C >> Num_mVPN 1304 Num_SG_P = 2*Num_mVPN 1306 Num_*G_P = Num_mVPN 1308 Num_PIM_MI_PMSI_Neigh = Num_mVPN 1310 Test Setup: 1312 Following test setup MUST be performed prior to executing this test 1313 case 1315 1. Topology: Reference Topology #1 1316 2.P-instance Multicast Configuration: 1317 a. Protocol for Default MDT groups: PIM-SM (ASM) 1318 b. RP location for Default MDT groups: P router 1319 c.SPT (Shortest Path Tree)threshold for Default MDT groups: 1320 infinity 1321 3. S-PMSI (Data MDT) Configuration: 1322 a.S-PMSI used: NO 1323 b.Protocol instantiating S-PMSIs: NA 1324 4. C- instance Multicast Configuration: 1325 a.Protocol for PIM C-instances: PIM-SM (ASM) 1326 b.RP Location for PIM C-instances: Test apparatus port closest 1327 to the source. 1328 a. SPT (Shortest Path Tree) threshold for PIM C-instances: 1329 zero 1330 5.Multicast Control Plane Profile (all per mVPN except a.; all from 1331 DUT's perspective): 1332 a. Number of MVPNs(Num_mVPN) configured on DUT: 100 and 1333 maximum value tested in 9.5 1334 b. Number of PIM VPN C-interfaces: maximum found in 9.2 1335 c. Number of remote PEs: 1 1336 d. Number of C-instance multicast groups in encap direction:0 1337 e. Number of C-instance sources per group in encap direction:0 1338 f. Number of C-instance OIFs per (S,G) in encap direction:0 1339 g. Number of C-instance multicast groups in decap direction: 1340 varies 1341 h. Number of C-instance sources per group in decap 1342 direction:50 1343 i. Number of C-instance OIFs per (S,G) in decap direction: 1344 varies 1345 j. Maximum allowed number of sourced data MDTs(S-PMSI) 1346 configured on DUT: 0 1347 k. Number of data MDTs(S-PMSI) sourced from DUT:0 1348 l. Number of data MDTs(S-PMSI) with receivers behind DUT:0 1349 m. Number of C-instance (S,G) flows using sourced data MDTs 1350 (S-PMSIs):0 1351 n. Number of C-instance (S,G) flows using received data MDTs 1352 (S-PMSIs):0 1354 Test Execution Procedure: 1356 Test will consist of finding the maximum number of C-instance PIM 1357 OIFs by varying the average number OIFs per PIM C-instance mroute. 1358 Maximum number will be found for couple of values of number of C- 1359 instance PIM mroutes. Test will be executed for two values of 1360 number of mVPNs: 100 and maximum value tested in 9.5.All C-instance 1361 PIM mroutes will be in decap direction. Procedure is as follows: 1363 1. For the first iteration of test number of C-instance decap 1364 groups should be set to 25% of maximum value achieved in test 1365 case instance of 9.5 where all C-instance groups were in decap 1366 direction and 100 mVPNs was used. Execute number of test case 1367 instances using steps 1-8 in section 7.1 where in each test case 1368 instance average number of C-instance OIFs per mroute is varied 1369 in increments of 2 until maximum number of OIFs is reached. 1371 2. Repeat step 1 for 50%,75% and 100% of C-instance decap groups 1372 achieved in test case 9.5. 1374 3. Repeat steps 1 and 2 for the case of maximum number of mVPNs 1375 tested in 9.5. 1377 For each test case instance perform steps 1-8 from section 7.1. and 1378 1-7 from section 7.2 for all mandatory stimuli in section 7. 1380 Test Result Report: 1382 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1383 at least maximum value of OIFs per C-instance mroute for every 1384 tested value of number of decapsulation groups per PE. It is 1385 DESIRED to include the same data for at least 5 different values of 1386 number of OIFs for each of tested values of number of decap 1387 groups(i.e. for at least 5 test case instances per each tested 1388 value of number of decap groups). 1390 9.7 Joined S-PMSI (Data MDT) Scale 1392 Test Objective: 1394 To determine the maximum number of data MDTs (S-PMSIs) that a PE 1395 can join. In order to assess maximum number of data MDTs (S-PMSI) 1396 joined, we minimize resources taken by C-instance mroutes by 1397 requiring that no data MDT (S-PMSI) reuse is utilized in this test 1398 case. Note that depending on specific deployment context data MDT 1399 reuse might or might not be preferred. 1401 Metric Variables Relationships: 1403 Num_SPMSI_Rx = Num_SPMSI_RxFlows > Num_mVPN 1405 Num_SPMSI_Src=Num_SPMSI_SrcFlows = 0 1406 Num_PIM_MI_PMSI_Neigh = Num_mVPN 1408 Num_MC_C_ints = Num_PIM_C_neigh > Num_mVPN 1410 (Num_*G_C + Num_SG_C)>> Num_mVPN 1412 Num_OIF_C >> Num_mVPN 1414 Num_SG_P > 2*Num_mVPN 1416 Num_*G_P > Num_mVPN 1418 Test Setup: 1420 Following test setup MUST be performed prior to executing this test 1421 case 1423 1. Topology: Reference Topology #1 1424 2. P-instance Multicast Configuration: 1425 a. Protocol for Default MDT groups: PIM-SM (ASM) 1426 b. RP location for Default MDT groups: P router 1427 c. SPT (Shortest Path Tree) threshold for Default MDT groups: 1428 infinity 1429 3. S-PMSI (Data MDT) Configuration: 1430 a.S-PMSI used: YES 1431 b.Protocol instantiating S-PMSIs: PIM SSM 1432 4. C- instance Multicast Configuration: 1433 a.Protocol for PIM C-instances: PIM-SM (ASM) 1434 b.RP Location for PIM C-instances: Test apparatus port closest 1435 to the source. 1436 d. SPT (Shortest Path Tree) threshold for PIM C-instances: 1437 zero 1438 5. Multicast Control Plane Profile (all per mVPN except a.; all 1439 from DUT's perspective): 1440 a. Number of MVPNs (Num_mVPN) configured on DUT: maximum 1441 number of mVPNs obtained in test case 9.5 (refer to it as 1442 Vmax) 1443 b. Number of PIM VPN C-interfaces: max found in 9.2 for Vmax 1444 mVPNs 1445 c. Number of remote PEs: 1 1446 d. Number of C-instance multicast groups in encap direction:0 1447 e. Number of C-instance sources per group in encap direction:0 1448 f. Number of C-instance OIFs per (S,G) in encap direction:0 1449 g. Number of C-instance multicast groups in decap direction: 1450 :[Smax/4] where Smax is maximum number of C-instance groups 1451 obtained in test case 9.5 for Vmax number of mVPNs and case 1452 where 100% of mroutes are in decap direction. 1453 h. Number of C-instance sources per group in decap direction:2 1454 i. Number of C-instance OIFs per (S,G) in decap direction:1 1455 j. Maximum allowed number of sourced data MDTs (S-PMSI) 1456 configured on DUT: 0 1457 k. Number of data MDTs (S-PMSI) sourced from DUT:0 1458 l. Number of data MDTs (S-PMSI)with receivers behind DUT: see 1459 test procedure 1460 m. Number of C-instance (S,G) flows using sourced data MDTs 1461 (S-PMSIs):0 1462 n. Number of C-instance (S,G) flows using received data MDTs 1463 (S-PMSIs):varies 1465 Test Execution Procedure: 1467 Test will consist of varying number of data MDTs (S-PMSIs) for 1468 flows that have receivers behind DUT (refer to those data MDTs (S- 1469 PMSI) as ''received data MDTs''). During all test case instances 1470 total number of C-instance PIM mroutes MUST remain constant and 1471 will be [Smax/4] rounded to the first lower integer. We will vary 1472 total number of received data MDTs (S-PMSIs) by varying number of 1473 mVPNs configured to use data MDTs (S-PMSIs) at the remote PE that 1474 has sources behind it, while number of data MDTs (S-PMSIs) per 1475 mVPNs will be same for all mVPNs that use them. If given mVPN is 1476 using data MDTs (S-PMSIs) in particular test case instance number 1477 of them should be Dvpn=[Smax/(4*Vmax)] rounded to first lower value 1478 that can be represented as 2^I where I is an integer. Note that 1479 number of data MDTs (S-PMSIs) configured and sourced by DUT MUST be 1480 zero in this test case. Procedure is as follows: 1482 1. Configure one mVPN on the remote PE and all flows so that this 1483 mVPN has Dvpn data MDTs (S-PMSIs) utilized and all are sourced 1484 at the remote PE and received at DUT. Execute steps 1-7 in 1485 section 7.1 1487 2. Repeat step 1 where number of mVPNs that utilize data MDTs (in 1488 the exact same way as 1 mVPN described in step1) takes following 1489 values 25%,50%,75%,and 100% of Vmax. 1491 3. If platform limit is not reached during execution of step 2, 1492 increase number of data MDTs (S-PMSIs) per mVPN and repeat steps 1493 1 and 2. 1495 For each test case instance perform steps 1-8 from section 7.1. and 1496 1-7 from section 7.2 for all mandatory stimuli in section 7. 1498 Test Result Report: 1500 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1501 all test case instances executed. 1503 9.8 Sourced S-PMSI (Data MDT) Scale 1505 Test Objective: 1507 To determine maximum number of data MDTs (S-PMSIs) that PE can 1508 source. In order to assess maximum number of data MDTs (S-PMSIs) 1509 sourced, we minimize resources taken by C-instance mroutes by 1510 requiring that no data MDT (S-PMSIs) reuse is utilized in this test 1511 case. Note that depending on specific deployment context data MDT 1512 reuse might or might not be preferred. 1514 Metric Variables Relationships: 1516 Num_SPMSI_Src = Num_SPMSI_SrcFlows > Num_mVPN 1518 Num_SPMSI_Rx = Num_SPMSI_RxFlows = 0 1520 Num_PIM_MI_PMSI_Neigh = Num_mVPN 1522 Num_MC_C_ints = Num_PIM_C_neigh = Num_mVPN 1524 (Num_*G_C + Num_SG_C)>> Num_mVPN 1526 Num_OIF_C >> Num_mVPN 1528 Num_SG_P > 2*Num_mVPN 1530 Num_*G_P > Num_mVPN 1532 Test Setup: 1534 Following test setup MUST be performed prior to executing this test 1535 case 1536 1. Topology: Reference Topology #1 1537 2. P-instance Multicast Configuration: 1538 a. Protocol for Default MDT groups: PIM-SM (ASM) 1539 b. RP location for Default MDT groups: P router 1540 c. SPT (Shortest Path Tree)threshold for Default MDT groups: 1541 infinity 1542 3. S-PMSI (Data MDT) Configuration: 1543 a.S-PMSI used: YES 1544 b.Protocol instantiating S-PMSIs: PIM SSM 1545 4. C- instance Multicast Configuration: 1546 a. Protocol for PIM C-instances: PIM-SM (ASM) 1547 b. RP Location for PIM C-instances: Test apparatus port 1548 closest to the source. 1549 c. SPT ((Shortest Path Tree) threshold for PIM C-instances: 1550 zero 1551 5. Multicast Control Plane Profile (all per mVPN except a.; all 1552 from DUT's perspective): 1553 a. Number of MVPNs configured on DUT (Num_mVPN): maximum 1554 number of mVPNs obtained in test case 9.5 (refer to it as 1555 Vmax) 1556 b. Number of PIM VPN C-interfaces: max found in 9.2 for Vmax 1557 mVPNs 1558 c. Number of remote PEs: 1 1559 d. Number of C-instance multicast groups in encap direction: 1560 [Smax/4] where Smax is maximum number of C-instance groups 1561 obtained in test case 9.5 for Vmax number of mVPNs and case 1562 where 100% of mroutes are in encap direction. 1563 e. Number of C-instance sources per group in encap direction:2 1564 f. Number of C-instance OIFs per (S,G) in encap direction:1 1565 g. Number of C-instance multicast groups in decap direction:0 1566 h. Number of C-instance sources per group in decap direction:0 1567 i. Number of C-instance OIFs per (S,G) in decap direction:0 1568 j. Maximum allowed number of sourced data MDTs (S-PMSIs) 1569 configured on DUT: see test case procedure 1570 k. Number of data MDTs (S-PMSIs) sourced from DUT: see test 1571 case procedure 1572 l. Number of data MDTs (S-PMSIs) with receivers behind DUT: 0 1573 m. Number of C-instance (S,G) flows using sourced data MDTs 1574 (S-PMSI):varies 1575 n. Number of C-instance (S,G) flows using received data MDTs 1576 (S-PMSI):0 1578 Test Execution Procedure: 1580 Reverse role of DUT and remote PE from test case 9.7, where now DUT 1581 is sourcing all data MDTs (S-PMSIs) while remote PE is on the 1582 receiving end of them. Repeat test case 9.7 for this reversed role 1583 scenario. 1585 9.9 Data MDT (S-PMSI) Reuse 1587 Test Objective: 1589 To determine maximum number of C-instance flows that can utilize 1590 data MDTs (S-PMSIs) and assess impact data MDT reuse has. Note that 1591 depending on specific deployment context data MDT reuse might or 1592 might not be preferred. 1594 Metric Variables Relationships: 1596 Num_SPMSI_RxFlows >= Num_SPMSI_Rx >= Num_mVPN 1598 Num_SPMSI_SrcFlows >= Num_SPMSI_Src >= Num_mVPN 1600 Num_PIM_MI_PMSI_Neigh = Num_mVPN 1602 Num_MC_C_ints = Num_PIM_C_neigh > Num_mVPN 1604 (Num_*G_C + Num_SG_C)>> Num_mVPN 1606 Num_OIF_C >> Num_mVPN 1608 Num_SG_P > 2*Num_mVPN 1610 Num_*G_P > Num_mVPN 1612 Test Setup: 1614 Following test setup MUST be performed prior to executing this test 1615 case 1617 1. Topology: Reference Topology #1 1618 2. P-instance Multicast Configuration: 1619 a. Protocol for Default MDT groups: PIM-SM (ASM) 1620 b. RP location for Default MDT groups: P router 1621 c. SPT (Shortest Path Tree) threshold for Default MDT groups: 1622 infinity 1624 3. S-PMSI (Data MDT) Configuration: 1625 a.S-PMSI used: YES 1626 b.Protocol instantiating S-PMSIs: PIM SSM 1627 4. C- instance Multicast Configuration: 1628 a. Protocol for PIM C-instances: PIM-SM (ASM) 1629 b. RP Location for PIM C-instances: Test apparatus port 1630 closest to the source. 1631 c. SPT (Shortest Path Tree) threshold for PIM C-instances: 1632 zero 1633 5. Multicast Control Plane Profile (all per mVPN except a.; all 1634 from DUT's perspective): 1635 a. Number of MVPNs configured on DUT (Num_mVPN): maximum 1636 number of mVPNs obtained in test case 9.5 (refer to it as 1637 Vmax) 1638 b. Number of PIM VPN C-interfaces: max found in 9.2 for Vmax 1639 mVPNs 1640 c. Number of remote PEs: 1 1641 d. Number of C-instance multicast groups in encap direction: : 1642 50% of Semax where Semax is maximum number of C-instance 1643 encap groups obtained in test case 9.5 for Vmax number of 1644 mVPNs and case where 10% of mroutes are in encap 1645 direction. 1646 e. Number of C-instance sources per group in encap 1647 direction:50 1648 f. Number of C-instance OIFs per (S,G) in encap direction:1 1649 g. Number of C-instance multicast groups in decap direction: : 1650 50% of Sdmax where Sdmax is maximum number of C-instance 1651 encap groups obtained in test case 9.5 for Vmax number of 1652 mVPNs and case where 90% of mroutes are in decap 1653 direction.. 1654 h. Number of C-instance sources per group in decap 1655 direction:50 1656 i. Number of C-instance OIFs per (S,G) in decap direction:1 1657 j. Maximum allowed number of sourced data MDTs (S-PMSIs) 1658 configured on DUT: 2 1659 k. Number of data MDTs (S-PMSIs) sourced from DUT: 2 1660 l. Number of data MDTs (S-PMSIs) with receivers behind DUT: 8 1661 m. Number of C-instance (S,G) flows using sourced data MDTs 1662 (S-PMSIs):varies 1663 n. Number of C-instance (S,G) flows using received data MDTs 1664 (S-PMSIs):varies 1666 Test Execution Procedure: 1668 Test will consist of varying number of C-instance flows that will 1669 utilize data MDT (S-PMSIs), while keeping number of C-instance 1670 mroutes and data MDTs (S-PMSIs) constant. By doing this one can 1671 assess impact of data MDT reuse. 1673 Procedure is as follows: 1675 1. Configure test apparatus such that number of flows using data 1676 MDTs (S-PMSIs) is the same as number of data MDTs (S-PMSIs), 1677 i.e. there is no data MDT reuse by multiple traffic flows. 1678 Execute steps 1-7 in section 7.1 and 1-8 in section 7.2 1680 2. Repeat step 1 for 10*I flows where ''i=2…N'' where N is integer 1681 value for which either maximum number of flows mapped to data 1682 MDT (S-PMSI) is reached or number of flows becomes equal to 1683 number of (S,G) C-instance mroutes. 1685 For each test case instance perform steps 1-8 from section 7.1. and 1686 1-7 from section 7.2 for all mandatory stimuli in section 7. 1688 Test Result Report: 1690 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1691 all test case instances executed. 1693 9.10 PIM C-instances J/P Suppression Effectiveness 1695 Test Objective: 1697 MI-PMSI functions as a broadcast network and standard PIM LAN (Local 1698 Area Network) procedures, including PIM J/P Suppression, can be used. 1699 Depending on distribution of C-instance sources, RPs and receivers in 1700 MVPN network capability to perform J/P Suppression can have great 1701 impact on overall scale capabilities of PE devices. In particular 1702 largest impact is on scale capabilities of PE router whose attached 1703 customers source large number of multicast flows or host large number 1704 of RPs (refer to such PE as ''source'' PE)in the network with large 1705 number of PE routers with receivers for those flows. However function 1706 of PIM J/P Suppression is performed by all PE devices that have 1707 receivers behind them (refer to such PE as ''receiving'' PE). Goal of 1708 this test case is to assess capability of ''receiving'' PE to perform 1709 J/P suppression for large amount of C-instance multicast routes. 1711 Metric Variables Relationships: 1713 Num_PIM_MI_PMSI_Neigh = 2*Num_mVPN 1715 Num_MC_C_ints = Num_PIM_C_neigh = Num_mVPN 1717 (Num_*G_C + Num_SG_C)>> Num_mVPN 1719 Num_OIF_C >> Num_mVPN 1721 Num_SG_P = 2*Num_mVPN 1723 Num_*G_P = Num_mVPN 1725 Num_SPMSI_Rx = Num_SPMSI_Src = 0 1727 Test Setup: 1729 Following test setup MUST be performed prior to executing this test 1730 case 1732 1. Topology: 1734 ________ _________ ________ 1735 / \ / \ / \ 1736 | |R1 | (DUT) |D2 | (RR) | 1737 | Rx1 |====| PE1 |====| P | 1738 | | D1| | B1| | 1739 \________/ \_________/ \________/ 1740 || 1741 || ____________ _______ 1742 || / \ / \ 1743 || | (Emulated) |B3 | | 1744 ++===========| PE2 |====| Src | 1745 || B2| | B4| | 1746 || \____________/ \_______/ 1747 || 1748 || ____________ _______ 1749 || / \ / \ 1750 || | (Emulated) |B6 | | 1751 ++===========| PE3 |====| Rx2 | 1752 B5| | B7| | 1753 \____________/ \_______/ 1755 2. P-instance Multicast Configuration: 1756 a. Protocol for Default MDT groups: PIM-SM (ASM) 1757 b. RP location for Default MDT groups: P router 1758 c. SPT (Shortest Path Tree) threshold for Default MDT groups: 1759 infinity 1760 3. S-PMSI (Data MDT) Configuration: 1761 a.S-PMSI used: NO 1762 b.Protocol instantiating S-PMSIs: NA 1763 4. C- instance Multicast Configuration: 1764 a. Protocol for PIM C-instances: PIM-SM (ASM) 1765 b. RP Location for PIM C-instances: Test apparatus port 1766 closest to the source. 1767 c. SPT (Shortest Path Tree) threshold for PIM C-instances: 1768 zero 1769 5.Multicast Control Plane Profile (all per mVPN except a.; all from 1770 DUT's perspective): 1771 a. Number of MVPNs (Num_mVPN) configured on DUT (Num_mVPN): 1772 varies 1773 b. Number of PIM VPN C-interfaces: 1 1774 c. Number of remote PEs: 2 1775 d. Number of C-instance multicast groups in encap direction: 1776 varies 1777 e. Number of C-instance sources per group in encap 1778 direction:50 1779 f. Number of C-instance OIFs per (S,G) in encap direction:1 1780 g. Number of C-instance multicast groups in decap direction:0 1781 h. Number of C-instance sources per group in decap direction:0 1782 i. Number of C-instance OIFs per (S,G) in decap direction:0 1783 j. Maximum allowed number of sourced data MDTs (S-PMSIs) 1784 configured on DUT: 0 1785 k. Number of data MDTs (S-PMSIs) sourced from DUT:0 1786 l. Number of data MDTs(S-PMSIs) with receivers behind DUT:0 1787 m. Number of C-instance (S,G) flows using sourced data MDTs 1788 (S-PMSIs):0 1789 n. Number of C-instance (S,G) flows using received data MDTs 1790 (S-PMSIs):0 1792 Test Execution Procedure: 1794 For maximum number of C-instances multicast routes obtained in test 1795 case 9.5 for 100 mVPNs and 100% mroutes in decap direction perform 1796 following: 1798 1) Establish all PIM session required to emulate defined 1799 topology 1801 2) Perform all C-instance PIM joins from ''Rx2'' (test 1802 apparatus port B5 in topology diagram) 1804 3) Start all traffic from ''Src'' (test apparatus port R1 in 1805 topology diagram) and wait until steady state is 1806 achieved. 1808 4) On C-instance PIM session (established over MI-PMSI) of 1809 test apparatus port ''Src'' (B2) measure number of J/P PDUs 1810 received in 10 minute (J1) interval and calculate rate of 1811 J/P PDUs as JR1=J1/(60*10) 1813 5) Perform all C-instance PIM joins from test apparatus port 1814 ''Rx1'' (R1) and wait until steady state is achieved on 1815 DUT. 1817 6) On C-instance PIM session (established over MI-PMSI) of 1818 test apparatus port ''Src'' (B2) measure number of J/P PDUs 1819 received in 10 minute (J2) interval and calculate rate of 1820 J/P PDUs as JR2=J2/(60*10) 1822 7) If JR2 < 1.2*JR1 we can conclude that DUT is suppressing 1823 J/P messages successfully. 1825 Repeat steps 1-7, for maximum number of C-instances multicast routes 1826 obtained in test case 9.5 for maximum number of mVPN and 100% state 1827 in decap direction. 1829 Note that no failure recovery testing is required in this test case. 1831 Test Result Report: 1833 Data listed in 8.1 MUST be reported in tabular format for all test 1834 case instances. In addition rates JR1 and JR2 MUST be reported. 1835 Optionally one can report absolute numbers or rates of number of 1836 PIM J/P PDUs transmitted by DUT and PE3 (test apparatus port B5). 1838 9.11 Additional Tests and Considerations for Devices Lacking ''Efficient'' 1839 Join/Prune Suppression 1841 If 9.10 revealed that device does not perform J/P suppression, repeat 1842 test case 9.5 where for all groups in encapsulation direction, J/P 1843 messages are sent from more than one remote PE router, i.e. number of 1844 remote PE routers with receivers becomes additional variable. One 1845 MUST execute test for at least 3 values of number of remote PE 1846 routers with receivers. It is suggested to chose values such that 1847 product of number of PE routers with receivers and number of mVPNs is 1848 50% of maximum number of PIM neighbors over MI-PMSIs achieved in test 1849 9.3. 1851 In addition, in test cases 9.12-9.17, test apparatus MUST be 1852 configured such that all remote PEs are sending J/P message for any 1853 given C-instance encapsulation group. On contrary if 9.10 revealed 1854 that DUT platform efficiently performs J/P suppression, test 1855 apparatus MUST be configured such that only one remote PE is sending 1856 J/P message for any given C-instance encapsulation group. 1858 Note that PIM Join/Prune suppression is relevant only for MVPN 1859 architectures from [L3VPN-MCAST] that utilize PIM as PE-to-PE 1860 signaling such as ''ROSEN-8'' architecture. However, even if other 1861 PE-to-PE signaling methods are to be used for exchanging C-instance 1862 PIM messages, the testing of C-instance PIM Join/Prune message rate 1863 is still relevant. For example, if BGP is used as PE-PE signaling 1864 distributing C-instance multicast routes , the rate of PIM messages 1865 and its impact on PE depends on whether Route reflector to PE mroute 1866 filtering is implemented. In addition, when BGP is used as PE-PE 1867 signaling mechanism, the impact on Route Reflectors has to be also 1868 measured but is beyond scope of this document. 1870 9.12 Scale of mVPNs spanning large number of PEs 1872 Test Objective: 1874 As we noted mVPN scale is multidimensional and depends on number of 1875 variables. While test cases 9.1-9.11 focused on only one or two 1876 variables at the time while minimizing impact of all others, they 1877 don't give good representation of platform capabilities in more 1878 realistic deployment scenarios where none of variables are 1879 minimized. Objective of this test case is to assess capabilities of 1880 platform in more realistic deployment scenario. In particular this 1881 test case will focus on finding maximum number of mVPN instances 1882 that span large number of PE routers while they have values for 1883 other MVPN variables chosen to be on the order of magnitude used by 1884 MVPN deployments at the time this draft was written. Specific 1885 values are defined in Test Setup section. 1887 Metric Variables Relationships: 1889 Num_PIM_MI_PMSI_Neigh = 500*Num_mVPN 1891 Num_MC_C_ints = Num_PIM_C_neigh = 2*Num_mVPN 1893 (Num_*G_C + Num_SG_C)= 30 * Num_mVPN 1895 Num_OIF_C = Num_mVPN = 60 * Num_mVPN 1897 Num_SPMSI_Rx = 8*Num_mVPN 1899 Num_SPMSI_Src = 2*Num_mVPN 1901 Num_SPMSI_RxFlows = 18*Num_mVPN 1903 Num_SPMSI_SrcFlows = 2*Num_mVPN 1905 Num_SG_P, Num_*G_P - depends on PIM protocol variant used for 1906 MI-PMSIs 1908 Test Setup: 1910 Following test setup MUST be performed prior to executing this test 1911 case 1913 1. Topology: Reference Topology #1 1914 2. P-instance Multicast Configuration: 1915 a. Protocol for Default MDT groups: varies 1916 b. RP location for Default MDT groups: P router 1917 c. SPT (Shortest Path Tree) threshold for Default MDT groups: 1918 infinity 1919 3. S-PMSI (Data MDT) Configuration: 1920 a.S-PMSI used: YES 1921 b.Protocol instantiating S-PMSIs: PIM SSM 1922 4. C- instance Multicast Configuration: 1923 a.Protocol for PIM C-instances: PIM-SM (ASM) 1924 b.RP Location for PIM C-instances: Test apparatus port closest 1925 to the source. 1926 c.SPT (Shortest Path Tree) threshold for PIM C-instances: zero 1927 5.Multicast Control Plane Profile (all per mVPN except a.; all from 1928 DUT's perspective): 1929 a. Number of MVPNs configured on DUT: varies 1930 b. Number of PIM VPN C-interfaces: 2 1931 c. Number of remote PEs: 500 1932 d. Number of C-instance multicast groups in encap direction: 1 1933 e. Number of C-instance sources per group in encap direction:2 1934 f. Number of C-instance OIFs per (S,G) in encap direction:2 1935 g. Number of C-instance multicast groups in decap direction:9 1936 h. Number of C-instance sources per group in decap direction:2 1937 i. Number of C-instance OIFs per (S,G) in decap direction:2 1938 j. Maximum allowed number of sourced data MDTs (S-PMSIs) 1939 configured on DUT: 2 1940 k. Number of data MDTs (S-PMSIs) sourced from DUT:2 1941 l. Number of data MDTs (S-PMSIs) with receivers behind DUT:8 1942 m. Number of C-instance (S,G) flows using sourced data MDTs 1943 (S-PMSIs):2 1944 n. Number of C-instance (S,G) flows using received data MDTs 1945 (S-PMSIs):18 1947 Test Execution Procedure: 1949 This test case SHOULD be repeated for all PIM protocol variants(PIM 1950 ASM, SSM and Bi-dir) supported by implementer for MI-PMSI (default 1951 MDT). At minimum PIM ASM MUST be tested. 1953 Refer to 9.11 for guidelines on how many PE routers should be 1954 sending J/P messages for any given C-instance mroute in encap 1955 direction. 1957 Execute number of test case instances where in each test case 1958 instance number of configured mVPNs is varied with the goal of 1959 finding maximum number of mVPNs that platform can support. mVPN 1960 instance here includes C-instance state, OIFs, PIM neighborships 1961 and data MDTs (S-PMSIs) as specified by Test Setup. 1963 For each test case instance perform steps 1-8 from section 7.1. and 1964 1-7 from section 7.2 for all mandatory stimuli in section 7. 1966 Test Result Report: 1968 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1969 at least maximum value of number of mVPNs achieved. It is DESIRED 1970 to include the same data for at least 5 different values of number 1971 of mVPNs (i.e. for at least 5 test case instances). 1973 9.13 Scale of mVPNs with larger amount of state 1975 Test Objective: 1977 As we noted mVPN scale is multidimensional and depends on number of 1978 variables. While test cases 9.1-9.11 focused on only one or two 1979 variables at the time while minimizing impact of all others, they 1980 don't give good representation of platform capabilities in more 1981 realistic deployment scenarios where none of variables are 1982 minimized. Objective of this test case just is to assess 1983 capabilities of platform in more realistic deployment scenario. In 1984 particular this test case will focus on finding maximum number of 1985 mVPN instances that contain large number of C-instance PIM state 1986 while they have values for other MVPN variables chosen to be on the 1987 order of magnitude used by MVPN deployments at the time this draft 1988 was written. Specific values are defined in Test Setup section. 1990 Metric Variables Relationships: 1992 Num_PIM_MI_PMSI_Neigh = 50*Num_mVPN 1994 Num_MC_C_ints = Num_PIM_C_neigh = 2*Num_mVPN 1996 (Num_*G_C + Num_SG_C)= 300 * Num_mVPN 1998 Num_OIF_C = Num_mVPN = 600 * Num_mVPN 2000 Num_SPMSI_Rx = 8*Num_mVPN 2002 Num_SPMSI_Src = 2*Num_mVPN 2004 Num_SPMSI_RxFlows = 225*Num_mVPN 2006 Num_SPMSI_SrcFlows = 25*Num_mVPN 2008 Num_SG_P, Num_*G_P - depends on PIM protocol variant used for 2009 MI-PMSIs 2011 Test Setup: 2013 Following test setup MUST be performed prior to executing this test 2014 case 2016 1. Topology: Reference Topology #1 2017 2. P-instance Multicast Configuration: 2018 a. Protocol for Default MDT groups: varies 2019 b. RP location for Default MDT groups: P router 2020 c. SPT (Shortest Path Tree) threshold for Default MDT groups: 2021 infinity 2022 3. S-PMSI (Data MDT) Configuration: 2023 a.S-PMSI used: YES 2024 b.Protocol instantiating S-PMSIs: PIM SSM 2025 4. C- instance Multicast Configuration: 2026 a.Protocol for PIM C-instances: PIM-SM (ASM) 2027 b.RP Location for PIM C-instances: Test apparatus port closest 2028 to the source. 2029 c.SPT (Shortest Path Tree)threshold for PIM C-instances: zero 2030 5.Multicast Control Plane Profile (all per mVPN except a.; all from 2031 DUT's perspective): 2032 a. Number of MVPNs configured on DUT (Num_mVPN) : varies 2033 b. Number of PIM VPN C-interfaces: 2 2034 c. Number of remote PEs: 50 2035 d. Number of C-instance multicast groups in encap direction:5 2036 e. Number of C-instance sources per group in encap direction:5 2037 f. Number of C-instance OIFs per (S,G) in encap direction:2 2038 g. Number of C-instance multicast groups in decap direction:45 2039 h. Number of C-instance sources per group in decap direction:5 2040 i. Number of C-instance OIFs per (S,G) in decap direction:2 2041 j. Maximum allowed number of sourced data MDTs (S- 2042 PMSIs)configured on DUT: 2 2043 k. Number of data MDTs (S-PMSIs) sourced from DUT:2 2044 l. Number of data MDTs (S-PMSIs) with receivers behind DUT:8 2045 m. Number of C-instance (S,G) flows using sourced data MDTs 2046 (S-PMSIs):25 2047 n. Number of C-instance (S,G) flows using received data MDTs 2048 (S-PMSIs):225 2050 Test Execution Procedure: 2052 This test case SHOULD be repeated for all PIM protocol variants(PIM 2053 ASM, SSM and Bi-dir) supported by implementer for MI-PMSI (default 2054 MDT). At minimum PIM ASM MUST be tested. 2056 Refer to 9.11 for guidelines on how many PE routers should be 2057 sending J/P messages for any given C-instance mroute in encap 2058 direction. 2060 Execute number of test case instances where in each test case 2061 instance number of configured mVPNs is varied with the goal of 2062 finding maximum number of mVPNs that platform can support. mVPN 2063 instance here includes C-instance state, OIFs, PIM neighborships 2064 and data MDTs (S-PMSIs) as specified by Test Setup. 2066 For each test case instance perform steps 1-8 from section 7.1. and 2067 1-7 from section 7.2 for all mandatory stimuli in section 7. 2069 Test Result Report: 2071 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 2072 at least maximum value of number of mVPNs achieved. It is DESIRED 2073 to include the same data for at least 5 different values of number 2074 of mVPNs (i.e. for at least 5 test case instances). 2076 9.14 Scale of ''average'' size mVPNs 2078 Test Objective: 2080 As we noted mVPN scale is multidimensional and depends on number of 2081 variables. While test cases 9.1-9.11 focused on only one or two 2082 variables at the time while minimizing impact of all others, they 2083 don't give good representation of platform capabilities in more 2084 realistic deployment scenarios where none of variables are 2085 minimized. While test cases 9.12 and 9.13 assess two more extreme 2086 cases with respect to number of PE routers and mVPN routes, 2087 objective of this test case is to assess number of mVPNs for the 2088 case where each mVPN represents average size mVPN customer. 2089 Specific values are defined in Test Setup section. 2091 Metric Variables Relationships: 2093 Num_PIM_MI_PMSI_Neigh = 100*Num_mVPN 2095 Num_MC_C_ints = Num_PIM_C_neigh = 2*Num_mVPN 2097 (Num_*G_C + Num_SG_C)= 100 * Num_mVPN 2099 Num_OIF_C = Num_mVPN = 200 * Num_mVPN 2101 Num_SPMSI_Rx = 8*Num_mVPN 2103 Num_SPMSI_Src = 2*Num_mVPN 2104 Num_SPMSI_RxFlows = 72*Num_mVPN 2106 Num_SPMSI_SrcFlows = 8*Num_mVPN 2108 Num_SG_P, Num_*G_P - depends on PIM protocol variant used for 2109 MI-PMSIs 2111 Test Setup: 2113 Following test setup MUST be performed prior to executing this test 2114 case 2116 1. Topology: Reference Topology #1 2117 2. P-instance Multicast Configuration: 2118 a. Protocol for Default MDT groups: varies 2119 b. RP location for Default MDT groups: P router 2120 c. SPT (Shortest Path Tree)threshold for Default MDT groups: 2121 infinity 2122 3. S-PMSI (Data MDT) Configuration: 2123 a.S-PMSI used: YES 2124 b.Protocol instantiating S-PMSIs: PIM SSM 2125 4. C- instance Multicast Configuration: 2126 a. Protocol for PIM C-instances: PIM-SM (ASM) 2127 b. RP Location for PIM C-instances: Test apparatus port 2128 closest to the source. 2129 c. SPT (Shortest Path Tree) threshold for PIM C-instances: 2130 zero 2131 5. Multicast Control Plane Profile (all per mVPN except a.; all 2132 from DUT's perspective): 2133 a. Number of MVPNs configured on DUT (Num_mVPN): varies 2134 b. Number of PIM VPN C-interfaces: 2 2135 c. Number of remote PEs: 100 2136 d. Number of C-instance multicast groups in encap direction:2 2137 e. Number of C-instance sources per group in encap direction:4 2138 f. Number of C-instance OIFs per (S,G) in encap direction:2 2139 g. Number of C-instance multicast groups in decap direction:18 2140 h. Number of C-instance sources per group in decap direction:4 2141 i. Number of C-instance OIFs per (S,G) in decap direction:2 2142 j. Maximum allowed number of sourced data MDTs (S-PMSIs) 2143 configured on DUT: 2 2144 k. Number of data MDTs (S-PMSIs) sourced from DUT:2 2145 l. Number of data MDTs (S-PMSIs) with receivers behind DUT:8 2146 m. Number of C-instance (S,G) flows using sourced data MDTs 2147 (S-PMSIs):8 2148 n. Number of C-instance (S,G) flows using received data MDTs 2149 (S-PMSIs):72 2151 Test Execution Procedure: 2153 This test case SHOULD be repeated for all PIM protocol variants(PIM 2154 ASM, SSM and Bi-dir) supported by implementer for MI-PMSI (default 2155 MDT). At minimum PIM ASM MUST be tested. 2157 Execute number of test case instances where in each test case 2158 instance number of configured mVPNs is varied with the goal of 2159 finding maximum number of mVPNs that platform can support. mVPN 2160 instance here includes C-instance state, OIFs, PIM neighborships 2161 and data MDTs (S-PMSIs) as specified by Test Setup. 2163 For each test case instance perform steps 1-8 from section 7.1. and 2164 1-7 from section 7.2 for all mandatory stimuli in section 7. 2166 Refer to 9.11 for guidelines on how many PE routers should be 2167 sending J/P messages for any given C-instance mroute in encap 2168 direction. 2170 Test Result Report: 2172 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 2173 at least maximum value of number of mVPNs achieved. It is DESIRED 2174 to include the same data for at least 5 different values of number 2175 of mVPNs (i.e. for at least 5 test case instances). 2177 9.15 S-PMSI Switching Delay 2179 Test Objective: 2181 The test objective is to measure the elapsed time for traffic to 2182 start flowing on S-PMSI, i.e., the time from the moment of signaling 2183 of an S-PMSI to the moment when traffic starts flowing on the S-PMSI. 2184 We will refer to this measure as S-PMSI switching delay [S- 2185 PMSI_DELAY]. 2187 Metric Variables Relationships: 2189 Same as for test case 9.14. 2191 Test Setup: 2193 Same as for test case 9.14. 2195 Test Execution Procedure: 2197 Test will measure the time for traffic to start flowing on S-PMSI, 2198 i.e., the time from the moment of signaling of an S-PMSI to the 2199 moment when traffic starts flowing on the S-PMSI on the DUT. This 2200 test MUST be repeated multiple (at least 20) times (for each value 2201 of number of mVPNs) across multi-second intervals in order to 2202 isolate any timing issues. This test MUST be performed with 2203 varying number of average size MVPNs on DUT (up to the maximum) as 2204 defined in the test case 9.14. With a given number of MVPNs on 2205 DUT, the switching delay of several S-PMSIs sourced at the DUT in 2206 different MVPNs will be measured. In case S-PSMI creation is 2207 triggered by rate of C-instance traffic flow, the S-PMSI threshold 2208 should be set to min possible value, depending on the 2209 implementation. Such threshold value used MUST be documented in 2210 the test report. 2212 Refer to 9.11 for guidelines on how many PE routers should be 2213 sending J/P messages for any given C-instance mroute in encap 2214 direction. 2216 Test Result Report: 2218 The test results MUST include the range of S-PMSI switching 2219 delays: minimum, average and maximum [S-PMSI_DELAY]. 2220 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 2221 at least maximum value of number of mVPNs achieved. It is DESIRED 2222 to include the same data for at least 5 different values of number 2223 of mVPNs (i.e. for at least 5 test case instances). 2225 9.16 Convergence of C-Instance PIM Joins 2227 Test Objective: 2229 The test objective is to measure how long it takes for the first 2230 receiver on the DUT, issuing C-instance PIM (*,G) Join, to receive 2231 the traffic from already active C-instance source (S,G). 2233 Metric Variables Relationships: 2235 Same as for test case 9.14. 2237 Test Setup: 2239 Same as in test case 9.14 2241 Test Execution Procedure: 2243 Test will consist of an active C-instance source (S,G) attached 2244 to/behind a remote PE (PE2 in Topology #1). There will be at least 2245 one active C-instance receiver of (*,G) behind this remote PE 2246 (PE2). This setup ensures that C-instance PIM Register procedure 2247 for (S,G) has been completed and that there are no receivers 2248 across the core network. With this initial setup, the test will 2249 add one C-instance (*,G) receiver attached to DUT and issuing PIM 2250 (*,G) Join towards the DUT. The test will measure the time 2251 for traffic from (S,G) behind the remote PE to be received by 2252 (*,G) receiver behind the DUT. This test MUST be repeated multiple 2253 (at least 10) times in order to isolate any timing issues. This 2254 test MUST be performed with varying number of average size MVPNs 2255 (up to the maximum) as defined in the test case 9.14. 2257 Refer to 9.11 for guidelines on how many PE routers should be 2258 sending J/P messages for any given C-instance mroute in encap 2259 direction. 2261 Test Result Report: 2263 The test results MUST include the range of C-instance PIM (*,G) 2264 Join convergence times: minimum, average, maximum. 2265 Data listed in 8.1 and 8.2 MUST be reported in tabular format for at 2266 least maximum value of number of mVPNs achieved. It is DESIRED to 2267 include the same data for at least 5 different values of number of 2268 mVPNs (i.e. for at least 5 test case instances). 2270 9.17 Effect of Co-locating C-RPs on a PE 2272 Test Objective: 2274 The test objective is to assess scaling impact of SP hosting 2275 customer's RPs (C-RPs) on PE router. This is the optional 2276 deployment model as stated in [MVPN-REQ] and is deployed today by 2277 number of service providers. Only difference between test cases 2278 9.14 and 9.17 is location of C-RP; thus by comparing test results 2279 of 9.17 and 9.14 one will be able to determine additional impact 2280 co-locating RP has on PE scale compared to deployment model of 2281 customers hosting their own RPs. 2283 Metric Variables Relationships: 2285 Num_PIM_MI_PMSI_Neigh = 100*Num_mVPN 2287 Num_MC_C_ints = Num_PIM_C_neigh = 2*Num_mVPN 2289 (Num_*G_C + Num_SG_C)= 100 * Num_mVPN 2291 Num_OIF_C = Num_mVPN = 200 * Num_mVPN 2293 Num_SPMSI_Rx = 8*Num_mVPN 2295 Num_SPMSI_Src = 2*Num_mVPN 2297 Num_SPMSI_RxFlows = 72*Num_mVPN 2299 Num_SPMSI_SrcFlows = 8*Num_mVPN 2301 Num_SG_P, Num_*G_P -depends on PIM protocol variant used for 2302 MI-PMSIs 2304 Test Setup: 2306 Following test setup MUST be performed prior to executing this test 2307 case 2309 1.Topology: Reference Topology #1 2310 2.P-instance Multicast Configuration: 2311 a. Protocol for Default MDT groups: PIM-SM (ASM) 2312 b. RP location for Default MDT groups: P router 2313 c. SPT (Shortest Path Tree) threshold for Default MDT 2314 groups: infinity 2315 3.S-PMSI (Data MDT) Configuration: 2317 a.S-PMSI used: YES 2318 b.Protocol instantiating S-PMSIs: PIM SSM 2319 4.C-instance Multicast Configuration: 2320 a. Protocol for PIM C-instances: PIM-SM (ASM) 2321 b. RP Location for PIM C-instances: DUT 2322 c. SPT threshold for PIM C-instances: zero 2323 5.Multicast Control Plane Profile (all per mVPN except a.; all from 2324 DUT's perspective): 2325 a. Number of MVPNs configured on DUT: varies 2326 b. Number of PIM VPN C-interfaces: 2 2327 c. Number of remote PEs: 100 2328 d. Number of C-instance multicast groups in encap direction:2 2329 e. Number of C-instance sources per group in encap direction:4 2330 f. Number of C-instance OIFs per (S,G) in encap direction:2 2331 g. Number of C-instance multicast groups in decap direction:18 2332 h. Number of C-instance sources per group in decap direction:4 2333 i. Number of C-instance OIFs per (S,G) in decap direction:2 2334 j. Maximum allowed number of sourced data MDTs (S-PMSIs) 2335 configured on DUT: 2 2336 k. Number of data MDTs (S-PMSIs) sourced from DUT:2 2337 l. Number of data MDTs (S-PMSIs) with receivers behind DUT:8 2338 m. Number of C-instance (S,G) flows using sourced data MDTs 2339 (S-PMSIs):8 2340 n. Number of C-instance (S,G) flows using received data MDTs 2341 (S-PMSIs):72 2343 Test Execution Procedure: 2345 This test case SHOULD be repeated for all PIM protocol variants(PIM 2346 ASM, SSM and Bi-dir) supported by implementer for MI-PMSI (default 2347 MDT). At minimum PIM ASM MUST be tested. 2349 Refer to 9.11 for guidelines on how many PE routers should be 2350 sending J/P messages for any given C-instance mroute in encap 2351 direction. 2353 Execute number of test case instances where in each test case 2354 instance number of configured mVPNs is varied with the goal of 2355 finding maximum number of mVPNs that platform can support in this 2356 environment. mVPN instance here includes C-instance state, OIFs, 2357 PIM neighborships and data MDTs (S-PMSIs) as specified by Test 2358 Setup. 2360 For each test case instance perform following steps: 2362 a. Steps 1-4 from section 7.1. 2364 b. Send PIM Register messages from all ''source'' test apparatus 2365 ports 2367 c. Test apparatus should verify that correct (S,G) PIM Join 2368 messages had been received by ''source'' test apparatus port. 2369 In reaction to receipt of (S,G) joins, source test 2370 apparatus ports should start transmitting multicast traffic 2371 to appropriate multicast groups and start sending Data- 2372 header Registers [RFC4601]. 2374 d. Steps 6-8 from section 7.1. 2376 For all mandatory stimuli defined in section 7 perform following 2377 steps: 2379 a. Steps a-d from paragraph above 2381 b. Steps 2-7 from section 7.2 2383 Test Result Report: 2385 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 2386 at least maximum value of number of mVPNs achieved. It is DESIRED 2387 to include the same data for at least 5 different values of number 2388 of mVPNs (i.e. for at least 5 test case instances). 2390 10 Security Considerations 2392 Documents of this type do not directly affect the security of 2393 the Internet or of corporate networks as long as benchmarking 2394 is not performed on devices or systems connected to operating 2395 networks. 2397 11 IANA Considerations 2399 This document requires no IANA considerations. 2401 12 Acknowledgments 2403 We would like to thank Aamer Akhter, Arjen Boers, Yiqun Cai, Min Li, 2404 Amal Maalouf, Mike McBride, Ciprian Popoviciu, Dan Williston, Rajiv 2405 Asati and Thomas Morin for their valuable feedback on content of this 2406 draft. We would like to thank Nick Satsia for his support with test 2407 verification of this draft. 2409 13 References 2411 13.1 Normative References 2413 [MVPN-REQ] T. Morin, Ed., ''Requirements for Multicast in L3 Provider- 2414 Provisioned VPNs'', draft-ietf-l3vpn-ppvpn-mcast-reqts-09.txt 2416 [L3VPN-MCAST] E. Rosen, R. Aggarwal, ''Multicast in MPLS/BGP IP VPNs'', 2417 draft-ietf-l3vpn-2547bis-mcast-03.txt 2419 [RFC4364] E.Rosen, Y. Rekhter, ''BGP/MPLS IP Virtual Private Networks 2420 (VPNs)'' 2422 [RFC4601] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, ''Protocol 2423 Independent Multicast - Sparse Mode (PIM-SM):Protocol Specification'' 2425 13.2 Informative References 2427 [ROSEN-8] E. Rosen, Y. Cai, I. Wijnands, "Multicast in MPLS/BGP IP 2428 VPNs", draft-rosen-vpn-mcast-08.txt 2430 [MVPN-BCP] Y. Cai, M. McBride, C. Hall, M. Napierala, ''Multicast VPN 2431 Deployment Recommendations'', draft-ycai-mboned-mvpn-deploy-00.txt 2432 Author's Addresses 2434 Silvija A. Dry 2435 Cisco 2436 7025 Kit Creek Rd. 2437 Research Triangle Park, NC 27709 2438 sdry@cisco.com 2440 Fernando Calabria 2441 Cisco 2442 7025 Kit Creek Rd. 2443 Research Triangle Park, NC 27709 2444 fcalabri@cisco.com 2446 Maria Napierala 2447 AT&T 2448 200 Laurel Avenue 2449 Middletown, NJ 07748 2450 mnapierala@att.com 2452 Yuji Kamite 2453 NTT Corporation 2454 Tokyo Opera City Tower 2455 3-20-2 Nishi Shinjuku, Shinjuku-ku 2456 Tokyo 163-1421 2457 Japan 2458 y.kamite@ntt.com 2460 Ian Yee Yan Fung 2461 Cisco Systems, Inc. 2462 ifung@cisco.com 2464 Intellectual Property Statement 2466 The IETF takes no position regarding the validity or scope of any 2467 Intellectual Property Rights or other rights that might be claimed to 2468 pertain to the implementation or use of the technology described in 2469 this document or the extent to which any license under such rights 2470 might or might not be available; nor does it represent that it has 2471 made any independent effort to identify any such rights. Information 2472 on the procedures with respect to rights in RFC documents can be 2473 found in BCP 78 and BCP 79. 2475 Copies of IPR disclosures made to the IETF Secretariat and any 2476 assurances of licenses to be made available, or the result of an 2477 attempt made to obtain a general license or permission for the use of 2478 such proprietary rights by implementers or users of this 2479 specification can be obtained from the IETF on-line IPR repository at 2480 http://www.ietf.org/ipr. 2482 The IETF invites any interested party to bring to its attention any 2483 copyrights, patents or patent applications, or other proprietary 2484 rights that may cover technology that may be required to implement 2485 this standard. Please address the information to the IETF at 2486 ietf-ipr@ietf.org. 2488 Disclaimer of Validity 2490 This document and the information contained herein are provided on an 2491 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2492 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2493 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2494 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2495 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2496 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2498 Copyright Statement 2500 Copyright (C) The IETF Trust (2007). 2502 This document is subject to the rights, licenses and restrictions 2503 contained in BCP 78, and except as set forth therein, the authors 2504 retain all their rights. 2506 This document and the information contained herein are provided on 2507 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2508 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 2509 IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 2510 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 2511 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 2512 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 2513 FOR A PARTICULAR PURPOSE. 2515 Acknowledgment 2517 Funding for the RFC Editor function is currently provided by the 2518 Internet Society.