May 1999 - Test - lists.nanog.org

RE: OSPF multi-level hierarchy: Necessary at all?
by Jessica Yu 27 May '99

27 May '99

The main purpose of doing hierarchical IGP (OSPF or ISIS), in my view, is to scale IGP routing and achieve fault isolation in large scaled networks. Most of the large networks exit today (especially those using IS-IS as IGP) are still having one flat IGP routing area since IS-IS simply does not have adequate 2-level support. The protocol issues are being addressed in the IETF. I can see a move to 2-level hierarchy in the near future but do not see more than 2 levels would be needed soon. In addition, some large ISPs are moving away from ATM overlay model to MPLS, this will reduce IS-IS/OSPF adjacency greatly (no more full mesh topology from IGP's point of view) thus alleviate IGP scaling issue. Further, the complexity of protocol and operation management will increase with the number of levels added to the hierarchy. In sum, the use of more than 2-level of IGP hierarchy is less likely, at least not in the near future. The following Internet-draft include some discussions of the topic in discussing routing scaling issues in general. Title : Scalable Routing Design Principles Author(s) : J. Yu Filename : draft-yu-routing-scaling-00.txt Pages : 24 Date : 15-Apr-99 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yu-routing-scaling-00.txt --Jessica - ------- Forwarded Message Return-Path: owner-nanog-outgoing(a)merit.edu Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by cannes.aa.ans.net (8.8.5/8.8.7) with ESMTP id LAA08768 for <jyy(a)cannes.aa.ans.net>; Thu, 27 May 1999 11:40:17 -0400 (EDT) Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id LAA29164; Thu, 27 May 1999 11:40:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7BB1044439; Thu, 27 May 1999 11:38:43 -0400 (EDT) Received: by segue.merit.edu (Postfix, from userid 56) id 5371344445; Thu, 27 May 1999 11:38:43 -0400 (EDT) Received: from amtsun.amt.ru (amtsun.amt.ru [212.111.64.19]) by segue.merit.edu (Postfix) with ESMTP id 881D144439 for <nanog(a)merit.edu>; Thu, 27 May 1999 11:38:35 -0400 (EDT) Received: from zinin (amtsun.amt.ru [212.111.64.19]) by amtsun.amt.ru (8.8.8/8.7.3.1) with SMTP id TAA14815 for <nanog(a)merit.edu>; Thu, 27 May 1999 19:38:21 +0400 (MSD) Delivered-To: nanog-outgoing(a)merit.edu Message-Id: <2.2.32.19990527153613.00ad2b70@amtsun> X-Sender: zinin@amtsun X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Date: Thu, 27 May 1999 19:36:13 +0400 To: nanog(a)merit.edu From: Alex Zinin <zinin(a)amt.ru> Subject: OSPF multi-level hierarchy: Necessary at all? Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog-outgoing(a)merit.edu X-Loop: nanog Content-Type: text/plain; charset="us-ascii" Content-Length: 764 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] - ------- End of Forwarded Message ------- End of Forwarded Message

1 0

Re: OSPF multi-level hierarchy: Necessary at all?
by Vadim Antonov 27 May '99

27 May '99

Alex Zinin <zinin(a)amt.ru> wrote: >We're currently discussing necessity of multi-level hierarchy >in OSPF on the WG mail list. ... >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. (Now, the _exterior_ information is aplenty, but OSPF is useless for it anyway). 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 :) --vadim

2 1

Re: OSPF multi-level hierarchy: Necessary at all?
by Alex Zinin 27 May '99

27 May '99

>> >> 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 -:). Ah, yeah, forgot about the range :) but you got the idea. > >> >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, Mmmm...I believe you mean we can control imported (import/export...:)) hey, let's say external) routes with stub areas. > >Btw, do you know _GATED_? It allow to control IMPORTED routes, but for >OSPF_ASE_ routes only. Actually in Cisco you can apply distribute-list to the whole process and it will be able to control which routes are installed into the routing table or got redistributed from it. You cannot control what is exchanged between routers, of course. >I don't think it's possible to control route >import anywhere except area borders (for the OSPF case), sure it is not, because you need to have syncronized LSDBs for all routers to calculate identical shortest paths. >but why don't do >it on the area boundaries? We should be able to but not now, unfortunately. I actualy have heard some rumors Cisco's gonna support this type of filtering. > >> >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? Not-So-Stubby Area, it works like a stub one, but allows to have an ASBR in it. So it does not accept ASE-LSAs from the domain, but can be used to inject externals into it. > >> >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. you mean RFC 1403? Alex. ------------------------------------------------------------------ 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]

