Virtual multi-instancing for link state protocols
draft-hegde-rtgwg-virtual-multi-instance-00

Abstract

In networks with routers of different capabilities, some routers may not be able to participate fully in supporting new features or handling large databases and the associated flooding. In some cases, these restrictions can cause severe scalability issues for the network in general. This document proposes virtual multi-instances, a generic mechanism for OSPF and IS-IS, that allows groups of routers in specific topologies to have a reduced database and reduces the topology changes that are seen. The virtual multi-instances are specified so that no software or protocol changes are required in the restricted routers. Due to the potential number of virtual multi-instances in a network, the configuration is limited and is not specified per virtual instance.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 1, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Problem Description
• 2.1. Issues
• 2.1.1. Load on Spoke routers
• 2.1.2. Customer Routers Causing Frequent SPFs
• 2.1.3. Mixture of Capabilities between Routers
• 3. Topology Restrictions
• 4. Solution Overview
• 4.1. Identification into Virtual Instances or Virtual Areas
• 4.2. Route Redistribution
• 4.3. Avoiding Transit Traffic
• 4.4. Including Hub-to-Hub Links for Ring LSDBs
• 4.5. Hierarchical Virtual Multi-Instance
• 4.6. Dynamic shortcut Tunnels
• 5. Hub Router Behavior
• 5.1. Classification into an Virtual Instance/Area
• 5.2. Generating Router LSA/LSPs and Default Routes for Virtual Instances
• 5.3. SPF computations and Route Preference
• 6. Manageability considerations
• 7. Backward compatibility
• 8. Security Considerations
• 9. IANA Considerations
• 10. Acknowledgements
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Authors' Addresses

1. Introduction

A router that participates in OSPF or IS-IS must be capable of handling the entire link state database (LSDB) for the areas or levels that router participates in. In OSPF, this can be mitigated by creating small or stub areas, but such areas must still be configured. In IS-IS, regardless of area address, there can be only a single Level 1. The need to handle the entire LSDB as well as all functionality required in that area or level poses a difficulty for networks that have routers with limited functionality or resources.

In Section 2, the specific problems motivating a solution are discussed. These problems derive from a mixture of operational concerns around configuration, equipment with limited resources, networks with growing numbers of routers, and enhancements in the IGPs that may be needed to support some services but that can't be supported by deployed equipment.

The proposed solution is termed virtual multi-instances because the hub router (termed from a motivating hub-and-spoke topology) is configured to dynamically treat a neighbor's LSP or LSA as belonging to a particular instance, that may be created and deleted on demand. For OSPF, that virtual instance may instead be treated as a virtual area. The hub router automatically creates the virtual instance, distributes a default route into the virtual instance, may advertise specific links into the virtual instance, and redistributes optionally summarized routes learned from that virtual instance.

The topologies to which virtual multi-instances can be applied are restricted. In Section 3, the three different types of topologies are described with different behavior for route redistribution, leaking of hub to hub links into the virtual instance, and ensuring a single hub router LSA/LSP announcement into the virtual instance/area. The virtual instance or area is distinguished based upon the hub router’s and neighbor’s Router-ID or system-id or upon the neighbor’s specified area-id. An overview of the solution is given in Section 4.

In Section 5, the specific procedures that a hub router must follow to use virtual multi-instances are defined. Because this solution is intended to be low-touch to ease manageability, the suggested configuration aspects are described in Section 6. In Section 8, the potential security benefits of reducing network visibility and using different instances are briefly discussed.

2. Problem Description

Hub-and-Spoke topologies are increasingly being used at large scale. Due to the scale and to improve routing between spokes, dynamic tunnels between spokes can be established and torn-down on-demand based on traffic flow. Particularly when combined with routers that have limited resources and low-feature implementations of IS-IS or OSPF, these topologies causes real issues in existing networks as described in Section 2.1.

In a hub-and-spoke network, each spoke in the same area unnecessarily learns the link information of the other spokes. This extra information not only grows the size of the LSDB but also causes additional information flooding with associated SPFs. In OSPF, spokes can be separated into different areas but this comes with configuration overhead and can waste IP addresses, since a different IP address is required per interface per area it is used in. In IS-IS, because there is only one L1 domain, the only way to create separated domains is to have separate L1L2 routers for each domain. While [RFC7356] defines different flooding scopes for IS-IS, the changes are not backwards compatible and how the information would be properly processed for basic routing is not defined. In a network, it is rarely feasible to have multiple L1L2 routers in the same geographic area simply to separate the flooding domains.

