Subject: Re: ospf limits...

From: Igor Miroshnik <[email-masked]>
Date: Thu, 6 Mar 2003 11:16:13 -0500

From the implementor's point of view, what should be the input for the
needed memory estimation (for OSPF separately)? And then what is the
heuristics to proceed with?

---

From: Javed Syed <[email-masked]>
Date: Fri, 7 Mar 2003 02:46:32 -0500

Ravi,

Since router technology has made lot of progress, number of routers  in area , database limitation, two process all those design limitation does not raise any concerns.
make sure depending on the vendor, you can play with spfhold timer qnd other great ospf commands on point to point link to reduce the amount of LSA flooding etc depending on your design consideration.
Do you have any low speed links anywhere in your network which will be part of your ospf domain ?

javed

---

From: "Manral, Vishwas" <[email-masked]>
Date: Sun, 9 Mar 2003 23:55:38 -0500

Hi Yasu,

However not all routers may support DC-Extensions.;-)

Thanks,
Vishwas

-----Original Message-----
From: Yasuhiro Ohara [mailto:[email-masked]]
Sent: Monday, March 10, 2003 5:50 AM
To: [email-masked]; [email-masked]
Subject: Re: ospf limits...

Thanks Singh, Manral,

I agree, OSPF has DoNotAge bit about LSA refresh.
I forgot about that.

And so what I said might be wrong, there'll be no scalability issues
in terms of refresh rate. sorry.

regards,
yasu

From: "Manral, Vishwas" <[email-masked]>
Subject: Re: ospf limits...
Date: Sun, 9 Mar 2003 23:40:25 -0500

