idnits 2.17.00 (12 Aug 2021) /tmp/idnits12428/draft-sdry-bmwg-mvpnscale-03.txt: 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 1896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1879. 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 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 904 has weird spacing: '...figured on DU...' == Line 1354 has weird spacing: '...e is to asses...' == Line 1734 has weird spacing: '...nstance is us...' == 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: For consistency, it is recommended for test apparatus ports that are physically directly connected to DUT (port A1 in Figures 1 and 2)MUST not to use IGMP protocol to emulate multicast receivers. Instead PIM protocol should be used, i.e. the DUT should not be the last 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 (November 9, 2007) is 5306 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 132, but not defined == Missing Reference: 'RFC1242' is mentioned on line 508, but not defined == Missing Reference: 'RFC2285' is mentioned on line 701, but not defined == Unused Reference: 'RFC4364' is defined on line 1812, but no explicit reference was found in the text == Unused Reference: 'MVPN-BCP' is defined on line 1823, 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 (~~), 15 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 Communications 10 Expires: May 2008 November 9, 2007 12 Multicast VPN Scalability Benchmarking 13 draft-sdry-bmwg-mvpnscale-03.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 May 9, 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.........................................8 57 6 Test Environment...............................................8 58 6.1 Test Topologies..........................................8 59 6.2 Unicast Control Plane Setup..............................9 60 6.3 Multicast Control Plane Setup...........................10 61 6.4 Considerations for Number of Receivers behind remote PEs11 62 6.5 Data Traffic Characteristics............................11 63 6.6 Test Apparatus Considerations...........................12 64 7 Test Categories, Stimulus and Execution Methodology...........12 65 7.1 Steady State Testing Execution Methodology..............14 66 7.2 Failure Recovery Testing Execution Methodology..........15 67 8 Results Content and Reporting Format..........................16 68 8.1 Steady State Testing....................................16 69 8.2 Failure Recovery Testing................................17 70 9 Test Cases Common to all MVPN Architectures...................18 71 9.1 "Empty" MVPNs Scale.....................................18 72 9.2 PIM Enabled VPN C-Interfaces Scale......................19 73 9.3 PIM C-instances Mroutes Scale...........................20 74 9.4 PIM C-Instances OIF Scale...............................22 75 9.5 Joined S-PMSI (Data MDT) Scale..........................24 76 9.6 Sourced S-PMSI (Data MDT) Scale.........................25 77 9.7 S-PMSI (Data MDT) Reuse.................................26 78 9.8 Scale of mVPNs spanning large number of PEs.............28 79 9.9 Scale of mVPNs with larger amount of state..............30 80 9.10 Scale of "average" size mVPNs...........................31 81 9.11 S-PMSI Switching Delay..................................32 82 9.12 Convergence of C-Instance PIM Joins.....................33 83 9.13 Effect of Co-locating C-RPs on a PE.....................34 84 10 Test Cases Specific to PIM PE-PE signaling.................35 85 10.1 PIM Neighborships Scale.................................35 86 10.2 PIM C-instances J/P Suppression Effectiveness...........37 87 11 Test Cases Specific to PIM MI-PMSI trees...................39 88 11.1 Default MDT's (MI-PMSI's) PIM P-Instance Mroutes Scale..39 89 12 Security Considerations....................................41 90 13 IANA Considerations........................................41 91 14 Acknowledgments............................................41 92 15 References.................................................41 93 15.1 Normative References....................................41 94 15.2 Informative References..................................42 95 Author's Addresses...............................................43 96 Intellectual Property Statement..................................43 97 Disclaimer of Validity...........................................44 98 Copyright Statement..............................................44 99 Acknowledgment...................................................44 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 9-tuple comprised of a set of variables that 121 indicate the overall scalability capabilities of a PE device 122 implementation. MVPN scalability is multi-dimensional and can not 123 be quantified with single parameter, thus defining such a metric 124 set is necessary. MVPN Metric will be defined in section 5. The 125 remaining of this document focuses on a methodology that 126 characterizes different dimensions of MVPN Metric. 127 o Choice of MVPN architecture or MVPN design and operational choices 128 within specific architecture (such as selection of PIM protocol 129 variant or extent of S-PMSI (data MDT) usage), impact the overall 130 MVPN scalability of a PE device. Typically there is a tradeoff 131 between optimality and scalability. More details on these choices 132 with their tradeoffs are discussed in [MVPN-DEPLOY] and [L3VPN- 133 MCAST]. In this document design choices most suitable for a goal 134 of any given test case will be used which may not necessarily be 135 the same as recommended design choice for a realistic deployment. 136 o MVPN is a service that is never deployed in isolation as it 137 requires underlying unicast VPN offering. Typically SPs add MVPN 138 service on PE devices that are already deployed and are providing 139 a large number of other services such as unicast L3VPNs, L2VPNs, 140 internet access, etc. Therefore, when considering MVPN scalability 141 in realistic deployments one needs to take into consideration the 142 level to which PE resources are already utilized and the available 143 headroom amount remaining. In this document it will be assumed 144 that MVPN service is deployed as an addition of a "minimized" 145 unicast control plane. 146 o MVPN Scalability of a PE device is different when the system is 147 subjected to different stimuli. For example overall scalability 148 achieved in steady state is typically higher than when the system 149 is subjected to a network and/or device specific failures. In this 150 document a limited set of mandatory test stimuli will be defined. 152 2 Document Scope 154 In IETF currently there are multiple proposals on architectures and 155 protocols for implementing MVPN service, as documented in [L3VPN- 156 MCAST]. The scope of this document is to provide MVPN scalability 157 metric and benchmarking methodology set common to all architectures 158 from [L3VPN-MCAST]. However, some architectures may require 159 additional architecture specific test cases and considerations. This 160 document provides such additional test cases for the stable and 161 widely deployed MVPN architecture described in [L3VPN-MCAST] which 162 uses PIM protocol for both PE-PE transmission of C-Multicast routing 163 information (test cases in section 10) and to create 'tunnels' that 164 instantiate Multidirectional Inclusive P-Multicast Service Interfaces 165 (MI-PMSIs) and Selective P-Multicast Service Interfaces (S-PMSIs) 166 (test cases in section 11). The same architecture is also described 167 in [ROSEN-8] which is obsoleted by [L3VPN-MCAST]. In the rest of the 168 document this architecture will be referred to as "ROSEN-8" 169 architecture. 171 As other architectures from [L3VPN-MCAST] become stable and widely 172 deployed, amendments to this document can be made to address any 173 specific scalability considerations of such architectures. 175 Scope of this document is to address comparison between different 176 implementations of the same MVPN architecture, and not between 177 different MVPN architectures defined in [L3VPN-MCAST]. 179 This document proposes a MVPN metric and a test methodology to 180 compare the MVPN control plane scalability of PE devices in a 181 standardized way. In contrast, forwarding performance benchmarking is 182 not within the scope of this document. 184 Test methodology defines a standard set of test cases, their test 185 execution procedures, results content and reporting format. Standard 186 test environment is also defined for each test case. 188 Test cases 9.1-9.7,10.1,11.1 focuses on determining implementation 189 limits individually for each of the key MVPN variables in a standard 190 way. Test cases (9.8-9.13) focus on determining implementation limits 191 for combination of all MVPN variables and will be helpful to 192 operators with network engineering for their deployments. Choices of 193 values of variables in test cases 9.8-9.13 were made using 194 information from the MVPN requirements survey conducted as part of 195 [MVPN-REQ]. 197 Each test case addresses following two major testing types: 199 . Steady State Testing: Device Under Test (DUT) and network as a 200 whole are not subject to any failure stimulus/control plane events. 201 . Failure Recovery Testing: DUT and or network components are subject 202 to different failure stimulus that introduces one or more control 203 plane instability events. 205 In this document limited set of mandatory test stimuli is also 206 defined. 208 Note that, depending on MVPN architecture, the deployment of MVPN 209 also consumes resources on network elements other than PE router such 210 as P devices, route reflectors and CE devices. Their scalability is 211 beyond the scope of this document. 213 3 Terminology 215 DUT (Device Under Test) term will be used interchangeably with MVPN 216 PE device. All other PE devices in the test topology will be referred 217 to as "remote PEs". 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. 258 Data MDT (Data Multicast Distribution Tree): Multicast distribution 259 tree through the SP core that delivers VPN data traffic for a 260 particular multicast group only to those PE routers which are on the 261 path to receivers of that group. This is [ROSEN-8] terminology for 262 transport service of S-PMSIs. 264 ASM (Any Source Multicast): Multicast service model in which a 265 receiver subscribes to a multicast group to receive traffic sent to 266 the group by any source. 268 SSM (Source Specific Multicast): Multicast service model in which a 269 receiver subscribes to a multicast group to receive traffic sent to 270 the group by the specific source. 272 Mroute: Multicast route. Term "state" will used interchangeable with 273 "mroute" and "multicast route". 275 "ROSEN-8" architecture: architecture described in [L3VPN-MCAST] which 276 uses PIM protocol for both PE-PE Transmission of C-Multicast Routing 277 and to create 'tunnels' that instantiate Multidirectional Inclusive 278 P-Multicast Service Interfaces (MI-PMSIs) and Selective P-Multicast 279 Service Interfaces (S-PMSIs). This is a same as architecture 280 described in [ROSEN-8]. 282 Ingress C-instance multicast group or mroute: C-instance multicast 283 group or mroute which has source behind VPN C-interface of DUT PE and 284 at least one receiver behind one of remote PEs. 286 Egress C-instance multicast group or mroute: C-instance multicast 287 group or mroute which has source behind one of remote PEs and at 288 least one receiver behind VPN C-interface of DUT PE. 290 Ingress traffic flow, packet, traffic: respectively multicast traffic 291 flow, packet, traffic forwarded by DUT using ingress C-instance 292 mroute. 294 Egress traffic flow, packet, traffic: respectively multicast traffic 295 flow, packet, traffic forwarded by DUT using egress C-instance 296 mroute. 298 4 Key Words to Reflect Requirements 300 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 301 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 302 document are to be interpreted as described in RFC 2119. 304 RFC 2119 defines the use of these key words to help make the intent 305 of standards track documents as clear as possible. While this 306 document uses these keywords, this document is not a standards track 308 5 MVPN Metric Definition 310 MVPN control plane scalability of PE device can not be described as a 311 single parameter but it requires a set of variables. We call such a 312 set "MVPN Metric" and define it further in this section. 314 When providing scalability capabilities of a PE device one MUST 315 provide values for all of the MVPN metric variables that were used 316 during the test. For example, one should never claim that a PE device 317 supports X number of MVPNs without disclosing the values of other 318 MVPN Metric variables. 320 The MVPN Metric is defined as a tuple of the following 9 variables: 322 1. Num_mVPN: Number of multicast VPN routing instances configured on 323 DUT that have MI-PMSI (default MDT) active and forwarding 324 2. Num_PE: Number of PE routers per multicast VPN 325 3. Num_MC_C_ints: Number of PIM C-interfaces on DUT 326 4. Num_PIM_C_neigh: Total number of PIM neighbors in PIM C-instances 327 across all mVPNs on DUT 328 5. Num_*G_C: Total number of (*,G) multicast routes across all MVPNs 329 on DUT capable of forwarding and created by PIM C-instances. 330 6. Num_SG_C: Total number of (S,G) multicast routes across all MVPNs 331 on DUT capable of forwarding and created by PIM C-instances. 332 7. Num_OIF_C: Total number of OIFs on DUT across all multicast routes 333 created by PIM C-instances. 334 8. Num_SPMSI_Src: Total number of S-PMSIs (data MDTs) across all mVPNs 335 on DUT that are sourced by DUT. 336 9. Num_SPMSI_Rx: Total number of S-PMSIs (data MDTs) across all mVPNs 337 on DUT for which DUT is a receiver. 339 6 Test Environment 341 All protocols involved MUST be deployed with default timers as 342 specified by their corresponding RFC / standards. 344 6.1 Test Topologies 346 Following test topology is used by all test cases that don't 347 explicitly specify different topology. 349 ___________ _________ ________ ________ ___________ 350 / \ / \ / \ / \ / \ 351 | Test |A1 | (DUT) |D2 | RR |B2 | |B4 | Test | 352 | Apparatus |===| PE1 |===| P |===| PE2 |===| Apparatus | 353 | | D1| | B1| | B3| | A2| | 354 \___________/ \_________/ \______/ \________/ \___________/ 355 || 356 || _____________ 357 || / \ 358 || A3| Test | 359 ++================| Apparatus | 360 | (Emulating | 361 |_PE routers)_| 362 \_____________/ 364 Figure 1. Test Topology 1 366 Legend: 368 D1 (DUT's C-facing interface): DUT's interface that connects to 369 customer premise router (C-router). 371 D2 (DUT's P-facing interface): DUT's interface that connects to SP's 372 core router (P-router). 374 RR/P (Route Reflector/P-router) - single router that will be 375 performing roles of both P-router and route reflector 377 PE2 - Will also be referred to as "Remote PE" and is the router 378 performing PE functionality to assist with evaluation of DUT PE 379 router. 381 6.2 Unicast Control Plane Setup 383 All P facing interfaces MUST use OSPF as IGP. This requirement is 384 made to provide a standard way to compare end to end convergence 385 times which depend on the underlying unicast protocol. Only a minimum 386 number of IGP routes required to establish connectivity should be 387 seen on the DUT. 389 All PE routers in the topology including the DUT and emulated PE's 390 MUST have one iBGP peer to the Route Reflector. DUT SHOULD NOT have 391 any additional iBGP peering. Only the minimum number of VPNv4 iBGP 392 routes required to establish site to site VPN connectivity should be 393 imported on the DUT. There SHOULD NOT be any internet/ipv4 routes 394 seen on the DUT. 396 A DUT MUST use static unicast routing on all C facing VPN interfaces. 397 Only the minimum number of static routes required to establish end to 398 end connectivity should be seen on the DUT. No dynamic unicast 399 routing protocol is used in order to minimize processing overhead. 401 6.3 Multicast Control Plane Setup 403 In any given test, all MI-PMSIs (default MDTs) MUST be established 404 using the same protocol. In cases where PIM is used to establish MI- 405 PMSIs, different tests may require different PIM protocol variants, 406 so refer to individual test cases for the appropriate PIM P-instance 407 configuration. In any test case where ASM (Any Source Multicast) mode 408 of PIM-SM (Protocol Independent Multicast - Sparse mode) is the 409 multicast routing protocol used for MI-PMSI (default MDT), a DUT 410 SHOULD NOT be the RP (Rendezvous Point). Also dynamic RP discovery 411 protocols SHOULD NOT be used for default MDT groups. 413 For S-PMSIs (data MDT) point to multipoint trees MUST be used. For 414 example if PIM is used to build S-PMSI groups PIM-SSM (Source 415 Specific Multicast) routing protocol MUST be used. 417 Following C-instance multicast configuration MUST be used in all test 418 cases: 419 a. Protocol for PIM C-instances: PIM-SM (ASM) 420 b. RP Location for PIM C-instances: Test apparatus port 421 closest to the source. 422 c. SPT threshold for PIM C-instances: zero 424 Following per MVPN scale of common variables MUST be used in all test 425 cases except where test case setup explicitly asks to test with 426 different values: 428 a. Number of PIM VPN C-interfaces: 1 429 b. Number of sources per C-instance group: 2 430 c. Ratio of ingress to egress C-instance groups: 10%:90% 432 Behind each VPN C-interface there MUST be one receiver for each 433 C-instance group whose source doesn't reside behind the same 434 C-interface. 436 Sources emulated by test apparatus ports that are physically directly 437 connected to DUT (port A1 in Figures 1 and 2) not have IP address 438 from DUT's connected subnets, i.e. the DUT MUST NOT be the first hop 439 router. 441 For consistency, it is recommended for test apparatus ports that are 442 physically directly connected to DUT (port A1 in Figures 1 and 2)MUST 443 not to use IGMP protocol to emulate multicast receivers. Instead PIM 444 protocol should be used, i.e. the DUT should not be the last hop 445 router. 447 As an exception to previous paragraph it may exist specific network 448 design requirement to deploy IGMP receivers connected directly to the 449 DUT in which case test results MUST specify number of C-interfaces 450 with IGMP receivers. Regardless the IGMP protocol variant to be 451 deployed (IGMPV2 / V3); receivers MUST be emulated by the test 452 apparatus and NOT defined on the DUT in the form of static group 453 reports. Test apparatus MUST be capable to emulate an IGMP Host or 454 Querier and set a maximum Timer Interval between messages of 1/10th 455 of a second. 457 6.4 Considerations for Number of Receivers behind remote PEs 459 Number of C-instance receivers behind remote PEs that MUST be 460 emulated with test tools for all ingress multicast groups depends on 461 protocol used for PE-PE signaling. 463 If PIM is used as PE-PE signaling and test case 10.2 revealed that PE 464 device does perform J/P suppression all test cases MUST be executed 465 with receiver behind only one of remote PEs for any given ingress C- 466 instance group. This is required to properly emulate remote PEs that 467 support PIM J/P suppression with existing test tools which do not 468 support PIM J/P suppression. 470 If PIM is used as PE-PE signaling and test case 10.2 revealed that PE 471 device does not perform efficient J/P suppression, then for each test 472 case that is requesting in Test Setup section for Number of remote 473 PEs > 1, testing MUST be executed with receivers behind 50% of remote 474 PEs per ingress C-instance group. It is DESIRABLE to execute all such 475 test cases with 2 additional values of number receivers behind remote 476 PEs. 478 If BGP is used as PE-PE signaling, then for each test case that is 479 requesting in Test Setup section for Number of remote PEs > 1, 480 testing MUST be executed with receivers behind 50% of remote PEs per 481 ingress C-instance group. It is DESIRABLE to execute all such test 482 cases with 2 additional values of number receivers behind remote PEs. 484 6.5 Data Traffic Characteristics 486 For every C-instance multicast route there MUST be traffic flow 487 associated with it and forwarded by DUT. 489 All C-instance flows SHOULD be transmitted with the same traffic rate 490 and packet size. 492 As the focus of this document is on the control plane scalability and 493 not on forwarding performance the data rate and packet size of 494 traffic flows can be chosen by user but it MUST be reported in the 495 test results. However it is suggested to use 10% of "idle system" 496 throughput [RFC1242] so that it can be easily detected if hardware 497 forwarding platforms start forwarding in software and at the same 498 time in case of software forwarding platforms there will be enough 499 processor headroom left for control plane scaling. By "idle system" 500 we refer to system with all of MVPN metric variables minimized and 501 single VPN traffic flow in each direction. 503 As an additional requirement, the reader of this document may also be 504 interested in analyzing the "impact" that high traffic rate may have 505 on the control plane. This would be of interest mostly for software 506 forwarding platforms. For this specific requirement additional test 507 cases SHOULD be performed increasing the rate of multicast traffic to 508 20%, 50% and 90% of "idle system" throughput [RFC1242]. 510 6.6 Test Apparatus Considerations 512 Different test tools must generate C-instance PIM protocol control 513 messages in a consistent way since they are directly connected to the 514 DUT. 516 The following MUST be implemented on all PIM sessions on the test 517 apparatus: 519 1) PIM Join/Prune aggregation MUST be utilized and set such that 80 520 PIM J/P messages are aggregated in each PDU 522 2) PIM Join/Prune aggregated PDUs MUST be sent at 10 PDUs/sec rate 523 per PIM session, i.e. this translates to maximum of 524 80*10*60=48,000 state per minute. 526 3) PIM Register messages MUST be sent at 100 PDUs/sec rate. 528 7 Test Categories, Stimulus and Execution Methodology 530 Each test case specified in section 9 MUST be executed for steady 531 state and for each of six mandatory failure stimulus listed below. 532 Optionally one can use methodology defined in this document for 533 additional stimulus. 535 Mandatory failure stimulus: 537 1) DUT Power Cycle: Physical power cycle of DUT. All convergence 538 times MUST be measured from the time DUT's power is turned back 539 on. This time instance will be referred to as Tf (the time of 540 failure recovery action) for this failure stimulus. 542 2) Main Processor Card Switchover: Physical removal of the active 543 main processor card in the redundant system. All convergence times 544 should be measured from the time active processor card is 545 physically disconnected from the chassis (Tf). This stimulus can 546 be omitted only for platforms that do not support redundant main 547 processor cards. 549 3) P-facing Line Card OIR (online insertion and removal): Physical 550 removal and insertion of P-facing line card. Time between removal 551 and insertion SHOULD be at least 300 seconds. All convergence 552 times should be measured from the time line card is physically 553 inserted into chassis (Tf). 555 4) C-facing Line Card OIR: Physical removal and insertion of C-facing 556 line card. Time between removal and insertion SHOULD be at least 557 300 seconds. All convergence times should be measured from the 558 time line card is physically re-inserted into chassis (Tf). 560 5) P-facing Link Flap: Physical removal and insertion of the cable 561 from P router side that is connected to P-facing interface of DUT. 562 Time between removal and insertion SHOULD be at least 300 seconds. 563 All convergence times should be measured from the time cable is 564 physically re-inserted (Tf). 566 6) C-facing Link Flap: Physical removal and insertion of the cable 567 from test apparatus side that is connected to C-facing interface 568 of DUT. Time between removal and insertion SHOULD be at least 300 569 seconds. All convergence times should be measured from the time 570 cable is physically re-inserted (Tf). 572 Since the test execution methodology is similar for all test cases we 573 will describe it here for both steady state and failure recovery 574 testing. Any deviation from this will be specified per test case in 575 sections 9,10 and 11. 577 Multiple iterations of each test are required to determine maximum 578 value for certain set of variables. A single iteration will be 579 referred to as a "Test Case Instance". 581 7.1 Steady State Testing Execution Methodology 583 The following test execution procedure MUST be used for all Test Case 584 Instances during steady state testing of each test case defined in 585 sections 9,10 and 11 of this document: 587 1) Ensure the testbed is setup according to Test Setup instructions 588 of individual test case 590 2) All interfaces MUST be operational and MI-PMSIs (default MDTs) 591 required by the test case MUST be built as expected. 592 Verification can be done by DUT internal tools. 594 3) All real and emulated PE devices required by test cases MUST 595 have all C-instance PIM neighborships (including over MI-PMSIs) 596 operational in both directions. Verification MUST be done by 597 both external test apparatus and DUT internal tools. 599 4) All destination test apparatus ports configured to receive 600 multicast traffic should join all configured multicast groups. 602 5) All source test apparatus ports configured to transmit multicast 603 traffic should start transmitting to all multicast groups. 605 6) All multicast traffic MUST be received at all expected 606 destination test ports without any packet drops. This MUST be 607 verified using external test apparatus. If this state can not be 608 reached within 10 minutes of execution of step 5, continue to 609 next test case instance with reduced value of scaled variable/s 610 . 612 7) After state in previous step is reached wait 10 minutes and 613 start collecting data for this test instance required by 614 individual test case. This time instance is considered steady 615 state. 617 8) If any one of following conditions are reached continue to next 618 test case instance with reduced value of scaled variable/s: 620 o 100% utilization of system resources (memory, processor, 621 etc.) 623 o Failing of any of test case specific criteria or criteria in 624 steps 1-6 above 626 The number of Test Case Instances per test case is left to 627 tester's discretion. However, it is DESIRABLE to have results for 628 at least 5 test case instances. Having a range of values will help 629 in variable's characterization. The characterization of a variable 630 cannot be achieved with only one test case instance result. 632 7.2 Failure Recovery Testing Execution Methodology 634 The following test execution procedure MUST be used for all Test Case 635 Instances during failure recovery testing of each test case defined 636 in section 9 of this document: 638 1) Execute steps 1-7 from section 7.1 640 2) After steady state in previous step is reached wait 10 minutes 641 to initiate one of mandatory failure stimulus listed in section 642 7. Note the time of failure recovery action (Tf) as displayed by 643 the external test apparatus that is measuring the received 644 multicast traffic. 646 3) Using the external test apparatus note the time when THE FIRST 647 multicast packet has been received on at least ONE of expected 648 ports. Refer to this time instance as Tre for the first such 649 ingress packet and Trd for the first such egress packet. 651 4) Using the external test apparatus note the time when ALL 652 multicast traffic has been received on ALL expected ports, i.e. 653 it has returned to the same initial rate (in pps). Refer to this 654 time instance Trall. 656 5) After state in previous step is reached execute steps 2-3 from 657 7.1. 659 6) If all data verified in step 5 is the same as before failure 660 wait 10 minutes and start collecting data for this test instance 661 required by each individual test case 663 7) If any one of following conditions are reached continue to next 664 test case instance with reduced value of scaled variable/s: 666 a. Value of MVPN metric in steady state reached after failure 667 stimuli (step 6 above) is not the same as in original 668 steady state. 670 b. Failing of any of test case specific criteria or criteria 671 in steps 1-6 above 673 The number of Test Case Instances per test case is left to 674 tester's discretion. However, it is DESIRABLE to have results for 675 at least 5 test case instances. Having a range of values will help 676 in variable's characterization. The characterization of a variable 677 cannot be achieved with only one test case instance result. 679 8 Results Content and Reporting Format 681 8.1 Steady State Testing 683 For steady state portion of testing for each test case the following 684 results MUST be included in the test case report: 686 1. Protocol used for establishment of MI-PMSIs and S-PMSIs 687 2. Protocol used for PE-PE signaling 688 3. Maximum value achieved for variables requested to be varied in 689 individual test case 690 4. Values of MVPN Metric variables in the test instance in which item 691 1 of this report was achieved. The MVPN Metric as defined in 692 section 5 of this document MUST be used 693 5. Num_*G_P: Total number of (*,G) multicast routes on DUT created by 694 PIM P-instance on DUT. 695 6. Num_SG_P: Total number of (S,G) multicast routes on DUT created by 696 PIM P-instance. 697 7. Num_OIF_P: Total number of OIFs (outgoing interfaces) on DUT across 698 all multicast routes created by PIM P-instance. 699 8. Forwarding rate(in pps)[RFC2285] and packet sizes (in bytes) of all 700 flows in ingress direction at DUT 701 9. Forwarding rate(in pps)[RFC2285] and packet sizes (in bytes) of all 702 flows in egress direction at DUT 703 10. Multicast Latency [RFC2432]averaged over all C-instance 704 multicast flows in ingress direction 705 11. Multicast Latency [RFC2432]averaged over all C-instance 706 multicast flows in egress direction 707 12. Utilization of all processors in the system including the main 708 processor and line card processors where applicable. A description 709 of the way processor utilization is measured SHOULD be included in 710 the report. 711 13. Utilization of all relevant DUT memory components including 712 the main route processor memory and line cards where applicable. 713 14. Utilization of any relevant hardware components where 714 applicable 715 15. Any deviations in DUT configuration from the configuration 716 defined in this document. 718 16. Any deviations in test execution procedure 720 It is DESIRABLE to include in the report items 1-16 above for all 721 optional test case instances executed, where instead of maximum value 722 achieved one would report tested value for each test case instance. 724 8.2 Failure Recovery Testing 726 In addition to data included in steady state reports defined in the 727 previous section the following MUST be included in the result report 728 of each failure recovery test case: 730 1. The worst case end to end traffic convergence time (Trall-Tf) 731 2. The best case end to end traffic convergence time ((Tre-Tf) for 732 ingress traffic and (Trd-Tf) for egress traffic) 734 Note: Determination of whether all multicast flows had recovered to 735 the original traffic rate MUST be made by external test tools and 736 not by any available tools internal to the DUT or other routers in 737 the test topology. 739 It is DESIRABLE to include: 741 1. A graph from all test tool ports showing transmitted and received 742 packet rate starting from 60 seconds prior to failure action to 60 743 seconds after all multicast flows had recovered to the traffic rate 744 they had prior to the failure. 745 2. The best case MI-PMSI PIM neighborship convergence time: time 746 interval from instance Tf to instance when the first C-instance PIM 747 neighbor across one of MI-PMSIs comes up on both DUT and 748 neighboring device (i.e. "bi-directional" neighborships are 749 established). 750 3. The worst case MI-PMSI PIM neighborship convergence time: time 751 interval from instance Tf to instance when all expected C-instance 752 PIM neighbors across one of MI-PMSIs comes up on both DUT and 753 neighboring device (i.e. "bi-directional" neighborships are 754 established). 756 9 Test Cases Common to all MVPN Architectures 758 Test cases in this section are applicable to all MVPN architectures 759 described in [L3VPN-MCAST]. As [L3VPN-MCAST] specifies use of S-PMSIs 760 as optional, test cases 9.5-9.7,9.11 can be omitted for implementers 761 that don't support S-PMSIs. For such implementers test cases 9.8- 762 9.10,9.12-9.13 SHOULD still be executed but without use of S-PMSIs 763 and the exception MUST be documented in the test report. 765 9.1 "Empty" MVPNs Scale 767 Test Objective: 769 To determine maximum number of MVPN instances that can be 770 configured and operational on the MVPN PE router. Note that we 771 refer here to mVPNs as "empty" as amount of PIM neighborships, 772 interfaces, C-instances multicast routes and SI-PMSIs associated 773 with given mVPN is negligible or zero in this test case. 775 Metric Variables Relationships: 777 Num_mVPN=Num_MC_C_ints 779 Num_*G_C=Num_SG_C=2*Num_mVPN 781 Num_OIF_C=4*Num_mVPN 783 Test Setup: 785 Following test setup MUST be performed prior to executing this test 786 case 788 1. Protocol for MI-PMSI P-instance PIM groups (if PIM used): ASM or 789 Bi-dir 790 2. S-PMSI (Data MDT) used: NO 791 3. Multicast Control Plane Profile (all per mVPN except a.; all 792 from DUT's perspective): 793 a. Number of MVPNs configured on DUT(Num_mVPN): varies 794 b. Number of remote PEs: 1 795 c. Number of C-instance multicast groups : 2 796 d. Ratio of ingress vs. egress C-instance groups: 50%:50% 798 Test Execution Procedure: 800 Execute number of test case instances where in each test case 801 instance number of configured mVPNs is varied with the goal of 802 finding maximum number of mVPNs that can be configured and 803 operational on DUT. Configured mVPN will be considered operational 804 if all traffic flows are being received on ALL expected ports 805 without any drops. 807 For each test case instance perform steps 1-8 from section 7.1. and 808 1-7 from section 7.2 for all mandatory stimuli in section 7. 810 Test Result Report: 812 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 813 at least maximum value of number of mVPNs achieved. It is DESIRABLE 814 to include the same data for at least 5 different values of number 815 of mVPNs (i.e. for at least 5 test case instances). 817 9.2 PIM Enabled VPN C-Interfaces Scale 819 Test Objective: 821 To determine maximum number of PIM enabled VPN C-interfaces that 822 can be operational on the MVPN PE router for couple of fixed values 823 of number of mVPNs. Amount of all other MVPN Metric is minimized in 824 this test case. 826 Metric Variables Relationships: 828 Num_MC_C_ints >= Num_mVPN 830 Num_*G_C=Num_SG_C=Num_OIF_C=0 832 Test Setup: 834 Following test setup MUST be performed prior to executing this test 835 case 837 1. Protocol for MI-PMSI P-instance PIM groups (if PIM used): ASM or 838 Bi-dir 839 2. S-PMSI (Data MDT) used: NO 840 3. Multicast Control Plane Profile (all per mVPN except a.; all 841 from DUT's perspective): 842 a. Number of MVPNs configured on DUT (Num_mVPN): varies 843 b. Number of PIM VPN C-interfaces: varies 844 c. Number of remote PEs: 1 845 d. Number of C-instance multicast groups : 0 847 Test Execution Procedure: 849 Following are steps to execute this test case: 851 1. Configure 100 mVPNs on DUT and PE2. Execute number of test case 852 instances where in each test case instance number of PIM enabled 853 VPN C-interfaces per mVPN is varied with the goal of finding 854 maximum number of PIM enabled VPN C-interfaces that can be 855 configured and operational on DUT. Configured VPN C-interface will 856 be considered operational if there is at least one PIM neighbor in 857 VPN C-instance on each configured C-interface. 859 2. Repeat step 1 for 100*I mVPNs where "i=2…N" where N is integer 860 value for which either maximum number of PIM enabled VPN C- 861 interfaces per mVPN becomes smaller than one or maximum number of 862 mVPNs found in test case 9.1 is reached. 864 Note that in this test case there SHOULD NOT be any multicast C- 865 instance traffic sources or receivers thus one MUST modify test 866 execution procedure from 7.1 and 7.2. For each test case instance 867 perform steps 1-3,7 from section 7.1. and 1-2,5-7 from section 7.2 868 for all mandatory stimuli in section 7. 870 Test Result Report: 872 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 873 at least maximum achieved value of number of PIM enabled VPN C- 874 interfaces. It is DESIRED to include the same data for at least 5 875 different values of PIM enabled VPN C-interfaces (i.e. for at least 876 5 test case instances). 878 9.3 PIM C-instances Mroutes Scale 880 Test Objective: 882 To determine the maximum amount of PIM C-instance mroutes that a PE 883 router can create, maintain and forward on. Amount of most of other 884 MVPN Metric is minimized in this test case. 886 Metric Variables Relationships: 888 (Num_*G_C + Num_SG_C)>> Num_mVPN 889 Num_OIF_C >> Num_mVPN 891 Num_MC_C_ints = Num_mVPN 893 Test Setup: 895 Following test setup MUST be performed prior to executing this test 896 case 898 1. Protocol for MI-PMSI P-instance PIM groups(if PIM used): ASM or 899 Bi-dir 901 2. S-PMSI (Data MDT) used: NO 902 3. Multicast Control Plane Profile (all per mVPN except a.; all 903 from DUT's perspective): 904 a. Number of MVPNs (Num_mVPN) configured on DUT: varies 905 b. Number of remote PEs: 1 906 c. Ratio of ingress vs. egress C-instance groups: 100%:0%, 907 0%:100% and 10%:90% 908 d. Number of C-instance sources per group: 2 and 50 910 Test Execution Procedure: 912 Total number of C-instance PIM mroutes is proportional to product 913 of number of mVPNs DUT belongs to and average number of C-instance 914 PIM mroutes per mVPN. Total number of C-instance mroutes can vary 915 depending on number of mVPNs, number of sources per group and 916 location of the sources/receivers. Thus this test should be 917 executed for all specified values of parameters in Test Setup. 919 Each test will consist of finding maximum number of C-instance PIM 920 mroutes by varying average number of C-instance PIM mroutes per 921 mVPN for set of fixed values of number of mVPNs. Procedure is as 922 follows: 924 1. On DUT and PE2 configure 100 mVPNs. Setup environment such that 925 all PIM C-instance sources are behind DUT. Execute number of 926 test case instances using steps 1-7 in section 7.1 where in each 927 test case instance number of C-instance PIM groups is varied 928 until maximum number of C-instance PIM mroutes is found. 930 2. Repeat step 1 for 100*I mVPNs where "i=2…N" where N is integer 931 value for which either maximum number of C-instance PIM mroutes per 932 mVPN becomes smaller than one or maximum number of mVPNs found in 933 test case 9.1 is reached. 935 3. Repeat steps 1 and 2 for two more values of ingress vs. egress 936 C-instance groups ratio: 0%:100% and 10%:90%. 938 4. Repeat steps 1 and 2 for one more value of number of sources per 939 group 941 For each test case instance perform steps 1-8 from section 7.1. and 942 1-7 from section 7.2 for all mandatory stimuli in section 7. 944 Test Result Report: 946 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 947 at least maximum value of average number of PIM C-instance mroutes 948 for every tested value of number of mVPNs per PE. It is DESIRED to 949 include the same data for at least 5 different values of number of 950 PIM C-instance mroutes per mVPN for each of tested values of number 951 of mVPNs per PE(i.e. for at least 5 test case instances per each 952 tested value of number of mVPNs). 954 9.4 PIM C-Instances OIF Scale 956 Test Objective: 958 To determine the maximum amount of PIM C-instance OIFs that a PE 959 router can create and maintain. Amount of other MVPN Metric is 960 minimized in this test case. 962 Metric Variables Relationships: 964 Num_MC_C_ints > Num_mVPN 966 (Num_*G_C + Num_SG_C)>> Num_mVPN 968 Num_OIF_C >> Num_mVPN 970 Test Setup: 972 Following test setup MUST be performed prior to executing this test 973 case 975 1. Protocol for MI-PMSI P-instance PIM groups (if PIM used): ASM or 976 Bi-dir 978 2. S-PMSI (Data MDT)used: NO 979 3. Multicast Control Plane Profile (all per mVPN except a.; all 980 from DUT's perspective): 981 a. Number of MVPNs(Num_mVPN)configured on DUT: 100 and maximum 982 value tested in 9.3 983 b. Number of PIM VPN C-interfaces: maximum found in 9.2 984 c. Number of remote PEs: 1 985 d. Ratio of ingress vs. egress C-instance groups: 0%:100% 987 Test Execution Procedure: 989 Test will consist of finding the maximum number of C-instance PIM 990 OIFs by varying the average number OIFs per PIM C-instance mroute. 991 Maximum number will be found for couple of values of number of C- 992 instance PIM mroutes. Test will be executed for two values of 993 number of mVPNs: 100 and maximum value tested in 9.3.All C-instance 994 PIM mroutes will be in egress direction. Procedure is as follows: 996 1. For the first test iteration number of C-instance groups should 997 be set to 25% of maximum value achieved in test case instance of 998 9.3 where C-instance group ingress vs. egress ratio was 0:100% 999 and 100 mVPNs was used. Execute number of test case instances 1000 using steps 1-8 in section 7.1 where in each test case instance 1001 average number of C-instance OIFs per mroute is varied in 1002 increments of 2 until maximum number of OIFs is reached. 1004 2. Repeat step 1 for 50%,75% and 100% of egress C-instance groups 1005 achieved in test case 9.3. 1007 3. Repeat steps 1 and 2 for the case of maximum number of mVPNs 1008 tested in 9.3. 1010 For each test case instance perform steps 1-8 from section 7.1. and 1011 1-7 from section 7.2 for all mandatory stimuli in section 7. 1013 Test Result Report: 1015 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1016 at least maximum value of OIFs per C-instance mroute for every 1017 tested value of number of egress groups per PE. It is DESIRED to 1018 include the same data for at least 5 different values of number of 1019 OIFs for each of tested values of number of egress groups(i.e. for 1020 at least 5 test case instances per each tested value of number of 1021 egress groups). 1023 9.5 Joined S-PMSI (Data MDT) Scale 1025 Test Objective: 1027 To determine the maximum number of S-PMSIs (data MDTs) that a PE 1028 can join. In order to assess maximum number of S-PMSI (data MDTs) 1029 joined, we minimize resources taken by C-instance mroutes by 1030 requiring that no data MDT (S-PMSI) reuse is utilized in this test 1031 case. Note that depending on specific deployment context data MDT 1032 reuse might or might not be desirable. 1034 Metric Variables Relationships: 1036 Num_SPMSI_Rx > Num_mVPN 1038 Num_SPMSI_Src = 0 1040 Num_MC_C_ints > Num_mVPN 1042 (Num_*G_C + Num_SG_C)>> Num_mVPN 1044 Num_OIF_C >> Num_mVPN 1046 Test Setup: 1048 Following test setup MUST be performed prior to executing this test 1049 case 1051 1. Protocol for MI-PMSI P-instance PIM groups (if PIM used): ASM or 1052 Bi-dir 1053 2. S-PMSI (Data MDT)used: YES 1054 3. Multicast Control Plane Profile (all per mVPN except a.; all 1055 from DUT's perspective): 1056 a. Number of MVPNs (Num_mVPN) configured on DUT: maximum 1057 number of mVPNs obtained in test case 9.3 (refer to it as 1058 Vmax) 1059 b. Number of PIM VPN C-interfaces: max found in 9.2 for Vmax 1060 mVPNs 1061 c. Number of remote PEs: 1 1062 d. Number of C-instance multicast groups: :[Smax/4] where Smax 1063 is maximum number of C-instance groups obtained in test 1064 case 9.3 for Vmax number of mVPNs 1065 e. Ratio of ingress vs. egress C-instance groups: 0%:100% 1067 Test Execution Procedure: 1069 Test will consist of varying number of S-PMSIs utilized by flows 1070 that have receivers behind DUT (refer to those S-PMSI as "joined S- 1071 PMSIs"). During all test case instances total number of C-instance 1072 PIM mroutes MUST remain constant and will be [Smax/4] rounded to 1073 the first lower integer. We will vary total number of joined S- 1074 PMSIs by varying number of mVPNs configured to use S-PMSIs at the 1075 remote PE that has sources behind it, while number of data S-PMSIs 1076 per mVPNs will be same for all mVPNs that use them. If given mVPN 1077 is using S-PMSIs in particular test case instance number of them 1078 should be Dvpn=[Smax/(4*Vmax)] rounded to first lower value that 1079 can be represented as 2^I where I is an integer. Note that number 1080 of S-PMSIs configured and sourced by DUT MUST be zero in this test 1081 case. Procedure is as follows: 1083 1. Configure one mVPN on the remote PE and all flows so that this 1084 mVPN has Dvpn S-PMSIs (data MDTs) utilized and all are sourced 1085 at the remote PE and received at DUT. Execute steps 1-7 in 1086 section 7.1 1088 2. Repeat step 1 where number of mVPNs that utilize S-PMSIs/data 1089 MDTs (in the exact same way as 1 mVPN described in step1) takes 1090 following values 25%,50%,75%,and 100% of Vmax. 1092 3. If platform limit is not reached during execution of step 2, 1093 increase number of joined S-PMSIs (data MDTs) per mVPN and 1094 repeat steps 1 and 2. 1096 For each test case instance perform steps 1-8 from section 7.1. and 1097 1-7 from section 7.2 for all mandatory stimuli in section 7. 1099 Test Result Report: 1101 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1102 all test case instances executed. 1104 9.6 Sourced S-PMSI (Data MDT) Scale 1106 Test Objective: 1108 To determine maximum number of S-PMSIs (data MDTs) that PE can 1109 source. In order to assess maximum number of S-PMSIs sourced, we 1110 minimize resources taken by C-instance mroutes by requiring that no 1111 S-PMSI (data MDT) reuse is utilized in this test case. Note that 1112 depending on specific deployment context data MDT reuse might or 1113 might not be desirable. 1115 Metric Variables Relationships: 1117 Num_SPMSI_Src > Num_mVPN 1119 Num_SPMSI_Rx = 0 1121 Num_MC_C_ints = Num_mVPN 1123 (Num_*G_C + Num_SG_C)>> Num_mVPN 1125 Num_OIF_C >> Num_mVPN 1127 Test Setup: 1129 Following test setup MUST be performed prior to executing this test 1130 case 1132 1. Protocol for MI-PMSI P-instance PIM groups (if PIM used): ASM or 1133 Bi-dir 1134 2. S-PMSI (Data MDT)used: YES 1135 3. Multicast Control Plane Profile (all per mVPN except a.; all 1136 from DUT's perspective): 1137 a. Number of MVPNs (Num_mVPN) configured on DUT: maximum 1138 number of mVPNs obtained in test case 9.3 (refer to it as 1139 Vmax) 1140 b. Number of PIM VPN C-interfaces: max found in 9.2 for Vmax 1141 mVPNs 1142 c. Number of remote PEs: 1 1143 d. Number of C-instance multicast groups: :[Smax/4] where Smax 1144 is maximum number of C-instance groups obtained in test 1145 case 9.5 for Vmax number of mVPNs 1146 e. Ratio of ingress vs. egress C-instance groups: 100%:0% 1148 Test Execution Procedure: 1150 Reverse role of DUT and remote PE from test case 9.5, where now DUT 1151 is sourcing all data MDTs (S-PMSIs) while remote PE is on the 1152 receiving end of them. Repeat test case 9.5 for this reversed role 1153 scenario. 1155 9.7 S-PMSI (Data MDT) Reuse 1157 Test Objective: 1159 To determine maximum number of C-instance flows that can utilize 1160 data MDTs (S-PMSIs) and assess impact data MDT reuse has. Note that 1161 depending on specific deployment context data MDT reuse might or 1162 might not be desirable. This is optional test case for 1163 implementations that do support S-PMSI reuse. 1165 Metric Variables Relationships: 1167 (Num_*G_C + Num_SG_C)>Num_SPMSI_Rx >= Num_mVPN 1169 (Num_*G_C + Num_SG_C)>Num_SPMSI_Src >= Num_mVPN 1171 Num_MC_C_ints = Num_PIM_C_neigh > Num_mVPN 1173 (Num_*G_C + Num_SG_C)>> Num_mVPN 1175 Num_OIF_C >> Num_mVPN 1177 Test Setup: 1179 Following test setup MUST be performed prior to executing this test 1180 case 1182 1. Protocol for MI-PMSI P-instance PIM groups (if PIM used): ASM 1183 or Bi-dir 1184 2. S-PMSI (Data MDT)used: YES 1185 3. Multicast Control Plane Profile (all per mVPN except a.; all 1186 from DUT's perspective): 1187 a. Number of MVPNs configured on DUT (Num_mVPN): maximum 1188 number of mVPNs obtained in test case 9.5 (refer to it as 1189 Vmax) 1190 b. Number of PIM VPN C-interfaces: max found in 9.2 for Vmax 1191 mVPNs 1192 c. Number of remote PEs: 1 1193 d. Number of C-instance multicast groups: :[Smax/2] where Smax 1194 is maximum number of C-instance groups obtained in test 1195 case 9.3 for Vmax number of mVPNs 1196 e. Ratio of ingress vs. egress C-instance groups: 10%:90% 1197 f. Number of sourced data MDTs (S-PMSIs): 2 1198 g. Number of received data MDTs (S-PMSIs): 8 1200 Test Execution Procedure: 1202 Test will consist of varying number of C-instance flows that will 1203 utilize S-PMSIs, while keeping number of C-instance mroutes and 1204 data MDTs (S-PMSIs) constant. By doing this one can assess impact 1205 of data MDT reuse. 1207 Procedure is as follows: 1209 1. Configure test apparatus such that number of flows using S- 1210 PMSIs is the same as number of S-PMSIs, i.e. there is no S-PMSI 1211 reuse by multiple traffic flows. Execute steps 1-7 in section 1212 7.1 and 1-8 in section 7.2 1214 2. Repeat step 1 for 10*I flows where "i=2…N" where N is integer 1215 value for which either maximum number of flows mapped to data 1216 MDT (S-PMSI) is reached or number of flows becomes equal to 1217 number of (S,G) C-instance mroutes. 1219 For each test case instance perform steps 1-8 from section 7.1. and 1220 1-7 from section 7.2 for all mandatory stimuli in section 7. 1222 Test Result Report: 1224 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1225 all test case instances executed. 1227 9.8 Scale of mVPNs spanning large number of PEs 1229 Test Objective: 1231 As we noted mVPN scale is multidimensional and depends on number of 1232 variables. While test cases 9.1-9.7 focused on only one or two 1233 variables at the time while minimizing impact of all others, they 1234 don't give good representation of platform capabilities in more 1235 realistic deployment scenarios where none of variables are 1236 minimized. Objective of this test case (and test cases 9.8-9.13)is 1237 to assess capabilities of platform in more realistic deployment 1238 scenario. In particular this test case will focus on finding 1239 maximum number of mVPN instances that span large number of PE 1240 routers while they have values for other MVPN variables chosen to 1241 be on the order of magnitude used by MVPN deployments at the time 1242 this draft was written. Specific values are defined in Test Setup 1243 section. 1245 Metric Variables Relationships: 1247 Num_MC_C_ints = 2*Num_mVPN 1249 (Num_*G_C + Num_SG_C)= 30 * Num_mVPN 1251 Num_OIF_C = Num_mVPN = 60 * Num_mVPN 1253 Num_SPMSI_Rx = 8*Num_mVPN 1255 Num_SPMSI_Src = 2*Num_mVPN 1257 Test Setup: 1259 Following test setup MUST be performed prior to executing this test 1260 case 1262 1. S-PMSI (Data MDT)used: YES 1263 2. Multicast Control Plane Profile (all per mVPN except a.; all 1264 from DUT's perspective): 1265 a. Number of MVPNs configured on DUT: varies 1266 b. Number of PIM VPN C-interfaces: 2 1267 c. Number of remote PEs: 500 1268 d. Number of C-instance multicast groups:10 1270 e. Number of data MDTs (S-PMSIs) sourced from DUT:2 1271 f. Number of data MDTs (S-PMSIs) with receivers behind DUT:8 1273 Test Execution Procedure: 1275 This test case SHOULD be repeated for all mechanisms of 1276 instantiating MI-PMSIs (default MDTs) supported by implementer. If 1277 PIM protocol is used all PIM variants(PIM ASM, SSM and Bi-dir) 1278 supported by implementer should be tested. At minimum PIM ASM MUST 1279 be tested. 1281 Refer to 6.4 for guidelines on how many PE routers should be 1282 sending J/P messages for any given ingress C-instance mroute. 1284 Execute number of test case instances where in each test case 1285 instance number of configured mVPNs is varied with the goal of 1286 finding maximum number of mVPNs that platform can support. mVPN 1287 instance here includes C-instance state, OIFs, PIM neighborships 1288 and data MDTs (S-PMSIs) as specified by Test Setup. 1290 For each test case instance perform steps 1-8 from section 7.1. and 1291 1-7 from section 7.2 for all mandatory stimuli in section 7. 1293 Test Result Report: 1295 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1296 at least maximum value of number of mVPNs achieved. It is DESIRED 1297 to include the same data for at least 5 different values of number 1298 of mVPNs (i.e. for at least 5 test case instances). 1300 9.9 Scale of mVPNs with larger amount of state 1302 Test Objective: 1304 Objective of this test case is on finding maximum number of mVPN 1305 instances that contain large number of C-instance PIM state while 1306 they have values for other MVPN variables chosen to be on the order 1307 of magnitude used by MVPN deployments at the time this draft was 1308 written. Specific values are defined in Test Setup section. 1310 Metric Variables Relationships: 1312 Num_MC_C_ints = 2*Num_mVPN 1314 (Num_*G_C + Num_SG_C)= 300 * Num_mVPN 1316 Num_OIF_C = Num_mVPN = 600 * Num_mVPN 1318 Num_SPMSI_Rx = 8*Num_mVPN 1320 Num_SPMSI_Src = 2*Num_mVPN 1322 Test Setup: 1324 Following test setup MUST be performed prior to executing this test 1325 case 1327 1. S-PMSI (Data MDT)used: YES 1328 3.Multicast Control Plane Profile (all per mVPN except a.; all from 1329 DUT's perspective): 1330 a. Number of MVPNs configured on DUT (Num_mVPN) : varies 1331 b. Number of PIM VPN C-interfaces: 2 1332 c. Number of remote PEs: 50 1333 d. Number of C-instance multicast groups:100 1334 e. Number of data MDTs (S-PMSIs) sourced from DUT:2 1335 f. Number of data MDTs (S-PMSIs) with receivers behind DUT:8 1337 Test Execution Procedure: 1339 Same as Test Execution Procedure in 9.8 1341 Test Result Report: 1343 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1344 at least maximum value of number of mVPNs achieved. It is DESIRED 1345 to include the same data for at least 5 different values of number 1346 of mVPNs (i.e. for at least 5 test case instances). 1348 9.10 Scale of "average" size mVPNs 1350 Test Objective: 1352 While test cases 9.12 and 9.13 assess two more extreme deployment 1353 scenarios with respect to number of PE routers and mVPN routes, 1354 objective of this test case is to assess number of mVPNs for the 1355 case where each mVPN represents average size mVPN customer. 1356 Specific values are defined in Test Setup section. 1358 Metric Variables Relationships: 1360 Num_MC_C_ints = 2*Num_mVPN 1362 (Num_*G_C + Num_SG_C)= 100 * Num_mVPN 1364 Num_OIF_C = Num_mVPN = 200 * Num_mVPN 1366 Num_SPMSI_Rx = 8*Num_mVPN 1368 Num_SPMSI_Src = 2*Num_mVPN 1370 Test Setup: 1372 Following test setup MUST be performed prior to executing this test 1373 case 1375 1. S-PMSI (Data MDT)used: YES 1376 3. Multicast Control Plane Profile (all per mVPN except a.; all 1377 from DUT's perspective): 1378 a. Number of MVPNs configured on DUT (Num_mVPN): varies 1379 b. Number of PIM VPN C-interfaces: 2 1380 c. Number of remote PEs: 100 1381 d. Number of C-instance multicast groups:33 1382 e. Number of data MDTs (S-PMSIs) sourced from DUT:2 1383 f. Number of data MDTs (S-PMSIs) with receivers behind DUT:8 1385 Test Execution Procedure: 1387 Same as Test Execution Procedure in 9.8 1389 Test Result Report: 1391 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1392 at least maximum value of number of mVPNs achieved. It is DESIRED 1393 to include the same data for at least 5 different values of number 1394 of mVPNs (i.e. for at least 5 test case instances). 1396 9.11 S-PMSI Switching Delay 1398 Test Objective: 1400 The test objective is to measure the elapsed time for traffic to 1401 start flowing on S-PMSI, i.e., the time from the moment of signaling 1402 of an S-PMSI to the moment when traffic starts flowing on the S-PMSI. 1403 We will refer to this measure as S-PMSI switching delay [S- 1404 PMSI_DELAY]. 1406 Metric Variables Relationships: 1408 Same as for test case 9.10. 1410 Test Setup: 1412 Same as for test case 9.10. 1414 Test Execution Procedure: 1416 Test will measure the time for traffic to start flowing on S-PMSI, 1417 i.e., the time from the moment of signaling of an S-PMSI to the 1418 moment when traffic starts flowing on the S-PMSI on the DUT. This 1419 test MUST be repeated multiple (at least 20) times (for each value 1420 of number of mVPNs) across multi-second intervals in order to 1421 isolate any timing issues. This test MUST be performed with 1422 varying number of average size MVPNs on DUT (up to the maximum) as 1423 defined in the test case 9.10. With a given number of MVPNs on 1424 DUT, the switching delay of several S-PMSIs sourced at the DUT in 1425 different MVPNs will be measured. In case S-PSMI creation is 1426 triggered by rate of C-instance traffic flow, the S-PMSI threshold 1427 should be set to min possible value, depending on the 1428 implementation. Such threshold value used MUST be documented in 1429 the test report. 1431 Test Result Report: 1433 The test results MUST include the range of S-PMSI switching 1434 delays: minimum, average and maximum [S-PMSI_DELAY]. 1435 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1436 at least maximum value of number of mVPNs achieved. It is DESIRED 1437 to include the same data for at least 5 different values of number 1438 of mVPNs (i.e. for at least 5 test case instances). 1440 9.12 Convergence of C-Instance PIM Joins 1442 Test Objective: 1444 The test objective is to measure how long it takes for the first 1445 receiver on the DUT, issuing C-instance PIM (*,G) Join, to receive 1446 the traffic from already active C-instance source (S,G). 1448 Metric Variables Relationships: 1450 Same as for test case 9.14. 1452 Test Setup: 1454 Same as in test case 9.14 1456 Test Execution Procedure: 1458 Test will consist of an active C-instance source (S,G) attached 1459 to/behind a remote PE (PE2 in Topology #1). There will be at least 1460 one active C-instance receiver of (*,G) behind this remote PE 1461 (PE2). This setup ensures that C-instance PIM Register procedure 1462 for (S,G) has been completed and that there are no receivers 1463 across the core network. With this initial setup, the test will 1464 add one C-instance (*,G) receiver attached to DUT and issuing PIM 1465 (*,G) Join towards the DUT. The test will measure the time 1466 for traffic from (S,G) behind the remote PE to be received by 1467 (*,G) receiver behind the DUT. This test MUST be repeated multiple 1468 (at least 10) times in order to isolate any timing issues. This 1469 test MUST be performed with varying number of average size MVPNs 1470 (up to the maximum) as defined in the test case 9.14. 1472 Test Result Report: 1474 The test results MUST include the range of C-instance PIM (*,G) 1475 Join convergence times: minimum, average, maximum. 1476 Data listed in 8.1 and 8.2 MUST be reported in tabular format for at 1477 least maximum value of number of mVPNs achieved. It is DESIRED to 1478 include the same data for at least 5 different values of number of 1479 mVPNs (i.e. for at least 5 test case instances). 1481 9.13 Effect of Co-locating C-RPs on a PE 1483 Test Objective: 1485 The test objective is to assess scaling impact of SP hosting 1486 customer's RPs (C-RPs) on PE router. This is the optional 1487 deployment model as stated in [MVPN-REQ] and is deployed today by 1488 number of service providers. Only difference between test cases 1489 9.10 and 9.13 is location of C-RP; thus by comparing test results 1490 of 9.10 and 9.13 one will be able to determine additional impact 1491 co-locating RP has on PE scale compared to deployment model of 1492 customers hosting their own RPs. 1494 Metric Variables Relationships: 1496 Same as in 9.10. 1498 Test Setup: 1500 Same as in 9.10, except for placing C-instance RPs on DUT. 1501 Test Execution Procedure: 1503 This test case SHOULD be repeated for all mechanisms of 1504 instantiating MI-PMSIs (default MDTs) supported by implementer. If 1505 PIM protocol is used all PIM variants(PIM ASM, SSM and Bi-dir) 1506 supported by implementer should be tested. At minimum PIM ASM MUST 1507 be tested. 1509 Refer to 6.4 for guidelines on how many PE routers should be 1510 sending J/P messages for any given ingress C-instance mroute. 1512 Execute number of test case instances where in each test case 1513 instance number of configured mVPNs is varied with the goal of 1514 finding maximum number of mVPNs that platform can support in this 1515 environment. mVPN instance here includes C-instance state, OIFs, 1516 PIM neighborships and data MDTs (S-PMSIs) as specified by Test 1517 Setup. 1519 For each test case instance perform following steps: 1521 a. Steps 1-4 from section 7.1. 1523 b. Send PIM Register messages from all "source" test apparatus 1524 ports 1526 c. Test apparatus should verify that correct (S,G) PIM Join 1527 messages had been received by "source" test apparatus port. 1528 In reaction to receipt of (S,G) joins, source test 1529 apparatus ports should start transmitting multicast traffic 1530 to appropriate multicast groups and start sending Data- 1531 header Registers [RFC4601]. 1533 d. Steps 6-8 from section 7.1. 1535 For all mandatory stimuli defined in section 7 perform following 1536 steps: 1538 a. Steps a-d from paragraph above 1540 b. Steps 2-7 from section 7.2 1542 Test Result Report: 1544 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1545 at least maximum value of number of mVPNs achieved. It is DESIRED 1546 to include the same data for at least 5 different values of number 1547 of mVPNs (i.e. for at least 5 test case instances). 1549 10 Test Cases Specific to PIM PE-PE signaling 1551 Test cases in this section are applicable only to MVPN architectures 1552 which use PIM protocol for PE-PE transmission of C-Multicast routing 1553 information, such as "ROSEN-8" architecture. 1555 10.1 PIM Neighborships Scale 1557 Test Objective: 1559 To determine maximum number of PIM C-instance neighborships across 1560 MI-PMSIs that PE router can create and maintain. Amount of most of 1561 other MVPN Metric such as C-instance multicast routes is minimized 1562 in this test case. 1564 Metric Variables Relationships: 1566 Num_MC_C_ints = Num_PIM_C_neigh = Num_mVPN 1568 Num_*G_C = Num_SG_C = 2*Num_mVPN 1570 Num_OIF_C = 4*Num_mVPN 1572 Test Setup: 1574 Following test setup MUST be performed prior to executing this test 1575 case 1577 1. Protocol for MI-PMSI P-instance PIM groups (if PIM used): ASM or 1578 Bi-dir 1579 2. S-PMSI (Data MDT) used: NO 1580 4. Multicast Control Plane Profile (all per mVPN except a.; all 1581 from DUT's perspective): 1582 a. Number of MVPNs configured on DUT (Num_mVPN): varies 1583 b. Number of remote PEs: varies 1584 c. Number of C-instance multicast groups : 2 1585 d. Ratio of ingress vs. egress C-instance groups: 50%:50% 1587 Test Execution Procedure: 1589 Number of C-instance PIM neigborships across MI-PMSIs is 1590 proportional to product of number of mVPNs DUT belongs to and 1591 average number of PEs belonging to the same mVPNs. 1593 Test will consist of finding maximum number of C-instance PIM 1594 neighborships across MI-PMSIs by varying average number of PEs per 1595 mVPN for set of fixed values of number of mVPNs. Procedure is as 1596 follows: 1598 1. Configure 100 mVPNs on DUT. Execute number of test case 1599 instances where in each test case instance number of PE routers 1600 belonging to each mVPN is varied until maximum number of such 1601 PEs is found. All mVPNs should have same number of PE routers. 1603 2. Repeat step 1 for 100*I mVPNs where "i=2…N" where N is integer 1604 value for which either maximum number of PEs per mVPN becomes 1605 smaller than one or maximum number of mVPNs found in test case 9.1 1606 is reached. 1608 For each test case instance perform steps 1-8 from section 7.1. and 1609 1-7 from section 7.2 for all mandatory stimuli in section 7. 1611 Test Result Report: 1613 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1614 at least maximum value of average number of PEs for every tested 1615 value of number of mVPNs per PE (Num_mVPN). It is DESIRED to 1616 include the same data for at least 5 different values of number of 1617 PEs for each of tested values of number of mVPNs per PE(i.e. for at 1618 least 5 test case instances per each tested value of number of 1619 mVPNs). 1621 10.2 PIM C-instances J/P Suppression Effectiveness 1623 Test Objective: 1625 If PIM is used as PE-PE signaling, optional feature of PIM J/P 1626 Suppression is performed by all PE devices that have receivers behind 1627 them (refer to such PE as egress PE). Goal of this test case is to 1628 assess capability of egress PE to perform C-instance J/P suppression 1629 for large amount of C-instance multicast routes. 1631 Metric Variables Relationships: 1633 Num_MC_C_ints = Num_mVPN 1635 (Num_*G_C + Num_SG_C)>> Num_mVPN 1637 Num_OIF_C >> Num_mVPN 1639 Test Setup: 1641 Following test setup MUST be performed prior to executing this test 1642 case 1643 1. Topology: 1645 ________ _________ ________ 1646 / \ / \ / \ 1647 | |R1 | (DUT) |D2 | (RR) | 1648 | Rx1 |====| PE1 |====| P | 1649 | | D1| | B1| | 1650 \________/ \_________/ \________/ 1651 || 1652 || ____________ _______ 1653 || / \ / \ 1654 || | (Emulated) |B3 | | 1655 ++=====| PE2 |====| Src | 1656 || B2| | B4| | 1657 || \____________/ \_______/ 1658 || 1659 || ____________ _______ 1660 || / \ / \ 1661 || | (Emulated) |B6 | | 1662 ++=====| PE3 |====| Rx2 | 1663 B5| | B7| | 1664 \____________/ \_______/ 1666 1. Protocol for MI-PMSI P-instance PIM groups (if PIM used):ASM or 1667 Bi-dir 1668 2. S-PMSI (Data MDT)used: NO 1669 3. Multicast Control Plane Profile (all per mVPN except a.; all 1670 from DUT's perspective): 1671 a. Number of MVPNs (Num_mVPN) configured on DUT (Num_mVPN): 1672 varies 1673 b. Number of PIM VPN C-interfaces: 1 1674 c. Number of remote PEs: 2 1675 d. Ratio of ingress vs. egress C-instance groups: 0%:100% 1677 Test Execution Procedure: 1679 For maximum number of C-instances multicast routes obtained in test 1680 case 9.3 for 100 mVPNs and 100% C-instance mroutes in egress 1681 direction perform following: 1683 1) Establish all PIM sessions required to emulate defined 1684 topology 1686 2) Perform all C-instance PIM joins from "Rx2" (test 1687 apparatus port B5 in topology diagram) 1689 3) Start all traffic from "Src" (test apparatus port R1 in 1690 topology diagram) and wait until steady state is 1691 achieved. 1693 4) On C-instance PIM session used for PE-PE signaling of 1694 test apparatus port "Src" (B2) measure number of C- 1695 instance J/Ps received in 10 minute (J1) interval and 1696 calculate rate of J/Ps as JR1=J1/(60*10). 1698 5) Perform all C-instance PIM joins from test apparatus port 1699 "Rx1" (R1) and wait until steady state is achieved on 1700 DUT. 1702 6) On C-instance PIM session used for PE-PE signaling of 1703 test apparatus port "Src" (B2) measure number of C- 1704 instance J/Ps received in 10 minute (J2) interval and 1705 calculate rate of J/Ps as JR2=J2/(60*10). 1707 7) If JR2 < 1.2*JR1 we can conclude that DUT is suppressing 1708 J/P messages successfully. 1710 Repeat steps 1-7, for maximum number of C-instances multicast routes 1711 obtained in test case 9.3 for maximum number of mVPN and 100% state 1712 in egress direction. 1714 Note that no failure recovery testing is required in this test case. 1716 Test Result Report: 1718 Data listed in 8.1 MUST be reported in tabular format for all test 1719 case instances. In addition rates JR1 and JR2 MUST be reported. 1720 Optionally one can report absolute numbers or rates of number of 1721 PIM J/P PDUs transmitted by DUT and PE3 (test apparatus port B5). 1723 11 Test Cases Specific to PIM MI-PMSI trees 1725 Test cases in this section are applicable only to MVPN architectures 1726 which use PIM protocol to create 'tunnels' that instantiate MI-PMSIs 1727 and optional S-PMSIs, such as "ROSEN-8" architecture. 1729 11.1Default MDT's (MI-PMSI's) PIM P-Instance Mroutes Scale 1731 Test Objective: 1733 To determine maximum number of mVPNs and PE routers per mVPN when 1734 PIM P-instance is using protocol variant that generates maximum 1735 amount of PIM P-instance mroutes. Amount of most of other MVPN 1736 Metric such C-instance multicast mroutes is minimized in this test 1737 case. 1739 Metric Variables Relationships: 1741 Num_MC_C_ints = Num_mVPN 1743 Num_*G_C = Num_SG_C = 2*Num_mVPN 1745 Num_OIF_C = 4*Num_mVPN 1747 Test Setup: 1749 Following test setup MUST be performed prior to executing this test 1750 case 1752 1. Protocol for MI-PMSI P-instance PIM groups: SSM 1753 2. S-PMSI (Data MDT) used: NO 1754 3. Multicast Control Plane Profile (all per mVPN except a.; all 1755 from DUT's perspective): 1756 a. Number of MVPNs configured on DUT (Num_mVPN): varies 1757 b. Number of remote PEs: varies 1758 c. Number of C-instance multicast groups : 2 1759 d. Ratio of ingress vs. egress C-instance groups: 50%:50 1761 Test Execution Procedure: 1763 Amount of PIM P-instance mroutes on PE router created by default 1764 MDTs (MI-PMSIs) depends in general on choice of PIM protocol 1765 variant, number of mVPNs and average number of PE routers per mVPN. 1766 In order to assess the impact of PIM P-instance mroutes created by 1767 MVPN default MDTs (MI-PMSIs) has on resources, test case 10.1 will 1768 be repeated with changing PIM P-instance protocol mode to SSM. Note 1769 that test cases 9.1-9.7 and 10.1-2 use Bi-dir PIM or PIM-SM (ASM) 1770 with SPT threshold of infinity in order to minimize impact PIM P- 1771 instance mroutes has on resources while focusing on characterizing 1772 other variables described in test cases 9.1-9.7 and 10.1-2. 1774 Test Result Report: 1776 Data listed in 8.1 and 8.2 MUST be reported in tabular format for 1777 at least maximum value of average number of PEs for every tested 1778 value of number of mVPNs per PE. It is DESIRED to include the same 1779 data for at least 5 different values of number of PEs for each of 1780 tested values of number of mVPNs per PE(i.e. for at least 5 test 1781 case instances per each tested value of number of mVPNs). 1783 12 Security Considerations 1785 Documents of this type do not directly affect the security of 1786 the Internet or of corporate networks as long as benchmarking 1787 is not performed on devices or systems connected to operating 1788 networks. 1790 13 IANA Considerations 1792 This document requires no IANA considerations. 1794 14 Acknowledgments 1796 We would like to thank Aamer Akhter, Arjen Boers, Yiqun Cai, Min Li, 1797 Amal Maalouf, Mike McBride, Ciprian Popoviciu, Dan Williston, Rajiv 1798 Asati and Thomas Morin for their valuable feedback on content of this 1799 draft. We would like to thank Nick Satsia for his support with test 1800 verification of this draft. 1802 15 References 1804 15.1 Normative References 1806 [MVPN-REQ] T. Morin, Ed., "Requirements for Multicast in L3 Provider- 1807 Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts-09.txt 1809 [L3VPN-MCAST] E. Rosen, R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", 1810 draft-ietf-l3vpn-2547bis-mcast-03.txt 1812 [RFC4364] E.Rosen, Y. Rekhter, ''BGP/MPLS IP Virtual Private Networks 1813 (VPNs)'' 1815 [RFC4601] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, ''Protocol 1816 Independent Multicast - Sparse Mode (PIM-SM):Protocol Specification'' 1818 15.2 Informative References 1820 [ROSEN-8] E. Rosen, Y. Cai, I. Wijnands, "Multicast in MPLS/BGP IP 1821 VPNs", draft-rosen-vpn-mcast-08.txt 1823 [MVPN-BCP] Y. Cai, M. McBride, C. Hall, M. Napierala, ''Multicast VPN 1824 Deployment Recommendations'', draft-ycai-mboned-mvpn-deploy-00.txt 1825 Author's Addresses 1827 Silvija A. Dry 1828 Cisco 1829 7025 Kit Creek Rd. 1830 Research Triangle Park, NC 27709 1831 sdry@cisco.com 1833 Fernando Calabria 1834 Cisco 1835 7025 Kit Creek Rd. 1836 Research Triangle Park, NC 27709 1837 fcalabri@cisco.com 1839 Maria Napierala 1840 AT&T 1841 200 Laurel Avenue 1842 Middletown, NJ 07748 1843 mnapierala@att.com 1845 Yuji Kamite 1846 NTT Communications 1847 Tokyo Opera City Tower 1848 3-20-2 Nishi Shinjuku, Shinjuku-ku 1849 Tokyo 163-1421 1850 Japan 1851 y.kamite@ntt.com 1853 Ian Yee Yan Fung 1854 Cisco Systems, Inc. 1855 ifung@cisco.com 1857 Intellectual Property Statement 1859 The IETF takes no position regarding the validity or scope of any 1860 Intellectual Property Rights or other rights that might be claimed to 1861 pertain to the implementation or use of the technology described in 1862 this document or the extent to which any license under such rights 1863 might or might not be available; nor does it represent that it has 1864 made any independent effort to identify any such rights. Information 1865 on the procedures with respect to rights in RFC documents can be 1866 found in BCP 78 and BCP 79. 1868 Copies of IPR disclosures made to the IETF Secretariat and any 1869 assurances of licenses to be made available, or the result of an 1870 attempt made to obtain a general license or permission for the use of 1871 such proprietary rights by implementers or users of this 1872 specification can be obtained from the IETF on-line IPR repository at 1873 http://www.ietf.org/ipr. 1875 The IETF invites any interested party to bring to its attention any 1876 copyrights, patents or patent applications, or other proprietary 1877 rights that may cover technology that may be required to implement 1878 this standard. Please address the information to the IETF at 1879 ietf-ipr@ietf.org. 1881 Copyright Statement 1883 Copyright (C) The IETF Trust (2007). 1885 This document is subject to the rights, licenses and restrictions 1886 contained in BCP 78, and except as set forth therein, the authors 1887 retain all their rights. 1889 This document and the information contained herein are provided on 1890 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1891 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1892 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1893 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1894 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1895 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1896 FOR A PARTICULAR PURPOSE. 1898 Acknowledgment 1900 Funding for the RFC Editor function is currently provided by the 1901 Internet Society.