idnits 2.17.1 draft-hegde-rtgwg-virtual-multi-instance-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 'SHOULD not' in this paragraph: Routes from one virtual instance SHOULD not be leaked into each other unless explicitly configured to do so via local policies. By default, routes from default instance MUST NOT be leaked into the virtual instances. -- The document date (March 21, 2016) is 2957 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) ** Obsolete normative reference: RFC 6822 (Obsoleted by RFC 8202) == Outdated reference: A later version (-11) exists of draft-ietf-isis-node-admin-tag-08 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing area S. Hegde 3 Internet-Draft Salih. K.A 4 Intended status: Standards Track Juniper Networks 5 Expires: September 22, 2016 M. Venkatesan 6 Comcast 7 R. Callon 8 A. Atlas 9 Juniper Networks 10 March 21, 2016 12 Virtual multi-instancing for link state protocols 13 draft-hegde-rtgwg-virtual-multi-instance-01 15 Abstract 17 In networks with routers of different capabilities, some routers may 18 not be able to participate fully in supporting new features or 19 handling large databases and the associated flooding. In some cases, 20 these restrictions can cause severe scalability issues for the 21 network in general. This document proposes virtual multi-instances, 22 a generic mechanism for OSPF and IS-IS, that allows groups of routers 23 in specific topologies to have a reduced database and reduces the 24 topology changes that are seen. The virtual multi-instances are 25 specified so that no software or protocol changes are required in the 26 restricted routers. Due to the potential number of virtual multi- 27 instances in a network, the configuration is limited and is not 28 specified per virtual instance. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 22, 2016. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Problem Description . . . . . . . . . . . . . . . . . . . . . 4 72 2.1. Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1.1. Load on Spoke routers . . . . . . . . . . . . . . . . 4 74 2.1.2. Customer Routers Causing Frequent SPFs . . . . . . . 5 75 2.1.3. Mixture of Capabilities between Routers . . . . . . . 5 76 3. Topology Restrictions . . . . . . . . . . . . . . . . . . . . 5 77 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8 78 4.1. Identification into Virtual Instances or Virtual Areas . 8 79 4.2. Route Redistribution . . . . . . . . . . . . . . . . . . 9 80 4.3. Avoiding Transit Traffic . . . . . . . . . . . . . . . . 10 81 4.4. Including Hub-to-Hub Links for Ring LSDBs . . . . . . . . 10 82 4.5. Hierarchical Virtual Multi-Instance . . . . . . . . . . . 10 83 4.6. Dynamic shortcut Tunnels . . . . . . . . . . . . . . . . 11 84 5. Hub Router Behavior . . . . . . . . . . . . . . . . . . . . . 11 85 5.1. Classification into an Virtual Instance/Area . . . . . . 11 86 5.2. Generating Router LSA/LSPs and Default Routes for Virtual 87 Instances . . . . . . . . . . . . . . . . . . . . . . . . 12 88 5.3. SPF computations and Route Preference . . . . . . . . . . 12 89 6. Manageability considerations . . . . . . . . . . . . . . . . 12 90 7. Backward compatibility . . . . . . . . . . . . . . . . . . . 13 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 96 11.2. Informative References . . . . . . . . . . . . . . . . . 14 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 99 1. Introduction 101 A router that participates in OSPF or IS-IS must be capable of 102 handling the entire link state database (LSDB) for the areas or 103 levels that router participates in. In OSPF, this can be mitigated 104 by creating small or stub areas, but such areas must still be 105 configured. In IS-IS, regardless of area address, there can be only 106 a single Level 1. The need to handle the entire LSDB as well as all 107 functionality required in that area or level poses a difficulty for 108 networks that have routers with limited functionality or resources. 110 In Section 2, the specific problems motivating a solution are 111 discussed. These problems derive from a mixture of operational 112 concerns around configuration, equipment with limited resources, 113 networks with growing numbers of routers, and enhancements in the 114 IGPs that may be needed to support some services but that can't be 115 supported by deployed equipment. 117 The proposed solution is termed virtual multi-instances because the 118 hub router (termed from a motivating hub-and-spoke topology) is 119 configured to dynamically treat a neighbour's LSP or LSA as belonging 120 to a particular instance, that may be created and deleted on demand. 121 For OSPF, that virtual instance may instead be treated as a virtual 122 area. The hub router automatically creates the virtual instance, 123 distributes a default route into the virtual instance, may advertise 124 specific links into the virtual instance, and redistributes 125 optionally summarized routes learned from that virtual instance. 126 Although the solution does not require any extension to existing 127 protocol standards, the redistribution behaviour should be followed 128 by hub routers for each of the topologies and hence the need for 129 standardization of this solution. 131 The topologies to which virtual multi-instances can be applied are 132 restricted. In Section 3, the three different types of topologies 133 are described with different behaviour for route redistribution, 134 leaking of hub to hub links into the virtual instance, and ensuring a 135 single hub router LSA/LSP announcement into the virtual instance/ 136 area. The virtual instance or area is distinguished based upon the 137 hub router's and neighbour's Router-ID or system-id or upon the 138 neighbour's specified area-id. An overview of the solution is given 139 in Section 4. 141 In Section 5, the specific procedures that a hub router must follow 142 to use virtual multi-instances are defined. Because this solution is 143 intended to be low-touch to ease manageability, the suggested 144 configuration aspects are described in Section 6. In Section 8, the 145 potential security benefits of reducing network visibility and using 146 different instances are briefly discussed. 148 2. Problem Description 150 Hub-and-Spoke topologies are increasingly being used at large scale. 151 Due to the scale and to improve routing between spokes, dynamic 152 tunnels between spokes can be established and torn-down on-demand 153 based on traffic flow. Particularly when combined with routers that 154 have limited resources and low-feature implementations of IS-IS or 155 OSPF, these topologies causes real issues in existing networks as 156 described in Section 2.1. 158 In a hub-and-spoke network, each spoke in the same area unnecessarily 159 learns the link information of the other spokes. This extra 160 information not only grows the size of the LSDB but also causes 161 additional information flooding with associated SPFs. In OSPF, 162 spokes can be separated into different areas but this comes with 163 configuration overhead and can waste IP addresses, since a different 164 IP address is required per interface per area it is used in. In IS- 165 IS, because there is only one L1 domain, the only way to create 166 separated domains is to have separate L1L2 routers for each domain. 167 While [RFC7356] defines different flooding scopes for IS-IS, the 168 changes are not backwards compatible and how the information would be 169 properly processed for basic routing is not defined. In a network, 170 it is rarely feasible to have multiple L1L2 routers in the same 171 geographic area simply to separate the flooding domains. 173 To provide improved routing between spokes, the ability to establish 174 and tear down dynamic tunnels between spokes on-demand is defined in, 175 for instance, "Auto Discovery VPN Protocol" 176 [I-D.sathyanarayan-ipsecme-advpn]. A huge number of dynamic tunnels 177 can badly impact the scaling of a link-state protocol. At the same 178 time, these on-demand tunnels can't require configuration overhead to 179 separate them into different areas. 181 2.1. Issues 183 2.1.1. Load on Spoke routers 185 As discussed, containing a hub-and-spoke network inside a single area 186 means that all routers carry the full LSDB for the area. This can 187 overload limited-capability routers or non-router devices that are 188 frequently used as spoke routers. The use of a limited-capability 189 router can thus constrain the size of the area. 191 High Internet traffic growth requires a high number of link and node 192 updates in metro networks. The number of IP prefixes processed in LS 193 databases increases, causing longer SPF calculations. Though modern 194 routers have high CPUs and better resources for faster SPF 195 calculations, non-router devices typically have limited resources for 196 processing. The size of the LSDB and frequency of SPFs is a problem 197 for non-router devices participating in the routing protocol. 199 2.1.2. Customer Routers Causing Frequent SPFs 201 In some cases, service-provider-managed CPEs may participate in the 202 link state routing protocol to advertise their connected and loop- 203 back interfaces for end-to-end connectivity. Power cycles and device 204 failure of CPEs can trigger updates to and SPF calculations on all 205 routers in the domain or area. Isolation of the CPEs from uninvolved 206 routers is desirable. 208 2.1.3. Mixture of Capabilities between Routers 210 A metro L1 network supports many different customers and services, 211 but the inclusion of non-router devices (such as cable modem 212 termination systems, video edge devices, voice soft switches, etc.) 213 that participate in the link state protocol may severely limit the 214 ability to provide those different services and abilities. 216 A non-router device typically just gets its default route from the 217 upstream L1L2 routers for outbound traffic. While that meets the 218 requirements of the non-router device, the inability of such devices 219 to support all IS-IS features (e.g. multi-topology) means that the 220 whole Metro L1 network can't support those features. 222 It may not be reasonable or economical to request the implementation 223 of such features on a non-router device that has no need to use them. 224 A solution is required that can support both non-router devices with 225 limited routing protocol features and core network devices with 226 complete routing features. This will allow the Metro L1 network to 227 provide diversified services to different customers. 229 3. Topology Restrictions 231 The issues discussed in Section 2 centre on issues around hub-and- 232 spoke topologies. In the simplest case, each spoke is connected to a 233 single hub router as shown in Figure 1. To provide resiliency, a 234 spoke may be connected to two or more hub routers, as shown in 235 Figure 2. Since normal link state routing is performed between the 236 hub and the spoke, the spoke does not need to be a single router, but 237 could be a small connected group of routers operating as an IS-IS 238 (level 1) or OSPF area as long as only one among the group of routers 239 connects to the hub router. 241 +-------+ 242 | Hub 1 | 243 +-------+ 244 / | \ 245 / | \ 246 +---+ | +---+ 247 |A_1| | |C_1| 248 +---+ | +---+ 249 / \ +---+ | 250 / | | B | +---+ 251 / | +---+ |C_2| 252 +---+ +---+ +---+ 253 |A_2|-|A_3| 254 +---+ +---+ 256 Figure 1: Different spokes connected to a single Hub 258 +---------+ +---------+ 259 | Hub_1 | | Hub_2 | 260 +---------+ +---------+ 261 | \ / | 262 | \ / | 263 +-----+ X +-----+ 264 | A_1 | --/ \--| B_1 | 265 +-----+ +-----+ 266 / \ 267 +---+ +---+ 268 |A_2|-|A_3| 269 +---+ +---+ 271 Figure 2: Spokes connected to two Hubs 273 When there are a huge number of spoke routers, the spokes may be 274 connecting to set of hubs which in turn connect to a hub at the 275 higher level making a hierarchical hub and spoke.It is possible to 276 use virtual multi-instances hierarchically so that a spoke may itself 277 have spokes or rings that have been summarized. 279 Increased deployments of hub and spoke topologies has lead to 280 improved routing requirements between the spokes. A typical 281 enterprise network with branch offices connecting to head office is 282 usually deployed using IPSEC VPNs. The Figure 4 shows dynamic tunnel 283 topology where A and B are spoke routers and a tunnel is created/ 284 teared-down between them on-demand. The handling of a dynamic tunnel 285 in a virtual instance is slightly different from how a spoke or ring 286 topology is handled; this is to avoid route redistribution beyond the 287 two ends of the dynamic tunnel. 289 Another common topology is to have rings that connect to two hub 290 routers, which are themselves directly connected; this is shown in 291 Figure 3; it is possible for additional routers to be connected to 292 the basic ring as shown in ring F. To support ring topologies, the 293 two hub-connecting routers are identified as belonging to the same 294 instance, as described in Section 5 and Section 6. The necessity for 295 this static configuration is what makes it unsuitable for use with 296 dynamic tunnels connecting spokes. 298 +-----+ +-----+ 299 | G_1 |---| G_2 | 300 +-----+ +-----+ 301 \ / 302 +---------+ +---------+ 303 | Hub_1 |---| Hub_2 | 304 +---------+ +---------+ 305 | | | | 306 | +-----+ +-----+ | 307 | | E_1 |--| E_2 | | 308 | +-----+ +-----+ | 309 | | 310 +-----+ +-----+ +-----+ +-----+ 311 | F_1 |-| F_2 | -| F_5 |-| F_6 | 312 +-----+ +-----+ +-----+ +-----+ 313 | | 314 +-----+ +-----+ 315 | F_3 |-----| F_4 | 316 +-----+ +-----+ 318 Figure 3: Rings connected to one or two Hubs 320 +-------+ 321 | Hub 1 | 322 +-------+ 323 / \ === is dynamic tunnel 324 / \ 325 +---+ +---+ 326 | A |=======| B | 327 +---+ +---+ 329 Figure 4: Dynamic tunnel connecting single-node spokes 331 4. Solution Overview 333 This document defines virtual multi-instances, which is a mechanism 334 to dynamically create and destroy virtual instances or virtual areas. 335 A similar result can be obtained by creating virtual stub areas in 336 OSPF rather than virtual instances. Whether to create virtual 337 instance or virtual area is an implementation choice. 339 It is well defined for OSPF and IS-IS how multiple instances can run 340 across a single interface (see [RFC6549] and [RFC6822]) but to 341 support multiple instances in this general case, an instance-id is 342 required in the messages to distinguish which instance is intended. 343 This also requires that all routers in the non-default instance 344 support the extensions. Virtual multi-instances removes the 345 requirement to include the instance-id by both restricting topology 346 and using router-id/system id or area address as keys to distinguish 347 the instances. 349 By isolating spokes, rings and dynamic tunnels into their own virtual 350 instances, this solution provides isolation for spokes, avoids large 351 LSDBs and, except for handling dynamic tunnels, the need for spoke 352 routers to implement additional features in the IGP. The 353 configuration can be independent of the number of interfaces 354 affected. 356 4.1. Identification into Virtual Instances or Virtual Areas 358 There are three different basic types of topologies supported - 359 spoke-based, ring-based and dynamic-tunnel based. A hub router will 360 be configured to know that virtual multi-instance should apply to a 361 set of interfaces and the topology the interfaces correspond to. 362 When an IGP peer is connected via one of those interfaces, the hub 363 router determines the associated instance and, if necessary, creates 364 it. When the last IGP peer disconnects from a virtual instance, the 365 hub router can delete the associated instance. If an IGP peer has a 366 spoke-based or dynamic-tunnel based topology, then the associated 367 virtual instance is identified by the (hub router router-id/system- 368 id, IGP peer router-id/system-id). 370 In OSPF, it is possible to configure rings as separate stub areas. 371 This requires that all routers in the stub area be configured with 372 the specific and unique area address. In IS-IS, it is not possible 373 to have multiple separate (having separate flooding domain) L1 areas 374 connecting to the same L1/L2 router. For virtual multi-instance to 375 support ring topologies, a router that connects to the hub must be 376 configured with an area address. If multiple routers in the same 377 ring connect to the same hub (routers G_1 and G_2 in Figure 3), then 378 all those and only those routers must be configured with the same 379 area address. The hub will create a virtual instance or virtual area 380 that is identified by the area address. The hub router does not need 381 to have the area address configured on the set of interfaces to which 382 virtual multi-instance applies. If a single router in a ring 383 connects to a given hub (routers E_1, E_2, F_1, and F_6 in Figure 3, 384 then that router may be configured with a special area address 385 UNIQUE_RING_AREA_ADDRESS (well-known or explicitly configured) and 386 the hub will create a virtual instance or virtual area that is 387 identified by (hub router router-id/system-id, IGP peer router-id/ 388 system-id) but is marked as a ring topology. Virtual instances/areas 389 that are ring topologies will have hub-to-hub links advertised into 390 them. 392 A router may be connected to a hub via multiple links due to 393 redundancy or to provide sufficient bandwidth. Because a virtual 394 instance is identified by either (hub router router-id/system-id, IGP 395 peer router-id/system-id) or an area address, the multiple IGP 396 adjacencies formed across the parallel links will be in the same 397 instance. 399 4.2. Route Redistribution 401 The route redistribution for virtual instances containing a dynamic 402 tunnel is different than that for virtual instances with spoke or 403 ring topologies. For a virtual instance with a dynamic tunnel, only 404 the ends of the dynamic tunnel should learn about the prefixes in the 405 virtual instance. This is to prevent traffic from routing down a 406 spoke and across the dynamic tunnel in order to reach the a 407 destination on the other spoke. A router at the end of a dynamic 408 tunnel 410 o MUST NOT advertise a default route into 412 o SHOULD redistribute its own prefixes into 414 o MAY redistribute non-default prefixes from only its default 415 instance into 417 o SHOULD NOT redistribute prefixes out of 419 the associated virtual instance/area. 421 For spoke and ring topologies, the hub router is responsible for 422 providing a default route into the virtual instance and for 423 redistributing the routes learned from a virtual instance into the 424 default instance. A hub router connected to a spoke or ring topology 426 o MUST advertise a default route into 427 o by default, MUST advertise reachability to the addresses that are 428 learned from 430 o before exporting into the default instance, MAY summarize routes 431 from 433 o by default, MUST NOT leak routes from the default instance into 435 the associated virtual instance/area. 437 Routes from one virtual instance SHOULD not be leaked into each other 438 unless explicitly configured to do so via local policies. By 439 default, routes from default instance MUST NOT be leaked into the 440 virtual instances. 442 4.3. Avoiding Transit Traffic 444 Via each virtual instance that is connected to two hubs, a hub router 445 will see a topology to reach the other hub router. However, transit 446 traffic sent via spokes SHOULD be avoided. After the hub router has 447 completed its SPFs in each virtual instance/area as well as any non- 448 virtual instances, the hub router must determine which route is 449 preferred. Routes learned via a non-virtual instance MUST be 450 preferred over routes learned via a virtual instance/area. 452 4.4. Including Hub-to-Hub Links for Ring LSDBs 454 Rings that include two hubs usually also need to see the link between 455 the two hubs in their LSDB. This provides redundancy and the 456 possibility of fast-reroute techniques. The link between the hubs is 457 in the default instance. The hub-to-hub links will be advertised by 458 a hub router into all virtual instances/areas that are known to have 459 a ring topology. A hub router can identify other hub routers either 460 by configuration or by using determining other routers with the 461 appropriate node admin tag (see [I-D.ietf-ospf-node-admin-tag] and 462 [I-D.ietf-isis-node-admin-tag]) in the default instance. 464 4.5. Hierarchical Virtual Multi-Instance 466 When considering the use of tunnels to connect spokes towards a hub, 467 it is possible for hub-and-spoke topologies to scale extremely high. 468 To reduce the load on particular hubs, it may be useful to consider 469 topologies that include hierarchy so that a spoke router could act as 470 a hub for several remote spokes. Since the spoke router is 471 deliberately unaware that its default instance is being treated as a 472 virtual instance, there are no additional requirements on a router 473 supporting virtual multi-instance. 475 4.6. Dynamic shortcut Tunnels 477 As previously discussed (see Section 2), virtual multi-instances need 478 to handle large numbers of dynamic tunnels being created and removed. 479 By way of an example, consider Figure 1 where router A_2 has a 480 dynamic tunnel created to C_2. Router A_2 will create a virtual 481 instance (A_2, C_2) and may redistribute the prefixes associated with 482 C_2, C_1, and Hub_1 into A_2's default instance. Similarly, C_2 will 483 create a virtual instance (C_2, A_2) and may redistribute the 484 prefixes associated with A_1, A_2, A_3, and Hub_1. 486 Treating a dynamic tunnel as a virtual instance is how dynamic 487 tunnels need to be handled to avoid multiple different LSAs from the 488 same hub router being seen by routers in the connected spokes. 489 Supporting dynamic tunnels does require that router-ends of the 490 dynamic tunnel router support the virtual multi-instance 491 functionality as a hub. There are specific different rules for 492 handling route redistribution (see Section 4.2 for a virtual instance 493 that contains a dynamic tunnel. 495 In a common topology such as shown in Figure 4, the two spokes each 496 contain a single router A or B and those routers are connected by a 497 dynamic tunnel. In some deployments, it is likely that all 498 connections from router A are sub interfaces across a single 499 interface and that single interface is configured for the "dynamic 500 tunnel topology". In that case, A may treat both the dynamic tunnel 501 to B and the connection to Hub_1 as separate virtual instances and 502 follow the route redistribution rules for the "dynamic tunnel 503 topology" for both. Hub_1 can treat A as being in a "spoke topology" 504 and thus redistribute the needed default route in and redistribute 505 the routes learned from A. This combination will provide the correct 506 behaviour. 508 5. Hub Router Behavior 510 5.1. Classification into an Virtual Instance/Area 512 A received hello, LSupdate or LSP packet needs to be classified as to 513 which instance it belongs to. The following describes how a Hub 514 Router MUST do this classification. 516 1. Was the LSP/LSA received on an interface configured for virtual 517 multi-instance? If no, select default instance or instance-id in 518 packet and exit. 520 2. Was the LSP/LSA received on an interface configured for ring 521 topology? If yes, goto (4). 523 3. Assign to instance or area identified by (hub router-id/system- 524 id, IGP peer source router-id/system-id) and exit. 526 4. Is the Area ID in the packet the UNIQUE_RING_AREA_ADDRESS? If 527 yes, assign to instance or area identified by (hub router-id/ 528 system-id, IGP peer source router-id/system-id) and exit. 530 5. Assign to instance identified by the Area ID and exit. 532 New virtual instances/areas SHOULD be created when there is no 533 corresponding instance. With the closing of the last IGP adjacency 534 associated with a virtual instance/area, that virtual instance/area 535 MAY be destroyed. 537 5.2. Generating Router LSA/LSPs and Default Routes for Virtual 538 Instances 540 For each virtual instance/area, the Hub Router MUST generate a 541 separate Router LSA/LSP that includes only the links to IGP peers 542 identified as part of that virtual instance/area and, if the virtual 543 instance/area is identified as a ring topology, SHOULD include any 544 direct links from the Hub Router to another Hub Router. 546 5.3. SPF computations and Route Preference 548 A separate SPF calculation SHOULD be done for each virtual instance. 549 If the same prefix is learned from a non-virtual instance/area, then 550 its route MUST be preferred over the route via a virtual instance/ 551 area. 553 6. Manageability considerations 555 Because of the scale for hub-and-spoke topologies, it is difficult to 556 manage per-spoke configuration on the hubs. Therefore, virtual 557 multi-instance does not require per-spoke configuration. The 558 following are the expected configuration aspects. 560 o A set of interfaces is specified as configured for virtual multi- 561 instance. The type of topology - spoke, ring, or dynamic tunnel - 562 must be specified for the set. 564 o The set of neighboring hub routers may be specified. This is per 565 hub neighbor configuration. Alternately, node admin tags may be 566 supported and one admin tag configured to indicate what other 567 routers are hub routers. 569 o A value for the UNIQUE_RING_AREA_ADDRESS may be specified or a 570 well-known default (TBD) may be used. 572 o A default route to be advertised into virtual instances/areas may 573 be defined. 575 o A summarization policy for redistributing prefixes may be defined. 576 Ideally, this should apply to a set of virtual instances/areas. 578 It is expected that virtual multi-instance will be useful to provide 579 a zero-touch hub for IPSEC VPNs where it is highly desirable to have 580 no per spoke configuration on the hub router. 582 7. Backward compatibility 584 The mechanism described in the document is fully backward compatible. 585 The mechanism described in this document need to be supported by the 586 hub and the spokes need not support the mechanism unless they need to 587 support dynamic tunnels. 589 8. Security Considerations 591 This document does not introduce any further security issues other 592 than those discussed in [RFC2328] and [RFC5340]. 594 When a new spoke connects to the hub, it is restricted in terms of 595 visibility into the network. This enhances security in terms of 596 limited exposure to the unauthenticated nodes.Also the ability of a 597 spoke to perturb the entire area is minimized when summarization is 598 done. Per spoke authentication is already available and is expected 599 to work well with virtual multi-instance. 601 9. IANA Considerations 603 This document does not currently require any allocations from IANA. 605 10. Acknowledgements 607 The authors would like to thank Jeffrey Zhang, Pushpasis Sarkar and 608 Gil Spolidoro for their suggestions and review. 610 11. References 612 11.1. Normative References 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, 616 DOI 10.17487/RFC2119, March 1997, 617 . 619 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 620 DOI 10.17487/RFC2328, April 1998, 621 . 623 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 624 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 625 . 627 [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- 628 Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, 629 March 2012, . 631 [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. 632 Ward, "IS-IS Multi-Instance", RFC 6822, 633 DOI 10.17487/RFC6822, December 2012, 634 . 636 11.2. Informative References 638 [I-D.ietf-isis-node-admin-tag] 639 Sarkar, P., Gredler, H., Hegde, S., Litkowski, S., 640 Decraene, B., Li, Z., Rodriguez, R., and H. Raghuveer, 641 "Advertising Per-node Admin Tags in IS-IS", draft-ietf- 642 isis-node-admin-tag-08 (work in progress), December 2015. 644 [I-D.ietf-ospf-node-admin-tag] 645 Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. 646 Decraene, "Advertising per-node administrative tags in 647 OSPF", draft-ietf-ospf-node-admin-tag-09 (work in 648 progress), November 2015. 650 [I-D.sathyanarayan-ipsecme-advpn] 651 Sathyanarayan, P., Hanna, S., Melam, N., Nir, Y., Migault, 652 D., and K. Pentikousis, "Auto Discovery VPN Protocol", 653 draft-sathyanarayan-ipsecme-advpn-03 (work in progress), 654 October 2013. 656 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 657 Scope Link State PDUs (LSPs)", RFC 7356, 658 DOI 10.17487/RFC7356, September 2014, 659 . 661 Authors' Addresses 662 Shraddha Hegde 663 Juniper Networks 664 Embassy Business Park 665 Bangalore, KA 560093 666 India 668 Email: shraddha@juniper.net 670 Salih K.A 671 Juniper Networks 672 Embassy Business Park 673 Bangalore, KA 560093 674 India 676 Email: salih@juniper.net 678 Mannan Venkatesan 679 Comcast 680 1800 Bishops Gate Blvd 681 Mount Laurel , NJ 08053 682 USA 684 Email: mannan_venkatesan@cable.comcast.com 686 Ross Callon 687 Juniper Networks 688 Westford , MA 01886 689 USA 691 Email: rcallon@juniper.net 693 Alia K. Atlas 694 Juniper Networks 696 Email: akatlas@juniper.net