> Hi Yasu,
>
> Just one small point I want to make.
>
> Using
>
http://www.ietf.org/internet-drafts/draft-pillay-esnault-ospf-flooding-04.tx
> t , we can reduce the Refresh-Rate.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Yasuhiro Ohara [mailto:[email-masked]]
> Sent: Monday, March 10, 2003 5:31 AM
> To: [email-masked]
> Subject: Re: ospf limits...
>
>
> All I meant is that you can control refresh rate of IS-IS.
>
> In larger system, OSPF LSA refresh and/or IS-IS LSP refresh
> can be several tens of times per second. Then you can reduce
> the refresh rate only when you use IS-IS, but you can't reduce
> the refresh rate if you use OSPF.
>
> Does that matter the scalability of network, doesn't it ?
>
> I don't know actual parameter to enlarge the duration of LSP's life
> (the time till the LSP expires), because I haven't touched
> any working IS-IS ...
>
> regards,
> yasu
>
> From: Rohit Gupta <[email-masked]>
> Subject: Re: ospf limits...
> Date: Sun, 9 Mar 2003 19:52:28 -0800
>
> > Yasu,
> > I could not understand as to how this will help in
> > building larger ISIS areas vis-a-vis OSPF!
> >
> > Rohit
> >
> > --- Yasuhiro Ohara <[email-masked]> wrote:
> > > Hi,
> > >
> > > Though I haven't read (or don't remember) any
> > > document mentions
> > > that, I guess it comes from the capability of
> > > controlling the rate
> > > of bandwidth consumption used by LSA refresh.
> > >
> > > Because IS-IS ages LSP by counting down the age and
> > > expires them
> > > when the age is 0, IS-IS's "IS" can decide when to
> > > refresh his LSP
> > > individually. OSPF specifies when to refresh and/or
> > > expire LSA
> > > explicitly, so OSPF system's refresh rate is
> > > affected by the
> > > network-size (precisely # of LSA), and can't be
> > > reduced by
> > > human manipulation.
> > >
> > > regards,
> > > yasu
> > >
> > > From: Rohit Gupta <[email-masked]>
> > > Subject: Re: ospf limits...
> > > Date: Fri, 7 Mar 2003 01:00:14 -0800
> > >
> > > > I remember reading somewhere that ISIS can support
> > > > bigger areas than OSPF though i am not sure as to
> > > how
> > > > exactly, given that both are link state and almost
> > > > similar.
> > > >
> > > > So if you cant scale well with OSPF then you can
> > > > consider ISIS also.
> > > >
> > > > ----- Original Message -----
> > > > From: "klara moser" <[email-masked]>
> > > > To: <[email-masked]>
> > > > Sent: Thursday, March 06, 2003 11:41 PM
> > > > Subject: Re: ospf limits...
> > > >
> > > >
> > > > > Hi Ravi,
> > > > >
> > > > > As far as I know the OSPF protocol has only one
> > > > limitation on the topologies
> > > > > size - the Network and Router LSA size. The max
> > > is
> > > > 64KB. This limits the number
> > > > > of links the router can have in a single area,
> > > > because it has to advertise them
> > > > > in a single Router LSA. You can do the math. It
> > > is
> > > > something like 5 000 links.
> > > > >
> > > > > Klara
> > > > >
> > > > > Quaizar Vohra wrote:
> > > > >
> > > > > > I think the main factor is the amount of
> > > flooding
> > > > a router has to do
> > > > > > which depends on how many adjacencies you have
> > > and
> > > > how many LSAs you
> > > > > > have to flood to each adjacency. So it is
> > > useful
> > > > to divide your
> > > > > > network into multiple areas so as to reduce
> > > > flooding. Also large
> > > > > > no. of adjacencies in a single area can result
> > > in
> > > > rather large router
> > > > > > LSAs which causes a lots of fragmentation and
> > > adds
> > > > to the flooding
> > > > > > load.
> > > > > >
> > > > > > Quaizar
> > > > > >
> > > > > >  > I am in the midst of redesigning an OSPF
> > > > network to accommodate
> > > > > >  > significant growth, especially in the Area
> > > 0
> > > > backbone. There has been
> > > > > >  > some concern about the size of the OSPF
> > > > topology that would result and
> > > > > >  > whether the routing protocol would remain
> > > > robust, able to handle the odd
> > > > > >  > flapping link or memory leak. The network
> > > in
> > > > question is using high-end
> > > > > >  > routers with high speed links (at least
> > > DS-3).
> > > > > >  >
> > > > > >  > Are there any heuristics that someone has
> > > which
> > > > may give us an idea of
> > > > > >  > the comfort zone in terms of the database
> > > size,
> > > > number of neighbors,
> > > > > >  > routers, etc?
> > > > > >  >
> > > > > >  > Or, could someone share information on the
> > > size
> > > > of large OSPF
> > > > > >  > implementations that they are aware of?
> > > > > >  >
> > > > > >  > I know that this issue is rather vague
> > > (clouded
> > > > in too many unknowns)
> > > > > >  > and may only result in rather ambiguous
> > > > > >  > answers, but, one never knows.
> > > > > >  >
> > > > > >  > Thanks,
> > > >
> > > >
> > > > __________________________________________________
> > > > Do you Yahoo!?
> > > > Yahoo! Tax Center - forms, calculators, tips, more
> > > > http://taxes.yahoo.com/
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, more
> > http://taxes.yahoo.com/

---

From: "Manral, Vishwas" <[email-masked]>
Date: Mon, 10 Mar 2003 00:37:50 -0500

Hi Manav,

I think the point you are trying to make is that Reachability information is
kept seperate from topology information in ISIS and OSPFv3, while it is not
in OSPFv2.

I am not sure however, how often the case where, IP Reachability information
changes  while topology information does not, will occur. I am not sure this
would be a restriction on the OSPF area limit.

Thanks,
Vishwas

-----Original Message-----
From: Manav Bhatia [mailto:[email-masked]]
Sent: Monday, March 10, 2003 10:57 AM
To: [email-masked]
Subject: Re: ospf limits...

Dave,
I believe in ISIS all IP reachability ends up as leaf nodes and thus any
changes in the IP reachability alone results, only in a partial SPF run
(Partial Route Calculation, or PRC); the routers in the tree need to
calculate only the parts of the tree in which the leaf node for that
destination network resides. They need not run the entire SPF.

Whereas in OSPF one may run partial SPF only in case of changes in
inter-area routes.

Am i missing something?

Regards,
Manav

----- Original Message -----
From: "Dave Katz" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 10, 2003 10:42 AM
Subject: Re: ospf limits...

>    I think ISIS might be preferred to support larger networks because all
the
>    IP prefixes align as leaves in the SPF tree, meaning full SPF is not
run in
>    most cases where a link failure does not impact the core topology. In
OSPF,
>    all IP link failures in an area trigger LSA updates, which, in turn,
cause
>    full SPF runs. Therefore, a large OSPF area would be more demanding on
>    processing resources on the average than an ISIS network of comparable
>    size.
>
> This is an implementation detail that is not necessarily true.
>

---

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 10 Mar 2003 14:48:47 -0500

[Manav]
->    I believe in ISIS all IP reachability ends up as leaf
-> nodes and thus any
->    changes in the IP reachability alone results, only in a
-> partial SPF run
->    (Partial Route Calculation, or PRC); the routers in the
-> tree need to calculate only the parts of the tree in which
-> the leaf node for that
->    destination network resides. They need not run the entire SPF.
[Vishwas]
-> I am not sure however, how often the case where, IP
-> Reachability information changes  while topology information
-> does not, will occur.
[Dave]
->  Yes.  Fundamentally the problem is the same in both--if the actual
-> link topology changes, an SPF is required.  If leaf connectivity
-> changes, it is not.

  I think we are not in sync here w.r.t two things (correct me):
  1. *leaf* (router) in the graph (network) vs
     *leaf* (node) in the tree, and
  2. The *reachability* vs *link topology* changes

  Manav, if ISIS design allows implementer to choose index trees
  such that all *reachability* resides in the leaves (in the tree) -
  including the reachability of non-leaf (transit) routers resides
  on leaf nodes in the tree - then YES, it is very easy to skip
  the Full-SPF when *reachability* information alone changes
  (with out even going to Partial-SPF - just by updating the parent
  - pi - links). What I mean by reachability here is: some address
  in a leaf node in the tree (including some transit router's
  address in the graph) changed from x to y.

  As Dave said, when *link topology* changes, then NO. I think
  even in the case of index trees we have to do whole SPF. For
  example, if a link goes down, we chop-off an edge in the
  tree, that will result in all leaves falling off of the tree.
  We have to reinsert (set union algo) all those singleton
  leaves (reachability) back to the tree. From the perspective
  of Dijkstra's algorithm, the only way we can do those reinsertions
  is by doing the whole-SPF. Because, Dijkstra's algo is like
  Prim's unlike Kruskal's forest trees where you can find the
  least-weight edge that connects the two distinct forests. So,
  we have to do the whole SPF when topology changes.

  Remember, as we know, we no need to maintain the whole tree
  in case of OSPF or ISIS. All we need is the *new* parent
  for the singleton leaf (which fell off because of a link cut).
  Just to find the new parent, we have to do the whole-SPF.

  If the link got cut will result in a two disjoint forests
  (unlike falling off leaves) then we can find another safe
  least weight edge that will joint the disjoint forests by
  partial-SPF run (updating few pi links in the forests).
  Finding out such cut (which makes the tree disjoint) is
  real difficult (thank to Robert Tarjan).

  Neverthless, if we maintian some additional information about
  the topology structure (by augmenting the data structures) then
  we can do Partial-SPF. Please look for such work in OSPF:
  http://www.isoc.org/inet99/proceedings/4g/4g_2.htm

Venkata.