From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 3 21:15:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21120 for ; Mon, 3 Mar 2003 21:15:44 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0091505C@cherry.ease.lsoft.com>; Mon, 3 Mar 2003 21:17:45 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 676037 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 3 Mar 2003 21:17:44 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Mar 2003 21:17:44 -0500 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h242HhS37183; Mon, 3 Mar 2003 18:17:43 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h242HhR52715; Mon, 3 Mar 2003 18:17:43 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs References: <60F922ABE8BE9C428E806F43C0EC73680B33C3@HARITHA> <3E5DDBD1.6EFF3278@earthlink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20030303171817.B52437@kummer.juniper.net> Date: Mon, 3 Mar 2003 18:17:43 -0800 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: To: Erblichs To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E5DDBD1.6EFF3278@earthlink.net> Precedence: list Hi Mitchell, On Thu, 27 Feb 2003, Erblichs wrote: > I think I missed why certain items are obmitted from this draft which > is very interesting... Just a few items :) This draft will be superceded by a new draft with similar goals but quite a different implementation. Unfortunately, we missed the ID cutoff, but the essence remains -- fast (sub-second) hellos, L2 independent, in principle L3 independent, and (the big change) routing protocol independent. We'll submit it after the IETF. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 4 02:42:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08478 for ; Tue, 4 Mar 2003 02:42:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00915A08@cherry.ease.lsoft.com>; Tue, 4 Mar 2003 2:44:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 676655 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Mar 2003 02:44:36 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Mar 2003 02:44:35 -0500 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18q76I-0007Qu-00; Mon, 03 Mar 2003 23:44:34 -0800 X-Mailer: The Bat! (v1.62i) Personal X-Priority: 3 (Normal) References: <60F922ABE8BE9C428E806F43C0EC73680B33C3@HARITHA> <3E5DDBD1.6EFF3278@earthlink.net> <20030303171817.B52437@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <72297164149.20030303234422@psg.com> Date: Mon, 3 Mar 2003 23:44:22 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: To: Kireeti Kompella To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030303171817.B52437@kummer.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Kireeti, Could you possibly put it on the web somewhere? It would be interesting to look at it. Thanks. -- Alex Monday, March 3, 2003, 6:17:43 PM, Kireeti Kompella wrote: > Hi Mitchell, > On Thu, 27 Feb 2003, Erblichs wrote: >> I think I missed why certain items are obmitted from this draft which >> is very interesting... Just a few items :) > This draft will be superceded by a new draft with similar goals > but quite a different implementation. Unfortunately, we missed > the ID cutoff, but the essence remains -- fast (sub-second) hellos, > L2 independent, in principle L3 independent, and (the big change) > routing protocol independent. > We'll submit it after the IETF. > Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 4 05:22:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11311 for ; Tue, 4 Mar 2003 05:22:44 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00915E16@cherry.ease.lsoft.com>; Tue, 4 Mar 2003 5:24:45 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 676876 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Mar 2003 05:24:45 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Mar 2003 05:24:45 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00915D0E@cherry.ease.lsoft.com>; Tue, 4 Mar 2003 5:24:45 -0500 Message-ID: Date: Tue, 4 Mar 2003 05:24:45 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: What is real ABR? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Ladies and Gentlemen, I have failed to find the answer in the archives. The question is what the behavior of ABR should be when it is neither physically connected to the backbone, nor having any configured virtual link. RFC2328 says such a router (having active interfaces to multiple areas) marks its router LSA with the bit B. Furthermore, as an ABR, the router originates summary LSAs and injects them into the attached non-stub areas. 1. Are the routes built by internal routers on the basis of those summary LSAs valid? Such inter-area routes pass between areas without the backbone mediation. 2. ABR should only process the backbone summary LSAs. The database of the router described has no backbone summary LSAs. Does it mean that this router cannot build inter-area routes? Thank you, Igor From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 4 05:40:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11678 for ; Tue, 4 Mar 2003 05:40:03 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00915CC7@cherry.ease.lsoft.com>; Tue, 4 Mar 2003 5:42:05 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 676933 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Mar 2003 05:42:05 -0500 Received: from 144.189.100.105 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Mar 2003 05:42:05 -0500 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h24AflLH005843 for ; Tue, 4 Mar 2003 03:41:47 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id DAA20954 for ; Tue, 4 Mar 2003 03:42:03 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Mar 2003 05:41:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 4 Mar 2003 05:42:58 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: What is real ABR? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Igor, To answer your questions: - 1. Yes they are. The leaking of summary LSA's is given in section 12.4.3 RFC2328. " Note that only intra-area routes are advertised into the backbone, while both intra-area and inter-area routes are advertised into the other areas. " 2. Yes in case a router has active attachments to multiple areas, only the backbone summary LSA's are to be processed for routing table calculations. In this case no summary LSA's will be processed. Going through the document http://www.ietf.org/internet-drafts/draft-ietf-ospf-abr-alt-05.txt would be helpful to clear any doubts you have. Thanks, Vishwas -----Original Message----- From: Igor Miroshnik [mailto:IgorM@RADLAN.COM] Sent: Tuesday, March 04, 2003 3:55 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: What is real ABR? Ladies and Gentlemen, I have failed to find the answer in the archives. The question is what the behavior of ABR should be when it is neither physically connected to the backbone, nor having any configured virtual link. RFC2328 says such a router (having active interfaces to multiple areas) marks its router LSA with the bit B. Furthermore, as an ABR, the router originates summary LSAs and injects them into the attached non-stub areas. 1. Are the routes built by internal routers on the basis of those summary LSAs valid? Such inter-area routes pass between areas without the backbone mediation. 2. ABR should only process the backbone summary LSAs. The database of the router described has no backbone summary LSAs. Does it mean that this router cannot build inter-area routes? Thank you, Igor From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 4 16:24:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10954 for ; Tue, 4 Mar 2003 16:24:07 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00916E92@cherry.ease.lsoft.com>; Tue, 4 Mar 2003 16:26:08 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 679012 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Mar 2003 16:26:08 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Mar 2003 16:26:08 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00916F0A@cherry.ease.lsoft.com>; Tue, 4 Mar 2003 16:26:08 -0500 Message-ID: Date: Tue, 4 Mar 2003 16:26:08 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Unresolved virtual next hops To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list All, Section 16.3 of RFC2328 says: "The calculation also determines the actual next hop(s) for those destinations whose next hop was calculated as a virtual link in Sections 16.1 and 16.2. After completion of the calculation below, any paths calculated in Sections 16.1 and 16.2 that still have unresolved virtual next hops should be discarded." As far as I understand, at list one next hop (may be suboptimal though) has been already found during the intra-area routes calculation in the corresponding Transit Area. Otherwise, we would not have advertised that virtual link in our backbone Router LSA. Can anybody give an example when there still remain unresolved virtual next hops at the stage described above in 16.3? Thanks, Igor From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 4 18:27:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15132 for ; Tue, 4 Mar 2003 18:27:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00917465@cherry.ease.lsoft.com>; Tue, 4 Mar 2003 18:29:12 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 679605 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Mar 2003 18:29:12 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Mar 2003 18:29:12 -0500 Received: (qmail 10714 invoked from network); 4 Mar 2003 23:29:11 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 4 Mar 2003 23:29:11 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id SAA19167 for ; Tue, 4 Mar 2003 18:29:11 -0500 Message-ID: <200303042329.SAA19167@bigbird.xebeo.com> Date: Tue, 4 Mar 2003 18:29:11 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Your message of "Thu, 09 Jan 2003 18:06:01 EST." <3E1E0059.5000806@redback.com> Precedence: list Folks, This issue has been around for a while and it is time that we picked one of the proposals as the WG document. My read of the consensus is that draft-ishiguro-ospf-ospfv3-traffic-01.txt should be used as the basis for TE for OSPFv3. Anybody care to comment further on the topic? Preferrably with points that have not been discussed on the list before. Regards, --rohit. On Thu, 9 Jan 2003 18:06:01 -0500 Acee Lindem writes: =>Kunihiro Ishiguro wrote: =>>>At the 55th IETF WG meeting, there were two proposals for =>>>supporting additional OSPF applications. There was quite =>>>a lively discussion of the relative merits of each and =>>>we decided that it would be best to discuss it further on =>>>the OSPF WG list. Heretofore, there hasn't been any further =>>>discussion so I figure it is time to get the ball rolling (or =>>>in this case, the E-mails flying). =>>> =>>> - OSPFv2 Opaque LSAs in OSPFv3 =>>> http://www.ietf.org/internet-drafts/draft-kompella-ospf-opaquev2-00.txt =>>> =>>> - Traffic Engineering Extensions to OSPF version 3 =>>> http://www.ietf.org/internet-drafts/draft-ishiguro-ospf-ospfv3-traffic- >01.txt =>>> =>>>The first defines the transformations necessary to map OSPFv2 =>>>opaque LSAs to OSPFv3. The second defines how to map the most =>>>widely implemented and deployed OSPFv2 opaque to OSPFv3 using =>>>new LSA types. =>> =>> =>> Well, besides I wrote a draft for OSPFv3 TE, I support defining a new =>> LS type for new application. OSPFv3 already has clean design and very =>> flexible architecture for new application. => =>[Speaking as WG member] => =>I have to agree with you here. I can't see the point of adding another =>layer of multiplexing for these types in OSPFv3. In OSPFv2, the opaque =>type was necessary since unknown types weren't handled. From an =>applications standpoint, it is much more likely that one is going to =>want to do something (whether it be process or view) all the LSAs =>associated with a given type than all opaque LSAs. => =>The only additional cost that I see is that when an opaque type is =>requested from IANA for OSPFv2, an OSPFv3 LSA type function code must =>also be requested. => =>--- =>Acee ___ From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 5 09:20:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01058 for ; Wed, 5 Mar 2003 09:20:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00918A8B@cherry.ease.lsoft.com>; Wed, 5 Mar 2003 9:22:25 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 681584 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 5 Mar 2003 09:22:25 -0500 Received: from 64.139.11.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Mar 2003 09:22:24 -0500 Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h25EL6o6001104; Wed, 5 Mar 2003 23:21:11 +0900 References: <3E1E0059.5000806@redback.com> <200303042329.SAA19167@bigbird.xebeo.com> User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: <87llzt6gj1.wl@ipinfusion.com> Date: Wed, 5 Mar 2003 06:21:06 -0800 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: OSPFv3 Applications Support Comments: To: Rohit Dube To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200303042329.SAA19167@bigbird.xebeo.com> Precedence: list >This issue has been around for a while and it is time that >we picked one of the proposals as the WG document. > >My read of the consensus is that >draft-ishiguro-ospf-ospfv3-traffic-01.txt >should be used as the basis for TE for OSPFv3. > >Anybody care to comment further on the topic? Preferrably with >points that have not been discussed on the list before. Thanks Rohit. I've update the draft with including Kireeti and Alex's comments. I hope this help we reach to rough consensus. -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 5 13:52:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21554 for ; Wed, 5 Mar 2003 13:52:36 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.009191A0@cherry.ease.lsoft.com>; Wed, 5 Mar 2003 13:54:39 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682272 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 5 Mar 2003 13:54:39 -0500 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Mar 2003 13:54:38 -0500 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id h25Isab1022549 for ; Wed, 5 Mar 2003 10:54:36 -0800 (PST) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (/) with ESMTP id h25IsTXd011070 for ; Wed, 5 Mar 2003 10:54:29 -0800 (PST) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.8/8.12.8) with ESMTP id h25Iin3a013451 for ; Wed, 5 Mar 2003 10:44:49 -0800 (PST) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id h25Iimxc026059 for ; Wed, 5 Mar 2003 10:44:48 -0800 (PST) References: <3E1E0059.5000806@redback.com> <200303042329.SAA19167@bigbird.xebeo.com> <87llzt6gj1.wl@ipinfusion.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <029001c2e349$7c1c1c50$1105f183@b90.tdd.sj.nec.com> Date: Wed, 5 Mar 2003 11:00:26 -0800 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Un-numbered point to point. doubt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello all!, I presently working on OSPF un-numbered point to point support. I need some clarification in implementing this support.. Well! to support this un-numbered point to point, the IP need to support this feature. If some body put some light on this it will be great! Yes! even if get some general view about how the IP need to support the un-numbered point to point of OSPF?? Is there any standard available for this?? Well! what i know is: * in case of un-numbered point to point, the one of valid IP address of other interface will be assigned to this un-numbered p2p. So, that whenever OSPF sends the packet, it will use this IP address as source address in the IP header. But how exactly it is implemeted?? Especially in linux kind of IP. (and stack). Thanks, GKS. NEC america, CA. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 5 21:57:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10875 for ; Wed, 5 Mar 2003 21:57:46 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0091A114@cherry.ease.lsoft.com>; Wed, 5 Mar 2003 21:59:48 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683744 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 5 Mar 2003 21:59:47 -0500 Received: from 67.17.166.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Mar 2003 21:49:47 -0500 Received: from Farshad (unverified [12.232.15.100]) by ucmmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id for ; Wed, 5 Mar 2003 21:49:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Wed, 5 Mar 2003 18:51:27 -0800 Reply-To: Mailing List Sender: Mailing List From: "Farshad (Sean) Tavallaei" Subject: Re: Un-numbered point to point. doubt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <029001c2e349$7c1c1c50$1105f183@b90.tdd.sj.nec.com> Precedence: list Content-Transfer-Encoding: 7bit GKS, RFC 1812 section 2.2.7 is a good start. I think I have seen this done with Linux using virtual or logical IP addresses or interfaces, or even sometimes loopback addresses for the unnumbered IP address. I know that may not be much, but it is a start. Good luck, Farshad -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of kamatchi soundaram Sent: Wednesday, March 05, 2003 11:00 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Un-numbered point to point. doubt Hello all!, I presently working on OSPF un-numbered point to point support. I need some clarification in implementing this support.. Well! to support this un-numbered point to point, the IP need to support this feature. If some body put some light on this it will be great! Yes! even if get some general view about how the IP need to support the un-numbered point to point of OSPF?? Is there any standard available for this?? Well! what i know is: * in case of un-numbered point to point, the one of valid IP address of other interface will be assigned to this un-numbered p2p. So, that whenever OSPF sends the packet, it will use this IP address as source address in the IP header. But how exactly it is implemeted?? Especially in linux kind of IP. (and stack). Thanks, GKS. NEC america, CA. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 5 22:23:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11340 for ; Wed, 5 Mar 2003 22:23:56 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0091A119@cherry.ease.lsoft.com>; Wed, 5 Mar 2003 22:25:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683903 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 5 Mar 2003 22:25:58 -0500 Received: from 67.17.166.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Mar 2003 22:25:58 -0500 Received: from Farshad (unverified [12.232.15.100]) by ucmmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id for ; Wed, 5 Mar 2003 22:25:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Wed, 5 Mar 2003 19:27:39 -0800 Reply-To: Mailing List Sender: Mailing List From: "Farshad (Sean) Tavallaei" Subject: Re: Un-numbered point to point. doubt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit GKS, Also, RFC 1586 section 3.2 is a good place to look at. Remember, the virtual links are like the unnumbered links for OSPF. From what I understand, when sending an OSPF packet through a virtual link, you need to know the destination IP address, which is supposed to be one of the interface IP addresses of the remote ABR. If the remote ABR is connected through unnumbered links only, you may not know any of its IP addresses. You may try to use looking for a /32 in the router-LSA and using it as the dst if no interface addresses are available, however, there may be situations where this is just not possible (i.e., no loopback addresses are announced). draft-ietf-isis-igp-p2p-over-lan-00.txt also has some good pointers. Hope that helps, Farshad -----Original Message----- From: Farshad (Sean) Tavallaei [mailto:farshad@onebox.com] Sent: Wednesday, March 05, 2003 6:51 PM To: Mailing List Subject: RE: Un-numbered point to point. doubt GKS, RFC 1812 section 2.2.7 is a good start. I think I have seen this done with Linux using virtual or logical IP addresses or interfaces, or even sometimes loopback addresses for the unnumbered IP address. I know that may not be much, but it is a start. Good luck, Farshad -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of kamatchi soundaram Sent: Wednesday, March 05, 2003 11:00 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Un-numbered point to point. doubt Hello all!, I presently working on OSPF un-numbered point to point support. I need some clarification in implementing this support.. Well! to support this un-numbered point to point, the IP need to support this feature. If some body put some light on this it will be great! Yes! even if get some general view about how the IP need to support the un-numbered point to point of OSPF?? Is there any standard available for this?? Well! what i know is: * in case of un-numbered point to point, the one of valid IP address of other interface will be assigned to this un-numbered p2p. So, that whenever OSPF sends the packet, it will use this IP address as source address in the IP header. But how exactly it is implemeted?? Especially in linux kind of IP. (and stack). Thanks, GKS. NEC america, CA. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 09:27:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16539 for ; Thu, 6 Mar 2003 09:27:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0091B3B5@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 9:29:34 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 685407 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 09:29:34 -0500 Received: from 63.210.62.243 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 09:19:34 -0500 X-VirusChecked: Checked X-Env-Sender: rmalhotra@bankofny.com X-Msg-Ref: server-31.tower-15.messagelabs.com!1046960364!26333 Received: (qmail 4448 invoked from network); 6 Mar 2003 14:19:25 -0000 Received: from unknown (HELO lgsbrc01.bankofny.com) (160.254.107.25) by server-31.tower-15.messagelabs.com with SMTP; 6 Mar 2003 14:19:25 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Thu, 6 Mar 2003 09:19:23 -0500 Reply-To: Mailing List Sender: Mailing List From: Ravi Malhotra Subject: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I am in the midst of redesigning an OSPF network to accommodate significant growth, especially in the Area 0 backbone. There has been some concern about the size of the OSPF topology that would result and whether the routing protocol would remain robust, able to handle the odd flapping link or memory leak. The network in question is using high-end routers with high speed links (at least DS-3). Are there any heuristics that someone has which may give us an idea of the comfort zone in terms of the database size, number of neighbors, routers, etc? Or, could someone share information on the size of large OSPF implementations that they are aware of? I know that this issue is rather vague (clouded in too many unknowns) and may only result in rather ambiguous answers, but, one never knows. Thanks, Ravi The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 09:32:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16831 for ; Thu, 6 Mar 2003 09:32:51 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0091B20A@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 9:34:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 685462 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 09:34:53 -0500 Received: from 128.96.41.1 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 09:34:53 -0500 Received: from research.telcordia.com (ar8-206 [192.4.8.206]) by thumper.research.telcordia.com (8.12.8/8.12.1) with ESMTP id h26EYhdl000626 for ; Thu, 6 Mar 2003 09:34:43 -0500 (EST) X-Mailer: Mozilla 4.8 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/) Message-ID: <3E675C82.E9A556B4@research.telcordia.com> Date: Thu, 6 Mar 2003 09:34:43 -0500 Reply-To: Mailing List Sender: Mailing List From: Sanjai Narain Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Ravi: As far as I know, OSPF has been used for a network of eighteen thousand routers in a financial company's network. -- Sanjai Ravi Malhotra wrote: > I am in the midst of redesigning an OSPF network to accommodate > significant growth, especially in the Area 0 backbone. There has been > some concern about the size of the OSPF topology that would result and > whether the routing protocol would remain robust, able to handle the odd > flapping link or memory leak. The network in question is using high-end > routers with high speed links (at least DS-3). > > Are there any heuristics that someone has which may give us an idea of > the comfort zone in terms of the database size, number of neighbors, > routers, etc? > > Or, could someone share information on the size of large OSPF > implementations that they are aware of? > > I know that this issue is rather vague (clouded in too many unknowns) > and may only result in rather ambiguous > answers, but, one never knows. > > Thanks, > > Ravi > > The information in this e-mail, and any attachment therein, is > confidential and for use by the addressee only. If you are not the > intended recipient, please return the e-mail to the sender and delete it > from your computer. Although The Bank of New York attempts to sweep > e-mail and attachments for viruses, it does not guarantee that either > are virus-free and accepts no liability for any damage sustained as a > result of viruses. -- Sanjai Narain Senior Research Scientist Telcordia Technologies 445 South Street Morristown, NJ 07960 USA Tel: +1 973 829 4515 Fax: +1 973 829 5888 Email: narain@research.telcordia.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 09:58:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17847 for ; Thu, 6 Mar 2003 09:58:12 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0091B301@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 10:00:15 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 685534 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 10:00:15 -0500 Received: from 209.202.115.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 09:50:15 -0500 Received: (qmail 21701 invoked from network); 6 Mar 2003 14:57:53 -0000 Received: from unknown (HELO alcatel.com) (138.120.105.194) by kanmx1.ca.alcatel.com with SMTP; 6 Mar 2003 14:57:53 -0000 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E676025.D75B471@alcatel.com> Date: Thu, 6 Mar 2003 09:50:14 -0500 Reply-To: Mailing List Sender: Mailing List From: klara moser Organization: Alcatel CID Subject: Re: Un-numbered point to point. doubt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi GKS, Actually, on a un-numbered point-to-point interface OSPF will send all its packets to the well defined All OSPF Routers "broadcast" address. In this case you do not need a uniquely defined IP address for the remote peer. The only requirement is that the layer two supports the OSPF "broadcast" address. Greetings Klara "Farshad (Sean) Tavallaei" wrote: > GKS, > > Also, RFC 1586 section 3.2 is a good place to look at. Remember, the virtual > links are like the unnumbered links for OSPF. Except for the virtual link you need the peer address, for unnumbered point-to-point interface you don't. > From what I understand, when > sending an OSPF packet through a virtual link, you need to know the > destination IP address, which is supposed to be one of the interface IP > addresses of the remote ABR. If the remote ABR is connected through > unnumbered links only, you may not know any of its IP addresses. You may try > to use looking for a /32 in the router-LSA and using it as the dst if no > interface addresses are available, however, there may be situations where > this is just not possible (i.e., no loopback addresses are announced). > > draft-ietf-isis-igp-p2p-over-lan-00.txt also has some good pointers. > > Hope that helps, > > Farshad > > -----Original Message----- > From: Farshad (Sean) Tavallaei [mailto:farshad@onebox.com] > Sent: Wednesday, March 05, 2003 6:51 PM > To: Mailing List > Subject: RE: Un-numbered point to point. doubt > > GKS, > > RFC 1812 section 2.2.7 is a good start. I think I have seen this done with > Linux using virtual or logical IP addresses or interfaces, or even sometimes > loopback addresses for the unnumbered IP address. > > I know that may not be much, but it is a start. > > Good luck, > > Farshad > > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of kamatchi > soundaram > Sent: Wednesday, March 05, 2003 11:00 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Un-numbered point to point. doubt > > Hello all!, > > I presently working on OSPF un-numbered point to point support. I need > some clarification in implementing this support.. > > Well! to support this un-numbered point to point, the IP need to support > this feature. If some body put some light on this it will be great! Yes! > even if get some general view about how the IP need to support the > un-numbered point to point of OSPF?? > > Is there any standard available for this?? > > Well! what i know is: > * in case of un-numbered point to point, the one of valid IP address of > other interface will be assigned to this un-numbered p2p. So, that whenever > OSPF sends the packet, it will use this IP address as source address in the > IP header. But how exactly it is implemeted?? Especially in linux kind of > IP. (and stack). > > Thanks, > GKS. > NEC america, > CA. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 10:02:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18047 for ; Thu, 6 Mar 2003 10:02:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0091B374@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 10:04:37 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 685617 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 10:04:38 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 10:04:37 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 41CB23D0F41 for ; Thu, 6 Mar 2003 07:04:36 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E676476.7010605@redback.com> Date: Thu, 6 Mar 2003 10:08:38 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Unresolved virtual next hops To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Igor Miroshnik wrote: > All, > > Section 16.3 of RFC2328 says: > > "The calculation also determines the actual next hop(s) for those > destinations whose next hop was calculated as a virtual link in Sections > 16.1 and 16.2. After completion of the calculation below, any paths > calculated in Sections 16.1 and 16.2 that still have unresolved virtual > next hops should be discarded." > > As far as I understand, at list one next hop (may be suboptimal though) has > been already found during the intra-area routes calculation in the > corresponding Transit Area. Otherwise, we would not have advertised that > virtual link in our backbone Router LSA. Hi Igor, Section 16.1.1 says that virtual nexthop resolution should be deferred until after section 16.3. However, I believe most implementations will use the virtual next hop and only update it if there is a better path through the transit area. > > Can anybody give an example when there still remain unresolved virtual next > hops at the stage described above in 16.3? I guess this could happen if you ran your backbone intra-area SPF calculation prior to the transit area calculation. In our implementation, we always run the backbone intra-area SPF after all the other areas. Good Luck, Acee > > Thanks, > Igor > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 10:39:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21001 for ; Thu, 6 Mar 2003 10:39:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0091B496@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 10:41:37 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 685704 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 10:41:37 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 10:41:37 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id AA08B3D0F46 for ; Thu, 6 Mar 2003 07:41:35 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3E675C82.E9A556B4@research.telcordia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E676D21.6000003@redback.com> Date: Thu, 6 Mar 2003 10:45:37 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Ravi, I agree that modern routers and OSPF implementations have blown away the previous limits for the number of routers in an area. As an example, take a look at the results of Lightreading's Edge Router test (apologies in the advance for vendor specific information): http://www.lightreading.com/document.asp?doc_id=25454&page_number=14 Also, it has been my experience that the limiting factor is the number of neighbor adjacencies that must be maintained. This number will vary by routing platform - ask your vendor. Sanjai Narain wrote: > Ravi: As far as I know, OSPF has been used for a network of eighteen > thousand routers in a financial company's network. -- Sanjai > > Ravi Malhotra wrote: > > >>I am in the midst of redesigning an OSPF network to accommodate >>significant growth, especially in the Area 0 backbone. There has been >>some concern about the size of the OSPF topology that would result and >>whether the routing protocol would remain robust, able to handle the odd >>flapping link or memory leak. The network in question is using high-end >>routers with high speed links (at least DS-3). >> >>Are there any heuristics that someone has which may give us an idea of >>the comfort zone in terms of the database size, number of neighbors, >>routers, etc? >> >>Or, could someone share information on the size of large OSPF >>implementations that they are aware of? >> >>I know that this issue is rather vague (clouded in too many unknowns) >>and may only result in rather ambiguous >>answers, but, one never knows. >> >>Thanks, >> >>Ravi >> >>The information in this e-mail, and any attachment therein, is >>confidential and for use by the addressee only. If you are not the >>intended recipient, please return the e-mail to the sender and delete it >>from your computer. Although The Bank of New York attempts to sweep >>e-mail and attachments for viruses, it does not guarantee that either >>are virus-free and accepts no liability for any damage sustained as a >>result of viruses. > > > -- > Sanjai Narain > Senior Research Scientist > Telcordia Technologies > 445 South Street > Morristown, NJ 07960 > USA > Tel: +1 973 829 4515 Fax: +1 973 829 5888 > Email: narain@research.telcordia.com > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 10:49:17 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21842 for ; Thu, 6 Mar 2003 10:49:16 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0091B509@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 10:51:19 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 685746 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 10:51:19 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 10:51:19 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 4CA443D0F4E for ; Thu, 6 Mar 2003 07:51:18 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3E676025.D75B471@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E676F67.30800@redback.com> Date: Thu, 6 Mar 2003 10:55:19 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Un-numbered point to point. doubt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Klara, Just one clarification - AllSPFRouters (224.0.0.5) is a local-wire multicast address. I know this is what you meant but wanted to avoid confusion. klara moser wrote: > Hi GKS, > > Actually, on a un-numbered point-to-point interface OSPF will send all its > packets to the well defined All OSPF Routers "broadcast" address. In this case > you do not need a uniquely defined IP address for the remote peer. The only > requirement is that the layer two supports the OSPF "broadcast" address. > > Greetings > Klara > > "Farshad (Sean) Tavallaei" wrote: > > >>GKS, >> >>Also, RFC 1586 section 3.2 is a good place to look at. Remember, the virtual >>links are like the unnumbered links for OSPF. > > > Except for the virtual link you need the peer address, for unnumbered > point-to-point interface you don't. > > >>From what I understand, when >>sending an OSPF packet through a virtual link, you need to know the >>destination IP address, which is supposed to be one of the interface IP >>addresses of the remote ABR. If the remote ABR is connected through >>unnumbered links only, you may not know any of its IP addresses. You may try >>to use looking for a /32 in the router-LSA and using it as the dst if no >>interface addresses are available, however, there may be situations where >>this is just not possible (i.e., no loopback addresses are announced). >> >>draft-ietf-isis-igp-p2p-over-lan-00.txt also has some good pointers. >> >>Hope that helps, >> >>Farshad >> >>-----Original Message----- >>From: Farshad (Sean) Tavallaei [mailto:farshad@onebox.com] >>Sent: Wednesday, March 05, 2003 6:51 PM >>To: Mailing List >>Subject: RE: Un-numbered point to point. doubt >> >>GKS, >> >>RFC 1812 section 2.2.7 is a good start. I think I have seen this done with >>Linux using virtual or logical IP addresses or interfaces, or even sometimes >>loopback addresses for the unnumbered IP address. >> >>I know that may not be much, but it is a start. >> >>Good luck, >> >>Farshad >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of kamatchi >>soundaram >>Sent: Wednesday, March 05, 2003 11:00 AM >>To: OSPF@DISCUSS.MICROSOFT.COM >>Subject: Un-numbered point to point. doubt >> >>Hello all!, >> >> I presently working on OSPF un-numbered point to point support. I need >>some clarification in implementing this support.. >> >>Well! to support this un-numbered point to point, the IP need to support >>this feature. If some body put some light on this it will be great! Yes! >>even if get some general view about how the IP need to support the >>un-numbered point to point of OSPF?? >> >> Is there any standard available for this?? >> >>Well! what i know is: >>* in case of un-numbered point to point, the one of valid IP address of >>other interface will be assigned to this un-numbered p2p. So, that whenever >>OSPF sends the packet, it will use this IP address as source address in the >>IP header. But how exactly it is implemeted?? Especially in linux kind of >>IP. (and stack). >> >>Thanks, >>GKS. >>NEC america, >>CA. > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 11:14:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24026 for ; Thu, 6 Mar 2003 11:14:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0091B709@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 11:16:15 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 685819 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 11:16:15 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 11:16:15 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0091B504@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 11:16:13 -0500 Message-ID: Date: Thu, 6 Mar 2003 11:16:13 -0500 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list From the implementor's point of view, what should be the input for the needed memory estimation (for OSPF separately)? And then what is the heuristics to proceed with? From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 12:14:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29551 for ; Thu, 6 Mar 2003 12:14:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0091B8C8@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 12:16:07 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 685953 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 12:16:07 -0500 Received: from 192.75.23.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 12:16:07 -0500 Received: (qmail 10624 invoked from network); 6 Mar 2003 17:18:17 -0000 Received: from unknown (HELO alcatel.com) (138.120.105.194) by kanmx2.ca.alcatel.com with SMTP; 6 Mar 2003 17:18:17 -0000 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3E676025.D75B471@alcatel.com> <3E676F67.30800@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E678255.D54EDD57@alcatel.com> Date: Thu, 6 Mar 2003 12:16:05 -0500 Reply-To: Mailing List Sender: Mailing List From: klara moser Organization: Alcatel CID Subject: Re: Un-numbered point to point. doubt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Thanks Acee, It is a broadcast address from OSPF protocol point of view, this is why I called it "broadcast" :) Klara Acee Lindem wrote: > Klara, > > Just one clarification - AllSPFRouters (224.0.0.5) is > a local-wire multicast address. I know this is what you meant but > wanted to avoid confusion. > > klara moser wrote: > ? Hi GKS, > ? > ? Actually, on a un-numbered point-to-point interface OSPF will send all its > ? packets to the well defined All OSPF Routers "broadcast" address. In this case > ? you do not need a uniquely defined IP address for the remote peer. The only > ? requirement is that the layer two supports the OSPF "broadcast" address. > ? > ? Greetings > ? Klara > ? > ? "Farshad (Sean) Tavallaei" wrote: > ? > ? > ??GKS, > ?? > ??Also, RFC 1586 section 3.2 is a good place to look at. Remember, the virtual > ??links are like the unnumbered links for OSPF. > ? > ? > ? Except for the virtual link you need the peer address, for unnumbered > ? point-to-point interface you don't. > ? > ? > ??From what I understand, when > ??sending an OSPF packet through a virtual link, you need to know the > ??destination IP address, which is supposed to be one of the interface IP > ??addresses of the remote ABR. If the remote ABR is connected through > ??unnumbered links only, you may not know any of its IP addresses. You may try > ??to use looking for a /32 in the router-LSA and using it as the dst if no > ??interface addresses are available, however, there may be situations where > ??this is just not possible (i.e., no loopback addresses are announced). > ?? > ??draft-ietf-isis-igp-p2p-over-lan-00.txt also has some good pointers. > ?? > ??Hope that helps, > ?? > ??Farshad > ?? > ??-----Original Message----- > ??From: Farshad (Sean) Tavallaei [mailto:farshad@onebox.com] > ??Sent: Wednesday, March 05, 2003 6:51 PM > ??To: Mailing List > ??Subject: RE: Un-numbered point to point. doubt > ?? > ??GKS, > ?? > ??RFC 1812 section 2.2.7 is a good start. I think I have seen this done with > ??Linux using virtual or logical IP addresses or interfaces, or even sometimes > ??loopback addresses for the unnumbered IP address. > ?? > ??I know that may not be much, but it is a start. > ?? > ??Good luck, > ?? > ??Farshad > ?? > ??-----Original Message----- > ??From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of kamatchi > ??soundaram > ??Sent: Wednesday, March 05, 2003 11:00 AM > ??To: OSPF@DISCUSS.MICROSOFT.COM > ??Subject: Un-numbered point to point. doubt > ?? > ??Hello all!, > ?? > ?? I presently working on OSPF un-numbered point to point support. I need > ??some clarification in implementing this support.. > ?? > ??Well! to support this un-numbered point to point, the IP need to support > ??this feature. If some body put some light on this it will be great! Yes! > ??even if get some general view about how the IP need to support the > ??un-numbered point to point of OSPF?? > ?? > ?? Is there any standard available for this?? > ?? > ??Well! what i know is: > ??* in case of un-numbered point to point, the one of valid IP address of > ??other interface will be assigned to this un-numbered p2p. So, that whenever > ??OSPF sends the packet, it will use this IP address as source address in the > ??IP header. But how exactly it is implemeted?? Especially in linux kind of > ??IP. (and stack). > ?? > ??Thanks, > ??GKS. > ??NEC america, > ??CA. > ? > ? > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 12:39:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02088 for ; Thu, 6 Mar 2003 12:39:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0091B8C8@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 12:41:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 685989 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 12:41:41 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 12:31:41 -0500 Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h26HVeS37469 for ; Thu, 6 Mar 2003 09:31:40 -0800 (PST) (envelope-from qv@juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h26HVe118803; Thu, 6 Mar 2003 09:31:40 -0800 (PST) (envelope-from qv) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200303061731.h26HVe118803@fuinar.juniper.net> Date: Thu, 6 Mar 2003 09:31:40 -0800 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit I think the main factor is the amount of flooding a router has to do which depends on how many adjacencies you have and how many LSAs you have to flood to each adjacency. So it is useful to divide your network into multiple areas so as to reduce flooding. Also large no. of adjacencies in a single area can result in rather large router LSAs which causes a lots of fragmentation and adds to the flooding load. Quaizar > I am in the midst of redesigning an OSPF network to accommodate > significant growth, especially in the Area 0 backbone. There has been > some concern about the size of the OSPF topology that would result and > whether the routing protocol would remain robust, able to handle the odd > flapping link or memory leak. The network in question is using high-end > routers with high speed links (at least DS-3). > > Are there any heuristics that someone has which may give us an idea of > the comfort zone in terms of the database size, number of neighbors, > routers, etc? > > Or, could someone share information on the size of large OSPF > implementations that they are aware of? > > I know that this issue is rather vague (clouded in too many unknowns) > and may only result in rather ambiguous > answers, but, one never knows. > > Thanks, > > Ravi > > > The information in this e-mail, and any attachment therein, is > confidential and for use by the addressee only. If you are not the > intended recipient, please return the e-mail to the sender and delete it > from your computer. Although The Bank of New York attempts to sweep > e-mail and attachments for viruses, it does not guarantee that either > are virus-free and accepts no liability for any damage sustained as a > result of viruses. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 13:09:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04039 for ; Thu, 6 Mar 2003 13:09:50 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0091BB6F@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 13:11:54 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 686155 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 13:11:54 -0500 Received: from 209.202.115.138 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 13:11:54 -0500 Received: (qmail 22548 invoked from network); 6 Mar 2003 18:19:32 -0000 Received: from unknown (HELO alcatel.com) (138.120.105.194) by kanmx1.ca.alcatel.com with SMTP; 6 Mar 2003 18:19:32 -0000 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <200303061731.h26HVe118803@fuinar.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E678F68.2D93337C@alcatel.com> Date: Thu, 6 Mar 2003 13:11:52 -0500 Reply-To: Mailing List Sender: Mailing List From: klara moser Organization: Alcatel CID Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Ravi, As far as I know the OSPF protocol has only one limitation on the topologies size - the Network and Router LSA size. The max is 64KB. This limits the number of links the router can have in a single area, because it has to advertise them in a single Router LSA. You can do the math. It is something like 5 000 links. Klara Quaizar Vohra wrote: > I think the main factor is the amount of flooding a router has to do > which depends on how many adjacencies you have and how many LSAs you > have to flood to each adjacency. So it is useful to divide your > network into multiple areas so as to reduce flooding. Also large > no. of adjacencies in a single area can result in rather large router > LSAs which causes a lots of fragmentation and adds to the flooding > load. > > Quaizar > > > I am in the midst of redesigning an OSPF network to accommodate > > significant growth, especially in the Area 0 backbone. There has been > > some concern about the size of the OSPF topology that would result and > > whether the routing protocol would remain robust, able to handle the odd > > flapping link or memory leak. The network in question is using high-end > > routers with high speed links (at least DS-3). > > > > Are there any heuristics that someone has which may give us an idea of > > the comfort zone in terms of the database size, number of neighbors, > > routers, etc? > > > > Or, could someone share information on the size of large OSPF > > implementations that they are aware of? > > > > I know that this issue is rather vague (clouded in too many unknowns) > > and may only result in rather ambiguous > > answers, but, one never knows. > > > > Thanks, > > > > Ravi > > > > > > The information in this e-mail, and any attachment therein, is > > confidential and for use by the addressee only. If you are not the > > intended recipient, please return the e-mail to the sender and delete it > > from your computer. Although The Bank of New York attempts to sweep > > e-mail and attachments for viruses, it does not guarantee that either > > are virus-free and accepts no liability for any damage sustained as a > > result of viruses. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 13:45:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05730 for ; Thu, 6 Mar 2003 13:45:33 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0091BB25@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 13:47:37 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 686245 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 13:47:37 -0500 Received: from 65.54.246.112 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 13:47:37 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 6 Mar 2003 10:47:36 -0800 X-Originating-IP: [64.221.212.131] References: <3E5C6F37.4060306@xebeo.com> <20030226.174811.112777204.yasu@sfc.wide.ad.jp> <3E5C89F6.9080900@xebeo.com> <20030226.212807.00986828.yasu@sfc.wide.ad.jp> <0a7001c2dd94$bb6ee320$81c802c0@alok> <3E5E0101.54E86F43@earthlink.net> <000d01c2de5d$f6d56460$81c802c0@alok> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 06 Mar 2003 18:47:36.0433 (UTC) FILETIME=[DAFBA610:01C2E410] Message-ID: Date: Thu, 6 Mar 2003 10:47:36 -0800 Reply-To: Mailing List Sender: Mailing List From: Ajay Virginkar Subject: Ospf Packet checksum To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, I have an issue where a router (from vendor X) complains of receiving checksum FFFF and expects a zero. I checked the OSPF mailing list archives but could not come to any conclusions from the previous discussion regarding this. Both sides are configured with no authentication. The question I guess is that, is it valid to send a checksum of 0 in the OSPF packet header. It seems that in the IP headers, a checksum of 0 is considered invalid. Does OSPF permit checksum of value 0? Thanks Ajay From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 14:17:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07309 for ; Thu, 6 Mar 2003 14:17:07 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0091BD2C@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 14:19:11 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 686310 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 14:19:11 -0500 Received: from 216.136.131.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 14:09:11 -0500 Received: from [192.25.240.225] by web11102.mail.yahoo.com via HTTP; Thu, 06 Mar 2003 11:09:08 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030306190908.42631.qmail@web11102.mail.yahoo.com> Date: Thu, 6 Mar 2003 11:09:08 -0800 Reply-To: Mailing List Sender: Mailing List From: Yenyi Fu Subject: Un-numbered point to point - OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi all, A follow on question, more specific to OSPFv3 for unnumbered point-to-point interfaces. Looking at RFC 2740, the generation of IntraAreaPrefix Lsa - referencing the router specifies: point-to-point link which has not been assigned a prefix,then the site-local and global scope IPv6 addresses associated with the interface (if any) are copied into the intra-area-prefix-LSA, setting the LA-bit in the PrefixOptions field, and setting the PrefixLength to 128 and the Metric to 0. What happens if the router does not have any site-local or global scope IPv6 associated with it? Is an IntraAreaPrefixLsa - Referencing the router still sent out for this router? What would be in the prefix, prefix option, and prefix length fields? Thanks, Yenyi __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 14:21:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07518 for ; Thu, 6 Mar 2003 14:21:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0091BE04@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 14:23:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 686348 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 14:23:59 -0500 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 14:23:59 -0500 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id h26JNub1002112 for ; Thu, 6 Mar 2003 11:23:56 -0800 (PST) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (/) with ESMTP id h26JNXSf005687 for ; Thu, 6 Mar 2003 11:23:33 -0800 (PST) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.8/8.12.8) with ESMTP id h26JDq3a022501 for ; Thu, 6 Mar 2003 11:13:53 -0800 (PST) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id h26JDpxc024053 for ; Thu, 6 Mar 2003 11:13:51 -0800 (PST) References: <3E676025.D75B471@alcatel.com> <3E676F67.30800@redback.com> <3E678255.D54EDD57@alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <038001c2e416$b5fd3940$1105f183@b90.tdd.sj.nec.com> Date: Thu, 6 Mar 2003 11:29:30 -0800 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Futher clarification needed-- Un-numbered point to point. doubt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, Thanks to all of u for ur valuable inputs. Now, i need some specific clarification.. Lets assume the following is the topoly: R1 R2 ____ ___ O----| ___|------------|___|------O E1 I1 I2 E2 The topology detail: 1) R1 and R2 are two routers. 2) E1 is ethernet and I1 is un-numbered p2p interface of R1. 3) Similarly E2 is ethernet and I2 is un-numbered p2p interface of R2. 4) Assume E1 is 192.168.12.1 (mask is 255.255.255.0) 5) Assume E2 is 192.168.13.1 (mask is 255.255.255.0) 6) Now as per RFC 1812 (un-numbered p2p support at IP), the interface I1 of R1 will borrow the IP address of E1 (192.168.12.1) and similarly I2 of R2 borrow the IP address of E2 (192.168.13.1) to specify the source address in the IP header. 7) Lets assume as per my stack implementation, OSPF uses RAW socket with IP header inclusion option, for the OSPF packet sending out. In this case, IP forward/trasmit will receive OSPF packet (Lets say Hello) and IP header with source as 192.168.12.1 and destination as Multicast address 224.0.0.5. Case 1: 8) IP will look into the route table to send the packet, obviously it could not find anything match for this detination, then either it may discard or just forward the packet to defualt destination (or gateway). In our case it is more probably the Lan interface. So in this case there is no chance of OSPF packet to be sent over the Un-numbered point to point interface. Case 2: If the above problem is because of using RAW socket, and will it be solved, if OSPF explicity specifies the interface Name/index through which the OSPF packet need to delivered, then IP will deliver it in the right interface?? Clarification 2: My other question is: do i need to specify the neighbor (other end of the interface) IP address, when i configure the Numbered point to point for OSPF?? Thanks in advance, GKS NEC America, CA USA. ----- Original Message ----- From: "klara moser" To: Sent: Thursday, March 06, 2003 9:16 AM Subject: Re: Un-numbered point to point. doubt > Thanks Acee, > > It is a broadcast address from OSPF protocol point of view, this is why I called it > "broadcast" :) > > Klara > > Acee Lindem wrote: > > > Klara, > > > > Just one clarification - AllSPFRouters (224.0.0.5) is > > a local-wire multicast address. I know this is what you meant but > > wanted to avoid confusion. > > > > klara moser wrote: > > ? Hi GKS, > > ? > > ? Actually, on a un-numbered point-to-point interface OSPF will send all its > > ? packets to the well defined All OSPF Routers "broadcast" address. In this case > > ? you do not need a uniquely defined IP address for the remote peer. The only > > ? requirement is that the layer two supports the OSPF "broadcast" address. > > ? > > ? Greetings > > ? Klara > > ? > > ? "Farshad (Sean) Tavallaei" wrote: > > ? > > ? > > ??GKS, > > ?? > > ??Also, RFC 1586 section 3.2 is a good place to look at. Remember, the virtual > > ??links are like the unnumbered links for OSPF. > > ? > > ? > > ? Except for the virtual link you need the peer address, for unnumbered > > ? point-to-point interface you don't. > > ? > > ? > > ??From what I understand, when > > ??sending an OSPF packet through a virtual link, you need to know the > > ??destination IP address, which is supposed to be one of the interface IP > > ??addresses of the remote ABR. If the remote ABR is connected through > > ??unnumbered links only, you may not know any of its IP addresses. You may try > > ??to use looking for a /32 in the router-LSA and using it as the dst if no > > ??interface addresses are available, however, there may be situations where > > ??this is just not possible (i.e., no loopback addresses are announced). > > ?? > > ??draft-ietf-isis-igp-p2p-over-lan-00.txt also has some good pointers. > > ?? > > ??Hope that helps, > > ?? > > ??Farshad > > ?? > > ??-----Original Message----- > > ??From: Farshad (Sean) Tavallaei [mailto:farshad@onebox.com] > > ??Sent: Wednesday, March 05, 2003 6:51 PM > > ??To: Mailing List > > ??Subject: RE: Un-numbered point to point. doubt > > ?? > > ??GKS, > > ?? > > ??RFC 1812 section 2.2.7 is a good start. I think I have seen this done with > > ??Linux using virtual or logical IP addresses or interfaces, or even sometimes > > ??loopback addresses for the unnumbered IP address. > > ?? > > ??I know that may not be much, but it is a start. > > ?? > > ??Good luck, > > ?? > > ??Farshad > > ?? > > ??-----Original Message----- > > ??From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of kamatchi > > ??soundaram > > ??Sent: Wednesday, March 05, 2003 11:00 AM > > ??To: OSPF@DISCUSS.MICROSOFT.COM > > ??Subject: Un-numbered point to point. doubt > > ?? > > ??Hello all!, > > ?? > > ?? I presently working on OSPF un-numbered point to point support. I need > > ??some clarification in implementing this support.. > > ?? > > ??Well! to support this un-numbered point to point, the IP need to support > > ??this feature. If some body put some light on this it will be great! Yes! > > ??even if get some general view about how the IP need to support the > > ??un-numbered point to point of OSPF?? > > ?? > > ?? Is there any standard available for this?? > > ?? > > ??Well! what i know is: > > ??* in case of un-numbered point to point, the one of valid IP address of > > ??other interface will be assigned to this un-numbered p2p. So, that whenever > > ??OSPF sends the packet, it will use this IP address as source address in the > > ??IP header. But how exactly it is implemeted?? Especially in linux kind of > > ??IP. (and stack). > > ?? > > ??Thanks, > > ??GKS. > > ??NEC america, > > ??CA. > > ? > > ? > > > > -- > > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 15:07:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10016 for ; Thu, 6 Mar 2003 15:07:56 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0091BE10@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 15:10:00 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663196 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 15:10:00 -0500 Received: from 207.159.120.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 15:10:00 -0500 Received: by xmxpita.excite.com (Postfix, from userid 110) id 3F7F23E1E; Thu, 6 Mar 2003 15:09:52 -0500 (EST) Received: from [64.47.48.10] by xprdmailfe9.nwk.excite.com via HTTP; Thu, 06 Mar 2003 15:09:52 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20030306200952.3F7F23E1E@xmxpita.excite.com> Date: Thu, 6 Mar 2003 15:09:52 -0500 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Ospf Packet checksum To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Ajay, I'm not a checksum calculation expert (there are others on this list who are, and can explain this further), but as I understand it, a Fletcher-computed checksum such as what OSPF uses, cannot result in a zero value 0x0000. The only time that OSPF does use a zero checksum value is when message-digest (MD5) authentication is used. There's a blurb on this in the appendix (E, I believe) in RFC2328. -don --- On Thu 03/06, Ajay Virginkar < virgink@HOTMAIL.COM > wrote: From: Ajay Virginkar [mailto: virgink@HOTMAIL.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Thu, 6 Mar 2003 10:47:36 -0800 Subject: Ospf Packet checksum Hi, I have an issue where a router (from vendor X) complains of receiving checksum FFFF and expects a zero. I checked the OSPF mailing list archives but could not come to any conclusions from the previous discussion regarding this. Both sides are configured with no authentication. The question I guess is that, is it valid to send a checksum of 0 in the OSPF packet header. It seems that in the IP headers, a checksum of 0 is considered invalid. Does OSPF permit checksum of value 0? Thanks Ajay _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 16:03:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12392 for ; Thu, 6 Mar 2003 16:03:29 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0091C075@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 16:05:32 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663319 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 16:05:32 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 16:05:32 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA07575 for ; Thu, 6 Mar 2003 16:05:29 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA20227 for ; Thu, 6 Mar 2003 16:05:30 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 16:05:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557634EE@vie-msgusr-01.dc.fore.com> Date: Thu, 6 Mar 2003 16:05:26 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Futher clarification needed-- Un-numbered point to point. dou bt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Kamatchi, -> IP header with -> source as 192.168.12.1 and destination as Multicast address 224.0.0.5. -> Case 1: -> 8) IP will look into the route table to send the packet, -> obviously it could -> not find anything match for this detination, then either it -> may discard or -> just forward the packet to defualt destination (or gateway). -> In our case it -> is more probably the Lan interface. So in this case there is -> no chance of -> OSPF packet to be sent over the Un-numbered point to point interface. No need to look into the (unicast) route table for multicast addresses. The destination address in the IP packet is 224.0.0.5 (which is link local multicast). Multicasting is specific to per interface - (I,G). So, if you know the outgoing interface, then enable multicasting on that interface and send the packet out. To support unnumbered interfaces, socket APIs (in most of the operating systems) are not sufficient. Richard Stevens writes in "UNIX Network Programming - Networking APIs: Sockets and XTI", Volume 1, Second Edition, Page 497: . . . When the interface on which to join is not specified, Berkeley- derived kernels look up the multicast address in the normal IP routing table and use the resulting interface (p. 357 of TCPv2). Some systems install a route for all multicast addresses (that is, a route with a destination of 224.0.0.0/8 for IPv4) upon initialization to handle this scenario. The change was made with IPv6 to use an interface index to specify the interface, instead of the local unicast address that is used with IPv4, to allow joins on unnumbered interfaces and tunnel endpoints. This is why interface name and index functions that we described in Section 17.6 were introduced with RFC2133 ... ... With my knowledge in BSD & Linux OS, I strongly suggest you to enhance the "bind"ing to specify interface index along with IP address (in other words, socket binds to the interface directly - provided you use socket per interface). If you support shared sockets ('m' sockets per 'n' interfaces with any to any connectivity) then you got to do additional work. -> Case 2: If the above problem is because of using RAW socket, -> and will it be -> solved, if OSPF explicitly specifies the interface Name/index -> through which -> the OSPF packet need to delivered, then IP will deliver it -> in the right -> interface?? Yes. Explained above. Remember, you can use some of the socket options (if I remember correctly, ROUTETOIF, SO_DONTROUTE etc socket options) to force the packet out to an interface (but I think those options sets the TTL to 1 - check out). -> Clarification 2: My other question is: do i need to specify -> the neighbor -> (other end of the interface) IP address, when i configure -> the Numbered point -> to point for OSPF?? Not necessary. It is the trade-off I observed. When you provide neighbor address in the interface configuration itself then you can immediately add (a specific) route to reach the neighbor to your route table. If not, the only way you can learn the reachability to the neighbor address is when the Layer 3 routing protocol converges. I would like to clear some of the historical doubts w.r.t unnumbered interfaces (I am lazy to write a draft). The way you configure L2/L3 interfaces dictates you on how you add/delete/modify delete routes from routing table. Layer 3 Routing protocols tell us the "prefix (destination) to nexthop (gateway)" resolution. Operating system performs the "gateway -> outgoing interface" resolution. In the case of unnumbered, Layer 3 protocol must provide the local interface index when resolving prefixes so that operating system can find the outgoing interface without any gateway address (just because there is no gateway address for unnumbered links). Let me know if something is not clear. Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 16:22:25 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13113 for ; Thu, 6 Mar 2003 16:22:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0091BFEB@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 16:24:26 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663383 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 16:24:26 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 16:24:26 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA08153 for ; Thu, 6 Mar 2003 16:24:23 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22437 for ; Thu, 6 Mar 2003 16:24:23 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 16:24:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557634EF@vie-msgusr-01.dc.fore.com> Date: Thu, 6 Mar 2003 16:24:19 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Futher clarification needed-- Un-numbered point to point. dou bt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -> With my knowledge in BSD & Linux OS, I strongly suggest you -> to enhance the "bind"ing to specify interface index along with -> IP address Let me be more specific here: theoretially, bind system call is supposed to be used to figure out the appropriate socket for incoming packets (some times it's used to set the outgoing packet's source IP address). It is not supposed to be used for figuring out the outgoing interace (or bypassing the route lookups etc). What I meant by "bind"ing is, multicast binding to an interface. You can use the existing socket options, IP_ADD_MEMBERSHIP (for receive-binding) or IP_MULTICAST_IF (for send-binding) or enhance kernel for your own socket option (for example, look at IP_RECVIF option open source code written by Bill) Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 17:01:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15102 for ; Thu, 6 Mar 2003 17:01:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0091C2D9@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 17:03:33 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663470 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 17:03:33 -0500 Received: from 65.54.246.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 17:03:33 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 6 Mar 2003 14:03:32 -0800 X-Originating-IP: [64.221.212.131] References: <20030306200952.3F7F23E1E@xmxpita.excite.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 06 Mar 2003 22:03:32.0832 (UTC) FILETIME=[3A57C600:01C2E42C] Message-ID: Date: Thu, 6 Mar 2003 14:03:32 -0800 Reply-To: Mailing List Sender: Mailing List From: Ajay Virginkar Subject: Re: Ospf Packet checksum To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Fletcher's algo is used for LS Checksum. I think for the ospf packet checksum, we use the standard IP checksum mechanism. There is a reference to this special case for checksum values in RFC 1624 which throws some light on this issue. Ajay ----- Original Message ----- From: "Don Goodspeed" To: Sent: Thursday, March 06, 2003 12:09 PM Subject: Re: Ospf Packet checksum > Ajay, > > I'm not a checksum calculation expert (there are others on this > list who are, and can explain this further), but as I understand > it, a Fletcher-computed checksum such as what OSPF uses, cannot > result in a zero value 0x0000. > > The only time that OSPF does use a zero checksum value is when > message-digest (MD5) authentication is used. There's a blurb > on this in the appendix (E, I believe) in RFC2328. > > -don > > --- On Thu 03/06, Ajay Virginkar < virgink@HOTMAIL.COM > wrote: > From: Ajay Virginkar [mailto: virgink@HOTMAIL.COM] > To: OSPF@DISCUSS.MICROSOFT.COM > Date: Thu, 6 Mar 2003 10:47:36 -0800 > Subject: Ospf Packet checksum > > Hi, > I have an issue where a router (from vendor X) complains of receiving > checksum FFFF and expects a zero. I checked the OSPF mailing list archives > but could not come to any conclusions from the previous discussion regarding > this. > Both sides are configured with no authentication. The question I guess is > that, is it valid to send a checksum of 0 in the OSPF packet header. It > seems that in the IP headers, a checksum of 0 is considered invalid. Does > OSPF permit checksum of value 0? > Thanks > Ajay > > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 17:16:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15558 for ; Thu, 6 Mar 2003 17:16:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0091C244@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 17:18:38 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663503 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 17:18:38 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 17:18:38 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 3E92F1E0932 for ; Thu, 6 Mar 2003 14:16:43 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030306200952.3F7F23E1E@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E67C9B9.407@redback.com> Date: Thu, 6 Mar 2003 17:20:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Ospf Packet checksum To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Don, One correction. Don Goodspeed wrote: > Ajay, > > I'm not a checksum calculation expert (there are others on this > list who are, and can explain this further), but as I understand > it, a Fletcher-computed checksum such as what OSPF uses, cannot > result in a zero value 0x0000. While LSAs use a fletcher checksum, OSPF packets use the internet checksum originally described in RFC 1071. I don't remember enough about the properties of the inet checksum to say for sure that it couldn't result in a value of 0x0000. Perhaps someone else could comment. > > The only time that OSPF does use a zero checksum value is when > message-digest (MD5) authentication is used. There's a blurb > on this in the appendix (E, I believe) in RFC2328. > > -don > > --- On Thu 03/06, Ajay Virginkar < virgink@HOTMAIL.COM > wrote: > From: Ajay Virginkar [mailto: virgink@HOTMAIL.COM] > To: OSPF@DISCUSS.MICROSOFT.COM > Date: Thu, 6 Mar 2003 10:47:36 -0800 > Subject: Ospf Packet checksum > > Hi, > I have an issue where a router (from vendor X) complains of receiving > checksum FFFF and expects a zero. I checked the OSPF mailing list archives > but could not come to any conclusions from the previous discussion regarding > this. > Both sides are configured with no authentication. The question I guess is > that, is it valid to send a checksum of 0 in the OSPF packet header. It > seems that in the IP headers, a checksum of 0 is considered invalid. Does > OSPF permit checksum of value 0? > Thanks > Ajay > > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 17:57:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16669 for ; Thu, 6 Mar 2003 17:57:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0091C330@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 17:59:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663570 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 17:59:57 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 17:59:57 -0500 Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h26MxuS63778 for ; Thu, 6 Mar 2003 14:59:56 -0800 (PST) (envelope-from dennis@juniper.net) X-Mailer: exmh version 2.0.2 2/24/98 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200303062259.h26MxuS63778@merlot.juniper.net> Date: Thu, 6 Mar 2003 14:59:56 -0800 Reply-To: Mailing List Sender: Mailing List From: Dennis Ferguson Subject: Re: Ospf Packet checksum To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Your message of "Thu, 06 Mar 2003 10:47:36 PST." Precedence: list Ajay, > It > seems that in the IP headers, a checksum of 0 is considered invalid. This part is wrong. If you study the calculations in RFC 1071 very carefully you'll discover that in almost all cases they produce checksum values in the range 0-0xfffe, and it is 0xffff which is unlikely to appear in the checksum field. This is also the way most people implement the checksum in the IP and TCP headers, in fact the only special case I know of which is specified to work your way is the UDP checksum. Since the OSPF checksum is not special-cased like UDP is, the best assumption is that it was intended that you compute it like RFC 1071 does. Note that the receiver in this case is certainly broken since, given how RFC 1071 defines a 1's complement sum and how it specifies that the checksum should be checked, the values 0xffff and 0x0000 in the header should produce identical check values (except in the very special case that the rest of the data being checksummed is all-zeros, in which case only 0xffff works). To be conservative, however, you should probably do your checksum computation *exactly* the way RFC 1071 does it, and the RFC 1071 computations (usually) produce 0-valued checksums rather than 0xffff. Dennis Ferguson From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 18:11:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17836 for ; Thu, 6 Mar 2003 18:11:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0091C5B0@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 18:13:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663626 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 18:13:36 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 18:13:36 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA10207 for ; Thu, 6 Mar 2003 18:13:29 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA02282 for ; Thu, 6 Mar 2003 18:13:31 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 18:13:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557634F0@vie-msgusr-01.dc.fore.com> Date: Thu, 6 Mar 2003 18:13:24 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Ospf Packet checksum To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -> To be conservative, however, you -> should probably do your checksum computation *exactly* the -> way RFC 1071 does it, and the RFC 1071 computations (usually) -> produce 0-valued checksums rather than 0xffff. Correction. RFC 1141 obsoletes RFC 1071. But I prefer RFC 1624 which updates RFC 1141. RFC 1624 reads: ... In one's complement, there are two representations of zero: the all zero and the all one bit values, often referred to as +0 and -0. One's complement addition of non-zero inputs can produce -0 as a result, but never +0. Since there is guaranteed to be at least one non-zero field in the IP header, and the checksum field in the protocol header is the complement of the sum, the checksum field can never contain ~(+0), which is -0 (0xFFFF). It can, however, contain ~(-0), which is +0 (0x0000). ... Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 18:51:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19907 for ; Thu, 6 Mar 2003 18:51:39 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0091C480@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 18:53:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663744 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 18:53:42 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 18:53:42 -0500 Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h26NrfS67942 for ; Thu, 6 Mar 2003 15:53:41 -0800 (PST) (envelope-from dennis@juniper.net) X-Mailer: exmh version 2.0.2 2/24/98 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200303062353.h26NrfS67942@merlot.juniper.net> Date: Thu, 6 Mar 2003 15:53:41 -0800 Reply-To: Mailing List Sender: Mailing List From: Dennis Ferguson Subject: Re: Ospf Packet checksum To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Your message of "Thu, 06 Mar 2003 18:13:24 EST." <39469E08BD83D411A3D900204840EC557634F0@vie-msgusr-01.dc.fore.com> Precedence: list > -> To be conservative, however, you > -> should probably do your checksum computation *exactly* the > -> way RFC 1071 does it, and the RFC 1071 computations (usually) > -> produce 0-valued checksums rather than 0xffff. > > Correction. RFC 1141 obsoletes RFC 1071. But I prefer RFC 1624 > which updates RFC 1141. RFC 1624 reads: That's no correction. RFC's 1141 and 1624 update 1071 only with respect to the computation of incremental updates of the IP header checksum, a topic which takes up less than half of one page out of RFC 1071's 24 pages and is not relevant to the issue of how to compute a checksum for the OSPF packet. RFC 1071 is still the canonical reference for the computation of the IP 1's complement checksum, the other papers don't cover that. Dennis Ferguson From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 19:48:32 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22005 for ; Thu, 6 Mar 2003 19:48:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0091C71E@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 19:50:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663924 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 19:50:35 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 19:50:35 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 281EE233DF; Fri, 7 Mar 2003 09:50:34 +0900 (JST) References: <20030306190908.42631.qmail@web11102.mail.yahoo.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030307.095033.119927566.yasu@sfc.wide.ad.jp> Date: Fri, 7 Mar 2003 09:50:33 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Un-numbered point to point - OSPFv3 Comments: To: yenyifu@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030306190908.42631.qmail@web11102.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit > What happens if the router does not have any > site-local or global scope IPv6 associated with it? > Is an IntraAreaPrefixLsa - Referencing the router > still sent out for this router? What would be in the > prefix, prefix option, and prefix length fields? Hi, my interpretation is that the router should not send any Intra-Area-Prefix-LSA which refers the router itself, in that case. It is not needed, and further it will corrupt routing someway because of the bogus prefix field, and because of the consequence that every other router will consume his CPU to calculate the bogus prefix's route. There's no way for a router to detect if other routers have some stub prefixes, other than to check whether the routers originate any Intra-Area-Prefix-LSA or not. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 6 23:31:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27249 for ; Thu, 6 Mar 2003 23:31:29 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0091CD3F@cherry.ease.lsoft.com>; Thu, 6 Mar 2003 23:33:31 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664337 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Mar 2003 23:33:31 -0500 Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Mar 2003 23:33:31 -0500 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h274XUdG022039 for ; Thu, 6 Mar 2003 21:33:30 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id VAA14721 for ; Thu, 6 Mar 2003 21:31:36 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Mar 2003 23:33:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 6 Mar 2003 23:35:23 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Ospf Packet checksum To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, A similar issue came up on the list last year http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0205&L=OSPF&P=R6701&I= -3&m=3446 Thanks, Vishwas -----Original Message----- From: Dennis Ferguson [mailto:dennis@JUNIPER.NET] Sent: Friday, March 07, 2003 5:24 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Ospf Packet checksum > -> To be conservative, however, you > -> should probably do your checksum computation *exactly* the > -> way RFC 1071 does it, and the RFC 1071 computations (usually) > -> produce 0-valued checksums rather than 0xffff. > > Correction. RFC 1141 obsoletes RFC 1071. But I prefer RFC 1624 > which updates RFC 1141. RFC 1624 reads: That's no correction. RFC's 1141 and 1624 update 1071 only with respect to the computation of incremental updates of the IP header checksum, a topic which takes up less than half of one page out of RFC 1071's 24 pages and is not relevant to the issue of how to compute a checksum for the OSPF packet. RFC 1071 is still the canonical reference for the computation of the IP 1's complement checksum, the other papers don't cover that. Dennis Ferguson From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 7 00:32:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00090 for ; Fri, 7 Mar 2003 00:32:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0091CD2B@cherry.ease.lsoft.com>; Fri, 7 Mar 2003 0:34:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664490 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 7 Mar 2003 00:34:26 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Mar 2003 00:34:26 -0500 Received: from alok ([203.124.140.97]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h275uRr07572 for ; Fri, 7 Mar 2003 11:26:28 +0530 References: <39469E08BD83D411A3D900204840EC557634EF@vie-msgusr-01.dc.fore.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <02a701c2e46b$6f47b840$81c802c0@alok> Date: Fri, 7 Mar 2003 11:05:45 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Futher clarification needed-- Un-numbered point to point. dou bt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list pardon me if this is off topic but i needed to know if someone could help me here, imr_addr is the address to which the IP_ADD_MEMBERSHIP is done to use receive binding... what i wish to know is that when i use INADDR_ANY as its value, will it bind to "any/all physical interface" or only "1 interface" which it randomly chooses? ( i beleive it is different across different unix flavours) most of the stuff i looked up was from man 7 ip and here: http://www.cs.unc.edu/~jeffay/dirt/FAQ/comp249-001-F99/mcast-socket.html the same seems to work on one redhat linux version but not the other.... would appreciate any help.. -rgds Alok ----- Original Message ----- From: Naidu, Venkata To: Sent: Friday, March 07, 2003 2:54 AM Subject: Re: Futher clarification needed-- Un-numbered point to point. dou bt > -> With my knowledge in BSD & Linux OS, I strongly suggest you > -> to enhance the "bind"ing to specify interface index along with > -> IP address > > Let me be more specific here: theoretially, bind system call > is supposed to be used to figure out the appropriate socket > for incoming packets (some times it's used to set the > outgoing packet's source IP address). It is not supposed to > be used for figuring out the outgoing interace (or bypassing > the route lookups etc). > > What I meant by "bind"ing is, multicast binding to an interface. > You can use the existing socket options, IP_ADD_MEMBERSHIP > (for receive-binding) or IP_MULTICAST_IF (for send-binding) or > enhance kernel for your own socket option (for example, > look at IP_RECVIF option open source code written by Bill) > > Venkata. > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 7 00:41:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00296 for ; Fri, 7 Mar 2003 00:41:03 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0091CD8A@cherry.ease.lsoft.com>; Fri, 7 Mar 2003 0:43:06 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664485 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 7 Mar 2003 00:43:06 -0500 Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Mar 2003 00:33:05 -0500 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h275X5dG002773 for ; Thu, 6 Mar 2003 22:33:05 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id WAA15513 for ; Thu, 6 Mar 2003 22:33:04 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 00:32:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2E46B.1FC56920" Message-ID: Date: Fri, 7 Mar 2003 00:33:46 -0500 Reply-To: Mailing List Sender: Mailing List From: "Banwari, Amit" Subject: dont take the previous one.. take this To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C2E46B.1FC56920 Content-Type: text/plain; charset="iso-8859-1" ------_=_NextPart_000_01C2E46B.1FC56920 Content-Type: text/plain; name="isis_18_mono.txt" Content-Disposition: attachment; filename="isis_18_mono.txt" Content-Transfer-Encoding: quoted-printable main (ac,av) { var node_number =3D av[1]; var subnet =3D av[2]; var card_num =3D av[3]; if(ac < 4) return; =20 =20 /* COMMON TO EVERY NODE : ALL NODES MUST DEFINE THESE */=20 gl_node.num =3D node_number; gl_node.log_name =3D "mynet" + node_number + ".log"; gl_node.log_mask =3D 0xFFFFFFFF; =20 /* ISIS */ /* WILL DEFAULT IF NOT DEFINED TO THE VALUE OF 1 */ gl_node.notify_key =3D 1; gl_node.export_key =3D 1; gl_node.opaque_key =3D 1; gl_node.fib.key =3D 1; gl_node.fib.vrid =3D 1; gl_node.mab.key =3D 1; gl_node.isis.key =3D 1; gl_node.policy.key =3D 1; gl_node.bgp.key =3D 1; gl_node.rip.key =3D 1; gl_node.ospf.key =3D 1; gl_node.pols.key =3D 1; gl_node.polc.key =3D 1; gl_node.isis.enable =3D1; gl_node.bgp.enable =3D0; gl_node.ospf.enable =3D0; gl_node.rip.enable =3D0; =20 /* iprp_ake variables */ =20 my_rid =3D gl_node.num; my_slot_num =3D card_num ; gl_fib_key =3D gl_node.fib.key; gl_fibs_key =3D gl_node.fib.key; gl_fibc_key =3D gl_node.fib.key; gl_isis_key =3D gl_node.isis.key; gl_pols_key =3D gl_node.pols.key; gl_polc_key =3D gl_node.polc.key; isis_node_list[1].key_num =3D gl_node.isis.key; fibs_key =3D gl_node.fib.key; switch(node_number) { case 1: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.1"; gl_node.sys_id =3D "abcdea"; gl_node.sys_type =3D 1; /* L1 IS */ /* Manual Area Addresses */ =20 gl_node.area1 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xaa"; gl_node.area2 =3D ""; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 1; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.12.1"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 12000; gl_node.card[1].iface[1].local_mac =3D = "\x01\x1a\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].remote_port =3D 21000; gl_node.card[1].iface[1].remote_mac =3D = "\x01\x1b\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 1; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; =20 gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1; =20 =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.13.1"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 13000; gl_node.card[1].iface[2].local_mac =3D = "\x01\x2a\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].remote_port =3D 31000; gl_node.card[1].iface[2].remote_mac =3D = "\x01\x1c\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 1; =09 gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; =09 gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1 ; /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[3].if_index =3D 3; gl_node.card[1].iface[3].if_sub_index =3D 0; gl_node.card[1].iface[3].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[3].if_mtu =3D 1024; gl_node.card[1].iface[3].ckt_index =3D 3; gl_node.card[1].iface[3].local_ip_addr =3D "172.32.14.1"; gl_node.card[1].iface[3].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[3].local_port =3D 14000; gl_node.card[1].iface[3].local_mac =3D = "\x01\x3a\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[3].remote_port =3D 41000; gl_node.card[1].iface[3].remote_mac =3D = "\x01\x1d\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[3].conn_info =3D 0; gl_node.card[1].iface[3].sim_server =3D 1; gl_node.card[1].iface[3].lvl1_priority =3D node_number; gl_node.card[1].iface[3].lvl1_metric =3D node_number; gl_node.card[1].iface[3].lvl2_priority =3D node_number; gl_node.card[1].iface[3].lvl2_metric =3D node_number; =09 =20 gl_node.card[1].iface[3].meshgrp_enable =3D 1; gl_node.card[1].iface[3].meshgrp_id =3D 1;=20 =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[4].if_index =3D 4; gl_node.card[1].iface[4].if_sub_index =3D 0; gl_node.card[1].iface[4].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[4].if_mtu =3D 1024; gl_node.card[1].iface[4].ckt_index =3D 4; gl_node.card[1].iface[4].local_ip_addr =3D "10.10.10.1"; gl_node.card[1].iface[4].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[4].local_port =3D 18000; gl_node.card[1].iface[4].local_mac =3D = "\x01\x4a\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[4].remote_port =3D 81000; gl_node.card[1].iface[4].remote_mac =3D = "\x01\x18\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[4].conn_info =3D 0; gl_node.card[1].iface[4].sim_server =3D 1; gl_node.card[1].iface[4].lvl1_priority =3D node_number; gl_node.card[1].iface[4].lvl1_metric =3D node_number; gl_node.card[1].iface[4].lvl2_priority =3D node_number; gl_node.card[1].iface[4].lvl2_metric =3D node_number; =20 gl_node.card[1].iface[4].meshgrp_enable =3D 1; gl_node.card[1].iface[4].meshgrp_id =3D 1;=20 =20 break; case 2: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.2"; gl_node.sys_id =3D "abcdeb"; gl_node.sys_type =3D 3; /* L1L2 IS */ /* Manual Area Addresses */ gl_node.area1 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xaa"; gl_node.area2 =3D ""; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 2; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.12.2"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 21000; gl_node.card[1].iface[1].local_mac =3D = "\x01\x1b\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].remote_port =3D 12000; gl_node.card[1].iface[1].remote_mac =3D = "\x01\x1a\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; =20 gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1; =20 gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.23.2"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 23000; gl_node.card[1].iface[2].local_mac =3D = "\x01\x2b\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].remote_port =3D 32000; gl_node.card[1].iface[2].remote_mac =3D = "\x01\x2c\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 1; gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; =20 gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1 ;=20 =20 gl_node.card[1].iface[3].if_index =3D 3; gl_node.card[1].iface[3].if_sub_index =3D 0; gl_node.card[1].iface[3].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[3].if_mtu =3D 1024; gl_node.card[1].iface[3].ckt_index =3D 3; gl_node.card[1].iface[3].local_ip_addr =3D "172.32.25.2"; gl_node.card[1].iface[3].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[3].local_port =3D 25000; gl_node.card[1].iface[3].local_mac =3D = "\x01\x3b\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[3].remote_port =3D 52000; gl_node.card[1].iface[3].remote_mac =3D = "\x01\x1e\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[3].conn_info =3D 0; gl_node.card[1].iface[3].sim_server =3D 1; gl_node.card[1].iface[3].lvl1_priority =3D node_number; gl_node.card[1].iface[3].lvl1_metric =3D node_number; gl_node.card[1].iface[3].lvl2_priority =3D node_number; gl_node.card[1].iface[3].lvl2_metric =3D node_number; gl_node.card[1].iface[3].meshgrp_enable =3D 1; gl_node.card[1].iface[3].meshgrp_id =3D 1;=20 gl_node.card[1].iface[4].if_index =3D 4; gl_node.card[1].iface[4].if_sub_index =3D 0; gl_node.card[1].iface[4].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[4].if_mtu =3D 1024; gl_node.card[1].iface[4].ckt_index =3D 4; gl_node.card[1].iface[4].local_ip_addr =3D "172.32.26.2"; gl_node.card[1].iface[4].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[4].local_port =3D 26000; gl_node.card[1].iface[4].local_mac =3D = "\x01\x4b\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[4].remote_port =3D 62000; gl_node.card[1].iface[4].remote_mac =3D = "\x01\x1f\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[4].conn_info =3D 0; gl_node.card[1].iface[4].sim_server =3D 1; gl_node.card[1].iface[4].lvl1_priority =3D node_number; gl_node.card[1].iface[4].lvl1_metric =3D node_number; gl_node.card[1].iface[4].lvl2_priority =3D node_number; gl_node.card[1].iface[4].lvl2_metric =3D node_number; gl_node.card[1].iface[4].meshgrp_enable =3D 1; gl_node.card[1].iface[4].meshgrp_id =3D 1; gl_node.card[1].iface[5].if_index =3D 5; gl_node.card[1].iface[5].if_sub_index =3D 0; gl_node.card[1].iface[5].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[5].if_mtu =3D 1024; gl_node.card[1].iface[5].ckt_index =3D 5; gl_node.card[1].iface[5].local_ip_addr =3D "172.32.27.2"; gl_node.card[1].iface[5].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[5].local_port =3D 27000; gl_node.card[1].iface[5].local_mac =3D = "\x01\x5b\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[5].remote_port =3D 72000; gl_node.card[1].iface[5].remote_mac =3D = "\x01\x17\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[5].conn_info =3D 0; gl_node.card[1].iface[5].sim_server =3D 1; gl_node.card[1].iface[5].lvl1_priority =3D node_number; gl_node.card[1].iface[5].lvl1_metric =3D node_number; gl_node.card[1].iface[5].lvl2_priority =3D node_number; gl_node.card[1].iface[5].lvl2_metric =3D node_number; gl_node.card[1].iface[5].meshgrp_enable =3D 1; gl_node.card[1].iface[5].meshgrp_id =3D 1;=20 =09 gl_node.card[1].iface[6].if_index =3D 6; gl_node.card[1].iface[6].local_ip_addr =3D "172.32.212.2"; gl_node.card[1].iface[6].com_type =3D "bcast"; /* "bcast" | = "ptp" */ gl_node.card[1].iface[6].if_sub_index =3D 0; gl_node.card[1].iface[6].ckt_index =3D 6; gl_node.card[1].iface[6].if_mtu =3D 1024;=20 gl_node.card[1].iface[6].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[6].local_port =3D 20012; gl_node.card[1].iface[6].local_mac =3D = "\x02\x12\x02\x12\x02\x12\0x00"; gl_node.card[1].iface[6].remote_port =3D 12002; gl_node.card[1].iface[6].remote_mac =3D = "\x12\x02\x12\x02\x12\x02\0x00"; gl_node.card[1].iface[6].conn_info =3D 0; gl_node.card[1].iface[6].sim_server =3D 1; gl_node.card[1].iface[6].lvl1_priority =3D node_number; gl_node.card[1].iface[6].lvl1_metric =3D node_number; gl_node.card[1].iface[6].lvl2_priority =3D node_number; gl_node.card[1].iface[6].lvl2_metric =3D node_number; gl_node.card[1].iface[6].meshgrp_enable =3D 1; gl_node.card[1].iface[6].meshgrp_id =3D 1;=20 =09 gl_node.card[1].iface[7].if_index =3D 7; gl_node.card[1].iface[7].local_ip_addr =3D "172.32.215.2"; gl_node.card[1].iface[7].if_sub_index =3D 0; gl_node.card[1].iface[7].com_type =3D "bcast"; /* "bcast" | = "ptp" */ gl_node.card[1].iface[7].ckt_index =3D 7; gl_node.card[1].iface[7].if_mtu =3D 1024;=20 gl_node.card[1].iface[7].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[7].local_port =3D 20015; gl_node.card[1].iface[7].local_mac =3D = "\x02\x15\x02\x15\x02\x15\0x00"; gl_node.card[1].iface[7].remote_port =3D 15002; gl_node.card[1].iface[7].remote_mac =3D = "\x15\x02\x15\x02\x15\x02\0x00"; gl_node.card[1].iface[7].conn_info =3D 0; gl_node.card[1].iface[7].sim_server =3D 1; gl_node.card[1].iface[7].lvl1_priority =3D node_number; gl_node.card[1].iface[7].lvl1_metric =3D node_number; gl_node.card[1].iface[7].lvl2_priority =3D node_number; gl_node.card[1].iface[7].lvl2_metric =3D node_number; gl_node.card[1].iface[7].meshgrp_enable =3D 1; gl_node.card[1].iface[7].meshgrp_id =3D 1;=20 =20 =20 /* ISIS fields only */ gl_node.card[1].iface[8].if_index =3D 8; gl_node.card[1].iface[8].local_ip_addr =3D "172.32.217.2"; gl_node.card[1].iface[8].if_sub_index =3D 0; gl_node.card[1].iface[8].com_type =3D "bcast"; /* "bcast" | = "ptp" */ gl_node.card[1].iface[8].ckt_index =3D 8; gl_node.card[1].iface[8].if_mtu =3D 1024;=20 gl_node.card[1].iface[8].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[8].local_port =3D 20017; gl_node.card[1].iface[8].local_mac =3D = "\x02\x17\x02\x17\x02\x17\0x00"; gl_node.card[1].iface[8].remote_port =3D 17002; gl_node.card[1].iface[8].remote_mac =3D = "\x17\x02\x17\x02\x17\x02\0x00"; gl_node.card[1].iface[8].conn_info =3D 0; gl_node.card[1].iface[8].sim_server =3D 1;=20 =09 gl_node.card[1].iface[8].lvl1_priority =3D node_number; gl_node.card[1].iface[8].lvl1_metric =3D node_number; gl_node.card[1].iface[8].lvl2_priority =3D node_number; gl_node.card[1].iface[8].lvl2_metric =3D node_number; gl_node.card[1].iface[8].meshgrp_enable =3D 1; gl_node.card[1].iface[8].meshgrp_id =3D 1;=20 break; case 3: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.3"; gl_node.sys_id =3D "abcdec"; gl_node.sys_type =3D 1; /* L1 IS */ /* Manual Area Addresses */ gl_node.area1 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xaa"; gl_node.area2 =3D ""; gl_node.area3 =3D ""; =20 =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.13.3"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 31000; gl_node.card[1].iface[1].local_mac =3D = "\x01\x1c\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].remote_port =3D 13000; gl_node.card[1].iface[1].remote_mac =3D = "\x01\x2a\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1;=20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.23.3"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 32000; gl_node.card[1].iface[2].local_mac =3D = "\x01\x2c\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].remote_port =3D 23000; gl_node.card[1].iface[2].remote_mac =3D = "\x01\x2b\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 0; gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1 ;=20 =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[3].if_index =3D 3; gl_node.card[1].iface[3].if_sub_index =3D 0; gl_node.card[1].iface[3].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[3].if_mtu =3D 1024; gl_node.card[1].iface[3].ckt_index =3D 3; gl_node.card[1].iface[3].local_ip_addr =3D "172.32.34.3"; gl_node.card[1].iface[3].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[3].local_port =3D 34000; gl_node.card[1].iface[3].local_mac =3D = "\x01\x3c\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[3].remote_port =3D 43000; gl_node.card[1].iface[3].remote_mac =3D = "\x01\x2d\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[3].conn_info =3D 0; gl_node.card[1].iface[3].sim_server =3D 1; gl_node.card[1].iface[3].lvl1_priority =3D node_number; gl_node.card[1].iface[3].lvl1_metric =3D node_number; gl_node.card[1].iface[3].lvl2_priority =3D node_number; gl_node.card[1].iface[3].lvl2_metric =3D node_number; gl_node.card[1].iface[3].meshgrp_enable =3D 1; gl_node.card[1].iface[3].meshgrp_id =3D 1;=20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[4].if_index =3D 4; gl_node.card[1].iface[4].if_sub_index =3D 0; gl_node.card[1].iface[4].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[4].if_mtu =3D 1024; gl_node.card[1].iface[4].ckt_index =3D 4; gl_node.card[1].iface[4].local_ip_addr =3D "10.10.12.3"; gl_node.card[1].iface[4].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[4].local_port =3D 39000; gl_node.card[1].iface[4].local_mac =3D = "\x01\x4c\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[4].remote_port =3D 93000; gl_node.card[1].iface[4].remote_mac =3D = "\x01\x19\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[4].conn_info =3D 0; gl_node.card[1].iface[4].sim_server =3D 1; gl_node.card[1].iface[4].lvl1_priority =3D node_number; gl_node.card[1].iface[4].lvl1_metric =3D node_number; gl_node.card[1].iface[4].lvl2_priority =3D node_number; gl_node.card[1].iface[4].lvl2_metric =3D node_number; gl_node.card[1].iface[4].meshgrp_enable =3D 1; gl_node.card[1].iface[4].meshgrp_id =3D 1;=20 =20 break; case 4: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.4"; gl_node.sys_id =3D "abcded"; gl_node.sys_type =3D 1; /* L1 IS */ /* Manual Area Addresses */ gl_node.area1 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xaa"; gl_node.area2 =3D ""; gl_node.area3 =3D ""; gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =09 =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.14.4"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 41000; gl_node.card[1].iface[1].local_mac =3D = "\x01\x1d\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].remote_port =3D 14000; gl_node.card[1].iface[1].remote_mac =3D = "\x01\x3a\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.34.4"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 43000; gl_node.card[1].iface[2].local_mac =3D = "\x01\x2d\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].remote_port =3D 34000; gl_node.card[1].iface[2].remote_mac =3D = "\x01\x3c\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 0; gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1 ;=20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[3].if_index =3D 3; gl_node.card[1].iface[3].if_sub_index =3D 0; gl_node.card[1].iface[3].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[3].if_mtu =3D 1024; gl_node.card[1].iface[3].ckt_index =3D 3; gl_node.card[1].iface[3].local_ip_addr =3D "10.10.11.4"; gl_node.card[1].iface[3].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[3].local_port =3D 40010; gl_node.card[1].iface[3].local_mac =3D = "\x01\x3d\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[3].remote_port =3D 10004; gl_node.card[1].iface[3].remote_mac =3D = "\x01\x10\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[3].conn_info =3D 0; gl_node.card[1].iface[3].sim_server =3D 1; gl_node.card[1].iface[3].lvl1_priority =3D node_number; gl_node.card[1].iface[3].lvl1_metric =3D node_number; gl_node.card[1].iface[3].lvl2_priority =3D node_number; gl_node.card[1].iface[3].lvl2_metric =3D node_number; gl_node.card[1].iface[3].meshgrp_enable =3D 1; gl_node.card[1].iface[3].meshgrp_id =3D 1;=20 /* ISIS fields only */ gl_node.card[1].iface[4].local_ip_addr =3D "172.32.49.4"; gl_node.card[1].iface[4].if_index =3D 4; gl_node.card[1].iface[4].if_sub_index =3D 0; gl_node.card[1].iface[4].com_type =3D "bcast"; /* "bcast" | = "ptp" */ gl_node.card[1].iface[4].ckt_index =3D 4; gl_node.card[1].iface[4].if_mtu =3D 1024;=20 gl_node.card[1].iface[4].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[4].local_port =3D 49000; gl_node.card[1].iface[4].local_mac =3D = "\x49\x94\x49\x94\x49\x94\0x00"; gl_node.card[1].iface[4].remote_port =3D 94000; gl_node.card[1].iface[4].remote_mac =3D = "\x94\x49\x94\x49\x94\x49\0x00"; gl_node.card[1].iface[4].conn_info =3D 0; gl_node.card[1].iface[4].sim_server =3D 1; =20 =09 gl_node.card[1].iface[4].lvl1_priority =3D node_number; gl_node.card[1].iface[4].lvl1_metric =3D node_number; gl_node.card[1].iface[4].lvl2_priority =3D node_number; gl_node.card[1].iface[4].lvl2_metric =3D node_number; gl_node.card[1].iface[4].meshgrp_enable =3D 1; gl_node.card[1].iface[4].meshgrp_id =3D 1;=20 break; case 5: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.5"; gl_node.sys_id =3D "abcdee"; gl_node.sys_type =3D 2; /* L2 IS */ /* Manual Area Addresses */ gl_node.area1 =3D ""; gl_node.area2 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xbb"; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; =20 =20 gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.25.5"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 52000; gl_node.card[1].iface[1].local_mac =3D = "\x01\x1e\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].remote_port =3D 25000; gl_node.card[1].iface[1].remote_mac =3D = "\x01\x3b\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1; =20 =09 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.56.5"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 56000; gl_node.card[1].iface[2].local_mac =3D = "\x01\x2e\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].remote_port =3D 65000; gl_node.card[1].iface[2].remote_mac =3D = "\x01\x2f\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 1; gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; =20 gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1 ; /* ISIS fields only */ gl_node.card[1].iface[3].if_index =3D 3; gl_node.card[1].iface[3].if_sub_index =3D 0; gl_node.card[1].iface[3].ckt_index =3D 3; gl_node.card[1].iface[3].com_type =3D "bcast"; /* "bcast" | = "ptp" */ gl_node.card[1].iface[3].local_ip_addr =3D "172.32.55.5"; gl_node.card[1].iface[3].if_mtu =3D 1024;=20 gl_node.card[1].iface[3].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[3].local_port =3D 50012; gl_node.card[1].iface[3].local_mac =3D = "\x05\x12\x05\x12\x05\x12\0x00"; gl_node.card[1].iface[3].remote_port =3D 12005; gl_node.card[1].iface[3].remote_mac =3D = "\x12\x05\x12\x05\x12\x05\0x00"; gl_node.card[1].iface[3].conn_info =3D 0; gl_node.card[1].iface[3].sim_server =3D 1; =20 gl_node.card[1].iface[3].lvl1_priority =3D node_number; gl_node.card[1].iface[3].lvl1_metric =3D node_number; gl_node.card[1].iface[3].lvl2_priority =3D node_number; gl_node.card[1].iface[3].lvl2_metric =3D node_number; gl_node.card[1].iface[3].meshgrp_enable =3D 1; gl_node.card[1].iface[3].meshgrp_id =3D 1;=20 break; case 6: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.6"; gl_node.sys_id =3D "abcdef"; gl_node.sys_type =3D 2; /* L2 IS */ /* Manual Area Addresses */ gl_node.area1 =3D ""; gl_node.area2 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xbb"; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; =20 gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.26.6"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 62000; gl_node.card[1].iface[1].local_mac =3D = "\x01\x1f\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].remote_port =3D 26000; gl_node.card[1].iface[1].remote_mac =3D = "\x01\x4b\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.56.6"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 65000; gl_node.card[1].iface[2].local_mac =3D = "\x01\x2f\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].remote_port =3D 56000; gl_node.card[1].iface[2].remote_mac =3D = "\x01\x2e\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 0; gl_node.card[1].iface[2].lvl1_priority =3D 2; gl_node.card[1].iface[2].lvl1_metric =3D 3; gl_node.card[1].iface[2].lvl2_priority =3D 2; gl_node.card[1].iface[2].lvl2_metric =3D 2; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1; /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[3].if_index =3D 3; gl_node.card[1].iface[3].if_sub_index =3D 0; gl_node.card[1].iface[3].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[3].if_mtu =3D 1024; gl_node.card[1].iface[3].ckt_index =3D 3; gl_node.card[1].iface[3].local_ip_addr =3D "172.32.67.6"; gl_node.card[1].iface[3].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[3].local_port =3D 67000; gl_node.card[1].iface[3].local_mac =3D = "\x01\x3f\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[3].remote_port =3D 76000; gl_node.card[1].iface[3].remote_mac =3D = "\x01\x27\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[3].conn_info =3D 0; gl_node.card[1].iface[3].sim_server =3D 1; =09 gl_node.card[1].iface[3].lvl1_priority =3D node_number; gl_node.card[1].iface[3].lvl1_metric =3D node_number; gl_node.card[1].iface[3].lvl2_priority =3D node_number; gl_node.card[1].iface[3].lvl2_metric =3D node_number; =20 gl_node.card[1].iface[3].meshgrp_enable =3D 1; gl_node.card[1].iface[3].meshgrp_id =3D 1;=20 break; case 7: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.7"; gl_node.sys_id =3D "abcd07"; gl_node.sys_type =3D 3; /* L1L2 IS */ /* Manual Area Addresses */ gl_node.area1 =3D ""; gl_node.area2 =3D ""; gl_node.area3 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xcc"; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 =20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =09 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.27.7"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 72000; gl_node.card[1].iface[1].local_mac =3D = "\x01\x17\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].remote_port =3D 27000; gl_node.card[1].iface[1].remote_mac =3D = "\x01\x5b\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; =09 gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.67.7"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 76000; gl_node.card[1].iface[2].local_mac =3D = "\x01\x27\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].remote_port =3D 67000; gl_node.card[1].iface[2].remote_mac =3D = "\x01\x3f\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 0; gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1 ; /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[3].if_index =3D 3; gl_node.card[1].iface[3].if_sub_index =3D 0; gl_node.card[1].iface[3].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[3].if_mtu =3D 1024; gl_node.card[1].iface[3].ckt_index =3D 3; gl_node.card[1].iface[3].local_ip_addr =3D "10.10.125.7"; gl_node.card[1].iface[3].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[3].local_port =3D 70011; gl_node.card[1].iface[3].local_mac =3D = "\x01\x37\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[3].remote_port =3D 11007; gl_node.card[1].iface[3].remote_mac =3D = "\x01\x11\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[3].conn_info =3D 0; gl_node.card[1].iface[3].sim_server =3D 1; gl_node.card[1].iface[3].lvl1_priority =3D node_number; gl_node.card[1].iface[3].lvl1_metric =3D node_number; gl_node.card[1].iface[3].lvl2_priority =3D node_number; gl_node.card[1].iface[3].lvl2_metric =3D node_number; =20 gl_node.card[1].iface[3].meshgrp_enable =3D 1; gl_node.card[1].iface[3].meshgrp_id =3D 1;=20 break; case 8: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.8"; gl_node.sys_id =3D "abcd08"; gl_node.sys_type =3D 1; /* L1 IS */ /* Manual Area Addresses */ gl_node.area1 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xaa"; gl_node.area2 =3D ""; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 =09 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; =20 =20 gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "10.10.10.8"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 81000; gl_node.card[1].iface[1].local_mac =3D = "\x01\x18\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].remote_port =3D 18000; gl_node.card[1].iface[1].remote_mac =3D = "\x01\x4a\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; =20 gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1; =20 =09 gl_node.card[1].iface[2].local_ip_addr =3D "172.32.88.8"; gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* "bcast" | = "ptp" */ gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].if_mtu =3D 1024;=20 gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 80018; gl_node.card[1].iface[2].local_mac =3D = "\x08\x18\x08\x18\x08\x18\0x00"; gl_node.card[1].iface[2].remote_port =3D 18008; gl_node.card[1].iface[2].remote_mac =3D = "\x18\x08\x18\x08\x18\x08\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 1; =09 gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1 ;=20 break; case 9: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.9"; gl_node.sys_id =3D "abcd09"; gl_node.sys_type =3D 3; /* L1 IS */ /* Manual Area Addresses */ gl_node.area1 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xaa"; gl_node.area2 =3D ""; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 =09 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide";; gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "10.10.12.9"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 93000; gl_node.card[1].iface[1].local_mac =3D = "\x01\x19\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].remote_port =3D 39000; gl_node.card[1].iface[1].remote_mac =3D = "\x01\x4c\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1; =09 gl_node.card[1].iface[2].local_ip_addr =3D "172.32.49.9"; gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* "bcast" | = "ptp" */ gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].if_mtu =3D 1024;=20 gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 94000; gl_node.card[1].iface[2].local_mac =3D = "\x94\x49\x94\x49\x94\x49\0x00"; gl_node.card[1].iface[2].remote_port =3D 49000; gl_node.card[1].iface[2].remote_mac =3D = "\x49\x94\x49\x94\x49\x94\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 0; =09 gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1;=20 =09 gl_node.card[1].iface[3].local_ip_addr =3D "172.32.99.9"; gl_node.card[1].iface[3].if_index =3D 3; gl_node.card[1].iface[3].if_sub_index =3D 0; gl_node.card[1].iface[3].com_type =3D "bcast"; /* "bcast" | = "ptp" */ gl_node.card[1].iface[3].ckt_index =3D 3; gl_node.card[1].iface[3].if_mtu =3D 1024;=20 gl_node.card[1].iface[3].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[3].local_port =3D 90010; gl_node.card[1].iface[3].local_mac =3D = "\x09\x10\x09\x10\x09\x10\0x00"; gl_node.card[1].iface[3].remote_port =3D 10009; gl_node.card[1].iface[3].remote_mac =3D = "\x10\x09\x10\x09\x10\x09\0x00"; gl_node.card[1].iface[3].conn_info =3D 0; gl_node.card[1].iface[3].sim_server =3D 1; =09 gl_node.card[1].iface[3].lvl1_priority =3D node_number; gl_node.card[1].iface[3].lvl1_metric =3D node_number; gl_node.card[1].iface[3].lvl2_priority =3D node_number; gl_node.card[1].iface[3].lvl2_metric =3D node_number; gl_node.card[1].iface[3].meshgrp_enable =3D 1; gl_node.card[1].iface[3].meshgrp_id =3D 1;=20 break; case 10: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.10"; gl_node.sys_id =3D "abcd10"; gl_node.sys_type =3D 1; /* L1 IS */ /* Manual Area Addresses */ gl_node.area1 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xaa"; gl_node.area2 =3D ""; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "10.10.11.10"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 10004; gl_node.card[1].iface[1].local_mac =3D = "\x01\x10\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].remote_port =3D 40010; gl_node.card[1].iface[1].remote_mac =3D = "\x01\x3d\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1;=20 gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].if_mtu =3D 1024;=20 gl_node.card[1].iface[2].com_type =3D "bcast"; /* "bcast" | = "ptp" */ gl_node.card[1].iface[2].local_ip_addr =3D "172.32.99.10"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 10009; gl_node.card[1].iface[2].local_mac =3D = "\x10\x09\x10\x09\x10\x09\0x00"; gl_node.card[1].iface[2].remote_port =3D 90010; gl_node.card[1].iface[2].remote_mac =3D = "\x09\x10\x09\x10\x09\x10\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 0; gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1;=20 break; case 11: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.11"; gl_node.sys_id =3D "abcd11"; gl_node.sys_type =3D 1; /* L1 IS */ /* Manual Area Addresses */ =20 gl_node.area1 =3D ""; gl_node.area2 =3D ""; gl_node.area3 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xcc"; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 =09 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "10.10.125.11"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 11007; gl_node.card[1].iface[1].local_mac =3D = "\x01\x11\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].remote_port =3D 70011; gl_node.card[1].iface[1].remote_mac =3D = "\x01\x37\xef\xde\xad\xba\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1; =09 break; case 12: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.12"; gl_node.sys_id =3D "abcd12"; gl_node.sys_type =3D 2; /* L2 IS */ /* Manual Area Addresses */ =20 gl_node.area1 =3D ""; gl_node.area2 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xbb"; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.212.12"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 12002; gl_node.card[1].iface[1].local_mac =3D = "\x12\x02\x12\x02\x12\x02\0x00"; gl_node.card[1].iface[1].remote_port =3D 20012; gl_node.card[1].iface[1].remote_mac =3D = "\x02\x12\x02\x12\x02\x12\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1;=20 =09 gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.123.12"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 12013; gl_node.card[1].iface[2].local_mac =3D = "\x12\x13\x12\x13\x12\x13\0x00"; gl_node.card[1].iface[2].remote_port =3D 13012; gl_node.card[1].iface[2].remote_mac =3D = "\x13\x12\x13\x12\x13\x12\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 1; gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1; =09 gl_node.card[1].iface[3].if_index =3D 3; gl_node.card[1].iface[3].if_sub_index =3D 0; gl_node.card[1].iface[3].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[3].if_mtu =3D 1024; gl_node.card[1].iface[3].ckt_index =3D 3; gl_node.card[1].iface[3].local_ip_addr =3D "172.32.55.12"; gl_node.card[1].iface[3].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[3].local_port =3D 12005; gl_node.card[1].iface[3].local_mac =3D = "\x12\x05\x12\x05\x12\x05\0x00"; gl_node.card[1].iface[3].remote_port =3D 50012; gl_node.card[1].iface[3].remote_mac =3D = "\x05\x12\x05\x12\x05\x12\0x00"; gl_node.card[1].iface[3].conn_info =3D 0; gl_node.card[1].iface[3].sim_server =3D 0; gl_node.card[1].iface[3].lvl1_priority =3D node_number; gl_node.card[1].iface[3].lvl1_metric =3D node_number; gl_node.card[1].iface[3].lvl2_priority =3D node_number; gl_node.card[1].iface[3].lvl2_metric =3D node_number; gl_node.card[1].iface[3].meshgrp_enable =3D 1; gl_node.card[1].iface[3].meshgrp_id =3D 1; =09 break; case 13: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.13"; gl_node.sys_id =3D "abcd13"; gl_node.sys_type =3D 3; /* L1L2 IS */ /* Manual Area Addresses */ =20 gl_node.area1 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xaa"; gl_node.area2 =3D ""; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; =20 =20 gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =09 =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.123.13"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 13012; gl_node.card[1].iface[1].local_mac =3D = "\x13\x12\x13\x12\x13\x12\0x00"; gl_node.card[1].iface[1].remote_port =3D 12013; gl_node.card[1].iface[1].remote_mac =3D = "\x12\x13\x12\x13\x12\x13\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; =09 gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1;=20 gl_node.card[1].iface[2].if_index =3D 2;=20 gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.135.13"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 13015; gl_node.card[1].iface[2].local_mac =3D = "\x13\x15\x13\x15\x13\x15\0x00"; gl_node.card[1].iface[2].remote_port =3D 15013; gl_node.card[1].iface[2].remote_mac =3D = "\x15\x13\x15\x13\x15\x13\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 1; gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1 ; =09 gl_node.card[1].iface[3].if_index =3D 3;=20 gl_node.card[1].iface[3].if_sub_index =3D 0; gl_node.card[1].iface[3].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[3].if_mtu =3D 1024; gl_node.card[1].iface[3].ckt_index =3D 3; gl_node.card[1].iface[3].local_ip_addr =3D "172.32.134.13"; gl_node.card[1].iface[3].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[3].local_port =3D 13014; gl_node.card[1].iface[3].local_mac =3D = "\x13\x14\x13\x14\x13\x14\0x00"; gl_node.card[1].iface[3].remote_port =3D 14013; gl_node.card[1].iface[3].remote_mac =3D = "\x14\x13\x14\x13\x14\x13\0x00"; gl_node.card[1].iface[3].conn_info =3D 0; gl_node.card[1].iface[3].sim_server =3D 1; =09 gl_node.card[1].iface[3].lvl1_priority =3D node_number; gl_node.card[1].iface[3].lvl1_metric =3D node_number; gl_node.card[1].iface[3].lvl2_priority =3D node_number; gl_node.card[1].iface[3].lvl2_metric =3D node_number; gl_node.card[1].iface[3].meshgrp_enable =3D 1; gl_node.card[1].iface[3].meshgrp_id =3D 1; gl_node.card[1].iface[4].if_index =3D 4;=20 gl_node.card[1].iface[4].if_sub_index =3D 0; gl_node.card[1].iface[4].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[4].if_mtu =3D 1024; gl_node.card[1].iface[4].ckt_index =3D 4; gl_node.card[1].iface[4].local_ip_addr =3D "172.32.138.13"; gl_node.card[1].iface[4].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[4].local_port =3D 13018; gl_node.card[1].iface[4].local_mac =3D = "\x13\x18\x13\x18\x13\x18\0x00"; gl_node.card[1].iface[4].remote_port =3D 18013; gl_node.card[1].iface[4].remote_mac =3D = "\x18\x13\x18\x13\x18\x13\0x00"; gl_node.card[1].iface[4].conn_info =3D 0; gl_node.card[1].iface[4].sim_server =3D 1; gl_node.card[1].iface[4].lvl1_priority =3D node_number; gl_node.card[1].iface[4].lvl1_metric =3D node_number; gl_node.card[1].iface[4].lvl2_priority =3D node_number; gl_node.card[1].iface[4].lvl2_metric =3D node_number; gl_node.card[1].iface[4].meshgrp_enable =3D 1; gl_node.card[1].iface[4].meshgrp_id =3D 1; =09 break; case 14: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.14"; gl_node.sys_id =3D "abcd14"; gl_node.sys_type =3D 1; /* L1 IS */ /* Manual Area Addresses */ =20 gl_node.area1 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xaa"; gl_node.area2 =3D ""; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; =20 =09 gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.134.14"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 14013; gl_node.card[1].iface[1].local_mac =3D = "\x14\x13\x14\x13\x14\x13\0x00"; gl_node.card[1].iface[1].remote_port =3D 13014; gl_node.card[1].iface[1].remote_mac =3D = "\x13\x14\x13\x14\x13\x14\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1;=20 =09 gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.146.14"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 14016; gl_node.card[1].iface[2].local_mac =3D = "\x14\x16\x14\x16\x14\x16\0x00"; gl_node.card[1].iface[2].remote_port =3D 16014; gl_node.card[1].iface[2].remote_mac =3D = "\x16\x14\x16\x14\x16\x14\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 1; gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1 ;=20 =09 break; case 15: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.15.15"; gl_node.sys_id =3D "abcd15"; gl_node.sys_type =3D 1; /* L1 IS */ /* Manual Area Addresses */ =20 gl_node.area1 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xaa"; gl_node.area2 =3D ""; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.215.15"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 15002; gl_node.card[1].iface[1].local_mac =3D = "\x15\x02\x15\x02\x15\x02\0x00"; gl_node.card[1].iface[1].remote_port =3D 20015; gl_node.card[1].iface[1].remote_mac =3D = "\x02\x15\x02\x15\x02\x15\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1;=20 gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.135.15"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 15013; gl_node.card[1].iface[2].local_mac =3D = "\x15\x13\x15\x13\x15\x13\0x00"; gl_node.card[1].iface[2].remote_port =3D 13015; gl_node.card[1].iface[2].remote_mac =3D = "\x13\x15\x13\x15\x13\x15\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 0; gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1 ; gl_node.card[1].iface[3].if_index =3D 3; gl_node.card[1].iface[3].if_sub_index =3D 0; gl_node.card[1].iface[3].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[3].if_mtu =3D 1024; gl_node.card[1].iface[3].ckt_index =3D 3; gl_node.card[1].iface[3].local_ip_addr =3D "172.32.157.15"; gl_node.card[1].iface[3].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[3].local_port =3D 15017; gl_node.card[1].iface[3].local_mac =3D = "\x15\x17\x15\x17\x15\x17\0x00"; gl_node.card[1].iface[3].remote_port =3D 17015; gl_node.card[1].iface[3].remote_mac =3D = "\x17\x15\x17\x15\x17\x15\0x00"; gl_node.card[1].iface[3].conn_info =3D 0; gl_node.card[1].iface[3].sim_server =3D 1; gl_node.card[1].iface[3].lvl1_priority =3D node_number; gl_node.card[1].iface[3].lvl1_metric =3D node_number; gl_node.card[1].iface[3].lvl2_priority =3D node_number; gl_node.card[1].iface[3].lvl2_metric =3D node_number; gl_node.card[1].iface[3].meshgrp_enable =3D 1; gl_node.card[1].iface[3].meshgrp_id =3D 1; break; case 16: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.16"; gl_node.sys_id =3D "abcd16"; gl_node.sys_type =3D 1; /* L1 IS */ /* Manual Area Addresses */ =20 gl_node.area1 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xaa"; gl_node.area2 =3D ""; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =09 =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.146.16"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 16014; gl_node.card[1].iface[1].local_mac =3D = "\x16\x14\x16\x14\x16\x14\0x00"; gl_node.card[1].iface[1].remote_port =3D 14016; gl_node.card[1].iface[1].remote_mac =3D = "\x14\x16\x14\x16\x14\x16\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1;=20 gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.168.16"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 16018; gl_node.card[1].iface[2].local_mac =3D = "\x16\x18\x16\x18\x16\x18\0x00"; gl_node.card[1].iface[2].remote_port =3D 18016; gl_node.card[1].iface[2].remote_mac =3D = "\x18\x16\x18\x16\x18\x16\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 1; gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1; =20 break; case 17: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.17"; gl_node.sys_id =3D "abcd17"; gl_node.sys_type =3D 1; /* L1 IS */ /* Manual Area Addresses */ =20 gl_node.area1 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xaa"; gl_node.area2 =3D ""; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; =20 =09 gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20;=09 =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.217.17"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 17002; gl_node.card[1].iface[1].local_mac =3D = "\x17\x02\x17\x02\x17\x02\0x00"; gl_node.card[1].iface[1].remote_port =3D 20017; gl_node.card[1].iface[1].remote_mac =3D = "\x02\x17\x02\x17\x02\x17\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1;=20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.157.17"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 17015; gl_node.card[1].iface[2].local_mac =3D = "\x17\x15\x17\x15\x17\x15\0x00"; gl_node.card[1].iface[2].remote_port =3D 15017; gl_node.card[1].iface[2].remote_mac =3D = "\x15\x17\x15\x17\x15\x17\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 0; gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1 ; /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[3].if_index =3D 3; gl_node.card[1].iface[3].if_sub_index =3D 0; gl_node.card[1].iface[3].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[3].if_mtu =3D 1024; gl_node.card[1].iface[3].ckt_index =3D 3; gl_node.card[1].iface[3].local_ip_addr =3D "172.32.178.17"; gl_node.card[1].iface[3].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[3].local_port =3D 17018; gl_node.card[1].iface[3].local_mac =3D = "\x17\x18\x17\x18\x17\x18\0x00"; gl_node.card[1].iface[3].remote_port =3D 18017; gl_node.card[1].iface[3].remote_mac =3D = "\x18\x17\x18\x17\x18\x17\0x00"; gl_node.card[1].iface[3].conn_info =3D 0; gl_node.card[1].iface[3].sim_server =3D 1; gl_node.card[1].iface[3].lvl1_priority =3D node_number; gl_node.card[1].iface[3].lvl1_metric =3D node_number; gl_node.card[1].iface[3].lvl2_priority =3D node_number; gl_node.card[1].iface[3].lvl2_metric =3D node_number; gl_node.card[1].iface[3].meshgrp_enable =3D 1; gl_node.card[1].iface[3].meshgrp_id =3D 1; =20 break; case 18: /* ALL NODES MUST DEFINE THIS */ gl_node.router_id =3D "172.32.1.18"; gl_node.sys_id =3D "abcd18"; gl_node.sys_type =3D 1; /* L1 IS */ /* Manual Area Addresses */ =20 gl_node.area1 =3D "\x49\x00\x01\x00\x00\x00\x00\x00\x0a\xaa"; gl_node.area2 =3D ""; gl_node.area3 =3D ""; =09 /* MDS AND RMS FIELDS */ gl_node.cards_in_system =3D 1; /* MDS, ISIS, LTCS FIELDS */ gl_node.card[1].vcard_id =3D 3; gl_node.card[1].anchor =3D 1; /* = 1=3DV_CARD_QA_1,2=3DV_CARD_QA_2 */ gl_node.card[1].role =3D "p"; /* "p"=3Dprimary | = "b"=3Dbackup | "n"=3Dnone */=20 /* RMS FIELDS */ gl_node.card[1].peer_vcard =3D 1; /* ISIS FIELD ONLY */ gl_node.card[1].type =3D "mlith"; /* "mcard" | "ifcard" | = "mlith" */=20 =20 gl_node.l1metric_type =3D "wide"; gl_node.l2metric_type =3D "wide"; gl_node.l1spf_type =3D "wide"; gl_node.l2spf_type =3D "wide"; =20 gl_node.maxage =3D 1200; gl_node.l1buf_size =3D 1212; gl_node.l2buf_size =3D 1212; gl_node.minl1lsp_intvl =3D 15; gl_node.minl2lsp_intvl =3D 21; gl_node.refresh_intvl =3D 20; =20 /* ALL NODES MUST DEFINE THESE */ gl_node.card[1].iface[1].if_index =3D 1; gl_node.card[1].iface[1].if_sub_index =3D 0; gl_node.card[1].iface[1].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[1].if_mtu =3D 1024; gl_node.card[1].iface[1].ckt_index =3D 1; gl_node.card[1].iface[1].local_ip_addr =3D "172.32.88.18"; gl_node.card[1].iface[1].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[1].local_port =3D 18008; gl_node.card[1].iface[1].local_mac =3D = "\x18\x08\x18\x08\x18\x08\0x00"; gl_node.card[1].iface[1].remote_port =3D 80018; gl_node.card[1].iface[1].remote_mac =3D = "\x08\x18\x08\x18\x08\x18\0x00"; gl_node.card[1].iface[1].conn_info =3D 0; gl_node.card[1].iface[1].sim_server =3D 0; =09 gl_node.card[1].iface[1].lvl1_priority =3D node_number; gl_node.card[1].iface[1].lvl1_metric =3D node_number; gl_node.card[1].iface[1].lvl2_priority =3D node_number; gl_node.card[1].iface[1].lvl2_metric =3D node_number; gl_node.card[1].iface[1].meshgrp_enable =3D 1; gl_node.card[1].iface[1].meshgrp_id =3D 1;=20 gl_node.card[1].iface[2].if_index =3D 2; gl_node.card[1].iface[2].if_sub_index =3D 0; gl_node.card[1].iface[2].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[2].if_mtu =3D 1024; gl_node.card[1].iface[2].ckt_index =3D 2; gl_node.card[1].iface[2].local_ip_addr =3D "172.32.168.18"; gl_node.card[1].iface[2].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[2].local_port =3D 18016; gl_node.card[1].iface[2].local_mac =3D = "\x18\x16\x18\x16\x18\x16\0x00"; gl_node.card[1].iface[2].remote_port =3D 16018; gl_node.card[1].iface[2].remote_mac =3D = "\x16\x18\x16\x18\x16\x18\0x00"; gl_node.card[1].iface[2].conn_info =3D 0; gl_node.card[1].iface[2].sim_server =3D 0; gl_node.card[1].iface[2].lvl1_priority =3D node_number; gl_node.card[1].iface[2].lvl1_metric =3D node_number; gl_node.card[1].iface[2].lvl2_priority =3D node_number; gl_node.card[1].iface[2].lvl2_metric =3D node_number; gl_node.card[1].iface[2].meshgrp_enable =3D 1; gl_node.card[1].iface[2].meshgrp_id =3D 1 ; gl_node.card[1].iface[3].if_index =3D 3; gl_node.card[1].iface[3].if_sub_index =3D 0; gl_node.card[1].iface[3].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[3].if_mtu =3D 1024; gl_node.card[1].iface[3].ckt_index =3D 3; gl_node.card[1].iface[3].local_ip_addr =3D "172.32.178.18"; gl_node.card[1].iface[3].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[3].local_port =3D 18017; gl_node.card[1].iface[3].local_mac =3D = "\x18\x17\x18\x17\x18\x17\0x00"; gl_node.card[1].iface[3].remote_port =3D 17018; gl_node.card[1].iface[3].remote_mac =3D = "\x17\x18\x17\x18\x17\x18\0x00"; gl_node.card[1].iface[3].conn_info =3D 0; gl_node.card[1].iface[3].sim_server =3D 0; gl_node.card[1].iface[3].lvl1_priority =3D node_number; gl_node.card[1].iface[3].lvl1_metric =3D node_number; gl_node.card[1].iface[3].lvl2_priority =3D node_number; gl_node.card[1].iface[3].lvl2_metric =3D node_number; gl_node.card[1].iface[3].meshgrp_enable =3D 1; gl_node.card[1].iface[3].meshgrp_id =3D 1;=20 =09 gl_node.card[1].iface[4].if_index =3D 4; gl_node.card[1].iface[4].if_sub_index =3D 0; gl_node.card[1].iface[4].com_type =3D "bcast"; /* = "bcast" | "ptp" */ gl_node.card[1].iface[4].if_mtu =3D 1024; gl_node.card[1].iface[4].ckt_index =3D 4; gl_node.card[1].iface[4].local_ip_addr =3D "172.32.138.18"; gl_node.card[1].iface[4].if_mask_len =3D 24; /* = 255.255.255.0 */ gl_node.card[1].iface[4].local_port =3D 18013; gl_node.card[1].iface[4].local_mac =3D = "\x18\x13\x18\x13\x18\x13\0x00"; gl_node.card[1].iface[4].remote_port =3D 13018; gl_node.card[1].iface[4].remote_mac =3D = "\x13\x18\x13\x18\x13\x18\0x00"; gl_node.card[1].iface[4].conn_info =3D 0; gl_node.card[1].iface[4].sim_server =3D 0; gl_node.card[1].iface[4].lvl1_priority =3D node_number; gl_node.card[1].iface[4].lvl1_metric =3D node_number; gl_node.card[1].iface[4].lvl2_priority =3D node_number; gl_node.card[1].iface[4].lvl2_metric =3D node_number; gl_node.card[1].iface[4].meshgrp_enable =3D 1; gl_node.card[1].iface[4].meshgrp_id =3D 18; break; } hjw_print_string("\n\nDATA FILE =3D LTCS ISIS MONO...\n\n") return (gl_node); } ------_=_NextPart_000_01C2E46B.1FC56920-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 7 00:48:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00413 for ; Fri, 7 Mar 2003 00:48:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0091CE4A@cherry.ease.lsoft.com>; Fri, 7 Mar 2003 0:50:34 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664554 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 7 Mar 2003 00:50:34 -0500 Received: from 203.254.224.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Mar 2003 00:50:33 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HBD00F016UB1V@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Fri, 07 Mar 2003 14:49:23 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HBD00D406U7HM@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Fri, 07 Mar 2003 14:49:23 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HBD001A97IO8J@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Fri, 07 Mar 2003 15:04:03 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Message-ID: <068401c2e46d$451c5c90$b4036c6b@sisodomain.com> Date: Fri, 7 Mar 2003 11:19:06 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: dont take the previous one.. take this To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Amit, But what are we supposed to do with this LTCS ISIS Mono file? :-) Cheers (hic!) ----- Original Message ----- From: "Banwari, Amit" To: Sent: Friday, March 07, 2003 11:03 AM Subject: dont take the previous one.. take this > > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 7 02:44:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13859 for ; Fri, 7 Mar 2003 02:44:33 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0091D2C0@cherry.ease.lsoft.com>; Fri, 7 Mar 2003 2:46:37 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664748 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 7 Mar 2003 02:46:37 -0500 Received: from 64.12.136.164 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Mar 2003 02:46:37 -0500 Received: from Jjsyed@aol.com by imo-m09.mx.aol.com (mail_out_v34.21.) id 7.a.2dc6d57b (15864) for ; Fri, 7 Mar 2003 02:46:33 -0500 (EST) Received: from aol.com (mow-m29.webmail.aol.com [64.12.137.6]) by air-id06.mx.aol.com (v90_r2.5) with ESMTP id MAILINID63-0307024633; Fri, 07 Mar 2003 02:46:33 1900 MIME-Version: 1.0 X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <7ED3E72A.566892CC.0004D071@aol.com> Date: Fri, 7 Mar 2003 02:46:32 -0500 Reply-To: Mailing List Sender: Mailing List From: Javed Syed Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Ravi, Since router technology has made lot of progress, number of routers in area , database limitation, two process all those design limitation does not raise any concerns. make sure depending on the vendor, you can play with spfhold timer qnd other great ospf commands on point to point link to reduce the amount of LSA flooding etc depending on your design consideration. Do you have any low speed links anywhere in your network which will be part of your ospf domain ? javed From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 7 03:58:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15115 for ; Fri, 7 Mar 2003 03:58:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0091D3F4@cherry.ease.lsoft.com>; Fri, 7 Mar 2003 4:00:16 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664871 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 7 Mar 2003 04:00:15 -0500 Received: from 216.136.226.178 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Mar 2003 04:00:15 -0500 Received: from [210.118.108.254] by web20705.mail.yahoo.com via HTTP; Fri, 07 Mar 2003 01:00:14 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030307090014.57999.qmail@web20705.mail.yahoo.com> Date: Fri, 7 Mar 2003 01:00:14 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I remember reading somewhere that ISIS can support bigger areas than OSPF though i am not sure as to how exactly, given that both are link state and almost similar. So if you cant scale well with OSPF then you can consider ISIS also. ----- Original Message ----- From: "klara moser" To: Sent: Thursday, March 06, 2003 11:41 PM Subject: Re: ospf limits... > Hi Ravi, > > As far as I know the OSPF protocol has only one limitation on the topologies > size - the Network and Router LSA size. The max is 64KB. This limits the number > of links the router can have in a single area, because it has to advertise them > in a single Router LSA. You can do the math. It is something like 5 000 links. > > Klara > > Quaizar Vohra wrote: > > > I think the main factor is the amount of flooding a router has to do > > which depends on how many adjacencies you have and how many LSAs you > > have to flood to each adjacency. So it is useful to divide your > > network into multiple areas so as to reduce flooding. Also large > > no. of adjacencies in a single area can result in rather large router > > LSAs which causes a lots of fragmentation and adds to the flooding > > load. > > > > Quaizar > > > > > I am in the midst of redesigning an OSPF network to accommodate > > > significant growth, especially in the Area 0 backbone. There has been > > > some concern about the size of the OSPF topology that would result and > > > whether the routing protocol would remain robust, able to handle the odd > > > flapping link or memory leak. The network in question is using high-end > > > routers with high speed links (at least DS-3). > > > > > > Are there any heuristics that someone has which may give us an idea of > > > the comfort zone in terms of the database size, number of neighbors, > > > routers, etc? > > > > > > Or, could someone share information on the size of large OSPF > > > implementations that they are aware of? > > > > > > I know that this issue is rather vague (clouded in too many unknowns) > > > and may only result in rather ambiguous > > > answers, but, one never knows. > > > > > > Thanks, __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 7 09:19:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03739 for ; Fri, 7 Mar 2003 09:19:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0091DE6A@cherry.ease.lsoft.com>; Fri, 7 Mar 2003 9:21:43 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665858 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 7 Mar 2003 09:21:42 -0500 Received: from 192.75.23.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Mar 2003 09:21:42 -0500 Received: (qmail 13819 invoked from network); 7 Mar 2003 14:23:53 -0000 Received: from unknown (HELO alcatel.com) (138.120.105.194) by kanmx2.ca.alcatel.com with SMTP; 7 Mar 2003 14:23:53 -0000 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <20030307090014.57999.qmail@web20705.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E68AAF5.6FF26B7B@alcatel.com> Date: Fri, 7 Mar 2003 09:21:41 -0500 Reply-To: Mailing List Sender: Mailing List From: klara moser Organization: Alcatel CID Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I think that the limit for the ISIS topologies comes from the fact that there could be only 256 LSPs generated and this is for all route types. It is still very big database (256 x 1470bytes)... Klara Rohit Gupta wrote: > I remember reading somewhere that ISIS can support > bigger areas than OSPF though i am not sure as to how > exactly, given that both are link state and almost > similar. > > So if you cant scale well with OSPF then you can > consider ISIS also. > > ----- Original Message ----- > From: "klara moser" > To: > Sent: Thursday, March 06, 2003 11:41 PM > Subject: Re: ospf limits... > > > Hi Ravi, > > > > As far as I know the OSPF protocol has only one > limitation on the topologies > > size - the Network and Router LSA size. The max is > 64KB. This limits the number > > of links the router can have in a single area, > because it has to advertise them > > in a single Router LSA. You can do the math. It is > something like 5 000 links. > > > > Klara > > > > Quaizar Vohra wrote: > > > > > I think the main factor is the amount of flooding > a router has to do > > > which depends on how many adjacencies you have and > how many LSAs you > > > have to flood to each adjacency. So it is useful > to divide your > > > network into multiple areas so as to reduce > flooding. Also large > > > no. of adjacencies in a single area can result in > rather large router > > > LSAs which causes a lots of fragmentation and adds > to the flooding > > > load. > > > > > > Quaizar > > > > > > > I am in the midst of redesigning an OSPF > network to accommodate > > > > significant growth, especially in the Area 0 > backbone. There has been > > > > some concern about the size of the OSPF > topology that would result and > > > > whether the routing protocol would remain > robust, able to handle the odd > > > > flapping link or memory leak. The network in > question is using high-end > > > > routers with high speed links (at least DS-3). > > > > > > > > Are there any heuristics that someone has which > may give us an idea of > > > > the comfort zone in terms of the database size, > number of neighbors, > > > > routers, etc? > > > > > > > > Or, could someone share information on the size > of large OSPF > > > > implementations that they are aware of? > > > > > > > > I know that this issue is rather vague (clouded > in too many unknowns) > > > > and may only result in rather ambiguous > > > > answers, but, one never knows. > > > > > > > > Thanks, > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 7 10:38:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11249 for ; Fri, 7 Mar 2003 10:38:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0091E135@cherry.ease.lsoft.com>; Fri, 7 Mar 2003 10:40:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666081 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 7 Mar 2003 10:40:59 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Mar 2003 10:40:59 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23153 for ; Fri, 7 Mar 2003 10:40:57 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA06932 for ; Fri, 7 Mar 2003 10:40:58 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 10:40:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557634F1@vie-msgusr-01.dc.fore.com> Date: Fri, 7 Mar 2003 10:40:53 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Futher clarification needed-- Un-numbered point to point. dou bt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Alok, -> what i wish to know is that when i use INADDR_ANY as its -> value, will it bind -> to "any/all physical interface" or only "1 interface" which -> it randomly -> chooses? ( i beleive it is different across different unix flavours) When the interface (IP address in case of IPv4 or ifindex in case of IPv6) is not specified in IP_MULTICAST_IF or IP_ADD_MEMBERSHIP socket options, kernel selects only *one* local interface. Here INADDR_ANY is _not_ treated like a wildcard by the kernel. So, the choice is given to the kernel. The assumption is that if a route exists for a given multicast address (perhaps the default in the routing table), then the resulting interface should be used for input and output. Most of the operating systems uses this tip in interface selection. Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 7 10:54:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12042 for ; Fri, 7 Mar 2003 10:54:41 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0091E12A@cherry.ease.lsoft.com>; Fri, 7 Mar 2003 10:56:43 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666136 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 7 Mar 2003 10:56:42 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Mar 2003 10:56:42 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23738 for ; Fri, 7 Mar 2003 10:56:40 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09269 for ; Fri, 7 Mar 2003 10:56:42 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 10:56:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557634F2@vie-msgusr-01.dc.fore.com> Date: Fri, 7 Mar 2003 10:56:32 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Ospf Packet checksum To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -> > Correction. RFC 1141 obsoletes RFC 1071. But I prefer RFC 1624 -> > which updates RFC 1141. RFC 1624 reads: -> -> That's no correction. RFC's 1141 and 1624 update 1071 only -> with respect -> to the computation of incremental updates of the IP header -> checksum, a -> topic which takes up less than half of one page out of RFC -> 1071's 24 pages -> and is not relevant to the issue of how to compute a -> checksum for the OSPF -> packet. RFC 1071 is still the canonical reference for the -> computation of -> the IP 1's complement checksum, the other papers don't cover that. Yes. you are right. I agree. Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 7 13:54:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22882 for ; Fri, 7 Mar 2003 13:54:51 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0091E7FA@cherry.ease.lsoft.com>; Fri, 7 Mar 2003 13:56:54 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666552 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 7 Mar 2003 13:56:54 -0500 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Mar 2003 13:56:53 -0500 Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id h27Iupb1007986 for ; Fri, 7 Mar 2003 10:56:52 -0800 (PST) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (/) with ESMTP id h27Iui13022855 for ; Fri, 7 Mar 2003 10:56:44 -0800 (PST) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.8/8.12.8) with ESMTP id h27Il23a001459 for ; Fri, 7 Mar 2003 10:47:02 -0800 (PST) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id h27Il0xc001073 for ; Fri, 7 Mar 2003 10:47:01 -0800 (PST) References: <39469E08BD83D411A3D900204840EC557634EE@vie-msgusr-01.dc.fore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <041501c2e4dc$20988640$1105f183@b90.tdd.sj.nec.com> Date: Fri, 7 Mar 2003 11:02:40 -0800 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Re: Futher clarification needed-- Un-numbered point to point. dou bt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Venkata, Thanks for ur inputs. But, would u think using a dedicated socket for each interface is advisable? Especially in my environment, i do have 63 un-numbred pt-to-pt interfaces and only one Lan interface. And i do have only one valid global IP address that too for the LAN. If there is any other method to solve this problem, it would be appreciable. Btw: Ofcourse, the other method that would think is, having a queue and event communication between IP and OSPF. But it needs much modification in my stack especially at IP point of view... thanks in advance, GKS. ----- Original Message ----- From: "Naidu, Venkata" To: Sent: Thursday, March 06, 2003 1:05 PM Subject: Re: Futher clarification needed-- Un-numbered point to point. dou bt > Kamatchi, > > -> IP header with > -> source as 192.168.12.1 and destination as Multicast address 224.0.0.5. > -> Case 1: > -> 8) IP will look into the route table to send the packet, > -> obviously it could > -> not find anything match for this detination, then either it > -> may discard or > -> just forward the packet to defualt destination (or gateway). > -> In our case it > -> is more probably the Lan interface. So in this case there is > -> no chance of > -> OSPF packet to be sent over the Un-numbered point to point interface. > > No need to look into the (unicast) route table for multicast > addresses. The destination address in the IP packet is 224.0.0.5 > (which is link local multicast). Multicasting is specific to per > interface - (I,G). So, if you know the outgoing interface, then > enable multicasting on that interface and send the packet out. > > To support unnumbered interfaces, socket APIs (in most of the > operating systems) are not sufficient. Richard Stevens writes in > "UNIX Network Programming - Networking APIs: Sockets and XTI", > Volume 1, Second Edition, Page 497: > > . . . > When the interface on which to join is not specified, Berkeley- > derived kernels look up the multicast address in the normal IP > routing table and use the resulting interface (p. 357 of TCPv2). > Some systems install a route for all multicast addresses (that > is, a route with a destination of 224.0.0.0/8 for IPv4) upon > initialization to handle this scenario. > > The change was made with IPv6 to use an interface index to > specify the interface, instead of the local unicast address > that is used with IPv4, to allow joins on unnumbered interfaces > and tunnel endpoints. This is why interface name and index > functions that we described in Section 17.6 were introduced > with RFC2133 ... > ... > > With my knowledge in BSD & Linux OS, I strongly suggest you > to enhance the "bind"ing to specify interface index along with > IP address (in other words, socket binds to the interface > directly - provided you use socket per interface). If you > support shared sockets ('m' sockets per 'n' interfaces with > any to any connectivity) then you got to do additional work. > > > -> Case 2: If the above problem is because of using RAW socket, > -> and will it be > -> solved, if OSPF explicitly specifies the interface Name/index > -> through which > -> the OSPF packet need to delivered, then IP will deliver it > -> in the right > -> interface?? > > Yes. Explained above. Remember, you can use some of the > socket options (if I remember correctly, ROUTETOIF, SO_DONTROUTE > etc socket options) to force the packet out to an interface > (but I think those options sets the TTL to 1 - check out). > > -> Clarification 2: My other question is: do i need to specify > -> the neighbor > -> (other end of the interface) IP address, when i configure > -> the Numbered point > -> to point for OSPF?? > > Not necessary. It is the trade-off I observed. When you provide > neighbor address in the interface configuration itself then you > can immediately add (a specific) route to reach the neighbor > to your route table. If not, the only way you can learn the > reachability to the neighbor address is when the Layer 3 > routing protocol converges. > > I would like to clear some of the historical doubts w.r.t > unnumbered interfaces (I am lazy to write a draft). The way > you configure L2/L3 interfaces dictates you on how you > add/delete/modify delete routes from routing table. Layer 3 > Routing protocols tell us the "prefix (destination) to > nexthop (gateway)" resolution. Operating system performs the > "gateway -> outgoing interface" resolution. In the case of > unnumbered, Layer 3 protocol must provide the local interface > index when resolving prefixes so that operating system can > find the outgoing interface without any gateway address (just > because there is no gateway address for unnumbered links). > > Let me know if something is not clear. > > Venkata. > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 7 16:10:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03767 for ; Fri, 7 Mar 2003 16:10:03 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0091EC8B@cherry.ease.lsoft.com>; Fri, 7 Mar 2003 16:12:07 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667029 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 7 Mar 2003 16:12:06 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Mar 2003 16:12:06 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA03038 for ; Fri, 7 Mar 2003 16:11:54 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA20859 for ; Fri, 7 Mar 2003 16:11:56 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 16:11:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557634F5@vie-msgusr-01.dc.fore.com> Date: Fri, 7 Mar 2003 16:11:49 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Futher clarification needed-- Un-numbered point to point. dou bt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Kamatchi, -> Thanks for ur inputs. But, would u think using a dedicated -> socket for each interface is advisable? Now you are asking real internals. That is the trade-off (optimization) you have to make. Let me give some hints: - Performance: most of the operating system IP stacks use (some kind of) hashing to *find* the appropriate socket or fd for the incoming packets (except in few cases: Raw IP unicast etc). Kernel figures out Raw IP multicast, UDP (unicast & multicast) and TCP sockets pretty quickly using hashing in the order of O(1) average time. So, having lot of sockets won't hit the performance that much. - System Resources: if there are large number of interfaces (in the order of 4k) then, more sockets (actually fds) one per interface is not advisable. Why? Mostly, the fds space is shared by different applications (look at select call - one can do select fd_set on any kind of fd - file/socket etc). You will be wasting lot of system resource (for example, each socket will have send and receive buffer space etc etc). So, having lot of sockets is going to hit resource usage. - On the other hand, if you use shared sockets, then I can easily imagine that you are using IP_HDRINCL option (ie., building IP header your own instead in the kernel). Then you must be going for a route table lookup for each and every packet - including multicast packets. If we assume that the routing table is radix/patricia tree, then there must be some logarithmic average time search. All the above processing can be avoided if you use socket per interface. - The best solution is, use shared sockets if you are going to run OSPF on large number (order of 4K) of interfaces. Otherwise, use one socket per interface. -> Especially in my environment, i do have 63 un-numbred -> pt-to-pt interfaces and only one Lan interface. And i do have -> only one valid global IP address that too for the LAN. Again, whether you have one global IP address *or* one IP address per interface is irrelevant in the current context. Which IP address you are going to use as the source address of the packet is *not* the issue here. The real issue you have to solve is, "how can I send the packet out on the desired outgoing interface?" -> If there is any other method to solve this problem, it would be -> appreciable. -> -> Btw: Ofcourse, the other method that would think is, having -> a queue and -> event communication between IP and OSPF. But it needs much -> modification in -> my stack especially at IP point of view... Don't complicate things. Just try to figure out how best you can send the packet out using all the information you have (including different socket options etc etc) Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 7 17:00:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08054 for ; Fri, 7 Mar 2003 17:00:01 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0091EEDF@cherry.ease.lsoft.com>; Fri, 7 Mar 2003 17:02:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667251 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 7 Mar 2003 17:02:03 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 7 Mar 2003 17:02:03 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 29016235CC; Sat, 8 Mar 2003 07:02:02 +0900 (JST) References: <20030307090014.57999.qmail@web20705.mail.yahoo.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030308.070201.61956851.yasu@sfc.wide.ad.jp> Date: Sat, 8 Mar 2003 07:02:01 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: ospf limits... Comments: To: rohitgupta416@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030307090014.57999.qmail@web20705.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Hi, Though I haven't read (or don't remember) any document mentions that, I guess it comes from the capability of controlling the rate of bandwidth consumption used by LSA refresh. Because IS-IS ages LSP by counting down the age and expires them when the age is 0, IS-IS's "IS" can decide when to refresh his LSP individually. OSPF specifies when to refresh and/or expire LSA explicitly, so OSPF system's refresh rate is affected by the network-size (precisely # of LSA), and can't be reduced by human manipulation. regards, yasu From: Rohit Gupta Subject: Re: ospf limits... Date: Fri, 7 Mar 2003 01:00:14 -0800 > I remember reading somewhere that ISIS can support > bigger areas than OSPF though i am not sure as to how > exactly, given that both are link state and almost > similar. > > So if you cant scale well with OSPF then you can > consider ISIS also. > > ----- Original Message ----- > From: "klara moser" > To: > Sent: Thursday, March 06, 2003 11:41 PM > Subject: Re: ospf limits... > > > > Hi Ravi, > > > > As far as I know the OSPF protocol has only one > limitation on the topologies > > size - the Network and Router LSA size. The max is > 64KB. This limits the number > > of links the router can have in a single area, > because it has to advertise them > > in a single Router LSA. You can do the math. It is > something like 5 000 links. > > > > Klara > > > > Quaizar Vohra wrote: > > > > > I think the main factor is the amount of flooding > a router has to do > > > which depends on how many adjacencies you have and > how many LSAs you > > > have to flood to each adjacency. So it is useful > to divide your > > > network into multiple areas so as to reduce > flooding. Also large > > > no. of adjacencies in a single area can result in > rather large router > > > LSAs which causes a lots of fragmentation and adds > to the flooding > > > load. > > > > > > Quaizar > > > > > > > I am in the midst of redesigning an OSPF > network to accommodate > > > > significant growth, especially in the Area 0 > backbone. There has been > > > > some concern about the size of the OSPF > topology that would result and > > > > whether the routing protocol would remain > robust, able to handle the odd > > > > flapping link or memory leak. The network in > question is using high-end > > > > routers with high speed links (at least DS-3). > > > > > > > > Are there any heuristics that someone has which > may give us an idea of > > > > the comfort zone in terms of the database size, > number of neighbors, > > > > routers, etc? > > > > > > > > Or, could someone share information on the size > of large OSPF > > > > implementations that they are aware of? > > > > > > > > I know that this issue is rather vague (clouded > in too many unknowns) > > > > and may only result in rather ambiguous > > > > answers, but, one never knows. > > > > > > > > Thanks, > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Sat Mar 8 09:08:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18744 for ; Sat, 8 Mar 2003 09:08:06 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0092027D@cherry.ease.lsoft.com>; Sat, 8 Mar 2003 9:10:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 669164 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 8 Mar 2003 09:10:09 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 8 Mar 2003 09:10:09 -0500 Received: from apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with SMTP id h28EWLr09770 for ; Sat, 8 Mar 2003 20:02:21 +0530 Received: from 219.65.48.106 (SquirrelMail authenticated user alok.dube) by mail.apara.com with HTTP; Sat, 8 Mar 2003 20:02:21 +0530 (IST) References: <39469E08BD83D411A3D900204840EC557634F1@vie-msgusr-01.dc.fore.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <1151.219.65.48.106.1047133941.squirrel@mail.apara.com> Date: Sat, 8 Mar 2003 20:02:21 +0530 Reply-To: Mailing List Sender: Mailing List From: Alok Dube Subject: Re: Futher clarification needed-- Un-numbered point to point. dou bt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC557634F1@vie-msgusr-01.dc.fore.com> Precedence: list Content-Transfer-Encoding: 8bit hi, but then how do we ensure that all interfaces "listen" to multicast? keep binding to each one? > Alok, > > -> what i wish to know is that when i use INADDR_ANY as its > -> value, will it bind > -> to "any/all physical interface" or only "1 interface" which > -> it randomly > -> chooses? ( i beleive it is different across different unix flavours) > > When the interface (IP address in case of IPv4 or ifindex in > case of IPv6) is not specified in IP_MULTICAST_IF or > IP_ADD_MEMBERSHIP socket options, kernel selects only *one* > local interface. Here INADDR_ANY is _not_ treated like a > wildcard by the kernel. So, the choice is given to the kernel. > > The assumption is that if a route exists for a given multicast > address (perhaps the default in the routing table), then the > resulting interface should be used for input and output. Most > of the operating systems uses this tip in interface selection. > > Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Sun Mar 9 18:14:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27943 for ; Sun, 9 Mar 2003 18:14:02 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00922A51@cherry.ease.lsoft.com>; 9 Mar 2003 18:16:08 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 672957 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 9 Mar 2003 18:16:08 -0500 Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Mar 2003 18:16:07 -0500 Received: from user-38ldts2.dialup.mindspring.com ([209.86.247.130] helo=earthlink.net) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18sA1W-0005I0-00 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 09 Mar 2003 15:16:06 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <60F922ABE8BE9C428E806F43C0EC73680B33C3@HARITHA> <3E5DDBD1.6EFF3278@earthlink.net> <20030303171817.B52437@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E6BC825.8079C949@earthlink.net> Date: Sun, 9 Mar 2003 15:03:01 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kiretti Kompella, Of all the items that I mentioned, I think one of the main items deals with a sub-second (microsec to millisec) interval values. A negotation like interval determination would probably be number one for me. Assuming that you would not find it beneficial for different intervals being set, I would think that if a router were recieving the said packet on a microsec timeframe and while under congestion or such, it should be able to inform the sender to bump up the interval to the highest value. Almost ala "BGP neighbor negotiation hold timer" but I am suggesting to a higher value. If after the "congestion event" has passed, the router sending the higher interval value, could adjust downwards to meet the first router's value, thus re-achieving the microsec earlier interval. Mitchell Erblich Sr. Network Software Engineer ======================================= Kireeti Kompella wrote: > > Hi Mitchell, > > On Thu, 27 Feb 2003, Erblichs wrote: > > > I think I missed why certain items are obmitted from this draft which > > is very interesting... Just a few items :) > > This draft will be superceded by a new draft with similar goals > but quite a different implementation. Unfortunately, we missed > the ID cutoff, but the essence remains -- fast (sub-second) hellos, > L2 independent, in principle L3 independent, and (the big change) > routing protocol independent. > > We'll submit it after the IETF. > > Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Sun Mar 9 22:49:21 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17971 for ; Sun, 9 Mar 2003 22:49:21 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00923214@cherry.ease.lsoft.com>; 9 Mar 2003 22:51:24 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673560 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 9 Mar 2003 22:51:23 -0500 Received: from 216.136.226.177 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Mar 2003 22:51:23 -0500 Received: from [210.118.108.254] by web20704.mail.yahoo.com via HTTP; Sun, 09 Mar 2003 19:51:23 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030310035123.58614.qmail@web20704.mail.yahoo.com> Date: Sun, 9 Mar 2003 19:51:23 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E68AAF5.6FF26B7B@alcatel.com> Precedence: list A draft by Amir Hermelin (draft-ietf-isis-ext-lsp-frags-02.txt) now changes that and we can have LSP fragments > 256 Rohit --- klara moser wrote: > I think that the limit for the ISIS topologies comes > from the fact that > there could be only 256 LSPs generated and this is > for all route types. > It is still very big database (256 x 1470bytes)... > > Klara > > Rohit Gupta wrote: > > > I remember reading somewhere that ISIS can support > > bigger areas than OSPF though i am not sure as to > how > > exactly, given that both are link state and almost > > similar. > > > > So if you cant scale well with OSPF then you can > > consider ISIS also. > > > > ----- Original Message ----- > > From: "klara moser" > > To: > > Sent: Thursday, March 06, 2003 11:41 PM > > Subject: Re: ospf limits... > > > > > Hi Ravi, > > > > > > As far as I know the OSPF protocol has only one > > limitation on the topologies > > > size - the Network and Router LSA size. The max > is > > 64KB. This limits the number > > > of links the router can have in a single area, > > because it has to advertise them > > > in a single Router LSA. You can do the math. It > is > > something like 5 000 links. > > > > > > Klara > > > > > > Quaizar Vohra wrote: > > > > > > > I think the main factor is the amount of > flooding > > a router has to do > > > > which depends on how many adjacencies you have > and > > how many LSAs you > > > > have to flood to each adjacency. So it is > useful > > to divide your > > > > network into multiple areas so as to reduce > > flooding. Also large > > > > no. of adjacencies in a single area can result > in > > rather large router > > > > LSAs which causes a lots of fragmentation and > adds > > to the flooding > > > > load. > > > > > > > > Quaizar > > > > > > > > > I am in the midst of redesigning an OSPF > > network to accommodate > > > > > significant growth, especially in the Area > 0 > > backbone. There has been > > > > > some concern about the size of the OSPF > > topology that would result and > > > > > whether the routing protocol would remain > > robust, able to handle the odd > > > > > flapping link or memory leak. The network > in > > question is using high-end > > > > > routers with high speed links (at least > DS-3). > > > > > > > > > > Are there any heuristics that someone has > which > > may give us an idea of > > > > > the comfort zone in terms of the database > size, > > number of neighbors, > > > > > routers, etc? > > > > > > > > > > Or, could someone share information on the > size > > of large OSPF > > > > > implementations that they are aware of? > > > > > > > > > > I know that this issue is rather vague > (clouded > > in too many unknowns) > > > > > and may only result in rather ambiguous > > > > > answers, but, one never knows. > > > > > > > > > > Thanks, > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Sun Mar 9 22:50:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18186 for ; Sun, 9 Mar 2003 22:50:23 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00923024@cherry.ease.lsoft.com>; 9 Mar 2003 22:52:29 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673603 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 9 Mar 2003 22:52:29 -0500 Received: from 216.136.226.181 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Mar 2003 22:52:29 -0500 Received: from [210.118.108.254] by web20708.mail.yahoo.com via HTTP; Sun, 09 Mar 2003 19:52:28 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030310035228.70463.qmail@web20708.mail.yahoo.com> Date: Sun, 9 Mar 2003 19:52:28 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030308.070201.61956851.yasu@sfc.wide.ad.jp> Precedence: list Yasu, I could not understand as to how this will help in building larger ISIS areas vis-a-vis OSPF! Rohit --- Yasuhiro Ohara wrote: > Hi, > > Though I haven't read (or don't remember) any > document mentions > that, I guess it comes from the capability of > controlling the rate > of bandwidth consumption used by LSA refresh. > > Because IS-IS ages LSP by counting down the age and > expires them > when the age is 0, IS-IS's "IS" can decide when to > refresh his LSP > individually. OSPF specifies when to refresh and/or > expire LSA > explicitly, so OSPF system's refresh rate is > affected by the > network-size (precisely # of LSA), and can't be > reduced by > human manipulation. > > regards, > yasu > > From: Rohit Gupta > Subject: Re: ospf limits... > Date: Fri, 7 Mar 2003 01:00:14 -0800 > > > I remember reading somewhere that ISIS can support > > bigger areas than OSPF though i am not sure as to > how > > exactly, given that both are link state and almost > > similar. > > > > So if you cant scale well with OSPF then you can > > consider ISIS also. > > > > ----- Original Message ----- > > From: "klara moser" > > To: > > Sent: Thursday, March 06, 2003 11:41 PM > > Subject: Re: ospf limits... > > > > > > > Hi Ravi, > > > > > > As far as I know the OSPF protocol has only one > > limitation on the topologies > > > size - the Network and Router LSA size. The max > is > > 64KB. This limits the number > > > of links the router can have in a single area, > > because it has to advertise them > > > in a single Router LSA. You can do the math. It > is > > something like 5 000 links. > > > > > > Klara > > > > > > Quaizar Vohra wrote: > > > > > > > I think the main factor is the amount of > flooding > > a router has to do > > > > which depends on how many adjacencies you have > and > > how many LSAs you > > > > have to flood to each adjacency. So it is > useful > > to divide your > > > > network into multiple areas so as to reduce > > flooding. Also large > > > > no. of adjacencies in a single area can result > in > > rather large router > > > > LSAs which causes a lots of fragmentation and > adds > > to the flooding > > > > load. > > > > > > > > Quaizar > > > > > > > > > I am in the midst of redesigning an OSPF > > network to accommodate > > > > > significant growth, especially in the Area > 0 > > backbone. There has been > > > > > some concern about the size of the OSPF > > topology that would result and > > > > > whether the routing protocol would remain > > robust, able to handle the odd > > > > > flapping link or memory leak. The network > in > > question is using high-end > > > > > routers with high speed links (at least > DS-3). > > > > > > > > > > Are there any heuristics that someone has > which > > may give us an idea of > > > > > the comfort zone in terms of the database > size, > > number of neighbors, > > > > > routers, etc? > > > > > > > > > > Or, could someone share information on the > size > > of large OSPF > > > > > implementations that they are aware of? > > > > > > > > > > I know that this issue is rather vague > (clouded > > in too many unknowns) > > > > > and may only result in rather ambiguous > > > > > answers, but, one never knows. > > > > > > > > > > Thanks, > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Sun Mar 9 23:27:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24957 for ; Sun, 9 Mar 2003 23:27:04 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0092328B@cherry.ease.lsoft.com>; 9 Mar 2003 23:29:11 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673648 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 9 Mar 2003 23:29:10 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Mar 2003 23:29:09 -0500 Received: from yasu-t23.sfc.wide.ad.jp (YahooBB219186098034.bbtec.net [219.186.98.34]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id F1ECA23876; Mon, 10 Mar 2003 13:29:08 +0900 (JST) References: <20030308.070201.61956851.yasu@sfc.wide.ad.jp> <20030310035228.70463.qmail@web20708.mail.yahoo.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030310.090048.125189123.yasu@sfc.wide.ad.jp> Date: Mon, 10 Mar 2003 09:00:48 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: ospf limits... Comments: To: rohitgupta416@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030310035228.70463.qmail@web20708.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit All I meant is that you can control refresh rate of IS-IS. In larger system, OSPF LSA refresh and/or IS-IS LSP refresh can be several tens of times per second. Then you can reduce the refresh rate only when you use IS-IS, but you can't reduce the refresh rate if you use OSPF. Does that matter the scalability of network, doesn't it ? I don't know actual parameter to enlarge the duration of LSP's life (the time till the LSP expires), because I haven't touched any working IS-IS ... regards, yasu From: Rohit Gupta Subject: Re: ospf limits... Date: Sun, 9 Mar 2003 19:52:28 -0800 > Yasu, > I could not understand as to how this will help in > building larger ISIS areas vis-a-vis OSPF! > > Rohit > > --- Yasuhiro Ohara wrote: > > Hi, > > > > Though I haven't read (or don't remember) any > > document mentions > > that, I guess it comes from the capability of > > controlling the rate > > of bandwidth consumption used by LSA refresh. > > > > Because IS-IS ages LSP by counting down the age and > > expires them > > when the age is 0, IS-IS's "IS" can decide when to > > refresh his LSP > > individually. OSPF specifies when to refresh and/or > > expire LSA > > explicitly, so OSPF system's refresh rate is > > affected by the > > network-size (precisely # of LSA), and can't be > > reduced by > > human manipulation. > > > > regards, > > yasu > > > > From: Rohit Gupta > > Subject: Re: ospf limits... > > Date: Fri, 7 Mar 2003 01:00:14 -0800 > > > > > I remember reading somewhere that ISIS can support > > > bigger areas than OSPF though i am not sure as to > > how > > > exactly, given that both are link state and almost > > > similar. > > > > > > So if you cant scale well with OSPF then you can > > > consider ISIS also. > > > > > > ----- Original Message ----- > > > From: "klara moser" > > > To: > > > Sent: Thursday, March 06, 2003 11:41 PM > > > Subject: Re: ospf limits... > > > > > > > > > > Hi Ravi, > > > > > > > > As far as I know the OSPF protocol has only one > > > limitation on the topologies > > > > size - the Network and Router LSA size. The max > > is > > > 64KB. This limits the number > > > > of links the router can have in a single area, > > > because it has to advertise them > > > > in a single Router LSA. You can do the math. It > > is > > > something like 5 000 links. > > > > > > > > Klara > > > > > > > > Quaizar Vohra wrote: > > > > > > > > > I think the main factor is the amount of > > flooding > > > a router has to do > > > > > which depends on how many adjacencies you have > > and > > > how many LSAs you > > > > > have to flood to each adjacency. So it is > > useful > > > to divide your > > > > > network into multiple areas so as to reduce > > > flooding. Also large > > > > > no. of adjacencies in a single area can result > > in > > > rather large router > > > > > LSAs which causes a lots of fragmentation and > > adds > > > to the flooding > > > > > load. > > > > > > > > > > Quaizar > > > > > > > > > > > I am in the midst of redesigning an OSPF > > > network to accommodate > > > > > > significant growth, especially in the Area > > 0 > > > backbone. There has been > > > > > > some concern about the size of the OSPF > > > topology that would result and > > > > > > whether the routing protocol would remain > > > robust, able to handle the odd > > > > > > flapping link or memory leak. The network > > in > > > question is using high-end > > > > > > routers with high speed links (at least > > DS-3). > > > > > > > > > > > > Are there any heuristics that someone has > > which > > > may give us an idea of > > > > > > the comfort zone in terms of the database > > size, > > > number of neighbors, > > > > > > routers, etc? > > > > > > > > > > > > Or, could someone share information on the > > size > > > of large OSPF > > > > > > implementations that they are aware of? > > > > > > > > > > > > I know that this issue is rather vague > > (clouded > > > in too many unknowns) > > > > > > and may only result in rather ambiguous > > > > > > answers, but, one never knows. > > > > > > > > > > > > Thanks, > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Tax Center - forms, calculators, tips, more > > > http://taxes.yahoo.com/ > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Sun Mar 9 23:37:17 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26875 for ; Sun, 9 Mar 2003 23:37:17 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00923351@cherry.ease.lsoft.com>; 9 Mar 2003 23:39:23 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673676 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 9 Mar 2003 23:39:23 -0500 Received: from 144.189.100.105 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Mar 2003 23:39:23 -0500 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h2A4d1eC021458 for ; Sun, 9 Mar 2003 21:39:01 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id VAA14569 for ; Sun, 9 Mar 2003 21:39:21 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Sun, 9 Mar 2003 23:38:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sun, 9 Mar 2003 23:40:25 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Yasu, Just one small point I want to make. Using http://www.ietf.org/internet-drafts/draft-pillay-esnault-ospf-flooding-04.tx t , we can reduce the Refresh-Rate. Thanks, Vishwas -----Original Message----- From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] Sent: Monday, March 10, 2003 5:31 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: ospf limits... All I meant is that you can control refresh rate of IS-IS. In larger system, OSPF LSA refresh and/or IS-IS LSP refresh can be several tens of times per second. Then you can reduce the refresh rate only when you use IS-IS, but you can't reduce the refresh rate if you use OSPF. Does that matter the scalability of network, doesn't it ? I don't know actual parameter to enlarge the duration of LSP's life (the time till the LSP expires), because I haven't touched any working IS-IS ... regards, yasu From: Rohit Gupta Subject: Re: ospf limits... Date: Sun, 9 Mar 2003 19:52:28 -0800 > Yasu, > I could not understand as to how this will help in > building larger ISIS areas vis-a-vis OSPF! > > Rohit > > --- Yasuhiro Ohara wrote: > > Hi, > > > > Though I haven't read (or don't remember) any > > document mentions > > that, I guess it comes from the capability of > > controlling the rate > > of bandwidth consumption used by LSA refresh. > > > > Because IS-IS ages LSP by counting down the age and > > expires them > > when the age is 0, IS-IS's "IS" can decide when to > > refresh his LSP > > individually. OSPF specifies when to refresh and/or > > expire LSA > > explicitly, so OSPF system's refresh rate is > > affected by the > > network-size (precisely # of LSA), and can't be > > reduced by > > human manipulation. > > > > regards, > > yasu > > > > From: Rohit Gupta > > Subject: Re: ospf limits... > > Date: Fri, 7 Mar 2003 01:00:14 -0800 > > > > > I remember reading somewhere that ISIS can support > > > bigger areas than OSPF though i am not sure as to > > how > > > exactly, given that both are link state and almost > > > similar. > > > > > > So if you cant scale well with OSPF then you can > > > consider ISIS also. > > > > > > ----- Original Message ----- > > > From: "klara moser" > > > To: > > > Sent: Thursday, March 06, 2003 11:41 PM > > > Subject: Re: ospf limits... > > > > > > > > > > Hi Ravi, > > > > > > > > As far as I know the OSPF protocol has only one > > > limitation on the topologies > > > > size - the Network and Router LSA size. The max > > is > > > 64KB. This limits the number > > > > of links the router can have in a single area, > > > because it has to advertise them > > > > in a single Router LSA. You can do the math. It > > is > > > something like 5 000 links. > > > > > > > > Klara > > > > > > > > Quaizar Vohra wrote: > > > > > > > > > I think the main factor is the amount of > > flooding > > > a router has to do > > > > > which depends on how many adjacencies you have > > and > > > how many LSAs you > > > > > have to flood to each adjacency. So it is > > useful > > > to divide your > > > > > network into multiple areas so as to reduce > > > flooding. Also large > > > > > no. of adjacencies in a single area can result > > in > > > rather large router > > > > > LSAs which causes a lots of fragmentation and > > adds > > > to the flooding > > > > > load. > > > > > > > > > > Quaizar > > > > > > > > > > > I am in the midst of redesigning an OSPF > > > network to accommodate > > > > > > significant growth, especially in the Area > > 0 > > > backbone. There has been > > > > > > some concern about the size of the OSPF > > > topology that would result and > > > > > > whether the routing protocol would remain > > > robust, able to handle the odd > > > > > > flapping link or memory leak. The network > > in > > > question is using high-end > > > > > > routers with high speed links (at least > > DS-3). > > > > > > > > > > > > Are there any heuristics that someone has > > which > > > may give us an idea of > > > > > > the comfort zone in terms of the database > > size, > > > number of neighbors, > > > > > > routers, etc? > > > > > > > > > > > > Or, could someone share information on the > > size > > > of large OSPF > > > > > > implementations that they are aware of? > > > > > > > > > > > > I know that this issue is rather vague > > (clouded > > > in too many unknowns) > > > > > > and may only result in rather ambiguous > > > > > > answers, but, one never knows. > > > > > > > > > > > > Thanks, > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Tax Center - forms, calculators, tips, more > > > http://taxes.yahoo.com/ > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Sun Mar 9 23:46:14 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28540 for ; Sun, 9 Mar 2003 23:46:14 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00923302@cherry.ease.lsoft.com>; 9 Mar 2003 23:48:21 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673698 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 9 Mar 2003 23:48:20 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Mar 2003 23:48:19 -0500 Received: from yasu-t23.sfc.wide.ad.jp (YahooBB219186098034.bbtec.net [219.186.98.34]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id D027C23876; Mon, 10 Mar 2003 13:48:18 +0900 (JST) References: X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030310.091944.58457970.yasu@sfc.wide.ad.jp> Date: Mon, 10 Mar 2003 09:19:44 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: ospf limits... Comments: To: VishwasM@NETPLANE.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Thanks Singh, Manral, I agree, OSPF has DoNotAge bit about LSA refresh. I forgot about that. And so what I said might be wrong, there'll be no scalability issues in terms of refresh rate. sorry. regards, yasu From: "Manral, Vishwas" Subject: Re: ospf limits... Date: Sun, 9 Mar 2003 23:40:25 -0500 > Hi Yasu, > > Just one small point I want to make. > > Using > http://www.ietf.org/internet-drafts/draft-pillay-esnault-ospf-flooding-04.tx > t , we can reduce the Refresh-Rate. > > Thanks, > Vishwas > > -----Original Message----- > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > Sent: Monday, March 10, 2003 5:31 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: ospf limits... > > > All I meant is that you can control refresh rate of IS-IS. > > In larger system, OSPF LSA refresh and/or IS-IS LSP refresh > can be several tens of times per second. Then you can reduce > the refresh rate only when you use IS-IS, but you can't reduce > the refresh rate if you use OSPF. > > Does that matter the scalability of network, doesn't it ? > > I don't know actual parameter to enlarge the duration of LSP's life > (the time till the LSP expires), because I haven't touched > any working IS-IS ... > > regards, > yasu > > From: Rohit Gupta > Subject: Re: ospf limits... > Date: Sun, 9 Mar 2003 19:52:28 -0800 > > > Yasu, > > I could not understand as to how this will help in > > building larger ISIS areas vis-a-vis OSPF! > > > > Rohit > > > > --- Yasuhiro Ohara wrote: > > > Hi, > > > > > > Though I haven't read (or don't remember) any > > > document mentions > > > that, I guess it comes from the capability of > > > controlling the rate > > > of bandwidth consumption used by LSA refresh. > > > > > > Because IS-IS ages LSP by counting down the age and > > > expires them > > > when the age is 0, IS-IS's "IS" can decide when to > > > refresh his LSP > > > individually. OSPF specifies when to refresh and/or > > > expire LSA > > > explicitly, so OSPF system's refresh rate is > > > affected by the > > > network-size (precisely # of LSA), and can't be > > > reduced by > > > human manipulation. > > > > > > regards, > > > yasu > > > > > > From: Rohit Gupta > > > Subject: Re: ospf limits... > > > Date: Fri, 7 Mar 2003 01:00:14 -0800 > > > > > > > I remember reading somewhere that ISIS can support > > > > bigger areas than OSPF though i am not sure as to > > > how > > > > exactly, given that both are link state and almost > > > > similar. > > > > > > > > So if you cant scale well with OSPF then you can > > > > consider ISIS also. > > > > > > > > ----- Original Message ----- > > > > From: "klara moser" > > > > To: > > > > Sent: Thursday, March 06, 2003 11:41 PM > > > > Subject: Re: ospf limits... > > > > > > > > > > > > > Hi Ravi, > > > > > > > > > > As far as I know the OSPF protocol has only one > > > > limitation on the topologies > > > > > size - the Network and Router LSA size. The max > > > is > > > > 64KB. This limits the number > > > > > of links the router can have in a single area, > > > > because it has to advertise them > > > > > in a single Router LSA. You can do the math. It > > > is > > > > something like 5 000 links. > > > > > > > > > > Klara > > > > > > > > > > Quaizar Vohra wrote: > > > > > > > > > > > I think the main factor is the amount of > > > flooding > > > > a router has to do > > > > > > which depends on how many adjacencies you have > > > and > > > > how many LSAs you > > > > > > have to flood to each adjacency. So it is > > > useful > > > > to divide your > > > > > > network into multiple areas so as to reduce > > > > flooding. Also large > > > > > > no. of adjacencies in a single area can result > > > in > > > > rather large router > > > > > > LSAs which causes a lots of fragmentation and > > > adds > > > > to the flooding > > > > > > load. > > > > > > > > > > > > Quaizar > > > > > > > > > > > > > I am in the midst of redesigning an OSPF > > > > network to accommodate > > > > > > > significant growth, especially in the Area > > > 0 > > > > backbone. There has been > > > > > > > some concern about the size of the OSPF > > > > topology that would result and > > > > > > > whether the routing protocol would remain > > > > robust, able to handle the odd > > > > > > > flapping link or memory leak. The network > > > in > > > > question is using high-end > > > > > > > routers with high speed links (at least > > > DS-3). > > > > > > > > > > > > > > Are there any heuristics that someone has > > > which > > > > may give us an idea of > > > > > > > the comfort zone in terms of the database > > > size, > > > > number of neighbors, > > > > > > > routers, etc? > > > > > > > > > > > > > > Or, could someone share information on the > > > size > > > > of large OSPF > > > > > > > implementations that they are aware of? > > > > > > > > > > > > > > I know that this issue is rather vague > > > (clouded > > > > in too many unknowns) > > > > > > > and may only result in rather ambiguous > > > > > > > answers, but, one never knows. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > __________________________________________________ > > > > Do you Yahoo!? > > > > Yahoo! Tax Center - forms, calculators, tips, more > > > > http://taxes.yahoo.com/ > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Sun Mar 9 23:51:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29515 for ; Sun, 9 Mar 2003 23:51:48 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00923222@cherry.ease.lsoft.com>; 9 Mar 2003 23:53:49 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673718 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 9 Mar 2003 23:53:49 -0500 Received: from 129.188.136.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Mar 2003 23:53:49 -0500 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2A4rm05007276 for ; Sun, 9 Mar 2003 21:53:48 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id VAA11859 for ; Sun, 9 Mar 2003 21:51:50 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Sun, 9 Mar 2003 23:53:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sun, 9 Mar 2003 23:55:38 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: ospf limits... Comments: To: Yasuhiro Ohara To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Yasu, However not all routers may support DC-Extensions.;-) Thanks, Vishwas -----Original Message----- From: Yasuhiro Ohara [mailto:yasu@sfc.wide.ad.jp] Sent: Monday, March 10, 2003 5:50 AM To: OSPF@DISCUSS.MICROSOFT.COM; VishwasM@NETPLANE.COM Subject: Re: ospf limits... Thanks Singh, Manral, I agree, OSPF has DoNotAge bit about LSA refresh. I forgot about that. And so what I said might be wrong, there'll be no scalability issues in terms of refresh rate. sorry. regards, yasu From: "Manral, Vishwas" Subject: Re: ospf limits... Date: Sun, 9 Mar 2003 23:40:25 -0500 > Hi Yasu, > > Just one small point I want to make. > > Using > http://www.ietf.org/internet-drafts/draft-pillay-esnault-ospf-flooding-04.tx > t , we can reduce the Refresh-Rate. > > Thanks, > Vishwas > > -----Original Message----- > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > Sent: Monday, March 10, 2003 5:31 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: ospf limits... > > > All I meant is that you can control refresh rate of IS-IS. > > In larger system, OSPF LSA refresh and/or IS-IS LSP refresh > can be several tens of times per second. Then you can reduce > the refresh rate only when you use IS-IS, but you can't reduce > the refresh rate if you use OSPF. > > Does that matter the scalability of network, doesn't it ? > > I don't know actual parameter to enlarge the duration of LSP's life > (the time till the LSP expires), because I haven't touched > any working IS-IS ... > > regards, > yasu > > From: Rohit Gupta > Subject: Re: ospf limits... > Date: Sun, 9 Mar 2003 19:52:28 -0800 > > > Yasu, > > I could not understand as to how this will help in > > building larger ISIS areas vis-a-vis OSPF! > > > > Rohit > > > > --- Yasuhiro Ohara wrote: > > > Hi, > > > > > > Though I haven't read (or don't remember) any > > > document mentions > > > that, I guess it comes from the capability of > > > controlling the rate > > > of bandwidth consumption used by LSA refresh. > > > > > > Because IS-IS ages LSP by counting down the age and > > > expires them > > > when the age is 0, IS-IS's "IS" can decide when to > > > refresh his LSP > > > individually. OSPF specifies when to refresh and/or > > > expire LSA > > > explicitly, so OSPF system's refresh rate is > > > affected by the > > > network-size (precisely # of LSA), and can't be > > > reduced by > > > human manipulation. > > > > > > regards, > > > yasu > > > > > > From: Rohit Gupta > > > Subject: Re: ospf limits... > > > Date: Fri, 7 Mar 2003 01:00:14 -0800 > > > > > > > I remember reading somewhere that ISIS can support > > > > bigger areas than OSPF though i am not sure as to > > > how > > > > exactly, given that both are link state and almost > > > > similar. > > > > > > > > So if you cant scale well with OSPF then you can > > > > consider ISIS also. > > > > > > > > ----- Original Message ----- > > > > From: "klara moser" > > > > To: > > > > Sent: Thursday, March 06, 2003 11:41 PM > > > > Subject: Re: ospf limits... > > > > > > > > > > > > > Hi Ravi, > > > > > > > > > > As far as I know the OSPF protocol has only one > > > > limitation on the topologies > > > > > size - the Network and Router LSA size. The max > > > is > > > > 64KB. This limits the number > > > > > of links the router can have in a single area, > > > > because it has to advertise them > > > > > in a single Router LSA. You can do the math. It > > > is > > > > something like 5 000 links. > > > > > > > > > > Klara > > > > > > > > > > Quaizar Vohra wrote: > > > > > > > > > > > I think the main factor is the amount of > > > flooding > > > > a router has to do > > > > > > which depends on how many adjacencies you have > > > and > > > > how many LSAs you > > > > > > have to flood to each adjacency. So it is > > > useful > > > > to divide your > > > > > > network into multiple areas so as to reduce > > > > flooding. Also large > > > > > > no. of adjacencies in a single area can result > > > in > > > > rather large router > > > > > > LSAs which causes a lots of fragmentation and > > > adds > > > > to the flooding > > > > > > load. > > > > > > > > > > > > Quaizar > > > > > > > > > > > > > I am in the midst of redesigning an OSPF > > > > network to accommodate > > > > > > > significant growth, especially in the Area > > > 0 > > > > backbone. There has been > > > > > > > some concern about the size of the OSPF > > > > topology that would result and > > > > > > > whether the routing protocol would remain > > > > robust, able to handle the odd > > > > > > > flapping link or memory leak. The network > > > in > > > > question is using high-end > > > > > > > routers with high speed links (at least > > > DS-3). > > > > > > > > > > > > > > Are there any heuristics that someone has > > > which > > > > may give us an idea of > > > > > > > the comfort zone in terms of the database > > > size, > > > > number of neighbors, > > > > > > > routers, etc? > > > > > > > > > > > > > > Or, could someone share information on the > > > size > > > > of large OSPF > > > > > > > implementations that they are aware of? > > > > > > > > > > > > > > I know that this issue is rather vague > > > (clouded > > > > in too many unknowns) > > > > > > > and may only result in rather ambiguous > > > > > > > answers, but, one never knows. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > __________________________________________________ > > > > Do you Yahoo!? > > > > Yahoo! Tax Center - forms, calculators, tips, more > > > > http://taxes.yahoo.com/ > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 10 00:03:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01591 for ; Mon, 10 Mar 2003 00:03:18 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.009233AA@cherry.ease.lsoft.com>; Mon, 10 Mar 2003 0:05:18 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673817 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 00:05:15 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Mar 2003 00:05:14 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2A55ES35171 for ; Sun, 9 Mar 2003 21:05:14 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id h2A55EE46065; Sun, 9 Mar 2003 21:05:14 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <20030310035228.70463.qmail@web20708.mail.yahoo.com> Message-ID: <200303100505.h2A55EE46065@cirrus.juniper.net> Date: Sun, 9 Mar 2003 21:05:14 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030310035228.70463.qmail@web20708.mail.yahoo.com> (message from Rohit Gupta on Sun, 9 Mar 2003 19:52:28 -0800) Precedence: list For all practical purposes, the designs of the OSPF and ISIS protocols will not be the limiting factor in the size of an area, unless (a) you have a really good implementation, and (b) you feel the need to dump excessive numbers (many thousands) of external and stub routes into the protocol. Most implementations will crash and burn before the topology gets big enough to become an issue, and most people don't dump externals into their IGPs (they use BGP instead.) Architecturally, OSPF limits the inter-router topology and stub routes due to the 64KB limit on the Router LSA, and ISIS limits the total amount of information due to the 256 LSP "fragment" limit. One could come up with various hacks for either protocol if these limits were actually, well, limiting, but this has never been the case in (sane) practice. Historically, the ISIS implementation from a particular major vendor has had better scaling characteristics than the OSPF implementation of that particular major vendor, but this this isn't really the case for another major vendor. ;-) --Dave From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 10 00:06:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02100 for ; Mon, 10 Mar 2003 00:06:02 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.009233C5@cherry.ease.lsoft.com>; Mon, 10 Mar 2003 0:08:09 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673836 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 00:08:08 -0500 Received: from 203.254.224.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Mar 2003 00:08:08 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HBI00201OVMWB@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 14:06:58 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HBI00KSXOVM4M@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 14:06:58 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HBI001M6PKC8J@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 14:21:51 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030310035228.70463.qmail@web20708.mail.yahoo.com> Message-ID: <092401c2e6c2$d5fe9370$b4036c6b@sisodomain.com> Date: Mon, 10 Mar 2003 10:36:38 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT I think ISIS might be preferred to support larger networks because all the IP prefixes align as leaves in the SPF tree, meaning full SPF is not run in most cases where a link failure does not impact the core topology. In OSPF, all IP link failures in an area trigger LSA updates, which, in turn, cause full SPF runs. Therefore, a large OSPF area would be more demanding on processing resources on the average than an ISIS network of comparable size. Regards, Manav ----- Original Message ----- From: "Rohit Gupta" To: Sent: Monday, March 10, 2003 9:22 AM Subject: Re: ospf limits... > Yasu, > I could not understand as to how this will help in > building larger ISIS areas vis-a-vis OSPF! > > Rohit > > --- Yasuhiro Ohara wrote: > > Hi, > > > > Though I haven't read (or don't remember) any > > document mentions > > that, I guess it comes from the capability of > > controlling the rate > > of bandwidth consumption used by LSA refresh. > > > > Because IS-IS ages LSP by counting down the age and > > expires them > > when the age is 0, IS-IS's "IS" can decide when to > > refresh his LSP > > individually. OSPF specifies when to refresh and/or > > expire LSA > > explicitly, so OSPF system's refresh rate is > > affected by the > > network-size (precisely # of LSA), and can't be > > reduced by > > human manipulation. > > > > regards, > > yasu > > > > From: Rohit Gupta > > Subject: Re: ospf limits... > > Date: Fri, 7 Mar 2003 01:00:14 -0800 > > > > > I remember reading somewhere that ISIS can support > > > bigger areas than OSPF though i am not sure as to > > how > > > exactly, given that both are link state and almost > > > similar. > > > > > > So if you cant scale well with OSPF then you can > > > consider ISIS also. > > > > > > ----- Original Message ----- > > > From: "klara moser" > > > To: > > > Sent: Thursday, March 06, 2003 11:41 PM > > > Subject: Re: ospf limits... > > > > > > > > > > Hi Ravi, > > > > > > > > As far as I know the OSPF protocol has only one > > > limitation on the topologies > > > > size - the Network and Router LSA size. The max > > is > > > 64KB. This limits the number > > > > of links the router can have in a single area, > > > because it has to advertise them > > > > in a single Router LSA. You can do the math. It > > is > > > something like 5 000 links. > > > > > > > > Klara > > > > > > > > Quaizar Vohra wrote: > > > > > > > > > I think the main factor is the amount of > > flooding > > > a router has to do > > > > > which depends on how many adjacencies you have > > and > > > how many LSAs you > > > > > have to flood to each adjacency. So it is > > useful > > > to divide your > > > > > network into multiple areas so as to reduce > > > flooding. Also large > > > > > no. of adjacencies in a single area can result > > in > > > rather large router > > > > > LSAs which causes a lots of fragmentation and > > adds > > > to the flooding > > > > > load. > > > > > > > > > > Quaizar > > > > > > > > > > > I am in the midst of redesigning an OSPF > > > network to accommodate > > > > > > significant growth, especially in the Area > > 0 > > > backbone. There has been > > > > > > some concern about the size of the OSPF > > > topology that would result and > > > > > > whether the routing protocol would remain > > > robust, able to handle the odd > > > > > > flapping link or memory leak. The network > > in > > > question is using high-end > > > > > > routers with high speed links (at least > > DS-3). > > > > > > > > > > > > Are there any heuristics that someone has > > which > > > may give us an idea of > > > > > > the comfort zone in terms of the database > > size, > > > number of neighbors, > > > > > > routers, etc? > > > > > > > > > > > > Or, could someone share information on the > > size > > > of large OSPF > > > > > > implementations that they are aware of? > > > > > > > > > > > > I know that this issue is rather vague > > (clouded > > > in too many unknowns) > > > > > > and may only result in rather ambiguous > > > > > > answers, but, one never knows. > > > > > > > > > > > > Thanks, > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Tax Center - forms, calculators, tips, more > > > http://taxes.yahoo.com/ > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 10 00:10:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02886 for ; Mon, 10 Mar 2003 00:10:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0092358D@cherry.ease.lsoft.com>; Mon, 10 Mar 2003 0:12:45 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673869 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 00:12:44 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Mar 2003 00:12:44 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2A5CiS35344 for ; Sun, 9 Mar 2003 21:12:44 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id h2A5Cin46090; Sun, 9 Mar 2003 21:12:44 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <20030310035228.70463.qmail@web20708.mail.yahoo.com> <092401c2e6c2$d5fe9370$b4036c6b@sisodomain.com> Message-ID: <200303100512.h2A5Cin46090@cirrus.juniper.net> Date: Sun, 9 Mar 2003 21:12:44 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <092401c2e6c2$d5fe9370$b4036c6b@sisodomain.com> (message from Manav Bhatia on Mon, 10 Mar 2003 10:36:38 +0530) Precedence: list I think ISIS might be preferred to support larger networks because all the IP prefixes align as leaves in the SPF tree, meaning full SPF is not run in most cases where a link failure does not impact the core topology. In OSPF, all IP link failures in an area trigger LSA updates, which, in turn, cause full SPF runs. Therefore, a large OSPF area would be more demanding on processing resources on the average than an ISIS network of comparable size. This is an implementation detail that is not necessarily true. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 10 00:27:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05893 for ; Mon, 10 Mar 2003 00:27:09 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0092345B@cherry.ease.lsoft.com>; Mon, 10 Mar 2003 0:29:16 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673908 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 00:29:16 -0500 Received: from 203.254.224.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Mar 2003 00:29:16 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HBI00319PUUJ8@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 14:28:06 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HBI00KHRPU9AP@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 14:27:46 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HBI00155QJ08J@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 14:42:39 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030310035228.70463.qmail@web20708.mail.yahoo.com> <092401c2e6c2$d5fe9370$b4036c6b@sisodomain.com> <200303100512.h2A5Cin46090@cirrus.juniper.net> Message-ID: <094801c2e6c5$bdcf2410$b4036c6b@sisodomain.com> Date: Mon, 10 Mar 2003 10:57:25 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Dave, I believe in ISIS all IP reachability ends up as leaf nodes and thus any changes in the IP reachability alone results, only in a partial SPF run (Partial Route Calculation, or PRC); the routers in the tree need to calculate only the parts of the tree in which the leaf node for that destination network resides. They need not run the entire SPF. Whereas in OSPF one may run partial SPF only in case of changes in inter-area routes. Am i missing something? Regards, Manav ----- Original Message ----- From: "Dave Katz" To: Sent: Monday, March 10, 2003 10:42 AM Subject: Re: ospf limits... > I think ISIS might be preferred to support larger networks because all the > IP prefixes align as leaves in the SPF tree, meaning full SPF is not run in > most cases where a link failure does not impact the core topology. In OSPF, > all IP link failures in an area trigger LSA updates, which, in turn, cause > full SPF runs. Therefore, a large OSPF area would be more demanding on > processing resources on the average than an ISIS network of comparable > size. > > This is an implementation detail that is not necessarily true. > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 10 00:34:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07195 for ; Mon, 10 Mar 2003 00:34:06 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00923633@cherry.ease.lsoft.com>; Mon, 10 Mar 2003 0:36:12 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673937 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 00:36:12 -0500 Received: from 144.189.100.103 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Mar 2003 00:36:11 -0500 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2A5Zdc3017493 for ; Sun, 9 Mar 2003 22:35:39 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id WAA19750 for ; Sun, 9 Mar 2003 22:36:10 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 00:36:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 10 Mar 2003 00:37:50 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Manav, I think the point you are trying to make is that Reachability information is kept seperate from topology information in ISIS and OSPFv3, while it is not in OSPFv2. I am not sure however, how often the case where, IP Reachability information changes while topology information does not, will occur. I am not sure this would be a restriction on the OSPF area limit. Thanks, Vishwas -----Original Message----- From: Manav Bhatia [mailto:manav@SAMSUNG.COM] Sent: Monday, March 10, 2003 10:57 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: ospf limits... Dave, I believe in ISIS all IP reachability ends up as leaf nodes and thus any changes in the IP reachability alone results, only in a partial SPF run (Partial Route Calculation, or PRC); the routers in the tree need to calculate only the parts of the tree in which the leaf node for that destination network resides. They need not run the entire SPF. Whereas in OSPF one may run partial SPF only in case of changes in inter-area routes. Am i missing something? Regards, Manav ----- Original Message ----- From: "Dave Katz" To: Sent: Monday, March 10, 2003 10:42 AM Subject: Re: ospf limits... > I think ISIS might be preferred to support larger networks because all the > IP prefixes align as leaves in the SPF tree, meaning full SPF is not run in > most cases where a link failure does not impact the core topology. In OSPF, > all IP link failures in an area trigger LSA updates, which, in turn, cause > full SPF runs. Therefore, a large OSPF area would be more demanding on > processing resources on the average than an ISIS network of comparable > size. > > This is an implementation detail that is not necessarily true. > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 10 01:47:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20312 for ; Mon, 10 Mar 2003 01:47:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0092364B@cherry.ease.lsoft.com>; Mon, 10 Mar 2003 1:49:51 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 674065 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 01:49:51 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Mar 2003 01:49:51 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2A6noS39291 for ; Sun, 9 Mar 2003 22:49:50 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id h2A6noB46227; Sun, 9 Mar 2003 22:49:50 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <20030310035228.70463.qmail@web20708.mail.yahoo.com> <092401c2e6c2$d5fe9370$b4036c6b@sisodomain.com> <200303100512.h2A5Cin46090@cirrus.juniper.net> <094801c2e6c5$bdcf2410$b4036c6b@sisodomain.com> Message-ID: <200303100649.h2A6noB46227@cirrus.juniper.net> Date: Sun, 9 Mar 2003 22:49:50 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <094801c2e6c5$bdcf2410$b4036c6b@sisodomain.com> (message from Manav Bhatia on Mon, 10 Mar 2003 10:57:25 +0530) Precedence: list I believe in ISIS all IP reachability ends up as leaf nodes and thus any changes in the IP reachability alone results, only in a partial SPF run (Partial Route Calculation, or PRC); the routers in the tree need to calculate only the parts of the tree in which the leaf node for that destination network resides. They need not run the entire SPF. Whereas in OSPF one may run partial SPF only in case of changes in inter-area routes. Am i missing something? Yes. Fundamentally the problem is the same in both--if the actual link topology changes, an SPF is required. If leaf connectivity changes, it is not. Determining the difference is an exercise for the implementor. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 10 14:12:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08763 for ; Mon, 10 Mar 2003 14:12:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.009244BC@cherry.ease.lsoft.com>; Mon, 10 Mar 2003 14:14:18 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 675735 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 14:14:17 -0500 Received: from 207.217.120.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Mar 2003 14:14:17 -0500 Received: from user-2ivfnua.dialup.mindspring.com ([165.247.223.202] helo=earthlink.net) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18sSj1-00055D-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 11:14:16 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E6CDCEC.6152CFCF@earthlink.net> Date: Mon, 10 Mar 2003 10:43:56 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Ravi, One major concern about with respect to the number of neighbors, is their consistency/frequency in sending hellos to prevent adjs from being torn down uncessarily vs the amount of time a link may be down and then tearing down the adj and running another SPF computation. In my opinion a core router, must be able to lookup / insert maybe 500 elements per second in its LSDB, run single digit ms duration SPF calculation times, and pass 98%+ of its pkts to the proper destination. I would think that the above core router would need to support up to 500 nbrs per area and a 1 million LSDB table size. Mitchell Erblich Sr Software Engineer ============================= Ravi Malhotra wrote: > > I am in the midst of redesigning an OSPF network to accommodate > significant growth, especially in the Area 0 backbone. There has been > some concern about the size of the OSPF topology that would result and > whether the routing protocol would remain robust, able to handle the odd > flapping link or memory leak. The network in question is using high-end > routers with high speed links (at least DS-3). > > Are there any heuristics that someone has which may give us an idea of > the comfort zone in terms of the database size, number of neighbors, > routers, etc? > > Or, could someone share information on the size of large OSPF > implementations that they are aware of? > > I know that this issue is rather vague (clouded in too many unknowns) > and may only result in rather ambiguous > answers, but, one never knows. > > Thanks, > > Ravi > > The information in this e-mail, and any attachment therein, is > confidential and for use by the addressee only. If you are not the > intended recipient, please return the e-mail to the sender and delete it > from your computer. Although The Bank of New York attempts to sweep > e-mail and attachments for viruses, it does not guarantee that either > are virus-free and accepts no liability for any damage sustained as a > result of viruses. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 10 14:46:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10180 for ; Mon, 10 Mar 2003 14:46:52 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00924738@cherry.ease.lsoft.com>; Mon, 10 Mar 2003 14:48:58 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 675848 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 14:48:57 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Mar 2003 14:48:57 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA08205 for ; Mon, 10 Mar 2003 14:48:55 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA00371 for ; Mon, 10 Mar 2003 14:48:57 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 14:48:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763501@vie-msgusr-01.dc.fore.com> Date: Mon, 10 Mar 2003 14:48:47 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list [Manav] -> I believe in ISIS all IP reachability ends up as leaf -> nodes and thus any -> changes in the IP reachability alone results, only in a -> partial SPF run -> (Partial Route Calculation, or PRC); the routers in the -> tree need to calculate only the parts of the tree in which -> the leaf node for that -> destination network resides. They need not run the entire SPF. [Vishwas] -> I am not sure however, how often the case where, IP -> Reachability information changes while topology information -> does not, will occur. [Dave] -> Yes. Fundamentally the problem is the same in both--if the actual -> link topology changes, an SPF is required. If leaf connectivity -> changes, it is not. I think we are not in sync here w.r.t two things (correct me): 1. *leaf* (router) in the graph (network) vs *leaf* (node) in the tree, and 2. The *reachability* vs *link topology* changes Manav, if ISIS design allows implementer to choose index trees such that all *reachability* resides in the leaves (in the tree) - including the reachability of non-leaf (transit) routers resides on leaf nodes in the tree - then YES, it is very easy to skip the Full-SPF when *reachability* information alone changes (with out even going to Partial-SPF - just by updating the parent - pi - links). What I mean by reachability here is: some address in a leaf node in the tree (including some transit router's address in the graph) changed from x to y. As Dave said, when *link topology* changes, then NO. I think even in the case of index trees we have to do whole SPF. For example, if a link goes down, we chop-off an edge in the tree, that will result in all leaves falling off of the tree. We have to reinsert (set union algo) all those singleton leaves (reachability) back to the tree. From the perspective of Dijkstra's algorithm, the only way we can do those reinsertions is by doing the whole-SPF. Because, Dijkstra's algo is like Prim's unlike Kruskal's forest trees where you can find the least-weight edge that connects the two distinct forests. So, we have to do the whole SPF when topology changes. Remember, as we know, we no need to maintain the whole tree in case of OSPF or ISIS. All we need is the *new* parent for the singleton leaf (which fell off because of a link cut). Just to find the new parent, we have to do the whole-SPF. If the link got cut will result in a two disjoint forests (unlike falling off leaves) then we can find another safe least weight edge that will joint the disjoint forests by partial-SPF run (updating few pi links in the forests). Finding out such cut (which makes the tree disjoint) is real difficult (thank to Robert Tarjan). Neverthless, if we maintian some additional information about the topology structure (by augmenting the data structures) then we can do Partial-SPF. Please look for such work in OSPF: http://www.isoc.org/inet99/proceedings/4g/4g_2.htm Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 10 14:57:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10571 for ; Mon, 10 Mar 2003 14:57:47 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0092474F@cherry.ease.lsoft.com>; Mon, 10 Mar 2003 14:59:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 675957 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 14:59:53 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Mar 2003 14:59:53 -0500 Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2AJxqS89655 for ; Mon, 10 Mar 2003 11:59:52 -0800 (PST) (envelope-from qv@juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h2AJxqk32726; Mon, 10 Mar 2003 11:59:52 -0800 (PST) (envelope-from qv) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3E6CDCEC.6152CFCF@earthlink.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200303101959.h2AJxqk32726@fuinar.juniper.net> Date: Mon, 10 Mar 2003 11:59:52 -0800 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E6CDCEC.6152CFCF@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Mitchell, Unless you do DoNotAge LSAs, you will end up flooding close to 400 LSA per second just due to periodic refreshes (asuuming around 2500 seconds as refresh interval for each LSA). If you flood this to 500 nbrs, you end up generating 400 * 500 LSAs per seconds, which is close to 200,000 LSAs per second. Which amounts to approx 200,000 * 32 bytes per seconds (assuming most LSAs are external). This come to 6.4 mbytes of LSA traffic per second. And this alone in a single area, let alone multiple areas. Also we are not counting any processing overheads or other ospf traffic. I would be quite surprised if any vendor comes even close to this. Also 500 nbrs in a single area would mean very large router LSAs, resulting in lots of fragmentation. Fragmentation coupled with flooding to 500 nbrs will be quite CPU intensive. I would be more comfortable with 50 to 100 nbrs per area, 500 to 1000 nbrs across multiple areas, with upto 10K LSAs per area. Quaizar > Ravi, > > > One major concern about with respect to the number of > neighbors, is their consistency/frequency in sending hellos > to prevent adjs from being torn down uncessarily vs the > amount of time a link may be down and then tearing down > the adj and running another SPF computation. > > In my opinion a core router, must be able to lookup / insert > maybe 500 elements per second in its LSDB, run single digit > ms duration SPF calculation times, and pass 98%+ of its pkts > to the proper destination. > > I would think that the above core router would need to support > up to 500 nbrs per area and a 1 million LSDB table size. > > Mitchell Erblich > Sr Software Engineer > ============================= > > > Ravi Malhotra wrote: > > > > I am in the midst of redesigning an OSPF network to accommodate > > significant growth, especially in the Area 0 backbone. There has been > > some concern about the size of the OSPF topology that would result and > > whether the routing protocol would remain robust, able to handle the odd > > flapping link or memory leak. The network in question is using high-end > > routers with high speed links (at least DS-3). > > > > Are there any heuristics that someone has which may give us an idea of > > the comfort zone in terms of the database size, number of neighbors, > > routers, etc? > > > > Or, could someone share information on the size of large OSPF > > implementations that they are aware of? > > > > I know that this issue is rather vague (clouded in too many unknowns) > > and may only result in rather ambiguous > > answers, but, one never knows. > > > > Thanks, > > > > Ravi > > > > The information in this e-mail, and any attachment therein, is > > confidential and for use by the addressee only. If you are not the > > intended recipient, please return the e-mail to the sender and delete it > > from your computer. Although The Bank of New York attempts to sweep > > e-mail and attachments for viruses, it does not guarantee that either > > are virus-free and accepts no liability for any damage sustained as a > > result of viruses. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 10 15:10:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11810 for ; Mon, 10 Mar 2003 15:10:59 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00924879@cherry.ease.lsoft.com>; Mon, 10 Mar 2003 15:13:05 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 676010 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 15:13:05 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Mar 2003 15:13:05 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA09181 for ; Mon, 10 Mar 2003 15:13:02 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA04303 for ; Mon, 10 Mar 2003 15:13:04 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Mar 2003 15:13:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763502@vie-msgusr-01.dc.fore.com> Date: Mon, 10 Mar 2003 15:12:54 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -> Manav, if ISIS design allows implementer to choose index trees -> such that all *reachability* resides in the leaves (in the tree) - -> including the reachability of non-leaf (transit) routers resides -> on leaf nodes in the tree - then YES, it is very easy to skip -> the Full-SPF when *reachability* information alone changes -> (with out even going to Partial-SPF - just by updating the parent -> - pi - links). What I mean by reachability here is: some address -> in a leaf node in the tree (including some transit router's -> address in the graph) changed from x to y. I am not satisfied with what I wrote. Let me re-phrase. If an ISIS implementation stores reachability information only in leaf-nodes (in a tree) then the amount of work we need to do will be less if the reachability alone changes. If OSPFv2 (not OSPFv3) stores reachability information in internal nodes as well, then the amount of work is little more (very little) when compared to index trees above. All we need to do is, walk all the (immediate) children and ask them "eh! I am the new parent for you, nothing changed, just point to me". So, where we store reachability information in the tree is irrelevant to the size of the tree (that is, the size of the area). It is all implementation dependent. Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 10 17:07:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16561 for ; Mon, 10 Mar 2003 17:07:03 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00924DE3@cherry.ease.lsoft.com>; Mon, 10 Mar 2003 17:09:07 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 676304 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 17:09:06 -0500 Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Mar 2003 17:09:06 -0500 Received: from user-2ivfnua.dialup.mindspring.com ([165.247.223.202] helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18sVS8-0002HZ-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 14:09:01 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <3E6CDCEC.6152CFCF@earthlink.net> <200303101959.h2AJxqk32726@fuinar.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E6D0595.FF344CFD@earthlink.net> Date: Mon, 10 Mar 2003 13:37:25 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yes, He did mention area 0 backbone. So, I am assuming "signifciant growth" and multiple Gb or 10Gb links bandwidth links. The "maybe 500 elements per sec" to "maybe 500 elements per nbr per sec" suggestion is based on whether DR and BDRs exist within the OSPF backbone OR a full-mesh exists between nbrs in an area. And of course 500LSAs per sec * 60 = 30K. And 30k * 30 minutes = 900k. Flooding is only over DR/BDR links when they exist, so that would minimize the LSA flooding overhead to what would minimally be about 545 elements per sec. Mitchell Erblich Sr Software Engineer ========================= Quaizar Vohra wrote: > > Mitchell, > > Unless you do DoNotAge LSAs, you will end up flooding close to > 400 LSA per second just due to periodic refreshes (asuuming around > 2500 seconds as refresh interval for each LSA). If you flood this to > 500 nbrs, you end up generating 400 * 500 LSAs per seconds, which is > close to 200,000 LSAs per second. Which amounts to approx 200,000 * 32 > bytes per seconds (assuming most LSAs are external). This come to 6.4 > mbytes of LSA traffic per second. And this alone in a single area, let > alone multiple areas. Also we are not counting any processing > overheads or other ospf traffic. I would be quite surprised if any > vendor comes even close to this. > > Also 500 nbrs in a single area would mean very large router LSAs, > resulting in lots of fragmentation. Fragmentation coupled with > flooding to 500 nbrs will be quite CPU intensive. > > I would be more comfortable with 50 to 100 nbrs per area, 500 to 1000 > nbrs across multiple areas, with upto 10K LSAs per area. > > Quaizar > > > Ravi, > > > > > > One major concern about with respect to the number of > > neighbors, is their consistency/frequency in sending hellos > > to prevent adjs from being torn down uncessarily vs the > > amount of time a link may be down and then tearing down > > the adj and running another SPF computation. > > > > In my opinion a core router, must be able to lookup / insert > > maybe 500 elements per second in its LSDB, run single digit > > ms duration SPF calculation times, and pass 98%+ of its pkts > > to the proper destination. > > > > I would think that the above core router would need to support > > up to 500 nbrs per area and a 1 million LSDB table size. > > > > Mitchell Erblich > > Sr Software Engineer > > ============================= > > > > > > Ravi Malhotra wrote: > > > > > > I am in the midst of redesigning an OSPF network to accommodate > > > significant growth, especially in the Area 0 backbone. There has been > > > some concern about the size of the OSPF topology that would result and > > > whether the routing protocol would remain robust, able to handle the odd > > > flapping link or memory leak. The network in question is using high-end > > > routers with high speed links (at least DS-3). > > > > > > Are there any heuristics that someone has which may give us an idea of > > > the comfort zone in terms of the database size, number of neighbors, > > > routers, etc? > > > > > > Or, could someone share information on the size of large OSPF > > > implementations that they are aware of? > > > > > > I know that this issue is rather vague (clouded in too many unknowns) > > > and may only result in rather ambiguous > > > answers, but, one never knows. > > > > > > Thanks, > > > > > > Ravi > > > > > > The information in this e-mail, and any attachment therein, is > > > confidential and for use by the addressee only. If you are not the > > > intended recipient, please return the e-mail to the sender and delete it > > > from your computer. Although The Bank of New York attempts to sweep > > > e-mail and attachments for viruses, it does not guarantee that either > > > are virus-free and accepts no liability for any damage sustained as a > > > result of viruses. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 10 18:59:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21430 for ; Mon, 10 Mar 2003 18:59:39 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00924FE8@cherry.ease.lsoft.com>; Mon, 10 Mar 2003 19:01:46 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 676682 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Mar 2003 19:01:45 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Mar 2003 19:01:45 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2B01iS10159 for ; Mon, 10 Mar 2003 16:01:44 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id h2B01iX48567; Mon, 10 Mar 2003 16:01:44 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <39469E08BD83D411A3D900204840EC55763502@vie-msgusr-01.dc.fore.com> Message-ID: <200303110001.h2B01iX48567@cirrus.juniper.net> Date: Mon, 10 Mar 2003 16:01:44 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: ospf limits... To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC55763502@vie-msgusr-01.dc.fore.com> (Venkata.Naidu@MARCONI.COM) Precedence: list It is all implementation dependent. This pretty much sums up most of the discussions on this list. Maybe I should set up a cron job. ;-) From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 11 13:39:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01170 for ; Tue, 11 Mar 2003 13:39:02 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.009267BC@cherry.ease.lsoft.com>; Tue, 11 Mar 2003 13:41:07 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 678468 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Mar 2003 13:41:06 -0500 Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Mar 2003 13:41:06 -0500 Received: from user-2ivfjhs.dialup.mindspring.com ([165.247.206.60] helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18sogT-0001H8-00 for ospf@discuss.microsoft.com; Tue, 11 Mar 2003 10:41:05 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E6E23CC.33EB50F5@earthlink.net> Date: Tue, 11 Mar 2003 09:58:36 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: wait timer, ExStart, and adj formation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, I have an issue dealing with the interaction of the wait timer, adjacency formation, and the reception of the DBD packet to move into the ExStart of the nbr state machine. This is in a Ethernet environment. What is occuring is simply stated as the ending of the wait timer on one system, an election of DR/BDR and the sending of a DBD packet out. However, the 2nd system still hadn't ended its wait timer and thus no adj has formed. Due to this, the rec'd DBD is normally dropped. This is going on at a customer site after they have mucked with the OSPF code. I know of a simple fix to patch the problem, but was looking to get a consensus on the frequency of this timing issue being seen. Thanks, Mitchell Erblich Sr. Software Engineer From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 11 14:09:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04046 for ; Tue, 11 Mar 2003 14:09:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00926908@cherry.ease.lsoft.com>; Tue, 11 Mar 2003 14:11:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 678509 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Mar 2003 14:11:52 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Mar 2003 14:11:52 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2BJBqS71696 for ; Tue, 11 Mar 2003 11:11:52 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id h2BJBqJ51064; Tue, 11 Mar 2003 11:11:52 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <3E6E23CC.33EB50F5@earthlink.net> Message-ID: <200303111911.h2BJBqJ51064@cirrus.juniper.net> Date: Tue, 11 Mar 2003 11:11:52 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: wait timer, ExStart, and adj formation To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E6E23CC.33EB50F5@earthlink.net> (message from Erblichs on Tue, 11 Mar 2003 09:58:36 -0800) Precedence: list So what operational problem are you trying to solve? It will all come up with the next DBD packet anyhow. Bringing up multiple systems on a LAN more-or-less simultaneously will always be a little ugly, but why do you care? I have an issue dealing with the interaction of the wait timer, adjacency formation, and the reception of the DBD packet to move into the ExStart of the nbr state machine. This is in a Ethernet environment. What is occuring is simply stated as the ending of the wait timer on one system, an election of DR/BDR and the sending of a DBD packet out. However, the 2nd system still hadn't ended its wait timer and thus no adj has formed. Due to this, the rec'd DBD is normally dropped. This is going on at a customer site after they have mucked with the OSPF code. I know of a simple fix to patch the problem, but was looking to get a consensus on the frequency of this timing issue being seen. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 11 14:24:11 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05928 for ; Tue, 11 Mar 2003 14:24:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00926851@cherry.ease.lsoft.com>; Tue, 11 Mar 2003 14:26:19 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 678544 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Mar 2003 14:26:18 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Mar 2003 14:26:17 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 625F25214CC for ; Tue, 11 Mar 2003 11:26:17 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3E6E23CC.33EB50F5@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E6E3907.1070803@redback.com> Date: Tue, 11 Mar 2003 14:29:11 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: wait timer, ExStart, and adj formation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mitchell, This is normal operation. The router coming out of interface wait state first will continue to resend the initial database packet every retransmit interval seconds. The router in wait state will exit wait state when he receives a hello from the other guy (assuming these are the only guys on the ethernet and the first has elected himself DR). Erblichs wrote: > Group, > > I have an issue dealing with the interaction of the wait timer, > adjacency formation, and the reception of the DBD packet to > move into the ExStart of the nbr state machine. This is > in a Ethernet environment. > > What is occuring is simply stated as the ending of the > wait timer on one system, an election of DR/BDR and > the sending of a DBD packet out. > > However, the 2nd system still hadn't ended its wait > timer and thus no adj has formed. Due to this, the > rec'd DBD is normally dropped. > > This is going on at a customer site after they have > mucked with the OSPF code. I know of a simple fix > to patch the problem, but was looking to get a consensus > on the frequency of this timing issue being seen. > > Thanks, > Mitchell Erblich > Sr. Software Engineer > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 11 14:34:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06722 for ; Tue, 11 Mar 2003 14:34:44 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.009269A6@cherry.ease.lsoft.com>; Tue, 11 Mar 2003 14:36:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 678572 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Mar 2003 14:36:52 -0500 Received: from 67.17.166.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Mar 2003 14:36:52 -0500 Received: from Farshad (unverified [12.232.15.100]) by ucmmail.com (Rockliffe SMTPRA 5.2.5) with ESMTP id for ; Tue, 11 Mar 2003 14:36:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Wed, 11 Mar 1998 11:38:47 -0800 Reply-To: Mailing List Sender: Mailing List From: "Farshad (Sean) Tavallaei" Subject: Re: wait timer, ExStart, and adj formation To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E6E23CC.33EB50F5@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Mitchell, The period of the wait timer is the same as the RouterDeadInterval. One thing they might have done is that they forgot to set that correctly in their code (maybe they set it to a default constant value), and if they configured the Dead timer to be different then they do not match any more... If the system is not going to ExStart, it is possible that both systems are claiming to be master and the master/slave negotiation never completes (e,g, they both have the same Route ID, etc.) Hope I could help, Farshad -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Erblichs Sent: Tuesday, March 11, 2003 9:59 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: wait timer, ExStart, and adj formation Group, I have an issue dealing with the interaction of the wait timer, adjacency formation, and the reception of the DBD packet to move into the ExStart of the nbr state machine. This is in a Ethernet environment. What is occuring is simply stated as the ending of the wait timer on one system, an election of DR/BDR and the sending of a DBD packet out. However, the 2nd system still hadn't ended its wait timer and thus no adj has formed. Due to this, the rec'd DBD is normally dropped. This is going on at a customer site after they have mucked with the OSPF code. I know of a simple fix to patch the problem, but was looking to get a consensus on the frequency of this timing issue being seen. Thanks, Mitchell Erblich Sr. Software Engineer From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 11 15:55:14 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11818 for ; Tue, 11 Mar 2003 15:55:14 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00926D46@cherry.ease.lsoft.com>; Tue, 11 Mar 2003 15:57:20 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 678846 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Mar 2003 15:57:19 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Mar 2003 15:57:19 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 0889D517E88 for ; Tue, 11 Mar 2003 12:57:19 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E6E4E5C.3050406@redback.com> Date: Tue, 11 Mar 2003 16:00:12 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF WG Agenda To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Below is the tentative agenda for our meeting in SF. Please send Rohit or myself an E-mail if you have an have any additions. Open Shortest Path First WG (OSPF) Monday, March 17 (13:00 - 15:00) ================================= CHAIRS: Rohit Dube Acee Lindem AGENDA: Agenda Bashing 5 Mins WG document status 10 Mins Chairs MIB Update 10 Mins Dan Joyal OSPF as the PE/CE Protocol in BGP/MPLS VPNs 10 Mins Eric Rosen Support of address families in OSPFv3 15 Mins One of the authors WG Charter Update 15 Mins Chairs -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 11 17:09:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14670 for ; Tue, 11 Mar 2003 17:09:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.009271D8@cherry.ease.lsoft.com>; Tue, 11 Mar 2003 17:11:48 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 678942 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Mar 2003 17:11:47 -0500 Received: from 207.159.120.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Mar 2003 17:11:47 -0500 Received: by xmxpita.excite.com (Postfix, from userid 110) id 7ED9D1346B; Tue, 11 Mar 2003 17:11:45 -0500 (EST) Received: from [64.47.48.10] by xprdmailfe5.nwk.excite.com via HTTP; Tue, 11 Mar 2003 17:11:45 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20030311221145.7ED9D1346B@xmxpita.excite.com> Date: Tue, 11 Mar 2003 17:11:45 -0500 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: wait timer, ExStart, and adj formation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit All, I've seen implementations that track all of the neighbor errors, and this one packet shows up as a Bad Neighbor State since the DBD packet came in when the adjacency was in a state below ExStart. This is probably what was noticed and the reason Mitchell is looking into this. But since there is no adverse effect, this should be explainable by pointing this out in the RFC (hey, it operates as intended!). My 2 cents, Don --- On Tue 03/11, Acee Lindem < acee@REDBACK.COM > wrote: From: Acee Lindem [mailto: acee@REDBACK.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Tue, 11 Mar 2003 14:29:11 -0500 Subject: Re: wait timer, ExStart, and adj formation Mitchell, This is normal operation. The router coming out of interface wait state first will continue to resend the initial database packet every retransmit interval seconds. The router in wait state will exit wait state when he receives a hello from the other guy (assuming these are the only guys on the ethernet and the first has elected himself DR). Erblichs wrote: > Group, > > I have an issue dealing with the interaction of the wait timer, > adjacency formation, and the reception of the DBD packet to > move into the ExStart of the nbr state machine. This is > in a Ethernet environment. > > What is occuring is simply stated as the ending of the > wait timer on one system, an election of DR/BDR and > the sending of a DBD packet out. > > However, the 2nd system still hadn't ended its wait > timer and thus no adj has formed. Due to this, the > rec'd DBD is normally dropped. > > This is going on at a customer site after they have > mucked with the OSPF code. I know of a simple fix > to patch the problem, but was looking to get a consensus > on the frequency of this timing issue being seen. > > Thanks, > Mitchell Erblich > Sr. Software Engineer > -- Acee _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 11 20:00:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21442 for ; Tue, 11 Mar 2003 20:00:29 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00927987@cherry.ease.lsoft.com>; Tue, 11 Mar 2003 20:02:37 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 679411 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Mar 2003 20:02:37 -0500 Received: from 207.217.120.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Mar 2003 20:02:37 -0500 Received: from user-38ldsor.dialup.mindspring.com ([209.86.243.27] helo=earthlink.net) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18sudf-0001y8-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Mar 2003 17:02:35 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <3E6E23CC.33EB50F5@earthlink.net> <3E6E3907.1070803@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E6E86D1.BB0D76CE@earthlink.net> Date: Tue, 11 Mar 2003 17:01:05 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: wait timer, ExStart, and adj formation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Thanks, I guess I don't remember seeing a msg that that a DBD pkt is dropped due to nbr state being less than ExStart. Mitchell Erblich ----------------------- Acee Lindem wrote: > > Mitchell, > > This is normal operation. The router coming out of interface wait > state first will continue to resend the initial database packet every > retransmit interval seconds. The router in wait state will exit > wait state when he receives a hello from the other guy (assuming these are > the only guys on the ethernet and the first has elected himself DR). > > Erblichs wrote: > > Group, > > > > I have an issue dealing with the interaction of the wait timer, > > adjacency formation, and the reception of the DBD packet to > > move into the ExStart of the nbr state machine. This is > > in a Ethernet environment. > > > > What is occuring is simply stated as the ending of the > > wait timer on one system, an election of DR/BDR and > > the sending of a DBD packet out. > > > > However, the 2nd system still hadn't ended its wait > > timer and thus no adj has formed. Due to this, the > > rec'd DBD is normally dropped. > > > > This is going on at a customer site after they have > > mucked with the OSPF code. I know of a simple fix > > to patch the problem, but was looking to get a consensus > > on the frequency of this timing issue being seen. > > > > Thanks, > > Mitchell Erblich > > Sr. Software Engineer > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 11 20:27:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22044 for ; Tue, 11 Mar 2003 20:27:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00927A3C@cherry.ease.lsoft.com>; Tue, 11 Mar 2003 20:30:02 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 679452 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Mar 2003 20:30:01 -0500 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Mar 2003 20:30:01 -0500 Received: from user-38ldsor.dialup.mindspring.com ([209.86.243.27] helo=earthlink.net) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18sv4B-00021c-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Mar 2003 17:29:59 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <3E6E23CC.33EB50F5@earthlink.net> <200303111911.h2BJBqJ51064@cirrus.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E6E8D3B.18A5A7A1@earthlink.net> Date: Tue, 11 Mar 2003 17:28:27 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: wait timer, ExStart, and adj formation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Dave, I care in this case because the customer cares and sees an error msg. In addition, where the proto-adj may have been in ExStart state maybe 1ms later, the adj won't be in ExStart until the DBD pkt is re-xmit'ed. Mitchell Erblich ================= Dave Katz wrote: > > So what operational problem are you trying to solve? It will all come > up with the next DBD packet anyhow. Bringing up multiple systems on > a LAN more-or-less simultaneously will always be a little ugly, but > why do you care? > > I have an issue dealing with the interaction of the wait timer, > adjacency formation, and the reception of the DBD packet to > move into the ExStart of the nbr state machine. This is > in a Ethernet environment. > > What is occuring is simply stated as the ending of the > wait timer on one system, an election of DR/BDR and > the sending of a DBD packet out. > > However, the 2nd system still hadn't ended its wait > timer and thus no adj has formed. Due to this, the > rec'd DBD is normally dropped. > > This is going on at a customer site after they have > mucked with the OSPF code. I know of a simple fix > to patch the problem, but was looking to get a consensus > on the frequency of this timing issue being seen. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 01:16:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27803 for ; Wed, 12 Mar 2003 01:16:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.009284F0@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 1:19:02 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 679978 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 01:19:01 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 01:19:01 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2C6J1S35505 for ; Tue, 11 Mar 2003 22:19:01 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id h2C6J1052578; Tue, 11 Mar 2003 22:19:01 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <3E6E23CC.33EB50F5@earthlink.net> <200303111911.h2BJBqJ51064@cirrus.juniper.net> <3E6E8D3B.18A5A7A1@earthlink.net> Message-ID: <200303120619.h2C6J1052578@cirrus.juniper.net> Date: Tue, 11 Mar 2003 22:19:01 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: wait timer, ExStart, and adj formation To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E6E8D3B.18A5A7A1@earthlink.net> (message from Erblichs on Tue, 11 Mar 2003 17:28:27 -0800) Precedence: list I care in this case because the customer cares and sees an error msg. Something I learned a long time ago about building products is to not issue error messages when there's no error, as it always frightens the customers. In addition, where the proto-adj may have been in ExStart state maybe 1ms later, the adj won't be in ExStart until the DBD pkt is re-xmit'ed. Like I asked, what is the operational problem? One packet time later it comes up. --Dave From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 05:49:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28846 for ; Wed, 12 Mar 2003 05:49:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00928DD7@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 5:52:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 680523 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 05:52:04 -0500 Received: from 193.70.192.127 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 05:42:03 -0500 Received: from libero.it (193.70.192.43) by smtp3.libero.it (6.7.015) id 3E68E8E300050BFA for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 11:42:02 +0100 MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 81.73.170.22 Message-ID: Date: Wed, 12 Mar 2003 11:42:02 +0100 Reply-To: Mailing List Sender: Mailing List From: "=?iso-8859-1?Q?john151@libero.it?=" Subject: =?iso-8859-1?Q?Between_OSPF_RSVP...?= To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA28846 Hi all, I' m interesting in protection/restoration (P/R) mechanisms and after having read some works, i' d like to do some observations. In a TE path protection scenario, there are works dealing with the use of RSVP-TE messages to signal, in example, a link failure. But could it have sense this other way of recovery? ...After a detection of a failure, OSPF ( OSPF-TE ) uses the flooding mechanism to advertise the all network that one link is broken ( ... using opaque LSA? ); then all nodes, receiving the LSA with this information, could compute an analysis of what LSPs ( LSP having source in that node ) are interested by the failure. Then, in example, each node that wants to do restoration in a MPLS scenario could make a Label Switching if there is a Backup Path available. This approach has some problem: - a faster trigger on OSPF in detecting failure, since HELLO mechanism is slow; - the prioriting of the sequence ---flooding LSA--- and then ---computing SPF algorithm--- to do faster; - the adding of intelligence in each node to do the Switching. I know that these are only some observations containing ( i hope few ) errors and that aren't complete, but since i haven' t found any P/R mechanisms in a TE scenario using OSPF ( or any optimized version of this ), i' d like to make you a question: is this a possible way of study ( as an alternative to RSVP signalling ) or is completely wrong and out of all standards? Thanks in advance for your kind answers and observations. Giovanni Di Giacomo From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 13:08:14 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14168 for ; Wed, 12 Mar 2003 13:08:14 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00929994@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 13:10:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682335 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 13:10:17 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 13:10:17 -0500 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2CIAGS66994; Wed, 12 Mar 2003 10:10:16 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h2CIAGl95887; Wed, 12 Mar 2003 10:10:16 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs References: <60F922ABE8BE9C428E806F43C0EC73680B33C3@HARITHA> <3E5DDBD1.6EFF3278@earthlink.net> <20030303171817.B52437@kummer.juniper.net> <72297164149.20030303234422@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20030312100908.U95881@kummer.juniper.net> Date: Wed, 12 Mar 2003 10:10:16 -0800 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: To: Alex Zinin To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <72297164149.20030303234422@psg.com> Precedence: list Hi Alex, On Mon, 3 Mar 2003, Alex Zinin wrote: > Could you possibly put it on the web somewhere? > It would be interesting to look at it. > Thanks. We only just finished polishing it up :-) We'll submit it as soon as the IETF is over, but I will suggest to the main authors to post it somewhere ... Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 13:26:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14774 for ; Wed, 12 Mar 2003 13:26:36 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00929920@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 13:28:45 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682413 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 13:28:45 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 13:28:44 -0500 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2CISiS68458 for ; Wed, 12 Mar 2003 10:28:44 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h2CISiJ95985 for ; Wed, 12 Mar 2003 10:28:44 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs References: <200303042329.SAA19167@bigbird.xebeo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20030312101401.B95881@kummer.juniper.net> Date: Wed, 12 Mar 2003 10:28:44 -0800 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200303042329.SAA19167@bigbird.xebeo.com> Precedence: list Hi Rohit, On Tue, 4 Mar 2003, Rohit Dube wrote: > This issue has been around for a while and it is time that > we picked one of the proposals as the WG document. Before we do that, let me try to summarize what the _real_ issue is. The read that I got at the last IETF is that OSPFv2 and OSPFv3 are *different* protocols; that one is focussed on IPv4 and the other on IPv6. So, the real question is, do we want to go down this path: create a major split, and declare v2 and v3 are different protocols. IMO, they are very closely related, and building on that closeness rather than emphasizing the differences is a better path. So, for example, carrying IPv4 prefixes in OSPFv3 the same way that they are carried in OSPFv2, carrying OSPFv2 opaque LSAs in v3 as is, etc. seems a cleaner path. On the other hand, defining new formats for TE in v3 emphasizes the difference. I can't speak for all the authors of OSPFv3, but there was a mail by Dennis Ferguson that seemed to indicate that he would like to see v3 include v2, not as different protocols. I could be wrong -- but it would be nice to at least get the opinions of the authors before we declare a major fork in the road. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 13:39:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15641 for ; Wed, 12 Mar 2003 13:39:14 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00929A18@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 13:41:21 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682435 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 13:41:21 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 13:41:20 -0500 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2CIfKS69524 for ; Wed, 12 Mar 2003 10:41:20 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h2CIfKY96038 for ; Wed, 12 Mar 2003 10:41:20 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs References: <60F922ABE8BE9C428E806F43C0EC73680B33C3@HARITHA> <3E5DDBD1.6EFF3278@earthlink.net> <20030303171817.B52437@kummer.juniper.net> <3E6BC825.8079C949@earthlink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20030312104001.V95881@kummer.juniper.net> Date: Wed, 12 Mar 2003 10:41:20 -0800 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E6BC825.8079C949@earthlink.net> Precedence: list Hi, On Sun, 9 Mar 2003, Erblichs wrote: > Of all the items that I mentioned, I think one of the main > items deals with a sub-second (microsec to millisec) > interval values. You're scaring me with "microsec"! > A negotation like interval determination would probably > be number one for me. The new draft is moving in this direction. Each sender says how fast it can send and receive; other senders adjust to this. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 14:09:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16493 for ; Wed, 12 Mar 2003 14:09:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00929987@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 14:11:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682520 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 14:11:42 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 14:11:41 -0500 Received: (qmail 17196 invoked from network); 12 Mar 2003 19:11:41 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 12 Mar 2003 19:11:41 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id OAA14095 for ; Wed, 12 Mar 2003 14:11:41 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200303121911.OAA14095@bigbird.xebeo.com> Date: Wed, 12 Mar 2003 14:11:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from Kireeti Kompella of "Wed, 12 Mar 2003 10:28:44 PST." <20030312101401.B95881@kummer.juniper.net> Precedence: list Hi Kireeti, Some comments inline [..] On Wed, 12 Mar 2003 10:28:44 -0800 Kireeti Kompella writes: =>Hi Rohit, => =>On Tue, 4 Mar 2003, Rohit Dube wrote: => =>> This issue has been around for a while and it is time that =>> we picked one of the proposals as the WG document. => =>Before we do that, let me try to summarize what the _real_ issue is. =>The read that I got at the last IETF is that OSPFv2 and OSPFv3 are =>*different* protocols; that one is focussed on IPv4 and the other =>on IPv6. Yes - one of the main arguments put out in previous discussions is in fact that OSPFv2 and OSPFv3 are different protocols. I just wanted to point out that "OSPFv2 is for ipv4 and OSPFv3 is for ipv6" is not the only significant point of difference. The too protocols differ in other areas as well : for example generalization of flooding scope which we have discussed previously on the list. Certainly the way RFC2740 is written, it deals primarily with ipv6. And as such OSPFv3 is not adequately specified for ipv4. =>So, the real question is, do we want to go down this path: create a =>major split, and declare v2 and v3 are different protocols. IMO, =>they are very closely related, and building on that closeness rather =>than emphasizing the differences is a better path. IMO this would also mean that 2740 would have to be revisited to clarify/specify support for ipv4. => =>So, for example, carrying IPv4 prefixes in OSPFv3 the same way =>that they are carried in OSPFv2, carrying OSPFv2 opaque LSAs in v3 =>as is, etc. seems a cleaner path. On the other hand, defining new =>formats for TE in v3 emphasizes the difference. => =>I can't speak for all the authors of OSPFv3, but there was a mail by =>Dennis Ferguson that seemed to indicate that he would like to see v3 =>include v2, not as different protocols. I could be wrong -- but it =>would be nice to at least get the opinions of the authors before we =>declare a major fork in the road. Yes I remember this. People can revisit this discussion at the OSPF archives circa october 2002. During this discussion it was also mentioned that one of the OSPFv3 authors preferred to run OSPFv3 separately from OSPFv2 wherever both ipv4 and ipv6 were needed. Certainly opinions from the co-authors as well as others actively developing OSPFv3 are very welcome. => =>Kireeti. ___ Best, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 14:19:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16882 for ; Wed, 12 Mar 2003 14:19:43 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00929917@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 14:21:49 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682554 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 14:21:48 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 14:21:48 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA03399 for ; Wed, 12 Mar 2003 14:21:45 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15294 for ; Wed, 12 Mar 2003 14:21:47 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 14:21:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763512@vie-msgusr-01.dc.fore.com> Date: Wed, 12 Mar 2003 14:21:45 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -> IMO this would also mean that 2740 would have to be revisited to -> clarify/specify support for ipv4. IMO, this must be done first (before) we decide to port the existing features. The amount of changes when we revisit 2740 support for ipv4 will dictate the next steps. Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 14:49:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18187 for ; Wed, 12 Mar 2003 14:49:25 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00929BE1@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 14:51:34 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682658 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 14:51:34 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 14:51:34 -0500 Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2CJpXS75431 for ; Wed, 12 Mar 2003 11:51:33 -0800 (PST) (envelope-from qv@juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h2CJpXx38860; Wed, 12 Mar 2003 11:51:33 -0800 (PST) (envelope-from qv) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200303042329.SAA19167@bigbird.xebeo.com> <20030312101401.B95881@kummer.juniper.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200303121951.h2CJpXx38860@fuinar.juniper.net> Date: Wed, 12 Mar 2003 11:51:33 -0800 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030312101401.B95881@kummer.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Also as an implementor, I think it woold be a major pain redoing the way IPv4 prefixes are carried in OSPFv3 if the design is far removed from the existing OSPFv2. It has taken several years to refine the existing OSPFv2 implementation and iron out all the problems. Redoing the design will have significant impact on the code stability. In one implementation, OSPFv3 and OSPFv2 share more than 80 percent of the code. The less than 20 % comes from the differences between the 2 protocols, which are mainly : 1) Differences in the LSA formats. 2) OSPFv3 runs on a link in a subnet independent manner while OSPFv2 is subnet dependent. Which also impacts the nexthop computation. Doing a redesign of how IPv4 prefixes are carried in OSPFv3 will require adding some significant amount of code for translating LSAs from OSPFv2 format to OSPFv3 format. The only benefit I see of doing away with OSPFv2 and carrying IPv4 prefixes in OSPFv3 is reduction in the amount of config a network administrator will have to do, if he wants to run OSPF for both IPv4 and IPv6. Other than that I am unaware of any benefits. I would argue that there are other mechanisms to achieve that without impacting the protocol itself. I would also argue that there isn't much difference whether you run a single protocol to carry both families, or two different protocols. There difference in the protocol traffic and the impact on the control plane resources (e.g. CPU, memory) will be insignificant. Quaizar > Hi Rohit, > > On Tue, 4 Mar 2003, Rohit Dube wrote: > > > This issue has been around for a while and it is time that > > we picked one of the proposals as the WG document. > > Before we do that, let me try to summarize what the _real_ issue is. > The read that I got at the last IETF is that OSPFv2 and OSPFv3 are > *different* protocols; that one is focussed on IPv4 and the other > on IPv6. > > So, the real question is, do we want to go down this path: create a > major split, and declare v2 and v3 are different protocols. IMO, > they are very closely related, and building on that closeness rather > than emphasizing the differences is a better path. > > So, for example, carrying IPv4 prefixes in OSPFv3 the same way > that they are carried in OSPFv2, carrying OSPFv2 opaque LSAs in v3 > as is, etc. seems a cleaner path. On the other hand, defining new > formats for TE in v3 emphasizes the difference. > > I can't speak for all the authors of OSPFv3, but there was a mail by > Dennis Ferguson that seemed to indicate that he would like to see v3 > include v2, not as different protocols. I could be wrong -- but it > would be nice to at least get the opinions of the authors before we > declare a major fork in the road. > > Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 15:05:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18962 for ; Wed, 12 Mar 2003 15:05:01 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00929BF5@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 15:07:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682718 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 15:07:10 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 15:07:09 -0500 Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2CK79S76909 for ; Wed, 12 Mar 2003 12:07:09 -0800 (PST) (envelope-from qv@juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h2CK79L38929; Wed, 12 Mar 2003 12:07:09 -0800 (PST) (envelope-from qv) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20030312101401.B95881@kummer.juniper.net> <200303121911.OAA14095@bigbird.xebeo.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200303122007.h2CK79L38929@fuinar.juniper.net> Date: Wed, 12 Mar 2003 12:07:09 -0800 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200303121911.OAA14095@bigbird.xebeo.com> Precedence: list Content-Transfer-Encoding: 7bit Rohit, > > Yes - one of the main arguments put out in previous discussions is > in fact that OSPFv2 and OSPFv3 are different protocols. I just wanted > to point out that "OSPFv2 is for ipv4 and OSPFv3 is for ipv6" is not > the only significant point of difference. The too protocols differ > in other areas as well : for example generalization of flooding scope > which we have discussed previously on the list. The generalization cleaned up what was a hole in rfc2328. As an implementor it didn't require a major redesign or significant code change when adding OSPFv3 support. Compared to 250 odd pages of OSPFv2, this was a minor change. The way OSPFv3 spec is written, i.e. just describing what is different from OSPFv2 should be a hint. > > Yes I remember this. People can revisit this discussion at the OSPF > archives circa october 2002. During this discussion it was also mentioned > that one of the OSPFv3 authors preferred to run OSPFv3 separately from > OSPFv2 wherever both ipv4 and ipv6 were needed. That is my opinion too. Quaizar From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 15:08:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19350 for ; Wed, 12 Mar 2003 15:08:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00929B3B@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 15:10:33 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682737 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 15:10:33 -0500 Received: from 193.70.192.52 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 15:10:33 -0500 Received: from libero.it (193.70.192.57) by smtp2.libero.it (6.7.015) id 3E68E862000609C9 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 21:10:32 +0100 MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 81.73.170.22 Message-ID: Date: Wed, 12 Mar 2003 21:10:31 +0100 Reply-To: Mailing List Sender: Mailing List From: "=?iso-8859-1?Q?john151@libero.it?=" Subject: =?iso-8859-1?Q?OSPF_RSVP...?= To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA19350 Hi all, essentially my considerations are: if i have two pre-calculated disjoint backup paths and i use opaque LSA to flood the link failure information, it could be a reasonable faster way of proceeding instead of using RSVP if i have an intelligence in the source routers (routers have to be able to switch among the two LSPs if they receive that particular opaque LSA; note that for a restoration of many LSPs RSVP will work in series, but OSPF will work in parallel with its flooding mechanism). So the basic question is: is it a reasonable way the use of OSPF and opaque LSA? Is there a reason to the use always RSVP for path protection, since, i think, increasing the LSPs corrupted by one link failure (if there are many active LSPs on the link that goes down) the OSPF mechanism of flooding is more efficient than using many RSVP messages from node that detects the failure towards the LSPs senders? Thanks in advance for your kind answers and observations. Giovanni Di Giacomo From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 15:45:40 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21513 for ; Wed, 12 Mar 2003 15:45:40 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00929DD3@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 15:47:48 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682840 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 15:47:48 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 15:47:48 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06489 for ; Wed, 12 Mar 2003 15:47:46 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29239 for ; Wed, 12 Mar 2003 15:47:47 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 15:47:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763516@vie-msgusr-01.dc.fore.com> Date: Wed, 12 Mar 2003 15:47:46 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list [1] -> run OSPFv3 separately from -> OSPFv2 wherever both ipv4 and ipv6 were needed. [2] -> In one implementation, OSPFv3 and OSPFv2 share more than -> 80 percent of the code. The less than 20 % comes from the -> differences between the 2 protocols, Don't you think above [1] & [2] statements are contradictory. If 80% of the code is same, then why should any customer prefer to run different instances when the code is almost same. In other words, if integrated-ISIS can handle both ISO and IPv4 address, will you prefer to run two ISIS instances (one for ISO and one IPv4) when a single ISIS instance can handle both addresses independently. I would like to know the "technical" & "operational" advantages of running two different instances of the (almost) same protocol(s). Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 16:33:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24092 for ; Wed, 12 Mar 2003 16:33:19 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00929E99@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 16:35:26 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682952 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 16:35:26 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 16:35:26 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2CLZPS83914 for ; Wed, 12 Mar 2003 13:35:25 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id h2CLZP154780; Wed, 12 Mar 2003 13:35:25 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <39469E08BD83D411A3D900204840EC55763516@vie-msgusr-01.dc.fore.com> Message-ID: <200303122135.h2CLZP154780@cirrus.juniper.net> Date: Wed, 12 Mar 2003 13:35:25 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC55763516@vie-msgusr-01.dc.fore.com> (Venkata.Naidu@MARCONI.COM) Precedence: list Don't you think above [1] & [2] statements are contradictory. If 80% of the code is same, then why should any customer prefer to run different instances when the code is almost same. Code commonality is entirely orthogonal to the issue of whether you run integrated or SIN. As an extreme example, cisco's ISIS and NLSP share about 98% of the code, but they are most decidedly run independently. In other words, if integrated-ISIS can handle both ISO and IPv4 address, will you prefer to run two ISIS instances (one for ISO and one IPv4) when a single ISIS instance can handle both addresses independently. I would like to know the "technical" & "operational" advantages of running two different instances of the (almost) same protocol(s). Customer acceptance and compatibility is a biggie; until everybody has a *stable* OSPFv3, nobody in their right mind will bet their IPv4 network on it (and can't in any case if the code's not there.) SIN is usually going to be more flexible, as you can have totally independent configurations and topologies. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 16:35:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24266 for ; Wed, 12 Mar 2003 16:35:18 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00929F0B@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 16:37:25 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682977 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 16:37:24 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 16:37:24 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id E250C3670A4 for ; Wed, 12 Mar 2003 13:37:22 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030312101401.B95881@kummer.juniper.net> <200303121911.OAA14095@bigbird.xebeo.com> <200303122007.h2CK79L38929@fuinar.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E6FA932.4060606@redback.com> Date: Wed, 12 Mar 2003 16:40:02 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Glad to see we are getting some good discussion on this issue. Hi Quaizar - See inline below. Quaizar Vohra wrote: > Rohit, > > > > > Yes - one of the main arguments put out in previous discussions is > > in fact that OSPFv2 and OSPFv3 are different protocols. I just wanted > > to point out that "OSPFv2 is for ipv4 and OSPFv3 is for ipv6" is not > > the only significant point of difference. The too protocols differ > > in other areas as well : for example generalization of flooding scope > > which we have discussed previously on the list. > > The generalization cleaned up what was a hole in rfc2328. As an > implementor it didn't require a major redesign or significant > code change when adding OSPFv3 support. Compared to 250 odd > pages of OSPFv2, this was a minor change. The way OSPFv3 > spec is written, i.e. just describing what is different from > OSPFv2 should be a hint. In my opinion, it is an even smaller change to remove the extra level of hierarchy for applications using OSPFv2 opaque LSAs. Why have the extra type when we can simply assign a LSA type for TE LSAs, grace LSAs or foo LSAs? It seems much like a much more natural classification to me. It is much more likely that I'm going to want to process all the LSAs for a given application than all my opaque LSAs. I also feel that whether or not OSPFv3 will eventually be used for carrying IPv4 prefixes is a completely independent issue (othrogonal in IETF-speak ;^). > > > > > Yes I remember this. People can revisit this discussion at the OSPF > > archives circa october 2002. During this discussion it was also mentioned > > that one of the OSPFv3 authors preferred to run OSPFv3 separately from > > OSPFv2 wherever both ipv4 and ipv6 were needed. > > That is my opinion too. > > Quaizar > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 16:50:53 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24817 for ; Wed, 12 Mar 2003 16:50:53 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0092A09C@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 16:53:00 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683010 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 16:53:00 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 16:53:00 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA08871 for ; Wed, 12 Mar 2003 16:52:57 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA09600 for ; Wed, 12 Mar 2003 16:52:59 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 16:52:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763518@vie-msgusr-01.dc.fore.com> Date: Wed, 12 Mar 2003 16:52:58 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Dave, -> Code commonality is entirely orthogonal to the issue of whether you -> run integrated or SIN. I knew someone is going to say this ;-) -> SIN is usually going to be more flexible, as you can have totally -> independent configurations and topologies. Dave, then I prefer to run OSPFv3 for IPv6 and IPv4 in a SIN basis. What I am trying to make a point is totally from an evolution perspective (hope you understand): IPv6 evolution from IPv4 is going to restrict OSPFv3 deployment in IPv6 only environment. Success of IPv6 is orthogonal to OSPFv3 deployment for me (I don't know why we are trying to bind IPv6 success with OSPFv3). OSPFv2 is new version which is not compatible with OSPFv1 (unlike other protocols where IGMPv3 is compatible with IGMPv2/1). In the same way, OSPFv3 is another refined version of the OSPF protocol. Some one made a point that OSPFv2 is refined over years. Yes. But all those refinements are already in OSPFv3 (RFC2328 < RFC2470). More over, OSPFv3 has more refinements which can't be put into OSPFv2 because of backward compatibility issues (just like OSPFv2 is created when there is no way to make OSPFv1 work) -> Customer acceptance and compatibility is a biggie; until -> everybody has -> a *stable* OSPFv3, nobody in their right mind will bet their IPv4 -> network on it (and can't in any case if the code's not there.) IMHO, OSPFv3 is going to perform at least (in the worst case) as good as OSPFv2 in IPv4 environments. It is just a matter of proving things to SPs - getting their trust/hope. It is all chicken and egg problem (where to start the chain reaction). Other than that, I don't see any technical argument. Do you think that OSPFv3 is going to perform poorly on IPv4 networks?!? Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 17:06:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25234 for ; Wed, 12 Mar 2003 17:06:43 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0092A1B5@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 17:08:50 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683086 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 17:08:50 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 17:08:50 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA09256 for ; Wed, 12 Mar 2003 17:08:48 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA11691 for ; Wed, 12 Mar 2003 17:08:49 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 17:08:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763519@vie-msgusr-01.dc.fore.com> Date: Wed, 12 Mar 2003 17:08:48 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Acee, -> I also feel that whether or not OSPFv3 will eventually be used -> for carrying IPv4 prefixes is a completely independent issue -> (othrogonal in IETF-speak ;^). It is *not* completely independent issue. May be, *some what* independent issue. ;) When we port the hop-by-hop LSAs then you MAY come to know that "wow! is it this simple to support IPv4 in OSPFv3 by just adding another layer" then we MAY get convinced that we should follow the same procedure even for IPv4 applications. With out doing the actual (core IP routing) exercise, we are trying to speed up things on MPLS-TE applications. Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 17:11:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25374 for ; Wed, 12 Mar 2003 17:11:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0092A196@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 17:13:20 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683107 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 17:13:20 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 17:13:20 -0500 Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2CMDJS86759 for ; Wed, 12 Mar 2003 14:13:19 -0800 (PST) (envelope-from qv@juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h2CMDJ539316; Wed, 12 Mar 2003 14:13:19 -0800 (PST) (envelope-from qv) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <39469E08BD83D411A3D900204840EC55763516@vie-msgusr-01.dc.fore.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200303122213.h2CMDJ539316@fuinar.juniper.net> Date: Wed, 12 Mar 2003 14:13:19 -0800 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC55763516@vie-msgusr-01.dc.fore.com> Precedence: list Content-Transfer-Encoding: 7bit Admittedly the protocols aren't exactly the same. My last mail did highlight the main differences. One being the change in LSA formats. And that is obviously the reason for running 2 instances of a similar protocol. But that doesn't still mean that the protocols are different. I was trying to argue against complete redesign of how IPv4 prefixes are carried in OSPFv3. That is a much farther stretch than carrying OSPFv2 LSAs as it is in OSPFv3 with just new LSA types. The former will also require code to be written for translation of OSPFv2 LSAS to OSPFv3 LSAs. Isn't addtional code complexity enough of a technical reason. As things stand, i.e. seperate protocols for IPv4 and IPv6, work well enough currently. What's your techical reason for modiyfing OSPFv3 to carry IPv4 prefixes. I think my objections in the last mail were technical enough. I don't see any merits in modifying a protocol (a complete redesign, let alone just a simple change) just to be able to run one instance of the protocol. Your ISIS argument holds if that was the case with OSPF from the start. That is not the case. People already have deployed OSPFv2. They will have to run OSPFv2 for a long time no matter what. I fail to see the configuration complexity argument as there are other ways of solving that problem. I also fail to see the control traffic overhead or more burden on the control plane argument. Quaizar > [1] > -> run OSPFv3 separately from > -> OSPFv2 wherever both ipv4 and ipv6 were needed. > [2] > -> In one implementation, OSPFv3 and OSPFv2 share more than > -> 80 percent of the code. The less than 20 % comes from the > -> differences between the 2 protocols, > > Don't you think above [1] & [2] statements are contradictory. > If 80% of the code is same, then why should any > customer prefer to run different instances when the > code is almost same. > > In other words, if integrated-ISIS can handle both ISO > and IPv4 address, will you prefer to run two ISIS instances > (one for ISO and one IPv4) when a single ISIS instance can > handle both addresses independently. > > I would like to know the "technical" & "operational" > advantages of running two different instances of the > (almost) same protocol(s). > > Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 17:19:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25521 for ; Wed, 12 Mar 2003 17:19:36 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0092A0FE@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 17:21:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683126 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 17:21:42 -0500 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 17:21:42 -0500 Received: from user-2ivfi18.dialup.mindspring.com ([165.247.200.40] helo=earthlink.net) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18tEbU-0002JU-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 14:21:41 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <60F922ABE8BE9C428E806F43C0EC73680B33C3@HARITHA> <3E5DDBD1.6EFF3278@earthlink.net> <20030303171817.B52437@kummer.juniper.net> <3E6BC825.8079C949@earthlink.net> <20030312104001.V95881@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E6FB1CD.2A8CF9D5@earthlink.net> Date: Wed, 12 Mar 2003 14:16:45 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kiretti, The protocol liveness doc states in section 2.2.1 the dead interval "is specified in microsecs". "Each sender says how fast it can send and receive". ohmmmm.. My 2nd item was "Why not have a "interval and a multipler" fields. The interval and the multiplier values should both be negotiated. An invalid packet should be a combination that when the two values combined are greater than 1 sec. The interval would give you a time consistency of sending, seccessive packets, the sequence number would inform if one or more packets is droped or not sent, and the multiplier times the interval would generate your new event of "maybe dead". This is versus your doc that states if you don't hear from me in interval time frame then consider me dead. Your interval maybe 1 ms, but you may be sending packets per us, and I can't stop you. Thus, I think you need the three values. I haven't yet really discussed different xmit and rcv'd negotiations if this is what you meant as "send and recieve". Also 1-to-1 negotiations or a group consensus negotiation could be considered... Mitchell Erblich Sr Software Engineer ============================= Kireeti Kompella wrote: > > Hi, > > On Sun, 9 Mar 2003, Erblichs wrote: > > > Of all the items that I mentioned, I think one of the main > > items deals with a sub-second (microsec to millisec) > > interval values. > > You're scaring me with "microsec"! > > > A negotation like interval determination would probably > > be number one for me. > > The new draft is moving in this direction. Each sender says how > fast it can send and receive; other senders adjust to this. > > Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 17:23:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25716 for ; Wed, 12 Mar 2003 17:23:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0092A0C9@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 17:26:02 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683162 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 17:26:02 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 17:26:02 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2CMQ2S87919 for ; Wed, 12 Mar 2003 14:26:02 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id h2CMQ2f54945; Wed, 12 Mar 2003 14:26:02 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <39469E08BD83D411A3D900204840EC55763518@vie-msgusr-01.dc.fore.com> Message-ID: <200303122226.h2CMQ2f54945@cirrus.juniper.net> Date: Wed, 12 Mar 2003 14:26:02 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC55763518@vie-msgusr-01.dc.fore.com> (Venkata.Naidu@MARCONI.COM) Precedence: list -> SIN is usually going to be more flexible, as you can have totally -> independent configurations and topologies. Dave, then I prefer to run OSPFv3 for IPv6 and IPv4 in a SIN basis. What I am trying to make a point is totally from an evolution perspective (hope you understand): IPv6 evolution from IPv4 is going to restrict OSPFv3 deployment in IPv6 only environment. Success of IPv6 is orthogonal to OSPFv3 deployment for me (I don't know why we are trying to bind IPv6 success with OSPFv3). v6 success is bound to *some* IGP; most of our customers are asking for OSPFv3, even though v6 for ISIS is far less risky (as far as the volume of new code goes.) The ISPs that run ISIS for v4 will probably run it for v6 as well, but the rest of the world will clamor for OSPF. The fates are very much intertwined. OSPFv2 is new version which is not compatible with OSPFv1 (unlike other protocols where IGMPv3 is compatible with IGMPv2/1). In the same way, OSPFv3 is another refined version of the OSPF protocol. That's like saying a Mack truck is a "refined version" of a Model T. ;-) The v1/v2 issue is ancient history--the number of folks that had to make that transition was vanishingly small by modern standards, and the environment was *very* different in those days (nobody actually expected the network to stay up.) I'm not sure what your point is. Some one made a point that OSPFv2 is refined over years. Yes. But all those refinements are already in OSPFv3 (RFC2328 < RFC2470). More over, OSPFv3 has more refinements which can't be put into OSPFv2 because of backward compatibility issues (just like OSPFv2 is created when there is no way to make OSPFv1 work) I'm actually agnostic about whether someone should run an integrated v3 or separate v2/v3. The interesting issue is whether or not these "refinements" are important enough for people to want to switch protocols. (This is, of course, a minor version of the bigger question, whether people will want to switch to v6 at all, but I'll stay out of that gunfight.) -> Customer acceptance and compatibility is a biggie; until -> everybody has -> a *stable* OSPFv3, nobody in their right mind will bet their IPv4 -> network on it (and can't in any case if the code's not there.) IMHO, OSPFv3 is going to perform at least (in the worst case) as good as OSPFv2 in IPv4 environments. It is just a matter of proving things to SPs - getting their trust/hope. It is all chicken and egg problem (where to start the chain reaction). Other than that, I don't see any technical argument. Do you think that OSPFv3 is going to perform poorly on IPv4 networks?!? I'm sure OSPFv3 as a protocol is just fine and dandy and will perform wonderfully. However, the number of really good OSPFv2 implementations is vanishingly small, even after the better part of 15 years, and I can pretty much guarantee that OSPFv3 implementations are not going to be better than the existing OSPFv2 implementations from the same vendors. The customers generally don't change things unless there is a compelling economic need to do so. My guess is that, if v3 does end up supporting both v4 and v6, most customers will stick with v2 until they're really sure that the v3 implementations are solid, and may never switch unless there's something they really need that v2 doesn't do for v4. (Lots of v's. ;-) ) From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 17:28:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25834 for ; Wed, 12 Mar 2003 17:28:58 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0092A207@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 17:31:05 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683213 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 17:31:05 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 17:31:05 -0500 Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2CMV5S88364 for ; Wed, 12 Mar 2003 14:31:05 -0800 (PST) (envelope-from qv@juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h2CMV5G39361; Wed, 12 Mar 2003 14:31:05 -0800 (PST) (envelope-from qv) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <39469E08BD83D411A3D900204840EC55763518@vie-msgusr-01.dc.fore.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200303122231.h2CMV5G39361@fuinar.juniper.net> Date: Wed, 12 Mar 2003 14:31:05 -0800 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC55763518@vie-msgusr-01.dc.fore.com> Precedence: list Content-Transfer-Encoding: 7bit > > OSPFv2 is new version which is not compatible with OSPFv1 > (unlike other protocols where IGMPv3 is compatible > with IGMPv2/1). In the same way, OSPFv3 is another refined > version of the OSPF protocol. > > Some one made a point that OSPFv2 is refined over years. > Yes. But all those refinements are already in OSPFv3 > (RFC2328 < RFC2470). More over, OSPFv3 has more > refinements which can't be put into OSPFv2 because of > backward compatibility issues (just like OSPFv2 is created > when there is no way to make OSPFv1 work) I think you are twisting my argument. I said that the OSPFv2 implementation took several years refining. Note the word IMPLEMENTATION in there. Refining the ietf spec itself is no doubt itself an issue. > > -> Customer acceptance and compatibility is a biggie; until > -> everybody has > -> a *stable* OSPFv3, nobody in their right mind will bet their IPv4 > -> network on it (and can't in any case if the code's not there.) > > IMHO, OSPFv3 is going to perform at least (in the worst case) > as good as OSPFv2 in IPv4 environments. It is just a matter > of proving things to SPs - getting their trust/hope. It is > all chicken and egg problem (where to start the chain reaction). > Other than that, I don't see any technical argument. > Do you think that OSPFv3 is going to perform poorly on > IPv4 networks?!? I don't think its a question of whether OSPFv3 will perform better or not. It will, as other protocols have, take its time refining the spec followed by ironing out all the implementation issues. You can't claim something is better than the other until its implemented and deployed. Technical argument or should I say motive is needed when you try to solve a problem. I don't see a problem yet. Quaizar > > Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 17:32:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25941 for ; Wed, 12 Mar 2003 17:32:12 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0092A072@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 17:34:20 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683230 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 17:34:20 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 17:34:20 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA09706 for ; Wed, 12 Mar 2003 17:34:17 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA14324 for ; Wed, 12 Mar 2003 17:34:19 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 17:34:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC5576351B@vie-msgusr-01.dc.fore.com> Date: Wed, 12 Mar 2003 17:34:18 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Quaizer, -> As things stand, i.e. seperate protocols for IPv4 and -> IPv6, work well enough currently. What's your techical -> reason for modiyfing OSPFv3 to carry IPv4 prefixes. Some of the features in OSPFv2 can't be changed - just for example, representation of p2p links. There are lot of such refinements in OSPFv3 which can't go into OSPFv2 (even though they are applicable to IPv4) because of backward compatibility. -> think my objections in the last mail were technical enough. -> I don't see any merits in modifying a protocol (a complete -> redesign, let alone just a simple change) just to be able to -> run one instance of the protocol. I am assuming that the re-design will be simple, and you are assuming that the re-design is complicated. How much time did Ross Callon spent when he thought that ISIS can be used for IPv4 ? Is RFC1195 the complete re-design of ISIS protocol? If so, I agree with you. -> Your ISIS argument holds if that was the case with OSPF -> from the start. That is not the case. People already -> have deployed OSPFv2. They will have to run OSPFv2 -> for a long time no matter what. Yes. If the deployment is the basis then I have to agree only with that. But, all my argument is, why are we stuck with old protocol. Let us evolve and refine protocols. Give better versions to customers. Don't you think that is the good intension?!? Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 17:44:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26668 for ; Wed, 12 Mar 2003 17:44:47 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0092A256@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 17:46:54 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683298 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 17:46:54 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 17:46:54 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2CMkrS89499 for ; Wed, 12 Mar 2003 14:46:53 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id h2CMkr755023; Wed, 12 Mar 2003 14:46:53 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <39469E08BD83D411A3D900204840EC5576351B@vie-msgusr-01.dc.fore.com> Message-ID: <200303122246.h2CMkr755023@cirrus.juniper.net> Date: Wed, 12 Mar 2003 14:46:53 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC5576351B@vie-msgusr-01.dc.fore.com> (Venkata.Naidu@MARCONI.COM) Precedence: list Some of the features in OSPFv2 can't be changed - just for example, representation of p2p links. There are lot of such refinements in OSPFv3 which can't go into OSPFv2 (even though they are applicable to IPv4) because of backward compatibility. If such refinements are operationally important, the vendors will be pressured by the customers to take care of the problem, and people will vote with their feet and pocketbooks. -> think my objections in the last mail were technical enough. -> I don't see any merits in modifying a protocol (a complete -> redesign, let alone just a simple change) just to be able to -> run one instance of the protocol. I am assuming that the re-design will be simple, and you are assuming that the re-design is complicated. How much time did Ross Callon spent when he thought that ISIS can be used for IPv4 ? Is RFC1195 the complete re-design of ISIS protocol? If so, I agree with you. I hosted the meeting (on a very cold December day in Ann Arbor) when the IP extensions to ISIS were worked out. The situation there was different; the only IGP available for IPv4 at the time was RIP (OSPF was also under design at the time.) ISIS was trivially extensible. If you want to play this game, a better parallel would be to instead try to extend OSPFv2 to carry v6 info. The OSPF Founding Fathers were quite explicit in making OSPFv2 extremely IPv4 centric (I thought it was a mistake then, and I still do now.) -> Your ISIS argument holds if that was the case with OSPF -> from the start. That is not the case. People already -> have deployed OSPFv2. They will have to run OSPFv2 -> for a long time no matter what. Yes. If the deployment is the basis then I have to agree only with that. But, all my argument is, why are we stuck with old protocol. Let us evolve and refine protocols. Give better versions to customers. Don't you think that is the good intension?!? Deployment is a *huge* issue. If the customers feel "stuck" they will clamor for the new and improved version. However, nobody in their right mind will switch protocols unless there's a *really* compelling reason to do so. --Dave From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 12 18:17:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29287 for ; Wed, 12 Mar 2003 18:17:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0092A32F@cherry.ease.lsoft.com>; Wed, 12 Mar 2003 18:19:31 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683389 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Mar 2003 18:19:31 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Mar 2003 18:19:31 -0500 Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2CNJUS91992 for ; Wed, 12 Mar 2003 15:19:30 -0800 (PST) (envelope-from qv@juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h2CNJUN39479; Wed, 12 Mar 2003 15:19:30 -0800 (PST) (envelope-from qv) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <39469E08BD83D411A3D900204840EC5576351B@vie-msgusr-01.dc.fore.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200303122319.h2CNJUN39479@fuinar.juniper.net> Date: Wed, 12 Mar 2003 15:19:30 -0800 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC5576351B@vie-msgusr-01.dc.fore.com> Precedence: list Content-Transfer-Encoding: 7bit Venkata, > > Some of the features in OSPFv2 can't be changed - > just for example, representation of p2p links. > There are lot of such refinements in OSPFv3 which > can't go into OSPFv2 (even though they are applicable > to IPv4) because of backward compatibility. Well, I am not arguing for porting the v3 refinements to v2. Precisely for the reason you mentioned, but in reverse, if there are semantic differences between carrying IPv4 prefixes in OSPFv3 and carrying IPv4 prefixes in OSPFv2, you will have a translation nightmare when translating OSPFv2 LSAs into OSPFv3 LSAs and vice-versa. You will need such translation when transitioning from OSPFv2 to OSPFv3 because part of your network will still be OSPFv2. > > -> think my objections in the last mail were technical enough. > -> I don't see any merits in modifying a protocol (a complete > -> redesign, let alone just a simple change) just to be able to > -> run one instance of the protocol. > > I am assuming that the re-design will be simple, and > you are assuming that the re-design is complicated. > How much time did Ross Callon spent when he thought > that ISIS can be used for IPv4 ? Is RFC1195 the > complete re-design of ISIS protocol? If so, I agree > with you. Even if the redesign is simple. It means more code. For what ? > > -> Your ISIS argument holds if that was the case with OSPF > -> from the start. That is not the case. People already > -> have deployed OSPFv2. They will have to run OSPFv2 > -> for a long time no matter what. > > Yes. If the deployment is the basis then I have to agree > only with that. But, all my argument is, why are we > stuck with old protocol. Let us evolve and refine > protocols. Give better versions to customers. Don't you > think that is the good intension?!? Isn't deployment a big issue ? Isn't IPv6 vs IPv4 war over the same reason. Quaizar > > Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 13 10:43:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06018 for ; Thu, 13 Mar 2003 10:43:51 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0092B937@cherry.ease.lsoft.com>; Thu, 13 Mar 2003 10:45:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 685417 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 13 Mar 2003 10:45:59 -0500 Received: from 193.70.192.52 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 13 Mar 2003 10:45:59 -0500 Received: from libero.it (193.70.192.42) by smtp2.libero.it (6.7.015) id 3E68E86200073DDE for OSPF@DISCUSS.MICROSOFT.COM; Thu, 13 Mar 2003 16:45:58 +0100 MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 81.73.170.22 Message-ID: Date: Thu, 13 Mar 2003 16:45:58 +0100 Reply-To: Mailing List Sender: Mailing List From: "=?iso-8859-1?Q?john151@libero.it?=" Subject: =?iso-8859-1?Q?Observations_OSPF_RSVP..._?= To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA06018 Hi all, i see at least two advantages in using Opaque LSA insted of PathErr (quite the same for the Notifies ) in this scenario: precalculated and presignalled backup disjoint paths for protected LSPs in MPLS Network, availability of fast detection mechanism ( from lower levels ) of link failure. 1) Since Opaque LSAs don' t trigger an SPF calculation in the routers they cross, all the Network is soon informed about the link failure event and IN PARALLEL each router can do the label switching on the backup LSPs ( after having controlled the presence of protected LSPs starting from it and interested by the link failure ). 2) Since i refer to protected LPSs ( they are relatively few ), thinking in a scenario in which there should be a return to the first active LSP when the link failed returns to be UP ( that is a second switch from backup LSP to the first active LSP ), could it be not necessary to send the PathTears immediately to cleanup resources? This will bring two beneficts: no PathTears and ResvTear sent immediately in the Network and no signalling messages storm when the link returns up ( after a not long period ), when it's probable that all the backup LSPs will return on that link (the link that went down). Thanks in advance for your kind answers and observations. Giovanni di Giacomo From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 14 03:57:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19476 for ; Fri, 14 Mar 2003 03:57:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0092DA56@cherry.ease.lsoft.com>; Fri, 14 Mar 2003 3:59:49 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 688915 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 14 Mar 2003 03:59:48 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Mar 2003 03:59:48 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h2E9O8b28085 for ; Fri, 14 Mar 2003 14:54:08 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h2E9O4328071 for ; Fri, 14 Mar 2003 14:54:05 +0530 References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <02de01c2ea08$6f7a01e0$81c802c0@alok> Date: Fri, 14 Mar 2003 14:32:15 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: OSPF RSVP... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > Hi all, > essentially my considerations are: if i have two pre-calculated disjoint backup paths and i use opaque LSA to flood the link failure information, > it could be a reasonable faster way of proceeding instead of using RSVP if i have an intelligence in the source routers (routers have to be able to switch among the two LSPs if they receive that particular opaque LSA; note that for a restoration of many LSPs RSVP will work in series, but OSPF will work in parallel with its flooding mechanism). but doesnt that "serial thingy" reduce your traffic? with flooding,you are increasing the same....why do you need to telll everyone somethig that only few people need to know? ......and eitherways for all new LSPs being setup the IGP is anyway flooding and telling the adjacencies about the link status... > So the basic question is: is it a reasonable way the use of OSPF and opaque LSA? Is there a reason to the use always RSVP for path protection, since, i think, increasing the LSPs corrupted by one link failure (if there are many active LSPs on the link that goes down) the OSPF mechanism of flooding is more efficient than using many RSVP messages from node that detects the failure towards the LSPs senders? hmmm am not too sure but i think RSVP can signal multiple "path tears" to its adjacent nodes in the same message..so you would get the same result in a way?..correct? (i may be wrong about this part......) From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 14 09:44:32 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26610 for ; Fri, 14 Mar 2003 09:44:31 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0092E0A0@cherry.ease.lsoft.com>; Fri, 14 Mar 2003 9:46:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 689784 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 14 Mar 2003 09:46:40 -0500 Received: from 171.71.177.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Mar 2003 09:46:40 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2EEkahs017137; Fri, 14 Mar 2003 06:46:37 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id UAA16757; Fri, 14 Mar 2003 20:15:15 +0530 (IST) References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_3EC7_01C2EA66.9C040C70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <3eca01c2ea38$82cf0a30$9c8b4d0a@apac.cisco.com> Date: Fri, 14 Mar 2003 20:16:34 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPFv2 MIB draft Comments: cc: joyal@lucent.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_3EC7_01C2EA66.9C040C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have some comments on draft-ietf-ospf-mib-update-05.txt. I would also like to have some clarifications. Please see the attached document. Thanks, Roy > Yes. An update is in the works. > > -Dan > > > -----Original Message----- > > From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > > Sent: Monday, February 10, 2003 3:01 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: OSPFv2 MIB draft > > > > > > Hi all: > > I would like to know the status of the working group > > draft-ietf-ospf-mib-update-05.txt. The current draft shows an > > expiry date of > > May 2001. > > Is there any plan to update the draft ? > > > > Thanks > > Gargi > > > ------=_NextPart_000_3EC7_01C2EA66.9C040C70 Content-Type: text/plain; name="ospf_mib_comments.txt" Content-Disposition: attachment; filename="ospf_mib_comments.txt" Content-Transfer-Encoding: quoted-printable Support for multiple OSPF processes: ----------------------------------- We raised this issue some time back in WG. Currently MIB supports only = one Router ID.=20 Multiple processes can have separate router IDs. It is also true with = other MIB objects=20 like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we got = was to use a=20 separate MIB view for each process. But I don't think it can be easily = implemented.=20 We suggest to form a new table to group scalar objects related to an = OSPF process and have Process Id as its INDEX. We also suggest to add Process Id as one of the = INDICES of all=20 tables. MAX-ACCESS value for INDICES of TABLES: -------------------------------------- I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES of = a table are=20 put as not-accesssible to reduce the number of SNMP messages. When an = SNMP GET or GETNEXT is issued on a non-INDEX object, we can extract the values of = INDICES from the object ID returned. For example, let us consider ospfAreaLsaCount. = When we query the value for this, we get something like ospfAreaLsaCount.0.0.0.1, = where 0.0.0.1 is=20 the AreaId, which is the INDEX of the ospfAreaTable. We can extract the = INDICES of=20 table like this even if they are not-accessible. The tables like = LsdbTable has many=20 number of INDICES and we can reduce the number of SNMP messages = considerably by changing them to not-accessible. If the MAX-ACCESS of INDICES are put as read-only to include them in the = TRAP=20 notification messages, they can be changed as accessible-for-notify. = Other approach to=20 this is remove the INDICES from TRAP notification messages. For example = if you take the case of IfStateChange TRAP, ospfIfStateChange NOTIFICATION-TYPE^M OBJECTS { ospfRouterId, -- The originator of the trap^M ospfIfIpAddress,^M ospfAddressLessIf,^M ospfIfState -- The new state^M }^M Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. When = we send TRAP notification, we can just send ospfIfState.. . Also I am not sure why ospfRouterId is included here. An NMS station can = always query ospfRouterId separately. By removing these MIB objects, we can reduce the size and = processing time of TRAP=20 messages considerably. Section : 4.3 Ignoring Initial Activity --------------------------------------- The section states "The majority of critical events occur when OSPF is = enabled on a router, at which time the designated router is elected and neighbor = adjacencies are formed" .=20 I am not sure if enabling OSPF on a router means enabling it on an = interface. I think it will be better to make the text clearer. Other statement is "To avoid unnecessary traps, a router should not = originate expected OSPF=20 interface related traps until two of that interface's dead timer = intervals have elapsed."=20 I think there will be some problems if the dead interval value is too = long. We may end up=20 not sending any of the expected TRAPS for a long time. Btw, could I = please know the reason=20 for selecting 2 * dead interval value for this purpose?. There might be = some case where an=20 interface is up and it goes down before (2 * dead interval). We can't = take it as an 'expected=20 event'. Probably we can ignore the expected events till the interface = reaches terminal state (FULL or 2WAY) for the first time after enabling OSPF. One more point is we are already limiting ospfIfStateChange, = ospfVirtIfStateChange,=20 ospfNbrStateChange and ospfVirtNbrStateChange notifications by = generating them only for terminal=20 state changes and backward tansition. Do we really need to ignore them = during the initial activity?.=20 Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa = traps should not be originated=20 until two dead timer intervals have elapsed where the deadtimer interval = used should be the dead=20 timer with the smallest value." Here whats the meaning of "dead timer = with smallest value"? Is it=20 the smallest interval value among all the interfaces? Section 4.4 Throttling Traps ---------------------------- Do we need to provide MIB objects corresponding to window size and the = number of TRAPs sent during the window time? Will the TRAPs other than ospfTxRetransmit, OrginateLsa = and MaxAgeLsa really cause a TRAP flood? Probably we need to throttle only the above three TRAPS? I think the normal practice is to inform the NMS using some other = notification at the end of a=20 particular interval when the TRAPs are dropped like this, "Trap N = dropped n times in an interval=20 t". We can add some common extra paratmeters to these notifications to = facilitate the NMS to query the router to retrieve some values and find out whats happening. ospfConfigErrorType=20 ------------------- Do we need an error type for duplicate router id in the received = messages? Some times loop back=20 address can be misconfigured. =20 ospfSetTrap ----------- The definition of this is little complicated. Any reasons for going for = last bit to first. We think its better to redefine this MIB object like this to make if more clear. cospfSetTrap OBJECT-TYPE SYNTAX BITS { ifConfigError (0), virtIfConfigError (1), ospfNbrStateChange (2), . . . } MAX-ACCESS read-write STATUS current DESCRIPTION "A One-octet string serving as a bit map for the trap events defined by the OSPF traps in this MIB. This object is used to enable and disable specific OSPF traps where a 1 in the corresponding bit field represents enabled." ::=3D { cospfTrapControl 1 } This definition enables the NMS to interpret the bit map easily. ospfIfStateChange ----------------- From the definition it looks like this TRAP should be generated only for = terminal states(when state progresses) and for backward transition. Infact the name = ospfIfStateChange simply suggests to generate TRAPs for all state transitions. The general tendency is to = ignore the DESCRIPTION when "StateChange" is read and assume its for all the state changes. It might = lead to wrong=20 implementations. I think we can also follow the approach taken in BGP = MIB(rfc1657). There they have notifications like this, bgpEstablished NOTIFICATION-TYPE OBJECTS { bgpPeerLastError, bgpPeerState } STATUS current DESCRIPTION "The BGP Established event is generated when the BGP FSM enters the ESTABLISHED state." ::=3D { bgpTraps 1 } bgpBackwardTransition NOTIFICATION-TYPE OBJECTS { bgpPeerLastError, bgpPeerState } STATUS current DESCRIPTION "The BGPBackwardTransition Event is = generated when the BGP FSM moves from a higher = numbered state to a lower numbered state." ::=3D { bgpTraps 2 } Our suggestion is to maintain ospfIfStateChange and use that for = monitoring all the states (some people may want that) and additionally have notifications similar = to the BGP notifications. Its also true with VirtIfStateChange, NbrStateChange and = VirtNbrStateChange. If somebody doesn't want to see ALL state TRAPS, they can suppress them by turning off the = corresponding bit in=20 ospfSetTrap. ospfNbrStateChange=20 ------------------ The DECRIPTION clause states=20 "When an neighbor transitions from or to Full on non-broadcast = multi-access and broadcast networks, the trap should be generated by the designated router. A = designated router=20 transitioning to Down will be noted by ospfIfStateChange." I think here the intention is to reduce the number of TRAPs as much as = possible by making only DR sending out this TRAP for a subnet. But there is a possibility = that osfpNbrStateChange notification is disabled on DR and enabled on DR other or BDR. NMS won't = receive TRAPs when NbrState becomes FULL in that case. There is a problem with the second = part of above statments as well. Suppose ospfIfStateChange is disabled on the router, then again = NMS won't know when=20 neighbor goes down. Probably its better to remove these two clauses. Support for sham links: ----------------------- Are you going to provide support for sham links? We may need these = tables and notifications, ShamLinkTable ShamLinkNbrTable ShamLinkStateChange notification ShamLinkNbrStateChange notification ------=_NextPart_000_3EC7_01C2EA66.9C040C70-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 14 11:08:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00707 for ; Fri, 14 Mar 2003 11:08:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0092E205@cherry.ease.lsoft.com>; Fri, 14 Mar 2003 11:10:40 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 690051 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 14 Mar 2003 11:10:39 -0500 Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Mar 2003 11:10:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 14 Mar 2003 11:10:37 -0500 Reply-To: Mailing List Sender: Mailing List From: Jeff Parker Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > I have some comments on draft-ietf-ospf-mib-update-05.txt. I > would also like to have some clarifications. > > Roy [ From attached doc ] > Support for multiple OSPF processes: > We suggest to form a new table to group scalar > objects related to an OSPF process and have > Process Id as its INDEX. Why must the index be the process ID? Does that interact well with various hot-restart and hot-standby ideas? - jeff parker From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 14 11:12:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00827 for ; Fri, 14 Mar 2003 11:12:56 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0092E3D1@cherry.ease.lsoft.com>; Fri, 14 Mar 2003 11:15:05 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 690070 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 14 Mar 2003 11:15:04 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Mar 2003 11:15:03 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 3A60F97564 for ; Fri, 14 Mar 2003 08:15:02 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E72008E.5000602@redback.com> Date: Fri, 14 Mar 2003 11:17:18 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Jeff Parker wrote: >>I have some comments on draft-ietf-ospf-mib-update-05.txt. I >>would also like to have some clarifications. >> >>Roy > > > [ From attached doc ] > >>Support for multiple OSPF processes: > > >>We suggest to form a new table to group scalar >>objects related to an OSPF process and have >>Process Id as its INDEX. > > > Why must the index be the process ID? Does that > interact well with various hot-restart and > hot-standby ideas? Hi Jeff. Actually process ID is IOS terminology. It is really an instance ID to reflect that fact that many vendors support multiple routing protocols instances. > > - jeff parker > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 14 17:52:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17432 for ; Fri, 14 Mar 2003 17:52:31 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0092F1DB@cherry.ease.lsoft.com>; Fri, 14 Mar 2003 17:54:40 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 691611 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 14 Mar 2003 17:54:40 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Mar 2003 17:54:40 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 8E5BBB5FEC for ; Fri, 14 Mar 2003 14:54:38 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3eca01c2ea38$82cf0a30$9c8b4d0a@apac.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E725E33.5040909@redback.com> Date: Fri, 14 Mar 2003 17:56:51 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Roy, I can appreciate your points since our product supports both multiple virtual router instances and multiple routing protocol instances within a particular virtual router. However, I think we'd essentially have to deprecate everything in the current MIB and define new tables in order to add OSPF instance ID as an index. Can someone who has more MIB definition experience comment? Additionally, the multiple instance problem is not unique to the OSPF MIB. Maybe a generic solution could be developed. Roy Jose wrote: > Hi, > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I would also like > to have some clarifications. Please see the attached document. > > Thanks, > Roy > > >>Yes. An update is in the works. >> >>-Dan >> >> >>>-----Original Message----- >>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] >>>Sent: Monday, February 10, 2003 3:01 PM >>>To: OSPF@DISCUSS.MICROSOFT.COM >>>Subject: OSPFv2 MIB draft >>> >>> >>>Hi all: >>>I would like to know the status of the working group >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an >>>expiry date of >>>May 2001. >>>Is there any plan to update the draft ? >>> >>>Thanks >>>Gargi >>> >> >> >>------------------------------------------------------------------------ >> >>Support for multiple OSPF processes: >>----------------------------------- >> >>We raised this issue some time back in WG. Currently MIB supports only one Router ID. >>Multiple processes can have separate router IDs. It is also true with other MIB objects >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we got was to use a >>separate MIB view for each process. But I don't think it can be easily implemented. >>We suggest to form a new table to group scalar objects related to an OSPF process and have >>Process Id as its INDEX. We also suggest to add Process Id as one of the INDICES of all >>tables. >> >> >>MAX-ACCESS value for INDICES of TABLES: >>-------------------------------------- >>I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES of a table are >>put as not-accesssible to reduce the number of SNMP messages. When an SNMP GET or >>GETNEXT is issued on a non-INDEX object, we can extract the values of INDICES from >>the object ID returned. For example, let us consider ospfAreaLsaCount. When we query >>the value for this, we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1 is >>the AreaId, which is the INDEX of the ospfAreaTable. We can extract the INDICES of >>table like this even if they are not-accessible. The tables like LsdbTable has many >>number of INDICES and we can reduce the number of SNMP messages considerably by changing >>them to not-accessible. >> >>If the MAX-ACCESS of INDICES are put as read-only to include them in the TRAP >>notification messages, they can be changed as accessible-for-notify. Other approach to >>this is remove the INDICES from TRAP notification messages. For example if you take the >>case of IfStateChange TRAP, >> >> ospfIfStateChange NOTIFICATION-TYPE^M >> OBJECTS { ospfRouterId, -- The originator of the trap^M >> ospfIfIpAddress,^M >> ospfAddressLessIf,^M >> ospfIfState -- The new state^M >> }^M >>Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. When we send TRAP >>notification, we can just send ospfIfState.. . >>Also I am not sure why ospfRouterId is included here. An NMS station can always query ospfRouterId >>separately. By removing these MIB objects, we can reduce the size and processing time of TRAP >>messages considerably. >> >>Section : 4.3 Ignoring Initial Activity >>--------------------------------------- >>The section states "The majority of critical events occur when OSPF is enabled on a >>router, at which time the designated router is elected and neighbor adjacencies are formed" . >>I am not sure if enabling OSPF on a router means enabling it on an interface. I think it will >>be better to make the text clearer. >> >>Other statement is "To avoid unnecessary traps, a router should not originate expected OSPF >>interface related traps until two of that interface's dead timer intervals have elapsed." >>I think there will be some problems if the dead interval value is too long. We may end up >>not sending any of the expected TRAPS for a long time. Btw, could I please know the reason >>for selecting 2 * dead interval value for this purpose?. There might be some case where an >>interface is up and it goes down before (2 * dead interval). We can't take it as an 'expected >>event'. Probably we can ignore the expected events till the interface reaches terminal state >>(FULL or 2WAY) for the first time after enabling OSPF. >> >> >>One more point is we are already limiting ospfIfStateChange, ospfVirtIfStateChange, >>ospfNbrStateChange and ospfVirtNbrStateChange notifications by generating them only for terminal >>state changes and backward tansition. Do we really need to ignore them during the initial activity?. >> >>Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa traps should not be originated >>until two dead timer intervals have elapsed where the deadtimer interval used should be the dead >>timer with the smallest value." Here whats the meaning of "dead timer with smallest value"? Is it >>the smallest interval value among all the interfaces? >> >> >>Section 4.4 Throttling Traps >>---------------------------- >>Do we need to provide MIB objects corresponding to window size and the number of TRAPs sent during >>the window time? Will the TRAPs other than ospfTxRetransmit, OrginateLsa and MaxAgeLsa really cause >>a TRAP flood? Probably we need to throttle only the above three TRAPS? >> >>I think the normal practice is to inform the NMS using some other notification at the end of a >>particular interval when the TRAPs are dropped like this, "Trap N dropped n times in an interval >>t". We can add some common extra paratmeters to these notifications to facilitate the NMS to query >>the router to retrieve some values and find out whats happening. >> >>ospfConfigErrorType >>------------------- >>Do we need an error type for duplicate router id in the received messages? Some times loop back >>address can be misconfigured. >> >>ospfSetTrap >>----------- >>The definition of this is little complicated. Any reasons for going for last bit to first. We think >>its better to redefine this MIB object like this to make if more clear. >> >> cospfSetTrap OBJECT-TYPE >> SYNTAX BITS { >> ifConfigError (0), >> virtIfConfigError (1), >> ospfNbrStateChange (2), >> . >> . >> . >> } >> MAX-ACCESS read-write >> STATUS current >> DESCRIPTION >> "A One-octet string serving as a bit map for >> the trap events defined by the OSPF traps in >> this MIB. This object is used to enable and >> disable specific OSPF traps where a 1 >> in the corresponding bit field represents >> enabled." >> ::= { cospfTrapControl 1 } >> >>This definition enables the NMS to interpret the bit map easily. >> >> >>ospfIfStateChange >>----------------- >> >>>From the definition it looks like this TRAP should be generated only for terminal states(when state >>progresses) and for backward transition. Infact the name ospfIfStateChange simply suggests to >>generate TRAPs for all state transitions. The general tendency is to ignore the DESCRIPTION when >>"StateChange" is read and assume its for all the state changes. It might lead to wrong >>implementations. I think we can also follow the approach taken in BGP MIB(rfc1657). >>There they have notifications like this, >> bgpEstablished NOTIFICATION-TYPE >> OBJECTS { bgpPeerLastError, >> bgpPeerState } >> STATUS current >> DESCRIPTION >> "The BGP Established event is generated when >> the BGP FSM enters the ESTABLISHED state." >> ::= { bgpTraps 1 } >> >> bgpBackwardTransition NOTIFICATION-TYPE >> OBJECTS { bgpPeerLastError, >> bgpPeerState } >> STATUS current >> DESCRIPTION >> "The BGPBackwardTransition Event is generated >> when the BGP FSM moves from a higher numbered >> state to a lower numbered state." >> ::= { bgpTraps 2 } >> >>Our suggestion is to maintain ospfIfStateChange and use that for monitoring all the states >>(some people may want that) and additionally have notifications similar to the BGP notifications. >>Its also true with VirtIfStateChange, NbrStateChange and VirtNbrStateChange. If somebody doesn't >>want to see ALL state TRAPS, they can suppress them by turning off the corresponding bit in >>ospfSetTrap. >> >> >>ospfNbrStateChange >>------------------ >>The DECRIPTION clause states >>"When an neighbor transitions from or to Full on non-broadcast multi-access and broadcast >> networks, the trap should be generated by the designated router. A designated router >>transitioning to Down will be noted by ospfIfStateChange." >>I think here the intention is to reduce the number of TRAPs as much as possible by making >>only DR sending out this TRAP for a subnet. But there is a possibility that osfpNbrStateChange >>notification is disabled on DR and enabled on DR other or BDR. NMS won't receive TRAPs when >>NbrState becomes FULL in that case. There is a problem with the second part of above statments >>as well. Suppose ospfIfStateChange is disabled on the router, then again NMS won't know when >>neighbor goes down. Probably its better to remove these two clauses. >> >> >>Support for sham links: >>----------------------- >>Are you going to provide support for sham links? We may need these tables and notifications, >>ShamLinkTable >>ShamLinkNbrTable >>ShamLinkStateChange notification >>ShamLinkNbrStateChange notification >> >> >> >> >> >> >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 14 19:31:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20803 for ; Fri, 14 Mar 2003 19:31:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0092F332@cherry.ease.lsoft.com>; Fri, 14 Mar 2003 19:34:01 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 691978 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 14 Mar 2003 19:34:01 -0500 Received: from 66.122.42.228 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Mar 2003 19:33:59 -0500 Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content Technologies SMTPRS 2.0.15) with SMTP id for ; Fri, 14 Mar 2003 16:31:57 -0800 Received: from MANIS (adsl-66-122-42-231.futsoft.com [66.122.42.231]) by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id QAA02815 for ; Fri, 14 Mar 2003 16:11:09 -0800 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 14 Mar 2003 16:33:51 -0800 Reply-To: Mailing List Sender: Mailing List From: Manikantan Srinivasan Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E725E33.5040909@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Acee I agree with you for adding OSPF instance ID as an index. This approach is simple and elegant. I have worked on an implementation with the same approach, using enterprise MIB. cheers mani ==================================== Manikantan Srinivasan Future Communications Software ==================================== #-----Original Message----- #From: Mailing List [mailto:OSPF@discuss.microsoft.com]On Behalf Of Acee #Lindem #Sent: Friday, March 14, 2003 2:57 PM #To: OSPF@discuss.microsoft.com #Subject: Re: OSPFv2 MIB draft # # #Roy, # #I can appreciate your points since our product supports both multiple #virtual router instances and multiple routing protocol instances #within a particular virtual router. However, I think we'd #essentially have to deprecate everything in the current MIB and define #new tables in order to add OSPF instance ID as an index. Can someone #who has more MIB definition experience comment? # #Additionally, the multiple instance problem is not unique to the #OSPF MIB. Maybe a generic solution could be developed. # # #Roy Jose wrote: #> Hi, #> #> I have some comments on draft-ietf-ospf-mib-update-05.txt. I #would also like #> to have some clarifications. Please see the attached document. #> #> Thanks, #> Roy #> #> #>>Yes. An update is in the works. #>> #>>-Dan #>> #>> #>>>-----Original Message----- #>>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] #>>>Sent: Monday, February 10, 2003 3:01 PM #>>>To: OSPF@DISCUSS.MICROSOFT.COM #>>>Subject: OSPFv2 MIB draft #>>> #>>> #>>>Hi all: #>>>I would like to know the status of the working group #>>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an #>>>expiry date of #>>>May 2001. #>>>Is there any plan to update the draft ? #>>> #>>>Thanks #>>>Gargi #>>> #>> #>> #>>------------------------------------------------------------------------ #>> #>>Support for multiple OSPF processes: #>>----------------------------------- #>> #>>We raised this issue some time back in WG. Currently MIB #supports only one Router ID. #>>Multiple processes can have separate router IDs. It is also true #with other MIB objects #>>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution #we got was to use a #>>separate MIB view for each process. But I don't think it can be #easily implemented. #>>We suggest to form a new table to group scalar objects related #to an OSPF process and have #>>Process Id as its INDEX. We also suggest to add Process Id as #one of the INDICES of all #>>tables. #>> #>> #>>MAX-ACCESS value for INDICES of TABLES: #>>-------------------------------------- #>>I see MAX-ACCESS value of all TABLEs are read-only. Normally #INDICES of a table are #>>put as not-accesssible to reduce the number of SNMP messages. #When an SNMP GET or #>>GETNEXT is issued on a non-INDEX object, we can extract the #values of INDICES from #>>the object ID returned. For example, let us consider #ospfAreaLsaCount. When we query #>>the value for this, we get something like #ospfAreaLsaCount.0.0.0.1, where 0.0.0.1 is #>>the AreaId, which is the INDEX of the ospfAreaTable. We can #extract the INDICES of #>>table like this even if they are not-accessible. The tables like #LsdbTable has many #>>number of INDICES and we can reduce the number of SNMP messages #considerably by changing #>>them to not-accessible. #>> #>>If the MAX-ACCESS of INDICES are put as read-only to include #them in the TRAP #>>notification messages, they can be changed as #accessible-for-notify. Other approach to #>>this is remove the INDICES from TRAP notification messages. For #example if you take the #>>case of IfStateChange TRAP, #>> #>> ospfIfStateChange NOTIFICATION-TYPE^M #>> OBJECTS { ospfRouterId, -- The originator of the trap^M #>> ospfIfIpAddress,^M #>> ospfAddressLessIf,^M #>> ospfIfState -- The new state^M #>> }^M #>>Here we don't actually need ospfIfIpAddress and #ospfAddressLessIf. When we send TRAP #>>notification, we can just send ospfIfState.. . #>>Also I am not sure why ospfRouterId is included here. An NMS #station can always query ospfRouterId #>>separately. By removing these MIB objects, we can reduce the #size and processing time of TRAP #>>messages considerably. #>> #>>Section : 4.3 Ignoring Initial Activity #>>--------------------------------------- #>>The section states "The majority of critical events occur when #OSPF is enabled on a #>>router, at which time the designated router is elected and #neighbor adjacencies are formed" . #>>I am not sure if enabling OSPF on a router means enabling it on #an interface. I think it will #>>be better to make the text clearer. #>> #>>Other statement is "To avoid unnecessary traps, a router should #not originate expected OSPF #>>interface related traps until two of that interface's dead timer #intervals have elapsed." #>>I think there will be some problems if the dead interval value #is too long. We may end up #>>not sending any of the expected TRAPS for a long time. Btw, #could I please know the reason #>>for selecting 2 * dead interval value for this purpose?. There #might be some case where an #>>interface is up and it goes down before (2 * dead interval). We #can't take it as an 'expected #>>event'. Probably we can ignore the expected events till the #interface reaches terminal state #>>(FULL or 2WAY) for the first time after enabling OSPF. #>> #>> #>>One more point is we are already limiting ospfIfStateChange, #ospfVirtIfStateChange, #>>ospfNbrStateChange and ospfVirtNbrStateChange notifications by #generating them only for terminal #>>state changes and backward tansition. Do we really need to #ignore them during the initial activity?. #>> #>>Other statement is "Additionally, ospfMaxAgeLsa and #ospfOriginateLsa traps should not be originated #>>until two dead timer intervals have elapsed where the deadtimer #interval used should be the dead #>>timer with the smallest value." Here whats the meaning of "dead #timer with smallest value"? Is it #>>the smallest interval value among all the interfaces? #>> #>> #>>Section 4.4 Throttling Traps #>>---------------------------- #>>Do we need to provide MIB objects corresponding to window size #and the number of TRAPs sent during #>>the window time? Will the TRAPs other than ospfTxRetransmit, #OrginateLsa and MaxAgeLsa really cause #>>a TRAP flood? Probably we need to throttle only the above three TRAPS? #>> #>>I think the normal practice is to inform the NMS using some #other notification at the end of a #>>particular interval when the TRAPs are dropped like this, "Trap #N dropped n times in an interval #>>t". We can add some common extra paratmeters to these #notifications to facilitate the NMS to query #>>the router to retrieve some values and find out whats happening. #>> #>>ospfConfigErrorType #>>------------------- #>>Do we need an error type for duplicate router id in the received #messages? Some times loop back #>>address can be misconfigured. #>> #>>ospfSetTrap #>>----------- #>>The definition of this is little complicated. Any reasons for #going for last bit to first. We think #>>its better to redefine this MIB object like this to make if more clear. #>> #>> cospfSetTrap OBJECT-TYPE #>> SYNTAX BITS { #>> ifConfigError (0), #>> virtIfConfigError (1), #>> ospfNbrStateChange (2), #>> . #>> . #>> . #>> } #>> MAX-ACCESS read-write #>> STATUS current #>> DESCRIPTION #>> "A One-octet string serving as a bit map for #>> the trap events defined by the OSPF traps in #>> this MIB. This object is used to enable and #>> disable specific OSPF traps where a 1 #>> in the corresponding bit field represents #>> enabled." #>> ::= { cospfTrapControl 1 } #>> #>>This definition enables the NMS to interpret the bit map easily. #>> #>> #>>ospfIfStateChange #>>----------------- #>> #>>>From the definition it looks like this TRAP should be generated #only for terminal states(when state #>>progresses) and for backward transition. Infact the name #ospfIfStateChange simply suggests to #>>generate TRAPs for all state transitions. The general tendency #is to ignore the DESCRIPTION when #>>"StateChange" is read and assume its for all the state changes. #It might lead to wrong #>>implementations. I think we can also follow the approach taken #in BGP MIB(rfc1657). #>>There they have notifications like this, #>> bgpEstablished NOTIFICATION-TYPE #>> OBJECTS { bgpPeerLastError, #>> bgpPeerState } #>> STATUS current #>> DESCRIPTION #>> "The BGP Established event is generated when #>> the BGP FSM enters the ESTABLISHED state." #>> ::= { bgpTraps 1 } #>> #>> bgpBackwardTransition NOTIFICATION-TYPE #>> OBJECTS { bgpPeerLastError, #>> bgpPeerState } #>> STATUS current #>> DESCRIPTION #>> "The BGPBackwardTransition Event is generated #>> when the BGP FSM moves from a higher numbered #>> state to a lower numbered state." #>> ::= { bgpTraps 2 } #>> #>>Our suggestion is to maintain ospfIfStateChange and use that for #monitoring all the states #>>(some people may want that) and additionally have notifications #similar to the BGP notifications. #>>Its also true with VirtIfStateChange, NbrStateChange and #VirtNbrStateChange. If somebody doesn't #>>want to see ALL state TRAPS, they can suppress them by turning #off the corresponding bit in #>>ospfSetTrap. #>> #>> #>>ospfNbrStateChange #>>------------------ #>>The DECRIPTION clause states #>>"When an neighbor transitions from or to Full on non-broadcast #multi-access and broadcast #>> networks, the trap should be generated by the designated #router. A designated router #>>transitioning to Down will be noted by ospfIfStateChange." #>>I think here the intention is to reduce the number of TRAPs as #much as possible by making #>>only DR sending out this TRAP for a subnet. But there is a #possibility that osfpNbrStateChange #>>notification is disabled on DR and enabled on DR other or BDR. #NMS won't receive TRAPs when #>>NbrState becomes FULL in that case. There is a problem with the #second part of above statments #>>as well. Suppose ospfIfStateChange is disabled on the router, #then again NMS won't know when #>>neighbor goes down. Probably its better to remove these two clauses. #>> #>> #>>Support for sham links: #>>----------------------- #>>Are you going to provide support for sham links? We may need #these tables and notifications, #>>ShamLinkTable #>>ShamLinkNbrTable #>>ShamLinkStateChange notification #>>ShamLinkNbrStateChange notification #>> #>> #>> #>> #>> #>> #>> #> # # #-- #Acee # From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 14 19:47:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21137 for ; Fri, 14 Mar 2003 19:47:59 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0092F462@cherry.ease.lsoft.com>; Fri, 14 Mar 2003 19:50:08 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 692015 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 14 Mar 2003 19:50:07 -0500 Received: from 156.153.255.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 14 Mar 2003 19:50:07 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel13.hp.com (Postfix) with ESMTP id B13221C0165C for ; Fri, 14 Mar 2003 16:50:06 -0800 (PST) Received: from rose.hp.com (ros54018fli.rose.hp.com [15.29.17.171]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id QAA05108 for ; Fri, 14 Mar 2003 16:49:52 -0800 (PST) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3eca01c2ea38$82cf0a30$9c8b4d0a@apac.cisco.com> <3E725E33.5040909@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E7278AE.BDA8BE3D@rose.hp.com> Date: Fri, 14 Mar 2003 16:49:50 -0800 Reply-To: Mailing List Sender: Mailing List From: John Flick Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yep, adding an index would require deprecating everything and starting over. Since this is an existing, widely deployed, Draft Standard MIB, this should not be done lightly. You would have the same problem if you tried changing MAX-ACCESS on the table indices (as was also suggested below). Since a change to MAX-ACCESS of an existing object is not allowed, you would need to deprecated the index objects, which would require deprecating the tables that they index. Changing to not-accessible is not required, since SMIv2 allows read-only indices for MIB modules that were translated from SMIv1 and therefore already had read-only indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 MIB module, so this exception applies. As far as finding a generic solution for multiple instances of a MIB module, the standard solution is to use contexts (note: this is not the same as a MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done in a somewhat ad-hoc way by using different community names for each instance of the OSPF MIB. In SNMPv3, it is more formally defined using the contextName. The Entity MIB entLogicalTable (RFC 2737) provides information about what contexts exist in an agent, and how to get to them. John Acee Lindem wrote: > > Roy, > > I can appreciate your points since our product supports both multiple > virtual router instances and multiple routing protocol instances > within a particular virtual router. However, I think we'd > essentially have to deprecate everything in the current MIB and define > new tables in order to add OSPF instance ID as an index. Can someone > who has more MIB definition experience comment? > > Additionally, the multiple instance problem is not unique to the > OSPF MIB. Maybe a generic solution could be developed. > > Roy Jose wrote: > > Hi, > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I would also like > > to have some clarifications. Please see the attached document. > > > > Thanks, > > Roy > > > > > >>Yes. An update is in the works. > >> > >>-Dan > >> > >> > >>>-----Original Message----- > >>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > >>>Sent: Monday, February 10, 2003 3:01 PM > >>>To: OSPF@DISCUSS.MICROSOFT.COM > >>>Subject: OSPFv2 MIB draft > >>> > >>> > >>>Hi all: > >>>I would like to know the status of the working group > >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an > >>>expiry date of > >>>May 2001. > >>>Is there any plan to update the draft ? > >>> > >>>Thanks > >>>Gargi > >>> > >> > >> > >>------------------------------------------------------------------------ > >> > >>Support for multiple OSPF processes: > >>----------------------------------- > >> > >>We raised this issue some time back in WG. Currently MIB supports only one Router ID. > >>Multiple processes can have separate router IDs. It is also true with other MIB objects > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we got was to use a > >>separate MIB view for each process. But I don't think it can be easily implemented. > >>We suggest to form a new table to group scalar objects related to an OSPF process and have > >>Process Id as its INDEX. We also suggest to add Process Id as one of the INDICES of all > >>tables. > >> > >> > >>MAX-ACCESS value for INDICES of TABLES: > >>-------------------------------------- > >>I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES of a table are > >>put as not-accesssible to reduce the number of SNMP messages. When an SNMP GET or > >>GETNEXT is issued on a non-INDEX object, we can extract the values of INDICES from > >>the object ID returned. For example, let us consider ospfAreaLsaCount. When we query > >>the value for this, we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1 is > >>the AreaId, which is the INDEX of the ospfAreaTable. We can extract the INDICES of > >>table like this even if they are not-accessible. The tables like LsdbTable has many > >>number of INDICES and we can reduce the number of SNMP messages considerably by changing > >>them to not-accessible. > >> > >>If the MAX-ACCESS of INDICES are put as read-only to include them in the TRAP > >>notification messages, they can be changed as accessible-for-notify. Other approach to > >>this is remove the INDICES from TRAP notification messages. For example if you take the > >>case of IfStateChange TRAP, > >> > >> ospfIfStateChange NOTIFICATION-TYPE^M > >> OBJECTS { ospfRouterId, -- The originator of the trap^M > >> ospfIfIpAddress,^M > >> ospfAddressLessIf,^M > >> ospfIfState -- The new state^M > >> }^M > >>Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. When we send TRAP > >>notification, we can just send ospfIfState.. . > >>Also I am not sure why ospfRouterId is included here. An NMS station can always query ospfRouterId > >>separately. By removing these MIB objects, we can reduce the size and processing time of TRAP > >>messages considerably. > >> > >>Section : 4.3 Ignoring Initial Activity > >>--------------------------------------- > >>The section states "The majority of critical events occur when OSPF is enabled on a > >>router, at which time the designated router is elected and neighbor adjacencies are formed" . > >>I am not sure if enabling OSPF on a router means enabling it on an interface. I think it will > >>be better to make the text clearer. > >> > >>Other statement is "To avoid unnecessary traps, a router should not originate expected OSPF > >>interface related traps until two of that interface's dead timer intervals have elapsed." > >>I think there will be some problems if the dead interval value is too long. We may end up > >>not sending any of the expected TRAPS for a long time. Btw, could I please know the reason > >>for selecting 2 * dead interval value for this purpose?. There might be some case where an > >>interface is up and it goes down before (2 * dead interval). We can't take it as an 'expected > >>event'. Probably we can ignore the expected events till the interface reaches terminal state > >>(FULL or 2WAY) for the first time after enabling OSPF. > >> > >> > >>One more point is we are already limiting ospfIfStateChange, ospfVirtIfStateChange, > >>ospfNbrStateChange and ospfVirtNbrStateChange notifications by generating them only for terminal > >>state changes and backward tansition. Do we really need to ignore them during the initial activity?. > >> > >>Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa traps should not be originated > >>until two dead timer intervals have elapsed where the deadtimer interval used should be the dead > >>timer with the smallest value." Here whats the meaning of "dead timer with smallest value"? Is it > >>the smallest interval value among all the interfaces? > >> > >> > >>Section 4.4 Throttling Traps > >>---------------------------- > >>Do we need to provide MIB objects corresponding to window size and the number of TRAPs sent during > >>the window time? Will the TRAPs other than ospfTxRetransmit, OrginateLsa and MaxAgeLsa really cause > >>a TRAP flood? Probably we need to throttle only the above three TRAPS? > >> > >>I think the normal practice is to inform the NMS using some other notification at the end of a > >>particular interval when the TRAPs are dropped like this, "Trap N dropped n times in an interval > >>t". We can add some common extra paratmeters to these notifications to facilitate the NMS to query > >>the router to retrieve some values and find out whats happening. > >> > >>ospfConfigErrorType > >>------------------- > >>Do we need an error type for duplicate router id in the received messages? Some times loop back > >>address can be misconfigured. > >> > >>ospfSetTrap > >>----------- > >>The definition of this is little complicated. Any reasons for going for last bit to first. We think > >>its better to redefine this MIB object like this to make if more clear. > >> > >> cospfSetTrap OBJECT-TYPE > >> SYNTAX BITS { > >> ifConfigError (0), > >> virtIfConfigError (1), > >> ospfNbrStateChange (2), > >> . > >> . > >> . > >> } > >> MAX-ACCESS read-write > >> STATUS current > >> DESCRIPTION > >> "A One-octet string serving as a bit map for > >> the trap events defined by the OSPF traps in > >> this MIB. This object is used to enable and > >> disable specific OSPF traps where a 1 > >> in the corresponding bit field represents > >> enabled." > >> ::= { cospfTrapControl 1 } > >> > >>This definition enables the NMS to interpret the bit map easily. > >> > >> > >>ospfIfStateChange > >>----------------- > >> > >>>From the definition it looks like this TRAP should be generated only for terminal states(when state > >>progresses) and for backward transition. Infact the name ospfIfStateChange simply suggests to > >>generate TRAPs for all state transitions. The general tendency is to ignore the DESCRIPTION when > >>"StateChange" is read and assume its for all the state changes. It might lead to wrong > >>implementations. I think we can also follow the approach taken in BGP MIB(rfc1657). > >>There they have notifications like this, > >> bgpEstablished NOTIFICATION-TYPE > >> OBJECTS { bgpPeerLastError, > >> bgpPeerState } > >> STATUS current > >> DESCRIPTION > >> "The BGP Established event is generated when > >> the BGP FSM enters the ESTABLISHED state." > >> ::= { bgpTraps 1 } > >> > >> bgpBackwardTransition NOTIFICATION-TYPE > >> OBJECTS { bgpPeerLastError, > >> bgpPeerState } > >> STATUS current > >> DESCRIPTION > >> "The BGPBackwardTransition Event is generated > >> when the BGP FSM moves from a higher numbered > >> state to a lower numbered state." > >> ::= { bgpTraps 2 } > >> > >>Our suggestion is to maintain ospfIfStateChange and use that for monitoring all the states > >>(some people may want that) and additionally have notifications similar to the BGP notifications. > >>Its also true with VirtIfStateChange, NbrStateChange and VirtNbrStateChange. If somebody doesn't > >>want to see ALL state TRAPS, they can suppress them by turning off the corresponding bit in > >>ospfSetTrap. > >> > >> > >>ospfNbrStateChange > >>------------------ > >>The DECRIPTION clause states > >>"When an neighbor transitions from or to Full on non-broadcast multi-access and broadcast > >> networks, the trap should be generated by the designated router. A designated router > >>transitioning to Down will be noted by ospfIfStateChange." > >>I think here the intention is to reduce the number of TRAPs as much as possible by making > >>only DR sending out this TRAP for a subnet. But there is a possibility that osfpNbrStateChange > >>notification is disabled on DR and enabled on DR other or BDR. NMS won't receive TRAPs when > >>NbrState becomes FULL in that case. There is a problem with the second part of above statments > >>as well. Suppose ospfIfStateChange is disabled on the router, then again NMS won't know when > >>neighbor goes down. Probably its better to remove these two clauses. > >> > >> > >>Support for sham links: > >>----------------------- > >>Are you going to provide support for sham links? We may need these tables and notifications, > >>ShamLinkTable > >>ShamLinkNbrTable > >>ShamLinkStateChange notification > >>ShamLinkNbrStateChange notification > >> > >> > >> > >> > >> > >> > >> > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sat Mar 15 07:05:18 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14731 for ; Sat, 15 Mar 2003 07:05:17 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00930177@cherry.ease.lsoft.com>; Sat, 15 Mar 2003 7:07:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 693361 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 15 Mar 2003 07:07:26 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 15 Mar 2003 07:07:26 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id DDB9B5C52B for ; Sat, 15 Mar 2003 04:07:10 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E7317EC.7000606@redback.com> Date: Sat, 15 Mar 2003 07:09:16 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF WG Presentations Posted To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit OSPF WG presentations are posted on the proceedings web page. Abhay sent me the OSPFv3 address family slides but they haven't been posted yet. http://www.ietf.org/proceedings/03mar/ -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sun Mar 16 20:06:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14499 for ; Sun, 16 Mar 2003 20:06:39 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00932DB2@cherry.ease.lsoft.com>; 16 Mar 2003 20:08:48 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 696281 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 16 Mar 2003 20:08:48 -0500 Received: from 207.217.120.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 16 Mar 2003 20:08:47 -0500 Received: from user-38lc10m.dialup.mindspring.com ([209.86.4.22] helo=earthlink.net) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18uj7N-00055S-00 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 16 Mar 2003 17:08:46 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <200303121911.OAA14095@bigbird.xebeo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E751FD0.932F5CB3@earthlink.net> Date: Sun, 16 Mar 2003 17:07:28 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit (1) 1st question... 2.1 processing OSPF v2 Opaque LSAs. (OSPFv2 Opaque LSAs in OSPFv3: draft) "An OSPF v3 ... as defined in [OSPFv3]." Why? Why don't we handle it in the context that the LSA was originated? In OSPFv2. Isn't this logic then specific to who recv's the LSA? Specificly what our our tradeoffs if we do OSPFv2 vs v3? (2) 2nd question... Do we ever want to convert the LSA from OSPFv2 to be in the proper format as originated by a OSPFv3 router? Especially if we are a DR and about to flood it to our v3 adjs. Why would you want to still send it out as a V2 LSA? (3) When would we convert it? (4) When wouldn't we convert it? (5) When would you flood both types from a v3? See the below senario with v2 and v3 being equal. Wouldn't this duplicate each recieved LSA by each router? Router v3 b recvs LSA from router a (v2), duplicates it an sends it to v2 and v3 routers.The next v3 router sees the v2 LSA and then creates a v3 LSA and forwards that one. Then the v3 version then arrives and gets forward. Help....Each time it is recieved it gets duplicated. ouch.. (6) And I assume that the LSAs are originated in v2. What happens if we want to originate the v2 from a v3 router. Is this allowed? I would think that this would then make sense in the section with the #1 below. ---------- Now, I like to step back and look at the big picture to see why we want to do this and since we are involved with a set of other routing protcols, do they have a set way of operation? 1) What does it really mean if we have an area full of OSPFv2 routers and 1 OSPFv3 router? Should their be 2-way communciation (sending and recieving v2 LSAs from a v3 router)? 2) Reverse number 1.. Same questions.. 3) What happens if we have equal number of OSPFv2/IPv4 and OSPFv3/IPv6, then what is wrong with a ships in the night approach? 4) Do we expect IPv4 pings to be understood with IPv6 pings? (aka icmp echo request and reply). Should the OSPF versions behave the same? And lastly if their was 2-way communication, then why not form adjs between the different versions? Or at least 1-way nbrs? Why not architect the allowance of hellos formed in a OSPFv3 be sent to a a OSPFv2 router?? Wouldn't this follow the "how OSPF version 2 opaque LSAs can be caried in OSPF version 3". Where do you stop? Should an interface to a router have socket capabilites that now specify whether it is IPv4 or IPv6? Thus, if it came on the IPv4 interface, then it is a OSPFv2 packet, else it is a IPv6. Sorry, this subject just raises a ton of questions.. Mitchell Erblich Sr. Software Engineer =========================================== Rohit Dube wrote: > > Hi Kireeti, > > Some comments inline [..] > > On Wed, 12 Mar 2003 10:28:44 -0800 Kireeti Kompella writes: > =>Hi Rohit, > => > =>On Tue, 4 Mar 2003, Rohit Dube wrote: > => > =>> This issue has been around for a while and it is time that > =>> we picked one of the proposals as the WG document. > => > =>Before we do that, let me try to summarize what the _real_ issue is. > =>The read that I got at the last IETF is that OSPFv2 and OSPFv3 are > =>*different* protocols; that one is focussed on IPv4 and the other > =>on IPv6. > > Yes - one of the main arguments put out in previous discussions is > in fact that OSPFv2 and OSPFv3 are different protocols. I just wanted > to point out that "OSPFv2 is for ipv4 and OSPFv3 is for ipv6" is not > the only significant point of difference. The too protocols differ > in other areas as well : for example generalization of flooding scope > which we have discussed previously on the list. > > Certainly the way RFC2740 is written, it deals primarily with ipv6. > And as such OSPFv3 is not adequately specified for ipv4. > > =>So, the real question is, do we want to go down this path: create a > =>major split, and declare v2 and v3 are different protocols. IMO, > =>they are very closely related, and building on that closeness rather > =>than emphasizing the differences is a better path. > > IMO this would also mean that 2740 would have to be revisited to > clarify/specify support for ipv4. > > => > =>So, for example, carrying IPv4 prefixes in OSPFv3 the same way > =>that they are carried in OSPFv2, carrying OSPFv2 opaque LSAs in v3 > =>as is, etc. seems a cleaner path. On the other hand, defining new > =>formats for TE in v3 emphasizes the difference. > => > =>I can't speak for all the authors of OSPFv3, but there was a mail by > =>Dennis Ferguson that seemed to indicate that he would like to see v3 > =>include v2, not as different protocols. I could be wrong -- but it > =>would be nice to at least get the opinions of the authors before we > =>declare a major fork in the road. > > Yes I remember this. People can revisit this discussion at the OSPF > archives circa october 2002. During this discussion it was also mentioned > that one of the OSPFv3 authors preferred to run OSPFv3 separately from > OSPFv2 wherever both ipv4 and ipv6 were needed. > > Certainly opinions from the co-authors as well as others actively > developing OSPFv3 are very welcome. > > => > =>Kireeti. > ___ > > Best, > --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Sun Mar 16 20:24:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14955 for ; Sun, 16 Mar 2003 20:24:47 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00932DFB@cherry.ease.lsoft.com>; 16 Mar 2003 20:26:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 696337 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 16 Mar 2003 20:26:59 -0500 Received: from 207.217.120.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 16 Mar 2003 20:26:58 -0500 Received: from user-38lc10m.dialup.mindspring.com ([209.86.4.22] helo=earthlink.net) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18ujOz-0007fS-00 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 16 Mar 2003 17:26:58 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <39469E08BD83D411A3D900204840EC55763516@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E752414.1B0966B@earthlink.net> Date: Sun, 16 Mar 2003 17:25:40 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I think people are missing the big picture. The question is not how much code is the same, but how much should it differ in the future. I see that IPv4 / OSPFv2 is a somewhat stable version with a certain number of legacy routers that will never have new functionality code added to their "firmware". With this is mid it will be very difficult not to support some level of ships in the night (SIN) approach. Mitchell Erblich Sr Software Engineer ============================== "Naidu, Venkata" wrote: > > [1] > -> run OSPFv3 separately from > -> OSPFv2 wherever both ipv4 and ipv6 were needed. > [2] > -> In one implementation, OSPFv3 and OSPFv2 share more than > -> 80 percent of the code. The less than 20 % comes from the > -> differences between the 2 protocols, > > Don't you think above [1] & [2] statements are contradictory. > If 80% of the code is same, then why should any > customer prefer to run different instances when the > code is almost same. > > In other words, if integrated-ISIS can handle both ISO > and IPv4 address, will you prefer to run two ISIS instances > (one for ISO and one IPv4) when a single ISIS instance can > handle both addresses independently. > > I would like to know the "technical" & "operational" > advantages of running two different instances of the > (almost) same protocol(s). > > Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Sun Mar 16 20:46:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15521 for ; Sun, 16 Mar 2003 20:46:34 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00932E59@cherry.ease.lsoft.com>; 16 Mar 2003 20:48:47 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 696376 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 16 Mar 2003 20:48:46 -0500 Received: from 207.217.120.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 16 Mar 2003 20:48:46 -0500 Received: from user-38lc10m.dialup.mindspring.com ([209.86.4.22] helo=earthlink.net) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18ujk4-0006bt-00 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 16 Mar 2003 17:48:45 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <200210171729.g9HHTwm17092@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E75292E.4591BF66@earthlink.net> Date: Sun, 16 Mar 2003 17:47:26 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Dennis, Sorry, but I agree with your first statement. "Why is having "many, many LSA types" any less clean than having many, many > opaque LSA types?" If I recieve a LSA, I only need to parse the LSA header before I need to decide how I am going to handle it. If I have many LSA opaque subtypes, don't I need to do more initial parsing before I can decide what to do with it? Thus, I am not really a fan of having 45 or so opaque LSA subtypes in the possible future. Mitchell Erblich Sr. Software Engineer =================================== Dennis Ferguson wrote: > > Sina, > > > if you want to allocate a new LSA type for each opaque type ( or better say > > for each new LSA introduced ) then we won't need to call this opaque LSA, > > you basically want to go to the idea of 'introducing a new LSA type' for > > each 'new LSA defined' and we will end up with many, many LSA type which I > > am not sure is a clean way ... > > Why is having "many, many LSA types" any less clean than having many, many > opaque LSA types? What difference does it make whether you need to look at > the LSA type or the opaque LSA's internal type to determine if you recognize > it? Note that if you don't recognize the LSA type OSPFv3 already forces you > to implement the procedures both to handle any number of unrecognized LSAs > and to flood them properly in any case, so why would you want to add yet > more code to the implementation to do the same thing a different way? If > there's anything unclean about this it would be adding a second way to > provide functionality which already exists, and must be implemented, > in the protocol. > > To be clear, I think the proper way to handle moving functionality from > OSPFv2 Opaque LSAs to OSPFv3 is to take the LSA-type+Opaque-type and map > it to an OSPFv3 LSA-type+flooding-scope. I am still concerned that there > be a way to specify the contents of the OSPFv2 LSA-type+Opaque-type, or > an equivalent OSPFv3 LSA-type+flooding-scope, in a single document, but > adding Opaque LSAs themselves to OSPFv3 (as opposed to mapping the contents > of a particular OSPFv2 opaque LSA type to an OSPFv3 LSA type) is an orthogonal > issue which adds no new functionality to the protocol, but requires that > every write code to support a second way to do the same thing. This doesn't > seem to make much sense. > > If there was some advantage to Opaque LSAs over OSPFv3's generic LSA flooding > procedures I think the time to point this out was the 3 years between > 1996, when OSPFv3's flooding procedures were first proposed, and 1999, > when the document became an RFC, so that the generic procedures could be > removed (like OSPFv2) and Opaque LSAs added instead. No matter how it is > done there needs to be only one way to do it, and OSPFv3 already has a way. > > > that way we honor the name opaque LSA ;-) and won't introduce a new LSA type > > every time we need to define a LSA > > But you've still not pointed out what is wrong with introducing a new LSA > type every time you need one. OSPFv3 makes everyone write code to handle > this, so what is wrong with making use of that code? > > > also it is not because we define opaque in v3 the same way as in v2 ( that > > is, using LS ID for opaque type and instance ) that we have to sync > > completely between v2 and v3, ospfv3 could have its own opaque type to be > > defined / standardized independently ... > > But OSPFv3 has already has its own opaque type. It is an LSA type you don't > understand with a flooding scope that you do understand. What's the use > of having another one? > > Dennis Ferguson From owner-ospf@DISCUSS.MICROSOFT.COM Sun Mar 16 23:41:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19493 for ; Sun, 16 Mar 2003 23:41:46 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0093332C@cherry.ease.lsoft.com>; 16 Mar 2003 23:43:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 696604 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 16 Mar 2003 23:43:56 -0500 Received: from 64.139.11.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 16 Mar 2003 23:43:56 -0500 Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2H4gfcd001100; Mon, 17 Mar 2003 13:42:41 +0900 References: <20030312101401.B95881@kummer.juniper.net> <200303121911.OAA14095@bigbird.xebeo.com> <200303122007.h2CK79L38929@fuinar.juniper.net> <3E6FA932.4060606@redback.com> User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: <8765qisiwu.wl@ipinfusion.com> Date: Sun, 16 Mar 2003 20:42:41 -0800 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: OSPFv3 Applications Support Comments: To: Acee Lindem To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E6FA932.4060606@redback.com> Precedence: list >In my opinion, it is an even smaller change to remove the extra >level of hierarchy for applications using OSPFv2 opaque LSAs. Why >have the extra type when we can simply assign a LSA type for >TE LSAs, grace LSAs or foo LSAs? It seems much like a much more >natural classification to me. It is much more likely that I'm going >to want to process all the LSAs for a given application than >all my opaque LSAs. Agreed. >I also feel that whether or not OSPFv3 will eventually be used >for carrying IPv4 prefixes is a completely independent issue >(othrogonal in IETF-speak ;^). Yes. It is independent issue. But when we support it, we will define new LS type. If we carry IPv4 prefix in OSPFv3 with OSPFv2 Opaque LSA format....that will be nightmare... -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 17 04:39:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08526 for ; Mon, 17 Mar 2003 04:39:19 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.009339CD@cherry.ease.lsoft.com>; Mon, 17 Mar 2003 4:41:29 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 697128 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 17 Mar 2003 04:41:28 -0500 Received: from 171.71.177.254 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Mar 2003 04:41:28 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2H9fPEY013238 for ; Mon, 17 Mar 2003 01:41:26 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id PAA02604 for ; Mon, 17 Mar 2003 15:10:03 +0530 (IST) References: <3eca01c2ea38$82cf0a30$9c8b4d0a@apac.cisco.com> <3E725E33.5040909@redback.com> <3E7278AE.BDA8BE3D@rose.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <00c001c2ec69$5fb7afb0$9c8b4d0a@apac.cisco.com> Date: Mon, 17 Mar 2003 15:11:23 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Thanks Jeff, Acee, Mani and John for your responses. How about other points?:) ----- Original Message ----- From: "John Flick" To: Sent: Saturday, March 15, 2003 6:19 AM Subject: Re: OSPFv2 MIB draft > Yep, adding an index would require deprecating everything and starting over. > Since this is an existing, widely deployed, Draft Standard MIB, this should > not be done lightly. > > You would have the same problem if you tried changing MAX-ACCESS on the > table indices (as was also suggested below). Since a change to MAX-ACCESS > of an existing object is not allowed, you would need to deprecated the index > objects, which would require deprecating the tables that they index. Changing > to not-accessible is not required, since SMIv2 allows read-only indices for > MIB modules that were translated from SMIv1 and therefore already had > read-only indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 MIB > module, so this exception applies. How about tables which were added later?: ospfAreaAggregateTable, ExtLsdbTable, etc. My worry is not if its allowed or not. I am trying to point out the extra processing routers and NMS have to do with the increased number of messages. > As far as finding a generic solution for multiple instances of a MIB module, > the standard solution is to use contexts (note: this is not the same as a > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done in a > somewhat ad-hoc way by using different community names for each instance > of the OSPF MIB. In SNMPv3, it is more formally defined using the > contextName. The Entity MIB entLogicalTable (RFC 2737) provides information > about what contexts exist in an agent, and how to get to them. After having a glance at rfc2737, I also think this is the way. I think we need to specify it clearly how it can be achieved using entLogicalTable. For example, how we need to represent the SNMP community string to retrieve info from a particular routing instance. Thanks, Roy > > John > > Acee Lindem wrote: > > > > Roy, > > > > I can appreciate your points since our product supports both multiple > > virtual router instances and multiple routing protocol instances > > within a particular virtual router. However, I think we'd > > essentially have to deprecate everything in the current MIB and define > > new tables in order to add OSPF instance ID as an index. Can someone > > who has more MIB definition experience comment? > > > > Additionally, the multiple instance problem is not unique to the > > OSPF MIB. Maybe a generic solution could be developed. > > > > Roy Jose wrote: > > > Hi, > > > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I would also like > > > to have some clarifications. Please see the attached document. > > > > > > Thanks, > > > Roy > > > > > > > > >>Yes. An update is in the works. > > >> > > >>-Dan > > >> > > >> > > >>>-----Original Message----- > > >>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > > >>>Sent: Monday, February 10, 2003 3:01 PM > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > >>>Subject: OSPFv2 MIB draft > > >>> > > >>> > > >>>Hi all: > > >>>I would like to know the status of the working group > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an > > >>>expiry date of > > >>>May 2001. > > >>>Is there any plan to update the draft ? > > >>> > > >>>Thanks > > >>>Gargi > > >>> > > >> > > >> > > >>------------------------------------------------------------------------ > > >> > > >>Support for multiple OSPF processes: > > >>----------------------------------- > > >> > > >>We raised this issue some time back in WG. Currently MIB supports only one Router ID. > > >>Multiple processes can have separate router IDs. It is also true with other MIB objects > > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we got was to use a > > >>separate MIB view for each process. But I don't think it can be easily implemented. > > >>We suggest to form a new table to group scalar objects related to an OSPF process and have > > >>Process Id as its INDEX. We also suggest to add Process Id as one of the INDICES of all > > >>tables. > > >> > > >> > > >>MAX-ACCESS value for INDICES of TABLES: > > >>-------------------------------------- > > >>I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES of a table are > > >>put as not-accesssible to reduce the number of SNMP messages. When an SNMP GET or > > >>GETNEXT is issued on a non-INDEX object, we can extract the values of INDICES from > > >>the object ID returned. For example, let us consider ospfAreaLsaCount. When we query > > >>the value for this, we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1 is > > >>the AreaId, which is the INDEX of the ospfAreaTable. We can extract the INDICES of > > >>table like this even if they are not-accessible. The tables like LsdbTable has many > > >>number of INDICES and we can reduce the number of SNMP messages considerably by changing > > >>them to not-accessible. > > >> > > >>If the MAX-ACCESS of INDICES are put as read-only to include them in the TRAP > > >>notification messages, they can be changed as accessible-for-notify. Other approach to > > >>this is remove the INDICES from TRAP notification messages. For example if you take the > > >>case of IfStateChange TRAP, > > >> > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > >> OBJECTS { ospfRouterId, -- The originator of the trap^M > > >> ospfIfIpAddress,^M > > >> ospfAddressLessIf,^M > > >> ospfIfState -- The new state^M > > >> }^M > > >>Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. When we send TRAP > > >>notification, we can just send ospfIfState.. . > > >>Also I am not sure why ospfRouterId is included here. An NMS station can always query ospfRouterId > > >>separately. By removing these MIB objects, we can reduce the size and processing time of TRAP > > >>messages considerably. > > >> > > >>Section : 4.3 Ignoring Initial Activity > > >>--------------------------------------- > > >>The section states "The majority of critical events occur when OSPF is enabled on a > > >>router, at which time the designated router is elected and neighbor adjacencies are formed" . > > >>I am not sure if enabling OSPF on a router means enabling it on an interface. I think it will > > >>be better to make the text clearer. > > >> > > >>Other statement is "To avoid unnecessary traps, a router should not originate expected OSPF > > >>interface related traps until two of that interface's dead timer intervals have elapsed." > > >>I think there will be some problems if the dead interval value is too long. We may end up > > >>not sending any of the expected TRAPS for a long time. Btw, could I please know the reason > > >>for selecting 2 * dead interval value for this purpose?. There might be some case where an > > >>interface is up and it goes down before (2 * dead interval). We can't take it as an 'expected > > >>event'. Probably we can ignore the expected events till the interface reaches terminal state > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > >> > > >> > > >>One more point is we are already limiting ospfIfStateChange, ospfVirtIfStateChange, > > >>ospfNbrStateChange and ospfVirtNbrStateChange notifications by generating them only for terminal > > >>state changes and backward tansition. Do we really need to ignore them during the initial activity?. > > >> > > >>Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa traps should not be originated > > >>until two dead timer intervals have elapsed where the deadtimer interval used should be the dead > > >>timer with the smallest value." Here whats the meaning of "dead timer with smallest value"? Is it > > >>the smallest interval value among all the interfaces? > > >> > > >> > > >>Section 4.4 Throttling Traps > > >>---------------------------- > > >>Do we need to provide MIB objects corresponding to window size and the number of TRAPs sent during > > >>the window time? Will the TRAPs other than ospfTxRetransmit, OrginateLsa and MaxAgeLsa really cause > > >>a TRAP flood? Probably we need to throttle only the above three TRAPS? > > >> > > >>I think the normal practice is to inform the NMS using some other notification at the end of a > > >>particular interval when the TRAPs are dropped like this, "Trap N dropped n times in an interval > > >>t". We can add some common extra paratmeters to these notifications to facilitate the NMS to query > > >>the router to retrieve some values and find out whats happening. > > >> > > >>ospfConfigErrorType > > >>------------------- > > >>Do we need an error type for duplicate router id in the received messages? Some times loop back > > >>address can be misconfigured. > > >> > > >>ospfSetTrap > > >>----------- > > >>The definition of this is little complicated. Any reasons for going for last bit to first. We think > > >>its better to redefine this MIB object like this to make if more clear. > > >> > > >> cospfSetTrap OBJECT-TYPE > > >> SYNTAX BITS { > > >> ifConfigError (0), > > >> virtIfConfigError (1), > > >> ospfNbrStateChange (2), > > >> . > > >> . > > >> . > > >> } > > >> MAX-ACCESS read-write > > >> STATUS current > > >> DESCRIPTION > > >> "A One-octet string serving as a bit map for > > >> the trap events defined by the OSPF traps in > > >> this MIB. This object is used to enable and > > >> disable specific OSPF traps where a 1 > > >> in the corresponding bit field represents > > >> enabled." > > >> ::= { cospfTrapControl 1 } > > >> > > >>This definition enables the NMS to interpret the bit map easily. > > >> > > >> > > >>ospfIfStateChange > > >>----------------- > > >> > > >>>From the definition it looks like this TRAP should be generated only for terminal states(when state > > >>progresses) and for backward transition. Infact the name ospfIfStateChange simply suggests to > > >>generate TRAPs for all state transitions. The general tendency is to ignore the DESCRIPTION when > > >>"StateChange" is read and assume its for all the state changes. It might lead to wrong > > >>implementations. I think we can also follow the approach taken in BGP MIB(rfc1657). > > >>There they have notifications like this, > > >> bgpEstablished NOTIFICATION-TYPE > > >> OBJECTS { bgpPeerLastError, > > >> bgpPeerState } > > >> STATUS current > > >> DESCRIPTION > > >> "The BGP Established event is generated when > > >> the BGP FSM enters the ESTABLISHED state." > > >> ::= { bgpTraps 1 } > > >> > > >> bgpBackwardTransition NOTIFICATION-TYPE > > >> OBJECTS { bgpPeerLastError, > > >> bgpPeerState } > > >> STATUS current > > >> DESCRIPTION > > >> "The BGPBackwardTransition Event is generated > > >> when the BGP FSM moves from a higher numbered > > >> state to a lower numbered state." > > >> ::= { bgpTraps 2 } > > >> > > >>Our suggestion is to maintain ospfIfStateChange and use that for monitoring all the states > > >>(some people may want that) and additionally have notifications similar to the BGP notifications. > > >>Its also true with VirtIfStateChange, NbrStateChange and VirtNbrStateChange. If somebody doesn't > > >>want to see ALL state TRAPS, they can suppress them by turning off the corresponding bit in > > >>ospfSetTrap. > > >> > > >> > > >>ospfNbrStateChange > > >>------------------ > > >>The DECRIPTION clause states > > >>"When an neighbor transitions from or to Full on non-broadcast multi-access and broadcast > > >> networks, the trap should be generated by the designated router. A designated router > > >>transitioning to Down will be noted by ospfIfStateChange." > > >>I think here the intention is to reduce the number of TRAPs as much as possible by making > > >>only DR sending out this TRAP for a subnet. But there is a possibility that osfpNbrStateChange > > >>notification is disabled on DR and enabled on DR other or BDR. NMS won't receive TRAPs when > > >>NbrState becomes FULL in that case. There is a problem with the second part of above statments > > >>as well. Suppose ospfIfStateChange is disabled on the router, then again NMS won't know when > > >>neighbor goes down. Probably its better to remove these two clauses. > > >> > > >> > > >>Support for sham links: > > >>----------------------- > > >>Are you going to provide support for sham links? We may need these tables and notifications, > > >>ShamLinkTable > > >>ShamLinkNbrTable > > >>ShamLinkStateChange notification > > >>ShamLinkNbrStateChange notification > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > > -- > > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 17 04:45:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08748 for ; Mon, 17 Mar 2003 04:45:47 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0093393E@cherry.ease.lsoft.com>; Mon, 17 Mar 2003 4:47:58 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 697141 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 17 Mar 2003 04:47:58 -0500 Received: from 171.71.177.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Mar 2003 04:47:58 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2H9ls0E008251 for ; Mon, 17 Mar 2003 01:47:55 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id PAA03331 for ; Mon, 17 Mar 2003 15:16:32 +0530 (IST) References: <3eca01c2ea38$82cf0a30$9c8b4d0a@apac.cisco.com> <3E725E33.5040909@redback.com> <3E7278AE.BDA8BE3D@rose.hp.com> <00c001c2ec69$5fb7afb0$9c8b4d0a@apac.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <00d501c2ec6a$47a3f090$9c8b4d0a@apac.cisco.com> Date: Mon, 17 Mar 2003 15:17:52 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit One more point I would like to add. Please see below. > Thanks Jeff, Acee, Mani and John for your responses. How about other > points?:) > > ----- Original Message ----- > From: "John Flick" > To: > Sent: Saturday, March 15, 2003 6:19 AM > Subject: Re: OSPFv2 MIB draft > > > Yep, adding an index would require deprecating everything and starting > over. > > Since this is an existing, widely deployed, Draft Standard MIB, this > should > > not be done lightly. > > > > You would have the same problem if you tried changing MAX-ACCESS on the > > table indices (as was also suggested below). Since a change to MAX-ACCESS > > of an existing object is not allowed, you would need to deprecated the > index > > objects, which would require deprecating the tables that they index. > Changing > > to not-accessible is not required, since SMIv2 allows read-only indices > for > > MIB modules that were translated from SMIv1 and therefore already had > > read-only indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 > MIB > > module, so this exception applies. > > How about tables which were added later?: ospfAreaAggregateTable, > ExtLsdbTable, etc. > My worry is not if its allowed or not. I am trying to point out the extra > processing routers and > NMS have to do with the increased number of messages. > > > As far as finding a generic solution for multiple instances of a MIB > module, > > the standard solution is to use contexts (note: this is not the same as a > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done in a > > somewhat ad-hoc way by using different community names for each instance > > of the OSPF MIB. In SNMPv3, it is more formally defined using the > > contextName. The Entity MIB entLogicalTable (RFC 2737) provides > information > > about what contexts exist in an agent, and how to get to them. > > After having a glance at rfc2737, I also think this is the way. I think we > need to specify it clearly how it can be achieved using entLogicalTable. For > example, how we need to represent the SNMP community string to retrieve info > from a particular routing instance. Other confusion can be, how can the NMS interpret the routing instance from the TRAP messages it receives. -Roy > > Thanks, > Roy > > > > > John > > > > Acee Lindem wrote: > > > > > > Roy, > > > > > > I can appreciate your points since our product supports both multiple > > > virtual router instances and multiple routing protocol instances > > > within a particular virtual router. However, I think we'd > > > essentially have to deprecate everything in the current MIB and define > > > new tables in order to add OSPF instance ID as an index. Can someone > > > who has more MIB definition experience comment? > > > > > > Additionally, the multiple instance problem is not unique to the > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > Roy Jose wrote: > > > > Hi, > > > > > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I would > also like > > > > to have some clarifications. Please see the attached document. > > > > > > > > Thanks, > > > > Roy > > > > > > > > > > > >>Yes. An update is in the works. > > > >> > > > >>-Dan > > > >> > > > >> > > > >>>-----Original Message----- > > > >>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > >>>Subject: OSPFv2 MIB draft > > > >>> > > > >>> > > > >>>Hi all: > > > >>>I would like to know the status of the working group > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an > > > >>>expiry date of > > > >>>May 2001. > > > >>>Is there any plan to update the draft ? > > > >>> > > > >>>Thanks > > > >>>Gargi > > > >>> > > > >> > > > >> > > > > >>------------------------------------------------------------------------ > > > >> > > > >>Support for multiple OSPF processes: > > > >>----------------------------------- > > > >> > > > >>We raised this issue some time back in WG. Currently MIB supports only > one Router ID. > > > >>Multiple processes can have separate router IDs. It is also true with > other MIB objects > > > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we > got was to use a > > > >>separate MIB view for each process. But I don't think it can be easily > implemented. > > > >>We suggest to form a new table to group scalar objects related to an > OSPF process and have > > > >>Process Id as its INDEX. We also suggest to add Process Id as one of > the INDICES of all > > > >>tables. > > > >> > > > >> > > > >>MAX-ACCESS value for INDICES of TABLES: > > > >>-------------------------------------- > > > >>I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES > of a table are > > > >>put as not-accesssible to reduce the number of SNMP messages. When an > SNMP GET or > > > >>GETNEXT is issued on a non-INDEX object, we can extract the values of > INDICES from > > > >>the object ID returned. For example, let us consider ospfAreaLsaCount. > When we query > > > >>the value for this, we get something like ospfAreaLsaCount.0.0.0.1, > where 0.0.0.1 is > > > >>the AreaId, which is the INDEX of the ospfAreaTable. We can extract > the INDICES of > > > >>table like this even if they are not-accessible. The tables like > LsdbTable has many > > > >>number of INDICES and we can reduce the number of SNMP messages > considerably by changing > > > >>them to not-accessible. > > > >> > > > >>If the MAX-ACCESS of INDICES are put as read-only to include them in > the TRAP > > > >>notification messages, they can be changed as accessible-for-notify. > Other approach to > > > >>this is remove the INDICES from TRAP notification messages. For > example if you take the > > > >>case of IfStateChange TRAP, > > > >> > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > >> OBJECTS { ospfRouterId, -- The originator of the trap^M > > > >> ospfIfIpAddress,^M > > > >> ospfAddressLessIf,^M > > > >> ospfIfState -- The new state^M > > > >> }^M > > > >>Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. > When we send TRAP > > > >>notification, we can just send ospfIfState. value>. . > > > >>Also I am not sure why ospfRouterId is included here. An NMS station > can always query ospfRouterId > > > >>separately. By removing these MIB objects, we can reduce the size and > processing time of TRAP > > > >>messages considerably. > > > >> > > > >>Section : 4.3 Ignoring Initial Activity > > > >>--------------------------------------- > > > >>The section states "The majority of critical events occur when OSPF is > enabled on a > > > >>router, at which time the designated router is elected and neighbor > adjacencies are formed" . > > > >>I am not sure if enabling OSPF on a router means enabling it on an > interface. I think it will > > > >>be better to make the text clearer. > > > >> > > > >>Other statement is "To avoid unnecessary traps, a router should not > originate expected OSPF > > > >>interface related traps until two of that interface's dead timer > intervals have elapsed." > > > >>I think there will be some problems if the dead interval value is too > long. We may end up > > > >>not sending any of the expected TRAPS for a long time. Btw, could I > please know the reason > > > >>for selecting 2 * dead interval value for this purpose?. There might > be some case where an > > > >>interface is up and it goes down before (2 * dead interval). We can't > take it as an 'expected > > > >>event'. Probably we can ignore the expected events till the interface > reaches terminal state > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > >> > > > >> > > > >>One more point is we are already limiting ospfIfStateChange, > ospfVirtIfStateChange, > > > >>ospfNbrStateChange and ospfVirtNbrStateChange notifications by > generating them only for terminal > > > >>state changes and backward tansition. Do we really need to ignore them > during the initial activity?. > > > >> > > > >>Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa > traps should not be originated > > > >>until two dead timer intervals have elapsed where the deadtimer > interval used should be the dead > > > >>timer with the smallest value." Here whats the meaning of "dead timer > with smallest value"? Is it > > > >>the smallest interval value among all the interfaces? > > > >> > > > >> > > > >>Section 4.4 Throttling Traps > > > >>---------------------------- > > > >>Do we need to provide MIB objects corresponding to window size and the > number of TRAPs sent during > > > >>the window time? Will the TRAPs other than ospfTxRetransmit, > OrginateLsa and MaxAgeLsa really cause > > > >>a TRAP flood? Probably we need to throttle only the above three TRAPS? > > > >> > > > >>I think the normal practice is to inform the NMS using some other > notification at the end of a > > > >>particular interval when the TRAPs are dropped like this, "Trap N > dropped n times in an interval > > > >>t". We can add some common extra paratmeters to these notifications to > facilitate the NMS to query > > > >>the router to retrieve some values and find out whats happening. > > > >> > > > >>ospfConfigErrorType > > > >>------------------- > > > >>Do we need an error type for duplicate router id in the received > messages? Some times loop back > > > >>address can be misconfigured. > > > >> > > > >>ospfSetTrap > > > >>----------- > > > >>The definition of this is little complicated. Any reasons for going > for last bit to first. We think > > > >>its better to redefine this MIB object like this to make if more > clear. > > > >> > > > >> cospfSetTrap OBJECT-TYPE > > > >> SYNTAX BITS { > > > >> ifConfigError (0), > > > >> virtIfConfigError (1), > > > >> ospfNbrStateChange (2), > > > >> . > > > >> . > > > >> . > > > >> } > > > >> MAX-ACCESS read-write > > > >> STATUS current > > > >> DESCRIPTION > > > >> "A One-octet string serving as a bit map for > > > >> the trap events defined by the OSPF traps in > > > >> this MIB. This object is used to enable and > > > >> disable specific OSPF traps where a 1 > > > >> in the corresponding bit field represents > > > >> enabled." > > > >> ::= { cospfTrapControl 1 } > > > >> > > > >>This definition enables the NMS to interpret the bit map easily. > > > >> > > > >> > > > >>ospfIfStateChange > > > >>----------------- > > > >> > > > >>>From the definition it looks like this TRAP should be generated only > for terminal states(when state > > > >>progresses) and for backward transition. Infact the name > ospfIfStateChange simply suggests to > > > >>generate TRAPs for all state transitions. The general tendency is to > ignore the DESCRIPTION when > > > >>"StateChange" is read and assume its for all the state changes. It > might lead to wrong > > > >>implementations. I think we can also follow the approach taken in BGP > MIB(rfc1657). > > > >>There they have notifications like this, > > > >> bgpEstablished NOTIFICATION-TYPE > > > >> OBJECTS { bgpPeerLastError, > > > >> bgpPeerState } > > > >> STATUS current > > > >> DESCRIPTION > > > >> "The BGP Established event is generated > when > > > >> the BGP FSM enters the ESTABLISHED state." > > > >> ::= { bgpTraps 1 } > > > >> > > > >> bgpBackwardTransition NOTIFICATION-TYPE > > > >> OBJECTS { bgpPeerLastError, > > > >> bgpPeerState } > > > >> STATUS current > > > >> DESCRIPTION > > > >> "The BGPBackwardTransition Event is > generated > > > >> when the BGP FSM moves from a higher > numbered > > > >> state to a lower numbered state." > > > >> ::= { bgpTraps 2 } > > > >> > > > >>Our suggestion is to maintain ospfIfStateChange and use that for > monitoring all the states > > > >>(some people may want that) and additionally have notifications > similar to the BGP notifications. > > > >>Its also true with VirtIfStateChange, NbrStateChange and > VirtNbrStateChange. If somebody doesn't > > > >>want to see ALL state TRAPS, they can suppress them by turning off the > corresponding bit in > > > >>ospfSetTrap. > > > >> > > > >> > > > >>ospfNbrStateChange > > > >>------------------ > > > >>The DECRIPTION clause states > > > >>"When an neighbor transitions from or to Full on non-broadcast > multi-access and broadcast > > > >> networks, the trap should be generated by the designated router. A > designated router > > > >>transitioning to Down will be noted by ospfIfStateChange." > > > >>I think here the intention is to reduce the number of TRAPs as much as > possible by making > > > >>only DR sending out this TRAP for a subnet. But there is a possibility > that osfpNbrStateChange > > > >>notification is disabled on DR and enabled on DR other or BDR. NMS > won't receive TRAPs when > > > >>NbrState becomes FULL in that case. There is a problem with the second > part of above statments > > > >>as well. Suppose ospfIfStateChange is disabled on the router, then > again NMS won't know when > > > >>neighbor goes down. Probably its better to remove these two clauses. > > > >> > > > >> > > > >>Support for sham links: > > > >>----------------------- > > > >>Are you going to provide support for sham links? We may need these > tables and notifications, > > > >>ShamLinkTable > > > >>ShamLinkNbrTable > > > >>ShamLinkStateChange notification > > > >>ShamLinkNbrStateChange notification > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > -- > > > Acee > > > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 17 12:49:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22268 for ; Mon, 17 Mar 2003 12:49:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.009341F3@cherry.ease.lsoft.com>; Mon, 17 Mar 2003 12:51:21 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 697917 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 17 Mar 2003 12:51:21 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Mar 2003 12:51:20 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 03C0A617E04 for ; Mon, 17 Mar 2003 09:51:20 -0800 (PST) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 References: <3eca01c2ea38$82cf0a30$9c8b4d0a@apac.cisco.com> <3E725E33.5040909@redback.com> <3E7278AE.BDA8BE3D@rose.hp.com> <00c001c2ec69$5fb7afb0$9c8b4d0a@apac.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E760C73.15C76D9D@redback.com> Date: Mon, 17 Mar 2003 12:57:07 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Roy, There are 3 reasons why I don't think Sham Links should be included in this MIB udpate: 1. I don't think they are sufficiently specified in the Internet Draft describing them. My experience implementing the Sham Link feature required some reverse engineering (Consult RFC 1264 for specification requirements). 2. The document describing them is not an OSPF WG document. In fact, it is not even an PPVPN document (although it could become one). 3. At some point, we have to close the door on adding MIB variables that are in all the drafts that may or may not ever reach draft standard status. If we don't do this, we'll never finish the MIB update. Thanks, Acee Roy Jose wrote: > > Thanks Jeff, Acee, Mani and John for your responses. How about other > points?:) > > ----- Original Message ----- > From: "John Flick" > To: > Sent: Saturday, March 15, 2003 6:19 AM > Subject: Re: OSPFv2 MIB draft > > > Yep, adding an index would require deprecating everything and starting > over. > > Since this is an existing, widely deployed, Draft Standard MIB, this > should > > not be done lightly. > > > > You would have the same problem if you tried changing MAX-ACCESS on the > > table indices (as was also suggested below). Since a change to MAX-ACCESS > > of an existing object is not allowed, you would need to deprecated the > index > > objects, which would require deprecating the tables that they index. > Changing > > to not-accessible is not required, since SMIv2 allows read-only indices > for > > MIB modules that were translated from SMIv1 and therefore already had > > read-only indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 > MIB > > module, so this exception applies. > > How about tables which were added later?: ospfAreaAggregateTable, > ExtLsdbTable, etc. > My worry is not if its allowed or not. I am trying to point out the extra > processing routers and > NMS have to do with the increased number of messages. > > > As far as finding a generic solution for multiple instances of a MIB > module, > > the standard solution is to use contexts (note: this is not the same as a > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done in a > > somewhat ad-hoc way by using different community names for each instance > > of the OSPF MIB. In SNMPv3, it is more formally defined using the > > contextName. The Entity MIB entLogicalTable (RFC 2737) provides > information > > about what contexts exist in an agent, and how to get to them. > > After having a glance at rfc2737, I also think this is the way. I think we > need to specify it clearly how it can be achieved using entLogicalTable. For > example, how we need to represent the SNMP community string to retrieve info > from a particular routing instance. > > Thanks, > Roy > > > > > John > > > > Acee Lindem wrote: > > > > > > Roy, > > > > > > I can appreciate your points since our product supports both multiple > > > virtual router instances and multiple routing protocol instances > > > within a particular virtual router. However, I think we'd > > > essentially have to deprecate everything in the current MIB and define > > > new tables in order to add OSPF instance ID as an index. Can someone > > > who has more MIB definition experience comment? > > > > > > Additionally, the multiple instance problem is not unique to the > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > Roy Jose wrote: > > > > Hi, > > > > > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I would > also like > > > > to have some clarifications. Please see the attached document. > > > > > > > > Thanks, > > > > Roy > > > > > > > > > > > >>Yes. An update is in the works. > > > >> > > > >>-Dan > > > >> > > > >> > > > >>>-----Original Message----- > > > >>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > >>>Subject: OSPFv2 MIB draft > > > >>> > > > >>> > > > >>>Hi all: > > > >>>I would like to know the status of the working group > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an > > > >>>expiry date of > > > >>>May 2001. > > > >>>Is there any plan to update the draft ? > > > >>> > > > >>>Thanks > > > >>>Gargi > > > >>> > > > >> > > > >> > > > > >>------------------------------------------------------------------------ > > > >> > > > >>Support for multiple OSPF processes: > > > >>----------------------------------- > > > >> > > > >>We raised this issue some time back in WG. Currently MIB supports only > one Router ID. > > > >>Multiple processes can have separate router IDs. It is also true with > other MIB objects > > > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we > got was to use a > > > >>separate MIB view for each process. But I don't think it can be easily > implemented. > > > >>We suggest to form a new table to group scalar objects related to an > OSPF process and have > > > >>Process Id as its INDEX. We also suggest to add Process Id as one of > the INDICES of all > > > >>tables. > > > >> > > > >> > > > >>MAX-ACCESS value for INDICES of TABLES: > > > >>-------------------------------------- > > > >>I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES > of a table are > > > >>put as not-accesssible to reduce the number of SNMP messages. When an > SNMP GET or > > > >>GETNEXT is issued on a non-INDEX object, we can extract the values of > INDICES from > > > >>the object ID returned. For example, let us consider ospfAreaLsaCount. > When we query > > > >>the value for this, we get something like ospfAreaLsaCount.0.0.0.1, > where 0.0.0.1 is > > > >>the AreaId, which is the INDEX of the ospfAreaTable. We can extract > the INDICES of > > > >>table like this even if they are not-accessible. The tables like > LsdbTable has many > > > >>number of INDICES and we can reduce the number of SNMP messages > considerably by changing > > > >>them to not-accessible. > > > >> > > > >>If the MAX-ACCESS of INDICES are put as read-only to include them in > the TRAP > > > >>notification messages, they can be changed as accessible-for-notify. > Other approach to > > > >>this is remove the INDICES from TRAP notification messages. For > example if you take the > > > >>case of IfStateChange TRAP, > > > >> > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > >> OBJECTS { ospfRouterId, -- The originator of the trap^M > > > >> ospfIfIpAddress,^M > > > >> ospfAddressLessIf,^M > > > >> ospfIfState -- The new state^M > > > >> }^M > > > >>Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. > When we send TRAP > > > >>notification, we can just send ospfIfState. value>. . > > > >>Also I am not sure why ospfRouterId is included here. An NMS station > can always query ospfRouterId > > > >>separately. By removing these MIB objects, we can reduce the size and > processing time of TRAP > > > >>messages considerably. > > > >> > > > >>Section : 4.3 Ignoring Initial Activity > > > >>--------------------------------------- > > > >>The section states "The majority of critical events occur when OSPF is > enabled on a > > > >>router, at which time the designated router is elected and neighbor > adjacencies are formed" . > > > >>I am not sure if enabling OSPF on a router means enabling it on an > interface. I think it will > > > >>be better to make the text clearer. > > > >> > > > >>Other statement is "To avoid unnecessary traps, a router should not > originate expected OSPF > > > >>interface related traps until two of that interface's dead timer > intervals have elapsed." > > > >>I think there will be some problems if the dead interval value is too > long. We may end up > > > >>not sending any of the expected TRAPS for a long time. Btw, could I > please know the reason > > > >>for selecting 2 * dead interval value for this purpose?. There might > be some case where an > > > >>interface is up and it goes down before (2 * dead interval). We can't > take it as an 'expected > > > >>event'. Probably we can ignore the expected events till the interface > reaches terminal state > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > >> > > > >> > > > >>One more point is we are already limiting ospfIfStateChange, > ospfVirtIfStateChange, > > > >>ospfNbrStateChange and ospfVirtNbrStateChange notifications by > generating them only for terminal > > > >>state changes and backward tansition. Do we really need to ignore them > during the initial activity?. > > > >> > > > >>Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa > traps should not be originated > > > >>until two dead timer intervals have elapsed where the deadtimer > interval used should be the dead > > > >>timer with the smallest value." Here whats the meaning of "dead timer > with smallest value"? Is it > > > >>the smallest interval value among all the interfaces? > > > >> > > > >> > > > >>Section 4.4 Throttling Traps > > > >>---------------------------- > > > >>Do we need to provide MIB objects corresponding to window size and the > number of TRAPs sent during > > > >>the window time? Will the TRAPs other than ospfTxRetransmit, > OrginateLsa and MaxAgeLsa really cause > > > >>a TRAP flood? Probably we need to throttle only the above three TRAPS? > > > >> > > > >>I think the normal practice is to inform the NMS using some other > notification at the end of a > > > >>particular interval when the TRAPs are dropped like this, "Trap N > dropped n times in an interval > > > >>t". We can add some common extra paratmeters to these notifications to > facilitate the NMS to query > > > >>the router to retrieve some values and find out whats happening. > > > >> > > > >>ospfConfigErrorType > > > >>------------------- > > > >>Do we need an error type for duplicate router id in the received > messages? Some times loop back > > > >>address can be misconfigured. > > > >> > > > >>ospfSetTrap > > > >>----------- > > > >>The definition of this is little complicated. Any reasons for going > for last bit to first. We think > > > >>its better to redefine this MIB object like this to make if more > clear. > > > >> > > > >> cospfSetTrap OBJECT-TYPE > > > >> SYNTAX BITS { > > > >> ifConfigError (0), > > > >> virtIfConfigError (1), > > > >> ospfNbrStateChange (2), > > > >> . > > > >> . > > > >> . > > > >> } > > > >> MAX-ACCESS read-write > > > >> STATUS current > > > >> DESCRIPTION > > > >> "A One-octet string serving as a bit map for > > > >> the trap events defined by the OSPF traps in > > > >> this MIB. This object is used to enable and > > > >> disable specific OSPF traps where a 1 > > > >> in the corresponding bit field represents > > > >> enabled." > > > >> ::= { cospfTrapControl 1 } > > > >> > > > >>This definition enables the NMS to interpret the bit map easily. > > > >> > > > >> > > > >>ospfIfStateChange > > > >>----------------- > > > >> > > > >>>From the definition it looks like this TRAP should be generated only > for terminal states(when state > > > >>progresses) and for backward transition. Infact the name > ospfIfStateChange simply suggests to > > > >>generate TRAPs for all state transitions. The general tendency is to > ignore the DESCRIPTION when > > > >>"StateChange" is read and assume its for all the state changes. It > might lead to wrong > > > >>implementations. I think we can also follow the approach taken in BGP > MIB(rfc1657). > > > >>There they have notifications like this, > > > >> bgpEstablished NOTIFICATION-TYPE > > > >> OBJECTS { bgpPeerLastError, > > > >> bgpPeerState } > > > >> STATUS current > > > >> DESCRIPTION > > > >> "The BGP Established event is generated > when > > > >> the BGP FSM enters the ESTABLISHED state." > > > >> ::= { bgpTraps 1 } > > > >> > > > >> bgpBackwardTransition NOTIFICATION-TYPE > > > >> OBJECTS { bgpPeerLastError, > > > >> bgpPeerState } > > > >> STATUS current > > > >> DESCRIPTION > > > >> "The BGPBackwardTransition Event is > generated > > > >> when the BGP FSM moves from a higher > numbered > > > >> state to a lower numbered state." > > > >> ::= { bgpTraps 2 } > > > >> > > > >>Our suggestion is to maintain ospfIfStateChange and use that for > monitoring all the states > > > >>(some people may want that) and additionally have notifications > similar to the BGP notifications. > > > >>Its also true with VirtIfStateChange, NbrStateChange and > VirtNbrStateChange. If somebody doesn't > > > >>want to see ALL state TRAPS, they can suppress them by turning off the > corresponding bit in > > > >>ospfSetTrap. > > > >> > > > >> > > > >>ospfNbrStateChange > > > >>------------------ > > > >>The DECRIPTION clause states > > > >>"When an neighbor transitions from or to Full on non-broadcast > multi-access and broadcast > > > >> networks, the trap should be generated by the designated router. A > designated router > > > >>transitioning to Down will be noted by ospfIfStateChange." > > > >>I think here the intention is to reduce the number of TRAPs as much as > possible by making > > > >>only DR sending out this TRAP for a subnet. But there is a possibility > that osfpNbrStateChange > > > >>notification is disabled on DR and enabled on DR other or BDR. NMS > won't receive TRAPs when > > > >>NbrState becomes FULL in that case. There is a problem with the second > part of above statments > > > >>as well. Suppose ospfIfStateChange is disabled on the router, then > again NMS won't know when > > > >>neighbor goes down. Probably its better to remove these two clauses. > > > >> > > > >> > > > >>Support for sham links: > > > >>----------------------- > > > >>Are you going to provide support for sham links? We may need these > tables and notifications, > > > >>ShamLinkTable > > > >>ShamLinkNbrTable > > > >>ShamLinkStateChange notification > > > >>ShamLinkNbrStateChange notification > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > -- > > > Acee > > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 17 12:58:27 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22834 for ; Mon, 17 Mar 2003 12:58:26 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0093420F@cherry.ease.lsoft.com>; Mon, 17 Mar 2003 13:00:38 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 697940 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 17 Mar 2003 13:00:38 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Mar 2003 13:00:38 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 77B40617E0E for ; Mon, 17 Mar 2003 10:00:37 -0800 (PST) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 References: <3eca01c2ea38$82cf0a30$9c8b4d0a@apac.cisco.com> <3E725E33.5040909@redback.com> <3E7278AE.BDA8BE3D@rose.hp.com> <00c001c2ec69$5fb7afb0$9c8b4d0a@apac.cisco.com> <3E760C73.15C76D9D@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E760EA0.5C769970@redback.com> Date: Mon, 17 Mar 2003 13:06:24 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit One small correction. Acee Lindem wrote: > > Roy, > > There are 3 reasons why I don't think Sham Links should > be included in this MIB udpate: > > 1. I don't think they are sufficiently specified in the > Internet Draft describing them. My experience implementing > the Sham Link feature required some reverse > engineering (Consult RFC 1264 for specification > requirements). > 2. The document describing them is not an OSPF WG > document. In fact, it is not even an PPVPN > document (although it could become one). > 3. At some point, we have to close the door on adding > MIB variables that are in all the drafts that may or > may not ever reach draft standard status. If we don't ~~~~~~~~~~~~~~ Meant to say "proposed standard" here. > do this, we'll never finish the MIB update. > > Thanks, > Acee > > Roy Jose wrote: > > > > Thanks Jeff, Acee, Mani and John for your responses. How about other > > points?:) > > > > ----- Original Message ----- > > From: "John Flick" > > To: > > Sent: Saturday, March 15, 2003 6:19 AM > > Subject: Re: OSPFv2 MIB draft > > > > > Yep, adding an index would require deprecating everything and starting > > over. > > > Since this is an existing, widely deployed, Draft Standard MIB, this > > should > > > not be done lightly. > > > > > > You would have the same problem if you tried changing MAX-ACCESS on the > > > table indices (as was also suggested below). Since a change to MAX-ACCESS > > > of an existing object is not allowed, you would need to deprecated the > > index > > > objects, which would require deprecating the tables that they index. > > Changing > > > to not-accessible is not required, since SMIv2 allows read-only indices > > for > > > MIB modules that were translated from SMIv1 and therefore already had > > > read-only indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 > > MIB > > > module, so this exception applies. > > > > How about tables which were added later?: ospfAreaAggregateTable, > > ExtLsdbTable, etc. > > My worry is not if its allowed or not. I am trying to point out the extra > > processing routers and > > NMS have to do with the increased number of messages. > > > > > As far as finding a generic solution for multiple instances of a MIB > > module, > > > the standard solution is to use contexts (note: this is not the same as a > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done in a > > > somewhat ad-hoc way by using different community names for each instance > > > of the OSPF MIB. In SNMPv3, it is more formally defined using the > > > contextName. The Entity MIB entLogicalTable (RFC 2737) provides > > information > > > about what contexts exist in an agent, and how to get to them. > > > > After having a glance at rfc2737, I also think this is the way. I think we > > need to specify it clearly how it can be achieved using entLogicalTable. For > > example, how we need to represent the SNMP community string to retrieve info > > from a particular routing instance. > > > > Thanks, > > Roy > > > > > > > > John > > > > > > Acee Lindem wrote: > > > > > > > > Roy, > > > > > > > > I can appreciate your points since our product supports both multiple > > > > virtual router instances and multiple routing protocol instances > > > > within a particular virtual router. However, I think we'd > > > > essentially have to deprecate everything in the current MIB and define > > > > new tables in order to add OSPF instance ID as an index. Can someone > > > > who has more MIB definition experience comment? > > > > > > > > Additionally, the multiple instance problem is not unique to the > > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > > > Roy Jose wrote: > > > > > Hi, > > > > > > > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I would > > also like > > > > > to have some clarifications. Please see the attached document. > > > > > > > > > > Thanks, > > > > > Roy > > > > > > > > > > > > > > >>Yes. An update is in the works. > > > > >> > > > > >>-Dan > > > > >> > > > > >> > > > > >>>-----Original Message----- > > > > >>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > > >>>Subject: OSPFv2 MIB draft > > > > >>> > > > > >>> > > > > >>>Hi all: > > > > >>>I would like to know the status of the working group > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an > > > > >>>expiry date of > > > > >>>May 2001. > > > > >>>Is there any plan to update the draft ? > > > > >>> > > > > >>>Thanks > > > > >>>Gargi > > > > >>> > > > > >> > > > > >> > > > > > > >>------------------------------------------------------------------------ > > > > >> > > > > >>Support for multiple OSPF processes: > > > > >>----------------------------------- > > > > >> > > > > >>We raised this issue some time back in WG. Currently MIB supports only > > one Router ID. > > > > >>Multiple processes can have separate router IDs. It is also true with > > other MIB objects > > > > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we > > got was to use a > > > > >>separate MIB view for each process. But I don't think it can be easily > > implemented. > > > > >>We suggest to form a new table to group scalar objects related to an > > OSPF process and have > > > > >>Process Id as its INDEX. We also suggest to add Process Id as one of > > the INDICES of all > > > > >>tables. > > > > >> > > > > >> > > > > >>MAX-ACCESS value for INDICES of TABLES: > > > > >>-------------------------------------- > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES > > of a table are > > > > >>put as not-accesssible to reduce the number of SNMP messages. When an > > SNMP GET or > > > > >>GETNEXT is issued on a non-INDEX object, we can extract the values of > > INDICES from > > > > >>the object ID returned. For example, let us consider ospfAreaLsaCount. > > When we query > > > > >>the value for this, we get something like ospfAreaLsaCount.0.0.0.1, > > where 0.0.0.1 is > > > > >>the AreaId, which is the INDEX of the ospfAreaTable. We can extract > > the INDICES of > > > > >>table like this even if they are not-accessible. The tables like > > LsdbTable has many > > > > >>number of INDICES and we can reduce the number of SNMP messages > > considerably by changing > > > > >>them to not-accessible. > > > > >> > > > > >>If the MAX-ACCESS of INDICES are put as read-only to include them in > > the TRAP > > > > >>notification messages, they can be changed as accessible-for-notify. > > Other approach to > > > > >>this is remove the INDICES from TRAP notification messages. For > > example if you take the > > > > >>case of IfStateChange TRAP, > > > > >> > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > > >> OBJECTS { ospfRouterId, -- The originator of the trap^M > > > > >> ospfIfIpAddress,^M > > > > >> ospfAddressLessIf,^M > > > > >> ospfIfState -- The new state^M > > > > >> }^M > > > > >>Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. > > When we send TRAP > > > > >>notification, we can just send ospfIfState. > value>. . > > > > >>Also I am not sure why ospfRouterId is included here. An NMS station > > can always query ospfRouterId > > > > >>separately. By removing these MIB objects, we can reduce the size and > > processing time of TRAP > > > > >>messages considerably. > > > > >> > > > > >>Section : 4.3 Ignoring Initial Activity > > > > >>--------------------------------------- > > > > >>The section states "The majority of critical events occur when OSPF is > > enabled on a > > > > >>router, at which time the designated router is elected and neighbor > > adjacencies are formed" . > > > > >>I am not sure if enabling OSPF on a router means enabling it on an > > interface. I think it will > > > > >>be better to make the text clearer. > > > > >> > > > > >>Other statement is "To avoid unnecessary traps, a router should not > > originate expected OSPF > > > > >>interface related traps until two of that interface's dead timer > > intervals have elapsed." > > > > >>I think there will be some problems if the dead interval value is too > > long. We may end up > > > > >>not sending any of the expected TRAPS for a long time. Btw, could I > > please know the reason > > > > >>for selecting 2 * dead interval value for this purpose?. There might > > be some case where an > > > > >>interface is up and it goes down before (2 * dead interval). We can't > > take it as an 'expected > > > > >>event'. Probably we can ignore the expected events till the interface > > reaches terminal state > > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > > >> > > > > >> > > > > >>One more point is we are already limiting ospfIfStateChange, > > ospfVirtIfStateChange, > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange notifications by > > generating them only for terminal > > > > >>state changes and backward tansition. Do we really need to ignore them > > during the initial activity?. > > > > >> > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa > > traps should not be originated > > > > >>until two dead timer intervals have elapsed where the deadtimer > > interval used should be the dead > > > > >>timer with the smallest value." Here whats the meaning of "dead timer > > with smallest value"? Is it > > > > >>the smallest interval value among all the interfaces? > > > > >> > > > > >> > > > > >>Section 4.4 Throttling Traps > > > > >>---------------------------- > > > > >>Do we need to provide MIB objects corresponding to window size and the > > number of TRAPs sent during > > > > >>the window time? Will the TRAPs other than ospfTxRetransmit, > > OrginateLsa and MaxAgeLsa really cause > > > > >>a TRAP flood? Probably we need to throttle only the above three TRAPS? > > > > >> > > > > >>I think the normal practice is to inform the NMS using some other > > notification at the end of a > > > > >>particular interval when the TRAPs are dropped like this, "Trap N > > dropped n times in an interval > > > > >>t". We can add some common extra paratmeters to these notifications to > > facilitate the NMS to query > > > > >>the router to retrieve some values and find out whats happening. > > > > >> > > > > >>ospfConfigErrorType > > > > >>------------------- > > > > >>Do we need an error type for duplicate router id in the received > > messages? Some times loop back > > > > >>address can be misconfigured. > > > > >> > > > > >>ospfSetTrap > > > > >>----------- > > > > >>The definition of this is little complicated. Any reasons for going > > for last bit to first. We think > > > > >>its better to redefine this MIB object like this to make if more > > clear. > > > > >> > > > > >> cospfSetTrap OBJECT-TYPE > > > > >> SYNTAX BITS { > > > > >> ifConfigError (0), > > > > >> virtIfConfigError (1), > > > > >> ospfNbrStateChange (2), > > > > >> . > > > > >> . > > > > >> . > > > > >> } > > > > >> MAX-ACCESS read-write > > > > >> STATUS current > > > > >> DESCRIPTION > > > > >> "A One-octet string serving as a bit map for > > > > >> the trap events defined by the OSPF traps in > > > > >> this MIB. This object is used to enable and > > > > >> disable specific OSPF traps where a 1 > > > > >> in the corresponding bit field represents > > > > >> enabled." > > > > >> ::= { cospfTrapControl 1 } > > > > >> > > > > >>This definition enables the NMS to interpret the bit map easily. > > > > >> > > > > >> > > > > >>ospfIfStateChange > > > > >>----------------- > > > > >> > > > > >>>From the definition it looks like this TRAP should be generated only > > for terminal states(when state > > > > >>progresses) and for backward transition. Infact the name > > ospfIfStateChange simply suggests to > > > > >>generate TRAPs for all state transitions. The general tendency is to > > ignore the DESCRIPTION when > > > > >>"StateChange" is read and assume its for all the state changes. It > > might lead to wrong > > > > >>implementations. I think we can also follow the approach taken in BGP > > MIB(rfc1657). > > > > >>There they have notifications like this, > > > > >> bgpEstablished NOTIFICATION-TYPE > > > > >> OBJECTS { bgpPeerLastError, > > > > >> bgpPeerState } > > > > >> STATUS current > > > > >> DESCRIPTION > > > > >> "The BGP Established event is generated > > when > > > > >> the BGP FSM enters the ESTABLISHED state." > > > > >> ::= { bgpTraps 1 } > > > > >> > > > > >> bgpBackwardTransition NOTIFICATION-TYPE > > > > >> OBJECTS { bgpPeerLastError, > > > > >> bgpPeerState } > > > > >> STATUS current > > > > >> DESCRIPTION > > > > >> "The BGPBackwardTransition Event is > > generated > > > > >> when the BGP FSM moves from a higher > > numbered > > > > >> state to a lower numbered state." > > > > >> ::= { bgpTraps 2 } > > > > >> > > > > >>Our suggestion is to maintain ospfIfStateChange and use that for > > monitoring all the states > > > > >>(some people may want that) and additionally have notifications > > similar to the BGP notifications. > > > > >>Its also true with VirtIfStateChange, NbrStateChange and > > VirtNbrStateChange. If somebody doesn't > > > > >>want to see ALL state TRAPS, they can suppress them by turning off the > > corresponding bit in > > > > >>ospfSetTrap. > > > > >> > > > > >> > > > > >>ospfNbrStateChange > > > > >>------------------ > > > > >>The DECRIPTION clause states > > > > >>"When an neighbor transitions from or to Full on non-broadcast > > multi-access and broadcast > > > > >> networks, the trap should be generated by the designated router. A > > designated router > > > > >>transitioning to Down will be noted by ospfIfStateChange." > > > > >>I think here the intention is to reduce the number of TRAPs as much as > > possible by making > > > > >>only DR sending out this TRAP for a subnet. But there is a possibility > > that osfpNbrStateChange > > > > >>notification is disabled on DR and enabled on DR other or BDR. NMS > > won't receive TRAPs when > > > > >>NbrState becomes FULL in that case. There is a problem with the second > > part of above statments > > > > >>as well. Suppose ospfIfStateChange is disabled on the router, then > > again NMS won't know when > > > > >>neighbor goes down. Probably its better to remove these two clauses. > > > > >> > > > > >> > > > > >>Support for sham links: > > > > >>----------------------- > > > > >>Are you going to provide support for sham links? We may need these > > tables and notifications, > > > > >>ShamLinkTable > > > > >>ShamLinkNbrTable > > > > >>ShamLinkStateChange notification > > > > >>ShamLinkNbrStateChange notification > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > > > > > > > > > -- > > > > Acee > > > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 17 16:10:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01365 for ; Mon, 17 Mar 2003 16:10:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00934714@cherry.ease.lsoft.com>; Mon, 17 Mar 2003 16:12:22 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 698342 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 17 Mar 2003 16:12:22 -0500 Received: from 216.136.173.13 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Mar 2003 16:02:21 -0500 Received: from [65.213.102.2] by web13509.mail.yahoo.com via HTTP; Mon, 17 Mar 2003 13:02:18 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030317210218.38105.qmail@web13509.mail.yahoo.com> Date: Mon, 17 Mar 2003 13:02:18 -0800 Reply-To: Mailing List Sender: Mailing List From: kajol pattnaik Subject: IGP/OSPF fast reroute. To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E760EA0.5C769970@redback.com> Precedence: list Hello, Are there any IETF standard/document for IGP/OSPF fast reroute as has been presented by alex zinin and chenigz in their presentation :"IGP Fast Reroute" , slides can be found at http://www.packetdesign.com/news/presentations.html This seems to be a good alternative to IGP fast convergence, to achive sub-second re-routing wit IGPs, by generating a two(or a fixed number of) best routes rather than one best route. If there are any IETF standards on this or, any work in progress in IETF, please point me to the documents. or, is this completely implementation specific. Are there any vendor /academic implementation that supports IGP/OSPF fast rerouting as presented above?? thanks, kajol. __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 17 16:13:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01480 for ; Mon, 17 Mar 2003 16:13:07 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0093480D@cherry.ease.lsoft.com>; Mon, 17 Mar 2003 16:15:20 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 698351 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 17 Mar 2003 16:15:20 -0500 Received: from 216.136.175.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Mar 2003 16:05:20 -0500 Received: from [65.213.102.2] by web13501.mail.yahoo.com via HTTP; Mon, 17 Mar 2003 13:05:20 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030317210520.31793.qmail@web13501.mail.yahoo.com> Date: Mon, 17 Mar 2003 13:05:20 -0800 Reply-To: Mailing List Sender: Mailing List From: kajol pattnaik Subject: IGP fast reroute To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hello, Are there any IETF standard/document for IGP/OSPF fast reroute as has been presented by alex zinin and chenigz in their presentation :"IGP Fast Reroute" , slides can be found at http://www.packetdesign.com/news/presentations.html This seems to be a good alternative to IGP fast convergence, to achive sub-second re-routing wit IGPs, by generating a two(or a fixed number of) best routes rather than one best route. If there are any IETF standards on this or, any work in progress in IETF, please point me to the documents. or, is this completely implementation specific. Are there any vendor /academic implementation that supports IGP/OSPF fast rerouting as presented above?? thanks, kajol. __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 17 16:19:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01757 for ; Mon, 17 Mar 2003 16:19:41 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00934719@cherry.ease.lsoft.com>; Mon, 17 Mar 2003 16:21:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 698362 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 17 Mar 2003 16:21:52 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Mar 2003 16:11:52 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0093476A@cherry.ease.lsoft.com>; Mon, 17 Mar 2003 16:11:53 -0500 Message-ID: Date: Mon, 17 Mar 2003 16:11:52 -0500 Reply-To: Mailing List Sender: Mailing List From: Kajol Pattnaik Subject: IGP fast reroute To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hello, Are there any IETF standard/document for IGP/OSPF fast reroute as has been presented by alex zinin and chenigz in their presentation :"IGP Fast Reroute" , slides can be found at http://www.packetdesign.com/news/presentations.html This seems to be a good alternative to IGP fast convergence, to achive sub-second re-routing wit IGPs, by generating a two(or a fixed number of) best routes rather than one best route. If there are any IETF standards on this or, any work in progress in IETF, please point me to the documents. or, is this completely implementation specific. Are there any vendor /academic implementation that supports IGP/OSPF fast rerouting as presented above?? thanks, kajol. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 17 16:35:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02793 for ; Mon, 17 Mar 2003 16:35:43 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009346B2@cherry.ease.lsoft.com>; Mon, 17 Mar 2003 16:37:54 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 698437 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 17 Mar 2003 16:37:53 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Mar 2003 16:37:52 -0500 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2HLbpS63482 for ; Mon, 17 Mar 2003 13:37:51 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h2HLbpW21362 for ; Mon, 17 Mar 2003 13:37:51 -0800 (PST) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs References: <20030312101401.B95881@kummer.juniper.net> <200303121911.OAA14095@bigbird.xebeo.com> <200303122007.h2CK79L38929@fuinar.juniper.net> <3E6FA932.4060606@redback.com> <8765qisiwu.wl@ipinfusion.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20030317132803.P21297@kummer.juniper.net> Date: Mon, 17 Mar 2003 13:37:51 -0800 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <8765qisiwu.wl@ipinfusion.com> Precedence: list On Sun, 16 Mar 2003, Kunihiro Ishiguro wrote: > Agreed. > > >I also feel that whether or not OSPFv3 will eventually be used > >for carrying IPv4 prefixes is a completely independent issue > >(othrogonal in IETF-speak ;^). > > Yes. It is independent issue. But when we support it, we will define > new LS type. If we carry IPv4 prefix in OSPFv3 with OSPFv2 Opaque LSA > format....that will be nightmare... It was never the idea to carry IPv4 prefixes with the v2 Opaque LSA format. Let me summarize the issues: 1) do we want to draw a line in the sand and state that OSPFv3 is a *different* protocol from OSPFv2? The alternative viewpoint is as far as specs go, v3 cleans up some aspects of v2 that weren't done optimally; as far as code goes, v3 implementations can share a lot of code with v2. 2) if the answer to the above is that v3 is a refinement of v2, then the question is, how much can we borrow from v2 (such as carrying IPv4 prefixes and Opaque LSAs in v3 pretty much the same way that they are carried in v2)? Kireeti. From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@DISCUSS.MICROSOFT.COM Mon Mar 17 23:01:18 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16047 for ; Mon, 17 Mar 2003 23:01:18 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00935378@cherry.ease.lsoft.com>; Mon, 17 Mar 2003 23:03:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 699169 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 17 Mar 2003 23:03:25 -0500 Received: from 129.188.136.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 17 Mar 2003 23:03:25 -0500 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2I43PK6017091 for ; Mon, 17 Mar 2003 21:03:25 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id VAA01457 for ; Mon, 17 Mar 2003 21:03:25 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Mar 2003 23:03:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 17 Mar 2003 23:05:09 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: IGP fast reroute To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Kajol, There is a document http://www.ietf.org/internet-drafts/draft-kini-traf-restore-nsp-00.txt that talks about non-shortest-path, which may be relevent to the discussion. Besides the IS-IS base document, ISO-10589 talks about "downstream path". A router calculates path to a destination from a neighbor(the LSDB in all routers is the same), and any path to the destination that has a lesser cost than from the calculating router itself is a downstream path.(if I remember it right). The idea is to find non-looping alternate paths. Thanks, Vishwas -----Original Message----- From: kajol pattnaik [mailto:kajol_patt@YAHOO.COM] Sent: Tuesday, March 18, 2003 2:35 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: IGP fast reroute Hello, Are there any IETF standard/document for IGP/OSPF fast reroute as has been presented by alex zinin and chenigz in their presentation :"IGP Fast Reroute" , slides can be found at http://www.packetdesign.com/news/presentations.html This seems to be a good alternative to IGP fast convergence, to achive sub-second re-routing wit IGPs, by generating a two(or a fixed number of) best routes rather than one best route. If there are any IETF standards on this or, any work in progress in IETF, please point me to the documents. or, is this completely implementation specific. Are there any vendor /academic implementation that supports IGP/OSPF fast rerouting as presented above?? thanks, kajol. __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 18 01:31:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20411 for ; Tue, 18 Mar 2003 01:31:04 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00935BA8@cherry.ease.lsoft.com>; Tue, 18 Mar 2003 1:33:16 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 699589 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 18 Mar 2003 01:33:15 -0500 Received: from 171.71.177.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Mar 2003 01:33:15 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2I6XBhs027463 for ; Mon, 17 Mar 2003 22:33:13 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id MAA15354 for ; Tue, 18 Mar 2003 12:01:49 +0530 (IST) References: <3eca01c2ea38$82cf0a30$9c8b4d0a@apac.cisco.com> <3E725E33.5040909@redback.com> <3E7278AE.BDA8BE3D@rose.hp.com> <00c001c2ec69$5fb7afb0$9c8b4d0a@apac.cisco.com> <3E760C73.15C76D9D@redback.com> <3E760EA0.5C769970@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <04ac01c2ed18$3ee3cdf0$9c8b4d0a@apac.cisco.com> Date: Tue, 18 Mar 2003 12:03:10 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Acee, I agree with you. Till it becomes a standard draft, vendors have to go with some proprietory MIB I guess. Btw, who is working on the MIB update currently? Thanks, Roy > One small correction. > > Acee Lindem wrote: > > > > Roy, > > > > There are 3 reasons why I don't think Sham Links should > > be included in this MIB udpate: > > > > 1. I don't think they are sufficiently specified in the > > Internet Draft describing them. My experience implementing > > the Sham Link feature required some reverse > > engineering (Consult RFC 1264 for specification > > requirements). > > 2. The document describing them is not an OSPF WG > > document. In fact, it is not even an PPVPN > > document (although it could become one). > > 3. At some point, we have to close the door on adding > > MIB variables that are in all the drafts that may or > > may not ever reach draft standard status. If we don't > ~~~~~~~~~~~~~~ > Meant to say "proposed standard" here. > > > do this, we'll never finish the MIB update. > > > > Thanks, > > Acee > > > > Roy Jose wrote: > > > > > > Thanks Jeff, Acee, Mani and John for your responses. How about other > > > points?:) > > > > > > ----- Original Message ----- > > > From: "John Flick" > > > To: > > > Sent: Saturday, March 15, 2003 6:19 AM > > > Subject: Re: OSPFv2 MIB draft > > > > > > > Yep, adding an index would require deprecating everything and starting > > > over. > > > > Since this is an existing, widely deployed, Draft Standard MIB, this > > > should > > > > not be done lightly. > > > > > > > > You would have the same problem if you tried changing MAX-ACCESS on the > > > > table indices (as was also suggested below). Since a change to MAX-ACCESS > > > > of an existing object is not allowed, you would need to deprecated the > > > index > > > > objects, which would require deprecating the tables that they index. > > > Changing > > > > to not-accessible is not required, since SMIv2 allows read-only indices > > > for > > > > MIB modules that were translated from SMIv1 and therefore already had > > > > read-only indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 > > > MIB > > > > module, so this exception applies. > > > > > > How about tables which were added later?: ospfAreaAggregateTable, > > > ExtLsdbTable, etc. > > > My worry is not if its allowed or not. I am trying to point out the extra > > > processing routers and > > > NMS have to do with the increased number of messages. > > > > > > > As far as finding a generic solution for multiple instances of a MIB > > > module, > > > > the standard solution is to use contexts (note: this is not the same as a > > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done in a > > > > somewhat ad-hoc way by using different community names for each instance > > > > of the OSPF MIB. In SNMPv3, it is more formally defined using the > > > > contextName. The Entity MIB entLogicalTable (RFC 2737) provides > > > information > > > > about what contexts exist in an agent, and how to get to them. > > > > > > After having a glance at rfc2737, I also think this is the way. I think we > > > need to specify it clearly how it can be achieved using entLogicalTable. For > > > example, how we need to represent the SNMP community string to retrieve info > > > from a particular routing instance. > > > > > > Thanks, > > > Roy > > > > > > > > > > > John > > > > > > > > Acee Lindem wrote: > > > > > > > > > > Roy, > > > > > > > > > > I can appreciate your points since our product supports both multiple > > > > > virtual router instances and multiple routing protocol instances > > > > > within a particular virtual router. However, I think we'd > > > > > essentially have to deprecate everything in the current MIB and define > > > > > new tables in order to add OSPF instance ID as an index. Can someone > > > > > who has more MIB definition experience comment? > > > > > > > > > > Additionally, the multiple instance problem is not unique to the > > > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > > > > > Roy Jose wrote: > > > > > > Hi, > > > > > > > > > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I would > > > also like > > > > > > to have some clarifications. Please see the attached document. > > > > > > > > > > > > Thanks, > > > > > > Roy > > > > > > > > > > > > > > > > > >>Yes. An update is in the works. > > > > > >> > > > > > >>-Dan > > > > > >> > > > > > >> > > > > > >>>-----Original Message----- > > > > > >>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > > > >>>Subject: OSPFv2 MIB draft > > > > > >>> > > > > > >>> > > > > > >>>Hi all: > > > > > >>>I would like to know the status of the working group > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an > > > > > >>>expiry date of > > > > > >>>May 2001. > > > > > >>>Is there any plan to update the draft ? > > > > > >>> > > > > > >>>Thanks > > > > > >>>Gargi > > > > > >>> > > > > > >> > > > > > >> > > > > > > > > >>------------------------------------------------------------------------ > > > > > >> > > > > > >>Support for multiple OSPF processes: > > > > > >>----------------------------------- > > > > > >> > > > > > >>We raised this issue some time back in WG. Currently MIB supports only > > > one Router ID. > > > > > >>Multiple processes can have separate router IDs. It is also true with > > > other MIB objects > > > > > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we > > > got was to use a > > > > > >>separate MIB view for each process. But I don't think it can be easily > > > implemented. > > > > > >>We suggest to form a new table to group scalar objects related to an > > > OSPF process and have > > > > > >>Process Id as its INDEX. We also suggest to add Process Id as one of > > > the INDICES of all > > > > > >>tables. > > > > > >> > > > > > >> > > > > > >>MAX-ACCESS value for INDICES of TABLES: > > > > > >>-------------------------------------- > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES > > > of a table are > > > > > >>put as not-accesssible to reduce the number of SNMP messages. When an > > > SNMP GET or > > > > > >>GETNEXT is issued on a non-INDEX object, we can extract the values of > > > INDICES from > > > > > >>the object ID returned. For example, let us consider ospfAreaLsaCount. > > > When we query > > > > > >>the value for this, we get something like ospfAreaLsaCount.0.0.0.1, > > > where 0.0.0.1 is > > > > > >>the AreaId, which is the INDEX of the ospfAreaTable. We can extract > > > the INDICES of > > > > > >>table like this even if they are not-accessible. The tables like > > > LsdbTable has many > > > > > >>number of INDICES and we can reduce the number of SNMP messages > > > considerably by changing > > > > > >>them to not-accessible. > > > > > >> > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to include them in > > > the TRAP > > > > > >>notification messages, they can be changed as accessible-for-notify. > > > Other approach to > > > > > >>this is remove the INDICES from TRAP notification messages. For > > > example if you take the > > > > > >>case of IfStateChange TRAP, > > > > > >> > > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > > > >> OBJECTS { ospfRouterId, -- The originator of the trap^M > > > > > >> ospfIfIpAddress,^M > > > > > >> ospfAddressLessIf,^M > > > > > >> ospfIfState -- The new state^M > > > > > >> }^M > > > > > >>Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. > > > When we send TRAP > > > > > >>notification, we can just send ospfIfState. > > value>. . > > > > > >>Also I am not sure why ospfRouterId is included here. An NMS station > > > can always query ospfRouterId > > > > > >>separately. By removing these MIB objects, we can reduce the size and > > > processing time of TRAP > > > > > >>messages considerably. > > > > > >> > > > > > >>Section : 4.3 Ignoring Initial Activity > > > > > >>--------------------------------------- > > > > > >>The section states "The majority of critical events occur when OSPF is > > > enabled on a > > > > > >>router, at which time the designated router is elected and neighbor > > > adjacencies are formed" . > > > > > >>I am not sure if enabling OSPF on a router means enabling it on an > > > interface. I think it will > > > > > >>be better to make the text clearer. > > > > > >> > > > > > >>Other statement is "To avoid unnecessary traps, a router should not > > > originate expected OSPF > > > > > >>interface related traps until two of that interface's dead timer > > > intervals have elapsed." > > > > > >>I think there will be some problems if the dead interval value is too > > > long. We may end up > > > > > >>not sending any of the expected TRAPS for a long time. Btw, could I > > > please know the reason > > > > > >>for selecting 2 * dead interval value for this purpose?. There might > > > be some case where an > > > > > >>interface is up and it goes down before (2 * dead interval). We can't > > > take it as an 'expected > > > > > >>event'. Probably we can ignore the expected events till the interface > > > reaches terminal state > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > > > >> > > > > > >> > > > > > >>One more point is we are already limiting ospfIfStateChange, > > > ospfVirtIfStateChange, > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange notifications by > > > generating them only for terminal > > > > > >>state changes and backward tansition. Do we really need to ignore them > > > during the initial activity?. > > > > > >> > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa > > > traps should not be originated > > > > > >>until two dead timer intervals have elapsed where the deadtimer > > > interval used should be the dead > > > > > >>timer with the smallest value." Here whats the meaning of "dead timer > > > with smallest value"? Is it > > > > > >>the smallest interval value among all the interfaces? > > > > > >> > > > > > >> > > > > > >>Section 4.4 Throttling Traps > > > > > >>---------------------------- > > > > > >>Do we need to provide MIB objects corresponding to window size and the > > > number of TRAPs sent during > > > > > >>the window time? Will the TRAPs other than ospfTxRetransmit, > > > OrginateLsa and MaxAgeLsa really cause > > > > > >>a TRAP flood? Probably we need to throttle only the above three TRAPS? > > > > > >> > > > > > >>I think the normal practice is to inform the NMS using some other > > > notification at the end of a > > > > > >>particular interval when the TRAPs are dropped like this, "Trap N > > > dropped n times in an interval > > > > > >>t". We can add some common extra paratmeters to these notifications to > > > facilitate the NMS to query > > > > > >>the router to retrieve some values and find out whats happening. > > > > > >> > > > > > >>ospfConfigErrorType > > > > > >>------------------- > > > > > >>Do we need an error type for duplicate router id in the received > > > messages? Some times loop back > > > > > >>address can be misconfigured. > > > > > >> > > > > > >>ospfSetTrap > > > > > >>----------- > > > > > >>The definition of this is little complicated. Any reasons for going > > > for last bit to first. We think > > > > > >>its better to redefine this MIB object like this to make if more > > > clear. > > > > > >> > > > > > >> cospfSetTrap OBJECT-TYPE > > > > > >> SYNTAX BITS { > > > > > >> ifConfigError (0), > > > > > >> virtIfConfigError (1), > > > > > >> ospfNbrStateChange (2), > > > > > >> . > > > > > >> . > > > > > >> . > > > > > >> } > > > > > >> MAX-ACCESS read-write > > > > > >> STATUS current > > > > > >> DESCRIPTION > > > > > >> "A One-octet string serving as a bit map for > > > > > >> the trap events defined by the OSPF traps in > > > > > >> this MIB. This object is used to enable and > > > > > >> disable specific OSPF traps where a 1 > > > > > >> in the corresponding bit field represents > > > > > >> enabled." > > > > > >> ::= { cospfTrapControl 1 } > > > > > >> > > > > > >>This definition enables the NMS to interpret the bit map easily. > > > > > >> > > > > > >> > > > > > >>ospfIfStateChange > > > > > >>----------------- > > > > > >> > > > > > >>>From the definition it looks like this TRAP should be generated only > > > for terminal states(when state > > > > > >>progresses) and for backward transition. Infact the name > > > ospfIfStateChange simply suggests to > > > > > >>generate TRAPs for all state transitions. The general tendency is to > > > ignore the DESCRIPTION when > > > > > >>"StateChange" is read and assume its for all the state changes. It > > > might lead to wrong > > > > > >>implementations. I think we can also follow the approach taken in BGP > > > MIB(rfc1657). > > > > > >>There they have notifications like this, > > > > > >> bgpEstablished NOTIFICATION-TYPE > > > > > >> OBJECTS { bgpPeerLastError, > > > > > >> bgpPeerState } > > > > > >> STATUS current > > > > > >> DESCRIPTION > > > > > >> "The BGP Established event is generated > > > when > > > > > >> the BGP FSM enters the ESTABLISHED state." > > > > > >> ::= { bgpTraps 1 } > > > > > >> > > > > > >> bgpBackwardTransition NOTIFICATION-TYPE > > > > > >> OBJECTS { bgpPeerLastError, > > > > > >> bgpPeerState } > > > > > >> STATUS current > > > > > >> DESCRIPTION > > > > > >> "The BGPBackwardTransition Event is > > > generated > > > > > >> when the BGP FSM moves from a higher > > > numbered > > > > > >> state to a lower numbered state." > > > > > >> ::= { bgpTraps 2 } > > > > > >> > > > > > >>Our suggestion is to maintain ospfIfStateChange and use that for > > > monitoring all the states > > > > > >>(some people may want that) and additionally have notifications > > > similar to the BGP notifications. > > > > > >>Its also true with VirtIfStateChange, NbrStateChange and > > > VirtNbrStateChange. If somebody doesn't > > > > > >>want to see ALL state TRAPS, they can suppress them by turning off the > > > corresponding bit in > > > > > >>ospfSetTrap. > > > > > >> > > > > > >> > > > > > >>ospfNbrStateChange > > > > > >>------------------ > > > > > >>The DECRIPTION clause states > > > > > >>"When an neighbor transitions from or to Full on non-broadcast > > > multi-access and broadcast > > > > > >> networks, the trap should be generated by the designated router. A > > > designated router > > > > > >>transitioning to Down will be noted by ospfIfStateChange." > > > > > >>I think here the intention is to reduce the number of TRAPs as much as > > > possible by making > > > > > >>only DR sending out this TRAP for a subnet. But there is a possibility > > > that osfpNbrStateChange > > > > > >>notification is disabled on DR and enabled on DR other or BDR. NMS > > > won't receive TRAPs when > > > > > >>NbrState becomes FULL in that case. There is a problem with the second > > > part of above statments > > > > > >>as well. Suppose ospfIfStateChange is disabled on the router, then > > > again NMS won't know when > > > > > >>neighbor goes down. Probably its better to remove these two clauses. > > > > > >> > > > > > >> > > > > > >>Support for sham links: > > > > > >>----------------------- > > > > > >>Are you going to provide support for sham links? We may need these > > > tables and notifications, > > > > > >>ShamLinkTable > > > > > >>ShamLinkNbrTable > > > > > >>ShamLinkStateChange notification > > > > > >>ShamLinkNbrStateChange notification > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > -- > > > > > Acee > > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 18 01:55:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20970 for ; Tue, 18 Mar 2003 01:55:48 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00935B98@cherry.ease.lsoft.com>; Tue, 18 Mar 2003 1:58:01 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 699630 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 18 Mar 2003 01:58:00 -0500 Received: from 144.189.100.103 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Mar 2003 01:58:00 -0500 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2I6vL0V019757 for ; Mon, 17 Mar 2003 23:57:21 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id XAA23001 for ; Mon, 17 Mar 2003 23:57:59 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Mar 2003 01:57:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 18 Mar 2003 01:52:27 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Dan Joyal is at present working on the OSPFv2 MIB. Thanks, Vishwas -----Original Message----- From: Roy Jose [mailto:rojose@CISCO.COM] Sent: Tuesday, March 18, 2003 12:03 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv2 MIB draft Hi Acee, I agree with you. Till it becomes a standard draft, vendors have to go with some proprietory MIB I guess. Btw, who is working on the MIB update currently? Thanks, Roy > One small correction. > > Acee Lindem wrote: > > > > Roy, > > > > There are 3 reasons why I don't think Sham Links should > > be included in this MIB udpate: > > > > 1. I don't think they are sufficiently specified in the > > Internet Draft describing them. My experience implementing > > the Sham Link feature required some reverse > > engineering (Consult RFC 1264 for specification > > requirements). > > 2. The document describing them is not an OSPF WG > > document. In fact, it is not even an PPVPN > > document (although it could become one). > > 3. At some point, we have to close the door on adding > > MIB variables that are in all the drafts that may or > > may not ever reach draft standard status. If we don't > ~~~~~~~~~~~~~~ > Meant to say "proposed standard" here. > > > do this, we'll never finish the MIB update. > > > > Thanks, > > Acee > > > > Roy Jose wrote: > > > > > > Thanks Jeff, Acee, Mani and John for your responses. How about other > > > points?:) > > > > > > ----- Original Message ----- > > > From: "John Flick" > > > To: > > > Sent: Saturday, March 15, 2003 6:19 AM > > > Subject: Re: OSPFv2 MIB draft > > > > > > > Yep, adding an index would require deprecating everything and starting > > > over. > > > > Since this is an existing, widely deployed, Draft Standard MIB, this > > > should > > > > not be done lightly. > > > > > > > > You would have the same problem if you tried changing MAX-ACCESS on the > > > > table indices (as was also suggested below). Since a change to MAX-ACCESS > > > > of an existing object is not allowed, you would need to deprecated the > > > index > > > > objects, which would require deprecating the tables that they index. > > > Changing > > > > to not-accessible is not required, since SMIv2 allows read-only indices > > > for > > > > MIB modules that were translated from SMIv1 and therefore already had > > > > read-only indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 > > > MIB > > > > module, so this exception applies. > > > > > > How about tables which were added later?: ospfAreaAggregateTable, > > > ExtLsdbTable, etc. > > > My worry is not if its allowed or not. I am trying to point out the extra > > > processing routers and > > > NMS have to do with the increased number of messages. > > > > > > > As far as finding a generic solution for multiple instances of a MIB > > > module, > > > > the standard solution is to use contexts (note: this is not the same as a > > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done in a > > > > somewhat ad-hoc way by using different community names for each instance > > > > of the OSPF MIB. In SNMPv3, it is more formally defined using the > > > > contextName. The Entity MIB entLogicalTable (RFC 2737) provides > > > information > > > > about what contexts exist in an agent, and how to get to them. > > > > > > After having a glance at rfc2737, I also think this is the way. I think we > > > need to specify it clearly how it can be achieved using entLogicalTable. For > > > example, how we need to represent the SNMP community string to retrieve info > > > from a particular routing instance. > > > > > > Thanks, > > > Roy > > > > > > > > > > > John > > > > > > > > Acee Lindem wrote: > > > > > > > > > > Roy, > > > > > > > > > > I can appreciate your points since our product supports both multiple > > > > > virtual router instances and multiple routing protocol instances > > > > > within a particular virtual router. However, I think we'd > > > > > essentially have to deprecate everything in the current MIB and define > > > > > new tables in order to add OSPF instance ID as an index. Can someone > > > > > who has more MIB definition experience comment? > > > > > > > > > > Additionally, the multiple instance problem is not unique to the > > > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > > > > > Roy Jose wrote: > > > > > > Hi, > > > > > > > > > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I would > > > also like > > > > > > to have some clarifications. Please see the attached document. > > > > > > > > > > > > Thanks, > > > > > > Roy > > > > > > > > > > > > > > > > > >>Yes. An update is in the works. > > > > > >> > > > > > >>-Dan > > > > > >> > > > > > >> > > > > > >>>-----Original Message----- > > > > > >>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > > > >>>Subject: OSPFv2 MIB draft > > > > > >>> > > > > > >>> > > > > > >>>Hi all: > > > > > >>>I would like to know the status of the working group > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an > > > > > >>>expiry date of > > > > > >>>May 2001. > > > > > >>>Is there any plan to update the draft ? > > > > > >>> > > > > > >>>Thanks > > > > > >>>Gargi > > > > > >>> > > > > > >> > > > > > >> > > > > > > > > >>------------------------------------------------------------------------ > > > > > >> > > > > > >>Support for multiple OSPF processes: > > > > > >>----------------------------------- > > > > > >> > > > > > >>We raised this issue some time back in WG. Currently MIB supports only > > > one Router ID. > > > > > >>Multiple processes can have separate router IDs. It is also true with > > > other MIB objects > > > > > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we > > > got was to use a > > > > > >>separate MIB view for each process. But I don't think it can be easily > > > implemented. > > > > > >>We suggest to form a new table to group scalar objects related to an > > > OSPF process and have > > > > > >>Process Id as its INDEX. We also suggest to add Process Id as one of > > > the INDICES of all > > > > > >>tables. > > > > > >> > > > > > >> > > > > > >>MAX-ACCESS value for INDICES of TABLES: > > > > > >>-------------------------------------- > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES > > > of a table are > > > > > >>put as not-accesssible to reduce the number of SNMP messages. When an > > > SNMP GET or > > > > > >>GETNEXT is issued on a non-INDEX object, we can extract the values of > > > INDICES from > > > > > >>the object ID returned. For example, let us consider ospfAreaLsaCount. > > > When we query > > > > > >>the value for this, we get something like ospfAreaLsaCount.0.0.0.1, > > > where 0.0.0.1 is > > > > > >>the AreaId, which is the INDEX of the ospfAreaTable. We can extract > > > the INDICES of > > > > > >>table like this even if they are not-accessible. The tables like > > > LsdbTable has many > > > > > >>number of INDICES and we can reduce the number of SNMP messages > > > considerably by changing > > > > > >>them to not-accessible. > > > > > >> > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to include them in > > > the TRAP > > > > > >>notification messages, they can be changed as accessible-for-notify. > > > Other approach to > > > > > >>this is remove the INDICES from TRAP notification messages. For > > > example if you take the > > > > > >>case of IfStateChange TRAP, > > > > > >> > > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > > > >> OBJECTS { ospfRouterId, -- The originator of the trap^M > > > > > >> ospfIfIpAddress,^M > > > > > >> ospfAddressLessIf,^M > > > > > >> ospfIfState -- The new state^M > > > > > >> }^M > > > > > >>Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. > > > When we send TRAP > > > > > >>notification, we can just send ospfIfState. > > value>. . > > > > > >>Also I am not sure why ospfRouterId is included here. An NMS station > > > can always query ospfRouterId > > > > > >>separately. By removing these MIB objects, we can reduce the size and > > > processing time of TRAP > > > > > >>messages considerably. > > > > > >> > > > > > >>Section : 4.3 Ignoring Initial Activity > > > > > >>--------------------------------------- > > > > > >>The section states "The majority of critical events occur when OSPF is > > > enabled on a > > > > > >>router, at which time the designated router is elected and neighbor > > > adjacencies are formed" . > > > > > >>I am not sure if enabling OSPF on a router means enabling it on an > > > interface. I think it will > > > > > >>be better to make the text clearer. > > > > > >> > > > > > >>Other statement is "To avoid unnecessary traps, a router should not > > > originate expected OSPF > > > > > >>interface related traps until two of that interface's dead timer > > > intervals have elapsed." > > > > > >>I think there will be some problems if the dead interval value is too > > > long. We may end up > > > > > >>not sending any of the expected TRAPS for a long time. Btw, could I > > > please know the reason > > > > > >>for selecting 2 * dead interval value for this purpose?. There might > > > be some case where an > > > > > >>interface is up and it goes down before (2 * dead interval). We can't > > > take it as an 'expected > > > > > >>event'. Probably we can ignore the expected events till the interface > > > reaches terminal state > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > > > >> > > > > > >> > > > > > >>One more point is we are already limiting ospfIfStateChange, > > > ospfVirtIfStateChange, > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange notifications by > > > generating them only for terminal > > > > > >>state changes and backward tansition. Do we really need to ignore them > > > during the initial activity?. > > > > > >> > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa > > > traps should not be originated > > > > > >>until two dead timer intervals have elapsed where the deadtimer > > > interval used should be the dead > > > > > >>timer with the smallest value." Here whats the meaning of "dead timer > > > with smallest value"? Is it > > > > > >>the smallest interval value among all the interfaces? > > > > > >> > > > > > >> > > > > > >>Section 4.4 Throttling Traps > > > > > >>---------------------------- > > > > > >>Do we need to provide MIB objects corresponding to window size and the > > > number of TRAPs sent during > > > > > >>the window time? Will the TRAPs other than ospfTxRetransmit, > > > OrginateLsa and MaxAgeLsa really cause > > > > > >>a TRAP flood? Probably we need to throttle only the above three TRAPS? > > > > > >> > > > > > >>I think the normal practice is to inform the NMS using some other > > > notification at the end of a > > > > > >>particular interval when the TRAPs are dropped like this, "Trap N > > > dropped n times in an interval > > > > > >>t". We can add some common extra paratmeters to these notifications to > > > facilitate the NMS to query > > > > > >>the router to retrieve some values and find out whats happening. > > > > > >> > > > > > >>ospfConfigErrorType > > > > > >>------------------- > > > > > >>Do we need an error type for duplicate router id in the received > > > messages? Some times loop back > > > > > >>address can be misconfigured. > > > > > >> > > > > > >>ospfSetTrap > > > > > >>----------- > > > > > >>The definition of this is little complicated. Any reasons for going > > > for last bit to first. We think > > > > > >>its better to redefine this MIB object like this to make if more > > > clear. > > > > > >> > > > > > >> cospfSetTrap OBJECT-TYPE > > > > > >> SYNTAX BITS { > > > > > >> ifConfigError (0), > > > > > >> virtIfConfigError (1), > > > > > >> ospfNbrStateChange (2), > > > > > >> . > > > > > >> . > > > > > >> . > > > > > >> } > > > > > >> MAX-ACCESS read-write > > > > > >> STATUS current > > > > > >> DESCRIPTION > > > > > >> "A One-octet string serving as a bit map for > > > > > >> the trap events defined by the OSPF traps in > > > > > >> this MIB. This object is used to enable and > > > > > >> disable specific OSPF traps where a 1 > > > > > >> in the corresponding bit field represents > > > > > >> enabled." > > > > > >> ::= { cospfTrapControl 1 } > > > > > >> > > > > > >>This definition enables the NMS to interpret the bit map easily. > > > > > >> > > > > > >> > > > > > >>ospfIfStateChange > > > > > >>----------------- > > > > > >> > > > > > >>>From the definition it looks like this TRAP should be generated only > > > for terminal states(when state > > > > > >>progresses) and for backward transition. Infact the name > > > ospfIfStateChange simply suggests to > > > > > >>generate TRAPs for all state transitions. The general tendency is to > > > ignore the DESCRIPTION when > > > > > >>"StateChange" is read and assume its for all the state changes. It > > > might lead to wrong > > > > > >>implementations. I think we can also follow the approach taken in BGP > > > MIB(rfc1657). > > > > > >>There they have notifications like this, > > > > > >> bgpEstablished NOTIFICATION-TYPE > > > > > >> OBJECTS { bgpPeerLastError, > > > > > >> bgpPeerState } > > > > > >> STATUS current > > > > > >> DESCRIPTION > > > > > >> "The BGP Established event is generated > > > when > > > > > >> the BGP FSM enters the ESTABLISHED state." > > > > > >> ::= { bgpTraps 1 } > > > > > >> > > > > > >> bgpBackwardTransition NOTIFICATION-TYPE > > > > > >> OBJECTS { bgpPeerLastError, > > > > > >> bgpPeerState } > > > > > >> STATUS current > > > > > >> DESCRIPTION > > > > > >> "The BGPBackwardTransition Event is > > > generated > > > > > >> when the BGP FSM moves from a higher > > > numbered > > > > > >> state to a lower numbered state." > > > > > >> ::= { bgpTraps 2 } > > > > > >> > > > > > >>Our suggestion is to maintain ospfIfStateChange and use that for > > > monitoring all the states > > > > > >>(some people may want that) and additionally have notifications > > > similar to the BGP notifications. > > > > > >>Its also true with VirtIfStateChange, NbrStateChange and > > > VirtNbrStateChange. If somebody doesn't > > > > > >>want to see ALL state TRAPS, they can suppress them by turning off the > > > corresponding bit in > > > > > >>ospfSetTrap. > > > > > >> > > > > > >> > > > > > >>ospfNbrStateChange > > > > > >>------------------ > > > > > >>The DECRIPTION clause states > > > > > >>"When an neighbor transitions from or to Full on non-broadcast > > > multi-access and broadcast > > > > > >> networks, the trap should be generated by the designated router. A > > > designated router > > > > > >>transitioning to Down will be noted by ospfIfStateChange." > > > > > >>I think here the intention is to reduce the number of TRAPs as much as > > > possible by making > > > > > >>only DR sending out this TRAP for a subnet. But there is a possibility > > > that osfpNbrStateChange > > > > > >>notification is disabled on DR and enabled on DR other or BDR. NMS > > > won't receive TRAPs when > > > > > >>NbrState becomes FULL in that case. There is a problem with the second > > > part of above statments > > > > > >>as well. Suppose ospfIfStateChange is disabled on the router, then > > > again NMS won't know when > > > > > >>neighbor goes down. Probably its better to remove these two clauses. > > > > > >> > > > > > >> > > > > > >>Support for sham links: > > > > > >>----------------------- > > > > > >>Are you going to provide support for sham links? We may need these > > > tables and notifications, > > > > > >>ShamLinkTable > > > > > >>ShamLinkNbrTable > > > > > >>ShamLinkStateChange notification > > > > > >>ShamLinkNbrStateChange notification > > > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 18 07:29:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09098 for ; Tue, 18 Mar 2003 07:29:12 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0093627B@cherry.ease.lsoft.com>; Tue, 18 Mar 2003 7:31:23 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 700498 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 18 Mar 2003 07:31:22 -0500 Received: from 164.107.115.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Mar 2003 07:31:22 -0500 Received: from zeta.cis.ohio-state.edu (daemon@zeta.cis.ohio-state.edu [164.107.112.46]) by cis.ohio-state.edu (8.11.6/8.11.6) with ESMTP id h2ICVL728934 for ; Tue, 18 Mar 2003 07:31:21 -0500 (EST) Received: from localhost (mukul@localhost) by zeta.cis.ohio-state.edu (8.11.6/8.11.6) with ESMTP id h2ICVLP14342 for ; Tue, 18 Mar 2003 07:31:21 -0500 (EST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 18 Mar 2003 07:31:21 -0500 Reply-To: Mailing List Sender: Mailing List From: mukul goyal Subject: Re: IGP fast reroute To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list A paper along similar lines is: Fortifying OSPF/IS-IS against link-failure by M. Thorup (http://www.research.att.com/~mthorup/PAPERS/papers.html). This paper talks about data structures that will allow a router to make a constant time determination regarding an outgoing link to a destination that avoids a given failed link. Thus, routing loops can be avoided in the scenarios where a router has learnt about a failure but has not yet updated the routing table. Thanks, Mukul On Mon, 17 Mar 2003, Manral, Vishwas wrote: > Hi Kajol, > > There is a document > http://www.ietf.org/internet-drafts/draft-kini-traf-restore-nsp-00.txt that > talks about non-shortest-path, which may be relevent to the discussion. > > Besides the IS-IS base document, ISO-10589 talks about "downstream path". A > router calculates path to a destination from a neighbor(the LSDB in all > routers is the same), and any path to the destination that has a lesser cost > than from the calculating router itself is a downstream path.(if I remember > it right). The idea is to find non-looping alternate paths. > > Thanks, > Vishwas > > -----Original Message----- > From: kajol pattnaik [mailto:kajol_patt@YAHOO.COM] > Sent: Tuesday, March 18, 2003 2:35 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: IGP fast reroute > > > Hello, > Are there any IETF standard/document for IGP/OSPF > fast reroute as has been presented by alex zinin and > chenigz in their presentation :"IGP Fast Reroute" , > slides can be found at > > http://www.packetdesign.com/news/presentations.html > > This seems to be a good alternative to IGP fast > convergence, to achive sub-second re-routing wit IGPs, > by generating a two(or a fixed number of) best routes > rather than one best route. > > If there are any IETF standards on this or, any work > in progress in IETF, please point me to the documents. > or, is this completely implementation specific. > > Are there any vendor /academic implementation that > supports IGP/OSPF fast rerouting as presented above?? > > thanks, > kajol. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > http://platinum.yahoo.com > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 18 17:29:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03119 for ; Tue, 18 Mar 2003 17:29:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0093739A@cherry.ease.lsoft.com>; Tue, 18 Mar 2003 17:32:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663167 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 18 Mar 2003 17:32:09 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Mar 2003 17:32:09 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 676DF5002A3 for ; Tue, 18 Mar 2003 14:32:08 -0800 (PST) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E779FC5.34979423@redback.com> Date: Tue, 18 Mar 2003 17:37:57 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Manral, Vishwas" wrote: > > Dan Joyal is at present working on the OSPFv2 MIB. And the OSPFv3 MIB as well. Thanks, Acee > > Thanks, > Vishwas > > -----Original Message----- > From: Roy Jose [mailto:rojose@CISCO.COM] > Sent: Tuesday, March 18, 2003 12:03 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPFv2 MIB draft > > Hi Acee, > > I agree with you. Till it becomes a standard draft, vendors have to go with > some proprietory MIB I guess. Btw, who is working on the MIB update > currently? > > Thanks, > Roy > > > One small correction. > > > > Acee Lindem wrote: > > > > > > Roy, > > > > > > There are 3 reasons why I don't think Sham Links should > > > be included in this MIB udpate: > > > > > > 1. I don't think they are sufficiently specified in the > > > Internet Draft describing them. My experience implementing > > > the Sham Link feature required some reverse > > > engineering (Consult RFC 1264 for specification > > > requirements). > > > 2. The document describing them is not an OSPF WG > > > document. In fact, it is not even an PPVPN > > > document (although it could become one). > > > 3. At some point, we have to close the door on adding > > > MIB variables that are in all the drafts that may or > > > may not ever reach draft standard status. If we don't > > ~~~~~~~~~~~~~~ > > Meant to say "proposed standard" here. > > > > > do this, we'll never finish the MIB update. > > > > > > Thanks, > > > Acee > > > > > > Roy Jose wrote: > > > > > > > > Thanks Jeff, Acee, Mani and John for your responses. How about other > > > > points?:) > > > > > > > > ----- Original Message ----- > > > > From: "John Flick" > > > > To: > > > > Sent: Saturday, March 15, 2003 6:19 AM > > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > Yep, adding an index would require deprecating everything and > starting > > > > over. > > > > > Since this is an existing, widely deployed, Draft Standard MIB, this > > > > should > > > > > not be done lightly. > > > > > > > > > > You would have the same problem if you tried changing MAX-ACCESS on > the > > > > > table indices (as was also suggested below). Since a change to > MAX-ACCESS > > > > > of an existing object is not allowed, you would need to deprecated > the > > > > index > > > > > objects, which would require deprecating the tables that they index. > > > > Changing > > > > > to not-accessible is not required, since SMIv2 allows read-only > indices > > > > for > > > > > MIB modules that were translated from SMIv1 and therefore already > had > > > > > read-only indices. The OSPFv2 MIB started life in RFC 1248 as an > SMIv1 > > > > MIB > > > > > module, so this exception applies. > > > > > > > > How about tables which were added later?: ospfAreaAggregateTable, > > > > ExtLsdbTable, etc. > > > > My worry is not if its allowed or not. I am trying to point out the > extra > > > > processing routers and > > > > NMS have to do with the increased number of messages. > > > > > > > > > As far as finding a generic solution for multiple instances of a MIB > > > > module, > > > > > the standard solution is to use contexts (note: this is not the same > as a > > > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done > in a > > > > > somewhat ad-hoc way by using different community names for each > instance > > > > > of the OSPF MIB. In SNMPv3, it is more formally defined using the > > > > > contextName. The Entity MIB entLogicalTable (RFC 2737) provides > > > > information > > > > > about what contexts exist in an agent, and how to get to them. > > > > > > > > After having a glance at rfc2737, I also think this is the way. I > think we > > > > need to specify it clearly how it can be achieved using > entLogicalTable. For > > > > example, how we need to represent the SNMP community string to > retrieve info > > > > from a particular routing instance. > > > > > > > > Thanks, > > > > Roy > > > > > > > > > > > > > > John > > > > > > > > > > Acee Lindem wrote: > > > > > > > > > > > > Roy, > > > > > > > > > > > > I can appreciate your points since our product supports both > multiple > > > > > > virtual router instances and multiple routing protocol instances > > > > > > within a particular virtual router. However, I think we'd > > > > > > essentially have to deprecate everything in the current MIB and > define > > > > > > new tables in order to add OSPF instance ID as an index. Can > someone > > > > > > who has more MIB definition experience comment? > > > > > > > > > > > > Additionally, the multiple instance problem is not unique to the > > > > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > > > > > > > Roy Jose wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I > would > > > > also like > > > > > > > to have some clarifications. Please see the attached document. > > > > > > > > > > > > > > Thanks, > > > > > > > Roy > > > > > > > > > > > > > > > > > > > > >>Yes. An update is in the works. > > > > > > >> > > > > > > >>-Dan > > > > > > >> > > > > > > >> > > > > > > >>>-----Original Message----- > > > > > > >>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > > > > >>>Subject: OSPFv2 MIB draft > > > > > > >>> > > > > > > >>> > > > > > > >>>Hi all: > > > > > > >>>I would like to know the status of the working group > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an > > > > > > >>>expiry date of > > > > > > >>>May 2001. > > > > > > >>>Is there any plan to update the draft ? > > > > > > >>> > > > > > > >>>Thanks > > > > > > >>>Gargi > > > > > > >>> > > > > > > >> > > > > > > >> > > > > > > > > > > > >>------------------------------------------------------------------------ > > > > > > >> > > > > > > >>Support for multiple OSPF processes: > > > > > > >>----------------------------------- > > > > > > >> > > > > > > >>We raised this issue some time back in WG. Currently MIB > supports only > > > > one Router ID. > > > > > > >>Multiple processes can have separate router IDs. It is also true > with > > > > other MIB objects > > > > > > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution > we > > > > got was to use a > > > > > > >>separate MIB view for each process. But I don't think it can be > easily > > > > implemented. > > > > > > >>We suggest to form a new table to group scalar objects related > to an > > > > OSPF process and have > > > > > > >>Process Id as its INDEX. We also suggest to add Process Id as > one of > > > > the INDICES of all > > > > > > >>tables. > > > > > > >> > > > > > > >> > > > > > > >>MAX-ACCESS value for INDICES of TABLES: > > > > > > >>-------------------------------------- > > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. Normally > INDICES > > > > of a table are > > > > > > >>put as not-accesssible to reduce the number of SNMP messages. > When an > > > > SNMP GET or > > > > > > >>GETNEXT is issued on a non-INDEX object, we can extract the > values of > > > > INDICES from > > > > > > >>the object ID returned. For example, let us consider > ospfAreaLsaCount. > > > > When we query > > > > > > >>the value for this, we get something like > ospfAreaLsaCount.0.0.0.1, > > > > where 0.0.0.1 is > > > > > > >>the AreaId, which is the INDEX of the ospfAreaTable. We can > extract > > > > the INDICES of > > > > > > >>table like this even if they are not-accessible. The tables like > > > > LsdbTable has many > > > > > > >>number of INDICES and we can reduce the number of SNMP messages > > > > considerably by changing > > > > > > >>them to not-accessible. > > > > > > >> > > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to include > them in > > > > the TRAP > > > > > > >>notification messages, they can be changed as > accessible-for-notify. > > > > Other approach to > > > > > > >>this is remove the INDICES from TRAP notification messages. For > > > > example if you take the > > > > > > >>case of IfStateChange TRAP, > > > > > > >> > > > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > > > > >> OBJECTS { ospfRouterId, -- The originator of the trap^M > > > > > > >> ospfIfIpAddress,^M > > > > > > >> ospfAddressLessIf,^M > > > > > > >> ospfIfState -- The new state^M > > > > > > >> }^M > > > > > > >>Here we don't actually need ospfIfIpAddress and > ospfAddressLessIf. > > > > When we send TRAP > > > > > > >>notification, we can just send ospfIfState. > > > value>. . > > > > > > >>Also I am not sure why ospfRouterId is included here. An NMS > station > > > > can always query ospfRouterId > > > > > > >>separately. By removing these MIB objects, we can reduce the > size and > > > > processing time of TRAP > > > > > > >>messages considerably. > > > > > > >> > > > > > > >>Section : 4.3 Ignoring Initial Activity > > > > > > >>--------------------------------------- > > > > > > >>The section states "The majority of critical events occur when > OSPF is > > > > enabled on a > > > > > > >>router, at which time the designated router is elected and > neighbor > > > > adjacencies are formed" . > > > > > > >>I am not sure if enabling OSPF on a router means enabling it on > an > > > > interface. I think it will > > > > > > >>be better to make the text clearer. > > > > > > >> > > > > > > >>Other statement is "To avoid unnecessary traps, a router should > not > > > > originate expected OSPF > > > > > > >>interface related traps until two of that interface's dead timer > > > > intervals have elapsed." > > > > > > >>I think there will be some problems if the dead interval value > is too > > > > long. We may end up > > > > > > >>not sending any of the expected TRAPS for a long time. Btw, > could I > > > > please know the reason > > > > > > >>for selecting 2 * dead interval value for this purpose?. There > might > > > > be some case where an > > > > > > >>interface is up and it goes down before (2 * dead interval). We > can't > > > > take it as an 'expected > > > > > > >>event'. Probably we can ignore the expected events till the > interface > > > > reaches terminal state > > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > > > > >> > > > > > > >> > > > > > > >>One more point is we are already limiting ospfIfStateChange, > > > > ospfVirtIfStateChange, > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange notifications by > > > > generating them only for terminal > > > > > > >>state changes and backward tansition. Do we really need to > ignore them > > > > during the initial activity?. > > > > > > >> > > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and > ospfOriginateLsa > > > > traps should not be originated > > > > > > >>until two dead timer intervals have elapsed where the deadtimer > > > > interval used should be the dead > > > > > > >>timer with the smallest value." Here whats the meaning of "dead > timer > > > > with smallest value"? Is it > > > > > > >>the smallest interval value among all the interfaces? > > > > > > >> > > > > > > >> > > > > > > >>Section 4.4 Throttling Traps > > > > > > >>---------------------------- > > > > > > >>Do we need to provide MIB objects corresponding to window size > and the > > > > number of TRAPs sent during > > > > > > >>the window time? Will the TRAPs other than ospfTxRetransmit, > > > > OrginateLsa and MaxAgeLsa really cause > > > > > > >>a TRAP flood? Probably we need to throttle only the above three > TRAPS? > > > > > > >> > > > > > > >>I think the normal practice is to inform the NMS using some > other > > > > notification at the end of a > > > > > > >>particular interval when the TRAPs are dropped like this, "Trap > N > > > > dropped n times in an interval > > > > > > >>t". We can add some common extra paratmeters to these > notifications to > > > > facilitate the NMS to query > > > > > > >>the router to retrieve some values and find out whats happening. > > > > > > >> > > > > > > >>ospfConfigErrorType > > > > > > >>------------------- > > > > > > >>Do we need an error type for duplicate router id in the received > > > > messages? Some times loop back > > > > > > >>address can be misconfigured. > > > > > > >> > > > > > > >>ospfSetTrap > > > > > > >>----------- > > > > > > >>The definition of this is little complicated. Any reasons for > going > > > > for last bit to first. We think > > > > > > >>its better to redefine this MIB object like this to make if more > > > > clear. > > > > > > >> > > > > > > >> cospfSetTrap OBJECT-TYPE > > > > > > >> SYNTAX BITS { > > > > > > >> ifConfigError (0), > > > > > > >> virtIfConfigError (1), > > > > > > >> ospfNbrStateChange (2), > > > > > > >> . > > > > > > >> . > > > > > > >> . > > > > > > >> } > > > > > > >> MAX-ACCESS read-write > > > > > > >> STATUS current > > > > > > >> DESCRIPTION > > > > > > >> "A One-octet string serving as a bit map for > > > > > > >> the trap events defined by the OSPF traps in > > > > > > >> this MIB. This object is used to enable and > > > > > > >> disable specific OSPF traps where a 1 > > > > > > >> in the corresponding bit field represents > > > > > > >> enabled." > > > > > > >> ::= { cospfTrapControl 1 } > > > > > > >> > > > > > > >>This definition enables the NMS to interpret the bit map easily. > > > > > > >> > > > > > > >> > > > > > > >>ospfIfStateChange > > > > > > >>----------------- > > > > > > >> > > > > > > >>>From the definition it looks like this TRAP should be generated > only > > > > for terminal states(when state > > > > > > >>progresses) and for backward transition. Infact the name > > > > ospfIfStateChange simply suggests to > > > > > > >>generate TRAPs for all state transitions. The general tendency > is to > > > > ignore the DESCRIPTION when > > > > > > >>"StateChange" is read and assume its for all the state changes. > It > > > > might lead to wrong > > > > > > >>implementations. I think we can also follow the approach taken > in BGP > > > > MIB(rfc1657). > > > > > > >>There they have notifications like this, > > > > > > >> bgpEstablished NOTIFICATION-TYPE > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > >> bgpPeerState } > > > > > > >> STATUS current > > > > > > >> DESCRIPTION > > > > > > >> "The BGP Established event is > generated > > > > when > > > > > > >> the BGP FSM enters the ESTABLISHED > state." > > > > > > >> ::= { bgpTraps 1 } > > > > > > >> > > > > > > >> bgpBackwardTransition NOTIFICATION-TYPE > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > >> bgpPeerState } > > > > > > >> STATUS current > > > > > > >> DESCRIPTION > > > > > > >> "The BGPBackwardTransition Event is > > > > generated > > > > > > >> when the BGP FSM moves from a higher > > > > numbered > > > > > > >> state to a lower numbered state." > > > > > > >> ::= { bgpTraps 2 } > > > > > > >> > > > > > > >>Our suggestion is to maintain ospfIfStateChange and use that for > > > > monitoring all the states > > > > > > >>(some people may want that) and additionally have notifications > > > > similar to the BGP notifications. > > > > > > >>Its also true with VirtIfStateChange, NbrStateChange and > > > > VirtNbrStateChange. If somebody doesn't > > > > > > >>want to see ALL state TRAPS, they can suppress them by turning > off the > > > > corresponding bit in > > > > > > >>ospfSetTrap. > > > > > > >> > > > > > > >> > > > > > > >>ospfNbrStateChange > > > > > > >>------------------ > > > > > > >>The DECRIPTION clause states > > > > > > >>"When an neighbor transitions from or to Full on non-broadcast > > > > multi-access and broadcast > > > > > > >> networks, the trap should be generated by the designated > router. A > > > > designated router > > > > > > >>transitioning to Down will be noted by ospfIfStateChange." > > > > > > >>I think here the intention is to reduce the number of TRAPs as > much as > > > > possible by making > > > > > > >>only DR sending out this TRAP for a subnet. But there is a > possibility > > > > that osfpNbrStateChange > > > > > > >>notification is disabled on DR and enabled on DR other or BDR. > NMS > > > > won't receive TRAPs when > > > > > > >>NbrState becomes FULL in that case. There is a problem with the > second > > > > part of above statments > > > > > > >>as well. Suppose ospfIfStateChange is disabled on the router, > then > > > > again NMS won't know when > > > > > > >>neighbor goes down. Probably its better to remove these two > clauses. > > > > > > >> > > > > > > >> > > > > > > >>Support for sham links: > > > > > > >>----------------------- > > > > > > >>Are you going to provide support for sham links? We may need > these > > > > tables and notifications, > > > > > > >>ShamLinkTable > > > > > > >>ShamLinkNbrTable > > > > > > >>ShamLinkStateChange notification > > > > > > >>ShamLinkNbrStateChange notification > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 19 02:41:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15252 for ; Wed, 19 Mar 2003 02:41:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0093824B@cherry.ease.lsoft.com>; Wed, 19 Mar 2003 2:44:09 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664238 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 19 Mar 2003 02:44:09 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Mar 2003 02:44:09 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 2E7BE7A6E10 for ; Tue, 18 Mar 2003 23:43:21 -0800 (PST) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 References: <20030312101401.B95881@kummer.juniper.net> <200303121911.OAA14095@bigbird.xebeo.com> <200303122007.h2CK79L38929@fuinar.juniper.net> <3E6FA932.4060606@redback.com> <8765qisiwu.wl@ipinfusion.com> <20030317132803.P21297@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E7820F5.6261E51F@redback.com> Date: Wed, 19 Mar 2003 02:49:09 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kireeti Kompella wrote: > > On Sun, 16 Mar 2003, Kunihiro Ishiguro wrote: > > > Agreed. > > > > >I also feel that whether or not OSPFv3 will eventually be used > > >for carrying IPv4 prefixes is a completely independent issue > > >(othrogonal in IETF-speak ;^). > > > > Yes. It is independent issue. But when we support it, we will define > > new LS type. If we carry IPv4 prefix in OSPFv3 with OSPFv2 Opaque LSA > > format....that will be nightmare... > > It was never the idea to carry IPv4 prefixes with the v2 Opaque LSA > format. > > Let me summarize the issues: > 1) do we want to draw a line in the sand and state that OSPFv3 is a > *different* protocol from OSPFv2? The alternative viewpoint is > as far as specs go, v3 cleans up some aspects of v2 that weren't > done optimally; as far as code goes, v3 implementations can share > a lot of code with v2. I'd go with the alternate viewpoint. One of the main motivations for the OSPFv2 opaque LSA was to solve the problem of how to get LSAs flooded w/o every router in the OSPF routing domain understanding all the opaque LSAs types. In OSPFv3, flooding of unknown LSA types is handled explicitly - this obviates the requirement for opaque LSAs. > 2) if the answer to the above is that v3 is a refinement of v2, then > the question is, how much can we borrow from v2 (such as carrying > IPv4 prefixes and Opaque LSAs in v3 pretty much the same way that > they are carried in v2)? Using a new LSA type vis-a-vis a multi-level identifier for each unique class of LSA is one of the things that is cleaned up in OSPFv3. Acee > > Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 19 07:33:17 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19588 for ; Wed, 19 Mar 2003 07:33:16 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0093869A@cherry.ease.lsoft.com>; Wed, 19 Mar 2003 7:35:28 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665108 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 19 Mar 2003 07:35:28 -0500 Received: from 171.71.177.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Mar 2003 07:35:27 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2JCZNhs001088; Wed, 19 Mar 2003 04:35:24 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id SAA10283; Wed, 19 Mar 2003 18:03:59 +0530 (IST) References: <3E779FC5.34979423@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <0acb01c2ee14$02060220$9c8b4d0a@apac.cisco.com> Date: Wed, 19 Mar 2003 18:05:21 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPFv2 MIB draft Comments: cc: joyal@lucent.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Thanks Manral, Acee. Let me point out the open issues here from the original document I sent. Joyal, please let me know if you need any clarifications. Support for multiple OSPF processes: ----------------------------------- We raised this issue some time back in WG. Currently MIB supports only one Router ID. Multiple processes can have separate router IDs. It is also true with other MIB objects like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we got was to use a separate MIB view for each process. But I don't think it can be easily implemented. We suggest to form a new table to group scalar objects related to an OSPF process and have Process Id as its INDEX. We also suggest to add Process Id as one of the INDICES of all tables. [WG - John Flick] As far as finding a generic solution for multiple instances of a MIB module, the standard solution is to use contexts (note: this is not the same as a MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done in a somewhat ad-hoc way by using different community names for each instance of the OSPF MIB. In SNMPv3, it is more formally defined using the contextName. The Entity MIB entLogicalTable (RFC 2737) provides information about what contexts exist in an agent, and how to get to them. [OPEN issue] I think we need to investigate on this and add a section to the draft how it can be applied to OSPF MIB . MAX-ACCESS value for INDICES of TABLES: -------------------------------------- I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES of a table are put as not-accesssible to reduce the number of SNMP messages. When an SNMP GET or GETNEXT is issued on a non-INDEX object, we can extract the values of INDICES from the object ID returned. For example, let us consider ospfAreaLsaCount. When we query the value for this, we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1 is the AreaId, which is the INDEX of the ospfAreaTable. We can extract the INDICES of table like this even if they are not-accessible. The tables like LsdbTable has many number of INDICES and we can reduce the number of SNMP messages considerably by changing them to not-accessible. [WG - John Flick] You would have the same problem if you tried changing MAX-ACCESS on the table indices (as was also suggested below). Since a change to MAX-ACCESS of an existing object is not allowed, you would need to deprecated the index objects, which would require deprecating the tables that they index. Changing to not-accessible is not required, since SMIv2 allows read-only indices for MIB modules that were translated from SMIv1 and therefore already had read-only indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 MIB module, so this exception applies. [OPEN issue] As I have pointed out earlier, by changing the INDICES we can reduce the number of SNMP GETNEXT reponses sent by the router considerably. The draft standard MIB is already widely deployed. But we need to deprecate an existing MIB and add a new version, when it is required. I feel if everyone thinks what I pointed out is a big advantange, still we can go ahead with this change. If the MAX-ACCESS of INDICES are put as read-only to include them in the TRAP notification messages, they can be changed as accessible-for-notify. Other approach to this is remove the INDICES from TRAP notification messages. For example if you take the case of IfStateChange TRAP, ospfIfStateChange NOTIFICATION-TYPE^M OBJECTS { ospfRouterId, -- The originator of the trap^M ospfIfIpAddress,^M ospfAddressLessIf,^M ospfIfState -- The new state^M }^M Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. When we send TRAP notification, we can just send ospfIfState.. . Also I am not sure why ospfRouterId is included here. An NMS station can always query ospfRouterId separately. By removing these MIB objects, we can reduce the size and processing time of TRAP messages considerably. [OPEN issue] The above point is not addressed yet. Section : 4.3 Ignoring Initial Activity --------------------------------------- [OPEN issue] This is not addressed yet. The section states "The majority of critical events occur when OSPF is enabled on a router, at which time the designated router is elected and neighbor adjacencies are formed" . I am not sure if enabling OSPF on a router means enabling it on an interface. I think it will be better to make the text clearer. Other statement is "To avoid unnecessary traps, a router should not originate expected OSPF interface related traps until two of that interface's dead timer intervals have elapsed." I think there will be some problems if the dead interval value is too long. We may end up not sending any of the expected TRAPS for a long time. Btw, could I please know the reason for selecting 2 * dead interval value for this purpose?. There might be some case where an interface is up and it goes down before (2 * dead interval). We can't take it as an 'expected event'. Probably we can ignore the expected events till the interface reaches terminal state (FULL or 2WAY) for the first time after enabling OSPF. One more point is we are already limiting ospfIfStateChange, ospfVirtIfStateChange, ospfNbrStateChange and ospfVirtNbrStateChange notifications by generating them only for terminal state changes and backward tansition. Do we really need to ignore them during the initial activity?. Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa traps should not be originated until two dead timer intervals have elapsed where the deadtimer interval used should be the dead timer with the smallest value." Here whats the meaning of "dead timer with smallest value"? Is it the smallest interval value among all the interfaces? Section 4.4 Throttling Traps ---------------------------- [OPEN issue] This is not addressed yet. Do we need to provide MIB objects corresponding to window size and the number of TRAPs sent during the window time? Will the TRAPs other than ospfTxRetransmit, OrginateLsa and MaxAgeLsa really cause a TRAP flood? Probably we need to throttle only the above three TRAPS? I think the normal practice is to inform the NMS using some other notification at the end of a particular interval when the TRAPs are dropped like this, "Trap N dropped n times in an interval t". We can add some common extra paratmeters to these notifications to facilitate the NMS to query the router to retrieve some values and find out whats happening. ospfConfigErrorType ------------------- [OPEN issue] This is not addressed yet. Do we need an error type for duplicate router id in the received messages? Some times loop back address can be misconfigured. ospfSetTrap ----------- [OPEN issue] This is not addressed yet. The definition of this is little complicated. Any reasons for going for last bit to first. We think its better to redefine this MIB object like this to make if more clear. cospfSetTrap OBJECT-TYPE SYNTAX BITS { ifConfigError (0), virtIfConfigError (1), ospfNbrStateChange (2), . . . } MAX-ACCESS read-write STATUS current DESCRIPTION "A One-octet string serving as a bit map for the trap events defined by the OSPF traps in this MIB. This object is used to enable and disable specific OSPF traps where a 1 in the corresponding bit field represents enabled." ::= { cospfTrapControl 1 } This definition enables the NMS to interpret the bit map easily. ospfIfStateChange ----------------- [OPEN issue] This is not addressed yet. From the definition it looks like this TRAP should be generated only for terminal states(when state progresses) and for backward transition. Infact the name ospfIfStateChange simply suggests to generate TRAPs for all state transitions. The general tendency is to ignore the DESCRIPTION when "StateChange" is read and assume its for all the state changes. It might lead to wrong implementations. I think we can also follow the approach taken in BGP MIB(rfc1657). There they have notifications like this, bgpEstablished NOTIFICATION-TYPE OBJECTS { bgpPeerLastError, bgpPeerState } STATUS current DESCRIPTION "The BGP Established event is generated when the BGP FSM enters the ESTABLISHED state." ::= { bgpTraps 1 } bgpBackwardTransition NOTIFICATION-TYPE OBJECTS { bgpPeerLastError, bgpPeerState } STATUS current DESCRIPTION "The BGPBackwardTransition Event is generated when the BGP FSM moves from a higher numbered state to a lower numbered state." ::= { bgpTraps 2 } Our suggestion is to maintain ospfIfStateChange and use that for monitoring all the states (some people may want that) and additionally have notifications similar to the BGP notifications. Its also true with VirtIfStateChange, NbrStateChange and VirtNbrStateChange. If somebody doesn't want to see ALL state TRAPS, they can suppress them by turning off the corresponding bit in ospfSetTrap. ospfNbrStateChange ------------------ [OPEN issue] This is not addressed yet. The DECRIPTION clause states "When an neighbor transitions from or to Full on non-broadcast multi-access and broadcast networks, the trap should be generated by the designated router. A designated router transitioning to Down will be noted by ospfIfStateChange." I think here the intention is to reduce the number of TRAPs as much as possible by making only DR sending out this TRAP for a subnet. But there is a possibility that osfpNbrStateChange notification is disabled on DR and enabled on DR other or BDR. NMS won't receive TRAPs when NbrState becomes FULL in that case. There is a problem with the second part of above statments as well. Suppose ospfIfStateChange is disabled on the router, then again NMS won't know when neighbor goes down. Probably its better to remove these two clauses. Thanks, Roy > "Manral, Vishwas" wrote: > > > > Dan Joyal is at present working on the OSPFv2 MIB. > > And the OSPFv3 MIB as well. > > > Thanks, > Acee > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Roy Jose [mailto:rojose@CISCO.COM] > > Sent: Tuesday, March 18, 2003 12:03 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: OSPFv2 MIB draft > > > > Hi Acee, > > > > I agree with you. Till it becomes a standard draft, vendors have to go with > > some proprietory MIB I guess. Btw, who is working on the MIB update > > currently? > > > > Thanks, > > Roy > > > > > One small correction. > > > > > > Acee Lindem wrote: > > > > > > > > Roy, > > > > > > > > There are 3 reasons why I don't think Sham Links should > > > > be included in this MIB udpate: > > > > > > > > 1. I don't think they are sufficiently specified in the > > > > Internet Draft describing them. My experience implementing > > > > the Sham Link feature required some reverse > > > > engineering (Consult RFC 1264 for specification > > > > requirements). > > > > 2. The document describing them is not an OSPF WG > > > > document. In fact, it is not even an PPVPN > > > > document (although it could become one). > > > > 3. At some point, we have to close the door on adding > > > > MIB variables that are in all the drafts that may or > > > > may not ever reach draft standard status. If we don't > > > ~~~~~~~~~~~~~~ > > > Meant to say "proposed standard" here. > > > > > > > do this, we'll never finish the MIB update. > > > > > > > > Thanks, > > > > Acee > > > > > > > > Roy Jose wrote: > > > > > > > > > > Thanks Jeff, Acee, Mani and John for your responses. How about other > > > > > points?:) > > > > > > > > > > ----- Original Message ----- > > > > > From: "John Flick" > > > > > To: > > > > > Sent: Saturday, March 15, 2003 6:19 AM > > > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > > > Yep, adding an index would require deprecating everything and > > starting > > > > > over. > > > > > > Since this is an existing, widely deployed, Draft Standard MIB, this > > > > > should > > > > > > not be done lightly. > > > > > > > > > > > > You would have the same problem if you tried changing MAX-ACCESS on > > the > > > > > > table indices (as was also suggested below). Since a change to > > MAX-ACCESS > > > > > > of an existing object is not allowed, you would need to deprecated > > the > > > > > index > > > > > > objects, which would require deprecating the tables that they index. > > > > > Changing > > > > > > to not-accessible is not required, since SMIv2 allows read-only > > indices > > > > > for > > > > > > MIB modules that were translated from SMIv1 and therefore already > > had > > > > > > read-only indices. The OSPFv2 MIB started life in RFC 1248 as an > > SMIv1 > > > > > MIB > > > > > > module, so this exception applies. > > > > > > > > > > How about tables which were added later?: ospfAreaAggregateTable, > > > > > ExtLsdbTable, etc. > > > > > My worry is not if its allowed or not. I am trying to point out the > > extra > > > > > processing routers and > > > > > NMS have to do with the increased number of messages. > > > > > > > > > > > As far as finding a generic solution for multiple instances of a MIB > > > > > module, > > > > > > the standard solution is to use contexts (note: this is not the same > > as a > > > > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done > > in a > > > > > > somewhat ad-hoc way by using different community names for each > > instance > > > > > > of the OSPF MIB. In SNMPv3, it is more formally defined using the > > > > > > contextName. The Entity MIB entLogicalTable (RFC 2737) provides > > > > > information > > > > > > about what contexts exist in an agent, and how to get to them. > > > > > > > > > > After having a glance at rfc2737, I also think this is the way. I > > think we > > > > > need to specify it clearly how it can be achieved using > > entLogicalTable. For > > > > > example, how we need to represent the SNMP community string to > > retrieve info > > > > > from a particular routing instance. > > > > > > > > > > Thanks, > > > > > Roy > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > Acee Lindem wrote: > > > > > > > > > > > > > > Roy, > > > > > > > > > > > > > > I can appreciate your points since our product supports both > > multiple > > > > > > > virtual router instances and multiple routing protocol instances > > > > > > > within a particular virtual router. However, I think we'd > > > > > > > essentially have to deprecate everything in the current MIB and > > define > > > > > > > new tables in order to add OSPF instance ID as an index. Can > > someone > > > > > > > who has more MIB definition experience comment? > > > > > > > > > > > > > > Additionally, the multiple instance problem is not unique to the > > > > > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > > > > > > > > > Roy Jose wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I > > would > > > > > also like > > > > > > > > to have some clarifications. Please see the attached document. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Roy > > > > > > > > > > > > > > > > > > > > > > > >>Yes. An update is in the works. > > > > > > > >> > > > > > > > >>-Dan > > > > > > > >> > > > > > > > >> > > > > > > > >>>-----Original Message----- > > > > > > > >>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > > > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > > > > > >>>Subject: OSPFv2 MIB draft > > > > > > > >>> > > > > > > > >>> > > > > > > > >>>Hi all: > > > > > > > >>>I would like to know the status of the working group > > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an > > > > > > > >>>expiry date of > > > > > > > >>>May 2001. > > > > > > > >>>Is there any plan to update the draft ? > > > > > > > >>> > > > > > > > >>>Thanks > > > > > > > >>>Gargi > > > > > > > >>> > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > >>------------------------------------------------------------------------ > > > > > > > >> > > > > > > > >>Support for multiple OSPF processes: > > > > > > > >>----------------------------------- > > > > > > > >> > > > > > > > >>We raised this issue some time back in WG. Currently MIB > > supports only > > > > > one Router ID. > > > > > > > >>Multiple processes can have separate router IDs. It is also true > > with > > > > > other MIB objects > > > > > > > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution > > we > > > > > got was to use a > > > > > > > >>separate MIB view for each process. But I don't think it can be > > easily > > > > > implemented. > > > > > > > >>We suggest to form a new table to group scalar objects related > > to an > > > > > OSPF process and have > > > > > > > >>Process Id as its INDEX. We also suggest to add Process Id as > > one of > > > > > the INDICES of all > > > > > > > >>tables. > > > > > > > >> > > > > > > > >> > > > > > > > >>MAX-ACCESS value for INDICES of TABLES: > > > > > > > >>-------------------------------------- > > > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. Normally > > INDICES > > > > > of a table are > > > > > > > >>put as not-accesssible to reduce the number of SNMP messages. > > When an > > > > > SNMP GET or > > > > > > > >>GETNEXT is issued on a non-INDEX object, we can extract the > > values of > > > > > INDICES from > > > > > > > >>the object ID returned. For example, let us consider > > ospfAreaLsaCount. > > > > > When we query > > > > > > > >>the value for this, we get something like > > ospfAreaLsaCount.0.0.0.1, > > > > > where 0.0.0.1 is > > > > > > > >>the AreaId, which is the INDEX of the ospfAreaTable. We can > > extract > > > > > the INDICES of > > > > > > > >>table like this even if they are not-accessible. The tables like > > > > > LsdbTable has many > > > > > > > >>number of INDICES and we can reduce the number of SNMP messages > > > > > considerably by changing > > > > > > > >>them to not-accessible. > > > > > > > >> > > > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to include > > them in > > > > > the TRAP > > > > > > > >>notification messages, they can be changed as > > accessible-for-notify. > > > > > Other approach to > > > > > > > >>this is remove the INDICES from TRAP notification messages. For > > > > > example if you take the > > > > > > > >>case of IfStateChange TRAP, > > > > > > > >> > > > > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > > > > > >> OBJECTS { ospfRouterId, -- The originator of the trap^M > > > > > > > >> ospfIfIpAddress,^M > > > > > > > >> ospfAddressLessIf,^M > > > > > > > >> ospfIfState -- The new state^M > > > > > > > >> }^M > > > > > > > >>Here we don't actually need ospfIfIpAddress and > > ospfAddressLessIf. > > > > > When we send TRAP > > > > > > > >>notification, we can just send ospfIfState. > > > > value>. . > > > > > > > >>Also I am not sure why ospfRouterId is included here. An NMS > > station > > > > > can always query ospfRouterId > > > > > > > >>separately. By removing these MIB objects, we can reduce the > > size and > > > > > processing time of TRAP > > > > > > > >>messages considerably. > > > > > > > >> > > > > > > > >>Section : 4.3 Ignoring Initial Activity > > > > > > > >>--------------------------------------- > > > > > > > >>The section states "The majority of critical events occur when > > OSPF is > > > > > enabled on a > > > > > > > >>router, at which time the designated router is elected and > > neighbor > > > > > adjacencies are formed" . > > > > > > > >>I am not sure if enabling OSPF on a router means enabling it on > > an > > > > > interface. I think it will > > > > > > > >>be better to make the text clearer. > > > > > > > >> > > > > > > > >>Other statement is "To avoid unnecessary traps, a router should > > not > > > > > originate expected OSPF > > > > > > > >>interface related traps until two of that interface's dead timer > > > > > intervals have elapsed." > > > > > > > >>I think there will be some problems if the dead interval value > > is too > > > > > long. We may end up > > > > > > > >>not sending any of the expected TRAPS for a long time. Btw, > > could I > > > > > please know the reason > > > > > > > >>for selecting 2 * dead interval value for this purpose?. There > > might > > > > > be some case where an > > > > > > > >>interface is up and it goes down before (2 * dead interval). We > > can't > > > > > take it as an 'expected > > > > > > > >>event'. Probably we can ignore the expected events till the > > interface > > > > > reaches terminal state > > > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > > > > > >> > > > > > > > >> > > > > > > > >>One more point is we are already limiting ospfIfStateChange, > > > > > ospfVirtIfStateChange, > > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange notifications by > > > > > generating them only for terminal > > > > > > > >>state changes and backward tansition. Do we really need to > > ignore them > > > > > during the initial activity?. > > > > > > > >> > > > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and > > ospfOriginateLsa > > > > > traps should not be originated > > > > > > > >>until two dead timer intervals have elapsed where the deadtimer > > > > > interval used should be the dead > > > > > > > >>timer with the smallest value." Here whats the meaning of "dead > > timer > > > > > with smallest value"? Is it > > > > > > > >>the smallest interval value among all the interfaces? > > > > > > > >> > > > > > > > >> > > > > > > > >>Section 4.4 Throttling Traps > > > > > > > >>---------------------------- > > > > > > > >>Do we need to provide MIB objects corresponding to window size > > and the > > > > > number of TRAPs sent during > > > > > > > >>the window time? Will the TRAPs other than ospfTxRetransmit, > > > > > OrginateLsa and MaxAgeLsa really cause > > > > > > > >>a TRAP flood? Probably we need to throttle only the above three > > TRAPS? > > > > > > > >> > > > > > > > >>I think the normal practice is to inform the NMS using some > > other > > > > > notification at the end of a > > > > > > > >>particular interval when the TRAPs are dropped like this, "Trap > > N > > > > > dropped n times in an interval > > > > > > > >>t". We can add some common extra paratmeters to these > > notifications to > > > > > facilitate the NMS to query > > > > > > > >>the router to retrieve some values and find out whats happening. > > > > > > > >> > > > > > > > >>ospfConfigErrorType > > > > > > > >>------------------- > > > > > > > >>Do we need an error type for duplicate router id in the received > > > > > messages? Some times loop back > > > > > > > >>address can be misconfigured. > > > > > > > >> > > > > > > > >>ospfSetTrap > > > > > > > >>----------- > > > > > > > >>The definition of this is little complicated. Any reasons for > > going > > > > > for last bit to first. We think > > > > > > > >>its better to redefine this MIB object like this to make if more > > > > > clear. > > > > > > > >> > > > > > > > >> cospfSetTrap OBJECT-TYPE > > > > > > > >> SYNTAX BITS { > > > > > > > >> ifConfigError (0), > > > > > > > >> virtIfConfigError (1), > > > > > > > >> ospfNbrStateChange (2), > > > > > > > >> . > > > > > > > >> . > > > > > > > >> . > > > > > > > >> } > > > > > > > >> MAX-ACCESS read-write > > > > > > > >> STATUS current > > > > > > > >> DESCRIPTION > > > > > > > >> "A One-octet string serving as a bit map for > > > > > > > >> the trap events defined by the OSPF traps in > > > > > > > >> this MIB. This object is used to enable and > > > > > > > >> disable specific OSPF traps where a 1 > > > > > > > >> in the corresponding bit field represents > > > > > > > >> enabled." > > > > > > > >> ::= { cospfTrapControl 1 } > > > > > > > >> > > > > > > > >>This definition enables the NMS to interpret the bit map easily. > > > > > > > >> > > > > > > > >> > > > > > > > >>ospfIfStateChange > > > > > > > >>----------------- > > > > > > > >> > > > > > > > >>>From the definition it looks like this TRAP should be generated > > only > > > > > for terminal states(when state > > > > > > > >>progresses) and for backward transition. Infact the name > > > > > ospfIfStateChange simply suggests to > > > > > > > >>generate TRAPs for all state transitions. The general tendency > > is to > > > > > ignore the DESCRIPTION when > > > > > > > >>"StateChange" is read and assume its for all the state changes. > > It > > > > > might lead to wrong > > > > > > > >>implementations. I think we can also follow the approach taken > > in BGP > > > > > MIB(rfc1657). > > > > > > > >>There they have notifications like this, > > > > > > > >> bgpEstablished NOTIFICATION-TYPE > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > >> bgpPeerState } > > > > > > > >> STATUS current > > > > > > > >> DESCRIPTION > > > > > > > >> "The BGP Established event is > > generated > > > > > when > > > > > > > >> the BGP FSM enters the ESTABLISHED > > state." > > > > > > > >> ::= { bgpTraps 1 } > > > > > > > >> > > > > > > > >> bgpBackwardTransition NOTIFICATION-TYPE > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > >> bgpPeerState } > > > > > > > >> STATUS current > > > > > > > >> DESCRIPTION > > > > > > > >> "The BGPBackwardTransition Event is > > > > > generated > > > > > > > >> when the BGP FSM moves from a higher > > > > > numbered > > > > > > > >> state to a lower numbered state." > > > > > > > >> ::= { bgpTraps 2 } > > > > > > > >> > > > > > > > >>Our suggestion is to maintain ospfIfStateChange and use that for > > > > > monitoring all the states > > > > > > > >>(some people may want that) and additionally have notifications > > > > > similar to the BGP notifications. > > > > > > > >>Its also true with VirtIfStateChange, NbrStateChange and > > > > > VirtNbrStateChange. If somebody doesn't > > > > > > > >>want to see ALL state TRAPS, they can suppress them by turning > > off the > > > > > corresponding bit in > > > > > > > >>ospfSetTrap. > > > > > > > >> > > > > > > > >> > > > > > > > >>ospfNbrStateChange > > > > > > > >>------------------ > > > > > > > >>The DECRIPTION clause states > > > > > > > >>"When an neighbor transitions from or to Full on non-broadcast > > > > > multi-access and broadcast > > > > > > > >> networks, the trap should be generated by the designated > > router. A > > > > > designated router > > > > > > > >>transitioning to Down will be noted by ospfIfStateChange." > > > > > > > >>I think here the intention is to reduce the number of TRAPs as > > much as > > > > > possible by making > > > > > > > >>only DR sending out this TRAP for a subnet. But there is a > > possibility > > > > > that osfpNbrStateChange > > > > > > > >>notification is disabled on DR and enabled on DR other or BDR. > > NMS > > > > > won't receive TRAPs when > > > > > > > >>NbrState becomes FULL in that case. There is a problem with the > > second > > > > > part of above statments > > > > > > > >>as well. Suppose ospfIfStateChange is disabled on the router, > > then > > > > > again NMS won't know when > > > > > > > >>neighbor goes down. Probably its better to remove these two > > clauses. > > > > > > > >> > > > > > > > >> > > > > > > > >>Support for sham links: > > > > > > > >>----------------------- > > > > > > > >>Are you going to provide support for sham links? We may need > > these > > > > > tables and notifications, > > > > > > > >>ShamLinkTable > > > > > > > >>ShamLinkNbrTable > > > > > > > >>ShamLinkStateChange notification > > > > > > > >>ShamLinkNbrStateChange notification > > > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 19 07:36:54 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19630 for ; Wed, 19 Mar 2003 07:36:51 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009386A2@cherry.ease.lsoft.com>; Wed, 19 Mar 2003 7:39:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665129 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 19 Mar 2003 07:39:04 -0500 Received: from 171.71.177.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Mar 2003 07:39:04 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2JCd0hs003092 for ; Wed, 19 Mar 2003 04:39:01 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id SAA10715 for ; Wed, 19 Mar 2003 18:07:37 +0530 (IST) References: <3E779FC5.34979423@redback.com> <0acb01c2ee14$02060220$9c8b4d0a@apac.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <0af301c2ee14$83903d60$9c8b4d0a@apac.cisco.com> Date: Wed, 19 Mar 2003 18:08:59 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Looks like Joyal's id is not reachable. ----- The following addresses had permanent fatal errors ----- (reason: 550 5.0.0 ... User unknown) -Roy > Thanks Manral, Acee. > > Let me point out the open issues here from the original document I sent. > Joyal, please let me know if you need any clarifications. > > Support for multiple OSPF processes: > ----------------------------------- > > We raised this issue some time back in WG. Currently MIB supports only one > Router ID. > Multiple processes can have separate router IDs. It is also true with other > MIB objects > like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we got was > to use a > separate MIB view for each process. But I don't think it can be easily > implemented. > We suggest to form a new table to group scalar objects related to an OSPF > process and have > Process Id as its INDEX. We also suggest to add Process Id as one of the > INDICES of all > tables. > [WG - John Flick] > As far as finding a generic solution for multiple instances of a MIB module, > the standard solution is to use contexts (note: this is not the same as a > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done in a > somewhat ad-hoc way by using different community names for each instance > of the OSPF MIB. In SNMPv3, it is more formally defined using the > contextName. The Entity MIB entLogicalTable (RFC 2737) provides information > about what contexts exist in an agent, and how to get to them. > [OPEN issue] > I think we need to investigate on this and add a section to the draft how it > can be applied to OSPF MIB . > > > MAX-ACCESS value for INDICES of TABLES: > -------------------------------------- > I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES of a > table are > put as not-accesssible to reduce the number of SNMP messages. When an SNMP > GET or > GETNEXT is issued on a non-INDEX object, we can extract the values of > INDICES from > the object ID returned. For example, let us consider ospfAreaLsaCount. When > we query > the value for this, we get something like ospfAreaLsaCount.0.0.0.1, where > 0.0.0.1 is > the AreaId, which is the INDEX of the ospfAreaTable. We can extract the > INDICES of > table like this even if they are not-accessible. The tables like LsdbTable > has many > number of INDICES and we can reduce the number of SNMP messages considerably > by changing > them to not-accessible. > > [WG - John Flick] > You would have the same problem if you tried changing MAX-ACCESS on the > table indices (as was also suggested below). Since a change to MAX-ACCESS > of an existing object is not allowed, you would need to deprecated the index > objects, which would require deprecating the tables that they index. > Changing > to not-accessible is not required, since SMIv2 allows read-only indices for > MIB modules that were translated from SMIv1 and therefore already had > read-only indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 MIB > module, so this exception applies. > > [OPEN issue] > As I have pointed out earlier, by changing the INDICES we can reduce the > number of SNMP GETNEXT reponses sent by the router considerably. The draft > standard MIB > is already widely deployed. But we need to deprecate an existing MIB and add > a new version, when it is required. I feel if everyone thinks what I pointed > out is a big advantange, still we can go ahead with this change. > > If the MAX-ACCESS of INDICES are put as read-only to include them in the > TRAP > notification messages, they can be changed as accessible-for-notify. Other > approach to > this is remove the INDICES from TRAP notification messages. For example if > you take the > case of IfStateChange TRAP, > > ospfIfStateChange NOTIFICATION-TYPE^M > OBJECTS { ospfRouterId, -- The originator of the trap^M > ospfIfIpAddress,^M > ospfAddressLessIf,^M > ospfIfState -- The new state^M > }^M > Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. When we > send TRAP > notification, we can just send ospfIfState. value>. . > Also I am not sure why ospfRouterId is included here. An NMS station can > always query ospfRouterId > separately. By removing these MIB objects, we can reduce the size and > processing time of TRAP > messages considerably. > > [OPEN issue] The above point is not addressed yet. > > Section : 4.3 Ignoring Initial Activity > --------------------------------------- > > [OPEN issue] This is not addressed yet. > > The section states "The majority of critical events occur when OSPF is > enabled on a > router, at which time the designated router is elected and neighbor > adjacencies are formed" . > I am not sure if enabling OSPF on a router means enabling it on an > interface. I think it will > be better to make the text clearer. > > Other statement is "To avoid unnecessary traps, a router should not > originate expected OSPF > interface related traps until two of that interface's dead timer intervals > have elapsed." > I think there will be some problems if the dead interval value is too long. > We may end up > not sending any of the expected TRAPS for a long time. Btw, could I please > know the reason > for selecting 2 * dead interval value for this purpose?. There might be some > case where an > interface is up and it goes down before (2 * dead interval). We can't take > it as an 'expected > event'. Probably we can ignore the expected events till the interface > reaches terminal state > (FULL or 2WAY) for the first time after enabling OSPF. > > > One more point is we are already limiting ospfIfStateChange, > ospfVirtIfStateChange, > ospfNbrStateChange and ospfVirtNbrStateChange notifications by generating > them only for terminal > state changes and backward tansition. Do we really need to ignore them > during the initial activity?. > > Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa traps > should not be originated > until two dead timer intervals have elapsed where the deadtimer interval > used should be the dead > timer with the smallest value." Here whats the meaning of "dead timer with > smallest value"? Is it > the smallest interval value among all the interfaces? > > > Section 4.4 Throttling Traps > ---------------------------- > > [OPEN issue] This is not addressed yet. > > Do we need to provide MIB objects corresponding to window size and the > number of TRAPs sent during > the window time? Will the TRAPs other than ospfTxRetransmit, OrginateLsa and > MaxAgeLsa really cause > a TRAP flood? Probably we need to throttle only the above three TRAPS? > > I think the normal practice is to inform the NMS using some other > notification at the end of a > particular interval when the TRAPs are dropped like this, "Trap N dropped n > times in an interval > t". We can add some common extra paratmeters to these notifications to > facilitate the NMS to query > the router to retrieve some values and find out whats happening. > > ospfConfigErrorType > ------------------- > > [OPEN issue] This is not addressed yet. > > Do we need an error type for duplicate router id in the received messages? > Some times loop back > address can be misconfigured. > > ospfSetTrap > ----------- > > [OPEN issue] This is not addressed yet. > > The definition of this is little complicated. Any reasons for going for last > bit to first. We think > its better to redefine this MIB object like this to make if more clear. > > cospfSetTrap OBJECT-TYPE > SYNTAX BITS { > ifConfigError (0), > virtIfConfigError (1), > ospfNbrStateChange (2), > . > . > . > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A One-octet string serving as a bit map for > the trap events defined by the OSPF traps in > this MIB. This object is used to enable and > disable specific OSPF traps where a 1 > in the corresponding bit field represents > enabled." > ::= { cospfTrapControl 1 } > > This definition enables the NMS to interpret the bit map easily. > > > ospfIfStateChange > ----------------- > [OPEN issue] This is not addressed yet. > > From the definition it looks like this TRAP should be generated only for > terminal states(when state > progresses) and for backward transition. Infact the name ospfIfStateChange > simply suggests to > generate TRAPs for all state transitions. The general tendency is to ignore > the DESCRIPTION when > "StateChange" is read and assume its for all the state changes. It might > lead to wrong > implementations. I think we can also follow the approach taken in BGP > MIB(rfc1657). > There they have notifications like this, > bgpEstablished NOTIFICATION-TYPE > OBJECTS { bgpPeerLastError, > bgpPeerState } > STATUS current > DESCRIPTION > "The BGP Established event is generated when > the BGP FSM enters the ESTABLISHED state." > ::= { bgpTraps 1 } > > bgpBackwardTransition NOTIFICATION-TYPE > OBJECTS { bgpPeerLastError, > bgpPeerState } > STATUS current > DESCRIPTION > "The BGPBackwardTransition Event is generated > when the BGP FSM moves from a higher numbered > state to a lower numbered state." > ::= { bgpTraps 2 } > > Our suggestion is to maintain ospfIfStateChange and use that for monitoring > all the states > (some people may want that) and additionally have notifications similar to > the BGP notifications. > Its also true with VirtIfStateChange, NbrStateChange and VirtNbrStateChange. > If somebody doesn't > want to see ALL state TRAPS, they can suppress them by turning off the > corresponding bit in > ospfSetTrap. > > > ospfNbrStateChange > ------------------ > > [OPEN issue] This is not addressed yet. > > The DECRIPTION clause states > "When an neighbor transitions from or to Full on non-broadcast multi-access > and broadcast > networks, the trap should be generated by the designated router. A > designated router > transitioning to Down will be noted by ospfIfStateChange." > I think here the intention is to reduce the number of TRAPs as much as > possible by making > only DR sending out this TRAP for a subnet. But there is a possibility that > osfpNbrStateChange > notification is disabled on DR and enabled on DR other or BDR. NMS won't > receive TRAPs when > NbrState becomes FULL in that case. There is a problem with the second part > of above statments > as well. Suppose ospfIfStateChange is disabled on the router, then again NMS > won't know when > neighbor goes down. Probably its better to remove these two clauses. > > Thanks, > Roy > > > > "Manral, Vishwas" wrote: > > > > > > Dan Joyal is at present working on the OSPFv2 MIB. > > > > And the OSPFv3 MIB as well. > > > > > > Thanks, > > Acee > > > > > > Thanks, > > > Vishwas > > > > > > -----Original Message----- > > > From: Roy Jose [mailto:rojose@CISCO.COM] > > > Sent: Tuesday, March 18, 2003 12:03 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: OSPFv2 MIB draft > > > > > > Hi Acee, > > > > > > I agree with you. Till it becomes a standard draft, vendors have to go > with > > > some proprietory MIB I guess. Btw, who is working on the MIB update > > > currently? > > > > > > Thanks, > > > Roy > > > > > > > One small correction. > > > > > > > > Acee Lindem wrote: > > > > > > > > > > Roy, > > > > > > > > > > There are 3 reasons why I don't think Sham Links should > > > > > be included in this MIB udpate: > > > > > > > > > > 1. I don't think they are sufficiently specified in the > > > > > Internet Draft describing them. My experience implementing > > > > > the Sham Link feature required some reverse > > > > > engineering (Consult RFC 1264 for specification > > > > > requirements). > > > > > 2. The document describing them is not an OSPF WG > > > > > document. In fact, it is not even an PPVPN > > > > > document (although it could become one). > > > > > 3. At some point, we have to close the door on adding > > > > > MIB variables that are in all the drafts that may or > > > > > may not ever reach draft standard status. If we don't > > > > ~~~~~~~~~~~~~~ > > > > Meant to say "proposed standard" here. > > > > > > > > > do this, we'll never finish the MIB update. > > > > > > > > > > Thanks, > > > > > Acee > > > > > > > > > > Roy Jose wrote: > > > > > > > > > > > > Thanks Jeff, Acee, Mani and John for your responses. How about > other > > > > > > points?:) > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "John Flick" > > > > > > To: > > > > > > Sent: Saturday, March 15, 2003 6:19 AM > > > > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > > > > > Yep, adding an index would require deprecating everything and > > > starting > > > > > > over. > > > > > > > Since this is an existing, widely deployed, Draft Standard MIB, > this > > > > > > should > > > > > > > not be done lightly. > > > > > > > > > > > > > > You would have the same problem if you tried changing MAX-ACCESS > on > > > the > > > > > > > table indices (as was also suggested below). Since a change to > > > MAX-ACCESS > > > > > > > of an existing object is not allowed, you would need to > deprecated > > > the > > > > > > index > > > > > > > objects, which would require deprecating the tables that they > index. > > > > > > Changing > > > > > > > to not-accessible is not required, since SMIv2 allows read-only > > > indices > > > > > > for > > > > > > > MIB modules that were translated from SMIv1 and therefore > already > > > had > > > > > > > read-only indices. The OSPFv2 MIB started life in RFC 1248 as > an > > > SMIv1 > > > > > > MIB > > > > > > > module, so this exception applies. > > > > > > > > > > > > How about tables which were added later?: ospfAreaAggregateTable, > > > > > > ExtLsdbTable, etc. > > > > > > My worry is not if its allowed or not. I am trying to point out > the > > > extra > > > > > > processing routers and > > > > > > NMS have to do with the increased number of messages. > > > > > > > > > > > > > As far as finding a generic solution for multiple instances of a > MIB > > > > > > module, > > > > > > > the standard solution is to use contexts (note: this is not the > same > > > as a > > > > > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was > done > > > in a > > > > > > > somewhat ad-hoc way by using different community names for each > > > instance > > > > > > > of the OSPF MIB. In SNMPv3, it is more formally defined using > the > > > > > > > contextName. The Entity MIB entLogicalTable (RFC 2737) provides > > > > > > information > > > > > > > about what contexts exist in an agent, and how to get to them. > > > > > > > > > > > > After having a glance at rfc2737, I also think this is the way. I > > > think we > > > > > > need to specify it clearly how it can be achieved using > > > entLogicalTable. For > > > > > > example, how we need to represent the SNMP community string to > > > retrieve info > > > > > > from a particular routing instance. > > > > > > > > > > > > Thanks, > > > > > > Roy > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > Acee Lindem wrote: > > > > > > > > > > > > > > > > Roy, > > > > > > > > > > > > > > > > I can appreciate your points since our product supports both > > > multiple > > > > > > > > virtual router instances and multiple routing protocol > instances > > > > > > > > within a particular virtual router. However, I think we'd > > > > > > > > essentially have to deprecate everything in the current MIB > and > > > define > > > > > > > > new tables in order to add OSPF instance ID as an index. Can > > > someone > > > > > > > > who has more MIB definition experience comment? > > > > > > > > > > > > > > > > Additionally, the multiple instance problem is not unique to > the > > > > > > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > > > > > > > > > > > Roy Jose wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I > > > would > > > > > > also like > > > > > > > > > to have some clarifications. Please see the attached > document. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Roy > > > > > > > > > > > > > > > > > > > > > > > > > > >>Yes. An update is in the works. > > > > > > > > >> > > > > > > > > >>-Dan > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>>-----Original Message----- > > > > > > > > >>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > > > > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > > > > > > >>>Subject: OSPFv2 MIB draft > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>>Hi all: > > > > > > > > >>>I would like to know the status of the working group > > > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows > an > > > > > > > > >>>expiry date of > > > > > > > > >>>May 2001. > > > > > > > > >>>Is there any plan to update the draft ? > > > > > > > > >>> > > > > > > > > >>>Thanks > > > > > > > > >>>Gargi > > > > > > > > >>> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > >>------------------------------------------------------------------------ > > > > > > > > >> > > > > > > > > >>Support for multiple OSPF processes: > > > > > > > > >>----------------------------------- > > > > > > > > >> > > > > > > > > >>We raised this issue some time back in WG. Currently MIB > > > supports only > > > > > > one Router ID. > > > > > > > > >>Multiple processes can have separate router IDs. It is also > true > > > with > > > > > > other MIB objects > > > > > > > > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The > solution > > > we > > > > > > got was to use a > > > > > > > > >>separate MIB view for each process. But I don't think it can > be > > > easily > > > > > > implemented. > > > > > > > > >>We suggest to form a new table to group scalar objects > related > > > to an > > > > > > OSPF process and have > > > > > > > > >>Process Id as its INDEX. We also suggest to add Process Id > as > > > one of > > > > > > the INDICES of all > > > > > > > > >>tables. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>MAX-ACCESS value for INDICES of TABLES: > > > > > > > > >>-------------------------------------- > > > > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. Normally > > > INDICES > > > > > > of a table are > > > > > > > > >>put as not-accesssible to reduce the number of SNMP > messages. > > > When an > > > > > > SNMP GET or > > > > > > > > >>GETNEXT is issued on a non-INDEX object, we can extract the > > > values of > > > > > > INDICES from > > > > > > > > >>the object ID returned. For example, let us consider > > > ospfAreaLsaCount. > > > > > > When we query > > > > > > > > >>the value for this, we get something like > > > ospfAreaLsaCount.0.0.0.1, > > > > > > where 0.0.0.1 is > > > > > > > > >>the AreaId, which is the INDEX of the ospfAreaTable. We can > > > extract > > > > > > the INDICES of > > > > > > > > >>table like this even if they are not-accessible. The tables > like > > > > > > LsdbTable has many > > > > > > > > >>number of INDICES and we can reduce the number of SNMP > messages > > > > > > considerably by changing > > > > > > > > >>them to not-accessible. > > > > > > > > >> > > > > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to include > > > them in > > > > > > the TRAP > > > > > > > > >>notification messages, they can be changed as > > > accessible-for-notify. > > > > > > Other approach to > > > > > > > > >>this is remove the INDICES from TRAP notification messages. > For > > > > > > example if you take the > > > > > > > > >>case of IfStateChange TRAP, > > > > > > > > >> > > > > > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > > > > > > >> OBJECTS { ospfRouterId, -- The originator of the > trap^M > > > > > > > > >> ospfIfIpAddress,^M > > > > > > > > >> ospfAddressLessIf,^M > > > > > > > > >> ospfIfState -- The new state^M > > > > > > > > >> }^M > > > > > > > > >>Here we don't actually need ospfIfIpAddress and > > > ospfAddressLessIf. > > > > > > When we send TRAP > > > > > > > > >>notification, we can just send ospfIfState. > > > > > value>. . > > > > > > > > >>Also I am not sure why ospfRouterId is included here. An NMS > > > station > > > > > > can always query ospfRouterId > > > > > > > > >>separately. By removing these MIB objects, we can reduce the > > > size and > > > > > > processing time of TRAP > > > > > > > > >>messages considerably. > > > > > > > > >> > > > > > > > > >>Section : 4.3 Ignoring Initial Activity > > > > > > > > >>--------------------------------------- > > > > > > > > >>The section states "The majority of critical events occur > when > > > OSPF is > > > > > > enabled on a > > > > > > > > >>router, at which time the designated router is elected and > > > neighbor > > > > > > adjacencies are formed" . > > > > > > > > >>I am not sure if enabling OSPF on a router means enabling it > on > > > an > > > > > > interface. I think it will > > > > > > > > >>be better to make the text clearer. > > > > > > > > >> > > > > > > > > >>Other statement is "To avoid unnecessary traps, a router > should > > > not > > > > > > originate expected OSPF > > > > > > > > >>interface related traps until two of that interface's dead > timer > > > > > > intervals have elapsed." > > > > > > > > >>I think there will be some problems if the dead interval > value > > > is too > > > > > > long. We may end up > > > > > > > > >>not sending any of the expected TRAPS for a long time. Btw, > > > could I > > > > > > please know the reason > > > > > > > > >>for selecting 2 * dead interval value for this purpose?. > There > > > might > > > > > > be some case where an > > > > > > > > >>interface is up and it goes down before (2 * dead interval). > We > > > can't > > > > > > take it as an 'expected > > > > > > > > >>event'. Probably we can ignore the expected events till the > > > interface > > > > > > reaches terminal state > > > > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>One more point is we are already limiting ospfIfStateChange, > > > > > > ospfVirtIfStateChange, > > > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange notifications > by > > > > > > generating them only for terminal > > > > > > > > >>state changes and backward tansition. Do we really need to > > > ignore them > > > > > > during the initial activity?. > > > > > > > > >> > > > > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and > > > ospfOriginateLsa > > > > > > traps should not be originated > > > > > > > > >>until two dead timer intervals have elapsed where the > deadtimer > > > > > > interval used should be the dead > > > > > > > > >>timer with the smallest value." Here whats the meaning of > "dead > > > timer > > > > > > with smallest value"? Is it > > > > > > > > >>the smallest interval value among all the interfaces? > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>Section 4.4 Throttling Traps > > > > > > > > >>---------------------------- > > > > > > > > >>Do we need to provide MIB objects corresponding to window > size > > > and the > > > > > > number of TRAPs sent during > > > > > > > > >>the window time? Will the TRAPs other than ospfTxRetransmit, > > > > > > OrginateLsa and MaxAgeLsa really cause > > > > > > > > >>a TRAP flood? Probably we need to throttle only the above > three > > > TRAPS? > > > > > > > > >> > > > > > > > > >>I think the normal practice is to inform the NMS using some > > > other > > > > > > notification at the end of a > > > > > > > > >>particular interval when the TRAPs are dropped like this, > "Trap > > > N > > > > > > dropped n times in an interval > > > > > > > > >>t". We can add some common extra paratmeters to these > > > notifications to > > > > > > facilitate the NMS to query > > > > > > > > >>the router to retrieve some values and find out whats > happening. > > > > > > > > >> > > > > > > > > >>ospfConfigErrorType > > > > > > > > >>------------------- > > > > > > > > >>Do we need an error type for duplicate router id in the > received > > > > > > messages? Some times loop back > > > > > > > > >>address can be misconfigured. > > > > > > > > >> > > > > > > > > >>ospfSetTrap > > > > > > > > >>----------- > > > > > > > > >>The definition of this is little complicated. Any reasons > for > > > going > > > > > > for last bit to first. We think > > > > > > > > >>its better to redefine this MIB object like this to make if > more > > > > > > clear. > > > > > > > > >> > > > > > > > > >> cospfSetTrap OBJECT-TYPE > > > > > > > > >> SYNTAX BITS { > > > > > > > > >> ifConfigError (0), > > > > > > > > >> virtIfConfigError (1), > > > > > > > > >> ospfNbrStateChange (2), > > > > > > > > >> . > > > > > > > > >> . > > > > > > > > >> . > > > > > > > > >> } > > > > > > > > >> MAX-ACCESS read-write > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "A One-octet string serving as a bit map for > > > > > > > > >> the trap events defined by the OSPF traps in > > > > > > > > >> this MIB. This object is used to enable and > > > > > > > > >> disable specific OSPF traps where a 1 > > > > > > > > >> in the corresponding bit field represents > > > > > > > > >> enabled." > > > > > > > > >> ::= { cospfTrapControl 1 } > > > > > > > > >> > > > > > > > > >>This definition enables the NMS to interpret the bit map > easily. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>ospfIfStateChange > > > > > > > > >>----------------- > > > > > > > > >> > > > > > > > > >>>From the definition it looks like this TRAP should be > generated > > > only > > > > > > for terminal states(when state > > > > > > > > >>progresses) and for backward transition. Infact the name > > > > > > ospfIfStateChange simply suggests to > > > > > > > > >>generate TRAPs for all state transitions. The general > tendency > > > is to > > > > > > ignore the DESCRIPTION when > > > > > > > > >>"StateChange" is read and assume its for all the state > changes. > > > It > > > > > > might lead to wrong > > > > > > > > >>implementations. I think we can also follow the approach > taken > > > in BGP > > > > > > MIB(rfc1657). > > > > > > > > >>There they have notifications like this, > > > > > > > > >> bgpEstablished NOTIFICATION-TYPE > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > >> bgpPeerState } > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "The BGP Established event is > > > generated > > > > > > when > > > > > > > > >> the BGP FSM enters the > ESTABLISHED > > > state." > > > > > > > > >> ::= { bgpTraps 1 } > > > > > > > > >> > > > > > > > > >> bgpBackwardTransition NOTIFICATION-TYPE > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > >> bgpPeerState } > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "The BGPBackwardTransition Event > is > > > > > > generated > > > > > > > > >> when the BGP FSM moves from a > higher > > > > > > numbered > > > > > > > > >> state to a lower numbered > state." > > > > > > > > >> ::= { bgpTraps 2 } > > > > > > > > >> > > > > > > > > >>Our suggestion is to maintain ospfIfStateChange and use that > for > > > > > > monitoring all the states > > > > > > > > >>(some people may want that) and additionally have > notifications > > > > > > similar to the BGP notifications. > > > > > > > > >>Its also true with VirtIfStateChange, NbrStateChange and > > > > > > VirtNbrStateChange. If somebody doesn't > > > > > > > > >>want to see ALL state TRAPS, they can suppress them by > turning > > > off the > > > > > > corresponding bit in > > > > > > > > >>ospfSetTrap. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>ospfNbrStateChange > > > > > > > > >>------------------ > > > > > > > > >>The DECRIPTION clause states > > > > > > > > >>"When an neighbor transitions from or to Full on > non-broadcast > > > > > > multi-access and broadcast > > > > > > > > >> networks, the trap should be generated by the designated > > > router. A > > > > > > designated router > > > > > > > > >>transitioning to Down will be noted by ospfIfStateChange." > > > > > > > > >>I think here the intention is to reduce the number of TRAPs > as > > > much as > > > > > > possible by making > > > > > > > > >>only DR sending out this TRAP for a subnet. But there is a > > > possibility > > > > > > that osfpNbrStateChange > > > > > > > > >>notification is disabled on DR and enabled on DR other or > BDR. > > > NMS > > > > > > won't receive TRAPs when > > > > > > > > >>NbrState becomes FULL in that case. There is a problem with > the > > > second > > > > > > part of above statments > > > > > > > > >>as well. Suppose ospfIfStateChange is disabled on the > router, > > > then > > > > > > again NMS won't know when > > > > > > > > >>neighbor goes down. Probably its better to remove these two > > > clauses. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>Support for sham links: > > > > > > > > >>----------------------- > > > > > > > > >>Are you going to provide support for sham links? We may need > > > these > > > > > > tables and notifications, > > > > > > > > >>ShamLinkTable > > > > > > > > >>ShamLinkNbrTable > > > > > > > > >>ShamLinkStateChange notification > > > > > > > > >>ShamLinkNbrStateChange notification > > > > > > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 19 08:27:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20570 for ; Wed, 19 Mar 2003 08:27:46 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.009387D6@cherry.ease.lsoft.com>; Wed, 19 Mar 2003 8:29:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665163 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 19 Mar 2003 08:29:59 -0500 Received: from 216.136.226.142 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Mar 2003 08:19:58 -0500 Received: from [203.200.20.226] by web20507.mail.yahoo.com via HTTP; Wed, 19 Mar 2003 13:19:55 GMT MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <20030319131956.22756.qmail@web20507.mail.yahoo.com> Date: Wed, 19 Mar 2003 13:19:55 +0000 Reply-To: Mailing List Sender: Mailing List From: =?iso-8859-1?q?John=20Smith?= Subject: draft-mirtorabi-ospfv3-af-00.txt and MOSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit How different is the draft-mirtorabi-ospfv3-af-00.txt from the existing MOSPF specifications given that i can advertise MULTICAST routes using the former. I can always use this new draft to advertise the different multicast routes and inject the best ones into the LSDB dedicated to the multicast RPF topology, run the SPF and use these best routes thus derived for RPF checks by other multicasting protocols. I am getting a little confused and would appreciate if somebody could help me out. TIA, Smith __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 19 09:58:11 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21798 for ; Wed, 19 Mar 2003 09:58:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00938EDD@cherry.ease.lsoft.com>; Wed, 19 Mar 2003 10:00:24 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665491 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 19 Mar 2003 10:00:23 -0500 Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Mar 2003 10:00:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 19 Mar 2003 10:00:20 -0500 Reply-To: Mailing List Sender: Mailing List From: Jeff Parker Subject: Re: OSPFv2 MIB draft Comments: cc: "Daniel Joyal (E-mail)" To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > Looks like Joyal's id is not reachable. try djoyal@nortelnetworks.com - jeff parker From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 19 11:23:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25035 for ; Wed, 19 Mar 2003 11:23:58 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00938F0A@cherry.ease.lsoft.com>; Wed, 19 Mar 2003 11:26:12 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665675 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 19 Mar 2003 11:26:11 -0500 Received: from 47.129.242.157 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Mar 2003 11:16:04 -0500 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2JGG1V03177 for ; Wed, 19 Mar 2003 11:16:01 -0500 (EST) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Mar 2003 11:16:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EE32.D463B578" Message-ID: <6204FDDE129D364D8040A98BCCB290EF0440AB37@zbl6c004.corpeast.baynetworks.com> Date: Wed, 19 Mar 2003 11:15:59 -0500 Reply-To: Mailing List Sender: Mailing List From: Daniel Joyal Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2EE32.D463B578 Content-Type: text/plain I am now back on the OSPF mailing list with my new e-mail address. -Dan > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Wednesday, March 19, 2003 10:00 AM > To: 'Mailing List' > Cc: Joyal, Daniel [BL60:0430:EXCH] > Subject: RE: OSPFv2 MIB draft > > > > > Looks like Joyal's id is not reachable. > > try > djoyal@nortelnetworks.com > > - jeff parker > ------_=_NextPart_001_01C2EE32.D463B578 Content-Type: text/html RE: OSPFv2 MIB draft

I am now back on the OSPF mailing list with
my new e-mail address.

-Dan

> -----Original Message-----
> From: Jeff Parker [mailto:jparker@axiowave.com]
> Sent: Wednesday, March 19, 2003 10:00 AM
> To: 'Mailing List'
> Cc: Joyal, Daniel [BL60:0430:EXCH]
> Subject: RE: OSPFv2 MIB draft
>
>
> 
> > Looks like Joyal's id is not reachable.
> 
> try
>       djoyal@nortelnetworks.com 
>
> - jeff parker
>

------_=_NextPart_001_01C2EE32.D463B578-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 19 12:58:54 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28110 for ; Wed, 19 Mar 2003 12:58:50 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00939397@cherry.ease.lsoft.com>; Wed, 19 Mar 2003 13:01:01 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665834 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 19 Mar 2003 13:01:00 -0500 Received: from 136.182.1.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Mar 2003 13:01:00 -0500 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2JI11EY015351 for ; Wed, 19 Mar 2003 11:01:01 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA10840 for ; Wed, 19 Mar 2003 10:58:47 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Mar 2003 13:00:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 19 Mar 2003 13:02:44 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Roy, I reread the OSPF-MIB and the issues you have. Though I do not know SNMP well, I will try to let you know my view of things. 1. I think the issue of multiple instance support can be clarified in the MIB. 2. Though I did observe that even in the ISIS-MIB, the MAX-ACCESS for indicies is set to not-accesible, I am not sure we would want to deprecate all the tables to get the slight benefit of saving SNMP messages. 3. I am not sure waiting for the neighbor to get to FULL state would be an appropriate solution either. There are cases where neighbor gets stuck in Exchange/Exstart state, we wouldn't be sending traps in that case either. 4. It can be done the way you say regarding the "throttling of traps", but I do not see such a major issue with this. 5. I think we can know of duplicate router ID, as the adjacency would not progress ahead of Exstart. 6. I think ok with any clarification. Thanks, Vishwas -----Original Message----- From: Roy Jose [mailto:rojose@CISCO.COM] Sent: Wednesday, March 19, 2003 6:05 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv2 MIB draft Thanks Manral, Acee. Let me point out the open issues here from the original document I sent. Joyal, please let me know if you need any clarifications. Support for multiple OSPF processes: ----------------------------------- We raised this issue some time back in WG. Currently MIB supports only one Router ID. Multiple processes can have separate router IDs. It is also true with other MIB objects like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we got was to use a separate MIB view for each process. But I don't think it can be easily implemented. We suggest to form a new table to group scalar objects related to an OSPF process and have Process Id as its INDEX. We also suggest to add Process Id as one of the INDICES of all tables. [WG - John Flick] As far as finding a generic solution for multiple instances of a MIB module, the standard solution is to use contexts (note: this is not the same as a MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done in a somewhat ad-hoc way by using different community names for each instance of the OSPF MIB. In SNMPv3, it is more formally defined using the contextName. The Entity MIB entLogicalTable (RFC 2737) provides information about what contexts exist in an agent, and how to get to them. [OPEN issue] I think we need to investigate on this and add a section to the draft how it can be applied to OSPF MIB . MAX-ACCESS value for INDICES of TABLES: -------------------------------------- I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES of a table are put as not-accesssible to reduce the number of SNMP messages. When an SNMP GET or GETNEXT is issued on a non-INDEX object, we can extract the values of INDICES from the object ID returned. For example, let us consider ospfAreaLsaCount. When we query the value for this, we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1 is the AreaId, which is the INDEX of the ospfAreaTable. We can extract the INDICES of table like this even if they are not-accessible. The tables like LsdbTable has many number of INDICES and we can reduce the number of SNMP messages considerably by changing them to not-accessible. [WG - John Flick] You would have the same problem if you tried changing MAX-ACCESS on the table indices (as was also suggested below). Since a change to MAX-ACCESS of an existing object is not allowed, you would need to deprecated the index objects, which would require deprecating the tables that they index. Changing to not-accessible is not required, since SMIv2 allows read-only indices for MIB modules that were translated from SMIv1 and therefore already had read-only indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 MIB module, so this exception applies. [OPEN issue] As I have pointed out earlier, by changing the INDICES we can reduce the number of SNMP GETNEXT reponses sent by the router considerably. The draft standard MIB is already widely deployed. But we need to deprecate an existing MIB and add a new version, when it is required. I feel if everyone thinks what I pointed out is a big advantange, still we can go ahead with this change. If the MAX-ACCESS of INDICES are put as read-only to include them in the TRAP notification messages, they can be changed as accessible-for-notify. Other approach to this is remove the INDICES from TRAP notification messages. For example if you take the case of IfStateChange TRAP, ospfIfStateChange NOTIFICATION-TYPE^M OBJECTS { ospfRouterId, -- The originator of the trap^M ospfIfIpAddress,^M ospfAddressLessIf,^M ospfIfState -- The new state^M }^M Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. When we send TRAP notification, we can just send ospfIfState.. . Also I am not sure why ospfRouterId is included here. An NMS station can always query ospfRouterId separately. By removing these MIB objects, we can reduce the size and processing time of TRAP messages considerably. [OPEN issue] The above point is not addressed yet. Section : 4.3 Ignoring Initial Activity --------------------------------------- [OPEN issue] This is not addressed yet. The section states "The majority of critical events occur when OSPF is enabled on a router, at which time the designated router is elected and neighbor adjacencies are formed" . I am not sure if enabling OSPF on a router means enabling it on an interface. I think it will be better to make the text clearer. Other statement is "To avoid unnecessary traps, a router should not originate expected OSPF interface related traps until two of that interface's dead timer intervals have elapsed." I think there will be some problems if the dead interval value is too long. We may end up not sending any of the expected TRAPS for a long time. Btw, could I please know the reason for selecting 2 * dead interval value for this purpose?. There might be some case where an interface is up and it goes down before (2 * dead interval). We can't take it as an 'expected event'. Probably we can ignore the expected events till the interface reaches terminal state (FULL or 2WAY) for the first time after enabling OSPF. One more point is we are already limiting ospfIfStateChange, ospfVirtIfStateChange, ospfNbrStateChange and ospfVirtNbrStateChange notifications by generating them only for terminal state changes and backward tansition. Do we really need to ignore them during the initial activity?. Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa traps should not be originated until two dead timer intervals have elapsed where the deadtimer interval used should be the dead timer with the smallest value." Here whats the meaning of "dead timer with smallest value"? Is it the smallest interval value among all the interfaces? Section 4.4 Throttling Traps ---------------------------- [OPEN issue] This is not addressed yet. Do we need to provide MIB objects corresponding to window size and the number of TRAPs sent during the window time? Will the TRAPs other than ospfTxRetransmit, OrginateLsa and MaxAgeLsa really cause a TRAP flood? Probably we need to throttle only the above three TRAPS? I think the normal practice is to inform the NMS using some other notification at the end of a particular interval when the TRAPs are dropped like this, "Trap N dropped n times in an interval t". We can add some common extra paratmeters to these notifications to facilitate the NMS to query the router to retrieve some values and find out whats happening. ospfConfigErrorType ------------------- [OPEN issue] This is not addressed yet. Do we need an error type for duplicate router id in the received messages? Some times loop back address can be misconfigured. ospfSetTrap ----------- [OPEN issue] This is not addressed yet. The definition of this is little complicated. Any reasons for going for last bit to first. We think its better to redefine this MIB object like this to make if more clear. cospfSetTrap OBJECT-TYPE SYNTAX BITS { ifConfigError (0), virtIfConfigError (1), ospfNbrStateChange (2), . . . } MAX-ACCESS read-write STATUS current DESCRIPTION "A One-octet string serving as a bit map for the trap events defined by the OSPF traps in this MIB. This object is used to enable and disable specific OSPF traps where a 1 in the corresponding bit field represents enabled." ::= { cospfTrapControl 1 } This definition enables the NMS to interpret the bit map easily. ospfIfStateChange ----------------- [OPEN issue] This is not addressed yet. From the definition it looks like this TRAP should be generated only for terminal states(when state progresses) and for backward transition. Infact the name ospfIfStateChange simply suggests to generate TRAPs for all state transitions. The general tendency is to ignore the DESCRIPTION when "StateChange" is read and assume its for all the state changes. It might lead to wrong implementations. I think we can also follow the approach taken in BGP MIB(rfc1657). There they have notifications like this, bgpEstablished NOTIFICATION-TYPE OBJECTS { bgpPeerLastError, bgpPeerState } STATUS current DESCRIPTION "The BGP Established event is generated when the BGP FSM enters the ESTABLISHED state." ::= { bgpTraps 1 } bgpBackwardTransition NOTIFICATION-TYPE OBJECTS { bgpPeerLastError, bgpPeerState } STATUS current DESCRIPTION "The BGPBackwardTransition Event is generated when the BGP FSM moves from a higher numbered state to a lower numbered state." ::= { bgpTraps 2 } Our suggestion is to maintain ospfIfStateChange and use that for monitoring all the states (some people may want that) and additionally have notifications similar to the BGP notifications. Its also true with VirtIfStateChange, NbrStateChange and VirtNbrStateChange. If somebody doesn't want to see ALL state TRAPS, they can suppress them by turning off the corresponding bit in ospfSetTrap. ospfNbrStateChange ------------------ [OPEN issue] This is not addressed yet. The DECRIPTION clause states "When an neighbor transitions from or to Full on non-broadcast multi-access and broadcast networks, the trap should be generated by the designated router. A designated router transitioning to Down will be noted by ospfIfStateChange." I think here the intention is to reduce the number of TRAPs as much as possible by making only DR sending out this TRAP for a subnet. But there is a possibility that osfpNbrStateChange notification is disabled on DR and enabled on DR other or BDR. NMS won't receive TRAPs when NbrState becomes FULL in that case. There is a problem with the second part of above statments as well. Suppose ospfIfStateChange is disabled on the router, then again NMS won't know when neighbor goes down. Probably its better to remove these two clauses. Thanks, Roy > "Manral, Vishwas" wrote: > > > > Dan Joyal is at present working on the OSPFv2 MIB. > > And the OSPFv3 MIB as well. > > > Thanks, > Acee > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Roy Jose [mailto:rojose@CISCO.COM] > > Sent: Tuesday, March 18, 2003 12:03 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: OSPFv2 MIB draft > > > > Hi Acee, > > > > I agree with you. Till it becomes a standard draft, vendors have to go with > > some proprietory MIB I guess. Btw, who is working on the MIB update > > currently? > > > > Thanks, > > Roy > > > > > One small correction. > > > > > > Acee Lindem wrote: > > > > > > > > Roy, > > > > > > > > There are 3 reasons why I don't think Sham Links should > > > > be included in this MIB udpate: > > > > > > > > 1. I don't think they are sufficiently specified in the > > > > Internet Draft describing them. My experience implementing > > > > the Sham Link feature required some reverse > > > > engineering (Consult RFC 1264 for specification > > > > requirements). > > > > 2. The document describing them is not an OSPF WG > > > > document. In fact, it is not even an PPVPN > > > > document (although it could become one). > > > > 3. At some point, we have to close the door on adding > > > > MIB variables that are in all the drafts that may or > > > > may not ever reach draft standard status. If we don't > > > ~~~~~~~~~~~~~~ > > > Meant to say "proposed standard" here. > > > > > > > do this, we'll never finish the MIB update. > > > > > > > > Thanks, > > > > Acee > > > > > > > > Roy Jose wrote: > > > > > > > > > > Thanks Jeff, Acee, Mani and John for your responses. How about other > > > > > points?:) > > > > > > > > > > ----- Original Message ----- > > > > > From: "John Flick" > > > > > To: > > > > > Sent: Saturday, March 15, 2003 6:19 AM > > > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > > > Yep, adding an index would require deprecating everything and > > starting > > > > > over. > > > > > > Since this is an existing, widely deployed, Draft Standard MIB, this > > > > > should > > > > > > not be done lightly. > > > > > > > > > > > > You would have the same problem if you tried changing MAX-ACCESS on > > the > > > > > > table indices (as was also suggested below). Since a change to > > MAX-ACCESS > > > > > > of an existing object is not allowed, you would need to deprecated > > the > > > > > index > > > > > > objects, which would require deprecating the tables that they index. > > > > > Changing > > > > > > to not-accessible is not required, since SMIv2 allows read-only > > indices > > > > > for > > > > > > MIB modules that were translated from SMIv1 and therefore already > > had > > > > > > read-only indices. The OSPFv2 MIB started life in RFC 1248 as an > > SMIv1 > > > > > MIB > > > > > > module, so this exception applies. > > > > > > > > > > How about tables which were added later?: ospfAreaAggregateTable, > > > > > ExtLsdbTable, etc. > > > > > My worry is not if its allowed or not. I am trying to point out the > > extra > > > > > processing routers and > > > > > NMS have to do with the increased number of messages. > > > > > > > > > > > As far as finding a generic solution for multiple instances of a MIB > > > > > module, > > > > > > the standard solution is to use contexts (note: this is not the same > > as a > > > > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done > > in a > > > > > > somewhat ad-hoc way by using different community names for each > > instance > > > > > > of the OSPF MIB. In SNMPv3, it is more formally defined using the > > > > > > contextName. The Entity MIB entLogicalTable (RFC 2737) provides > > > > > information > > > > > > about what contexts exist in an agent, and how to get to them. > > > > > > > > > > After having a glance at rfc2737, I also think this is the way. I > > think we > > > > > need to specify it clearly how it can be achieved using > > entLogicalTable. For > > > > > example, how we need to represent the SNMP community string to > > retrieve info > > > > > from a particular routing instance. > > > > > > > > > > Thanks, > > > > > Roy > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > Acee Lindem wrote: > > > > > > > > > > > > > > Roy, > > > > > > > > > > > > > > I can appreciate your points since our product supports both > > multiple > > > > > > > virtual router instances and multiple routing protocol instances > > > > > > > within a particular virtual router. However, I think we'd > > > > > > > essentially have to deprecate everything in the current MIB and > > define > > > > > > > new tables in order to add OSPF instance ID as an index. Can > > someone > > > > > > > who has more MIB definition experience comment? > > > > > > > > > > > > > > Additionally, the multiple instance problem is not unique to the > > > > > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > > > > > > > > > Roy Jose wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I > > would > > > > > also like > > > > > > > > to have some clarifications. Please see the attached document. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Roy > > > > > > > > > > > > > > > > > > > > > > > >>Yes. An update is in the works. > > > > > > > >> > > > > > > > >>-Dan > > > > > > > >> > > > > > > > >> > > > > > > > >>>-----Original Message----- > > > > > > > >>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > > > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > > > > > >>>Subject: OSPFv2 MIB draft > > > > > > > >>> > > > > > > > >>> > > > > > > > >>>Hi all: > > > > > > > >>>I would like to know the status of the working group > > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows an > > > > > > > >>>expiry date of > > > > > > > >>>May 2001. > > > > > > > >>>Is there any plan to update the draft ? > > > > > > > >>> > > > > > > > >>>Thanks > > > > > > > >>>Gargi > > > > > > > >>> > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > >>------------------------------------------------------------------------ > > > > > > > >> > > > > > > > >>Support for multiple OSPF processes: > > > > > > > >>----------------------------------- > > > > > > > >> > > > > > > > >>We raised this issue some time back in WG. Currently MIB > > supports only > > > > > one Router ID. > > > > > > > >>Multiple processes can have separate router IDs. It is also true > > with > > > > > other MIB objects > > > > > > > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution > > we > > > > > got was to use a > > > > > > > >>separate MIB view for each process. But I don't think it can be > > easily > > > > > implemented. > > > > > > > >>We suggest to form a new table to group scalar objects related > > to an > > > > > OSPF process and have > > > > > > > >>Process Id as its INDEX. We also suggest to add Process Id as > > one of > > > > > the INDICES of all > > > > > > > >>tables. > > > > > > > >> > > > > > > > >> > > > > > > > >>MAX-ACCESS value for INDICES of TABLES: > > > > > > > >>-------------------------------------- > > > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. Normally > > INDICES > > > > > of a table are > > > > > > > >>put as not-accesssible to reduce the number of SNMP messages. > > When an > > > > > SNMP GET or > > > > > > > >>GETNEXT is issued on a non-INDEX object, we can extract the > > values of > > > > > INDICES from > > > > > > > >>the object ID returned. For example, let us consider > > ospfAreaLsaCount. > > > > > When we query > > > > > > > >>the value for this, we get something like > > ospfAreaLsaCount.0.0.0.1, > > > > > where 0.0.0.1 is > > > > > > > >>the AreaId, which is the INDEX of the ospfAreaTable. We can > > extract > > > > > the INDICES of > > > > > > > >>table like this even if they are not-accessible. The tables like > > > > > LsdbTable has many > > > > > > > >>number of INDICES and we can reduce the number of SNMP messages > > > > > considerably by changing > > > > > > > >>them to not-accessible. > > > > > > > >> > > > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to include > > them in > > > > > the TRAP > > > > > > > >>notification messages, they can be changed as > > accessible-for-notify. > > > > > Other approach to > > > > > > > >>this is remove the INDICES from TRAP notification messages. For > > > > > example if you take the > > > > > > > >>case of IfStateChange TRAP, > > > > > > > >> > > > > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > > > > > >> OBJECTS { ospfRouterId, -- The originator of the trap^M > > > > > > > >> ospfIfIpAddress,^M > > > > > > > >> ospfAddressLessIf,^M > > > > > > > >> ospfIfState -- The new state^M > > > > > > > >> }^M > > > > > > > >>Here we don't actually need ospfIfIpAddress and > > ospfAddressLessIf. > > > > > When we send TRAP > > > > > > > >>notification, we can just send ospfIfState. > > > > value>. . > > > > > > > >>Also I am not sure why ospfRouterId is included here. An NMS > > station > > > > > can always query ospfRouterId > > > > > > > >>separately. By removing these MIB objects, we can reduce the > > size and > > > > > processing time of TRAP > > > > > > > >>messages considerably. > > > > > > > >> > > > > > > > >>Section : 4.3 Ignoring Initial Activity > > > > > > > >>--------------------------------------- > > > > > > > >>The section states "The majority of critical events occur when > > OSPF is > > > > > enabled on a > > > > > > > >>router, at which time the designated router is elected and > > neighbor > > > > > adjacencies are formed" . > > > > > > > >>I am not sure if enabling OSPF on a router means enabling it on > > an > > > > > interface. I think it will > > > > > > > >>be better to make the text clearer. > > > > > > > >> > > > > > > > >>Other statement is "To avoid unnecessary traps, a router should > > not > > > > > originate expected OSPF > > > > > > > >>interface related traps until two of that interface's dead timer > > > > > intervals have elapsed." > > > > > > > >>I think there will be some problems if the dead interval value > > is too > > > > > long. We may end up > > > > > > > >>not sending any of the expected TRAPS for a long time. Btw, > > could I > > > > > please know the reason > > > > > > > >>for selecting 2 * dead interval value for this purpose?. There > > might > > > > > be some case where an > > > > > > > >>interface is up and it goes down before (2 * dead interval). We > > can't > > > > > take it as an 'expected > > > > > > > >>event'. Probably we can ignore the expected events till the > > interface > > > > > reaches terminal state > > > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > > > > > >> > > > > > > > >> > > > > > > > >>One more point is we are already limiting ospfIfStateChange, > > > > > ospfVirtIfStateChange, > > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange notifications by > > > > > generating them only for terminal > > > > > > > >>state changes and backward tansition. Do we really need to > > ignore them > > > > > during the initial activity?. > > > > > > > >> > > > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and > > ospfOriginateLsa > > > > > traps should not be originated > > > > > > > >>until two dead timer intervals have elapsed where the deadtimer > > > > > interval used should be the dead > > > > > > > >>timer with the smallest value." Here whats the meaning of "dead > > timer > > > > > with smallest value"? Is it > > > > > > > >>the smallest interval value among all the interfaces? > > > > > > > >> > > > > > > > >> > > > > > > > >>Section 4.4 Throttling Traps > > > > > > > >>---------------------------- > > > > > > > >>Do we need to provide MIB objects corresponding to window size > > and the > > > > > number of TRAPs sent during > > > > > > > >>the window time? Will the TRAPs other than ospfTxRetransmit, > > > > > OrginateLsa and MaxAgeLsa really cause > > > > > > > >>a TRAP flood? Probably we need to throttle only the above three > > TRAPS? > > > > > > > >> > > > > > > > >>I think the normal practice is to inform the NMS using some > > other > > > > > notification at the end of a > > > > > > > >>particular interval when the TRAPs are dropped like this, "Trap > > N > > > > > dropped n times in an interval > > > > > > > >>t". We can add some common extra paratmeters to these > > notifications to > > > > > facilitate the NMS to query > > > > > > > >>the router to retrieve some values and find out whats happening. > > > > > > > >> > > > > > > > >>ospfConfigErrorType > > > > > > > >>------------------- > > > > > > > >>Do we need an error type for duplicate router id in the received > > > > > messages? Some times loop back > > > > > > > >>address can be misconfigured. > > > > > > > >> > > > > > > > >>ospfSetTrap > > > > > > > >>----------- > > > > > > > >>The definition of this is little complicated. Any reasons for > > going > > > > > for last bit to first. We think > > > > > > > >>its better to redefine this MIB object like this to make if more > > > > > clear. > > > > > > > >> > > > > > > > >> cospfSetTrap OBJECT-TYPE > > > > > > > >> SYNTAX BITS { > > > > > > > >> ifConfigError (0), > > > > > > > >> virtIfConfigError (1), > > > > > > > >> ospfNbrStateChange (2), > > > > > > > >> . > > > > > > > >> . > > > > > > > >> . > > > > > > > >> } > > > > > > > >> MAX-ACCESS read-write > > > > > > > >> STATUS current > > > > > > > >> DESCRIPTION > > > > > > > >> "A One-octet string serving as a bit map for > > > > > > > >> the trap events defined by the OSPF traps in > > > > > > > >> this MIB. This object is used to enable and > > > > > > > >> disable specific OSPF traps where a 1 > > > > > > > >> in the corresponding bit field represents > > > > > > > >> enabled." > > > > > > > >> ::= { cospfTrapControl 1 } > > > > > > > >> > > > > > > > >>This definition enables the NMS to interpret the bit map easily. > > > > > > > >> > > > > > > > >> > > > > > > > >>ospfIfStateChange > > > > > > > >>----------------- > > > > > > > >> > > > > > > > >>>From the definition it looks like this TRAP should be generated > > only > > > > > for terminal states(when state > > > > > > > >>progresses) and for backward transition. Infact the name > > > > > ospfIfStateChange simply suggests to > > > > > > > >>generate TRAPs for all state transitions. The general tendency > > is to > > > > > ignore the DESCRIPTION when > > > > > > > >>"StateChange" is read and assume its for all the state changes. > > It > > > > > might lead to wrong > > > > > > > >>implementations. I think we can also follow the approach taken > > in BGP > > > > > MIB(rfc1657). > > > > > > > >>There they have notifications like this, > > > > > > > >> bgpEstablished NOTIFICATION-TYPE > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > >> bgpPeerState } > > > > > > > >> STATUS current > > > > > > > >> DESCRIPTION > > > > > > > >> "The BGP Established event is > > generated > > > > > when > > > > > > > >> the BGP FSM enters the ESTABLISHED > > state." > > > > > > > >> ::= { bgpTraps 1 } > > > > > > > >> > > > > > > > >> bgpBackwardTransition NOTIFICATION-TYPE > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > >> bgpPeerState } > > > > > > > >> STATUS current > > > > > > > >> DESCRIPTION > > > > > > > >> "The BGPBackwardTransition Event is > > > > > generated > > > > > > > >> when the BGP FSM moves from a higher > > > > > numbered > > > > > > > >> state to a lower numbered state." > > > > > > > >> ::= { bgpTraps 2 } > > > > > > > >> > > > > > > > >>Our suggestion is to maintain ospfIfStateChange and use that for > > > > > monitoring all the states > > > > > > > >>(some people may want that) and additionally have notifications > > > > > similar to the BGP notifications. > > > > > > > >>Its also true with VirtIfStateChange, NbrStateChange and > > > > > VirtNbrStateChange. If somebody doesn't > > > > > > > >>want to see ALL state TRAPS, they can suppress them by turning > > off the > > > > > corresponding bit in > > > > > > > >>ospfSetTrap. > > > > > > > >> > > > > > > > >> > > > > > > > >>ospfNbrStateChange > > > > > > > >>------------------ > > > > > > > >>The DECRIPTION clause states > > > > > > > >>"When an neighbor transitions from or to Full on non-broadcast > > > > > multi-access and broadcast > > > > > > > >> networks, the trap should be generated by the designated > > router. A > > > > > designated router > > > > > > > >>transitioning to Down will be noted by ospfIfStateChange." > > > > > > > >>I think here the intention is to reduce the number of TRAPs as > > much as > > > > > possible by making > > > > > > > >>only DR sending out this TRAP for a subnet. But there is a > > possibility > > > > > that osfpNbrStateChange > > > > > > > >>notification is disabled on DR and enabled on DR other or BDR. > > NMS > > > > > won't receive TRAPs when > > > > > > > >>NbrState becomes FULL in that case. There is a problem with the > > second > > > > > part of above statments > > > > > > > >>as well. Suppose ospfIfStateChange is disabled on the router, > > then > > > > > again NMS won't know when > > > > > > > >>neighbor goes down. Probably its better to remove these two > > clauses. > > > > > > > >> > > > > > > > >> > > > > > > > >>Support for sham links: > > > > > > > >>----------------------- > > > > > > > >>Are you going to provide support for sham links? We may need > > these > > > > > tables and notifications, > > > > > > > >>ShamLinkTable > > > > > > > >>ShamLinkNbrTable > > > > > > > >>ShamLinkStateChange notification > > > > > > > >>ShamLinkNbrStateChange notification > > > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 19 14:30:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02419 for ; Wed, 19 Mar 2003 14:30:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0093952B@cherry.ease.lsoft.com>; Wed, 19 Mar 2003 14:33:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666048 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 19 Mar 2003 14:33:10 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Mar 2003 14:33:10 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15544 for ; Wed, 19 Mar 2003 14:33:07 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA11852 for ; Wed, 19 Mar 2003 14:33:09 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Mar 2003 14:33:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC5576353F@vie-msgusr-01.dc.fore.com> Date: Wed, 19 Mar 2003 14:33:07 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -> . . . One of the main motivations for -> the OSPFv2 opaque LSA was to solve the problem of how to get -> LSAs flooded -> w/o every router in the OSPF routing domain understanding all the -> opaque LSAs types. In OSPFv3, flooding of unknown LSA types -> is handled explicitly - this obviates the requirement for -> opaque LSAs. I think I heard these misconception about opaque LSAs quite few times now. Let me explain about the history of Opaque LSAs. When Rob was here in this group, the main motivation was to extend OSPF for the continuing extensions. Which he felt must be done in a simple, elegant way (around May 1997 the first draft was out). Along with Juha, Rob wrote first use of opaque LSAs to resolve ATM addresses (which never standardized). The initial Opaque LSAs draft reads: ... As a result of this deployment and the evolution of networking technology, OSPF has been extended to support many options; this evolution will obviously continue. This memo documents enhancements to the OSPF protocol to support a new type of link-state advertisement (LSA) called the Opaque LSA which defines an optional generalized mechanism to allow for future extensi- bility of OSPF. The information contained in Opaque LSAs may be used directly by OSPF or by other protocols. ^^^^^^^^^^^^^^^^^^ For example, the OSPF LSA may be used to distribute BGP AS Path information (as documented in The OSPF External Attributes LSA which is then used by BGP route-leaking mechanisms. The option may also be used to distribute IP QoS information which may be used directly by an OSPF path computation. The exact use of the Opaque LSA is beyond the scope of this draft. ... The main motivation is not about OSPFv2 "flooding problems" because other routers are not able to decode those LSAs. The main motivation is "How best other protocols/applications can make use of OSPF reliable flooding mechanisms instead of extending LSAs for each and every applications requirements?". More over in v2, all the LSAs are tightly encoded and difficult to piggyback the information. OSPFv2 required some way of TLV encoded LSAs. Draw a "clear-cut line" between the *LSA types* which are being used by OSPF for internal use (Hop-by-Hop Routing, flooding etc) _and_ the LSAs which are not used by OSPF protocol at all. That clear-cut line is named as "Opaque LSAs". I heard quite few times that other applications are re-using parser code in OSPF etc etc...NO...the applications are using the OSPF reliable flooding mechanism (which is somewhere in between connection less IP/UDP/DCCP and connection oriented TCP/SCTP) Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 19 17:20:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12242 for ; Wed, 19 Mar 2003 17:20:00 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00939CFB@cherry.ease.lsoft.com>; Wed, 19 Mar 2003 17:22:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666814 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 19 Mar 2003 17:22:03 -0500 Received: from 47.129.242.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Mar 2003 17:22:03 -0500 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2JMM1605056 for ; Wed, 19 Mar 2003 17:22:01 -0500 (EST) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Mar 2003 17:22:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EE65.F5942BD2" Message-ID: <6204FDDE129D364D8040A98BCCB290EF0440AB3D@zbl6c004.corpeast.baynetworks.com> Date: Wed, 19 Mar 2003 17:21:59 -0500 Reply-To: Mailing List Sender: Mailing List From: Daniel Joyal Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2EE65.F5942BD2 Content-Type: text/plain Comments in-line below. -Dan > -----Original Message----- > From: Roy Jose [mailto:rojose@CISCO.COM] > Sent: Wednesday, March 19, 2003 6:05 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPFv2 MIB draft > > > Thanks Manral, Acee. > > Let me point out the open issues here from the original > document I sent. Joyal, please let me know if you need any > clarifications. > > Support for multiple OSPF processes: > ----------------------------------- > > We raised this issue some time back in WG. Currently MIB > supports only one Router ID. Multiple processes can have > separate router IDs. It is also true with other MIB objects > like ospfExternLsaCount, ospfExternLsaCksumSum etc. The > solution we got was to use a separate MIB view for each > process. But I don't think it can be easily implemented. We > suggest to form a new table to group scalar objects related > to an OSPF process and have Process Id as its INDEX. We also > suggest to add Process Id as one of the INDICES of all > tables. [WG - John Flick] As far as finding a generic > solution for multiple instances of a MIB module, the standard > solution is to use contexts (note: this is not the same as a > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was > done in a somewhat ad-hoc way by using different community > names for each instance of the OSPF MIB. In SNMPv3, it is > more formally defined using the contextName. The Entity MIB > entLogicalTable (RFC 2737) provides information about what > contexts exist in an agent, and how to get to them. [OPEN > issue] I think we need to investigate on this and add a > section to the draft how it can be applied to OSPF MIB . > This issue is not unique to the OSPF MIBs. I would prefer to just reference the RFCs that deal with SNMP contexts that John Flick mentioned. > > MAX-ACCESS value for INDICES of TABLES: > -------------------------------------- > I see MAX-ACCESS value of all TABLEs are read-only. Normally > INDICES of a table are put as not-accesssible to reduce the > number of SNMP messages. When an SNMP GET or GETNEXT is > issued on a non-INDEX object, we can extract the values of > INDICES from the object ID returned. For example, let us > consider ospfAreaLsaCount. When we query the value for this, > we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1 > is the AreaId, which is the INDEX of the ospfAreaTable. We > can extract the INDICES of table like this even if they are > not-accessible. The tables like LsdbTable has many number of > INDICES and we can reduce the number of SNMP messages > considerably by changing them to not-accessible. > > [WG - John Flick] > You would have the same problem if you tried changing > MAX-ACCESS on the table indices (as was also suggested > below). Since a change to MAX-ACCESS of an existing object > is not allowed, you would need to deprecated the index > objects, which would require deprecating the tables that they > index. Changing to not-accessible is not required, since > SMIv2 allows read-only indices for MIB modules that were > translated from SMIv1 and therefore already had read-only > indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 > MIB module, so this exception applies. > > [OPEN issue] > As I have pointed out earlier, by changing the INDICES we can > reduce the number of SNMP GETNEXT reponses sent by the > router considerably. The draft standard MIB is already widely > deployed. But we need to deprecate an existing MIB and add a > new version, when it is required. I feel if everyone thinks > what I pointed out is a big advantange, still we can go ahead > with this change. > > If the MAX-ACCESS of INDICES are put as read-only to include > them in the TRAP notification messages, they can be changed > as accessible-for-notify. Other approach to this is remove > the INDICES from TRAP notification messages. For example if > you take the case of IfStateChange TRAP, > > ospfIfStateChange NOTIFICATION-TYPE^M > OBJECTS { ospfRouterId, -- The originator of the trap^M > ospfIfIpAddress,^M > ospfAddressLessIf,^M > ospfIfState -- The new state^M > }^M > Here we don't actually need ospfIfIpAddress and > ospfAddressLessIf. When we send TRAP notification, we can > just send ospfIfState. value>. . > Also I am not sure why ospfRouterId is included here. An NMS > station can always query ospfRouterId separately. By removing > these MIB objects, we can reduce the size and processing time > of TRAP messages considerably. > > [OPEN issue] The above point is not addressed yet. > I think there would need to be a strong WG consensus that deprecating the entire MIB for this is worth it. > Section : 4.3 Ignoring Initial Activity > --------------------------------------- > > [OPEN issue] This is not addressed yet. > > The section states "The majority of critical events occur > when OSPF is enabled on a router, at which time the > designated router is elected and neighbor adjacencies are > formed" . I am not sure if enabling OSPF on a router means > enabling it on an interface. I think it will be better to > make the text clearer. > > Other statement is "To avoid unnecessary traps, a router > should not originate expected OSPF interface related traps > until two of that interface's dead timer intervals have > elapsed." I think there will be some problems if the dead > interval value is too long. We may end up not sending any of > the expected TRAPS for a long time. Btw, could I please know > the reason for selecting 2 * dead interval value for this > purpose?. There might be some case where an interface is up > and it goes down before (2 * dead interval). We can't take it > as an 'expected event'. Probably we can ignore the expected > events till the interface reaches terminal state (FULL or > 2WAY) for the first time after enabling OSPF. > > > One more point is we are already limiting ospfIfStateChange, > ospfVirtIfStateChange, ospfNbrStateChange and > ospfVirtNbrStateChange notifications by generating them only > for terminal state changes and backward tansition. Do we > really need to ignore them during the initial activity?. > > Other statement is "Additionally, ospfMaxAgeLsa and > ospfOriginateLsa traps should not be originated until two > dead timer intervals have elapsed where the deadtimer > interval used should be the dead timer with the smallest > value." Here whats the meaning of "dead timer with smallest > value"? Is it the smallest interval value among all the interfaces? > I think the intent of the original authors of the MIB was to give some guidelines (hence the wording "should not" rather than "must not") for when or when not to generate traps. I don't know how closely real world implementations follow these guidelines. > > Section 4.4 Throttling Traps > ---------------------------- > > [OPEN issue] This is not addressed yet. > > Do we need to provide MIB objects corresponding to window > size and the number of TRAPs sent during the window time? > Will the TRAPs other than ospfTxRetransmit, OrginateLsa and > MaxAgeLsa really cause a TRAP flood? Probably we need to > throttle only the above three TRAPS? > > I think the normal practice is to inform the NMS using some > other notification at the end of a particular interval when > the TRAPs are dropped like this, "Trap N dropped n times in > an interval t". We can add some common extra paratmeters to > these notifications to facilitate the NMS to query the router > to retrieve some values and find out whats happening. > > ospfConfigErrorType > ------------------- > > [OPEN issue] This is not addressed yet. > > Do we need an error type for duplicate router id in the > received messages? Some times loop back address can be misconfigured. Easy to add if required. > > ospfSetTrap > ----------- > > [OPEN issue] This is not addressed yet. > > The definition of this is little complicated. Any reasons for > going for last bit to first. We think its better to redefine > this MIB object like this to make if more clear. > > cospfSetTrap OBJECT-TYPE > SYNTAX BITS { > ifConfigError (0), > virtIfConfigError (1), > ospfNbrStateChange (2), > . > . > . > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A One-octet string serving as a bit map for > the trap events defined by the OSPF traps in > this MIB. This object is used to enable and > disable specific OSPF traps where a 1 > in the corresponding bit field represents > enabled." > ::= { cospfTrapControl 1 } > > This definition enables the NMS to interpret the bit map easily. Changing to a non-equivalent syntax would require creation of a new object. > > > ospfIfStateChange > ----------------- > [OPEN issue] This is not addressed yet. > > From the definition it looks like this TRAP should be > generated only for terminal states(when state > progresses) and for backward transition. Infact the name > ospfIfStateChange simply suggests to generate TRAPs for all > state transitions. The general tendency is to ignore the > DESCRIPTION when "StateChange" is read and assume its for all > the state changes. It might lead to wrong implementations. I > think we can also follow the approach taken in BGP > MIB(rfc1657). There they have notifications like this, > bgpEstablished NOTIFICATION-TYPE > OBJECTS { bgpPeerLastError, > bgpPeerState } > STATUS current > DESCRIPTION > "The BGP Established event is > generated when > the BGP FSM enters the ESTABLISHED state." > ::= { bgpTraps 1 } > > bgpBackwardTransition NOTIFICATION-TYPE > OBJECTS { bgpPeerLastError, > bgpPeerState } > STATUS current > DESCRIPTION > "The BGPBackwardTransition Event > is generated > when the BGP FSM moves from a > higher numbered > state to a lower numbered state." > ::= { bgpTraps 2 } > > Our suggestion is to maintain ospfIfStateChange and use that > for monitoring all the states (some people may want that) and > additionally have notifications similar to the BGP > notifications. Its also true with VirtIfStateChange, > NbrStateChange and VirtNbrStateChange. If somebody doesn't > want to see ALL state TRAPS, they can suppress them by > turning off the corresponding bit in ospfSetTrap. > OK. Could you list the new BGP-like notifications for OSPF? > > ospfNbrStateChange > ------------------ > > [OPEN issue] This is not addressed yet. > > The DECRIPTION clause states > "When an neighbor transitions from or to Full on > non-broadcast multi-access and broadcast networks, the trap > should be generated by the designated router. A designated > router transitioning to Down will be noted by > ospfIfStateChange." I think here the intention is to reduce > the number of TRAPs as much as possible by making only DR > sending out this TRAP for a subnet. But there is a > possibility that osfpNbrStateChange notification is disabled > on DR and enabled on DR other or BDR. NMS won't receive TRAPs > when NbrState becomes FULL in that case. There is a problem > with the second part of above statments as well. Suppose > ospfIfStateChange is disabled on the router, then again NMS > won't know when neighbor goes down. Probably its better to > remove these two clauses. > > Thanks, > Roy > > > > "Manral, Vishwas" wrote: > > > > > > Dan Joyal is at present working on the OSPFv2 MIB. > > > > And the OSPFv3 MIB as well. > > > > > > Thanks, > > Acee > > > > > > Thanks, > > > Vishwas > > > > > > -----Original Message----- > > > From: Roy Jose [mailto:rojose@CISCO.COM] > > > Sent: Tuesday, March 18, 2003 12:03 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: OSPFv2 MIB draft > > > > > > Hi Acee, > > > > > > I agree with you. Till it becomes a standard draft, > vendors have to > > > go > with > > > some proprietory MIB I guess. Btw, who is working on the > MIB update > > > currently? > > > > > > Thanks, > > > Roy > > > > > > > One small correction. > > > > > > > > Acee Lindem wrote: > > > > > > > > > > Roy, > > > > > > > > > > There are 3 reasons why I don't think Sham Links should be > > > > > included in this MIB udpate: > > > > > > > > > > 1. I don't think they are sufficiently specified in the > > > > > Internet Draft describing them. My experience > implementing > > > > > the Sham Link feature required some reverse > > > > > engineering (Consult RFC 1264 for specification > > > > > requirements). > > > > > 2. The document describing them is not an OSPF WG > > > > > document. In fact, it is not even an PPVPN > > > > > document (although it could become one). > > > > > 3. At some point, we have to close the door on adding > > > > > MIB variables that are in all the drafts that may or > > > > > may not ever reach draft standard status. If we don't > > > > ~~~~~~~~~~~~~~ > > > > Meant to say "proposed standard" here. > > > > > > > > > do this, we'll never finish the MIB update. > > > > > > > > > > Thanks, > > > > > Acee > > > > > > > > > > Roy Jose wrote: > > > > > > > > > > > > Thanks Jeff, Acee, Mani and John for your responses. How > > > > > > about > other > > > > > > points?:) > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "John Flick" > > > > > > To: > > > > > > Sent: Saturday, March 15, 2003 6:19 AM > > > > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > > > > > Yep, adding an index would require deprecating everything > > > > > > > and > > > starting > > > > > > over. > > > > > > > Since this is an existing, widely deployed, Draft > Standard > > > > > > > MIB, > this > > > > > > should > > > > > > > not be done lightly. > > > > > > > > > > > > > > You would have the same problem if you tried changing > > > > > > > MAX-ACCESS > on > > > the > > > > > > > table indices (as was also suggested below). > Since a change > > > > > > > to > > > MAX-ACCESS > > > > > > > of an existing object is not allowed, you would need to > deprecated > > > the > > > > > > index > > > > > > > objects, which would require deprecating the tables that > > > > > > > they > index. > > > > > > Changing > > > > > > > to not-accessible is not required, since SMIv2 allows > > > > > > > read-only > > > indices > > > > > > for > > > > > > > MIB modules that were translated from SMIv1 and therefore > already > > > had > > > > > > > read-only indices. The OSPFv2 MIB started life > in RFC 1248 > > > > > > > as > an > > > SMIv1 > > > > > > MIB > > > > > > > module, so this exception applies. > > > > > > > > > > > > How about tables which were added later?: > > > > > > ospfAreaAggregateTable, ExtLsdbTable, etc. My worry > is not if > > > > > > its allowed or not. I am trying to point out > the > > > extra > > > > > > processing routers and > > > > > > NMS have to do with the increased number of messages. > > > > > > > > > > > > > As far as finding a generic solution for multiple > instances > > > > > > > of a > MIB > > > > > > module, > > > > > > > the standard solution is to use contexts (note: > this is not > > > > > > > the > same > > > as a > > > > > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this > > > > > > > was > done > > > in a > > > > > > > somewhat ad-hoc way by using different community > names for > > > > > > > each > > > instance > > > > > > > of the OSPF MIB. In SNMPv3, it is more formally defined > > > > > > > using > the > > > > > > > contextName. The Entity MIB entLogicalTable (RFC 2737) > > > > > > > provides > > > > > > information > > > > > > > about what contexts exist in an agent, and how to get to > > > > > > > them. > > > > > > > > > > > > After having a glance at rfc2737, I also think this is the > > > > > > way. I > > > think we > > > > > > need to specify it clearly how it can be achieved using > > > entLogicalTable. For > > > > > > example, how we need to represent the SNMP > community string to > > > retrieve info > > > > > > from a particular routing instance. > > > > > > > > > > > > Thanks, > > > > > > Roy > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > Acee Lindem wrote: > > > > > > > > > > > > > > > > Roy, > > > > > > > > > > > > > > > > I can appreciate your points since our product supports > > > > > > > > both > > > multiple > > > > > > > > virtual router instances and multiple routing protocol > instances > > > > > > > > within a particular virtual router. However, I > think we'd > > > > > > > > essentially have to deprecate everything in the current > > > > > > > > MIB > and > > > define > > > > > > > > new tables in order to add OSPF instance ID as > an index. > > > > > > > > Can > > > someone > > > > > > > > who has more MIB definition experience comment? > > > > > > > > > > > > > > > > Additionally, the multiple instance problem is > not unique > > > > > > > > to > the > > > > > > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > > > > > > > > > > > Roy Jose wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I have some comments on > > > > > > > > > draft-ietf-ospf-mib-update-05.txt. I > > > would > > > > > > also like > > > > > > > > > to have some clarifications. Please see the attached > document. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Roy > > > > > > > > > > > > > > > > > > > > > > > > > > >>Yes. An update is in the works. > > > > > > > > >> > > > > > > > > >>-Dan > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>>-----Original Message----- > > > > > > > > >>>From: Banerjee, Gargi > > > > > > > > >>>[mailto:Gargi.Banerjee@MARCONI.COM] > > > > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > > > > > > >>>Subject: OSPFv2 MIB draft > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>>Hi all: > > > > > > > > >>>I would like to know the status of the working group > > > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft > > > > > > > > >>>shows > an > > > > > > > > >>>expiry date of > > > > > > > > >>>May 2001. > > > > > > > > >>>Is there any plan to update the draft ? > > > > > > > > >>> > > > > > > > > >>>Thanks > > > > > > > > >>>Gargi > > > > > > > > >>> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > >>------------------------------------------------------------ > ---------- > >>-- > > > > > > > > >> > > > > > > > > >>Support for multiple OSPF processes: > > > > > > > > >>----------------------------------- > > > > > > > > >> > > > > > > > > >>We raised this issue some time back in WG. > Currently MIB > > > supports only > > > > > > one Router ID. > > > > > > > > >>Multiple processes can have separate router > IDs. It is > > > > > > > > >>also > true > > > with > > > > > > other MIB objects > > > > > > > > >>like ospfExternLsaCount, > ospfExternLsaCksumSum etc. The > solution > > > we > > > > > > got was to use a > > > > > > > > >>separate MIB view for each process. But I > don't think it > > > > > > > > >>can > be > > > easily > > > > > > implemented. > > > > > > > > >>We suggest to form a new table to group scalar objects > related > > > to an > > > > > > OSPF process and have > > > > > > > > >>Process Id as its INDEX. We also suggest to > add Process > > > > > > > > >>Id > as > > > one of > > > > > > the INDICES of all > > > > > > > > >>tables. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>MAX-ACCESS value for INDICES of TABLES: > > > > > > > > >>-------------------------------------- > > > > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. > > > > > > > > >>Normally > > > INDICES > > > > > > of a table are > > > > > > > > >>put as not-accesssible to reduce the number of SNMP > messages. > > > When an > > > > > > SNMP GET or > > > > > > > > >>GETNEXT is issued on a non-INDEX object, we > can extract > > > > > > > > >>the > > > values of > > > > > > INDICES from > > > > > > > > >>the object ID returned. For example, let us consider > > > ospfAreaLsaCount. > > > > > > When we query > > > > > > > > >>the value for this, we get something like > > > ospfAreaLsaCount.0.0.0.1, > > > > > > where 0.0.0.1 is > > > > > > > > >>the AreaId, which is the INDEX of the > ospfAreaTable. We > > > > > > > > >>can > > > extract > > > > > > the INDICES of > > > > > > > > >>table like this even if they are not-accessible. The > > > > > > > > >>tables > like > > > > > > LsdbTable has many > > > > > > > > >>number of INDICES and we can reduce the number of SNMP > messages > > > > > > considerably by changing > > > > > > > > >>them to not-accessible. > > > > > > > > >> > > > > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to > > > > > > > > >>include > > > them in > > > > > > the TRAP > > > > > > > > >>notification messages, they can be changed as > > > accessible-for-notify. > > > > > > Other approach to > > > > > > > > >>this is remove the INDICES from TRAP notification > > > > > > > > >>messages. > For > > > > > > example if you take the > > > > > > > > >>case of IfStateChange TRAP, > > > > > > > > >> > > > > > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > > > > > > >> OBJECTS { ospfRouterId, -- The > originator of the > trap^M > > > > > > > > >> ospfIfIpAddress,^M > > > > > > > > >> ospfAddressLessIf,^M > > > > > > > > >> ospfIfState -- The new state^M > > > > > > > > >> }^M > > > > > > > > >>Here we don't actually need ospfIfIpAddress and > > > ospfAddressLessIf. > > > > > > When we send TRAP > > > > > > > > >>notification, we can just send > > > > > > > > >>ospfIfState. > > > > > value>. . > > > > > > > > >>Also I am not sure why ospfRouterId is > included here. An > > > > > > > > >>NMS > > > station > > > > > > can always query ospfRouterId > > > > > > > > >>separately. By removing these MIB objects, we > can reduce > > > > > > > > >>the > > > size and > > > > > > processing time of TRAP > > > > > > > > >>messages considerably. > > > > > > > > >> > > > > > > > > >>Section : 4.3 Ignoring Initial Activity > > > > > > > > >>--------------------------------------- > > > > > > > > >>The section states "The majority of critical events > > > > > > > > >>occur > when > > > OSPF is > > > > > > enabled on a > > > > > > > > >>router, at which time the designated router > is elected > > > > > > > > >>and > > > neighbor > > > > > > adjacencies are formed" . > > > > > > > > >>I am not sure if enabling OSPF on a router means > > > > > > > > >>enabling it > on > > > an > > > > > > interface. I think it will > > > > > > > > >>be better to make the text clearer. > > > > > > > > >> > > > > > > > > >>Other statement is "To avoid unnecessary > traps, a router > should > > > not > > > > > > originate expected OSPF > > > > > > > > >>interface related traps until two of that interface's > > > > > > > > >>dead > timer > > > > > > intervals have elapsed." > > > > > > > > >>I think there will be some problems if the > dead interval > value > > > is too > > > > > > long. We may end up > > > > > > > > >>not sending any of the expected TRAPS for a > long time. > > > > > > > > >>Btw, > > > could I > > > > > > please know the reason > > > > > > > > >>for selecting 2 * dead interval value for > this purpose?. > There > > > might > > > > > > be some case where an > > > > > > > > >>interface is up and it goes down before (2 * dead > > > > > > > > >>interval). > We > > > can't > > > > > > take it as an 'expected > > > > > > > > >>event'. Probably we can ignore the expected > events till > > > > > > > > >>the > > > interface > > > > > > reaches terminal state > > > > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>One more point is we are already limiting > > > > > > > > >>ospfIfStateChange, > > > > > > ospfVirtIfStateChange, > > > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange > > > > > > > > >>notifications > by > > > > > > generating them only for terminal > > > > > > > > >>state changes and backward tansition. Do we > really need > > > > > > > > >>to > > > ignore them > > > > > > during the initial activity?. > > > > > > > > >> > > > > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and > > > ospfOriginateLsa > > > > > > traps should not be originated > > > > > > > > >>until two dead timer intervals have elapsed where the > deadtimer > > > > > > interval used should be the dead > > > > > > > > >>timer with the smallest value." Here whats > the meaning > > > > > > > > >>of > "dead > > > timer > > > > > > with smallest value"? Is it > > > > > > > > >>the smallest interval value among all the interfaces? > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>Section 4.4 Throttling Traps > > > > > > > > >>---------------------------- > > > > > > > > >>Do we need to provide MIB objects corresponding to > > > > > > > > >>window > size > > > and the > > > > > > number of TRAPs sent during > > > > > > > > >>the window time? Will the TRAPs other than > > > > > > > > >>ospfTxRetransmit, > > > > > > OrginateLsa and MaxAgeLsa really cause > > > > > > > > >>a TRAP flood? Probably we need to throttle only the > > > > > > > > >>above > three > > > TRAPS? > > > > > > > > >> > > > > > > > > >>I think the normal practice is to inform the > NMS using > > > > > > > > >>some > > > other > > > > > > notification at the end of a > > > > > > > > >>particular interval when the TRAPs are dropped like > > > > > > > > >>this, > "Trap > > > N > > > > > > dropped n times in an interval > > > > > > > > >>t". We can add some common extra paratmeters to these > > > notifications to > > > > > > facilitate the NMS to query > > > > > > > > >>the router to retrieve some values and find out whats > happening. > > > > > > > > >> > > > > > > > > >>ospfConfigErrorType > > > > > > > > >>------------------- > > > > > > > > >>Do we need an error type for duplicate router > id in the > received > > > > > > messages? Some times loop back > > > > > > > > >>address can be misconfigured. > > > > > > > > >> > > > > > > > > >>ospfSetTrap > > > > > > > > >>----------- > > > > > > > > >>The definition of this is little complicated. Any > > > > > > > > >>reasons > for > > > going > > > > > > for last bit to first. We think > > > > > > > > >>its better to redefine this MIB object like > this to make > > > > > > > > >>if > more > > > > > > clear. > > > > > > > > >> > > > > > > > > >> cospfSetTrap OBJECT-TYPE > > > > > > > > >> SYNTAX BITS { > > > > > > > > >> ifConfigError (0), > > > > > > > > >> virtIfConfigError (1), > > > > > > > > >> ospfNbrStateChange (2), > > > > > > > > >> . > > > > > > > > >> . > > > > > > > > >> . > > > > > > > > >> } > > > > > > > > >> MAX-ACCESS read-write > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "A One-octet string serving as a > bit map for > > > > > > > > >> the trap events defined by the > OSPF traps in > > > > > > > > >> this MIB. This object is used to enable and > > > > > > > > >> disable specific OSPF traps > where a 1 > > > > > > > > >> in the corresponding bit field > represents > > > > > > > > >> enabled." > > > > > > > > >> ::= { cospfTrapControl 1 } > > > > > > > > >> > > > > > > > > >>This definition enables the NMS to interpret > the bit map > easily. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>ospfIfStateChange > > > > > > > > >>----------------- > > > > > > > > >> > > > > > > > > >>>From the definition it looks like this TRAP should be > generated > > > only > > > > > > for terminal states(when state > > > > > > > > >>progresses) and for backward transition. > Infact the name > > > > > > ospfIfStateChange simply suggests to > > > > > > > > >>generate TRAPs for all state transitions. The general > tendency > > > is to > > > > > > ignore the DESCRIPTION when > > > > > > > > >>"StateChange" is read and assume its for all the state > changes. > > > It > > > > > > might lead to wrong > > > > > > > > >>implementations. I think we can also follow > the approach > taken > > > in BGP > > > > > > MIB(rfc1657). > > > > > > > > >>There they have notifications like this, > > > > > > > > >> bgpEstablished NOTIFICATION-TYPE > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > >> bgpPeerState } > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "The BGP > Established event > > > > > > > > >>is > > > generated > > > > > > when > > > > > > > > >> the BGP FSM enters the > ESTABLISHED > > > state." > > > > > > > > >> ::= { bgpTraps 1 } > > > > > > > > >> > > > > > > > > >> bgpBackwardTransition > NOTIFICATION-TYPE > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > >> bgpPeerState } > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "The > BGPBackwardTransition > > > > > > > > >> Event > is > > > > > > generated > > > > > > > > >> when the BGP FSM > moves from > > > > > > > > >> a > higher > > > > > > numbered > > > > > > > > >> state to a lower numbered > state." > > > > > > > > >> ::= { bgpTraps 2 } > > > > > > > > >> > > > > > > > > >>Our suggestion is to maintain > ospfIfStateChange and use > > > > > > > > >>that > for > > > > > > monitoring all the states > > > > > > > > >>(some people may want that) and additionally have > notifications > > > > > > similar to the BGP notifications. > > > > > > > > >>Its also true with VirtIfStateChange, > NbrStateChange and > > > > > > VirtNbrStateChange. If somebody doesn't > > > > > > > > >>want to see ALL state TRAPS, they can suppress them by > turning > > > off the > > > > > > corresponding bit in > > > > > > > > >>ospfSetTrap. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>ospfNbrStateChange > > > > > > > > >>------------------ > > > > > > > > >>The DECRIPTION clause states > > > > > > > > >>"When an neighbor transitions from or to Full on > non-broadcast > > > > > > multi-access and broadcast > > > > > > > > >> networks, the trap should be generated by the > > > > > > > > >> designated > > > router. A > > > > > > designated router > > > > > > > > >>transitioning to Down will be noted by > > > > > > > > >>ospfIfStateChange." I think here the intention is to > > > > > > > > >>reduce the number of TRAPs > as > > > much as > > > > > > possible by making > > > > > > > > >>only DR sending out this TRAP for a subnet. > But there is > > > > > > > > >>a > > > possibility > > > > > > that osfpNbrStateChange > > > > > > > > >>notification is disabled on DR and enabled on > DR other > > > > > > > > >>or > BDR. > > > NMS > > > > > > won't receive TRAPs when > > > > > > > > >>NbrState becomes FULL in that case. There is > a problem > > > > > > > > >>with > the > > > second > > > > > > part of above statments > > > > > > > > >>as well. Suppose ospfIfStateChange is disabled on the > router, > > > then > > > > > > again NMS won't know when > > > > > > > > >>neighbor goes down. Probably its better to > remove these > > > > > > > > >>two > > > clauses. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>Support for sham links: > > > > > > > > >>----------------------- > > > > > > > > >>Are you going to provide support for sham > links? We may > > > > > > > > >>need > > > these > > > > > > tables and notifications, > > > > > > > > >>ShamLinkTable > > > > > > > > >>ShamLinkNbrTable > > > > > > > > >>ShamLinkStateChange notification > ShamLinkNbrStateChange > > > > > > > > >>notification > > > > > > > > > ------_=_NextPart_001_01C2EE65.F5942BD2 Content-Type: text/html RE: OSPFv2 MIB draft

Comments in-line below.

-Dan

> -----Original Message-----
> From: Roy Jose [mailto:rojose@CISCO.COM]
> Sent: Wednesday, March 19, 2003 6:05 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: OSPFv2 MIB draft
>
>
> Thanks Manral, Acee.
>
> Let me point out the open issues here from the original
> document I sent. Joyal, please let me know if you need any
> clarifications.
>
> Support for multiple OSPF processes:
> -----------------------------------
>
> We raised this issue some time back in WG. Currently MIB
> supports only one Router ID. Multiple processes can have
> separate router IDs. It is also true with other MIB objects
> like ospfExternLsaCount, ospfExternLsaCksumSum etc. The
> solution we got was to use a separate MIB view for each
> process. But I don't think it can be easily implemented. We
> suggest to form a new table to group scalar objects related
> to an OSPF process and have Process Id as its INDEX. We also
> suggest to add Process Id as one of the INDICES of all
> tables. [WG - John Flick] As far as finding a generic
> solution for multiple instances of a MIB module, the standard
> solution is to use contexts (note: this is not the same as a
> MIB view.  See RFC 3411, section 3.3.1).  In SNMPv1, this was
> done in a somewhat ad-hoc way by using different community
> names for each instance of the OSPF MIB.  In SNMPv3, it is
> more formally defined using the contextName.  The Entity MIB
> entLogicalTable (RFC 2737) provides information about what
> contexts exist in an agent, and how to get to them. [OPEN
> issue] I think we need to investigate on this and add a
> section to the draft how it can be applied to OSPF MIB .
>

This issue is not unique to the OSPF MIBs. I would prefer
to just reference the RFCs that deal with SNMP contexts that
John Flick mentioned.

>
> MAX-ACCESS value for INDICES of TABLES:
> --------------------------------------
> I see MAX-ACCESS value of all TABLEs are read-only. Normally
> INDICES of a table are put as not-accesssible to reduce the
> number of SNMP messages. When an SNMP GET or GETNEXT is
> issued on a non-INDEX object, we can extract the values of
> INDICES from the object ID returned. For example, let us
> consider ospfAreaLsaCount. When we query the value for this,
> we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1
> is the AreaId, which is the INDEX of the ospfAreaTable. We
> can extract the INDICES of table like this even if they are
> not-accessible. The tables like LsdbTable has many number of
> INDICES and we can reduce the number of SNMP messages
> considerably by changing them to not-accessible.
>
> [WG - John Flick]
> You would have the same problem if you tried changing
> MAX-ACCESS on the table indices (as was also suggested
> below).  Since a change to MAX-ACCESS of an existing object
> is not allowed, you would need to deprecated the index
> objects, which would require deprecating the tables that they
> index. Changing to not-accessible is not required, since
> SMIv2 allows read-only indices for MIB modules that were
> translated from SMIv1 and therefore already had read-only
> indices.  The OSPFv2 MIB started life in RFC 1248 as an SMIv1
> MIB module, so this exception applies.
>
> [OPEN issue]
> As I have pointed out earlier, by changing the INDICES we can
> reduce the number of  SNMP GETNEXT reponses sent by the
> router considerably. The draft standard MIB is already widely
> deployed. But we need to deprecate an existing MIB and add a
> new version, when it is required. I feel if everyone thinks
> what I pointed out is a big advantange, still we can go ahead
> with this change.
>
> If the MAX-ACCESS of INDICES are put as read-only to include
> them in the TRAP notification messages, they can be changed
> as accessible-for-notify. Other approach to this is remove
> the INDICES from TRAP notification messages. For example if
> you take the case of IfStateChange TRAP,
>
>    ospfIfStateChange NOTIFICATION-TYPE^M
>         OBJECTS { ospfRouterId, -- The originator of the trap^M
>            ospfIfIpAddress,^M
>            ospfAddressLessIf,^M
>            ospfIfState   -- The new state^M
>            }^M
> Here we don't actually need ospfIfIpAddress and
> ospfAddressLessIf. When we send TRAP notification, we can
> just send ospfIfState.<ospfIfIpAddress
> value>.<ospfAddressLessIf value> .
> Also I am not sure why ospfRouterId is included here. An NMS
> station can always query ospfRouterId separately. By removing
> these MIB objects, we can reduce the size and processing time
> of TRAP messages considerably.
>
> [OPEN issue] The above point is not addressed yet.
>

I think there would need to be a strong WG consensus that deprecating the
entire MIB for this is worth it.
 
> Section : 4.3 Ignoring Initial Activity
> ---------------------------------------
>
> [OPEN issue] This is not addressed yet.
>
> The section states "The majority of critical events occur
> when OSPF is enabled on a router, at which time the
> designated router is elected and neighbor adjacencies are
> formed" . I am not sure if enabling OSPF on a router means
> enabling it on an interface. I think it will be better to
> make the text clearer.
>
> Other statement is "To avoid unnecessary traps, a router
> should not originate expected OSPF interface related traps
> until two of that interface's dead timer intervals have
> elapsed." I think there will be some problems if the dead
> interval value is too long. We may end up not sending any of
> the expected TRAPS for a long time. Btw, could I please know
> the reason for selecting 2 * dead interval value for this
> purpose?. There might be some case where an interface is up
> and it goes down before (2 * dead interval). We can't take it
> as an 'expected event'. Probably we can ignore the expected
> events till the interface reaches terminal state (FULL or
> 2WAY) for the first time after enabling OSPF.
>
>
> One more point is we are already limiting ospfIfStateChange,
> ospfVirtIfStateChange, ospfNbrStateChange and
> ospfVirtNbrStateChange notifications by generating them only
> for terminal state changes and backward tansition. Do we
> really need to ignore them during the initial activity?.
>
> Other statement is "Additionally, ospfMaxAgeLsa and
> ospfOriginateLsa traps should not be originated until two
> dead timer intervals have elapsed where the deadtimer
> interval used should be the dead timer with the smallest
> value." Here whats the meaning of "dead timer with smallest
> value"? Is it the smallest interval value among all the interfaces?
>

I think the intent of the original authors of the MIB was
to give some guidelines (hence the wording "should not" rather
than "must not") for when or when not to generate traps. I don't
know how closely real world implementations follow these guidelines.

>
> Section 4.4 Throttling Traps
> ----------------------------
>
> [OPEN issue] This is not addressed yet.
>
> Do we need to provide MIB objects corresponding to window
> size and the number of TRAPs sent during the window time?
> Will the TRAPs other than ospfTxRetransmit, OrginateLsa and
> MaxAgeLsa really cause a TRAP flood? Probably we need to
> throttle only the above three TRAPS?
>
> I think the normal practice is to inform the NMS using some
> other notification at the end of a particular interval when
> the TRAPs are dropped like this, "Trap N dropped n times in
> an interval t". We can add some common extra paratmeters to
> these notifications to facilitate the NMS to query the router
> to retrieve some values and find out whats happening.
>
> ospfConfigErrorType
> -------------------
>
> [OPEN issue] This is not addressed yet.
>
> Do we need an error type for duplicate router id in the
> received messages? Some times loop back address can be misconfigured.

Easy to add if required.

>
> ospfSetTrap
> -----------
>
> [OPEN issue] This is not addressed yet.
>
> The definition of this is little complicated. Any reasons for
> going for last bit to first. We think its better to redefine
> this MIB object like this to make if more clear.
>
>   cospfSetTrap OBJECT-TYPE
>         SYNTAX BITS {
>                        ifConfigError (0),
>                        virtIfConfigError (1),
>                        ospfNbrStateChange (2),
>                           .
>                           .
>                           .
>                     }
>         MAX-ACCESS   read-write
>         STATUS   current
>         DESCRIPTION
>            "A One-octet string serving as a bit  map  for
>            the trap events defined by the OSPF traps in
>            this MIB. This object is used to enable and
>            disable  specific OSPF   traps   where  a  1
>            in  the  corresponding bit  field represents
>            enabled."
>        ::= { cospfTrapControl 1 }
>
> This definition enables the NMS to interpret the bit map easily.

Changing to a non-equivalent syntax would require creation of a new object.

>
>
> ospfIfStateChange
> -----------------
> [OPEN issue] This is not addressed yet.
>
> From the definition it looks like this TRAP should be
> generated only for terminal states(when state
> progresses) and for backward transition. Infact the name
> ospfIfStateChange simply suggests to generate TRAPs for all
> state transitions. The general tendency is to ignore the
> DESCRIPTION when "StateChange" is read and assume its for all
> the state changes. It might lead to wrong implementations. I
> think we can also follow the approach taken in BGP
> MIB(rfc1657). There they have notifications like this,
>                 bgpEstablished NOTIFICATION-TYPE
>                     OBJECTS { bgpPeerLastError,
>                               bgpPeerState      }
>                     STATUS  current
>                     DESCRIPTION
>                             "The BGP Established event is
> generated when
>                             the BGP FSM enters the ESTABLISHED state."
>                     ::= { bgpTraps 1 }
>
>                 bgpBackwardTransition NOTIFICATION-TYPE
>                     OBJECTS { bgpPeerLastError,
>                               bgpPeerState      }
>                     STATUS  current
>                     DESCRIPTION
>                             "The BGPBackwardTransition Event
> is generated
>                             when the BGP FSM moves from a
> higher numbered
>                             state to a lower numbered state."
>                     ::= { bgpTraps 2 }
>
> Our suggestion is to maintain ospfIfStateChange and use that
> for monitoring all the states (some people may want that) and
> additionally have notifications similar to the BGP
> notifications. Its also true with VirtIfStateChange,
> NbrStateChange and VirtNbrStateChange. If somebody doesn't
> want to see ALL state TRAPS, they can suppress them by
> turning off the corresponding bit in ospfSetTrap.
>

OK. Could you list the new BGP-like notifications for OSPF?

>
> ospfNbrStateChange
> ------------------
>
> [OPEN issue] This is not addressed yet.
>
> The DECRIPTION clause states
> "When an neighbor transitions from or to Full on
> non-broadcast multi-access and broadcast  networks, the trap
> should be generated  by the designated router. A designated
> router transitioning to Down will be noted by
> ospfIfStateChange." I think here the intention is to reduce
> the number of TRAPs as much as possible by making only DR
> sending out this TRAP for a subnet. But there is a
> possibility that osfpNbrStateChange notification is disabled
> on DR and enabled on DR other or BDR. NMS won't receive TRAPs
> when NbrState becomes FULL in that case. There is a problem
> with the second part of above statments as well. Suppose
> ospfIfStateChange is disabled on the router, then again NMS
> won't know when neighbor goes down. Probably its better to
> remove these two clauses.
>
> Thanks,
> Roy
>
>
> > "Manral, Vishwas" wrote:
> > >
> > > Dan Joyal is at present working on the OSPFv2 MIB.
> >
> > And the OSPFv3 MIB as well.
> >
> >
> > Thanks,
> > Acee
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Roy Jose [mailto:rojose@CISCO.COM]
> > > Sent: Tuesday, March 18, 2003 12:03 PM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: Re: OSPFv2 MIB draft
> > >
> > > Hi Acee,
> > >
> > > I agree with you. Till it becomes a standard draft,
> vendors have to
> > > go
> with
> > > some proprietory MIB I guess. Btw, who is working on the
> MIB update
> > > currently?
> > >
> > > Thanks,
> > > Roy
> > >
> > > > One small correction.
> > > >
> > > > Acee Lindem wrote:
> > > > >
> > > > > Roy,
> > > > >
> > > > > There are 3 reasons why I don't think Sham Links should be
> > > > > included in this MIB udpate:
> > > > >
> > > > >   1. I don't think they are sufficiently specified in the
> > > > >      Internet Draft describing them. My experience
> implementing
> > > > >      the Sham Link feature required some reverse
> > > > >      engineering (Consult RFC 1264 for specification
> > > > >      requirements).
> > > > >   2. The document describing them is not an OSPF WG
> > > > >      document. In fact, it is not even an PPVPN
> > > > >      document (although it could become one).
> > > > >   3. At some point, we have to close the door on adding
> > > > >      MIB variables that are in all the drafts that may or
> > > > >      may not ever reach draft standard status. If we don't
> > > >                           ~~~~~~~~~~~~~~
> > > >    Meant to say "proposed standard" here.
> > > >
> > > > >      do this, we'll never finish the MIB update.
> > > > >
> > > > > Thanks,
> > > > > Acee
> > > > >
> > > > > Roy Jose wrote:
> > > > > >
> > > > > > Thanks Jeff, Acee, Mani and John  for your responses.  How
> > > > > > about
> other
> > > > > > points?:)
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "John Flick" <johnf@ROSE.HP.COM>
> > > > > > To: <OSPF@DISCUSS.MICROSOFT.COM>
> > > > > > Sent: Saturday, March 15, 2003 6:19 AM
> > > > > > Subject: Re: OSPFv2 MIB draft
> > > > > >
> > > > > > > Yep, adding an index would require deprecating everything
> > > > > > > and
> > > starting
> > > > > > over.
> > > > > > > Since this is an existing, widely deployed, Draft
> Standard
> > > > > > > MIB,
> this
> > > > > > should
> > > > > > > not be done lightly.
> > > > > > >
> > > > > > > You would have the same problem if you tried changing
> > > > > > > MAX-ACCESS
> on
> > > the
> > > > > > > table indices (as was also suggested below). 
> Since a change
> > > > > > > to
> > > MAX-ACCESS
> > > > > > > of an existing object is not allowed, you would need to
> deprecated
> > > the
> > > > > > index
> > > > > > > objects, which would require deprecating the tables that
> > > > > > > they
> index.
> > > > > > Changing
> > > > > > > to not-accessible is not required, since SMIv2 allows
> > > > > > > read-only
> > > indices
> > > > > > for
> > > > > > > MIB modules that were translated from SMIv1 and therefore
> already
> > > had
> > > > > > > read-only indices.  The OSPFv2 MIB started life
> in RFC 1248
> > > > > > > as
> an
> > > SMIv1
> > > > > > MIB
> > > > > > > module, so this exception applies.
> > > > > >
> > > > > > How about tables which were added later?:
> > > > > > ospfAreaAggregateTable, ExtLsdbTable, etc. My worry
> is not if
> > > > > > its allowed or not. I am trying to point out
> the
> > > extra
> > > > > > processing routers and
> > > > > > NMS have to do with the increased number of messages.
> > > > > >
> > > > > > > As far as finding a generic solution for multiple
> instances
> > > > > > > of a
> MIB
> > > > > > module,
> > > > > > > the standard solution is to use contexts (note:
> this is not
> > > > > > > the
> same
> > > as a
> > > > > > > MIB view.  See RFC 3411, section 3.3.1).  In SNMPv1, this
> > > > > > > was
> done
> > > in a
> > > > > > > somewhat ad-hoc way by using different community
> names for
> > > > > > > each
> > > instance
> > > > > > > of the OSPF MIB.  In SNMPv3, it is more formally defined
> > > > > > > using
> the
> > > > > > > contextName.  The Entity MIB entLogicalTable (RFC 2737)
> > > > > > > provides
> > > > > > information
> > > > > > > about what contexts exist in an agent, and how to get to
> > > > > > > them.
> > > > > >
> > > > > > After having a glance at rfc2737, I also think this is the
> > > > > > way. I
> > > think we
> > > > > > need to specify it clearly how it can be achieved using
> > > entLogicalTable. For
> > > > > > example, how we need to represent the SNMP
> community string to
> > > retrieve info
> > > > > > from a particular routing instance.
> > > > > >
> > > > > > Thanks,
> > > > > > Roy
> > > > > >
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > Acee Lindem wrote:
> > > > > > > >
> > > > > > > > Roy,
> > > > > > > >
> > > > > > > > I can appreciate your points since our product supports
> > > > > > > > both
> > > multiple
> > > > > > > > virtual router instances and multiple routing protocol
> instances
> > > > > > > > within a particular virtual router. However, I
> think we'd
> > > > > > > > essentially have to deprecate everything in the current
> > > > > > > > MIB
> and
> > > define
> > > > > > > > new tables in order to add OSPF instance ID as
> an index.
> > > > > > > > Can
> > > someone
> > > > > > > > who has more MIB definition experience comment?
> > > > > > > >
> > > > > > > > Additionally, the multiple instance problem is
> not unique
> > > > > > > > to
> the
> > > > > > > > OSPF MIB. Maybe a generic solution could be developed.
> > > > > > > >
> > > > > > > > Roy Jose wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I have some comments on
> > > > > > > > > draft-ietf-ospf-mib-update-05.txt. I
> > > would
> > > > > > also like
> > > > > > > > > to have some clarifications. Please see the attached
> document.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Roy
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >>Yes. An update is in the works.
> > > > > > > > >>
> > > > > > > > >>-Dan
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>>-----Original Message-----
> > > > > > > > >>>From: Banerjee, Gargi
> > > > > > > > >>>[mailto:Gargi.Banerjee@MARCONI.COM]
> > > > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM
> > > > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM
> > > > > > > > >>>Subject: OSPFv2 MIB draft
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>Hi all:
> > > > > > > > >>>I would like to know the status of the working group
> > > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft
> > > > > > > > >>>shows
> an
> > > > > > > > >>>expiry date of
> > > > > > > > >>>May 2001.
> > > > > > > > >>>Is there any plan to update the draft ?
> > > > > > > > >>>
> > > > > > > > >>>Thanks
> > > > > > > > >>>Gargi
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > >
> > > > > >
> > >
> >>------------------------------------------------------------
> ----------
> >>--
> > > > > > > > >>
> > > > > > > > >>Support for multiple OSPF processes:
> > > > > > > > >>-----------------------------------
> > > > > > > > >>
> > > > > > > > >>We raised this issue some time back in WG.
> Currently MIB
> > > supports only
> > > > > > one Router ID.
> > > > > > > > >>Multiple processes can have separate router
> IDs. It is
> > > > > > > > >>also
> true
> > > with
> > > > > > other MIB objects
> > > > > > > > >>like ospfExternLsaCount,
> ospfExternLsaCksumSum etc. The
> solution
> > > we
> > > > > > got was to use a
> > > > > > > > >>separate MIB view for each process. But I
> don't think it
> > > > > > > > >>can
> be
> > > easily
> > > > > > implemented.
> > > > > > > > >>We suggest to form a new table to group scalar objects
> related
> > > to an
> > > > > > OSPF process and have
> > > > > > > > >>Process Id as its INDEX. We also suggest to
> add Process
> > > > > > > > >>Id
> as
> > > one of
> > > > > > the INDICES of all
> > > > > > > > >>tables.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>MAX-ACCESS value for INDICES of TABLES:
> > > > > > > > >>--------------------------------------
> > > > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only.
> > > > > > > > >>Normally
> > > INDICES
> > > > > > of a table are
> > > > > > > > >>put as not-accesssible to reduce the number of SNMP
> messages.
> > > When an
> > > > > > SNMP GET or
> > > > > > > > >>GETNEXT is issued on a non-INDEX object, we
> can extract
> > > > > > > > >>the
> > > values of
> > > > > > INDICES from
> > > > > > > > >>the object ID returned. For example, let us consider
> > > ospfAreaLsaCount.
> > > > > > When we query
> > > > > > > > >>the value for this, we get something like
> > > ospfAreaLsaCount.0.0.0.1,
> > > > > > where 0.0.0.1 is
> > > > > > > > >>the AreaId, which is the INDEX of the
> ospfAreaTable. We
> > > > > > > > >>can
> > > extract
> > > > > > the INDICES of
> > > > > > > > >>table like this even if they are not-accessible. The
> > > > > > > > >>tables
> like
> > > > > > LsdbTable has many
> > > > > > > > >>number of INDICES and we can reduce the number of SNMP
> messages
> > > > > > considerably by changing
> > > > > > > > >>them to not-accessible.
> > > > > > > > >>
> > > > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to
> > > > > > > > >>include
> > > them in
> > > > > > the TRAP
> > > > > > > > >>notification messages, they can be changed as
> > > accessible-for-notify.
> > > > > > Other approach to
> > > > > > > > >>this is remove the INDICES from TRAP notification
> > > > > > > > >>messages.
> For
> > > > > > example if you take the
> > > > > > > > >>case of IfStateChange TRAP,
> > > > > > > > >>
> > > > > > > > >>   ospfIfStateChange NOTIFICATION-TYPE^M
> > > > > > > > >>        OBJECTS { ospfRouterId, -- The
> originator of the
> trap^M
> > > > > > > > >>           ospfIfIpAddress,^M
> > > > > > > > >>           ospfAddressLessIf,^M
> > > > > > > > >>           ospfIfState   -- The new state^M
> > > > > > > > >>           }^M
> > > > > > > > >>Here we don't actually need ospfIfIpAddress and
> > > ospfAddressLessIf.
> > > > > > When we send TRAP
> > > > > > > > >>notification, we can just send
> > > > > > > > >>ospfIfState.<ospfIfIpAddress
> > > > > > value>.<ospfAddressLessIf value> .
> > > > > > > > >>Also I am not sure why ospfRouterId is
> included here. An
> > > > > > > > >>NMS
> > > station
> > > > > > can always query ospfRouterId
> > > > > > > > >>separately. By removing these MIB objects, we
> can reduce
> > > > > > > > >>the
> > > size and
> > > > > > processing time of TRAP
> > > > > > > > >>messages considerably.
> > > > > > > > >>
> > > > > > > > >>Section : 4.3 Ignoring Initial Activity
> > > > > > > > >>---------------------------------------
> > > > > > > > >>The section states "The majority of critical events
> > > > > > > > >>occur
> when
> > > OSPF is
> > > > > > enabled on a
> > > > > > > > >>router, at which time the designated router
> is elected
> > > > > > > > >>and
> > > neighbor
> > > > > > adjacencies are formed" .
> > > > > > > > >>I am not sure if enabling OSPF on a router means
> > > > > > > > >>enabling it
> on
> > > an
> > > > > > interface. I think it will
> > > > > > > > >>be better to make the text clearer.
> > > > > > > > >>
> > > > > > > > >>Other statement is "To avoid unnecessary
> traps, a router
> should
> > > not
> > > > > > originate expected OSPF
> > > > > > > > >>interface related traps until two of that interface's
> > > > > > > > >>dead
> timer
> > > > > > intervals have elapsed."
> > > > > > > > >>I think there will be some problems if the
> dead interval
> value
> > > is too
> > > > > > long. We may end up
> > > > > > > > >>not sending any of the expected TRAPS for a
> long time.
> > > > > > > > >>Btw,
> > > could I
> > > > > > please know the reason
> > > > > > > > >>for selecting 2 * dead interval value for
> this purpose?.
> There
> > > might
> > > > > > be some case where an
> > > > > > > > >>interface is up and it goes down before (2 * dead
> > > > > > > > >>interval).
> We
> > > can't
> > > > > > take it as an 'expected
> > > > > > > > >>event'. Probably we can ignore the expected
> events till
> > > > > > > > >>the
> > > interface
> > > > > > reaches terminal state
> > > > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>One more point is we are already limiting
> > > > > > > > >>ospfIfStateChange,
> > > > > > ospfVirtIfStateChange,
> > > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange
> > > > > > > > >>notifications
> by
> > > > > > generating them only for terminal
> > > > > > > > >>state changes and backward tansition. Do we
> really need
> > > > > > > > >>to
> > > ignore them
> > > > > > during the initial activity?.
> > > > > > > > >>
> > > > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and
> > > ospfOriginateLsa
> > > > > > traps  should not be originated
> > > > > > > > >>until two dead timer intervals have elapsed where the
> deadtimer
> > > > > > interval used should be the dead
> > > > > > > > >>timer with the smallest value." Here whats
> the meaning
> > > > > > > > >>of
> "dead
> > > timer
> > > > > > with smallest value"? Is it
> > > > > > > > >>the smallest interval value among all the interfaces?
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>Section 4.4 Throttling Traps
> > > > > > > > >>----------------------------
> > > > > > > > >>Do we need to provide MIB objects corresponding to
> > > > > > > > >>window
> size
> > > and the
> > > > > > number of TRAPs sent during
> > > > > > > > >>the window time? Will the TRAPs other than
> > > > > > > > >>ospfTxRetransmit,
> > > > > > OrginateLsa and MaxAgeLsa really cause
> > > > > > > > >>a TRAP flood? Probably we need to throttle only the
> > > > > > > > >>above
> three
> > > TRAPS?
> > > > > > > > >>
> > > > > > > > >>I think the normal practice is to inform the
> NMS using
> > > > > > > > >>some
> > > other
> > > > > > notification at the end of a
> > > > > > > > >>particular interval when the TRAPs are dropped like
> > > > > > > > >>this,
> "Trap
> > > N
> > > > > > dropped n times in an interval
> > > > > > > > >>t". We can add some common extra paratmeters to these
> > > notifications to
> > > > > > facilitate the NMS to query
> > > > > > > > >>the router to retrieve some values and find out whats
> happening.
> > > > > > > > >>
> > > > > > > > >>ospfConfigErrorType
> > > > > > > > >>-------------------
> > > > > > > > >>Do we need an error type for duplicate router
> id in the
> received
> > > > > > messages? Some times loop back
> > > > > > > > >>address can be misconfigured.
> > > > > > > > >>
> > > > > > > > >>ospfSetTrap
> > > > > > > > >>-----------
> > > > > > > > >>The definition of this is little complicated. Any
> > > > > > > > >>reasons
> for
> > > going
> > > > > > for last bit to first. We think
> > > > > > > > >>its better to redefine this MIB object like
> this to make
> > > > > > > > >>if
> more
> > > > > > clear.
> > > > > > > > >>
> > > > > > > > >>  cospfSetTrap OBJECT-TYPE
> > > > > > > > >>        SYNTAX BITS {
> > > > > > > > >>                       ifConfigError (0),
> > > > > > > > >>                       virtIfConfigError (1),
> > > > > > > > >>                       ospfNbrStateChange (2),
> > > > > > > > >>                          .
> > > > > > > > >>                          .
> > > > > > > > >>                          .
> > > > > > > > >>                    }
> > > > > > > > >>        MAX-ACCESS   read-write
> > > > > > > > >>        STATUS   current
> > > > > > > > >>        DESCRIPTION
> > > > > > > > >>           "A One-octet string serving as a
> bit  map  for
> > > > > > > > >>           the trap events defined by the
> OSPF traps in
> > > > > > > > >>           this MIB. This object is used to enable and
> > > > > > > > >>           disable  specific OSPF   traps  
> where  a  1
> > > > > > > > >>           in  the  corresponding bit  field
> represents
> > > > > > > > >>           enabled."
> > > > > > > > >>       ::= { cospfTrapControl 1 }
> > > > > > > > >>
> > > > > > > > >>This definition enables the NMS to interpret
> the bit map
> easily.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>ospfIfStateChange
> > > > > > > > >>-----------------
> > > > > > > > >>
> > > > > > > > >>>From the definition it looks like this TRAP should be
> generated
> > > only
> > > > > > for terminal states(when state
> > > > > > > > >>progresses) and for backward transition.
> Infact the name
> > > > > > ospfIfStateChange simply suggests to
> > > > > > > > >>generate TRAPs for all state transitions. The general
> tendency
> > > is to
> > > > > > ignore the DESCRIPTION when
> > > > > > > > >>"StateChange" is read and assume its for all the state
> changes.
> > > It
> > > > > > might lead to wrong
> > > > > > > > >>implementations. I think we can also follow
> the approach
> taken
> > > in BGP
> > > > > > MIB(rfc1657).
> > > > > > > > >>There they have notifications like this,
> > > > > > > > >>                bgpEstablished NOTIFICATION-TYPE
> > > > > > > > >>                    OBJECTS { bgpPeerLastError,
> > > > > > > > >>                              bgpPeerState      }
> > > > > > > > >>                    STATUS  current
> > > > > > > > >>                    DESCRIPTION
> > > > > > > > >>                            "The BGP
> Established event
> > > > > > > > >>is
> > > generated
> > > > > > when
> > > > > > > > >>                            the BGP FSM enters the
> ESTABLISHED
> > > state."
> > > > > > > > >>                    ::= { bgpTraps 1 }
> > > > > > > > >>
> > > > > > > > >>                bgpBackwardTransition
> NOTIFICATION-TYPE
> > > > > > > > >>                    OBJECTS { bgpPeerLastError,
> > > > > > > > >>                              bgpPeerState      }
> > > > > > > > >>                    STATUS  current
> > > > > > > > >>                    DESCRIPTION
> > > > > > > > >>                            "The
> BGPBackwardTransition
> > > > > > > > >> Event
> is
> > > > > > generated
> > > > > > > > >>                            when the BGP FSM
> moves from
> > > > > > > > >> a
> higher
> > > > > > numbered
> > > > > > > > >>                            state to a lower numbered
> state."
> > > > > > > > >>                    ::= { bgpTraps 2 }
> > > > > > > > >>
> > > > > > > > >>Our suggestion is to maintain
> ospfIfStateChange and use
> > > > > > > > >>that
> for
> > > > > > monitoring all the states
> > > > > > > > >>(some people may want that) and additionally have
> notifications
> > > > > > similar to the BGP notifications.
> > > > > > > > >>Its also true with VirtIfStateChange,
> NbrStateChange and
> > > > > > VirtNbrStateChange. If somebody doesn't
> > > > > > > > >>want to see ALL state TRAPS, they can suppress them by
> turning
> > > off the
> > > > > > corresponding bit in
> > > > > > > > >>ospfSetTrap.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>ospfNbrStateChange
> > > > > > > > >>------------------
> > > > > > > > >>The DECRIPTION clause states
> > > > > > > > >>"When an neighbor transitions from or to Full on
> non-broadcast
> > > > > > multi-access and broadcast
> > > > > > > > >> networks, the trap should be generated  by the
> > > > > > > > >> designated
> > > router. A
> > > > > > designated router
> > > > > > > > >>transitioning to Down will be noted by
> > > > > > > > >>ospfIfStateChange." I think here the intention is to
> > > > > > > > >>reduce the number of TRAPs
> as
> > > much as
> > > > > > possible by making
> > > > > > > > >>only DR sending out this TRAP for a subnet.
> But there is
> > > > > > > > >>a
> > > possibility
> > > > > > that osfpNbrStateChange
> > > > > > > > >>notification is disabled on DR and enabled on
> DR other
> > > > > > > > >>or
> BDR.
> > > NMS
> > > > > > won't receive TRAPs when
> > > > > > > > >>NbrState becomes FULL in that case. There is
> a problem
> > > > > > > > >>with
> the
> > > second
> > > > > > part of above statments
> > > > > > > > >>as well. Suppose ospfIfStateChange is disabled on the
> router,
> > > then
> > > > > > again NMS won't know when
> > > > > > > > >>neighbor goes down. Probably its better to
> remove these
> > > > > > > > >>two
> > > clauses.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>Support for sham links:
> > > > > > > > >>-----------------------
> > > > > > > > >>Are you going to provide support for sham
> links? We may
> > > > > > > > >>need
> > > these
> > > > > > tables and notifications,
> > > > > > > > >>ShamLinkTable
> > > > > > > > >>ShamLinkNbrTable
> > > > > > > > >>ShamLinkStateChange notification
> ShamLinkNbrStateChange
> > > > > > > > >>notification
> > > > > >
> >
>

------_=_NextPart_001_01C2EE65.F5942BD2-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 19 18:08:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14187 for ; Wed, 19 Mar 2003 18:08:08 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00939FFC@cherry.ease.lsoft.com>; Wed, 19 Mar 2003 18:10:19 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666890 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 19 Mar 2003 18:10:19 -0500 Received: from 192.11.223.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Mar 2003 18:00:18 -0500 Received: from ma8117exch001u.wins.lucent.com (h152-148-89-175.lucent.com [152.148.89.175]) by auemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2JN0GY13337 for ; Wed, 19 Mar 2003 18:00:16 -0500 (EST) Received: by ma8117exch001u.inse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Mar 2003 18:00:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EE6A.E9410CF6" Message-ID: Date: Wed, 19 Mar 2003 18:00:14 -0500 Reply-To: Mailing List Sender: Mailing List From: "Nair, Girish (Girish)" Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2EE6A.E9410CF6 Content-Type: text/plain Hi Dan, Just wanted to say hello from the Telesto world. We are still in orbit aound Saturn deciding what to do :-) Have you settled down yet? Girish -----Original Message----- From: Daniel Joyal [mailto:djoyal@NORTELNETWORKS.COM] Sent: Wednesday, March 19, 2003 5:22 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv2 MIB draft Comments in-line below. -Dan > -----Original Message----- > From: Roy Jose [ mailto:rojose@CISCO.COM ] > Sent: Wednesday, March 19, 2003 6:05 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPFv2 MIB draft > > > Thanks Manral, Acee. > > Let me point out the open issues here from the original > document I sent. Joyal, please let me know if you need any > clarifications. > > Support for multiple OSPF processes: > ----------------------------------- > > We raised this issue some time back in WG. Currently MIB > supports only one Router ID. Multiple processes can have > separate router IDs. It is also true with other MIB objects > like ospfExternLsaCount, ospfExternLsaCksumSum etc. The > solution we got was to use a separate MIB view for each > process. But I don't think it can be easily implemented. We > suggest to form a new table to group scalar objects related > to an OSPF process and have Process Id as its INDEX. We also > suggest to add Process Id as one of the INDICES of all > tables. [WG - John Flick] As far as finding a generic > solution for multiple instances of a MIB module, the standard > solution is to use contexts (note: this is not the same as a > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was > done in a somewhat ad-hoc way by using different community > names for each instance of the OSPF MIB. In SNMPv3, it is > more formally defined using the contextName. The Entity MIB > entLogicalTable (RFC 2737) provides information about what > contexts exist in an agent, and how to get to them. [OPEN > issue] I think we need to investigate on this and add a > section to the draft how it can be applied to OSPF MIB . > This issue is not unique to the OSPF MIBs. I would prefer to just reference the RFCs that deal with SNMP contexts that John Flick mentioned. > > MAX-ACCESS value for INDICES of TABLES: > -------------------------------------- > I see MAX-ACCESS value of all TABLEs are read-only. Normally > INDICES of a table are put as not-accesssible to reduce the > number of SNMP messages. When an SNMP GET or GETNEXT is > issued on a non-INDEX object, we can extract the values of > INDICES from the object ID returned. For example, let us > consider ospfAreaLsaCount. When we query the value for this, > we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1 > is the AreaId, which is the INDEX of the ospfAreaTable. We > can extract the INDICES of table like this even if they are > not-accessible. The tables like LsdbTable has many number of > INDICES and we can reduce the number of SNMP messages > considerably by changing them to not-accessible. > > [WG - John Flick] > You would have the same problem if you tried changing > MAX-ACCESS on the table indices (as was also suggested > below). Since a change to MAX-ACCESS of an existing object > is not allowed, you would need to deprecated the index > objects, which would require deprecating the tables that they > index. Changing to not-accessible is not required, since > SMIv2 allows read-only indices for MIB modules that were > translated from SMIv1 and therefore already had read-only > indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 > MIB module, so this exception applies. > > [OPEN issue] > As I have pointed out earlier, by changing the INDICES we can > reduce the number of SNMP GETNEXT reponses sent by the > router considerably. The draft standard MIB is already widely > deployed. But we need to deprecate an existing MIB and add a > new version, when it is required. I feel if everyone thinks > what I pointed out is a big advantange, still we can go ahead > with this change. > > If the MAX-ACCESS of INDICES are put as read-only to include > them in the TRAP notification messages, they can be changed > as accessible-for-notify. Other approach to this is remove > the INDICES from TRAP notification messages. For example if > you take the case of IfStateChange TRAP, > > ospfIfStateChange NOTIFICATION-TYPE^M > OBJECTS { ospfRouterId, -- The originator of the trap^M > ospfIfIpAddress,^M > ospfAddressLessIf,^M > ospfIfState -- The new state^M > }^M > Here we don't actually need ospfIfIpAddress and > ospfAddressLessIf. When we send TRAP notification, we can > just send ospfIfState. value>. . > Also I am not sure why ospfRouterId is included here. An NMS > station can always query ospfRouterId separately. By removing > these MIB objects, we can reduce the size and processing time > of TRAP messages considerably. > > [OPEN issue] The above point is not addressed yet. > I think there would need to be a strong WG consensus that deprecating the entire MIB for this is worth it. > Section : 4.3 Ignoring Initial Activity > --------------------------------------- > > [OPEN issue] This is not addressed yet. > > The section states "The majority of critical events occur > when OSPF is enabled on a router, at which time the > designated router is elected and neighbor adjacencies are > formed" . I am not sure if enabling OSPF on a router means > enabling it on an interface. I think it will be better to > make the text clearer. > > Other statement is "To avoid unnecessary traps, a router > should not originate expected OSPF interface related traps > until two of that interface's dead timer intervals have > elapsed." I think there will be some problems if the dead > interval value is too long. We may end up not sending any of > the expected TRAPS for a long time. Btw, could I please know > the reason for selecting 2 * dead interval value for this > purpose?. There might be some case where an interface is up > and it goes down before (2 * dead interval). We can't take it > as an 'expected event'. Probably we can ignore the expected > events till the interface reaches terminal state (FULL or > 2WAY) for the first time after enabling OSPF. > > > One more point is we are already limiting ospfIfStateChange, > ospfVirtIfStateChange, ospfNbrStateChange and > ospfVirtNbrStateChange notifications by generating them only > for terminal state changes and backward tansition. Do we > really need to ignore them during the initial activity?. > > Other statement is "Additionally, ospfMaxAgeLsa and > ospfOriginateLsa traps should not be originated until two > dead timer intervals have elapsed where the deadtimer > interval used should be the dead timer with the smallest > value." Here whats the meaning of "dead timer with smallest > value"? Is it the smallest interval value among all the interfaces? > I think the intent of the original authors of the MIB was to give some guidelines (hence the wording "should not" rather than "must not") for when or when not to generate traps. I don't know how closely real world implementations follow these guidelines. > > Section 4.4 Throttling Traps > ---------------------------- > > [OPEN issue] This is not addressed yet. > > Do we need to provide MIB objects corresponding to window > size and the number of TRAPs sent during the window time? > Will the TRAPs other than ospfTxRetransmit, OrginateLsa and > MaxAgeLsa really cause a TRAP flood? Probably we need to > throttle only the above three TRAPS? > > I think the normal practice is to inform the NMS using some > other notification at the end of a particular interval when > the TRAPs are dropped like this, "Trap N dropped n times in > an interval t". We can add some common extra paratmeters to > these notifications to facilitate the NMS to query the router > to retrieve some values and find out whats happening. > > ospfConfigErrorType > ------------------- > > [OPEN issue] This is not addressed yet. > > Do we need an error type for duplicate router id in the > received messages? Some times loop back address can be misconfigured. Easy to add if required. > > ospfSetTrap > ----------- > > [OPEN issue] This is not addressed yet. > > The definition of this is little complicated. Any reasons for > going for last bit to first. We think its better to redefine > this MIB object like this to make if more clear. > > cospfSetTrap OBJECT-TYPE > SYNTAX BITS { > ifConfigError (0), > virtIfConfigError (1), > ospfNbrStateChange (2), > . > . > . > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A One-octet string serving as a bit map for > the trap events defined by the OSPF traps in > this MIB. This object is used to enable and > disable specific OSPF traps where a 1 > in the corresponding bit field represents > enabled." > ::= { cospfTrapControl 1 } > > This definition enables the NMS to interpret the bit map easily. Changing to a non-equivalent syntax would require creation of a new object. > > > ospfIfStateChange > ----------------- > [OPEN issue] This is not addressed yet. > > From the definition it looks like this TRAP should be > generated only for terminal states(when state > progresses) and for backward transition. Infact the name > ospfIfStateChange simply suggests to generate TRAPs for all > state transitions. The general tendency is to ignore the > DESCRIPTION when "StateChange" is read and assume its for all > the state changes. It might lead to wrong implementations. I > think we can also follow the approach taken in BGP > MIB(rfc1657). There they have notifications like this, > bgpEstablished NOTIFICATION-TYPE > OBJECTS { bgpPeerLastError, > bgpPeerState } > STATUS current > DESCRIPTION > "The BGP Established event is > generated when > the BGP FSM enters the ESTABLISHED state." > ::= { bgpTraps 1 } > > bgpBackwardTransition NOTIFICATION-TYPE > OBJECTS { bgpPeerLastError, > bgpPeerState } > STATUS current > DESCRIPTION > "The BGPBackwardTransition Event > is generated > when the BGP FSM moves from a > higher numbered > state to a lower numbered state." > ::= { bgpTraps 2 } > > Our suggestion is to maintain ospfIfStateChange and use that > for monitoring all the states (some people may want that) and > additionally have notifications similar to the BGP > notifications. Its also true with VirtIfStateChange, > NbrStateChange and VirtNbrStateChange. If somebody doesn't > want to see ALL state TRAPS, they can suppress them by > turning off the corresponding bit in ospfSetTrap. > OK. Could you list the new BGP-like notifications for OSPF? > > ospfNbrStateChange > ------------------ > > [OPEN issue] This is not addressed yet. > > The DECRIPTION clause states > "When an neighbor transitions from or to Full on > non-broadcast multi-access and broadcast networks, the trap > should be generated by the designated router. A designated > router transitioning to Down will be noted by > ospfIfStateChange." I think here the intention is to reduce > the number of TRAPs as much as possible by making only DR > sending out this TRAP for a subnet. But there is a > possibility that osfpNbrStateChange notification is disabled > on DR and enabled on DR other or BDR. NMS won't receive TRAPs > when NbrState becomes FULL in that case. There is a problem > with the second part of above statments as well. Suppose > ospfIfStateChange is disabled on the router, then again NMS > won't know when neighbor goes down. Probably its better to > remove these two clauses. > > Thanks, > Roy > > > > "Manral, Vishwas" wrote: > > > > > > Dan Joyal is at present working on the OSPFv2 MIB. > > > > And the OSPFv3 MIB as well. > > > > > > Thanks, > > Acee > > > > > > Thanks, > > > Vishwas > > > > > > -----Original Message----- > > > From: Roy Jose [ mailto:rojose@CISCO.COM ] > > > Sent: Tuesday, March 18, 2003 12:03 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: OSPFv2 MIB draft > > > > > > Hi Acee, > > > > > > I agree with you. Till it becomes a standard draft, > vendors have to > > > go > with > > > some proprietory MIB I guess. Btw, who is working on the > MIB update > > > currently? > > > > > > Thanks, > > > Roy > > > > > > > One small correction. > > > > > > > > Acee Lindem wrote: > > > > > > > > > > Roy, > > > > > > > > > > There are 3 reasons why I don't think Sham Links should be > > > > > included in this MIB udpate: > > > > > > > > > > 1. I don't think they are sufficiently specified in the > > > > > Internet Draft describing them. My experience > implementing > > > > > the Sham Link feature required some reverse > > > > > engineering (Consult RFC 1264 for specification > > > > > requirements). > > > > > 2. The document describing them is not an OSPF WG > > > > > document. In fact, it is not even an PPVPN > > > > > document (although it could become one). > > > > > 3. At some point, we have to close the door on adding > > > > > MIB variables that are in all the drafts that may or > > > > > may not ever reach draft standard status. If we don't > > > > ~~~~~~~~~~~~~~ > > > > Meant to say "proposed standard" here. > > > > > > > > > do this, we'll never finish the MIB update. > > > > > > > > > > Thanks, > > > > > Acee > > > > > > > > > > Roy Jose wrote: > > > > > > > > > > > > Thanks Jeff, Acee, Mani and John for your responses. How > > > > > > about > other > > > > > > points?:) > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "John Flick" > > > > > > To: > > > > > > Sent: Saturday, March 15, 2003 6:19 AM > > > > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > > > > > Yep, adding an index would require deprecating everything > > > > > > > and > > > starting > > > > > > over. > > > > > > > Since this is an existing, widely deployed, Draft > Standard > > > > > > > MIB, > this > > > > > > should > > > > > > > not be done lightly. > > > > > > > > > > > > > > You would have the same problem if you tried changing > > > > > > > MAX-ACCESS > on > > > the > > > > > > > table indices (as was also suggested below). > Since a change > > > > > > > to > > > MAX-ACCESS > > > > > > > of an existing object is not allowed, you would need to > deprecated > > > the > > > > > > index > > > > > > > objects, which would require deprecating the tables that > > > > > > > they > index. > > > > > > Changing > > > > > > > to not-accessible is not required, since SMIv2 allows > > > > > > > read-only > > > indices > > > > > > for > > > > > > > MIB modules that were translated from SMIv1 and therefore > already > > > had > > > > > > > read-only indices. The OSPFv2 MIB started life > in RFC 1248 > > > > > > > as > an > > > SMIv1 > > > > > > MIB > > > > > > > module, so this exception applies. > > > > > > > > > > > > How about tables which were added later?: > > > > > > ospfAreaAggregateTable, ExtLsdbTable, etc. My worry > is not if > > > > > > its allowed or not. I am trying to point out > the > > > extra > > > > > > processing routers and > > > > > > NMS have to do with the increased number of messages. > > > > > > > > > > > > > As far as finding a generic solution for multiple > instances > > > > > > > of a > MIB > > > > > > module, > > > > > > > the standard solution is to use contexts (note: > this is not > > > > > > > the > same > > > as a > > > > > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this > > > > > > > was > done > > > in a > > > > > > > somewhat ad-hoc way by using different community > names for > > > > > > > each > > > instance > > > > > > > of the OSPF MIB. In SNMPv3, it is more formally defined > > > > > > > using > the > > > > > > > contextName. The Entity MIB entLogicalTable (RFC 2737) > > > > > > > provides > > > > > > information > > > > > > > about what contexts exist in an agent, and how to get to > > > > > > > them. > > > > > > > > > > > > After having a glance at rfc2737, I also think this is the > > > > > > way. I > > > think we > > > > > > need to specify it clearly how it can be achieved using > > > entLogicalTable. For > > > > > > example, how we need to represent the SNMP > community string to > > > retrieve info > > > > > > from a particular routing instance. > > > > > > > > > > > > Thanks, > > > > > > Roy > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > Acee Lindem wrote: > > > > > > > > > > > > > > > > Roy, > > > > > > > > > > > > > > > > I can appreciate your points since our product supports > > > > > > > > both > > > multiple > > > > > > > > virtual router instances and multiple routing protocol > instances > > > > > > > > within a particular virtual router. However, I > think we'd > > > > > > > > essentially have to deprecate everything in the current > > > > > > > > MIB > and > > > define > > > > > > > > new tables in order to add OSPF instance ID as > an index. > > > > > > > > Can > > > someone > > > > > > > > who has more MIB definition experience comment? > > > > > > > > > > > > > > > > Additionally, the multiple instance problem is > not unique > > > > > > > > to > the > > > > > > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > > > > > > > > > > > Roy Jose wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I have some comments on > > > > > > > > > draft-ietf-ospf-mib-update-05.txt. I > > > would > > > > > > also like > > > > > > > > > to have some clarifications. Please see the attached > document. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Roy > > > > > > > > > > > > > > > > > > > > > > > > > > >>Yes. An update is in the works. > > > > > > > > >> > > > > > > > > >>-Dan > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>>-----Original Message----- > > > > > > > > >>>From: Banerjee, Gargi > > > > > > > > >>>[ mailto:Gargi.Banerjee@MARCONI.COM ] > > > > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > > > > > > >>>Subject: OSPFv2 MIB draft > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>>Hi all: > > > > > > > > >>>I would like to know the status of the working group > > > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft > > > > > > > > >>>shows > an > > > > > > > > >>>expiry date of > > > > > > > > >>>May 2001. > > > > > > > > >>>Is there any plan to update the draft ? > > > > > > > > >>> > > > > > > > > >>>Thanks > > > > > > > > >>>Gargi > > > > > > > > >>> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > >>------------------------------------------------------------ > ---------- > >>-- > > > > > > > > >> > > > > > > > > >>Support for multiple OSPF processes: > > > > > > > > >>----------------------------------- > > > > > > > > >> > > > > > > > > >>We raised this issue some time back in WG. > Currently MIB > > > supports only > > > > > > one Router ID. > > > > > > > > >>Multiple processes can have separate router > IDs. It is > > > > > > > > >>also > true > > > with > > > > > > other MIB objects > > > > > > > > >>like ospfExternLsaCount, > ospfExternLsaCksumSum etc. The > solution > > > we > > > > > > got was to use a > > > > > > > > >>separate MIB view for each process. But I > don't think it > > > > > > > > >>can > be > > > easily > > > > > > implemented. > > > > > > > > >>We suggest to form a new table to group scalar objects > related > > > to an > > > > > > OSPF process and have > > > > > > > > >>Process Id as its INDEX. We also suggest to > add Process > > > > > > > > >>Id > as > > > one of > > > > > > the INDICES of all > > > > > > > > >>tables. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>MAX-ACCESS value for INDICES of TABLES: > > > > > > > > >>-------------------------------------- > > > > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. > > > > > > > > >>Normally > > > INDICES > > > > > > of a table are > > > > > > > > >>put as not-accesssible to reduce the number of SNMP > messages. > > > When an > > > > > > SNMP GET or > > > > > > > > >>GETNEXT is issued on a non-INDEX object, we > can extract > > > > > > > > >>the > > > values of > > > > > > INDICES from > > > > > > > > >>the object ID returned. For example, let us consider > > > ospfAreaLsaCount. > > > > > > When we query > > > > > > > > >>the value for this, we get something like > > > ospfAreaLsaCount.0.0.0.1, > > > > > > where 0.0.0.1 is > > > > > > > > >>the AreaId, which is the INDEX of the > ospfAreaTable. We > > > > > > > > >>can > > > extract > > > > > > the INDICES of > > > > > > > > >>table like this even if they are not-accessible. The > > > > > > > > >>tables > like > > > > > > LsdbTable has many > > > > > > > > >>number of INDICES and we can reduce the number of SNMP > messages > > > > > > considerably by changing > > > > > > > > >>them to not-accessible. > > > > > > > > >> > > > > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to > > > > > > > > >>include > > > them in > > > > > > the TRAP > > > > > > > > >>notification messages, they can be changed as > > > accessible-for-notify. > > > > > > Other approach to > > > > > > > > >>this is remove the INDICES from TRAP notification > > > > > > > > >>messages. > For > > > > > > example if you take the > > > > > > > > >>case of IfStateChange TRAP, > > > > > > > > >> > > > > > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > > > > > > >> OBJECTS { ospfRouterId, -- The > originator of the > trap^M > > > > > > > > >> ospfIfIpAddress,^M > > > > > > > > >> ospfAddressLessIf,^M > > > > > > > > >> ospfIfState -- The new state^M > > > > > > > > >> }^M > > > > > > > > >>Here we don't actually need ospfIfIpAddress and > > > ospfAddressLessIf. > > > > > > When we send TRAP > > > > > > > > >>notification, we can just send > > > > > > > > >>ospfIfState. > > > > > value>. . > > > > > > > > >>Also I am not sure why ospfRouterId is > included here. An > > > > > > > > >>NMS > > > station > > > > > > can always query ospfRouterId > > > > > > > > >>separately. By removing these MIB objects, we > can reduce > > > > > > > > >>the > > > size and > > > > > > processing time of TRAP > > > > > > > > >>messages considerably. > > > > > > > > >> > > > > > > > > >>Section : 4.3 Ignoring Initial Activity > > > > > > > > >>--------------------------------------- > > > > > > > > >>The section states "The majority of critical events > > > > > > > > >>occur > when > > > OSPF is > > > > > > enabled on a > > > > > > > > >>router, at which time the designated router > is elected > > > > > > > > >>and > > > neighbor > > > > > > adjacencies are formed" . > > > > > > > > >>I am not sure if enabling OSPF on a router means > > > > > > > > >>enabling it > on > > > an > > > > > > interface. I think it will > > > > > > > > >>be better to make the text clearer. > > > > > > > > >> > > > > > > > > >>Other statement is "To avoid unnecessary > traps, a router > should > > > not > > > > > > originate expected OSPF > > > > > > > > >>interface related traps until two of that interface's > > > > > > > > >>dead > timer > > > > > > intervals have elapsed." > > > > > > > > >>I think there will be some problems if the > dead interval > value > > > is too > > > > > > long. We may end up > > > > > > > > >>not sending any of the expected TRAPS for a > long time. > > > > > > > > >>Btw, > > > could I > > > > > > please know the reason > > > > > > > > >>for selecting 2 * dead interval value for > this purpose?. > There > > > might > > > > > > be some case where an > > > > > > > > >>interface is up and it goes down before (2 * dead > > > > > > > > >>interval). > We > > > can't > > > > > > take it as an 'expected > > > > > > > > >>event'. Probably we can ignore the expected > events till > > > > > > > > >>the > > > interface > > > > > > reaches terminal state > > > > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>One more point is we are already limiting > > > > > > > > >>ospfIfStateChange, > > > > > > ospfVirtIfStateChange, > > > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange > > > > > > > > >>notifications > by > > > > > > generating them only for terminal > > > > > > > > >>state changes and backward tansition. Do we > really need > > > > > > > > >>to > > > ignore them > > > > > > during the initial activity?. > > > > > > > > >> > > > > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and > > > ospfOriginateLsa > > > > > > traps should not be originated > > > > > > > > >>until two dead timer intervals have elapsed where the > deadtimer > > > > > > interval used should be the dead > > > > > > > > >>timer with the smallest value." Here whats > the meaning > > > > > > > > >>of > "dead > > > timer > > > > > > with smallest value"? Is it > > > > > > > > >>the smallest interval value among all the interfaces? > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>Section 4.4 Throttling Traps > > > > > > > > >>---------------------------- > > > > > > > > >>Do we need to provide MIB objects corresponding to > > > > > > > > >>window > size > > > and the > > > > > > number of TRAPs sent during > > > > > > > > >>the window time? Will the TRAPs other than > > > > > > > > >>ospfTxRetransmit, > > > > > > OrginateLsa and MaxAgeLsa really cause > > > > > > > > >>a TRAP flood? Probably we need to throttle only the > > > > > > > > >>above > three > > > TRAPS? > > > > > > > > >> > > > > > > > > >>I think the normal practice is to inform the > NMS using > > > > > > > > >>some > > > other > > > > > > notification at the end of a > > > > > > > > >>particular interval when the TRAPs are dropped like > > > > > > > > >>this, > "Trap > > > N > > > > > > dropped n times in an interval > > > > > > > > >>t". We can add some common extra paratmeters to these > > > notifications to > > > > > > facilitate the NMS to query > > > > > > > > >>the router to retrieve some values and find out whats > happening. > > > > > > > > >> > > > > > > > > >>ospfConfigErrorType > > > > > > > > >>------------------- > > > > > > > > >>Do we need an error type for duplicate router > id in the > received > > > > > > messages? Some times loop back > > > > > > > > >>address can be misconfigured. > > > > > > > > >> > > > > > > > > >>ospfSetTrap > > > > > > > > >>----------- > > > > > > > > >>The definition of this is little complicated. Any > > > > > > > > >>reasons > for > > > going > > > > > > for last bit to first. We think > > > > > > > > >>its better to redefine this MIB object like > this to make > > > > > > > > >>if > more > > > > > > clear. > > > > > > > > >> > > > > > > > > >> cospfSetTrap OBJECT-TYPE > > > > > > > > >> SYNTAX BITS { > > > > > > > > >> ifConfigError (0), > > > > > > > > >> virtIfConfigError (1), > > > > > > > > >> ospfNbrStateChange (2), > > > > > > > > >> . > > > > > > > > >> . > > > > > > > > >> . > > > > > > > > >> } > > > > > > > > >> MAX-ACCESS read-write > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "A One-octet string serving as a > bit map for > > > > > > > > >> the trap events defined by the > OSPF traps in > > > > > > > > >> this MIB. This object is used to enable and > > > > > > > > >> disable specific OSPF traps > where a 1 > > > > > > > > >> in the corresponding bit field > represents > > > > > > > > >> enabled." > > > > > > > > >> ::= { cospfTrapControl 1 } > > > > > > > > >> > > > > > > > > >>This definition enables the NMS to interpret > the bit map > easily. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>ospfIfStateChange > > > > > > > > >>----------------- > > > > > > > > >> > > > > > > > > >>>From the definition it looks like this TRAP should be > generated > > > only > > > > > > for terminal states(when state > > > > > > > > >>progresses) and for backward transition. > Infact the name > > > > > > ospfIfStateChange simply suggests to > > > > > > > > >>generate TRAPs for all state transitions. The general > tendency > > > is to > > > > > > ignore the DESCRIPTION when > > > > > > > > >>"StateChange" is read and assume its for all the state > changes. > > > It > > > > > > might lead to wrong > > > > > > > > >>implementations. I think we can also follow > the approach > taken > > > in BGP > > > > > > MIB(rfc1657). > > > > > > > > >>There they have notifications like this, > > > > > > > > >> bgpEstablished NOTIFICATION-TYPE > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > >> bgpPeerState } > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "The BGP > Established event > > > > > > > > >>is > > > generated > > > > > > when > > > > > > > > >> the BGP FSM enters the > ESTABLISHED > > > state." > > > > > > > > >> ::= { bgpTraps 1 } > > > > > > > > >> > > > > > > > > >> bgpBackwardTransition > NOTIFICATION-TYPE > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > >> bgpPeerState } > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "The > BGPBackwardTransition > > > > > > > > >> Event > is > > > > > > generated > > > > > > > > >> when the BGP FSM > moves from > > > > > > > > >> a > higher > > > > > > numbered > > > > > > > > >> state to a lower numbered > state." > > > > > > > > >> ::= { bgpTraps 2 } > > > > > > > > >> > > > > > > > > >>Our suggestion is to maintain > ospfIfStateChange and use > > > > > > > > >>that > for > > > > > > monitoring all the states > > > > > > > > >>(some people may want that) and additionally have > notifications > > > > > > similar to the BGP notifications. > > > > > > > > >>Its also true with VirtIfStateChange, > NbrStateChange and > > > > > > VirtNbrStateChange. If somebody doesn't > > > > > > > > >>want to see ALL state TRAPS, they can suppress them by > turning > > > off the > > > > > > corresponding bit in > > > > > > > > >>ospfSetTrap. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>ospfNbrStateChange > > > > > > > > >>------------------ > > > > > > > > >>The DECRIPTION clause states > > > > > > > > >>"When an neighbor transitions from or to Full on > non-broadcast > > > > > > multi-access and broadcast > > > > > > > > >> networks, the trap should be generated by the > > > > > > > > >> designated > > > router. A > > > > > > designated router > > > > > > > > >>transitioning to Down will be noted by > > > > > > > > >>ospfIfStateChange." I think here the intention is to > > > > > > > > >>reduce the number of TRAPs > as > > > much as > > > > > > possible by making > > > > > > > > >>only DR sending out this TRAP for a subnet. > But there is > > > > > > > > >>a > > > possibility > > > > > > that osfpNbrStateChange > > > > > > > > >>notification is disabled on DR and enabled on > DR other > > > > > > > > >>or > BDR. > > > NMS > > > > > > won't receive TRAPs when > > > > > > > > >>NbrState becomes FULL in that case. There is > a problem > > > > > > > > >>with > the > > > second > > > > > > part of above statments > > > > > > > > >>as well. Suppose ospfIfStateChange is disabled on the > router, > > > then > > > > > > again NMS won't know when > > > > > > > > >>neighbor goes down. Probably its better to > remove these > > > > > > > > >>two > > > clauses. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>Support for sham links: > > > > > > > > >>----------------------- > > > > > > > > >>Are you going to provide support for sham > links? We may > > > > > > > > >>need > > > these > > > > > > tables and notifications, > > > > > > > > >>ShamLinkTable > > > > > > > > >>ShamLinkNbrTable > > > > > > > > >>ShamLinkStateChange notification > ShamLinkNbrStateChange > > > > > > > > >>notification > > > > > > > > > ------_=_NextPart_001_01C2EE6A.E9410CF6 Content-Type: text/html RE: OSPFv2 MIB draft
Hi Dan,
 
Just wanted to say hello from the Telesto world.
We are still in orbit aound Saturn deciding what to do :-)
Have you settled down yet?
 
Girish
-----Original Message-----
From: Daniel Joyal [mailto:djoyal@NORTELNETWORKS.COM]
Sent: Wednesday, March 19, 2003 5:22 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: OSPFv2 MIB draft

Comments in-line below.

-Dan

> -----Original Message-----
> From: Roy Jose [mailto:rojose@CISCO.COM]
> Sent: Wednesday, March 19, 2003 6:05 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: OSPFv2 MIB draft
>
>
> Thanks Manral, Acee.
>
> Let me point out the open issues here from the original
> document I sent. Joyal, please let me know if you need any
> clarifications.
>
> Support for multiple OSPF processes:
> -----------------------------------
>
> We raised this issue some time back in WG. Currently MIB
> supports only one Router ID. Multiple processes can have
> separate router IDs. It is also true with other MIB objects
> like ospfExternLsaCount, ospfExternLsaCksumSum etc. The
> solution we got was to use a separate MIB view for each
> process. But I don't think it can be easily implemented. We
> suggest to form a new table to group scalar objects related
> to an OSPF process and have Process Id as its INDEX. We also
> suggest to add Process Id as one of the INDICES of all
> tables. [WG - John Flick] As far as finding a generic
> solution for multiple instances of a MIB module, the standard
> solution is to use contexts (note: this is not the same as a
> MIB view.  See RFC 3411, section 3.3.1).  In SNMPv1, this was
> done in a somewhat ad-hoc way by using different community
> names for each instance of the OSPF MIB.  In SNMPv3, it is
> more formally defined using the contextName.  The Entity MIB
> entLogicalTable (RFC 2737) provides information about what
> contexts exist in an agent, and how to get to them. [OPEN
> issue] I think we need to investigate on this and add a
> section to the draft how it can be applied to OSPF MIB .
>

This issue is not unique to the OSPF MIBs. I would prefer
to just reference the RFCs that deal with SNMP contexts that
John Flick mentioned.

>
> MAX-ACCESS value for INDICES of TABLES:
> --------------------------------------
> I see MAX-ACCESS value of all TABLEs are read-only. Normally
> INDICES of a table are put as not-accesssible to reduce the
> number of SNMP messages. When an SNMP GET or GETNEXT is
> issued on a non-INDEX object, we can extract the values of
> INDICES from the object ID returned. For example, let us
> consider ospfAreaLsaCount. When we query the value for this,
> we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1
> is the AreaId, which is the INDEX of the ospfAreaTable. We
> can extract the INDICES of table like this even if they are
> not-accessible. The tables like LsdbTable has many number of
> INDICES and we can reduce the number of SNMP messages
> considerably by changing them to not-accessible.
>
> [WG - John Flick]
> You would have the same problem if you tried changing
> MAX-ACCESS on the table indices (as was also suggested
> below).  Since a change to MAX-ACCESS of an existing object
> is not allowed, you would need to deprecated the index
> objects, which would require deprecating the tables that they
> index. Changing to not-accessible is not required, since
> SMIv2 allows read-only indices for MIB modules that were
> translated from SMIv1 and therefore already had read-only
> indices.  The OSPFv2 MIB started life in RFC 1248 as an SMIv1
> MIB module, so this exception applies.
>
> [OPEN issue]
> As I have pointed out earlier, by changing the INDICES we can
> reduce the number of  SNMP GETNEXT reponses sent by the
> router considerably. The draft standard MIB is already widely
> deployed. But we need to deprecate an existing MIB and add a
> new version, when it is required. I feel if everyone thinks
> what I pointed out is a big advantange, still we can go ahead
> with this change.
>
> If the MAX-ACCESS of INDICES are put as read-only to include
> them in the TRAP notification messages, they can be changed
> as accessible-for-notify. Other approach to this is remove
> the INDICES from TRAP notification messages. For example if
> you take the case of IfStateChange TRAP,
>
>    ospfIfStateChange NOTIFICATION-TYPE^M
>         OBJECTS { ospfRouterId, -- The originator of the trap^M
>            ospfIfIpAddress,^M
>            ospfAddressLessIf,^M
>            ospfIfState   -- The new state^M
>            }^M
> Here we don't actually need ospfIfIpAddress and
> ospfAddressLessIf. When we send TRAP notification, we can
> just send ospfIfState.<ospfIfIpAddress
> value>.<ospfAddressLessIf value> .
> Also I am not sure why ospfRouterId is included here. An NMS
> station can always query ospfRouterId separately. By removing
> these MIB objects, we can reduce the size and processing time
> of TRAP messages considerably.
>
> [OPEN issue] The above point is not addressed yet.
>

I think there would need to be a strong WG consensus that deprecating the
entire MIB for this is worth it.
 
> Section : 4.3 Ignoring Initial Activity
> ---------------------------------------
>
> [OPEN issue] This is not addressed yet.
>
> The section states "The majority of critical events occur
> when OSPF is enabled on a router, at which time the
> designated router is elected and neighbor adjacencies are
> formed" . I am not sure if enabling OSPF on a router means
> enabling it on an interface. I think it will be better to
> make the text clearer.
>
> Other statement is "To avoid unnecessary traps, a router
> should not originate expected OSPF interface related traps
> until two of that interface's dead timer intervals have
> elapsed." I think there will be some problems if the dead
> interval value is too long. We may end up not sending any of
> the expected TRAPS for a long time. Btw, could I please know
> the reason for selecting 2 * dead interval value for this
> purpose?. There might be some case where an interface is up
> and it goes down before (2 * dead interval). We can't take it
> as an 'expected event'. Probably we can ignore the expected
> events till the interface reaches terminal state (FULL or
> 2WAY) for the first time after enabling OSPF.
>
>
> One more point is we are already limiting ospfIfStateChange,
> ospfVirtIfStateChange, ospfNbrStateChange and
> ospfVirtNbrStateChange notifications by generating them only
> for terminal state changes and backward tansition. Do we
> really need to ignore them during the initial activity?.
>
> Other statement is "Additionally, ospfMaxAgeLsa and
> ospfOriginateLsa traps should not be originated until two
> dead timer intervals have elapsed where the deadtimer
> interval used should be the dead timer with the smallest
> value." Here whats the meaning of "dead timer with smallest
> value"? Is it the smallest interval value among all the interfaces?
>

I think the intent of the original authors of the MIB was
to give some guidelines (hence the wording "should not" rather
than "must not") for when or when not to generate traps. I don't
know how closely real world implementations follow these guidelines.

>
> Section 4.4 Throttling Traps
> ----------------------------
>
> [OPEN issue] This is not addressed yet.
>
> Do we need to provide MIB objects corresponding to window
> size and the number of TRAPs sent during the window time?
> Will the TRAPs other than ospfTxRetransmit, OrginateLsa and
> MaxAgeLsa really cause a TRAP flood? Probably we need to
> throttle only the above three TRAPS?
>
> I think the normal practice is to inform the NMS using some
> other notification at the end of a particular interval when
> the TRAPs are dropped like this, "Trap N dropped n times in
> an interval t". We can add some common extra paratmeters to
> these notifications to facilitate the NMS to query the router
> to retrieve some values and find out whats happening.
>
> ospfConfigErrorType
> -------------------
>
> [OPEN issue] This is not addressed yet.
>
> Do we need an error type for duplicate router id in the
> received messages? Some times loop back address can be misconfigured.

Easy to add if required.

>
> ospfSetTrap
> -----------
>
> [OPEN issue] This is not addressed yet.
>
> The definition of this is little complicated. Any reasons for
> going for last bit to first. We think its better to redefine
> this MIB object like this to make if more clear.
>
>   cospfSetTrap OBJECT-TYPE
>         SYNTAX BITS {
>                        ifConfigError (0),
>                        virtIfConfigError (1),
>                        ospfNbrStateChange (2),
>                           .
>                           .
>                           .
>                     }
>         MAX-ACCESS   read-write
>         STATUS   current
>         DESCRIPTION
>            "A One-octet string serving as a bit  map  for
>            the trap events defined by the OSPF traps in
>            this MIB. This object is used to enable and
>            disable  specific OSPF   traps   where  a  1
>            in  the  corresponding bit  field represents
>            enabled."
>        ::= { cospfTrapControl 1 }
>
> This definition enables the NMS to interpret the bit map easily.

Changing to a non-equivalent syntax would require creation of a new object.

>
>
> ospfIfStateChange
> -----------------
> [OPEN issue] This is not addressed yet.
>
> From the definition it looks like this TRAP should be
> generated only for terminal states(when state
> progresses) and for backward transition. Infact the name
> ospfIfStateChange simply suggests to generate TRAPs for all
> state transitions. The general tendency is to ignore the
> DESCRIPTION when "StateChange" is read and assume its for all
> the state changes. It might lead to wrong implementations. I
> think we can also follow the approach taken in BGP
> MIB(rfc1657). There they have notifications like this,
>                 bgpEstablished NOTIFICATION-TYPE
>                     OBJECTS { bgpPeerLastError,
>                               bgpPeerState      }
>                     STATUS  current
>                     DESCRIPTION
>                             "The BGP Established event is
> generated when
>                             the BGP FSM enters the ESTABLISHED state."
>                     ::= { bgpTraps 1 }
>
>                 bgpBackwardTransition NOTIFICATION-TYPE
>                     OBJECTS { bgpPeerLastError,
>                               bgpPeerState      }
>                     STATUS  current
>                     DESCRIPTION
>                             "The BGPBackwardTransition Event
> is generated
>                             when the BGP FSM moves from a
> higher numbered
>                             state to a lower numbered state."
>                     ::= { bgpTraps 2 }
>
> Our suggestion is to maintain ospfIfStateChange and use that
> for monitoring all the states (some people may want that) and
> additionally have notifications similar to the BGP
> notifications. Its also true with VirtIfStateChange,
> NbrStateChange and VirtNbrStateChange. If somebody doesn't
> want to see ALL state TRAPS, they can suppress them by
> turning off the corresponding bit in ospfSetTrap.
>

OK. Could you list the new BGP-like notifications for OSPF?

>
> ospfNbrStateChange
> ------------------
>
> [OPEN issue] This is not addressed yet.
>
> The DECRIPTION clause states
> "When an neighbor transitions from or to Full on
> non-broadcast multi-access and broadcast  networks, the trap
> should be generated  by the designated router. A designated
> router transitioning to Down will be noted by
> ospfIfStateChange." I think here the intention is to reduce
> the number of TRAPs as much as possible by making only DR
> sending out this TRAP for a subnet. But there is a
> possibility that osfpNbrStateChange notification is disabled
> on DR and enabled on DR other or BDR. NMS won't receive TRAPs
> when NbrState becomes FULL in that case. There is a problem
> with the second part of above statments as well. Suppose
> ospfIfStateChange is disabled on the router, then again NMS
> won't know when neighbor goes down. Probably its better to
> remove these two clauses.
>
> Thanks,
> Roy
>
>
> > "Manral, Vishwas" wrote:
> > >
> > > Dan Joyal is at present working on the OSPFv2 MIB.
> >
> > And the OSPFv3 MIB as well.
> >
> >
> > Thanks,
> > Acee
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Roy Jose [mailto:rojose@CISCO.COM]
> > > Sent: Tuesday, March 18, 2003 12:03 PM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: Re: OSPFv2 MIB draft
> > >
> > > Hi Acee,
> > >
> > > I agree with you. Till it becomes a standard draft,
> vendors have to
> > > go
> with
> > > some proprietory MIB I guess. Btw, who is working on the
> MIB update
> > > currently?
> > >
> > > Thanks,
> > > Roy
> > >
> > > > One small correction.
> > > >
> > > > Acee Lindem wrote:
> > > > >
> > > > > Roy,
> > > > >
> > > > > There are 3 reasons why I don't think Sham Links should be
> > > > > included in this MIB udpate:
> > > > >
> > > > >   1. I don't think they are sufficiently specified in the
> > > > >      Internet Draft describing them. My experience
> implementing
> > > > >      the Sham Link feature required some reverse
> > > > >      engineering (Consult RFC 1264 for specification
> > > > >      requirements).
> > > > >   2. The document describing them is not an OSPF WG
> > > > >      document. In fact, it is not even an PPVPN
> > > > >      document (although it could become one).
> > > > >   3. At some point, we have to close the door on adding
> > > > >      MIB variables that are in all the drafts that may or
> > > > >      may not ever reach draft standard status. If we don't
> > > >                           ~~~~~~~~~~~~~~
> > > >    Meant to say "proposed standard" here.
> > > >
> > > > >      do this, we'll never finish the MIB update.
> > > > >
> > > > > Thanks,
> > > > > Acee
> > > > >
> > > > > Roy Jose wrote:
> > > > > >
> > > > > > Thanks Jeff, Acee, Mani and John  for your responses.  How
> > > > > > about
> other
> > > > > > points?:)
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "John Flick" <johnf@ROSE.HP.COM>
> > > > > > To: <OSPF@DISCUSS.MICROSOFT.COM>
> > > > > > Sent: Saturday, March 15, 2003 6:19 AM
> > > > > > Subject: Re: OSPFv2 MIB draft
> > > > > >
> > > > > > > Yep, adding an index would require deprecating everything
> > > > > > > and
> > > starting
> > > > > > over.
> > > > > > > Since this is an existing, widely deployed, Draft
> Standard
> > > > > > > MIB,
> this
> > > > > > should
> > > > > > > not be done lightly.
> > > > > > >
> > > > > > > You would have the same problem if you tried changing
> > > > > > > MAX-ACCESS
> on
> > > the
> > > > > > > table indices (as was also suggested below). 
> Since a change
> > > > > > > to
> > > MAX-ACCESS
> > > > > > > of an existing object is not allowed, you would need to
> deprecated
> > > the
> > > > > > index
> > > > > > > objects, which would require deprecating the tables that
> > > > > > > they
> index.
> > > > > > Changing
> > > > > > > to not-accessible is not required, since SMIv2 allows
> > > > > > > read-only
> > > indices
> > > > > > for
> > > > > > > MIB modules that were translated from SMIv1 and therefore
> already
> > > had
> > > > > > > read-only indices.  The OSPFv2 MIB started life
> in RFC 1248
> > > > > > > as
> an
> > > SMIv1
> > > > > > MIB
> > > > > > > module, so this exception applies.
> > > > > >
> > > > > > How about tables which were added later?:
> > > > > > ospfAreaAggregateTable, ExtLsdbTable, etc. My worry
> is not if
> > > > > > its allowed or not. I am trying to point out
> the
> > > extra
> > > > > > processing routers and
> > > > > > NMS have to do with the increased number of messages.
> > > > > >
> > > > > > > As far as finding a generic solution for multiple
> instances
> > > > > > > of a
> MIB
> > > > > > module,
> > > > > > > the standard solution is to use contexts (note:
> this is not
> > > > > > > the
> same
> > > as a
> > > > > > > MIB view.  See RFC 3411, section 3.3.1).  In SNMPv1, this
> > > > > > > was
> done
> > > in a
> > > > > > > somewhat ad-hoc way by using different community
> names for
> > > > > > > each
> > > instance
> > > > > > > of the OSPF MIB.  In SNMPv3, it is more formally defined
> > > > > > > using
> the
> > > > > > > contextName.  The Entity MIB entLogicalTable (RFC 2737)
> > > > > > > provides
> > > > > > information
> > > > > > > about what contexts exist in an agent, and how to get to
> > > > > > > them.
> > > > > >
> > > > > > After having a glance at rfc2737, I also think this is the
> > > > > > way. I
> > > think we
> > > > > > need to specify it clearly how it can be achieved using
> > > entLogicalTable. For
> > > > > > example, how we need to represent the SNMP
> community string to
> > > retrieve info
> > > > > > from a particular routing instance.
> > > > > >
> > > > > > Thanks,
> > > > > > Roy
> > > > > >
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > Acee Lindem wrote:
> > > > > > > >
> > > > > > > > Roy,
> > > > > > > >
> > > > > > > > I can appreciate your points since our product supports
> > > > > > > > both
> > > multiple
> > > > > > > > virtual router instances and multiple routing protocol
> instances
> > > > > > > > within a particular virtual router. However, I
> think we'd
> > > > > > > > essentially have to deprecate everything in the current
> > > > > > > > MIB
> and
> > > define
> > > > > > > > new tables in order to add OSPF instance ID as
> an index.
> > > > > > > > Can
> > > someone
> > > > > > > > who has more MIB definition experience comment?
> > > > > > > >
> > > > > > > > Additionally, the multiple instance problem is
> not unique
> > > > > > > > to
> the
> > > > > > > > OSPF MIB. Maybe a generic solution could be developed.
> > > > > > > >
> > > > > > > > Roy Jose wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I have some comments on
> > > > > > > > > draft-ietf-ospf-mib-update-05.txt. I
> > > would
> > > > > > also like
> > > > > > > > > to have some clarifications. Please see the attached
> document.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Roy
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >>Yes. An update is in the works.
> > > > > > > > >>
> > > > > > > > >>-Dan
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>>-----Original Message-----
> > > > > > > > >>>From: Banerjee, Gargi
> > > > > > > > >>>[mailto:Gargi.Banerjee@MARCONI.COM]
> > > > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM
> > > > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM
> > > > > > > > >>>Subject: OSPFv2 MIB draft
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>Hi all:
> > > > > > > > >>>I would like to know the status of the working group
> > > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft
> > > > > > > > >>>shows
> an
> > > > > > > > >>>expiry date of
> > > > > > > > >>>May 2001.
> > > > > > > > >>>Is there any plan to update the draft ?
> > > > > > > > >>>
> > > > > > > > >>>Thanks
> > > > > > > > >>>Gargi
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > >
> > > > > >
> > >
> >>------------------------------------------------------------
> ----------
> >>--
> > > > > > > > >>
> > > > > > > > >>Support for multiple OSPF processes:
> > > > > > > > >>-----------------------------------
> > > > > > > > >>
> > > > > > > > >>We raised this issue some time back in WG.
> Currently MIB
> > > supports only
> > > > > > one Router ID.
> > > > > > > > >>Multiple processes can have separate router
> IDs. It is
> > > > > > > > >>also
> true
> > > with
> > > > > > other MIB objects
> > > > > > > > >>like ospfExternLsaCount,
> ospfExternLsaCksumSum etc. The
> solution
> > > we
> > > > > > got was to use a
> > > > > > > > >>separate MIB view for each process. But I
> don't think it
> > > > > > > > >>can
> be
> > > easily
> > > > > > implemented.
> > > > > > > > >>We suggest to form a new table to group scalar objects
> related
> > > to an
> > > > > > OSPF process and have
> > > > > > > > >>Process Id as its INDEX. We also suggest to
> add Process
> > > > > > > > >>Id
> as
> > > one of
> > > > > > the INDICES of all
> > > > > > > > >>tables.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>MAX-ACCESS value for INDICES of TABLES:
> > > > > > > > >>--------------------------------------
> > > > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only.
> > > > > > > > >>Normally
> > > INDICES
> > > > > > of a table are
> > > > > > > > >>put as not-accesssible to reduce the number of SNMP
> messages.
> > > When an
> > > > > > SNMP GET or
> > > > > > > > >>GETNEXT is issued on a non-INDEX object, we
> can extract
> > > > > > > > >>the
> > > values of
> > > > > > INDICES from
> > > > > > > > >>the object ID returned. For example, let us consider
> > > ospfAreaLsaCount.
> > > > > > When we query
> > > > > > > > >>the value for this, we get something like
> > > ospfAreaLsaCount.0.0.0.1,
> > > > > > where 0.0.0.1 is
> > > > > > > > >>the AreaId, which is the INDEX of the
> ospfAreaTable. We
> > > > > > > > >>can
> > > extract
> > > > > > the INDICES of
> > > > > > > > >>table like this even if they are not-accessible. The
> > > > > > > > >>tables
> like
> > > > > > LsdbTable has many
> > > > > > > > >>number of INDICES and we can reduce the number of SNMP
> messages
> > > > > > considerably by changing
> > > > > > > > >>them to not-accessible.
> > > > > > > > >>
> > > > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to
> > > > > > > > >>include
> > > them in
> > > > > > the TRAP
> > > > > > > > >>notification messages, they can be changed as
> > > accessible-for-notify.
> > > > > > Other approach to
> > > > > > > > >>this is remove the INDICES from TRAP notification
> > > > > > > > >>messages.
> For
> > > > > > example if you take the
> > > > > > > > >>case of IfStateChange TRAP,
> > > > > > > > >>
> > > > > > > > >>   ospfIfStateChange NOTIFICATION-TYPE^M
> > > > > > > > >>        OBJECTS { ospfRouterId, -- The
> originator of the
> trap^M
> > > > > > > > >>           ospfIfIpAddress,^M
> > > > > > > > >>           ospfAddressLessIf,^M
> > > > > > > > >>           ospfIfState   -- The new state^M
> > > > > > > > >>           }^M
> > > > > > > > >>Here we don't actually need ospfIfIpAddress and
> > > ospfAddressLessIf.
> > > > > > When we send TRAP
> > > > > > > > >>notification, we can just send
> > > > > > > > >>ospfIfState.<ospfIfIpAddress
> > > > > > value>.<ospfAddressLessIf value> .
> > > > > > > > >>Also I am not sure why ospfRouterId is
> included here. An
> > > > > > > > >>NMS
> > > station
> > > > > > can always query ospfRouterId
> > > > > > > > >>separately. By removing these MIB objects, we
> can reduce
> > > > > > > > >>the
> > > size and
> > > > > > processing time of TRAP
> > > > > > > > >>messages considerably.
> > > > > > > > >>
> > > > > > > > >>Section : 4.3 Ignoring Initial Activity
> > > > > > > > >>---------------------------------------
> > > > > > > > >>The section states "The majority of critical events
> > > > > > > > >>occur
> when
> > > OSPF is
> > > > > > enabled on a
> > > > > > > > >>router, at which time the designated router
> is elected
> > > > > > > > >>and
> > > neighbor
> > > > > > adjacencies are formed" .
> > > > > > > > >>I am not sure if enabling OSPF on a router means
> > > > > > > > >>enabling it
> on
> > > an
> > > > > > interface. I think it will
> > > > > > > > >>be better to make the text clearer.
> > > > > > > > >>
> > > > > > > > >>Other statement is "To avoid unnecessary
> traps, a router
> should
> > > not
> > > > > > originate expected OSPF
> > > > > > > > >>interface related traps until two of that interface's
> > > > > > > > >>dead
> timer
> > > > > > intervals have elapsed."
> > > > > > > > >>I think there will be some problems if the
> dead interval
> value
> > > is too
> > > > > > long. We may end up
> > > > > > > > >>not sending any of the expected TRAPS for a
> long time.
> > > > > > > > >>Btw,
> > > could I
> > > > > > please know the reason
> > > > > > > > >>for selecting 2 * dead interval value for
> this purpose?.
> There
> > > might
> > > > > > be some case where an
> > > > > > > > >>interface is up and it goes down before (2 * dead
> > > > > > > > >>interval).
> We
> > > can't
> > > > > > take it as an 'expected
> > > > > > > > >>event'. Probably we can ignore the expected
> events till
> > > > > > > > >>the
> > > interface
> > > > > > reaches terminal state
> > > > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>One more point is we are already limiting
> > > > > > > > >>ospfIfStateChange,
> > > > > > ospfVirtIfStateChange,
> > > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange
> > > > > > > > >>notifications
> by
> > > > > > generating them only for terminal
> > > > > > > > >>state changes and backward tansition. Do we
> really need
> > > > > > > > >>to
> > > ignore them
> > > > > > during the initial activity?.
> > > > > > > > >>
> > > > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and
> > > ospfOriginateLsa
> > > > > > traps  should not be originated
> > > > > > > > >>until two dead timer intervals have elapsed where the
> deadtimer
> > > > > > interval used should be the dead
> > > > > > > > >>timer with the smallest value." Here whats
> the meaning
> > > > > > > > >>of
> "dead
> > > timer
> > > > > > with smallest value"? Is it
> > > > > > > > >>the smallest interval value among all the interfaces?
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>Section 4.4 Throttling Traps
> > > > > > > > >>----------------------------
> > > > > > > > >>Do we need to provide MIB objects corresponding to
> > > > > > > > >>window
> size
> > > and the
> > > > > > number of TRAPs sent during
> > > > > > > > >>the window time? Will the TRAPs other than
> > > > > > > > >>ospfTxRetransmit,
> > > > > > OrginateLsa and MaxAgeLsa really cause
> > > > > > > > >>a TRAP flood? Probably we need to throttle only the
> > > > > > > > >>above
> three
> > > TRAPS?
> > > > > > > > >>
> > > > > > > > >>I think the normal practice is to inform the
> NMS using
> > > > > > > > >>some
> > > other
> > > > > > notification at the end of a
> > > > > > > > >>particular interval when the TRAPs are dropped like
> > > > > > > > >>this,
> "Trap
> > > N
> > > > > > dropped n times in an interval
> > > > > > > > >>t". We can add some common extra paratmeters to these
> > > notifications to
> > > > > > facilitate the NMS to query
> > > > > > > > >>the router to retrieve some values and find out whats
> happening.
> > > > > > > > >>
> > > > > > > > >>ospfConfigErrorType
> > > > > > > > >>-------------------
> > > > > > > > >>Do we need an error type for duplicate router
> id in the
> received
> > > > > > messages? Some times loop back
> > > > > > > > >>address can be misconfigured.
> > > > > > > > >>
> > > > > > > > >>ospfSetTrap
> > > > > > > > >>-----------
> > > > > > > > >>The definition of this is little complicated. Any
> > > > > > > > >>reasons
> for
> > > going
> > > > > > for last bit to first. We think
> > > > > > > > >>its better to redefine this MIB object like
> this to make
> > > > > > > > >>if
> more
> > > > > > clear.
> > > > > > > > >>
> > > > > > > > >>  cospfSetTrap OBJECT-TYPE
> > > > > > > > >>        SYNTAX BITS {
> > > > > > > > >>                       ifConfigError (0),
> > > > > > > > >>                       virtIfConfigError (1),
> > > > > > > > >>                       ospfNbrStateChange (2),
> > > > > > > > >>                          .
> > > > > > > > >>                          .
> > > > > > > > >>                          .
> > > > > > > > >>                    }
> > > > > > > > >>        MAX-ACCESS   read-write
> > > > > > > > >>        STATUS   current
> > > > > > > > >>        DESCRIPTION
> > > > > > > > >>           "A One-octet string serving as a
> bit  map  for
> > > > > > > > >>           the trap events defined by the
> OSPF traps in
> > > > > > > > >>           this MIB. This object is used to enable and
> > > > > > > > >>           disable  specific OSPF   traps  
> where  a  1
> > > > > > > > >>           in  the  corresponding bit  field
> represents
> > > > > > > > >>           enabled."
> > > > > > > > >>       ::= { cospfTrapControl 1 }
> > > > > > > > >>
> > > > > > > > >>This definition enables the NMS to interpret
> the bit map
> easily.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>ospfIfStateChange
> > > > > > > > >>-----------------
> > > > > > > > >>
> > > > > > > > >>>From the definition it looks like this TRAP should be
> generated
> > > only
> > > > > > for terminal states(when state
> > > > > > > > >>progresses) and for backward transition.
> Infact the name
> > > > > > ospfIfStateChange simply suggests to
> > > > > > > > >>generate TRAPs for all state transitions. The general
> tendency
> > > is to
> > > > > > ignore the DESCRIPTION when
> > > > > > > > >>"StateChange" is read and assume its for all the state
> changes.
> > > It
> > > > > > might lead to wrong
> > > > > > > > >>implementations. I think we can also follow
> the approach
> taken
> > > in BGP
> > > > > > MIB(rfc1657).
> > > > > > > > >>There they have notifications like this,
> > > > > > > > >>                bgpEstablished NOTIFICATION-TYPE
> > > > > > > > >>                    OBJECTS { bgpPeerLastError,
> > > > > > > > >>                              bgpPeerState      }
> > > > > > > > >>                    STATUS  current
> > > > > > > > >>                    DESCRIPTION
> > > > > > > > >>                            "The BGP
> Established event
> > > > > > > > >>is
> > > generated
> > > > > > when
> > > > > > > > >>                            the BGP FSM enters the
> ESTABLISHED
> > > state."
> > > > > > > > >>                    ::= { bgpTraps 1 }
> > > > > > > > >>
> > > > > > > > >>                bgpBackwardTransition
> NOTIFICATION-TYPE
> > > > > > > > >>                    OBJECTS { bgpPeerLastError,
> > > > > > > > >>                              bgpPeerState      }
> > > > > > > > >>                    STATUS  current
> > > > > > > > >>                    DESCRIPTION
> > > > > > > > >>                            "The
> BGPBackwardTransition
> > > > > > > > >> Event
> is
> > > > > > generated
> > > > > > > > >>                            when the BGP FSM
> moves from
> > > > > > > > >> a
> higher
> > > > > > numbered
> > > > > > > > >>                            state to a lower numbered
> state."
> > > > > > > > >>                    ::= { bgpTraps 2 }
> > > > > > > > >>
> > > > > > > > >>Our suggestion is to maintain
> ospfIfStateChange and use
> > > > > > > > >>that
> for
> > > > > > monitoring all the states
> > > > > > > > >>(some people may want that) and additionally have
> notifications
> > > > > > similar to the BGP notifications.
> > > > > > > > >>Its also true with VirtIfStateChange,
> NbrStateChange and
> > > > > > VirtNbrStateChange. If somebody doesn't
> > > > > > > > >>want to see ALL state TRAPS, they can suppress them by
> turning
> > > off the
> > > > > > corresponding bit in
> > > > > > > > >>ospfSetTrap.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>ospfNbrStateChange
> > > > > > > > >>------------------
> > > > > > > > >>The DECRIPTION clause states
> > > > > > > > >>"When an neighbor transitions from or to Full on
> non-broadcast
> > > > > > multi-access and broadcast
> > > > > > > > >> networks, the trap should be generated  by the
> > > > > > > > >> designated
> > > router. A
> > > > > > designated router
> > > > > > > > >>transitioning to Down will be noted by
> > > > > > > > >>ospfIfStateChange." I think here the intention is to
> > > > > > > > >>reduce the number of TRAPs
> as
> > > much as
> > > > > > possible by making
> > > > > > > > >>only DR sending out this TRAP for a subnet.
> But there is
> > > > > > > > >>a
> > > possibility
> > > > > > that osfpNbrStateChange
> > > > > > > > >>notification is disabled on DR and enabled on
> DR other
> > > > > > > > >>or
> BDR.
> > > NMS
> > > > > > won't receive TRAPs when
> > > > > > > > >>NbrState becomes FULL in that case. There is
> a problem
> > > > > > > > >>with
> the
> > > second
> > > > > > part of above statments
> > > > > > > > >>as well. Suppose ospfIfStateChange is disabled on the
> router,
> > > then
> > > > > > again NMS won't know when
> > > > > > > > >>neighbor goes down. Probably its better to
> remove these
> > > > > > > > >>two
> > > clauses.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>Support for sham links:
> > > > > > > > >>-----------------------
> > > > > > > > >>Are you going to provide support for sham
> links? We may
> > > > > > > > >>need
> > > these
> > > > > > tables and notifications,
> > > > > > > > >>ShamLinkTable
> > > > > > > > >>ShamLinkNbrTable
> > > > > > > > >>ShamLinkStateChange notification
> ShamLinkNbrStateChange
> > > > > > > > >>notification
> > > > > >
> >
>

------_=_NextPart_001_01C2EE6A.E9410CF6-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 19 18:36:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16033 for ; Wed, 19 Mar 2003 18:36:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0093A00B@cherry.ease.lsoft.com>; Wed, 19 Mar 2003 18:38:56 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667041 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 19 Mar 2003 18:38:56 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Mar 2003 18:38:56 -0500 Received: from smirtoraw2k02 (ams-clip-vpn-dhcp24.cisco.com [10.61.64.24]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h2JNcnr15973 for ; Wed, 19 Mar 2003 15:38:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <00dc01c2ee70$b20cb400$f2ce7243@amer.cisco.com> Date: Wed, 19 Mar 2003 15:38:46 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: draft-mirtorabi-ospfv3-af-00.txt and MOSPF To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030319131956.22756.qmail@web20507.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Smith, > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM] On > Behalf Of John Smith > Sent: Wednesday, March 19, 2003 5:20 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: draft-mirtorabi-ospfv3-af-00.txt and MOSPF > > > How different is the draft-mirtorabi-ospfv3-af-00.txt from > the existing MOSPF specifications given that i can advertise > MULTICAST routes using the former. I can always use this new > draft to advertise the different multicast routes and inject > the best ones into the LSDB dedicated to the multicast RPF > topology, run the SPF and use these best routes thus derived > for RPF checks by other multicasting protocols. > > I am getting a little confused and would appreciate if > somebody could help me out. The difference is the choice of your multicast routing protocol, which is a comparison between MOSPF and other multicast protocols such as PIM. MOSPF builds a distribution tree for each source/group pair and computes a tree for active sources sending to the group therefore there is a scaling issue but let's not enter a multicast discussion With this new draft you can have a incongruent topology for your unicast and multicast IPv6 to do the RPF check and use other multicast protocols (e.g PIM) to create your tree (source based, shared distribution etc ) for forwarding multicast packets Sina > > TIA, > Smith > > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts http://uk.my.yahoo.com > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 19 18:53:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16503 for ; Wed, 19 Mar 2003 18:53:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0093A367@cherry.ease.lsoft.com>; Wed, 19 Mar 2003 18:55:19 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667097 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 19 Mar 2003 18:55:19 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 19 Mar 2003 18:55:19 -0500 Received: from smirtoraw2k02 (ams-clip-vpn-dhcp24.cisco.com [10.61.64.24]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h2JNtGr17524 for ; Wed, 19 Mar 2003 15:55:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <00e201c2ee72$fe606d90$f2ce7243@amer.cisco.com> Date: Wed, 19 Mar 2003 15:55:14 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: draft-mirtorabi-ospfv3-af-00.txt and MOSPF To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <00dc01c2ee70$b20cb400$f2ce7243@amer.cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Smith > With this new draft you can have a incongruent topology for > your unicast and multicast IPv6 to do the RPF check and use > other multicast protocols (e.g PIM) to create your tree > (source based, shared distribution etc ) for forwarding > multicast packets > > Sina Not sure if I mentioned clearly in my last e-mail, but let me emphasis that this new draft allow you to have an incongruent topology by having distinct unicast routing table for multicasts RPF check, so your multicst routing protocol can be what ever you want _including_ MOSPF Sina > > > > > > TIA, > > Smith > > > > __________________________________________________ > > Do You Yahoo!? > > Everything you'll ever need on one web page > > from News and Sport to Email and Music Charts http://uk.my.yahoo.com > > > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 20 03:50:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12025 for ; Thu, 20 Mar 2003 03:50:20 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0093B82E@cherry.ease.lsoft.com>; Thu, 20 Mar 2003 3:52:18 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668247 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 20 Mar 2003 03:52:17 -0500 Received: from 171.71.177.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Mar 2003 03:52:17 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2K8qDHp021492 for ; Thu, 20 Mar 2003 00:52:14 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id OAA23962 for ; Thu, 20 Mar 2003 14:20:48 +0530 (IST) References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <0f4101c2eebd$ff078df0$9c8b4d0a@apac.cisco.com> Date: Thu, 20 Mar 2003 14:22:10 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Manral, Thanks. > Hi Roy, > > I reread the OSPF-MIB and the issues you have. Though I do not know SNMP > well, I will try to let you know my view of things. > > 1. I think the issue of multiple instance support can be clarified in the > MIB. > > 2. Though I did observe that even in the ISIS-MIB, the MAX-ACCESS for > indicies is set to not-accesible, I am not sure we would want to deprecate > all the tables to get the slight benefit of saving SNMP messages. I believe it can be a considerable benefit. Lets consider LsdbEntry where we have four indices, ospfLsdbAreaId, ospfLsdbType, ospfLsdbLsid and ospfLsdbRouterId . When we try to access entire Lsdb details on your router, you use a 'getmany' utility which issues GETNEXT internally. This is what happens, GETNEXT ospfLsdbTable : Response -> ospfLsdbAreaId.a1.t1.lsdbid1.rtrid1 = X. GETNEXT ospfLsdbAreaId.a1.t1.lsdbid1.rtrid1 = X : Response -> ospfLsdbType.a1.t1.lsdbid1.rtrid1 = Y GETNEXT ospfLsdbType.a1.t1.lsdbid1.rtrid1 : : Response -> ospfLsdbLsid.a1.t1.lsdbid1.rtrid1 = Z GETNEXT ospfLsdbLsid.a1.t1.lsdbid1.rtrid1 : : Response -> ospfLsdbRouterId.a1.t1.lsdbid1.rtrid1 = A GETNEXT ospfLsdbRouterId.a1.t1.lsdbid1.rtrid1 : : Response -> ospfLsdbSequence.a1.t1.lsdbid1.rtrid1 = B . . If we can make the INDICES not-accessible, the first four messages need not be sent. Suppose you have 100 entries, you save 400 messages. Probably we can use GETBULK where you get N number of objects together. But its not supported with SNMP v1. > > 3. I am not sure waiting for the neighbor to get to FULL state would be an > appropriate solution either. There are cases where neighbor gets stuck in > Exchange/Exstart state, we wouldn't be sending traps in that case either. Good point. Thats why I am suggesting three different traps. Please see my next mail to Dan for more details. NbrStateChange -> For all state changes NbrStateTerminal NbrStateBackwardTransition. People, who are ready go with the risks as you are pointing out, can use the last two notifications instead of the first. > > 4. It can be done the way you say regarding the "throttling of traps", but I > do not see such a major issue with this. > > 5. I think we can know of duplicate router ID, as the adjacency would not > progress ahead of Exstart. But isn't it better to inform the NMS about the error? It will be great if someone can point out any other errors which we are missing. Thanks, Roy > > 6. I think ok with any clarification. > > Thanks, > Vishwas > > -----Original Message----- > From: Roy Jose [mailto:rojose@CISCO.COM] > Sent: Wednesday, March 19, 2003 6:05 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPFv2 MIB draft > > > Thanks Manral, Acee. > > Let me point out the open issues here from the original document I sent. > Joyal, please let me know if you need any clarifications. > > Support for multiple OSPF processes: > ----------------------------------- > > We raised this issue some time back in WG. Currently MIB supports only one > Router ID. > Multiple processes can have separate router IDs. It is also true with other > MIB objects > like ospfExternLsaCount, ospfExternLsaCksumSum etc. The solution we got was > to use a > separate MIB view for each process. But I don't think it can be easily > implemented. > We suggest to form a new table to group scalar objects related to an OSPF > process and have > Process Id as its INDEX. We also suggest to add Process Id as one of the > INDICES of all > tables. > [WG - John Flick] > As far as finding a generic solution for multiple instances of a MIB module, > the standard solution is to use contexts (note: this is not the same as a > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was done in a > somewhat ad-hoc way by using different community names for each instance > of the OSPF MIB. In SNMPv3, it is more formally defined using the > contextName. The Entity MIB entLogicalTable (RFC 2737) provides information > about what contexts exist in an agent, and how to get to them. > [OPEN issue] > I think we need to investigate on this and add a section to the draft how it > can be applied to OSPF MIB . > > > MAX-ACCESS value for INDICES of TABLES: > -------------------------------------- > I see MAX-ACCESS value of all TABLEs are read-only. Normally INDICES of a > table are > put as not-accesssible to reduce the number of SNMP messages. When an SNMP > GET or > GETNEXT is issued on a non-INDEX object, we can extract the values of > INDICES from > the object ID returned. For example, let us consider ospfAreaLsaCount. When > we query > the value for this, we get something like ospfAreaLsaCount.0.0.0.1, where > 0.0.0.1 is > the AreaId, which is the INDEX of the ospfAreaTable. We can extract the > INDICES of > table like this even if they are not-accessible. The tables like LsdbTable > has many > number of INDICES and we can reduce the number of SNMP messages considerably > by changing > them to not-accessible. > > [WG - John Flick] > You would have the same problem if you tried changing MAX-ACCESS on the > table indices (as was also suggested below). Since a change to MAX-ACCESS > of an existing object is not allowed, you would need to deprecated the index > objects, which would require deprecating the tables that they index. > Changing > to not-accessible is not required, since SMIv2 allows read-only indices for > MIB modules that were translated from SMIv1 and therefore already had > read-only indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 MIB > module, so this exception applies. > > [OPEN issue] > As I have pointed out earlier, by changing the INDICES we can reduce the > number of SNMP GETNEXT reponses sent by the router considerably. The draft > standard MIB > is already widely deployed. But we need to deprecate an existing MIB and add > a new version, when it is required. I feel if everyone thinks what I pointed > out is a big advantange, still we can go ahead with this change. > > If the MAX-ACCESS of INDICES are put as read-only to include them in the > TRAP > notification messages, they can be changed as accessible-for-notify. Other > approach to > this is remove the INDICES from TRAP notification messages. For example if > you take the > case of IfStateChange TRAP, > > ospfIfStateChange NOTIFICATION-TYPE^M > OBJECTS { ospfRouterId, -- The originator of the trap^M > ospfIfIpAddress,^M > ospfAddressLessIf,^M > ospfIfState -- The new state^M > }^M > Here we don't actually need ospfIfIpAddress and ospfAddressLessIf. When we > send TRAP > notification, we can just send ospfIfState. value>. . > Also I am not sure why ospfRouterId is included here. An NMS station can > always query ospfRouterId > separately. By removing these MIB objects, we can reduce the size and > processing time of TRAP > messages considerably. > > [OPEN issue] The above point is not addressed yet. > > Section : 4.3 Ignoring Initial Activity > --------------------------------------- > > [OPEN issue] This is not addressed yet. > > The section states "The majority of critical events occur when OSPF is > enabled on a > router, at which time the designated router is elected and neighbor > adjacencies are formed" . > I am not sure if enabling OSPF on a router means enabling it on an > interface. I think it will > be better to make the text clearer. > > Other statement is "To avoid unnecessary traps, a router should not > originate expected OSPF > interface related traps until two of that interface's dead timer intervals > have elapsed." > I think there will be some problems if the dead interval value is too long. > We may end up > not sending any of the expected TRAPS for a long time. Btw, could I please > know the reason > for selecting 2 * dead interval value for this purpose?. There might be some > case where an > interface is up and it goes down before (2 * dead interval). We can't take > it as an 'expected > event'. Probably we can ignore the expected events till the interface > reaches terminal state > (FULL or 2WAY) for the first time after enabling OSPF. > > > One more point is we are already limiting ospfIfStateChange, > ospfVirtIfStateChange, > ospfNbrStateChange and ospfVirtNbrStateChange notifications by generating > them only for terminal > state changes and backward tansition. Do we really need to ignore them > during the initial activity?. > > Other statement is "Additionally, ospfMaxAgeLsa and ospfOriginateLsa traps > should not be originated > until two dead timer intervals have elapsed where the deadtimer interval > used should be the dead > timer with the smallest value." Here whats the meaning of "dead timer with > smallest value"? Is it > the smallest interval value among all the interfaces? > > > Section 4.4 Throttling Traps > ---------------------------- > > [OPEN issue] This is not addressed yet. > > Do we need to provide MIB objects corresponding to window size and the > number of TRAPs sent during > the window time? Will the TRAPs other than ospfTxRetransmit, OrginateLsa and > MaxAgeLsa really cause > a TRAP flood? Probably we need to throttle only the above three TRAPS? > > I think the normal practice is to inform the NMS using some other > notification at the end of a > particular interval when the TRAPs are dropped like this, "Trap N dropped n > times in an interval > t". We can add some common extra paratmeters to these notifications to > facilitate the NMS to query > the router to retrieve some values and find out whats happening. > > ospfConfigErrorType > ------------------- > > [OPEN issue] This is not addressed yet. > > Do we need an error type for duplicate router id in the received messages? > Some times loop back > address can be misconfigured. > > ospfSetTrap > ----------- > > [OPEN issue] This is not addressed yet. > > The definition of this is little complicated. Any reasons for going for last > bit to first. We think > its better to redefine this MIB object like this to make if more clear. > > cospfSetTrap OBJECT-TYPE > SYNTAX BITS { > ifConfigError (0), > virtIfConfigError (1), > ospfNbrStateChange (2), > . > . > . > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A One-octet string serving as a bit map for > the trap events defined by the OSPF traps in > this MIB. This object is used to enable and > disable specific OSPF traps where a 1 > in the corresponding bit field represents > enabled." > ::= { cospfTrapControl 1 } > > This definition enables the NMS to interpret the bit map easily. > > > ospfIfStateChange > ----------------- > [OPEN issue] This is not addressed yet. > > From the definition it looks like this TRAP should be generated only for > terminal states(when state > progresses) and for backward transition. Infact the name ospfIfStateChange > simply suggests to > generate TRAPs for all state transitions. The general tendency is to ignore > the DESCRIPTION when > "StateChange" is read and assume its for all the state changes. It might > lead to wrong > implementations. I think we can also follow the approach taken in BGP > MIB(rfc1657). > There they have notifications like this, > bgpEstablished NOTIFICATION-TYPE > OBJECTS { bgpPeerLastError, > bgpPeerState } > STATUS current > DESCRIPTION > "The BGP Established event is generated when > the BGP FSM enters the ESTABLISHED state." > ::= { bgpTraps 1 } > > bgpBackwardTransition NOTIFICATION-TYPE > OBJECTS { bgpPeerLastError, > bgpPeerState } > STATUS current > DESCRIPTION > "The BGPBackwardTransition Event is generated > when the BGP FSM moves from a higher numbered > state to a lower numbered state." > ::= { bgpTraps 2 } > > Our suggestion is to maintain ospfIfStateChange and use that for monitoring > all the states > (some people may want that) and additionally have notifications similar to > the BGP notifications. > Its also true with VirtIfStateChange, NbrStateChange and VirtNbrStateChange. > If somebody doesn't > want to see ALL state TRAPS, they can suppress them by turning off the > corresponding bit in > ospfSetTrap. > > > ospfNbrStateChange > ------------------ > > [OPEN issue] This is not addressed yet. > > The DECRIPTION clause states > "When an neighbor transitions from or to Full on non-broadcast multi-access > and broadcast > networks, the trap should be generated by the designated router. A > designated router > transitioning to Down will be noted by ospfIfStateChange." > I think here the intention is to reduce the number of TRAPs as much as > possible by making > only DR sending out this TRAP for a subnet. But there is a possibility that > osfpNbrStateChange > notification is disabled on DR and enabled on DR other or BDR. NMS won't > receive TRAPs when > NbrState becomes FULL in that case. There is a problem with the second part > of above statments > as well. Suppose ospfIfStateChange is disabled on the router, then again NMS > won't know when > neighbor goes down. Probably its better to remove these two clauses. > > Thanks, > Roy > > > > "Manral, Vishwas" wrote: > > > > > > Dan Joyal is at present working on the OSPFv2 MIB. > > > > And the OSPFv3 MIB as well. > > > > > > Thanks, > > Acee > > > > > > Thanks, > > > Vishwas > > > > > > -----Original Message----- > > > From: Roy Jose [mailto:rojose@CISCO.COM] > > > Sent: Tuesday, March 18, 2003 12:03 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: OSPFv2 MIB draft > > > > > > Hi Acee, > > > > > > I agree with you. Till it becomes a standard draft, vendors have to go > with > > > some proprietory MIB I guess. Btw, who is working on the MIB update > > > currently? > > > > > > Thanks, > > > Roy > > > > > > > One small correction. > > > > > > > > Acee Lindem wrote: > > > > > > > > > > Roy, > > > > > > > > > > There are 3 reasons why I don't think Sham Links should > > > > > be included in this MIB udpate: > > > > > > > > > > 1. I don't think they are sufficiently specified in the > > > > > Internet Draft describing them. My experience implementing > > > > > the Sham Link feature required some reverse > > > > > engineering (Consult RFC 1264 for specification > > > > > requirements). > > > > > 2. The document describing them is not an OSPF WG > > > > > document. In fact, it is not even an PPVPN > > > > > document (although it could become one). > > > > > 3. At some point, we have to close the door on adding > > > > > MIB variables that are in all the drafts that may or > > > > > may not ever reach draft standard status. If we don't > > > > ~~~~~~~~~~~~~~ > > > > Meant to say "proposed standard" here. > > > > > > > > > do this, we'll never finish the MIB update. > > > > > > > > > > Thanks, > > > > > Acee > > > > > > > > > > Roy Jose wrote: > > > > > > > > > > > > Thanks Jeff, Acee, Mani and John for your responses. How about > other > > > > > > points?:) > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "John Flick" > > > > > > To: > > > > > > Sent: Saturday, March 15, 2003 6:19 AM > > > > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > > > > > Yep, adding an index would require deprecating everything and > > > starting > > > > > > over. > > > > > > > Since this is an existing, widely deployed, Draft Standard MIB, > this > > > > > > should > > > > > > > not be done lightly. > > > > > > > > > > > > > > You would have the same problem if you tried changing MAX-ACCESS > on > > > the > > > > > > > table indices (as was also suggested below). Since a change to > > > MAX-ACCESS > > > > > > > of an existing object is not allowed, you would need to > deprecated > > > the > > > > > > index > > > > > > > objects, which would require deprecating the tables that they > index. > > > > > > Changing > > > > > > > to not-accessible is not required, since SMIv2 allows read-only > > > indices > > > > > > for > > > > > > > MIB modules that were translated from SMIv1 and therefore > already > > > had > > > > > > > read-only indices. The OSPFv2 MIB started life in RFC 1248 as > an > > > SMIv1 > > > > > > MIB > > > > > > > module, so this exception applies. > > > > > > > > > > > > How about tables which were added later?: ospfAreaAggregateTable, > > > > > > ExtLsdbTable, etc. > > > > > > My worry is not if its allowed or not. I am trying to point out > the > > > extra > > > > > > processing routers and > > > > > > NMS have to do with the increased number of messages. > > > > > > > > > > > > > As far as finding a generic solution for multiple instances of a > MIB > > > > > > module, > > > > > > > the standard solution is to use contexts (note: this is not the > same > > > as a > > > > > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was > done > > > in a > > > > > > > somewhat ad-hoc way by using different community names for each > > > instance > > > > > > > of the OSPF MIB. In SNMPv3, it is more formally defined using > the > > > > > > > contextName. The Entity MIB entLogicalTable (RFC 2737) provides > > > > > > information > > > > > > > about what contexts exist in an agent, and how to get to them. > > > > > > > > > > > > After having a glance at rfc2737, I also think this is the way. I > > > think we > > > > > > need to specify it clearly how it can be achieved using > > > entLogicalTable. For > > > > > > example, how we need to represent the SNMP community string to > > > retrieve info > > > > > > from a particular routing instance. > > > > > > > > > > > > Thanks, > > > > > > Roy > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > Acee Lindem wrote: > > > > > > > > > > > > > > > > Roy, > > > > > > > > > > > > > > > > I can appreciate your points since our product supports both > > > multiple > > > > > > > > virtual router instances and multiple routing protocol > instances > > > > > > > > within a particular virtual router. However, I think we'd > > > > > > > > essentially have to deprecate everything in the current MIB > and > > > define > > > > > > > > new tables in order to add OSPF instance ID as an index. Can > > > someone > > > > > > > > who has more MIB definition experience comment? > > > > > > > > > > > > > > > > Additionally, the multiple instance problem is not unique to > the > > > > > > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > > > > > > > > > > > Roy Jose wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I have some comments on draft-ietf-ospf-mib-update-05.txt. I > > > would > > > > > > also like > > > > > > > > > to have some clarifications. Please see the attached > document. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Roy > > > > > > > > > > > > > > > > > > > > > > > > > > >>Yes. An update is in the works. > > > > > > > > >> > > > > > > > > >>-Dan > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>>-----Original Message----- > > > > > > > > >>>From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > > > > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > > > > > > >>>Subject: OSPFv2 MIB draft > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>>Hi all: > > > > > > > > >>>I would like to know the status of the working group > > > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft shows > an > > > > > > > > >>>expiry date of > > > > > > > > >>>May 2001. > > > > > > > > >>>Is there any plan to update the draft ? > > > > > > > > >>> > > > > > > > > >>>Thanks > > > > > > > > >>>Gargi > > > > > > > > >>> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > >>------------------------------------------------------------------------ > > > > > > > > >> > > > > > > > > >>Support for multiple OSPF processes: > > > > > > > > >>----------------------------------- > > > > > > > > >> > > > > > > > > >>We raised this issue some time back in WG. Currently MIB > > > supports only > > > > > > one Router ID. > > > > > > > > >>Multiple processes can have separate router IDs. It is also > true > > > with > > > > > > other MIB objects > > > > > > > > >>like ospfExternLsaCount, ospfExternLsaCksumSum etc. The > solution > > > we > > > > > > got was to use a > > > > > > > > >>separate MIB view for each process. But I don't think it can > be > > > easily > > > > > > implemented. > > > > > > > > >>We suggest to form a new table to group scalar objects > related > > > to an > > > > > > OSPF process and have > > > > > > > > >>Process Id as its INDEX. We also suggest to add Process Id > as > > > one of > > > > > > the INDICES of all > > > > > > > > >>tables. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>MAX-ACCESS value for INDICES of TABLES: > > > > > > > > >>-------------------------------------- > > > > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. Normally > > > INDICES > > > > > > of a table are > > > > > > > > >>put as not-accesssible to reduce the number of SNMP > messages. > > > When an > > > > > > SNMP GET or > > > > > > > > >>GETNEXT is issued on a non-INDEX object, we can extract the > > > values of > > > > > > INDICES from > > > > > > > > >>the object ID returned. For example, let us consider > > > ospfAreaLsaCount. > > > > > > When we query > > > > > > > > >>the value for this, we get something like > > > ospfAreaLsaCount.0.0.0.1, > > > > > > where 0.0.0.1 is > > > > > > > > >>the AreaId, which is the INDEX of the ospfAreaTable. We can > > > extract > > > > > > the INDICES of > > > > > > > > >>table like this even if they are not-accessible. The tables > like > > > > > > LsdbTable has many > > > > > > > > >>number of INDICES and we can reduce the number of SNMP > messages > > > > > > considerably by changing > > > > > > > > >>them to not-accessible. > > > > > > > > >> > > > > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to include > > > them in > > > > > > the TRAP > > > > > > > > >>notification messages, they can be changed as > > > accessible-for-notify. > > > > > > Other approach to > > > > > > > > >>this is remove the INDICES from TRAP notification messages. > For > > > > > > example if you take the > > > > > > > > >>case of IfStateChange TRAP, > > > > > > > > >> > > > > > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > > > > > > >> OBJECTS { ospfRouterId, -- The originator of the > trap^M > > > > > > > > >> ospfIfIpAddress,^M > > > > > > > > >> ospfAddressLessIf,^M > > > > > > > > >> ospfIfState -- The new state^M > > > > > > > > >> }^M > > > > > > > > >>Here we don't actually need ospfIfIpAddress and > > > ospfAddressLessIf. > > > > > > When we send TRAP > > > > > > > > >>notification, we can just send ospfIfState. > > > > > value>. . > > > > > > > > >>Also I am not sure why ospfRouterId is included here. An NMS > > > station > > > > > > can always query ospfRouterId > > > > > > > > >>separately. By removing these MIB objects, we can reduce the > > > size and > > > > > > processing time of TRAP > > > > > > > > >>messages considerably. > > > > > > > > >> > > > > > > > > >>Section : 4.3 Ignoring Initial Activity > > > > > > > > >>--------------------------------------- > > > > > > > > >>The section states "The majority of critical events occur > when > > > OSPF is > > > > > > enabled on a > > > > > > > > >>router, at which time the designated router is elected and > > > neighbor > > > > > > adjacencies are formed" . > > > > > > > > >>I am not sure if enabling OSPF on a router means enabling it > on > > > an > > > > > > interface. I think it will > > > > > > > > >>be better to make the text clearer. > > > > > > > > >> > > > > > > > > >>Other statement is "To avoid unnecessary traps, a router > should > > > not > > > > > > originate expected OSPF > > > > > > > > >>interface related traps until two of that interface's dead > timer > > > > > > intervals have elapsed." > > > > > > > > >>I think there will be some problems if the dead interval > value > > > is too > > > > > > long. We may end up > > > > > > > > >>not sending any of the expected TRAPS for a long time. Btw, > > > could I > > > > > > please know the reason > > > > > > > > >>for selecting 2 * dead interval value for this purpose?. > There > > > might > > > > > > be some case where an > > > > > > > > >>interface is up and it goes down before (2 * dead interval). > We > > > can't > > > > > > take it as an 'expected > > > > > > > > >>event'. Probably we can ignore the expected events till the > > > interface > > > > > > reaches terminal state > > > > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>One more point is we are already limiting ospfIfStateChange, > > > > > > ospfVirtIfStateChange, > > > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange notifications > by > > > > > > generating them only for terminal > > > > > > > > >>state changes and backward tansition. Do we really need to > > > ignore them > > > > > > during the initial activity?. > > > > > > > > >> > > > > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and > > > ospfOriginateLsa > > > > > > traps should not be originated > > > > > > > > >>until two dead timer intervals have elapsed where the > deadtimer > > > > > > interval used should be the dead > > > > > > > > >>timer with the smallest value." Here whats the meaning of > "dead > > > timer > > > > > > with smallest value"? Is it > > > > > > > > >>the smallest interval value among all the interfaces? > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>Section 4.4 Throttling Traps > > > > > > > > >>---------------------------- > > > > > > > > >>Do we need to provide MIB objects corresponding to window > size > > > and the > > > > > > number of TRAPs sent during > > > > > > > > >>the window time? Will the TRAPs other than ospfTxRetransmit, > > > > > > OrginateLsa and MaxAgeLsa really cause > > > > > > > > >>a TRAP flood? Probably we need to throttle only the above > three > > > TRAPS? > > > > > > > > >> > > > > > > > > >>I think the normal practice is to inform the NMS using some > > > other > > > > > > notification at the end of a > > > > > > > > >>particular interval when the TRAPs are dropped like this, > "Trap > > > N > > > > > > dropped n times in an interval > > > > > > > > >>t". We can add some common extra paratmeters to these > > > notifications to > > > > > > facilitate the NMS to query > > > > > > > > >>the router to retrieve some values and find out whats > happening. > > > > > > > > >> > > > > > > > > >>ospfConfigErrorType > > > > > > > > >>------------------- > > > > > > > > >>Do we need an error type for duplicate router id in the > received > > > > > > messages? Some times loop back > > > > > > > > >>address can be misconfigured. > > > > > > > > >> > > > > > > > > >>ospfSetTrap > > > > > > > > >>----------- > > > > > > > > >>The definition of this is little complicated. Any reasons > for > > > going > > > > > > for last bit to first. We think > > > > > > > > >>its better to redefine this MIB object like this to make if > more > > > > > > clear. > > > > > > > > >> > > > > > > > > >> cospfSetTrap OBJECT-TYPE > > > > > > > > >> SYNTAX BITS { > > > > > > > > >> ifConfigError (0), > > > > > > > > >> virtIfConfigError (1), > > > > > > > > >> ospfNbrStateChange (2), > > > > > > > > >> . > > > > > > > > >> . > > > > > > > > >> . > > > > > > > > >> } > > > > > > > > >> MAX-ACCESS read-write > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "A One-octet string serving as a bit map for > > > > > > > > >> the trap events defined by the OSPF traps in > > > > > > > > >> this MIB. This object is used to enable and > > > > > > > > >> disable specific OSPF traps where a 1 > > > > > > > > >> in the corresponding bit field represents > > > > > > > > >> enabled." > > > > > > > > >> ::= { cospfTrapControl 1 } > > > > > > > > >> > > > > > > > > >>This definition enables the NMS to interpret the bit map > easily. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>ospfIfStateChange > > > > > > > > >>----------------- > > > > > > > > >> > > > > > > > > >>>From the definition it looks like this TRAP should be > generated > > > only > > > > > > for terminal states(when state > > > > > > > > >>progresses) and for backward transition. Infact the name > > > > > > ospfIfStateChange simply suggests to > > > > > > > > >>generate TRAPs for all state transitions. The general > tendency > > > is to > > > > > > ignore the DESCRIPTION when > > > > > > > > >>"StateChange" is read and assume its for all the state > changes. > > > It > > > > > > might lead to wrong > > > > > > > > >>implementations. I think we can also follow the approach > taken > > > in BGP > > > > > > MIB(rfc1657). > > > > > > > > >>There they have notifications like this, > > > > > > > > >> bgpEstablished NOTIFICATION-TYPE > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > >> bgpPeerState } > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "The BGP Established event is > > > generated > > > > > > when > > > > > > > > >> the BGP FSM enters the > ESTABLISHED > > > state." > > > > > > > > >> ::= { bgpTraps 1 } > > > > > > > > >> > > > > > > > > >> bgpBackwardTransition NOTIFICATION-TYPE > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > >> bgpPeerState } > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "The BGPBackwardTransition Event > is > > > > > > generated > > > > > > > > >> when the BGP FSM moves from a > higher > > > > > > numbered > > > > > > > > >> state to a lower numbered > state." > > > > > > > > >> ::= { bgpTraps 2 } > > > > > > > > >> > > > > > > > > >>Our suggestion is to maintain ospfIfStateChange and use that > for > > > > > > monitoring all the states > > > > > > > > >>(some people may want that) and additionally have > notifications > > > > > > similar to the BGP notifications. > > > > > > > > >>Its also true with VirtIfStateChange, NbrStateChange and > > > > > > VirtNbrStateChange. If somebody doesn't > > > > > > > > >>want to see ALL state TRAPS, they can suppress them by > turning > > > off the > > > > > > corresponding bit in > > > > > > > > >>ospfSetTrap. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>ospfNbrStateChange > > > > > > > > >>------------------ > > > > > > > > >>The DECRIPTION clause states > > > > > > > > >>"When an neighbor transitions from or to Full on > non-broadcast > > > > > > multi-access and broadcast > > > > > > > > >> networks, the trap should be generated by the designated > > > router. A > > > > > > designated router > > > > > > > > >>transitioning to Down will be noted by ospfIfStateChange." > > > > > > > > >>I think here the intention is to reduce the number of TRAPs > as > > > much as > > > > > > possible by making > > > > > > > > >>only DR sending out this TRAP for a subnet. But there is a > > > possibility > > > > > > that osfpNbrStateChange > > > > > > > > >>notification is disabled on DR and enabled on DR other or > BDR. > > > NMS > > > > > > won't receive TRAPs when > > > > > > > > >>NbrState becomes FULL in that case. There is a problem with > the > > > second > > > > > > part of above statments > > > > > > > > >>as well. Suppose ospfIfStateChange is disabled on the > router, > > > then > > > > > > again NMS won't know when > > > > > > > > >>neighbor goes down. Probably its better to remove these two > > > clauses. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>Support for sham links: > > > > > > > > >>----------------------- > > > > > > > > >>Are you going to provide support for sham links? We may need > > > these > > > > > > tables and notifications, > > > > > > > > >>ShamLinkTable > > > > > > > > >>ShamLinkNbrTable > > > > > > > > >>ShamLinkStateChange notification > > > > > > > > >>ShamLinkNbrStateChange notification > > > > > > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 20 04:57:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13325 for ; Thu, 20 Mar 2003 04:57:50 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0093B70F@cherry.ease.lsoft.com>; Thu, 20 Mar 2003 4:59:44 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668376 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 20 Mar 2003 04:59:44 -0500 Received: from 171.71.177.254 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Mar 2003 04:59:44 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2K9xdmU013477 for ; Thu, 20 Mar 2003 01:59:40 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id PAA02926 for ; Thu, 20 Mar 2003 15:28:16 +0530 (IST) References: <6204FDDE129D364D8040A98BCCB290EF0440AB3D@zbl6c004.corpeast.baynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <0f6201c2eec7$6b0d46d0$9c8b4d0a@apac.cisco.com> Date: Thu, 20 Mar 2003 15:29:37 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Dan, Thanks. Please see inline. > Comments in-line below. > > -Dan > > > -----Original Message----- > > From: Roy Jose [mailto:rojose@CISCO.COM] > > Sent: Wednesday, March 19, 2003 6:05 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: OSPFv2 MIB draft > > > > > > Thanks Manral, Acee. > > > > Let me point out the open issues here from the original > > document I sent. Joyal, please let me know if you need any > > clarifications. > > > > Support for multiple OSPF processes: > > ----------------------------------- > > > > We raised this issue some time back in WG. Currently MIB > > supports only one Router ID. Multiple processes can have > > separate router IDs. It is also true with other MIB objects > > like ospfExternLsaCount, ospfExternLsaCksumSum etc. The > > solution we got was to use a separate MIB view for each > > process. But I don't think it can be easily implemented. We > > suggest to form a new table to group scalar objects related > > to an OSPF process and have Process Id as its INDEX. We also > > suggest to add Process Id as one of the INDICES of all > > tables. [WG - John Flick] As far as finding a generic > > solution for multiple instances of a MIB module, the standard > > solution is to use contexts (note: this is not the same as a > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was > > done in a somewhat ad-hoc way by using different community > > names for each instance of the OSPF MIB. In SNMPv3, it is > > more formally defined using the contextName. The Entity MIB > > entLogicalTable (RFC 2737) provides information about what > > contexts exist in an agent, and how to get to them. [OPEN > > issue] I think we need to investigate on this and add a > > section to the draft how it can be applied to OSPF MIB . > > > > This issue is not unique to the OSPF MIBs. I would prefer > to just reference the RFCs that deal with SNMP contexts that > John Flick mentioned. I would let John comment on this. Do we need to add any thing extra? My point is different implementations should have the same behavior to avoid interoperability issues. Also we need to think about modifying TRAP messages to facilitate the NMS interpret the routing instance. Probably we can add a new MIB object like OspfRoutingIstanceId to the notification messages. > > > > > MAX-ACCESS value for INDICES of TABLES: > > -------------------------------------- > > I see MAX-ACCESS value of all TABLEs are read-only. Normally > > INDICES of a table are put as not-accesssible to reduce the > > number of SNMP messages. When an SNMP GET or GETNEXT is > > issued on a non-INDEX object, we can extract the values of > > INDICES from the object ID returned. For example, let us > > consider ospfAreaLsaCount. When we query the value for this, > > we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1 > > is the AreaId, which is the INDEX of the ospfAreaTable. We > > can extract the INDICES of table like this even if they are > > not-accessible. The tables like LsdbTable has many number of > > INDICES and we can reduce the number of SNMP messages > > considerably by changing them to not-accessible. > > > > [WG - John Flick] > > You would have the same problem if you tried changing > > MAX-ACCESS on the table indices (as was also suggested > > below). Since a change to MAX-ACCESS of an existing object > > is not allowed, you would need to deprecated the index > > objects, which would require deprecating the tables that they > > index. Changing to not-accessible is not required, since > > SMIv2 allows read-only indices for MIB modules that were > > translated from SMIv1 and therefore already had read-only > > indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 > > MIB module, so this exception applies. > > > > [OPEN issue] > > As I have pointed out earlier, by changing the INDICES we can > > reduce the number of SNMP GETNEXT reponses sent by the > > router considerably. The draft standard MIB is already widely > > deployed. But we need to deprecate an existing MIB and add a > > new version, when it is required. I feel if everyone thinks > > what I pointed out is a big advantange, still we can go ahead > > with this change. > > > > If the MAX-ACCESS of INDICES are put as read-only to include > > them in the TRAP notification messages, they can be changed > > as accessible-for-notify. Other approach to this is remove > > the INDICES from TRAP notification messages. For example if > > you take the case of IfStateChange TRAP, > > > > ospfIfStateChange NOTIFICATION-TYPE^M > > OBJECTS { ospfRouterId, -- The originator of the trap^M > > ospfIfIpAddress,^M > > ospfAddressLessIf,^M > > ospfIfState -- The new state^M > > }^M > > Here we don't actually need ospfIfIpAddress and > > ospfAddressLessIf. When we send TRAP notification, we can > > just send ospfIfState. > value>. . > > Also I am not sure why ospfRouterId is included here. An NMS > > station can always query ospfRouterId separately. By removing > > these MIB objects, we can reduce the size and processing time > > of TRAP messages considerably. > > > > [OPEN issue] The above point is not addressed yet. > > > > I think there would need to be a strong WG consensus that deprecating the > entire MIB for this is worth it. I agree. Please see my previous mail to Manral. > > > Section : 4.3 Ignoring Initial Activity > > --------------------------------------- > > > > [OPEN issue] This is not addressed yet. > > > > The section states "The majority of critical events occur > > when OSPF is enabled on a router, at which time the > > designated router is elected and neighbor adjacencies are > > formed" . I am not sure if enabling OSPF on a router means > > enabling it on an interface. I think it will be better to > > make the text clearer. > > > > Other statement is "To avoid unnecessary traps, a router > > should not originate expected OSPF interface related traps > > until two of that interface's dead timer intervals have > > elapsed." I think there will be some problems if the dead > > interval value is too long. We may end up not sending any of > > the expected TRAPS for a long time. Btw, could I please know > > the reason for selecting 2 * dead interval value for this > > purpose?. There might be some case where an interface is up > > and it goes down before (2 * dead interval). We can't take it > > as an 'expected event'. Probably we can ignore the expected > > events till the interface reaches terminal state (FULL or > > 2WAY) for the first time after enabling OSPF. > > > > > > One more point is we are already limiting ospfIfStateChange, > > ospfVirtIfStateChange, ospfNbrStateChange and > > ospfVirtNbrStateChange notifications by generating them only > > for terminal state changes and backward tansition. Do we > > really need to ignore them during the initial activity?. > > > > Other statement is "Additionally, ospfMaxAgeLsa and > > ospfOriginateLsa traps should not be originated until two > > dead timer intervals have elapsed where the deadtimer > > interval used should be the dead timer with the smallest > > value." Here whats the meaning of "dead timer with smallest > > value"? Is it the smallest interval value among all the interfaces? > > > > I think the intent of the original authors of the MIB was > to give some guidelines (hence the wording "should not" rather > than "must not") for when or when not to generate traps. I don't > know how closely real world implementations follow these guidelines. I am sure many people would like to reduce the number of TRAPs during the initial activity. Imagine a case where OrinateLsaTrap TRAPs are flooded like anything during initial activity. In our implementation we are suppressing traps during initial activity, but not exactly in the same way taking advantage of "should not" :) I feel the guidelines here should be clear and worth to implement. > > > > > Section 4.4 Throttling Traps > > ---------------------------- > > > > [OPEN issue] This is not addressed yet. > > > > Do we need to provide MIB objects corresponding to window > > size and the number of TRAPs sent during the window time? > > Will the TRAPs other than ospfTxRetransmit, OrginateLsa and > > MaxAgeLsa really cause a TRAP flood? Probably we need to > > throttle only the above three TRAPS? > > > > I think the normal practice is to inform the NMS using some > > other notification at the end of a particular interval when > > the TRAPs are dropped like this, "Trap N dropped n times in > > an interval t". We can add some common extra paratmeters to > > these notifications to facilitate the NMS to query the router > > to retrieve some values and find out whats happening. > > > > ospfConfigErrorType > > ------------------- > > > > [OPEN issue] This is not addressed yet. > > > > Do we need an error type for duplicate router id in the > > received messages? Some times loop back address can be misconfigured. > > Easy to add if required. As I said in the earlier, we need to check if we are missing any other errors. > > > > > ospfSetTrap > > ----------- > > > > [OPEN issue] This is not addressed yet. > > > > The definition of this is little complicated. Any reasons for > > going for last bit to first. We think its better to redefine > > this MIB object like this to make if more clear. > > > > cospfSetTrap OBJECT-TYPE > > SYNTAX BITS { > > ifConfigError (0), > > virtIfConfigError (1), > > ospfNbrStateChange (2), > > . > > . > > . > > } > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "A One-octet string serving as a bit map for > > the trap events defined by the OSPF traps in > > this MIB. This object is used to enable and > > disable specific OSPF traps where a 1 > > in the corresponding bit field represents > > enabled." > > ::= { cospfTrapControl 1 } > > > > This definition enables the NMS to interpret the bit map easily. > > Changing to a non-equivalent syntax would require creation of a new object. This is a critical MIB object to control the TRAPs. I feel its important to make it easily interpreted. > > > > > > > ospfIfStateChange > > ----------------- > > [OPEN issue] This is not addressed yet. > > > > From the definition it looks like this TRAP should be > > generated only for terminal states(when state > > progresses) and for backward transition. Infact the name > > ospfIfStateChange simply suggests to generate TRAPs for all > > state transitions. The general tendency is to ignore the > > DESCRIPTION when "StateChange" is read and assume its for all > > the state changes. It might lead to wrong implementations. I > > think we can also follow the approach taken in BGP > > MIB(rfc1657). There they have notifications like this, > > bgpEstablished NOTIFICATION-TYPE > > OBJECTS { bgpPeerLastError, > > bgpPeerState } > > STATUS current > > DESCRIPTION > > "The BGP Established event is > > generated when > > the BGP FSM enters the ESTABLISHED state." > > ::= { bgpTraps 1 } > > > > bgpBackwardTransition NOTIFICATION-TYPE > > OBJECTS { bgpPeerLastError, > > bgpPeerState } > > STATUS current > > DESCRIPTION > > "The BGPBackwardTransition Event > > is generated > > when the BGP FSM moves from a > > higher numbered > > state to a lower numbered state." > > ::= { bgpTraps 2 } > > > > Our suggestion is to maintain ospfIfStateChange and use that > > for monitoring all the states (some people may want that) and > > additionally have notifications similar to the BGP > > notifications. Its also true with VirtIfStateChange, > > NbrStateChange and VirtNbrStateChange. If somebody doesn't > > want to see ALL state TRAPS, they can suppress them by > > turning off the corresponding bit in ospfSetTrap. > > > > OK. Could you list the new BGP-like notifications for OSPF? Sure. I have defined them in a rough way. Let me reiterate one point. Here the first TRAP in each step for people who are interested in knowing all state changes. The next two(Terminal and Backward transition are for those who want to limit the TRAP messages). Please note that I have added ospfConfigErrorType to make the NMS know the error which caused backward transition. ospfIfStateChange NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfIfState, -- The new state ospfConfigErrorType } STATUS current DESCRIPTION "An ospfIfStateChange trap signifies that there has been a change in the state of a non-virtual OSPF interface. The ospfIfIpAddress and ospfAddressLessIf values must be attached to ospfIfState object identifier. ospfConfigErrorType is set to a non-zero value when state change is due to some error. The notifications ospfIfStateTerminal and ospfIfStateBackwardTransition should be generated instead of ospfIfStateChange if the network manager is not interested in knowing the intermediate states." ::= { ospfTraps X } ospfIfStateTerminal NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfIfState -- The terminal state } STATUS current DESCRIPTION "An ospfIfStateTerminal notification signifies that a non-virtual OSPF interface reaches a terminal state (i.e., Point-to-Point, DR Other, Dr, or Backup). ospfIfIpAddress and ospfAddressLessIf values are attached to ospfIfState object identifier." ::= { ospfTraps X } ospfIfStateBackwardTransition NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfIfState, -- The new state ospfConfigErrorType } STATUS current DESCRIPTION "An ospfIfStateBackwardTransition notification signifies that a non-virtual OSPF interface state regresses (e.g., goes from Dr to Down). ospfIfIpAddress and ospfAddressLessIf values are attached to the ospfIfState object identifier. ospfConfigErrorType is set to a non-zero value when the state regresses due to an error." ::= { ospfTraps X } ospfVirtIfStateChange NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtIfState, -- The new state ospfConfigErrorType } STATUS current DESCRIPTION "An ospfVirtIfStateChange trap signifies that there has been a change in the state of a virtual OSPF interface. The ospfVirtIfAreaId and ospfVirtIfNeighbor values must be attached to the ospfVirtIfState object identifier. ospfConfigErrorType is set to a non-zero value when state change is due to some error. The notifications ospfIfStateTerminal and ospfIfStateBackwardTransition should be generated instead of ospfIfStateChange if the network manager is not interested in knowing the intermediate states." ::= { ospfTraps X } ospfVirtIfStateTerminal NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtIfState -- The terminal state } STATUS current DESCRIPTION "An ospfVirtIfStateTerminal notification signifies that a virtual OSPF interface reaches a terminal state (i.e., Point-to-Point). The ospfVirtIfAreaId and ospfVirtIfNeighbor values must be attached to the ospfVirtIfState object identifier.." ::= { ospfTraps X } ospfVirtIfStateBackwardTransition NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtIfState, -- The new state ospfConfigErrorType } STATUS current DESCRIPTION "An ospfVirtIfStateBackwardTransition notification signifies that a virtual OSPF interface state regresses (e.g., goes from Point-to-Point to Down). The ospfVirtIfAreaId and ospfVirtIfNeighbor values must be attached to the ospfVirtIfState object identifier. ospfConfigErrorType is set to a non-zero value when the state regresses due to an error." ::= { ospfTraps X } ospfNbrStateChange NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfNbrState, -- The new state ospfConfigErrorType } STATUS current DESCRIPTION "An ospfNbrStateChange trap signifies that there has been a change in the state of a non- virtual OSPF neighbor. The ospfNbrIpAddr, ospfNbrAddressLessIndex and ospfNbrRtrId value are attached to the ospfNbrState object identifier. ospfConfigErrorType is set to a non-zero value when state change is due to some error. The notifications ospfNbrStateTerminal and ospfNbrStateBackwardTransition should be generated instead of ospfNbrStateChange if the network manager is not interested in knowing the intermediate states." ::= { ospfTraps X } ospfNbrStateTerminal NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfNbrState -- The new state } STATUS current DESCRIPTION "An ospfNbrStateTerminal notification signifies that the neighbor state reaches to a terminal state (e.g., 2-Way, when adjacency not formed with the neighbor, or Full). The ospfNbrIpAddr, ospfNbrAddressLessIndex and ospfNbrRtrId value are attached to the ospfNbrState object identifier." ospfNbrStateBackwardTransition NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfNbrState, -- The new state ospfConfigErrorType } STATUS current DESCRIPTION "An ospfNbrStateBackwardTransition notification signifies that the state regresses (e.g., goes from Attempt or Full to 1-Way or Down). The ospfNbrIpAddr, ospfNbrAddressLessIndex and ospfNbrRtrId value are attached to the ospfNbrState object identifier. ospfConfigErrorType is set to a non-zero value when state change is due to some error." ospfVirtNbrStateChange NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtNbrState, -- The new state ospfConfigErrorType } STATUS current DESCRIPTION "An ospfVirtNbrStateChange trap signifies that there has been a change in the state of a non- virtual OSPF neighbor. The ospfVirtNbrArea and ospfVirtNbrRtrId values are attached to the ospfVirtNbrState object identifier. ospfConfigErrorType is set to a non-zero value when state change is due to some error. The notifications ospfVirtNbrStateTerminal and ospfVirtNbrStateBackwardTransition should be generated instead of ospfVirtNbrStateChange if the network manager is not interested in knowing the intermediate states." ::= { ospfTraps X } ospfVirtNbrStateTerminal NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtNbrState -- The new state } STATUS current DESCRIPTION "An ospfVirtNbrStateTerminal notification signifies that the neighbor state reaches to a terminal state (e.g., Full). The ospfVirtNbrArea and ospfVirtNbrRtrId values are attached to the ospfVirtNbrState object identifier." ::= { ospfTraps X } ospfVirtNbrStateBackwardTransition NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtNbrState, -- The new state ospfConfigErrorType } STATUS current DESCRIPTION "An ospfVirtNbrStateBackwardTransition notification signifies that the state regresses (e.g., goes from Attempt or Full to 1-Way or Down). The ospfVirtNbrArea and ospfVirtNbrRtrId values are attached to the ospfVirtNbrState object identifier. ospfConfigErrorType is set to a non-zero value when state change is due to some error." ::= { ospfTraps X } Thanks, Roy > > > > > ospfNbrStateChange > > ------------------ > > > > [OPEN issue] This is not addressed yet. > > > > The DECRIPTION clause states > > "When an neighbor transitions from or to Full on > > non-broadcast multi-access and broadcast networks, the trap > > should be generated by the designated router. A designated > > router transitioning to Down will be noted by > > ospfIfStateChange." I think here the intention is to reduce > > the number of TRAPs as much as possible by making only DR > > sending out this TRAP for a subnet. But there is a > > possibility that osfpNbrStateChange notification is disabled > > on DR and enabled on DR other or BDR. NMS won't receive TRAPs > > when NbrState becomes FULL in that case. There is a problem > > with the second part of above statments as well. Suppose > > ospfIfStateChange is disabled on the router, then again NMS > > won't know when neighbor goes down. Probably its better to > > remove these two clauses. > > > > Thanks, > > Roy > > > > > > > "Manral, Vishwas" wrote: > > > > > > > > Dan Joyal is at present working on the OSPFv2 MIB. > > > > > > And the OSPFv3 MIB as well. > > > > > > > > > Thanks, > > > Acee > > > > > > > > Thanks, > > > > Vishwas > > > > > > > > -----Original Message----- > > > > From: Roy Jose [mailto:rojose@CISCO.COM] > > > > Sent: Tuesday, March 18, 2003 12:03 PM > > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > Hi Acee, > > > > > > > > I agree with you. Till it becomes a standard draft, > > vendors have to > > > > go > > with > > > > some proprietory MIB I guess. Btw, who is working on the > > MIB update > > > > currently? > > > > > > > > Thanks, > > > > Roy > > > > > > > > > One small correction. > > > > > > > > > > Acee Lindem wrote: > > > > > > > > > > > > Roy, > > > > > > > > > > > > There are 3 reasons why I don't think Sham Links should be > > > > > > included in this MIB udpate: > > > > > > > > > > > > 1. I don't think they are sufficiently specified in the > > > > > > Internet Draft describing them. My experience > > implementing > > > > > > the Sham Link feature required some reverse > > > > > > engineering (Consult RFC 1264 for specification > > > > > > requirements). > > > > > > 2. The document describing them is not an OSPF WG > > > > > > document. In fact, it is not even an PPVPN > > > > > > document (although it could become one). > > > > > > 3. At some point, we have to close the door on adding > > > > > > MIB variables that are in all the drafts that may or > > > > > > may not ever reach draft standard status. If we don't > > > > > ~~~~~~~~~~~~~~ > > > > > Meant to say "proposed standard" here. > > > > > > > > > > > do this, we'll never finish the MIB update. > > > > > > > > > > > > Thanks, > > > > > > Acee > > > > > > > > > > > > Roy Jose wrote: > > > > > > > > > > > > > > Thanks Jeff, Acee, Mani and John for your responses. How > > > > > > > about > > other > > > > > > > points?:) > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "John Flick" > > > > > > > To: > > > > > > > Sent: Saturday, March 15, 2003 6:19 AM > > > > > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > > > > > > > Yep, adding an index would require deprecating everything > > > > > > > > and > > > > starting > > > > > > > over. > > > > > > > > Since this is an existing, widely deployed, Draft > > Standard > > > > > > > > MIB, > > this > > > > > > > should > > > > > > > > not be done lightly. > > > > > > > > > > > > > > > > You would have the same problem if you tried changing > > > > > > > > MAX-ACCESS > > on > > > > the > > > > > > > > table indices (as was also suggested below). > > Since a change > > > > > > > > to > > > > MAX-ACCESS > > > > > > > > of an existing object is not allowed, you would need to > > deprecated > > > > the > > > > > > > index > > > > > > > > objects, which would require deprecating the tables that > > > > > > > > they > > index. > > > > > > > Changing > > > > > > > > to not-accessible is not required, since SMIv2 allows > > > > > > > > read-only > > > > indices > > > > > > > for > > > > > > > > MIB modules that were translated from SMIv1 and therefore > > already > > > > had > > > > > > > > read-only indices. The OSPFv2 MIB started life > > in RFC 1248 > > > > > > > > as > > an > > > > SMIv1 > > > > > > > MIB > > > > > > > > module, so this exception applies. > > > > > > > > > > > > > > How about tables which were added later?: > > > > > > > ospfAreaAggregateTable, ExtLsdbTable, etc. My worry > > is not if > > > > > > > its allowed or not. I am trying to point out > > the > > > > extra > > > > > > > processing routers and > > > > > > > NMS have to do with the increased number of messages. > > > > > > > > > > > > > > > As far as finding a generic solution for multiple > > instances > > > > > > > > of a > > MIB > > > > > > > module, > > > > > > > > the standard solution is to use contexts (note: > > this is not > > > > > > > > the > > same > > > > as a > > > > > > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this > > > > > > > > was > > done > > > > in a > > > > > > > > somewhat ad-hoc way by using different community > > names for > > > > > > > > each > > > > instance > > > > > > > > of the OSPF MIB. In SNMPv3, it is more formally defined > > > > > > > > using > > the > > > > > > > > contextName. The Entity MIB entLogicalTable (RFC 2737) > > > > > > > > provides > > > > > > > information > > > > > > > > about what contexts exist in an agent, and how to get to > > > > > > > > them. > > > > > > > > > > > > > > After having a glance at rfc2737, I also think this is the > > > > > > > way. I > > > > think we > > > > > > > need to specify it clearly how it can be achieved using > > > > entLogicalTable. For > > > > > > > example, how we need to represent the SNMP > > community string to > > > > retrieve info > > > > > > > from a particular routing instance. > > > > > > > > > > > > > > Thanks, > > > > > > > Roy > > > > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > Acee Lindem wrote: > > > > > > > > > > > > > > > > > > Roy, > > > > > > > > > > > > > > > > > > I can appreciate your points since our product supports > > > > > > > > > both > > > > multiple > > > > > > > > > virtual router instances and multiple routing protocol > > instances > > > > > > > > > within a particular virtual router. However, I > > think we'd > > > > > > > > > essentially have to deprecate everything in the current > > > > > > > > > MIB > > and > > > > define > > > > > > > > > new tables in order to add OSPF instance ID as > > an index. > > > > > > > > > Can > > > > someone > > > > > > > > > who has more MIB definition experience comment? > > > > > > > > > > > > > > > > > > Additionally, the multiple instance problem is > > not unique > > > > > > > > > to > > the > > > > > > > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > > > > > > > > > > > > > Roy Jose wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I have some comments on > > > > > > > > > > draft-ietf-ospf-mib-update-05.txt. I > > > > would > > > > > > > also like > > > > > > > > > > to have some clarifications. Please see the attached > > document. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Roy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>Yes. An update is in the works. > > > > > > > > > >> > > > > > > > > > >>-Dan > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >>>-----Original Message----- > > > > > > > > > >>>From: Banerjee, Gargi > > > > > > > > > >>>[mailto:Gargi.Banerjee@MARCONI.COM] > > > > > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > > > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > > > > > > > >>>Subject: OSPFv2 MIB draft > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > > >>>Hi all: > > > > > > > > > >>>I would like to know the status of the working group > > > > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft > > > > > > > > > >>>shows > > an > > > > > > > > > >>>expiry date of > > > > > > > > > >>>May 2001. > > > > > > > > > >>>Is there any plan to update the draft ? > > > > > > > > > >>> > > > > > > > > > >>>Thanks > > > > > > > > > >>>Gargi > > > > > > > > > >>> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > >>------------------------------------------------------------ > > ---------- > > >>-- > > > > > > > > > >> > > > > > > > > > >>Support for multiple OSPF processes: > > > > > > > > > >>----------------------------------- > > > > > > > > > >> > > > > > > > > > >>We raised this issue some time back in WG. > > Currently MIB > > > > supports only > > > > > > > one Router ID. > > > > > > > > > >>Multiple processes can have separate router > > IDs. It is > > > > > > > > > >>also > > true > > > > with > > > > > > > other MIB objects > > > > > > > > > >>like ospfExternLsaCount, > > ospfExternLsaCksumSum etc. The > > solution > > > > we > > > > > > > got was to use a > > > > > > > > > >>separate MIB view for each process. But I > > don't think it > > > > > > > > > >>can > > be > > > > easily > > > > > > > implemented. > > > > > > > > > >>We suggest to form a new table to group scalar objects > > related > > > > to an > > > > > > > OSPF process and have > > > > > > > > > >>Process Id as its INDEX. We also suggest to > > add Process > > > > > > > > > >>Id > > as > > > > one of > > > > > > > the INDICES of all > > > > > > > > > >>tables. > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >>MAX-ACCESS value for INDICES of TABLES: > > > > > > > > > >>-------------------------------------- > > > > > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. > > > > > > > > > >>Normally > > > > INDICES > > > > > > > of a table are > > > > > > > > > >>put as not-accesssible to reduce the number of SNMP > > messages. > > > > When an > > > > > > > SNMP GET or > > > > > > > > > >>GETNEXT is issued on a non-INDEX object, we > > can extract > > > > > > > > > >>the > > > > values of > > > > > > > INDICES from > > > > > > > > > >>the object ID returned. For example, let us consider > > > > ospfAreaLsaCount. > > > > > > > When we query > > > > > > > > > >>the value for this, we get something like > > > > ospfAreaLsaCount.0.0.0.1, > > > > > > > where 0.0.0.1 is > > > > > > > > > >>the AreaId, which is the INDEX of the > > ospfAreaTable. We > > > > > > > > > >>can > > > > extract > > > > > > > the INDICES of > > > > > > > > > >>table like this even if they are not-accessible. The > > > > > > > > > >>tables > > like > > > > > > > LsdbTable has many > > > > > > > > > >>number of INDICES and we can reduce the number of SNMP > > messages > > > > > > > considerably by changing > > > > > > > > > >>them to not-accessible. > > > > > > > > > >> > > > > > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to > > > > > > > > > >>include > > > > them in > > > > > > > the TRAP > > > > > > > > > >>notification messages, they can be changed as > > > > accessible-for-notify. > > > > > > > Other approach to > > > > > > > > > >>this is remove the INDICES from TRAP notification > > > > > > > > > >>messages. > > For > > > > > > > example if you take the > > > > > > > > > >>case of IfStateChange TRAP, > > > > > > > > > >> > > > > > > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > > > > > > > >> OBJECTS { ospfRouterId, -- The > > originator of the > > trap^M > > > > > > > > > >> ospfIfIpAddress,^M > > > > > > > > > >> ospfAddressLessIf,^M > > > > > > > > > >> ospfIfState -- The new state^M > > > > > > > > > >> }^M > > > > > > > > > >>Here we don't actually need ospfIfIpAddress and > > > > ospfAddressLessIf. > > > > > > > When we send TRAP > > > > > > > > > >>notification, we can just send > > > > > > > > > >>ospfIfState. > > > > > > value>. . > > > > > > > > > >>Also I am not sure why ospfRouterId is > > included here. An > > > > > > > > > >>NMS > > > > station > > > > > > > can always query ospfRouterId > > > > > > > > > >>separately. By removing these MIB objects, we > > can reduce > > > > > > > > > >>the > > > > size and > > > > > > > processing time of TRAP > > > > > > > > > >>messages considerably. > > > > > > > > > >> > > > > > > > > > >>Section : 4.3 Ignoring Initial Activity > > > > > > > > > >>--------------------------------------- > > > > > > > > > >>The section states "The majority of critical events > > > > > > > > > >>occur > > when > > > > OSPF is > > > > > > > enabled on a > > > > > > > > > >>router, at which time the designated router > > is elected > > > > > > > > > >>and > > > > neighbor > > > > > > > adjacencies are formed" . > > > > > > > > > >>I am not sure if enabling OSPF on a router means > > > > > > > > > >>enabling it > > on > > > > an > > > > > > > interface. I think it will > > > > > > > > > >>be better to make the text clearer. > > > > > > > > > >> > > > > > > > > > >>Other statement is "To avoid unnecessary > > traps, a router > > should > > > > not > > > > > > > originate expected OSPF > > > > > > > > > >>interface related traps until two of that interface's > > > > > > > > > >>dead > > timer > > > > > > > intervals have elapsed." > > > > > > > > > >>I think there will be some problems if the > > dead interval > > value > > > > is too > > > > > > > long. We may end up > > > > > > > > > >>not sending any of the expected TRAPS for a > > long time. > > > > > > > > > >>Btw, > > > > could I > > > > > > > please know the reason > > > > > > > > > >>for selecting 2 * dead interval value for > > this purpose?. > > There > > > > might > > > > > > > be some case where an > > > > > > > > > >>interface is up and it goes down before (2 * dead > > > > > > > > > >>interval). > > We > > > > can't > > > > > > > take it as an 'expected > > > > > > > > > >>event'. Probably we can ignore the expected > > events till > > > > > > > > > >>the > > > > interface > > > > > > > reaches terminal state > > > > > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >>One more point is we are already limiting > > > > > > > > > >>ospfIfStateChange, > > > > > > > ospfVirtIfStateChange, > > > > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange > > > > > > > > > >>notifications > > by > > > > > > > generating them only for terminal > > > > > > > > > >>state changes and backward tansition. Do we > > really need > > > > > > > > > >>to > > > > ignore them > > > > > > > during the initial activity?. > > > > > > > > > >> > > > > > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and > > > > ospfOriginateLsa > > > > > > > traps should not be originated > > > > > > > > > >>until two dead timer intervals have elapsed where the > > deadtimer > > > > > > > interval used should be the dead > > > > > > > > > >>timer with the smallest value." Here whats > > the meaning > > > > > > > > > >>of > > "dead > > > > timer > > > > > > > with smallest value"? Is it > > > > > > > > > >>the smallest interval value among all the interfaces? > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >>Section 4.4 Throttling Traps > > > > > > > > > >>---------------------------- > > > > > > > > > >>Do we need to provide MIB objects corresponding to > > > > > > > > > >>window > > size > > > > and the > > > > > > > number of TRAPs sent during > > > > > > > > > >>the window time? Will the TRAPs other than > > > > > > > > > >>ospfTxRetransmit, > > > > > > > OrginateLsa and MaxAgeLsa really cause > > > > > > > > > >>a TRAP flood? Probably we need to throttle only the > > > > > > > > > >>above > > three > > > > TRAPS? > > > > > > > > > >> > > > > > > > > > >>I think the normal practice is to inform the > > NMS using > > > > > > > > > >>some > > > > other > > > > > > > notification at the end of a > > > > > > > > > >>particular interval when the TRAPs are dropped like > > > > > > > > > >>this, > > "Trap > > > > N > > > > > > > dropped n times in an interval > > > > > > > > > >>t". We can add some common extra paratmeters to these > > > > notifications to > > > > > > > facilitate the NMS to query > > > > > > > > > >>the router to retrieve some values and find out whats > > happening. > > > > > > > > > >> > > > > > > > > > >>ospfConfigErrorType > > > > > > > > > >>------------------- > > > > > > > > > >>Do we need an error type for duplicate router > > id in the > > received > > > > > > > messages? Some times loop back > > > > > > > > > >>address can be misconfigured. > > > > > > > > > >> > > > > > > > > > >>ospfSetTrap > > > > > > > > > >>----------- > > > > > > > > > >>The definition of this is little complicated. Any > > > > > > > > > >>reasons > > for > > > > going > > > > > > > for last bit to first. We think > > > > > > > > > >>its better to redefine this MIB object like > > this to make > > > > > > > > > >>if > > more > > > > > > > clear. > > > > > > > > > >> > > > > > > > > > >> cospfSetTrap OBJECT-TYPE > > > > > > > > > >> SYNTAX BITS { > > > > > > > > > >> ifConfigError (0), > > > > > > > > > >> virtIfConfigError (1), > > > > > > > > > >> ospfNbrStateChange (2), > > > > > > > > > >> . > > > > > > > > > >> . > > > > > > > > > >> . > > > > > > > > > >> } > > > > > > > > > >> MAX-ACCESS read-write > > > > > > > > > >> STATUS current > > > > > > > > > >> DESCRIPTION > > > > > > > > > >> "A One-octet string serving as a > > bit map for > > > > > > > > > >> the trap events defined by the > > OSPF traps in > > > > > > > > > >> this MIB. This object is used to enable and > > > > > > > > > >> disable specific OSPF traps > > where a 1 > > > > > > > > > >> in the corresponding bit field > > represents > > > > > > > > > >> enabled." > > > > > > > > > >> ::= { cospfTrapControl 1 } > > > > > > > > > >> > > > > > > > > > >>This definition enables the NMS to interpret > > the bit map > > easily. > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >>ospfIfStateChange > > > > > > > > > >>----------------- > > > > > > > > > >> > > > > > > > > > >>>From the definition it looks like this TRAP should be > > generated > > > > only > > > > > > > for terminal states(when state > > > > > > > > > >>progresses) and for backward transition. > > Infact the name > > > > > > > ospfIfStateChange simply suggests to > > > > > > > > > >>generate TRAPs for all state transitions. The general > > tendency > > > > is to > > > > > > > ignore the DESCRIPTION when > > > > > > > > > >>"StateChange" is read and assume its for all the state > > changes. > > > > It > > > > > > > might lead to wrong > > > > > > > > > >>implementations. I think we can also follow > > the approach > > taken > > > > in BGP > > > > > > > MIB(rfc1657). > > > > > > > > > >>There they have notifications like this, > > > > > > > > > >> bgpEstablished NOTIFICATION-TYPE > > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > > >> bgpPeerState } > > > > > > > > > >> STATUS current > > > > > > > > > >> DESCRIPTION > > > > > > > > > >> "The BGP > > Established event > > > > > > > > > >>is > > > > generated > > > > > > > when > > > > > > > > > >> the BGP FSM enters the > > ESTABLISHED > > > > state." > > > > > > > > > >> ::= { bgpTraps 1 } > > > > > > > > > >> > > > > > > > > > >> bgpBackwardTransition > > NOTIFICATION-TYPE > > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > > >> bgpPeerState } > > > > > > > > > >> STATUS current > > > > > > > > > >> DESCRIPTION > > > > > > > > > >> "The > > BGPBackwardTransition > > > > > > > > > >> Event > > is > > > > > > > generated > > > > > > > > > >> when the BGP FSM > > moves from > > > > > > > > > >> a > > higher > > > > > > > numbered > > > > > > > > > >> state to a lower numbered > > state." > > > > > > > > > >> ::= { bgpTraps 2 } > > > > > > > > > >> > > > > > > > > > >>Our suggestion is to maintain > > ospfIfStateChange and use > > > > > > > > > >>that > > for > > > > > > > monitoring all the states > > > > > > > > > >>(some people may want that) and additionally have > > notifications > > > > > > > similar to the BGP notifications. > > > > > > > > > >>Its also true with VirtIfStateChange, > > NbrStateChange and > > > > > > > VirtNbrStateChange. If somebody doesn't > > > > > > > > > >>want to see ALL state TRAPS, they can suppress them by > > turning > > > > off the > > > > > > > corresponding bit in > > > > > > > > > >>ospfSetTrap. > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >>ospfNbrStateChange > > > > > > > > > >>------------------ > > > > > > > > > >>The DECRIPTION clause states > > > > > > > > > >>"When an neighbor transitions from or to Full on > > non-broadcast > > > > > > > multi-access and broadcast > > > > > > > > > >> networks, the trap should be generated by the > > > > > > > > > >> designated > > > > router. A > > > > > > > designated router > > > > > > > > > >>transitioning to Down will be noted by > > > > > > > > > >>ospfIfStateChange." I think here the intention is to > > > > > > > > > >>reduce the number of TRAPs > > as > > > > much as > > > > > > > possible by making > > > > > > > > > >>only DR sending out this TRAP for a subnet. > > But there is > > > > > > > > > >>a > > > > possibility > > > > > > > that osfpNbrStateChange > > > > > > > > > >>notification is disabled on DR and enabled on > > DR other > > > > > > > > > >>or > > BDR. > > > > NMS > > > > > > > won't receive TRAPs when > > > > > > > > > >>NbrState becomes FULL in that case. There is > > a problem > > > > > > > > > >>with > > the > > > > second > > > > > > > part of above statments > > > > > > > > > >>as well. Suppose ospfIfStateChange is disabled on the > > router, > > > > then > > > > > > > again NMS won't know when > > > > > > > > > >>neighbor goes down. Probably its better to > > remove these > > > > > > > > > >>two > > > > clauses. > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >>Support for sham links: > > > > > > > > > >>----------------------- > > > > > > > > > >>Are you going to provide support for sham > > links? We may > > > > > > > > > >>need > > > > these > > > > > > > tables and notifications, > > > > > > > > > >>ShamLinkTable > > > > > > > > > >>ShamLinkNbrTable > > > > > > > > > >>ShamLinkStateChange notification > > ShamLinkNbrStateChange > > > > > > > > > >>notification > > > > > > > > > > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 20 05:49:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14145 for ; Thu, 20 Mar 2003 05:49:18 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0093B6B8@cherry.ease.lsoft.com>; Thu, 20 Mar 2003 5:51:26 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668513 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 20 Mar 2003 05:51:26 -0500 Received: from 171.71.177.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Mar 2003 05:51:26 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2KApLHp009500 for ; Thu, 20 Mar 2003 02:51:22 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id QAA09133 for ; Thu, 20 Mar 2003 16:19:57 +0530 (IST) References: <6204FDDE129D364D8040A98BCCB290EF0440AB3D@zbl6c004.corpeast.baynetworks.com> <0f6201c2eec7$6b0d46d0$9c8b4d0a@apac.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <0fed01c2eece$a3d69d20$9c8b4d0a@apac.cisco.com> Date: Thu, 20 Mar 2003 16:21:19 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit One correction inline, > Hi Dan, > > Thanks. Please see inline. > > > Comments in-line below. > > > > -Dan > > > > > -----Original Message----- > > > From: Roy Jose [mailto:rojose@CISCO.COM] > > > Sent: Wednesday, March 19, 2003 6:05 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > Thanks Manral, Acee. > > > > > > Let me point out the open issues here from the original > > > document I sent. Joyal, please let me know if you need any > > > clarifications. > > > > > > Support for multiple OSPF processes: > > > ----------------------------------- > > > > > > We raised this issue some time back in WG. Currently MIB > > > supports only one Router ID. Multiple processes can have > > > separate router IDs. It is also true with other MIB objects > > > like ospfExternLsaCount, ospfExternLsaCksumSum etc. The > > > solution we got was to use a separate MIB view for each > > > process. But I don't think it can be easily implemented. We > > > suggest to form a new table to group scalar objects related > > > to an OSPF process and have Process Id as its INDEX. We also > > > suggest to add Process Id as one of the INDICES of all > > > tables. [WG - John Flick] As far as finding a generic > > > solution for multiple instances of a MIB module, the standard > > > solution is to use contexts (note: this is not the same as a > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was > > > done in a somewhat ad-hoc way by using different community > > > names for each instance of the OSPF MIB. In SNMPv3, it is > > > more formally defined using the contextName. The Entity MIB > > > entLogicalTable (RFC 2737) provides information about what > > > contexts exist in an agent, and how to get to them. [OPEN > > > issue] I think we need to investigate on this and add a > > > section to the draft how it can be applied to OSPF MIB . > > > > > > > This issue is not unique to the OSPF MIBs. I would prefer > > to just reference the RFCs that deal with SNMP contexts that > > John Flick mentioned. > > I would let John comment on this. Do we need to add any thing extra? My > point is different implementations should have the same behavior to avoid > interoperability issues. Also we need to think about modifying TRAP messages > to facilitate the NMS interpret the routing instance. Probably we can add a > new MIB object like OspfRoutingIstanceId to the notification messages. > > > > > > > > > MAX-ACCESS value for INDICES of TABLES: > > > -------------------------------------- > > > I see MAX-ACCESS value of all TABLEs are read-only. Normally > > > INDICES of a table are put as not-accesssible to reduce the > > > number of SNMP messages. When an SNMP GET or GETNEXT is > > > issued on a non-INDEX object, we can extract the values of > > > INDICES from the object ID returned. For example, let us > > > consider ospfAreaLsaCount. When we query the value for this, > > > we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1 > > > is the AreaId, which is the INDEX of the ospfAreaTable. We > > > can extract the INDICES of table like this even if they are > > > not-accessible. The tables like LsdbTable has many number of > > > INDICES and we can reduce the number of SNMP messages > > > considerably by changing them to not-accessible. > > > > > > [WG - John Flick] > > > You would have the same problem if you tried changing > > > MAX-ACCESS on the table indices (as was also suggested > > > below). Since a change to MAX-ACCESS of an existing object > > > is not allowed, you would need to deprecated the index > > > objects, which would require deprecating the tables that they > > > index. Changing to not-accessible is not required, since > > > SMIv2 allows read-only indices for MIB modules that were > > > translated from SMIv1 and therefore already had read-only > > > indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 > > > MIB module, so this exception applies. > > > > > > [OPEN issue] > > > As I have pointed out earlier, by changing the INDICES we can > > > reduce the number of SNMP GETNEXT reponses sent by the > > > router considerably. The draft standard MIB is already widely > > > deployed. But we need to deprecate an existing MIB and add a > > > new version, when it is required. I feel if everyone thinks > > > what I pointed out is a big advantange, still we can go ahead > > > with this change. > > > > > > If the MAX-ACCESS of INDICES are put as read-only to include > > > them in the TRAP notification messages, they can be changed > > > as accessible-for-notify. Other approach to this is remove > > > the INDICES from TRAP notification messages. For example if > > > you take the case of IfStateChange TRAP, > > > > > > ospfIfStateChange NOTIFICATION-TYPE^M > > > OBJECTS { ospfRouterId, -- The originator of the trap^M > > > ospfIfIpAddress,^M > > > ospfAddressLessIf,^M > > > ospfIfState -- The new state^M > > > }^M > > > Here we don't actually need ospfIfIpAddress and > > > ospfAddressLessIf. When we send TRAP notification, we can > > > just send ospfIfState. > > value>. . > > > Also I am not sure why ospfRouterId is included here. An NMS > > > station can always query ospfRouterId separately. By removing > > > these MIB objects, we can reduce the size and processing time > > > of TRAP messages considerably. > > > > > > [OPEN issue] The above point is not addressed yet. > > > > > > > I think there would need to be a strong WG consensus that deprecating the > > entire MIB for this is worth it. > > I agree. Please see my previous mail to Manral. > > > > > > Section : 4.3 Ignoring Initial Activity > > > --------------------------------------- > > > > > > [OPEN issue] This is not addressed yet. > > > > > > The section states "The majority of critical events occur > > > when OSPF is enabled on a router, at which time the > > > designated router is elected and neighbor adjacencies are > > > formed" . I am not sure if enabling OSPF on a router means > > > enabling it on an interface. I think it will be better to > > > make the text clearer. > > > > > > Other statement is "To avoid unnecessary traps, a router > > > should not originate expected OSPF interface related traps > > > until two of that interface's dead timer intervals have > > > elapsed." I think there will be some problems if the dead > > > interval value is too long. We may end up not sending any of > > > the expected TRAPS for a long time. Btw, could I please know > > > the reason for selecting 2 * dead interval value for this > > > purpose?. There might be some case where an interface is up > > > and it goes down before (2 * dead interval). We can't take it > > > as an 'expected event'. Probably we can ignore the expected > > > events till the interface reaches terminal state (FULL or > > > 2WAY) for the first time after enabling OSPF. > > > > > > > > > One more point is we are already limiting ospfIfStateChange, > > > ospfVirtIfStateChange, ospfNbrStateChange and > > > ospfVirtNbrStateChange notifications by generating them only > > > for terminal state changes and backward tansition. Do we > > > really need to ignore them during the initial activity?. > > > > > > Other statement is "Additionally, ospfMaxAgeLsa and > > > ospfOriginateLsa traps should not be originated until two > > > dead timer intervals have elapsed where the deadtimer > > > interval used should be the dead timer with the smallest > > > value." Here whats the meaning of "dead timer with smallest > > > value"? Is it the smallest interval value among all the interfaces? > > > > > > > I think the intent of the original authors of the MIB was > > to give some guidelines (hence the wording "should not" rather > > than "must not") for when or when not to generate traps. I don't > > know how closely real world implementations follow these guidelines. > > I am sure many people would like to reduce the number of TRAPs during the > initial activity. Imagine a case where OrinateLsaTrap TRAPs are flooded like > anything during initial activity. In our implementation we are suppressing > traps during initial activity, but not exactly in the same way taking > advantage of "should not" :) I feel the guidelines here should be clear and > worth to implement. > > > > > > > > > Section 4.4 Throttling Traps > > > ---------------------------- > > > > > > [OPEN issue] This is not addressed yet. > > > > > > Do we need to provide MIB objects corresponding to window > > > size and the number of TRAPs sent during the window time? > > > Will the TRAPs other than ospfTxRetransmit, OrginateLsa and > > > MaxAgeLsa really cause a TRAP flood? Probably we need to > > > throttle only the above three TRAPS? > > > > > > I think the normal practice is to inform the NMS using some > > > other notification at the end of a particular interval when > > > the TRAPs are dropped like this, "Trap N dropped n times in > > > an interval t". We can add some common extra paratmeters to > > > these notifications to facilitate the NMS to query the router > > > to retrieve some values and find out whats happening. > > > > > > ospfConfigErrorType > > > ------------------- > > > > > > [OPEN issue] This is not addressed yet. > > > > > > Do we need an error type for duplicate router id in the > > > received messages? Some times loop back address can be misconfigured. > > > > Easy to add if required. > > As I said in the earlier, we need to check if we are missing any other > errors. > > > > > > > > > ospfSetTrap > > > ----------- > > > > > > [OPEN issue] This is not addressed yet. > > > > > > The definition of this is little complicated. Any reasons for > > > going for last bit to first. We think its better to redefine > > > this MIB object like this to make if more clear. > > > > > > cospfSetTrap OBJECT-TYPE > > > SYNTAX BITS { > > > ifConfigError (0), > > > virtIfConfigError (1), > > > ospfNbrStateChange (2), > > > . > > > . > > > . > > > } > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "A One-octet string serving as a bit map for > > > the trap events defined by the OSPF traps in > > > this MIB. This object is used to enable and > > > disable specific OSPF traps where a 1 > > > in the corresponding bit field represents > > > enabled." > > > ::= { cospfTrapControl 1 } > > > > > > This definition enables the NMS to interpret the bit map easily. > > > > Changing to a non-equivalent syntax would require creation of a new > object. > > This is a critical MIB object to control the TRAPs. I feel its important to > make it easily interpreted. > > > > > > > > > > > > ospfIfStateChange > > > ----------------- > > > [OPEN issue] This is not addressed yet. > > > > > > From the definition it looks like this TRAP should be > > > generated only for terminal states(when state > > > progresses) and for backward transition. Infact the name > > > ospfIfStateChange simply suggests to generate TRAPs for all > > > state transitions. The general tendency is to ignore the > > > DESCRIPTION when "StateChange" is read and assume its for all > > > the state changes. It might lead to wrong implementations. I > > > think we can also follow the approach taken in BGP > > > MIB(rfc1657). There they have notifications like this, > > > bgpEstablished NOTIFICATION-TYPE > > > OBJECTS { bgpPeerLastError, > > > bgpPeerState } > > > STATUS current > > > DESCRIPTION > > > "The BGP Established event is > > > generated when > > > the BGP FSM enters the ESTABLISHED state." > > > ::= { bgpTraps 1 } > > > > > > bgpBackwardTransition NOTIFICATION-TYPE > > > OBJECTS { bgpPeerLastError, > > > bgpPeerState } > > > STATUS current > > > DESCRIPTION > > > "The BGPBackwardTransition Event > > > is generated > > > when the BGP FSM moves from a > > > higher numbered > > > state to a lower numbered state." > > > ::= { bgpTraps 2 } > > > > > > Our suggestion is to maintain ospfIfStateChange and use that > > > for monitoring all the states (some people may want that) and > > > additionally have notifications similar to the BGP > > > notifications. Its also true with VirtIfStateChange, > > > NbrStateChange and VirtNbrStateChange. If somebody doesn't > > > want to see ALL state TRAPS, they can suppress them by > > > turning off the corresponding bit in ospfSetTrap. > > > > > > > OK. Could you list the new BGP-like notifications for OSPF? > > Sure. I have defined them in a rough way. Let me reiterate one point. Here > the first TRAP in each step for people who are interested in knowing all I meant each set by "step", for eg., ospfIfStateChange, ospfIfStateTerminal and ospfIfStateBackwardTransition. -Roy > state changes. The next two(Terminal and Backward transition are for those > who want to limit the TRAP messages). Please note that I have added > ospfConfigErrorType to make the NMS know the error which caused backward > transition. > > ospfIfStateChange NOTIFICATION-TYPE > OBJECTS { > ospfRouterId, -- The originator of the trap > ospfIfState, -- The new state > ospfConfigErrorType > } > STATUS current > DESCRIPTION > "An ospfIfStateChange trap signifies that there > has been a change in the state of a non-virtual > OSPF interface. The ospfIfIpAddress and > ospfAddressLessIf values must be attached to ospfIfState > object identifier. ospfConfigErrorType is set to a non-zero > value when state change is due to some error. > The notifications ospfIfStateTerminal and > ospfIfStateBackwardTransition should be generated > instead of ospfIfStateChange if the network manager is > not interested in knowing the intermediate states." > ::= { ospfTraps X } > > ospfIfStateTerminal NOTIFICATION-TYPE > OBJECTS { > ospfRouterId, -- The originator of the trap > ospfIfState -- The terminal state > } > STATUS current > DESCRIPTION > "An ospfIfStateTerminal notification signifies that a > non-virtual OSPF interface reaches a terminal > state (i.e., Point-to-Point, DR Other, Dr, or > Backup). ospfIfIpAddress and ospfAddressLessIf > values are attached to ospfIfState object identifier." > ::= { ospfTraps X } > > ospfIfStateBackwardTransition NOTIFICATION-TYPE > OBJECTS { > ospfRouterId, -- The originator of the trap > ospfIfState, -- The new state > ospfConfigErrorType > } > STATUS current > DESCRIPTION > "An ospfIfStateBackwardTransition notification signifies that a > non-virtual OSPF interface state regresses (e.g., goes > from Dr to Down). ospfIfIpAddress and ospfAddressLessIf > values are attached to the ospfIfState object identifier. > ospfConfigErrorType is set to a non-zero value when the state > regresses due to an error." > ::= { ospfTraps X } > > > ospfVirtIfStateChange NOTIFICATION-TYPE > OBJECTS { > ospfRouterId, -- The originator of the trap > ospfVirtIfState, -- The new state > ospfConfigErrorType > } > STATUS current > DESCRIPTION > "An ospfVirtIfStateChange trap signifies that there > has been a change in the state of a virtual > OSPF interface. The ospfVirtIfAreaId and > ospfVirtIfNeighbor values must be attached to the > ospfVirtIfState > object identifier. ospfConfigErrorType is set to a non-zero > value when state change is due to some error. > The notifications ospfIfStateTerminal and > ospfIfStateBackwardTransition should be generated > instead of ospfIfStateChange if the network manager is > not interested in knowing the intermediate states." > ::= { ospfTraps X } > > > ospfVirtIfStateTerminal NOTIFICATION-TYPE > OBJECTS { > ospfRouterId, -- The originator of the trap > ospfVirtIfState -- The terminal state > } > STATUS current > DESCRIPTION > "An ospfVirtIfStateTerminal notification signifies that a > virtual OSPF interface reaches a terminal > state (i.e., Point-to-Point). The ospfVirtIfAreaId and > ospfVirtIfNeighbor values must be attached to the > ospfVirtIfState > object identifier.." > ::= { ospfTraps X } > > > ospfVirtIfStateBackwardTransition NOTIFICATION-TYPE > OBJECTS { > ospfRouterId, -- The originator of the trap > ospfVirtIfState, -- The new state > ospfConfigErrorType > } > STATUS current > DESCRIPTION > "An ospfVirtIfStateBackwardTransition notification signifies that > a > virtual OSPF interface state regresses (e.g., goes from > Point-to-Point to Down). The ospfVirtIfAreaId and > ospfVirtIfNeighbor values must be attached to the ospfVirtIfState > object identifier. ospfConfigErrorType is set to a non-zero > value > when the state regresses due to an error." > ::= { ospfTraps X } > > ospfNbrStateChange NOTIFICATION-TYPE > OBJECTS { > ospfRouterId, -- The originator of the trap > ospfNbrState, -- The new state > ospfConfigErrorType > } > STATUS current > DESCRIPTION > "An ospfNbrStateChange trap signifies that > there has been a change in the state of a non- > virtual OSPF neighbor. The ospfNbrIpAddr, > ospfNbrAddressLessIndex and ospfNbrRtrId > value are attached to the ospfNbrState object > identifier. ospfConfigErrorType is set to a non-zero > value when state change is due to some error. > The notifications ospfNbrStateTerminal and > ospfNbrStateBackwardTransition should be generated > instead of ospfNbrStateChange if the network manager is > not interested in knowing the intermediate states." > > ::= { ospfTraps X } > > ospfNbrStateTerminal NOTIFICATION-TYPE > OBJECTS { > ospfRouterId, -- The originator of the trap > ospfNbrState -- The new state > } > STATUS current > DESCRIPTION > "An ospfNbrStateTerminal notification signifies > that the neighbor state reaches to a terminal state > (e.g., 2-Way, when adjacency not formed with > the neighbor, or Full). The ospfNbrIpAddr, > ospfNbrAddressLessIndex and ospfNbrRtrId > value are attached to the ospfNbrState object > identifier." > > ospfNbrStateBackwardTransition NOTIFICATION-TYPE > OBJECTS { > ospfRouterId, -- The originator of the trap > ospfNbrState, -- The new state > ospfConfigErrorType > } > STATUS current > DESCRIPTION > "An ospfNbrStateBackwardTransition notification > signifies that the state regresses (e.g., goes from > Attempt or Full to 1-Way or Down). The > ospfNbrIpAddr, ospfNbrAddressLessIndex and > ospfNbrRtrId value are attached to the ospfNbrState > object identifier. ospfConfigErrorType is set to a non-zero > value when state change is due to some error." > > ospfVirtNbrStateChange NOTIFICATION-TYPE > OBJECTS { > ospfRouterId, -- The originator of the trap > ospfVirtNbrState, -- The new state > ospfConfigErrorType > } > STATUS current > DESCRIPTION > "An ospfVirtNbrStateChange trap signifies that > there has been a change in the state of a non- > virtual OSPF neighbor. The ospfVirtNbrArea and > ospfVirtNbrRtrId values are attached to the ospfVirtNbrState > object identifier. ospfConfigErrorType is set to a non-zero > value when state change is due to some error. > The notifications ospfVirtNbrStateTerminal and > ospfVirtNbrStateBackwardTransition should be generated > instead of ospfVirtNbrStateChange if the network manager is > not interested in knowing the intermediate states." > > ::= { ospfTraps X } > > ospfVirtNbrStateTerminal NOTIFICATION-TYPE > OBJECTS { > ospfRouterId, -- The originator of the trap > ospfVirtNbrState -- The new state > } > STATUS current > DESCRIPTION > "An ospfVirtNbrStateTerminal notification signifies > that the neighbor state reaches to a terminal state > (e.g., Full). The ospfVirtNbrArea and ospfVirtNbrRtrId > values are attached to the ospfVirtNbrState object identifier." > ::= { ospfTraps X } > > ospfVirtNbrStateBackwardTransition NOTIFICATION-TYPE > OBJECTS { > ospfRouterId, -- The originator of the trap > ospfVirtNbrState, -- The new state > ospfConfigErrorType > } > STATUS current > DESCRIPTION > "An ospfVirtNbrStateBackwardTransition notification > signifies that the state regresses (e.g., goes from > Attempt or Full to 1-Way or Down). The ospfVirtNbrArea and > ospfVirtNbrRtrId values are attached to the ospfVirtNbrState > object identifier. ospfConfigErrorType is set to a non-zero > value when state change is due to some error." > ::= { ospfTraps X } > > Thanks, > Roy > > > > > > > > > ospfNbrStateChange > > > ------------------ > > > > > > [OPEN issue] This is not addressed yet. > > > > > > The DECRIPTION clause states > > > "When an neighbor transitions from or to Full on > > > non-broadcast multi-access and broadcast networks, the trap > > > should be generated by the designated router. A designated > > > router transitioning to Down will be noted by > > > ospfIfStateChange." I think here the intention is to reduce > > > the number of TRAPs as much as possible by making only DR > > > sending out this TRAP for a subnet. But there is a > > > possibility that osfpNbrStateChange notification is disabled > > > on DR and enabled on DR other or BDR. NMS won't receive TRAPs > > > when NbrState becomes FULL in that case. There is a problem > > > with the second part of above statments as well. Suppose > > > ospfIfStateChange is disabled on the router, then again NMS > > > won't know when neighbor goes down. Probably its better to > > > remove these two clauses. > > > > > > Thanks, > > > Roy > > > > > > > > > > "Manral, Vishwas" wrote: > > > > > > > > > > Dan Joyal is at present working on the OSPFv2 MIB. > > > > > > > > And the OSPFv3 MIB as well. > > > > > > > > > > > > Thanks, > > > > Acee > > > > > > > > > > Thanks, > > > > > Vishwas > > > > > > > > > > -----Original Message----- > > > > > From: Roy Jose [mailto:rojose@CISCO.COM] > > > > > Sent: Tuesday, March 18, 2003 12:03 PM > > > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > > Hi Acee, > > > > > > > > > > I agree with you. Till it becomes a standard draft, > > > vendors have to > > > > > go > > > with > > > > > some proprietory MIB I guess. Btw, who is working on the > > > MIB update > > > > > currently? > > > > > > > > > > Thanks, > > > > > Roy > > > > > > > > > > > One small correction. > > > > > > > > > > > > Acee Lindem wrote: > > > > > > > > > > > > > > Roy, > > > > > > > > > > > > > > There are 3 reasons why I don't think Sham Links should be > > > > > > > included in this MIB udpate: > > > > > > > > > > > > > > 1. I don't think they are sufficiently specified in the > > > > > > > Internet Draft describing them. My experience > > > implementing > > > > > > > the Sham Link feature required some reverse > > > > > > > engineering (Consult RFC 1264 for specification > > > > > > > requirements). > > > > > > > 2. The document describing them is not an OSPF WG > > > > > > > document. In fact, it is not even an PPVPN > > > > > > > document (although it could become one). > > > > > > > 3. At some point, we have to close the door on adding > > > > > > > MIB variables that are in all the drafts that may or > > > > > > > may not ever reach draft standard status. If we don't > > > > > > ~~~~~~~~~~~~~~ > > > > > > Meant to say "proposed standard" here. > > > > > > > > > > > > > do this, we'll never finish the MIB update. > > > > > > > > > > > > > > Thanks, > > > > > > > Acee > > > > > > > > > > > > > > Roy Jose wrote: > > > > > > > > > > > > > > > > Thanks Jeff, Acee, Mani and John for your responses. How > > > > > > > > about > > > other > > > > > > > > points?:) > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "John Flick" > > > > > > > > To: > > > > > > > > Sent: Saturday, March 15, 2003 6:19 AM > > > > > > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > > > > > > > > > Yep, adding an index would require deprecating everything > > > > > > > > > and > > > > > starting > > > > > > > > over. > > > > > > > > > Since this is an existing, widely deployed, Draft > > > Standard > > > > > > > > > MIB, > > > this > > > > > > > > should > > > > > > > > > not be done lightly. > > > > > > > > > > > > > > > > > > You would have the same problem if you tried changing > > > > > > > > > MAX-ACCESS > > > on > > > > > the > > > > > > > > > table indices (as was also suggested below). > > > Since a change > > > > > > > > > to > > > > > MAX-ACCESS > > > > > > > > > of an existing object is not allowed, you would need to > > > deprecated > > > > > the > > > > > > > > index > > > > > > > > > objects, which would require deprecating the tables that > > > > > > > > > they > > > index. > > > > > > > > Changing > > > > > > > > > to not-accessible is not required, since SMIv2 allows > > > > > > > > > read-only > > > > > indices > > > > > > > > for > > > > > > > > > MIB modules that were translated from SMIv1 and therefore > > > already > > > > > had > > > > > > > > > read-only indices. The OSPFv2 MIB started life > > > in RFC 1248 > > > > > > > > > as > > > an > > > > > SMIv1 > > > > > > > > MIB > > > > > > > > > module, so this exception applies. > > > > > > > > > > > > > > > > How about tables which were added later?: > > > > > > > > ospfAreaAggregateTable, ExtLsdbTable, etc. My worry > > > is not if > > > > > > > > its allowed or not. I am trying to point out > > > the > > > > > extra > > > > > > > > processing routers and > > > > > > > > NMS have to do with the increased number of messages. > > > > > > > > > > > > > > > > > As far as finding a generic solution for multiple > > > instances > > > > > > > > > of a > > > MIB > > > > > > > > module, > > > > > > > > > the standard solution is to use contexts (note: > > > this is not > > > > > > > > > the > > > same > > > > > as a > > > > > > > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this > > > > > > > > > was > > > done > > > > > in a > > > > > > > > > somewhat ad-hoc way by using different community > > > names for > > > > > > > > > each > > > > > instance > > > > > > > > > of the OSPF MIB. In SNMPv3, it is more formally defined > > > > > > > > > using > > > the > > > > > > > > > contextName. The Entity MIB entLogicalTable (RFC 2737) > > > > > > > > > provides > > > > > > > > information > > > > > > > > > about what contexts exist in an agent, and how to get to > > > > > > > > > them. > > > > > > > > > > > > > > > > After having a glance at rfc2737, I also think this is the > > > > > > > > way. I > > > > > think we > > > > > > > > need to specify it clearly how it can be achieved using > > > > > entLogicalTable. For > > > > > > > > example, how we need to represent the SNMP > > > community string to > > > > > retrieve info > > > > > > > > from a particular routing instance. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Roy > > > > > > > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > Acee Lindem wrote: > > > > > > > > > > > > > > > > > > > > Roy, > > > > > > > > > > > > > > > > > > > > I can appreciate your points since our product supports > > > > > > > > > > both > > > > > multiple > > > > > > > > > > virtual router instances and multiple routing protocol > > > instances > > > > > > > > > > within a particular virtual router. However, I > > > think we'd > > > > > > > > > > essentially have to deprecate everything in the current > > > > > > > > > > MIB > > > and > > > > > define > > > > > > > > > > new tables in order to add OSPF instance ID as > > > an index. > > > > > > > > > > Can > > > > > someone > > > > > > > > > > who has more MIB definition experience comment? > > > > > > > > > > > > > > > > > > > > Additionally, the multiple instance problem is > > > not unique > > > > > > > > > > to > > > the > > > > > > > > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > > > > > > > > > > > > > > > Roy Jose wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > I have some comments on > > > > > > > > > > > draft-ietf-ospf-mib-update-05.txt. I > > > > > would > > > > > > > > also like > > > > > > > > > > > to have some clarifications. Please see the attached > > > document. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Roy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>Yes. An update is in the works. > > > > > > > > > > >> > > > > > > > > > > >>-Dan > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >>>-----Original Message----- > > > > > > > > > > >>>From: Banerjee, Gargi > > > > > > > > > > >>>[mailto:Gargi.Banerjee@MARCONI.COM] > > > > > > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > > > > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > > > > > > > > >>>Subject: OSPFv2 MIB draft > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > > > >>>Hi all: > > > > > > > > > > >>>I would like to know the status of the working group > > > > > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft > > > > > > > > > > >>>shows > > > an > > > > > > > > > > >>>expiry date of > > > > > > > > > > >>>May 2001. > > > > > > > > > > >>>Is there any plan to update the draft ? > > > > > > > > > > >>> > > > > > > > > > > >>>Thanks > > > > > > > > > > >>>Gargi > > > > > > > > > > >>> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >>------------------------------------------------------------ > > > ---------- > > > >>-- > > > > > > > > > > >> > > > > > > > > > > >>Support for multiple OSPF processes: > > > > > > > > > > >>----------------------------------- > > > > > > > > > > >> > > > > > > > > > > >>We raised this issue some time back in WG. > > > Currently MIB > > > > > supports only > > > > > > > > one Router ID. > > > > > > > > > > >>Multiple processes can have separate router > > > IDs. It is > > > > > > > > > > >>also > > > true > > > > > with > > > > > > > > other MIB objects > > > > > > > > > > >>like ospfExternLsaCount, > > > ospfExternLsaCksumSum etc. The > > > solution > > > > > we > > > > > > > > got was to use a > > > > > > > > > > >>separate MIB view for each process. But I > > > don't think it > > > > > > > > > > >>can > > > be > > > > > easily > > > > > > > > implemented. > > > > > > > > > > >>We suggest to form a new table to group scalar objects > > > related > > > > > to an > > > > > > > > OSPF process and have > > > > > > > > > > >>Process Id as its INDEX. We also suggest to > > > add Process > > > > > > > > > > >>Id > > > as > > > > > one of > > > > > > > > the INDICES of all > > > > > > > > > > >>tables. > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >>MAX-ACCESS value for INDICES of TABLES: > > > > > > > > > > >>-------------------------------------- > > > > > > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. > > > > > > > > > > >>Normally > > > > > INDICES > > > > > > > > of a table are > > > > > > > > > > >>put as not-accesssible to reduce the number of SNMP > > > messages. > > > > > When an > > > > > > > > SNMP GET or > > > > > > > > > > >>GETNEXT is issued on a non-INDEX object, we > > > can extract > > > > > > > > > > >>the > > > > > values of > > > > > > > > INDICES from > > > > > > > > > > >>the object ID returned. For example, let us consider > > > > > ospfAreaLsaCount. > > > > > > > > When we query > > > > > > > > > > >>the value for this, we get something like > > > > > ospfAreaLsaCount.0.0.0.1, > > > > > > > > where 0.0.0.1 is > > > > > > > > > > >>the AreaId, which is the INDEX of the > > > ospfAreaTable. We > > > > > > > > > > >>can > > > > > extract > > > > > > > > the INDICES of > > > > > > > > > > >>table like this even if they are not-accessible. The > > > > > > > > > > >>tables > > > like > > > > > > > > LsdbTable has many > > > > > > > > > > >>number of INDICES and we can reduce the number of SNMP > > > messages > > > > > > > > considerably by changing > > > > > > > > > > >>them to not-accessible. > > > > > > > > > > >> > > > > > > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to > > > > > > > > > > >>include > > > > > them in > > > > > > > > the TRAP > > > > > > > > > > >>notification messages, they can be changed as > > > > > accessible-for-notify. > > > > > > > > Other approach to > > > > > > > > > > >>this is remove the INDICES from TRAP notification > > > > > > > > > > >>messages. > > > For > > > > > > > > example if you take the > > > > > > > > > > >>case of IfStateChange TRAP, > > > > > > > > > > >> > > > > > > > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > > > > > > > > >> OBJECTS { ospfRouterId, -- The > > > originator of the > > > trap^M > > > > > > > > > > >> ospfIfIpAddress,^M > > > > > > > > > > >> ospfAddressLessIf,^M > > > > > > > > > > >> ospfIfState -- The new state^M > > > > > > > > > > >> }^M > > > > > > > > > > >>Here we don't actually need ospfIfIpAddress and > > > > > ospfAddressLessIf. > > > > > > > > When we send TRAP > > > > > > > > > > >>notification, we can just send > > > > > > > > > > >>ospfIfState. > > > > > > > value>. . > > > > > > > > > > >>Also I am not sure why ospfRouterId is > > > included here. An > > > > > > > > > > >>NMS > > > > > station > > > > > > > > can always query ospfRouterId > > > > > > > > > > >>separately. By removing these MIB objects, we > > > can reduce > > > > > > > > > > >>the > > > > > size and > > > > > > > > processing time of TRAP > > > > > > > > > > >>messages considerably. > > > > > > > > > > >> > > > > > > > > > > >>Section : 4.3 Ignoring Initial Activity > > > > > > > > > > >>--------------------------------------- > > > > > > > > > > >>The section states "The majority of critical events > > > > > > > > > > >>occur > > > when > > > > > OSPF is > > > > > > > > enabled on a > > > > > > > > > > >>router, at which time the designated router > > > is elected > > > > > > > > > > >>and > > > > > neighbor > > > > > > > > adjacencies are formed" . > > > > > > > > > > >>I am not sure if enabling OSPF on a router means > > > > > > > > > > >>enabling it > > > on > > > > > an > > > > > > > > interface. I think it will > > > > > > > > > > >>be better to make the text clearer. > > > > > > > > > > >> > > > > > > > > > > >>Other statement is "To avoid unnecessary > > > traps, a router > > > should > > > > > not > > > > > > > > originate expected OSPF > > > > > > > > > > >>interface related traps until two of that interface's > > > > > > > > > > >>dead > > > timer > > > > > > > > intervals have elapsed." > > > > > > > > > > >>I think there will be some problems if the > > > dead interval > > > value > > > > > is too > > > > > > > > long. We may end up > > > > > > > > > > >>not sending any of the expected TRAPS for a > > > long time. > > > > > > > > > > >>Btw, > > > > > could I > > > > > > > > please know the reason > > > > > > > > > > >>for selecting 2 * dead interval value for > > > this purpose?. > > > There > > > > > might > > > > > > > > be some case where an > > > > > > > > > > >>interface is up and it goes down before (2 * dead > > > > > > > > > > >>interval). > > > We > > > > > can't > > > > > > > > take it as an 'expected > > > > > > > > > > >>event'. Probably we can ignore the expected > > > events till > > > > > > > > > > >>the > > > > > interface > > > > > > > > reaches terminal state > > > > > > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >>One more point is we are already limiting > > > > > > > > > > >>ospfIfStateChange, > > > > > > > > ospfVirtIfStateChange, > > > > > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange > > > > > > > > > > >>notifications > > > by > > > > > > > > generating them only for terminal > > > > > > > > > > >>state changes and backward tansition. Do we > > > really need > > > > > > > > > > >>to > > > > > ignore them > > > > > > > > during the initial activity?. > > > > > > > > > > >> > > > > > > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and > > > > > ospfOriginateLsa > > > > > > > > traps should not be originated > > > > > > > > > > >>until two dead timer intervals have elapsed where the > > > deadtimer > > > > > > > > interval used should be the dead > > > > > > > > > > >>timer with the smallest value." Here whats > > > the meaning > > > > > > > > > > >>of > > > "dead > > > > > timer > > > > > > > > with smallest value"? Is it > > > > > > > > > > >>the smallest interval value among all the interfaces? > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >>Section 4.4 Throttling Traps > > > > > > > > > > >>---------------------------- > > > > > > > > > > >>Do we need to provide MIB objects corresponding to > > > > > > > > > > >>window > > > size > > > > > and the > > > > > > > > number of TRAPs sent during > > > > > > > > > > >>the window time? Will the TRAPs other than > > > > > > > > > > >>ospfTxRetransmit, > > > > > > > > OrginateLsa and MaxAgeLsa really cause > > > > > > > > > > >>a TRAP flood? Probably we need to throttle only the > > > > > > > > > > >>above > > > three > > > > > TRAPS? > > > > > > > > > > >> > > > > > > > > > > >>I think the normal practice is to inform the > > > NMS using > > > > > > > > > > >>some > > > > > other > > > > > > > > notification at the end of a > > > > > > > > > > >>particular interval when the TRAPs are dropped like > > > > > > > > > > >>this, > > > "Trap > > > > > N > > > > > > > > dropped n times in an interval > > > > > > > > > > >>t". We can add some common extra paratmeters to these > > > > > notifications to > > > > > > > > facilitate the NMS to query > > > > > > > > > > >>the router to retrieve some values and find out whats > > > happening. > > > > > > > > > > >> > > > > > > > > > > >>ospfConfigErrorType > > > > > > > > > > >>------------------- > > > > > > > > > > >>Do we need an error type for duplicate router > > > id in the > > > received > > > > > > > > messages? Some times loop back > > > > > > > > > > >>address can be misconfigured. > > > > > > > > > > >> > > > > > > > > > > >>ospfSetTrap > > > > > > > > > > >>----------- > > > > > > > > > > >>The definition of this is little complicated. Any > > > > > > > > > > >>reasons > > > for > > > > > going > > > > > > > > for last bit to first. We think > > > > > > > > > > >>its better to redefine this MIB object like > > > this to make > > > > > > > > > > >>if > > > more > > > > > > > > clear. > > > > > > > > > > >> > > > > > > > > > > >> cospfSetTrap OBJECT-TYPE > > > > > > > > > > >> SYNTAX BITS { > > > > > > > > > > >> ifConfigError (0), > > > > > > > > > > >> virtIfConfigError (1), > > > > > > > > > > >> ospfNbrStateChange (2), > > > > > > > > > > >> . > > > > > > > > > > >> . > > > > > > > > > > >> . > > > > > > > > > > >> } > > > > > > > > > > >> MAX-ACCESS read-write > > > > > > > > > > >> STATUS current > > > > > > > > > > >> DESCRIPTION > > > > > > > > > > >> "A One-octet string serving as a > > > bit map for > > > > > > > > > > >> the trap events defined by the > > > OSPF traps in > > > > > > > > > > >> this MIB. This object is used to enable and > > > > > > > > > > >> disable specific OSPF traps > > > where a 1 > > > > > > > > > > >> in the corresponding bit field > > > represents > > > > > > > > > > >> enabled." > > > > > > > > > > >> ::= { cospfTrapControl 1 } > > > > > > > > > > >> > > > > > > > > > > >>This definition enables the NMS to interpret > > > the bit map > > > easily. > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >>ospfIfStateChange > > > > > > > > > > >>----------------- > > > > > > > > > > >> > > > > > > > > > > >>>From the definition it looks like this TRAP should be > > > generated > > > > > only > > > > > > > > for terminal states(when state > > > > > > > > > > >>progresses) and for backward transition. > > > Infact the name > > > > > > > > ospfIfStateChange simply suggests to > > > > > > > > > > >>generate TRAPs for all state transitions. The general > > > tendency > > > > > is to > > > > > > > > ignore the DESCRIPTION when > > > > > > > > > > >>"StateChange" is read and assume its for all the state > > > changes. > > > > > It > > > > > > > > might lead to wrong > > > > > > > > > > >>implementations. I think we can also follow > > > the approach > > > taken > > > > > in BGP > > > > > > > > MIB(rfc1657). > > > > > > > > > > >>There they have notifications like this, > > > > > > > > > > >> bgpEstablished NOTIFICATION-TYPE > > > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > > > >> bgpPeerState } > > > > > > > > > > >> STATUS current > > > > > > > > > > >> DESCRIPTION > > > > > > > > > > >> "The BGP > > > Established event > > > > > > > > > > >>is > > > > > generated > > > > > > > > when > > > > > > > > > > >> the BGP FSM enters the > > > ESTABLISHED > > > > > state." > > > > > > > > > > >> ::= { bgpTraps 1 } > > > > > > > > > > >> > > > > > > > > > > >> bgpBackwardTransition > > > NOTIFICATION-TYPE > > > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > > > >> bgpPeerState } > > > > > > > > > > >> STATUS current > > > > > > > > > > >> DESCRIPTION > > > > > > > > > > >> "The > > > BGPBackwardTransition > > > > > > > > > > >> Event > > > is > > > > > > > > generated > > > > > > > > > > >> when the BGP FSM > > > moves from > > > > > > > > > > >> a > > > higher > > > > > > > > numbered > > > > > > > > > > >> state to a lower numbered > > > state." > > > > > > > > > > >> ::= { bgpTraps 2 } > > > > > > > > > > >> > > > > > > > > > > >>Our suggestion is to maintain > > > ospfIfStateChange and use > > > > > > > > > > >>that > > > for > > > > > > > > monitoring all the states > > > > > > > > > > >>(some people may want that) and additionally have > > > notifications > > > > > > > > similar to the BGP notifications. > > > > > > > > > > >>Its also true with VirtIfStateChange, > > > NbrStateChange and > > > > > > > > VirtNbrStateChange. If somebody doesn't > > > > > > > > > > >>want to see ALL state TRAPS, they can suppress them by > > > turning > > > > > off the > > > > > > > > corresponding bit in > > > > > > > > > > >>ospfSetTrap. > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >>ospfNbrStateChange > > > > > > > > > > >>------------------ > > > > > > > > > > >>The DECRIPTION clause states > > > > > > > > > > >>"When an neighbor transitions from or to Full on > > > non-broadcast > > > > > > > > multi-access and broadcast > > > > > > > > > > >> networks, the trap should be generated by the > > > > > > > > > > >> designated > > > > > router. A > > > > > > > > designated router > > > > > > > > > > >>transitioning to Down will be noted by > > > > > > > > > > >>ospfIfStateChange." I think here the intention is to > > > > > > > > > > >>reduce the number of TRAPs > > > as > > > > > much as > > > > > > > > possible by making > > > > > > > > > > >>only DR sending out this TRAP for a subnet. > > > But there is > > > > > > > > > > >>a > > > > > possibility > > > > > > > > that osfpNbrStateChange > > > > > > > > > > >>notification is disabled on DR and enabled on > > > DR other > > > > > > > > > > >>or > > > BDR. > > > > > NMS > > > > > > > > won't receive TRAPs when > > > > > > > > > > >>NbrState becomes FULL in that case. There is > > > a problem > > > > > > > > > > >>with > > > the > > > > > second > > > > > > > > part of above statments > > > > > > > > > > >>as well. Suppose ospfIfStateChange is disabled on the > > > router, > > > > > then > > > > > > > > again NMS won't know when > > > > > > > > > > >>neighbor goes down. Probably its better to > > > remove these > > > > > > > > > > >>two > > > > > clauses. > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >>Support for sham links: > > > > > > > > > > >>----------------------- > > > > > > > > > > >>Are you going to provide support for sham > > > links? We may > > > > > > > > > > >>need > > > > > these > > > > > > > > tables and notifications, > > > > > > > > > > >>ShamLinkTable > > > > > > > > > > >>ShamLinkNbrTable > > > > > > > > > > >>ShamLinkStateChange notification > > > ShamLinkNbrStateChange > > > > > > > > > > >>notification > > > > > > > > > > > > > > > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 20 08:18:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16303 for ; Thu, 20 Mar 2003 08:18:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0093B8D3@cherry.ease.lsoft.com>; Thu, 20 Mar 2003 8:20:28 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668884 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 20 Mar 2003 08:20:28 -0500 Received: from 47.129.242.157 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Mar 2003 08:20:27 -0500 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2KDKNB23828 for ; Thu, 20 Mar 2003 08:20:23 -0500 (EST) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Mar 2003 08:20:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EEE3.70EE47EA" Message-ID: <6204FDDE129D364D8040A98BCCB290EF0440AB3E@zbl6c004.corpeast.baynetworks.com> Date: Thu, 20 Mar 2003 08:20:14 -0500 Reply-To: Mailing List Sender: Mailing List From: Daniel Joyal Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2EEE3.70EE47EA Content-Type: text/plain Hi Girish, Good to hear from you. The next-gen project here seems to be moving ahead with purpose. I has lots of visibility and, it appears, committment from the highest levels of management. It's too bad Lucent management can't make up it's mind about Telesto. Have they set up the development environment yet? Any other interesting rumors? -Dan -----Original Message----- From: Nair, Girish (Girish) [mailto:gnair@LUCENT.COM] Sent: Wednesday, March 19, 2003 6:00 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv2 MIB draft Hi Dan, Just wanted to say hello from the Telesto world. We are still in orbit aound Saturn deciding what to do :-) Have you settled down yet? Girish -----Original Message----- From: Daniel Joyal [mailto:djoyal@NORTELNETWORKS.COM] Sent: Wednesday, March 19, 2003 5:22 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv2 MIB draft Comments in-line below. -Dan > -----Original Message----- > From: Roy Jose [mailto:rojose@CISCO.COM ] > Sent: Wednesday, March 19, 2003 6:05 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPFv2 MIB draft > > > Thanks Manral, Acee. > > Let me point out the open issues here from the original > document I sent. Joyal, please let me know if you need any > clarifications. > > Support for multiple OSPF processes: > ----------------------------------- > > We raised this issue some time back in WG. Currently MIB > supports only one Router ID. Multiple processes can have > separate router IDs. It is also true with other MIB objects > like ospfExternLsaCount, ospfExternLsaCksumSum etc. The > solution we got was to use a separate MIB view for each > process. But I don't think it can be easily implemented. We > suggest to form a new table to group scalar objects related > to an OSPF process and have Process Id as its INDEX. We also > suggest to add Process Id as one of the INDICES of all > tables. [WG - John Flick] As far as finding a generic > solution for multiple instances of a MIB module, the standard > solution is to use contexts (note: this is not the same as a > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was > done in a somewhat ad-hoc way by using different community > names for each instance of the OSPF MIB. In SNMPv3, it is > more formally defined using the contextName. The Entity MIB > entLogicalTable (RFC 2737) provides information about what > contexts exist in an agent, and how to get to them. [OPEN > issue] I think we need to investigate on this and add a > section to the draft how it can be applied to OSPF MIB . > This issue is not unique to the OSPF MIBs. I would prefer to just reference the RFCs that deal with SNMP contexts that John Flick mentioned. > > MAX-ACCESS value for INDICES of TABLES: > -------------------------------------- > I see MAX-ACCESS value of all TABLEs are read-only. Normally > INDICES of a table are put as not-accesssible to reduce the > number of SNMP messages. When an SNMP GET or GETNEXT is > issued on a non-INDEX object, we can extract the values of > INDICES from the object ID returned. For example, let us > consider ospfAreaLsaCount. When we query the value for this, > we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1 > is the AreaId, which is the INDEX of the ospfAreaTable. We > can extract the INDICES of table like this even if they are > not-accessible. The tables like LsdbTable has many number of > INDICES and we can reduce the number of SNMP messages > considerably by changing them to not-accessible. > > [WG - John Flick] > You would have the same problem if you tried changing > MAX-ACCESS on the table indices (as was also suggested > below). Since a change to MAX-ACCESS of an existing object > is not allowed, you would need to deprecated the index > objects, which would require deprecating the tables that they > index. Changing to not-accessible is not required, since > SMIv2 allows read-only indices for MIB modules that were > translated from SMIv1 and therefore already had read-only > indices. The OSPFv2 MIB started life in RFC 1248 as an SMIv1 > MIB module, so this exception applies. > > [OPEN issue] > As I have pointed out earlier, by changing the INDICES we can > reduce the number of SNMP GETNEXT reponses sent by the > router considerably. The draft standard MIB is already widely > deployed. But we need to deprecate an existing MIB and add a > new version, when it is required. I feel if everyone thinks > what I pointed out is a big advantange, still we can go ahead > with this change. > > If the MAX-ACCESS of INDICES are put as read-only to include > them in the TRAP notification messages, they can be changed > as accessible-for-notify. Other approach to this is remove > the INDICES from TRAP notification messages. For example if > you take the case of IfStateChange TRAP, > > ospfIfStateChange NOTIFICATION-TYPE^M > OBJECTS { ospfRouterId, -- The originator of the trap^M > ospfIfIpAddress,^M > ospfAddressLessIf,^M > ospfIfState -- The new state^M > }^M > Here we don't actually need ospfIfIpAddress and > ospfAddressLessIf. When we send TRAP notification, we can > just send ospfIfState. value>. . > Also I am not sure why ospfRouterId is included here. An NMS > station can always query ospfRouterId separately. By removing > these MIB objects, we can reduce the size and processing time > of TRAP messages considerably. > > [OPEN issue] The above point is not addressed yet. > I think there would need to be a strong WG consensus that deprecating the entire MIB for this is worth it. > Section : 4.3 Ignoring Initial Activity > --------------------------------------- > > [OPEN issue] This is not addressed yet. > > The section states "The majority of critical events occur > when OSPF is enabled on a router, at which time the > designated router is elected and neighbor adjacencies are > formed" . I am not sure if enabling OSPF on a router means > enabling it on an interface. I think it will be better to > make the text clearer. > > Other statement is "To avoid unnecessary traps, a router > should not originate expected OSPF interface related traps > until two of that interface's dead timer intervals have > elapsed." I think there will be some problems if the dead > interval value is too long. We may end up not sending any of > the expected TRAPS for a long time. Btw, could I please know > the reason for selecting 2 * dead interval value for this > purpose?. There might be some case where an interface is up > and it goes down before (2 * dead interval). We can't take it > as an 'expected event'. Probably we can ignore the expected > events till the interface reaches terminal state (FULL or > 2WAY) for the first time after enabling OSPF. > > > One more point is we are already limiting ospfIfStateChange, > ospfVirtIfStateChange, ospfNbrStateChange and > ospfVirtNbrStateChange notifications by generating them only > for terminal state changes and backward tansition. Do we > really need to ignore them during the initial activity?. > > Other statement is "Additionally, ospfMaxAgeLsa and > ospfOriginateLsa traps should not be originated until two > dead timer intervals have elapsed where the deadtimer > interval used should be the dead timer with the smallest > value." Here whats the meaning of "dead timer with smallest > value"? Is it the smallest interval value among all the interfaces? > I think the intent of the original authors of the MIB was to give some guidelines (hence the wording "should not" rather than "must not") for when or when not to generate traps. I don't know how closely real world implementations follow these guidelines. > > Section 4.4 Throttling Traps > ---------------------------- > > [OPEN issue] This is not addressed yet. > > Do we need to provide MIB objects corresponding to window > size and the number of TRAPs sent during the window time? > Will the TRAPs other than ospfTxRetransmit, OrginateLsa and > MaxAgeLsa really cause a TRAP flood? Probably we need to > throttle only the above three TRAPS? > > I think the normal practice is to inform the NMS using some > other notification at the end of a particular interval when > the TRAPs are dropped like this, "Trap N dropped n times in > an interval t". We can add some common extra paratmeters to > these notifications to facilitate the NMS to query the router > to retrieve some values and find out whats happening. > > ospfConfigErrorType > ------------------- > > [OPEN issue] This is not addressed yet. > > Do we need an error type for duplicate router id in the > received messages? Some times loop back address can be misconfigured. Easy to add if required. > > ospfSetTrap > ----------- > > [OPEN issue] This is not addressed yet. > > The definition of this is little complicated. Any reasons for > going for last bit to first. We think its better to redefine > this MIB object like this to make if more clear. > > cospfSetTrap OBJECT-TYPE > SYNTAX BITS { > ifConfigError (0), > virtIfConfigError (1), > ospfNbrStateChange (2), > . > . > . > } > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "A One-octet string serving as a bit map for > the trap events defined by the OSPF traps in > this MIB. This object is used to enable and > disable specific OSPF traps where a 1 > in the corresponding bit field represents > enabled." > ::= { cospfTrapControl 1 } > > This definition enables the NMS to interpret the bit map easily. Changing to a non-equivalent syntax would require creation of a new object. > > > ospfIfStateChange > ----------------- > [OPEN issue] This is not addressed yet. > > From the definition it looks like this TRAP should be > generated only for terminal states(when state > progresses) and for backward transition. Infact the name > ospfIfStateChange simply suggests to generate TRAPs for all > state transitions. The general tendency is to ignore the > DESCRIPTION when "StateChange" is read and assume its for all > the state changes. It might lead to wrong implementations. I > think we can also follow the approach taken in BGP > MIB(rfc1657). There they have notifications like this, > bgpEstablished NOTIFICATION-TYPE > OBJECTS { bgpPeerLastError, > bgpPeerState } > STATUS current > DESCRIPTION > "The BGP Established event is > generated when > the BGP FSM enters the ESTABLISHED state." > ::= { bgpTraps 1 } > > bgpBackwardTransition NOTIFICATION-TYPE > OBJECTS { bgpPeerLastError, > bgpPeerState } > STATUS current > DESCRIPTION > "The BGPBackwardTransition Event > is generated > when the BGP FSM moves from a > higher numbered > state to a lower numbered state." > ::= { bgpTraps 2 } > > Our suggestion is to maintain ospfIfStateChange and use that > for monitoring all the states (some people may want that) and > additionally have notifications similar to the BGP > notifications. Its also true with VirtIfStateChange, > NbrStateChange and VirtNbrStateChange. If somebody doesn't > want to see ALL state TRAPS, they can suppress them by > turning off the corresponding bit in ospfSetTrap. > OK. Could you list the new BGP-like notifications for OSPF? > > ospfNbrStateChange > ------------------ > > [OPEN issue] This is not addressed yet. > > The DECRIPTION clause states > "When an neighbor transitions from or to Full on > non-broadcast multi-access and broadcast networks, the trap > should be generated by the designated router. A designated > router transitioning to Down will be noted by > ospfIfStateChange." I think here the intention is to reduce > the number of TRAPs as much as possible by making only DR > sending out this TRAP for a subnet. But there is a > possibility that osfpNbrStateChange notification is disabled > on DR and enabled on DR other or BDR. NMS won't receive TRAPs > when NbrState becomes FULL in that case. There is a problem > with the second part of above statments as well. Suppose > ospfIfStateChange is disabled on the router, then again NMS > won't know when neighbor goes down. Probably its better to > remove these two clauses. > > Thanks, > Roy > > > > "Manral, Vishwas" wrote: > > > > > > Dan Joyal is at present working on the OSPFv2 MIB. > > > > And the OSPFv3 MIB as well. > > > > > > Thanks, > > Acee > > > > > > Thanks, > > > Vishwas > > > > > > -----Original Message----- > > > From: Roy Jose [mailto:rojose@CISCO.COM ] > > > Sent: Tuesday, March 18, 2003 12:03 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: OSPFv2 MIB draft > > > > > > Hi Acee, > > > > > > I agree with you. Till it becomes a standard draft, > vendors have to > > > go > with > > > some proprietory MIB I guess. Btw, who is working on the > MIB update > > > currently? > > > > > > Thanks, > > > Roy > > > > > > > One small correction. > > > > > > > > Acee Lindem wrote: > > > > > > > > > > Roy, > > > > > > > > > > There are 3 reasons why I don't think Sham Links should be > > > > > included in this MIB udpate: > > > > > > > > > > 1. I don't think they are sufficiently specified in the > > > > > Internet Draft describing them. My experience > implementing > > > > > the Sham Link feature required some reverse > > > > > engineering (Consult RFC 1264 for specification > > > > > requirements). > > > > > 2. The document describing them is not an OSPF WG > > > > > document. In fact, it is not even an PPVPN > > > > > document (although it could become one). > > > > > 3. At some point, we have to close the door on adding > > > > > MIB variables that are in all the drafts that may or > > > > > may not ever reach draft standard status. If we don't > > > > ~~~~~~~~~~~~~~ > > > > Meant to say "proposed standard" here. > > > > > > > > > do this, we'll never finish the MIB update. > > > > > > > > > > Thanks, > > > > > Acee > > > > > > > > > > Roy Jose wrote: > > > > > > > > > > > > Thanks Jeff, Acee, Mani and John for your responses. How > > > > > > about > other > > > > > > points?:) > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "John Flick" > > > > > > To: > > > > > > Sent: Saturday, March 15, 2003 6:19 AM > > > > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > > > > > Yep, adding an index would require deprecating everything > > > > > > > and > > > starting > > > > > > over. > > > > > > > Since this is an existing, widely deployed, Draft > Standard > > > > > > > MIB, > this > > > > > > should > > > > > > > not be done lightly. > > > > > > > > > > > > > > You would have the same problem if you tried changing > > > > > > > MAX-ACCESS > on > > > the > > > > > > > table indices (as was also suggested below). > Since a change > > > > > > > to > > > MAX-ACCESS > > > > > > > of an existing object is not allowed, you would need to > deprecated > > > the > > > > > > index > > > > > > > objects, which would require deprecating the tables that > > > > > > > they > index. > > > > > > Changing > > > > > > > to not-accessible is not required, since SMIv2 allows > > > > > > > read-only > > > indices > > > > > > for > > > > > > > MIB modules that were translated from SMIv1 and therefore > already > > > had > > > > > > > read-only indices. The OSPFv2 MIB started life > in RFC 1248 > > > > > > > as > an > > > SMIv1 > > > > > > MIB > > > > > > > module, so this exception applies. > > > > > > > > > > > > How about tables which were added later?: > > > > > > ospfAreaAggregateTable, ExtLsdbTable, etc. My worry > is not if > > > > > > its allowed or not. I am trying to point out > the > > > extra > > > > > > processing routers and > > > > > > NMS have to do with the increased number of messages. > > > > > > > > > > > > > As far as finding a generic solution for multiple > instances > > > > > > > of a > MIB > > > > > > module, > > > > > > > the standard solution is to use contexts (note: > this is not > > > > > > > the > same > > > as a > > > > > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this > > > > > > > was > done > > > in a > > > > > > > somewhat ad-hoc way by using different community > names for > > > > > > > each > > > instance > > > > > > > of the OSPF MIB. In SNMPv3, it is more formally defined > > > > > > > using > the > > > > > > > contextName. The Entity MIB entLogicalTable (RFC 2737) > > > > > > > provides > > > > > > information > > > > > > > about what contexts exist in an agent, and how to get to > > > > > > > them. > > > > > > > > > > > > After having a glance at rfc2737, I also think this is the > > > > > > way. I > > > think we > > > > > > need to specify it clearly how it can be achieved using > > > entLogicalTable. For > > > > > > example, how we need to represent the SNMP > community string to > > > retrieve info > > > > > > from a particular routing instance. > > > > > > > > > > > > Thanks, > > > > > > Roy > > > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > Acee Lindem wrote: > > > > > > > > > > > > > > > > Roy, > > > > > > > > > > > > > > > > I can appreciate your points since our product supports > > > > > > > > both > > > multiple > > > > > > > > virtual router instances and multiple routing protocol > instances > > > > > > > > within a particular virtual router. However, I > think we'd > > > > > > > > essentially have to deprecate everything in the current > > > > > > > > MIB > and > > > define > > > > > > > > new tables in order to add OSPF instance ID as > an index. > > > > > > > > Can > > > someone > > > > > > > > who has more MIB definition experience comment? > > > > > > > > > > > > > > > > Additionally, the multiple instance problem is > not unique > > > > > > > > to > the > > > > > > > > OSPF MIB. Maybe a generic solution could be developed. > > > > > > > > > > > > > > > > Roy Jose wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I have some comments on > > > > > > > > > draft-ietf-ospf-mib-update-05.txt. I > > > would > > > > > > also like > > > > > > > > > to have some clarifications. Please see the attached > document. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Roy > > > > > > > > > > > > > > > > > > > > > > > > > > >>Yes. An update is in the works. > > > > > > > > >> > > > > > > > > >>-Dan > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>>-----Original Message----- > > > > > > > > >>>From: Banerjee, Gargi > > > > > > > > >>>[mailto:Gargi.Banerjee@MARCONI.COM ] > > > > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM > > > > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM > > > > > > > > >>>Subject: OSPFv2 MIB draft > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>>Hi all: > > > > > > > > >>>I would like to know the status of the working group > > > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft > > > > > > > > >>>shows > an > > > > > > > > >>>expiry date of > > > > > > > > >>>May 2001. > > > > > > > > >>>Is there any plan to update the draft ? > > > > > > > > >>> > > > > > > > > >>>Thanks > > > > > > > > >>>Gargi > > > > > > > > >>> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > >>------------------------------------------------------------ > ---------- > >>-- > > > > > > > > >> > > > > > > > > >>Support for multiple OSPF processes: > > > > > > > > >>----------------------------------- > > > > > > > > >> > > > > > > > > >>We raised this issue some time back in WG. > Currently MIB > > > supports only > > > > > > one Router ID. > > > > > > > > >>Multiple processes can have separate router > IDs. It is > > > > > > > > >>also > true > > > with > > > > > > other MIB objects > > > > > > > > >>like ospfExternLsaCount, > ospfExternLsaCksumSum etc. The > solution > > > we > > > > > > got was to use a > > > > > > > > >>separate MIB view for each process. But I > don't think it > > > > > > > > >>can > be > > > easily > > > > > > implemented. > > > > > > > > >>We suggest to form a new table to group scalar objects > related > > > to an > > > > > > OSPF process and have > > > > > > > > >>Process Id as its INDEX. We also suggest to > add Process > > > > > > > > >>Id > as > > > one of > > > > > > the INDICES of all > > > > > > > > >>tables. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>MAX-ACCESS value for INDICES of TABLES: > > > > > > > > >>-------------------------------------- > > > > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only. > > > > > > > > >>Normally > > > INDICES > > > > > > of a table are > > > > > > > > >>put as not-accesssible to reduce the number of SNMP > messages. > > > When an > > > > > > SNMP GET or > > > > > > > > >>GETNEXT is issued on a non-INDEX object, we > can extract > > > > > > > > >>the > > > values of > > > > > > INDICES from > > > > > > > > >>the object ID returned. For example, let us consider > > > ospfAreaLsaCount. > > > > > > When we query > > > > > > > > >>the value for this, we get something like > > > ospfAreaLsaCount.0.0.0.1, > > > > > > where 0.0.0.1 is > > > > > > > > >>the AreaId, which is the INDEX of the > ospfAreaTable. We > > > > > > > > >>can > > > extract > > > > > > the INDICES of > > > > > > > > >>table like this even if they are not-accessible. The > > > > > > > > >>tables > like > > > > > > LsdbTable has many > > > > > > > > >>number of INDICES and we can reduce the number of SNMP > messages > > > > > > considerably by changing > > > > > > > > >>them to not-accessible. > > > > > > > > >> > > > > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to > > > > > > > > >>include > > > them in > > > > > > the TRAP > > > > > > > > >>notification messages, they can be changed as > > > accessible-for-notify. > > > > > > Other approach to > > > > > > > > >>this is remove the INDICES from TRAP notification > > > > > > > > >>messages. > For > > > > > > example if you take the > > > > > > > > >>case of IfStateChange TRAP, > > > > > > > > >> > > > > > > > > >> ospfIfStateChange NOTIFICATION-TYPE^M > > > > > > > > >> OBJECTS { ospfRouterId, -- The > originator of the > trap^M > > > > > > > > >> ospfIfIpAddress,^M > > > > > > > > >> ospfAddressLessIf,^M > > > > > > > > >> ospfIfState -- The new state^M > > > > > > > > >> }^M > > > > > > > > >>Here we don't actually need ospfIfIpAddress and > > > ospfAddressLessIf. > > > > > > When we send TRAP > > > > > > > > >>notification, we can just send > > > > > > > > >>ospfIfState. > > > > > value>. . > > > > > > > > >>Also I am not sure why ospfRouterId is > included here. An > > > > > > > > >>NMS > > > station > > > > > > can always query ospfRouterId > > > > > > > > >>separately. By removing these MIB objects, we > can reduce > > > > > > > > >>the > > > size and > > > > > > processing time of TRAP > > > > > > > > >>messages considerably. > > > > > > > > >> > > > > > > > > >>Section : 4.3 Ignoring Initial Activity > > > > > > > > >>--------------------------------------- > > > > > > > > >>The section states "The majority of critical events > > > > > > > > >>occur > when > > > OSPF is > > > > > > enabled on a > > > > > > > > >>router, at which time the designated router > is elected > > > > > > > > >>and > > > neighbor > > > > > > adjacencies are formed" . > > > > > > > > >>I am not sure if enabling OSPF on a router means > > > > > > > > >>enabling it > on > > > an > > > > > > interface. I think it will > > > > > > > > >>be better to make the text clearer. > > > > > > > > >> > > > > > > > > >>Other statement is "To avoid unnecessary > traps, a router > should > > > not > > > > > > originate expected OSPF > > > > > > > > >>interface related traps until two of that interface's > > > > > > > > >>dead > timer > > > > > > intervals have elapsed." > > > > > > > > >>I think there will be some problems if the > dead interval > value > > > is too > > > > > > long. We may end up > > > > > > > > >>not sending any of the expected TRAPS for a > long time. > > > > > > > > >>Btw, > > > could I > > > > > > please know the reason > > > > > > > > >>for selecting 2 * dead interval value for > this purpose?. > There > > > might > > > > > > be some case where an > > > > > > > > >>interface is up and it goes down before (2 * dead > > > > > > > > >>interval). > We > > > can't > > > > > > take it as an 'expected > > > > > > > > >>event'. Probably we can ignore the expected > events till > > > > > > > > >>the > > > interface > > > > > > reaches terminal state > > > > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>One more point is we are already limiting > > > > > > > > >>ospfIfStateChange, > > > > > > ospfVirtIfStateChange, > > > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange > > > > > > > > >>notifications > by > > > > > > generating them only for terminal > > > > > > > > >>state changes and backward tansition. Do we > really need > > > > > > > > >>to > > > ignore them > > > > > > during the initial activity?. > > > > > > > > >> > > > > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and > > > ospfOriginateLsa > > > > > > traps should not be originated > > > > > > > > >>until two dead timer intervals have elapsed where the > deadtimer > > > > > > interval used should be the dead > > > > > > > > >>timer with the smallest value." Here whats > the meaning > > > > > > > > >>of > "dead > > > timer > > > > > > with smallest value"? Is it > > > > > > > > >>the smallest interval value among all the interfaces? > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>Section 4.4 Throttling Traps > > > > > > > > >>---------------------------- > > > > > > > > >>Do we need to provide MIB objects corresponding to > > > > > > > > >>window > size > > > and the > > > > > > number of TRAPs sent during > > > > > > > > >>the window time? Will the TRAPs other than > > > > > > > > >>ospfTxRetransmit, > > > > > > OrginateLsa and MaxAgeLsa really cause > > > > > > > > >>a TRAP flood? Probably we need to throttle only the > > > > > > > > >>above > three > > > TRAPS? > > > > > > > > >> > > > > > > > > >>I think the normal practice is to inform the > NMS using > > > > > > > > >>some > > > other > > > > > > notification at the end of a > > > > > > > > >>particular interval when the TRAPs are dropped like > > > > > > > > >>this, > "Trap > > > N > > > > > > dropped n times in an interval > > > > > > > > >>t". We can add some common extra paratmeters to these > > > notifications to > > > > > > facilitate the NMS to query > > > > > > > > >>the router to retrieve some values and find out whats > happening. > > > > > > > > >> > > > > > > > > >>ospfConfigErrorType > > > > > > > > >>------------------- > > > > > > > > >>Do we need an error type for duplicate router > id in the > received > > > > > > messages? Some times loop back > > > > > > > > >>address can be misconfigured. > > > > > > > > >> > > > > > > > > >>ospfSetTrap > > > > > > > > >>----------- > > > > > > > > >>The definition of this is little complicated. Any > > > > > > > > >>reasons > for > > > going > > > > > > for last bit to first. We think > > > > > > > > >>its better to redefine this MIB object like > this to make > > > > > > > > >>if > more > > > > > > clear. > > > > > > > > >> > > > > > > > > >> cospfSetTrap OBJECT-TYPE > > > > > > > > >> SYNTAX BITS { > > > > > > > > >> ifConfigError (0), > > > > > > > > >> virtIfConfigError (1), > > > > > > > > >> ospfNbrStateChange (2), > > > > > > > > >> . > > > > > > > > >> . > > > > > > > > >> . > > > > > > > > >> } > > > > > > > > >> MAX-ACCESS read-write > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "A One-octet string serving as a > bit map for > > > > > > > > >> the trap events defined by the > OSPF traps in > > > > > > > > >> this MIB. This object is used to enable and > > > > > > > > >> disable specific OSPF traps > where a 1 > > > > > > > > >> in the corresponding bit field > represents > > > > > > > > >> enabled." > > > > > > > > >> ::= { cospfTrapControl 1 } > > > > > > > > >> > > > > > > > > >>This definition enables the NMS to interpret > the bit map > easily. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>ospfIfStateChange > > > > > > > > >>----------------- > > > > > > > > >> > > > > > > > > >>>From the definition it looks like this TRAP should be > generated > > > only > > > > > > for terminal states(when state > > > > > > > > >>progresses) and for backward transition. > Infact the name > > > > > > ospfIfStateChange simply suggests to > > > > > > > > >>generate TRAPs for all state transitions. The general > tendency > > > is to > > > > > > ignore the DESCRIPTION when > > > > > > > > >>"StateChange" is read and assume its for all the state > changes. > > > It > > > > > > might lead to wrong > > > > > > > > >>implementations. I think we can also follow > the approach > taken > > > in BGP > > > > > > MIB(rfc1657). > > > > > > > > >>There they have notifications like this, > > > > > > > > >> bgpEstablished NOTIFICATION-TYPE > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > >> bgpPeerState } > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "The BGP > Established event > > > > > > > > >>is > > > generated > > > > > > when > > > > > > > > >> the BGP FSM enters the > ESTABLISHED > > > state." > > > > > > > > >> ::= { bgpTraps 1 } > > > > > > > > >> > > > > > > > > >> bgpBackwardTransition > NOTIFICATION-TYPE > > > > > > > > >> OBJECTS { bgpPeerLastError, > > > > > > > > >> bgpPeerState } > > > > > > > > >> STATUS current > > > > > > > > >> DESCRIPTION > > > > > > > > >> "The > BGPBackwardTransition > > > > > > > > >> Event > is > > > > > > generated > > > > > > > > >> when the BGP FSM > moves from > > > > > > > > >> a > higher > > > > > > numbered > > > > > > > > >> state to a lower numbered > state." > > > > > > > > >> ::= { bgpTraps 2 } > > > > > > > > >> > > > > > > > > >>Our suggestion is to maintain > ospfIfStateChange and use > > > > > > > > >>that > for > > > > > > monitoring all the states > > > > > > > > >>(some people may want that) and additionally have > notifications > > > > > > similar to the BGP notifications. > > > > > > > > >>Its also true with VirtIfStateChange, > NbrStateChange and > > > > > > VirtNbrStateChange. If somebody doesn't > > > > > > > > >>want to see ALL state TRAPS, they can suppress them by > turning > > > off the > > > > > > corresponding bit in > > > > > > > > >>ospfSetTrap. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>ospfNbrStateChange > > > > > > > > >>------------------ > > > > > > > > >>The DECRIPTION clause states > > > > > > > > >>"When an neighbor transitions from or to Full on > non-broadcast > > > > > > multi-access and broadcast > > > > > > > > >> networks, the trap should be generated by the > > > > > > > > >> designated > > > router. A > > > > > > designated router > > > > > > > > >>transitioning to Down will be noted by > > > > > > > > >>ospfIfStateChange." I think here the intention is to > > > > > > > > >>reduce the number of TRAPs > as > > > much as > > > > > > possible by making > > > > > > > > >>only DR sending out this TRAP for a subnet. > But there is > > > > > > > > >>a > > > possibility > > > > > > that osfpNbrStateChange > > > > > > > > >>notification is disabled on DR and enabled on > DR other > > > > > > > > >>or > BDR. > > > NMS > > > > > > won't receive TRAPs when > > > > > > > > >>NbrState becomes FULL in that case. There is > a problem > > > > > > > > >>with > the > > > second > > > > > > part of above statments > > > > > > > > >>as well. Suppose ospfIfStateChange is disabled on the > router, > > > then > > > > > > again NMS won't know when > > > > > > > > >>neighbor goes down. Probably its better to > remove these > > > > > > > > >>two > > > clauses. > > > > > > > > >> > > > > > > > > >> > > > > > > > > >>Support for sham links: > > > > > > > > >>----------------------- > > > > > > > > >>Are you going to provide support for sham > links? We may > > > > > > > > >>need > > > these > > > > > > tables and notifications, > > > > > > > > >>ShamLinkTable > > > > > > > > >>ShamLinkNbrTable > > > > > > > > >>ShamLinkStateChange notification > ShamLinkNbrStateChange > > > > > > > > >>notification > > > > > > > > > ------_=_NextPart_001_01C2EEE3.70EE47EA Content-Type: text/html Message
Hi Girish,
 
 Good to hear from you. The next-gen project here seems
to be moving ahead with purpose. I has lots of visibility
and, it appears, committment from the highest levels of
management.
 
 It's too bad Lucent management can't make up it's mind
about Telesto. Have they set up the development environment
yet? Any other interesting rumors?
 
-Dan
-----Original Message-----
From: Nair, Girish (Girish) [mailto:gnair@LUCENT.COM]
Sent: Wednesday, March 19, 2003 6:00 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: OSPFv2 MIB draft

Hi Dan,
 
Just wanted to say hello from the Telesto world.
We are still in orbit aound Saturn deciding what to do :-)
Have you settled down yet?
 
Girish
-----Original Message-----
From: Daniel Joyal [mailto:djoyal@NORTELNETWORKS.COM]
Sent: Wednesday, March 19, 2003 5:22 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: OSPFv2 MIB draft

Comments in-line below.

-Dan

> -----Original Message-----
> From: Roy Jose [mailto:rojose@CISCO.COM]
> Sent: Wednesday, March 19, 2003 6:05 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: OSPFv2 MIB draft
>
>
> Thanks Manral, Acee.
>
> Let me point out the open issues here from the original
> document I sent. Joyal, please let me know if you need any
> clarifications.
>
> Support for multiple OSPF processes:
> -----------------------------------
>
> We raised this issue some time back in WG. Currently MIB
> supports only one Router ID. Multiple processes can have
> separate router IDs. It is also true with other MIB objects
> like ospfExternLsaCount, ospfExternLsaCksumSum etc. The
> solution we got was to use a separate MIB view for each
> process. But I don't think it can be easily implemented. We
> suggest to form a new table to group scalar objects related
> to an OSPF process and have Process Id as its INDEX. We also
> suggest to add Process Id as one of the INDICES of all
> tables. [WG - John Flick] As far as finding a generic
> solution for multiple instances of a MIB module, the standard
> solution is to use contexts (note: this is not the same as a
> MIB view.  See RFC 3411, section 3.3.1).  In SNMPv1, this was
> done in a somewhat ad-hoc way by using different community
> names for each instance of the OSPF MIB.  In SNMPv3, it is
> more formally defined using the contextName.  The Entity MIB
> entLogicalTable (RFC 2737) provides information about what
> contexts exist in an agent, and how to get to them. [OPEN
> issue] I think we need to investigate on this and add a
> section to the draft how it can be applied to OSPF MIB .
>

This issue is not unique to the OSPF MIBs. I would prefer
to just reference the RFCs that deal with SNMP contexts that
John Flick mentioned.

>
> MAX-ACCESS value for INDICES of TABLES:
> --------------------------------------
> I see MAX-ACCESS value of all TABLEs are read-only. Normally
> INDICES of a table are put as not-accesssible to reduce the
> number of SNMP messages. When an SNMP GET or GETNEXT is
> issued on a non-INDEX object, we can extract the values of
> INDICES from the object ID returned. For example, let us
> consider ospfAreaLsaCount. When we query the value for this,
> we get something like ospfAreaLsaCount.0.0.0.1, where 0.0.0.1
> is the AreaId, which is the INDEX of the ospfAreaTable. We
> can extract the INDICES of table like this even if they are
> not-accessible. The tables like LsdbTable has many number of
> INDICES and we can reduce the number of SNMP messages
> considerably by changing them to not-accessible.
>
> [WG - John Flick]
> You would have the same problem if you tried changing
> MAX-ACCESS on the table indices (as was also suggested
> below).  Since a change to MAX-ACCESS of an existing object
> is not allowed, you would need to deprecated the index
> objects, which would require deprecating the tables that they
> index. Changing to not-accessible is not required, since
> SMIv2 allows read-only indices for MIB modules that were
> translated from SMIv1 and therefore already had read-only
> indices.  The OSPFv2 MIB started life in RFC 1248 as an SMIv1
> MIB module, so this exception applies.
>
> [OPEN issue]
> As I have pointed out earlier, by changing the INDICES we can
> reduce the number of  SNMP GETNEXT reponses sent by the
> router considerably. The draft standard MIB is already widely
> deployed. But we need to deprecate an existing MIB and add a
> new version, when it is required. I feel if everyone thinks
> what I pointed out is a big advantange, still we can go ahead
> with this change.
>
> If the MAX-ACCESS of INDICES are put as read-only to include
> them in the TRAP notification messages, they can be changed
> as accessible-for-notify. Other approach to this is remove
> the INDICES from TRAP notification messages. For example if
> you take the case of IfStateChange TRAP,
>
>    ospfIfStateChange NOTIFICATION-TYPE^M
>         OBJECTS { ospfRouterId, -- The originator of the trap^M
>            ospfIfIpAddress,^M
>            ospfAddressLessIf,^M
>            ospfIfState   -- The new state^M
>            }^M
> Here we don't actually need ospfIfIpAddress and
> ospfAddressLessIf. When we send TRAP notification, we can
> just send ospfIfState.<ospfIfIpAddress
> value>.<ospfAddressLessIf value> .
> Also I am not sure why ospfRouterId is included here. An NMS
> station can always query ospfRouterId separately. By removing
> these MIB objects, we can reduce the size and processing time
> of TRAP messages considerably.
>
> [OPEN issue] The above point is not addressed yet.
>

I think there would need to be a strong WG consensus that deprecating the
entire MIB for this is worth it.
 
> Section : 4.3 Ignoring Initial Activity
> ---------------------------------------
>
> [OPEN issue] This is not addressed yet.
>
> The section states "The majority of critical events occur
> when OSPF is enabled on a router, at which time the
> designated router is elected and neighbor adjacencies are
> formed" . I am not sure if enabling OSPF on a router means
> enabling it on an interface. I think it will be better to
> make the text clearer.
>
> Other statement is "To avoid unnecessary traps, a router
> should not originate expected OSPF interface related traps
> until two of that interface's dead timer intervals have
> elapsed." I think there will be some problems if the dead
> interval value is too long. We may end up not sending any of
> the expected TRAPS for a long time. Btw, could I please know
> the reason for selecting 2 * dead interval value for this
> purpose?. There might be some case where an interface is up
> and it goes down before (2 * dead interval). We can't take it
> as an 'expected event'. Probably we can ignore the expected
> events till the interface reaches terminal state (FULL or
> 2WAY) for the first time after enabling OSPF.
>
>
> One more point is we are already limiting ospfIfStateChange,
> ospfVirtIfStateChange, ospfNbrStateChange and
> ospfVirtNbrStateChange notifications by generating them only
> for terminal state changes and backward tansition. Do we
> really need to ignore them during the initial activity?.
>
> Other statement is "Additionally, ospfMaxAgeLsa and
> ospfOriginateLsa traps should not be originated until two
> dead timer intervals have elapsed where the deadtimer
> interval used should be the dead timer with the smallest
> value." Here whats the meaning of "dead timer with smallest
> value"? Is it the smallest interval value among all the interfaces?
>

I think the intent of the original authors of the MIB was
to give some guidelines (hence the wording "should not" rather
than "must not") for when or when not to generate traps. I don't
know how closely real world implementations follow these guidelines.

>
> Section 4.4 Throttling Traps
> ----------------------------
>
> [OPEN issue] This is not addressed yet.
>
> Do we need to provide MIB objects corresponding to window
> size and the number of TRAPs sent during the window time?
> Will the TRAPs other than ospfTxRetransmit, OrginateLsa and
> MaxAgeLsa really cause a TRAP flood? Probably we need to
> throttle only the above three TRAPS?
>
> I think the normal practice is to inform the NMS using some
> other notification at the end of a particular interval when
> the TRAPs are dropped like this, "Trap N dropped n times in
> an interval t". We can add some common extra paratmeters to
> these notifications to facilitate the NMS to query the router
> to retrieve some values and find out whats happening.
>
> ospfConfigErrorType
> -------------------
>
> [OPEN issue] This is not addressed yet.
>
> Do we need an error type for duplicate router id in the
> received messages? Some times loop back address can be misconfigured.

Easy to add if required.

>
> ospfSetTrap
> -----------
>
> [OPEN issue] This is not addressed yet.
>
> The definition of this is little complicated. Any reasons for
> going for last bit to first. We think its better to redefine
> this MIB object like this to make if more clear.
>
>   cospfSetTrap OBJECT-TYPE
>         SYNTAX BITS {
>                        ifConfigError (0),
>                        virtIfConfigError (1),
>                        ospfNbrStateChange (2),
>                           .
>                           .
>                           .
>                     }
>         MAX-ACCESS   read-write
>         STATUS   current
>         DESCRIPTION
>            "A One-octet string serving as a bit  map  for
>            the trap events defined by the OSPF traps in
>            this MIB. This object is used to enable and
>            disable  specific OSPF   traps   where  a  1
>            in  the  corresponding bit  field represents
>            enabled."
>        ::= { cospfTrapControl 1 }
>
> This definition enables the NMS to interpret the bit map easily.

Changing to a non-equivalent syntax would require creation of a new object.

>
>
> ospfIfStateChange
> -----------------
> [OPEN issue] This is not addressed yet.
>
> From the definition it looks like this TRAP should be
> generated only for terminal states(when state
> progresses) and for backward transition. Infact the name
> ospfIfStateChange simply suggests to generate TRAPs for all
> state transitions. The general tendency is to ignore the
> DESCRIPTION when "StateChange" is read and assume its for all
> the state changes. It might lead to wrong implementations. I
> think we can also follow the approach taken in BGP
> MIB(rfc1657). There they have notifications like this,
>                 bgpEstablished NOTIFICATION-TYPE
>                     OBJECTS { bgpPeerLastError,
>                               bgpPeerState      }
>                     STATUS  current
>                     DESCRIPTION
>                             "The BGP Established event is
> generated when
>                             the BGP FSM enters the ESTABLISHED state."
>                     ::= { bgpTraps 1 }
>
>                 bgpBackwardTransition NOTIFICATION-TYPE
>                     OBJECTS { bgpPeerLastError,
>                               bgpPeerState      }
>                     STATUS  current
>                     DESCRIPTION
>                             "The BGPBackwardTransition Event
> is generated
>                             when the BGP FSM moves from a
> higher numbered
>                             state to a lower numbered state."
>                     ::= { bgpTraps 2 }
>
> Our suggestion is to maintain ospfIfStateChange and use that
> for monitoring all the states (some people may want that) and
> additionally have notifications similar to the BGP
> notifications. Its also true with VirtIfStateChange,
> NbrStateChange and VirtNbrStateChange. If somebody doesn't
> want to see ALL state TRAPS, they can suppress them by
> turning off the corresponding bit in ospfSetTrap.
>

OK. Could you list the new BGP-like notifications for OSPF?

>
> ospfNbrStateChange
> ------------------
>
> [OPEN issue] This is not addressed yet.
>
> The DECRIPTION clause states
> "When an neighbor transitions from or to Full on
> non-broadcast multi-access and broadcast  networks, the trap
> should be generated  by the designated router. A designated
> router transitioning to Down will be noted by
> ospfIfStateChange." I think here the intention is to reduce
> the number of TRAPs as much as possible by making only DR
> sending out this TRAP for a subnet. But there is a
> possibility that osfpNbrStateChange notification is disabled
> on DR and enabled on DR other or BDR. NMS won't receive TRAPs
> when NbrState becomes FULL in that case. There is a problem
> with the second part of above statments as well. Suppose
> ospfIfStateChange is disabled on the router, then again NMS
> won't know when neighbor goes down. Probably its better to
> remove these two clauses.
>
> Thanks,
> Roy
>
>
> > "Manral, Vishwas" wrote:
> > >
> > > Dan Joyal is at present working on the OSPFv2 MIB.
> >
> > And the OSPFv3 MIB as well.
> >
> >
> > Thanks,
> > Acee
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Roy Jose [mailto:rojose@CISCO.COM]
> > > Sent: Tuesday, March 18, 2003 12:03 PM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: Re: OSPFv2 MIB draft
> > >
> > > Hi Acee,
> > >
> > > I agree with you. Till it becomes a standard draft,
> vendors have to
> > > go
> with
> > > some proprietory MIB I guess. Btw, who is working on the
> MIB update
> > > currently?
> > >
> > > Thanks,
> > > Roy
> > >
> > > > One small correction.
> > > >
> > > > Acee Lindem wrote:
> > > > >
> > > > > Roy,
> > > > >
> > > > > There are 3 reasons why I don't think Sham Links should be
> > > > > included in this MIB udpate:
> > > > >
> > > > >   1. I don't think they are sufficiently specified in the
> > > > >      Internet Draft describing them. My experience
> implementing
> > > > >      the Sham Link feature required some reverse
> > > > >      engineering (Consult RFC 1264 for specification
> > > > >      requirements).
> > > > >   2. The document describing them is not an OSPF WG
> > > > >      document. In fact, it is not even an PPVPN
> > > > >      document (although it could become one).
> > > > >   3. At some point, we have to close the door on adding
> > > > >      MIB variables that are in all the drafts that may or
> > > > >      may not ever reach draft standard status. If we don't
> > > >                           ~~~~~~~~~~~~~~
> > > >    Meant to say "proposed standard" here.
> > > >
> > > > >      do this, we'll never finish the MIB update.
> > > > >
> > > > > Thanks,
> > > > > Acee
> > > > >
> > > > > Roy Jose wrote:
> > > > > >
> > > > > > Thanks Jeff, Acee, Mani and John  for your responses.  How
> > > > > > about
> other
> > > > > > points?:)
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "John Flick" <johnf@ROSE.HP.COM>
> > > > > > To: <OSPF@DISCUSS.MICROSOFT.COM>
> > > > > > Sent: Saturday, March 15, 2003 6:19 AM
> > > > > > Subject: Re: OSPFv2 MIB draft
> > > > > >
> > > > > > > Yep, adding an index would require deprecating everything
> > > > > > > and
> > > starting
> > > > > > over.
> > > > > > > Since this is an existing, widely deployed, Draft
> Standard
> > > > > > > MIB,
> this
> > > > > > should
> > > > > > > not be done lightly.
> > > > > > >
> > > > > > > You would have the same problem if you tried changing
> > > > > > > MAX-ACCESS
> on
> > > the
> > > > > > > table indices (as was also suggested below). 
> Since a change
> > > > > > > to
> > > MAX-ACCESS
> > > > > > > of an existing object is not allowed, you would need to
> deprecated
> > > the
> > > > > > index
> > > > > > > objects, which would require deprecating the tables that
> > > > > > > they
> index.
> > > > > > Changing
> > > > > > > to not-accessible is not required, since SMIv2 allows
> > > > > > > read-only
> > > indices
> > > > > > for
> > > > > > > MIB modules that were translated from SMIv1 and therefore
> already
> > > had
> > > > > > > read-only indices.  The OSPFv2 MIB started life
> in RFC 1248
> > > > > > > as
> an
> > > SMIv1
> > > > > > MIB
> > > > > > > module, so this exception applies.
> > > > > >
> > > > > > How about tables which were added later?:
> > > > > > ospfAreaAggregateTable, ExtLsdbTable, etc. My worry
> is not if
> > > > > > its allowed or not. I am trying to point out
> the
> > > extra
> > > > > > processing routers and
> > > > > > NMS have to do with the increased number of messages.
> > > > > >
> > > > > > > As far as finding a generic solution for multiple
> instances
> > > > > > > of a
> MIB
> > > > > > module,
> > > > > > > the standard solution is to use contexts (note:
> this is not
> > > > > > > the
> same
> > > as a
> > > > > > > MIB view.  See RFC 3411, section 3.3.1).  In SNMPv1, this
> > > > > > > was
> done
> > > in a
> > > > > > > somewhat ad-hoc way by using different community
> names for
> > > > > > > each
> > > instance
> > > > > > > of the OSPF MIB.  In SNMPv3, it is more formally defined
> > > > > > > using
> the
> > > > > > > contextName.  The Entity MIB entLogicalTable (RFC 2737)
> > > > > > > provides
> > > > > > information
> > > > > > > about what contexts exist in an agent, and how to get to
> > > > > > > them.
> > > > > >
> > > > > > After having a glance at rfc2737, I also think this is the
> > > > > > way. I
> > > think we
> > > > > > need to specify it clearly how it can be achieved using
> > > entLogicalTable. For
> > > > > > example, how we need to represent the SNMP
> community string to
> > > retrieve info
> > > > > > from a particular routing instance.
> > > > > >
> > > > > > Thanks,
> > > > > > Roy
> > > > > >
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > Acee Lindem wrote:
> > > > > > > >
> > > > > > > > Roy,
> > > > > > > >
> > > > > > > > I can appreciate your points since our product supports
> > > > > > > > both
> > > multiple
> > > > > > > > virtual router instances and multiple routing protocol
> instances
> > > > > > > > within a particular virtual router. However, I
> think we'd
> > > > > > > > essentially have to deprecate everything in the current
> > > > > > > > MIB
> and
> > > define
> > > > > > > > new tables in order to add OSPF instance ID as
> an index.
> > > > > > > > Can
> > > someone
> > > > > > > > who has more MIB definition experience comment?
> > > > > > > >
> > > > > > > > Additionally, the multiple instance problem is
> not unique
> > > > > > > > to
> the
> > > > > > > > OSPF MIB. Maybe a generic solution could be developed.
> > > > > > > >
> > > > > > > > Roy Jose wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I have some comments on
> > > > > > > > > draft-ietf-ospf-mib-update-05.txt. I
> > > would
> > > > > > also like
> > > > > > > > > to have some clarifications. Please see the attached
> document.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Roy
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >>Yes. An update is in the works.
> > > > > > > > >>
> > > > > > > > >>-Dan
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>>-----Original Message-----
> > > > > > > > >>>From: Banerjee, Gargi
> > > > > > > > >>>[mailto:Gargi.Banerjee@MARCONI.COM]
> > > > > > > > >>>Sent: Monday, February 10, 2003 3:01 PM
> > > > > > > > >>>To: OSPF@DISCUSS.MICROSOFT.COM
> > > > > > > > >>>Subject: OSPFv2 MIB draft
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>Hi all:
> > > > > > > > >>>I would like to know the status of the working group
> > > > > > > > >>>draft-ietf-ospf-mib-update-05.txt. The current draft
> > > > > > > > >>>shows
> an
> > > > > > > > >>>expiry date of
> > > > > > > > >>>May 2001.
> > > > > > > > >>>Is there any plan to update the draft ?
> > > > > > > > >>>
> > > > > > > > >>>Thanks
> > > > > > > > >>>Gargi
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > >
> > > > > >
> > >
> >>------------------------------------------------------------
> ----------
> >>--
> > > > > > > > >>
> > > > > > > > >>Support for multiple OSPF processes:
> > > > > > > > >>-----------------------------------
> > > > > > > > >>
> > > > > > > > >>We raised this issue some time back in WG.
> Currently MIB
> > > supports only
> > > > > > one Router ID.
> > > > > > > > >>Multiple processes can have separate router
> IDs. It is
> > > > > > > > >>also
> true
> > > with
> > > > > > other MIB objects
> > > > > > > > >>like ospfExternLsaCount,
> ospfExternLsaCksumSum etc. The
> solution
> > > we
> > > > > > got was to use a
> > > > > > > > >>separate MIB view for each process. But I
> don't think it
> > > > > > > > >>can
> be
> > > easily
> > > > > > implemented.
> > > > > > > > >>We suggest to form a new table to group scalar objects
> related
> > > to an
> > > > > > OSPF process and have
> > > > > > > > >>Process Id as its INDEX. We also suggest to
> add Process
> > > > > > > > >>Id
> as
> > > one of
> > > > > > the INDICES of all
> > > > > > > > >>tables.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>MAX-ACCESS value for INDICES of TABLES:
> > > > > > > > >>--------------------------------------
> > > > > > > > >>I see MAX-ACCESS value of all TABLEs are read-only.
> > > > > > > > >>Normally
> > > INDICES
> > > > > > of a table are
> > > > > > > > >>put as not-accesssible to reduce the number of SNMP
> messages.
> > > When an
> > > > > > SNMP GET or
> > > > > > > > >>GETNEXT is issued on a non-INDEX object, we
> can extract
> > > > > > > > >>the
> > > values of
> > > > > > INDICES from
> > > > > > > > >>the object ID returned. For example, let us consider
> > > ospfAreaLsaCount.
> > > > > > When we query
> > > > > > > > >>the value for this, we get something like
> > > ospfAreaLsaCount.0.0.0.1,
> > > > > > where 0.0.0.1 is
> > > > > > > > >>the AreaId, which is the INDEX of the
> ospfAreaTable. We
> > > > > > > > >>can
> > > extract
> > > > > > the INDICES of
> > > > > > > > >>table like this even if they are not-accessible. The
> > > > > > > > >>tables
> like
> > > > > > LsdbTable has many
> > > > > > > > >>number of INDICES and we can reduce the number of SNMP
> messages
> > > > > > considerably by changing
> > > > > > > > >>them to not-accessible.
> > > > > > > > >>
> > > > > > > > >>If the MAX-ACCESS of INDICES are put as read-only to
> > > > > > > > >>include
> > > them in
> > > > > > the TRAP
> > > > > > > > >>notification messages, they can be changed as
> > > accessible-for-notify.
> > > > > > Other approach to
> > > > > > > > >>this is remove the INDICES from TRAP notification
> > > > > > > > >>messages.
> For
> > > > > > example if you take the
> > > > > > > > >>case of IfStateChange TRAP,
> > > > > > > > >>
> > > > > > > > >>   ospfIfStateChange NOTIFICATION-TYPE^M
> > > > > > > > >>        OBJECTS { ospfRouterId, -- The
> originator of the
> trap^M
> > > > > > > > >>           ospfIfIpAddress,^M
> > > > > > > > >>           ospfAddressLessIf,^M
> > > > > > > > >>           ospfIfState   -- The new state^M
> > > > > > > > >>           }^M
> > > > > > > > >>Here we don't actually need ospfIfIpAddress and
> > > ospfAddressLessIf.
> > > > > > When we send TRAP
> > > > > > > > >>notification, we can just send
> > > > > > > > >>ospfIfState.<ospfIfIpAddress
> > > > > > value>.<ospfAddressLessIf value> .
> > > > > > > > >>Also I am not sure why ospfRouterId is
> included here. An
> > > > > > > > >>NMS
> > > station
> > > > > > can always query ospfRouterId
> > > > > > > > >>separately. By removing these MIB objects, we
> can reduce
> > > > > > > > >>the
> > > size and
> > > > > > processing time of TRAP
> > > > > > > > >>messages considerably.
> > > > > > > > >>
> > > > > > > > >>Section : 4.3 Ignoring Initial Activity
> > > > > > > > >>---------------------------------------
> > > > > > > > >>The section states "The majority of critical events
> > > > > > > > >>occur
> when
> > > OSPF is
> > > > > > enabled on a
> > > > > > > > >>router, at which time the designated router
> is elected
> > > > > > > > >>and
> > > neighbor
> > > > > > adjacencies are formed" .
> > > > > > > > >>I am not sure if enabling OSPF on a router means
> > > > > > > > >>enabling it
> on
> > > an
> > > > > > interface. I think it will
> > > > > > > > >>be better to make the text clearer.
> > > > > > > > >>
> > > > > > > > >>Other statement is "To avoid unnecessary
> traps, a router
> should
> > > not
> > > > > > originate expected OSPF
> > > > > > > > >>interface related traps until two of that interface's
> > > > > > > > >>dead
> timer
> > > > > > intervals have elapsed."
> > > > > > > > >>I think there will be some problems if the
> dead interval
> value
> > > is too
> > > > > > long. We may end up
> > > > > > > > >>not sending any of the expected TRAPS for a
> long time.
> > > > > > > > >>Btw,
> > > could I
> > > > > > please know the reason
> > > > > > > > >>for selecting 2 * dead interval value for
> this purpose?.
> There
> > > might
> > > > > > be some case where an
> > > > > > > > >>interface is up and it goes down before (2 * dead
> > > > > > > > >>interval).
> We
> > > can't
> > > > > > take it as an 'expected
> > > > > > > > >>event'. Probably we can ignore the expected
> events till
> > > > > > > > >>the
> > > interface
> > > > > > reaches terminal state
> > > > > > > > >>(FULL or 2WAY) for the first time after enabling OSPF.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>One more point is we are already limiting
> > > > > > > > >>ospfIfStateChange,
> > > > > > ospfVirtIfStateChange,
> > > > > > > > >>ospfNbrStateChange and ospfVirtNbrStateChange
> > > > > > > > >>notifications
> by
> > > > > > generating them only for terminal
> > > > > > > > >>state changes and backward tansition. Do we
> really need
> > > > > > > > >>to
> > > ignore them
> > > > > > during the initial activity?.
> > > > > > > > >>
> > > > > > > > >>Other statement is "Additionally, ospfMaxAgeLsa and
> > > ospfOriginateLsa
> > > > > > traps  should not be originated
> > > > > > > > >>until two dead timer intervals have elapsed where the
> deadtimer
> > > > > > interval used should be the dead
> > > > > > > > >>timer with the smallest value." Here whats
> the meaning
> > > > > > > > >>of
> "dead
> > > timer
> > > > > > with smallest value"? Is it
> > > > > > > > >>the smallest interval value among all the interfaces?
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>Section 4.4 Throttling Traps
> > > > > > > > >>----------------------------
> > > > > > > > >>Do we need to provide MIB objects corresponding to
> > > > > > > > >>window
> size
> > > and the
> > > > > > number of TRAPs sent during
> > > > > > > > >>the window time? Will the TRAPs other than
> > > > > > > > >>ospfTxRetransmit,
> > > > > > OrginateLsa and MaxAgeLsa really cause
> > > > > > > > >>a TRAP flood? Probably we need to throttle only the
> > > > > > > > >>above
> three
> > > TRAPS?
> > > > > > > > >>
> > > > > > > > >>I think the normal practice is to inform the
> NMS using
> > > > > > > > >>some
> > > other
> > > > > > notification at the end of a
> > > > > > > > >>particular interval when the TRAPs are dropped like
> > > > > > > > >>this,
> "Trap
> > > N
> > > > > > dropped n times in an interval
> > > > > > > > >>t". We can add some common extra paratmeters to these
> > > notifications to
> > > > > > facilitate the NMS to query
> > > > > > > > >>the router to retrieve some values and find out whats
> happening.
> > > > > > > > >>
> > > > > > > > >>ospfConfigErrorType
> > > > > > > > >>-------------------
> > > > > > > > >>Do we need an error type for duplicate router
> id in the
> received
> > > > > > messages? Some times loop back
> > > > > > > > >>address can be misconfigured.
> > > > > > > > >>
> > > > > > > > >>ospfSetTrap
> > > > > > > > >>-----------
> > > > > > > > >>The definition of this is little complicated. Any
> > > > > > > > >>reasons
> for
> > > going
> > > > > > for last bit to first. We think
> > > > > > > > >>its better to redefine this MIB object like
> this to make
> > > > > > > > >>if
> more
> > > > > > clear.
> > > > > > > > >>
> > > > > > > > >>  cospfSetTrap OBJECT-TYPE
> > > > > > > > >>        SYNTAX BITS {
> > > > > > > > >>                       ifConfigError (0),
> > > > > > > > >>                       virtIfConfigError (1),
> > > > > > > > >>                       ospfNbrStateChange (2),
> > > > > > > > >>                          .
> > > > > > > > >>                          .
> > > > > > > > >>                          .
> > > > > > > > >>                    }
> > > > > > > > >>        MAX-ACCESS   read-write
> > > > > > > > >>        STATUS   current
> > > > > > > > >>        DESCRIPTION
> > > > > > > > >>           "A One-octet string serving as a
> bit  map  for
> > > > > > > > >>           the trap events defined by the
> OSPF traps in
> > > > > > > > >>           this MIB. This object is used to enable and
> > > > > > > > >>           disable  specific OSPF   traps  
> where  a  1
> > > > > > > > >>           in  the  corresponding bit  field
> represents
> > > > > > > > >>           enabled."
> > > > > > > > >>       ::= { cospfTrapControl 1 }
> > > > > > > > >>
> > > > > > > > >>This definition enables the NMS to interpret
> the bit map
> easily.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>ospfIfStateChange
> > > > > > > > >>-----------------
> > > > > > > > >>
> > > > > > > > >>>From the definition it looks like this TRAP should be
> generated
> > > only
> > > > > > for terminal states(when state
> > > > > > > > >>progresses) and for backward transition.
> Infact the name
> > > > > > ospfIfStateChange simply suggests to
> > > > > > > > >>generate TRAPs for all state transitions. The general
> tendency
> > > is to
> > > > > > ignore the DESCRIPTION when
> > > > > > > > >>"StateChange" is read and assume its for all the state
> changes.
> > > It
> > > > > > might lead to wrong
> > > > > > > > >>implementations. I think we can also follow
> the approach
> taken
> > > in BGP
> > > > > > MIB(rfc1657).
> > > > > > > > >>There they have notifications like this,
> > > > > > > > >>                bgpEstablished NOTIFICATION-TYPE
> > > > > > > > >>                    OBJECTS { bgpPeerLastError,
> > > > > > > > >>                              bgpPeerState      }
> > > > > > > > >>                    STATUS  current
> > > > > > > > >>                    DESCRIPTION
> > > > > > > > >>                            "The BGP
> Established event
> > > > > > > > >>is
> > > generated
> > > > > > when
> > > > > > > > >>                            the BGP FSM enters the
> ESTABLISHED
> > > state."
> > > > > > > > >>                    ::= { bgpTraps 1 }
> > > > > > > > >>
> > > > > > > > >>                bgpBackwardTransition
> NOTIFICATION-TYPE
> > > > > > > > >>                    OBJECTS { bgpPeerLastError,
> > > > > > > > >>                              bgpPeerState      }
> > > > > > > > >>                    STATUS  current
> > > > > > > > >>                    DESCRIPTION
> > > > > > > > >>                            "The
> BGPBackwardTransition
> > > > > > > > >> Event
> is
> > > > > > generated
> > > > > > > > >>                            when the BGP FSM
> moves from
> > > > > > > > >> a
> higher
> > > > > > numbered
> > > > > > > > >>                            state to a lower numbered
> state."
> > > > > > > > >>                    ::= { bgpTraps 2 }
> > > > > > > > >>
> > > > > > > > >>Our suggestion is to maintain
> ospfIfStateChange and use
> > > > > > > > >>that
> for
> > > > > > monitoring all the states
> > > > > > > > >>(some people may want that) and additionally have
> notifications
> > > > > > similar to the BGP notifications.
> > > > > > > > >>Its also true with VirtIfStateChange,
> NbrStateChange and
> > > > > > VirtNbrStateChange. If somebody doesn't
> > > > > > > > >>want to see ALL state TRAPS, they can suppress them by
> turning
> > > off the
> > > > > > corresponding bit in
> > > > > > > > >>ospfSetTrap.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>ospfNbrStateChange
> > > > > > > > >>------------------
> > > > > > > > >>The DECRIPTION clause states
> > > > > > > > >>"When an neighbor transitions from or to Full on
> non-broadcast
> > > > > > multi-access and broadcast
> > > > > > > > >> networks, the trap should be generated  by the
> > > > > > > > >> designated
> > > router. A
> > > > > > designated router
> > > > > > > > >>transitioning to Down will be noted by
> > > > > > > > >>ospfIfStateChange." I think here the intention is to
> > > > > > > > >>reduce the number of TRAPs
> as
> > > much as
> > > > > > possible by making
> > > > > > > > >>only DR sending out this TRAP for a subnet.
> But there is
> > > > > > > > >>a
> > > possibility
> > > > > > that osfpNbrStateChange
> > > > > > > > >>notification is disabled on DR and enabled on
> DR other
> > > > > > > > >>or
> BDR.
> > > NMS
> > > > > > won't receive TRAPs when
> > > > > > > > >>NbrState becomes FULL in that case. There is
> a problem
> > > > > > > > >>with
> the
> > > second
> > > > > > part of above statments
> > > > > > > > >>as well. Suppose ospfIfStateChange is disabled on the
> router,
> > > then
> > > > > > again NMS won't know when
> > > > > > > > >>neighbor goes down. Probably its better to
> remove these
> > > > > > > > >>two
> > > clauses.
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>Support for sham links:
> > > > > > > > >>-----------------------
> > > > > > > > >>Are you going to provide support for sham
> links? We may
> > > > > > > > >>need
> > > these
> > > > > > tables and notifications,
> > > > > > > > >>ShamLinkTable
> > > > > > > > >>ShamLinkNbrTable
> > > > > > > > >>ShamLinkStateChange notification
> ShamLinkNbrStateChange
> > > > > > > > >>notification
> > > > > >
> >
>

------_=_NextPart_001_01C2EEE3.70EE47EA-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 21 12:43:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20157 for ; Fri, 21 Mar 2003 12:43:44 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0093EE69@cherry.ease.lsoft.com>; Fri, 21 Mar 2003 12:45:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673178 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 21 Mar 2003 12:45:58 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Mar 2003 12:45:58 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 7AC86A6E484 for ; Fri, 21 Mar 2003 09:45:57 -0800 (PST) X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 References: <39469E08BD83D411A3D900204840EC5576353F@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E7B5134.73676DE7@redback.com> Date: Fri, 21 Mar 2003 12:51:48 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Venkata, I don't disagree with your recollection of the evolution of OSPFv2 opaque LSAs. It is my opinion (and that a large number of people I've spoken to) that opaque LSAs are unnecessary in OSPFv3 due to the inherent handling of unknown LSA types. I believe that identifying the application by the LSA type will actually make it more straight forward to export/import application data to/from another protocol. "Naidu, Venkata" wrote: > > -> . . . One of the main motivations for > -> the OSPFv2 opaque LSA was to solve the problem of how to get > -> LSAs flooded > -> w/o every router in the OSPF routing domain understanding all the > -> opaque LSAs types. In OSPFv3, flooding of unknown LSA types > -> is handled explicitly - this obviates the requirement for > -> opaque LSAs. > > I think I heard these misconception about opaque LSAs quite > few times now. Let me explain about the history of Opaque LSAs. > When Rob was here in this group, the main motivation was > to extend OSPF for the continuing extensions. Which he felt > must be done in a simple, elegant way (around May 1997 the first > draft was out). Along with Juha, Rob wrote first use of opaque > LSAs to resolve ATM addresses (which never standardized). > > The initial Opaque LSAs draft reads: > ... > As a result of this deployment and the evolution of networking > technology, OSPF has been extended to support many options; > this evolution will obviously continue. > > This memo documents enhancements to the OSPF protocol to support a new > type of link-state advertisement (LSA) called the Opaque LSA which > defines an optional generalized mechanism to allow for future extensi- > bility of OSPF. The information contained in Opaque LSAs may be used > directly by OSPF or by other protocols. > ^^^^^^^^^^^^^^^^^^ > For example, the OSPF LSA may be used to distribute BGP AS Path > information (as documented in The OSPF External Attributes LSA > which is then used by BGP route-leaking mechanisms. The option may > also be used to distribute IP QoS information which may be used > directly by an OSPF path computation. The exact use of the Opaque > LSA is beyond the scope of this draft. > ... > > The main motivation is not about OSPFv2 "flooding problems" because > other routers are not able to decode those LSAs. The main motivation > is "How best other protocols/applications can make use of OSPF > reliable flooding mechanisms instead of extending LSAs for each and > every applications requirements?". More over in v2, all the > LSAs are tightly encoded and difficult to piggyback the information. > OSPFv2 required some way of TLV encoded LSAs. > > Draw a "clear-cut line" between the *LSA types* which are being > used by OSPF for internal use (Hop-by-Hop Routing, flooding etc) > _and_ the LSAs which are not used by OSPF protocol at all. That > clear-cut line is named as "Opaque LSAs". > > I heard quite few times that other applications are re-using > parser code in OSPF etc etc...NO...the applications are using > the OSPF reliable flooding mechanism (which is somewhere in > between connection less IP/UDP/DCCP and connection oriented > TCP/SCTP) > > Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 21 13:32:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21866 for ; Fri, 21 Mar 2003 13:32:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0093F703@cherry.ease.lsoft.com>; Fri, 21 Mar 2003 13:34:21 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673670 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 21 Mar 2003 13:34:21 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Mar 2003 13:34:21 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 4C693436288 for ; Fri, 21 Mar 2003 10:34:20 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E7B5BE4.7060401@redback.com> Date: Fri, 21 Mar 2003 13:37:24 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: WG Last Call on draft-ietf-ospf-hitless-restart-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I only received one comment requesting for clarification during the WG last call. I plan to submit the document to the ADs after respinning the 07 version. 280a281 > to X, even though X's pre-start router-LSA did contain a 289d289 < to X, even though X's pre-start router-LSA did contain a 293,294c293,297 < reason (Section 3.2). < --- > reason (Section 3.2). A special case of LSA inconsistency > is when Router X establishes an adjacency with router Y > and doesn't receive an instance of its own pre-restart > router LSA. > 340d342 < 769a772,775 > Changes from 06 to 07 version: > > 1. Add clarification that a missing pre-restart LSA causes > the restarting router to terminate graceful restart. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 21 13:45:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22204 for ; Fri, 21 Mar 2003 13:45:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0093F77B@cherry.ease.lsoft.com>; Fri, 21 Mar 2003 13:47:26 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673717 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 21 Mar 2003 13:47:26 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Mar 2003 13:47:26 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09006 for ; Fri, 21 Mar 2003 13:47:23 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA29767 for ; Fri, 21 Mar 2003 13:47:25 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Mar 2003 13:47:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763550@vie-msgusr-01.dc.fore.com> Date: Fri, 21 Mar 2003 13:47:19 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: OSPFv3 Applications Support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -> I don't disagree with your recollection of the evolution of -> OSPFv2 opaque LSAs. It is my opinion (and that a large number -> of people I've spoken to) that opaque LSAs are unnecessary in -> OSPFv3 due to the inherent handling of unknown LSA types. Acee, I also don't disagree with wg consensus. :-) If the consensus is what you said for v3, let us follow. Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Sat Mar 22 03:03:27 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21875 for ; Sat, 22 Mar 2003 03:03:27 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00941B0B@cherry.ease.lsoft.com>; Sat, 22 Mar 2003 3:05:43 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 675966 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 22 Mar 2003 03:05:43 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 22 Mar 2003 03:05:43 -0500 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h2M8WwL13103 for ; Sat, 22 Mar 2003 14:02:58 +0530 Received: from apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with SMTP id h2M8WwX13097 for ; Sat, 22 Mar 2003 14:02:58 +0530 Received: from 203.124.147.65 (SquirrelMail authenticated user alok.dube) by mail.apara.com with HTTP; Sat, 22 Mar 2003 14:02:58 +0530 (IST) X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3538.203.124.147.65.1048321978.squirrel@mail.apara.com> Date: Sat, 22 Mar 2003 14:02:58 +0530 Reply-To: Mailing List Sender: Mailing List From: Alok Dube Subject: a doubt on SPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Hi, Assume I have 2 ABRs... Area 1 connects to Area 0 via ABR-1 and ABR-2. my questions are as follows. 1. will ABR-2 learn the route to Area 0 via ABR-1 (network LSA)...i think it should..correct? 2. if the path to a destination is better via ABR-2----(router in Area 1)--ABR-1---area 0 routers---(ABR of other Area), it will take this route..compared to ABR-2 -- area 0 routers ---(ABR of other Area)...am i correct? 3. if the destination was in Area 0 and the above condition again held true, there is no rule that a route learnt via type 1 lsa is given precedence over type 3? 3. Does OSPF ensure that routes learnt from a router are nevr sent back (split horizon types)...can someone point me to the part of RFC 2328 that states the same? or is the method implemented by means of simply checking the originator RID and discarding the LSA if it belongs to oneself? 4. if there are 2 ABRs, how will the LSAs originated by ABR-1 be treated by ABR-2? which section of the RFC deals with this?..is page 135 line 1 the answer?..but does the ABR itself use this LSA for its SPF calculations?(in a way this is same as case 1 above) thanks and rgds Alok From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 24 09:17:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19406 for ; Mon, 24 Mar 2003 09:17:04 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00944EB7@cherry.ease.lsoft.com>; Mon, 24 Mar 2003 9:19:21 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 680603 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 24 Mar 2003 09:19:21 -0500 Received: from 216.136.226.89 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Mar 2003 09:19:21 -0500 Received: from [203.200.20.226] by web20308.mail.yahoo.com via HTTP; Mon, 24 Mar 2003 06:19:20 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030324141920.30037.qmail@web20308.mail.yahoo.com> Date: Mon, 24 Mar 2003 06:19:20 -0800 Reply-To: Mailing List Sender: Mailing List From: Mareline Sheldon Subject: OOB Resynch To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Can i use OOB Resynch draft (along with link local signalling/etc) by Zinin for implementing graceful restart? If yes, then why do i need a separate graceful restart draft? Regards, Mareline S. __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 24 10:09:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21646 for ; Mon, 24 Mar 2003 10:09:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00944FC0@cherry.ease.lsoft.com>; Mon, 24 Mar 2003 10:12:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 680755 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 24 Mar 2003 10:12:03 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Mar 2003 10:12:03 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id C27A95EDD56 for ; Mon, 24 Mar 2003 07:12:01 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030324141920.30037.qmail@web20308.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E7F20D5.70403@redback.com> Date: Mon, 24 Mar 2003 10:14:29 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OOB Resynch To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mareline Sheldon wrote: Hello Mareline, > Hi, > Can i use OOB Resynch draft (along with link local signalling/etc) by Zinin for implementing > graceful restart? Not if you wish to interoperate with the IETF standard. > > If yes, then why do i need a separate graceful restart draft? The was the approach described in draft-ietf-ospf-hitless-restart-06.txt was chosen by the OSPF WG more than 2 years ago. Please check the OSPF list archives for more information. http://discuss.microsoft.com/archives/ospf.html > > Regards, > Mareline S. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! > http://platinum.yahoo.com > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 24 10:26:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22959 for ; Mon, 24 Mar 2003 10:26:03 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009450D9@cherry.ease.lsoft.com>; Mon, 24 Mar 2003 10:28:21 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 680792 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 24 Mar 2003 10:28:21 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Mar 2003 10:28:20 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 40C67962BAB for ; Mon, 24 Mar 2003 07:28:19 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3538.203.124.147.65.1048321978.squirrel@mail.apara.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E7F24A6.6070406@redback.com> Date: Mon, 24 Mar 2003 10:30:46 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: a doubt on SPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Alok Dube wrote: > Hi, Hi Alok, > > Assume I have 2 ABRs... > > Area 1 connects to Area 0 via ABR-1 and ABR-2. > > my questions are as follows. > > 1. will ABR-2 learn the route to Area 0 via ABR-1 (network LSA)...i think > it should..correct? ABR-2 should use it's intra-area path to routes in area 0. This question is a bit ambiguous due to the fact that there is no network diagram. > 2. if the path to a destination is better via ABR-2----(router in Area > 1)--ABR-1---area 0 routers---(ABR of other Area), it will take this > route..compared to ABR-2 -- area 0 routers ---(ABR of other Area)...am i > correct? OSPF Routers will prefer intra-area paths over inter-area paths. > 3. if the destination was in Area 0 and the above condition again held > true, there is no rule that a route learnt via type 1 lsa is given > precedence over type 3? See #2. > 3. Does OSPF ensure that routes learnt from a router are nevr sent back > (split horizon types)...can someone point me to the part of RFC 2328 that > states the same? or is the method implemented by means of simply checking > the originator RID and discarding the LSA if it belongs to oneself? This isn't needed for intra-area routes - the SPF calculation will ensure there is no looping. For generated summary advertisements, one doesn't advertise them back into the area corresponding to the route. > 4. if there are 2 ABRs, how will the LSAs originated by ABR-1 be treated > by ABR-2? which section of the RFC deals with this?..is page 135 line 1 > the answer?..but does the ABR itself use this LSA for its SPF > calculations?(in a way this is same as case 1 above) Read section 16.2 in RFC 2328. All the cases are covered. > thanks and rgds > Alok > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 24 11:04:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24162 for ; Mon, 24 Mar 2003 11:04:25 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0094515F@cherry.ease.lsoft.com>; Mon, 24 Mar 2003 11:06:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 680858 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 24 Mar 2003 11:06:42 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Mar 2003 11:06:42 -0500 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h2OGYfL20409 for ; Mon, 24 Mar 2003 22:04:41 +0530 Received: from apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with SMTP id h2OGYfX20403; Mon, 24 Mar 2003 22:04:41 +0530 Received: from 219.65.46.107 (SquirrelMail authenticated user alok.dube) by mail.apara.com with HTTP; Mon, 24 Mar 2003 22:04:41 +0530 (IST) References: <3538.203.124.147.65.1048321978.squirrel@mail.apara.com> <3E7F24A6.6070406@redback.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <1051.219.65.46.107.1048523681.squirrel@mail.apara.com> Date: Mon, 24 Mar 2003 22:04:41 +0530 Reply-To: Mailing List Sender: Mailing List From: Alok Dube Subject: Re: a doubt on SPF Comments: cc: acee@REDBACK.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E7F24A6.6070406@redback.com> Precedence: list Content-Transfer-Encoding: 8bit Hi Acee, thanks for your reply... maybe im a bit grey but ths thing is stil fuzzing me up... inline... > Alok Dube wrote: >> Hi, > > Hi Alok, > >> >> Assume I have 2 ABRs... >> >> Area 1 connects to Area 0 via ABR-1 and ABR-2. >> >> my questions are as follows. >> >> 1. will ABR-2 learn the route to Area 0 via ABR-1 (network LSA)...i >> think it should..correct? > > ABR-2 should use it's intra-area path to routes in area 0. This > question is a bit ambiguous due to the fact that there is no network > diagram. i dont have a diagram on hand, its basically a question as to why should "area boundarys" define the "shortest path".... > > >> 2. if the path to a destination is better via ABR-2----(router in Area >> 1)--ABR-1---area 0 routers---(ABR of other Area), it will take this >> route..compared to ABR-2 -- area 0 routers ---(ABR of other Area)...am >> i correct? > > OSPF Routers will prefer intra-area paths over inter-area paths. even if the inter area has a better SPF calculated metric from ABR-2?..thats strange...in a way, isnt it? > > >> 3. if the destination was in Area 0 and the above condition again held >> true, there is no rule that a route learnt via type 1 lsa is given >> precedence over type 3? > > > See #2. > >> 3. Does OSPF ensure that routes learnt from a router are nevr sent >> back (split horizon types)...can someone point me to the part of RFC >> 2328 that states the same? or is the method implemented by means of >> simply checking the originator RID and discarding the LSA if it >> belongs to oneself? > > This isn't needed for intra-area routes - the SPF calculation will > ensure there is no looping. For generated summary advertisements, one > doesn't advertise them back into the area corresponding to the route. fine, i saw the part on summary LSAs, and the fact that OSPF wont pass on routes which belong to an area back into the same area via another ABR... but on an ABR, would i use it?.... for example on the ABR-2, I have 2 interfaces, int-1 in Area 1 and int-2 in Area 0. Now if the router is a "datacentre" switch too, and is a next-hop for various servers to get to the other networks, shouldnt it use the better SPF path via ABR-1 to get to a destination...? > > >> 4. if there are 2 ABRs, how will the LSAs originated by ABR-1 be >> treated by ABR-2? which section of the RFC deals with this?..is page >> 135 line 1 the answer?..but does the ABR itself use this LSA for its >> SPF >> calculations?(in a way this is same as case 1 above) > > Read section 16.2 in RFC 2328. All the cases are covered. > 16.2 point 3 3) If it is a Type 3 summary-LSA, and the collection of destinations described by the summary-LSA equals one of the router's configured area address ranges (see Section 3.5), and the particular area address range is active, then the summary-LSA should be ignored. "Active" means that there are one or more reachable (by intra-area paths) networks contained in the area range. which means ignore it if its a route to area-0... if its a route to another area which is learnt via both area-0 and ABR-1 (area 1)........... then what? would : 4) Else, call the destination described by the LSA N (for Type 3 summary-LSAs, N's address is obtained by masking the LSA's Link State ID with the network/subnet mask contained in the body of the LSA), and the area border originating the LSA BR. Look up the routing table entry for BR having Area A as its associated area. If no such entry exists for router BR (i.e., BR is unreachable in Area A), do nothing with this LSA and consider the next in the list. Else, this LSA describes an inter-area path to destination N, whose cost is the distance to BR plus the cost specified in the LSA. Call the cost of this inter-area path IAC. will this come in here? or would it be as in 16.3 : 5) If this cost is less than the cost occurring in N's routing table entry, overwrite N's list of next hops with those used for BR, and set N's routing table cost to IAC. Else, if IAC is the same as N's current cost, add BR's list of next hops to N's list of next hops. In any case, the area associated with N's routing table entry must remain the backbone area, and the path type (either intra-area or inter-area) must also remain the same. ....isnt this a rule which primarily restricts OSPF from having "area in an area"? there are 2 things im trying to clarify 1. what tells SPF that "use the backbone route" 2. why can cant i simply have a "ring of areas" and no area 0? (bandwidth constraints/LSA flooding setaside for my drawing board model...). -rgds Alok From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 24 16:22:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04076 for ; Mon, 24 Mar 2003 16:22:27 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0094577F@cherry.ease.lsoft.com>; Mon, 24 Mar 2003 16:24:40 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 681672 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 24 Mar 2003 16:24:40 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Mar 2003 16:24:38 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id D3BDE4E9221; Mon, 24 Mar 2003 13:24:36 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3538.203.124.147.65.1048321978.squirrel@mail.apara.com> <3E7F24A6.6070406@redback.com> <1051.219.65.46.107.1048523681.squirrel@mail.apara.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E7F7824.7040101@redback.com> Date: Mon, 24 Mar 2003 16:27:00 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: a doubt on SPF Comments: To: alok.dube@apara.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Alok, See below - I attempted to answer the two questions at the end. Alok Dube wrote: > Hi Acee, > > thanks for your reply... > > maybe im a bit grey but ths thing is stil fuzzing me up... > > inline... > > >>Alok Dube wrote: >> >>>Hi, >> >>Hi Alok, >> >> >>>Assume I have 2 ABRs... >>> >>>Area 1 connects to Area 0 via ABR-1 and ABR-2. >>> >>>my questions are as follows. >>> >>>1. will ABR-2 learn the route to Area 0 via ABR-1 (network LSA)...i >>>think it should..correct? >> >>ABR-2 should use it's intra-area path to routes in area 0. This >>question is a bit ambiguous due to the fact that there is no network >>diagram. > > > i dont have a diagram on hand, its basically a question as to why should > "area boundarys" define the "shortest path".... > >> >>>2. if the path to a destination is better via ABR-2----(router in Area >>>1)--ABR-1---area 0 routers---(ABR of other Area), it will take this >>>route..compared to ABR-2 -- area 0 routers ---(ABR of other Area)...am >>>i correct? >> >>OSPF Routers will prefer intra-area paths over inter-area paths. > > > > even if the inter area has a better SPF calculated metric from > ABR-2?..thats strange...in a way, isnt it? > > >> >>>3. if the destination was in Area 0 and the above condition again held >>>true, there is no rule that a route learnt via type 1 lsa is given >>>precedence over type 3? >> >> >>See #2. >> >> >>>3. Does OSPF ensure that routes learnt from a router are nevr sent >>>back (split horizon types)...can someone point me to the part of RFC >>>2328 that states the same? or is the method implemented by means of >>>simply checking the originator RID and discarding the LSA if it >>>belongs to oneself? >> >>This isn't needed for intra-area routes - the SPF calculation will >>ensure there is no looping. For generated summary advertisements, one >>doesn't advertise them back into the area corresponding to the route. > > > > fine, i saw the part on summary LSAs, and the fact that OSPF wont pass on > routes which belong to an area back into the same area via another ABR... > but on an ABR, would i use it?.... > > for example on the ABR-2, I have 2 interfaces, int-1 in Area 1 and int-2 > in Area 0. > Now if the router is a "datacentre" switch too, and is a next-hop for > various servers to get to the other networks, shouldnt it use the better > SPF path via ABR-1 to get to a destination...? > > >> >>>4. if there are 2 ABRs, how will the LSAs originated by ABR-1 be >>>treated by ABR-2? which section of the RFC deals with this?..is page >>>135 line 1 the answer?..but does the ABR itself use this LSA for its >>>SPF >>>calculations?(in a way this is same as case 1 above) >> >>Read section 16.2 in RFC 2328. All the cases are covered. >> > > > > 16.2 point 3 > 3) If it is a Type 3 summary-LSA, and the collection of > destinations described by the summary-LSA equals one of the > router's configured area address ranges (see Section 3.5), > and the particular area address range is active, then the > summary-LSA should be ignored. "Active" means that there > are one or more reachable (by intra-area paths) networks > contained in the area range. > > > which means ignore it if its a route to area-0... > > if its a route to another area which is learnt via both area-0 and ABR-1 > (area 1)........... then what? > would : > 4) Else, call the destination described by the LSA N (for Type > 3 summary-LSAs, N's address is obtained by masking the LSA's > Link State ID with the network/subnet mask contained in the > body of the LSA), and the area border originating the LSA > BR. Look up the routing table entry for BR having Area A as > its associated area. If no such entry exists for router BR > (i.e., BR is unreachable in Area A), do nothing with this > LSA and consider the next in the list. Else, this LSA > describes an inter-area path to destination N, whose cost is > the distance to BR plus the cost specified in the LSA. Call > the cost of this inter-area path IAC. > > will this come in here? > > or would it be as in 16.3 : > > 5) If this cost is less than the cost occurring in N's routing > table entry, overwrite N's list of next hops with those used > for BR, and set N's routing table cost to IAC. Else, if IAC > is the same as N's current cost, add BR's list of next hops > to N's list of next hops. In any case, the area associated > with N's routing table entry must remain the backbone area, > and the path type (either intra-area or inter-area) must > also remain the same. > > ....isnt this a rule which primarily restricts OSPF from having "area in > an area"? > > there are 2 things im trying to clarify > > 1. what tells SPF that "use the backbone route" When you do your summary calculation, routers with multiple areas only consider backbone summaries (section 16.2). draft-ietf-ospf-abr-alt-05.txt allows summaries from multiple areas to be considered in situations where the router is detached from the backbone area. > 2. why can cant i simply have a "ring of areas" and no area 0? (bandwidth > constraints/LSA flooding setaside for my drawing board model...). The protocol as described in RFC 2328 affords deterministic and loop free operation between interoperating OSPF routers given the documented SPF route calculation (as described in section 16). The "ring of areas" topology is not supported by either RFC 2328 or draft-ietf-ospf-abr-alt-05.txt. If you want to design an OSPF network with multiple area your design MUST include a backbone area. Thanks, Acee > -rgds > Alok > > > > > > > > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 24 22:24:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16072 for ; Mon, 24 Mar 2003 22:24:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00946805@cherry.ease.lsoft.com>; Mon, 24 Mar 2003 22:26:28 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682612 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 24 Mar 2003 22:26:27 -0500 Received: from 156.153.255.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Mar 2003 22:26:27 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel11.hp.com (Postfix) with ESMTP id D42ED1C02015 for ; Mon, 24 Mar 2003 19:26:26 -0800 (PST) Received: from rose.hp.com (ros54018fli.rose.hp.com [15.29.17.171]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id TAA06467 for ; Mon, 24 Mar 2003 19:26:26 -0800 (PST) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <6204FDDE129D364D8040A98BCCB290EF0440AB3D@zbl6c004.corpeast.baynetworks.com> <0f6201c2eec7$6b0d46d0$9c8b4d0a@apac.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E7FCC5F.3E997628@rose.hp.com> Date: Mon, 24 Mar 2003 19:26:23 -0800 Reply-To: Mailing List Sender: Mailing List From: John Flick Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Roy, I do think it is probably a good idea to mention contexts and add a pointer to the Entity MIB. However, we need to be careful how far we go in specifying how multiple instances of OSPF are identified. In some routers, you can have multiple instances of OSPF that are feeding routes into a common FIB using administrative distance or some other preference mechanism to select a single route to each destination subnet from among the multiple instances. In this case, contexts that just identify the instance of OSPF are adequate. However, if you need to deal with the notion of a virtual router, where there could be multiple FIBs, you would probably want contexts that reference an entire virtual device, where one of the MIBs supported by that device is the OSPF MIB, but each virtual device probably has its own instance of the IP MIB, the FIB MIB, and whatever other MIBs that virtual device supports. In short, add a reference to the appropriate RFCs for contexts, but don't try to overspecify. As far as the trap message is concerned, with SNMPv3, the trap also carries a contextName which maps back to the context that generated the notification. For SNMPv1/SNMPv2c, you would use the same community in the trap message that you would use in a get or set to identify the instance. (However, we should be careful about spending too much time/text in this document talking about SNMPv1, since as of RFC 3410, it has been classified as historic.) Short answer: identify the OSPF instance in the trap the same way you do in the get/set message. John Roy Jose wrote: > > Hi Dan, > > Thanks. Please see inline. > > > Comments in-line below. > > > > -Dan > > > > > -----Original Message----- > > > From: Roy Jose [mailto:rojose@CISCO.COM] > > > Sent: Wednesday, March 19, 2003 6:05 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > Thanks Manral, Acee. > > > > > > Let me point out the open issues here from the original > > > document I sent. Joyal, please let me know if you need any > > > clarifications. > > > > > > Support for multiple OSPF processes: > > > ----------------------------------- > > > > > > We raised this issue some time back in WG. Currently MIB > > > supports only one Router ID. Multiple processes can have > > > separate router IDs. It is also true with other MIB objects > > > like ospfExternLsaCount, ospfExternLsaCksumSum etc. The > > > solution we got was to use a separate MIB view for each > > > process. But I don't think it can be easily implemented. We > > > suggest to form a new table to group scalar objects related > > > to an OSPF process and have Process Id as its INDEX. We also > > > suggest to add Process Id as one of the INDICES of all > > > tables. [WG - John Flick] As far as finding a generic > > > solution for multiple instances of a MIB module, the standard > > > solution is to use contexts (note: this is not the same as a > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was > > > done in a somewhat ad-hoc way by using different community > > > names for each instance of the OSPF MIB. In SNMPv3, it is > > > more formally defined using the contextName. The Entity MIB > > > entLogicalTable (RFC 2737) provides information about what > > > contexts exist in an agent, and how to get to them. [OPEN > > > issue] I think we need to investigate on this and add a > > > section to the draft how it can be applied to OSPF MIB . > > > > > > > This issue is not unique to the OSPF MIBs. I would prefer > > to just reference the RFCs that deal with SNMP contexts that > > John Flick mentioned. > > I would let John comment on this. Do we need to add any thing extra? My > point is different implementations should have the same behavior to avoid > interoperability issues. Also we need to think about modifying TRAP messages > to facilitate the NMS interpret the routing instance. Probably we can add a > new MIB object like OspfRoutingIstanceId to the notification messages. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 24 22:44:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16491 for ; Mon, 24 Mar 2003 22:44:34 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.009469F2@cherry.ease.lsoft.com>; Mon, 24 Mar 2003 22:46:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682671 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 24 Mar 2003 22:46:53 -0500 Received: from 156.153.255.206 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Mar 2003 22:46:52 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by atlrel8.hp.com (Postfix) with ESMTP id E7DEB1C01B64 for ; Mon, 24 Mar 2003 22:46:51 -0500 (EST) Received: from rose.hp.com (ros54018fli.rose.hp.com [15.29.17.171]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id TAA07896 for ; Mon, 24 Mar 2003 19:46:50 -0800 (PST) X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <0f4101c2eebd$ff078df0$9c8b4d0a@apac.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E7FD127.23C65654@rose.hp.com> Date: Mon, 24 Mar 2003 19:46:47 -0800 Reply-To: Mailing List Sender: Mailing List From: John Flick Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Roy, One datapoint is that the decision to make index objects not-accessible in SMIv2 has been somewhat controvertial. Many management app developers loathe having to parse out the indices from an OID. That said, I believe the issue you raise really only matters if you are dealing with a blind "get-next" sweep of a table. An application that is trying to upload this table could just as easily code its get-next requests to only ask for the columns it needs, e.g.: GETNEXT ospfLsdbSequence, ospfLsdbAge, ospfLsdbChecksum in a single request, then feed the OIDs it got from that request back into subsequent iterations. In other words, if the app doesn't want the indices, there is no need for it to ask for them. I am less interested in optimizing for a blind browser walk than I am in optimizing for a real monitoring application, and I don't think that optimizing that blind MIB walk is a very compelling reason for deprecating huge chunks of an existing, deployed MIB. As far as the rules for what is allowed in a MIB update are concerned, we could define any tables that are new in this update with not-accessible indices (e.g. the ospfLocalLsdbTable) if we are willing to tolerate the inconsistency with the rest of the MIB. But tables that were already published in RFC 1850 would need to be deprecated and new tables defined in order to change the MAX-ACCESS. RFC 2578, section 10 contains the detailed rules for what is allowed when updating a MIB module. There is a freely available tool called smidiff which will evaluate changes to a MIB module for legality. See http://www.ibr.cs.tu-bs.de/projects/libsmi/ John Roy Jose wrote: > > Hi Manral, > > Thanks. > > > Hi Roy, > > > > I reread the OSPF-MIB and the issues you have. Though I do not know SNMP > > well, I will try to let you know my view of things. > > > > 1. I think the issue of multiple instance support can be clarified in the > > MIB. > > > > 2. Though I did observe that even in the ISIS-MIB, the MAX-ACCESS for > > indicies is set to not-accesible, I am not sure we would want to deprecate > > all the tables to get the slight benefit of saving SNMP messages. > > I believe it can be a considerable benefit. Lets consider LsdbEntry where we > have four indices, > ospfLsdbAreaId, ospfLsdbType, ospfLsdbLsid and ospfLsdbRouterId . When we > try to access > entire Lsdb details on your router, you use a 'getmany' utility which issues > GETNEXT internally. This is what happens, > GETNEXT ospfLsdbTable : Response -> ospfLsdbAreaId.a1.t1.lsdbid1.rtrid1 = X. > GETNEXT ospfLsdbAreaId.a1.t1.lsdbid1.rtrid1 = X > : Response -> > ospfLsdbType.a1.t1.lsdbid1.rtrid1 = Y > GETNEXT ospfLsdbType.a1.t1.lsdbid1.rtrid1 : > : Response -> > ospfLsdbLsid.a1.t1.lsdbid1.rtrid1 = Z > GETNEXT ospfLsdbLsid.a1.t1.lsdbid1.rtrid1 : > : Response -> > ospfLsdbRouterId.a1.t1.lsdbid1.rtrid1 = A > GETNEXT ospfLsdbRouterId.a1.t1.lsdbid1.rtrid1 : > : Response -> > ospfLsdbSequence.a1.t1.lsdbid1.rtrid1 = B > . > . > If we can make the INDICES not-accessible, the first four messages need not > be sent. Suppose you have 100 entries, you save 400 messages. Probably we > can use GETBULK where you get N number of objects together. But its not > supported with SNMP v1. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 25 11:45:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20980 for ; Tue, 25 Mar 2003 11:45:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.009482C1@cherry.ease.lsoft.com>; Tue, 25 Mar 2003 11:48:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 684603 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Mar 2003 11:48:03 -0500 Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Mar 2003 11:48:03 -0500 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2PGm3FG008815 for ; Tue, 25 Mar 2003 09:48:03 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA20499 for ; Tue, 25 Mar 2003 09:47:55 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 11:47:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 25 Mar 2003 11:49:49 -0500 Reply-To: Mailing List Sender: Mailing List From: "Banwari, Amit" Subject: MIB v2 draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hello, I have a comment on draft-ietf-ospf-mib-update-05.txt. According to RFC 3101. "Like stub areas, NSSA border routers optionally import summary routes into their NSSAs as Type-3 summary-LSAs. If the import is disabled, particular care should be taken to ensure that summary routing is not obscured by an NSSA's Type-7 AS-external-LSAs. This may happen when the AS's other IGPs, like RIP and ISIS, leak routing information into the NSSA. In these cases all summary routes should be imported into the NSSA. The recommended default behavior is to import summary routes into NSSAs." but the draft-ietf-ospf-mib-update-05.txt as well as RFC 1850 states default behaviour for ospfAreaSummary as noAreaSummary. shouldn't the value in the MIB be changed to reflect values in the RFC3101. ospfAreaSummary OBJECT-TYPE SYNTAX INTEGER { noAreaSummary (1), sendAreaSummary (2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The variable ospfAreaSummary controls the im- port of summary LSAs into stub and NSSA areas. It has no effect on other areas. If it is noAreaSummary, the router will neither originate nor propagate summary LSAs into the stub or NSSA area. It will rely entirely on its default route. If it is sendAreaSummary, the router will both summarize and propagate summary LSAs." DEFVAL { noAreaSummary } ::= { ospfAreaEntry 9 } Thanks and Regards Amit Banwari From owner-ospf@DISCUSS.MICROSOFT.COM Tue Mar 25 11:47:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21077 for ; Tue, 25 Mar 2003 11:47:47 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.009482EF@cherry.ease.lsoft.com>; Tue, 25 Mar 2003 11:50:07 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 684633 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Mar 2003 11:50:06 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Mar 2003 11:50:06 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 3C5099A96C5 for ; Tue, 25 Mar 2003 08:50:05 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E808942.3010700@redback.com> Date: Tue, 25 Mar 2003 11:52:18 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: MIB v2 draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yes. Dan Joyal is in the process of updating this MIB. Banwari, Amit wrote: > Hello, > > I have a comment on draft-ietf-ospf-mib-update-05.txt. > > According to RFC 3101. > > "Like stub areas, NSSA border routers optionally import summary routes > into their NSSAs as Type-3 summary-LSAs. If the import is disabled, > particular care should be taken to ensure that summary routing is not > obscured by an NSSA's Type-7 AS-external-LSAs. This may happen when > the AS's other IGPs, like RIP and ISIS, leak routing information into > the NSSA. In these cases all summary routes should be imported into > the NSSA. The recommended default behavior is to import summary routes > into NSSAs." > > but the draft-ietf-ospf-mib-update-05.txt as well as RFC 1850 states default > behaviour for ospfAreaSummary as noAreaSummary. > > shouldn't the value in the MIB be changed to reflect values in the RFC3101. > ospfAreaSummary OBJECT-TYPE > SYNTAX INTEGER { > noAreaSummary (1), > sendAreaSummary (2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The variable ospfAreaSummary controls the im- > port of summary LSAs into stub and NSSA areas. > It has no effect on other areas. > > If it is noAreaSummary, the router will neither > originate nor propagate summary LSAs into the > stub or NSSA area. It will rely entirely on its > default route. > > If it is sendAreaSummary, the router will both > summarize and propagate summary LSAs." > DEFVAL { noAreaSummary } > ::= { ospfAreaEntry 9 } > > Thanks and Regards > Amit Banwari > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 26 05:25:00 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20449 for ; Wed, 26 Mar 2003 05:25:00 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0094B9FE@cherry.ease.lsoft.com>; Wed, 26 Mar 2003 5:27:18 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 688340 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Mar 2003 05:27:18 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Mar 2003 05:17:18 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0094BA02@cherry.ease.lsoft.com>; Wed, 26 Mar 2003 5:17:18 -0500 Message-ID: Date: Wed, 26 Mar 2003 05:17:18 -0500 Reply-To: Mailing List Sender: Mailing List From: Dror Dror Subject: MD5 various keys usage To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I've been trying to configure MD5 authentication using 2 Cisco routers. I noticed that I can configure more than one MD5 keys using the command: ip ospf message-digest md5 When I configured a few keys which are the same on both routers, I noticed that the 2 routers behave differently (I opened the debug ip ospf for logging). Initially (after enabling ospf on both routers), both of them sent thge HELLO packet with their youngest keys - which were different. Then, one router kept sending the youngest key, and the other send all keys for each OSPF packet. I also noticed that the router sending all the keys is the one which heard the HELLO packet first which was sent from the other router. Does any one understand why this is done, since each OSPF packet is replicated and sent for different keys. Thanks Dror From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 26 06:19:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21127 for ; Wed, 26 Mar 2003 06:19:20 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0094BBC1@cherry.ease.lsoft.com>; Wed, 26 Mar 2003 6:21:39 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 688639 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Mar 2003 06:21:39 -0500 Received: from 195.207.101.239 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Mar 2003 06:21:39 -0500 Received: from bemail05.net.alcatel.be (localhost [127.0.0.1]) by relay2.alcatel.be (8.10.1/8.11.4) with ESMTP id h2QBLU425415 for ; Wed, 26 Mar 2003 12:21:30 +0100 (MET) Received: from alcatel.be ([138.203.65.96]) by bemail05.net.alcatel.be (Lotus Domino Release 5.0.11) with ESMTP id 2003032612212759:3763 ; Wed, 26 Mar 2003 12:21:27 +0100 X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/26/2003 12:21:27, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 03/26/2003 12:21:30, Serialize complete at 03/26/2003 12:21:30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-ID: <3E818CF2.834009F2@alcatel.be> Date: Wed, 26 Mar 2003 12:20:18 +0100 Reply-To: Mailing List Sender: Mailing List From: Papadimitriou Dimitri Organization: optical network architecture (nta - antwerpen) Subject: link local signalling To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit folks, seeing that we are currently trying to look at ways to overcome options field limit, i would like to re- initiate the work on lls, i wonder if this item might be brought within the current re-charter *discussion* loop note: sorry for not having asked the question during the meeting, it had been adjourned before i had the time to jump from my seet thanks, - dimitri. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 26 06:52:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22163 for ; Wed, 26 Mar 2003 06:52:15 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0094BC05@cherry.ease.lsoft.com>; Wed, 26 Mar 2003 6:54:34 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 688693 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Mar 2003 06:54:33 -0500 Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Mar 2003 06:54:33 -0500 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2QBsXFG024090 for ; Wed, 26 Mar 2003 04:54:33 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA03512 for ; Wed, 26 Mar 2003 04:54:32 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 06:54:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 26 Mar 2003 06:56:13 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: link local signalling To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Dimitri, If I remember right, the draft was "delayed" looking for a valid application. Is there any new/specific application you have in mind for this? Thanks, Vishwas -----Original Message----- From: Papadimitriou Dimitri [mailto:Dimitri.Papadimitriou@ALCATEL.BE] Sent: Wednesday, March 26, 2003 4:50 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: link local signalling folks, seeing that we are currently trying to look at ways to overcome options field limit, i would like to re- initiate the work on lls, i wonder if this item might be brought within the current re-charter *discussion* loop note: sorry for not having asked the question during the meeting, it had been adjourned before i had the time to jump from my seet thanks, - dimitri. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 26 07:28:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23093 for ; Wed, 26 Mar 2003 07:28:43 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0094BBCB@cherry.ease.lsoft.com>; Wed, 26 Mar 2003 7:30:58 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 688765 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Mar 2003 07:30:56 -0500 Received: from 203.199.83.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Mar 2003 07:30:54 -0500 Received: (qmail 15038 invoked by uid 510); 26 Mar 2003 12:30:27 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 26 mar 2003 12:30:27 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030326123027.15037.qmail@webmail14.rediffmail.com> Date: Wed, 26 Mar 2003 12:30:27 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: NSSA ABR To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Suppose a router has two areas of which one is NSSA and the other is stub area. Does it qualify to be NSSA ABR and take part in NSSA Translator election ?? thanks, krishna On Mon, 24 Feb 2003 Krishna Rao wrote : >Hi, >Is there any difference between NSSA draft 11 and NSSA RFC 3101 >as per protocol functionality? >Or NSSA draft 11 is made into standard RFC 3101?? > >thanks, >krishna > > > >On Mon, 24 Feb 2003 Rohit Gupta wrote : >>Acee, >> > >> > Externally, origination should appear as the latter. >> > However, keep in mind that the only time flooding >> > can be suppressed is if an LSA is MaxAged while >> > waiting MinLSInterval to expire AND the sequence >> > number is the initial sequence number (0x80000001). >> >>And what if its not ISN. In my particular case it wont >>be! >> >>Theoretically i understand that the latter is the >>desired behaviour but do implementations actually do >>that when sending a MaxAge LSA (scan thru the Rxmt >>lists, etc and block the origination!) >> >> > >> > > >> > > Given the granularity of this timer (and maybe >> > some >> > > others too!) isnt it a little difficult to achieve >> > > sub-second convergence? >> > >> > This OSPF constant can delay convergence but it >> > is more a factor with router LSAs. For external >> > LSAs, >> > I think you want some holddown between originations >> > and I don't think 5 seconds is unreasonable. >> >>But this timer is applied for all the LSAs .. >>including the Router LSA. AS-External-LSA was just an >>example which i was taking .. >> >>Has anyone thought on these lines or is there some >>work which has been done over this. >> >>I for one would certainly be interested in knowing >>more about it. >> >>Regards, >>Rohit >> >> >> >> >> >>__________________________________________________ >>Do you Yahoo!? >>Yahoo! Tax Center - forms, calculators, tips, more >>http://taxes.yahoo.com/ _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 26 07:43:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24044 for ; Wed, 26 Mar 2003 07:43:37 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0094BD96@cherry.ease.lsoft.com>; Wed, 26 Mar 2003 7:45:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 688821 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Mar 2003 07:45:57 -0500 Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Mar 2003 07:45:57 -0500 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2QCjuFG008020 for ; Wed, 26 Mar 2003 05:45:57 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA18470 for ; Wed, 26 Mar 2003 05:45:56 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Mar 2003 07:45:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 26 Mar 2003 07:47:40 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: NSSA ABR To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Krishna, Interesting question !!!! It will not qualify for the translator election on other routers as E-bit cannot be set on an ABR, with an NSSA and a stub area into the stub area. The following statements are relevent: - " All NSSA border routers must set the E-bit in the Type-1 router-LSAs of their directly attached non-stub areas, even when they are not translating. This allows other NSSA border routers to see their ASBR status across the AS's transit topology. Failure to do so may cause the election algorithm to elect unnecessary translators. " besides " An NSSA border router whose NSSA's NSSATranslatorRole is set to Candidate must maintain a list of the NSSA's border routers that are reachable both over the NSSA and as ASBRs over the AS's transit topology. " So although the router becomes the translator(win the translator election on itself alone), it will not translate because it is attached to stub. Besides it will allow other ABR's to become translator as it will not qualify for their translator election. Thanks, Vishwas -----Original Message----- From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM] Sent: Wednesday, March 26, 2003 6:00 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: NSSA ABR Hi, Suppose a router has two areas of which one is NSSA and the other is stub area. Does it qualify to be NSSA ABR and take part in NSSA Translator election ?? thanks, krishna On Mon, 24 Feb 2003 Krishna Rao wrote : >Hi, >Is there any difference between NSSA draft 11 and NSSA RFC 3101 >as per protocol functionality? >Or NSSA draft 11 is made into standard RFC 3101?? > >thanks, >krishna > > > >On Mon, 24 Feb 2003 Rohit Gupta wrote : >>Acee, >> > >> > Externally, origination should appear as the latter. >> > However, keep in mind that the only time flooding >> > can be suppressed is if an LSA is MaxAged while >> > waiting MinLSInterval to expire AND the sequence >> > number is the initial sequence number (0x80000001). >> >>And what if its not ISN. In my particular case it wont >>be! >> >>Theoretically i understand that the latter is the >>desired behaviour but do implementations actually do >>that when sending a MaxAge LSA (scan thru the Rxmt >>lists, etc and block the origination!) >> >> > >> > > >> > > Given the granularity of this timer (and maybe >> > some >> > > others too!) isnt it a little difficult to achieve >> > > sub-second convergence? >> > >> > This OSPF constant can delay convergence but it >> > is more a factor with router LSAs. For external >> > LSAs, >> > I think you want some holddown between originations >> > and I don't think 5 seconds is unreasonable. >> >>But this timer is applied for all the LSAs .. >>including the Router LSA. AS-External-LSA was just an >>example which i was taking .. >> >>Has anyone thought on these lines or is there some >>work which has been done over this. >> >>I for one would certainly be interested in knowing >>more about it. >> >>Regards, >>Rohit >> >> >> >> >> >>__________________________________________________ >>Do you Yahoo!? >>Yahoo! Tax Center - forms, calculators, tips, more >>http://taxes.yahoo.com/ _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&w n From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 26 09:40:25 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27674 for ; Wed, 26 Mar 2003 09:40:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0094BF35@cherry.ease.lsoft.com>; Wed, 26 Mar 2003 9:42:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 689072 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Mar 2003 09:42:41 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Mar 2003 09:42:41 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 94022835F65 for ; Wed, 26 Mar 2003 06:42:39 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E81BCD8.9020506@redback.com> Date: Wed, 26 Mar 2003 09:44:40 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: MD5 various keys usage To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Dror Dror wrote: > Hi, > I've been trying to configure MD5 authentication using 2 Cisco routers. > I noticed that I can configure more than one MD5 keys using the command: > ip ospf message-digest md5 > > When I configured a few keys which are the same on both routers, I noticed > that the 2 routers behave differently (I opened the debug ip ospf for > logging). > > Initially (after enabling ospf on both routers), both of them sent thge > HELLO packet with their youngest keys - which were different. > Then, one router kept sending the youngest key, and the other send all keys > for each OSPF packet. > > I also noticed that the router sending all the keys is the one which heard > the HELLO packet first which was sent from the other router. > > Does any one understand why this is done, since each OSPF packet is > replicated and sent for different keys. Hi Dror, This is to support changing the key on multiple routers without losing the OSPF adjacencies (consider trying to change the key on all routers on a LAN simultaneously). Our product has similiar support utilizing a key chain. Thanks, Acee > > Thanks > Dror > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Mar 26 10:29:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00659 for ; Wed, 26 Mar 2003 10:29:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0094C2A4@cherry.ease.lsoft.com>; Wed, 26 Mar 2003 10:31:32 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 689342 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Mar 2003 10:31:31 -0500 Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Mar 2003 10:31:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 26 Mar 2003 10:31:29 -0500 Reply-To: Mailing List Sender: Mailing List From: Jeff Parker Subject: Re: MD5 various keys usage To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > > When I configured a few keys which are the same on both > routers, I noticed > > that the 2 routers behave differently > > Hi Dror, > > This is to support changing the key on multiple routers without > losing the OSPF adjacencies (consider trying to change the key on all > routers on a LAN simultaneously). Our product has similiar > support utilizing a key chain. > > Acee Adding multiple keys allows you to accept pkts with different keys at the same time. Different routers (and different code versions) might have different ways of expresing the following notions Which keys will be accepted? Which keys will be generated? To get the nice behavior Acee mentions, you need to be able to coordinate the switch from one key to the next. - jeff parker From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 27 04:00:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20526 for ; Thu, 27 Mar 2003 04:00:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0094E43E@cherry.ease.lsoft.com>; Thu, 27 Mar 2003 4:02:30 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 691450 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Mar 2003 04:02:30 -0500 Received: from 171.71.177.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Mar 2003 04:02:30 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2R92Q4c003522 for ; Thu, 27 Mar 2003 01:02:27 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id OAA05970 for ; Thu, 27 Mar 2003 14:28:48 +0530 (IST) References: <6204FDDE129D364D8040A98BCCB290EF0440AB3D@zbl6c004.corpeast.baynetworks.com> <0f6201c2eec7$6b0d46d0$9c8b4d0a@apac.cisco.com> <3E7FCC5F.3E997628@rose.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <1fb201c2f43f$476dcb50$9c8b4d0a@apac.cisco.com> Date: Thu, 27 Mar 2003 14:30:13 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi John, > Hi Roy, > > I do think it is probably a good idea to mention contexts and add a > pointer to the Entity MIB. However, we need to be careful how far we Right. Probably we can add a reference to section 3.3 of RFC 3411 as well where a picture shows multiple contexts for "bridge MIB" (Courtesey to Keith McCloghrie to point this out) > go in specifying how multiple instances of OSPF are identified. In > some routers, you can have multiple instances of OSPF that are feeding > routes into a common FIB using administrative distance or some other > preference mechanism to select a single route to each destination subnet > from among the multiple instances. In this case, contexts that just > identify the instance of OSPF are adequate. > > However, if you need to deal with the notion of a virtual router, where > there could be multiple FIBs, you would probably want contexts that > reference an entire virtual device, where one of the MIBs supported by > that device is the OSPF MIB, but each virtual device probably has its > own instance of the IP MIB, the FIB MIB, and whatever other MIBs that > virtual device supports. I think the above case also can be supported using ENTITY MIB where they can have multiple logical entities for entire MIB view relevant to the virtual router. > > In short, add a reference to the appropriate RFCs for contexts, but > don't try to overspecify. Right. A reference will do. > > As far as the trap message is concerned, with SNMPv3, the trap also > carries a contextName which maps back to the context that generated > the notification. For SNMPv1/SNMPv2c, you would use the same community > in the trap message that you would use in a get or set to identify > the instance. (However, we should be careful about spending too much > time/text in this document talking about SNMPv1, since as of RFC 3410, > it has been classified as historic.) Still we can mention about V1 and V2c for backward compatibility I guess. Thanks, Roy > > Short answer: identify the OSPF instance in the trap the same way you > do in the get/set message. > > John > > Roy Jose wrote: > > > > Hi Dan, > > > > Thanks. Please see inline. > > > > > Comments in-line below. > > > > > > -Dan > > > > > > > -----Original Message----- > > > > From: Roy Jose [mailto:rojose@CISCO.COM] > > > > Sent: Wednesday, March 19, 2003 6:05 PM > > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > > Subject: Re: OSPFv2 MIB draft > > > > > > > > > > > > Thanks Manral, Acee. > > > > > > > > Let me point out the open issues here from the original > > > > document I sent. Joyal, please let me know if you need any > > > > clarifications. > > > > > > > > Support for multiple OSPF processes: > > > > ----------------------------------- > > > > > > > > We raised this issue some time back in WG. Currently MIB > > > > supports only one Router ID. Multiple processes can have > > > > separate router IDs. It is also true with other MIB objects > > > > like ospfExternLsaCount, ospfExternLsaCksumSum etc. The > > > > solution we got was to use a separate MIB view for each > > > > process. But I don't think it can be easily implemented. We > > > > suggest to form a new table to group scalar objects related > > > > to an OSPF process and have Process Id as its INDEX. We also > > > > suggest to add Process Id as one of the INDICES of all > > > > tables. [WG - John Flick] As far as finding a generic > > > > solution for multiple instances of a MIB module, the standard > > > > solution is to use contexts (note: this is not the same as a > > > > MIB view. See RFC 3411, section 3.3.1). In SNMPv1, this was > > > > done in a somewhat ad-hoc way by using different community > > > > names for each instance of the OSPF MIB. In SNMPv3, it is > > > > more formally defined using the contextName. The Entity MIB > > > > entLogicalTable (RFC 2737) provides information about what > > > > contexts exist in an agent, and how to get to them. [OPEN > > > > issue] I think we need to investigate on this and add a > > > > section to the draft how it can be applied to OSPF MIB . > > > > > > > > > > This issue is not unique to the OSPF MIBs. I would prefer > > > to just reference the RFCs that deal with SNMP contexts that > > > John Flick mentioned. > > > > I would let John comment on this. Do we need to add any thing extra? My > > point is different implementations should have the same behavior to avoid > > interoperability issues. Also we need to think about modifying TRAP messages > > to facilitate the NMS interpret the routing instance. Probably we can add a > > new MIB object like OspfRoutingIstanceId to the notification messages. > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 27 04:25:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20891 for ; Thu, 27 Mar 2003 04:25:12 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0094E3E1@cherry.ease.lsoft.com>; Thu, 27 Mar 2003 4:27:29 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 691503 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Mar 2003 04:27:28 -0500 Received: from 171.71.177.254 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Mar 2003 04:27:27 -0500 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2R9RF9a024655 for ; Thu, 27 Mar 2003 01:27:24 -0800 (PST) Received: from ROJOSEW2K ([10.77.139.156]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id OAA09431 for ; Thu, 27 Mar 2003 14:55:49 +0530 (IST) References: <0f4101c2eebd$ff078df0$9c8b4d0a@apac.cisco.com> <3E7FD127.23C65654@rose.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <1fe701c2f443$0dbb4c80$9c8b4d0a@apac.cisco.com> Date: Thu, 27 Mar 2003 14:57:14 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi John, > Hi Roy, > > One datapoint is that the decision to make index objects not-accessible in SMIv2 > has been somewhat controvertial. Many management app developers loathe having > to parse out the indices from an OID. > > That said, I believe the issue you raise really only matters if you are dealing > with a blind "get-next" sweep of a table. An application that is trying to > upload this table could just as easily code its get-next requests to only > ask for the columns it needs, e.g.: But, I don't know howmany management applications would do it. Having said this, I agree this a very controversial point :) If WG is not confortable with deprecating all the tables, better not to do it. But as you say, it is a good idea to change the MAX-ACCESS values of the indices of new tables. I think inconistency here is not a big issue. Thanks, Roy > > GETNEXT ospfLsdbSequence, ospfLsdbAge, ospfLsdbChecksum > > in a single request, then feed the OIDs it got from that request back into > subsequent iterations. In other words, if the app doesn't want the indices, > there is no need for it to ask for them. I am less interested in optimizing > for a blind browser walk than I am in optimizing for a real monitoring > application, and I don't think that optimizing that blind MIB walk is a > very compelling reason for deprecating huge chunks of an existing, deployed > MIB. > > As far as the rules for what is allowed in a MIB update are concerned, we > could define any tables that are new in this update with not-accessible > indices (e.g. the ospfLocalLsdbTable) if we are willing to tolerate the > inconsistency with the rest of the MIB. But tables that were already > published in RFC 1850 would need to be deprecated and new tables defined > in order to change the MAX-ACCESS. RFC 2578, section 10 contains the > detailed rules for what is allowed when updating a MIB module. There is > a freely available tool called smidiff which will evaluate changes to > a MIB module for legality. See http://www.ibr.cs.tu-bs.de/projects/libsmi/ > > John > > Roy Jose wrote: > > > > Hi Manral, > > > > Thanks. > > > > > Hi Roy, > > > > > > I reread the OSPF-MIB and the issues you have. Though I do not know SNMP > > > well, I will try to let you know my view of things. > > > > > > 1. I think the issue of multiple instance support can be clarified in the > > > MIB. > > > > > > 2. Though I did observe that even in the ISIS-MIB, the MAX-ACCESS for > > > indicies is set to not-accesible, I am not sure we would want to deprecate > > > all the tables to get the slight benefit of saving SNMP messages. > > > > I believe it can be a considerable benefit. Lets consider LsdbEntry where we > > have four indices, > > ospfLsdbAreaId, ospfLsdbType, ospfLsdbLsid and ospfLsdbRouterId . When we > > try to access > > entire Lsdb details on your router, you use a 'getmany' utility which issues > > GETNEXT internally. This is what happens, > > GETNEXT ospfLsdbTable : Response -> ospfLsdbAreaId.a1.t1.lsdbid1.rtrid1 = X. > > GETNEXT ospfLsdbAreaId.a1.t1.lsdbid1.rtrid1 = X > > : Response -> > > ospfLsdbType.a1.t1.lsdbid1.rtrid1 = Y > > GETNEXT ospfLsdbType.a1.t1.lsdbid1.rtrid1 : > > : Response -> > > ospfLsdbLsid.a1.t1.lsdbid1.rtrid1 = Z > > GETNEXT ospfLsdbLsid.a1.t1.lsdbid1.rtrid1 : > > : Response -> > > ospfLsdbRouterId.a1.t1.lsdbid1.rtrid1 = A > > GETNEXT ospfLsdbRouterId.a1.t1.lsdbid1.rtrid1 : > > : Response -> > > ospfLsdbSequence.a1.t1.lsdbid1.rtrid1 = B > > . > > . > > If we can make the INDICES not-accessible, the first four messages need not > > be sent. Suppose you have 100 entries, you save 400 messages. Probably we > > can use GETBULK where you get N number of objects together. But its not > > supported with SNMP v1. > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 27 07:55:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26043 for ; Thu, 27 Mar 2003 07:55:46 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0094E81B@cherry.ease.lsoft.com>; Thu, 27 Mar 2003 7:58:06 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 691960 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Mar 2003 07:58:06 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Mar 2003 07:48:06 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25344; Thu, 27 Mar 2003 07:45:43 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200303271245.HAA25344@ietf.org> Date: Thu, 27 Mar 2003 07:45:43 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-ospfconv-applicability-02.txt Comments: cc: bmwg@ietf.org To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Benchmarking Applicability for Basic OSPF Convergence Author(s) : V. Manral, R. White, A. Shaikh Filename : draft-ietf-bmwg-ospfconv-applicability-02.txt Pages : 11 Date : 2003-3-26 This draft describes the applicability of [BENCHMARK] and similar work which may be done in the future. Refer to [TERM] for terminology used in this draft and [BENCHMARK]. The draft defines the advantages as well as limitations of using the method defined in [BENCHMARK], besides describing the pitfalls to avoid during measurement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-applicability-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-ospfconv-applicability-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-ospfconv-applicability-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-26122122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-ospfconv-applicability-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-ospfconv-applicability-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-26122122.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 27 07:55:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26062 for ; Thu, 27 Mar 2003 07:55:49 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0094E773@cherry.ease.lsoft.com>; Thu, 27 Mar 2003 7:58:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 691961 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Mar 2003 07:58:10 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Mar 2003 07:48:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25360; Thu, 27 Mar 2003 07:45:47 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200303271245.HAA25360@ietf.org> Date: Thu, 27 Mar 2003 07:45:47 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-ospfconv-intraarea-04.txt Comments: cc: bmwg@ietf.org To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Benchmarking Methodology for Basic OSPF Convergence Author(s) : V. Manral, R. White, A. Shaikh Filename : draft-ietf-bmwg-ospfconv-intraarea-04.txt Pages : 15 Date : 2003-3-26 This draft establishes standards for measuring OSPF convergence performance on a single router (SR-Convergence [4]). Its initial emphasis is on the control plane of single OSPF routers. We do not address forwarding plane performance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-intraarea-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-ospfconv-intraarea-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-ospfconv-intraarea-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-26122855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-ospfconv-intraarea-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-ospfconv-intraarea-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-26122855.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 27 07:55:54 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26086 for ; Thu, 27 Mar 2003 07:55:54 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0094E8D8@cherry.ease.lsoft.com>; Thu, 27 Mar 2003 7:58:15 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 691962 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Mar 2003 07:58:15 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Mar 2003 07:48:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25376; Thu, 27 Mar 2003 07:45:52 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200303271245.HAA25376@ietf.org> Date: Thu, 27 Mar 2003 07:45:52 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-ospfconv-term-03.txt Comments: cc: bmwg@ietf.org To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : OSPF Benchmarking Terminology and Concepts Author(s) : V. Manral, R. White, A. Shaikh Filename : draft-ietf-bmwg-ospfconv-term-03.txt Pages : 9 Date : 2003-3-26 This draft explains the terminology and concepts used in [BENCHMARK] and future OSPF benchmarking drafts, within the context of those drafts. While some of these terms may be defined elsewhere, and we will refer the reader to those definitions in some cases, we also include discussions concerning these terms as they relate specifically to the tasks involved in benchmarking the OSPF protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-term-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-ospfconv-term-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-ospfconv-term-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-26122907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-ospfconv-term-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-ospfconv-term-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-26122907.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 27 07:56:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26144 for ; Thu, 27 Mar 2003 07:56:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0094E7C2@cherry.ease.lsoft.com>; Thu, 27 Mar 2003 7:58:51 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 691965 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Mar 2003 07:58:51 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Mar 2003 07:48:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25511; Thu, 27 Mar 2003 07:46:29 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200303271246.HAA25511@ietf.org> Date: Thu, 27 Mar 2003 07:46:28 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-hitless-restart-07.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Graceful OSPF Restart Author(s) : J. Moy et al. Filename : draft-ietf-ospf-hitless-restart-07.txt Pages : 15 Date : 2003-3-26 This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called 'graceful restart' or 'non-stop forwarding'. A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-hitless-restart-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-hitless-restart-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-26123036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-hitless-restart-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-hitless-restart-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-26123036.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 27 12:53:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10214 for ; Thu, 27 Mar 2003 12:53:51 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0094F32A@cherry.ease.lsoft.com>; Thu, 27 Mar 2003 12:56:11 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 692663 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Mar 2003 12:56:11 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Mar 2003 12:56:10 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 44FF39F86BD; Thu, 27 Mar 2003 09:54:03 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200303271245.HAA25376@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E833B25.4090709@redback.com> Date: Thu, 27 Mar 2003 12:55:49 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-bmwg-ospfconv-term-03.txt Comments: cc: Tom Petch To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I believe this revision addresses Tom Petch's comments relating to the difference in terminolgy between this document and RFC 2328. Thanks, Acee Internet-Drafts@IETF.ORG wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Benchmarking Methodology Working Group of the IETF. > > Title : OSPF Benchmarking Terminology and Concepts > Author(s) : V. Manral, R. White, A. Shaikh > Filename : draft-ietf-bmwg-ospfconv-term-03.txt > Pages : 9 > Date : 2003-3-26 > > This draft explains the terminology and concepts used in [BENCHMARK] > and future OSPF benchmarking drafts, within the context of those > drafts. While some of these terms may be defined elsewhere, and we > will refer the reader to those definitions in some cases, we also > include discussions concerning these terms as they relate > specifically to the tasks involved in benchmarking the OSPF protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-term-03.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-bmwg-ospfconv-term-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-bmwg-ospfconv-term-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 27 14:15:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13616 for ; Thu, 27 Mar 2003 14:15:51 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0094F617@cherry.ease.lsoft.com>; Thu, 27 Mar 2003 14:18:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 692921 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Mar 2003 14:18:09 -0500 Received: from 207.159.120.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Mar 2003 14:18:09 -0500 Received: by xmxpita.excite.com (Postfix, from userid 110) id F230AB70C; Thu, 27 Mar 2003 14:18:05 -0500 (EST) Received: from [64.47.48.10] by xprdmailfe14.nwk.excite.com via HTTP; Thu, 27 Mar 2003 14:18:05 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20030327191805.F230AB70C@xmxpita.excite.com> Date: Thu, 27 Mar 2003 14:18:05 -0500 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit All, OK, here's my opinion (two cents please) and let me know if this would fly. For the current mib-update-nn file, only add additional attributes that are missing, and do no structural changes such as re-indexing, new tables, changes in max-access, etc. unless absolutely needed. Then get the thing done and published. Then start a new OSPFv2-MIB registered either under the existing "ospf" node, or under a completely new registration point from IANA. Then start this sucker from scratch. Do it once and do it right. Make the entire file SMIv2 compliant, add/modify/delete any tables that do not work, any traps that do not work, etc. Add an instance as an index to all tables (like in ISIS-MIB). Take all these discussion and comments and implement them once. Once done, we go back and deprecate the original OSPF-MIB file. Any takers, Don _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Thu Mar 27 22:50:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03117 for ; Thu, 27 Mar 2003 22:50:59 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00950651@cherry.ease.lsoft.com>; Thu, 27 Mar 2003 22:53:19 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 694621 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Mar 2003 22:53:19 -0500 Received: from 136.182.1.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Mar 2003 22:53:19 -0500 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2S3rOB6029183 for ; Thu, 27 Mar 2003 20:53:24 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id UAA25028 for ; Thu, 27 Mar 2003 20:53:04 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Mar 2003 22:52:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 27 Mar 2003 22:54:18 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: I-D ACTION:draft-ietf-bmwg-ospfconv-term-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee, You are right. This revision does address Tom Petch's comments, besides other changes suggested in the bmwg list. Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Thursday, March 27, 2003 11:26 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: I-D ACTION:draft-ietf-bmwg-ospfconv-term-03.txt I believe this revision addresses Tom Petch's comments relating to the difference in terminolgy between this document and RFC 2328. Thanks, Acee Internet-Drafts@IETF.ORG wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Benchmarking Methodology Working Group of the IETF. > > Title : OSPF Benchmarking Terminology and Concepts > Author(s) : V. Manral, R. White, A. Shaikh > Filename : draft-ietf-bmwg-ospfconv-term-03.txt > Pages : 9 > Date : 2003-3-26 > > This draft explains the terminology and concepts used in [BENCHMARK] > and future OSPF benchmarking drafts, within the context of those > drafts. While some of these terms may be defined elsewhere, and we > will refer the reader to those definitions in some cases, we also > include discussions concerning these terms as they relate > specifically to the tasks involved in benchmarking the OSPF protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-term-03.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-bmwg-ospfconv-term-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-bmwg-ospfconv-term-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 28 11:26:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05823 for ; Fri, 28 Mar 2003 11:26:02 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00951A6A@cherry.ease.lsoft.com>; Fri, 28 Mar 2003 11:28:12 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 696281 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 28 Mar 2003 11:28:12 -0500 Received: from 62.241.160.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 28 Mar 2003 11:28:11 -0500 Received: from tom3 (1Cust193.tnt14.lnd4.gbr.da.uu.net [62.188.143.193]) by colossus.systems.pipex.net (Postfix) with SMTP id 46EED1600032C for ; Fri, 28 Mar 2003 16:28:10 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <001001c2f546$8baecdc0$0301a8c0@tom3> Date: Fri, 28 Mar 2003 16:24:03 -0000 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: OSPF MIB role To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I am not clear what the purpose of this revision is and so find it hard to assess the changes. I appreciate that it is in the WG charter but why? I do agree with all the changes made but whether they go far enough or not depends on the objectives. In passing, Section 1 needs updating to reflect the new SNMP boiler plate; and should there be a mention of IP version number? IPv6 may be hitting us soon :-) and there is nothing here to say this is written in the days of IPv4 only. (eg IpAddress syntax) And should this provoke a thread, please start snipping before the e-mails get to 100KByte - my virus detection assumes anything over 50K must be an attack! Tom Petch nwnetworks@dial.pipex.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 28 14:31:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13622 for ; Fri, 28 Mar 2003 14:31:58 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00951DFC@cherry.ease.lsoft.com>; Fri, 28 Mar 2003 14:32:38 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 696811 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 28 Mar 2003 14:32:38 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 28 Mar 2003 14:32:37 -0500 Received: (qmail 15701 invoked from network); 28 Mar 2003 19:32:37 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 28 Mar 2003 19:32:37 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id OAA29659 for ; Fri, 28 Mar 2003 14:32:37 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-10306016700" Message-ID: <200303281932.OAA29659@bigbird.xebeo.com> Date: Fri, 28 Mar 2003 14:32:37 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: ietf 56 ospf wg meeting minutes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multipart MIME message. --==_Exmh_-10306016700 Content-Type: text/plain; charset=us-ascii Attached. Many thanks to Dimitri for putting these together! --rohit. --==_Exmh_-10306016700 Content-Type: text/plain ; name="ospf_minutes.txt"; charset=us-ascii Content-Description: ospf_minutes.txt Content-Disposition: attachment; filename="ospf_minutes.txt" Open Shortest Path First WG (ospf) Monday, March 17 (13:00 - 15:00) ================================ Reported by: Dimitri Papadimitriou CHAIRS: Rohit Dube Acee Lindem AGENDA: Agenda Bashing 5 Mins MIB Update 10 Mins Dan Joyal OSPF as the PE/CE Protocol in BGP/MPLS VPNs 10 Mins Eric Rosen Support of address families in OSPFv3 15 Mins Abhay Roy WG document status 10 Mins Chairs WG Charter Update 15 Mins Chairs --------------------------------------------------------------------------------- Meeting minutes: ================ Agenda Bashing 5 Mins --------------------------------------------------------------------------------- 1) MIB Update (10 Mins): Dan Joyal (Acee Lindem) OSPF MIB Status (Dan Joyal, discussed by Acee Lindem) o OSPFv2 MIB: Latest version -05.txt (Nov'00) Pending updates: - Add support for Graceful Restart - Add General group object for configuring reference bandwidth - Change General group object ospfOpaqueLsaSupport MAX-ACCESS from read-write to read-only - Deprecate ospfExtLsdbTable and add ospfAsLsdbTable - Add external route tag object to ospfAreaAggregateTable for NSSA (RFC 3101) - Add configuration support for detecting inactive neighbors over DC - Change status of RFC 1850 compliance and conformance groups to current Acee Lindem: respond and then WG last call (before the next ietf meeting) o OSPFv3 MIB: Lastest revision is -05 (Apr'02) Pending updates: - Add support for Graceful Restart - Add General group object for configuring reference bandwidth - Add General group counter object for External LSAs (for database overload) - Add external route tag object to ospfv3AreaAggregateTable for NSSA - Add configuration support for detecting inactive neighbors over DC - Add instance ID object to virtual interface entry - Remove LSA type enumerations from LSDB tables because OSPFv3 supports unrecognized LSA types - Add object to LSDB table to indicate whether the LSA is locally recognized Acee Lindem: respond and then WG last call (before the next ietf meeting) --------------------------------------------------------------------------------- 2) OSPF as the PE/CE Protocol in BGP/MPLS VPNs (10 Mins): Eric Rosen Summary: ------- o Overview: Scenario (Customer with multiple OSPF sites) - Service Provider connects sites over a shared backbone - Not with tunnels but by using BGP to distribute customer routes from site to site - Use of BGP is transprent to customer, SP converts BGP routes to OSPF (type 3, usually) o Topology view (see slides, discussing CE and PE definitions) Note: Eric also explains the problem under consideration, the difference betweeen BGP and OSPF (no ASPath send accross CE-PE link) defining the need for loopfree exchanges. o Route Distributions: - PE -> CE: Type 5 LSA (ASBR): use tag for avoiding looping - PE -> CE: Type 3 LSA : LSAs can start to loop around => Looping can happen with LSA Type 5, or with LSA Type 3 exchanged over PE-CE area 0 links. o Proposed Solution (to prevent from looping) - LSA Options field bit set when PE sends LSA's to CE - Do not generate BGP updates when PE receives LSA's from CE with bit set Discussions: ----------- - Acee Lindem: we have now 3 methods for loop avoidance: Route Tag, DN Bit and for Intra-Area link (sham links) - Eric Rosen: sham links is the preferred method (in addition to DN bit) - Acee Lindem: Thus we would have two preferred methods: DN bit and sham links ? - Eric Rosen: For Type3/5 DN bit applies and this without impacting the OSPF protocol but it would have been better to have only one mechanism - Acee Lindem: The DN bit proposal will be revisited during the OSPF WG charter discussion (note: see also below) --------------------------------------------------------------------------------- 3) Support of Address Families in OSPFv3 (15 Mins): Abhay Roy Summary: ------- o Overview: - What do we have today in OSPFv3 specification - What does this draft propose - What does this draft introduce - Introduction of the capability in OSPFv3 - Interaction with non-AF capable routers - Conclusion o Problem Statement: What do we have today in OSPFv3 specification - Router and Network LSAs carry only topology information - Only IPv6 address family is currently defined - IPv6-bit defined in Options field (can be used to include or exclude a node in IPv6 address-family) o What does this draft propose: - Enhance the per node support of AF to per link support to allow a link to be included or excluded explicitly in a given address-family - To be used during SPF in order to have incongruent AF topologies o What does this draft introduce: - A new bit (AF bit) in the Options field in order to support this feature (so routers supporting this draft must set this bit) - An unused field in the Router-LSA is defined with Address Familiies per link - AddressFamiles field is defined as: . each bit corresponds to an address-family (for the time being, only the v6 AF bit has been defined) . v6 AF bit must be set when a link participates in IPv6 topology otherwise it must be cleared . note: when a link participate in more than one AF, all of the corresponding bits will be set - A new LSA called AF-Functionality-LSA is defined to carry bits for each address families (area flooding scope and U bit is set) note: not needed for IPv6 AF (uses these bits from the router-lsa hdr) o Interaction with non-AF capable routers o Conclusion: - Enhances OSPFv3 address-family support from a per node to a per link - It enables incongruent topologies for different address-families - Applications ? Discussion: ---------- - Q1 (?): What about routers that do not support this feature ? - Abhay Roy: new AF capability only available when supported (obviously), here the backward compatibility applies to routers that would support this feature - Q1 (?): What happens if this capability is only supported on a per-node basis - Abhay Roy: you can not build congruent topologies - Q1 (?): Your proposal doesn't seem to be *so* backward compatible - Abhay Roy: (?) - Ghesam: Step towards IS-IS and half-bit with few things missing (metric) here ending with separated approaches - prefix itself carried in different LSA's to be modified on a per family basis, apart from that i don't have any specific issues with this proposal - Abhay Roy: we don't have an urgent need for it today (no per link support) and there is no possibility to have it in an easier way - Padma: parallelism with M-ISIS, also OSPFv3 does it have to carry IPv4 ? so it seems a bit too advanced with respect to the situation where we are and where want to go - Abhay Roy: Proposed implementation uses OSPF options bits, the debate OSPFv2/OSPFv3 and IPv4/IPv6 is orthogonal here, also this feature is useful in case of multicast topologies so it may become important in the future - Rohit Dube (to Abhay Roy): we allow for support of IPv4 in OSPFv3 and multicast with this new capability, do you see any other application(s) ? - Abhay Roy: IPv6/Multicast may require new topology, also other address families support than IPv6 might be needed ? but here the objective is to enhance this capability from a per node to a per link - Q2 (?): this capability is useful if you don't use the IPv6 proposal, thus suggest to wait for the first application before moving with that; but moving forward seems to be a bad choice at this point in time - Abhay Roy: agree, if we wait too long, new developments may need this and the per link capability is the real motivation behind - Rohit Dube: if needed better sooner than later but since we don't have any application why bother to include this feature now ? - Acee Lindem: mentions another problem (using RFC 1793, as example) where the backward compatibility issue required more code than the real feature, this aspect must also be taken into account when evaluating the present feature --------------------------------------------------------------------------------- 4) WG document status (10 Mins): WG Chairs o RFC 3101 - Open Shortest Path First (OSPF) "Not-So-Stubby Area" (NSSA) Option is now published o Traffic Engineering Extensions to OSPF Version 2: IETF wide last call completed. Decision to defer IANA update should allow publication but it will published at some point in time o OSPF Hitless Restart has completed the WG last call and will be udpated with clarifications based on the received comments (2 major comments - see mailing list - will be addressed in this update) o Detecting Inactive Neighbors over Demand Circuits - WG Last Call is completed and document submitted to IESG o Alternative OSPF ABR Implementations is in the RFC Publication Queue o OSPFv2/v3 MIBs both to be refreshed with additional MIB variables o Draft-ietf-ospf-scalability-02.txt should focus more on implementation rather than simulations (note: suggest a shorter title) o Authentication/Confidentiality for OSPFv3 (draft-ietf-ospf-ospfv3-auth-00.txt) requires more substantive discussions to move forward o TE extensions for ospfv3 (draft-ishiguo-ospf-ospfv3-traffic-02.txt) item added to the charter and it will become a WG document (we have a clear consensus through the ospf mailing list) Discussions: ----------- - Rohit: Any comments ? Any other issue on the drafts and their status ? Note: no reactions or comments from the room/group --------------------------------------------------------------------------------- 5) WG Charter Update (15 Mins): WG Chairs o OSPF as a PE/CE Protocol in BGP/MPLS VPNs - Rohit Dube: PPVPN WG works on OSPF for a while now, the recommendation here is to make it as part of the OSPF WG charter. Any comment from ppvpn participating people? o Support of Address Families in OSPFv3 - Note: discussion seems a bit pre-matured, no comments o Optional Router capabilities - Kireeti Kompella: it seems that we take the proposed drafts and include them in the charter rather than producing drafts from charter items - Rohit Dube: agrees - Kireeti Kompella: gives examples such as AF families coverage and multiple topologies - Acee Lindem: DN bit is to be added in the charter ? any objection ? anyone opposed ? Not an overhwhelming interest but due to the interaction with the PPVPN WG this item might come into consideration - Kireeti Kompella: Charter should say we want to interface with PPVPN WG since also sham links and others specific proposals related to the PPVPN WG are currently under discussion, so PPVPN WG does some work asking some change to OSPF. Kireeti argues in favor of larger charter items coverage rather than specific items to be covered - Rohit Dube: work items listed are managed and this does not go against inclusion of larger items within the charter of the OSPF working group - Alex Zinin: agrees with the relevance of the Kireeti's intervention, for the OSPF WG to extend the charter, the OSPF WG first needs to be in agreement that the group wants to extend than charter and then bring it to the IESG o OSPF flooding and refresh reduction in stable topologies - Rohit Dube: OSPF Flooding reduction in stable topologies, either we keep it or leave it? - Padma: sent an update which addresses comments received from Acee/Alex and she wants to see it going on and moving forward - Rohit Dube: for a couple of documents we want to be a bit more strict - Acee Lindem: target as PS initially, now it seems that informational is more appropriate - Padma: i am open to any proposal, it could be a proposed standard since not invalidating OSPF and just want to go forwad and close this item - Acee Lindem: implementation are available, as opposed to DC we propose here to go for informational (this i-d doesn't really build something new on top of RFC 1793) - Alex Zinin: pointing to this discusion, some discussions with SP's show that they are concerned with this draft that proposes to disable any LSA advertisement - Padma: only LSA refreshes are disabled by the Do Not Age (DNA) bit, LSA triggering still occurs independently of the DNA bit setting - Alex Zinin: LSA flooding rules shouldn't be stopped unless LSAs goes over the DC link, this method is not for application in case of "normal" (i.e. non-DC) link - Padma: we will take this discussion offline - Alex Zinin: DNA bit applicability won't go any further, all interfaces are DC interfaces so only flooded to the nearest neighbor - Acee Lindem: applicable if there are DC links otherwise not further flooded, agrees to take the discussion on the mailing list o Back to Optional Router capabilities - Acee Lindem: is there a consensus to move forward with this item ? - Acee Lindem: seems there is a disagreement until really needed (Acee also indicates that he is co-authoring this i-d but mentions that he sees one application for this i-d being the Path Computation Server - PCS) - Kireeti Kompella: PCS should be seen "as part" of the CCAMP WG charter but is not there today since we need first to include inter-area routing in the CCAMP WG charter; at that point PCS approach might be seen as a potential item - Rohit Dube: we wait until the CCAMP WG decides, so OSPF WG won't take any decision for the time being - Jean-Philippe Vasseur: MPLS WG also deals with the management of TE LSPs - Rohit Dube: then let's wait until MPLS working group decides - Rohit Dube: do we have any other option than 1) wait for CCAMP/MPLS WG outcomes or 2) define the capabilties that some application would use in the future - Acee Lindem: anybody else than the authors is interested in this i-d ? - Rohit Dube: it seems there is a very weak interest at this point in time o Back to Support of AF in OSPFv3 - Rohit Dube: same question for the Support of AF in OSPFv3. Poll for people that would like to see this item as part of the woking group charter ? Note: this i-d doesn't seem to receive a lot of support from the group to work on this item o Back to Optional Router capabilities - Rohit Dube: same question for the IGP Capabilities. Poll for people that would like to see this item as part of the woking group charter ? Note: no consensus on draft-raggarwa-... (due to room silence) - Rohit Dube: discussion on the mailing list will start once back from this IETF meeting - Acee Lindem: meeting is adjourned =========================================================================================== --==_Exmh_-10306016700-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Mar 28 16:14:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19194 for ; Fri, 28 Mar 2003 16:14:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0095221B@cherry.ease.lsoft.com>; Fri, 28 Mar 2003 16:17:00 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 697074 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 28 Mar 2003 16:16:59 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 28 Mar 2003 16:16:59 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 5ACA46B1210 for ; Fri, 28 Mar 2003 13:16:58 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030327191805.F230AB70C@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E84BC25.6050502@redback.com> Date: Fri, 28 Mar 2003 16:18:29 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit [Speaking as WG member] Don Goodspeed wrote: > All, Hi Don, > > OK, here's my opinion (two cents please) and let me know if this > would fly. For the current mib-update-nn file, only add additional > attributes that are missing, and do no structural changes such as > re-indexing, new tables, changes in max-access, etc. unless absolutely > needed. Then get the thing done and published. I agree here. This was before the ADs in the past and we decided to bring it back to the WG after updating it for some of the new features. > > Then start a new OSPFv2-MIB registered either under the existing > "ospf" node, or under a completely new registration point from IANA. > Then start this sucker from scratch. Do it once and do it right. > Make the entire file SMIv2 compliant, add/modify/delete any tables > that do not work, any traps that do not work, etc. Add an instance > as an index to all tables (like in ISIS-MIB). Take all these > discussion and comments and implement them once. A new MIB is the way to go if it is really required. People haven't screamed for it yet. > > Once done, we go back and deprecate the original OSPF-MIB file. > > Any takers, > Don > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 06:54:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02882 for ; Mon, 31 Mar 2003 06:54:59 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009571F9@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 6:57:22 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 702271 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 06:57:22 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 06:47:22 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02693; Mon, 31 Mar 2003 06:44:55 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200303311144.GAA02693@ietf.org> Date: Mon, 31 Mar 2003 06:44:55 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pillay-esnault-ospf-flooding-05.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPF Refresh and Flooding Reduction in Stable Topologies Author(s) : P. Pillay-Esnault Filename : draft-pillay-esnault-ospf-flooding-05.txt Pages : 4 Date : 2003-3-28 This document describes an extension to the OSPF protocol to eliminate or reduce periodic flooding of Link State Advertisements in stable topologies. The current behavior of OSPF requires that all LSAs be refreshed every 30 minutes regardless of the stability of the network except for DoNotAge LSAs. This document proposes to generalize the use of DoNotAge LSAs to reduce protocol traffic in stable topologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pillay-esnault-ospf-flooding-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pillay-esnault-ospf-flooding-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-pillay-esnault-ospf-flooding-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-28142341.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pillay-esnault-ospf-flooding-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-pillay-esnault-ospf-flooding-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-28142341.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 09:48:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07892 for ; Mon, 31 Mar 2003 09:48:12 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0095787F@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 9:50:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 702626 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 09:50:17 -0500 Received: from 64.104.193.198 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 09:50:16 -0500 Received: from cisco.com (localhost [127.0.0.1]) by syd-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2VEo9sI025957; Tue, 1 Apr 2003 00:50:10 +1000 (EST) User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: <200303311450.h2VEo9sI025957@syd-msg-core-1.cisco.com> Date: Mon, 31 Mar 2003 09:50:07 -0500 Reply-To: Mailing List Sender: Mailing List From: Eric Rosen Subject: Re: ietf 56 ospf wg meeting minutes To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Your message of Fri, 28 Mar 2003 14:32:37 -0500. <200303281932.OAA29659@bigbird.xebeo.com> Precedence: list With regard to the following extract from the minutes: > - Acee Lindem: we have now 3 methods for loop avoidance: Route Tag, DN Bit > and for Intra-Area link (sham links) > - Eric Rosen: sham links is the preferred method (in addition to DN bit) > - Acee Lindem: Thus we would have two preferred methods: DN bit and sham > links ? > - Eric Rosen: For Type3/5 DN bit applies and this without impacting the > OSPF protocol but it would have been better to have only one mechanism I think the following would be more accurate: - Acee Lindem: we have now 3 methods for loop avoidance: Route Tag, DN Bit and for Intra-Area link (sham links) - Eric Rosen: route tags can be eliminated in favor of the DN bit, but sham links cannot be. - Acee Lindem: Thus we would have two preferred methods: DN bit and sham links ? - Eric Rosen: DN bit applies only to type 3/5 LSAs. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 10:30:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11299 for ; Mon, 31 Mar 2003 10:30:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0095780A@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 10:33:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 702688 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 10:33:10 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 10:23:10 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0095788A@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 10:23:10 -0500 Message-ID: Date: Mon, 31 Mar 2003 10:23:10 -0500 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: OSPFv3 and IPv6 on-link router advertisements To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list How are IPv6 on-link router advertisements treated in OSPFv3? Does a router that advertises on-link prefixes in router advertisements also advertise them in link-lsas? And if these prefixes are not also advertised in link-lsas, how should they be treated by OSPFv3? Are they treated as AS-external desinations, or as if they had been received on a link-lsa (i.e., AS internal)? Mike From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 10:59:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12250 for ; Mon, 31 Mar 2003 10:59:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.009578F7@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 11:02:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 702771 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 11:02:02 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 11:02:02 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 552E163CE22 for ; Mon, 31 Mar 2003 08:02:01 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8866AF.9020009@redback.com> Date: Mon, 31 Mar 2003 11:02:55 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 and IPv6 on-link router advertisements To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello Mike, Mike Fox wrote: > How are IPv6 on-link router advertisements treated in OSPFv3? > Does a router that advertises on-link prefixes in router advertisements also > advertise them in link-lsas? On-link prefixes are NOT advertised in router LSAs - only link-LSAs and Intra-area prefix LSAs. > And if these prefixes are not also advertised in link-lsas, > how should they be treated by OSPFv3? Are they > treated as AS-external desinations, or as if they had been received on > a link-lsa (i.e., AS internal)? They are considered to be OSPF Intra-area routes. I've left out a lot of details - it is probably best to just re-read RFC 2740 and ask specific questions. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 11:59:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14384 for ; Mon, 31 Mar 2003 11:59:22 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00957BFA@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 12:01:46 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 702892 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 12:01:46 -0500 Received: from 144.189.100.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 12:01:46 -0500 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2VH1bGD007380 for ; Mon, 31 Mar 2003 10:01:37 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id KAA21977 for ; Mon, 31 Mar 2003 10:01:20 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Mar 2003 12:01:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 31 Mar 2003 12:03:19 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv3 and IPv6 on-link router advertisements To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Mike, I am not sure how OSPFv3 and RA messages are directly related and Acee has probably answered your question already. However still OSPFv3 advertizes link-local addreses as well as IPv6 prefixes assigned to a link in its link LSA's. I think the RA message does not advertize Link-local address however. Please let me know if this answers your question? Thanks, Vishwas -----Original Message----- From: Mike Fox [mailto:mjfox@US.IBM.COM] Sent: Monday, March 31, 2003 8:53 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPFv3 and IPv6 on-link router advertisements How are IPv6 on-link router advertisements treated in OSPFv3? Does a router that advertises on-link prefixes in router advertisements also advertise them in link-lsas? And if these prefixes are not also advertised in link-lsas, how should they be treated by OSPFv3? Are they treated as AS-external desinations, or as if they had been received on a link-lsa (i.e., AS internal)? Mike From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 12:10:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14954 for ; Mon, 31 Mar 2003 12:10:49 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00957B6F@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 12:12:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 702953 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 12:12:17 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 12:12:16 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 746D91DBFE8 for ; Mon, 31 Mar 2003 09:12:15 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E887725.8050205@redback.com> Date: Mon, 31 Mar 2003 12:13:09 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 and IPv6 on-link router advertisements To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Vishwas, I guess I have too much of a OSPF centric view ;^). In Mikes original message, I confused neighbor discovery RAs with OSPFv3 router LSAs. Anyway, my opinion is that routers should rely on the routing protocols (e.g., OSPFv3) to learn about on-link prefixes and that neighbor discovery RAs are primarily for hosts. Manral, Vishwas wrote: > Hi Mike, > > I am not sure how OSPFv3 and RA messages are directly related and Acee has > probably answered your question already. > > However still OSPFv3 advertizes link-local addreses as well as IPv6 prefixes > assigned to a link in its link LSA's. I think the RA message does not > advertize Link-local address however. > > Please let me know if this answers your question? > > Thanks, > Vishwas > > -----Original Message----- > From: Mike Fox [mailto:mjfox@US.IBM.COM] > Sent: Monday, March 31, 2003 8:53 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: OSPFv3 and IPv6 on-link router advertisements > > > How are IPv6 on-link router advertisements treated in OSPFv3? Does a router > that advertises on-link prefixes in router advertisements also > advertise them in link-lsas? And if these prefixes are not also advertised > in link-lsas, how should they be treated by OSPFv3? Are they > treated as AS-external desinations, or as if they had been received on a > link-lsa (i.e., AS internal)? > > Mike > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 12:26:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15307 for ; Mon, 31 Mar 2003 12:26:46 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00957BD3@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 12:29:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 703031 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 12:29:10 -0500 Received: from 32.97.110.133 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 12:29:10 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h2VHT9Ef049570 for ; Mon, 31 Mar 2003 12:29:09 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2VHT7b0051618 for ; Mon, 31 Mar 2003 10:29:07 -0700 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 03/31/2003 10:29:07 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Mon, 31 Mar 2003 12:28:46 -0500 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Re: OSPFv3 and IPv6 on-link router advertisements To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Acee Lindem wrote > On-link prefixes are NOT advertised in router LSAs - only link-LSAs > and Intra-area prefix LSAs. > They are considered to be OSPF Intra-area routes. > I've left out a lot of details - it is probably best to just re-read > RFC 2740 and ask specific questions. I don't think my question was precise enough. I have been through RFC 2740, and as far as I can tell, it does cover the interaction I am asking about. I am asking about interaction between OSPFv3 and the IPv6 Neighbor Discovery protocol, which is described in RFC 2461 . Part of the IPv6 Neighbor Discovery protocol is the ability of routers to send ICMPv6 Router Advertisement messages to on-link hosts, advertising on-link prefixes. These advertised prefixes can be used in stateless autoconfiguration, and/or they can also be simply advertised as on-link. With that background, hopefully these questions are better phrased and more to the point: 1. If a router is running OSPFv3, does it still advertise on-link prefixes via Neighbor Discovery ICMPv6 messages,or does it only use link-LSA's, or does it use both? 2. If a host or router running OSPFv3 receives an ICMPv6 Neighbor Discovery message advertising an on-link prefix, and that prefix is not also received in a link-LSA, does it treat it as OSPF internal or OSPF external? Mike From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 12:58:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16892 for ; Mon, 31 Mar 2003 12:58:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00957D63@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 13:01:09 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 703170 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 13:01:09 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 13:01:09 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 2CAFB9E8BA9 for ; Mon, 31 Mar 2003 10:01:08 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E888299.4000406@redback.com> Date: Mon, 31 Mar 2003 13:02:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 and IPv6 on-link router advertisements To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Mike, You're right - I was confused by initial E-mail. I'll give you my opinion on the interaction between ND and OSPFv3. I'd be very interested in the opinions of those who have followed the IPng discussion more diligently than myself. Mike Fox wrote: > Acee Lindem wrote > > >>On-link prefixes are NOT advertised in router LSAs - only link-LSAs >>and Intra-area prefix LSAs. >>They are considered to be OSPF Intra-area routes. >>I've left out a lot of details - it is probably best to just re-read >>RFC 2740 and ask specific questions. > > > I don't think my question was precise enough. I have been through RFC > 2740, and as far as I can tell, it does cover the interaction I am asking > about. > > I am asking about interaction between OSPFv3 and the IPv6 Neighbor > Discovery protocol, which is described in RFC 2461 . Part of the IPv6 > Neighbor Discovery protocol is the ability of routers to send ICMPv6 Router > Advertisement messages to on-link hosts, advertising on-link prefixes. > These advertised prefixes can be used in stateless autoconfiguration, > and/or they can also be simply advertised as on-link. > > With that background, hopefully these questions are better phrased and > more to the point: > > 1. If a router is running OSPFv3, does it still advertise on-link prefixes > via Neighbor Discovery ICMPv6 messages,or does it only use link-LSA's, or > does it use both? An IPv6 router must advertise prefixes in ND router advertisements. If OSPFv3 is configured on the interface, it also must advertise its prefixes in a link-local LSA. > > 2. If a host or router running OSPFv3 receives an ICMPv6 Neighbor Discovery > message advertising an on-link prefix, and that prefix is not also received > in a link-LSA, does it treat it as OSPF internal or OSPF external? Hmmm, I'd call this a misconfiguration. I'd log at least an INFO or WARN message. Since you're a host (and not a router) you listen to ND RAs and install the corresponding RA routes. In this case, the corresponding route type will not be OSPFv3 at all. I'd think it would be an ND stateless auto-configuration route. If you redistribute the route back into OSPFv3 and re-advertise it, then it should probably be advertised in an OSPFv3 external LSA. > > Mike > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 12:59:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16921 for ; Mon, 31 Mar 2003 12:59:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00957D1D@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 13:02:00 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 703188 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 13:02:00 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 13:01:59 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id DEFE824C00; Tue, 1 Apr 2003 03:01:57 +0900 (JST) References: X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030401.030156.63287579.yasu@sfc.wide.ad.jp> Date: Tue, 1 Apr 2003 03:01:56 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: OSPFv3 and IPv6 on-link router advertisements Comments: To: mjfox@US.IBM.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Mike, > I don't think my question was precise enough. I have been through RFC > 2740, and as far as I can tell, it does cover the interaction I am asking > about. I don't think so, which part is it mentioned ? > I am asking about interaction between OSPFv3 and the IPv6 Neighbor > Discovery protocol, which is described in RFC 2461 . Part of the IPv6 > Neighbor Discovery protocol is the ability of routers to send ICMPv6 Router > Advertisement messages to on-link hosts, advertising on-link prefixes. > These advertised prefixes can be used in stateless autoconfiguration, > and/or they can also be simply advertised as on-link. > > With that background, hopefully these questions are better phrased and > more to the point: > > 1. If a router is running OSPFv3, does it still advertise on-link prefixes > via Neighbor Discovery ICMPv6 messages,or does it only use link-LSA's, or > does it use both? I guess that all depends on the configuration of the router. A router can know his on-link prefix either Link-LSA or RA, or both. Even if the router receives both Link-LSA and RA, there won't be any problem, at least protocol level. One interesting case will be when the router receives RA, and the router's interface is "passive" or something that makes OSPFv3 to advertise attached address prefix on that interface. Then the router will advertise the prefix in the Intra-Area-Prefix-LSA referring the router's Router-LSA. > 2. If a host or router running OSPFv3 receives an ICMPv6 Neighbor Discovery > message advertising an on-link prefix, and that prefix is not also received > in a link-LSA, does it treat it as OSPF internal or OSPF external? Usually OSPFv3 do not advertise the address prefix on the interface which is not included in OSPF domain (in other words the interface that does neither speak OSPF nor form OSPF adjacency), I believe. So in your case, OSPF will have nothing to do with the address prefix, except for the case I mentioned above. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 14:11:11 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19585 for ; Mon, 31 Mar 2003 14:11:11 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00957EB5@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 14:13:35 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 703377 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 14:13:35 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 14:13:35 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id CF4F414C922 for ; Mon, 31 Mar 2003 11:13:33 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200303311450.h2VEo9sI025957@syd-msg-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E889392.3060208@redback.com> Date: Mon, 31 Mar 2003 14:14:26 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: ietf 56 ospf wg meeting minutes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Eric, Thanks - We'll update. Also, I'm updating the punctation of one of my statements. Eric Rosen wrote: > With regard to the following extract from the minutes: > > >>- Acee Lindem: we have now 3 methods for loop avoidance: Route Tag, DN Bit >> and for Intra-Area link (sham links) > > >>- Eric Rosen: sham links is the preferred method (in addition to DN bit) > > >>- Acee Lindem: Thus we would have two preferred methods: DN bit and sham >> links ? > > >>- Eric Rosen: For Type3/5 DN bit applies and this without impacting the >> OSPF protocol but it would have been better to have only one mechanism > > > > I think the following would be more accurate: > > - Acee Lindem: we have now 3 methods for loop avoidance: Route Tag, DN Bit > and for Intra-Area link (sham links) > > - Eric Rosen: route tags can be eliminated in favor of the DN bit, but sham > links cannot be. > > - Acee Lindem: Thus we would have two preferred methods: DN bit and sham > links ? links. > > - Eric Rosen: DN bit applies only to type 3/5 LSAs. > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 15:08:11 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21713 for ; Mon, 31 Mar 2003 15:08:11 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00957FF3@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 15:10:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 703550 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 15:10:36 -0500 Received: from 32.97.110.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 15:10:33 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h2VK9E2S076952 for ; Mon, 31 Mar 2003 15:09:14 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2VKARb0014830 for ; Mon, 31 Mar 2003 13:10:28 -0700 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 03/31/2003 13:10:28 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Mon, 31 Mar 2003 15:09:47 -0500 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Re: OSPFv3 and IPv6 on-link router advertisements To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Yasuhiro Ohara wrote: > Mike Fox wrote > > I don't think my question was precise enough. I have been through RFC > > 2740, and as far as I can tell, it does cover the interaction I am asking > > about. > I don't think so, which part is it mentioned ? You're right Yasuhiro, it was a typo in my last message. It should have said "...it does NOT cover the interaction..." If it did cover it, I would not need ask this question :) Acee wrote: > Anyway, my opinion is that routers should rely on the routing > protocols (e.g., OSPFv3) to learn about on-link prefixes and > that neighbor discovery RAs are primarily for hosts. Unfortunately the distinction between host and router is not so clear-cut for us. My product is a hybrid of a host and router. For purposes of this question, it receives ICMPv6 Router Advertisements and never sends them. On the same interfaces, it also participates fully in the OSPF autonomous system. As we implemented IPv6, we initially shipped our IPv6 implementation without support for a dynamic routing protocol, relying solely on static routes and router advertisements for IPv6 routing. However, IPv6 dynamic routing is a requirement for our customers, so now I am working to understand what's needed to add OSPFv3. Since we already have OSPFv2 implemented most of it is pretty straightforward, but we are puzzling over how the Router Advertisement prefixes and OSPF Autonomous System will interact. It seems like OSPFv3 and Neighbor Discovery were not designed to work together -- neither RFC mentions the other. The assumption that some people have made in this discussion, and maybe also the assumption made by the designers of these protocols, seems to be that you support one or the other. But we support both. We need to receive the Router Advertisements so we can do stateless autoconfiguration. But we will also support OSPFv3. If a router that sends RA packets also sends link-LSAs for the same prefixes, then that answers the question -- obviously, any prefix received on a link-LSA will be OSPF internal. However, if the router does not send a link-LSA for every on-link prefix that it advertises via RA (or if there is a router on my LAN that is sending Router Advertisements but NOT running OSPFv3) then I need to decide if a prefix learned only via RA is OSPF internal or OSPF external. There are good arguments for both answers. For OSPF internal, one could argue that the prefix is assigned to a link that is internal to the OSPF AS (since I'm running OSPF on that link), so it should be internal. In this view, RA is just a lower-level method for the TCP/IP stack to learn its interface prefixes. Futhermore, if it is OSPF internal than I need to include it on my link-LSA. For OSPF external, one could argue that the prefix was learned via a routing protocol other than OSPF. In this view Router Advertisement is another routing protocol and therefore a different autonomous system, and I would need to advertise it on an AS-external LSA. . Mike From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 16:29:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25485 for ; Mon, 31 Mar 2003 16:29:08 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.009584C5@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 16:30:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 703847 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 16:30:17 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 16:30:15 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id AA438915148 for ; Mon, 31 Mar 2003 13:30:13 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E88B398.1060209@redback.com> Date: Mon, 31 Mar 2003 16:31:04 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 and IPv6 on-link router advertisements To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mike Fox wrote: > Yasuhiro Ohara wrote: > >>Mike Fox wrote > > >>> I don't think my question was precise enough. I have been through RFC >>>2740, and as far as I can tell, it does cover the interaction I am >> > asking > >>>about. >> > >>I don't think so, which part is it mentioned ? > > > You're right Yasuhiro, it was a typo in my last message. It should have > said "...it does NOT cover the interaction..." If it did cover it, I would > not need ask this question :) > > Acee wrote: > > >>Anyway, my opinion is that routers should rely on the routing >>protocols (e.g., OSPFv3) to learn about on-link prefixes and >>that neighbor discovery RAs are primarily for hosts. > > > Unfortunately the distinction between host and router is not so clear-cut > for us. My product is a hybrid of a host and router. For purposes of this > question, it receives ICMPv6 Router Advertisements and never sends them. > On the same interfaces, it also participates fully in the OSPF autonomous > system. > > As we implemented IPv6, we initially shipped our IPv6 implementation > without support for a dynamic routing protocol, relying solely on static > routes and router advertisements for IPv6 routing. However, IPv6 dynamic > routing is a requirement for our customers, so now I am working to > understand what's needed to add OSPFv3. Since we already have OSPFv2 > implemented most of it is pretty straightforward, but we are puzzling over > how the Router Advertisement prefixes and OSPF Autonomous System will > interact. > > It seems like OSPFv3 and Neighbor Discovery were not designed to work > together -- neither RFC mentions the other. The assumption that some people > have made in this discussion, and maybe also the assumption made by the > designers of these protocols, seems to be that you support one or the > other. But we support both. We need to receive the Router Advertisements > so we can do stateless autoconfiguration. But we will also support OSPFv3. > > > If a router that sends RA packets also sends link-LSAs for the same > prefixes, then that answers the question -- obviously, any prefix received > on a link-LSA will be OSPF internal. > > However, if the router does not send a link-LSA for every on-link prefix > that it advertises via RA (or if there is a router on my LAN that is > sending Router Advertisements but NOT running OSPFv3) then I need to decide > if a prefix learned only via RA is OSPF internal or OSPF external. There > are good arguments for both answers. > > For OSPF internal, one could argue that the prefix is assigned to a link > that is internal to the OSPF AS (since I'm running OSPF on that link), so > it should be internal. In this view, RA is just a lower-level method for > the TCP/IP stack to learn its interface prefixes. Futhermore, if it is > OSPF internal than I need to include it on my link-LSA. > > For OSPF external, one could argue that the prefix was learned via a > routing protocol other than OSPF. In this view Router Advertisement is > another routing protocol and therefore a different autonomous system, and I > would need to advertise it on an AS-external LSA. . Mike, There are really at least a couple issues here. First off, you may have 2 routes but only one is active. So, you need to have the concept of adminstrative distance (or preference) to determine whether you install the OSPFv3 route or the ND auto-config route. IMHO, the default adminstrative distance should prefer the ND route over the OSPFv3 route since it is somewhat analogous to a connected (or direct) route. Once you've determined which route to install, the next decision is whether or not to re-advertise the route. If you install the ND route, you need to determine 1) Whether or not you will include it in your own link-LSA. 2) If so, then it will be advertised to others as an OSPF route but it will remain an ND route to you. 3) If not, then it could be optionally redistributed into OSPFv3 and advertised as an AS external route. If you install the OSPFv3 route, you would certainly not re-advertise it in your own link-LSA. If your box is acting as a router, you should probably include a configuration knob to disable listening to RAs on the interface. Make more sense? Acee > > Mike > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 17:57:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29788 for ; Mon, 31 Mar 2003 17:57:33 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.009587A5@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 17:59:56 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 704104 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 17:59:55 -0500 Received: from 63.78.179.216 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 17:59:55 -0500 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h2VN01Z02135 for ; Mon, 31 Mar 2003 17:00:01 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 31 Mar 2003 16:59:54 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 31 Mar 2003 16:59:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Authentication/Encryption Algorithms for draft-ietf-ospf-ospfv3-auth-00.txt Thread-Index: AcL32SNxbIJICXPbRaO+39mcpNYsew== X-OriginalArrivalTime: 31 Mar 2003 22:59:12.0966 (UTC) FILETIME=[258B8660:01C2F7D9] Message-ID: <7CA3477F476D7F4FB82F02960B79CEBD01C73DFB@daebe008.americas.nokia.com> Date: Mon, 31 Mar 2003 16:59:12 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Subject: Authentication/Encryption Algorithms for draft-ietf-ospf-ospfv3-auth-00.txt Comments: cc: Nagavenkata.Melam@nokia.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA29788 Hi All, Section 5 in draft draft-ietf-ospf-ospfv3-auth-00.txt says MD5 as a MUST for authentication and DES as a MUST for encryption. This doesn't match the current IPsec specifications (section 5 of draft-ietf-ipsec-rfc2402bis-02.txt and draft-ietf-ipsec-esp-v3-04.txt). We could change it to match the IPsec specifications but that create a maintenence problem. We will always have to keep this document updated with IPsec documents. So should we just say that the implementation should be conformant to ESP and AH RFCs instead of naming the algorithms. regards Mukesh From owner-ospf@DISCUSS.MICROSOFT.COM Mon Mar 31 18:57:17 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03267 for ; Mon, 31 Mar 2003 18:57:16 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0095881B@cherry.ease.lsoft.com>; Mon, 31 Mar 2003 18:59:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 704215 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 31 Mar 2003 18:59:40 -0500 Received: from 63.78.179.217 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 31 Mar 2003 18:59:40 -0500 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h2VNxeH08917 for ; Mon, 31 Mar 2003 17:59:40 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 31 Mar 2003 17:59:40 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 31 Mar 2003 15:59:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: ospfv3 IPSec draft.. Thread-Index: AcLes9PyRUniYZOUSIuT37/gQG98AQZJkTZQ X-OriginalArrivalTime: 31 Mar 2003 23:59:39.0860 (UTC) FILETIME=[9757A140:01C2F7E1] Message-ID: <7CA3477F476D7F4FB82F02960B79CEBD01C73DFC@daebe008.americas.nokia.com> Date: Mon, 31 Mar 2003 17:59:39 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Subject: SRC address for packets over Virtual Link Comments: cc: Nagavenkata.Melam@nokia.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA03267 Hi All, This is related to draft draft-ietf-ospf-ospfv3-auth-00.txt. Abhay Roy brought this point up to me so I wanted to start a discussion on this in the mailing list. The draft suggests to install the following rule for virtual links. ===== interface source destination protocol action any src/128 dst/128 OSPF apply ===== In order to secure the packets that are exchanged over virtual links, the end point IP addresses must be predictable. Page 41 of OSPFv3 RFC (2740) says the following about finding the dst address === When the router added to the area routing table in this step is the other end of a virtual link, the virtual neighbor's IP address is set as follows: The collection of intra-area-prefix- LSAs originated by the virtual neighbor is examined, with the virtual neighbor's IP address being set to the first prefix encountered having the "LA-bit" set. === But when it comes to finding the src addr, it simply says "one of the router's own site-local or global IPv6 addresses". So with the currect specs, it is not possible to provide security to virtual links reliably. The solution of the problem is to make the end point IP addresses predictable by mandating using "first prefix with LA-bit set in our own intra-area-prefix-LSAs", as src address. Basically use the address as src, what other endpoint will use as dst. I am planning to put this as a mandatory item in draft-ietf-ospf-ospfv3-auth-00.txt. Would appreciate comments from everyone. regards Mukesh