2 1

Re: OSPF multi-level hierarchy: Necessary at all?
by Alex Zinin 27 May '99

27 May '99

Hey, Alex: At 20:23 27.05.99 +0400, you wrote: >Alex. > >First of all, which 'WG' do you mean? I mean IETF's OSPF WG, sorry :) > >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 :) > 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. > > > > >On Thu, 27 May 1999, Alex Zinin wrote: > >> Date: Thu, 27 May 1999 19:36:13 +0400 >> From: Alex Zinin <zinin(a)amt.ru> >> To: nanog(a)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]

2 1

Re: OSPF multi-level hierarchy: Necessary at all?
by Alex Zinin 27 May '99

27 May '99

Hey, Alex: At 20:23 27.05.99 +0400, you wrote: >Alex. > >First of all, which 'WG' do you mean? I mean IETF's OSPF WG, sorry :) > >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 :) > 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. > > > > >On Thu, 27 May 1999, Alex Zinin wrote: > >> Date: Thu, 27 May 1999 19:36:13 +0400 >> From: Alex Zinin <zinin(a)amt.ru> >> To: nanog(a)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]

1 0

OSPF multi-level hierarchy: Necessary at all?
by Alex Zinin 27 May '99

27 May '99

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]

2 1

FGC Greenfield Deployment slides
by Alan Hannan 26 May '99

26 May '99

are available now at http://www.eng.globalcenter.net/presentations/nanog/ -alan

1 0

Local Exchange Carriers in New York
by Jan Ahrent Czmok 26 May '99

26 May '99

Can anyone provide me with a comprehensive list of phone carriers offering ISDN PRI Provisioning and Leased Lines (no Internet) from T1 to OC3 within New York Area ? Jan Czmok Gigabell AG

2 1

SIA contingency plan released
by Sean Donelan 26 May '99

26 May '99

If you would like to see what a contingency plan looks like, the Securities Industry Association released its industry Y2K contingency plan yesterday. http://www.sia.com/year_2000/pdf/Y2KReport.pdf The SIA tends to refer to the Internet as the "web." How many network planning folks were aware one alternative for maintaining market operations is using the web to post prices? I'm glad the financial industry has such confidence in our ability to continue to deliver service even if other communication systems fail. Also after the NANOG meeting I received a few additional comments on my presentation. I would like to clarify a few things. 1) I did not mean to imply that DRA has completed all of its Y2K preparations. See Year 2000 Readiness Disclosure Statement. 2) The US Government is (at least one US Senator has strongly suggested it, so it seems pretty likely it will be done) setting up a Y2K network which is independent of the normal telephone network (satellite, HF radio, and other government communication assets) including electric grid controllers and 'major' telephone company management centers. However, at the current time no ISP NOC has asked or been asked to participate. Even at those companies which have both a voice NMCC and an ISP NOC, the ISP part of the company has generally been left out. I covered some of the reasons in my talk (although perhaps a bit obliquely). 3) I'm not recommending using the FCC 'emergency' rule to attempt ISP NOC communication. I think even the hams would agree, without training and experience such ad hoc radio networks tend to quickly become unusable. And no, I don't think having a ham license is sufficient (or necessary) experience. I'd rather teach 10 law firm receptionists how to use a radio if I want to be sure the message will be delivered to the correct person without being garbled, for many of the same reasons you don't hire your typical telephone engineer as a telephone receptionist. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Contact info, please?
by alex＠nac.net 25 May '99

25 May '99

Looking for clueful contacts for Level3 & Williams, specifically in 111 8th Ave, NYC. Forward to alex(a)nac.net, thanks! -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP; we have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

1 0