One document matched: draft-raza-ospf-stub-neighbor-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 06:06:43 |