[OSPF] Comments for "OSPF Stub Neighbors"

["Russ White" <[e-mail]>]

Y'all --

Some thoughts on the current OSPF stub neighbors draft. Some are grammar,
later ones are content.

==
With the growing size of an OSPF-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.

This is too much text that's not needed. Something simpler would do, such as
--

OSPF is often deployed on large scale hub and spoke or spine and leaf
topologies. In both of these topologies, a large number of routers running
OSPF will never transit traffic, and hence could be declared stub routers. 

==
The spoke router in the case of a hub and spoke (or a host running OSPF)
only need 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 in the virtual machines.

This feels like too much text as well. Maybe --

OSPF stub routers only need to receive a default route to the rest of the
network, and they need to send information about connected subnets or hosts
(in the case of a virtual machine or hypervisor running OSPF).

I actually don't know that I would agree with the idea that an OSPF stub
only needs a default route -- in fact, you want a subset of routes rather
than a defualt only, much like partials in BGP peering. The point is that
the stub doesn't need any topology information, and it also doesn't need
full reachability information. I'll have more comments on this in later
sections.

==
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.

Too much explanation... There's no real tie between flooding domains
(areas), "protecting the larger network," and the concept being presented
here -- it just feels like random information. Something like this might
help tie things together better --

OSPF networks are broken up into flooding domains, called areas, to manage
the amount of control plane state carried to any individual router. Within a
flooding domain, each router has a synchronized database containing full
reachability and topology information within the area. At the area border,
topology information is automatically removed from the information
advertised by an OSPF router, and reachability information can be removed
through route aggregation. This draft proposes removing all topology
information transmitted to OSPF stub routers, and allowing the network
administrator fine grained control over reachability information advertised
to an OSPF stub router.

==
Also increasing the number of areas on ABR can burden the ABR, this is due
to the creation of large number of summary 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.

I think what this is trying to say is -- "if you set up each remote as its
own area, you incur a penalty in OSPF ABR processing." I would either
introduce the alternate solution more fully, or just remove this. IMHO, it's
not needed, so I would choose the simpler path and just remove it.

==
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.

The problem is made more urgent because of VMs and hypervisors -- ack.
Again, though, either explain the problem completely, or leave it out.
Again, IMHO, this isn't needed, so I would leave it out. It's simpler in the
long run.

==
We presuppose familiarity with the contents of [RFC2328].

I don't think this is needed, myself...

==
Incremental deployment

The introduction to this section feels like it could be simplified a good
bit. Maybe something like --

The changes proposed in this draft impact the hub router in a hub and spoke
or spine and leaf topology. The hub router is not required to be an area
border router (ABR). From the perspective of the hub router's neighbors, the
hub router will appear to be a normal OSPF router running an unmodified
version of OSPF.

Or something like that... ??

BTW, I'm not certain you're going to actually get away with not changing the
remotes, but more on that in a moment. :-)

==
Vendors have implemented LSA filtering function on per neighbors basis
specially for the purpose of scaling large full mesh environments. 

This section seems a little muddled to me... :-( First, there are two types
of filtering here; one that blocks flooding across a particular link similar
to a DR/DIS, the other which blocks the advertisment of specific
reachability information in a type 3 (the inverse of route leaking in
IS-IS). I think you're talking about the first one here, but I don't really
understand how it applies to the problem at hand. If it's really a hub and
spoke sort of topology, then each remote is only going to receive one copy
of each LSA. If it's spine and leaf, then you can block flooding, but it's a
bit harder than it seems, I think. You either need to have the one hub that
is flooding towards the remotes list all the hubs that are connected to the
remote, or you need to play some other game. For the remotes towards the
hubs, there are a number of solutions here -- look at the old MANET work for
something that's already been implemented in this space.

==
4.1, 4.2, and 4.3 don't seem to be necessary to me... ??

==
5.1 Stub Neighbor Overview

I'm a little confused by the special default route type. Specifically --

Why not just send a type 3 with only a default route, or only the subset of
routes you want the stub to know about? Maybe this has been discussed
before, but building a new TLV type seems like a lot of work for a limited
range of functionality that could be provided in a way the protocol already
knows about.

How are you going to prevent the stub from reflooding the LSA it receives
from the hub to any other device? Given the draft specifically says "the
stub router doesn't need to be changed," there doesn't seem to be any way to
solve this. You can assume the stub will only be connected to other modified
hub routers, but this seems like a pretty dangerous assumption.

What I think I'd do instead is introduce a new type 3 with a TTL. Then you
could put whatever you want in it, and be assured the information won't be
reflooded. Require the use of a tag for stub routers that don't support the
new TTL field, rather than relying on correct network topology
configuration. The point of control to prevent reflooding needs to be at the
stub router, rather than the hub router.

==
I have more comments for the later sections, but I'd like to clear these up
before moving into the rest of the draft.

HTH

:-)

Russ