OSPF multi-level hierarchy: Necessary at all?

Hey, Alex:

Alex.

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

I mean IETF's OSPF WG, sorry :slight_smile:

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.

OK, lemme put it the way it is now:

1. From intra-domain routing standpoint we have two levels: intra-area
    and inter-area. All routers within an area know the whole topology
    of it. On the area borders the topology is hidden, routing info summarized
    and internal routers see summaries from all areas.

2. For routing to destinations outside an OSPF domain we have Type5-LSAs
    which can carry type 1 or type 2 routes (this is what you meant, I
believe),
    depending on whether your external metric is comparible with the OSPF
    one or not.

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).

Agree

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),

I've heard some of them do have big enough OSPF networks :slight_smile:

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

Yeah, in this case the sub-area 0.1.1's topology would be hidden
from the 0.1's routers and vice versa.

(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

Well, you do know that you can create loopback interfaces and the router-ID
will be the highest one among them. Say you do:

int lo 0
ip address 255.1.1.1

It will hardly be overriden by another loopback.

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

Actually there is a DDTS on the wish-list, but it is still not implemented for
some reason, let's hope it will be....
Derek, are you reading us ? ;))

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.

I was thinking about it as well. One could configure some area range
as a "discard" one, effectively saying that all routes dropping into the
range should be ignored instead of announced in a summary-LSA.

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).

Actually, you can use NSSA, but doesn't allow for filtering either.

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

[snip: got your wish, Alex]

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

who said you can't ? or I'm missing something?

Alex.

Date: Thu, 27 May 1999 19:36:13 +0400
From: Alex Zinin <zinin@amt.ru>
To: nanog@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)

Yeah, in this case the sub-area 0.1.1's topology would be hidden
from the 0.1's routers and vice versa.

> (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

Well, you do know that you can create loopback interfaces and the router-ID
will be the highest one among them. Say you do:

int lo 0
ip address 255.1.1.1

Hmm. Try yourself. Then, the quote from my config:
!
interface Loopback98
description Router-ID
ip address 223.255.254.118 255.255.255.255

I even proposed to declare 223.255/16 as private block -:).

Looks like doing the sex on the top of the tree - to make the life more
complex...

> router ospf 111
> router-id 1.2.3.4

Actually there is a DDTS on the wish-list, but it is still not implemented for
some reason, let's hope it will be....

I can imagine the ONLY reason for such SIMPLE thing... And it's in TODO
for a years - now everyone know the trick you showed above...

>network and name his _AREA 1.2.3.4_ with the strict filtering on the
>border.

I was thinking about it as well. One could configure some area range
as a "discard" one, effectively saying that all routes dropping into the
range should be ignored instead of announced in a summary-LSA.

I am not sure if it's the same what I was saying, but approx. it is. We
need good inter-area routing with the distribute-control over it. We can
control exported prefixes by -STUB AREA- definition and/or
summarisations, but we can't control incoming routes,

Btw, do you know _GATED_? It allow to control IMPORTED routes, but for
OSPF_ASE_ routes only. I don't think it's possible to control route
import anywhere except area borders (for the OSPF case), but why don't do
it on the area boundaries?

>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).

Actually, you can use NSSA, but doesn't allow for filtering either.

Sorry, what's NSSA?

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

[snip: got your wish, Alex]

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

who said you can't ? or I'm missing something?

Yes, I can. But no one (except me) know about it -:).

I mean some mixturing of OSPF and BGP properties. They are mixtured
already - OSPF tag can hold 1 BGP paths. Through I don't think it's
important for now.

Alex.

>
>
>
>
>
>> Date: Thu, 27 May 1999 19:36:13 +0400
>> From: Alex Zinin <zinin@amt.ru>
>> To: nanog@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)
>
>
>
------------------------------------------------------------------
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)