Re: OSPF multi-level hierarchy: Necessary at all?

["Alex P. Rudnev" <alex () Relcom EU net>]

> 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.
>
> > On Thu, 27 May 1999, Alex Zinin wrote:
> >
> > > 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)