OSPF multi-level hierarchy: Necessary at all?

Alex P. Rudnev alex at Relcom.EU.net
Thu May 27 16:23:30 UTC 1999


Alex.

First of all, which 'WG' do you mean?

Then. I can't understand from your message which kind of hierarchy do you 
mean. OSPF have a few of different hierarchy issues - (1) two types of 
metrics, inter and intra-area metrics (type 1 and type 2); (2) there is 2 
level hierarchy of AREA/BACKBONE with the summarisation on the area 
borders.

If talking about the first, I hardly imagine the situation when someone 
is not satisfied by 2 existing metric types (except he can be unsatisfyed 
by the calculation scheme). If about the second - may be, not for ISP 
(ISP don't use complex OSPF routing, they have a lot of headache with 
IBGP instead), but for the corporate networks. Really, why can't I have 
any-level hierarchy for the OSPF zone - area 0, area 0.1, area 0.1.1, for 
example (this mean - I built area-0 part; then I add some area 0.1 part - 
first is _backbone_ in existing terms, second _area_), then if I'd like 
to add some big part to the area 0.1, I prefere to create sub-area 0.1.1 
(for example) instead of building virtual links and using some other 
tricks (moreobver, VL can't be used with CISCO's at all because CISCO 
don't allow to control router-id directly and you can't build VL withouth 
knowing router-id; it's amazing why for a few years CISCO can't implement 
one simple command

 router ospf 111
 router-id 1.2.3.4

or

 router-id Ethernet0

).

Through I think the problem of building complex ara schemas is not 
important for the ISP. More important is the problem of import/export - I 
can installl BGP routing with the customer and control announces by the 
route-map or distribute-lists; I can use RIP (I can't, but it's not 
important) and control announces by the distribute-lists; why can't I 
connect the customer's OSPF area (this is area-0 for HIM) to my OSPF 
network and name his _AREA 1.2.3.4_ with the strict filtering on the 
border.

This is reason why ISP don't like OSPF and such protocols - they can be 
used for the inter-router routing, but they can't be used to connect with 
the customers (no, I can run 10 different OSPF processes and re-advertise 
routes - one more headache for the network admins).

PS. From ISP's point of view. What I'd like.

1) There is some network. They run OSPF over it. Router CUST1 is AREA-0 
router.

2) There is some other network. They run OSPF over it. Router ISP1 is 
AREA-0 router for this network too (or it is AREA-xx, not important).

I'd like to communicate this two OSPF networks by OSPF protocol, with the 
distribute-list restrictions (I define router blocks I can receive and 
minimal network size I'd like to receive from the CUST1), and (from my, 
ISP, point of view) this customer looks as usial OSPF area. For the 
customer, my AREA-0 looks as some other AREA-1. And we can do filtering 
on the board and control strictly which networks can be injected - from 
ISP to CUST, from CUST to ISP.

3) Moreover, why can't I determine different BGP AS numbers for the boths 
ISP and CUST OSPF zones. 




On Thu, 27 May 1999, Alex Zinin wrote:

> Date: Thu, 27 May 1999 19:36:13 +0400
> From: Alex Zinin <zinin at amt.ru>
> To: nanog at merit.edu
> Subject: OSPF multi-level hierarchy: Necessary at all?
> 
> 
> Hello, 
> 
> We're currently discussing necessity of multi-level hierarchy
> in OSPF on the WG mail list.
> 
> The idea is to implement SPF-based interarea routing
> with more than two levels of topology abstraction and
> route aggregation (we have two levels in OSPF at the
> moment level1 being intra-area routing and level2 being
> the inter-area one).
> 
> I have some thoughts on how this could be done,
> but the main question is whether there is a demand
> for it or not.
> 
> Everyone is really welcome to share opinions.
> 
> Thanks in advance,
> ------------------------------------------------------------------
> 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)





More information about the NANOG mailing list