Network Working Group K. Raza Internet-Draft vIPtela Intended status: Standards Track J. Cavanaugh Expires: January 17, 2014 JP Morgan Chase A. Kulawiak Bank of America P. Pillay-Esnault F. Shamim Cisco Systems July 16, 2013 OSPF Stub Neighbors draft-raza-ospf-stub-neighbor-00 Abstract Open Shortest Path First stub neighbor is an enhancement to the protocol to support large scale of neighbors in some topologies with improved convergence behavior. It introduces limited changes protocol behavior to implement a scalable solution for hub and spoke topologies by restricting the functionality changes to the hub. The concepts are also applicable to a host running in a virtual machine environment. 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 17, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Raza, et al. Expires January 17, 2014 [Page 1] Internet-Draft OSPF Stub Neighbors July 2013 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 2. Specification of Requirements . . . . . . . . . . . . . . . . 5 3. Incremental deployment . . . . . . . . . . . . . . . . . . . 5 4. Link State Advertisement Filtering . . . . . . . . . . . . . 5 4.1. Area Border Router(ABR) Hub Routers . . . . . . . . . . . 6 4.2. Autonomous System Boundary Router (ASBR) Hub Routers . . 6 4.3. Other Hub Routers . . . . . . . . . . . . . . . . . . . . 6 5. Proposed Changes . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Stub neighbor overview . . . . . . . . . . . . . . . . . 6 5.2. Local Adjacency . . . . . . . . . . . . . . . . . . . . . 6 5.3. Local Router LSA originated on the Hub Router . . . . . . 7 6. Demand Circuit . . . . . . . . . . . . . . . . . . . . . . . 9 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 1. Introduction With the growing size of an Open Shortest Patch First (OSPF) [RFC2328] network, most large networks are now deploying OSPF in large hub and spoke topologies. Also in lot of cases L3 routing would be extended to Top of rack or even to a host running virtual machines. In any case these remote devices constitute a stub point in an OSPF network. These devices although being part of OSPF network will never be a transit point and thus do not need any topology information of the area nor do they require optimal routing calculations. Raza, et al. Expires January 17, 2014 [Page 2] Internet-Draft OSPF Stub Neighbors July 2013 The spoke router in the case of a hub and spoke (or a host running OSPF) only need a default route to the rest of the network, but they do need to send information about the connected network in the local site. In case of hosts they need to advertise routes inside of the virtual machines. OSPF as network protocol was designed for an environment where routers were of similar capabilities. To protect the larger network, area hierarchy was introduced. Network was typically broken up into a backbone area and several subordinate areas. This breakup of the topology into areas serves multiple purposes As OSPF has become pervasive protocol in the enterprise network it needs to evolve for large hub and spoke setups, these are typical retail environments. In a retail setup typical remote branch router does not have enough capacity to become part of a larger area, even if we break the network in large number of smaller areas. A remote router in one retail store does not need to have routes to all the router in other retail store that are part of its area setup. Also increasing the number of areas on Area Border Routers(ABR) can burden the router due to the creation of large number of Summary Link State Advertisement (LSA). Although this can be handled by creating the areas as stub with no summary. Even by creating smaller sized areas with stub no summary, it does not completely eliminate the problem of having unnecessary information from the prospective of intra area. With the advent of virtualized hosts, hosts are now advertising an increasing number of new virtual machine routes. These prefixes need to be advertised by a router that is connected to the host. Traditionally the host would be connected to the router via a shared link between the two (host and router). The host is often sourcing subnets that are not connected to the common subnet between the host and routers. However, the hosts (or spokes) themselves just need a default route from the router(or hub) to reach rest of the network. The solutions using current features of the protocol are not scalable. The overhead of protocol info and flooding of large number of unnecessary information to low-end routers caps the number of spokes on a hub. Raza, et al. Expires January 17, 2014 [Page 3] Internet-Draft OSPF Stub Neighbors July 2013 Virtualized Machines Virtualized Machines Virtualized Machines | | | | | | | | | +-----------+ +-----------+ +-----------+ |Hypervisor | |Hypervisor | |Hypervisor | +-----------+ +-----------+ +-----------+ | \ | \ / | | Area 1 \ | \ / | Area 1 | \ | /-----\---/ | +---+ \------\ +---+/ \------ +---+ Data Center 1 |R1 | \ \ |R2 | /|R3 | +---+ \ +---+ / +---+ \ \ / \ / / \ Area 1 \ / \ / / Area 1 \ / \ / \ / \ +---+/ \ / +---+/ ABR |R4 | / \ |R5 | ABR +---+ -----/ \ --- +---+ / \ / Area 0 \ +---+ +---+ |R6 |----------------------------- |R7 | +---+ \ / +---+ | \ ------------\ / | | / ------------\---/ | | / Area 0 \ | +---+ / \ +---+ |R8 |------------------------------|R9 | +---+ +---+ \ Area 0 / \ / +---+ +---+ ABR|R10| \ / |R11| ABR +---+ \ / +---+ / \ / /\ / \ / \ / \ Area 2 / / \ / \ +---+ / \ +---+ / \ \ +---+ |R12| / \|R13| / \---\ |R14| +---+ \ +---+ \ / +---+ Data Center 2 | \ | \ / | | Area 1 \ | / \ | Area 1 | \ | / \ | +-----------+ +-----------+ +-----------+ |Hypervisor | |Hypervisor | |Hypervisor | +-----------+ +-----------+ +-----------+ | | | | | | | | | Virtualized Machines Virtualized Machines Virtualized Machines Raza, et al. Expires January 17, 2014 [Page 4] Internet-Draft OSPF Stub Neighbors July 2013 Hub and Spoke Example This document describes extensions to OSPF to support very large Hub and spoke topologies more efficiently. Currently, the spoke router receives unnecessary information from the neighboring hub routers about all the other routers in the area. In most cases all a spoke router needs is IP reachability to hub routers which are the gateways to the rest of the network. 2. Specification of Requirements 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 [RFC2119]. 3. Incremental deployment For ease of deployment, the changes proposed in this document will be limited to the hub routers only. By limiting changes only to the hub router the feature can be incrementally introduced without upgrading other routers in the network. Specifically, the spoke sites do not need to be upgraded. It will be the responsibility of the hub router to mask the changes from the spoke as well as rest of the OSPF network such that the upgrading the network is simple from the point of interoperability and ease of deployment. The hub router can be a normal router and there is no requirement for the hub to be a area border router or an autonomous system boundary router. Hub site is a sort of passive listener. It is there to receive routes from the spoke site, and to just provide exit towards rest of the network. A hub router sends a default or aggregated route towards the spoke and filters out all the information about rest of the network from the spoke. 4. Link State Advertisement Filtering Routers establish adjacencies to flood topological information. The flooding process ensures all the information is consistent across the entire area and ensures the LSAs are delivered to all routers within the same area. From the protocol prospective topological information that is carried in the LSAs cannot be filtered, which it is essential to the loop free topology. Raza, et al. Expires January 17, 2014 [Page 5] Internet-Draft OSPF Stub Neighbors July 2013 The topological information learned, by all routers within an area build the consistent graph of the network connections. Today prefix aggregation can only be achieved using summary type 3 or type 5 LSA. There is no way to limit or mask intra area information. The hub and spoke topologies or Data center cases, it would be beneficial to mask intra area information as it would not cause any loop. 4.1. Area Border Router(ABR) Hub Routers Aggregation can be achieved at the ABR Hub router level using current features. The aggregation can be done by either using ranges or the default route injected as a type 3 LSA. 4.2. Autonomous System Boundary Router (ASBR) Hub Routers Similarly aggregation can be achieved at the ASBR Hub router level using current features. The aggregation can be done by either using ranges or the default route injected as a type 5 or type 7 LSA. 4.3. Other Hub Routers Currently there is no possibility of aggregating prefixes sent to the spoke routers which severely impacts the scale. This document describes the extensions to the protocol to address these scale issues in section 5. 5. Proposed Changes 5.1. Stub neighbor overview We propose a new kind of adjacency for neighbors configured as stub. The local adjacency will have a modified flooding content as the stub router only need a gateway through its neighbor. The hub router will send limited information to the remote spoke router without overwhelming the host with area topology. Spoke nodes should be considered a stub node when the remote site needs to send only prefixes to rest of the OSPF network without being considered a transit node. 5.2. Local Adjacency The local adjacency concept in only present on a hub router and it applies to those neighbors configured as stub neighbors. In this case, the hub router will maintain the adjacency to stub neighbors as local only. Raza, et al. Expires January 17, 2014 [Page 6] Internet-Draft OSPF Stub Neighbors July 2013 The hub router will flood a simplified router LSA to its local adjacencies so as to mask the area topology behind it. The Hub "Local" router LSA will contain only a p2p link to the stub neighbor when full adjacency is achieved and advertise one stub link with a configured range or the default prefix or both. The Hub router will effectively hide all the area topology including the prefixes behind it. We are introducing a new type of default route with a local behavior. The current use of default route as type 3 or as type 5 cannot solve some of the use cases and more specifically in the Data center topologies. The spoke router will function as normal advertising all its connected prefixes to Hub router. 5.3. Local Router LSA originated on the Hub Router The local Router LSA MUST contain at least 2 links. One p2p link to the stub neighbor and a stub link to advertise the default prefix or a range defined per configuration. Example 1: Hub Local router-LSA for any area with default prefix LS age = 0 ;always true on origination Options = ; LS type = 1 ;indicates router-LSA Link State ID = 192.0.2.1 ;Hub Router ID Advertising Router = 192.0.2.1 ;Hub Router ID bit E = 0 ;not an AS boundary router bit B = 0 ;not area border router #links = 2 Link ID = 192.0.2.2 ;Spoke Router ID. Link Data = 192.0.2.1 ;Hub IP interface to net Type = 1 ;connects to Point-to-point network # TOS metrics = 0 metric = 1 Link ID = 0.0.0.0 ;Default prefix Link Data = 0xffffffff ;Network mask Type = 3 ;connects to stub network # TOS metrics = 0 metric = 100 Hub Local router-LSA for any area with default prefix Raza, et al. Expires January 17, 2014 [Page 7] Internet-Draft OSPF Stub Neighbors July 2013 Example 2: Hub Local router-LSA for any area with configured ranges LS age = 0 ;always true on origination Options = ; LS type = 1 ;indicates router-LSA Link State ID = 192.0.2.1 ;Hub Router ID Advertising Router = 192.0.2.1 ;Hub Router ID bit E = 0 ;not an AS boundary router bit B = 0 ;not area border router #links = 2 Link ID = 192.0.2.2 ;Spoke Router ID. Link Data = 192.0.2.1 ;Hub interface to net Type = 1 ;connects to Point-to-point network # TOS metrics = 0 metric = 1 Link ID = 198.51.100.0 ;Range Link Data = 0xffffff00 ;Network mask Type = 3 ;connects to stub network # TOS metrics = 0 metric = 100 Hub Local router-LSA for any area with configured ranges A spoke router is usually a leaf node or in some cases may be in a dual-homed topology with another hub. In these cases, both Hub routers MUST be configured to view the spoke as a stub neighbor. The Local Router LSA of a Hub will get flooded over the other OSPF interfaces of a spoke router. A Hub router MUST ignore local router LSAs from other Hub routers flooded by a stub neighbor. Rest of OSPF topology | | | |<--Normal HUB RTR LSA | | | (site-1) | (site-2) HOSTS -------- SPOKE1 -------- HUB---------- SPOKE2 -------- HOSTS ^ ^ | | Simplified HUB Local RTR LSA contains only p2p link and a stub link with default or configured range Hub and Spoke Example Raza, et al. Expires January 17, 2014 [Page 8] Internet-Draft OSPF Stub Neighbors July 2013 6. Demand Circuit Sections 4.1, 4.2 described how to reduce the amount of information flooded and increase scalability. The use of Demand Circuit capability [RFC1793] can further enhance the scalability for some use cases. By making the spoke neighbors as demand circuit we will be able to suppress the refresh of all the routes we have learned from spoke sites. Only incremental changes are flooded in the network. Most networks have large number of spoke sites, in some large network there could be around 18-20K spoke sites each sending up to 3-5 subnets. Have to refresh these large number of LSAs can have unnecessary information flooded throughout large OSPF domain. Second type of spoke sites that are emerging are running over long distance wireless networks. Sending periodic hellos for neighbor detection is not desired behavior in long distance wireless network. We do understand this can have convergence impact for the spoke that is dual homed. 7. Benefits By making hub router define a stub neighbor we would be able to run OSPF in a true hub and spoke setup. Where the router that connects to the network and has local routes that needs to be advertising to rest of the network does not have to know about the OSPF topology beyond its hub. 8. Security Considerations This memo does not introduce any new security concerns or take any directed action towards improving the security of OSPF deployments in general. 9. IANA Considerations There are no IANA considerations. 10. Acknowledgments This document was produced using Marshall Rose's xml2rfc tool. Raza, et al. Expires January 17, 2014 [Page 9] Internet-Draft OSPF Stub Neighbors July 2013 11. Normative References [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. Authors' Addresses Khalid Raza vIPtela 1735 Technology Drive San Jose, CA 95110 USA EMail: khalid.raza@viptela.com Jon Cavanaugh JP Morgan Chase 1111 Polaris, Suite 4N Columbus, OH 43240 USA EMail: john.e.cavanaugh@jpmchase.com Andrew Kulawiak Bank of America New York, NY 10004 USA EMail: andrew.kulawiak@bankofamerica.com Padma Pillay-Esnault Cisco Systems 510 McCarty Blvd Milpitas, CA 95035 USA EMail: ppe@cisco.com Raza, et al. Expires January 17, 2014 [Page 10] Internet-Draft OSPF Stub Neighbors July 2013 Faraz Shamim Cisco Systems 2200 President George Bush TPKE Richardson, TX 75082 USA EMail: sshamim@cisco.com Raza, et al. Expires January 17, 2014 [Page 11]