To provide improved routing between spokes, the ability to establish and tear down dynamic tunnels between spokes on-demand is defined in, for instance, "Auto Discovery VPN Protocol" [I-D.sathyanarayan-ipsecme-advpn]. A huge number of dynamic tunnels can badly impact the scaling of a link-state protocol. At the same time, these on-demand tunnels can't require configuration overhead to separate them into different areas.

2.1. Issues

2.1.1. Load on Spoke routers

As discussed, containing a hub-and-spoke network inside a single area means that all routers carry the full LSDB for the area. This can overload limited-capability routers or non-router devices that are frequently used as spoke routers. The use of a limited-capability router can thus constrain the size of the area.

High Internet traffic growth requires a high number of link and node updates in metro networks. The number of IP prefixes processed in LS databases increases, causing longer SPF calculations. Though modern routers have high CPUs and better resources for faster SPF calculations, non-router devices typically have limited resources for processing. The size of the LSDB and frequency of SPFs is a problem for non-router devices participating in the routing protocol.

2.1.2. Customer Routers Causing Frequent SPFs

In some cases, service-provider-managed CPEs may participate in the link state routing protocol to advertise their connected and loopback interfaces for end-to-end connectivity. Power cycles and device failure of CPEs can trigger updates to and SPF calculations on all routers in the domain or area. Isolation of the CPEs from uninvolved routers is desirable.

2.1.3. Mixture of Capabilities between Routers

A metro L1 network supports many different customers and services, but the inclusion of non-router devices (such as cable modem termination systems, video edge devices, voice soft switches, etc.) that participate in the link state protocol may severely limit the ability to provide those different services and abilities.

A non-router device typically just gets its default route from the upstream L1L2 routers for outbound traffic. While that meets the requirements of the non-router device, the inability of such devices to support all IS-IS features (e.g. multi-topology) means that the whole Metro L1 network can't support those features.

It may not be reasonable or economical to request the implementation of such features on a non-router device that has no need to use them. A solution is required that can support both non-router devices with limited routing protocol features and core network devices with complete routing features. This will allow the Metro L1 network to provide diversified services to different customers.

3. Topology Restrictions

The issues discussed in Section 2 center on issues around hub-and-spoke topologies. In the simplest case, each spoke is connected to a single hub router as shown in Figure 1. To provide resiliency, a spoke may be connected to two hub routers, as shown in Figure 2. Since normal link state routing is performed between the hub and the spoke, the spoke does not need to be a single router, but could be a small connected group of routers operating as an IS-IS (level 1) or OSPF area as long as only one among the group of routers connects to the hub router.

                 +-------+
                 | Hub 1 |
                 +-------+
                  /   |  \
                 /    |   \
              +---+   |   +---+ 
              |A_1|   |   |C_1|
              +---+   |   +---+
               /  \  +---+   |
              /    | | B |  +---+
             /     | +---+  |C_2|  
          +---+ +---+       +---+
          |A_2|-|A_3|   
          +---+ +---+

       +---------+   +---------+ 
       |  Hub_1  |   |  Hub_2  |
       +---------+   +---------+
          |      \   /    |
          |       \ /     |
        +-----+    X   +-----+
        | A_1 | --/ \--| B_1 |
        +-----+        +-----+
         /    \
       +---+ +---+   
       |A_2|-|A_3|   
       +---+ +---+

    +-----+   +-----+
    | G_1 |---| G_2 |      
    +-----+   +-----+
         \      /
       +---------+   +---------+ 
       |  Hub_1  |---|  Hub_2  |
       +---------+   +---------+
         |     |       |      |
         |  +-----+  +-----+  |
         |  | E_1 |--| E_2 |  |
         |  +-----+  +-----+  |
         |                    |
     +-----+ +-----+  +-----+ +-----+
     | F_1 |-| F_2 | -| F_5 |-| F_6 |
     +-----+ +-----+  +-----+ +-----+
        |               |
       +-----+     +-----+
       | F_3 |-----| F_4 |      
       +-----+     +-----+

       +-------+
       | Hub 1 | 
       +-------+
       /      \         === is dynamic tunnel
      /        \
   +---+       +---+ 
   | A |=======| B |
   +---+       +---+