Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!NSIPO.NASA.GOV!medin
From: medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: OSPF Area Routing
Message-ID: <8909120155.AA05159@cincsac.arc.nasa.gov>
Date: 12 Sep 89 01:55:37 GMT
References: <878@cgch.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 30


Not true.  In an older draft of the spec, that was the case.  In the current
spec (which has just been submitted for publication as an RFC - should be out
soon), the area boundaries can occur on internal subnet boundaries.  That is,
you could collapse the area routing information on subnet boundaries
(with a given mask) and not to the natural mask of the network.  The 
packet formats were changed so that this could occur.  Van Jacobson at
LBL and John Larson (who used to be at Xerox PARC) all had very good reasons
for why the spec should be this way.  The reason it wasn't that way in the
first place was an attempt to try and simplify the protocol, but upon
careful examination, it didn't really simplify much (except configuration)
since you already had to deal with variable length subnet mask support.

If you think it was bad for you, think of a large company who uses a
single Class A network number for their internal system.  Running such
a system as a single area would have defeated the whole reason areas
were introduced in the specification.  In addition, since the authentication
type is configurable on a per area basis, areas can be fairly autonomous.
Since OSPF areas also act as routing firewalls (an intra-area path is
NEVER overriden by an inter-area path), there are reasons why one
would use areas in cases where the topological complexity wouldn't justify
it alone.

Also note, that it's VERY hard to do this unless you have variable length
subnet mask support.  Since OSPF handles this, it's not a problem, but
this issue can a very sticky one to deal with.


						Thanks,
						   Milo