Interesting multiple OSPF area dilemma

Greetings:

I seek input on a decision I must make regarding using multiple areas
in a network using OSPF as the IGP.

I have reviewed the NANOG archive messages regarding OSPF hierarchy,
KISS principle, OSPF design, etc., but I'd still enjoy some feedback.

* We have an existing nationwide network all carried by a single ATM carrier.
    (Carrier "A")

* The network is flat. Everything is area 0.0.0.0. Currently less than 1000
    OSPF route table entries.

* We are expanding the network via a second carrier. (Carrier "B")

* As we do more business with the new carrier "B" we expect to swing cities
    currently on the "A" network over to the "B" network.

* I have a fresh /18 from ARIN to apply to the build out with new Carrier "B"

* Both networks will tie into the same hubs on the east and west coasts.

The questions are:

1. Do I even consider creating a second area "1" for the new network?

   I don't have a huge number of routers, or routes, yet. Our existing
   address space is highly fragmented for various reasons, but that
   doesn't mean we shouldn't attempt to inject some order to the network
   as we move forward.
    
2. If we are successful in moving all business away from existing carrier "A"
    then we have to create a new area 0. That puts us in the position of having
    to put interfaces linking cities into the new area 0, while each city then
    has to have a unique new area for the "local" interfaces. I don't even
    want to think about virtual link games as I'm a big believer in the KISS
    principle. (I'm lazy, and I don't expect to be the one supporting this forever.)
    
   How do I move area 0?

    I suppose I could start by putting all inter-city links in the new network in
    area 0, but then right off the bat I have 2 OSPF areas in every new city.
    That seems to be counter to much that I've read. I expect the vast
    majority of "local" interfaces to be stub areas anyway.

3. Are any gains in route aggregation and fault tolerance offset by:
     * the additional "cost" of complexity
     * additional CPU load necessary to process multiple areas?

More Gory details:

Existing network "A":
  * East Coast hub with transit via UUNET
  * West Coast hub with transit via SAVVIS
  * 16 Satellite cities. Each city is dual homed to East/West Coast Hubs
     via ATM
  * 2 dozen routers in network.
  * Currently less than 1000 OSPF routes all in area 0.
  * BGP4 as the I/EBGP

New network "B"
  * connects to same east/west coast hubs as network "A"
  * we have a fresh /18 to apply to this buildout

Sorry, but don't do the things more complex than they are. Think about
your network as about the network built ove the mixture of ATM pvc's
(and/or other ATM methods), not important is this A, B or C carriers at
all.

Area in OSPF is the way to decrease the memory and CPU routers use for the
data base calculation; AS'es in BGP are the way to split network to the
different administratively-controlled domains. You have not first not the
second reason to run from the flat model.

If you'll have the big branch with it's own internal structure, you can
consider selecting this branch into the area (if it's structure is not
used for the transit). Through it was discussed here some time ago - it's
not pleasant until OSPF have not somple hierarchy instead of fixed 2-level
one with the special _area-0_ backbone.

PS. The idea pf any dynamic protocol such as OSPF was very simple. Any
config should looks like:

interface XX1
   cost XXXX (for YYY traffic)
interface XX2
  cost YYYY (for YYY traffic, may be)

...
router PROTOCOL
  network ANY
.

