Re: OSPF multi-level hierarchy: Necessary at all?
At 11:35 27.05.99 -0700, Vadim Antonov wrote:
...
but the main question is whether there is a demand for it or not.
I guess the answer is pretty much not. The amount of interior routing information in a properly designed backbone is quite small even if there is no two-layer abstraction.
If you do not use route-summarization on the area borders, your're gonna have flat network from the routing info's point of view, even though the topology info is abstracted. Flat networks are very well known to be not scalable.
(Now, the _exterior_ information is aplenty, but OSPF is useless for it anyway).
The new approach could incorporate aggregating externals on level borders in addition to aggregating internal routing info.
If someone proposed simplifying and cleaning up OSPF i'd be quite for it. Building a protocol allowing to get rid of iBGP hack would also help :)
In OSPFv6 an ASE-LSA can point to another LSA, which per D. Ferguson can contain BGP path attributes. The new approach (which could be intergrated in OSPF for IPv6 btw) could use a technique analogous to this one. Rgds ------------------------------------------------------------------ Alex D. Zinin, Consultant CCSI #98966 CCIE #4015 AMT Group / ISL Cisco Systems Gold Certified Partner http://www.amt.ru irc: //EFNET/#cisco, //irc.msn.com/#NetCisco [Ustas]
Btw. Flat network... Routers now have - 128 or 256 MB RAM, 300 - 400 Mhz CPU. I guess you can built flat betwork with 5,000 routers withouth hard problems. Through it's not the question. There is _already_ 2 levels; you can use multi-zone OSPF (independent OSPF networks connected by _redistribute_). The question was _is 2-level hierarchy enougph__? On Fri, 28 May 1999, Alex Zinin wrote:
Date: Fri, 28 May 1999 14:26:27 +0400 From: Alex Zinin <zinin@amt.ru> To: Vadim Antonov <avg@kotovnik.com>, nanog@merit.edu Subject: Re: OSPF multi-level hierarchy: Necessary at all?
At 11:35 27.05.99 -0700, Vadim Antonov wrote:
...
but the main question is whether there is a demand for it or not.
I guess the answer is pretty much not. The amount of interior routing information in a properly designed backbone is quite small even if there is no two-layer abstraction.
If you do not use route-summarization on the area borders, your're gonna have flat network from the routing info's point of view, even though the topology info is abstracted. Flat networks are very well known to be not scalable.
(Now, the _exterior_ information is aplenty, but OSPF is useless for it anyway).
The new approach could incorporate aggregating externals on level borders in addition to aggregating internal routing info.
If someone proposed simplifying and cleaning up OSPF i'd be quite for it. Building a protocol allowing to get rid of iBGP hack would also help :)
In OSPFv6 an ASE-LSA can point to another LSA, which per D. Ferguson can contain BGP path attributes. The new approach (which could be intergrated in OSPF for IPv6 btw) could use a technique analogous to this one.
Rgds ------------------------------------------------------------------ Alex D. Zinin, Consultant CCSI #98966 CCIE #4015 AMT Group / ISL Cisco Systems Gold Certified Partner http://www.amt.ru irc: //EFNET/#cisco, //irc.msn.com/#NetCisco [Ustas]
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)
Btw. Flat network...
Routers now have - 128 or 256 MB RAM, 300 - 400 Mhz CPU. I guess you can built flat betwork with 5,000 routers withouth hard problems.
With a network this large, probability of any router interface going down, link flapping or rotuer failure is high so it can happen frequently. With one giant flat IGP area, any such incident occuring anywhere in the network will cause network wide LSA flooding, SPF calculation and link database update. Lots of network resources including router CPU will be consumed. Even one has a lot of cpu power in super routers, it's still a good idea to prevent an outage anywhere in the network from causing network wide event i.e. to localize the problem. A giant flat IGP area in a large network does not help achieving fault isolation. --Jessica
I know. I meant _things changed and old estimations should be changed too_. Not more. And then, if you don't include dialup interfaces into OSPF, but use static leased lines instead, why do you think the information changes frequently. Interface changes caused by failures, maintanance, reconfigurations. Ask any network admin how frequent are this events. Once/week or once/months. Through if we like to distribute information about dynamic dialup links - yes, you need some aggregation. If you are talking about the _huge_ events (such as cutting of the whole region from the flate network) - yes. For example, if I exclude the OSPF_ASE announces of dialup addresses here, I'll see not more than 1 LSA change/1hour. Once a day some link can fail, or once/hour some engeneer can turn off some equipment. If there is 100 POP's we'll see 100 such events/hour. I am not saying flat network is good, not. But the troubles are exaggerating. If you simplyt get 5000 CISCO routers, configure them as router osfp 1 network 0.0.0.0 255.255.255.255 area 0 interface Ethernet0/0 ip address xxxx interface Serial1/0 ip unnimbered Ethernet0/0 ... interface Serial4/8 ip unnimbered Ethernet0/0 connect all this routers and turn them on, it'll work. It's not the thing I recommend to do, but when someone say _you need areas for more than 100 routers OSPF domain_, I am not sure it's true. If someone say _you need aggregation if you want to flood diaup addresses from 10,000 modem's POP over the 100 POP's network_ it's true, but the areas are not only aggregation mechod. Through I like the idea of hierarchical routing system when someone can built AREA-0, then built another AREA-0 network, then interconnect them by AREA-1 backbone, etc etc. Btw, this means OSPF was not good designed because every AREA in it know _I am an area_, through it's better if it image itself as backbone (-:)). And there is administrating issues over it - it's important to allow different peoples control different parts of the network. But please stop talking about _a lot of interface changes_ etc withouth referencing to the type of network. In case of leased-links network I can built the network of ANY size; and limitations depends of the link stability, not of the network size. And they depend of the administrative issues. If you have 3 branches, you (may be) have 3 sysadmins, and it's better if they don't bother about the whole network at all. And the back-bone admin don't like to bother about the areas. On Fri, 28 May 1999, Jessica Yu wrote:
Date: Fri, 28 May 1999 14:51:40 -0400 From: Jessica Yu <jyy@ans.net> To: "Alex P. Rudnev" <alex@Relcom.EU.net> Cc: Alex Zinin <zinin@amt.ru>, Vadim Antonov <avg@kotovnik.com>, nanog@merit.edu Subject: Re: OSPF multi-level hierarchy: Necessary at all?
Btw. Flat network...
Routers now have - 128 or 256 MB RAM, 300 - 400 Mhz CPU. I guess you can built flat betwork with 5,000 routers withouth hard problems.
With a network this large, probability of any router interface going down, link flapping or rotuer failure is high so it can happen frequently. With one giant flat IGP area, any such incident occuring anywhere in the network will cause network wide LSA flooding, SPF calculation and link database update. Lots of network resources including router CPU will be consumed. Even one has a lot of cpu power in super routers, it's still a good idea to prevent an outage anywhere in the network from causing network wide event i.e. to localize the problem. A giant flat IGP area in a large network does not help achieving fault isolation.
--Jessica
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)
But please stop talking about _a lot of interface changes_ etc withouth referencing to the type of network. In case of leased-links network I can built the network of ANY size; and limitations depends of the link stability, not of the network size.
I was talking about ISP network which mostly is leased-line based. It depends on link stability and router stability. As I pointed out in my previous message, the more router and link a network has (i.e. the large scaled network), the large chance of having link flapping and router crashes (if you think in percentage sense), the more flooding, SPF calculation and LSDB update all routers in the network have to handle. If there is a hierarchy, then only a portion of routers (not all the routers) would need to handle flooding, SPF calculation and LSDB update. Also, the large the size of network (lots of routers and links), the bigger the LSDB and the higher complexity of SPF calculation. --Jessica
I was talking about ISP network which mostly is leased-line based. It depends on link stability and router stability. As I pointed out in my previous message, the more router and link a network has (i.e. the large scaled network), the large chance of having link flapping and router crashes (if you think in percentage sense), the more flooding, SPF calculation and LSDB update all routers in the network have to handle. If there is a hierarchy, then only a portion of routers (not all the routers) would need to handle flooding, SPF calculation and LSDB update.
You are 100% right - it's the classic. Through the initial question whas _does we need hierarchical multi-level SPF routing schema?_. And my opinion was _yes, but due to administration, but not CPU/memory issues (yes, this is important too but it's importance is usially overestimated). And no one from this list argued for this hierarchy at all.
Also, the large the size of network (lots of routers and links), the bigger the LSDB and the higher complexity of SPF calculation.
--Jessica
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)
participants (3)
-
Alex P. Rudnev
-
Alex Zinin
-
Jessica Yu