Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Sudheer Dharanikota (sudheerNAYNA.COM)
Date: Tue Jul 24 2001 - 11:09:55 CDT
I have been thinking in the sam elines for some time and I feel
it makes my life "draft-many-ccamp-srg-00.txt" very interesting.
Could send me the pointers please. If you are coming to London,
we can discuss this too.
Alex Zinin wrote:
> Several years ago I proposed an idea of multi-level OSPF
> (MLOSPF), where OSPF would perform multi-level link-state
> (not path-vector as in your suggestion) routing. That was
> basically a logical result of trying to think of a better
> inter-area routing mechanism for OSPF. As a nice side effect,
> MLOSPF did not have the requirement for the backbone area
> (since we don't need star-topology to get rid of DV routing
> loops any more), and supported arbitrary area topologies.
> The idea did not find a lot of interest, mainly because
> most (if not all) ISPs run BGP to distribute actual routing
> information and IGPs (OSPF and ISIS) are used to "glue the
> loopbacks together" [(C) by someone]. However, I think this
> topic may become more interesting in the light of hierarchical
> MPLS traffic engineering. I can send a link to the document
> and presentations if anyone is interested.
> Alex Zinin
> Monday, July 23, 2001, 9:03:51 AM, Curtis Call wrote:
> > Has anyone explored the possibility of removing the backbone from OSPF,
> > thereby allowing more flexible configurations? It seems to me that by adding
> > an Area Path field (which would function identically to the AS_PATH in BGP) to
> > Summary LSAs the requirement of having all inter-area traffic pass the
> > backbone could be removed. This could be accomplished via use of Type 10
> > Opaque LSAs which could contain similar information to standard Network and
> > ASBR Summary LSAs with a TLV used for the Area Path which would be composed of
> > sub-tlv's for each area the LSA has already traversed. Then, an ABR will not
> > share the information contained within this particular LSA with any of it's
> > attached areas if they are already present in the area path. It would make
> > OSPF areas behave in similar ways to BGP ASes which would allow administrators
> > to setup areas in any topology they wished (and also remove the use of
> > virtual-links).
> > This would require area numbers to be unique throughout the OSPF domain, but I
> > assume this is standard practice anyway. Backward compatibility could be
> > tricky, but I think it could be worked out without too many problems.
> > Has this already been looked at before? If not, does anyone else see this as
> > being beneficial? I am unfamiliar with the process of making suggestions for
> > OSPF, but if this idea hasn't been rejected before and others think it would
> > be useful then I would be interested in contributing to a draft on the
> > subject.
> > Thanks.