Everything extra was caused by one of the two reasons - the lack of cpu or
memory (OSPF areas, mixture of OSPF or STATIC's, etc), or the necessety to
divide network administration into the different domains (company XX and
company YYY, or the base company and the branch).

If your background carrier[s] is [are] not IP but L2 (treating ATM or FR
pvc's as
L2) carrier, it's a set of links or a set of LAN, P2P or NBMA networks.

Through I suspect you missed some detailes - elsewhere no one can explain
why did you get different IP addresses for using with the A or B ATM
carrier...
While you can run flat IGP schema, it's not nessesary at all. If you can
not, it's better to divide address space by the geographical, but not Ln-1
carrier's name, principles.

The different address blocks became important issue if you want to use
some Ln (IP in your case) provider for the transit purposes except of Ln-1
(ATM in your case) provider. Usially it's important to have Ln transit
between different geographical locations, and easy to order Ln-1 transit
in the local area (because in the local area you expances are not the link
fee, but in the long-distant transit links the cost of this links became
higher and it can cause you to use, for example, global internet as the
transit area. Don't forgot about the NAT, btw.

PS. May be I was wrong here to getting such advice, but I saw a lot of
mistakes did because the books describing different protocols forget to
explain the SIMPLE model of this protocol, and are trying to explain the
complex mechanisms the protocol use to get over the cpu or memory or
stability limitations...

Alex. /sorry for the long answer/

Date: Fri, 01 Oct 1999 11:21:37 -0400
From: Dustin Clampitt <jdustin@ziplink.net>
To: nanog@merit.edu
Cc: jdustin@ziplink.net
Subject: Interesting multiple OSPF area dilemma

Greetings:

I seek input on a decision I must make regarding using multiple areas
in a network using OSPF as the IGP.

I have reviewed the NANOG archive messages regarding OSPF hierarchy,
KISS principle, OSPF design, etc., but I'd still enjoy some feedback.

* We have an existing nationwide network all carried by a single ATM carrier.
    (Carrier "A")

* The network is flat. Everything is area 0.0.0.0. Currently less than 1000
    OSPF route table entries.

* We are expanding the network via a second carrier. (Carrier "B")

* As we do more business with the new carrier "B" we expect to swing cities
    currently on the "A" network over to the "B" network.

* I have a fresh /18 from ARIN to apply to the build out with new Carrier "B"

* Both networks will tie into the same hubs on the east and west coasts.

The questions are:

1. Do I even consider creating a second area "1" for the new network?

   I don't have a huge number of routers, or routes, yet. Our existing
   address space is highly fragmented for various reasons, but that
   doesn't mean we shouldn't attempt to inject some order to the network
   as we move forward.
    
2. If we are successful in moving all business away from existing carrier "A"
    then we have to create a new area 0. That puts us in the position of having
    to put interfaces linking cities into the new area 0, while each city then
    has to have a unique new area for the "local" interfaces. I don't even
    want to think about virtual link games as I'm a big believer in the KISS
    principle. (I'm lazy, and I don't expect to be the one supporting this forever.)
    
   How do I move area 0?

    I suppose I could start by putting all inter-city links in the new network in
    area 0, but then right off the bat I have 2 OSPF areas in every new city.
    That seems to be counter to much that I've read. I expect the vast
    majority of "local" interfaces to be stub areas anyway.

3. Are any gains in route aggregation and fault tolerance offset by:
     * the additional "cost" of complexity
     * additional CPU load necessary to process multiple areas?

More Gory details:

Existing network "A":
  * East Coast hub with transit via UUNET
  * West Coast hub with transit via SAVVIS
  * 16 Satellite cities. Each city is dual homed to East/West Coast Hubs
     via ATM
  * 2 dozen routers in network.
  * Currently less than 1000 OSPF routes all in area 0.
  * BGP4 as the I/EBGP

New network "B"
  * connects to same east/west coast hubs as network "A"
  * we have a fresh /18 to apply to this buildout

---

I apologize for turning the list into OSPF design 101. It seems to me
to be apropos and an interesting dilemma that may be faced by others
who inherit a network that grew without benefit of a master plan.

Actually, in deference to those list readers who I know at one time were
formerly involved with this network, I'm sure there was a plan, but it was
lost before I got here. And 2.5 years ago I probably wouldn't have recognized
it if it came up and bit me on the butt.

I could just punt, and put it all in area 0, but I just had to ask.

Sincerely,

Dustin Clampitt

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

If you're going to be at the Montreal meeting, I'm doing an OSPF tutorial
in the afternoon. This might be an interesting problem to discuss after
the presentation, if we still have the room -- and the bar doesn't call too
loudly.