From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 2 01:45:30 2004 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 BAA08503 for ; Mon, 2 Feb 2004 01:45:30 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00CC8B46@cherry.ease.lsoft.com>; Mon, 2 Feb 2004 1:45:29 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 268612 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 Feb 2004 01:45:27 -0500 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 2 Feb 2004 01:45:26 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i126jQ215675 for ; Mon, 2 Feb 2004 08:45:26 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 2 Feb 2004 08:45:25 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 1 Feb 2004 22:45:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Configured default route or OSPF default route Thread-Index: AcPl9x2nll4UlM8fR7iS8POhcEgzoADYGrsQ X-OriginalArrivalTime: 02 Feb 2004 06:45:23.0405 (UTC) FILETIME=[220B0FD0:01C3E958] Message-ID: <8D260779A766FB4A9C1739A476F84FA4015471BC@daebe009.americas.nokia.com> Date: Mon, 2 Feb 2004 00:45:23 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: Configured default route or OSPF default route To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Acee/Pawan, When you refer to "OSPF learned routes", do you mean OSPF External routes or ALL ospf routes ? Because Nokia routers prefer all OSPF routes except the OSPF External routes over the static routers but=20 prefer static routes over the OSPF External routes and IMHO that=20 is a sensible thing to do. Ofcourse an administrator is allowed to changes all these preferences. Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Bhatia Pawan-CPB101 > Sent: Wednesday, January 28, 2004 3:23 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Configured default route or OSPF default route >=20 >=20 > 3COM (and now Motorola) routers also prefer static routes=20 > over OSPF learned routes. However, there is an option to=20 > configure a static route such that the OSPF learned route=20 > takes precedence. >=20 > regards, > Pawan >=20 > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On=20 > Behalf Of Acee Lindem > Sent: Tuesday, January 27, 2004 3:31 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Configured default route or OSPF default route >=20 >=20 > ----- Original Message ----- > From: "Abhijit Kumbhare" > To: > Sent: Tuesday, January 27, 2004 5:25 PM > Subject: Configured default route or OSPF default route >=20 >=20 > > Hello, > > > > If the user has not configured anything - what is the generally > > accepted default preference in most implementations - should the > > configured default route take precedence or the learned=20 > (OSPF) default > > route? > > > > I believe Cisco uses the static (configured) default route over the > > learned default route - how do others handle it? >=20 > Hi Abhijit, >=20 > We, Redback, also will prefer a static route over an OSPF=20 > learned route. I think this is the right default since the=20 > static route is explicit. We do allow the preference (aka,=20 > administrative distance) to be configured for individual=20 > static routes. Additionally, we'll install the a backup OSPF=20 > external route (default or otherwise) even if we are=20 > advertising an external route ourselves and let the defaulted=20 > or configued route preferences sort themselves out in RIB. If=20 > we install an OSPF intra or inter area route, we will=20 > discontinue advertising an OSPF external route. I think this=20 > approach offers the most flexibility. >=20 > Thanks, > Acee >=20 > > > > Thanks, > > Abhijit Kumbhare >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 2 02:07:39 2004 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 CAA17484 for ; Mon, 2 Feb 2004 02:07:38 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00CC8C69@cherry.ease.lsoft.com>; Mon, 2 Feb 2004 2:07:38 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 269209 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 Feb 2004 02:07:35 -0500 Received: from 203.199.54.34 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 2 Feb 2004 01:57:35 -0500 Received: from Bangalore.lntinfotech.com ([107.108.204.3]) by mailrelay2.lntinfotech.com (Lotus Domino Release 5.0.12) with ESMTP id 2004020212285456:1506 ; Mon, 2 Feb 2004 12:28:54 +0530 X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.9 |November 16, 2001) at 02/02/2004 12:25:46 PM, Itemize by SMTP Server on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 02/02/2004 12:28:54 PM, Serialize by Router on MAILRELAY2/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 02/02/2004 12:28:58 PM, Serialize complete at 02/02/2004 12:28:58 PM Content-type: text/plain; charset=us-ascii Message-ID: Date: Mon, 2 Feb 2004 12:25:45 +0530 Reply-To: Mailing List Sender: Mailing List From: Durai R Subject: Re: Configured default route or OSPF default route To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi All, If the route is learned by OSPF, then its administrative distance is 110 by default. This can be changed by the administrator. But the administrative distance of the default route which is configured by the administrator is by default 1. This also can be changed by the administrator. So under normal situations ie.,with default values, configured static route will always have higher precedence than the learned route(ospf default route). Lower the administrative distance means higher the trustness of the route. Regards, Durai Mukesh.Gupta@NOKI A.COM To: OSPF@PEACH.EASE.LSOFT.COM Sent by: Mailing cc: List Subject: Re: Configured default route or OSPF default 02/02/2004 12:15 PM Please respond to Mailing List Acee/Pawan, When you refer to "OSPF learned routes", do you mean OSPF External routes or ALL ospf routes ? Because Nokia routers prefer all OSPF routes except the OSPF External routes over the static routers but prefer static routes over the OSPF External routes and IMHO that is a sensible thing to do. Ofcourse an administrator is allowed to changes all these preferences. Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Bhatia Pawan-CPB101 > Sent: Wednesday, January 28, 2004 3:23 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Configured default route or OSPF default route > > > 3COM (and now Motorola) routers also prefer static routes > over OSPF learned routes. However, there is an option to > configure a static route such that the OSPF learned route > takes precedence. > > regards, > Pawan > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > Behalf Of Acee Lindem > Sent: Tuesday, January 27, 2004 3:31 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Configured default route or OSPF default route > > > ----- Original Message ----- > From: "Abhijit Kumbhare" > To: > Sent: Tuesday, January 27, 2004 5:25 PM > Subject: Configured default route or OSPF default route > > > > Hello, > > > > If the user has not configured anything - what is the generally > > accepted default preference in most implementations - should the > > configured default route take precedence or the learned > (OSPF) default > > route? > > > > I believe Cisco uses the static (configured) default route over the > > learned default route - how do others handle it? > > Hi Abhijit, > > We, Redback, also will prefer a static route over an OSPF > learned route. I think this is the right default since the > static route is explicit. We do allow the preference (aka, > administrative distance) to be configured for individual > static routes. Additionally, we'll install the a backup OSPF > external route (default or otherwise) even if we are > advertising an external route ourselves and let the defaulted > or configued route preferences sort themselves out in RIB. If > we install an OSPF intra or inter area route, we will > discontinue advertising an OSPF external route. I think this > approach offers the most flexibility. > > Thanks, > Acee > > > > > Thanks, > > Abhijit Kumbhare > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 2 02:08:59 2004 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 CAA19039 for ; Mon, 2 Feb 2004 02:08:56 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00CC8AE6@cherry.ease.lsoft.com>; Mon, 2 Feb 2004 2:08:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 269857 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 Feb 2004 02:08:51 -0500 Received: from 67.17.166.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 2 Feb 2004 02:08:51 -0500 Received: from homejtm01a43f8 (unverified [24.5.244.52]) by ucmmail.com (Rockliffe SMTPRA 5.3.6) with ESMTP id for ; Mon, 2 Feb 2004 02:08:51 -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, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Message-ID: <000001c3e95b$e119dc50$6400a8c0@homejtm01a43f8> Date: Sun, 1 Feb 2004 23:12:11 -0800 Reply-To: Mailing List Sender: Mailing List From: Farshad Tavallaei Subject: Re: Configured default route or OSPF default route To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA4015471BC@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Mukesh, I am assuming you are asking about transit areas (some call them normal areas). In a transit area, the default route is an external route anyway. e.g OSPF default route is an external route in area 0. sean -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mukesh.Gupta@NOKIA.COM Sent: Sunday, February 01, 2004 10:45 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Configured default route or OSPF default route Acee/Pawan, When you refer to "OSPF learned routes", do you mean OSPF External routes or ALL ospf routes ? Because Nokia routers prefer all OSPF routes except the OSPF External routes over the static routers but prefer static routes over the OSPF External routes and IMHO that is a sensible thing to do. Ofcourse an administrator is allowed to changes all these preferences. Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Bhatia Pawan-CPB101 > Sent: Wednesday, January 28, 2004 3:23 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Configured default route or OSPF default route > > > 3COM (and now Motorola) routers also prefer static routes > over OSPF learned routes. However, there is an option to > configure a static route such that the OSPF learned route > takes precedence. > > regards, > Pawan > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > Behalf Of Acee Lindem > Sent: Tuesday, January 27, 2004 3:31 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Configured default route or OSPF default route > > > ----- Original Message ----- > From: "Abhijit Kumbhare" > To: > Sent: Tuesday, January 27, 2004 5:25 PM > Subject: Configured default route or OSPF default route > > > > Hello, > > > > If the user has not configured anything - what is the generally > > accepted default preference in most implementations - should the > > configured default route take precedence or the learned > (OSPF) default > > route? > > > > I believe Cisco uses the static (configured) default route over the > > learned default route - how do others handle it? > > Hi Abhijit, > > We, Redback, also will prefer a static route over an OSPF > learned route. I think this is the right default since the > static route is explicit. We do allow the preference (aka, > administrative distance) to be configured for individual > static routes. Additionally, we'll install the a backup OSPF > external route (default or otherwise) even if we are > advertising an external route ourselves and let the defaulted > or configued route preferences sort themselves out in RIB. If > we install an OSPF intra or inter area route, we will > discontinue advertising an OSPF external route. I think this > approach offers the most flexibility. > > Thanks, > Acee > > > > > Thanks, > > Abhijit Kumbhare > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 2 02:43:06 2004 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 CAA23564 for ; Mon, 2 Feb 2004 02:43:06 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00CC8AC5@cherry.ease.lsoft.com>; Mon, 2 Feb 2004 2:43:05 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 271357 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 Feb 2004 02:42:57 -0500 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 2 Feb 2004 02:42:57 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i127guM08249 for ; Mon, 2 Feb 2004 09:42:56 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 2 Feb 2004 09:42:52 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 2 Feb 2004 01:42:51 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Configured default route or OSPF default route Thread-Index: AcPpW3P7qyIPtyHgT2afbNZl51Re5wABAh4g X-OriginalArrivalTime: 02 Feb 2004 07:42:51.0024 (UTC) FILETIME=[28FBF900:01C3E960] Message-ID: <8D260779A766FB4A9C1739A476F84FA4015471BF@daebe009.americas.nokia.com> Date: Mon, 2 Feb 2004 01:42:51 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: Configured default route or OSPF default route To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Sean, You are right. The default route will be an ospf external route and=20 a static default route will be (and should be) preferred over the default route learned through OSPF. I raised the point because I thought people were saying that the static routes (All and not just the default) are preferred over OSPF learned routes (All and not just the OSPF External). Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Farshad Tavallaei > Sent: Sunday, February 01, 2004 11:12 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Configured default route or OSPF default route >=20 >=20 > Mukesh, >=20 > I am assuming you are asking about transit areas (some call=20 > them normal > areas). In a transit area, the default route is an external route > anyway. e.g OSPF default route is an external route in area 0. >=20 > sean >=20 >=20 > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Mukesh.Gupta@NOKIA.COM > Sent: Sunday, February 01, 2004 10:45 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Configured default route or OSPF default route >=20 > Acee/Pawan, >=20 > When you refer to "OSPF learned routes", do you mean OSPF External > routes or ALL ospf routes ? Because Nokia routers prefer all OSPF > routes except the OSPF External routes over the static routers but > prefer static routes over the OSPF External routes and IMHO that > is a sensible thing to do. >=20 > Ofcourse an administrator is allowed to changes all these preferences. >=20 > Regards > Mukesh >=20 > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On=20 > Behalf Of ext > > Bhatia Pawan-CPB101 > > Sent: Wednesday, January 28, 2004 3:23 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: Configured default route or OSPF default route > > > > > > 3COM (and now Motorola) routers also prefer static routes > > over OSPF learned routes. However, there is an option to > > configure a static route such that the OSPF learned route > > takes precedence. > > > > regards, > > Pawan > > > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > > Behalf Of Acee Lindem > > Sent: Tuesday, January 27, 2004 3:31 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: Configured default route or OSPF default route > > > > > > ----- Original Message ----- > > From: "Abhijit Kumbhare" > > To: > > Sent: Tuesday, January 27, 2004 5:25 PM > > Subject: Configured default route or OSPF default route > > > > > > > Hello, > > > > > > If the user has not configured anything - what is the generally > > > accepted default preference in most implementations - should the > > > configured default route take precedence or the learned > > (OSPF) default > > > route? > > > > > > I believe Cisco uses the static (configured) default=20 > route over the > > > learned default route - how do others handle it? > > > > Hi Abhijit, > > > > We, Redback, also will prefer a static route over an OSPF > > learned route. I think this is the right default since the > > static route is explicit. We do allow the preference (aka, > > administrative distance) to be configured for individual > > static routes. Additionally, we'll install the a backup OSPF > > external route (default or otherwise) even if we are > > advertising an external route ourselves and let the defaulted > > or configued route preferences sort themselves out in RIB. If > > we install an OSPF intra or inter area route, we will > > discontinue advertising an OSPF external route. I think this > > approach offers the most flexibility. > > > > Thanks, > > Acee > > > > > > > > Thanks, > > > Abhijit Kumbhare > > >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 2 09:22:13 2004 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 JAA14364 for ; Mon, 2 Feb 2004 09:22:10 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00CC932F@cherry.ease.lsoft.com>; Mon, 2 Feb 2004 8:42:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 372713 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 Feb 2004 08:42:39 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 2 Feb 2004 08:42:38 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A0FE07D3021 for ; Mon, 2 Feb 2004 05:42:38 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21246-02 for ; Mon, 2 Feb 2004 05:42:38 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.58]) by prattle.redback.com (Postfix) with SMTP id 102A57D3023 for ; Mon, 2 Feb 2004 05:42:37 -0800 (PST) References: <8D260779A766FB4A9C1739A476F84FA4015471BC@daebe009.americas.nokia.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.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <072b01c3e992$64deb5c0$0302a8c0@aceeinspiron> Date: Mon, 2 Feb 2004 08:42:25 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Configured default route or OSPF default route To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Mukesh, Our implementation is modular in that the OSPF routing calculation and the RIB are separate. Within OSPF, we always prefer OSPF internal routes (i.e., intra-area and inter-area routes) over external routes and will not advertise a redistributed route if there is an OSPF internal route. Within the RIB, our default administrative distance (or preference) for static routes is lower (more preferred) than OSPF internal routes. Acee ----- Original Message ----- From: To: Sent: Monday, February 02, 2004 1:45 AM Subject: Re: Configured default route or OSPF default route Acee/Pawan, When you refer to "OSPF learned routes", do you mean OSPF External routes or ALL ospf routes ? Because Nokia routers prefer all OSPF routes except the OSPF External routes over the static routers but prefer static routes over the OSPF External routes and IMHO that is a sensible thing to do. Ofcourse an administrator is allowed to changes all these preferences. Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Bhatia Pawan-CPB101 > Sent: Wednesday, January 28, 2004 3:23 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Configured default route or OSPF default route > > > 3COM (and now Motorola) routers also prefer static routes > over OSPF learned routes. However, there is an option to > configure a static route such that the OSPF learned route > takes precedence. > > regards, > Pawan > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > Behalf Of Acee Lindem > Sent: Tuesday, January 27, 2004 3:31 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Configured default route or OSPF default route > > > ----- Original Message ----- > From: "Abhijit Kumbhare" > To: > Sent: Tuesday, January 27, 2004 5:25 PM > Subject: Configured default route or OSPF default route > > > > Hello, > > > > If the user has not configured anything - what is the generally > > accepted default preference in most implementations - should the > > configured default route take precedence or the learned > (OSPF) default > > route? > > > > I believe Cisco uses the static (configured) default route over the > > learned default route - how do others handle it? > > Hi Abhijit, > > We, Redback, also will prefer a static route over an OSPF > learned route. I think this is the right default since the > static route is explicit. We do allow the preference (aka, > administrative distance) to be configured for individual > static routes. Additionally, we'll install the a backup OSPF > external route (default or otherwise) even if we are > advertising an external route ourselves and let the defaulted > or configued route preferences sort themselves out in RIB. If > we install an OSPF intra or inter area route, we will > discontinue advertising an OSPF external route. I think this > approach offers the most flexibility. > > Thanks, > Acee > > > > > Thanks, > > Abhijit Kumbhare > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 2 09:47:40 2004 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 JAA15506 for ; Mon, 2 Feb 2004 09:47:40 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00CC952B@cherry.ease.lsoft.com>; Mon, 2 Feb 2004 9:47:39 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 402771 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 Feb 2004 09:47:34 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 2 Feb 2004 09:47:34 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 2124160D6A0; Mon, 2 Feb 2004 06:47:34 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29989-04; Mon, 2 Feb 2004 06:47:33 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.58]) by prattle.redback.com (Postfix) with SMTP id C750D60D6A1; Mon, 2 Feb 2004 06:47:27 -0800 (PST) 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.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <075001c3e99b$76a67910$0302a8c0@aceeinspiron> Date: Mon, 2 Feb 2004 09:47:15 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: WG Last Call Completed for OSPF Version 2 Management Information Base draft-ietf-ospf-mib-update-08.txt Comments: To: Alex Zinin , Bill Fenner Comments: cc: iesg-secretary To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit The WG last call for the subject document has completed. The document will now be submitted to the routing area ADs for evaluation. The document status is Proposed Standard. ------ Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 2 13:36:54 2004 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 NAA29598 for ; Mon, 2 Feb 2004 13:36:51 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00CC9A85@cherry.ease.lsoft.com>; Mon, 2 Feb 2004 13:36:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 435273 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 Feb 2004 13:36:44 -0500 Received: from 129.188.136.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 2 Feb 2004 13:36:44 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i12IahkR005317 for ; Mon, 2 Feb 2004 11:36:43 -0700 (MST) Received: from il06exm10.corp.mot.com (il06exm10.corp.mot.com [10.0.111.10]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i12IPpIi013290 for ; Mon, 2 Feb 2004 12:25:52 -0600 Received: by il06exm10 with Internet Mail Service (5.5.2657.2) id ; Mon, 2 Feb 2004 12:26:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Message-ID: Date: Mon, 2 Feb 2004 12:26:22 -0600 Reply-To: Mailing List Sender: Mailing List From: Bhatia Pawan-CPB101 Subject: Re: Configured default route or OSPF default route To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Mukesh, In Motorola Pathbuilder routers, Static routes have the highest precedence (even higher than OSPF Internal routes). Regards, Pawan -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mukesh.Gupta@NOKIA.COM Sent: Sunday, February 01, 2004 10:45 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Configured default route or OSPF default route Acee/Pawan, When you refer to "OSPF learned routes", do you mean OSPF External routes or ALL ospf routes ? Because Nokia routers prefer all OSPF routes except the OSPF External routes over the static routers but prefer static routes over the OSPF External routes and IMHO that is a sensible thing to do. Ofcourse an administrator is allowed to changes all these preferences. Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Bhatia Pawan-CPB101 > Sent: Wednesday, January 28, 2004 3:23 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Configured default route or OSPF default route > > > 3COM (and now Motorola) routers also prefer static routes > over OSPF learned routes. However, there is an option to > configure a static route such that the OSPF learned route > takes precedence. > > regards, > Pawan > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > Behalf Of Acee Lindem > Sent: Tuesday, January 27, 2004 3:31 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Configured default route or OSPF default route > > > ----- Original Message ----- > From: "Abhijit Kumbhare" > To: > Sent: Tuesday, January 27, 2004 5:25 PM > Subject: Configured default route or OSPF default route > > > > Hello, > > > > If the user has not configured anything - what is the generally > > accepted default preference in most implementations - should the > > configured default route take precedence or the learned > (OSPF) default > > route? > > > > I believe Cisco uses the static (configured) default route over the > > learned default route - how do others handle it? > > Hi Abhijit, > > We, Redback, also will prefer a static route over an OSPF > learned route. I think this is the right default since the > static route is explicit. We do allow the preference (aka, > administrative distance) to be configured for individual > static routes. Additionally, we'll install the a backup OSPF > external route (default or otherwise) even if we are > advertising an external route ourselves and let the defaulted > or configued route preferences sort themselves out in RIB. If > we install an OSPF intra or inter area route, we will > discontinue advertising an OSPF external route. I think this > approach offers the most flexibility. > > Thanks, > Acee > > > > > Thanks, > > Abhijit Kumbhare > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 2 22:13:44 2004 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 WAA02800 for ; Mon, 2 Feb 2004 22:13:42 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00CCA436@cherry.ease.lsoft.com>; Mon, 2 Feb 2004 22:13:40 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 481462 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 Feb 2004 22:13:36 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 2 Feb 2004 22:13:36 -0500 Received: from smirtoraw2k03 (sjc-vpn3-794.cisco.com [10.21.67.26]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i133DLJ08174 for ; Mon, 2 Feb 2004 19:13:21 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Message-ID: <01d401c3ea03$b61d2270$f86445ab@amer.cisco.com> Date: Mon, 2 Feb 2004 19:13:21 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: I-D ACTION:draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit All, This draft allows to define a link in more than one area. It decouples secondary adjacencies from primary adj and use the existing interface and neighbor FSM, therefore simplifying the implementation. Comments are welcome. Thanks Sina ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF Multi-Area Adjacency Author(s) : S. Mirtorabi Filename : draft-mirtorabi-ospf-multi-area-adj-00.txt Pages : 4 Date : 2004-1-28 This memo documents an extension to OSPF to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra-area path to the corresponding areas sharing the same link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-multi-area-adj- 00.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-mirtorabi-ospf-multi-area-adj-00.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-mirtorabi-ospf-multi-area-adj-00.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. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 3 06:46:15 2004 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 GAA05248 for ; Tue, 3 Feb 2004 06:46:15 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00CCB22B@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 6:46:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 592527 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 06:46:13 -0500 Received: from 205.158.62.67 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 06:46:13 -0500 Received: from wspf1.us4.outblaze.com (wspf1.us4.outblaze.com [205.158.62.146]) by spf13.us4.outblaze.com (Postfix) with QMQP id C387B1800A97 for ; Tue, 3 Feb 2004 11:46:12 +0000 (GMT) Received: (qmail 8194 invoked from network); 3 Feb 2004 11:46:09 -0000 Received: from unknown (HELO ws5-8.us4.outblaze.com) (205.158.62.74) by wspf1.us4.outblaze.com with SMTP; 3 Feb 2004 11:46:09 -0000 Received: (qmail 1289 invoked by uid 1001); 3 Feb 2004 11:46:09 -0000 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [203.197.138.194] by ws5-8.us4.outblaze.com with http for niveda@indiainfo.com; Tue, 03 Feb 2004 17:16:09 +0530 X-Originating-Ip: 203.197.138.194 X-Originating-Server: ws5-8.us4.outblaze.com Message-ID: <20040203114609.1288.qmail@indiainfo.com> Date: Tue, 3 Feb 2004 17:16:09 +0530 Reply-To: Mailing List Sender: Mailing List From: Niveda Monyvannan Subject: Opaque support for v3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit There was long discussion with subject "OSPFV2 opaque LSAs in OSPFv3" in the OSPF mailing list. The draft with this subject from Kompella sugests the opaque LSAs type for OSPFv3. I think the draft has expired in April 2003 and there were no steps to come up with the next version. Traffic Engineering draft (draft-ietf-ospf-ospfv3-traffic-01.txt) has defined a new LSA type (Intra-Area-TE-LSA 0xa00a ) for Traffic engineering extension. It seems to be not using Opaque LSA used in OSPFv2 TE. So what is the status of Opaque extension for OSPFv3. Is there a plan to inherit the Opaque of v2 to v3 or opaque extension is not applicable with V3 as handling unknown LSAs are taken care in v3 by basic protocol design. Any light on this point is appreciated. Regards, Niveda -- ______________________________________________ IndiaInfo Mail - the free e-mail service with a difference! www.indiainfo.com Check out our value-added Premium features, such as an extra 20MB for mail storage, POP3, e-mail forwarding, and ads-free mailboxes! Powered by Outblaze From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 3 08:32:34 2004 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 IAA08144 for ; Tue, 3 Feb 2004 08:32:33 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00CCB45D@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 8:32:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 600804 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 08:32:28 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 08:32:27 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 0BC5B6C5DC4 for ; Tue, 3 Feb 2004 05:32:27 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13142-06 for ; Tue, 3 Feb 2004 05:32:26 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.4]) by prattle.redback.com (Postfix) with SMTP id 58A9B6C5DC0 for ; Tue, 3 Feb 2004 05:32:26 -0800 (PST) References: <20040203114609.1288.qmail@indiainfo.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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <007c01c3ea5a$24fb96d0$0302a8c0@aceeinspiron> Date: Tue, 3 Feb 2004 08:32:17 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Opaque support for v3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Niveda, See inline. ----- Original Message ----- From: "Niveda Monyvannan" To: Sent: Tuesday, February 03, 2004 6:46 AM Subject: Opaque support for v3 > There was long discussion with subject "OSPFV2 opaque LSAs in OSPFv3" in the OSPF mailing list. The draft with this subject from Kompella sugests the opaque LSAs type for OSPFv3. > > I think the draft has expired in April 2003 and there were no steps to come up with the next version. > > Traffic Engineering draft (draft-ietf-ospf-ospfv3-traffic-01.txt) has defined a new LSA type (Intra-Area-TE-LSA 0xa00a ) > for Traffic engineering extension. It seems to be not using Opaque LSA used in OSPFv2 TE. > > So what is the status of Opaque extension for OSPFv3. > > Is there a plan to inherit the Opaque of v2 to v3 > or > opaque extension is not applicable with V3 as handling unknown LSAs are taken care in v3 by basic protocol design. The latter. > > Any light on this point is appreciated. > > Regards, > Niveda > -- > ______________________________________________ > IndiaInfo Mail - the free e-mail service with a difference! www.indiainfo.com > Check out our value-added Premium features, such as an extra 20MB for mail storage, POP3, e-mail forwarding, and ads-free mailboxes! > > Powered by Outblaze From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 3 12:57:56 2004 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 MAA21543 for ; Tue, 3 Feb 2004 12:57:54 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00CCBB02@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 12:57:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 631520 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 12:57:49 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 12:57:49 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01L65T56MF808X9K3N@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 03 Feb 2004 09:57:46 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01L65T56MKVM8X9K3N@omega7.wr.usgs.gov> Date: Tue, 3 Feb 2004 09:57:46 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: I-D ACTION:draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Sina, Peter, Acee, Anand, Your draft is a little sketchy (Interface configuration parameters?). I suppose that is OK. Don't you need to process Hello packets differently than RFC 2328? Also when I published the draft "OSPF Multiple Area Links" sometime back, I noticed that Hello packet processing made these kinds of adjacencies seem incompatible with VLs (also TAs when area 0 is primary?) on the same ABR over the same area. I would have liked to have retained the NBMA network type for secondary adjacencies, but this draft is a big step forward. Thanks. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 3 13:22:00 2004 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 NAA22879 for ; Tue, 3 Feb 2004 13:21:59 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00CCBA59@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 13:22:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 633941 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 13:21:59 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 13:21:59 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 51931321160 for ; Tue, 3 Feb 2004 10:21:58 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14935-08 for ; Tue, 3 Feb 2004 10:21:58 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.4]) by prattle.redback.com (Postfix) with SMTP id 947A932116E for ; Tue, 3 Feb 2004 10:21:57 -0800 (PST) References: <01L65T56MKVM8X9K3N@omega7.wr.usgs.gov> 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <002801c3ea82$96d0a4d0$0302a8c0@aceeinspiron> Date: Tue, 3 Feb 2004 13:21:47 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Pat Murphy - (650)329-4044" To: Sent: Tuesday, February 03, 2004 11:57 AM Subject: I-D ACTION:draft-mirtorabi-ospf-multi-area-adj-00.txt > Sina, Peter, Acee, Anand, > > Your draft is a little sketchy (Interface configuration parameters?). I > suppose that is OK. Don't you need to process Hello packets differently > than RFC 2328? Also when I published the draft "OSPF Multiple Area > Links" sometime back, I noticed that Hello packet processing made these > kinds of adjacencies seem incompatible with VLs (also TAs when area 0 is > primary?) on the same ABR over the same area. I would have liked to have > retained the NBMA network type for secondary adjacencies, but this draft > is a big step forward. Pat, This draft is simpler than yours in that there is no relationship between the secondary adjacencies and the primary adjacency other than they share same link. Thanks, Acee > > Thanks. > > Pat From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 3 20:01:06 2004 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 UAA15475 for ; Tue, 3 Feb 2004 20:01:06 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00CCC50E@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 20:01:05 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 670620 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 20:01:03 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 20:01:03 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01L667WYBNG68X9K3N@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 03 Feb 2004 17:01:01 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: pmurphy MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01L667WYBOE08X9K3N@omega7.wr.usgs.gov> Date: Tue, 3 Feb 2004 17:01:01 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Acee, >This draft is simpler than yours in that there is no relationship between >the secondary adjacencies and the primary adjacency other than they >share same link. That was clear when I read the draft and I am not objecting to the simplification. My OSPF knowledge is getting a little stale so please be patient while I catch up. What I meant to say was don't you need to process OSPF protocol packets differently than RFC 2328 Section 8.2? No where in this section and RFC 2328's Section 1.2 definition of interface does Area Id factor into an interface definition, only addressing. What is your rationale for not updating the OSPF protocol packet processing? It sounds like, from your Section 6, that you are stretching the definition of an OSPF interface to include a configuration parameter, namely Area ID. Also I believe these unnumbered point-to-point adjacencies are incompatible with VLs. E.g. suppose a layer 2 interface is configured with Area 1 and broadcast network type plus Area 0 and point-to-point network type. If there also exists an Area 0 virtual link configured across Area 1 to another ABR several hops away, is it always possible to distinguish the Area 0 OSPF packets destined for the virtual interface from those destined for the Area 0 point-to-point interface? If not, I recommend you make the two features incompatible. VLs are pretty much useless, so its not a major point for me. As for TAs there is some feature there. You would be safe if the protocol packets arrived inside the tunnel. However its OK with me if these features are simply incompatible. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 3 20:20:40 2004 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 UAA15973 for ; Tue, 3 Feb 2004 20:20:39 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00CCC68D@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 20:20:39 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 672517 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 20:20:37 -0500 Received: from 203.199.83.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 20:20:37 -0500 Received: (qmail 27712 invoked by uid 510); 4 Feb 2004 01:20:34 -0000 Received: from unknown (128.107.253.39) by rediffmail.com via HTTP; 04 feb 2004 01:20:34 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1075857634---0-203.199.83.148-27709" Message-ID: <20040204012034.27711.qmail@webmail26.rediffmail.com> Date: Wed, 4 Feb 2004 01:20:34 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: I-D ACTION:draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1075857634---0-203.199.83.148-27709 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi,
=0ASection 3:
=0A1)ABRs will simply establish multiple adja= cencies belonging to 
=0A  different areas.
=0A
=0Avive= k> a) Routers must be OSPF ABR before attempting this adjacency.
=0A&= nbsp;         OR
=0A      b) They ca= n attempt this adjacency and become an ABR.     
=0A=0ASection 4:
=0A2)Multi-area adjacencies are configured between two ro= uters having a
=0A  common interface.
=0A
=0Avivek> a) Wh= y this statement?? Is multiple adjacency cannot be
=0A    &nb= sp;     configured between ABRs/Routers across multiple hops.
= =0A
=0A-Vivek
=0A
=0A
=0A
=0A
=0A      &nb= sp;
=0A
=0A
=0A
=0AOn Tue, 03 Feb 2004 Sina Mirtorabi wrote :=
=0A>All,
=0A>
=0A>This draft allows to define a link in = more than one area. It decouples
=0A>secondary adjacencies from prima= ry adj and use the existing interface
=0A>and neighbor FSM, therefore= simplifying the implementation.
=0A>
=0A>Comments are welcome.=
=0A>
=0A>Thanks
=0A>Sina
=0A>
=0A>
=0A>= ;----
=0A>
=0A>
=0A>A New Internet-Draft is available fro= m the on-line Internet-Drafts
=0A>directories.
=0A>
=0A><= BR>=0A>        Title        &nb= sp; : OSPF Multi-Area Adjacency
=0A>        Aut= hor(s)      : S. Mirtorabi
=0A>      &= nbsp; Filename        : draft-mirtorabi-ospf-multi-are= a-adj-00.txt
=0A>        Pages    &nbs= p;     : 4
=0A>        Date  &nb= sp;         : 2004-1-28
=0A>
=0A>This memo = documents an extension to OSPF to allow a single physical
=0A>  =   link to be shared by multiple areas. This is necessary to allow the=
=0A>    link to be considered an intra-area link in multi= ple areas.
=0A>    This would create an intra-area path to= the corresponding areas
=0A>    sharing the same link.=0A>
=0A>A URL for this Internet-Draft is:
=0A>http://www.i= etf.org/internet-drafts/draft-mirtorabi-ospf-multi-area-adj-
=0A>00.t= xt
=0A>
=0A>To remove yourself from the IETF Announcement list,= send a message to
=0A>ietf-announce-request with the word unsubscrib= e in the body of the
=0A>message.
=0A>
=0A>Internet-Draft= s are also available by anonymous FTP. Login with the
=0A>username &q= uot;anonymous" and a password of your e-mail address. After
=0A>= logging in, type "cd internet-drafts" and then
=0A>  &= nbsp;     "get draft-mirtorabi-ospf-multi-area-adj-00.txt&q= uot;.
=0A>
=0A>A list of Internet-Drafts directories can be fou= nd in
=0A>http://www.ietf.org/shadow.html
=0A>or ftp://ftp.ietf= .org/ietf/1shadow-sites.txt
=0A>
=0A>
=0A>Internet-Drafts= can also be obtained by e-mail.
=0A>
=0A>Send a message to:=0A>        mailserv@ietf.org.
=0A>In the bo= dy type:
=0A>        "FILE
=0A>/inter= net-drafts/draft-mirtorabi-ospf-multi-area-adj-00.txt".
=0A>
= =0A>NOTE:  The mail server at ietf.org can return the document in<= BR>=0A>        MIME-encoded form by using the "= ;mpack" utility.  To use this
=0A>      &nbs= p; feature, insert the command "ENCODING mime" before the "= FILE"
=0A>        command.  To decode = the response(s), you will need "munpack" or
=0A>  &nbs= p;     a MIME-compliant mail reader.  Different MIME-compli= ant mail
=0A>readers
=0A>        exhibit d= ifferent behavior, especially when dealing with
=0A>    &nb= sp;   "multipart" MIME messages (i.e. documents which have = been split
=0A>        up into multiple messages= ), so check your local documentation on
=0A>      &nbs= p; how to manipulate these messages.
=0A>
=0A>
=0A>Below= is the data which will enable a MIME compliant mail reader
=0A>imple= mentation to automatically retrieve the ASCII version of the
=0A>Inte= rnet-Draft.
=0A=0A

=0A

=0A=0A --Next_1075857634---0-203.199.83.148-27709 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=0ASection 3:=0A1)ABRs will simply establish multiple adjacencies belong= ing to =0A different areas.=0A=0Avivek> a) Routers must be OSPF ABR befor= e attempting this adjacency.=0A OR=0A b) They can attempt th= is adjacency and become an ABR. =0A=0ASection 4:=0A2)Multi-area adjac= encies are configured between two routers having a=0A common interface. = =0A=0Avivek> a) Why this statement?? Is multiple adjacency cannot be =0A = configured between ABRs/Routers across multiple hops.=0A=0A-Vivek=0A= =0A=0A=0A=0A =0A=0A=0A=0AOn Tue, 03 Feb 2004 Sina Mirtorabi wrote := =0A>All,=0A>=0A>This draft allows to define a link in more than one area. I= t decouples=0A>secondary adjacencies from primary adj and use the existing = interface=0A>and neighbor FSM, therefore simplifying the implementation.=0A= >=0A>Comments are welcome.=0A>=0A>Thanks=0A>Sina=0A>=0A>=0A>----=0A>=0A>=0A= >A New Internet-Draft is available from the on-line Internet-Drafts=0A>dire= ctories.=0A>=0A>=0A> Title : OSPF Multi-Area Adjacency=0A= > Author(s) : S. Mirtorabi=0A> Filename : draf= t-mirtorabi-ospf-multi-area-adj-00.txt=0A> Pages : 4=0A> = Date : 2004-1-28=0A>=0A>This memo documents an extension= to OSPF to allow a single physical=0A> link to be shared by multiple a= reas. This is necessary to allow the=0A> link to be considered an intra= -area link in multiple areas.=0A> This would create an intra-area path = to the corresponding areas=0A> sharing the same link.=0A>=0A>A URL for = this Internet-Draft is:=0A>http://www.ietf.org/internet-drafts/draft-mirtor= abi-ospf-multi-area-adj-=0A>00.txt=0A>=0A>To remove yourself from the IETF = Announcement list, send a message to=0A>ietf-announce-request with the word= unsubscribe in the body of the=0A>message.=0A>=0A>Internet-Drafts are also= available by anonymous FTP. Login with the=0A>username "anonymous" and a p= assword of your e-mail address. After=0A>logging in, type "cd internet-draf= ts" and then=0A> "get draft-mirtorabi-ospf-multi-area-adj-00.txt".= =0A>=0A>A list of Internet-Drafts directories can be found in=0A>http://www= .ietf.org/shadow.html=0A>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=0A>= =0A>=0A>Internet-Drafts can also be obtained by e-mail.=0A>=0A>Send a messa= ge to:=0A> mailserv@ietf.org.=0A>In the body type:=0A> "FIL= E=0A>/internet-drafts/draft-mirtorabi-ospf-multi-area-adj-00.txt".=0A>=0A>N= OTE: The mail server at ietf.org can return the document in=0A> M= IME-encoded form by using the "mpack" utility. To use this=0A> fea= ture, insert the command "ENCODING mime" before the "FILE"=0A> comm= and. To decode the response(s), you will need "munpack" or=0A> a M= IME-compliant mail reader. Different MIME-compliant mail=0A>readers=0A> = exhibit different behavior, especially when dealing with=0A> = "multipart" MIME messages (i.e. documents which have been split=0A> = up into multiple messages), so check your local documentation on=0A> = how to manipulate these messages.=0A>=0A>=0A>Below is the data which wil= l enable a MIME compliant mail reader=0A>implementation to automatically re= trieve the ASCII version of the=0A>Internet-Draft.=0A --Next_1075857634---0-203.199.83.148-27709-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 3 20:39:00 2004 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 UAA16484 for ; Tue, 3 Feb 2004 20:39:00 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00CCC79D@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 20:39:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 674543 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 20:38:55 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 20:38:55 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01L6698VV6RI8X9K3N@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 03 Feb 2004 17:38:53 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01L6698VV6R48X9K3N@omega7.wr.usgs.gov> Date: Tue, 3 Feb 2004 17:38:53 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: I-D ACTION:draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list s>Section 3: s>1)ABRs will simply establish multiple adjacencies belonging to s> different areas. v> a) Routers must be OSPF ABR before attempting this adjacency. v> OR v> b) They can attempt this adjacency and become an ABR. Multiple adjacencies can be used to stretch area 0 into an non-backbone area. Two such adjacencies could be use to build a fixed high performance backup path along the same links that are part of any non-backbone area, even NSSAs and stub areas; as opposed to VLs that can only traverse standard OSPF areas. s>Section 4: s>2)Multi-area adjacencies are configured between two routers having s> a common interface. v> a) Why this statement?? Is multiple adjacency cannot be v> configured between ABRs/Routers across multiple hops. Correct. These are standard single hop OSPF adjacencies traversing specific links with specific performance characteristics. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 3 21:34:22 2004 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 VAA18524 for ; Tue, 3 Feb 2004 21:34:22 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00CCC6EB@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 21:34:21 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 678562 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 21:34:20 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 21:34:20 -0500 Received: from smirtoraw2k03 (sjc-vpn3-16.cisco.com [10.21.64.16]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i142YJJ23639 for ; Tue, 3 Feb 2004 18:34:19 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Message-ID: <000b01c3eac7$642d7cc0$f2ce7243@amer.cisco.com> Date: Tue, 3 Feb 2004 18:34:18 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01L667WYBOE08X9K3N@omega7.wr.usgs.gov> Precedence: list Content-Transfer-Encoding: 7bit Pat, -> ->Acee, -> ->>This draft is simpler than yours in that there is no relationship ->>between the secondary adjacencies and the primary adjacency ->other than ->>they share same link. -> ->That was clear when I read the draft and I am not objecting ->to the simplification. My OSPF knowledge is getting a little ->stale so please be patient while I catch up. What I meant to ->say was don't you need to process OSPF protocol packets ->differently than RFC 2328 Section 8.2? No where in this ->section and RFC 2328's Section 1.2 definition of interface ->does Area Id factor into an interface definition, only ->addressing. What is your rationale for not updating the OSPF ->protocol packet processing? It sounds like, from your Section ->6, that you are stretching the definition of an OSPF ->interface to include a configuration parameter, namely Area ID. Area-ID is part of Interface Data Structure and is already defined to associate a packet with the corresponding area ( i.e VL). I agree with you that the packet processing need to be spelled out explicitly -> ->Also I believe these unnumbered point-to-point adjacencies ->are incompatible with VLs. E.g. suppose a layer 2 interface ->is configured with Area 1 and broadcast network type plus ->Area 0 and point-to-point network type. If there also exists ->an Area 0 virtual link configured across Area 1 to another ->ABR several hops away, is it always possible to distinguish ->the Area 0 OSPF packets destined for the virtual interface ->from those destined for the Area 0 point-to-point interface? Yes it can be distinguished, because in this case you do not have the same neighbor as the VL is multiple hop away ->If not, I recommend you make the two features incompatible. ->VLs are pretty much useless, so its not a major point for me. ->As for TAs there is some feature there. You would be safe if ->the protocol packets arrived inside the tunnel. However its ->OK with me if these features are simply incompatible. If you have a 1 hop VL configured and also configure multi-area adjacency between the _same_ neighbors then there might not be a way to associate the receiving packet to VL or multi-area adj although you could use TTL to distinguish. The question is actually why you want to use a one hop VL and also a multi-area adj between two nodes. They provide the same functionality and one should not need to configure both at the same time between the two same nodes. Sina -> ->Pat -> From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 3 22:00:58 2004 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 WAA19276 for ; Tue, 3 Feb 2004 22:00:58 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00CCC5ED@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 22:00:58 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 679894 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 22:00:57 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 22:00:57 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01L66C4KRBQO8X9R6W@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 03 Feb 2004 19:00:55 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01L66C4KRCOY8X9R6W@omega7.wr.usgs.gov> Date: Tue, 3 Feb 2004 19:00:55 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list >Yes it can be distinguished, because in this case you do not have the >same neighbor as the VL is multiple hop away Note RFC 2328 Section 8.2 OSPF protocol packet processing normally does not involve comparing neighbor IDs. You may be digging a worm hole here and I don't feel VLs are worth it. >If you have a 1 hop VL configured and also configure multi-area >adjacency between the _same_ neighbors then there might not be a way to >associate the receiving packet to VL or multi-area adj although you >could use TTL to distinguish. The question is actually why you want to >use a one hop VL and also a multi-area adj between two nodes. A better ? is why anyone would ever use a VL? However, if one was into VLs, I suppose he/she might want to build a VL to backup the shared link, hoping that, should the link break, the VL can find another multi-hop virtual path between the two nodes for area 0 transit traffic. As for why the shared link has a primary non-zero backbone area versus an area 0 primary area, that's easy. It needs to be of type other than p-t-p because of the non-backbone area's many routers that share the link's netwwork. I recommend you make the two features incompatible. Folk who use this feature probably won't use VLs. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 3 23:10:02 2004 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 XAA21234 for ; Tue, 3 Feb 2004 23:10:02 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00CCC975@cherry.ease.lsoft.com>; Tue, 3 Feb 2004 23:10:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 687088 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Feb 2004 23:00:16 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 3 Feb 2004 23:00:04 -0500 Received: from smirtoraw2k03 (sjc-vpn3-16.cisco.com [10.21.64.16]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i14402J27766 for ; Tue, 3 Feb 2004 20:00:02 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Message-ID: <000d01c3ead3$5e528050$f2ce7243@amer.cisco.com> Date: Tue, 3 Feb 2004 20:00:01 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01L66C4KRCOY8X9R6W@omega7.wr.usgs.gov> Precedence: list Content-Transfer-Encoding: 7bit Pat, ->>Yes it can be distinguished, because in this case you do not ->have the ->>same neighbor as the VL is multiple hop away -> ->Note RFC 2328 Section 8.2 OSPF protocol packet processing ->normally does not involve comparing neighbor IDs. You may be ->digging a worm hole here and I don't feel VLs are worth it. What you say above is irrelevant, Do you mean that we cannot support today two VL over the same link to two different neighbors? This is exactly the same, i.e two different neighbors -> ->>If you have a 1 hop VL configured and also configure multi-area ->>adjacency between the _same_ neighbors then there might not ->be a way to ->>associate the receiving packet to VL or multi-area adj although you ->>could use TTL to distinguish. The question is actually why ->you want to ->>use a one hop VL and also a multi-area adj between two nodes. -> ->A better ? is why anyone would ever use a VL? However, if one ->was into VLs, I suppose he/she might want to build a VL to ->backup the shared link, hoping that, should the link break, ->the VL can find another multi-hop virtual path between the ->two nodes for area 0 transit traffic. As for why the shared ->link has a primary non-zero backbone area versus an area 0 ->primary area, that's easy. It needs to be of type other than ->p-t-p because of the non-backbone area's many routers that ->share the link's netwwork. -> ->I recommend you make the two features incompatible. Folk who ->use this feature probably won't use VLs. There is no incompatibility in general except when you configure VL and multi-area adj between the _same_ neighbors (which further can happen only if your VL is single hop). In all case this should be handled at the configuration level and not OSPF packet processing. Sina From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 4 09:02:55 2004 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 JAA05943 for ; Wed, 4 Feb 2004 09:02:54 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00CCD41D@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 9:02:53 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 763371 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 09:02:50 -0500 Received: from 203.199.83.147 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 08:52:50 -0500 Received: (qmail 32039 invoked by uid 510); 4 Feb 2004 13:19:25 -0000 Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 04 feb 2004 13:19:25 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1075900765---0-203.199.83.147-32035" Message-ID: <20040204131925.32038.qmail@webmail25.rediffmail.com> Date: Wed, 4 Feb 2004 13:19:25 -0000 Reply-To: Mailing List Sender: Mailing List From: query OSPF Subject: forwarding address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1075900765---0-203.199.83.147-32035 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AI have one doubt
=0Aregarding AS external routes. In section 16.4,= step (3), it says that "If
=0Athe forwarding address is non-zero, = look up the forwarding address in the
=0Arouting table. The matching rou= ting table entry must specify an intra-area
=0Aor inter-area path; if no= such path exists, do nothing with the LSA and
=0Aconsider the next in t= he list". And in section 12.4.4.1, it says that "Note
=0Athat = when the forwarding address field is non-zero, it should point to a
=0Ar= outer belonging to another Autonomous System". My question is: if the<= BR>=0Aforwarding address points to a router in another AS, how can you get = an
=0Aintra-area or inter-area route to it?
=0A
=0Aregards
=0A<= BR>=0A=0A

=0A

=0A=0A --Next_1075900765---0-203.199.83.147-32035 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have one doubt=0Aregarding AS external routes. In section 16.4, step (3),= it says that "If=0Athe forwarding address is non-zero, look up the forward= ing address in the=0Arouting table. The matching routing table entry must s= pecify an intra-area=0Aor inter-area path; if no such path exists, do nothi= ng with the LSA and=0Aconsider the next in the list". And in section 12.4.4= .1, it says that "Note=0Athat when the forwarding address field is non-zero= , it should point to a=0Arouter belonging to another Autonomous System". My= question is: if the=0Aforwarding address points to a router in another AS,= how can you get an=0Aintra-area or inter-area route to it?=0A=0Aregards=0A= =0A --Next_1075900765---0-203.199.83.147-32035-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 4 09:15:17 2004 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 JAA06630 for ; Wed, 4 Feb 2004 09:15:16 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00CCD605@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 9:15:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 765583 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 09:15:14 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 09:15:14 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 3A4971453CB for ; Wed, 4 Feb 2004 06:15:14 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14531-09 for ; Wed, 4 Feb 2004 06:15:13 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.4]) by prattle.redback.com (Postfix) with SMTP id 765541453C6 for ; Wed, 4 Feb 2004 06:15:13 -0800 (PST) References: <20040204131925.32038.qmail@webmail25.rediffmail.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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <01be01c3eb29$481443e0$0302a8c0@aceeinspiron> Date: Wed, 4 Feb 2004 09:15:02 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: forwarding address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit First of all, please refrain from using rich text messages on the list. They are more difficult to handle. ----- Original Message ----- From: query OSPF To: OSPF@PEACH.EASE.LSOFT.COM Sent: Wednesday, February 04, 2004 8:19 AM Subject: forwarding address > I have one doubt > regarding AS external routes. In section 16.4, step (3), it says that "If > the forwarding address is non-zero, look up the forwarding address in the > routing table. The matching routing table entry must specify an intra-area > or inter-area path; if no such path exists, do nothing with the LSA and > consider the next in the list". And in section 12.4.4.1, it says that "Note > that when the forwarding address field is non-zero, it should point to a > router belonging to another Autonomous System". My question is: if the > forwarding address points to a router in another AS, how can you get an > intra-area or inter-area route to it? If the ASBR's next-hop router has an interface on a multi-access network that is part of the OSPF routing domain. Refer to the discussion of "forwarding address" in section 2.3 or RFC 2328. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 4 09:23:13 2004 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 JAA07087 for ; Wed, 4 Feb 2004 09:23:13 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00CCD5F8@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 9:23:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 766004 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 09:23:11 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 09:23:11 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A93CC1453CD for ; Wed, 4 Feb 2004 06:23:10 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15535-08 for ; Wed, 4 Feb 2004 06:23:10 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.4]) by prattle.redback.com (Postfix) with SMTP id B6C201453C9 for ; Wed, 4 Feb 2004 06:23:09 -0800 (PST) References: <20040204012034.27711.qmail@webmail26.rediffmail.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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <01ef01c3eb2a$63eff590$0302a8c0@aceeinspiron> Date: Wed, 4 Feb 2004 09:22:58 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit More rich text... ----- Original Message ----- From: Vivek Dubey To: OSPF@PEACH.EASE.LSOFT.COM Sent: Tuesday, February 03, 2004 8:20 PM Subject: Re: I-D ACTION:draft-mirtorabi-ospf-multi-area-adj-00.txt > Hi, > Section 3: > 1)ABRs will simply establish multiple adjacencies belonging to > different areas. > vivek> a) Routers must be OSPF ABR before attempting this adjacency. > OR > b) They can attempt this adjacency and become an ABR. I would say neither. I router is an ABR by virtue of attaching to multiple areas (RFC 2328). The multi-area adjacency function is only applicable to ABRs. > Section 4: > 2)Multi-area adjacencies are configured between two routers having a > common interface. > vivek> a) Why this statement?? Is multiple adjacency cannot be > configured between ABRs/Routers across multiple hops. No. This is simply a machism to allow a single physical link to be part of the topology in multiple areas. -Vivek On Tue, 03 Feb 2004 Sina Mirtorabi wrote : >All, > >This draft allows to define a link in more than one area. It decouples >secondary adjacencies from primary adj and use the existing interface >and neighbor FSM, therefore simplifying the implementation. > >Comments are welcome. > >Thanks >Sina > > >---- > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : OSPF Multi-Area Adjacency > Author(s) : S. Mirtorabi > Filename : draft-mirtorabi-ospf-multi-area-adj-00.txt > Pages : 4 > Date : 2004-1-28 > >This memo documents an extension to OSPF to allow a single physical > link to be shared by multiple areas. This is necessary to allow the > link to be considered an intra-area link in multiple areas. > This would create an intra-area path to the corresponding areas > sharing the same link. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-multi-area-adj- >00.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-mirtorabi-ospf-multi-area-adj-00.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-mirtorabi-ospf-multi-area-adj-00.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. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 4 09:48:11 2004 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 JAA07749 for ; Wed, 4 Feb 2004 09:48:09 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00CCD604@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 9:48:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 768204 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 09:48:07 -0500 Received: from 32.97.110.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 09:48:07 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i14Em2pZ593294 for ; Wed, 4 Feb 2004 09:48:03 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i14Em2OA124960 for ; Wed, 4 Feb 2004 07:48:02 -0700 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 02/04/2004 07:48:01, Serialize complete at 02/04/2004 07:48:01 Content-Type: multipart/alternative; boundary="=_alternative 00512FF385256E30_=" Message-ID: Date: Wed, 4 Feb 2004 09:48:00 -0500 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Re: forwarding address To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01be01c3eb29$481443e0$0302a8c0@aceeinspiron> Precedence: list This is a multipart message in MIME format. --=_alternative 00512FF385256E30_= Content-Type: text/plain; charset="US-ASCII" Acee wrote: > If the ASBR's next-hop router has an interface on a multi-access network > that is part of the OSPF routing domain. Refer to the discussion of "forwarding > address" in section 2.3 or RFC 2328. I've asked this same question on this list and got this same answer. I still don't like it though, because I thought the point of the forwarding address was to advertise a default route on behalf of a router who can't advertise it himself. If the default router has an interface that's part of the OSPF domain, then he can advertise himself as default router and no forwarding address is needed, IMO. However the response to my objection is that if the forwarding address is an external address, there's no guarantee that other OSPF routers can reach it. Kind of a catch-22: the only time it's really needed is the time you can't be sure it can be reached. Mike ----------------------------------------------------------------------- Enterprise Network Solutions ----------------------------------------------------------------------- Research Triangle Park, NC USA/ --=_alternative 00512FF385256E30_= Content-Type: text/html; charset="US-ASCII"
Acee wrote:

> If the ASBR's next-hop router has an interface on a multi-access network
> that is part of the OSPF routing domain. Refer to the discussion of "forwarding
> address" in section 2.3 or RFC 2328.
I've asked this same question on this list and got this same answer.  I still don't like it though, because I thought the point of the forwarding address was to advertise a default route on behalf of a router who can't advertise it himself.  If the default router has an interface that's part of the OSPF domain, then he can advertise himself as default router and no forwarding address is needed, IMO.   However the response to my objection is that if the forwarding address is an external address, there's no guarantee that other OSPF routers can reach it.  Kind of a catch-22: the only time it's really needed is the time you can't be sure it can be reached.

Mike
-----------------------------------------------------------------------
Enterprise Network Solutions
-----------------------------------------------------------------------
Research Triangle Park, NC  USA/
--=_alternative 00512FF385256E30_=-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 4 10:09:05 2004 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 KAA09184 for ; Wed, 4 Feb 2004 10:09:04 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00CCD6C4@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 10:09:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 770021 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 10:09:01 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 10:09:01 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 3BA351453D1 for ; Wed, 4 Feb 2004 07:09:01 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22055-03 for ; Wed, 4 Feb 2004 07:09:00 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.4]) by prattle.redback.com (Postfix) with SMTP id E1C6A1453D0 for ; Wed, 4 Feb 2004 07:08:59 -0800 (PST) References: <000d01c3ead3$5e528050$f2ce7243@amer.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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <021901c3eb30$cb1d79d0$0302a8c0@aceeinspiron> Date: Wed, 4 Feb 2004 10:08:48 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sina, Pat, In summary, 1. We need to document that changes to packet processing to use area ID for determining the interface corresponding to a packet. 2. There is ambiguity in demuxing the packet if one defines a virtual link in same area as an interface with a both a backbone adjacency and a transit area adjacency (assuming this is the best path through the transit area). Solutions Include: 1. Using other fields in the OSPF or IP packet header to determine the appropriate interface. 2. Don't bring up the virtual link if the best path is over a P2P interface associated with a multi-area adjacency (this could be done by flagging the router route during the transit area's intra-area SPF). 3. Add configuration checking to disallow a virtual link in an area with a multi-area adjacency shared with the backbone. 4. Simply document the problem and tell people not to do it (this probably isn't good since the hello packets for the virtual link will be associated with the backbone and most likely prevent an adjacency from being formed over either path). I like #2 or #3. I don't really like #1 since I can't come up with a solution that works for packet types other than hello. Thanks, Acee ----- Original Message ----- From: "Sina Mirtorabi" To: Sent: Tuesday, February 03, 2004 11:00 PM Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt > Pat, > > ->>Yes it can be distinguished, because in this case you do not > ->have the > ->>same neighbor as the VL is multiple hop away > -> > ->Note RFC 2328 Section 8.2 OSPF protocol packet processing > ->normally does not involve comparing neighbor IDs. You may be > ->digging a worm hole here and I don't feel VLs are worth it. > > What you say above is irrelevant, Do you mean that we cannot support > today two VL over the same link to two different neighbors? This is > exactly the same, i.e two different neighbors > > -> > ->>If you have a 1 hop VL configured and also configure multi-area > ->>adjacency between the _same_ neighbors then there might not > ->be a way to > ->>associate the receiving packet to VL or multi-area adj although you > ->>could use TTL to distinguish. The question is actually why > ->you want to > ->>use a one hop VL and also a multi-area adj between two nodes. > -> > ->A better ? is why anyone would ever use a VL? However, if one > ->was into VLs, I suppose he/she might want to build a VL to > ->backup the shared link, hoping that, should the link break, > ->the VL can find another multi-hop virtual path between the > ->two nodes for area 0 transit traffic. As for why the shared > ->link has a primary non-zero backbone area versus an area 0 > ->primary area, that's easy. It needs to be of type other than > ->p-t-p because of the non-backbone area's many routers that > ->share the link's netwwork. > -> > ->I recommend you make the two features incompatible. Folk who > ->use this feature probably won't use VLs. > > There is no incompatibility in general except when you configure VL and > multi-area adj between the _same_ neighbors (which further can happen > only if your VL is single hop). In all case this should be handled at > the configuration level and not OSPF packet processing. > > Sina From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 4 11:24:20 2004 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 LAA13029 for ; Wed, 4 Feb 2004 11:24:19 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00CCD835@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 11:24:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 776030 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 11:24:17 -0500 Received: from 132.177.123.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 11:14:17 -0500 Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by io.iol.unh.edu (8.12.11/8.12.11) with ESMTP id i14GBDIn013555 for ; Wed, 4 Feb 2004 11:11:13 -0500 Received: (from apache@localhost) by io.iol.unh.edu (8.12.11/8.12.11/Submit) id i14GBDN4013554 for ospf@peach.ease.lsoft.com; Wed, 4 Feb 2004 11:11:13 -0500 X-Authentication-Warning: io.iol.unh.edu: apache set sender to bahill@iol.unh.edu using -f Received: from allegro.iol.unh.edu (allegro.iol.unh.edu [132.177.118.50]) by webmail.iol.unh.edu (IMP) with HTTP for ; Wed, 4 Feb 2004 11:11:13 -0500 References: <4021089D.6080400@iol.unh.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 132.177.118.50 X-MailScanner-Information: Please contact systems@iol.unh.edu for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-99.715, required 5, NO_REAL_NAME 0.28, USER_IN_WHITELIST -100.00) Message-ID: <1075911073.64c48d1e7ca80@webmail.iol.unh.edu> Date: Wed, 4 Feb 2004 11:11:13 -0500 Reply-To: Mailing List Sender: Mailing List From: Barbara Hill Subject: Re: forwarding address To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4021089D.6080400@iol.unh.edu> Precedence: list Content-Transfer-Encoding: 7bit Mike wrote : >I thought the point of the forwarding >address was to advertise a default route on behalf of a router who can't >advertise it himself. The point of a default route is to advertise the most appropriate next-hop for the external destination advertised in the as-external-lsa. Thus, a forwarding route could specify a default route (0.0.0.0), if you wish to advertise the router itself as the best next hop for that as-external destination to the domain. However, if you wish to specify a specific route to an external destination, it would advertise the best hop to reach that destination. Such a situation is discussed in detail in RFC 2328, sections 2.3 and 12.4.4.1. Additional information, concerning the use of as-external-lsas and the use of default routes vs specific forwarding addresses, can be found in section 16.4 and Appendix A.4.5 I have included these excerpts for your reference. 2.3 This section has assumed that packets destined for external destinations are always routed through the advertising AS boundary router. This is not always desirable. For example, suppose in Figure 2 there is an additional router attached to Network N6, called Router RTX. Suppose further that RTX does not participate in OSPF routing, but does exchange BGP information with the AS boundary router RT7. Then, Router RT7 would end up advertising OSPF external routes for all destinations that should be routed to RTX. An extra hop will sometimes be introduced if packets for these destinations need always be routed first to Router RT7 (the advertising router). To deal with this situation, the OSPF protocol allows an AS boundary router to specify a "forwarding address" in its AS- external-LSAs. In the above example, Router RT7 would specify RTX's IP address as the "forwarding address" for all those destinations whose packets should be routed directly to RTX. The "forwarding address" has one other application. It enables routers in the Autonomous System's interior to function as "route servers". For example, in Figure 2 the router RT6 could become a route server, gaining external routing information through a combination of static configuration and external routing protocols. RT6 would then start advertising itself as an AS boundary router, and would originate a collection of OSPF AS-external-LSAs. In each AS-external-LSA, Router RT6 would specify the correct Autonomous System exit point to use for the destination through appropriate setting of the LSA's "forwarding address" field. + | 3+---+ N12 N14 N1|--|RT1|\ 1 \ N13 / | +---+ \ 8\ |8/8 + \ ____ \|/ / \ 1+---+8 8+---+6 * N3 *---|RT4|------|RT5|--------+ \____/ +---+ +---+ | + / | |7 | | 3+---+ / | | | N2|--|RT2|/1 |1 |6 | | +---+ +---+8 6+---+ | + |RT3|--------------|RT6| | +---+ +---+ | |2 Ia|7 | | | | +---------+ | | N4 | | | | | | N11 | | +---------+ | | | | | N12 |3 | |6 2/ +---+ | +---+/ |RT9| | |RT7|---N15 +---+ | +---+ 9 |1 + | |1 _|__ | Ib|5 __|_ / \ 1+----+2 | 3+----+1 / \ * N9 *------|RT11|----|---|RT10|---* N6 * \____/ +----+ | +----+ \____/ | | | |1 + |1 +--+ 10+----+ N8 +---+ |H1|-----|RT12| |RT8| +--+SLIP +----+ +---+ |2 |4 | | +---------+ +--------+ N10 N7 Figure 2: A sample Autonomous System 12.4.4.1. Examples of AS-external-LSAs Consider once again the AS pictured in Figure 6. There are two AS boundary routers: RT5 and RT7. Router RT5 originates three AS-external-LSAs, for networks N12-N14. Router RT7 originates two AS-external-LSAs, for networks N12 and N15. Assume that RT7 has learned its route to N12 via BGP, and that it wishes to advertise a Type 2 metric to the AS. RT7 would then originate the following LSA for N12: ; AS-external-LSA for Network N12, ; originated by Router RT7 LS age = 0 ;always true on origination Options = (E-bit) ; LS type = 5 ;AS-external-LSA Link State ID = N12's IP network number Advertising Router = Router RT7's ID bit E = 1 ;Type 2 metric metric = 2 Forwarding address = 0.0.0.0 In the above example, the forwarding address field has been set to 0.0.0.0, indicating that packets for the external destination should be forwarded to the advertising OSPF router (RT7). This is not always desirable. Consider the example pictured in Figure 16. There are three OSPF routers (RTA, RTB and RTC) connected to a common network. Only one of these routers, RTA, is exchanging BGP information with the non-OSPF router RTX. RTA must then originate AS- external-LSAs for those destinations it has learned from RTX. By using the AS-external-LSA's forwarding address field, RTA can specify that packets for these destinations be forwarded directly to RTX. Without this feature, Routers RTB and RTC would take an extra hop to get to these destinations. Note that when the forwarding address field is non- zero, it should point to a router belonging to another Autonomous System. A forwarding address can also be specified for the default route. For example, in figure 16 RTA may want to specify that all externally-destined packets should by default be forwarded to its BGP peer RTX. The resulting AS-external-LSA is pictured below. Note that the Link State ID is set to DefaultDestination. ; Default route, originated by Router RTA ; Packets forwarded through RTX LS age = 0 ;always true on origination Options = (E-bit) ; LS type = 5 ;AS-external-LSA Link State ID = DefaultDestination ; default route Advertising Router = Router RTA's ID bit E = 1 ;Type 2 metric metric = 1 Forwarding address = RTX's IP address 16.4 AS external routes are calculated by examining AS-external-LSAs. Each of the AS-external-LSAs is considered in turn. Most AS- external-LSAs describe routes to specific IP destinations. An AS-external-LSA can also describe a default route for the Autonomous System (Destination ID = DefaultDestination, network/subnet mask = 0x00000000). For each AS-external-LSA: (3) Call the destination described by the LSA N. 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. Look up the routing table entries (potentially one per attached area) for the AS boundary router (ASBR) that originated the LSA. If no entries exist for router ASBR (i.e., ASBR is unreachable), do nothing with this LSA and consider the next in the list. Else, this LSA describes an AS external path to destination N. Examine the forwarding address specified in the AS- external-LSA. This indicates the IP address to which packets for the destination should be forwarded. If the forwarding address is set to 0.0.0.0, packets should be sent to the ASBR itself. Among the multiple routing table entries for the ASBR, select the preferred entry as follows. If RFC1583Compatibility is set to "disabled", prune the set of routing table entries for the ASBR as described in Section 16.4.1. In any case, among the remaining routing table entries, select the routing table entry with the least cost; when there are multiple least cost routing table entries the entry whose associated area has the largest OSPF Area ID (when considered as an unsigned 32-bit integer) is chosen. If the forwarding address is non-zero, look up the forwarding address in the routing table.[24] The matching routing table entry must specify an intra-area or inter-area path; if no such path exists, do nothing with the LSA and consider the next in the list. A.4.5 AS-external-LSAs usually describe a particular external destination. For these LSAs the Link State ID field specifies an IP network number (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E for details). AS- external-LSAs are also used to describe a default route. Default routes are used when no specific route exists to the destination. Forwarding address Data traffic for the advertised destination will be forwarded to this address. If the Forwarding address is set to 0.0.0.0, data traffic will be forwarded instead to the LSA's originator (i.e., the responsible AS boundary router). -Barbara Hill InterOperability Lab at UNH Durham, NH Acee wrote: > If the ASBR's next-hop router has an interface on a multi-access network > that is part of the OSPF routing domain. Refer to the discussion of "forwarding > address" in section 2.3 or RFC 2328. I've asked this same question on this list and got this same answer. I still don't like it though, because I thought the point of the forwarding address was to advertise a default route on behalf of a router who can't advertise it himself. If the default router has an interface that's part of the OSPF domain, then he can advertise himself as default router and no forwarding address is needed, IMO. However the response to my objection is that if the forwarding address is an external address, there's no guarantee that other OSPF routers can reach it. Kind of a catch-22: the only time it's really needed is the time you can't be sure it can be reached. Mike ----------------------------------------------------------------------- Enterprise Network Solutions ----------------------------------------------------------------------- Research Triangle Park, NC USA/ From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 4 12:24:48 2004 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 MAA15554 for ; Wed, 4 Feb 2004 12:24:48 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00CCD9C2@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 12:24:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 782161 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 12:24:43 -0500 Received: from 65.54.247.115 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 12:24:43 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Feb 2004 09:24:42 -0800 Received: from 64.221.212.137 by by2fd.bay2.hotmail.msn.com with HTTP; Wed, 04 Feb 2004 17:24:42 GMT X-Originating-IP: [64.221.212.137] X-Originating-Email: [virgink@hotmail.com] X-Sender: virgink@hotmail.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 04 Feb 2004 17:24:42.0618 (UTC) FILETIME=[C6BDF5A0:01C3EB43] Message-ID: Date: Wed, 4 Feb 2004 17:24:42 +0000 Reply-To: Mailing List Sender: Mailing List From: Ajay Virginkar Subject: Re: forwarding address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list You could use passive OSPF interfaces though. >From: Mike Fox >Reply-To: Mailing List >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: forwarding address >Date: Wed, 4 Feb 2004 09:48:00 -0500 > >Acee wrote: > > > If the ASBR's next-hop router has an interface on a multi-access network > > that is part of the OSPF routing domain. Refer to the discussion of >"forwarding > > address" in section 2.3 or RFC 2328. > >I've asked this same question on this list and got this same answer. I >still don't like it though, because I thought the point of the forwarding >address was to advertise a default route on behalf of a router who can't >advertise it himself. If the default router has an interface that's part >of the OSPF domain, then he can advertise himself as default router and no >forwarding address is needed, IMO. However the response to my objection >is that if the forwarding address is an external address, there's no >guarantee that other OSPF routers can reach it. Kind of a catch-22: the >only time it's really needed is the time you can't be sure it can be >reached. > >Mike >----------------------------------------------------------------------- >Enterprise Network Solutions >----------------------------------------------------------------------- >Research Triangle Park, NC USA/ _________________________________________________________________ Get a FREE online virus check for your PC here, from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 4 13:04:17 2004 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 NAA18070 for ; Wed, 4 Feb 2004 13:04:16 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00CCD876@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 13:04:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 785723 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 13:04:15 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 13:04:15 -0500 Received: from smirtoraw2k03 (dhcp-171-69-100-248.cisco.com [171.69.100.248]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i14I4FJ00551 for ; Wed, 4 Feb 2004 10:04:15 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Message-ID: <000a01c3eb49$4ce80580$f86445ab@amer.cisco.com> Date: Wed, 4 Feb 2004 10:04:15 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <021901c3eb30$cb1d79d0$0302a8c0@aceeinspiron> Precedence: list Content-Transfer-Encoding: 7bit Acee, ->Sina, Pat, -> ->In summary, -> -> 1. We need to document that changes to packet processing -> to use area ID for determining the interface corresponding -> to a packet. -> -> 2. There is ambiguity in demuxing the packet if one defines a -> virtual link in same area as an interface with a both a -> backbone adjacency and a transit area adjacency (assuming -> this is the best path through the transit area). -> -> Solutions Include: -> -> 1. Using other fields in the OSPF or IP packet header to -> determine the appropriate interface. -> 2. Don't bring up the virtual link if the best path is over -> a P2P interface associated with a multi-area ->adjacency (this -> could be done by flagging the router route ->during the transit -> area's intra-area SPF). -> 3. Add configuration checking to disallow a virtual ->link in an -> area with a multi-area adjacency shared with the ->backbone. -> 4. Simply document the problem and tell people not ->to do it (this -> probably isn't good since the hello packets for ->the virtual link -> will be associated with the backbone and most likely -> prevent an adjacency from being formed over either path). -> -> I like #2 or #3. I don't really like #1 since I can't come up -> with a solution that works for packet types other than hello. The potential conflict can happen ( assuming there is VL and multi-area adj between the same neighbor) as a result of a conflicting configuration. Therefore option #3 looks to me the natural and easiest place to handle this. The prevention of such a conflicting configuration is totally acceptable as multi-area adj and single hop VL provide the same functionality... Thanks Sina -> -> -> ->Thanks, ->Acee -> ->----- Original Message ----- ->From: "Sina Mirtorabi" ->To: ->Sent: Tuesday, February 03, 2004 11:00 PM ->Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt -> -> ->> Pat, ->> ->> ->>Yes it can be distinguished, because in this case you do not ->> ->have the ->> ->>same neighbor as the VL is multiple hop away ->> -> ->> ->Note RFC 2328 Section 8.2 OSPF protocol packet processing ->normally ->> ->does not involve comparing neighbor IDs. You may be ->digging a worm ->> ->hole here and I don't feel VLs are worth it. ->> ->> What you say above is irrelevant, Do you mean that we ->cannot support ->> today two VL over the same link to two different neighbors? This is ->> exactly the same, i.e two different neighbors ->> ->> -> ->> ->>If you have a 1 hop VL configured and also configure multi-area ->> ->>adjacency between the _same_ neighbors then there might not ->> ->be a way to ->> ->>associate the receiving packet to VL or multi-area adj ->although you ->> ->>could use TTL to distinguish. The question is actually why ->> ->you want to ->> ->>use a one hop VL and also a multi-area adj between two nodes. ->> -> ->> ->A better ? is why anyone would ever use a VL? However, if one was ->> ->into VLs, I suppose he/she might want to build a VL to backup the ->> ->shared link, hoping that, should the link break, the VL can find ->> ->another multi-hop virtual path between the two nodes for area 0 ->> ->transit traffic. As for why the shared link has a primary ->non-zero ->> ->backbone area versus an area 0 primary area, that's easy. ->It needs ->> ->to be of type other than p-t-p because of the non-backbone area's ->> ->many routers that share the link's netwwork. ->> -> ->> ->I recommend you make the two features incompatible. Folk who use ->> ->this feature probably won't use VLs. ->> ->> There is no incompatibility in general except when you configure VL ->> and multi-area adj between the _same_ neighbors (which further can ->> happen only if your VL is single hop). In all case this should be ->> handled at the configuration level and not OSPF packet processing. ->> ->> Sina -> From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 4 13:36:00 2004 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 NAA19531 for ; Wed, 4 Feb 2004 13:36:00 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00CCDB08@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 13:35:59 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 788414 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 13:35:57 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 13:35:57 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01L678RTVX348X9KOS@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Feb 2004 10:35:56 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: pmurphy MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01L678RTVYZ68X9KOS@omega7.wr.usgs.gov> Date: Wed, 4 Feb 2004 10:35:56 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Sina, Note it is important to be able to cost a multi-area adjency differently for each area, plus set the authentication parameters. I don't see a need to tweak the interval/delay timers??? As for, >->Note RFC 2328 Section 8.2 OSPF protocol packet processing >->normally does not involve comparing neighbor IDs. >Do you mean that we cannot support >today two VL over the same link to two different neighbors? Currently VL OSPF protocol packets are accepted in 8.2 step (2) regardless of who the neighbor is. ->A better ? is why anyone would ever use a VL? However, if one ->was into VLs, I suppose he/she might want to build a VL to ->backup the shared link, hoping that, should the link break, ->the VL can find another multi-hop virtual path between the ->two nodes for area 0 transit traffic. As for why the shared ->link has a primary non-zero backbone area versus an area 0 ->primary area, that's easy. It needs to be of type other than ->p-t-p because of the non-backbone area's many routers that ->share the link's netwwork. Actually this is a weak example unless the transit area has equal cost multipaths between the two neighbors available for the VL that includes a single hop path carrying a multi-area adjacency. Costing of the VL and the MA also plays a role. My ignorance is showing here. I have only found one useful application of VLs; and it wasn't partition repair. >In all case this should be handled at >the configuration level and not OSPF packet processing. I don't recommend trying to make this work by tweaking OSPF packet processing. I was recommending that you don't allow the configuration of MAs and VLs over the same transit area on the same ABR. Subtle incompatibilities are often overlooked by network implementors. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 4 13:41:52 2004 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 NAA19780 for ; Wed, 4 Feb 2004 13:41:52 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00CCDBDB@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 13:41:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 793220 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 13:41:50 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 13:41:50 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01L678Z489PY8X9KOS@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Feb 2004 10:41:48 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01L678Z489Q08X9KOS@omega7.wr.usgs.gov> Date: Wed, 4 Feb 2004 10:41:48 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Acee, MY preference is the following in order of preference: 3. Add configuration checking to disallow a virtual link in an area with a multi-area adjacency shared with the backbone. 2. Don't bring up the virtual link if the best path is over a P2P interface associated with a multi-area adjacency (this could be done by flagging the router route during the transit area's intra-area SPF). as 3 seems easier to do. Also 2 might trojan a confusing anomaly for NOCs. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 4 20:10:47 2004 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 UAA11963 for ; Wed, 4 Feb 2004 20:10:47 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00CCE518@cherry.ease.lsoft.com>; Wed, 4 Feb 2004 20:10:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 835221 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Feb 2004 20:10:45 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 4 Feb 2004 20:10:45 -0500 Received: from smirtoraw2k03 (sjc-vpn2-239.cisco.com [10.21.112.239]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i151AhJ04513 for ; Wed, 4 Feb 2004 17:10:43 -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.4927.1200 Message-ID: <00cb01c3eb84$e0ddd270$f2ce7243@amer.cisco.com> Date: Wed, 4 Feb 2004 17:10:43 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01L678RTVYZ68X9KOS@omega7.wr.usgs.gov> Precedence: list Content-Transfer-Encoding: 7bit Pat, -> ->Sina, -> ->Note it is important to be able to cost a multi-area adjency ->differently for each area, plus set the authentication ->parameters. I don't see a need to tweak the interval/delay timers??? Sure, each multi-area adj will have its own Interface data structure -> ->As for, -> ->>->Note RFC 2328 Section 8.2 OSPF protocol packet processing normally ->>->does not involve comparing neighbor IDs. -> ->>Do you mean that we cannot support ->>today two VL over the same link to two different neighbors? -> ->Currently VL OSPF protocol packets are accepted in 8.2 step ->(2) regardless of who the neighbor is. You should be looking at the beginning of the section 8.2 where we do validity check for IP and OSPF header. Further it states if the packet is Hello it should be processed as in section 10.5 where you do consider an active neighbor or create one based on IP address or neighbor router ID. When your receive a packet you do associate it with a neighbor therefore it is implicit that if you have different neighbor there is no conflict.... ->>In all case this should be handled at ->>the configuration level and not OSPF packet processing. -> ->I don't recommend trying to make this work by tweaking OSPF ->packet processing. I was recommending that you don't allow ->the configuration of MAs and VLs over the same transit area ->on the same ABR. Ok so we are in agreement that this should be handled at the config level Sina From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 5 06:40:17 2004 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 GAA12066 for ; Thu, 5 Feb 2004 06:40:17 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00CCF411@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 6:40:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 912022 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 06:40:08 -0500 Received: from 203.199.83.248 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 06:40:06 -0500 Received: (qmail 19588 invoked by uid 510); 5 Feb 2004 11:38:42 -0000 Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 05 feb 2004 11:38:42 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1075981122---0-203.199.83.248-19585" Message-ID: <20040205113842.19587.qmail@webmail36.rediffmail.com> Date: Thu, 5 Feb 2004 11:38:42 -0000 Reply-To: Mailing List Sender: Mailing List From: query OSPF Subject: Priority in Link Lsa To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1075981122---0-203.199.83.248-19585 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0A
=0AFor OSPFv3, why is the router priority specified on the link-L= SA in addition to the hello packets?
=0A
=0Asame question is asked by= mike but don't find any answer?
=0A
=0Aregards
=0AManish
=0A<= BR>=0A
=0A=0A

=0A

=0A=0A --Next_1075981122---0-203.199.83.248-19585 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =0AFor OSPFv3, why is the router priority specified on the link-LSA in addi= tion to the hello packets?=0A=0Asame question is asked by mike but don't fi= nd any answer?=0A=0Aregards=0AManish =0A=0A=0A --Next_1075981122---0-203.199.83.248-19585-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 5 08:11:43 2004 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 IAA14432 for ; Thu, 5 Feb 2004 08:11:43 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00CCF5B4@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 8:11:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 921726 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 08:11:40 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 08:11:40 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A8D4F18A5A5 for ; Thu, 5 Feb 2004 05:11:39 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11124-09 for ; Thu, 5 Feb 2004 05:11:39 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.25]) by prattle.redback.com (Postfix) with SMTP id DFAD918A5AB for ; Thu, 5 Feb 2004 05:11:38 -0800 (PST) References: <20040205113842.19587.qmail@webmail36.rediffmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C3EBBF.ACD384D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <003101c3ebe9$962ffae0$0302a8c0@aceeinspiron> Date: Thu, 5 Feb 2004 08:11:36 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Priority in Link Lsa To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C3EBBF.ACD384D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Manish, I don't see any reason. I don't use it in my implementation (other than setting it, using it to determine if a link LSA has changed, and=20 displaying it.=20 Thanks, Acee =20 ----- Original Message -----=20 From: query OSPF=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Thursday, February 05, 2004 6:38 AM Subject: Priority in Link Lsa For OSPFv3, why is the router priority specified on the link-LSA in = addition to the hello packets? same question is asked by mike but don't find any answer? regards Manish=20 ------=_NextPart_000_002E_01C3EBBF.ACD384D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Manish,
 
I don't see any reason. I don't = use it in my=20 implementation (other
than setting it, using it to determine = if a link=20 LSA has changed, and
displaying it.
 
Thanks,
Acee  
----- Original Message -----
From:=20 query=20 OSPF
Sent: Thursday, February 05, = 2004 6:38=20 AM
Subject: Priority in Link = Lsa


For OSPFv3, why is the router priority specified on the = link-LSA in=20 addition to the hello packets?

same question is asked by mike = but don't=20 find any answer?

regards
Manish




------=_NextPart_000_002E_01C3EBBF.ACD384D0-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 5 08:30:02 2004 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 IAA14760 for ; Thu, 5 Feb 2004 08:30:02 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00CCF523@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 8:30:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 922173 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 08:30:00 -0500 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 08:19:59 -0500 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 5 Feb 2004 18:49:47 +0530 Received: from manishgs (manishgs.future.futsoft.com [10.6.4.94]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i15DHex25021 for ; Thu, 5 Feb 2004 18:47:40 +0530 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: <001e01c3ebeb$915f7520$5e04060a@future.futsoft.com> Date: Thu, 5 Feb 2004 18:55:47 +0530 Reply-To: Mailing List Sender: Mailing List From: Manish Gupta Subject: ospfv3 router dead Interval To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <1075911073.64c48d1e7ca80@webmail.iol.unh.edu> Precedence: list Content-Transfer-Encoding: 7bit Hi, ospfv3IfRtrDeadInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds that a router's Hello packets have not been seen before it's neigh- bors declare the router down. This should be some multiple of the Hello interval. This value must be the same for all routers attached to a common network." DEFVAL { 40 } ::= { ospfv3IfEntry 9 } I think this DeadInterval value can not be Unsigned32 since ospfv3 hello packet have only two bytes for RouterDeadInterval. range should be defined for DeadInterval like HelloRange for HelloInterval. regards Manish Gupta *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 5 08:57:43 2004 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 IAA15331 for ; Thu, 5 Feb 2004 08:57:43 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00CCF4E4@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 8:57:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 923891 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 08:57:41 -0500 Received: from 67.100.73.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 08:57:41 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: ospfv3 router dead Interval Thread-Index: AcPr7Club0Ppqft8QOW1eQF1wTeR6AAA49Pw Message-ID: Date: Thu, 5 Feb 2004 05:56:16 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: ospfv3 router dead Interval To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Manish, You are right there. We will update it when we publish the next version = of the MIB. Thanks., Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Manish Gupta Sent: Thursday, February 05, 2004 6:56 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: ospfv3 router dead Interval Hi, ospfv3IfRtrDeadInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds that a router's Hello packets have not been seen before it's neigh- bors declare the router down. This should be some multiple of the Hello interval. This value must be the same for all routers attached to a common network." DEFVAL { 40 } ::=3D { ospfv3IfEntry 9 } I think this DeadInterval value can not be Unsigned32 since ospfv3 hello packet have only two bytes for RouterDeadInterval. range should be = defined for DeadInterval like HelloRange for HelloInterval. regards Manish Gupta *************************************************************************= ** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************= ** From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 5 12:32:42 2004 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 MAA25166 for ; Thu, 5 Feb 2004 12:32:42 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00CCFBE5@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 12:32:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 959567 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 12:32:40 -0500 Received: from 207.217.120.232 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 12:32:40 -0500 Received: from user-2ivfmri.dialup.mindspring.com ([165.247.219.114] helo=erg.sri.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AonMk-0004Lp-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 05 Feb 2004 09:32:38 -0800 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 References: <20040205113842.19587.qmail@webmail36.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <40227E33.90604@erg.sri.com> Date: Thu, 5 Feb 2004 09:32:35 -0800 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: Priority in Link Lsa To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Manish, My guess is that this is for use on NBMA links, since each router attached to an NBMA link does not receive Hellos from all other routers attached to the NBMA link, but does receive link-LSAs. This way, each router on the NBMA link will know the router priority of every other router on the NBMA link, and will thus know which routers are eligible to become Designated Router. (OSPFv2 requires some configuration information for the Hello Protocol.) Richard query OSPF wrote: >For OSPFv3, why is the router priority specified on the link-LSA in addition to the hello packets? > >same question is asked by mike but don't find any answer? > >regards >Manish > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 5 12:50:10 2004 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 MAA25697 for ; Thu, 5 Feb 2004 12:50:09 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00CCFCD5@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 12:50:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 960783 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 12:50:09 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 12:50:09 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D98BC5573DA for ; Thu, 5 Feb 2004 09:50:07 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26558-03 for ; Thu, 5 Feb 2004 09:50:07 -0800 (PST) Received: from aceeinspiron (unknown [172.31.254.25]) by prattle.redback.com (Postfix) with SMTP id 24FBB5573D8 for ; Thu, 5 Feb 2004 09:50:07 -0800 (PST) References: <20040205113842.19587.qmail@webmail36.rediffmail.com> <40227E33.90604@erg.sri.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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <008201c3ec10$7ccda670$0302a8c0@aceeinspiron> Date: Thu, 5 Feb 2004 12:50:04 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Priority in Link Lsa To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Richard Ogier" To: Sent: Thursday, February 05, 2004 12:32 PM Subject: Re: Priority in Link Lsa > Hi Manish, > > My guess is that this is for use on NBMA links, since each router attached > to an NBMA link does not receive Hellos from all other routers attached > to the NBMA link, but does receive link-LSAs. This way, each router > on the NBMA link will know the router priority of every other router on > the NBMA link, and will thus know which routers are eligible to become > Designated Router. (OSPFv2 requires some configuration information > for the Hello Protocol.) Richard, I thought about this possibility but the router priority is really an imperfect solution. On an NBMA network, you need to elect a DR initially in order for the first link LSA to be flooded. So, the router priority in the link LSA doesn't buy you anything other than being able to check for inconsistencies in your NBMA neighbor configuration (I haven't implemented this). Thanks, Acee > > Richard > > > query OSPF wrote: > > >For OSPFv3, why is the router priority specified on the link-LSA in addition to the hello packets? > > > >same question is asked by mike but don't find any answer? > > > >regards > >Manish > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 5 15:54:47 2004 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 PAA06359 for ; Thu, 5 Feb 2004 15:54:46 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00CD003B@cherry.ease.lsoft.com>; Thu, 5 Feb 2004 15:54:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 979375 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 5 Feb 2004 15:54:44 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 5 Feb 2004 15:44:44 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05414; Thu, 5 Feb 2004 15:44:41 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200402052044.PAA05414@ietf.org> Date: Thu, 5 Feb 2004 15:44:41 -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-dc-07.txt To: OSPF@PEACH.EASE.LSOFT.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 : Detecting Inactive Neighbors over OSPF Demand Circuits Author(s) : S. Rao, A. Zinin, A. Roy Filename : draft-ietf-ospf-dc-07.txt Pages : 5 Date : 2004-2-5 OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits is optimized in RFC1793 to minimize the amount of overhead traffic. A part of OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect a OSPF-inactive neighbor over such a link. This memo introduces a new mechanism called A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-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-dc-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-dc-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: <2004-2-5155342.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-dc-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-dc-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-5155342.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 6 00:43:11 2004 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 AAA00007 for ; Fri, 6 Feb 2004 00:43:11 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00CD0D79@cherry.ease.lsoft.com>; Fri, 6 Feb 2004 0:43:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1029930 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 6 Feb 2004 00:43:09 -0500 Received: from 203.199.83.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 6 Feb 2004 00:43:09 -0500 Received: (qmail 3641 invoked by uid 510); 6 Feb 2004 05:43:06 -0000 Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 06 feb 2004 05:43:06 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1076046186---0-203.199.83.148-3630" Message-ID: <20040206054306.3640.qmail@webmail26.rediffmail.com> Date: Fri, 6 Feb 2004 05:43:06 -0000 Reply-To: Mailing List Sender: Mailing List From: query OSPF Subject: OSPFv3 Questions To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1076046186---0-203.199.83.148-3630 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi,
=0A
=0AI have couple of questions.
=0A1. What is the pur= pose of options field in Router-LSA? This options information can be collec= ted from the hello packet also.
=0A
=0A2. If a router generate two ro= uter-LSA and then in the case of a mismatch of options field in the two Rou= ter-LSA, then according to rfc2740, LSA with lowest link state ID take prec= edence, Why?
=0A
=0Aregards=0A

=0A

=0A=0A --Next_1076046186---0-203.199.83.148-3630 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=0A=0AI have couple of questions.=0A1. What is the purpose of options fi= eld in Router-LSA? This options information can be collected from the hello= packet also.=0A=0A2. If a router generate two router-LSA and then in the c= ase of a mismatch of options field in the two Router-LSA, then according to= rfc2740, LSA with lowest link state ID take precedence, Why?=0A=0Aregards --Next_1076046186---0-203.199.83.148-3630-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 6 02:24:11 2004 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 CAA14854 for ; Fri, 6 Feb 2004 02:24:11 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00CD0DF5@cherry.ease.lsoft.com>; Fri, 6 Feb 2004 2:24:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1036067 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 6 Feb 2004 02:24:10 -0500 Received: from 165.212.11.111 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 6 Feb 2004 02:24:10 -0500 Received: from uadvg130.cms.usa.net (165.212.11.130) by cmsoutbound.mx.net with SMTP; 6 Feb 2004 07:24:08 -0000 Received: from mjbarnes [24.5.6.40] by uadvg130.cms.usa.net (ASMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.13N) with ESMTP id 567iBFHyg0022M30; Fri, 06 Feb 2004 07:24:06 GMT X-USANET-Auth: 24.5.6.40 AUTH michael_barnes@usa.net mjbarnes X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.37/37 Message-ID: Date: Thu, 5 Feb 2004 23:24:06 -0800 Reply-To: Mailing List Sender: Mailing List From: Michael Barnes Subject: Re: OSPFv3 Questions To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20040206054306.3640.qmail@webmail26.rediffmail.com> Precedence: list On 02/06/2004 at 05:43 AM, query OSPF said: >I have couple of questions. >1. What is the purpose of options field in Router-LSA? This options >information can be collected from the hello packet also. The Router-LSA is flooded throughout an area. This way, all of the routers in the area will know what options the router supports, not just those which receive the Hello packets. This is particularly important because some of the bits in the Router-LSA's options field, such as the v6 bit, are required during the SPF calculation. >2. If a router generate two router-LSA and then in the case of a mismatch >of options field in the two Router-LSA, then according to rfc2740, LSA >with lowest link state ID take precedence, Why? If the router's options change only one of the Router-LSAs needs to be re-originated. This way all of the routers know which of the Router-LSAs will have the correct options bits. Regards, Michael From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 6 14:11:27 2004 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 OAA09933 for ; Fri, 6 Feb 2004 14:11:27 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00CD1C68@cherry.ease.lsoft.com>; Fri, 6 Feb 2004 14:11:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1129155 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 6 Feb 2004 14:11:24 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 6 Feb 2004 14:11:23 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 001BB81B341; Fri, 6 Feb 2004 11:11:20 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01588-07; Fri, 6 Feb 2004 11:11:20 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.180]) by prattle.redback.com (Postfix) with SMTP id 60D3481B349; Fri, 6 Feb 2004 11:11:19 -0800 (PST) References: <4023E09E.1DAE0E3E@americasm01.nt.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01C3ECBB.158011A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <005c01c3ece4$ff05e1a0$0302a8c0@aceeinspiron> Date: Fri, 6 Feb 2004 14:11:16 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: questions about "Opaque capability on DD exchange ..." Comments: To: Lily Lu To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0059_01C3ECBB.158011A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lily, In the future, please send your questions in plain text format to the OSPF list. If you receive an opaque LSA and you do not support them, you should generate a SequenceNumberMismatch as documented on pages 101-102 in RFC 2328. Since OSPF is designed for a single administrative domain the adminstrator should be able to take action to deal with the errant router.=20 ----- Original Message -----=20 From: Lily Lu=20 To: rcoltun@fore.com ; acee@REDBACK.COM ; michael_barnes@USA.NET ; = jmoy@casc.com=20 Sent: Friday, February 06, 2004 1:44 PM Subject: questions about "Opaque capability on DD exchange ..." Hi Acee, Rob, John and Michael:=20 In the RFC2370, it state:=20 "An opaque-capable router learns of its neighbor's opaque capability=20 at the beginning of the "Database Exchange Process" (see Section = 10.6=20 of [OSPF], receiving Database Description packets from a neighbor = in=20 state ExStart). ....=20 Then, in the next step of the Database Exchange process,=20 Opaque LSAs are included in the Database summary list that is sent = to=20 the neighbor (see Sections 3.2 below and 10.3 of [OSPF]) if and = only=20 if the neighbor is opaque capable.=20 "=20 I'm also aware that in the next paragraph, it says "The non-opaque-=20 capable router will then simply discard the LSA (see Section 13 of=20 [OSPF], receiving LSAs having unknown LS types".=20 However, I thought that would only apply to " multicasts", or it can = apply to any situation including=20 neighbors staging and neighbor state machine?=20 Questions=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 - What happens when a router did send it's opaque LSA to it's = none-Opaque LSA neighbor?=20 - Should the neighbor still go ahead and try to stage to "full" with = the router, or should the neighbor=20 bump the router and not staging with it at all?=20 - What's the consequence, if the neighbor go ahead to stage with the = router? Do we have problems?=20 - Do we know how Cisco or Juniper behaves ?=20 Just don't wanbt to have a drastic treasurement for such an event, = unless it's very neccessary.=20 Thank you in advance,=20 Lily=20 =20 =20 =20 ------=_NextPart_000_0059_01C3ECBB.158011A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Lily,
In the future, please send your = questions in plain=20 text format to the
OSPF list. If you receive an opaque LSA = and you do=20 not support
them, you should generate a = SequenceNumberMismatch=20 as documented
on pages 101-102 in RFC 2328. Since = OSPF is=20 designed for a single
administrative domain the adminstrator = should be=20 able to take action
to deal with the errant router. =
----- Original Message -----
From:=20 Lily Lu
To: rcoltun@fore.com ; acee@REDBACK.COM ;=20 michael_barnes@USA.NET ; jmoy@casc.com =
Sent: Friday, February 06, 2004 = 1:44=20 PM
Subject: questions about = "Opaque=20 capability on DD exchange ..."

Hi Acee, Rob, John and Michael:=20

In the RFC2370, it state:=20

"An opaque-capable router learns of its neighbor's opaque = capability=20
   at the beginning of the "Database Exchange = Process" (see=20 Section 10.6
   of [OSPF], receiving Database = Description=20 packets from a neighbor in
   state ExStart). = ....=20
 Then, in the next step of the Database Exchange = process,=20
   Opaque LSAs are included in the Database summary = list that=20 is sent to
   the neighbor (see Sections 3.2 = below and=20 10.3 of [OSPF]) if and only
   if the = neighbor=20 is opaque capable.
"
  I'm also aware that = in the=20 next paragraph, it says "The non-opaque-
   = capable=20 router will then simply discard the LSA (see Section 13 of=20
   [OSPF], receiving LSAs having unknown LS = types".=20
  However, I thought that would only apply to " = multicasts",=20 or it can apply to any situation including
neighbors staging = and=20 neighbor state machine?=20

Questions
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
- What happens = when a router did send it's=20 opaque LSA to it's none-Opaque LSA neighbor?=20

- Should the neighbor still go ahead and try to stage to "full" = with the=20 router, or should the neighbor
bump the router and not staging = with it at=20 all?=20

- What's the consequence, if the neighbor go ahead to stage with = the=20 router? Do we have problems?=20

- Do we know how Cisco or Juniper behaves  ?=20

Just don't wanbt to have a drastic treasurement for such an event, = unless=20 it's very neccessary.=20

Thank you in advance,
Lily
 
 
 =20

------=_NextPart_000_0059_01C3ECBB.158011A0-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 6 16:40:55 2004 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 QAA21339 for ; Fri, 6 Feb 2004 16:40:55 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00CD214D@cherry.ease.lsoft.com>; Fri, 6 Feb 2004 16:40:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1148559 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 6 Feb 2004 16:40:52 -0500 Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 6 Feb 2004 16:40:52 -0500 Received: from user-2ivflek.dialup.mindspring.com ([165.247.213.212] helo=earthlink.net) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1ApDiU-0003Oi-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 06 Feb 2004 13:40:51 -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: <4023E09E.1DAE0E3E@americasm01.nt.com> <005c01c3ece4$ff05e1a0$0302a8c0@aceeinspiron> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <40240A5B.A9C36DB0@earthlink.net> Date: Fri, 6 Feb 2004 13:42:51 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Authentication changes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Group, What is the expected amount of cleanup if the authentication method or values are changed by a OSPF router and correctly validated by a peer/full adj OSPF router? Yes, I am assuming past LSDB synchronization, and the OSPF routers have achieved a full adj. Mitchell Erblich Sr Network Software Eng. ------------------ From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 6 17:11:17 2004 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 RAA25177 for ; Fri, 6 Feb 2004 17:11:16 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00CD2245@cherry.ease.lsoft.com>; Fri, 6 Feb 2004 17:11:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1153017 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 6 Feb 2004 17:11:15 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 6 Feb 2004 17:11:15 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id AA0BB1ADFC4 for ; Fri, 6 Feb 2004 14:11:14 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19042-03 for ; Fri, 6 Feb 2004 14:11:14 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.180]) by prattle.redback.com (Postfix) with SMTP id 7A7551ADFC3 for ; Fri, 6 Feb 2004 14:11:13 -0800 (PST) References: <01L678Z489Q08X9KOS@omega7.wr.usgs.gov> 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <010801c3ecfe$205deaa0$0302a8c0@aceeinspiron> Date: Fri, 6 Feb 2004 17:11:09 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Pat, Sina, Let's go with configuration checking as it seems to be the favorite. We'll update in the next revision. Sorry about the delay in responding - I've tied up with a lot of things lately. ----- Original Message ----- From: "Pat Murphy - (650)329-4044" To: Sent: Wednesday, February 04, 2004 12:41 PM Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt > Acee, > > MY preference is the following in order of preference: > > 3. Add configuration checking to disallow a virtual link in an > area with a multi-area adjacency shared with the backbone. > > 2. Don't bring up the virtual link if the best path is over > a P2P interface associated with a multi-area adjacency (this > could be done by flagging the router route during the transit > area's intra-area SPF). > > as 3 seems easier to do. Also 2 might trojan a confusing anomaly for NOCs. > > Pat From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 6 17:27:02 2004 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 RAA26134 for ; Fri, 6 Feb 2004 17:27:02 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00CD2179@cherry.ease.lsoft.com>; Fri, 6 Feb 2004 17:27:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1154363 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 6 Feb 2004 17:27:02 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 6 Feb 2004 17:27:02 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 361C61ADFC1 for ; Fri, 6 Feb 2004 14:27:01 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21690-04 for ; Fri, 6 Feb 2004 14:27:01 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.180]) by prattle.redback.com (Postfix) with SMTP id 252991ADFC2 for ; Fri, 6 Feb 2004 14:27:00 -0800 (PST) References: <4023E09E.1DAE0E3E@americasm01.nt.com> <005c01c3ece4$ff05e1a0$0302a8c0@aceeinspiron> <40240A5B.A9C36DB0@earthlink.net> 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <012801c3ed00$548c9c70$0302a8c0@aceeinspiron> Date: Fri, 6 Feb 2004 17:26:56 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Authentication changes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Erblichs" To: Sent: Friday, February 06, 2004 4:42 PM Subject: Authentication changes > Hi Group, > > What is the expected amount of cleanup if the authentication > method or values are changed by a OSPF router and correctly > validated by a peer/full adj OSPF router? Hi Mitchell, The change of authentication method should be seemless as long as all routers on the network are changed within the router-dead-interval. For key changes, various vendors have implemented different mechansims for changing an OSPF interface key without precise synchronization of key changes so in this case you're not even bounded by the router-dead-interval. Thanks, > > Yes, I am assuming past LSDB synchronization, and the > OSPF routers have achieved a full adj. > > Mitchell Erblich > Sr Network Software Eng. > ------------------ From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 9 05:56:15 2004 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 FAA11709 for ; Mon, 9 Feb 2004 05:56:15 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00CD58EA@cherry.ease.lsoft.com>; Mon, 9 Feb 2004 5:56:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1416742 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Feb 2004 05:56:11 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 9 Feb 2004 05:56:11 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2004 03:03:59 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i19Au8Gv025713; Mon, 9 Feb 2004 02:56:08 -0800 (PST) Received: from cisco.com (sjc-vpn4-130.cisco.com [10.21.80.130]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQS92731; Mon, 9 Feb 2004 02:56:07 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <401EDCC1.8040406@cisco.com> <004401c3ea11$6b398060$0302a8c0@aceeinspiron> <401F57ED.4060401@cisco.com> <008801c3ea60$9d016460$0302a8c0@aceeinspiron> <4021361B.1000906@cisco.com> <044601c3eba2$6ed0c1b0$0302a8c0@aceeinspiron> <402208EA.9040101@cisco.com> <007401c3ec0d$3e760dc0$0302a8c0@aceeinspiron> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <40276747.5010706@cisco.com> Date: Mon, 9 Feb 2004 02:56:07 -0800 Reply-To: Mailing List Sender: Mailing List From: Sandy Eng Subject: Special handling for MaxSequenceNumber Comments: cc: Acee Lindem , Peter Psenak , Rohit Dube , sandye@cisco.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi all, A proposal to add special handling to RFC 2328, Section 13.1 "Determining which LSA is newer", for LSAs with MaxSequenceNumber. Scenario: ========= Rtr A -------------- Rtr B 1) Rtr A receives a corrupted self-originated router-LSA, due to attack or software bug, with MaxSequenceNumber and different LSA content. Rtr A thinks it receives an old router-LSA, and tries to wrap the sequence number and maxages this LSA, before re-originating a new lsa. 2) If Rtr B has already received this corrupted packet, and later receives the MAXAGE LSA from Rtr A, due to a higher checksum value (comparison based on Section 13.1, RFC 2328) of the malformed packet, it thinks its LSA is newer and sends it back to Rtr A. 3) (1) - (2) repeats itself continuously. Meanwhile, Rtr A keeps retransmitting the MAXAGE lsa as it receives no ACK from its neighbor(s). Proposed adjustment to Section 13.1, RFC 2328 ============================================= For the above scenario, if both the received and existing LSAs have MaxSequenceNumber, it would only make sense to compare the age next : if (both received and existing LSAs have MaxSequenceNumber) { if (Both LS ages are different) { swap second and third bullet in Section 13.1 : - proceed to compare age - third bullet in Section 13.1 - then compare checksums - second bullet in Section 13.1 ... } else - proceed as normal with checksums - second bullet in Section 13.1 } This adjustment is in line with what the RFC intended for a MaxSequenceNumber LSA to do when wrapping - flush before originating a new one, which is a special case. This modification is just ensuring this to be working as intended. With all the security concerns we face today in the network, I think customers would appreciate this extra ensurance. Knowing a lot of networks today do not reach MaxSequenceNumber, tempering with packets by setting MaxSequenceNumber is too easy a hack to take down a network. With backward compatibility in mind, we can address this case for MaxSequenceNumber in our RFC. Please comment. Thanks, Sandy Acee Lindem wrote: > Sandy, Peter, > In thinking about it more, it will really be a pain to > purge an LSA that isn't actually installed (in this case I'm > referring to the MaxSequenceNumber LSA received by > the originator). Hence, it may not be that bad to go with > your suggestion to change the order of comparisons for > the case where the sequence number is at MAX. Since it > broken for this case I don't see this as a severe backward > compatibility problem. > > Can you take it to the list since you (or some testing your > product) originally discovered the problem. > > Thanks, > Acee > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 9 21:04:34 2004 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 VAA10836 for ; Mon, 9 Feb 2004 21:04:34 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00CD6C94@cherry.ease.lsoft.com>; Mon, 9 Feb 2004 21:04:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1531598 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Feb 2004 21:04:31 -0500 Received: from 207.217.120.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 9 Feb 2004 21:04:31 -0500 Received: from user-38lc0p7.dialup.mindspring.com ([209.86.3.39] helo=earthlink.net) by bittern.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AqNH6-0002Y5-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 09 Feb 2004 18:05:20 -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: <40283CD8.F62F98F1@earthlink.net> Date: Mon, 9 Feb 2004 18:07:20 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: FYI: Route Flapping To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, I have a concern that Route Flapping algorithms are being employed by routers which violate the values of MinLSInterval/Arrival. In a heterogeneous environments where OSPF routers are from different vendors, these values IMO must be followed. However, it has been argued that convergence where routes are incorrect due to flapping is less desirable than the logical splitting of an area, due to some routers ignoring the above values and implementing some Route Flap algorithm. Feedback please... Mitchell Erblich From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 9 21:58:06 2004 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 VAA12386 for ; Mon, 9 Feb 2004 21:58:06 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00CD6D5C@cherry.ease.lsoft.com>; Mon, 9 Feb 2004 21:58:07 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1548044 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Feb 2004 21:58:05 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 9 Feb 2004 21:58:05 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i1A2w5Bm031995 for ; Mon, 9 Feb 2004 18:58:05 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from juniper.net (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1A2w4h29588 for ; Mon, 9 Feb 2004 18:58:05 -0800 (PST) (envelope-from dkatz@juniper.net) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Message-ID: Date: Mon, 9 Feb 2004 18:58:04 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: FYI: Route Flapping To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <40283CD8.F62F98F1@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit MinLSInterval should have never been an architectural constant. MinLSArrival should never have been an architectural constant either, and arguably should never have existed (as it makes manipulation of the transmit interval more problematic.) Note that ignoring either of these values should have *no* effect on interoperability, as any system that enforces MinLSArrival will drop excessively rapid LS changes (and in any case, enforcing MinLSArrival is insufficient to protect a system against excessive LSAs, and building a system that is well protected against such things should be outside the scope of the specification.) It has been demonstrated that convergence of LS networks is far from simultaneous even when they are homogeneous (there are way too many factors that stand in the way) and in some cases may take multiple SPF spins (particularly in the case of a link coming up.) The only way to improve the global convergence time, IMHO, is to do everything as rapidly as possible (while protecting against meltdown, of course.) Absurdly long SPF delays are the biggest impediment to progress in this area. For what it's worth, we dropped support for MinLSArrival some time ago, and will regenerate a limited number of LSAs at a much more rapid interval than 5 seconds before slowing down. Grumpy as ever, --Dave On Monday, Feb 9, 2004, at 18:07 US/Pacific, Erblichs wrote: > Group, > > > I have a concern that Route Flapping algorithms > are being employed by routers which > violate the values of MinLSInterval/Arrival. > > In a heterogeneous environments where OSPF routers > are from different vendors, these values IMO must > be followed. However, it has been argued that > convergence where routes are incorrect due to > flapping is less desirable than the logical splitting > of an area, due to some routers ignoring the > above values and implementing some Route Flap > algorithm. > > Feedback please... > > Mitchell Erblich > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 10 10:09:16 2004 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 KAA21391 for ; Tue, 10 Feb 2004 10:09:16 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00CD7CAE@cherry.ease.lsoft.com>; Tue, 10 Feb 2004 10:09:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1646172 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Feb 2004 10:09:13 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 10 Feb 2004 10:09:13 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A7A5968C1CE for ; Tue, 10 Feb 2004 07:09:12 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11302-08 for ; Tue, 10 Feb 2004 07:09:12 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.156]) by prattle.redback.com (Postfix) with SMTP id A220F68C1C5 for ; Tue, 10 Feb 2004 07:09:11 -0800 (PST) References: <401EDCC1.8040406@cisco.com> <004401c3ea11$6b398060$0302a8c0@aceeinspiron> <401F57ED.4060401@cisco.com> <008801c3ea60$9d016460$0302a8c0@aceeinspiron> <4021361B.1000906@cisco.com> <044601c3eba2$6ed0c1b0$0302a8c0@aceeinspiron> <402208EA.9040101@cisco.com> <007401c3ec0d$3e760dc0$0302a8c0@aceeinspiron> <40276747.5010706@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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <043d01c3efe7$cf9de060$0302a8c0@aceeinspiron> Date: Tue, 10 Feb 2004 10:08:58 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Special handling for MaxSequenceNumber To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit This is a real situation that can occur is someone spoofs a MaxSequenceNumber LSA with a higher checksum than the real one. We discussed alternatives to fixing this. The other we discussed was the advertising router purging the errant more recent LSA prior to re-originating a new one with InitialSequenceNumber. It seemed more difficult since you'd need to reliably flood an LSA that you don't install. Comments? Irrespective of the solution - should we handle this with RFC errata or a short draft? Thanks, Acee ----- Original Message ----- From: "Sandy Eng" To: Sent: Monday, February 09, 2004 5:56 AM Subject: Special handling for MaxSequenceNumber > Hi all, > > A proposal to add special handling to RFC 2328, Section 13.1 > "Determining which LSA is newer", for LSAs with MaxSequenceNumber. > > Scenario: > ========= > > Rtr A -------------- Rtr B > > 1) Rtr A receives a corrupted self-originated router-LSA, due to attack > or software bug, with MaxSequenceNumber and different LSA content. Rtr A > thinks it receives an old router-LSA, and tries to wrap the sequence > number and maxages this LSA, before re-originating a new lsa. > > 2) If Rtr B has already received this corrupted packet, and later > receives the MAXAGE LSA from Rtr A, due to a higher checksum value > (comparison based on Section 13.1, RFC 2328) of the malformed packet, it > thinks its LSA is newer and sends it back to Rtr A. > > 3) (1) - (2) repeats itself continuously. Meanwhile, Rtr A keeps > retransmitting the MAXAGE lsa as it receives no ACK from its neighbor(s). > > > Proposed adjustment to Section 13.1, RFC 2328 > ============================================= > > For the above scenario, if both the received and existing LSAs have > MaxSequenceNumber, it would only make sense to compare the age next : > > if (both received and existing LSAs have MaxSequenceNumber) { > if (Both LS ages are different) { > swap second and third bullet in Section 13.1 : > - proceed to compare age - third bullet in Section 13.1 > - then compare checksums - second bullet in Section 13.1 > ... > } > else > - proceed as normal with checksums - second bullet in Section 13.1 > } > > This adjustment is in line with what the RFC intended for a > MaxSequenceNumber LSA to do when wrapping - flush before originating a > new one, which is a special case. This modification is just ensuring > this to be working as intended. > > With all the security concerns we face today in the network, I think > customers would appreciate this extra ensurance. Knowing a lot of > networks today do not reach MaxSequenceNumber, tempering with packets by > setting MaxSequenceNumber is too easy a hack to take down a network. > > With backward compatibility in mind, we can address this case for > MaxSequenceNumber in our RFC. > > Please comment. > > Thanks, > Sandy > > > Acee Lindem wrote: > > Sandy, Peter, > > In thinking about it more, it will really be a pain to > > purge an LSA that isn't actually installed (in this case I'm > > referring to the MaxSequenceNumber LSA received by > > the originator). Hence, it may not be that bad to go with > > your suggestion to change the order of comparisons for > > the case where the sequence number is at MAX. Since it > > broken for this case I don't see this as a severe backward > > compatibility problem. > > > > Can you take it to the list since you (or some testing your > > product) originally discovered the problem. > > > > Thanks, > > Acee > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 10 10:46:00 2004 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 KAA23698 for ; Tue, 10 Feb 2004 10:46:00 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00CD7E55@cherry.ease.lsoft.com>; Tue, 10 Feb 2004 10:46:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1649940 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Feb 2004 10:45:58 -0500 Received: from 169.144.2.221 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 10 Feb 2004 10:45:58 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCH7BF>; Tue, 10 Feb 2004 10:45: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: <39469E08BD83D411A3D900204840EC55FB71D7@vie-msgusr-01.dc.fore.com> Date: Tue, 10 Feb 2004 10:45:51 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: long SPF delays To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list -> Absurdly long SPF delays are the biggest impediment to -> progress in this area. Yes. But only in the worst case. Progress in theoretical computer science is far rapid to catch-up. Let me take this opportunity to share some information which I came across and thought very useful for this community. In a recent paper by Thorup et. al., "Speeding up Dynamic Shortest Path Algorithms", Sept 2003 (not yet published) http://www.research.att.com/~mgcr/doc/dspa.pdf authors compared 4 Dynamic Dijkstra algorithms. The paper is so practical in a way, it gives complete algorithms with full statistical results in a larger simulated topologies (very large when compared to Internet IGP domains). For theoretical interest, most of the Dynamic SPF algorithms are based on Ramalingam and Reps "Generalization of Incremental SPF" paper - which is based on to Knuth's Static Dijkstra SPF generalization using finite automata. Look at Chapter 2 in a recent MIT PhD thesis for a general framework for Dynamic SPF (don't look at Chapter 3 which is based on linear programming - different from Dijkstra SPF) http://citeseer.nj.nec.com/335235.html In his classic paper, Thorup reduced static SPF computation to linear time O(m), m is number of edges. His approach is different from Dijkstra, to break the log sorting time. http://citeseer.nj.nec.com/thorup97undirected.html (This may be impractical to adapt to IGPs, for the implicit assumptions by the algorithms) For comprehensive list of literature on Dynamic SPF algos, look at: http://www.cs.uwaterloo.ca/~y6yang/page.htm In conclusion, I feel that, OSPF/ISIS SPF computations can be speed-up dramatically (at least in expected case) using recent advances in systems engineering and theoretical computer science without loss of generality (esp. in asynchronous distributed algorithms in arbitrary connected network problem space). Any comments, please discuss. Venkata. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 10 14:46:21 2004 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 OAA05009 for ; Tue, 10 Feb 2004 14:46:21 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00CD84B5@cherry.ease.lsoft.com>; Tue, 10 Feb 2004 14:46:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1671289 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Feb 2004 14:46:17 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 10 Feb 2004 14:46:17 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i1AJkHBm034644 for ; Tue, 10 Feb 2004 11:46:18 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from juniper.net (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1AJkHh08077 for ; Tue, 10 Feb 2004 11:46:17 -0800 (PST) (envelope-from dkatz@juniper.net) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Message-ID: Date: Tue, 10 Feb 2004 11:46:17 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: long SPF delays To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC55FB71D7@vie-msgusr-01.dc.fore.com> Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, Feb 10, 2004, at 07:45 US/Pacific, Naidu, Venkata wrote: > -> Absurdly long SPF delays are the biggest impediment to > -> progress in this area. > > Yes. But only in the worst case. Progress in theoretical > computer science is far rapid to catch-up. > You misunderstood me. The problem is not the duration of the SPF calculation (which is typically in the millisecond range) but in implementations that put a long delay between successive calculations in order to stave off instability (due to insufficiently robust code.) I have yet to see any evidence that SPF calculations in any practical OSPF/ISIS networks are taking long enough to make it necessary to add the complexity of optimizing the SPF calculation. It's an interesting theoretical problem, and it probably has practical application in other realms, but not in IP networks. Lots of things besides the SPF calculation cause problems if you try to build an O(10000) node network. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 10 16:05:01 2004 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 QAA14890 for ; Tue, 10 Feb 2004 16:05:00 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00CD8695@cherry.ease.lsoft.com>; Tue, 10 Feb 2004 16:04:58 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1678903 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Feb 2004 16:04:55 -0500 Received: from 169.144.2.221 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 10 Feb 2004 16:04:55 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSC2HHR>; Tue, 10 Feb 2004 16:04: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: <39469E08BD83D411A3D900204840EC55FB71D8@vie-msgusr-01.dc.fore.com> Date: Tue, 10 Feb 2004 16:04:45 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: long SPF delays To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list -> > -> Absurdly long SPF delays are the biggest impediment to -> > -> progress in this area. -> > -> > Yes. But only in the worst case. Progress in theoretical -> > computer science is far rapid to catch-up. -> > -> -> You misunderstood me. The problem is not the duration of the SPF -> calculation (which is typically in the millisecond range) but in -> implementations that put a long delay between successive calculations -> in order to stave off instability (due to insufficiently -> robust code.) Ok. I got what you were saying. I think the problem you are trying to solve is way below the lower bound we could achieve in an asynchronous system where byzantine failures are expected and continuous. The problem you are talking about SPF is a local convergence problem. That means, only the computing router's routing table is expecting to be converted after a change some where in the network. 1. Why anyone put a long delay between SPFs ? In implementations, I worked on, I insist below heuristics in the basic SPF design: a. SPF is triggered as an independent task taking complete advantage of underlying operating system and processor(s) (for example, as a separate task/thread using SMP etc) ONLY when there is a change in database. If multiple such protocols/processes/tasks are competing for resources, then it is a different story - it is a classic system performance/scheduling question. b. Never assume network is converged - that means never assume that there won't be any more new updates in near future. Assume, network/topology is ever changing. c. If there is no change in database (based on overall checksum check etc), then there is no need to wake-up/re-start SPF computation. d. If there is a change in database while doing an SPF run, then stopping and re-staring SPF run (even in the case of Dynamic SPFs) is a good thing to do. This can be done in constant time in SPF computation (using a global flag, every time after relaxing a node into SPT) 2. For global convergence, as you said, rapid flooding is important. Parameter tuning, heuristics and algorithms for rapid flooding is another topic altogether. Venkata. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 10 16:16:10 2004 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 QAA16975 for ; Tue, 10 Feb 2004 16:16:08 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00CD84EE@cherry.ease.lsoft.com>; Tue, 10 Feb 2004 16:16:08 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1679898 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Feb 2004 16:16:05 -0500 Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 10 Feb 2004 16:16:05 -0500 Received: from user-2ivfld1.dialup.mindspring.com ([165.247.213.161] helo=earthlink.net) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AqfEj-00007w-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Feb 2004 13:16: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 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <402949E3.AB6BAD27@earthlink.net> Date: Tue, 10 Feb 2004 13:15:15 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: long SPF delays To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit This sounds that you believe that SPF throttling and packet pacing functionality by some companies isn't necessary. If packet pacing is implimented by some routers, then without SPF throttling, wouldn't sucessive SPF calculations occur? Of course, packet pacing is to spread out peak LSA xmits to min input buffer overflows, etc.. Lastly, with vastly cheaper memory subsystems and larger phys memories it is possible to decrease the amount of route aggregation to achieve better path routing. However, this will and does significantly increase the LSDB sizing, and secondarily normally increases the SPF computation duration beyond ms durations (in a large number of deployed routers) with LSDB sizing ranging from 500k to 2.5M Mitchell Erblich ----------------------------- Dave Katz wrote: > > On Tuesday, Feb 10, 2004, at 07:45 US/Pacific, Naidu, Venkata wrote: > > > -> Absurdly long SPF delays are the biggest impediment to > > -> progress in this area. > > > > Yes. But only in the worst case. Progress in theoretical > > computer science is far rapid to catch-up. > > > > You misunderstood me. The problem is not the duration of the SPF > calculation (which is typically in the millisecond range) but in > implementations that put a long delay between successive calculations > in order to stave off instability (due to insufficiently robust code.) > > I have yet to see any evidence that SPF calculations in any practical > OSPF/ISIS networks are taking long enough to make it necessary to add > the complexity of optimizing the SPF calculation. It's an interesting > theoretical problem, and it probably has practical application in other > realms, but not in IP networks. Lots of things besides the SPF > calculation cause problems if you try to build an O(10000) node network. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 10 17:26:42 2004 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 RAA25387 for ; Tue, 10 Feb 2004 17:26:42 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00CD8A3C@cherry.ease.lsoft.com>; Tue, 10 Feb 2004 17:26:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1689371 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Feb 2004 17:26:38 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 10 Feb 2004 17:26:38 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i1AMQdBm035169 for ; Tue, 10 Feb 2004 14:26:39 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from juniper.net (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1AMQdh26710 for ; Tue, 10 Feb 2004 14:26:39 -0800 (PST) (envelope-from dkatz@juniper.net) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Message-ID: <3188DDC0-5C18-11D8-A1E9-000A95A55D88@juniper.net> Date: Tue, 10 Feb 2004 14:26:38 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: long SPF delays To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC55FB71D8@vie-msgusr-01.dc.fore.com> Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, Feb 10, 2004, at 13:04 US/Pacific, Naidu, Venkata wrote: > Ok. I got what you were saying. I think the problem you are > trying to solve is way below the lower bound we could achieve > in an asynchronous system where byzantine failures are expected > and continuous. > > The problem you are talking about SPF is a local convergence > problem. That means, only the computing router's routing table > is expecting to be converted after a change some where in > the network. > > 1. Why anyone put a long delay between SPFs ? In implementations, > I worked on, I insist below heuristics in the basic SPF > design: The reason that long inter-SPF intervals have been used in the past is due to scheduling and queuing problems in particular implementations. There are a number of implementations that will collapse if the CPU load gets high enough, as a side effect of run-to-completion scheduling and process starvation. By putting a holddown on the recalculation, such systems can be kept away from the cliff edge. As you are no doubt aware, given what you said in your message, there is no reason why SPF can't be running more or less continuously without threatening system stability. I'm not trying to solve any problems, I just like to complain. ;-) --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 10 18:02:37 2004 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 SAA27991 for ; Tue, 10 Feb 2004 18:02:35 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00CD8993@cherry.ease.lsoft.com>; Tue, 10 Feb 2004 18:02:36 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1693047 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Feb 2004 18:02:34 -0500 Received: from 203.199.83.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 10 Feb 2004 18:02:33 -0500 Received: (qmail 2189 invoked by uid 510); 10 Feb 2004 23:02:31 -0000 Received: from unknown (128.107.253.39) by rediffmail.com via HTTP; 10 feb 2004 23:02:31 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1076454151---0-203.199.83.148-2186" Message-ID: <20040210230231.2188.qmail@webmail26.rediffmail.com> Date: Tue, 10 Feb 2004 23:02:31 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Special handling for MaxSequenceNumber To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1076454151---0-203.199.83.148-2186 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0ABut just changing the order of comparisons (max age check before chec= k sum)doesnt seems to solve the issue. What prevents "someone" fr= om hacking the "age" if that can be done with "sequence numb= er".
=0AWe'll again end up in same condition.
=0A
=0A
=0AP= .S: Pls bear the rich text. I need to migrate my subscription to another ac= .
=0A
=0A-Vivek
=0A
=0A
=0A
=0AOn Tue, 10 Feb 2004 Acee L= indem wrote :
=0A>This is a real situation that can occur is someone = spoofs a
=0A>MaxSequenceNumber LSA with a higher checksum than
=0A= >the real one. We discussed alternatives to fixing this. The other = we
=0A>discussed was the advertising router purging the errant more = recent
=0A>LSA prior to re-originating a new one with InitialSequence= Number.
=0A>It seemed more difficult since you'd need to reliably flo= od an LSA
=0A>that you don't install.
=0A>
=0A>Comments?<= BR>=0A>
=0A>Irrespective of the solution - should we handle this w= ith RFC
=0A>errata or a short draft?
=0A>
=0A>Thanks,
= =0A>Acee
=0A>
=0A>----- Original Message -----
=0A> Fr= om: "Sandy Eng" <swkeng@CISCO.COM>
=0A>To: <OSPF@P= EACH.EASE.LSOFT.COM>
=0A>Sent: Monday, February 09, 2004 5:56 AM=0A>Subject: Special handling for MaxSequenceNumber
=0A>
=0A&= gt;
=0A> > Hi all,
=0A> >
=0A> > A proposal to a= dd special handling to RFC 2328, Section 13.1
=0A> > "Determi= ning which LSA is newer", for LSAs with MaxSequenceNumber.
=0A> = >
=0A> > Scenario:
=0A> > =3D=3D=3D=3D=3D=3D=3D=3D=3D<= BR>=0A> >
=0A> > Rtr A  -------------- Rtr B
=0A>= >
=0A> > 1) Rtr A receives a corrupted self-originated router-= LSA, due to attack
=0A> > or software bug, with MaxSequenceNumber = and different LSA content. Rtr A
=0A> >  thinks it receives = an old router-LSA, and tries to wrap the sequence
=0A> > number an= d maxages this LSA, before re-originating a new lsa.
=0A> >
=0A= > > 2) If Rtr B has already received this corrupted packet, and later=
=0A> > receives the MAXAGE LSA from Rtr A, due to a higher checks= um value
=0A> > (comparison based on Section 13.1, RFC 2328) of th= e malformed packet, it
=0A> > thinks its LSA is newer and sends it= back to Rtr A.
=0A> >
=0A> > 3) (1) - (2) repeats itself= continuously. Meanwhile, Rtr A keeps
=0A> > retransmitting the MA= XAGE lsa as it receives no ACK from its neighbor(s).
=0A> >
=0A= > >
=0A> > Proposed adjustment to Section 13.1, RFC 2328
= =0A> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=0A> >
=0A> > For the above scenario, if both the receiv= ed and existing LSAs have
=0A> > MaxSequenceNumber, it would only = make sense to compare the age next :
=0A> >
=0A> > if (bo= th received and existing LSAs have MaxSequenceNumber) {
=0A> >&nbs= p; if (Both LS ages are different) {
=0A> >    swap se= cond and third bullet in Section 13.1 :
=0A> >    - pro= ceed to compare age - third bullet in Section 13.1
=0A> >  &n= bsp; - then compare checksums - second bullet in Section 13.1
=0A> &= gt;    ...
=0A> >  }
=0A> >  else<= BR>=0A> >    - proceed as normal with checksums - second b= ullet in Section 13.1
=0A> > }
=0A> >
=0A> > Thi= s adjustment is in line with what the RFC intended for a
=0A> > Ma= xSequenceNumber LSA to do when wrapping - flush before originating a
=0A= > > new one, which is a special case. This modification is just ensur= ing
=0A> > this to be working as intended.
=0A> >
=0A&= gt; > With all the security concerns we face today in the network, I thi= nk
=0A> > customers would appreciate this extra ensurance. Knowing= a lot of
=0A> > networks today do not reach MaxSequenceNumber, te= mpering with packets by
=0A> > setting MaxSequenceNumber is too ea= sy a hack to take down a network.
=0A> >
=0A> > With back= ward compatibility in mind, we can address this case for
=0A> > Ma= xSequenceNumber in our RFC.
=0A> >
=0A> > Please comment.=
=0A> >
=0A> > Thanks,
=0A> > Sandy
=0A> &= gt;
=0A> >
=0A> > Acee Lindem wrote:
=0A> > >= Sandy, Peter,
=0A> > > In thinking about it more, it will real= ly be a pain to
=0A> > > purge an LSA that isn't actually insta= lled (in this case I'm
=0A> > > referring to the MaxSequenceNum= ber LSA received by
=0A> > > the originator). Hence, it may not= be that bad to go with
=0A> > > your suggestion to change the = order of comparisons for
=0A> > > the case where the sequence n= umber is at MAX. Since it
=0A> > > broken for this case I don't= see this as a severe backward
=0A> > > compatibility problem.<= BR>=0A> > >
=0A> > > Can you take it to the list since= you (or some testing your
=0A> > > product) originally discove= red the problem.
=0A> > >
=0A> > > Thanks,
=0A&g= t; > > Acee
=0A> > >
=0A=0A

=0A

=0A=0A --Next_1076454151---0-203.199.83.148-2186 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable But just changing the order of comparisons (max age check before check sum)= doesnt seems to solve the issue. What prevents "someone" from hacking the "= age" if that can be done with "sequence number".=0AWe'll again end up in sa= me condition.=0A=0A=0AP.S: Pls bear the rich text. I need to migrate my sub= scription to another ac.=0A=0A-Vivek=0A=0A=0A=0AOn Tue, 10 Feb 2004 Acee Li= ndem wrote :=0A>This is a real situation that can occur is someone spoofs a= =0A>MaxSequenceNumber LSA with a higher checksum than=0A>the real one. We d= iscussed alternatives to fixing this. The other we=0A>discussed was the ad= vertising router purging the errant more recent=0A>LSA prior to re-originat= ing a new one with InitialSequenceNumber.=0A>It seemed more difficult since= you'd need to reliably flood an LSA=0A>that you don't install.=0A>=0A>Comm= ents?=0A>=0A>Irrespective of the solution - should we handle this with RFC= =0A>errata or a short draft?=0A>=0A>Thanks,=0A>Acee=0A>=0A>----- Original M= essage -----=0A> From: "Sandy Eng" =0A>To: =0A>Sent: Monday, February 09, 2004 5:56 AM=0A>Subject: Specia= l handling for MaxSequenceNumber=0A>=0A>=0A> > Hi all,=0A> >=0A> > A propos= al to add special handling to RFC 2328, Section 13.1=0A> > "Determining whi= ch LSA is newer", for LSAs with MaxSequenceNumber.=0A> >=0A> > Scenario:=0A= > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=0A> >=0A> > Rtr A -------------- Rtr B=0A>= >=0A> > 1) Rtr A receives a corrupted self-originated router-LSA, due to a= ttack=0A> > or software bug, with MaxSequenceNumber and different LSA conte= nt. Rtr A=0A> > thinks it receives an old router-LSA, and tries to wrap t= he sequence=0A> > number and maxages this LSA, before re-originating a new = lsa.=0A> >=0A> > 2) If Rtr B has already received this corrupted packet, an= d later=0A> > receives the MAXAGE LSA from Rtr A, due to a higher checksum = value=0A> > (comparison based on Section 13.1, RFC 2328) of the malformed p= acket, it=0A> > thinks its LSA is newer and sends it back to Rtr A.=0A> >= =0A> > 3) (1) - (2) repeats itself continuously. Meanwhile, Rtr A keeps=0A>= > retransmitting the MAXAGE lsa as it receives no ACK from its neighbor(s)= .=0A> >=0A> >=0A> > Proposed adjustment to Section 13.1, RFC 2328=0A> > =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A> >=0A> > For t= he above scenario, if both the received and existing LSAs have=0A> > MaxSeq= uenceNumber, it would only make sense to compare the age next :=0A> >=0A> >= if (both received and existing LSAs have MaxSequenceNumber) {=0A> > if (= Both LS ages are different) {=0A> > swap second and third bullet in Sec= tion 13.1 :=0A> > - proceed to compare age - third bullet in Section 13= .1=0A> > - then compare checksums - second bullet in Section 13.1=0A> >= ...=0A> > }=0A> > else=0A> > - proceed as normal with checksum= s - second bullet in Section 13.1=0A> > }=0A> >=0A> > This adjustment is in= line with what the RFC intended for a=0A> > MaxSequenceNumber LSA to do wh= en wrapping - flush before originating a=0A> > new one, which is a special = case. This modification is just ensuring=0A> > this to be working as intend= ed.=0A> >=0A> > With all the security concerns we face today in the network= , I think=0A> > customers would appreciate this extra ensurance. Knowing a = lot of=0A> > networks today do not reach MaxSequenceNumber, tempering with = packets by=0A> > setting MaxSequenceNumber is too easy a hack to take down = a network.=0A> >=0A> > With backward compatibility in mind, we can address = this case for=0A> > MaxSequenceNumber in our RFC.=0A> >=0A> > Please commen= t.=0A> >=0A> > Thanks,=0A> > Sandy=0A> >=0A> >=0A> > Acee Lindem wrote:=0A>= > > Sandy, Peter,=0A> > > In thinking about it more, it will really be a p= ain to=0A> > > purge an LSA that isn't actually installed (in this case I'm= =0A> > > referring to the MaxSequenceNumber LSA received by=0A> > > the ori= ginator). Hence, it may not be that bad to go with=0A> > > your suggestion = to change the order of comparisons for=0A> > > the case where the sequence = number is at MAX. Since it=0A> > > broken for this case I don't see this as= a severe backward=0A> > > compatibility problem.=0A> > >=0A> > > Can you t= ake it to the list since you (or some testing your=0A> > > product) origina= lly discovered the problem.=0A> > >=0A> > > Thanks,=0A> > > Acee=0A> > >=0A --Next_1076454151---0-203.199.83.148-2186-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 10 18:27:49 2004 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 SAA29815 for ; Tue, 10 Feb 2004 18:27:47 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00CD8B0F@cherry.ease.lsoft.com>; Tue, 10 Feb 2004 18:27:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1694300 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Feb 2004 18:27:44 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 10 Feb 2004 18:27:44 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i1ANRil92283 for ; Tue, 10 Feb 2004 15:27:44 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from juniper.net (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1ANRch33837 for ; Tue, 10 Feb 2004 15:27:38 -0800 (PST) (envelope-from dkatz@juniper.net) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Message-ID: Date: Tue, 10 Feb 2004 15:27:37 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: long SPF delays To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <402949E3.AB6BAD27@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, Feb 10, 2004, at 13:15 US/Pacific, Erblichs wrote: > This sounds that you believe that SPF throttling and packet pacing > functionality by some companies isn't necessary. I believe packet pacing is absolutely necessary (since there's no flow control in the protocol, and the receiver may be dropping packets), but that's quite distinct from LSA generation holddown. You're right, I don't believe that SPF throttling is necessary, nor is it desirable (except as a self-preservation measure when it looks like things are really hosed.) > > If packet pacing is implimented by some routers, then without SPF > throttling, > wouldn't sucessive SPF calculations occur? Of course, packet pacing > is to spread out peak LSA xmits to min input buffer overflows, etc.. Yes, successive SPF calculations may occur. That's a good thing, unless the system tends to melt down in such cases, as you'll reach convergence nirvana sooner. > > Lastly, with vastly cheaper memory subsystems and larger phys memories > it is possible to decrease the amount of route aggregation to achieve > better path routing. However, this will and does significantly increase > the LSDB sizing, and secondarily normally increases the SPF computation > duration beyond ms durations (in a large number of deployed routers) > with LSDB sizing ranging from 500k to 2.5M This doesn't increase the complexity of the SPF calculation, just the sheer volume of leaf nodes to process. Optimizing this does not require the relatively arcane algorithms that are favorites of researchers; we're not talking about 500K vertices after all. This case is just a matter of trying to minimize the amount of linear slogging you have to do. Trying to run giant LSDBs will require a lot more things to scale than just the SPF, which unfortunately is what people like to think about. You also have to deal with the sheer volume of database exchange, the max size of the Router LSA, and downloading all of those routes to the forwarding engine, among other things. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 10 18:54:13 2004 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 SAA00862 for ; Tue, 10 Feb 2004 18:54:13 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00CD8B6F@cherry.ease.lsoft.com>; Tue, 10 Feb 2004 18:54:14 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1696790 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Feb 2004 18:54:12 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 10 Feb 2004 18:54:12 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 10 Feb 2004 16:02:18 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1ANsA4U000243 for ; Tue, 10 Feb 2004 15:54:10 -0800 (PST) Received: from cisco.com ([128.107.177.148]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQU75364; Tue, 10 Feb 2004 15:54:06 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20040210230231.2188.qmail@webmail26.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <40296F1D.2020800@cisco.com> Date: Tue, 10 Feb 2004 15:54:05 -0800 Reply-To: Mailing List Sender: Mailing List From: Sandy Eng Subject: Re: Special handling for MaxSequenceNumber To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vivek, Vivek Dubey wrote: > But just changing the order of comparisons (max age check before check sum)doesnt seems to solve the issue. What prevents "someone" from hacking the "age" if that can be done with "sequence number". > We'll again end up in same condition. Agreed with the fact that we are not attempting to prevent all hacks with this change. Just changing anything in an LSA content maliciously changes the checksum right away, which by itself can cause a lot of damage. However, the adjustment proposed fixes the somewhat broken logic for MAXSequenceNumber LSAs by allowing the network to repair the spoof - let the MAXSequenceNumber LSA gets flushed first before re-originating a new LSA with InitSequenceNumber. If the age is spoofed, either a fake MAXAGE LSA will override, or a fake younger LSA will override (if the age difference between the spoofed and existing LSAs is more than MaxAgeDiff). In both cases, the router will eventually re-originate a new LSA with a larger sequence number. This new LSA should eventually get flooded. For the MAXSequenceNumber case, we need to make sure we have a way out - to allow a new LSA to get re-originated. Thanks, Sandy > > > P.S: Pls bear the rich text. I need to migrate my subscription to another ac. > > -Vivek > > > > On Tue, 10 Feb 2004 Acee Lindem wrote : > >>This is a real situation that can occur is someone spoofs a >>MaxSequenceNumber LSA with a higher checksum than >>the real one. We discussed alternatives to fixing this. The other we >>discussed was the advertising router purging the errant more recent >>LSA prior to re-originating a new one with InitialSequenceNumber. >>It seemed more difficult since you'd need to reliably flood an LSA >>that you don't install. >> >>Comments? >> >>Irrespective of the solution - should we handle this with RFC >>errata or a short draft? >> >>Thanks, >>Acee >> >>----- Original Message ----- >>From: "Sandy Eng" >>To: >>Sent: Monday, February 09, 2004 5:56 AM >>Subject: Special handling for MaxSequenceNumber >> >> >> >>>Hi all, >>> >>>A proposal to add special handling to RFC 2328, Section 13.1 >>>"Determining which LSA is newer", for LSAs with MaxSequenceNumber. >>> >>>Scenario: >>>========= >>> >>>Rtr A -------------- Rtr B >>> >>>1) Rtr A receives a corrupted self-originated router-LSA, due to attack >>>or software bug, with MaxSequenceNumber and different LSA content. Rtr A >>> thinks it receives an old router-LSA, and tries to wrap the sequence >>>number and maxages this LSA, before re-originating a new lsa. >>> >>>2) If Rtr B has already received this corrupted packet, and later >>>receives the MAXAGE LSA from Rtr A, due to a higher checksum value >>>(comparison based on Section 13.1, RFC 2328) of the malformed packet, it >>>thinks its LSA is newer and sends it back to Rtr A. >>> >>>3) (1) - (2) repeats itself continuously. Meanwhile, Rtr A keeps >>>retransmitting the MAXAGE lsa as it receives no ACK from its neighbor(s). >>> >>> >>>Proposed adjustment to Section 13.1, RFC 2328 >>>============================================= >>> >>>For the above scenario, if both the received and existing LSAs have >>>MaxSequenceNumber, it would only make sense to compare the age next : >>> >>>if (both received and existing LSAs have MaxSequenceNumber) { >>> if (Both LS ages are different) { >>> swap second and third bullet in Section 13.1 : >>> - proceed to compare age - third bullet in Section 13.1 >>> - then compare checksums - second bullet in Section 13.1 >>> ... >>> } >>> else >>> - proceed as normal with checksums - second bullet in Section 13.1 >>>} >>> >>>This adjustment is in line with what the RFC intended for a >>>MaxSequenceNumber LSA to do when wrapping - flush before originating a >>>new one, which is a special case. This modification is just ensuring >>>this to be working as intended. >>> >>>With all the security concerns we face today in the network, I think >>>customers would appreciate this extra ensurance. Knowing a lot of >>>networks today do not reach MaxSequenceNumber, tempering with packets by >>>setting MaxSequenceNumber is too easy a hack to take down a network. >>> >>>With backward compatibility in mind, we can address this case for >>>MaxSequenceNumber in our RFC. >>> >>>Please comment. >>> >>>Thanks, >>>Sandy >>> >>> >>>Acee Lindem wrote: >>> >>>>Sandy, Peter, >>>>In thinking about it more, it will really be a pain to >>>>purge an LSA that isn't actually installed (in this case I'm >>>>referring to the MaxSequenceNumber LSA received by >>>>the originator). Hence, it may not be that bad to go with >>>>your suggestion to change the order of comparisons for >>>>the case where the sequence number is at MAX. Since it >>>>broken for this case I don't see this as a severe backward >>>>compatibility problem. >>>> >>>>Can you take it to the list since you (or some testing your >>>>product) originally discovered the problem. >>>> >>>>Thanks, >>>>Acee >>>> >>> > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 10 19:58:52 2004 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 TAA07182 for ; Tue, 10 Feb 2004 19:58:52 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00CD8CB9@cherry.ease.lsoft.com>; Tue, 10 Feb 2004 19:58:50 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1702539 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Feb 2004 19:58:48 -0500 Received: from 203.199.83.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 10 Feb 2004 19:58:47 -0500 Received: (qmail 17721 invoked by uid 510); 11 Feb 2004 00:58:44 -0000 Received: from unknown (128.107.253.39) by rediffmail.com via HTTP; 11 feb 2004 00:58:44 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1076461124---0-203.199.83.148-17718" Message-ID: <20040211005844.17720.qmail@webmail26.rediffmail.com> Date: Wed, 11 Feb 2004 00:58:44 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Special handling for MaxSequenceNumber To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1076461124---0-203.199.83.148-17718 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0ASandy,
=0APoint is whether this needs to be addressed by:
=0A1)= Change in section 13.1(RFC 2328) - proposed by you.
=0AOR
=0A2) Chan= ge in section 13.4/14.1 (RFC 2328).
=0A
=0AI am not very convinced wi= th the change in (1) above yet.
=0A
=0AAcee - Whether by draft/errata= , depends on the solution agreed upon.
=0A
=0A-Vivek
=0A
=0A=0A
=0A
=0AOn Wed, 11 Feb 2004 Sandy Eng wrote :
=0A>Vivek,=0A>
=0A>Vivek Dubey wrote:
=0A>>But just changing the o= rder of comparisons (max age check before check sum)doesnt seems to solve t= he issue. What prevents "someone" from hacking the "age"= ; if that can be done with "sequence number".
=0A>>We'll= again end up in same condition.
=0A>
=0A>Agreed with the fact = that we are not attempting to prevent all hacks
=0A>with this change.= Just changing anything in an LSA content maliciously
=0A>  chan= ges the checksum right away, which by itself can cause a lot of
=0A>d= amage. However, the adjustment proposed fixes the somewhat broken logic
= =0A>for MAXSequenceNumber LSAs by allowing the network to repair the spo= of -
=0A>let the MAXSequenceNumber LSA gets flushed first before re-o= riginating a
=0A>new LSA with InitSequenceNumber.
=0A>
=0A&g= t;If the age is spoofed, either a fake MAXAGE LSA will override, or a fake<= BR>=0A>younger LSA will override (if the age difference between the spoo= fed and
=0A>existing LSAs is more than MaxAgeDiff). In both cases, th= e router will
=0A>eventually re-originate a new LSA with a larger seq= uence number. This
=0A>new LSA should eventually get flooded.
=0A&= gt;
=0A>For the MAXSequenceNumber case, we need to make sure we have = a way out -
=0A>to allow a new LSA to get re-originated.
=0A>=0A>Thanks,
=0A>Sandy
=0A>
=0A>
=0A>
=0A>= ;
=0A>>
=0A>>
=0A>>P.S: Pls bear the rich text. = I need to migrate my subscription to another ac.
=0A>>
=0A>&= gt;-Vivek
=0A>>
=0A>>
=0A>>
=0A>>On Tue= , 10 Feb 2004 Acee Lindem wrote :
=0A>>
=0A>>>This is = a real situation that can occur is someone spoofs a
=0A>>>MaxSe= quenceNumber LSA with a higher checksum than
=0A>>>the real one= . We discussed alternatives to fixing this. The other  we
=0A>&g= t;>discussed was the advertising router purging the errant more recent=0A>>>LSA prior to re-originating a new one with InitialSequence= Number.
=0A>>>It seemed more difficult since you'd need to reli= ably flood an LSA
=0A>>>that you don't install.
=0A>>&= gt;
=0A>>>Comments?
=0A>>>
=0A>>>Irresp= ective of the solution - should we handle this with RFC
=0A>>>e= rrata or a short draft?
=0A>>>
=0A>>>Thanks,
=0A= >>>Acee
=0A>>>
=0A>>>----- Original Messag= e -----
=0A>>> From: "Sandy Eng" <swkeng@CISCO.COM= >
=0A>>>To: <OSPF@PEACH.EASE.LSOFT.COM>
=0A>>= >Sent: Monday, February 09, 2004 5:56 AM
=0A>>>Subject: Spec= ial handling for MaxSequenceNumber
=0A>>>
=0A>>>=0A>>>
=0A>>>>Hi all,
=0A>>>>
= =0A>>>>A proposal to add special handling to RFC 2328, Section = 13.1
=0A>>>>"Determining which LSA is newer", for = LSAs with MaxSequenceNumber.
=0A>>>>
=0A>>>>S= cenario:
=0A>>>>=3D=3D=3D=3D=3D=3D=3D=3D=3D
=0A>>&g= t;>
=0A>>>>Rtr A  -------------- Rtr B
=0A>>= ;>>
=0A>>>>1) Rtr A receives a corrupted self-originat= ed router-LSA, due to attack
=0A>>>>or software bug, with Ma= xSequenceNumber and different LSA content. Rtr A
=0A>>>>&nbs= p; thinks it receives an old router-LSA, and tries to wrap the sequence
= =0A>>>>number and maxages this LSA, before re-originating a new= lsa.
=0A>>>>
=0A>>>>2) If Rtr B has already = received this corrupted packet, and later
=0A>>>>receives th= e MAXAGE LSA from Rtr A, due to a higher checksum value
=0A>>>&= gt;(comparison based on Section 13.1, RFC 2328) of the malformed packet, it=
=0A>>>>thinks its LSA is newer and sends it back to Rtr A.<= BR>=0A>>>>
=0A>>>>3) (1) - (2) repeats itself co= ntinuously. Meanwhile, Rtr A keeps
=0A>>>>retransmitting the= MAXAGE lsa as it receives no ACK from its neighbor(s).
=0A>>>&= gt;
=0A>>>>
=0A>>>>Proposed adjustment to Sec= tion 13.1, RFC 2328
=0A>>>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
=0A>>>>
=0A>>>>Fo= r the above scenario, if both the received and existing LSAs have
=0A>= ;>>>MaxSequenceNumber, it would only make sense to compare the age= next :
=0A>>>>
=0A>>>>if (both received and = existing LSAs have MaxSequenceNumber) {
=0A>>>>  if (Bo= th LS ages are different) {
=0A>>>>    swap second= and third bullet in Section 13.1 :
=0A>>>>    - p= roceed to compare age - third bullet in Section 13.1
=0A>>>>=     - then compare checksums - second bullet in Section 13.1
= =0A>>>>    ...
=0A>>>>  }
=0A&= gt;>>>  else
=0A>>>>    - proceed as= normal with checksums - second bullet in Section 13.1
=0A>>>&g= t;}
=0A>>>>
=0A>>>>This adjustment is in line= with what the RFC intended for a
=0A>>>>MaxSequenceNumber L= SA to do when wrapping - flush before originating a
=0A>>>>n= ew one, which is a special case. This modification is just ensuring
=0A&= gt;>>>this to be working as intended.
=0A>>>>
= =0A>>>>With all the security concerns we face today in the netw= ork, I think
=0A>>>>customers would appreciate this extra en= surance. Knowing a lot of
=0A>>>>networks today do not reach= MaxSequenceNumber, tempering with packets by
=0A>>>>setting= MaxSequenceNumber is too easy a hack to take down a network.
=0A>>= ;>>
=0A>>>>With backward compatibility in mind, we can= address this case for
=0A>>>>MaxSequenceNumber in our RFC.<= BR>=0A>>>>
=0A>>>>Please comment.
=0A>>= >>
=0A>>>>Thanks,
=0A>>>>Sandy
=0A&g= t;>>>
=0A>>>>
=0A>>>>Acee Lindem wro= te:
=0A>>>>
=0A>>>>>Sandy, Peter,
=0A&g= t;>>>>In thinking about it more, it will really be a pain to=0A>>>>>purge an LSA that isn't actually installed (in this= case I'm
=0A>>>>>referring to the MaxSequenceNumber LSA = received by
=0A>>>>>the originator). Hence, it may not be= that bad to go with
=0A>>>>>your suggestion to change th= e order of comparisons for
=0A>>>>>the case where the seq= uence number is at MAX. Since it
=0A>>>>>broken for this = case I don't see this as a severe backward
=0A>>>>>compat= ibility problem.
=0A>>>>>
=0A>>>>>Can y= ou take it to the list since you (or some testing your
=0A>>>&g= t;>product) originally discovered the problem.
=0A>>>>>= ;
=0A>>>>>Thanks,
=0A>>>>>Acee
=0A&g= t;>>>>
=0A>>>>
=0A>>
=0A=0A

=0A
=0A=0A --Next_1076461124---0-203.199.83.148-17718 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sandy,=0APoint is whether this needs to be addressed by:=0A1) Change in sec= tion 13.1(RFC 2328) - proposed by you.=0AOR=0A2) Change in section 13.4/14.= 1 (RFC 2328).=0A=0AI am not very convinced with the change in (1) above yet= .=0A=0AAcee - Whether by draft/errata, depends on the solution agreed upon.= =0A=0A-Vivek=0A=0A=0A=0A=0AOn Wed, 11 Feb 2004 Sandy Eng wrote :=0A>Vivek,= =0A>=0A>Vivek Dubey wrote:=0A>>But just changing the order of comparisons (= max age check before check sum)doesnt seems to solve the issue. What preven= ts "someone" from hacking the "age" if that can be done with "sequence numb= er".=0A>>We'll again end up in same condition.=0A>=0A>Agreed with the fact = that we are not attempting to prevent all hacks=0A>with this change. Just c= hanging anything in an LSA content maliciously=0A> changes the checksum ri= ght away, which by itself can cause a lot of=0A>damage. However, the adjust= ment proposed fixes the somewhat broken logic=0A>for MAXSequenceNumber LSAs= by allowing the network to repair the spoof -=0A>let the MAXSequenceNumber= LSA gets flushed first before re-originating a=0A>new LSA with InitSequenc= eNumber.=0A>=0A>If the age is spoofed, either a fake MAXAGE LSA will overri= de, or a fake=0A>younger LSA will override (if the age difference between t= he spoofed and=0A>existing LSAs is more than MaxAgeDiff). In both cases, th= e router will=0A>eventually re-originate a new LSA with a larger sequence n= umber. This=0A>new LSA should eventually get flooded.=0A>=0A>For the MAXSeq= uenceNumber case, we need to make sure we have a way out -=0A>to allow a ne= w LSA to get re-originated.=0A>=0A>Thanks,=0A>Sandy=0A>=0A>=0A>=0A>=0A>>=0A= >>=0A>>P.S: Pls bear the rich text. I need to migrate my subscription to an= other ac.=0A>>=0A>>-Vivek=0A>>=0A>>=0A>>=0A>>On Tue, 10 Feb 2004 Acee Linde= m wrote :=0A>>=0A>>>This is a real situation that can occur is someone spoo= fs a=0A>>>MaxSequenceNumber LSA with a higher checksum than=0A>>>the real o= ne. We discussed alternatives to fixing this. The other we=0A>>>discussed = was the advertising router purging the errant more recent=0A>>>LSA prior to= re-originating a new one with InitialSequenceNumber.=0A>>>It seemed more d= ifficult since you'd need to reliably flood an LSA=0A>>>that you don't inst= all.=0A>>>=0A>>>Comments?=0A>>>=0A>>>Irrespective of the solution - should = we handle this with RFC=0A>>>errata or a short draft?=0A>>>=0A>>>Thanks,=0A= >>>Acee=0A>>>=0A>>>----- Original Message -----=0A>>> From: "Sandy Eng" =0A>>>To: =0A>>>Sent: Monday, Feb= ruary 09, 2004 5:56 AM=0A>>>Subject: Special handling for MaxSequenceNumber= =0A>>>=0A>>>=0A>>>=0A>>>>Hi all,=0A>>>>=0A>>>>A proposal to add special han= dling to RFC 2328, Section 13.1=0A>>>>"Determining which LSA is newer", for= LSAs with MaxSequenceNumber.=0A>>>>=0A>>>>Scenario:=0A>>>>=3D=3D=3D=3D=3D= =3D=3D=3D=3D=0A>>>>=0A>>>>Rtr A -------------- Rtr B=0A>>>>=0A>>>>1) Rtr A= receives a corrupted self-originated router-LSA, due to attack=0A>>>>or so= ftware bug, with MaxSequenceNumber and different LSA content. Rtr A=0A>>>> = thinks it receives an old router-LSA, and tries to wrap the sequence=0A>>>= >number and maxages this LSA, before re-originating a new lsa.=0A>>>>=0A>>>= >2) If Rtr B has already received this corrupted packet, and later=0A>>>>re= ceives the MAXAGE LSA from Rtr A, due to a higher checksum value=0A>>>>(com= parison based on Section 13.1, RFC 2328) of the malformed packet, it=0A>>>>= thinks its LSA is newer and sends it back to Rtr A.=0A>>>>=0A>>>>3) (1) - (= 2) repeats itself continuously. Meanwhile, Rtr A keeps=0A>>>>retransmitting= the MAXAGE lsa as it receives no ACK from its neighbor(s).=0A>>>>=0A>>>>= =0A>>>>Proposed adjustment to Section 13.1, RFC 2328=0A>>>>=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A>>>>=0A>>>>For the above sc= enario, if both the received and existing LSAs have=0A>>>>MaxSequenceNumber= , it would only make sense to compare the age next :=0A>>>>=0A>>>>if (both = received and existing LSAs have MaxSequenceNumber) {=0A>>>> if (Both LS ag= es are different) {=0A>>>> swap second and third bullet in Section 13.1 = :=0A>>>> - proceed to compare age - third bullet in Section 13.1=0A>>>> = - then compare checksums - second bullet in Section 13.1=0A>>>> ...= =0A>>>> }=0A>>>> else=0A>>>> - proceed as normal with checksums - seco= nd bullet in Section 13.1=0A>>>>}=0A>>>>=0A>>>>This adjustment is in line w= ith what the RFC intended for a=0A>>>>MaxSequenceNumber LSA to do when wrap= ping - flush before originating a=0A>>>>new one, which is a special case. T= his modification is just ensuring=0A>>>>this to be working as intended.=0A>= >>>=0A>>>>With all the security concerns we face today in the network, I th= ink=0A>>>>customers would appreciate this extra ensurance. Knowing a lot of= =0A>>>>networks today do not reach MaxSequenceNumber, tempering with packet= s by=0A>>>>setting MaxSequenceNumber is too easy a hack to take down a netw= ork.=0A>>>>=0A>>>>With backward compatibility in mind, we can address this = case for=0A>>>>MaxSequenceNumber in our RFC.=0A>>>>=0A>>>>Please comment.= =0A>>>>=0A>>>>Thanks,=0A>>>>Sandy=0A>>>>=0A>>>>=0A>>>>Acee Lindem wrote:=0A= >>>>=0A>>>>>Sandy, Peter,=0A>>>>>In thinking about it more, it will really = be a pain to=0A>>>>>purge an LSA that isn't actually installed (in this cas= e I'm=0A>>>>>referring to the MaxSequenceNumber LSA received by=0A>>>>>the = originator). Hence, it may not be that bad to go with=0A>>>>>your suggestio= n to change the order of comparisons for=0A>>>>>the case where the sequence= number is at MAX. Since it=0A>>>>>broken for this case I don't see this as= a severe backward=0A>>>>>compatibility problem.=0A>>>>>=0A>>>>>Can you tak= e it to the list since you (or some testing your=0A>>>>>product) originally= discovered the problem.=0A>>>>>=0A>>>>>Thanks,=0A>>>>>Acee=0A>>>>>=0A>>>>= =0A>>=0A --Next_1076461124---0-203.199.83.148-17718-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 11 04:10:44 2004 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 EAA23359 for ; Wed, 11 Feb 2004 04:10:43 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00CD96B5@cherry.ease.lsoft.com>; Wed, 11 Feb 2004 4:10:40 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1751526 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Feb 2004 04:10:39 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Feb 2004 04:10:38 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 11 Feb 2004 01:18:09 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1B9Aau5028538 for ; Wed, 11 Feb 2004 01:10:37 -0800 (PST) Received: from cisco.com (sjc-vpn4-106.cisco.com [10.21.80.106]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQV08302; Wed, 11 Feb 2004 01:10:35 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20040211005844.17720.qmail@webmail26.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4029F189.4020202@cisco.com> Date: Wed, 11 Feb 2004 01:10:33 -0800 Reply-To: Mailing List Sender: Mailing List From: Sandy Eng Subject: Re: Special handling for MaxSequenceNumber To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vivek, Vivek Dubey wrote: > Sandy, > Point is whether this needs to be addressed by: > 1) Change in section 13.1(RFC 2328) - proposed by you. > OR > 2) Change in section 13.4/14.1 (RFC 2328). How do you suggest changing 13.4/14.1? -Sandy > > I am not very convinced with the change in (1) above yet. > > Acee - Whether by draft/errata, depends on the solution agreed upon. > > -Vivek > > > > > On Wed, 11 Feb 2004 Sandy Eng wrote : > >>Vivek, >> >>Vivek Dubey wrote: >> >>>But just changing the order of comparisons (max age check before check sum)doesnt seems to solve the issue. What prevents "someone" from hacking the "age" if that can be done with "sequence number". >>>We'll again end up in same condition. >> >>Agreed with the fact that we are not attempting to prevent all hacks >>with this change. Just changing anything in an LSA content maliciously >> changes the checksum right away, which by itself can cause a lot of >>damage. However, the adjustment proposed fixes the somewhat broken logic >>for MAXSequenceNumber LSAs by allowing the network to repair the spoof - >>let the MAXSequenceNumber LSA gets flushed first before re-originating a >>new LSA with InitSequenceNumber. >> >>If the age is spoofed, either a fake MAXAGE LSA will override, or a fake >>younger LSA will override (if the age difference between the spoofed and >>existing LSAs is more than MaxAgeDiff). In both cases, the router will >>eventually re-originate a new LSA with a larger sequence number. This >>new LSA should eventually get flooded. >> >>For the MAXSequenceNumber case, we need to make sure we have a way out - >>to allow a new LSA to get re-originated. >> >>Thanks, >>Sandy >> >> >> >> >> >>> >>>P.S: Pls bear the rich text. I need to migrate my subscription to another ac. >>> >>>-Vivek >>> >>> >>> >>>On Tue, 10 Feb 2004 Acee Lindem wrote : >>> >>> >>>>This is a real situation that can occur is someone spoofs a >>>>MaxSequenceNumber LSA with a higher checksum than >>>>the real one. We discussed alternatives to fixing this. The other we >>>>discussed was the advertising router purging the errant more recent >>>>LSA prior to re-originating a new one with InitialSequenceNumber. >>>>It seemed more difficult since you'd need to reliably flood an LSA >>>>that you don't install. >>>> >>>>Comments? >>>> >>>>Irrespective of the solution - should we handle this with RFC >>>>errata or a short draft? >>>> >>>>Thanks, >>>>Acee >>>> >>>>----- Original Message ----- >>>>From: "Sandy Eng" >>>>To: >>>>Sent: Monday, February 09, 2004 5:56 AM >>>>Subject: Special handling for MaxSequenceNumber >>>> >>>> >>>> >>>> >>>>>Hi all, >>>>> >>>>>A proposal to add special handling to RFC 2328, Section 13.1 >>>>>"Determining which LSA is newer", for LSAs with MaxSequenceNumber. >>>>> >>>>>Scenario: >>>>>========= >>>>> >>>>>Rtr A -------------- Rtr B >>>>> >>>>>1) Rtr A receives a corrupted self-originated router-LSA, due to attack >>>>>or software bug, with MaxSequenceNumber and different LSA content. Rtr A >>>>> thinks it receives an old router-LSA, and tries to wrap the sequence >>>>>number and maxages this LSA, before re-originating a new lsa. >>>>> >>>>>2) If Rtr B has already received this corrupted packet, and later >>>>>receives the MAXAGE LSA from Rtr A, due to a higher checksum value >>>>>(comparison based on Section 13.1, RFC 2328) of the malformed packet, it >>>>>thinks its LSA is newer and sends it back to Rtr A. >>>>> >>>>>3) (1) - (2) repeats itself continuously. Meanwhile, Rtr A keeps >>>>>retransmitting the MAXAGE lsa as it receives no ACK from its neighbor(s). >>>>> >>>>> >>>>>Proposed adjustment to Section 13.1, RFC 2328 >>>>>============================================= >>>>> >>>>>For the above scenario, if both the received and existing LSAs have >>>>>MaxSequenceNumber, it would only make sense to compare the age next : >>>>> >>>>>if (both received and existing LSAs have MaxSequenceNumber) { >>>>> if (Both LS ages are different) { >>>>> swap second and third bullet in Section 13.1 : >>>>> - proceed to compare age - third bullet in Section 13.1 >>>>> - then compare checksums - second bullet in Section 13.1 >>>>> ... >>>>> } >>>>> else >>>>> - proceed as normal with checksums - second bullet in Section 13.1 >>>>>} >>>>> >>>>>This adjustment is in line with what the RFC intended for a >>>>>MaxSequenceNumber LSA to do when wrapping - flush before originating a >>>>>new one, which is a special case. This modification is just ensuring >>>>>this to be working as intended. >>>>> >>>>>With all the security concerns we face today in the network, I think >>>>>customers would appreciate this extra ensurance. Knowing a lot of >>>>>networks today do not reach MaxSequenceNumber, tempering with packets by >>>>>setting MaxSequenceNumber is too easy a hack to take down a network. >>>>> >>>>>With backward compatibility in mind, we can address this case for >>>>>MaxSequenceNumber in our RFC. >>>>> >>>>>Please comment. >>>>> >>>>>Thanks, >>>>>Sandy >>>>> >>>>> >>>>>Acee Lindem wrote: >>>>> >>>>> >>>>>>Sandy, Peter, >>>>>>In thinking about it more, it will really be a pain to >>>>>>purge an LSA that isn't actually installed (in this case I'm >>>>>>referring to the MaxSequenceNumber LSA received by >>>>>>the originator). Hence, it may not be that bad to go with >>>>>>your suggestion to change the order of comparisons for >>>>>>the case where the sequence number is at MAX. Since it >>>>>>broken for this case I don't see this as a severe backward >>>>>>compatibility problem. >>>>>> >>>>>>Can you take it to the list since you (or some testing your >>>>>>product) originally discovered the problem. >>>>>> >>>>>>Thanks, >>>>>>Acee >>>>>> >>>>> > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 11 04:39:25 2004 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 EAA24775 for ; Wed, 11 Feb 2004 04:39:25 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00CD95A7@cherry.ease.lsoft.com>; Wed, 11 Feb 2004 4:39:25 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1752323 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Feb 2004 04:39:23 -0500 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Feb 2004 04:39:23 -0500 Received: (qmail 28631 invoked by uid 404); 11 Feb 2004 09:39:23 -0000 Received: from prz@xebeo.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.405724 secs); 11 Feb 2004 09:39:23 -0000 Received: from unknown (HELO xebeo.com) (172.16.1.102) by lxmail.nj.us.utstar.com with SMTP; 11 Feb 2004 09:39:22 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 X-Accept-Language: en-us, en MIME-Version: 1.0 References: X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4029F849.3000900@xebeo.com> Date: Wed, 11 Feb 2004 10:39:21 +0100 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: long SPF delays To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Dave Katz wrote: > On Tuesday, Feb 10, 2004, at 13:15 US/Pacific, Erblichs wrote: > >> This sounds that you believe that SPF throttling and packet pacing >> functionality by some companies isn't necessary. > > > I believe packet pacing is absolutely necessary (since there's no flow > control in the protocol, and the receiver may be dropping packets), but > that's quite distinct from LSA generation holddown. You're right, I > don't believe that SPF throttling is necessary, nor is it desirable > (except as a self-preservation measure when it looks like things are > really hosed.) Hmm, yes, so I had an interesting implementation experience (actually quite foreseable). And that was, that even if SPF is not running-to-completion but preemptively with optimistic shared-read locks [I slightly disagree with what Dave said, that people hold down because of running-to-completion, well implemented it's a pro-cons tradeoff of at least same quality and performance as preemptive, prefereable to me actually, since you have to put more work into implementation upfront but end up with less problems in deployment] there is the necessity to throttle SPF runs since otherwise fine-granularity locking and flooding stepping on spf locks and vice-versa at a certain p oint causes enough thrashing to make you back SPF off. So yes, I agree with Dave, it's only a self-preservation measure but I found, a necessary one. > > >> >> If packet pacing is implimented by some routers, then without SPF >> throttling, >> wouldn't sucessive SPF calculations occur? Of course, packet pacing >> is to spread out peak LSA xmits to min input buffer overflows, etc.. > well, spreading LSA xmits is another cause of longer convergence time. You end up with more SPF runs, most of them with incomplete information. So yes, you run SPF 'immediately' but since you don't have your LSAs around, you just have the illusion of having converged. Globally, you didn't. So, some packet pacing is necessary but it's not desirable for fast convergence. BTW, there is a decent Ph.D. thesis by George Apostopopoulus (oh, god, I probably misspelled) where he looked exactly into packet packing/LSA generation intervals/SPF delays vs. global convergence times. This was done in context of OSPF carrying QoS around so fairly close to this interest group. >> > > >> >> Lastly, with vastly cheaper memory subsystems and larger phys memories >> it is possible to decrease the amount of route aggregation to achieve >> better path routing. However, this will and does significantly increase >> the LSDB sizing, and secondarily normally increases the SPF computation >> duration beyond ms durations (in a large number of deployed routers) >> with LSDB sizing ranging from 500k to 2.5M > > > This doesn't increase the complexity of the SPF calculation, just the > sheer volume of leaf nodes to process. Optimizing this does not > require the relatively arcane algorithms that are favorites of > researchers; we're not talking about 500K vertices after all. This > case is just a matter of trying to minimize the amount of linear > slogging you have to do. > > Trying to run giant LSDBs will require a lot more things to scale than > just the SPF, which unfortunately is what people like to think about. > You also have to deal with the sheer volume of database exchange, the > max size of the Router LSA, and downloading all of those routes to the > forwarding engine, among other things. yepp, in this scenario optimizing SPF is a blip on the horizon only (and it's only a linear problem anyway). In fact, you start to push the architectural capability of the protocols (assuming you want it converged in time << infinity and even then, at certain point in time you start to regenerate LSAs before they got all places in the network == no convergence) thanks -- -tony From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 11 07:08:47 2004 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 HAA28387 for ; Wed, 11 Feb 2004 07:08:46 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00CD98AF@cherry.ease.lsoft.com>; Wed, 11 Feb 2004 7:08:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1788755 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Feb 2004 07:08:44 -0500 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Feb 2004 07:08:42 -0500 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Wed, 11 Feb 2004 17:38:22 +0530 Received: from vanitha (vanitha.future.futsoft.com [10.6.4.92]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id i1BC8A730040 for ; Wed, 11 Feb 2004 17:38:10 +0530 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-MS-TNEF-Correlator: 00000000C6E88EDCEFD6D711BC240050DAED411864977E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <009901c3f097$9642e440$5c04060a@future.futsoft.com> Date: Wed, 11 Feb 2004 17:37:12 +0530 Reply-To: Mailing List Sender: Mailing List From: Vanitha N Subject: Re: ospfv3 router dead Interval To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Vishwas, One more input. If an entry is added in ospfv3AreaAggregateTable with ospfv3AreaAggregateAreaLsdbType as NSSA, then this entry is used in the Type7 to Type 5 translation as per the RFC 3101 section 3.2. Hence the resultant aggregated LSA is Type 5. But the description of Ospfv3AreaAggregateRouteTag is "This tag is advertised in the summarized NSSA LSA only". We might have to change the description to give more clarity. Regards, Vanitha N. -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Vishwas Manral Sent: Thursday, 5 February 2004 7:26 PM To: OSPF@peach.ease.lsoft.com Subject: Re: ospfv3 router dead Interval Manish, You are right there. We will update it when we publish the next version of the MIB. Thanks., Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Manish Gupta Sent: Thursday, February 05, 2004 6:56 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: ospfv3 router dead Interval Hi, ospfv3IfRtrDeadInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-create STATUS current DESCRIPTION "The number of seconds that a router's Hello packets have not been seen before it's neigh- bors declare the router down. This should be some multiple of the Hello interval. This value must be the same for all routers attached to a common network." DEFVAL { 40 } ::= { ospfv3IfEntry 9 } I think this DeadInterval value can not be Unsigned32 since ospfv3 hello packet have only two bytes for RouterDeadInterval. range should be defined for DeadInterval like HelloRange for HelloInterval. regards Manish Gupta *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 11 07:34:20 2004 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 HAA28969 for ; Wed, 11 Feb 2004 07:34:20 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00CD9ADE@cherry.ease.lsoft.com>; Wed, 11 Feb 2004 7:34:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1790034 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Feb 2004 07:34:17 -0500 Received: from 202.43.216.213 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Feb 2004 07:34:16 -0500 Received: from [61.130.8.66] by web15410.mail.cnb.yahoo.com via HTTP; Wed, 11 Feb 2004 20:34:12 CST MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Message-ID: <20040211123412.99364.qmail@web15410.mail.cnb.yahoo.com> Date: Wed, 11 Feb 2004 20:34:12 +0800 Reply-To: Mailing List Sender: Mailing List From: =?gb2312?q?Jing=20Shen?= Subject: OSPF area planning recommandations To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4029F849.3000900@xebeo.com> Precedence: list Content-Transfer-Encoding: 8bit Hi, I'm looking for some recommandations or guidelines for OSPF area planning in ISP networks or enterprise networks. The target is to reach optimal point in cost-performance space. Is there someone would do me a favor ? thanks Jing Shen _________________________________________________________ Do You Yahoo!? ÍêÈ«Ãâ·ÑµÄÑÅ»¢µçÓÊ£¬ÂíÉÏ×¢²á»ñÔù¶îÍâ60Õ×ÍøÂç´æ´¢¿Õ¼ä http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.mail.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 11 09:53:01 2004 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 JAA03099 for ; Wed, 11 Feb 2004 09:53:01 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00CD9B53@cherry.ease.lsoft.com>; Wed, 11 Feb 2004 9:53:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1798108 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Feb 2004 09:52:58 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Feb 2004 09:52:58 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 11 Feb 2004 06:51:29 -0800 Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1BEquhu015658 for ; Wed, 11 Feb 2004 09:52:56 -0500 (EST) Received: from localhost (rtp-vpn2-106.cisco.com [10.82.240.106]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA29033 for ; Wed, 11 Feb 2004 09:52:56 -0500 (EST) X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 11 Feb 2004 09:52:54 -0500 Reply-To: Mailing List Sender: Mailing List From: Russ White Subject: Extensions to OSPF to Support Mobile Ad Hoc Networking To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Y'all: We are past the new work cutoff, so I'm posting this directly here, rather than waiting 'til after IETF to do so. I'll post it in the normal way after IETF is over. http://www.riw.us/temp/draft-chandra-ospf-manet-00.txt Abstract: This document describes extensions to OSPF to support mobile ad hoc networking. Specifically, the document specifies a mechanism for link-local signaling, a OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 11 12:50:42 2004 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 MAA11472 for ; Wed, 11 Feb 2004 12:50:32 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00CD9F45@cherry.ease.lsoft.com>; Wed, 11 Feb 2004 12:49:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1816692 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Feb 2004 12:49:51 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Feb 2004 12:49:49 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i1BHnhl95304 for ; Wed, 11 Feb 2004 09:49:45 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from juniper.net (nimbus-bsr.juniper.net [172.16.12.201]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1BHnch28421 for ; Wed, 11 Feb 2004 09:49:38 -0800 (PST) (envelope-from dkatz@juniper.net) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Message-ID: Date: Wed, 11 Feb 2004 09:49:35 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: long SPF delays To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4029F849.3000900@xebeo.com> Precedence: list Content-Transfer-Encoding: 7bit On Wednesday, Feb 11, 2004, at 01:39 US/Pacific, Tony Przygienda wrote: > > Hmm, yes, so I had an interesting implementation experience (actually > quite foreseable). And that was, that even if SPF is not > running-to-completion > but preemptively with optimistic shared-read locks > [I slightly disagree with what Dave said, that people hold down > because of > running-to-completion, well implemented it's a pro-cons tradeoff of at > least same > quality and performance > as preemptive, prefereable to me actually, since you have to put more > work into implementation upfront but end up with less problems in > deployment] > there is the necessity to throttle SPF runs since otherwise > fine-granularity locking > and flooding stepping on spf locks and vice-versa at a certain p oint > causes > enough thrashing to make you back SPF off. So yes, I agree with Dave, > it's > only a self-preservation measure but I found, a necessary one. There are more subtle methods than fixed-time holddowns that will accomplish the same thing (avoiding database lockout), but none of it is fundamentally necessary unless you are actually running into contention problems (I think we're in violent agreement here.) My point wasn't that nonpreemptive scheduling is the cause (or the only cause) of people doing long SPF holddowns; rather, long SPF holddowns were implemented as a bandaid for problems exacerbated by nonpreemptive environments. (I actually think that nonpreemptive environments are best for *most* of what goes on in a protocol; it makes for much more robust code if done properly.) > >> >> >>> >>> If packet pacing is implimented by some routers, then without SPF >>> throttling, >>> wouldn't sucessive SPF calculations occur? Of course, packet pacing >>> is to spread out peak LSA xmits to min input buffer overflows, etc.. >> > well, spreading LSA xmits is another cause of longer convergence time. > You end up with more SPF runs, most of them with incomplete > information. > So yes, you run SPF 'immediately' but since you don't have your LSAs > around, > you just have the illusion of having converged. Globally, you didn't. > So, some > packet pacing is necessary but it's not desirable for fast convergence. The fundamental problem is that there are competing goals: fast convergence and stability. Stability is primary, since it doesn't matter how fast your unstable network converges. The trick is to choose what cases you want to optimize (say, the fiber cut that requires rerouting 500,000 VoIP calls) and then Do the Right Thing. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 11 16:47:16 2004 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 QAA29197 for ; Wed, 11 Feb 2004 16:47:15 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00CDA6E7@cherry.ease.lsoft.com>; Wed, 11 Feb 2004 16:47:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1846506 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Feb 2004 16:47:10 -0500 Received: from 203.199.83.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Feb 2004 16:47:10 -0500 Received: (qmail 15465 invoked by uid 510); 11 Feb 2004 21:47:09 -0000 Received: from unknown (128.107.253.39) by rediffmail.com via HTTP; 11 feb 2004 21:47:09 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1076536029---0-203.199.83.148-15460" Message-ID: <20040211214709.15464.qmail@webmail26.rediffmail.com> Date: Wed, 11 Feb 2004 21:47:09 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Special handling for MaxSequenceNumber To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1076536029---0-203.199.83.148-15460 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0A1) Rtr A - Restarted.
=0A2) Rtr B - Holds LSA X (MaxSequenceNumber= ) originated by Rtr A before 
=0A         = ; Rtr A got restarted.
=0A3) Rtr A - Receives self originated LSA X wit= h MaxSequenceNumber.
=0A4) Two cases here:
=0A  a) Rtr A in a n= ew session has already originated LSA X:
=0A      a1) Rtr= A flushes the LSA X from routing domain by incrementing 
=0A = ;         the age to MaxAge.
=0A     = a2) Originates the new instance.
=0A  b) Rtr A no longer wishes t= o originate LSA X:
=0A      b1) Rtr A flushes the LSA X f= rom routing domain by incrementing 
=0A       =   the age to MaxAge.
=0ATill here it is assumed, there is no hack(= normal scenario) and checksum of LSA X is same i.e
=0ALsa X present in = Rtr B and MaxAge LSA X now sent by Rtr A.
=0ASo the problem does not occ= ur.
=0ABut as pointed out, somehow the checksum of LSA X at Rtr B is hig= her than that of MaxAge LSA X flooded by Rtr A.
=0A
=0A5) Rtr B sends= its copy of LSA X to Rtr A.
=0A6) So we again hit case (4) above. And a= s Sandy pointed out, this loop should be broken.
=0A
=0AMy thinking i= s, it would be better if the issue is solved at the senders side (Rtr A) ra= ther than at the receivers side (Rtr B).
=0A
=0A7) Rtr A should MaxAg= e the received LSA, and put this one on the 
=0A  retransmis= sion list removing the one with LSA checksum less, and
=0A  shoul= d flood it out.
=0A8) When Rtr B receives this MaxAge LSA X (checksum an= amoly) should be
=0A  taken care off.
=0A
=0AUnless until s= omebody is repeatedly hacking the LSAs, very unlikely.
=0AThe most like= ly reason we can hit the problem is because of some software bug.
=0ATh= ats one way i can think off, as of now.
=0A
=0A-Vivek
=0A =0A

= =0A

=0A=0A --Next_1076536029---0-203.199.83.148-15460 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 1) Rtr A - Restarted.=0A2) Rtr B - Holds LSA X (MaxSequenceNumber) originat= ed by Rtr A before =0A Rtr A got restarted.=0A3) Rtr A - Receive= s self originated LSA X with MaxSequenceNumber.=0A4) Two cases here:=0A a= ) Rtr A in a new session has already originated LSA X:=0A a1) Rtr A fl= ushes the LSA X from routing domain by incrementing =0A the age t= o MaxAge.=0A a2) Originates the new instance.=0A b) Rtr A no longer = wishes to originate LSA X:=0A b1) Rtr A flushes the LSA X from routing= domain by incrementing =0A the age to MaxAge.=0ATill here it is = assumed, there is no hack(normal scenario) and checksum of LSA X is same i.= e =0ALsa X present in Rtr B and MaxAge LSA X now sent by Rtr A.=0ASo the pr= oblem does not occur.=0ABut as pointed out, somehow the checksum of LSA X a= t Rtr B is higher than that of MaxAge LSA X flooded by Rtr A.=0A=0A5) Rtr B= sends its copy of LSA X to Rtr A.=0A6) So we again hit case (4) above. And= as Sandy pointed out, this loop should be broken.=0A=0AMy thinking is, it = would be better if the issue is solved at the senders side (Rtr A) rather t= han at the receivers side (Rtr B).=0A=0A7) Rtr A should MaxAge the received= LSA, and put this one on the =0A retransmission list removing the one w= ith LSA checksum less, and =0A should flood it out.=0A8) When Rtr B recei= ves this MaxAge LSA X (checksum anamoly) should be =0A taken care off.=0A= =0AUnless until somebody is repeatedly hacking the LSAs, very unlikely. =0A= The most likely reason we can hit the problem is because of some software b= ug. =0AThats one way i can think off, as of now.=0A=0A-Vivek=0A=20 --Next_1076536029---0-203.199.83.148-15460-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 11 19:33:55 2004 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 TAA13936 for ; Wed, 11 Feb 2004 19:33:54 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00CDAA79@cherry.ease.lsoft.com>; Wed, 11 Feb 2004 19:33:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1858547 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Feb 2004 19:33:47 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Feb 2004 19:33:47 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2004 16:34:33 -0800 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1C0Xi4U028675 for ; Wed, 11 Feb 2004 16:33:45 -0800 (PST) Received: from cisco.com (swkeng-u10.cisco.com [128.107.162.57]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQV91187; Wed, 11 Feb 2004 16:33:44 -0800 (PST) X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <20040211214709.15464.qmail@webmail26.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <402AC9E7.48B3EC7E@cisco.com> Date: Wed, 11 Feb 2004 16:33:43 -0800 Reply-To: Mailing List Sender: Mailing List From: Sandy Eng Subject: Re: Special handling for MaxSequenceNumber To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vivek, Vivek Dubey wrote: > > 1) Rtr A - Restarted. > 2) Rtr B - Holds LSA X (MaxSequenceNumber) originated by Rtr A before > Rtr A got restarted. > 3) Rtr A - Receives self originated LSA X with MaxSequenceNumber. > 4) Two cases here: > a) Rtr A in a new session has already originated LSA X: > a1) Rtr A flushes the LSA X from routing domain by incrementing > the age to MaxAge. > a2) Originates the new instance. > b) Rtr A no longer wishes to originate LSA X: > b1) Rtr A flushes the LSA X from routing domain by incrementing > the age to MaxAge. > Till here it is assumed, there is no hack(normal scenario) and checksum of LSA X is same i.e > Lsa X present in Rtr B and MaxAge LSA X now sent by Rtr A. > So the problem does not occur. > But as pointed out, somehow the checksum of LSA X at Rtr B is higher than that of MaxAge LSA X flooded by Rtr A. > > 5) Rtr B sends its copy of LSA X to Rtr A. > 6) So we again hit case (4) above. And as Sandy pointed out, this loop should be broken. > > My thinking is, it would be better if the issue is solved at the senders side (Rtr A) rather than at the receivers side (Rtr B). > > 7) Rtr A should MaxAge the received LSA, and put this one on the > retransmission list removing the one with LSA checksum less, and > should flood it out. > 8) When Rtr B receives this MaxAge LSA X (checksum anamoly) should be > taken care off. Acee and us had exactly the same discussion beforehand. The above will take a bit more work : 1) Rtr A tries to flush the MaxSequenceNumber LSA first. 2) Rtr B thinks its LSA is newer due to the larger checksum, and sends it back to Rtr A. 3) Rtr A sees this LSA, it will then flush this newer LSA as you mentioned above. If we just adjust the comparison routine, then right at (2) above, Rtr B knows that it will take the MAXAGE LSA instead. This saves the extra flooding effort of (2) and (3). > > Unless until somebody is repeatedly hacking the LSAs, very unlikely. > The most likely reason we can hit the problem is because of some software bug. > Thats one way i can think off, as of now. Imagine the case when Rtr A is replaced with another vendor's router, or a new version of software, loaded with the same config. Take the nebulous case when a router in NSSA does not *have* to have the N-bit set in a router-lsa (perhaps this is something we can re-define as well for the NSSA draft). This new hardware/software sets this bit in its router-lsa's option, whereas the old Rtr A didn't - of course we are assuming a network segment in NSSA here. An LSA with one bit of difference with the rest of the LSA content the same yields marked different checksum. In this case, the LSA with option 0x20 (old Rtr A) yeilds a larger checksum than option 0x28 (new Rtr A). If a bunch of routers in the network are transitioning hardware/software, you will have a network stuck in this packet storm of retransmission loops. Here is not an intentional attack. If it were an attack, it is highly likely the attacker can be maliciously enough to send malformed packets out repeatedly. Thanks, Sandy > > -Vivek > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 11 20:40:18 2004 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 UAA17439 for ; Wed, 11 Feb 2004 20:40:18 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00CDAB79@cherry.ease.lsoft.com>; Wed, 11 Feb 2004 20:40:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 1865116 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Feb 2004 20:40:13 -0500 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Feb 2004 20:40:13 -0500 Received: (qmail 8384 invoked by uid 404); 12 Feb 2004 01:40:13 -0000 Received: from prz@xebeo.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.482522 secs); 12 Feb 2004 01:40:13 -0000 Received: from unknown (HELO xebeo.com) (172.16.1.113) by lxmail.nj.us.utstar.com with SMTP; 12 Feb 2004 01:40:12 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 X-Accept-Language: en-us, en MIME-Version: 1.0 References: X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <402AD97B.6050308@xebeo.com> Date: Thu, 12 Feb 2004 02:40:11 +0100 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: long SPF delays To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Dave Katz wrote: > On Wednesday, Feb 11, 2004, at 01:39 US/Pacific, Tony Przygienda wrote: > >> >> Hmm, yes, so I had an interesting implementation experience (actually >> quite foreseable). And that was, that even if SPF is not >> running-to-completion >> but preemptively with optimistic shared-read locks >> [I slightly disagree with what Dave said, that people hold down >> because of >> running-to-completion, well implemented it's a pro-cons tradeoff of at >> least same >> quality and performance >> as preemptive, prefereable to me actually, since you have to put more >> work into implementation upfront but end up with less problems in >> deployment] >> there is the necessity to throttle SPF runs since otherwise >> fine-granularity locking >> and flooding stepping on spf locks and vice-versa at a certain p oint >> causes >> enough thrashing to make you back SPF off. So yes, I agree with Dave, >> it's >> only a self-preservation measure but I found, a necessary one. > > > There are more subtle methods than fixed-time holddowns that will > accomplish the same thing (avoiding database lockout), but none of it > is fundamentally necessary unless you are actually running into > contention problems (I think we're in violent agreement here.) > > My point wasn't that nonpreemptive scheduling is the cause (or the only > cause) of people doing long SPF holddowns; rather, long SPF holddowns > were implemented as a bandaid for problems exacerbated by nonpreemptive > environments. (I actually think that nonpreemptive environments are > best for *most* of what goes on in a protocol; it makes for much more > robust code if done properly.) 100% in sync -- tony From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 16:42:35 2004 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 QAA08025 for ; Fri, 13 Feb 2004 16:42:34 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00CDE279@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 16:42:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2127677 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 16:42:31 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 16:42:30 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D148968A02D for ; Fri, 13 Feb 2004 13:42:29 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08987-07 for ; Fri, 13 Feb 2004 13:42:29 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.217]) by prattle.redback.com (Postfix) with SMTP id 8563368A02C for ; Fri, 13 Feb 2004 13:42:28 -0800 (PST) References: <001b01c3e698$9bf83ba0$f86445ab@amer.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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <0b0e01c3f27a$44555200$0302a8c0@aceeinspiron> Date: Fri, 13 Feb 2004 16:42:23 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-mirtorabi-ospfv3-af-alt-01.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit We discussed making this a WG document in Minneapolis and all the mailing list discussion heretofore has been in favor of doing so. The only half ways dissenting opinions have come from those asking why not an approach using a single adjacency. I would think that this draft would not preclude this - in fact, the reserved instance ID range could be used for this purpose (did I say that?). Anyway, unless there is a strong objection this draft will be come a WG document. Thanks, Acee ----- Original Message ----- From: "Sina Mirtorabi" To: Sent: Thursday, January 29, 2004 1:49 PM Subject: I-D ACTION:draft-mirtorabi-ospfv3-af-alt-01.txt > Folks, > > A new version of address-family draft is available. The diffs are > > o Section 3, Instance ID range has been updated > > o Section 8, for IPv4 AF nexthop calculation, an IPv4 address will be > advertised in "link-local address filed" of Link-LSA. Previously this > address was advertised in prefix field with LA-bit set. > > o Section 9, adds the support of OSPFv3 over IPv4 > > o Section 10, VL support has been updated > > > Thanks > Sina > > -------------- > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Support of address families in OSPFv3 > Author(s) : S. Mirtorabi > Filename : draft-mirtorabi-ospfv3-af-alt-01.txt > Pages : 6 > Date : 2004-1-28 > > This document describes a mechanism for supporting multiple address > families in OSPFv3 using multiple instances. It maps an address family > (AF) to an OSPFv3 instance using the Instance ID field in the OSPFv3 > packet header. This approach is fairly simple and minimizes extensions > to OSPFv3 for supporting multiple AF's. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mirtorabi-ospfv3-af-alt-01.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-mirtorabi-ospfv3-af-alt-01.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-mirtorabi-ospfv3-af-alt-01.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. > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 16:55:32 2004 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 QAA09249 for ; Fri, 13 Feb 2004 16:55:32 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00CDE114@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 16:55:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2128539 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 16:55:32 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 16:55:32 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E405DA014A3 for ; Fri, 13 Feb 2004 13:55:30 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11130-02 for ; Fri, 13 Feb 2004 13:55:30 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.217]) by prattle.redback.com (Postfix) with SMTP id 2DD55A014A0 for ; Fri, 13 Feb 2004 13:55:30 -0800 (PST) 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <0b2201c3f27c$160cf400$0302a8c0@aceeinspiron> Date: Fri, 13 Feb 2004 16:55:25 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Multi-address and Tunnel Adjacency To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Speaking as a WG member, I think we should accept one of these drafts as a working group document since the requirement to share an OSPFv2 link over multiple areas without additional encapsulation has existed for some time. http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunnel-adjacency-01.txt http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-multi-area-adj-00.txt The multi-area adjacency draft provides the minimum functionality to use a link in multiple areas (without additional addressing or encapsulation). The TA draft solves this problem along with providing a mechanism to dynamically bring up tunnels through a transit area (the tunnel will be used for both data and the adjacency). Comments? ------ Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 17:05:01 2004 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 RAA09940 for ; Fri, 13 Feb 2004 17:05:01 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00CDE2C3@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 17:05:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2129882 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 17:05:00 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 17:05:00 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 4B97DA014A0 for ; Fri, 13 Feb 2004 14:04:59 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12811-04 for ; Fri, 13 Feb 2004 14:04:59 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.217]) by prattle.redback.com (Postfix) with SMTP id 76F01A014A2 for ; Fri, 13 Feb 2004 14:04:58 -0800 (PST) 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <0b3c01c3f27d$68ccc570$0302a8c0@aceeinspiron> Date: Fri, 13 Feb 2004 17:04:53 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF Local Link Signaling To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Speaking as a WG Co-Chair: This draft was considered years back in the context of graceful restart signaling. http://www.ietf.org/internet-drafts/draft-nguyen-ospf-lls-04.txt I think we should revisit it now as a general mechanism (I keep seeing new drafts that make use of it). I believe there are no Intellectual Property Rights (IPR) issues with this specification (please correct me if I'm wrong). Discussion??? ------ Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 17:14:46 2004 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 RAA10674 for ; Fri, 13 Feb 2004 17:14:46 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00CDE2D1@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 17:14:47 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2130465 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 17:14:46 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 17:14:46 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 319F1A014AC for ; Fri, 13 Feb 2004 14:14:45 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14223-10 for ; Fri, 13 Feb 2004 14:14:44 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.217]) by prattle.redback.com (Postfix) with SMTP id 04D96A014A6 for ; Fri, 13 Feb 2004 14:14:43 -0800 (PST) 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <0b5b01c3f27e$c59233c0$0302a8c0@aceeinspiron> Date: Fri, 13 Feb 2004 17:14:36 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPFv3 Traffic Engineering TLVs and TE Node Address TLV To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit We have draft-ietf-ospf-ospfv3-traffic-01.txt describing OSPFv3 traffic engineering TLVs. A new TLV, Router Address TLV, is proposed to carry a single routable IPv6 address. Additionally, at the last IETF, a new draft was presented, draft-raggarwa-ospf-te-node-addr-00.txt, which proposes the advertisement of multiple routable addresses. There seemed to be agreement that the draft was a logical extension of RFC 3630 and there was no opposition. It seems that if we accept the node address draft we should modify the OSPFv3 traffic engineering draft to add the requirement for a node address TLV specifying at least one routable IPv6 address. ------ Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 17:19:59 2004 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 RAA11036 for ; Fri, 13 Feb 2004 17:19:59 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00CDE2A9@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 17:20:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2130740 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 17:19:59 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 17:19:58 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E701858AAC1 for ; Fri, 13 Feb 2004 14:19:57 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15228-05 for ; Fri, 13 Feb 2004 14:19:57 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.217]) by prattle.redback.com (Postfix) with SMTP id 2B6CE58AAC0 for ; Fri, 13 Feb 2004 14:19:57 -0800 (PST) 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <0b7c01c3f27f$806ea890$0302a8c0@aceeinspiron> Date: Fri, 13 Feb 2004 17:19:51 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF Graceful Restart Implementation Report To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I intend to last call this document shortly after the next IETF. The proposed status will be informational. http://www.ietf.org/internet-drafts/draft-ietf-ospf-graceful-impl-report-01.txt ------ Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 17:21:32 2004 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 RAA11107 for ; Fri, 13 Feb 2004 17:21:32 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00CDE2EA@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 17:21:33 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2130857 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 17:21:31 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 17:21:31 -0500 Received: from rtp-iosxdm1.cisco.com (rtp-iosxdm1.cisco.com [64.102.16.214]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1DMLS4U009115 for ; Fri, 13 Feb 2004 14:21:29 -0800 (PST) Received: (lhnguyen@localhost) by rtp-iosxdm1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA09699 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 17:21:28 -0500 (EST) References: <0b3c01c3f27d$68ccc570$0302a8c0@aceeinspiron> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <20040213222128.GW12307@rtp-iosxdm1.cisco.com> Date: Fri, 13 Feb 2004 17:21:28 -0500 Reply-To: Mailing List Sender: Mailing List From: Liem Nguyen Subject: Re: OSPF Local Link Signaling To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <0b3c01c3f27d$68ccc570$0302a8c0@aceeinspiron> Precedence: list Acee, On Fri, Feb 13, 2004 at 05:04:53PM -0500, Acee Lindem wrote: > Speaking as a WG Co-Chair: > > This draft was considered years back in the context of graceful > restart signaling. > > http://www.ietf.org/internet-drafts/draft-nguyen-ospf-lls-04.txt > > I think we should revisit it now as a general mechanism (I keep > seeing new drafts that make use of it). I believe there are no > Intellectual Property Rights (IPR) issues with this specification > (please correct me if I'm wrong). There is no IRP for this draft. Liem From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 17:32:09 2004 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 RAA11708 for ; Fri, 13 Feb 2004 17:32:09 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00CDE2DE@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 17:32:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2131616 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 17:32:09 -0500 Received: from 65.223.109.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 17:32:08 -0500 Received: from localhost.localdomain (aluminium [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i1DMVwga001262; Fri, 13 Feb 2004 14:31:58 -0800 References: <0b5b01c3f27e$c59233c0$0302a8c0@aceeinspiron> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.2 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Fri, 13 Feb 2004 14:31:58 -0800 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: OSPFv3 Traffic Engineering TLVs and TE Node Address TLV Comments: cc: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <0b5b01c3f27e$c59233c0$0302a8c0@aceeinspiron> Precedence: list >It seems that if we accept the node address draft we should >modify the OSPFv3 traffic engineering draft to add the >requirement for a node address TLV specifying at least one >routable IPv6 address. I think so too. How do you think guys? -- Kunihiro Ishiguro From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 17:33:39 2004 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 RAA11796 for ; Fri, 13 Feb 2004 17:33:38 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00CDE34F@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 17:33:39 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2131686 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 17:33:37 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 17:33:37 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i1DMXZBm046561 for ; Fri, 13 Feb 2004 14:33:36 -0800 (PST) (envelope-from rahul@juniper.net) Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1DMXZo01054 for ; Fri, 13 Feb 2004 14:33:35 -0800 (PST) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id i1DMXZq69441 for ; Fri, 13 Feb 2004 14:33:35 -0800 (PST) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs References: <0b5b01c3f27e$c59233c0$0302a8c0@aceeinspiron> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20040213142454.Q61537@sapphire.juniper.net> Date: Fri, 13 Feb 2004 14:33:35 -0800 Reply-To: Mailing List Sender: Mailing List From: Rahul Aggarwal Subject: Re: OSPFv3 Traffic Engineering TLVs and TE Node Address TLV To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <0b5b01c3f27e$c59233c0$0302a8c0@aceeinspiron> Precedence: list Hi Acee, On Fri, 13 Feb 2004, Acee Lindem wrote: > We have draft-ietf-ospf-ospfv3-traffic-01.txt describing > OSPFv3 traffic engineering TLVs. A new TLV, Router Address TLV, > is proposed to carry a single routable IPv6 address. > > Additionally, at the last IETF, a new draft was presented, > draft-raggarwa-ospf-te-node-addr-00.txt, which proposes the > advertisement of multiple routable addresses. There seemed to > be agreement that the draft was a logical extension of > RFC 3630 and there was no opposition. > Thanks for bringing this up. I have been meaning to poll the list for moving this draft forward. > It seems that if we accept the node address draft we should > modify the OSPFv3 traffic engineering draft to add the > requirement for a node address TLV specifying at least one > routable IPv6 address. > The Node Address TLV is intended to carry local addresses, that are not otherwise advertised in OSPF TE (router ID, TE links, Router IPv6 Address). This can be clarified further in draft-raggarwa-ospf-te-node-addr-00.txt. Will that suffice ? Thanks, rahul > > > ------ > Acee > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 17:48:29 2004 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 RAA12099 for ; Fri, 13 Feb 2004 17:48:28 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00CDE3F3@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 17:48:28 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2132805 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 17:48:26 -0500 Received: from 169.144.2.221 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 17:48:26 -0500 Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <1TSCLKXK>; Fri, 13 Feb 2004 17:48:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55FB71E7@vie-msgusr-01.dc.fore.com> Date: Fri, 13 Feb 2004 17:48:25 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: OSPFv3 Traffic Engineering TLVs and TE Node Address TLV To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list -> The Node Address TLV is intended to carry local addresses, -> that are not -> otherwise advertised in OSPF TE (router ID, TE links, Router IPv6 -> Address). This can be clarified further in -> draft-raggarwa-ospf-te-node-addr-00.txt. Will that suffice ? If possible, can you please look at my previous question ? http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0311&L=ospf&T=0&F=&S=&P=732 Venkata. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 18:12:45 2004 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 SAA13892 for ; Fri, 13 Feb 2004 18:12:44 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00CDE3D3@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 18:12:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2134491 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 18:12:44 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 18:12:44 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i1DNChBm046659 for ; Fri, 13 Feb 2004 15:12:43 -0800 (PST) (envelope-from rahul@juniper.net) Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1DNCho05700 for ; Fri, 13 Feb 2004 15:12:43 -0800 (PST) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id i1DNChA74334 for ; Fri, 13 Feb 2004 15:12:43 -0800 (PST) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs References: <39469E08BD83D411A3D900204840EC55FB71E7@vie-msgusr-01.dc.fore.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20040213150711.V61537@sapphire.juniper.net> Date: Fri, 13 Feb 2004 15:12:43 -0800 Reply-To: Mailing List Sender: Mailing List From: Rahul Aggarwal Subject: Re: OSPFv3 Traffic Engineering TLVs and TE Node Address TLV To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC55FB71E7@vie-msgusr-01.dc.fore.com> Precedence: list Hi Venkata, On Fri, 13 Feb 2004, Naidu, Venkata wrote: > -> The Node Address TLV is intended to carry local addresses, > -> that are not > -> otherwise advertised in OSPF TE (router ID, TE links, Router IPv6 > -> Address). This can be clarified further in > -> draft-raggarwa-ospf-te-node-addr-00.txt. Will that suffice ? > > If possible, can you please look at my previous question ? > > http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0311&L=ospf&T=0&F=&S=&P=732 > Sorry, I missed your previous email. The question was: >In other words, why is Router LSA stub info not *sufficient* > to learn all local addresses (if we enable active/passive > OSPF routing over all those interfaces) ? It doesn't cover all the cases, in particular a P2P interface. For a P2P interface, as per RFC 2328: - If subnetted P2P: Link ID: subnet, Link Data: mask, Cost: Intf Cost This is not sufficient to add the local intf address of the advertising router, needed by TED. - If not subnetted P2P and nbr, LID: nbr address, LData: 0xffffffff, Cost: Intf Cost Same problem as above. Thanks for the comment. We can clarify this in the draft. rahul > Venkata. > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 18:16:01 2004 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 SAA14337 for ; Fri, 13 Feb 2004 18:16:01 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00CDE3FB@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 18:16:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2134645 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 18:16:01 -0500 Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 18:16:01 -0500 Received: from fuinar.juniper.net (localhost [127.0.0.1]) by fuinar.juniper.net (8.12.8p1/8.12.3) with ESMTP id i1DNG17s007865 for ; Fri, 13 Feb 2004 15:16:01 -0800 (PST) (envelope-from qv@fuinar.juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.12.8p1/8.12.3/Submit) id i1DNG1sU007862; Fri, 13 Feb 2004 15:16:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <0b2201c3f27c$160cf400$0302a8c0@aceeinspiron> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200402132316.i1DNG1sU007862@fuinar.juniper.net> Date: Fri, 13 Feb 2004 15:16:01 -0800 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Multi-address and Tunnel Adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <0b2201c3f27c$160cf400$0302a8c0@aceeinspiron> Precedence: list Content-Transfer-Encoding: 7bit I prefer the multi-area adjacency draft as it is simpler and cleaner in design. The other draft proposes something which is easier implemented using mechansims outside ospf. Quaizar > Speaking as a WG member, I think we should accept > one of these drafts as a working group document since the > requirement to share an OSPFv2 link over multiple areas > without additional encapsulation has existed for some > time. > > http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunnel-adjacency-01.txt > > http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-multi-area-adj-00.txt > > The multi-area adjacency draft provides the minimum functionality to > use a link in multiple areas (without additional addressing or encapsulation). > The TA draft solves this problem along with providing a mechanism to > dynamically bring up tunnels through a transit area (the tunnel will be > used for both data and the adjacency). > > Comments? > ------ > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 18:41:34 2004 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 SAA15763 for ; Fri, 13 Feb 2004 18:41:34 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00CDE33D@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 18:41:35 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2136145 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 18:41:34 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 18:41:33 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i1DNfXl06392 for ; Fri, 13 Feb 2004 15:41:33 -0800 (PST) (envelope-from rahul@juniper.net) Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1DNfSo08449 for ; Fri, 13 Feb 2004 15:41:28 -0800 (PST) (envelope-from rahul@juniper.net) Received: from localhost (rahul@localhost) by sapphire.juniper.net (8.11.6/8.11.3) with ESMTP id i1DNfS577857 for ; Fri, 13 Feb 2004 15:41:28 -0800 (PST) (envelope-from rahul@juniper.net) X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs References: <0b2201c3f27c$160cf400$0302a8c0@aceeinspiron> <200402132316.i1DNG1sU007862@fuinar.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20040213153722.L61537@sapphire.juniper.net> Date: Fri, 13 Feb 2004 15:41:28 -0800 Reply-To: Mailing List Sender: Mailing List From: Rahul Aggarwal Subject: Re: Multi-address and Tunnel Adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200402132316.i1DNG1sU007862@fuinar.juniper.net> Precedence: list On Fri, 13 Feb 2004, Quaizar Vohra wrote: > I prefer the multi-area adjacency draft as it is simpler and > cleaner in design. The other draft proposes something which is > easier implemented using mechansims outside ospf. > I would agree with that. rahul > Quaizar > > > Speaking as a WG member, I think we should accept > > one of these drafts as a working group document since the > > requirement to share an OSPFv2 link over multiple areas > > without additional encapsulation has existed for some > > time. > > > > http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunnel-adjacency-01.txt > > > > http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-multi-area-adj-00.txt > > > > The multi-area adjacency draft provides the minimum functionality to > > use a link in multiple areas (without additional addressing or encapsulation). > > The TA draft solves this problem along with providing a mechanism to > > dynamically bring up tunnels through a transit area (the tunnel will be > > used for both data and the adjacency). > > > > Comments? > > ------ > > Acee > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 18:47:36 2004 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 SAA15875 for ; Fri, 13 Feb 2004 18:47:35 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00CDE27E@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 18:47:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2136477 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 18:47:35 -0500 Received: from 203.199.83.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 18:47:34 -0500 Received: (qmail 17893 invoked by uid 510); 13 Feb 2004 23:47:31 -0000 Received: from unknown (128.107.253.39) by rediffmail.com via HTTP; 13 feb 2004 23:47:31 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1076716051---0-203.199.83.148-17889" Message-ID: <20040213234731.17892.qmail@webmail26.rediffmail.com> Date: Fri, 13 Feb 2004 23:47:31 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Special handling for MaxSequenceNumber To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1076716051---0-203.199.83.148-17889 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AInlined........<vivek>
=0A
=0AImagine the case when Rtr A= is replaced with another vendor's router, or
=0Aa new version of softwa= re, loaded with the same config. Take the
=0Anebulous case when a router= in NSSA does not *have* to have the N-bit
=0Aset in a router-lsa (perha= ps this is something we can re-define as well
=0Afor the NSSA draft). Th= is new hardware/software sets this bit in its
=0Arouter-lsa's option, wh= ereas the old Rtr A didn't - of course we are
=0Aassuming a network segm= ent in NSSA here.
=0AAn LSA with one bit of difference with the rest of = the LSA content the
=0Asame yields marked different checksum. In this ca= se, the LSA with option
=0A0x20 (old Rtr A) yeilds a larger checksum tha= n option 0x28 (new Rtr A).
=0AIf a bunch of routers in the network are t= ransitioning
=0Ahardware/software, you will have a network stuck in this= packet storm of
=0Aretransmission loops.
=0Avivek> Rtr A just flu= shes its old LSA and then only goes to originate new instance.So checksum a= nomaly should not occur.
=0AAnd in case of bug one more retransmission i= s not a "lot" of traffic.
=0A
=0A
=0AIf it were an attac= k, it is highly likely the attacker can be maliciously enough to send malfo= rmed packets out repeatedly.
=0Avivek> Remember Age field is not chec= ksum protected. By giving it weight over LS checksum we are making OSPF mor= e prone to attack rather than saving it.     
=0AFurthe= r, if it is hack, Seq No/Checksum/Age all three can be hacked, so by going = for Age check before checksum, security is not enahanced.
=0ABut we'll b= e more vulnerable to software bugs as Age field is not checksum protected.<= BR>=0A
=0A 
=0AIf we just adjust the comparison routine, then = right at (2) above, Rtr B
=0Aknows that it will take the MAXAGE LSA inst= ead. This saves the extra
=0Aflooding effort of (2) and (3).
=0Avivek= > I'll say this flooding is not "that" extra.
=0A
=0A=0A-Vivek
=0A
=0AOn Thu, 12 Feb 2004 Sandy Eng wrote :
=0A>Viv= ek,
=0A>
=0A>Vivek Dubey wrote:
=0A> >
=0A> >= 1) Rtr A - Restarted.
=0A> > 2) Rtr B - Holds LSA X (MaxSequenceN= umber) originated by Rtr A before
=0A> >       = ;     Rtr A got restarted.
=0A> > 3) Rtr A - Receives se= lf originated LSA X with MaxSequenceNumber.
=0A> > 4) Two cases he= re:
=0A> >    a) Rtr A in a new session has already orig= inated LSA X:
=0A> >      a1) Rtr A flushes the LS= A X from routing domain by incrementing
=0A> >     =     the age to MaxAge.
=0A> >      a2)= Originates the new instance.
=0A> >    b) Rtr A no long= er wishes to originate LSA X:
=0A> >      b1) Rtr = A flushes the LSA X from routing domain by incrementing
=0A> >&nbs= p;         the age to MaxAge.
=0A> > Till her= e it is assumed, there is no hack(normal scenario) and checksum of LSA X is= same i.e
=0A> > Lsa X present in Rtr B and MaxAge LSA X now sent = by Rtr A.
=0A> > So the problem does not occur.
=0A> > Bu= t as pointed out, somehow the checksum of LSA X at Rtr B is higher than tha= t of MaxAge LSA X flooded by Rtr A.
=0A> >
=0A> > 5) Rtr = B sends its copy of LSA X to Rtr A.
=0A> > 6) So we again hit case= (4) above. And as Sandy pointed out, this loop should be broken.
=0A>= ; >
=0A> > My thinking is, it would be better if the issue is s= olved at the senders side (Rtr A) rather than at the receivers side (Rtr B)= .
=0A> >
=0A> > 7) Rtr A should MaxAge the received LSA, = and put this one on the
=0A> >    retransmission list re= moving the one with LSA checksum less, and
=0A> >    sho= uld flood it out.
=0A> > 8) When Rtr B receives this MaxAge LSA X = (checksum anamoly) should be
=0A> >    taken care off.=0A>
=0A>Acee and us had exactly the same discussion beforehand.= The above will
=0A>take a bit more work :
=0A>
=0A>1) Rt= r A tries to flush the MaxSequenceNumber LSA first.
=0A>
=0A>2)= Rtr B thinks its LSA is newer due to the larger checksum, and sends
=0A= >it back to Rtr A.
=0A>
=0A>3) Rtr A sees this LSA, it will = then flush this newer LSA as you
=0A>mentioned above.
=0A>
= =0A>
=0A>If we just adjust the comparison routine, then right at (= 2) above, Rtr B
=0A>knows that it will take the MAXAGE LSA instead. T= his saves the extra
=0A>flooding effort of (2) and (3).
=0A>=0A>
=0A> >
=0A> > Unless until somebody is repeatedl= y hacking the LSAs, very unlikely.
=0A> > The most likely reason w= e can hit the problem is because of some software bug.
=0A> > That= s one way i can think off, as of now.
=0A>
=0A>Imagine the case= when Rtr A is replaced with another vendor's router, or
=0A>a new ve= rsion of software, loaded with the same config. Take the
=0A>nebulous= case when a router in NSSA does not *have* to have the N-bit
=0A>set= in a router-lsa (perhaps this is something we can re-define as well
=0A= >for the NSSA draft). This new hardware/software sets this bit in its=0A>router-lsa's option, whereas the old Rtr A didn't - of course we ar= e
=0A>assuming a network segment in NSSA here.
=0A>
=0A>A= n LSA with one bit of difference with the rest of the LSA content the
= =0A>same yields marked different checksum. In this case, the LSA with op= tion
=0A>0x20 (old Rtr A) yeilds a larger checksum than option 0x28 (= new Rtr A).
=0A>
=0A>If a bunch of routers in the network are t= ransitioning
=0A>hardware/software, you will have a network stuck in = this packet storm of
=0A>retransmission loops. Here is not an intenti= onal attack. If it were an
=0A>attack, it is highly likely the attack= er can be maliciously enough to
=0A>send malformed packets out repeat= edly.
=0A>
=0A>Thanks,
=0A>Sandy
=0A>
=0A>=0A>
=0A>
=0A> >
=0A> > -Vivek
=0A> ><= BR>=0A=0A

=0A

=0A=0A --Next_1076716051---0-203.199.83.148-17889 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Inlined........=0A=0AImagine the case when Rtr A is replaced with an= other vendor's router, or=0Aa new version of software, loaded with the same= config. Take the=0Anebulous case when a router in NSSA does not *have* to = have the N-bit=0Aset in a router-lsa (perhaps this is something we can re-d= efine as well=0Afor the NSSA draft). This new hardware/software sets this b= it in its=0Arouter-lsa's option, whereas the old Rtr A didn't - of course w= e are=0Aassuming a network segment in NSSA here.=0AAn LSA with one bit of d= ifference with the rest of the LSA content the=0Asame yields marked differe= nt checksum. In this case, the LSA with option=0A0x20 (old Rtr A) yeilds a = larger checksum than option 0x28 (new Rtr A).=0AIf a bunch of routers in th= e network are transitioning=0Ahardware/software, you will have a network st= uck in this packet storm of=0Aretransmission loops.=0Avivek> Rtr A just flu= shes its old LSA and then only goes to originate new instance.So checksum a= nomaly should not occur.=0AAnd in case of bug one more retransmission is no= t a "lot" of traffic.=0A=0A=0AIf it were an attack, it is highly likely the= attacker can be maliciously enough to send malformed packets out repeatedl= y.=0Avivek> Remember Age field is not checksum protected. By giving it weig= ht over LS checksum we are making OSPF more prone to attack rather than sav= ing it. =0AFurther, if it is hack, Seq No/Checksum/Age all three can = be hacked, so by going for Age check before checksum, security is not enaha= nced.=0ABut we'll be more vulnerable to software bugs as Age field is not c= hecksum protected.=0A=0A =0AIf we just adjust the comparison routine, the= n right at (2) above, Rtr B=0Aknows that it will take the MAXAGE LSA instea= d. This saves the extra=0Aflooding effort of (2) and (3).=0Avivek> I'll say= this flooding is not "that" extra.=0A=0A=0A-Vivek=0A=0AOn Thu, 12 Feb 2004= Sandy Eng wrote :=0A>Vivek,=0A>=0A>Vivek Dubey wrote:=0A> >=0A> > 1) Rtr A= - Restarted.=0A> > 2) Rtr B - Holds LSA X (MaxSequenceNumber) originated b= y Rtr A before=0A> > Rtr A got restarted.=0A> > 3) Rtr A - Recei= ves self originated LSA X with MaxSequenceNumber.=0A> > 4) Two cases here:= =0A> > a) Rtr A in a new session has already originated LSA X:=0A> > = a1) Rtr A flushes the LSA X from routing domain by incrementing=0A> > = the age to MaxAge.=0A> > a2) Originates the new instance.=0A>= > b) Rtr A no longer wishes to originate LSA X:=0A> > b1) Rtr A f= lushes the LSA X from routing domain by incrementing=0A> > the ag= e to MaxAge.=0A> > Till here it is assumed, there is no hack(normal scenari= o) and checksum of LSA X is same i.e=0A> > Lsa X present in Rtr B and MaxAg= e LSA X now sent by Rtr A.=0A> > So the problem does not occur.=0A> > But a= s pointed out, somehow the checksum of LSA X at Rtr B is higher than that o= f MaxAge LSA X flooded by Rtr A.=0A> >=0A> > 5) Rtr B sends its copy of LSA= X to Rtr A.=0A> > 6) So we again hit case (4) above. And as Sandy pointed = out, this loop should be broken.=0A> >=0A> > My thinking is, it would be be= tter if the issue is solved at the senders side (Rtr A) rather than at the = receivers side (Rtr B).=0A> >=0A> > 7) Rtr A should MaxAge the received LSA= , and put this one on the=0A> > retransmission list removing the one wit= h LSA checksum less, and=0A> > should flood it out.=0A> > 8) When Rtr B = receives this MaxAge LSA X (checksum anamoly) should be=0A> > taken care= off.=0A>=0A>Acee and us had exactly the same discussion beforehand. The ab= ove will=0A>take a bit more work :=0A>=0A>1) Rtr A tries to flush the MaxSe= quenceNumber LSA first.=0A>=0A>2) Rtr B thinks its LSA is newer due to the = larger checksum, and sends=0A>it back to Rtr A.=0A>=0A>3) Rtr A sees this L= SA, it will then flush this newer LSA as you=0A>mentioned above.=0A>=0A>=0A= >If we just adjust the comparison routine, then right at (2) above, Rtr B= =0A>knows that it will take the MAXAGE LSA instead. This saves the extra=0A= >flooding effort of (2) and (3).=0A>=0A>=0A> >=0A> > Unless until somebody = is repeatedly hacking the LSAs, very unlikely.=0A> > The most likely reason= we can hit the problem is because of some software bug.=0A> > Thats one wa= y i can think off, as of now.=0A>=0A>Imagine the case when Rtr A is replace= d with another vendor's router, or=0A>a new version of software, loaded wit= h the same config. Take the=0A>nebulous case when a router in NSSA does not= *have* to have the N-bit=0A>set in a router-lsa (perhaps this is something= we can re-define as well=0A>for the NSSA draft). This new hardware/softwar= e sets this bit in its=0A>router-lsa's option, whereas the old Rtr A didn't= - of course we are=0A>assuming a network segment in NSSA here.=0A>=0A>An L= SA with one bit of difference with the rest of the LSA content the=0A>same = yields marked different checksum. In this case, the LSA with option=0A>0x20= (old Rtr A) yeilds a larger checksum than option 0x28 (new Rtr A).=0A>=0A>= If a bunch of routers in the network are transitioning=0A>hardware/software= , you will have a network stuck in this packet storm of=0A>retransmission l= oops. Here is not an intentional attack. If it were an=0A>attack, it is hig= hly likely the attacker can be maliciously enough to=0A>send malformed pack= ets out repeatedly.=0A>=0A>Thanks,=0A>Sandy=0A>=0A>=0A>=0A>=0A> >=0A> > -Vi= vek=0A> >=0A --Next_1076716051---0-203.199.83.148-17889-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 20:04:32 2004 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 UAA18035 for ; Fri, 13 Feb 2004 20:04:31 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00CDE582@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 20:04:31 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2144024 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 20:04:29 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 20:04:29 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 13 Feb 2004 17:12:31 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1E14Q1m006464 for ; Fri, 13 Feb 2004 17:04:27 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-247.cisco.com [128.107.163.247]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQY07429; Fri, 13 Feb 2004 17:04:26 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20040213234731.17892.qmail@webmail26.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <402D741A.103@cisco.com> Date: Fri, 13 Feb 2004 17:04:26 -0800 Reply-To: Mailing List Sender: Mailing List From: Sandy Eng Subject: Re: Special handling for MaxSequenceNumber To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vivek, Vivek Dubey wrote: > Inlined........ > > Imagine the case when Rtr A is replaced with another vendor's router, or > a new version of software, loaded with the same config. Take the > nebulous case when a router in NSSA does not *have* to have the N-bit > set in a router-lsa (perhaps this is something we can re-define as well > for the NSSA draft). This new hardware/software sets this bit in its > router-lsa's option, whereas the old Rtr A didn't - of course we are > assuming a network segment in NSSA here. > An LSA with one bit of difference with the rest of the LSA content the > same yields marked different checksum. In this case, the LSA with option > 0x20 (old Rtr A) yeilds a larger checksum than option 0x28 (new Rtr A). > If a bunch of routers in the network are transitioning > hardware/software, you will have a network stuck in this packet storm of > retransmission loops. > vivek> Rtr A just flushes its old LSA and then only goes to originate new instance.So checksum anomaly should not occur. > And in case of bug one more retransmission is not a "lot" of traffic. Rtr A could not flush its old LSA here. If the old LSA had a larger checksum, when Rtr A comes up to receive this old self-originated LSA, its MAXAGE LSA will not be accepted due to the smaller checksum, and the same loop will happen here. > > > If it were an attack, it is highly likely the attacker can be maliciously enough to send malformed packets out repeatedly. > vivek> Remember Age field is not checksum protected. By giving it weight over LS checksum we are making OSPF more prone to attack rather than saving it. > Further, if it is hack, Seq No/Checksum/Age all three can be hacked, so by going for Age check before checksum, security is not enahanced. > But we'll be more vulnerable to software bugs as Age field is not checksum protected. Again, we are only talking the specific case of MaxSequenceNumber LSAs here, and as I mentioned in previous email, we are not attempting to prevent all hacks with this change, but to give MaxSequencNumber LSAs with MAXAGE a chance to go through the wrapping process, and in many cases, this could repair the anomaly in the network. > > > If we just adjust the comparison routine, then right at (2) above, Rtr B > knows that it will take the MAXAGE LSA instead. This saves the extra > flooding effort of (2) and (3). > vivek> I'll say this flooding is not "that" extra. I would think any extra flooding is an overhead, especially in a large network with high number of links. Thanks, Sandy > > > -Vivek > > On Thu, 12 Feb 2004 Sandy Eng wrote : > >>Vivek, >> >>Vivek Dubey wrote: >> >>>1) Rtr A - Restarted. >>>2) Rtr B - Holds LSA X (MaxSequenceNumber) originated by Rtr A before >>> Rtr A got restarted. >>>3) Rtr A - Receives self originated LSA X with MaxSequenceNumber. >>>4) Two cases here: >>> a) Rtr A in a new session has already originated LSA X: >>> a1) Rtr A flushes the LSA X from routing domain by incrementing >>> the age to MaxAge. >>> a2) Originates the new instance. >>> b) Rtr A no longer wishes to originate LSA X: >>> b1) Rtr A flushes the LSA X from routing domain by incrementing >>> the age to MaxAge. >>>Till here it is assumed, there is no hack(normal scenario) and checksum of LSA X is same i.e >>>Lsa X present in Rtr B and MaxAge LSA X now sent by Rtr A. >>>So the problem does not occur. >>>But as pointed out, somehow the checksum of LSA X at Rtr B is higher than that of MaxAge LSA X flooded by Rtr A. >>> >>>5) Rtr B sends its copy of LSA X to Rtr A. >>>6) So we again hit case (4) above. And as Sandy pointed out, this loop should be broken. >>> >>>My thinking is, it would be better if the issue is solved at the senders side (Rtr A) rather than at the receivers side (Rtr B). >>> >>>7) Rtr A should MaxAge the received LSA, and put this one on the >>> retransmission list removing the one with LSA checksum less, and >>> should flood it out. >>>8) When Rtr B receives this MaxAge LSA X (checksum anamoly) should be >>> taken care off. >> >>Acee and us had exactly the same discussion beforehand. The above will >>take a bit more work : >> >>1) Rtr A tries to flush the MaxSequenceNumber LSA first. >> >>2) Rtr B thinks its LSA is newer due to the larger checksum, and sends >>it back to Rtr A. >> >>3) Rtr A sees this LSA, it will then flush this newer LSA as you >>mentioned above. >> >> >>If we just adjust the comparison routine, then right at (2) above, Rtr B >>knows that it will take the MAXAGE LSA instead. This saves the extra >>flooding effort of (2) and (3). >> >> >> >>>Unless until somebody is repeatedly hacking the LSAs, very unlikely. >>>The most likely reason we can hit the problem is because of some software bug. >>>Thats one way i can think off, as of now. >> >>Imagine the case when Rtr A is replaced with another vendor's router, or >>a new version of software, loaded with the same config. Take the >>nebulous case when a router in NSSA does not *have* to have the N-bit >>set in a router-lsa (perhaps this is something we can re-define as well >>for the NSSA draft). This new hardware/software sets this bit in its >>router-lsa's option, whereas the old Rtr A didn't - of course we are >>assuming a network segment in NSSA here. >> >>An LSA with one bit of difference with the rest of the LSA content the >>same yields marked different checksum. In this case, the LSA with option >>0x20 (old Rtr A) yeilds a larger checksum than option 0x28 (new Rtr A). >> >>If a bunch of routers in the network are transitioning >>hardware/software, you will have a network stuck in this packet storm of >>retransmission loops. Here is not an intentional attack. If it were an >>attack, it is highly likely the attacker can be maliciously enough to >>send malformed packets out repeatedly. >> >>Thanks, >>Sandy >> >> >> >> >> >>>-Vivek >>> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 13 20:51:26 2004 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 UAA19403 for ; Fri, 13 Feb 2004 20:51:26 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00CDE67A@cherry.ease.lsoft.com>; Fri, 13 Feb 2004 20:51:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2146120 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Feb 2004 20:51:24 -0500 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 13 Feb 2004 20:51:24 -0500 Received: from smirtoraw2k03 (sjc-vpn4-310.cisco.com [10.21.81.54]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i1E1pNi02692 for ; Fri, 13 Feb 2004 17:51:23 -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.4927.1200 Message-ID: <019d01c3f29d$0cc6ac80$f86445ab@amer.cisco.com> Date: Fri, 13 Feb 2004 17:51:21 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Multi-address and Tunnel Adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200402132316.i1DNG1sU007862@fuinar.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Quaizar, Rahul Although there is a small overlap for a single hop case I do not think that the two drafts really compete as they solve different problems. Tunnel adjacency solve the case where ABR are multi-hops and further provide an automatic partition repair for the non-backbone areas. If you refer to GRE tunnel as an alternative solution, there are draw backs in it such as extra configuration overhead, extra IP address for tunnel, relying on IP reachbility versus SPF reachability and besides the manual tunnel does not provide automatic partition repair. I believe an implementation can decide to implement either, both or none of the solutions however customers needs different solutions and I know customers who are interested in automatic partition repair solution of TA. Thanks Sina ->-----Original Message----- ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On ->Behalf Of Quaizar Vohra ->Sent: Friday, February 13, 2004 3:16 PM ->To: OSPF@PEACH.EASE.LSOFT.COM ->Subject: Multi-address and Tunnel Adjacency -> -> ->I prefer the multi-area adjacency draft as it is simpler and ->cleaner in design. The other draft proposes something which ->is easier implemented using mechansims outside ospf. -> ->Quaizar -> -> > Speaking as a WG member, I think we should accept -> > one of these drafts as a working group document since the -> > requirement to share an OSPFv2 link over multiple areas -> > without additional encapsulation has existed for some -> > time. -> > -> > ->http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunne l-adjacency-01.txt > > http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-multi-area-adj- 00.txt > > The multi-area adjacency draft provides the minimum functionality to > use a link in multiple areas (without additional addressing or encapsulation). > The TA draft solves this problem along with providing a mechanism to > dynamically bring up tunnels through a transit area (the tunnel will be > used for both data and the adjacency). > > Comments? > ------ > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Sat Feb 14 16:16:27 2004 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 QAA01411 for ; Sat, 14 Feb 2004 16:16:27 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00CDF55A@cherry.ease.lsoft.com>; Sat, 14 Feb 2004 16:16:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2242216 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 14 Feb 2004 16:16:25 -0500 Received: from 209.119.0.34 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 14 Feb 2004 16:06:25 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <12.0040071E@grape.ease.lsoft.com>; Sat, 14 Feb 2004 16:06:25 -0500 Message-ID: Date: Sat, 14 Feb 2004 16:06:24 -0500 Reply-To: Mailing List Sender: Mailing List From: Balki S Subject: OSPF sequence number wrapping To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list can someone please help me. When sequence number of LSA reaches max_sequence_number, how does OSPF handle this. Does it shut down for long period (until LSA ages out) or does it just flush the max_seq LSA , then sending the seq number 1 ? balki From owner-ospf@PEACH.EASE.LSOFT.COM Sat Feb 14 20:24:48 2004 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 UAA08142 for ; Sat, 14 Feb 2004 20:24:48 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00CDF95B@cherry.ease.lsoft.com>; Sat, 14 Feb 2004 20:24:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2252936 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 14 Feb 2004 20:24:45 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 14 Feb 2004 20:24:44 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D665E3F7B3C for ; Sat, 14 Feb 2004 17:24:43 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05530-03 for ; Sat, 14 Feb 2004 17:24:43 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.217]) by prattle.redback.com (Postfix) with SMTP id B92593F7B38 for ; Sat, 14 Feb 2004 17:24:42 -0800 (PST) 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <0c2e01c3f362$78d622f0$0302a8c0@aceeinspiron> Date: Sat, 14 Feb 2004 20:24:34 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF sequence number wrapping To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Balki S" To: Sent: Saturday, February 14, 2004 4:06 PM Subject: OSPF sequence number wrapping > can someone please help me. > When sequence number of LSA reaches max_sequence_number, how does OSPF > handle this. Does it shut down for long period (until LSA ages out) or does > it just flush the max_seq LSA , then sending the seq number 1 ? Hi Balki, The latter. This is documented in RFC 2328, Section 12.1.5. Hope this helps, Acee > > balki From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 02:03:23 2004 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 CAA19328 for ; Mon, 16 Feb 2004 02:03:23 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00CE12B6@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 2:03:20 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2379799 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 02:03:18 -0500 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 02:03:17 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1G73G314758 for ; Mon, 16 Feb 2004 09:03:16 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 16 Feb 2004 09:03:16 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Feb 2004 01:03:13 -0600 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Highly Available OSPF Router. Thread-Index: AcP0WvAXH4lElLb1QP6LjcW7zbM4SA== X-OriginalArrivalTime: 16 Feb 2004 07:03:13.0932 (UTC) FILETIME=[F1E904C0:01C3F45A] Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABEA0@daebe009.americas.nokia.com> Date: Mon, 16 Feb 2004 01:03:13 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Has anyone implemented an OSPF HA where two or more OSPF routers appear as one OSPF router to the OSPF neighbors. One of the routers=20 (the Master) talks to the external world (OSPF neighbors) and the=20 others (the Backups) keep all the dynamic OSPF state (neighbors, database etc) in sync with the Master. When the Master dies, one of the backup router takes over immediately without the neighbors realizing any change in the network ? If anyone has implemented any such thing, I would like to hear about how they do it. I would also like to know if the WG would be interested in standardizing such a mechanism ? At least I think that it will be a useful thing !! Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 02:10:11 2004 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 CAA24109 for ; Mon, 16 Feb 2004 02:10:11 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00CE1466@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 2:10:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2380056 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 02:10:09 -0500 Received: from 67.17.166.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 02:10:09 -0500 Received: from homejtm01a43f8 (unverified [24.5.244.52]) by ucmmail.com (Rockliffe SMTPRA 5.3.6) with ESMTP id for ; Mon, 16 Feb 2004 02:10:09 -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, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Message-ID: <000201c3f45c$76b8d8a0$6400a8c0@homejtm01a43f8> Date: Sun, 15 Feb 2004 23:14:05 -0800 Reply-To: Mailing List Sender: Mailing List From: Farshad Tavallaei Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABEA0@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Mukesh, What are the benefits of this idea over the current implementation of OSPF? Sean -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mukesh.Gupta@NOKIA.COM Sent: Sunday, February 15, 2004 11:03 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Highly Available OSPF Router. Has anyone implemented an OSPF HA where two or more OSPF routers appear as one OSPF router to the OSPF neighbors. One of the routers (the Master) talks to the external world (OSPF neighbors) and the others (the Backups) keep all the dynamic OSPF state (neighbors, database etc) in sync with the Master. When the Master dies, one of the backup router takes over immediately without the neighbors realizing any change in the network ? If anyone has implemented any such thing, I would like to hear about how they do it. I would also like to know if the WG would be interested in standardizing such a mechanism ? At least I think that it will be a useful thing !! Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 02:12:46 2004 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 CAA26226 for ; Mon, 16 Feb 2004 02:12:45 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00CE14DF@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 2:12:45 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2380138 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 02:12:44 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 02:12:43 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Highly Available OSPF Router. thread-index: AcP0WvAXH4lElLb1QP6LjcW7zbM4SAAAMCbw Message-ID: Date: Sun, 15 Feb 2004 23:11:02 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Mukesh, I know and have worked on one such implementation = http://mcg.motorola.com/netplane/. I do not see any reason why things should be standardized in OSPF = working group at all. You may however want to have a look at the SAForum = site http://www.saforum.org/home. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Mukesh.Gupta@NOKIA.COM Sent: Monday, February 16, 2004 12:33 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Highly Available OSPF Router. Has anyone implemented an OSPF HA where two or more OSPF routers appear as one OSPF router to the OSPF neighbors. One of the routers=20 (the Master) talks to the external world (OSPF neighbors) and the=20 others (the Backups) keep all the dynamic OSPF state (neighbors, database etc) in sync with the Master. When the Master dies, one of the backup router takes over immediately without the neighbors realizing any change in the network ? If anyone has implemented any such thing, I would like to hear about how they do it. I would also like to know if the WG would be interested in standardizing such a mechanism ? At least I think that it will be a useful thing !! Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 02:19:30 2004 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 CAA00285 for ; Mon, 16 Feb 2004 02:19:29 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00CE1454@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 2:19:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2380357 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 02:19:26 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 02:19:26 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i1G7JPl19726 for ; Sun, 15 Feb 2004 23:19:25 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from juniper.net (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1G7JKo12489 for ; Sun, 15 Feb 2004 23:19:20 -0800 (PST) (envelope-from dkatz@juniper.net) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Message-ID: <700342AF-6050-11D8-BA5D-000A95A55D88@juniper.net> Date: Sun, 15 Feb 2004 23:19:20 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABEA0@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit I suspect a number of folks are working on things like this. However, the way you describe it says that it in fact is not subject to standardization, since it does what it does without the neighbors realizing (nothing outside the "black box.") Therefore it is only an implementation trick, not something to be standardized. --Dave On Sunday, Feb 15, 2004, at 23:03 US/Pacific, Mukesh.Gupta@NOKIA.COM wrote: > Has anyone implemented an OSPF HA where two or more OSPF routers > appear as one OSPF router to the OSPF neighbors. One of the routers > (the Master) talks to the external world (OSPF neighbors) and the > others (the Backups) keep all the dynamic OSPF state (neighbors, > database etc) in sync with the Master. When the Master dies, one of > the backup router takes over immediately without the neighbors > realizing any change in the network ? > > If anyone has implemented any such thing, I would like to hear about > how they do it. I would also like to know if the WG would be interested > in standardizing such a mechanism ? At least I think that it will be > a useful thing !! > > Regards > Mukesh > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 02:24:00 2004 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 CAA00619 for ; Mon, 16 Feb 2004 02:24:00 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00CE14EF@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 2:24:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2380520 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 02:23:56 -0500 Received: from 192.11.222.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 02:23:56 -0500 Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com [135.254.246.205]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1G7Nqr15988 for ; Mon, 16 Feb 2004 01:23:52 -0600 (CST) Received: by ii0015exch002u.wins.lucent.com with Internet Mail Service (5.5.2657.72) id <16ZZTLY0>; Mon, 16 Feb 2004 12:53:49 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <6733C768256DEC42A72BAFEFA9CF06D208840DAA@ii0015exch002u.wins.lucent.com> Date: Mon, 16 Feb 2004 12:53:44 +0530 Reply-To: Mailing List Sender: Mailing List From: "Ramalingam, Swaminathan (Swaminathan)" Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Mukesh, Do u mean multi-level hierarchy in OSPF?. Present two-level hierarchy in OSPF is too good enough to achieve scalability in any big network. Do you really see any necessity for this?. If so, could you explain where it can be useful?. Swami >-----Original Message----- >From: Mukesh.Gupta@NOKIA.COM [mailto:Mukesh.Gupta@NOKIA.COM] >Sent: Monday, February 16, 2004 12:33 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Highly Available OSPF Router. > > >Has anyone implemented an OSPF HA where two or more OSPF routers >appear as one OSPF router to the OSPF neighbors. One of the routers >(the Master) talks to the external world (OSPF neighbors) and the >others (the Backups) keep all the dynamic OSPF state (neighbors, >database etc) in sync with the Master. When the Master dies, one of >the backup router takes over immediately without the neighbors >realizing any change in the network ? > >If anyone has implemented any such thing, I would like to hear about >how they do it. I would also like to know if the WG would be interested >in standardizing such a mechanism ? At least I think that it will be >a useful thing !! > >Regards >Mukesh > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 02:26:32 2004 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 CAA00849 for ; Mon, 16 Feb 2004 02:26:31 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00CE13D9@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 2:26:31 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2380599 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 02:26:28 -0500 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 02:26:26 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1G7QP314113 for ; Mon, 16 Feb 2004 09:26:25 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 16 Feb 2004 09:26:04 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 15 Feb 2004 23:26:03 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Highly Available OSPF Router. Thread-Index: AcP0XTxGRAmiFIEySJmkZVsp/Elj1AAAC18A X-OriginalArrivalTime: 16 Feb 2004 07:26:03.0327 (UTC) FILETIME=[22221CF0:01C3F45E] Message-ID: <8D260779A766FB4A9C1739A476F84FA401547266@daebe009.americas.nokia.com> Date: Mon, 16 Feb 2004 01:26:02 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Thanks for the quick responses :) Ok let me take the word "standardized" back ! I meant to ask "will it be useful to write an informational document on how to do this implementation trick for OSPF" ? I am sure every implementor will have to think about the same issues like: - what are the tasks that are just performed by the Master and not by the backups. - How to synchronize the initial state between the master and=20 the member. - How to keep the state in sync. - What actions to perform at the time of the swithover (master dying and backup taking over). etc. etc. Why not write a document and make it easier for everyone ?? Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Dave Katz > Sent: Sunday, February 15, 2004 11:19 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Highly Available OSPF Router. >=20 >=20 > I suspect a number of folks are working on things like this. >=20 > However, the way you describe it says that it in fact is not=20 > subject to > standardization, since it does what it does without the neighbors > realizing (nothing outside the "black box.") Therefore it is only an > implementation trick, not something to be standardized. >=20 > --Dave >=20 > On Sunday, Feb 15, 2004, at 23:03 US/Pacific, Mukesh.Gupta@NOKIA.COM > wrote: >=20 > > Has anyone implemented an OSPF HA where two or more OSPF routers > > appear as one OSPF router to the OSPF neighbors. One of the routers > > (the Master) talks to the external world (OSPF neighbors) and the > > others (the Backups) keep all the dynamic OSPF state (neighbors, > > database etc) in sync with the Master. When the Master dies, one of > > the backup router takes over immediately without the neighbors > > realizing any change in the network ? > > > > If anyone has implemented any such thing, I would like to hear about > > how they do it. I would also like to know if the WG would=20 > be interested > > in standardizing such a mechanism ? At least I think that it will be > > a useful thing !! > > > > Regards > > Mukesh > > >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 02:29:10 2004 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 CAA01129 for ; Mon, 16 Feb 2004 02:29:09 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00CE14B2@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 2:29:09 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2380732 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 02:29:03 -0500 Received: from 194.134.35.177 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 02:28:56 -0500 Received: from xtreme (unknown [81.70.87.202]) by smtp6.wanadoo.nl (Postfix) with ESMTP id BA1AA77E04 for ; Mon, 16 Feb 2004 08:28:44 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Thread-Index: AcP0WvAXH4lElLb1QP6LjcW7zbM4SAAAyQhQ Message-ID: <20040216072844.BA1AA77E04@smtp6.wanadoo.nl> Date: Mon, 16 Feb 2004 08:33:20 +0100 Reply-To: Mailing List Sender: Mailing List From: Joris Dobbelsteen Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA42ABEA0@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Mukesh, I believe such an implementation would not require an WG standard. There are numberous techniques available for creating high-availability/load-balancing clusters, both hardware and software. It is up to an implementators of an OSPF router (and other routing protocols as well) to ensure the state of the router is shared between the clusters, conforming to the standard of a single router. The use of a intra-cluster communication protocol would be useless, as different implementations use different structures and might have states defined differently. This would not allow them to share state efficiently, if at all possible. Next I believe this idea is of little use with OSPF. A much simpler and elegant solution is available: two OSPF routers. Let OSPF take care of selecting the router which is available, rather than HA/LB hardware/software. This works just as well, because OSPF is designed for this task. - Joris >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On >Behalf Of Mukesh.Gupta@NOKIA.COM >Sent: Monday, 16 February 2004 8:03 >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Highly Available OSPF Router. > >Has anyone implemented an OSPF HA where two or more OSPF >routers appear as one OSPF router to the OSPF neighbors. One >of the routers (the Master) talks to the external world (OSPF >neighbors) and the others (the Backups) keep all the dynamic >OSPF state (neighbors, database etc) in sync with the Master. >When the Master dies, one of the backup router takes over >immediately without the neighbors realizing any change in the network ? > >If anyone has implemented any such thing, I would like to hear >about how they do it. I would also like to know if the WG >would be interested in standardizing such a mechanism ? At >least I think that it will be a useful thing !! > >Regards >Mukesh > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 02:30:21 2004 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 CAA01247 for ; Mon, 16 Feb 2004 02:30:21 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00CE14AA@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 2:30:21 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2380817 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 02:30:19 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 02:30:19 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Highly Available OSPF Router. thread-index: AcP0XTxGRAmiFIEySJmkZVsp/Elj1AAAC18AAAAzTDA= Message-ID: Date: Sun, 15 Feb 2004 23:28:40 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Mukesh, This thing is not OSPF specific at all, and can be done applications. As = Dave said its pretty standard stuff done by a lot of vendors, why dont = you have a look at the link I provided? Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Mukesh.Gupta@NOKIA.COM Sent: Monday, February 16, 2004 12:56 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Highly Available OSPF Router. Thanks for the quick responses :) Ok let me take the word "standardized" back ! I meant to ask "will it be useful to write an informational document on how to do this implementation trick for OSPF" ? I am sure every implementor will have to think about the same issues like: - what are the tasks that are just performed by the Master and not by the backups. - How to synchronize the initial state between the master and=20 the member. - How to keep the state in sync. - What actions to perform at the time of the swithover (master dying and backup taking over). etc. etc. Why not write a document and make it easier for everyone ?? Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Dave Katz > Sent: Sunday, February 15, 2004 11:19 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Highly Available OSPF Router. >=20 >=20 > I suspect a number of folks are working on things like this. >=20 > However, the way you describe it says that it in fact is not=20 > subject to > standardization, since it does what it does without the neighbors > realizing (nothing outside the "black box.") Therefore it is only an > implementation trick, not something to be standardized. >=20 > --Dave >=20 > On Sunday, Feb 15, 2004, at 23:03 US/Pacific, Mukesh.Gupta@NOKIA.COM > wrote: >=20 > > Has anyone implemented an OSPF HA where two or more OSPF routers > > appear as one OSPF router to the OSPF neighbors. One of the routers > > (the Master) talks to the external world (OSPF neighbors) and the > > others (the Backups) keep all the dynamic OSPF state (neighbors, > > database etc) in sync with the Master. When the Master dies, one of > > the backup router takes over immediately without the neighbors > > realizing any change in the network ? > > > > If anyone has implemented any such thing, I would like to hear about > > how they do it. I would also like to know if the WG would=20 > be interested > > in standardizing such a mechanism ? At least I think that it will be > > a useful thing !! > > > > Regards > > Mukesh > > >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 02:35:05 2004 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 CAA02028 for ; Mon, 16 Feb 2004 02:35:04 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00CE138D@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 2:35:03 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2381005 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 02:35:02 -0500 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 02:35:02 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1G7Z0v06388 for ; Mon, 16 Feb 2004 09:35:01 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 16 Feb 2004 09:34:34 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 16 Feb 2004 01:34:33 -0600 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Highly Available OSPF Router. Thread-Index: AcP0XeKmAX8d4MDvSwWcf+KkqI5vWQAAFlZQ X-OriginalArrivalTime: 16 Feb 2004 07:34:33.0468 (UTC) FILETIME=[523373C0:01C3F45F] Message-ID: <8D260779A766FB4A9C1739A476F84FA401547267@daebe009.americas.nokia.com> Date: Mon, 16 Feb 2004 01:34:32 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Swami/Sean, Your questions about why/where do we need this.. One example would be on a multiblade system where one blade (the central processor) is running OSPF and distributing the routes to=20 all other blades (the forwarding units). The forwarding units just=20 forward the traffic using the forwarding table received from the=20 central processor. Let say this central processor has a backup ( otherwise the whole system will be down when the central processor dies). Now when the active central processor dies, the standby central processor takes over. As the standby central processor does not have any dynamic OSPF state, the adjacencies are re-formed.=20 While OSPF is converging, the forwarding blades are not able to forward the traffic. If we wanted to make the standby central processor "hot standby", we need to synchronize the OSPF state between the active and the standby so that the standby can takeover immediately without breaking the adjacencies. Does it make any sense ?? Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Ramalingam, Swaminathan (Swaminathan) > Sent: Sunday, February 15, 2004 11:24 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Highly Available OSPF Router. >=20 >=20 > Mukesh, > Do u mean multi-level hierarchy in OSPF?. Present two-level=20 > hierarchy in > OSPF is too good enough to achieve scalability in any big=20 > network. Do you > really see any necessity for this?. If so, could you explain=20 > where it can be > useful?. >=20 > Swami >=20 > >-----Original Message----- > >From: Mukesh.Gupta@NOKIA.COM [mailto:Mukesh.Gupta@NOKIA.COM] > >Sent: Monday, February 16, 2004 12:33 PM > >To: OSPF@PEACH.EASE.LSOFT.COM > >Subject: Highly Available OSPF Router. > > > > > >Has anyone implemented an OSPF HA where two or more OSPF routers > >appear as one OSPF router to the OSPF neighbors. One of the routers > >(the Master) talks to the external world (OSPF neighbors) and the > >others (the Backups) keep all the dynamic OSPF state (neighbors, > >database etc) in sync with the Master. When the Master dies, one of > >the backup router takes over immediately without the neighbors > >realizing any change in the network ? > > > >If anyone has implemented any such thing, I would like to hear about > >how they do it. I would also like to know if the WG would be=20 > interested > >in standardizing such a mechanism ? At least I think that it will be > >a useful thing !! > > > >Regards > >Mukesh > > >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 02:39:05 2004 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 CAA02670 for ; Mon, 16 Feb 2004 02:39:05 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00CE14A9@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 2:39:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2381187 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 02:39:03 -0500 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 02:39:03 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1G7d1302587 for ; Mon, 16 Feb 2004 09:39:02 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 16 Feb 2004 09:39:01 +0200 Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 15 Feb 2004 23:39:00 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Highly Available OSPF Router. Thread-Index: AcP0XTxGRAmiFIEySJmkZVsp/Elj1AAAC18AAAAzTDAAAFmtMA== X-OriginalArrivalTime: 16 Feb 2004 07:39:00.0218 (UTC) FILETIME=[F13245A0:01C3F45F] Message-ID: <8D260779A766FB4A9C1739A476F84FA401547268@daebe009.americas.nokia.com> Date: Mon, 16 Feb 2004 01:38:59 -0600 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Vishwas, I did take a look at the links that you provided. I am sorry but I couldn't figure out what specifically on those site you are=20 referring me too. Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Vishwas Manral > Sent: Sunday, February 15, 2004 11:29 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Highly Available OSPF Router. >=20 >=20 > Hi Mukesh, >=20 > This thing is not OSPF specific at all, and can be done=20 > applications. As Dave said its pretty standard stuff done by=20 > a lot of vendors, why dont you have a look at the link I provided? >=20 > Thanks, > Vishwas >=20 > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > Mukesh.Gupta@NOKIA.COM > Sent: Monday, February 16, 2004 12:56 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Highly Available OSPF Router. >=20 >=20 > Thanks for the quick responses :) >=20 > Ok let me take the word "standardized" back ! >=20 > I meant to ask "will it be useful to write an informational > document on how to do this implementation trick for OSPF" ? > I am sure every implementor will have to think about the same > issues like: >=20 > - what are the tasks that are just performed by the Master and > not by the backups. > - How to synchronize the initial state between the master and=20 > the member. > - How to keep the state in sync. > - What actions to perform at the time of the swithover (master > dying and backup taking over). > etc. etc. >=20 > Why not write a document and make it easier for everyone ?? >=20 > Regards > Mukesh >=20 > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On=20 > Behalf Of ext > > Dave Katz > > Sent: Sunday, February 15, 2004 11:19 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: Highly Available OSPF Router. > >=20 > >=20 > > I suspect a number of folks are working on things like this. > >=20 > > However, the way you describe it says that it in fact is not=20 > > subject to > > standardization, since it does what it does without the neighbors > > realizing (nothing outside the "black box.") Therefore it=20 > is only an > > implementation trick, not something to be standardized. > >=20 > > --Dave > >=20 > > On Sunday, Feb 15, 2004, at 23:03 US/Pacific, Mukesh.Gupta@NOKIA.COM > > wrote: > >=20 > > > Has anyone implemented an OSPF HA where two or more OSPF routers > > > appear as one OSPF router to the OSPF neighbors. One of=20 > the routers > > > (the Master) talks to the external world (OSPF neighbors) and the > > > others (the Backups) keep all the dynamic OSPF state (neighbors, > > > database etc) in sync with the Master. When the Master=20 > dies, one of > > > the backup router takes over immediately without the neighbors > > > realizing any change in the network ? > > > > > > If anyone has implemented any such thing, I would like to=20 > hear about > > > how they do it. I would also like to know if the WG would=20 > > be interested > > > in standardizing such a mechanism ? At least I think that=20 > it will be > > > a useful thing !! > > > > > > Regards > > > Mukesh > > > > >=20 >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 02:47:35 2004 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 CAA03018 for ; Mon, 16 Feb 2004 02:47:34 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00CE13B7@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 2:47:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2381533 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 02:47:19 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 02:47:19 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i1G7lIl19770 for ; Sun, 15 Feb 2004 23:47:18 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from juniper.net (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i1G7lDo13987 for ; Sun, 15 Feb 2004 23:47:13 -0800 (PST) (envelope-from dkatz@juniper.net) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Message-ID: <554F6F08-6054-11D8-BA5D-000A95A55D88@juniper.net> Date: Sun, 15 Feb 2004 23:47:13 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401547266@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit On Sunday, Feb 15, 2004, at 23:26 US/Pacific, Mukesh.Gupta@NOKIA.COM wrote: > > Why not write a document and make it easier for everyone ?? > Competitive advantage. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 03:34:18 2004 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 DAA05481 for ; Mon, 16 Feb 2004 03:34:18 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00CE15FE@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 3:34:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2382877 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 03:34:02 -0500 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 03:34:02 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HT600J1254PSE@mailout1.samsung.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 17:34:01 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HT600DCD54MOI@mailout1.samsung.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 17:33:59 +0900 (KST) Received: from manav ([107.108.71.121]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HT6002MB54LT2@mmp2.samsung.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 17:33:58 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <8D260779A766FB4A9C1739A476F84FA401547267@daebe009.americas.nokia.com> Message-ID: <044a01c3f467$290a8530$79476c6b@sisodomain.com> Date: Mon, 16 Feb 2004 14:00:38 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Mukesh, Here you're talking about the internals of a protocol implementation (in your specific case OSPF), that will definitely vary from vendor to vendor and from implementation to implementation. Besides, such extensions (hopefully) should not affect the implementation's/protocol's external behavior (which is what really requires specification), because if it does, it is a bug! Manav ----- Original Message ----- From: To: Sent: Monday, February 16, 2004 1:04 PM Subject: Re: Highly Available OSPF Router. Swami/Sean, Your questions about why/where do we need this.. One example would be on a multiblade system where one blade (the central processor) is running OSPF and distributing the routes to all other blades (the forwarding units). The forwarding units just forward the traffic using the forwarding table received from the central processor. Let say this central processor has a backup ( otherwise the whole system will be down when the central processor dies). Now when the active central processor dies, the standby central processor takes over. As the standby central processor does not have any dynamic OSPF state, the adjacencies are re-formed. While OSPF is converging, the forwarding blades are not able to forward the traffic. If we wanted to make the standby central processor "hot standby", we need to synchronize the OSPF state between the active and the standby so that the standby can takeover immediately without breaking the adjacencies. Does it make any sense ?? Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Ramalingam, Swaminathan (Swaminathan) > Sent: Sunday, February 15, 2004 11:24 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Highly Available OSPF Router. > > > Mukesh, > Do u mean multi-level hierarchy in OSPF?. Present two-level > hierarchy in > OSPF is too good enough to achieve scalability in any big > network. Do you > really see any necessity for this?. If so, could you explain > where it can be > useful?. > > Swami > > >-----Original Message----- > >From: Mukesh.Gupta@NOKIA.COM [mailto:Mukesh.Gupta@NOKIA.COM] > >Sent: Monday, February 16, 2004 12:33 PM > >To: OSPF@PEACH.EASE.LSOFT.COM > >Subject: Highly Available OSPF Router. > > > > > >Has anyone implemented an OSPF HA where two or more OSPF routers > >appear as one OSPF router to the OSPF neighbors. One of the routers > >(the Master) talks to the external world (OSPF neighbors) and the > >others (the Backups) keep all the dynamic OSPF state (neighbors, > >database etc) in sync with the Master. When the Master dies, one of > >the backup router takes over immediately without the neighbors > >realizing any change in the network ? > > > >If anyone has implemented any such thing, I would like to hear about > >how they do it. I would also like to know if the WG would be > interested > >in standardizing such a mechanism ? At least I think that it will be > >a useful thing !! > > > >Regards > >Mukesh > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 03:44:55 2004 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 DAA05854 for ; Mon, 16 Feb 2004 03:44:54 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00CE15AF@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 3:44:54 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2382924 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 03:44:53 -0500 Received: from 64.12.138.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 03:34:53 -0500 Received: from logs-ntc-th.proxy.aol.com (logs-ntc-th.proxy.aol.com [198.81.19.131]) by rly-ip05.mx.aol.com (v95.1) with ESMTP id RELAYIN1-24030806037f; Mon, 16 Feb 2004 03:33:36 -0500 Received: from VenkatK (ACC391D7.ipt.aol.com [172.195.145.215]) by logs-ntc-th.proxy.aol.com (8.12.10/8.12.10) with ESMTP id i1G8SRXj018099 for ; Mon, 16 Feb 2004 08:28:27 GMT 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Apparently-From: Harikrishnagp@aol.com X-AOL-IP: 198.81.19.131 Message-ID: <000101c3f466$de73abf0$d791c3ac@VenkatK> Date: Mon, 16 Feb 2004 00:28:34 -0800 Reply-To: Mailing List Sender: Mailing List From: Hari Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA401547268@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Mukesh, Though I'm not sure of the generality of the solutions I agree with Mukesh in having an "informational document for High available OSPF". It helps any one trying to build HA-OSPF to have atleast some design directions BTW I think Vishwas is referring to commercially available HA-OSPF implementations. If that is the case the following links might be useful. http://mcg.motorola.com/netplane/releases/01282002-1.htm http://www.dataconnection.com/iprouting/ospf.htm Thanks, Hari -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mukesh.Gupta@NOKIA.COM Sent: Sunday, February 15, 2004 11:39 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Highly Available OSPF Router. Vishwas, I did take a look at the links that you provided. I am sorry but I couldn't figure out what specifically on those site you are referring me too. Regards Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Vishwas Manral > Sent: Sunday, February 15, 2004 11:29 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Highly Available OSPF Router. > > > Hi Mukesh, > > This thing is not OSPF specific at all, and can be done > applications. As Dave said its pretty standard stuff done by > a lot of vendors, why dont you have a look at the link I provided? > > Thanks, > Vishwas > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > Mukesh.Gupta@NOKIA.COM > Sent: Monday, February 16, 2004 12:56 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Highly Available OSPF Router. > > > Thanks for the quick responses :) > > Ok let me take the word "standardized" back ! > > I meant to ask "will it be useful to write an informational > document on how to do this implementation trick for OSPF" ? > I am sure every implementor will have to think about the same > issues like: > > - what are the tasks that are just performed by the Master and > not by the backups. > - How to synchronize the initial state between the master and > the member. > - How to keep the state in sync. > - What actions to perform at the time of the swithover (master > dying and backup taking over). > etc. etc. > > Why not write a document and make it easier for everyone ?? > > Regards > Mukesh > > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On > Behalf Of ext > > Dave Katz > > Sent: Sunday, February 15, 2004 11:19 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: Highly Available OSPF Router. > > > > > > I suspect a number of folks are working on things like this. > > > > However, the way you describe it says that it in fact is not > > subject to > > standardization, since it does what it does without the neighbors > > realizing (nothing outside the "black box.") Therefore it > is only an > > implementation trick, not something to be standardized. > > > > --Dave > > > > On Sunday, Feb 15, 2004, at 23:03 US/Pacific, Mukesh.Gupta@NOKIA.COM > > wrote: > > > > > Has anyone implemented an OSPF HA where two or more OSPF routers > > > appear as one OSPF router to the OSPF neighbors. One of > the routers > > > (the Master) talks to the external world (OSPF neighbors) and the > > > others (the Backups) keep all the dynamic OSPF state (neighbors, > > > database etc) in sync with the Master. When the Master > dies, one of > > > the backup router takes over immediately without the neighbors > > > realizing any change in the network ? > > > > > > If anyone has implemented any such thing, I would like to > hear about > > > how they do it. I would also like to know if the WG would > > be interested > > > in standardizing such a mechanism ? At least I think that > it will be > > > a useful thing !! > > > > > > Regards > > > Mukesh > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 03:49:24 2004 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 DAA05970 for ; Mon, 16 Feb 2004 03:49:24 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00CE15B5@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 3:49:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2383313 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 03:49:23 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 03:49:22 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: Highly Available OSPF Router. thread-index: AcP0XTxGRAmiFIEySJmkZVsp/Elj1AAAC18AAAAzTDAAAJhb0AACOV8A Message-ID: Date: Mon, 16 Feb 2004 00:47:42 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: FW: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Just to clear the confusion !! -----Original Message----- From: Mukesh.Gupta@nokia.com [mailto:Mukesh.Gupta@nokia.com] Sent: Monday, February 16, 2004 1:15 PM To: Vishwas Manral Subject: RE: Highly Available OSPF Router. Vishwas, I found the specifications on the saforum. I will go through them. Thanks a lot !! - Mukesh > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > Vishwas Manral > Sent: Sunday, February 15, 2004 11:29 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Highly Available OSPF Router. >=20 >=20 > Hi Mukesh, >=20 > This thing is not OSPF specific at all, and can be done=20 > applications. As Dave said its pretty standard stuff done by=20 > a lot of vendors, why dont you have a look at the link I provided? >=20 > Thanks, > Vishwas >=20 > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > Mukesh.Gupta@NOKIA.COM > Sent: Monday, February 16, 2004 12:56 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Highly Available OSPF Router. >=20 >=20 > Thanks for the quick responses :) >=20 > Ok let me take the word "standardized" back ! >=20 > I meant to ask "will it be useful to write an informational > document on how to do this implementation trick for OSPF" ? > I am sure every implementor will have to think about the same > issues like: >=20 > - what are the tasks that are just performed by the Master and > not by the backups. > - How to synchronize the initial state between the master and=20 > the member. > - How to keep the state in sync. > - What actions to perform at the time of the swithover (master > dying and backup taking over). > etc. etc. >=20 > Why not write a document and make it easier for everyone ?? >=20 > Regards > Mukesh >=20 > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On=20 > Behalf Of ext > > Dave Katz > > Sent: Sunday, February 15, 2004 11:19 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: Highly Available OSPF Router. > >=20 > >=20 > > I suspect a number of folks are working on things like this. > >=20 > > However, the way you describe it says that it in fact is not=20 > > subject to > > standardization, since it does what it does without the neighbors > > realizing (nothing outside the "black box.") Therefore it=20 > is only an > > implementation trick, not something to be standardized. > >=20 > > --Dave > >=20 > > On Sunday, Feb 15, 2004, at 23:03 US/Pacific, Mukesh.Gupta@NOKIA.COM > > wrote: > >=20 > > > Has anyone implemented an OSPF HA where two or more OSPF routers > > > appear as one OSPF router to the OSPF neighbors. One of=20 > the routers > > > (the Master) talks to the external world (OSPF neighbors) and the > > > others (the Backups) keep all the dynamic OSPF state (neighbors, > > > database etc) in sync with the Master. When the Master=20 > dies, one of > > > the backup router takes over immediately without the neighbors > > > realizing any change in the network ? > > > > > > If anyone has implemented any such thing, I would like to=20 > hear about > > > how they do it. I would also like to know if the WG would=20 > > be interested > > > in standardizing such a mechanism ? At least I think that=20 > it will be > > > a useful thing !! > > > > > > Regards > > > Mukesh > > > > >=20 >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 04:15:24 2004 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 EAA07340 for ; Mon, 16 Feb 2004 04:15:23 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00CE146F@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 4:15:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2384290 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 04:15:22 -0500 Received: from 202.43.216.213 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 04:15:21 -0500 Received: from [202.96.96.35] by web15410.mail.cnb.yahoo.com via HTTP; Mon, 16 Feb 2004 17:15:17 CST MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Message-ID: <20040216091517.20749.qmail@web15410.mail.cnb.yahoo.com> Date: Mon, 16 Feb 2004 17:15:17 +0800 Reply-To: Mailing List Sender: Mailing List From: =?gb2312?q?Jing=20Shen?= Subject: Re: FW: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 8bit Could this be achived by VRRP at edge routers? or with backbone let ospf select active link automatically ? To the situation of hot-standby CPU, could that be considered as 'hitless restart' internally? Jing --- Vishwas Manral µÄÕýÎÄ£º> Just to clear the confusion !! > > -----Original Message----- > From: Mukesh.Gupta@nokia.com > [mailto:Mukesh.Gupta@nokia.com] > Sent: Monday, February 16, 2004 1:15 PM > To: Vishwas Manral > Subject: RE: Highly Available OSPF Router. > > > Vishwas, > > I found the specifications on the saforum. I will go > through them. > > Thanks a lot !! > > - Mukesh > > > -----Original Message----- > > From: Mailing List > [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of ext > > Vishwas Manral > > Sent: Sunday, February 15, 2004 11:29 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: Highly Available OSPF Router. > > > > > > Hi Mukesh, > > > > This thing is not OSPF specific at all, and can be > done > > applications. As Dave said its pretty standard > stuff done by > > a lot of vendors, why dont you have a look at the > link I provided? > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Mailing List > [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > > Mukesh.Gupta@NOKIA.COM > > Sent: Monday, February 16, 2004 12:56 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: Highly Available OSPF Router. > > > > > > Thanks for the quick responses :) > > > > Ok let me take the word "standardized" back ! > > > > I meant to ask "will it be useful to write an > informational > > document on how to do this implementation trick > for OSPF" ? > > I am sure every implementor will have to think > about the same > > issues like: > > > > - what are the tasks that are just performed by > the Master and > > not by the backups. > > - How to synchronize the initial state between the > master and > > the member. > > - How to keep the state in sync. > > - What actions to perform at the time of the > swithover (master > > dying and backup taking over). > > etc. etc. > > > > Why not write a document and make it easier for > everyone ?? > > > > Regards > > Mukesh > > > > > -----Original Message----- > > > From: Mailing List > [mailto:OSPF@PEACH.EASE.LSOFT.COM]On > > Behalf Of ext > > > Dave Katz > > > Sent: Sunday, February 15, 2004 11:19 PM > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > Subject: Re: Highly Available OSPF Router. > > > > > > > > > I suspect a number of folks are working on > things like this. > > > > > > However, the way you describe it says that it in > fact is not > > > subject to > > > standardization, since it does what it does > without the neighbors > > > realizing (nothing outside the "black box.") > Therefore it > > is only an > > > implementation trick, not something to be > standardized. > > > > > > --Dave > > > > > > On Sunday, Feb 15, 2004, at 23:03 US/Pacific, > Mukesh.Gupta@NOKIA.COM > > > wrote: > > > > > > > Has anyone implemented an OSPF HA where two or > more OSPF routers > > > > appear as one OSPF router to the OSPF > neighbors. One of > > the routers > > > > (the Master) talks to the external world (OSPF > neighbors) and the > > > > others (the Backups) keep all the dynamic OSPF > state (neighbors, > > > > database etc) in sync with the Master. When > the Master > > dies, one of > > > > the backup router takes over immediately > without the neighbors > > > > realizing any change in the network ? > > > > > > > > If anyone has implemented any such thing, I > would like to > > hear about > > > > how they do it. I would also like to know if > the WG would > > > be interested > > > > in standardizing such a mechanism ? At least I > think that > > it will be > > > > a useful thing !! > > > > > > > > Regards > > > > Mukesh > > > > > > > > > > Regards > > > > Mukesh > > > > > > > > > _________________________________________________________ Do You Yahoo!? ÍêÈ«Ãâ·ÑµÄÑÅ»¢µçÓÊ£¬ÂíÉÏ×¢²á»ñÔù¶îÍâ60Õ×ÍøÂç´æ´¢¿Õ¼ä http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.mail.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 10:42:36 2004 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 KAA26197 for ; Mon, 16 Feb 2004 10:42:35 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00CE1AED@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 10:42:31 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2431009 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 10:42:30 -0500 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 10:42:29 -0500 Received: (qmail 8486 invoked by uid 404); 16 Feb 2004 15:42:29 -0000 Received: from prz@xebeo.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.067245 secs); 16 Feb 2004 15:42:29 -0000 Received: from unknown (HELO xebeo.com) (172.16.1.108) by lxmail.nj.us.utstar.com with SMTP; 16 Feb 2004 15:42:29 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000101c3f466$de73abf0$d791c3ac@VenkatK> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4030E4E5.3030000@xebeo.com> Date: Mon, 16 Feb 2004 16:42:29 +0100 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hari wrote: >Hi Mukesh, > Though I'm not sure of the generality of the solutions I agree with >Mukesh in having an "informational document for High available OSPF". > It helps any one trying to build HA-OSPF to have atleast some design >directions > > i) IETF is not the forum for such a document really. It governs 'behavior between boxes'. That's for a good reason. ii) Implementation details change from architecture to architecture drastically and your document, even best written and well-ment, has a very high chance to cause more confusion than help, since the interpretation of what you wrote may cause implentors to take completely wrong decisions for their architecture. E.g., if a box has extremely slow between blades-communication, your document may cause complete havoc to a system. Another example, if a box distributes hello state machines on different blades than topology maintainance, your document is hard to interpret. That assuming you write 'put OSPF on two different blades and sync them up using some kind of internal protocol'. iii) Nobody can prevent you from publishing an informational and way worse things made it into an 'informational' ;-)) -- tony > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 12:04:37 2004 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 MAA05606 for ; Mon, 16 Feb 2004 12:04:36 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00CE1E31@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 12:04:36 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2437719 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 12:04:34 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 12:04:33 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01L6NX2M0H948X5AXF@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 09:04:29 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: pmurphy MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01L6NX2M0I6Y8X5AXF@omega7.wr.usgs.gov> Date: Mon, 16 Feb 2004 09:04:29 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: Multi-address and Tunnel Adjacency To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Acee, Both tools partially meet a requirement that I have long hoped for. If I have to choose I prefer the multi-area adjacency draft. Corporate OSPF topologies are built one link at a time to meet specific performance criteria for carrying the expected load of specific networks. Redundant links are also planned with that in mind. Indeed sometimes under dire conditions it is better to just let an area partition; as the shifting of load could cause even more damage. In addition the multi-area adjacency draft can support multiple non-backbone areas down the same non-backbone link, while the TAs of the current draft can only be built over area 0 (a minor point). The simplicity and added feature of TAs is appealing, but I would not want to give up controlling the quality of redundant and preferred paths one link at a time. Note given the increasing size of router memory that can support substantially larger routing tables, the requirement to avoid the adverse impact of area/range summarization during area partitioning is not the requirement it once was. We use to worry about such things. Now we simply drop the summarization. There are a number of reasons I have never found virtual links a useful tool that also apply to TAs. E.g. transit paths through OSPF areas are commonly a mixed bag of high-performance paths versus lower performing paths. The lack of path control requires a careful study of possible remote outcomes before the tool is deployed. Links with line speeds greater that 100Mbps are quite common these days even in corporate networks. This complicates the OSPF costing of links. VLs and TAs work best in an OSPF domain with a consistent costing algorithm between areas. The usefulness of VLs and TAs might benefit from the addition of VL and TA parameters like max-path-cost or max-path-TTL that would control if and when adjacencies should form. However speed and hop count alone do not determine path preference. Two single hop paths of the same speed can have decidedly different performance parameters. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 16 16:08:43 2004 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 QAA24582 for ; Mon, 16 Feb 2004 16:08:41 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00CE22EE@cherry.ease.lsoft.com>; Mon, 16 Feb 2004 16:08:40 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2465663 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 16 Feb 2004 16:08:39 -0500 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 16 Feb 2004 16:08:38 -0500 Received: from smirtoraw2k03 (sjc-vpn4-665.cisco.com [10.21.82.153]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i1GL8bi23239 for ; Mon, 16 Feb 2004 13:08:37 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Message-ID: <015101c3f4d1$0bb5ec80$f2ce7243@amer.cisco.com> Date: Mon, 16 Feb 2004 13:08:37 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Multi-address and Tunnel Adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <01L6NX2M0I6Y8X5AXF@omega7.wr.usgs.gov> Precedence: list Content-Transfer-Encoding: 7bit Pat, -> ->Acee, -> ->Both tools partially meet a requirement that I have long ->hoped for. If I have to choose I prefer the multi-area ->adjacency draft. Corporate OSPF topologies are built one link ->at a time to meet specific performance criteria for carrying ->the expected load of specific networks. Redundant links are ->also planned with that in mind. Your argument for load does not stand, the whole idea of using TA (or multi-area adj) is to use the high speed backbone path (link) and avoid going through a suboptimal path through non-backbone area ->Indeed sometimes under dire ->conditions it is better to just let an area partition; as the ->shifting of load could cause even more damage. I remind you that configuring partition avoidance is optional, if one does not need (there is no summarization) or has a eventual load problem you will not configure the partition repair. Note that in absence of summarization, your area will be automatically repaired through the backbone and you still have the load problem you describe if it really exist. ->Note given the increasing size of router memory that can ->support substantially larger routing tables, the requirement ->to avoid the adverse impact of area/range summarization ->during area partitioning is not the requirement it once was. The memory is irrelevant here. If you are summarizing it is because you want to minimize the flooding of thousands of LSAs and not really because you are concerned for holding the advertised prefix in your RIB. ->We use to worry about such things. Now we simply drop the ->summarization. It depends who is "we". Dropping packet cannot be acceptable for some customers. Imagine a common hub and spoke topology where you are summarizing at ABRs. If the intra-area link between the ABR goes down then you are either dropping the packet or doing suboptimal routing as described in application section of TA. If you drop packet at ABR then your remote are isolated... -> ->There are a number of reasons I have never found virtual ->links a useful tool that also apply to TAs. E.g. transit ->paths through OSPF areas are commonly a mixed bag of ->high-performance paths versus lower performing paths. TA transit area can only be backbone therefore what you state above although may apply to VL, does NOT apply to TA. Sina From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 17 08:56:50 2004 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 IAA28272 for ; Tue, 17 Feb 2004 08:56:49 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00CE35FC@cherry.ease.lsoft.com>; Tue, 17 Feb 2004 8:56:39 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2571568 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 Feb 2004 08:56:37 -0500 Received: from 203.199.83.147 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 17 Feb 2004 08:56:37 -0500 Received: (qmail 27201 invoked by uid 510); 17 Feb 2004 13:56:32 -0000 Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 17 feb 2004 13:56:32 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1077026192---0-203.199.83.147-22118" Message-ID: <20040217135632.27200.qmail@webmail25.rediffmail.com> Date: Tue, 17 Feb 2004 13:56:32 -0000 Reply-To: Mailing List Sender: Mailing List From: query OSPF Subject: Question: NU-bit To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1077026192---0-203.199.83.147-22118 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi,
=0A
=0AI have a question:
=0ANU-bit: This bit a capabili= ty bit of the IPv6 address prefix.
=0AWhenever a router will generate a= address prefix, how does it set the NU-bit? Or user has to configure the N= U-bit for the address prefix?
=0A
=0AIs there any further intention f= or the bit?
=0A
=0AThanks in advance.
=0A
=0A=0A

=0A

= =0A=0A --Next_1077026192---0-203.199.83.147-22118 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=0A=0AI have a question:=0ANU-bit: This bit a capability bit of the IPv6= address prefix. =0AWhenever a router will generate a address prefix, how d= oes it set the NU-bit? Or user has to configure the NU-bit for the address = prefix?=0A=0AIs there any further intention for the bit?=0A=0AThanks in adv= ance.=0A=0A --Next_1077026192---0-203.199.83.147-22118-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 17 14:52:03 2004 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 OAA29833 for ; Tue, 17 Feb 2004 14:52:02 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00CE3E0D@cherry.ease.lsoft.com>; Tue, 17 Feb 2004 14:52:01 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2635909 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 Feb 2004 14:51:59 -0500 Received: from 207.17.136.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 17 Feb 2004 14:51:59 -0500 Received: from fuinar.juniper.net (localhost [127.0.0.1]) by fuinar.juniper.net (8.12.8p1/8.12.3) with ESMTP id i1HJpw7s019871 for ; Tue, 17 Feb 2004 11:51:58 -0800 (PST) (envelope-from qv@fuinar.juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.12.8p1/8.12.3/Submit) id i1HJpwqt019868; Tue, 17 Feb 2004 11:51:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200402132316.i1DNG1sU007862@fuinar.juniper.net> <019d01c3f29d$0cc6ac80$f86445ab@amer.cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200402171951.i1HJpwqt019868@fuinar.juniper.net> Date: Tue, 17 Feb 2004 11:51:58 -0800 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: Multi-address and Tunnel Adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <019d01c3f29d$0cc6ac80$f86445ab@amer.cisco.com> Precedence: list Content-Transfer-Encoding: 7bit > Quaizar, Rahul > > Although there is a small overlap for a single hop case I do not think > that the two drafts really compete as they solve different problems. > > Tunnel adjacency solve the case where ABR are multi-hops and further > provide an automatic partition repair for the non-backbone areas. If you > refer to GRE tunnel as an alternative solution, there are draw backs in > it such as extra configuration overhead, extra IP address for tunnel, > relying on IP reachbility versus SPF reachability and besides the manual > tunnel does not provide automatic partition repair. The extra config for TA is comparable to GRE. GRE tunnels could be run unnumberred. Could you please explain (no sarcasm intended, just admitting ignorance) why SPF reachability is considered superior to IP reachability. A GRE tunnel could be tied to route reachability of the tunnel end-point if one wanted it so (which would cover SPF-reachability). One could easily simulate an automatic partition repair using GRE tunnel by giving it a cost which would be higher than the intra-area cost of the remote end. My main point being virtual-links add very significantly to the implementation complexity. TAs would just add to that. While I find that multi-adjacency draft simpler and elegant wrt implementation and fullfils a requirement which clearly falls under the perview of an IGP. Optimal routing is clearly under the scope of an IGP while reachabiliity is clearly not. Quaizar > > I believe an implementation can decide to implement either, both or none > of the solutions however customers needs different solutions and I know > customers who are interested in automatic partition repair solution of > TA. > > Thanks > Sina > > > > ->-----Original Message----- > ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > ->Behalf Of Quaizar Vohra > ->Sent: Friday, February 13, 2004 3:16 PM > ->To: OSPF@PEACH.EASE.LSOFT.COM > ->Subject: Multi-address and Tunnel Adjacency > -> > -> > ->I prefer the multi-area adjacency draft as it is simpler and > ->cleaner in design. The other draft proposes something which > ->is easier implemented using mechansims outside ospf. > -> > ->Quaizar > -> > -> > Speaking as a WG member, I think we should accept > -> > one of these drafts as a working group document since the > -> > requirement to share an OSPFv2 link over multiple areas > -> > without additional encapsulation has existed for some > -> > time. > -> > > -> > > ->http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-tunne > l-adjacency-01.txt > > > > > http://www.ietf.org/internet-drafts/draft-mirtorabi-ospf-multi-area-adj- > 00.txt > > > > The multi-area adjacency draft provides the minimum functionality to > > use a link in multiple areas (without additional addressing or > encapsulation). > The TA draft solves this problem along with providing > a mechanism to > dynamically bring up tunnels through a transit area > (the tunnel will be > used for both data and the adjacency). > > > Comments? > ------ > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 17 16:35:40 2004 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 QAA07304 for ; Tue, 17 Feb 2004 16:35:39 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00CE3FE3@cherry.ease.lsoft.com>; Tue, 17 Feb 2004 16:28:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2644785 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 Feb 2004 16:28:31 -0500 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 17 Feb 2004 16:27:45 -0500 Received: from smirtoraw2k03 (dhcp-171-69-100-250.cisco.com [171.69.100.250]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i1HLRii21165 for ; Tue, 17 Feb 2004 13:27:44 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Message-ID: <01bc01c3f59c$e1b78570$fa6445ab@amer.cisco.com> Date: Tue, 17 Feb 2004 13:27:44 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Multi-address and Tunnel Adjacency To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200402171951.i1HJpwqt019868@fuinar.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Quaizar, ->The extra config for TA is comparable to GRE. GRE tunnels ->could be run unnumberred. Well the TA config should be one line of the config ( similar to VL ), for GRE you have to create tunnel, assign tunnel end point reachability address, advertise them in OSPF and configure OSPF over the tunnel so it should not be that comparable As the number of tunnels increase ( H&S topology with different non-backbone area ) the above could be significant... -> ->Could you please explain (no sarcasm intended, just admitting ->ignorance) why SPF reachability is considered superior to IP ->reachability. A GRE tunnel could be tied to route ->reachability of the tunnel end-point if one wanted it so ->(which would cover SPF-reachability). In general IP reachability can take any path while SPF reachability is through an intended transit area. If your area is partitioned your tunnel end point reachablity may switch from intra-area route into Inter-area route which could lead to learning the tunnel endpoint through the tunnel itself and failing the tunnel. ( although you could prevent that by assigning a high cost to the GRE tunnel) -> ->One could easily simulate an automatic partition repair using ->GRE tunnel by giving it a cost which would be higher than the ->intra-area cost of the remote end. -> ->My main point being virtual-links add very significantly to ->the implementation complexity. TAs would just add to that. Any change to OSPF, could be perceived as an implementation complexity. It is natural for a protocol to be extended if there are requirements and customer demand behind it. Also one of the complexity of the VL may be related to TransitCapability and nexthop calculation which does not exit in TA. Probably the categories of the draft should be aimed to be Informational so that it does not force an implementation to implement it. -> ->While I find that multi-adjacency draft simpler and elegant ->wrt implementation and fullfils a requirement which clearly ->falls under the perview of an IGP. Optimal routing is clearly ->under the scope of an IGP while reachabiliity is clearly not. Considering others comments, looks like there is an agreement to move forward the multi-adj draft Sina From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 17 17:05:38 2004 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 RAA10882 for ; Tue, 17 Feb 2004 17:05:37 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00CE41D2@cherry.ease.lsoft.com>; Tue, 17 Feb 2004 17:05:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2647631 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 Feb 2004 17:05:33 -0500 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 17 Feb 2004 17:03:52 -0500 Received: (qmail 11323 invoked by uid 404); 17 Feb 2004 22:03:52 -0000 Received: from rohit@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.750965 secs); 17 Feb 2004 22:03:52 -0000 Received: from web.xebeo.com (HELO web.nj.us.utstar.com) (192.168.0.3) by lxmail.xebeo.com with SMTP; 17 Feb 2004 22:03:51 -0000 Received: from utstar.com (IDENT:rohit@localhost.localdomain [127.0.0.1]) by web.nj.us.utstar.com (8.9.3/8.9.3) with ESMTP id RAA29154 for ; Tue, 17 Feb 2004 17:03:50 -0500 Message-ID: <200402172203.RAA29154@web.nj.us.utstar.com> Date: Tue, 17 Feb 2004 17:03:50 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: no ospf wg meeting in seoul To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list FYI - we will not have an OSPF WG meeting in Seoul. --rohit. (and Acee). From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 17 21:13:31 2004 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 VAA23364 for ; Tue, 17 Feb 2004 21:13:31 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00CE4763@cherry.ease.lsoft.com>; Tue, 17 Feb 2004 21:13:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2675526 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 Feb 2004 21:13:29 -0500 Received: from 130.76.96.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 17 Feb 2004 21:13:29 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id UAA03168 for ; Tue, 17 Feb 2004 20:13:28 -0600 (CST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id UAA22723 for ; Tue, 17 Feb 2004 20:13:27 -0600 (CST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i1I2BWb14167 for ; Tue, 17 Feb 2004 18:11:32 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Tue, 17 Feb 2004 18:11:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Extensions to OSPF to Support Mobile Ad Hoc Networking Thread-Index: AcPwrtjwVlnX7ynnRMW9dahPogIXWwFEicxw X-OriginalArrivalTime: 18 Feb 2004 02:11:57.0312 (UTC) FILETIME=[95DBF000:01C3F5C4] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC2DE@xch-nw-27.nw.nos.boeing.com> Date: Tue, 17 Feb 2004 18:11:57 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: Extensions to OSPF to Support Mobile Ad Hoc Networking To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable I have some questions and comments on this document. - it is unclear whether this is intended for v2. At the start of section 2, it seems to be intended for both v2 and v3, but the discussion is very v3 specific. - at the end of page 4, there was discussion about the fact that too many neighbors will cause scalability problems. This was also discussed in Fred Baker's MANET draft from 2002. =20 Do you intend to introduce mechanisms for minimizing the=20 number of neighbors that a router tries to become adjacent with, or is that outside the scope of this proposal? - could you please explain why LLS extensions are preferable to defining a new packet type (such as Incremental Hello)? If there is no advantage, LLS seems a more roundabout way to do it. - in section 2.3.4.1, last bullet, what do you mean by neighbors possibly being DR or BDR? =20 - do you foresee additional significant extensions beyond use of MPRs/ack strategy for flooding and use of incremental Hellos? Tom > -----Original Message----- > From: Russ White [mailto:ruwhite@CISCO.COM]=20 > Sent: Wednesday, February 11, 2004 6:53 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Extensions to OSPF to Support Mobile Ad Hoc Networking >=20 >=20 > Y'all: >=20 > We are past the new work cutoff, so I'm posting this directly=20 > here, rather > than waiting 'til after IETF to do so. I'll post it in the=20 > normal way after > IETF is over. >=20 http://www.riw.us/temp/draft-chandra-ospf-manet-00.txt Abstract: This document describes extensions to OSPF to support mobile ad hoc networking. Specifically, the document specifies a mechanism for link-local signaling, a OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 18 00:40:10 2004 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 AAA29947 for ; Wed, 18 Feb 2004 00:40:09 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00CE4BEC@cherry.ease.lsoft.com>; Wed, 18 Feb 2004 0:40:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2697978 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 18 Feb 2004 00:40:08 -0500 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 18 Feb 2004 00:40:08 -0500 Received: from user-2ivfmrc.dialup.mindspring.com ([165.247.219.108] helo=erg.sri.com) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AtKRK-0003RG-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 17 Feb 2004 21:40:07 -0800 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4032FAAD.8060907@erg.sri.com> Date: Tue, 17 Feb 2004 21:39:57 -0800 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: Extensions to OSPF to Support Mobile Ad Hoc Networking To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Russ and all, I have some comments on the document draft-chandra-ospf-manet-ext-00.txt I like the use of incremental (or differential) Hellos. TBRPF also uses differential Hellos to reduce overhead, and avoids having to report all neighbors periodically in Hellos. (As far as I know TBRPF is the first MANET protocol that has Hellos with this property.) I also like your use of the sequence number (SCS) that is incremented only when the neighbor set changes. This is probably an improvement over the Hello sequence number of TBRPF, which is incremented with each Hello. However, one advantage of TBRPF Hellos is that a 1-way neighbor is not included indefinitely in Hellos. (A MANET node can have a large number of 1-way neighbors that never become 2-way.) However, it should be easy to modify your protocol so that 1-way neighbors are included in Hellos for only a short time. I also like the fact that 2-hop neighbor information is learned via LSAs and not Hellos. This has been a point of argument between TBRPF and OLSR for years. (In OLSR, nodes learn 2-hop neighbor information via Hellos, and in TBRPF this is learned via topology updates.) I like the technique in which each node only needs to ACK each LSA instance once (even if it is received from multiple neighbors). However, this can still result in a lot of overhead when topology changes are frequent. In draft-ogier-manet-ospf-extension-00.txt, I discuss two promising alternatives to ACKs, which I summarize below. The first idea is to identify LSAs that change frequently, by maintaining an exponential moving average of the time between successive updates of each LSA. The originator can identify (via an option bit) such frequently changing LSAs as "non-ackable". (This is slightly different from my draft.) Non-ackable LSAs are retransmitted periodically (e.g., every 5 seconds) and thus need not be ACKed, thereby reducing overhead significantly. The second idea in my draft is inspired by the Complete Sequence Numbers messages of IS-IS. Each node (or as proposed in my draft, each CDS node) periodically broadcasts to all neighbors a complete set of Database Description packets. If a node receives such a DD packet from a neighbor that indicates the neighbor has a more recent instance of some LSAs, the node unicasts a LS Request packet to the neighbor, to request the newer information. INRIA has put out a new draft (draft-clausen-manet-ospf-dbx-00.txt) which presents a variation of this idea that uses a more compact representation for the Database Description messages. My objective was to use the OSPF DD and LS Request packets with little or no modification, but it will be interesting to see if the more compact representation of INRIA reduces overhead sufficiently to justify the new message types. Finally, it appears that you require the formation of full adjacencies between all pairs of neighbors, which I think is very inefficient. That's like requiring that adjacencies be formed between all pairs of nodes in an OSPF broadcast network (instead of just between the DR and Backup DR and their neighbors). As discussed in my draft, adjacencies only need to be formed between CDS nodes and their neighbors. (A CDS node is a natural generalization of a DR.) My draft also discusses ways to reduce overhead with MPRs, e.g., by having each MPR report only a subset of the LSAs in its database. (It may also be possible to apply this latter idea to reduce the overhead of the method described in INRIA's new draft.) Richard From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 18 09:01:00 2004 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 JAA11322 for ; Wed, 18 Feb 2004 09:01:00 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00CE5590@cherry.ease.lsoft.com>; Wed, 18 Feb 2004 9:00:53 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 2756296 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 18 Feb 2004 08:59:44 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 18 Feb 2004 08:59:44 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 08266885076 for ; Wed, 18 Feb 2004 05:59:42 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28412-06 for ; Wed, 18 Feb 2004 05:59:41 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.163]) by prattle.redback.com (Postfix) with SMTP id 34653885073 for ; Wed, 18 Feb 2004 05:59:41 -0800 (PST) References: <20040217135632.27200.qmail@webmail25.rediffmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_028B_01C3F5FD.859373B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <028e01c3f627$6ef7b1f0$0302a8c0@aceeinspiron> Date: Wed, 18 Feb 2004 08:59:31 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question: NU-bit To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_028B_01C3F5FD.859373B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe the NU bit was originally specified for use with =20 MOSPF [RFC 1584]. Currently, there is no standardized use for the bit (other than advertised prefixes with the NU bit set are excluded for the unicast routing calculation).=20 ----- Original Message -----=20 From: query OSPF=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Tuesday, February 17, 2004 8:56 AM Subject: Question: NU-bit Hi, I have a question: NU-bit: This bit a capability bit of the IPv6 address prefix.=20 Whenever a router will generate a address prefix, how does it set the = NU-bit? Or user has to configure the NU-bit for the address prefix? Is there any further intention for the bit? Thanks in advance. ------=_NextPart_000_028B_01C3F5FD.859373B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I believe the NU bit was originally = specified for=20 use with 
MOSPF [RFC 1584]. Currently, there = is=20 no standardized
use for the bit (other = than advertised=20 prefixes with the NU
bit set are excluded for the unicast = routing=20 calculation).
 
----- Original Message -----
From:=20 query=20 OSPF
Sent: Tuesday, February 17, = 2004 8:56=20 AM
Subject: Question: NU-bit

Hi,

I have a question:
NU-bit: This bit a capability bit = of the=20 IPv6 address prefix.
Whenever a router will generate a address = prefix, how=20 does it set the NU-bit? Or user has to configure the NU-bit for the = address=20 prefix?

Is there any further intention for the = bit?

Thanks in=20 advance.



------=_NextPart_000_028B_01C3F5FD.859373B0-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 20 04:56:13 2004 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 EAA12805 for ; Fri, 20 Feb 2004 04:56:13 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00CF81D4@cherry.ease.lsoft.com>; Fri, 20 Feb 2004 4:56:10 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3052221 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 19 Feb 2004 23:48:20 -0500 Received: from 64.4.35.226 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 19 Feb 2004 23:48:20 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 19 Feb 2004 20:48:19 -0800 Received: from 63.126.135.11 by bay12-dav52.bay12.hotmail.com with DAV; Fri, 20 Feb 2004 04:48:18 +0000 X-Originating-IP: [63.126.135.11] X-Originating-Email: [desai_purvi@hotmail.com] X-Sender: desai_purvi@hotmail.com References: <8D260779A766FB4A9C1739A476F84FA42ABEA0@daebe009.americas.nokia.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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 20 Feb 2004 04:48:19.0298 (UTC) FILETIME=[C2C8E420:01C3F76C] Message-ID: Date: Thu, 19 Feb 2004 20:48:18 -0800 Reply-To: Mailing List Sender: Mailing List From: Purvi Subject: Re: Highly Available OSPF Router. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mukesh, I had implemented similar OSPF failover mechanism some years back. If you have any specific question, let me know. IMHO, even though this task is not that complex, solution of this nature is not efficient & not needed in most scenarios. OSPF protocol in network design itself could be used in creative ways to provide redundancy... and more.. In my view, standardization or informational rfc for the requirements as specified in the email are not desirable. Its one of the solution, design and implementation issues, specific to the vendor, which eventually differentiates one vendor from another. Regards, -Purvi ----- Original Message ----- From: To: Sent: Sunday, February 15, 2004 11:03 PM Subject: Highly Available OSPF Router. Has anyone implemented an OSPF HA where two or more OSPF routers appear as one OSPF router to the OSPF neighbors. One of the routers (the Master) talks to the external world (OSPF neighbors) and the others (the Backups) keep all the dynamic OSPF state (neighbors, database etc) in sync with the Master. When the Master dies, one of the backup router takes over immediately without the neighbors realizing any change in the network ? If anyone has implemented any such thing, I would like to hear about how they do it. I would also like to know if the WG would be interested in standardizing such a mechanism ? At least I think that it will be a useful thing !! Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 20 13:41:19 2004 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 NAA06025 for ; Fri, 20 Feb 2004 13:41:18 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00CF904F@cherry.ease.lsoft.com>; Fri, 20 Feb 2004 13:41:17 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3185801 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 20 Feb 2004 13:41:16 -0500 Received: from 130.76.32.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 20 Feb 2004 13:31:16 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA17775 for ; Fri, 20 Feb 2004 10:31:15 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id KAA21654 for ; Fri, 20 Feb 2004 10:31:14 -0800 (PST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i1KITT610449 for ; Fri, 20 Feb 2004 10:29:29 -0800 (PST) Received: from xch-nw-26.nw.nos.boeing.com ([192.48.4.100]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Fri, 20 Feb 2004 10:28:04 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Extensions to OSPF to Support Mobile Ad Hoc Networking Thread-Index: AcPwrti/qWH/iRs3S66zz2HjgPYRXAHKhZzw X-OriginalArrivalTime: 20 Feb 2004 18:28:04.0655 (UTC) FILETIME=[478AC3F0:01C3F7DF] Message-ID: <2AFCB5FA378DEE4CA704B9AD7764637901866BC2@xch-nw-26.nw.nos.boeing.com> Date: Fri, 20 Feb 2004 10:27:46 -0800 Reply-To: Mailing List Sender: Mailing List From: "Spagnolo, Phillip A" Subject: Re: Extensions to OSPF to Support Mobile Ad Hoc Networking To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Madhavi, Below are a few questions about your optimizations for Link State Acknowledgements. =20 section 2.4.7 states=20 Note that a node can determine whether its further flooding a LSA will only result in a redundant transmission by already having heard link state acknowledgements (ACKs) or floods for the LSA from all of its peers. section 2.4.8 states 2. Typically, LSAs are acknowledged by all of the adjacent speak- ers. In the case of relayed information, the relay MUST only expect either explicit or implicit acknowledgements from peers that have not previously acknowledged this LSA. The retransmis- sion procedures, if any exist, for the underlying protocol MUST be followed. 3. Because routing updates are sent via multicast, the set of over- lapping speakers will usually receive the same update more than once. A speaker SHOULD only acknowledge the first update received on the link. The draft does not specify how the following mechanisms are to be implemented. However, the statements seem to imply memory of each ACK that has been received. Does this mean you keep a new database of ACKs received for a particular LSA from a particular router? Do you only keep track of ACKs for LSAs in your link state database, or do you record ACKs for LSAs not yet received? To determine if you should further flood an LSA (sec 2.4.7), it seems that the later will be needed. Also, in sec 2.4.8 a router needs past ACK information, so the speaker only has to acknowledge the first LSA, and the LSA source does not expect an ACK. =20 My desire is to understand the complexity of keeping ACK information. Thanks for your response, Phil > -----Original Message----- > From: Russ White [mailto:ruwhite@CISCO.COM]=20 > Sent: Wednesday, February 11, 2004 6:53 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Extensions to OSPF to Support Mobile Ad Hoc Networking >=20 >=20 > Y'all: >=20 > We are past the new work cutoff, so I'm posting this directly=20 > here, rather than waiting 'til after IETF to do so. I'll post=20 > it in the normal way after IETF is over. >=20 http://www.riw.us/temp/draft-chandra-ospf-manet-00.txt Abstract: This document describes extensions to OSPF to support mobile ad hoc networking. Specifically, the document specifies a mechanism for link-local signaling, a OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 20 14:53:43 2004 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 OAA09443 for ; Fri, 20 Feb 2004 14:53:42 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00CF918D@cherry.ease.lsoft.com>; Fri, 20 Feb 2004 14:53:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3193352 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 20 Feb 2004 14:53:40 -0500 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 20 Feb 2004 14:43:40 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00CF9143@cherry.ease.lsoft.com>; Fri, 20 Feb 2004 14:43:40 -0500 Message-ID: Date: Fri, 20 Feb 2004 14:43:39 -0500 Reply-To: Mailing List Sender: Mailing List From: Madhavi Chandra Subject: Re: Extensions to OSPF to Support Mobile Ad Hoc Networking Comments: To: Tom Henderson To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Tom, On Tue, 17 Feb 2004 18:11:57 -0800, Henderson, Thomas R wrote: >I have some questions and comments on this document. > >- it is unclear whether this is intended for v2. At the >start of section 2, it seems to be intended for both v2 and >v3, but the discussion is very v3 specific. Yes, the proposal details are for v3....however, they do have applicability for v2 as well...although the details may differ slightly. >- at the end of page 4, there was discussion about the fact >that too many neighbors will cause scalability problems. This >was also discussed in Fred Baker's MANET draft from 2002. >Do you intend to introduce mechanisms for minimizing the >number of neighbors that a router tries to become adjacent with, >or is that outside the scope of this proposal? We are looking into ways for synchronization optimization that alleviates much of the overhead associated with two neighbors becoming adjacent. >- could you please explain why LLS extensions are preferable >to defining a new packet type (such as Incremental Hello)? >If there is no advantage, LLS seems a more roundabout way to do it. Using LLS gives you the ability to add anything to an existing OSPF packet, rather than always declaring a new type...thus, preserving backwards compatability. If an OSPF router receives a Hello packet with LLS, and doesn't support LLS, it will simply ignore it. The sender can then decide to build the adjacency normally, or just not build an adjacency at all. On the flip side, if a Hello is replaced with a new Incremental Hello packet type that is not supported, this breaks backwards compatability. >- in section 2.3.4.1, last bullet, what do you mean by neighbors >possibly being DR or BDR? Actually, we had designed this part for use 'beyond MANETs' and thus the reference. >- do you foresee additional significant extensions beyond >use of MPRs/ack strategy for flooding and use of incremental Hellos? Well, as many others, our research also continues. :) We are looking into further optimizations for scalability...but, it's pretty much work in progress. Regards, Madhavi >Tom > >> -----Original Message----- >> From: Russ White [mailto:ruwhite@CISCO.COM] >> Sent: Wednesday, February 11, 2004 6:53 AM >> To: OSPF@PEACH.EASE.LSOFT.COM >> Subject: Extensions to OSPF to Support Mobile Ad Hoc Networking >> >> >> Y'all: >> >> We are past the new work cutoff, so I'm posting this directly >> here, rather >> than waiting 'til after IETF to do so. I'll post it in the >> normal way after >> IETF is over. >> >http://www.riw.us/temp/draft-chandra-ospf-manet-00.txt > >Abstract: > >This document describes extensions to OSPF to support mobile ad hoc >networking. Specifically, the document specifies a mechanism for >link-local signaling, a OSPF-MANET interface, a simple technique to >reduce the size of Hello packets by only transmitting incremental >state changes, and a method for optimized flooding of routing >updates. > >:-) > >Russ > >__________________________________ >riw@cisco.com CCIE <>< Grace Alone From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 20 15:05:35 2004 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 PAA10182 for ; Fri, 20 Feb 2004 15:05:35 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00CF9309@cherry.ease.lsoft.com>; Fri, 20 Feb 2004 15:05:36 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3196359 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 20 Feb 2004 15:05:34 -0500 Received: from 130.76.32.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 20 Feb 2004 15:05:34 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id MAA25413; Fri, 20 Feb 2004 12:05:33 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id MAA20037; Fri, 20 Feb 2004 12:05:32 -0800 (PST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i1KK4N626018; Fri, 20 Feb 2004 12:04:23 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Fri, 20 Feb 2004 12:04:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Extensions to OSPF to Support Mobile Ad Hoc Networking Thread-Index: AcP36ilIAUeIDvalT2e9exmRTaIz7wAASSVA X-OriginalArrivalTime: 20 Feb 2004 20:04:27.0077 (UTC) FILETIME=[BE225750:01C3F7EC] Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC2EA@xch-nw-27.nw.nos.boeing.com> Date: Fri, 20 Feb 2004 12:04:26 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: Extensions to OSPF to Support Mobile Ad Hoc Networking Comments: To: Madhavi Chandra To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Madhavi Chandra [mailto:mchandra@CISCO.COM] > Sent: Friday, February 20, 2004 11:44 AM > To: OSPF@PEACH.EASE.LSOFT.COM; Henderson, Thomas R > Cc: Madhavi Chandra > Subject: Re: Extensions to OSPF to Support Mobile Ad Hoc Networking > > >- could you please explain why LLS extensions are preferable > >to defining a new packet type (such as Incremental Hello)? > >If there is no advantage, LLS seems a more roundabout way to do it. >=20 > Using LLS gives you the ability to add anything to an existing OSPF > packet, rather than always declaring a new type...thus, preserving > backwards compatability. If an OSPF router receives a Hello=20 > packet with > LLS, and doesn't support LLS, it will simply ignore it. The=20 > sender can > then decide to build the adjacency normally, or just not=20 > build an adjacency > at all. On the flip side, if a Hello is replaced with a new=20 > Incremental > Hello packet type that is not supported, this breaks backwards > compatability. >=20 I didn't see explicitly mentioned in the draft that these extensions allow adjacencies to be created between MANET and non-MANET interfaces, with the MANET mechanisms working correctly throughout the subnet. =20 Is this the case? =20 Tom From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 23 02:31:35 2004 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 CAA11602 for ; Mon, 23 Feb 2004 02:31:35 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00CFEB5E@cherry.ease.lsoft.com>; Mon, 23 Feb 2004 2:31:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3476337 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Feb 2004 02:31:32 -0500 Received: from 147.234.1.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Feb 2004 02:21:31 -0500 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.12.10+Sun/8.12.10) with ESMTP id i1N7FjE2010092 for ; Mon, 23 Feb 2004 09:15:50 +0200 (IST) X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 02/23/2004 09:21:25 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Mon, 23 Feb 2004 09:21:16 +0200 Reply-To: Mailing List Sender: Mailing List From: Ilan Bercovich Subject: RFC1850 question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hello Can any one help with this: Since "ospfAreaId" is defined as a "read-only" attribute, How should one define a new area ID?? Thanks in advance, Ilan _______________________________________ Ilan Bercovich, R&D Embedded SW Engineer Optical Networks Division, ECI Telecom Phone: +972-3-9287473 Cell: +972-55-787473 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 23 02:32:32 2004 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 CAA11632 for ; Mon, 23 Feb 2004 02:32:31 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00CFEA8D@cherry.ease.lsoft.com>; Mon, 23 Feb 2004 2:32:32 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3476843 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Feb 2004 02:32:30 -0500 Received: from 156.147.1.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Feb 2004 02:32:30 -0500 Received: from [156.147.51.110] (yjim@lge.com) by mail1.lge.co.kr (Terrace MailWatcher) with ESMTP id 2004022316:12:36:744005.26507.637 for ; Mon, 23 Feb 2004 16:12:36 +0900 (KST) X-MIMETrack: Serialize by Router on LGEKRHQMS26/LGE/LG Group(Release 5.0.12HF532 | December 4, 2003) at 2004/02/23 04:31:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: base64 X-TERRACE-SPAMRATE: Spacelee says NOT YET spam-rated. Message-ID: Date: Mon, 23 Feb 2004 16:31:48 +0900 Reply-To: Mailing List Sender: Mailing List From: "(Your Name)" Subject: Out of Office AutoReply To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 tNnAvSCx4rCjILW/vsggu+e5q73HwLsguvG/7yC/ucGkwNS0z7TZOiAgMjAwNC8wMi8yMyB+IDIw MDQvMDIvMjcNCg0KW8f1vcXH0LGzIMDUsbM6IDIvMjMov/kpIH4gMi8yNyix3SldDQoNCkknbGwg YmUgb3V0IG9mIHRoZSBvZmZpY2Ugc3RhcnRpbmcgRmViLiAyMyB1bnRpbCBGZWIuIDI3LCAyMDA0 Lg0KRm9yIGltbWVkaWF0ZSBhc3Npc3RhbmNlLCBwbGVhc2UgY29udGFjdCBteSBjb2xsZWFnZSBL eW91bmdzb28gS2ltDQphdCBraW1rc0BsZ2UuY29tLiBJJ2xsIHJlc3BvbmQgdG8geW91ciBtYWls IHdoZW4gSSByZXR1cm4uDQo= From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 23 04:23:07 2004 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 EAA14998 for ; Mon, 23 Feb 2004 04:23:07 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00CFECEF@cherry.ease.lsoft.com>; Mon, 23 Feb 2004 4:23:07 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3480166 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Feb 2004 04:23:05 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Feb 2004 04:23:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: RFC1850 question thread-index: AcP53xHzJCHhU/21QJSXWW0cmR4s5wADvpdw Message-ID: Date: Mon, 23 Feb 2004 01:21:15 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: RFC1850 question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Ilan,, Area Id has to be read only in the OspfAreaEntry Table as it is the = Index into the table. To create a new table you can set any of the read-create variables with = the correct Area Id eg ospfAuthType . Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Ilan Bercovich Sent: Monday, February 23, 2004 12:51 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: RFC1850 question Hello Can any one help with this: Since "ospfAreaId" is defined as a "read-only" attribute, How should one define a new area ID?? Thanks in advance, Ilan From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 23 11:16:29 2004 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 LAA04515 for ; Mon, 23 Feb 2004 11:16:29 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00CFF5F5@cherry.ease.lsoft.com>; Mon, 23 Feb 2004 11:16:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3556159 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Feb 2004 11:16:15 -0500 Received: from 47.129.242.157 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Feb 2004 11:16:15 -0500 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1NGGDC03207 for ; Mon, 23 Feb 2004 11:16:13 -0500 (EST) Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id <1F3PATDW>; Mon, 23 Feb 2004 11:16:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FA28.5AB58FF0" Message-ID: <8B888AAAAB0FD31189590008C79184431B09DF8E@zbl6c002.corpeast.baynetworks.com> Date: Mon, 23 Feb 2004 11:16:12 -0500 Reply-To: Mailing List Sender: Mailing List From: Ruth Fax Subject: Re: RFC1850 question To: OSPF@PEACH.EASE.LSOFT.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_01C3FA28.5AB58FF0 Content-Type: text/plain Shalom Ilan, "Read only" attributes cannot be set via SNMP. These are usuauly set by the management systems on the device. Although SNMP stand for "Simple Network Management Protocol", it's really "Simple Network Monitoring Protocol". For a number of reasons, it is very difficult to actually manage a device with SNMP. --Ruth -----Original Message----- From: Ilan Bercovich [mailto:Ilan.Bercovich@ECITELE.COM] Sent: Monday, February 23, 2004 2:21 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: RFC1850 question Hello Can any one help with this: Since "ospfAreaId" is defined as a "read-only" attribute, How should one define a new area ID?? Thanks in advance, Ilan _______________________________________ Ilan Bercovich, R&D Embedded SW Engineer Optical Networks Division, ECI Telecom Phone: +972-3-9287473 Cell: +972-55-787473 ------_=_NextPart_001_01C3FA28.5AB58FF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: RFC1850 question

Shalom Ilan,

"Read only" attributes cannot be set via = SNMP.  These are usuauly set by the management systems
on the device.  Although SNMP stand for = "Simple Network Management Protocol", it's really = "Simple Network
Monitoring Protocol".  For a number of = reasons, it is very difficult to actually manage a device with = SNMP.

--Ruth

-----Original Message-----
From: Ilan Bercovich [mailto:Ilan.Bercovich@ECITELE= .COM]
Sent: Monday, February 23, 2004 2:21 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: RFC1850 question


Hello

Can any one help with this:

Since "ospfAreaId" is defined as a = "read-only" attribute,
How should one define a new area ID??

Thanks in advance,
Ilan
_______________________________________
Ilan Bercovich, R&D Embedded SW Engineer
Optical Networks Division, ECI Telecom
Phone: +972-3-9287473 Cell: +972-55-787473

------_=_NextPart_001_01C3FA28.5AB58FF0-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 23 14:31:12 2004 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 OAA14391 for ; Mon, 23 Feb 2004 14:31:11 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00CFFAF3@cherry.ease.lsoft.com>; Mon, 23 Feb 2004 14:31:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3589406 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Feb 2004 14:30:57 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Feb 2004 14:30:57 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2004 11:33:24 -0800 Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1NJUrT4011269 for ; Mon, 23 Feb 2004 14:30:53 -0500 (EST) Received: from localhost (rtp-vpn3-305.cisco.com [10.82.217.51]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA25166 for ; Mon, 23 Feb 2004 14:30:52 -0500 (EST) References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC2DE@xch-nw-27.nw.nos.boeing.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 23 Feb 2004 14:30:52 -0500 Reply-To: Mailing List Sender: Mailing List From: Russ White Subject: Re: Extensions to OSPF to Support Mobile Ad Hoc Networking To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC2DE@xch-nw-27.nw.nos.boeing.com> Precedence: list > - at the end of page 4, there was discussion about the fact that too many > neighbors will cause scalability problems. This was also discussed in > Fred Baker's MANET draft from 2002. Do you intend to introduce > mechanisms for minimizing the number of neighbors that a router tries to > become adjacent with, or is that outside the scope of this proposal? The direction we're going on in this area is to reduce the cost of becoming adjacent, rather than preventing adjacencies in the first place--at least at this point. > - could you please explain why LLS extensions are preferable to defining > a new packet type (such as Incremental Hello)? If there is no advantage, > LLS seems a more roundabout way to do it. Because it doesn't impact backwards compatibility. The LLS extensions will be quietly ignored if the router doesn't know how to support it, which allows us to continue and build a "normal" OSPF adjacency with that neighbor. If we use some other packet type, we either need to send those packets plus hello's, to maintain backwards compatibility, or only send this new placket type, which would break backwards compatability. > - do you foresee additional significant extensions beyond use of MPRs/ack > strategy for flooding and use of incremental Hellos? Yes, possibly. There are other uses within OSPF, as well, so it's a generic extension that's useful for a lot of other things, not just MANET. Flexibility is good. :-) :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 23 14:36:30 2004 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 OAA14674 for ; Mon, 23 Feb 2004 14:36:29 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00CFFB2C@cherry.ease.lsoft.com>; Mon, 23 Feb 2004 14:36:28 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3590806 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Feb 2004 14:36:26 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Feb 2004 14:36:26 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2004 11:38:53 -0800 Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1NJaJ0K016296 for ; Mon, 23 Feb 2004 14:36:24 -0500 (EST) Received: from localhost (rtp-vpn3-305.cisco.com [10.82.217.51]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA25907 for ; Mon, 23 Feb 2004 14:36:19 -0500 (EST) References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC2EA@xch-nw-27.nw.nos.boeing.com> X-X-Sender: ruwhite@shako.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Mon, 23 Feb 2004 14:36:18 -0500 Reply-To: Mailing List Sender: Mailing List From: Russ White Subject: Re: Extensions to OSPF to Support Mobile Ad Hoc Networking To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC2EA@xch-nw-27.nw.nos.boeing.com> Precedence: list > > Using LLS gives you the ability to add anything to an existing OSPF > > packet, rather than always declaring a new type...thus, preserving > > backwards compatability. If an OSPF router receives a Hello packet with > > LLS, and doesn't support LLS, it will simply ignore it. The sender can > > then decide to build the adjacency normally, or just not build an > > adjacency at all. On the flip side, if a Hello is replaced with a new > > Incremental Hello packet type that is not supported, this breaks > > backwards compatability. > > I didn't see explicitly mentioned in the draft that these extensions > allow adjacencies to be created between MANET and non-MANET interfaces, > with the MANET mechanisms working correctly throughout the subnet. Is > this the case? The idea would be that if a new neighbor doesn't send us the LLS information, we would be able to know that (because they don't respond with the new packet format, or don't send it at all), and we can determine, at that point, if we should form an adjacency or not (this would be implementation/configuration specific). Something I could envision (this is just thinking out loud) is that we could detect nonMANET neighbors on a given physical interface, and put these neighbors on a seperate logical interface, so such auto-detection would/could be useful in some situations (?). :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 23 14:45:12 2004 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 OAA15150 for ; Mon, 23 Feb 2004 14:45:12 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00CFFA3E@cherry.ease.lsoft.com>; Mon, 23 Feb 2004 14:45:12 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3592343 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Feb 2004 14:45:10 -0500 Received: from 209.119.1.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Feb 2004 14:45:10 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wnt.dc.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.FED277CE@wnt.dc.lsoft.com>; Mon, 23 Feb 2004 14:45:10 -0500 Message-ID: Date: Mon, 23 Feb 2004 14:45:10 -0500 Reply-To: Mailing List Sender: Mailing List From: Madhavi Chandra Subject: Re: Extensions to OSPF to Support Mobile Ad Hoc Networking Comments: To: Phil Spagnolo To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Phillip, On Fri, 20 Feb 2004 10:27:46 -0800, Spagnolo, Phillip A wrote: >Madhavi, > >Below are a few questions about your optimizations for Link State >Acknowledgements. > >section 2.4.7 states > Note that a node can determine whether its further flooding a LSA > will only result in a redundant transmission by already having heard > link state acknowledgements (ACKs) or floods for the LSA from all of > its peers. > >section 2.4.8 states > 2. Typically, LSAs are acknowledged by all of the adjacent speak- > ers. In the case of relayed information, the relay MUST only > expect either explicit or implicit acknowledgements from peers > that have not previously acknowledged this LSA. The retransmis- > sion procedures, if any exist, for the underlying protocol MUST > be followed. > 3. Because routing updates are sent via multicast, the set of over- > lapping speakers will usually receive the same update more than > once. A speaker SHOULD only acknowledge the first update > received on the link. > >The draft does not specify how the following mechanisms are to be >implemented. However, the statements seem to imply memory of each ACK >that has been received. Does this mean you keep a new database of ACKs >received for a particular LSA from a particular router? Do you only >keep track of ACKs for LSAs in your link state database, or do you >record ACKs for LSAs not yet received? To determine if you should >further flood an LSA (sec 2.4.7), it seems that the later will be >needed. Also, in sec 2.4.8 a router needs past ACK information, so the >speaker only has to acknowledge the first LSA, and the LSA source does >not expect an ACK. > >My desire is to understand the complexity of keeping ACK information. Sure. This is pretty much implementation specific. We implement a new ACK cache (the ACKs aren't saved in the existing data structures). We cache ACKs for LSAs that have not yet been received. The cache also contains information on router- ID's from which the ACK has been received. Entries are aged-out based on a timer, or can be explicitly removed. Regards, Madhavi >Thanks for your response, >Phil > > > > >> -----Original Message----- >> From: Russ White [mailto:ruwhite@CISCO.COM] >> Sent: Wednesday, February 11, 2004 6:53 AM >> To: OSPF@PEACH.EASE.LSOFT.COM >> Subject: Extensions to OSPF to Support Mobile Ad Hoc Networking >> >> >> Y'all: >> >> We are past the new work cutoff, so I'm posting this directly >> here, rather than waiting 'til after IETF to do so. I'll post >> it in the normal way after IETF is over. >> >http://www.riw.us/temp/draft-chandra-ospf-manet-00.txt > >Abstract: > >This document describes extensions to OSPF to support mobile ad hoc >networking. Specifically, the document specifies a mechanism for >link-local signaling, a OSPF-MANET interface, a simple technique to >reduce the size of Hello packets by only transmitting incremental state >changes, and a method for optimized flooding of routing updates. > >:-) > >Russ > >__________________________________ >riw@cisco.com CCIE <>< Grace Alone From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 23 14:48:34 2004 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 OAA15250 for ; Mon, 23 Feb 2004 14:48:33 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00CFF981@cherry.ease.lsoft.com>; Mon, 23 Feb 2004 14:48:32 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3592686 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Feb 2004 14:48:31 -0500 Received: from 203.199.83.147 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Feb 2004 14:48:30 -0500 Received: (qmail 23213 invoked by uid 510); 23 Feb 2004 19:48:27 -0000 Received: from unknown (128.107.253.39) by rediffmail.com via HTTP; 23 feb 2004 19:48:27 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1077565707---0-203.199.83.147-23210" Message-ID: <20040223194827.23212.qmail@webmail25.rediffmail.com> Date: Mon, 23 Feb 2004 19:48:27 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: RFC1850 question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart mime message --Next_1077565707---0-203.199.83.147-23210 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AIlan,
=0AIn area table areaId is the index hence read-only.
=0A= To create a new area through SNMP, there are two ways:
=0A1) Create-Wait= the area row entry:
=0A  Later activate the entry after setting t= he other read-write
=0A  attributes of the area.
=0A2) Create a= nd Go area entry: In this case area is initialized
=0A  with defau= lt attributes.
=0A
=0A-Vivek
=0A
=0A
=0AOn Mon, 23 Feb 2004= Ilan Bercovich wrote :
=0A>Hello
=0A>
=0A>Can any one he= lp with this:
=0A>
=0A>Since "ospfAreaId" is defined = as a "read-only" attribute,
=0A>How should one define a new= area ID??
=0A>
=0A>Thanks in advance,
=0A>Ilan
=0A>= ;_______________________________________
=0A>Ilan Bercovich, R&D = Embedded SW Engineer
=0A>Optical Networks Division, ECI Telecom
= =0A>Phone: +972-3-9287473 Cell: +972-55-787473
=0A=0A

=0A

= =0A=0A --Next_1077565707---0-203.199.83.147-23210 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Ilan,=0AIn area table areaId is the index hence read-only.=0ATo create a ne= w area through SNMP, there are two ways:=0A1) Create-Wait the area row entr= y:=0A Later activate the entry after setting the other read-write=0A at= tributes of the area.=0A2) Create and Go area entry: In this case area is i= nitialized=0A with default attributes.=0A=0A-Vivek=0A =0A=0AOn Mon, 23 Fe= b 2004 Ilan Bercovich wrote :=0A>Hello=0A>=0A>Can any one help with this:= =0A>=0A>Since "ospfAreaId" is defined as a "read-only" attribute,=0A>How sh= ould one define a new area ID??=0A>=0A>Thanks in advance,=0A>Ilan=0A>______= _________________________________=0A>Ilan Bercovich, R&D Embedded SW Engine= er=0A>Optical Networks Division, ECI Telecom=0A>Phone: +972-3-9287473 Cell:= +972-55-787473=0A --Next_1077565707---0-203.199.83.147-23210-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 23 15:54:29 2004 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 PAA19471 for ; Mon, 23 Feb 2004 15:54:29 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00CFFD3C@cherry.ease.lsoft.com>; Mon, 23 Feb 2004 15:54:29 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3600453 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Feb 2004 15:54:28 -0500 Received: from 130.76.96.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Feb 2004 15:54:28 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA07300 for ; Mon, 23 Feb 2004 14:54:27 -0600 (CST) Received: from slb-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id OAA12466 for ; Mon, 23 Feb 2004 14:54:26 -0600 (CST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by slb-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i1NKr1s21014 for ; Mon, 23 Feb 2004 12:53:01 -0800 (PST) Received: from xch-nw-26.nw.nos.boeing.com ([192.48.4.100]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Mon, 23 Feb 2004 12:51:34 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Comment on draft-ogier-manet-ospf-extension-00.txt Thread-Index: AcP6RHDmAPVg5G9HSoODQXfPBkyp8QAAwBDQAAGWxFA= X-OriginalArrivalTime: 23 Feb 2004 20:51:34.0128 (UTC) FILETIME=[D26D5700:01C3FA4E] Message-ID: <2AFCB5FA378DEE4CA704B9AD7764637901839BA3@xch-nw-26.nw.nos.boeing.com> Date: Mon, 23 Feb 2004 12:51:33 -0800 Reply-To: Mailing List Sender: Mailing List From: "Spagnolo, Phillip A" Subject: Re: Comment on draft-ogier-manet-ospf-extension-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Richard, Section 6.1 of your draft states: A router can decide to suppress ACKs for a given LSA if a new instance of the LSA (with a larger sequence number) is usually received every RxmtInterval seconds (e.g., 5-10 seconds). An exponential moving average of the time between LSA updates, or of the number of LSA updates during the last RxmtInterval seconds, can be maintained for each LSA. Two thresholds can be defined to employ hysteresis in deciding whether to suppress ACKs for a given LSA. We thought the above mechanism would effectively reduce the amount of overhead due to useless acks. It potentially allows for a hybrid operation between reliable flooding during periods of low link change and periodic flooding under high link change. Therefore, we decided to take a look at this technique in isolation, as applied to OSPF. Specifically, we looked at a QualNet OSPFv2 simulation with Point-to-Multipoint interfaces on 802.11b network, a random waypoint mobility model, and only the above suggested modifications (no other wireless-oriented changes such as flooding optimizations). However, somewhat to our surprise, the simulation results suggest that the performance gains may be elusive, at least in the mobility model we tested. Specifically,=20 - the approach adapts to the link changes passively by predicting the future based upon the history. However, we found it difficult to predict based on the past, looking at both fixed and exponentially weighted windows with different window sizes and weights. In fact, it looked almost as if the interarrivals were exponentially distributed (modulo the MinLSInterval). Not only was there a degree of unpredictability in the actual generation of the LSAs, the practice of OSPF flooding further filters the interarrival process from the perspective of a given node that may be multiple hops downstream of an originator. Due to inaccurate estimates, the overall overhead went up in all simulations, and the delivery ratio went down. The LSAcks are reduced, but LSUs are increased (more retransmissions). =20 - even if each node suppresses the ACKs, the LSAs are flooded through out the network during rapid link changes around the originator. These LSAs generate much higher overhead than the ACKs (overhead due to LSA transmissions dominates that of the ACKs). =20 - the approach assumes senders use the same RxmtInterval as its own value and requires sender uses same RxmtInterval for all neighbors. This requirement may force the RxmtInterval to be interchanged between neighbors like the hello and dead intervals, or make it into an area parameter. We are preparing a draft that will provide more details about this and related topics, but just wanted to note that the early results were not promising. Phil =20 From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 24 11:29:44 2004 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 LAA28196 for ; Tue, 24 Feb 2004 11:29:44 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00D01491@cherry.ease.lsoft.com>; Tue, 24 Feb 2004 11:29:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3739680 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 24 Feb 2004 11:29:41 -0500 Received: from 207.217.120.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 24 Feb 2004 11:29:41 -0500 Received: from user-2ivfk7q.dialup.mindspring.com ([165.247.208.250] helo=erg.sri.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AvfRC-0001mQ-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 24 Feb 2004 08:29:39 -0800 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 References: <2AFCB5FA378DEE4CA704B9AD7764637901839BA3@xch-nw-26.nw.nos.boeing.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <403B7BF1.4050204@erg.sri.com> Date: Tue, 24 Feb 2004 08:29:37 -0800 Reply-To: Mailing List Sender: Mailing List From: Richard Ogier Subject: Re: Comment on draft-ogier-manet-ospf-extension-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Phil, Thanks for summarizing the results of your simulation investigation. Without knowing the parameters (e.g., smoothing constant, node speed, graph density, threshold for suppressing ACKs, etc.) and details such as whether retransmitted LSAs were unicast, I'm not sure how to interpret your conclusions. As I mentioned in my post of 2/17/04, I modified my suggested technique so that the originator decides whether the LSA should be marked as "non-ackable" depending on how frequently it changes. (I did this so that all nodes agree on whether a given LSA is ackable, and to distinguish between ackable LSAs which are unicast when retransmitted, and non-ackable LSAs which are never unicast on a MANET interface.) A non-ackable LSA is never ACKed, but is effectively flooded periodically, with a period slightly larger than MinLSInterval. It seems pretty intuitive that if an LSA is updated (a new instance originated) every MinLSInterval with probability 0.99 (for example), then since it will be flooded every MinLSInterval anyway, there is no need to ACK it, so you can save overhead by not ACKing it (although as you say the overhead reduction could be small). So the suggested technique seems useful at least in this case, unless you have decided to avoid both ACKs and periodic flooding (which is actually what I have decided). Also, one of my main points had nothing to do with hybrid operation, but only that your LSF message is not needed, since the LS sequence number can be used for this purpose. Do you agree with me on that point now? As I have discussed, I don't think LS ACKs is the best approach, and my draft actually favors using what is essentially LS *NACKs*, i.e., periodic DD packets similar to the periodic Complete Sequence Numbers packets of IS-IS. And from the new draft (draft-clausen-manet-ospf-dbx-00.txt) it appears that INRIA is also proposing to use a variation of the IS-IS technique. The only reason I proposed the hybrid of ACKs and periodic flooding is because it seemed to involve minimal changes to OSPF, which I thought would make it more acceptable to the WG. However, I am seeing major changes to OSPF proposed by both the Cisco and Boeing/INRIA teams which may be justified if they result in major improvement in performance. For example, I previously thought that incremental/differential Hellos would be too much of a change, but am glad to see that Cisco is proposing to use them. Since I used them in TBRPF (RFC 3684), I also plan to use them in the OSPF extension that I am developing (although with some differences). This is a difficult problem, so it is good that there will be multiple solutions to compare. But we need to have a plan for comparing the different solutions via simulations! Do you have a plan for compare your protocol to Cisco's? I know you are using Qualnet and Cisco is using OPNET. Regards, Richard Spagnolo, Phillip A wrote: >Richard, > >Section 6.1 of your draft states: > A router can decide to suppress ACKs for a given LSA if a new > instance of the LSA (with a larger sequence number) is usually > received every RxmtInterval seconds (e.g., 5-10 seconds). An > exponential moving average of the time between LSA updates, or of the > number of LSA updates during the last RxmtInterval seconds, can be > maintained for each LSA. Two thresholds can be defined to employ > hysteresis in deciding whether to suppress ACKs for a given LSA. > >We thought the above mechanism would effectively reduce the amount of >overhead due to useless acks. It potentially allows for a hybrid >operation between reliable flooding during periods of low link change >and periodic flooding under high link change. Therefore, we decided to >take a look at this technique in isolation, as applied to OSPF. >Specifically, we looked at a QualNet OSPFv2 simulation with >Point-to-Multipoint interfaces on 802.11b network, a random waypoint >mobility model, and only the above suggested modifications (no other >wireless-oriented changes such as flooding optimizations). > >However, somewhat to our surprise, the simulation results suggest that >the performance gains may be elusive, at least in the mobility model we >tested. Specifically, > >- the approach adapts to the link changes passively by predicting the >future based upon the history. However, we found it difficult to >predict based on the past, looking at both fixed and exponentially >weighted windows with different window sizes and weights. In fact, it >looked almost as if the interarrivals were exponentially distributed >(modulo the MinLSInterval). Not only was there a degree of >unpredictability in the actual generation of the LSAs, the practice of >OSPF flooding further filters the interarrival process from the >perspective of a given node that may be multiple hops downstream of an >originator. Due to inaccurate estimates, the overall overhead went up >in all simulations, and the delivery ratio went down. The LSAcks are >reduced, but LSUs are increased (more retransmissions). > >- even if each node suppresses the ACKs, the LSAs are flooded through >out the network during rapid link changes around the originator. These >LSAs generate much higher overhead than the ACKs (overhead due to LSA >transmissions dominates that of the ACKs). > >- the approach assumes senders use the same RxmtInterval as its own >value and requires sender uses same RxmtInterval for all neighbors. This >requirement may force the RxmtInterval to be interchanged between >neighbors like the hello and dead intervals, or make it into an area >parameter. > >We are preparing a draft that will provide more details about this and >related topics, but just wanted to note that the early results were not >promising. > >Phil > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 24 13:12:27 2004 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 NAA02089 for ; Tue, 24 Feb 2004 13:12:26 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00D01843@cherry.ease.lsoft.com>; Tue, 24 Feb 2004 13:12:11 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3749048 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 24 Feb 2004 13:12:09 -0500 Received: from 130.76.64.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 24 Feb 2004 13:12:09 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA15809 for ; Tue, 24 Feb 2004 10:12:08 -0800 (PST) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id KAA18309 for ; Tue, 24 Feb 2004 10:12:07 -0800 (PST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i1OIBMn08420 for ; Tue, 24 Feb 2004 12:11:22 -0600 (CST) Received: from xch-nw-26.nw.nos.boeing.com ([192.48.4.100]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Tue, 24 Feb 2004 10:10:55 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Comment on draft-ogier-manet-ospf-extension-00.txt Thread-Index: AcP688Yhj5PzY/X+RZy9V7vcFVLhzgADG6yA X-OriginalArrivalTime: 24 Feb 2004 18:10:55.0409 (UTC) FILETIME=[8BB74A10:01C3FB01] Message-ID: <2AFCB5FA378DEE4CA704B9AD7764637901866BC8@xch-nw-26.nw.nos.boeing.com> Date: Tue, 24 Feb 2004 10:10:55 -0800 Reply-To: Mailing List Sender: Mailing List From: "Spagnolo, Phillip A" Subject: Re: Comment on draft-ogier-manet-ospf-extension-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Richard, A general comment on our current approach to designing a wireless interface. We see that the OSPF community would like to see as few changes as necessary in a new interface. Therefore, our current approach is to start from the standard point-to-multipoint interface (could change)and to make small changes until we reach a interface that will be considered efficient enough. We are testing many of the ideas by Cisco and yourself. For example, our first step is to find the best flooding algorithm because we see that as the top generator of overhead. If after making small changes, the interface is still not efficient more drastic changes must be made. For example we are not giving up on acks, yet. We will distribute a draft that gives some insights we have gained in this approach. Comments below.=20 > -----Original Message----- > From: Richard Ogier [mailto:ogier@ERG.SRI.COM]=20 > Sent: Tuesday, February 24, 2004 8:30 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Comment on draft-ogier-manet-ospf-extension-00.txt >=20 >=20 > Phil, >=20 > Thanks for summarizing the results of your simulation=20 > investigation. Without knowing the parameters (e.g.,=20 > smoothing constant, node speed, graph density, threshold for=20 > suppressing ACKs, etc.) and details such as whether=20 > retransmitted LSAs were unicast, I'm not sure how to=20 > interpret your conclusions. Of course, different scenarios and assumptions may yield different results, but the point is that we were more discouraged than we expected in getting it to improve performance, and in looking at it more closely, it seemed like there might be fundamental difficulties in at least some scenarios. >=20 > As I mentioned in my post of 2/17/04, I modified my suggested=20 > technique so that the originator decides whether the LSA=20 > should be marked as "non-ackable" depending on how frequently=20 > it changes. (I did this so that all nodes agree on whether a=20 > given LSA is ackable, and to distinguish between ackable LSAs=20 > which are unicast when retransmitted, and non-ackable LSAs=20 > which are never unicast on a MANET interface.) A non-ackable=20 > LSA is never ACKed, but is effectively flooded periodically,=20 > with a period slightly larger than MinLSInterval. I saw your post, but we wanted to address the current draft before moving on. We also have come to the opinion that the decision to ACK or even send an LSA must be from the originators perspective. The originator has a better view of how its links are changing. Instead of not acking, it may be best to just delay the LSA that will change shortly anyway. >=20 > It seems pretty intuitive that if an LSA is updated (a new instance > originated) every MinLSInterval with probability 0.99 (for=20 > example), then since it will be flooded every MinLSInterval=20 > anyway, there is no need to ACK it, so you can save overhead=20 > by not ACKing it (although as you say the overhead reduction=20 > could be small). So the suggested technique seems useful at=20 > least in this case, unless you have decided to avoid both=20 > ACKs and periodic flooding (which is actually what I have decided). In the case you present there is no need to use ack suppression. If you delay the receiver from acking by MinLSInterval+delta=20 > Also, one of my main points had nothing to do with hybrid=20 > operation, but only that your LSF message is not needed,=20 > since the LS sequence number can be used for this purpose. =20 > Do you agree with me on that point now? Yes, it is not strictly necessary, but may be convenient, as discussed=20 in a previous post: http://peach.ease.lsoft.com/scripts/wa.exe?A2=3Dind0401&L=3Dospf&T=3D0&F=3D= &S=3D&P =3D5579 >=20 > As I have discussed, I don't think LS ACKs is the best=20 > approach, and my draft actually favors using what is=20 > essentially LS *NACKs*, i.e., periodic DD packets similar to=20 > the periodic Complete Sequence Numbers packets of IS-IS. And=20 > from the new draft > (draft-clausen-manet-ospf-dbx-00.txt) it appears that INRIA > is also proposing to use a variation of the IS-IS technique.=20 > The only reason I proposed the hybrid of ACKs and periodic=20 > flooding is because it seemed to involve minimal changes to=20 > OSPF, which I thought would make it more acceptable to the=20 > WG. However, I am seeing major changes to OSPF proposed by=20 > both the Cisco and Boeing/INRIA teams which may be justified=20 > if they result in major improvement in performance. >=20 > For example, I previously thought that=20 > incremental/differential Hellos would be too much of a=20 > change, but am glad to see that Cisco is proposing to use=20 > them. Since I used them in TBRPF (RFC 3684), I also plan to=20 > use them in the OSPF extension that I am developing (although=20 > with some differences). >=20 > This is a difficult problem, so it is good that there will be=20 > multiple solutions to compare. But we need to have a plan for=20 > comparing the different solutions via simulations! Do you=20 > have a plan for compare your protocol to Cisco's? I know you=20 > are using Qualnet and Cisco is using OPNET. >=20 > Regards, > Richard We can provide patches and scripts to QualNet if you want to repeat them (don't know if you use QualNet). It would be nice if we could get a common framework using an open-source discrete=20 event simulator with wireless models (such as ns-2). We looked at porting John Moy's simulator to ns but it didn't seem straightforward. Phil >=20 >=20 > Spagnolo, Phillip A wrote: >=20 > >Richard, > > > >Section 6.1 of your draft states: > > A router can decide to suppress ACKs for a given LSA if a new > > instance of the LSA (with a larger sequence number) is usually > > received every RxmtInterval seconds (e.g., 5-10 seconds). An > > exponential moving average of the time between LSA=20 > updates, or of the > > number of LSA updates during the last RxmtInterval seconds, can be > > maintained for each LSA. Two thresholds can be defined to employ > > hysteresis in deciding whether to suppress ACKs for a given LSA. > > > >We thought the above mechanism would effectively reduce the=20 > amount of=20 > >overhead due to useless acks. It potentially allows for a hybrid=20 > >operation between reliable flooding during periods of low=20 > link change=20 > >and periodic flooding under high link change. Therefore, we=20 > decided to=20 > >take a look at this technique in isolation, as applied to OSPF.=20 > >Specifically, we looked at a QualNet OSPFv2 simulation with=20 > >Point-to-Multipoint interfaces on 802.11b network, a random waypoint=20 > >mobility model, and only the above suggested modifications (no other=20 > >wireless-oriented changes such as flooding optimizations). > > > >However, somewhat to our surprise, the simulation results=20 > suggest that=20 > >the performance gains may be elusive, at least in the=20 > mobility model we=20 > >tested. Specifically, > > > >- the approach adapts to the link changes passively by=20 > predicting the=20 > >future based upon the history. However, we found it difficult to=20 > >predict based on the past, looking at both fixed and exponentially=20 > >weighted windows with different window sizes and weights. =20 > In fact, it=20 > >looked almost as if the interarrivals were exponentially distributed=20 > >(modulo the MinLSInterval). Not only was there a degree of=20 > >unpredictability in the actual generation of the LSAs, the=20 > practice of=20 > >OSPF flooding further filters the interarrival process from the=20 > >perspective of a given node that may be multiple hops=20 > downstream of an=20 > >originator. Due to inaccurate estimates, the overall=20 > overhead went up > >in all simulations, and the delivery ratio went down. The=20 > LSAcks are > >reduced, but LSUs are increased (more retransmissions). > > > >- even if each node suppresses the ACKs, the LSAs are=20 > flooded through=20 > >out the network during rapid link changes around the=20 > originator. These=20 > >LSAs generate much higher overhead than the ACKs (overhead=20 > due to LSA=20 > >transmissions dominates that of the ACKs). > > > >- the approach assumes senders use the same RxmtInterval as its own=20 > >value and requires sender uses same RxmtInterval for all neighbors.=20 > >This requirement may force the RxmtInterval to be=20 > interchanged between=20 > >neighbors like the hello and dead intervals, or make it into an area=20 > >parameter. > > > >We are preparing a draft that will provide more details=20 > about this and=20 > >related topics, but just wanted to note that the early=20 > results were not=20 > >promising. > > > >Phil > > >=20 From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Thu Feb 26 02:31:52 2004 Received: from grape.ease.lsoft.com (grape.ease.lsoft.com [209.119.1.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24872 for ; Thu, 26 Feb 2004 02:31:51 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <9.00414082@grape.ease.lsoft.com>; Thu, 26 Feb 2004 2:31:52 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3998335 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 26 Feb 2004 02:31:51 -0500 Received: from 147.234.1.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 26 Feb 2004 02:31:51 -0500 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.12.10+Sun/8.12.10) with ESMTP id i1Q7QCE2021079 for ; Thu, 26 Feb 2004 09:26:14 +0200 (IST) X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 02/26/2004 09:31:48 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Thu, 26 Feb 2004 09:31:38 +0200 Reply-To: Mailing List Sender: Mailing List From: Ilan Bercovich Subject: RFC1850 question - clarification To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, From Vishwas answer (below), I understand that once a table is created, read-only attribute may be set as well. But from Ruth and Vivek answers I understand read-only attributes can never be written. Can any one please clarify this point? Thanks, Ilan Vivek Dubey cc: Subject: Re: RFC1850 question 02/23/2004 21:48 Ilan, In area table areaId is the index hence read-only. To create a new area through SNMP, there are two ways: 1) Create-Wait the area row entry: Later activate the entry after setting the other read-write attributes of the area. 2) Create and Go area entry: In this case area is initialized with default attributes. -Vivek Ruth Fax cc: Subject: Re: RFC1850 question 02/23/2004 18:16 Shalom Ilan, "Read only" attributes cannot be set via SNMP. These are usuauly set by the management systems on the device. Although SNMP stand for "Simple Network Management Protocol", it's really "Simple Network Monitoring Protocol". For a number of reasons, it is very difficult to actually manage a device with SNMP. --Ruth Vishwas Manral cc: Subject: Re: RFC1850 question 02/23/2004 11:21 Hi Ilan,, Area Id has to be read only in the OspfAreaEntry Table as it is the Index into the table. To create a new table you can set any of the read-create variables with the correct Area Id eg ospfAuthType . Thanks, Vishwas -----Original Message----- From: Ilan Bercovich [mailto:Ilan.Bercovich@ECITELE.COM] Sent: Monday, February 23, 2004 2:21 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: RFC1850 question Hello Can any one help with this: Since "ospfAreaId" is defined as a "read-only" attribute, How should one define a new area ID?? Thanks in advance, Ilan _______________________________________ Ilan Bercovich, R&D Embedded SW Engineer Optical Networks Division, ECI Telecom Phone: +972-3-9287473 Cell: +972-55-787473 From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 26 02:33:14 2004 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 CAA24926 for ; Thu, 26 Feb 2004 02:33:13 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00D046C8@cherry.ease.lsoft.com>; Thu, 26 Feb 2004 2:33:13 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3998439 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 26 Feb 2004 02:33:12 -0500 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 26 Feb 2004 02:33:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: RFC1850 question - clarification thread-index: AcP8Op1IE7cQjzmPRHS6d8uZDY2FSwAAC+aQ Message-ID: Date: Wed, 25 Feb 2004 23:31:13 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: RFC1850 question - clarification To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Ilan, No Read-only attribute cannot be set after a table is created. Sorry if = I conveyed that wrongly. -Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Ilan Bercovich Sent: Thursday, February 26, 2004 1:02 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: RFC1850 question - clarification Hi, From Vishwas answer (below), I understand that once a table is created, read-only attribute may be set as well. But from Ruth and Vivek answers I understand read-only attributes can = never be written. Can any one please clarify this point? Thanks, Ilan Vivek Dubey cc: Subject: Re: RFC1850 question 02/23/2004 21:48 Ilan, In area table areaId is the index hence read-only. To create a new area through SNMP, there are two ways: 1) Create-Wait the area row entry: Later activate the entry after setting the other read-write attributes of the area. 2) Create and Go area entry: In this case area is initialized with default attributes. -Vivek Ruth Fax cc: Subject: Re: RFC1850 = question 02/23/2004 18:16 Shalom Ilan, "Read only" attributes cannot be set via SNMP. These are usuauly set by the management systems on the device. Although SNMP stand for "Simple Network Management Protocol", it's really "Simple Network Monitoring Protocol". For a number of reasons, it is very difficult to actually manage a device with SNMP. --Ruth Vishwas Manral cc: Subject: Re: RFC1850 question 02/23/2004 11:21 Hi Ilan,, Area Id has to be read only in the OspfAreaEntry Table as it is the = Index into the table. To create a new table you can set any of the read-create variables with = the correct Area Id eg ospfAuthType . Thanks, Vishwas -----Original Message----- From: Ilan Bercovich [mailto:Ilan.Bercovich@ECITELE.COM] Sent: Monday, February 23, 2004 2:21 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: RFC1850 question Hello Can any one help with this: Since "ospfAreaId" is defined as a "read-only" attribute, How should one define a new area ID?? Thanks in advance, Ilan _______________________________________ Ilan Bercovich, R&D Embedded SW Engineer Optical Networks Division, ECI Telecom Phone: +972-3-9287473 Cell: +972-55-787473 From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 26 02:35:43 2004 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 CAA25045 for ; Thu, 26 Feb 2004 02:35:42 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00D046DC@cherry.ease.lsoft.com>; Thu, 26 Feb 2004 2:35:42 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3998730 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 26 Feb 2004 02:35:41 -0500 Received: from 147.234.1.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 26 Feb 2004 02:35:40 -0500 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.12.10+Sun/8.12.10) with ESMTP id i1Q7U1E6022122 for ; Thu, 26 Feb 2004 09:30:03 +0200 (IST) X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at 02/26/2004 09:35:38 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Thu, 26 Feb 2004 09:35:20 +0200 Reply-To: Mailing List Sender: Mailing List From: Ilan Bercovich Subject: Re: RFC1850 question - clarification To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Vishwas I didn't write "after a table is created", but "once a table is created". Can it be set then? Regards, Ilan Vishwas Manral cc: Sent by: Mailing Subject: Re: RFC1850 question - clarification List 02/26/2004 09:31 Please respond to Mailing List Ilan, No Read-only attribute cannot be set after a table is created. Sorry if I conveyed that wrongly. -Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Ilan Bercovich Sent: Thursday, February 26, 2004 1:02 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: RFC1850 question - clarification Hi, From Vishwas answer (below), I understand that once a table is created, read-only attribute may be set as well. But from Ruth and Vivek answers I understand read-only attributes can never be written. Can any one please clarify this point? Thanks, Ilan Vivek Dubey cc: Subject: Re: RFC1850 question 02/23/2004 21:48 Ilan, In area table areaId is the index hence read-only. To create a new area through SNMP, there are two ways: 1) Create-Wait the area row entry: Later activate the entry after setting the other read-write attributes of the area. 2) Create and Go area entry: In this case area is initialized with default attributes. -Vivek Ruth Fax cc: Subject: Re: RFC1850 question 02/23/2004 18:16 Shalom Ilan, "Read only" attributes cannot be set via SNMP. These are usuauly set by the management systems on the device. Although SNMP stand for "Simple Network Management Protocol", it's really "Simple Network Monitoring Protocol". For a number of reasons, it is very difficult to actually manage a device with SNMP. --Ruth Vishwas Manral cc: Subject: Re: RFC1850 question 02/23/2004 11:21 Hi Ilan,, Area Id has to be read only in the OspfAreaEntry Table as it is the Index into the table. To create a new table you can set any of the read-create variables with the correct Area Id eg ospfAuthType . Thanks, Vishwas -----Original Message----- From: Ilan Bercovich [mailto:Ilan.Bercovich@ECITELE.COM] Sent: Monday, February 23, 2004 2:21 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: RFC1850 question Hello Can any one help with this: Since "ospfAreaId" is defined as a "read-only" attribute, How should one define a new area ID?? Thanks in advance, Ilan _______________________________________ Ilan Bercovich, R&D Embedded SW Engineer Optical Networks Division, ECI Telecom Phone: +972-3-9287473 Cell: +972-55-787473 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 27 16:56:26 2004 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 QAA26750 for ; Fri, 27 Feb 2004 16:56:26 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00D07B0F@cherry.ease.lsoft.com>; Fri, 27 Feb 2004 16:56:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 4262341 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 27 Feb 2004 16:56:24 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 27 Feb 2004 16:56:24 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 8B9955CF626; Fri, 27 Feb 2004 13:56:23 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10095-07; Fri, 27 Feb 2004 13:56:23 -0800 (PST) Received: from aceeinspiron (unknown [172.31.253.222]) by prattle.redback.com (Postfix) with SMTP id B0EE45CF625; Fri, 27 Feb 2004 13:56:22 -0800 (PST) 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <02c401c3fd7c$86762e90$0302a8c0@aceeinspiron> Date: Fri, 27 Feb 2004 16:56:16 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPFv3 Destination Address Filter Comments: To: RPSEC WG List To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit We've implemented the subject draft to mitigate some of the OSPFv3 vulnerabilities. While the solution isn't perfect, it is lightweight, easy to deploy, and fully compatible with the current OSPFv3 specification (RFC 2740). http://www.ietf.org/internet-drafts/draft-lindem-ospfv3-dest-filter-00.txt ------ Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 27 17:59:37 2004 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 RAA00805 for ; Fri, 27 Feb 2004 17:59:36 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00D07CBC@cherry.ease.lsoft.com>; Fri, 27 Feb 2004 17:59:35 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 4267881 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 27 Feb 2004 17:59:33 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 27 Feb 2004 17:59:33 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id i1RMxXUG014847 for ; Fri, 27 Feb 2004 17:59:33 -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 RAA03914 for ; Fri, 27 Feb 2004 17:59:34 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Feb 2004 17:59:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55FB7201@vie-msgusr-01.dc.fore.com> Date: Fri, 27 Feb 2004 17:59:29 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: OSPFv3 Destination Address Filter To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Acee, -> We've implemented the subject draft to mitigate some of the -> OSPFv3 vulnerabilities. While the solution isn't perfect, it is -> lightweight, easy to deploy, and fully compatible with the current -> OSPFv3 specification (RFC 2740). -> -> http://www.ietf.org/internet-drafts/draft-lindem-ospfv3-dest- -> filter-00.txt After a quick look, here are few comments: 1. Check should be: if (((first-two-octets & 0xffc0) != 0xfe80) && <<<< ((first-two-octets & 0xff0f) != 0xff02)) { ==== ((first-two-octets & 0xffff) != 0xff02)) { >>>> drop the packet; } I think, OSPFv3 SHOULD work on permanently flagged multicast addresses not with T flag on'ed ones. 2. The draft reads: The granularity of the check will limit the usage of virtual links at the granularity which it is applied. For example, if it is applied at the BSD socket level, virtual links may not be used by any OSPF instance utilizing that socket. Alternately, additional configuration and checking could be added at the socket level so that the destination filter is only applied to certain instances, areas, or interfaces. There is another way to support what this draft does with out loss of generality. If these checks are applied at the Raw-IPv6 stack level (using local address binding socket options) virtual link support will not be jeopardized. Doing below steps will solve DOS attack for IPv4 applications (i.e., OSPFv2, RSVP-TE etc) and IPv6 applications (i.e., OSPFv3 etc.) - at least for the ones which operate on per interface basis. 1. Bind to the local interface (either using link-layer address/ ifindex) and make it strong-end socket. That is the socket will accept incoming packets only from the binded interface. 2. Listen only for appropriate multicast address groups using various MULTICAST socket options. This will make sure the above checks are done at the Raw-IP level instead of at the OSPF level. 3. Open another INADDR_ANY socket ONLY when virtual links are operational. Note that, this socket will receive all types of OSPF packets. But, that is fine, OSPF will anyway make sure (have to make sure) validity of every packet received on this socket. It is a good idea to enhance socket APIs to have filters based on list of IP addresses instead of all-or-one (i.e., multiple bindings like). May be, Bill Fenner can answer why it is not incorporated in IPv6 at least. I expected this in his recent Book. :) Venakta. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 27 18:37:40 2004 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 SAA03699 for ; Fri, 27 Feb 2004 18:37:40 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00D07DAF@cherry.ease.lsoft.com>; Fri, 27 Feb 2004 18:37:41 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 4273382 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 27 Feb 2004 18:37:40 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 27 Feb 2004 18:37:39 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E609EA1E0A3 for ; Fri, 27 Feb 2004 15:37:38 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25021-08 for ; Fri, 27 Feb 2004 15:37:38 -0800 (PST) Received: from redback.com (dhcp-41-22.redback.com [155.53.41.22]) by prattle.redback.com (Postfix) with ESMTP id B12E1A1E0A2 for ; Fri, 27 Feb 2004 15:37:38 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <39469E08BD83D411A3D900204840EC55FB7201@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <403FD44D.B4BAC5E8@redback.com> Date: Fri, 27 Feb 2004 15:35:41 -0800 Reply-To: Mailing List Sender: Mailing List From: Anand Oswal Organization: Redback Networks Subject: Re: OSPFv3 Destination Address Filter To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Venkata, Are you talking about a socket per interface ? Thanks Anand "Naidu, Venkata" wrote: > > Hi Acee, > > -> We've implemented the subject draft to mitigate some of the > -> OSPFv3 vulnerabilities. While the solution isn't perfect, it is > -> lightweight, easy to deploy, and fully compatible with the current > -> OSPFv3 specification (RFC 2740). > -> > -> http://www.ietf.org/internet-drafts/draft-lindem-ospfv3-dest- > -> filter-00.txt > > After a quick look, here are few comments: > > 1. Check should be: > if (((first-two-octets & 0xffc0) != 0xfe80) && > <<<< > ((first-two-octets & 0xff0f) != 0xff02)) { > ==== > ((first-two-octets & 0xffff) != 0xff02)) { > >>>> > drop the packet; > } > > I think, OSPFv3 SHOULD work on permanently flagged multicast > addresses not with T flag on'ed ones. > > 2. The draft reads: > > The granularity of the check will limit the usage of virtual > links at the granularity which it is applied. For example, if > it is applied at the BSD socket level, virtual links may not > be used by any OSPF instance utilizing that socket. > Alternately, additional configuration and checking could be > added at the socket level so that the destination filter is > only applied to certain instances, areas, or interfaces. > > There is another way to support what this draft does with out > loss of generality. If these checks are applied at the Raw-IPv6 > stack level (using local address binding socket options) > virtual link support will not be jeopardized. > > Doing below steps will solve DOS attack for IPv4 applications > (i.e., OSPFv2, RSVP-TE etc) and IPv6 applications (i.e., OSPFv3 > etc.) - at least for the ones which operate on per interface > basis. > > 1. Bind to the local interface (either using link-layer address/ > ifindex) and make it strong-end socket. That is the socket > will accept incoming packets only from the binded interface. > > 2. Listen only for appropriate multicast address groups using > various MULTICAST socket options. This will make sure the > above checks are done at the Raw-IP level instead of at the > OSPF level. > > 3. Open another INADDR_ANY socket ONLY when virtual links are > operational. Note that, this socket will receive all types > of OSPF packets. But, that is fine, OSPF will anyway make > sure (have to make sure) validity of every packet received > on this socket. > > It is a good idea to enhance socket APIs to have filters based > on list of IP addresses instead of all-or-one (i.e., multiple > bindings like). May be, Bill Fenner can answer why it is not > incorporated in IPv6 at least. I expected this in his recent > Book. :) > > Venakta. From owner-ospf@PEACH.EASE.LSOFT.COM Sat Feb 28 00:12:45 2004 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 AAA17767 for ; Sat, 28 Feb 2004 00:12:45 -0500 (EST) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00D085B7@cherry.ease.lsoft.com>; Sat, 28 Feb 2004 0:08:28 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 4304192 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 28 Feb 2004 00:08:26 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 28 Feb 2004 00:08:26 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00D08564@cherry.ease.lsoft.com>; Sat, 28 Feb 2004 0:08:24 -0500 Received: from 192.11.222.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 28 Feb 2004 00:08:23 -0500 Received: from shobharani-st2 (h135-254-211-199.lucent.com [135.254.211.199]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with SMTP id i1S58Gr27467 for ; Fri, 27 Feb 2004 23:08:17 -0600 (CST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ceyntgwpxgyfxuguubjq" Message-ID: Date: Sat, 28 Feb 2004 10:38:15 +0530 Reply-To: Mailing List Sender: Mailing List From: John.Moy@SYCAMORENET.COM Subject: Monthly incomings summary Comments: To: OSPF@DISCUSS.MICROSOFT.COM To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list ----------ceyntgwpxgyfxuguubjq Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on the network) Found virus WORM_BAGLE.C in file lhdybymw.exe (in badcbabb.zip) The file badcbabb.zip is moved to /var/spool/quarantine/virODLklOfLa. This is a machine-generated message, please do not reply via email. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770. --------------------------------------------------------- ----------ceyntgwpxgyfxuguubjq Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ----------ceyntgwpxgyfxuguubjq Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on the network) badcbabb.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------ceyntgwpxgyfxuguubjq--