From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 1 09:49:41 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00976 for ; Thu, 1 Aug 2002 09:49:40 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.006B72F4@cherry.ease.lsoft.com>; Thu, 1 Aug 2002 9:50:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 160528 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 1 Aug 2002 09:50:40 -0400 Received: from 64.26.0.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 1 Aug 2002 09:50:40 -0400 Received: from gsaravanan-PC.zigma.com (ip-151-104-122-168.corp.ne.3com.com [151.104.122.168] (may be forged)) by bernstein.siteprotect.com (8.9.3/8.9.3) with ESMTP id IAA03100 for ; Thu, 1 Aug 2002 08:50:39 -0500 X-Sender: gsaravanan@www.zigma.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <5.0.2.1.0.20020801095017.00a30cb0@www.zigma.com> Date: Thu, 1 Aug 2002 09:59:14 -0400 Reply-To: Mailing List Sender: Mailing List From: Sriram Saravanan Subject: Data Description Packet Sequence To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I have a question regarding Data Description Sequence Generation and any comments/suggestions on this is welcome. My Question: I am trying to use one of my SUN Interface as OSPF Emulator. I try to send OSPF hello packets periodically to OSPF Network where I have one or two switches which has been configured to handle OSPF routing. When the routers see the hello packets coming out from my SUN, they try to update LS by sending Data Description Packets. While trying to ack. the packets, I try to send DD Sequence packet and trying to claim myself as Master. But, while doing so, for some reason, I couldn't establish master-slave relationship and both my Sun Workstation and Router claim as master. (Router ID of Hello Packets generated from SUN is greater than OSPF Routers) Any idea what I am doing wrong here .... Thanks and have a great day! - G From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 1 11:49:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04382 for ; Thu, 1 Aug 2002 11:49:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.006B74C3@cherry.ease.lsoft.com>; Thu, 1 Aug 2002 11:50:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 161079 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 1 Aug 2002 11:50:56 -0400 Received: from 205.158.62.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 1 Aug 2002 11:50:55 -0400 Received: (qmail 60646 invoked by uid 1001); 1 Aug 2002 15:50:54 -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 [141.84.69.18] by ws1-11.us4.outblaze.com with http for beatriz_hargrave@mail.com; Thu, 01 Aug 2002 10:50:54 -0500 X-Originating-Ip: 141.84.69.18 X-Originating-Server: ws1-11.us4.outblaze.com Message-ID: <20020801155054.60645.qmail@mail.com> Date: Thu, 1 Aug 2002 10:50:54 -0500 Reply-To: Mailing List Sender: Mailing List From: Beatriz Silva Subject: usage of OSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello everybody ! Does anybody know what is the usage of OSPF protocol as compared to the other routing protocols ? Is it really the most used ? What is the percentage of networks that use OSPF ? I have the same question for SNMP management protocol too. (if somebody happens to know) Thanks, Beatriz -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup Get 4 DVDs for $.49 cents! plus shipping & processing. Click to join. http://adfarm.mediaplex.com/ad/ck/990-1736-3566-59 From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 1 12:14:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05361 for ; Thu, 1 Aug 2002 12:14:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.006B768F@cherry.ease.lsoft.com>; Thu, 1 Aug 2002 12:15:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 161159 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 1 Aug 2002 12:15:26 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 1 Aug 2002 12:15:26 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 2BC9B1531D4 for ; Thu, 1 Aug 2002 09:15:23 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <5.0.2.1.0.20020801095017.00a30cb0@www.zigma.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D495E2F.9030408@redback.com> Date: Thu, 1 Aug 2002 12:13:35 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Data Description Packet Sequence To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sriram Saravanan wrote: > Hi, > > I have a question regarding Data Description Sequence Generation and any comments/suggestions on this is welcome. > > My Question: > I am trying to use one of my SUN Interface as OSPF Emulator. > > I try to send OSPF hello packets periodically to OSPF Network where I have one or two switches which has been configured to handle OSPF routing. > > When the routers see the hello packets coming out from my SUN, they try to update LS by sending Data Description Packets. > > While trying to ack. the packets, I try to send DD Sequence packet and trying to claim myself as Master. > > But, while doing so, for some reason, I couldn't establish master-slave relationship and both my Sun Workstation and Router claim as master. (Router ID of Hello Packets generated from SUN is greater than OSPF Routers) > > Any idea what I am doing wrong here .... Sriram, Both sides will send the initial DD packet with the M bit set. Try re-sending the DD packet from you emulation code once you determine your router-ID is greater (refer to figure 14 on page 106 in RFC 2329). Also, make use you are don't have any little endian issues with the packets you are sending from the Sun. You could check your router vendor's debug output (but don't put vendor specific debug output to this list ;^). > > Thanks and have a great day! > > - G > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 1 17:42:49 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15759 for ; Thu, 1 Aug 2002 17:42:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.006B821A@cherry.ease.lsoft.com>; Thu, 1 Aug 2002 17:43:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 162212 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 1 Aug 2002 17:43:54 -0400 Received: from 204.178.16.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 1 Aug 2002 17:33:54 -0400 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g71LXrLI069950 for ; Thu, 1 Aug 2002 17:33:53 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g71LXlk89850 for ; Thu, 1 Aug 2002 17:33:47 -0400 (EDT) Received: from fanghpcho (fangh-pcho [135.180.160.148]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id RAA09872 for ; Thu, 1 Aug 2002 17:33:47 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Thu, 1 Aug 2002 17:33:47 -0400 Reply-To: Mailing List Sender: Mailing List From: Fang Hao Subject: MIB for OSPF-TE? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, I am trying to find out if there is any MIB defined for OSPF TE extensions. For instance, if I need to set the TE metric of a router by using SNMP, which table should I look for? I browsed through the current drafts and RFCs of this working group, but didn't find it. Maybe I missed it though. Thanks, Fang From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 1 18:05:18 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17673 for ; Thu, 1 Aug 2002 18:05:18 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.006B834D@cherry.ease.lsoft.com>; Thu, 1 Aug 2002 18:06:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 162356 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 1 Aug 2002 18:06:27 -0400 Received: from 141.156.71.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 1 Aug 2002 18:06:27 -0400 Received: from WTN10069.opnet.com (unverified) by smtp1.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Thu, 1 Aug 2002 18:05:42 -0400 X-Sender: svenkatachalam@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.2.20020801180510.00ae6540@mail.opnet.com> Date: Thu, 1 Aug 2002 18:06:22 -0400 Reply-To: Mailing List Sender: Mailing List From: "Senthil K. Venkatachalam" Subject: Re: MIB for OSPF-TE? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi Fang, There is no MIB defined yet for the OSPF extensions for TE. Regards, Senthil. At 05:33 PM 8/1/2002 -0400, Fang Hao wrote: >Hi, > >I am trying to find out if there is any MIB defined for OSPF >TE extensions. For instance, if I need to set the TE metric >of a router by using SNMP, which table should I look for? I >browsed through the current drafts and RFCs of this working >group, but didn't find it. Maybe I missed it though. > >Thanks, >Fang From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 1 18:18:21 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18300 for ; Thu, 1 Aug 2002 18:18:21 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.006B82B0@cherry.ease.lsoft.com>; Thu, 1 Aug 2002 18:19:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 162446 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 1 Aug 2002 18:19:29 -0400 Received: from 204.178.16.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 1 Aug 2002 18:19:29 -0400 Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.5/8.12.5) with ESMTP id g71MJTLI070284 for ; Thu, 1 Aug 2002 18:19:29 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g71MJMo68836 for ; Thu, 1 Aug 2002 18:19:22 -0400 (EDT) Received: from fanghpcho (fangh-pcho [135.180.160.148]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id SAA11301 for ; Thu, 1 Aug 2002 18:19:22 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Thu, 1 Aug 2002 18:19:22 -0400 Reply-To: Mailing List Sender: Mailing List From: Fang Hao Subject: Re: MIB for OSPF-TE? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <5.1.0.14.2.20020801180510.00ae6540@mail.opnet.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Senthil, Thanks for replying. Are you aware of any work undergoing to define such a MIB, or any vendor has it in their enterprise MIB? Fang -----Original Message----- From: Mailing List [mailto:OSPF@discuss.microsoft.com]On Behalf Of Senthil K. Venkatachalam Sent: Thursday, August 01, 2002 6:06 PM To: OSPF@discuss.microsoft.com Subject: Re: MIB for OSPF-TE? Hi Fang, There is no MIB defined yet for the OSPF extensions for TE. Regards, Senthil. At 05:33 PM 8/1/2002 -0400, Fang Hao wrote: >Hi, > >I am trying to find out if there is any MIB defined for OSPF >TE extensions. For instance, if I need to set the TE metric >of a router by using SNMP, which table should I look for? I >browsed through the current drafts and RFCs of this working >group, but didn't find it. Maybe I missed it though. > >Thanks, >Fang From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 1 18:39:03 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19152 for ; Thu, 1 Aug 2002 18:39:03 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.006B833F@cherry.ease.lsoft.com>; Thu, 1 Aug 2002 18:40:12 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 162552 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 1 Aug 2002 18:40:12 -0400 Received: from 141.156.71.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 1 Aug 2002 18:40:12 -0400 Received: from WTN10069.opnet.com (unverified) by smtp1.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Thu, 1 Aug 2002 18:39:17 -0400 X-Sender: svenkatachalam@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <5.1.0.14.2.20020801180510.00ae6540@mail.opnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.2.20020801183904.00b10e40@mail.opnet.com> Date: Thu, 1 Aug 2002 18:39:57 -0400 Reply-To: Mailing List Sender: Mailing List From: "Senthil K. Venkatachalam" Subject: Re: MIB for OSPF-TE? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Fang, Vendors define their own proprietary MIBs and CLI. You can find some info at the Cisco/Juniper Websites. Regards, Senthil. At 06:19 PM 8/1/2002 -0400, you wrote: >Hi Senthil, > >Thanks for replying. Are you aware of any work undergoing >to define such a MIB, or any vendor has it in their enterprise MIB? > >Fang > >-----Original Message----- >From: Mailing List [mailto:OSPF@discuss.microsoft.com]On Behalf Of >Senthil K. Venkatachalam >Sent: Thursday, August 01, 2002 6:06 PM >To: OSPF@discuss.microsoft.com >Subject: Re: MIB for OSPF-TE? > > >Hi Fang, > >There is no MIB defined yet for the OSPF extensions for TE. > >Regards, >Senthil. > > >At 05:33 PM 8/1/2002 -0400, Fang Hao wrote: > >Hi, > > > >I am trying to find out if there is any MIB defined for OSPF > >TE extensions. For instance, if I need to set the TE metric > >of a router by using SNMP, which table should I look for? I > >browsed through the current drafts and RFCs of this working > >group, but didn't find it. Maybe I missed it though. > > > >Thanks, > >Fang From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 2 05:03:20 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11710 for ; Fri, 2 Aug 2002 05:03:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.006B9691@cherry.ease.lsoft.com>; Fri, 2 Aug 2002 5:04:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 164164 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 2 Aug 2002 05:04:28 -0400 Received: from 62.241.160.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 2 Aug 2002 05:04:28 -0400 Received: from tom3 (usermg68.uk.uudial.com [62.188.122.54]) by colossus.systems.pipex.net (Postfix) with SMTP id 7A84516000541 for ; Fri, 2 Aug 2002 10:04:26 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <016d01c23a03$378a0420$0301a8c0@tom3> Date: Fri, 2 Aug 2002 09:52:55 +0100 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: usage of OSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit My experience across some hundred of more medium and large enterprises, mostly in Europe, is, in order of usage, 1 RIPv1 2 OSPF 3 RIPv2 4 Cisco proprietary ISIS nowhere. Given some enterprises have more than one IGP, OSPF is about 30%. For me, this ongoing use of mature and familiar technology parallels the use of Ethernetv2 to underpin ever larger and faster networks :-) For SNMP, I suggest you try an SNMP mailing list and I'll give you my ha'pen'orth there. Tom Petch, Network Consultant nwnetworks@dial.pipex.com -----Original Message----- From: Beatriz Silva To: OSPF@DISCUSS.MICROSOFT.COM Date: 01 August 2002 16:48 Subject: usage of OSPF >Hello everybody ! > >Does anybody know what is the usage of OSPF protocol as compared to the other routing protocols ? Is it really the most used ? What is the percentage of networks that use OSPF ? > >I have the same question for SNMP management protocol too. (if somebody happens to know) > >Thanks, >Beatriz > > >-- >__________________________________________________________ >Sign-up for your own FREE Personalized E-mail at Mail.com >http://www.mail.com/?sr=signup > >Get 4 DVDs for $.49 cents! plus shipping & processing. Click to join. >http://adfarm.mediaplex.com/ad/ck/990-1736-3566-59 From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 2 05:16:05 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11909 for ; Fri, 2 Aug 2002 05:16:05 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006B95CF@cherry.ease.lsoft.com>; Fri, 2 Aug 2002 5:17:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 164215 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 2 Aug 2002 05:17:14 -0400 Received: from 66.218.78.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 2 Aug 2002 05:17:13 -0400 Received: from [203.200.20.226] by web40307.mail.yahoo.com via HTTP; Fri, 02 Aug 2002 02:17:13 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020802091713.15640.qmail@web40307.mail.yahoo.com> Date: Fri, 2 Aug 2002 02:17:13 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Opaque LSA Type To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <01ff01c2014c$7290cdf0$b4036c6b@sisodomain.com> Precedence: list Hi All, We all know that Type 10 of opaque LSA is used for the TE Application. what are Type 9 and Type 11 LSAs used for??? Regards Amit __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 2 06:27:19 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12841 for ; Fri, 2 Aug 2002 06:27:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006B9732@cherry.ease.lsoft.com>; Fri, 2 Aug 2002 6:28:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 164753 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 2 Aug 2002 06:28:27 -0400 Received: from 64.4.15.136 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 2 Aug 2002 06:28:27 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 2 Aug 2002 03:28:27 -0700 Received: from 203.196.146.243 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 02 Aug 2002 10:28:27 GMT X-Originating-IP: [203.196.146.243] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 Aug 2002 10:28:27.0414 (UTC) FILETIME=[56C00360:01C23A0F] Message-ID: Date: Fri, 2 Aug 2002 10:28:27 +0000 Reply-To: Mailing List Sender: Mailing List From: praveendas e Subject: Re: Opaque LSA Type To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hai Amith, In the draft draft-katz-yeung-ospf-traffic-06.txt they are saying as " Three types of Opaque LSAs exist, each of which has different flooding scope. This proposal uses only Type 10 LSAs, which have area flooding scope. " in section 2.1 LSA Type But in the RFC 2370 it is clear that "Link-state type 9 denotes a link-local scope. Type-9 Opaque LSAs are not flooded beyond the local (sub)network" and "Link-state type 11 denotes that the LSA is flooded throughout the Autonomous System (AS). The flooding scope of type-11 LSAs are equivalent to the flooding scope of AS-external (type-5) LSAs. Specifically type-11 Opaque LSAs are 1) flooded throughout all transit areas, 2) not flooded into stub areas from the backbone and 3) not originated by routers into their connected stub areas. As with type-5 LSAs, if a type-11 Opaque LSA is received in a stub area from a neighboring router within the stub area the LSA is rejected. " Hope this will help you Regards Praveendas Hi All, We all know that Type 10 of opaque LSA is used for the TE Application. what are Type 9 and Type 11 LSAs used for??? Regards Amit _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 2 06:28:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12859 for ; Fri, 2 Aug 2002 06:28:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.006B96CB@cherry.ease.lsoft.com>; Fri, 2 Aug 2002 6:29:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 164790 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 2 Aug 2002 06:29:59 -0400 Received: from 64.4.15.67 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 2 Aug 2002 06:29:59 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 2 Aug 2002 03:29:59 -0700 Received: from 203.196.146.243 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 02 Aug 2002 10:29:58 GMT X-Originating-IP: [203.196.146.243] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 Aug 2002 10:29:59.0152 (UTC) FILETIME=[8D6E1F00:01C23A0F] Message-ID: Date: Fri, 2 Aug 2002 10:29:58 +0000 Reply-To: Mailing List Sender: Mailing List From: praveendas e Subject: Re: Opaque LSA Type To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hai Amith, In the draft draft-katz-yeung-ospf-traffic-06.txt they are saying as " Three types of Opaque LSAs exist, each of which has different flooding scope. This proposal uses only Type 10 LSAs, which have area flooding scope. " in section 2.1 LSA Type But in the RFC 2370 it is clear that "Link-state type 9 denotes a link-local scope. Type-9 Opaque LSAs are not flooded beyond the local (sub)network" and "Link-state type 11 denotes that the LSA is flooded throughout the Autonomous System (AS). The flooding scope of type-11 LSAs are equivalent to the flooding scope of AS-external (type-5) LSAs. Specifically type-11 Opaque LSAs are 1) flooded throughout all transit areas, 2) not flooded into stub areas from the backbone and 3) not originated by routers into their connected stub areas. As with type-5 LSAs, if a type-11 Opaque LSA is received in a stub area from a neighboring router within the stub area the LSA is rejected. " Hope this will help you Regards Praveendas Hi All, We all know that Type 10 of opaque LSA is used for the TE Application. what are Type 9 and Type 11 LSAs used for??? Regards Amit _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 2 07:55:22 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15271 for ; Fri, 2 Aug 2002 07:55:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006B99DF@cherry.ease.lsoft.com>; Fri, 2 Aug 2002 7:56:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 165067 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 2 Aug 2002 07:56:31 -0400 Received: from 64.102.17.77 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 2 Aug 2002 07:56:31 -0400 Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA29719 for ; Fri, 2 Aug 2002 07:56:31 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 2 Aug 2002 07:56:31 -0400 Reply-To: Mailing List Sender: Mailing List From: Russ White Subject: Re: usage of OSPF To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <016d01c23a03$378a0420$0301a8c0@tom3> Precedence: list My experience differs somewhat.... In the US, I see mostly EIGRP in the enterprise market (maybe 80%), with some OSPF, and no IS-IS. On the SP side, I see about equal parts of IS-IS and OSPF. In Europe, I mostly see about equal divides between the three in the enterprise market, with SP's mostly on the IS-IS side, with some OSPF. But I'm certain you'll hear different things from different people, depending on which customers they've worked with. :-) Russ On Fri, 2 Aug 2002, Tom Petch wrote: > My experience across some hundred of more medium and large > enterprises, mostly in Europe, is, in order of usage, > > 1 RIPv1 > 2 OSPF > 3 RIPv2 > 4 Cisco proprietary > > ISIS nowhere. > Given some enterprises have more than one IGP, OSPF is about 30%. > > For me, this ongoing use of mature and familiar technology parallels > the use of Ethernetv2 to underpin ever larger and faster networks :-) > > For SNMP, I suggest you try an SNMP mailing list and I'll give you my > ha'pen'orth there. > > Tom Petch, Network Consultant > nwnetworks@dial.pipex.com > > -----Original Message----- > From: Beatriz Silva > To: OSPF@DISCUSS.MICROSOFT.COM > Date: 01 August 2002 16:48 > Subject: usage of OSPF > > > >Hello everybody ! > > > >Does anybody know what is the usage of OSPF protocol as compared to > the other routing protocols ? Is it really the most used ? What is the > percentage of networks that use OSPF ? > > > >I have the same question for SNMP management protocol too. (if > somebody happens to know) > > > >Thanks, > >Beatriz > > > > > >-- > >__________________________________________________________ > >Sign-up for your own FREE Personalized E-mail at Mail.com > >http://www.mail.com/?sr=signup > > > >Get 4 DVDs for $.49 cents! plus shipping & processing. Click to join. > >http://adfarm.mediaplex.com/ad/ck/990-1736-3566-59 > __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 2 09:56:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20009 for ; Fri, 2 Aug 2002 09:56:32 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.006B9B8B@cherry.ease.lsoft.com>; Fri, 2 Aug 2002 9:57:39 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 165425 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 2 Aug 2002 09:57:39 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 2 Aug 2002 09:57:39 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 31B632848B6 for ; Fri, 2 Aug 2002 06:57:38 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20020802091713.15640.qmail@web40307.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D4A8F5A.90000@redback.com> Date: Fri, 2 Aug 2002 09:55:38 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Opaque LSA Type To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Someone asked this once before. If you go to the archives and start with this post, you'll see a whole range of potential applications. As previous noted, the LSA type designates the flooding scope. The application or LSA type is contained in the leftmost 8 bits of the LSA ID (these types are assigned by IANA). I hope this link works... http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R8870&I=-3&m=2147 Amit Srivastava wrote: > Hi All, > We all know that Type 10 of opaque LSA is used > for the TE Application. > what are Type 9 and Type 11 LSAs used for??? > Regards > Amit > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 2 10:34:39 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21928 for ; Fri, 2 Aug 2002 10:34:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006B9D3A@cherry.ease.lsoft.com>; Fri, 2 Aug 2002 10:35:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 165620 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 2 Aug 2002 10:35:44 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 2 Aug 2002 10:35:44 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Aug 2002 10:35:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 2 Aug 2002 10:38:04 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: usage of OSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi folks, This is from the ISIS mailing list, and was posted by Danny McPherson "I actually did a survey a while back and found that of the largest 10 domestic ISPs ~7 used IS-IS, the remaining 3 used OSPF. Of the ~70 networks I had knowledge of (either as a result of direct involvement, directed queries or publicly solicited responses) ~15 used IS-IS while the rest used OSPF (minus a few stragglers using EIGRP or the like). [Disclaimer: "Largest 10" is purely in my mind, I did no customer counts, IP counts or the like in an attempt to qualify my employment of the phrase.] It's quite reasonable to assume that the number of IS-IS ISP networks decreases substantially thereafter. And I'm guessing there are very very few enterprises that employ IS-IS as their IP IGP -- for obvious reasons." So here are some different statistics again, Thanks, Vishwas -----Original Message----- From: Russ White [mailto:ruwhite@CISCO.COM] Sent: Friday, August 02, 2002 5:27 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: usage of OSPF My experience differs somewhat.... In the US, I see mostly EIGRP in the enterprise market (maybe 80%), with some OSPF, and no IS-IS. On the SP side, I see about equal parts of IS-IS and OSPF. In Europe, I mostly see about equal divides between the three in the enterprise market, with SP's mostly on the IS-IS side, with some OSPF. But I'm certain you'll hear different things from different people, depending on which customers they've worked with. :-) Russ On Fri, 2 Aug 2002, Tom Petch wrote: > My experience across some hundred of more medium and large > enterprises, mostly in Europe, is, in order of usage, > > 1 RIPv1 > 2 OSPF > 3 RIPv2 > 4 Cisco proprietary > > ISIS nowhere. > Given some enterprises have more than one IGP, OSPF is about 30%. > > For me, this ongoing use of mature and familiar technology parallels > the use of Ethernetv2 to underpin ever larger and faster networks :-) > > For SNMP, I suggest you try an SNMP mailing list and I'll give you my > ha'pen'orth there. > > Tom Petch, Network Consultant > nwnetworks@dial.pipex.com > > -----Original Message----- > From: Beatriz Silva > To: OSPF@DISCUSS.MICROSOFT.COM > Date: 01 August 2002 16:48 > Subject: usage of OSPF > > > >Hello everybody ! > > > >Does anybody know what is the usage of OSPF protocol as compared to > the other routing protocols ? Is it really the most used ? What is the > percentage of networks that use OSPF ? > > > >I have the same question for SNMP management protocol too. (if > somebody happens to know) > > > >Thanks, > >Beatriz > > > > > >-- > >__________________________________________________________ > >Sign-up for your own FREE Personalized E-mail at Mail.com > >http://www.mail.com/?sr=signup > > > >Get 4 DVDs for $.49 cents! plus shipping & processing. Click to join. > >http://adfarm.mediaplex.com/ad/ck/990-1736-3566-59 > __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 2 11:54:44 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24559 for ; Fri, 2 Aug 2002 11:54:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.006B9EDA@cherry.ease.lsoft.com>; Fri, 2 Aug 2002 11:55:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 166012 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 2 Aug 2002 11:55:53 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 2 Aug 2002 11:55:52 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 47C67473CCE; Fri, 2 Aug 2002 08:55:51 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200207291542.LAA22256@erosen-u10.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D4AAB0E.7050300@redback.com> Date: Fri, 2 Aug 2002 11:53:50 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on OSPF PC/CE Drafts Comments: To: erosen@cisco.com Comments: cc: Provider Provisioned VPN Discussion List To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Eric - sorry for the delay in responding. Eric Rosen wrote: > Acee> Here are my comments on draft-rosen-vpns-ospf-bgp-mpls-04.txt and > Acee> draft-rosen-ppvpn-ospf2547-area0-00.txt: > > Acee> General: > > Acee> - It would seem that these two drafts could be combined since > Acee> draft-rosen-ppvpn-ospf2547-area0-00.txt only contains a couple > Acee> paragraphs of unique information. This would also avoid all > Acee> references in draft-rosen-vpns-ospf-bgp-mpls-04.txt > > They were separated into two drafts since the "couple of paragraphs of > unique information" in the area 0 draft include a new use of one of the LSA > options bits, and hence needs discussion by the OSPF WG. The other draft > does not require any new use of any OSPF protocol field. True. There are a number of draft contending for this OSPF option bit (I think this only one getting traction as far as implementation and deployment). However, I think that draft-route-vpns-ospf-bgp-mpls-04.txt should be discussed by the OSPF WG as well since it has impacts how OSPF does route redistribution. > > Acee> - The PE router doesn't really have to be an ABR. It is already > Acee> "faking" that VPN redistributed routes are inter-area routes. It > Acee> can also set its router LSA B bit accordingly. Oh well, maybe this > Acee> could be considered an implementation detail. > > Would it be more accurate to say "the PE router acts, to the CE router, as > an ABR?" That's good. Or you might say "The PE router presents itself to the CE router as an ABR by setting the B bit in it's router LSA." > > Acee> draft-rosen-vpns-ospf-bgp-mpls-04.txt: > > Acee> - Page 4, second list item. Since the VPN routes are advertised as > Acee> type 3 LSAs, I believe you should say "inter-area routes" rather > Acee> than "intra-network routes". > > Intra-network routes is the requirement, inter-area routes is the solution. > > Acee> - Page 11 - Why is auto-configuration a "MUST"? > > I don't see where it says that. This text could be interpreted in multiple ways. 4.2.3.2. Creating Sham Links Sham links may be manually configured, or they may be auto- configured. Each VRF that is associated with a PE-CE link on which OSPF is running MUST be configurable as to whether auto-configuration of sham links to/from that VRF is allowed. The default MUST be "manual configuration". > > Acee> - Page 12, last paragraph - Don't you mean that the PE should not > Acee> install the route into the VRF routing table (since there should > Acee> already be a BGP route). This will insure it doesn't replace the > Acee> route and that it is not redistributed. > > The route has to be in the VRF or won't be used, but it should not be > redistributed via BGP. Ok - I agree that what is important is preventing redistribution of the route back into BGP. However,the VRF should already have an iBGP route (if it doesn't, how can you be sure the VPN backbone has the route?). New comment: Discuss sham link MTU including the fact that the "Interface MTU" field in Database Description packets should be set to 0 similar to virtual links. Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 2 15:19:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02426 for ; Fri, 2 Aug 2002 15:19:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.006BA3DD@cherry.ease.lsoft.com>; Fri, 2 Aug 2002 15:20:19 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 166637 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 2 Aug 2002 15:20:19 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 2 Aug 2002 15:10:19 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 84536473CC7; Fri, 2 Aug 2002 12:10:18 -0700 (PDT) Message-ID: <20020802191018.84536473CC7@prattle.redback.com> Date: Fri, 2 Aug 2002 12:10:18 -0700 Reply-To: Mailing List Sender: Mailing List From: Naiming Shen Subject: Re: Comments on OSPF PC/CE Drafts To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Mail from Acee Lindem dated Fri, 02 Aug 2002 11:53:50 EDT <3D4AAB0E.7050300@redback.com> Precedence: list Hi Acee, there could be a 'corner' case where multiple remove PEs in the same VPN announce the same routes. the local PE/vpn suppose to pick the one which has sham links with, since those are the intra-area routes. but bgp does not have this ospf internal info and it may install something towards diff PE(s). does this matter in real operation? probably not. thanks. ] > ] > Acee> - Page 12, last paragraph - Don't you mean that the PE should not ] > Acee> install the route into the VRF routing table (since there shou ld ] > Acee> already be a BGP route). This will insure it doesn't replace the ] > Acee> route and that it is not redistributed. ] > ] > The route has to be in the VRF or won't be used, but it should not be ] > redistributed via BGP. ] ] ] Ok - I agree that what is important is preventing redistribution of the route back ] into BGP. However,the VRF should already have an iBGP route (if it doesn't, how ] can you be sure the VPN backbone has the route?). - Naiming From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 2 17:44:48 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08181 for ; Fri, 2 Aug 2002 17:44:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.006BA840@cherry.ease.lsoft.com>; Fri, 2 Aug 2002 17:45:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 167114 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 2 Aug 2002 17:45:56 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 2 Aug 2002 17:45:56 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17akF9-000FeU-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 02 Aug 2002 14:45:55 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <1742227633.20020802144425@psg.com> Date: Fri, 2 Aug 2002 14:44:25 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Slides at IETF54 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Folks- Those of you who showed slides in Yokohama, please submit them to minutes@ietf.org as soon as you can. Thank you. -- Alex From owner-ospf@DISCUSS.MICROSOFT.COM Sat Aug 3 19:09:07 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12224 for ; Sat, 3 Aug 2002 19:09:07 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.006BC1A6@cherry.ease.lsoft.com>; Sat, 3 Aug 2002 19:10:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 169942 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 3 Aug 2002 19:10:03 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 3 Aug 2002 19:00:03 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.006BC244@cherry.ease.lsoft.com>; Sat, 3 Aug 2002 19:00:03 -0400 Message-ID: Date: Sat, 3 Aug 2002 19:00:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Chaoping Wu Subject: Re: Congestion Avoidance & Control for OSPF Networks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi all, I'm not sure of the status of this I-D after the recent IETF meeting. Hopefully it is stil on track. I do have some specific and general comments that I'd like to share with you and have some discussions if not done before. General Comments ================ 1. Outbound Congestion Notificatoin This I-D suggests this notification not required in some way (section 4.2.1). But I think this notification is important and may complement the whole mechanism in the following way: A. Identifying source of congestion. In OSPF network types NBMA, P-TO-P, P-T--MP, Virtual links, OSPF packets may go through some kind of transit networks which may be congested for some reason. In this scenario, the receiving OSPF router can tell if the originating router experiences congestion or not. B. Faster notification is possible if outbound congestion notification is performed. It should be sent immediatly once detected. 2. State of Congestion This I-D specifies 3 states MUST be defined (section 4.2.1) but it has not specified a consistent way of defining the states. In networks mixed with different vendor routers, if a "high congestion state" in one router is equivalent to "low congestion state" of its neighboring router that is made by a different vendor using different definitions of congestion state, the resulted congestion measures in this network may not be as desired, isn't it? 3. Adding A Congestion Prediction Concept What about incorparating a congestion prediction concept into this I-D? Preventive congestion measures should be very used for netwrok administrators to get alerted about when they should start consider optimize their networks. Potential congestion may be simply another congestion state. All comments on the above are appreciated. I may post some specific comments about the I-D when I have more time. Regards, Chaoping Wu From owner-ospf@DISCUSS.MICROSOFT.COM Sun Aug 4 19:52:31 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15777 for ; Sun, 4 Aug 2002 19:52:30 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.006BD7CA@cherry.ease.lsoft.com>; 4 Aug 2002 19:53:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 171930 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 4 Aug 2002 19:53:40 -0400 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 4 Aug 2002 19:53:39 -0400 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g74NfIv0019400 for ; Sun, 4 Aug 2002 18:53:39 -0500 (CDT) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (6.5.019) id 3CE519BE024CDC32; Sun, 4 Aug 2002 19:53:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Congestion Avoidance & Control for OSPF Networks Thread-Index: AcI7Qut5Vrh223JmTX+1LNULxILyagAzXA/A Message-ID: <28F05913385EAC43AF019413F674A0170167B112@OCCLUST04EVS1.ugd.att.com> Date: Sun, 4 Aug 2002 19:53:38 -0400 Reply-To: Mailing List Sender: Mailing List From: "Ash, Gerald R (Jerry), ALASO" Subject: Re: Congestion Avoidance & Control for OSPF Networks Comments: To: Chaoping Wu To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA15777 Dear Chaoping Wu, Thank you very much for your comments, please see responses below. Regards, Jerry Ash > I'm not sure of the status of this I-D after the recent IETF meeting. > Hopefully it is still on track. I do have some specific and general comments > that I'd like to share with you and have some discussions if not done > before. The draft wasn't discussed at Yokohama, however, we hope to advance the draft on the list, and discuss it further at IETF-55 in Atlanta. > General Comments > ================ > 1. Outbound Congestion Notification > This I-D suggests this notification not required in some way > (section 4.2.1). But I think this notification is important and may > complement the whole mechanism in the following way: > A. Identifying source of congestion. > In OSPF network types NBMA, P-TO-P, P-T--MP, Virtual links, OSPF > packets may go through some kind of transit networks which may > be congested for some reason. In this scenario, the receiving > OSPF router can tell if the originating router experiences > congestion or not. > > B. Faster notification is possible if outbound congestion notification > is performed. It should be sent immediately once detected. I agree with your observations, the draft does call for immediate notification of congestion, once detected. > 2. State of Congestion > This I-D specifies 3 states MUST be defined (section 4.2.1) but it > has not specified a consistent way of defining the states. > > In networks mixed with different vendor routers, if a "high congestion > state" in one router is equivalent to "low congestion state" of its > neighboring router that is made by a different vendor using different > definitions of congestion state, the resulted congestion measures in > this network may not be as desired, isn't it? You point is well taken, and some consistency in the definition of congestion state is needed, further work on this is warranted. > 3. Adding A Congestion Prediction Concept > What about incorporating a congestion prediction concept into this > I-D? Preventive congestion measures should be very used for network > administrators to get alerted about when they should start consider > optimize their networks. Potential congestion may be simply another > congestion state. Sounds like a good capability, if feasible, but how does one do (reliable) congestion prediction? Thanks again for your comments. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Aug 5 00:47:44 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21928 for ; Mon, 5 Aug 2002 00:47:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006BDD35@cherry.ease.lsoft.com>; Mon, 5 Aug 2002 0:48:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 172695 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 5 Aug 2002 00:48:53 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 5 Aug 2002 00:48:52 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Aug 2002 00:48:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 5 Aug 2002 00:51:18 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Congestion Avoidance & Control for OSPF Networks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Chaoping, I would like to add to what Jerry has already said. > 1. Outbound Congestion Notificatoin > This I-D suggests this notification not required in some way > (section 4.2.1). But I think this notification is important and may > complement the whole mechanism in the following way: > A. Identifying source of congestion. > In OSPF network types NBMA, P-TO-P, P-T--MP, Virtual links, OSPF > packets may go through some kind of transit networks which may > be congested for some reason. In this scenario, the receiving > OSPF router can tell if the originating router experiences > congestion or not. > > B. Faster notification is possible if outbound congestion notification > is performed. It should be sent immediatly once detected. Though what you say is true, if I have understood you correctly, we have tried to avoid signalling both for our own congestion as well as congestion at the other end(which is also harder to predict). We have gone with the assumption that if the congestion occurs at the other end, then the congested router will notify abt it. This fact has been put forward in Section 4.2.1, maybe we can clarify that further. > 2. State of Congestion > This I-D specifies 3 states MUST be defined (section 4.2.1) but it > has not specified a consistent way of defining the states. > > In networks mixed with different vendor routers, if a "high congestion > state" in one router is equivalent to "low congestion state" of its > neighboring router that is made by a different vendor using different > definitions of congestion state, the resulted congestion measures in > this network may not be as desired, isn't it? Though what you say would be desired, however, there can be no perfect way to exactly classify it, on different routers/vendors/etc. We have however given some suggestions in the beginning of the section, we can try to make the classifications more precise. > 3. Adding A Congestion Prediction Concept > What about incorparating a congestion prediction concept into this > I-D? Preventive congestion measures should be very used for netwrok > administrators to get alerted about when they should start consider > optimize their networks. Potential congestion may be simply another > congestion state. As the actual signalling of congestion and measure of levels of congestion has been left to the implementation, an implementation could always signal low congestion, when it can predict it is going into congestion. The exact prediction methods are left to the local router itself, and as Jerry pointed out it may be hard to predict it. What we have tried to define is a method by which a local router can signal congestion(levels of them), and how the neighboring router SHOULD react on getting such a congestion notification. Besides that we have put in minimal changes required for any implementation to support such a functionality. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Mon Aug 5 05:24:41 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05791 for ; Mon, 5 Aug 2002 05:24:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.006BE2D6@cherry.ease.lsoft.com>; Mon, 5 Aug 2002 5:25:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 173373 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 5 Aug 2002 05:25:51 -0400 Received: from 66.218.78.89 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 5 Aug 2002 05:25:51 -0400 Received: from [203.200.20.226] by web40310.mail.yahoo.com via HTTP; Mon, 05 Aug 2002 02:25:50 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020805092550.2263.qmail@web40310.mail.yahoo.com> Date: Mon, 5 Aug 2002 02:25:50 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3D4A8F5A.90000@redback.com> Precedence: list Hi Acee, I have a doubt which goes as under:- Can the period for the hitless restart period greater than the MAX age??? I think it should not be as during the SPF calculation that will cause the MAX age LSAs not to be considered causing the route table entries to change. What do you say?? Regards Amit __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Mon Aug 5 09:02:15 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11118 for ; Mon, 5 Aug 2002 09:02:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.006BE5EA@cherry.ease.lsoft.com>; Mon, 5 Aug 2002 9:03:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 174271 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 5 Aug 2002 09:03:26 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 5 Aug 2002 09:03:26 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id C29B61DCC6D for ; Mon, 5 Aug 2002 06:03:24 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20020805092550.2263.qmail@web40310.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D4E76FE.5080608@redback.com> Date: Mon, 5 Aug 2002 09:00:46 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Amit Srivastava wrote: > Hi Acee, > I have a doubt which goes as under:- > Can the period for the hitless restart period > greater than the MAX age??? > I think it should not be > as during the SPF calculation that will cause the MAX > age LSAs not to be considered causing the route table > entries to change. What do you say?? Hi Amit, I agree. It will not work if the grace period exceeds MaxAge since the restarting router's pre-restart LSAs will be purged from the OSPF routing domain. Thanks, > Regards > Amit > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Aug 5 09:48:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12960 for ; Mon, 5 Aug 2002 09:48:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.006BE6B0@cherry.ease.lsoft.com>; Mon, 5 Aug 2002 9:49:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 174557 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 5 Aug 2002 09:49:37 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 5 Aug 2002 09:49:36 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 306F34BA216 for ; Mon, 5 Aug 2002 06:49:35 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20020802191018.84536473CC7@prattle.redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D4E81D0.8090400@redback.com> Date: Mon, 5 Aug 2002 09:46:56 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on OSPF PC/CE Drafts To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Naiming Shen wrote: > Hi Acee, > > there could be a 'corner' case where multiple remove PEs in the same > VPN announce the same routes. the local PE/vpn suppose to pick the one > which has sham links with, since those are the intra-area routes. but bgp > does not have this ospf internal info and it may install something towards > diff PE(s). does this matter in real operation? probably not. Naiming, I've thought about this and the situation you mention certainly is possible with multiple PEs connecting the same set of backdoor connected CE sites. I was hoping for more commonality with the vanilla OSPF PE/CE scenario but that may not possible. Let's discuss offline - this will require at least one new mechanism. Thanks, Acee > > thanks. > > ] > > ] > Acee> - Page 12, last paragraph - Don't you mean that the PE should not > ] > Acee> install the route into the VRF routing table (since there shou > ld > ] > Acee> already be a BGP route). This will insure it doesn't replace the > ] > Acee> route and that it is not redistributed. > ] > > ] > The route has to be in the VRF or won't be used, but it should not be > ] > redistributed via BGP. > ] > ] > ] Ok - I agree that what is important is preventing redistribution of the route back > ] into BGP. However,the VRF should already have an iBGP route (if it doesn't, how > ] can you be sure the VPN backbone has the route?). > > - Naiming > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Aug 5 12:55:11 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22035 for ; Mon, 5 Aug 2002 12:55:11 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.006BE9FC@cherry.ease.lsoft.com>; Mon, 5 Aug 2002 12:56:20 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 175698 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 5 Aug 2002 12:56:19 -0400 Received: from 216.15.8.227 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 5 Aug 2002 12:56:19 -0400 Received: from jupiter.polarisnetworks.com ([192.168.0.19]) by mercury.polarisnetworks.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Mon, 5 Aug 2002 09:51:49 -0700 Received: by JUPITER with Internet Mail Service (5.5.2650.21) id <32SQGGJK>; Mon, 5 Aug 2002 09:53:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 5 Aug 2002 09:53:39 -0700 Reply-To: Mailing List Sender: Mailing List From: "Cheng, Dean" Subject: Hello To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Jerry, Got your phone message and sorry I could'nt responde earlier since I was at the OIF last week. Yes I'm also interested to discuss with you on the issues that you cited. Perhaps you can give me a call after your trip ? Regards, Dean From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 6 01:40:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16808 for ; Tue, 6 Aug 2002 01:40:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.006C04F5@cherry.ease.lsoft.com>; Tue, 6 Aug 2002 1:41:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 177477 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 Aug 2002 01:41:15 -0400 Received: from 134.32.26.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 6 Aug 2002 01:31:15 -0400 Received: from conversion-daemon.eurmta01.london.eur.slb.com by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) id <0H0E00101PO5N3@eurmta01.london.eur.slb.com> for ospf@discuss.microsoft.com; Tue, 06 Aug 2002 05:31:10 +0000 (GMT) Received: from ntsrv1-omd.dubai.omnes.slb.com (ntsrv1-omd.dubai.omnes.slb.com [163.183.2.211]) by eurmta01.london.eur.slb.com (iPlanet Messaging Server 5.2 HotFix 0.3 (built May 13 2002)) with ESMTP id <0H0E00LM4PZXNH@eurmta01.london.eur.slb.com> for ospf@discuss.microsoft.com; Tue, 06 Aug 2002 05:31:10 +0000 (GMT) Received: from SCHLUMBE-W88QH4.abu-dhabi.sns.slb.com ([163.183.47.75]) by ntsrv1-omd.dubai.omnes.slb.com (Post.Office MTA v3.5.3 release 223 ID# 0-58147U25000L25000S0V35) with ESMTP id com for ; Tue, 06 Aug 2002 09:31:07 +0400 X-Sender: hendaz@163.183.2.211 MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Message-ID: <5.1.1.1.2.20020806093035.00b0e738@163.183.2.211> Date: Tue, 6 Aug 2002 09:31:54 +0400 Reply-To: Mailing List Sender: Mailing List From: Mohammed Hendaz Subject: Totally Stubby & NSSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Hi, Is the "totally stubby" type a Cisco proprietary or a standard implemented by other vendors (Nortel, 3Com, etc)? I've not seen it mentioned in RFC 2328. Also the NSSA type, I've seen the standard track RFC 1587, but is it implemented by routers vendors other than Cisco? I appreciate your feed back. Regards, Mohammed. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 6 01:54:15 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16983 for ; Tue, 6 Aug 2002 01:54:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006C044F@cherry.ease.lsoft.com>; Tue, 6 Aug 2002 1:55:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 177540 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 Aug 2002 01:55:27 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 6 Aug 2002 01:55:27 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 87D7D2CDB53 for ; Mon, 5 Aug 2002 22:55:25 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <5.1.1.1.2.20020806093035.00b0e738@163.183.2.211> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D4F6425.4060905@redback.com> Date: Tue, 6 Aug 2002 01:52:37 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Totally Stubby & NSSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mohammed Hendaz wrote: > Hi, > > Is the "totally stubby" type a Cisco proprietary or a standard > implemented by other vendors (Nortel, 3Com, etc)? I've not > seen it mentioned in RFC 2328. Mohammed, I believe Cisco coined the term "totally stubby" but most router vendors also support the "no-summary" option for stub areas. > > Also the NSSA type, I've seen the standard track RFC 1587, but > is it implemented by routers vendors other than Cisco? I believe many router vendors also support NSSA areas. > > I appreciate your feed back. > > Regards, > Mohammed. > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 6 02:01:49 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19612 for ; Tue, 6 Aug 2002 02:01:49 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006C0453@cherry.ease.lsoft.com>; Tue, 6 Aug 2002 2:03:00 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 177580 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 Aug 2002 02:03:00 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 6 Aug 2002 02:03:00 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 02:02:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 6 Aug 2002 02:05:09 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Totally Stubby & NSSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Mohammed, "Totally stubby" is implemented by Juniper/other vendors too. http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-05.txt does talk about ospfAreaSummary object in the area table, which controls the import of summary LSA's into Stub and NSSA areas. When no summaries are imported into stub areas it becomes "Totally stubby". The NSSA RFC1587 will soon be updated by this http://www.ietf.org/internet-drafts/draft-ietf-ospf-nssa-update-11.txt . NSSA has been implemented by a lot of other vendors too, however a lot of them still follow RFC1587. Thanks, Vishwas -----Original Message----- From: Mohammed Hendaz [mailto:hendaz@ABU-DHABI.SNS.SLB.COM] Sent: Tuesday, August 06, 2002 11:02 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Totally Stubby & NSSA Hi, Is the "totally stubby" type a Cisco proprietary or a standard implemented by other vendors (Nortel, 3Com, etc)? I've not seen it mentioned in RFC 2328. Also the NSSA type, I've seen the standard track RFC 1587, but is it implemented by routers vendors other than Cisco? I appreciate your feed back. Regards, Mohammed. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 6 02:06:03 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25176 for ; Tue, 6 Aug 2002 02:06:03 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.006C065A@cherry.ease.lsoft.com>; Tue, 6 Aug 2002 2:07:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 177603 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 Aug 2002 02:07:13 -0400 Received: from 66.218.78.85 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 6 Aug 2002 02:07:13 -0400 Received: from [203.200.20.226] by web40306.mail.yahoo.com via HTTP; Mon, 05 Aug 2002 23:07:12 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020806060712.76574.qmail@web40306.mail.yahoo.com> Date: Mon, 5 Aug 2002 23:07:12 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: Totally Stubby & NSSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3D4F6425.4060905@redback.com> Precedence: list Hi All, I want to know the application which uses type 11 opaque LSA.If anyone can help. Regards Amit __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 6 02:07:51 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26256 for ; Tue, 6 Aug 2002 02:07:51 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006C0497@cherry.ease.lsoft.com>; Tue, 6 Aug 2002 2:09:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 177620 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 Aug 2002 02:09:03 -0400 Received: from 66.218.78.88 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 6 Aug 2002 02:09:03 -0400 Received: from [203.200.20.226] by web40309.mail.yahoo.com via HTTP; Mon, 05 Aug 2002 23:09:02 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020806060902.82975.qmail@web40309.mail.yahoo.com> Date: Mon, 5 Aug 2002 23:09:02 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Type 11 Opaque LSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi All, I want to know the application which uses type 11 LSAs. If anyone could help?? Regards Amit __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 6 03:18:43 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27820 for ; Tue, 6 Aug 2002 03:18:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.006C0553@cherry.ease.lsoft.com>; Tue, 6 Aug 2002 3:19:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 177855 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 Aug 2002 03:19:55 -0400 Received: from 64.4.15.233 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 6 Aug 2002 03:19:55 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Aug 2002 00:19:54 -0700 Received: from 203.196.146.243 by lw10fd.law10.hotmail.msn.com with HTTP; Tue, 06 Aug 2002 07:19:54 GMT X-Originating-IP: [203.196.146.243] Mime-Version: 1.0 Content-Type: text/html X-OriginalArrivalTime: 06 Aug 2002 07:19:54.0792 (UTC) FILETIME=[A98DE280:01C23D19] Message-ID: Date: Tue, 6 Aug 2002 07:19:54 +0000 Reply-To: Mailing List Sender: Mailing List From: praveendas e Subject: Re: Type 11 Opaque LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list

Hai Amit

Hi All,

I want to know the application which uses type 11
LSAs. If anyone could help??
Regards

Amit

The type 11 and type 10 LSA's are used in Dynamic Hostname Exchange Mechanism           for OSPF and You can refer the following Link for more info

draft-venkata-ospf-dynamic-hostname-00.txt         

Hope thhis help you

rgds

Praveendas

 

Join the world’s largest e-mail service with MSN Hotmail. Click Here
From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 6 06:59:57 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03528 for ; Tue, 6 Aug 2002 06:59:57 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006C0742@cherry.ease.lsoft.com>; Tue, 6 Aug 2002 7:01:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 178560 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 Aug 2002 07:01:06 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 6 Aug 2002 07:01:06 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Aug 2002 07:01:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 6 Aug 2002 07:03:17 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Type 11 Opaque LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Amit, The draft on path computation server discovery uses type-11 LSA's too. http://www.ietf.org/internet-drafts/draft-vasseur-mpls-ospf-pcsd-discovery-0 0.txt This draft was presented in Yokohama OSPF-WG meeting. A simple way to find answers, could be to look thru the mail archives located at http://discuss.microsoft.com/archives/ospf.html and the charter at http://www.ietf.org/html.charters/ospf-charter.html . You can also have a look at the draft index http://www.ietf.org/ids.by.wg/none.html for drafts which are individual submissions. Thanks, Vishwas -----Original Message----- From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM] Sent: Tuesday, August 06, 2002 11:39 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Type 11 Opaque LSA Hi All, I want to know the application which uses type 11 LSAs. If anyone could help?? Regards Amit From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 6 08:13:55 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07015 for ; Tue, 6 Aug 2002 08:13:55 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006C08F0@cherry.ease.lsoft.com>; Tue, 6 Aug 2002 8:15:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 178725 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 Aug 2002 08:15:06 -0400 Received: from 152.163.225.106 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 6 Aug 2002 08:15:06 -0400 Received: from Jjsyed@aol.com by imo-r10.mx.aol.com (mail_out_v33.5.) id c.f4.1f91ab5b (5708); Tue, 6 Aug 2002 08:15:03 -0400 (EDT) Received: from aol.com (mow-m20.webmail.aol.com [64.12.180.136]) by air-id04.mx.aol.com (v86_r1.16) with ESMTP id MAILINID41-0806081503; Tue, 06 Aug 2002 08:15:03 -0400 X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <1A3B3137.475D3B8C.0004D071@aol.com> Date: Tue, 6 Aug 2002 08:15:59 -0400 Reply-To: Mailing List Sender: Mailing List From: Javed Syed Subject: Re: Totally Stubby & NSSA Comments: To: OSPF@DISCUSS.MICROSOFT.COM|Mailing To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit cisco proprietry javed From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 6 15:43:45 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25985 for ; Tue, 6 Aug 2002 15:43:45 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.006C16CC@cherry.ease.lsoft.com>; Tue, 6 Aug 2002 15:44:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 77710 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 Aug 2002 15:44:57 -0400 Received: from 216.136.225.46 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 6 Aug 2002 15:44:57 -0400 Received: from [64.95.122.60] by web20001.mail.yahoo.com via HTTP; Tue, 06 Aug 2002 12:44:55 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020806194455.11477.qmail@web20001.mail.yahoo.com> Date: Tue, 6 Aug 2002 12:44:55 -0700 Reply-To: Mailing List Sender: Mailing List From: somnath mani Subject: Hub abd spoke and MPLS-BGP-VPN To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, In a hub abd spoke topology implemented using BGP-MPLS-VPN, a hub PE is talking OSPF with a HUB CE using OSPF. When the hub PE receives route updates from spoke PEs ( via BGP), it generates summary/ASE LSAs and sends them across to the CE which forwards them to the hub PE back in to a different vrf, from where on these routes are exported back to the spoke PEs. The draft says that when we genereate summary lsas we set the DN bit ( if the pe-ce link is in area 0).similarly for ASEs we set the vpn route tag. this is to prevent looping. In the above scenario, when the CE forwards the lsas back to PE in a different vrf, we see that the DN bit is set and we do not install the route. Am I missing something in the draft ? how do we make the DN bit vrf aware ? Thanks Somnath __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 6 21:00:43 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05911 for ; Tue, 6 Aug 2002 21:00:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.006C1D5C@cherry.ease.lsoft.com>; Tue, 6 Aug 2002 21:01:54 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 78300 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 6 Aug 2002 21:01:53 -0400 Received: from 159.226.39.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 6 Aug 2002 20:51:53 -0400 Received: (qmail 15058 invoked from network); 7 Aug 2002 00:28:39 -0000 Received: from unknown (HELO jhy) (159.226.39.103) by 159.226.39.4 with SMTP; 7 Aug 2002 00:28:39 -0000 References: <20020806060902.82975.qmail@web40309.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <004c01c23dac$ce4bab50$6727e29f@jhy> Date: Wed, 7 Aug 2002 08:53:12 +0800 Reply-To: Mailing List Sender: Mailing List From: angela Subject: About Data Base Description packet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id VAA05911 Hi All I have one question about interfae MTU processing in DDP exchange. In my mind, I think any MTU mismatch between two neighbor can not exchange normally. So I think any router(OSPFv2 or OSPFv3) should not process the DDP with lower or higher MTU set. If anyone could help? Is it right?? Best Regards, angela Network Testing Lab Institute of Computing Technology Chinese Academy of Sciences NO. 6, South Road, Kexueyuan, Zhongguancun P.O.Box 2704 Beijing 100080, P.R. China Tel: +86-10-82628446,62565533 ext..9213(office) E-mail: jhyang@ict.ac.cn From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 7 10:34:21 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20485 for ; Wed, 7 Aug 2002 10:34:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006C2AB4@cherry.ease.lsoft.com>; Wed, 7 Aug 2002 10:01:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 79278 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 7 Aug 2002 10:01:26 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 7 Aug 2002 10:01:16 -0400 Received: from cisco.com (dhcp-bru-peg1-vl18-144-254-2-59.cisco.com [144.254.2.59]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g77Bri719628 for ; Wed, 7 Aug 2002 13:53:44 +0200 (CEST) X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <20020806194455.11477.qmail@web20001.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D510A48.4B5BAE88@cisco.com> Date: Wed, 7 Aug 2002 13:53:44 +0200 Reply-To: Mailing List Sender: Mailing List From: Peter Psenak Subject: Re: Hub abd spoke and MPLS-BGP-VPN To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Somnath, somnath mani wrote: > > Hi, > In a hub abd spoke topology implemented using > BGP-MPLS-VPN, a hub PE is talking OSPF with a HUB CE > using OSPF. When the hub PE receives route updates > from spoke PEs ( via BGP), it generates summary/ASE > LSAs and sends them across to the CE which forwards > them to the hub PE back in to a different vrf, from > where on these routes are exported back to the spoke > PEs. > > The draft says that when we genereate summary lsas we > set the DN bit ( if the pe-ce link is in area > 0).similarly for ASEs we set the vpn route tag. this > is to prevent looping. > > In the above scenario, when the CE forwards the lsas > back to PE in a different vrf, we see that the DN bit why would a CE router forward LSAs from one vrf to another one? > is set and we do not install the route. Am I missing > something in the draft ? how do we make the DN bit vrf > aware ? DN-bit is not VRF aware. DN-bit signals that prefix has been imported from the VPN backbone. thanks, Peter > > Thanks > Somnath > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 7 10:34:22 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20498 for ; Wed, 7 Aug 2002 10:34:21 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.006C2D02@cherry.ease.lsoft.com>; Wed, 7 Aug 2002 10:24:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 79393 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 7 Aug 2002 10:24:47 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 7 Aug 2002 10:24:47 -0400 Received: from ASMIRNOVW2K (dhcp-bru-peg2-vl26-144-254-9-171.cisco.com [144.254.9.171]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g77EOk722613 for ; Wed, 7 Aug 2002 16:24:46 +0200 (CEST) References: <20020806194455.11477.qmail@web20001.mail.yahoo.com> <3D510A48.4B5BAE88@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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: <041b01c23e1e$212eee60$ab09fe90@cisco.com> Date: Wed, 7 Aug 2002 16:24:24 +0200 Reply-To: Mailing List Sender: Mailing List From: Anton Smirnov Organization: Cisco Systems, Inc. Subject: Re: Hub abd spoke and MPLS-BGP-VPN To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, leaking from one VRF to another on one PE router is frequent design if end-customer wants central processing for some services. Say, end-customer has firewall on his central site and wants to ensure that all traffic between all his sites and other VRFs/Internet/whatever-else goes thru the central firewall (it's good from maintainability point of view and stateful inspection). OK, in case of firewall it is unlikely to have 1 OSPF process on both sides, but I'm sure other similar setups can (and will be) invented. DN bit does not support this type of 'automatic' discovery and manipulation. I think implementation may provide means to manually configure selective DN bit suppression, if deemed needed. Anton ----- Original Message ----- From: "Peter Psenak" To: Sent: Wednesday, August 07, 2002 13:53 Subject: Re: [OSPF] Hub abd spoke and MPLS-BGP-VPN > Somnath, > > somnath mani wrote: > > > > Hi, > > In a hub abd spoke topology implemented using > > BGP-MPLS-VPN, a hub PE is talking OSPF with a HUB CE > > using OSPF. When the hub PE receives route updates > > from spoke PEs ( via BGP), it generates summary/ASE > > LSAs and sends them across to the CE which forwards > > them to the hub PE back in to a different vrf, from > > where on these routes are exported back to the spoke > > PEs. > > > > The draft says that when we genereate summary lsas we > > set the DN bit ( if the pe-ce link is in area > > 0).similarly for ASEs we set the vpn route tag. this > > is to prevent looping. > > > > In the above scenario, when the CE forwards the lsas > > back to PE in a different vrf, we see that the DN bit > > why would a CE router forward LSAs from one vrf to another one? > > > is set and we do not install the route. Am I missing > > something in the draft ? how do we make the DN bit vrf > > aware ? > > DN-bit is not VRF aware. DN-bit signals that prefix has been imported > from the VPN backbone. > > thanks, > Peter > > > > > Thanks > > Somnath > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Health - Feel better, live better > > http://health.yahoo.com > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 7 10:34:23 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20511 for ; Wed, 7 Aug 2002 10:34:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006C2D95@cherry.ease.lsoft.com>; Wed, 7 Aug 2002 10:30:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 79466 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 7 Aug 2002 10:30:24 -0400 Received: from 64.4.15.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 7 Aug 2002 10:30:24 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Aug 2002 23:00:31 -0700 Received: from 203.196.146.243 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 07 Aug 2002 06:00:30 GMT X-Originating-IP: [203.196.146.243] Mime-Version: 1.0 Content-Type: text/html X-OriginalArrivalTime: 07 Aug 2002 06:00:31.0187 (UTC) FILETIME=[BCA33230:01C23DD7] Message-ID: Date: Wed, 7 Aug 2002 06:00:30 +0000 Reply-To: Mailing List Sender: Mailing List From: praveendas e Subject: Re: About Data Base Description packet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list



Hai angela

Angela wrote:

Hi All
I have one question about interfae MTU processing in DDP exchange.
In my mind, I think any MTU mismatch between two neighbor can not exchange normally. So I think any router(OSPFv2 or OSPFv3) should not process the DDP with lower or higher MTU set. If anyone could help? Is it right??
 

 

In section A.3.3 The Database Description packet

of RFC 2328 it is given the description of

interface MTU and it says that

"Interface MTU

The size in bytes of the largest IP datagram that can be sent

out the associated interface, without fragmentation. "

And this interface MTU is initially configured as the fixed default value while configuring a new router interface (According to the network type Ethernet/Point-to-point or what ever ).

Suppose you configure one router interface having MTU 1500Bytes and another router with interafce MTU 2000Bytes whenever receiving a DD packet, OSPF is checking for interface MTU. If the DD packet MTU is Less than the interface MTU then the DD packet will accept otherwise the packet will reject saying that MTU mismatch and dropping the packet.

Hope this will help you

Regards

Praveendas


Join the world’s largest e-mail service with MSN Hotmail. Click Here
From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 7 11:17:39 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22806 for ; Wed, 7 Aug 2002 11:17:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.006C3032@cherry.ease.lsoft.com>; Wed, 7 Aug 2002 11:18:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 79807 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 7 Aug 2002 11:18:47 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 7 Aug 2002 11:18:47 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 43C80262802 for ; Tue, 6 Aug 2002 21:51:20 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20020806060902.82975.qmail@web40309.mail.yahoo.com> <004c01c23dac$ce4bab50$6727e29f@jhy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D50A693.5080800@redback.com> Date: Wed, 7 Aug 2002 00:48:19 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: About Data Base Description packet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit angela wrote: > Hi All > I have one question about interfae MTU processing in DDP exchange. > In my mind, I think any MTU mismatch between two neighbor can not > exchange normally. So I think any router(OSPFv2 or OSPFv3) should > not process the DDP with lower or higher MTU set. If anyone could help? Is it right?? Angela, If you look at section 10.6 in RFC 2328 you'll see that the OSPF router with the lower MTU will reject the DB exchange packet. Hence, you'll never get out of Exchange-start state. Within the last 6 months, there was a long thread on this subject on the list. However, at present, I can't get to the archives. You can try http://discuss.microsoft.com/archives/ospf.html later. > > Best Regards, > angela > > Network Testing Lab > Institute of Computing Technology > Chinese Academy of Sciences > NO. 6, South Road, Kexueyuan, Zhongguancun > P.O.Box 2704 > Beijing 100080, P.R. China > Tel: +86-10-82628446,62565533 ext..9213(office) > E-mail: jhyang@ict.ac.cn > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 7 11:45:11 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24372 for ; Wed, 7 Aug 2002 11:45:11 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.006C3027@cherry.ease.lsoft.com>; Wed, 7 Aug 2002 11:46:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 79977 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 7 Aug 2002 11:46:24 -0400 Received: from 193.180.251.47 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 7 Aug 2002 11:46:24 -0400 Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g77CXwRb018924 for ; Wed, 7 Aug 2002 14:33:58 +0200 (MEST) Received: from euripides.eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id OAA11466; Wed, 7 Aug 2002 14:33:55 +0200 (MET DST) Received: from euripides (euripides [159.107.197.84]) by euripides.eth.ericsson.se (8.10.2+Sun/8.8.8) with SMTP id g77CXru02107 for ; Wed, 7 Aug 2002 14:33:53 +0200 (MEST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MRiaA1rSS0Mo70V5E0JOrQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Message-ID: <200208071233.g77CXru02107@euripides.eth.ericsson.se> Date: Wed, 7 Aug 2002 14:33:53 +0200 Reply-To: Mailing List Sender: Mailing List From: Sandor Ecker Subject: 2 ospf link on the same physical link To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hello! I have tried the following on zebra (redhat linux), and on cisco routers too. I had a simple ip link (for example r1_e0/1--r2_e0/1), i added a network entry to the ospf, to bring the adj. up, this was ok. I added a secondary ip address (in another subnet) to the interfaces in every router, and the corresponding network entry for the ospf. But the second ospf link didn't grow up... :( I made a topology like this: +---+ +---+ | |e0/1 e0/1| | | |----Ar0----| | | | | | | r1|sec sec| r2| | |----Ar1----| | | | | | +---+ +---+ r1: The interface config: ! interface Ethernet0/1 ip address 10.211.92.1 255.255.255.0 secondary ip address 10.211.192.1 255.255.255.0 no ip directed-broadcast ip ospf network point-to-point The ospf config: router ospf 1 network 10.211.92.0 0.0.0.255 area 1 network 10.211.192.0 0.0.0.255 area 0 ! On this router the ospf showed just the original interface with the original ip address... r1#show ip ospf interface Ethernet0/1 is up, line protocol is up Internet Address 10.211.192.1/24, Area 0 Process ID 1, Router ID 10.211.192.1, Network Type POINT_TO_POINT, Cost: 10 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:00 Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 2 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 10.211.192.8 Suppress hello for 0 neighbor(s) r2: Interface config: ! interface Ethernet0/1 ip address 10.211.92.8 255.255.255.0 secondary ip address 10.211.192.8 255.255.255.0 no ip directed-broadcast ip ospf network point-to-point The ospf config: router ospf 1 network 10.211.92.0 0.0.0.255 area 1 network 10.211.192.0 0.0.0.255 area 0 ! On this router like the first, just the original ip address occur. r2#show ip ospf interface Ethernet0/1 is up, line protocol is up Internet Address 10.211.192.8/24, Area 0 Process ID 1, Router ID 10.211.192.8, Network Type POINT_TO_POINT, Cost: 10 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:03 Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 10.211.192.1 Suppress hello for 0 neighbor(s) Kozos volt a kovetkezo: The adj. was the same on each router. r1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.211.192.8 1 FULL/ - 00:00:32 10.211.192.8 Ethernet0/1 The secondary ip address work, i can ping it. (for ex.: from r1 10.211.92.8) The experience with zebras was the same. They haven't seen the eth2:0 as ospf interface. show ip ospf interface shows nothing about eth2:0. Hello packets were send just between the primary interfaces, so neighboring grow up just between them. Has anybody any idea, experience? Thanks a lot! Sincerely, Sandor Ecker From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 7 14:17:41 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02377 for ; Wed, 7 Aug 2002 14:17:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.006C34B0@cherry.ease.lsoft.com>; Wed, 7 Aug 2002 13:18:36 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 80417 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 7 Aug 2002 13:18:36 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 7 Aug 2002 13:18:36 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Aug 2002 13:18:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 7 Aug 2002 13:21:01 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: FW: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Resending as the mail failed to turn up. -Vishwas > -----Original Message----- > From: Manral, Vishwas > Sent: Wednesday, August 07, 2002 5:22 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt > > Hi Folks, > > Peter Psenak and I have been discussing the following and we would like > your views. > > The PCS/some machine in the OSPF domain advertizes the capabilities of the > PCS so that other routers can dynamically learn about the existance of the > PCS. If the PCS looses its "path computation" capability the PCSD LSA is > flushed to indicate that. However when the PCS goes down/is > disconnected/partitioned from the domain any other router in the domain > cannot directly know of the fact. > > To get over this, one of the suggestions is to advertize the PCS/the > router advertizing the PCS capability to the domain as an ASBR. All > routers in the domain would know of the PCS/the router if there was a > router route to the PCS. As soon as the PCS goes down the router route to > it is removed, and hence we can easily find out the existance of a PCS. > > Another way to do it could be to see if there is a route to the PCS on the > router. However because of the fact that a PCS could be well in another > domain/another area, and the prefixes are aggregated, there would be no > way to know for certain if the PCS is up or not for certain. > > We would want to know views on the above or any other method to > dynamically learn of the existence of the PCS. > > Thanks, > Vishwas > > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 7 14:17:42 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02393 for ; Wed, 7 Aug 2002 14:17:42 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.006C3802@cherry.ease.lsoft.com>; Wed, 7 Aug 2002 14:08:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 80603 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 7 Aug 2002 14:08:07 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 7 Aug 2002 14:08:06 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006C3880@cherry.ease.lsoft.com>; Wed, 7 Aug 2002 14:08:06 -0400 Message-ID: Date: Wed, 7 Aug 2002 14:08:05 -0400 Reply-To: Mailing List Sender: Mailing List From: Chaoping Wu Subject: Re: Congestion Avoidance & Control for OSPF Networks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Vishwas & Jerry, Thanks for your replies. Please see my comments inside. Chaoping On Mon, 5 Aug 2002 00:51:18 -0400, Manral, Vishwas wrote: >Hi Chaoping, > >I would like to add to what Jerry has already said. > >> 1. Outbound Congestion Notificatoin >> This I-D suggests this notification not required in some way >> (section 4.2.1). But I think this notification is important and may >> complement the whole mechanism in the following way: >> A. Identifying source of congestion. >> In OSPF network types NBMA, P-TO-P, P-T--MP, Virtual links, OSPF >> packets may go through some kind of transit networks which may >> be congested for some reason. In this scenario, the receiving >> OSPF router can tell if the originating router experiences >> congestion or not. >> >> B. Faster notification is possible if outbound congestion notification >> is performed. It should be sent immediatly once detected. >Though what you say is true, if I have understood you correctly, we have >tried to avoid signalling both for our own congestion as well as congestion >at the other end(which is also harder to predict). We have gone with the >assumption that if the congestion occurs at the other end, then the >congested router will notify abt it. This fact has been put forward in >Section 4.2.1, maybe we can clarify that further. > ========================================================================= This particular comment was about outband congestion at a local router only, rather than any congestion at a remote side as you implied in the reply (I agree with you that remote end congestion is harder to predict, but this is not the point I was trying to make above). The question is what should the local OSPF router do if it detects outband congestion? In section 4.2.1, the ID says "Detecting outbound congestion in some way does not require notification, since we should assume the adjacent router will detect this congestion on its own." While this is true, but it loses the some benifits, such as the points in 1.A & 1.B as I mentioned above. So, instead, I think we should promote the usage of explicit outband congestion notification in this ID. Also another related note is the triggering time of Hello messages that contain LLS congestion signaling. It was not clear from the ID if this signaling should be sent immediately once congestion is detected, or wait until the traditional Hello timer expire. Although this may be somewhat implementation dependent, but I think we should probably promote the better way: immediate notification. ========================================================================= >> 2. State of Congestion >> This I-D specifies 3 states MUST be defined (section 4.2.1) but it >> has not specified a consistent way of defining the states. >> >> In networks mixed with different vendor routers, if a "high congestion >> state" in one router is equivalent to "low congestion state" of its >> neighboring router that is made by a different vendor using different >> definitions of congestion state, the resulted congestion measures in >> this network may not be as desired, isn't it? >Though what you say would be desired, however, there can be no perfect way >to exactly classify it, on different routers/vendors/etc. We have however >given some suggestions in the beginning of the section, we can try to make >the classifications more precise. > ======================================================================= Agreed on "no perfect way to exactly classify it". But if we have a desire to explore ideas to make it better, we may find othe ways. More on this point in the near future. ======================================================================= >> 3. Adding A Congestion Prediction Concept >> What about incorparating a congestion prediction concept into this >> I-D? Preventive congestion measures should be very used for netwrok >> administrators to get alerted about when they should start consider >> optimize their networks. Potential congestion may be simply another >> congestion state. >As the actual signalling of congestion and measure of levels of congestion >has been left to the implementation, an implementation could always signal >low congestion, when it can predict it is going into congestion. The exact >prediction methods are left to the local router itself, and as Jerry pointed >out it may be hard to predict it. > ====================================================================== This ID does provide a good mechanism on congestion prevention. But if you go one step further to introduce the concept of congestion prevention in the ID, I believe it would open another door of useful capabilities. Congestion prediction has been implemented in networking equipment. It may be easier than you think. If there's enough interest, I'll make some suggestions later. ====================================================================== >What we have tried to define is a method by which a local router can signal >congestion(levels of them), and how the neighboring router SHOULD react on >getting such a congestion notification. Besides that we have put in minimal >changes required for any implementation to support such a functionality. > >Thanks, >Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 7 15:10:15 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02384 for ; Wed, 7 Aug 2002 14:17:42 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006C341A@cherry.ease.lsoft.com>; Wed, 7 Aug 2002 13:18:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 80423 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 7 Aug 2002 13:18:38 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 7 Aug 2002 13:18:37 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Aug 2002 07:49:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 7 Aug 2002 07:52:06 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Folks, Peter Psenak and I have been discussing the following and we would like your views. The PCS/some machine in the OSPF domain advertizes the capabilities of the PCS so that other routers can dynamically learn about the existance of the PCS. If the PCS looses its "path computation" capability the PCSD LSA is flushed to indicate that. However when the PCS goes down/is disconnected/partitioned from the domain any other router in the domain cannot directly know of the fact. To get over this, one of the suggestions is to advertize the PCS/the router advertizing the PCS capability to the domain as an ASBR. All routers in the domain would know of the PCS/the router if there was a router route to the PCS. As soon as the PCS goes down the router route to it is removed, and hence we can easily find out the existance of a PCS. Another way to do it could be to see if there is a route to the PCS on the router. However because of the fact that a PCS could be well in another domain/another area, and the prefixes are aggregated, there would be no way to know for certain if the PCS is up or not for certain. We would want to know views on the above or any other method to dynamically learn of the existence of the PCS. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 7 15:29:35 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04897 for ; Wed, 7 Aug 2002 15:29:35 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.006C3929@cherry.ease.lsoft.com>; Wed, 7 Aug 2002 15:30:47 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 80825 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 7 Aug 2002 15:30:47 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 7 Aug 2002 15:30:33 -0400 Received: from asmirnovisdnhome (asmirnov-isdn-home.cisco.com [10.49.1.50]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g77JTs708585 for ; Wed, 7 Aug 2002 21:29:54 +0200 (CEST) References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <003e01c23e48$a5ec9d30$3201310a@asmirnovisdnhome> Date: Wed, 7 Aug 2002 21:28:44 +0200 Reply-To: Mailing List Sender: Mailing List From: Anton Smirnov Organization: Cisco Systems Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vishwas, I think you forgot to include third option - that PCS always originates only Type-10 LSA and ABRs 'translate' it between areas. ABR knows intra-area reachability of originator and can withdraw self-originated translated copies, if needed. Obvious minuses of this approach are: - Overall increased complexity of the specification and implementation, though I can't say that this increase is dramatic. This is the most serious minus, IMO. - At least one ABR to each area-PCSuser must support this specification. Doesn't look like _really_ problematic issue, though also not very nice. - Receiving router may get more than one instance of same information. Can be easily identified as such, if needed. For example, by requiring TLV with originator RID - Increased load on ABRs and increased number of LSAs in areas. Not an issue at all, as we are talking about a few LSAs only. I think this option at least deserves to be mentioned. Anton ----- Original Message ----- From: "Manral, Vishwas" To: Sent: Wednesday, August 07, 2002 1:52 PM Subject: [OSPF] draft-vasseur-mpls-ospf-pcsd-discovery-00.txt > Hi Folks, > > Peter Psenak and I have been discussing the following and we would like your > views. > > The PCS/some machine in the OSPF domain advertizes the capabilities of the > PCS so that other routers can dynamically learn about the existance of the > PCS. If the PCS looses its "path computation" capability the PCSD LSA is > flushed to indicate that. However when the PCS goes down/is > disconnected/partitioned from the domain any other router in the domain > cannot directly know of the fact. > > To get over this, one of the suggestions is to advertize the PCS/the router > advertizing the PCS capability to the domain as an ASBR. All routers in the > domain would know of the PCS/the router if there was a router route to the > PCS. As soon as the PCS goes down the router route to it is removed, and > hence we can easily find out the existance of a PCS. > > Another way to do it could be to see if there is a route to the PCS on the > router. However because of the fact that a PCS could be well in another > domain/another area, and the prefixes are aggregated, there would be no way > to know for certain if the PCS is up or not for certain. > > We would want to know views on the above or any other method to dynamically > learn of the existence of the PCS. > > Thanks, > Vishwas > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 7 21:31:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16064 for ; Wed, 7 Aug 2002 21:31:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006C447F@cherry.ease.lsoft.com>; Wed, 7 Aug 2002 21:32:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 77117 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 7 Aug 2002 21:32:37 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 7 Aug 2002 21:32:37 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 6E55F428F29 for ; Wed, 7 Aug 2002 18:32:39 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200208071233.g77CXru02107@euripides.eth.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D51CA86.2090203@redback.com> Date: Wed, 7 Aug 2002 21:33:58 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: 2 ospf link on the same physical link To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sandor, Some vendors support OSPF on secondary IP addresses and others do not. Refer to the list post below. http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0203&L=ospf&T=0&F=&S=&P=3918 The draft below proposes a way of supporting a single link in multiple areas as a way of getting around the primary address limitation (among other benefits). http://www.ietf.org/internet-drafts/draft-ietf-ospf-mlinks-03.txt Thanks, Acee Sandor Ecker wrote: > Hello! > > I have tried the following on zebra (redhat linux), and on cisco routers too. > I had a simple ip link (for example r1_e0/1--r2_e0/1), i added a network entry > to the ospf, to bring the adj. up, this was ok. I added a secondary ip address > (in another subnet) to the interfaces in every router, and the corresponding > network entry for the ospf. But the second ospf link didn't grow up... :( > > I made a topology like this: > > +---+ +---+ > | |e0/1 e0/1| | > | |----Ar0----| | > | | | | > | r1|sec sec| r2| > | |----Ar1----| | > | | | | > +---+ +---+ > > r1: > The interface config: > ! > interface Ethernet0/1 > ip address 10.211.92.1 255.255.255.0 secondary > ip address 10.211.192.1 255.255.255.0 > no ip directed-broadcast > ip ospf network point-to-point > > The ospf config: > router ospf 1 > network 10.211.92.0 0.0.0.255 area 1 > network 10.211.192.0 0.0.0.255 area 0 > ! > > On this router the ospf showed just the original interface with the original ip > address... > > r1#show ip ospf interface > Ethernet0/1 is up, line protocol is up > Internet Address 10.211.192.1/24, Area 0 > Process ID 1, Router ID 10.211.192.1, Network Type POINT_TO_POINT, Cost: 10 > Transmit Delay is 1 sec, State POINT_TO_POINT, > Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 > Hello due in 00:00:00 > Index 1/1, flood queue length 0 > Next 0x0(0)/0x0(0) > Last flood scan length is 1, maximum is 2 > Last flood scan time is 0 msec, maximum is 0 msec > Neighbor Count is 1, Adjacent neighbor count is 1 > Adjacent with neighbor 10.211.192.8 > Suppress hello for 0 neighbor(s) > > > r2: > Interface config: > ! > interface Ethernet0/1 > ip address 10.211.92.8 255.255.255.0 secondary > ip address 10.211.192.8 255.255.255.0 > no ip directed-broadcast > ip ospf network point-to-point > > The ospf config: > router ospf 1 > network 10.211.92.0 0.0.0.255 area 1 > network 10.211.192.0 0.0.0.255 area 0 > ! > > On this router like the first, just the original ip address occur. > > r2#show ip ospf interface > Ethernet0/1 is up, line protocol is up > Internet Address 10.211.192.8/24, Area 0 > Process ID 1, Router ID 10.211.192.8, Network Type POINT_TO_POINT, Cost: 10 > Transmit Delay is 1 sec, State POINT_TO_POINT, > Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 > Hello due in 00:00:03 > Index 1/1, flood queue length 0 > Next 0x0(0)/0x0(0) > Last flood scan length is 1, maximum is 1 > Last flood scan time is 0 msec, maximum is 0 msec > Neighbor Count is 1, Adjacent neighbor count is 1 > Adjacent with neighbor 10.211.192.1 > Suppress hello for 0 neighbor(s) > > Kozos volt a kovetkezo: > > The adj. was the same on each router. > > r1#show ip ospf neighbor > > Neighbor ID Pri State Dead Time Address Interface > 10.211.192.8 1 FULL/ - 00:00:32 10.211.192.8 Ethernet0/1 > > The secondary ip address work, i can ping it. (for ex.: from r1 10.211.92.8) > > The experience with zebras was the same. They haven't seen the eth2:0 as ospf > interface. > show ip ospf interface shows nothing about eth2:0. > > Hello packets were send just between the primary interfaces, so neighboring grow > up just between them. > > Has anybody any idea, experience? Thanks a lot! > > Sincerely, > Sandor Ecker > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 00:14:05 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20319 for ; Thu, 8 Aug 2002 00:14:05 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006C4956@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 0:13:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 77532 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 00:13:37 -0400 Received: from 216.136.174.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 00:03:37 -0400 Received: from [203.200.20.226] by web13002.mail.yahoo.com via HTTP; Wed, 07 Aug 2002 21:03:36 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-195919318-1028779416=:60694" Message-ID: <20020808040336.61343.qmail@web13002.mail.yahoo.com> Date: Wed, 7 Aug 2002 21:03:36 -0700 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: Criteria for DRship To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --0-195919318-1028779416=:60694 Content-Type: text/plain; charset=us-ascii Hi, Should a router having larger number of interfaces on which OSPF is running be configured with a higher priority so that it is elected as DR when the election takes place? What are the things a system administrator looks at before zeroing upon a router to act as a DR. Has the number of interfaces it is configured for OSPF anything to do with it? Thanks in advance, Rohit --------------------------------- Do You Yahoo!? HotJobs, a Yahoo! service - Search Thousands of New Jobs --0-195919318-1028779416=:60694 Content-Type: text/html; charset=us-ascii

Hi,

Should a router having larger number of interfaces on which OSPF is running be configured with a higher priority so that it is elected as DR when the election takes place?

 

What are the things a system administrator looks at before zeroing upon a router to act as a DR.

 

Has the number of interfaces it is configured for OSPF anything to do with it?

 

Thanks in advance,

Rohit


Do You Yahoo!?
HotJobs, a Yahoo! service - Search Thousands of New Jobs --0-195919318-1028779416=:60694-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 01:04:11 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21273 for ; Thu, 8 Aug 2002 01:04:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.006C4A54@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 1:05:19 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 77726 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 01:05:18 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 01:05:18 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 3C39C2CDB49 for ; Wed, 7 Aug 2002 22:05:16 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 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: <3D51FC59.30401@redback.com> Date: Thu, 8 Aug 2002 01:06:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vishwas, I like the idea of a PCS simply setting the E bit in its router LSA(s) and using the reachability of the PCS's router route to determine whether it is available. My reasons: 1. It is completely backward compatible. All OSPF routers in the routing domain will support this mechanism without update. 2. There really shouldn't be that many of these beasts in a routing domain. Hence, the impact of a few extra router routes or type 4 summary LSAs should be negligible. 3. It is consistent with the "spirit" of the opaque LSAs. Routers that don't support the path computation application won't be impacted. Thanks, Acee Manral, Vishwas wrote: > Hi Folks, > > Peter Psenak and I have been discussing the following and we would like your > views. > > The PCS/some machine in the OSPF domain advertizes the capabilities of the > PCS so that other routers can dynamically learn about the existance of the > PCS. If the PCS looses its "path computation" capability the PCSD LSA is > flushed to indicate that. However when the PCS goes down/is > disconnected/partitioned from the domain any other router in the domain > cannot directly know of the fact. > > To get over this, one of the suggestions is to advertize the PCS/the router > advertizing the PCS capability to the domain as an ASBR. All routers in the > domain would know of the PCS/the router if there was a router route to the > PCS. As soon as the PCS goes down the router route to it is removed, and > hence we can easily find out the existance of a PCS. > > Another way to do it could be to see if there is a route to the PCS on the > router. However because of the fact that a PCS could be well in another > domain/another area, and the prefixes are aggregated, there would be no way > to know for certain if the PCS is up or not for certain. > > We would want to know views on the above or any other method to dynamically > learn of the existence of the PCS. > > Thanks, > Vishwas > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 02:38:12 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02283 for ; Thu, 8 Aug 2002 02:38:11 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.006C4E76@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 2:39:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 78070 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 02:39:22 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 02:39:21 -0400 Received: from ASMIRNOVW2K (dhcp-bru-peg2-vl26-144-254-9-171.cisco.com [144.254.9.171]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g786co723901; Thu, 8 Aug 2002 08:38:50 +0200 (CEST) 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: <047401c23ea6$30cefd00$ab09fe90@cisco.com> Date: Thu, 8 Aug 2002 08:38:22 +0200 Reply-To: Mailing List Sender: Mailing List From: Anton Smirnov Organization: Cisco Systems, Inc. Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt Comments: To: "Manral, Vishwas" To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vishwas, I think your message to the list just has been delayed somewhere as your previous message did, not lost. Right, I don't say that it is new or best idea. I just listed _possible_ solution with its inherent disadvantages. Actually, I would say that so far there are two good alternatives: the one with PCS representing itself as ASBR and the one with translation between areas. And main question which should distinguish preference between these two solutions is also listed in your last email: do we want PCS information to be propagated into all flavors of stub areas or impose requirement to have own PCS at such areas. I don't think that stub status of an area is a good justification to isolate it from PCSD information. Main reason to make an area stub is to reduce number of LSAs in it, not to achieve any kind of security. PCSD LSAs will not break this idea. And, after all, combined solution is possible: PCS server resides in 'normal' area and presents itself as ASBR in all normal areas; while specification leaves room for optional translation capability on border routers to stub areas. This will combine best and worst of both solutions, but all worst is optional and left on implementation's choice. Anton ----- Original Message ----- From: "Manral, Vishwas" To: "'asmirnov@CISCO.COM'" Sent: Thursday, August 08, 2002 06:25 Subject: FW: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt > Forwarding as it hasn't turned up from the list !!! > > -Vishwas > > -----Original Message----- > From: Manral, Vishwas > Sent: Thursday, August 08, 2002 9:49 AM > To: 'Mailing List' > Subject: RE: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt > > > Hi Anton, > > You are right, and we did think of this approach, more from the NSSA and > Stub point of view, because in those areas type-11 LSA's are not flooded. > > However we did not want to have any translation function on stub/NSSA ABRs. > Stub areas should remain stub (no external info should be sent inside). > These > areas should have their own PCS inside the area if needed, or clients inside > stub/NSSA areas should be configured statically with the PCS address, to > avoid added complexity. > > Thanks, > Vishwas > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 02:53:52 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02596 for ; Thu, 8 Aug 2002 02:53:51 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.006C4F30@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 2:55:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 78161 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 02:55:01 -0400 Received: from 66.218.78.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 02:55:00 -0400 Received: from [203.200.20.226] by web40304.mail.yahoo.com via HTTP; Wed, 07 Aug 2002 23:55:02 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020808065502.74472.qmail@web40304.mail.yahoo.com> Date: Wed, 7 Aug 2002 23:55:02 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: NSSA Problem To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <047401c23ea6$30cefd00$ab09fe90@cisco.com> Precedence: list Hi All, I got the doubt while reading the RFC for NSSA it says All the Type 7 LSAs converted into the Type 5 LSA MUST have a forwarding address set. I can understarnd the point mentioned in RFC 2328 about the forwarding address but in this case i am not able to appreciate the MUST conditionin the RFC(with Exception when u start aggregating multiple routes). Please if some one know the answer to it kindly explain to me. Regards Amit __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 04:36:44 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05134 for ; Thu, 8 Aug 2002 04:36:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.006C59A6@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 4:37:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 78874 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 04:37:53 -0400 Received: from 192.11.226.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 04:37:53 -0400 Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com [135.252.18.18]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g788bs819508 for ; Thu, 8 Aug 2002 04:37:55 -0400 (EDT) Received: by CI0026EXCH001U with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 16:29:14 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="gb2312" Message-ID: <31C0F08B0D18D511ACC800508BAE7B4702B9D02A@CI0026EXCH001U> Date: Thu, 8 Aug 2002 16:29:08 +0800 Reply-To: Mailing List Sender: Mailing List From: "Li, Ke Qin (Peter)" Subject: About Traffic Engineering Extensions to OSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi all, I want to know the current status of "Traffic Engineering Extensions to OSPF". I know that it has experienced two Last Calls. And the expiration date of current version draft-katz-yeung-ospf-traffic-06.txt is April 2002. I'm confused that why it has not been an RFC nor removed from WG draft list. Keqin Li Bell Labs Research China Tel: 86-010-68748088-8438 From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 04:48:40 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05359 for ; Thu, 8 Aug 2002 04:48:40 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.006C5B37@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 4:49:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 78931 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 04:49:50 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 04:49:49 -0400 Received: from cisco.com (ppsenak-isdn-home.cisco.com [10.49.2.254]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g788np722386 for ; Thu, 8 Aug 2002 10:49:51 +0200 (CEST) X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D5230AF.31B7B429@cisco.com> Date: Thu, 8 Aug 2002 10:49:51 +0200 Reply-To: Mailing List Sender: Mailing List From: Peter Psenak Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit "Manral, Vishwas" wrote: > > Hi Folks, > > Peter Psenak and I have been discussing the following and we would like your > views. > > The PCS/some machine in the OSPF domain advertizes the capabilities of the > PCS so that other routers can dynamically learn about the existance of the > PCS. If the PCS looses its "path computation" capability the PCSD LSA is > flushed to indicate that. However when the PCS goes down/is > disconnected/partitioned from the domain any other router in the domain > cannot directly know of the fact. > > To get over this, one of the suggestions is to advertize the PCS/the router > advertizing the PCS capability to the domain as an ASBR. All routers in the > domain would know of the PCS/the router if there was a router route to the > PCS. As soon as the PCS goes down the router route to it is removed, and > hence we can easily find out the existance of a PCS. > > Another way to do it could be to see if there is a route to the PCS on the > router. However because of the fact that a PCS could be well in another > domain/another area, and the prefixes are aggregated, there would be no way > to know for certain if the PCS is up or not for certain. just for clarification, current draft does not propose any method of maintaining the reachability of the PCS servers on the routers and relies purely on the IP reachability of the 'PCS address' that is advertised in the Opaque LSA. If the PCS address can not be reached (no reply to the Path computation Request), PCS client may try to contact an alternative PCS server. thanks, Peter > > We would want to know views on the above or any other method to dynamically > learn of the existence of the PCS. > > Thanks, > Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 08:02:28 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08765 for ; Thu, 8 Aug 2002 08:02:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.006C5CA0@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 8:03:39 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 79865 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 08:03:39 -0400 Received: from 66.218.78.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 08:03:39 -0400 Received: from [203.200.20.226] by web40308.mail.yahoo.com via HTTP; Thu, 08 Aug 2002 05:03:38 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020808120338.38340.qmail@web40308.mail.yahoo.com> Date: Thu, 8 Aug 2002 05:03:38 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: RFC ietf Drafe Contradicts in NSSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020808065502.74472.qmail@web40304.mail.yahoo.com> Precedence: list Hi All, I have found a contradition in the NSSA RFC 1587 and ietf dratf number 11 for nssa. The RFC specifies in section 3.5 2nd last para:- When a type-5 LSA and a type-7 LSA are found to have the same type and an equal distance, the following priorities apply (listed from highest to lowest) for breaking the tie. a. Any type 5 LSA. b. A type-7 LSA with the P-bit set and the forwarding address non-zero. c. Any other type-7 LSA. While the Draft specifies in section 3.5 2nd Last para that:- (e) If the current LSA is functionally the same as an installed LSA (i.e., same destination, cost and non-zero forwarding address) then apply the following priorities in deciding which LSA is preferred: 1. A Type-7 LSA with the P-bit set. 2. A Type-5 LSA. 3. The LSA with the higher router ID. Now my doubt is which one to Follow??? Please Help Regards Amit __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 08:37:41 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09501 for ; Thu, 8 Aug 2002 08:37:40 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006C5DAD@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 8:38:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 80074 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 08:38:53 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 08:38:52 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 08:38:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 8 Aug 2002 08:40:18 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Congestion Avoidance & Control for OSPF Networks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Reforwarding. -Vishwas -----Original Message----- From: Manral, Vishwas Sent: Thursday, August 08, 2002 10:17 AM To: 'Mailing List' Subject: RE: Congestion Avoidance & Control for OSPF Networks Hi Chaoping, Jerry may reply in greater detail later, ;-) however my replies. > Also another related note is the triggering time of Hello messages > that contain LLS congestion signaling. It was not clear from the ID if > this signaling should be sent immediately once congestion is detected, > or wait until the traditional Hello timer expire. Although this may be > somewhat implementation dependent, but I think we should probably > promote the better way: immediate notification. We have not put the fact explicitly in the draft, and the idea behind it(as you rightly observed) was that we left it to the implementor. Yes we can explicitly state the fact(the quicker the notification the better), however I think the fact would be obvious to anyone reading the draft anyway. The general idea we got when we floated the prepublished version of the draft was that we should try and leave as much mileage to the implementor, while also achieving our objectives. > Agreed on "no perfect way to exactly classify it". But if we have a > desire to explore ideas to make it better, we may find othe ways. > More on this point in the near future. Sure we are open to ideas. If you can tell us any way we could actually clasify such a congestion on all routers that would be fantastic !! > This ID does provide a good mechanism on congestion prevention. > But if you go one step further to introduce the concept of congestion > prevention in the ID, I believe it would open another > door of useful capabilities. There is nothing in the draft that prevents us from doing "congestion prevention" ;-) as I said before. If we have congestion prediction capabilities we can as well signal congestion even before we fall into that state of congestion. > Congestion prediction has been implemented in networking equipment. > It may be easier than you think. If there's enough interest, I'll > make some suggestions later. Sure we would be very happy to hear back from you on this. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 08:37:49 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09516 for ; Thu, 8 Aug 2002 08:37:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.006C5D5E@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 8:39:01 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 80100 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 08:39:00 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 08:38:57 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 00:17:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 8 Aug 2002 00:19:27 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Anton, You are right, and we did think of this approach, more from the NSSA and Stub point of view, because in those areas type-11 LSA's are not flooded. However we did not want to have any translation function on stub/NSSA ABRs. Stub areas should remain stub (no external info should be sent inside). These areas should have their own PCS inside the area if needed, or clients inside stub/NSSA areas should be configured statically with the PCS address, to avoid added complexity. Thanks, Vishwas -----Original Message----- From: Anton Smirnov [mailto:asmirnov@CISCO.COM] Sent: Thursday, August 08, 2002 12:59 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt Vishwas, I think you forgot to include third option - that PCS always originates only Type-10 LSA and ABRs 'translate' it between areas. ABR knows intra-area reachability of originator and can withdraw self-originated translated copies, if needed. Obvious minuses of this approach are: - Overall increased complexity of the specification and implementation, though I can't say that this increase is dramatic. This is the most serious minus, IMO. - At least one ABR to each area-PCSuser must support this specification. Doesn't look like _really_ problematic issue, though also not very nice. - Receiving router may get more than one instance of same information. Can be easily identified as such, if needed. For example, by requiring TLV with originator RID - Increased load on ABRs and increased number of LSAs in areas. Not an issue at all, as we are talking about a few LSAs only. I think this option at least deserves to be mentioned. Anton ----- Original Message ----- From: "Manral, Vishwas" To: Sent: Wednesday, August 07, 2002 1:52 PM Subject: [OSPF] draft-vasseur-mpls-ospf-pcsd-discovery-00.txt > Hi Folks, > > Peter Psenak and I have been discussing the following and we would like your > views. > > The PCS/some machine in the OSPF domain advertizes the capabilities of the > PCS so that other routers can dynamically learn about the existance of the > PCS. If the PCS looses its "path computation" capability the PCSD LSA is > flushed to indicate that. However when the PCS goes down/is > disconnected/partitioned from the domain any other router in the domain > cannot directly know of the fact. > > To get over this, one of the suggestions is to advertize the PCS/the router > advertizing the PCS capability to the domain as an ASBR. All routers in the > domain would know of the PCS/the router if there was a router route to the > PCS. As soon as the PCS goes down the router route to it is removed, and > hence we can easily find out the existance of a PCS. > > Another way to do it could be to see if there is a route to the PCS on the > router. However because of the fact that a PCS could be well in another > domain/another area, and the prefixes are aggregated, there would be no way > to know for certain if the PCS is up or not for certain. > > We would want to know views on the above or any other method to dynamically > learn of the existence of the PCS. > > Thanks, > Vishwas > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 08:37:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09530 for ; Thu, 8 Aug 2002 08:37:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.006C5E9D@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 8:39:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 80112 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 08:39:03 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 08:39:02 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 00:44:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 8 Aug 2002 00:46:36 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Congestion Avoidance & Control for OSPF Networks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Chaoping, Jerry may reply in greater detail later, ;-) however my replies. > Also another related note is the triggering time of Hello messages > that contain LLS congestion signaling. It was not clear from the ID if > this signaling should be sent immediately once congestion is detected, > or wait until the traditional Hello timer expire. Although this may be > somewhat implementation dependent, but I think we should probably > promote the better way: immediate notification. We have not put the fact explicitly in the draft, and the idea behind it(as you rightly observed) was that we left it to the implementor. Yes we can explicitly state the fact(the quicker the notification the better), however I think the fact would be obvious to anyone reading the draft anyway. The general idea we got when we floated the prepublished version of the draft was that we should try and leave as much mileage to the implementor, while also achieving our objectives. > Agreed on "no perfect way to exactly classify it". But if we have a > desire to explore ideas to make it better, we may find othe ways. > More on this point in the near future. Sure we are open to ideas. If you can tell us any way we could actually clasify such a congestion on all routers that would be fantastic !! > This ID does provide a good mechanism on congestion prevention. > But if you go one step further to introduce the concept of congestion > prevention in the ID, I believe it would open another > door of useful capabilities. There is nothing in the draft that prevents us from doing "congestion prevention" ;-) as I said before. If we have congestion prediction capabilities we can as well signal congestion even before we fall into that state of congestion. > Congestion prediction has been implemented in networking equipment. > It may be easier than you think. If there's enough interest, I'll > make some suggestions later. Sure we would be very happy to hear back from you on this. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 08:46:34 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09754 for ; Thu, 8 Aug 2002 08:46:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.006C5EC6@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 8:47:45 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 80236 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 08:47:44 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 08:47:44 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 13F8ECAB6A for ; Thu, 8 Aug 2002 05:47:44 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20020808065502.74472.qmail@web40304.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D5268B8.8040607@redback.com> Date: Thu, 8 Aug 2002 08:48:56 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: NSSA Problem To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Amit Srivastava wrote: > Hi All, > I got the doubt while reading the RFC for NSSA it > says All the Type 7 LSAs converted into the Type 5 LSA > MUST have a forwarding address set. > I can understarnd the point mentioned in > RFC 2328 about the forwarding address but in this case > i am not able to appreciate the MUST conditionin the > RFC(with Exception when u start aggregating multiple > routes). > Please if some one know the answer to it kindly > explain to me. Amit, An ABR for an NSSA does not generate type 4 summaries for ASBRs within the NSSA. Hence a forwarding address is required to compute the best path to the prefix advertised in the translated LSA. Thanks, Acee > Regards > Amit > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 10:43:08 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14112 for ; Thu, 8 Aug 2002 10:43:07 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.006C61C2@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 10:44:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 80911 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 10:44:15 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 10:44:14 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16566 for ; Thu, 8 Aug 2002 10:44:13 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01242 for ; Thu, 8 Aug 2002 10:44:13 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W99QRG9>; Thu, 8 Aug 2002 10:44:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557632C5@vie-msgusr-01.dc.fore.com> Date: Thu, 8 Aug 2002 10:44:02 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Vishwas, I don't *fully* support to make PCS server an ASBR. IMO, we are overloading the functionality of ASBR. Otherway, I agree to Acee about backward compatibility advantages. -> > Another way to do it could be to see if there is a route -> to the PCS on the router. The way draft is right now is fine (as explained by Peter). Make reachability of the PCS server outside the scope of the document. The current OSPF-TE draft also does the same for Router Address (which is required to be routable always and very different from OSPF Router ID) The Router Address TLV specifies a stable IP address of the advertising router that is always reachable if there is any connectivity to it. -> However because of the fact that a PCS could be -> well in another domain/another area, and the prefixes are -> aggregated, there would be no way to know for certain -> if the PCS is up or not for certain. Vishwas, how is this different from normal prefix reachability when ABR is aggregating prefixes ? As we know, with aggregation we lose some information. In other words, if an internal router gets disconnected in an aggregated area, How are other area routers know about the fact ? -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 10:46:56 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14234 for ; Thu, 8 Aug 2002 10:46:56 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006C60AE@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 10:48:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 80935 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 10:48:08 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 10:48:07 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17150 for ; Thu, 8 Aug 2002 10:48:07 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03208 for ; Thu, 8 Aug 2002 10:48:07 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W99QRPR>; Thu, 8 Aug 2002 10:48:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557632C6@vie-msgusr-01.dc.fore.com> Date: Thu, 8 Aug 2002 10:48:03 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Dijkstra: 1930-2002 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list FYI, http://www.cs.utexas.edu/users/UTCS/notices/dijkstra/ewdobit.html -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 11:50:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16747 for ; Thu, 8 Aug 2002 11:50:26 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.006C669F@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 11:51:39 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 81401 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 11:51:37 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 11:51:37 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17cpZY-0002zf-00; Thu, 08 Aug 2002 08:51:37 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <31C0F08B0D18D511ACC800508BAE7B4702B9D02A@CI0026EXCH001U> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <12978229568.20020808085012@psg.com> Date: Thu, 8 Aug 2002 08:50:12 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: About Traffic Engineering Extensions to OSPF Comments: To: "Li, Ke Qin (Peter)" To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <31C0F08B0D18D511ACC800508BAE7B4702B9D02A@CI0026EXCH001U> Precedence: list Content-Transfer-Encoding: 7bit Keqin- The document was submitted to the IESG, AD-review comments were provided to the authors and we're still waiting for the version that addresses them. So, the ball is in the authors' court. -- Alex Thursday, August 08, 2002, 1:29:08 AM, Li, Ke Qin (Peter) wrote: > Hi all, > I want to know the current status of "Traffic Engineering Extensions to > OSPF". I know that it has experienced two Last Calls. And the expiration > date of current version draft-katz-yeung-ospf-traffic-06.txt is April 2002. > I'm confused that why it has not been an RFC nor removed from WG draft list. > Keqin Li > Bell Labs Research China > Tel: 86-010-68748088-8438 From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 12:29:57 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18429 for ; Thu, 8 Aug 2002 12:29:57 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.006C6841@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 12:31:10 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 81637 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 12:31:07 -0400 Received: from 66.21.69.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 12:21:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 8 Aug 2002 12:07:53 -0400 Reply-To: Mailing List Sender: Mailing List From: Vijaya Bhaskar Subject: basic DR/BDR question! To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list On what basis an OSPF router on a particular interface declares itself as DR or BDR? From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 12:57:28 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19485 for ; Thu, 8 Aug 2002 12:57:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.006C6887@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 12:58:12 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 81734 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 12:58:08 -0400 Received: from 66.122.42.228 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 12:58:08 -0400 Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content Technologies SMTPRS 2.0.15) with SMTP id for ; Thu, 08 Aug 2002 09:57:03 -0700 Received: from MANIS (adsl-66-122-42-231.futsoft.com [66.122.42.231]) by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id IAA28553 for ; Thu, 8 Aug 2002 08:39:44 -0700 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: Date: Thu, 8 Aug 2002 09:58:00 -0700 Reply-To: Mailing List Sender: Mailing List From: Manikantan Srinivasan Subject: Re: basic DR/BDR question! To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hello Vijaya Bhaskar The Router priority is important in the DR/BDR election. Second if there is more than one router in a network with same priority then the Router with highest Router ID becomes DR/BDR. Detailed information is available in sections 7.3, 7.4 and 9.4 in RFC 2328. regards mani -----Original Message----- From: Mailing List [mailto:OSPF@discuss.microsoft.com]On Behalf Of Vijaya Bhaskar Sent: Thursday, August 08, 2002 9:08 AM To: OSPF@discuss.microsoft.com Subject: basic DR/BDR question! On what basis an OSPF router on a particular interface declares itself as DR or BDR? From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 13:05:23 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19742 for ; Thu, 8 Aug 2002 13:05:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.006C68B2@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 13:06:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 81774 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 13:06:33 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 13:06:33 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g78H6Zm52489 for ; Thu, 8 Aug 2002 10:06:35 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g78H6ZF31335 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 10:06:35 -0700 (PDT) (envelope-from kireeti) Message-ID: <200208081706.g78H6ZF31335@kummer.juniper.net> Date: Thu, 8 Aug 2002 10:06:35 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: About Traffic Engineering Extensions to OSPF To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <31C0F08B0D18D511ACC800508BAE7B4702B9D02A@CI0026EXCH001U> Precedence: list > I want to know the current status of "Traffic Engineering Extensions to > OSPF". Mea culpa. Bill was good enough to read and comment in detail; I haven't kept up my end. I will post a new version incorporation Bill's comments, and some nuggets from 2223bis, if Bill missed any. ETA: two weeks. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 13:38:59 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20729 for ; Thu, 8 Aug 2002 13:38:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.006C6911@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 13:40:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 81904 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 13:40:06 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 13:40:06 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 13:40:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 8 Aug 2002 13:42:37 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Venkata, > I don't *fully* support to make PCS server an ASBR. > IMO, we are overloading the functionality of ASBR. We are just using an already existing functionality for a very similar function. We have done this for a lot of other purposes and I feel it is valid. > The way draft is right now is fine (as explained by Peter). > Make reachability of the PCS server outside the scope > of the document. Well that is good enough. However its easy in OSPF to figure out whether a router is down or not. Incase we go the way the draft is, the PC client would only know of a PC Server not existing/going down after few failed retries or when the MaxAge of the LSA expires. So the fact becomes that an advertized PCS may not be up at all, its just that we have the IP address and capabilities of all PCS, which would not make it so very dynamic(as I see it). > The current OSPF-TE draft also does the same for Router > Address (which is required to be routable always and > very different from OSPF Router ID) > > The Router Address TLV specifies a stable IP address of the > advertising router that is always reachable if there is any > connectivity to it. When a link goes down the adjacent router will not advertize the link and hence the link and the router reachable thru the link will not be used for TE purposes either. We do not do a best effort in TE, where we actually try and only in case of failure realize a router/link could be down. I guess some implementations do use the router LSA to figure out if the router is actually reachable. The router LSA is updated when the link goes down, and when that happens we canot reach the router and we do not use the TE information of that router either. > Vishwas, how is this different from normal prefix reachability > when ABR is aggregating prefixes ? As we know, with aggregation > we lose some information. It is not, and that is what I am trying to state. Even the existence of a route to a prefix may not mean the PCS is up. > In other words, if an internal router gets disconnected in an > aggregated area, How are other area routers know about the > fact ? Well if the router is an ASBR, other area routers know of the router because type-4 LSA's for the router. If a router route for the router exists the router is reachable when it is not, it is not. Hope I am clearer this time. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 14:47:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22886 for ; Thu, 8 Aug 2002 14:47:36 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.006C6A84@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 14:48:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 82173 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 14:48:44 -0400 Received: from 63.236.75.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 14:48:44 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 74335109EF3; Thu, 8 Aug 2002 14:48:44 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe1.nwk.excite.com via HTTP; Thu, 08 Aug 2002 14:48:44 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20020808184844.74335109EF3@xmxpita.excite.com> Date: Thu, 8 Aug 2002 14:48:44 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: RFC ietf Drafe Contradicts in NSSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Amit, The nssa-update-11 draft is correct. Since it's an update to the RFC, you should always consider it's operation to be correct. Just because we cannot state compliance to IETF drafts does not mean we cannot implement them. As for the actual reason "why" the change was made, I've seen situations where an external LSA was chosen by a non-translator ABR. The translator ABR goes down, and the non-translator did not start translating because it had chosen the route from the Type-5 external (only NSSA reachable routes are translated). Cheers, -don --- On Thu 08/08, Amit Srivastava wrote: From: Amit Srivastava [mailto: ospfisfun@YAHOO.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Thu, 8 Aug 2002 05:03:38 -0700 Subject: RFC ietf Drafe Contradicts in NSSA > Hi All, > I have found a contradition in the NSSA RFC 1587 and > ietf dratf number 11 for nssa. The RFC specifies in > section 3.5 2nd last para:- > > When a type-5 LSA and a type-7 LSA are found to have > the same type and an equal distance, the following > priorities apply (listed from highest to lowest) for > breaking the tie. > a. Any type 5 LSA. > b. A type-7 LSA with the P-bit set and the forwarding > address non-zero. > c. Any other type-7 LSA. > > While the Draft specifies in section 3.5 2nd Last para > that:- > > (e) If the current LSA is functionally the > same as an installed LSA (i.e., same destination, cost > and non-zero forwarding address) then apply the > following priorities in deciding which LSA is > preferred: > 1. A Type-7 LSA with the P-bit set. > > 2. A Type-5 LSA. > > 3. The LSA with the higher router ID. > > Now my doubt is which one to Follow??? > Please Help > Regards > Amit > > > > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 14:53:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23050 for ; Thu, 8 Aug 2002 14:53:35 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.006C6C02@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 14:54:49 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 82228 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 14:54:44 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 14:54:44 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA04038 for ; Thu, 8 Aug 2002 14:54:46 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA20177 for ; Thu, 8 Aug 2002 14:54:47 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W99Q91G>; Thu, 8 Aug 2002 14:54:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557632CD@vie-msgusr-01.dc.fore.com> Date: Thu, 8 Aug 2002 14:54:45 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Vishwas, -> We have done this for a lot of other purposes and -> I feel it is valid. I am not saying that your ASBR suggestion is invalid :) Please read on... May I know for what other purposes we used ASBR option ? -> > The current OSPF-TE draft also does the same for Router -> > Address (which is required to be routable always and -> > very different from OSPF Router ID) -> > -> > The Router Address TLV specifies a stable IP address of the -> > advertising router that is always reachable if there is any -> > connectivity to it. -> -> When a link goes down the adjacent router will not advertize -> the link and -> hence the link and the router reachable thru the link will -> not be used for -> TE purposes either. We do not do a best effort in TE, where -> we actually try -> and only in case of failure realize a router/link could be down. Vishwas, here I am talking about Router Address TLV and not Link TLV. Consider all the links are up, but the advertised Router Address can still be unreachable. OSPF-TE draft didn't say that "Make sure that router advertises Router Address in their Router LSAs as stub links" etc etc. -> I guess some implementations do use the router LSA to figure -> out if the -> router is actually reachable. The router LSA is updated when -> the link goes -> down, and when that happens we canot reach the router and we -> do not use the TE information of that router either. You are talking about proprietary implementations here :) You know that I am NOT a full supporter of such designs. You are assuming that all *TE links* are *reachable* & *routable* links. -> Well if the router is an ASBR, other area routers know of -> the router because type-4 LSA's for the router. If a router -> route for the router exists the router is reachable when -> it is not, it is not. You didn't get my actual point. My point is, don't mandate that "PCS server must be an ASBR". You can mention in the draft: "If the administrator would like to know the reachability of PCS server dynamically then he can do one of the following possible options (this list is by no way comprehensive): 1. If the PCS server is an internal router then advertise PCS server as an ABSR. But care must be taken in case of stub/NSSA areas. 2. make an ABR act as PCS server 3. make another PCS server as backup and make sure that backup is reachable when primary goes down" If an administrator would like to know the changes to PCS status then he can always turn on ASBR option on that router. If he doesn't want, (for example he added static routes along the path to PCS) then let PCS connections fail...let clients re-try. -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 15:30:31 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24201 for ; Thu, 8 Aug 2002 15:30:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006C6C98@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 15:31:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 82327 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 15:31:44 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 15:31:43 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 15:31:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 8 Aug 2002 15:34:10 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Venkata, > May I know for what other purposes we used ASBR option ? In ISIS the RFC3277 uses Overload bit to avoid Transient Blackhole Avoidance, OSPF uses the LSInfinity cost mechanism in RFC3137 for stub router advertisment, not something they may have originally been designed for. We are not overloading the functionality of ASBR, which is where u started off from and I find no reason for ur objection. > You didn't get my actual point. My point is, > don't mandate that "PCS server must be an ASBR". Venkata, the point is very simple. By using the PCS as an ASBR we can easily irrespective of inter-area/intra-area/other domain know of the existence of the PCS. Its about dynamically learning the existence of PCS by PCC and sending request for path computation. By using the E bit in router LSA it is done in a uniform way and reliably and that is what the point is. Can you tell me what problems you see with this? I did not understand ur proposal either. > If an administrator would like to know the changes to PCS status then he can > always turn on ASBR option on that router If an administrator wants to know the status of the PCS, he can as well find out the status on the PCS, why would he need to set the ASBR option for it on the PCS. Or are you sugesting something else? Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 15:50:49 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24615 for ; Thu, 8 Aug 2002 15:50:49 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006C6EDC@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 15:52:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 82523 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 15:52:02 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 15:52:01 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id EBE144483EB for ; Thu, 8 Aug 2002 12:51:58 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 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: <3D52CC23.1060100@redback.com> Date: Thu, 8 Aug 2002 15:53:07 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: > Hi Venkata, > > >> May I know for what other purposes we used ASBR option ? >> > > In ISIS the RFC3277 uses Overload bit to avoid Transient Blackhole > Avoidance, OSPF uses the LSInfinity cost mechanism in RFC3137 for stub > router advertisment, not something they may have originally been designed > for. We are not overloading the functionality of ASBR, which is where u > started off from and I find no reason for ur objection. Venkata, Vishwas, Another example would be the use of a type 4 summary LSA to signal the presence of DC clear LSAs across area boundaries as described in RFC 1793. Thanks, Acee > > >> You didn't get my actual point. My point is, >> don't mandate that "PCS server must be an ASBR". >> > Venkata, the point is very simple. By using the PCS as an ASBR we can easily > irrespective of inter-area/intra-area/other domain know of the existence of > the PCS. > > Its about dynamically learning the existence of PCS by PCC and sending > request for path computation. By using the E bit in router LSA it is done in > a uniform way and reliably and that is what the point is. > > Can you tell me what problems you see with this? I did not understand ur > proposal either. > > >>If an administrator would like to know the changes to PCS status then he >> > can > >>always turn on ASBR option on that router >> > > If an administrator wants to know the status of the PCS, he can as well find > out the status on the PCS, why would he need to set the ASBR option for it > on the PCS. Or are you sugesting something else? > > Thanks, > Vishwas > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 16:04:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25173 for ; Thu, 8 Aug 2002 16:04:26 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.006C711A@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 16:05:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 82554 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 16:05:37 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 16:05:37 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA10010 for ; Thu, 8 Aug 2002 16:05:34 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA17076 for ; Thu, 8 Aug 2002 16:05:34 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W99RDZV>; Thu, 8 Aug 2002 16:05:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557632CE@vie-msgusr-01.dc.fore.com> Date: Thu, 8 Aug 2002 16:05:26 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Vishwas, -> Can you tell me what problems you see with this? I did not -> understand ur proposal either. I don't see any problem with your ASBR option for PCS. (except some extra Type 4 LSAs extra processing in ABR etc, which are tolerable). By doing so we get lot of advantages as explained by you and Acee. -> Its about dynamically learning the existence of PCS by PCC I am suggesting a very simple change. Don't *mandate* the PCS to be an ASBR. Just *suggest* that making an ASBR will make PCC to learn about PCS *dynamically*. If the administrator is willing to do so, then he makes PCS an ASBR. If he doesn't (for his own reasons) he always has the option of making the PCS a non-ASBR. All the risk is administrator's (because he wanted the PCS to be a non-ASBR for his own reasons). I am just suggesting you a flexibility. Just don't take it so hard :) Again, your ASBR option is fine - but an intelligent administrator knows what he can do to make PCS reachable at all times. I am just giving you a suggestion with out losing functionality. I would like to know your thoughts - "why you want to make PCS always ASBR without giving flexibility to administrator ?". Please let me know your thoughts - Acee, Parker ? -- Venkata From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 16:11:04 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25381 for ; Thu, 8 Aug 2002 16:11:04 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.006C71CB@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 16:12:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 82585 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 16:12:17 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 16:12:17 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA10748 for ; Thu, 8 Aug 2002 16:12:15 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA19737 for ; Thu, 8 Aug 2002 16:12:16 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W99R1HN>; Thu, 8 Aug 2002 16:12:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557632CF@vie-msgusr-01.dc.fore.com> Date: Thu, 8 Aug 2002 16:12:12 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -> Please let me know your thoughts - Acee, Parker ? Sorry, that should be Peter Psenak (not Parker) -- Venkata From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 16:59:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26687 for ; Thu, 8 Aug 2002 16:59:32 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006C71A2@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 17:00:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 82708 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 17:00:45 -0400 Received: from 66.122.42.228 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 17:00:44 -0400 Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content Technologies SMTPRS 2.0.15) with SMTP id for ; Thu, 08 Aug 2002 13:59:24 -0700 Received: from fcslabmc4 (adsl-66-122-42-235.futsoft.com [66.122.42.235]) by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id MAA29959 for ; Thu, 8 Aug 2002 12:41:57 -0700 References: <20020808184844.74335109EF3@xmxpita.excite.com> MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <019301c23f1e$cd595df0$eb2a7a42@futsoft.com> Date: Thu, 8 Aug 2002 14:01:41 -0700 Reply-To: Mailing List Sender: Mailing List From: Samvid Shah Subject: Re: RFC ietf Drafe Contradicts in NSSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Don and Amit, my 2 cents... Thanks. -Samvid ----- Original Message ----- From: Don Goodspeed To: Sent: Thursday, August 08, 2002 11:48 AM Subject: Re: RFC ietf Drafe Contradicts in NSSA > Amit, > > The nssa-update-11 draft is correct. Since it's an update > to the RFC, you should always consider it's operation to be > correct. Just because we cannot state compliance to IETF > drafts does not mean we cannot implement them. > > As for the actual reason "why" the change was made, I've seen > situations where an external LSA was chosen by a non-translator > ABR. The translator ABR goes down, and the non-translator did > not start translating because it had chosen the route from > the Type-5 external (only NSSA reachable routes are translated). Samvid> If we consider NSSA with 2 ABRs both connected to area 0, probably we can appreciate this fact (giving higher priority to type 7 LSA with P bit set for installing it as AS external route). Since, type 7 LSA represents intra-area LSA and P bit set represents the LSA needs to be translated to type 5 , giving higher priority to type 7 LSA with P bit increases chances that routing will be optimal for AS external routes in this case. > > Cheers, > -don > > --- On Thu 08/08, Amit Srivastava wrote: > From: Amit Srivastava [mailto: ospfisfun@YAHOO.COM] > To: OSPF@DISCUSS.MICROSOFT.COM > Date: Thu, 8 Aug 2002 05:03:38 -0700 > Subject: RFC ietf Drafe Contradicts in NSSA > > > Hi All, > > I have found a contradition in the NSSA RFC 1587 and > > ietf dratf number 11 for nssa. The RFC specifies in > > section 3.5 2nd last para:- > > > > When a type-5 LSA and a type-7 LSA are found to have > > the same type and an equal distance, the following > > priorities apply (listed from highest to lowest) for > > breaking the tie. > > a. Any type 5 LSA. > > b. A type-7 LSA with the P-bit set and the forwarding > > address non-zero. > > c. Any other type-7 LSA. > > > > While the Draft specifies in section 3.5 2nd Last para > > that:- > > > > (e) If the current LSA is functionally the > > same as an installed LSA (i.e., same destination, cost > > and non-zero forwarding address) then apply the > > following priorities in deciding which LSA is > > preferred: > > 1. A Type-7 LSA with the P-bit set. > > > > 2. A Type-5 LSA. > > > > 3. The LSA with the higher router ID. > > > > Now my doubt is which one to Follow??? > > Please Help > > Regards > > Amit > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > HotJobs - Search Thousands of New Jobs > > http://www.hotjobs.com > > > > ------------------------------------------------ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 17:32:42 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27621 for ; Thu, 8 Aug 2002 17:32:42 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.006C73C2@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 17:33:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 82815 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 17:33:54 -0400 Received: from 66.125.201.154 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 17:23:53 -0400 Received: (from cengiz@localhost) by zen.packetdesign.com (8.11.6/8.11.6) id g78LRAr31787 for OSPF@discuss.microsoft.com; Thu, 8 Aug 2002 14:27:10 -0700 X-Authentication-Warning: zen.packetdesign.com: cengiz set sender to Cengiz_Alaettinoglu@yahoo.com using -f References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Message-ID: <1028842030.11041.50.camel@zen.packetdesign.com> Date: Thu, 8 Aug 2002 14:27:10 -0700 Reply-To: Mailing List Sender: Mailing List From: Cengiz Alaettinoglu Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Here is a pointer to the NANOG talk mentioned below. ISIS Routing on the Qwest Backbone: a Recipe for Subsecond ISIS Convergence http://www.nanog.org/mtg-0202/cengiz.html It has a nice graph on an exponential link flap damping filter. Cengiz On Mon, 2002-07-22 at 21:44, Manral, Vishwas wrote: > Hi Andrepeter, > > I haven't really been following the thread but now that you mentioned the > draft > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt > > I would like to add that there are some things that we have mentioned in > section 4 of the draft that could help in case of "link flaps". > > The main point being to give more priority to "link down" than to "link up". > This could mean that in case of flaps we could signal "link down" > immediately however damp the "link up" event. Cengiz and Steve Casner > reached a similar conclusion with respect to ISIS protocol, they even > presented something related at NANOG. > > Thanks, > Vishwas > > > ...deleted... > > In my opinion the only service OSPF (or any other IGP) > > provides/should provide is connectivity, i.e. it tells you if > > a link exists and if it can carry traffic, not how much > > traffic there is. Route recalculation based on traffic > > information (congestion gives new cost values) should not be > > done as it will introduce route flaps. > > This also holds for a DiffServ world. In a DiffServ world > > packets are preferentially forwarded, but always such that no > > single class is starved. Even if some class gets so little BW > > that de-facto the link is down for that class, one should not > > declare the link down for that class, as it is equivalent > > with assigning a high cost for that link. Hence link monitor > > packets per class make no sense. (Besides, in long > > simulations with strict priority queueing we never had class > > starvation) > > As for Hello in the highest DiffServ class: we tested this > > idea in simulations for all OSPF packets, and results were > > excellent, i.e. route table convergence in the order of the > > half the minimum round trip time (excl. route table > > recalculations). This idea was also proposed in > > 'draft-ietf-ospf-scalability-01.txt'. > > > > regards, > > > > Andrepeter -- Cengiz Alaettinoglu From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 19:29:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00583 for ; Thu, 8 Aug 2002 19:29:24 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.006C7736@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 19:30:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 83296 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 19:30:31 -0400 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 19:30:31 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01KL28C8IAPC8WY6UX@omega7.wr.usgs.gov> for OSPF@DISCUSS.MICROSOFT.COM; Thu, 08 Aug 2002 16:30:32 -0700 (PDT) X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM X-VMS-Cc: pmurphy,ospfisfun@yahoo.com MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01KL28C8ICLE8WY6UX@omega7.wr.usgs.gov> Date: Thu, 8 Aug 2002 16:30:32 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: NSSA Problem Comments: cc: OSPFISFUN@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Amit, > I can understand the point mentioned in >RFC 2328 about the forwarding address but in this case >I am not able to appreciate the MUST condition the >RFC(with Exception when u start aggregating multiple >routes). It is true that type 7 LSAs that are aggregated into a single Type 5 LSA with a 0.0.0.0 forwarding address do not need a computed forwarding address. But usually an NSSA's ASBR has no way of knowing whether or not its self-originated Type-7 LSAs are aggregated by the NSSA's ABRs during translation. Without providing configuration to the contrary, the NSSA's ASBRs MUST assume their Type 7 LSAs (with the P-bit set) will not be aggregated during translation and therefore MUST compute a non-zero forwarding address. I don't see much value in complicating the NSSA spec by softening this requirement for Type 7 range aggregations or for the case of an NSSA with just a single ABR. Its hard to imagine any IPv4 application where the forwarding address cannot be set (IPv6ers care to jump in???). Note that when the P-bit is clear, the new NSSA spec does allow a Type 7 LSA to have a 0.0.0.0 forwarding address. >An ABR for an NSSA does not generate type 4 summaries for >ASBRs within the NSSA. This is because all type 5 LSA translations of type 7 LSAs are originated by NSSA ABRs, not NSSA ASBRs. >Hence a forwarding address is >required to compute the best path to the prefix >advertised in the translated LSA. If the NSSA's ABR translators used a 0.0.0.0 forwarding address in their Type 5 LSA translations, these Type 5 LSA translations would cause packets to be forwarded directly through their originating ABR rather than via a potentially more preferred path through a different NSSA ABR. Note that this is always the case when type 7 ranges aggregate Type 7 LSAs into a Type 5 LSA with a 0.0.0.0 forwarding address. Pat From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 20:17:28 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01538 for ; Thu, 8 Aug 2002 20:17:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.006C7B22@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 20:18:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 83433 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 20:18:37 -0400 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 20:18:37 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01KL2A0VPCY88WY6UX@omega7.wr.usgs.gov> for OSPF@DISCUSS.MICROSOFT.COM; Thu, 08 Aug 2002 17:18:38 -0700 (PDT) X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM X-VMS-Cc: pmurphy,ospfisfun@YAHOO.COM MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01KL2A0VPCYA8WY6UX@omega7.wr.usgs.gov> Date: Thu, 8 Aug 2002 17:18:38 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: RFC ietf Drafe Contradicts in NSSA Comments: cc: OSPFISFUN@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Amit, Keep in mind that the latest NSSA spec, ietf dratf number 11, is updating section 3.5 of RFC 1587 to be consistent with the current OSPFv2 spec, RFC 2328, Section 16.4. Consider an expanded wording of your snip from RFC 1587: When a type-5 LSA and a type-7 LSA are found to have the same type and an equal distance, the following priorities apply (listed from highest to lowest) for breaking the tie. a. Any type 5 LSA. b. A type-7 LSA with the P-bit set and the forwarding address non-zero. c. Any other type-7 LSA. The biggest problem with this algorithm is the fact it makes a Type 5 LSA translation of a Type 7 LSA more preferred when it originates from a different NSSA ABR than the local router. It also gives Type 5 LSAs preference over equally preferred Type 7 LSAs even when their forwarding addresses are different. The new NSSA spec (An RFC publication is forthcoming as soon as I can crank out one last response with edits to the RFC Editor) resolves this issue more specifically: (e) If the current LSA is functionally the same as an installed LSA (i.e., same destination, cost and non-zero forwarding address) then apply the following priorities in deciding which LSA is preferred: 1. A Type-7 LSA with the P-bit set. 2. A Type-5 LSA. 3. The LSA with the higher router ID. Unlike RFC 1587, multiple Type 5 LSAs and/or Type 7 LSAs which have the same type and equal metric, but different forwarding addresses, have equal preference and are all installed. Note that there are examples where each of these three preferences is used. Furthermore these preferences always produce a single installed LSA amongst a set of LSAs which are functionally the same, regardless of Type. Pat From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 8 23:47:06 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05874 for ; Thu, 8 Aug 2002 23:47:05 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.006C870B@cherry.ease.lsoft.com>; Thu, 8 Aug 2002 23:48:19 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 84021 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 8 Aug 2002 23:48:18 -0400 Received: from 216.136.130.169 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 8 Aug 2002 23:38:18 -0400 Received: from [24.61.222.97] by web10605.mail.yahoo.com via HTTP; Thu, 08 Aug 2002 20:38:17 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020809033817.34460.qmail@web10605.mail.yahoo.com> Date: Thu, 8 Aug 2002 20:38:17 -0700 Reply-To: Mailing List Sender: Mailing List From: Subhash Subject: LSAs with Reserved flooding scope To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <01KL2A0VPCYA8WY6UX@omega7.wr.usgs.gov> Precedence: list Hi, I was going over rfc 2740 section 3.5.1(3) - if the flooding scope of a received LSA is set to reserved, discard it. Is such a check required when a database description packet is received? The reason why I am asking is because if a router doesnt make such a check upon receiving the DD, & sends a request for such an LSA, its request list will never become empty, as per rfc 2328. Am I right? Thanks for your feedback. -Subhash __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 9 00:31:35 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06784 for ; Fri, 9 Aug 2002 00:31:35 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006C8A00@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 0:32:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 84273 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 9 Aug 2002 00:32:47 -0400 Received: from 66.218.78.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 9 Aug 2002 00:32:47 -0400 Received: from [203.200.20.226] by web40308.mail.yahoo.com via HTTP; Thu, 08 Aug 2002 21:32:47 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020809043247.87573.qmail@web40308.mail.yahoo.com> Date: Thu, 8 Aug 2002 21:32:47 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: NSSA Problem To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <01KL28C8ICLE8WY6UX@omega7.wr.usgs.gov> Precedence: list Hi Pat and Acee, See even if the forwarding address is not set in the originating AS-external LSA(in the NSSA) the ABR can know about the router which has originated the LSA by its router id. So why they are imphasising on setting of the forwarding address!! I am still in the same state of confision plz help!! Regards Amit --- "Pat Murphy - (650)329-4044" wrote: > Amit, > > > I can understand the point mentioned in > >RFC 2328 about the forwarding address but in this > case > >I am not able to appreciate the MUST condition the > >RFC(with Exception when u start aggregating > multiple > >routes). > > It is true that type 7 LSAs that are aggregated into > a single > Type 5 LSA with a 0.0.0.0 forwarding address do not > need a > computed forwarding address. But usually an NSSA's > ASBR has no > way of knowing whether or not its self-originated > Type-7 LSAs > are aggregated by the NSSA's ABRs during > translation. Without > providing configuration to the contrary, the NSSA's > ASBRs MUST > assume their Type 7 LSAs (with the P-bit set) will > not be > aggregated during translation and therefore MUST > compute a > non-zero forwarding address. > > I don't see much value in complicating the NSSA spec > by > softening this requirement for Type 7 range > aggregations or > for the case of an NSSA with just a single ABR. Its > hard to > imagine any IPv4 application where the forwarding > address > cannot be set (IPv6ers care to jump in???). Note > that when the > P-bit is clear, the new NSSA spec does allow a Type > 7 LSA to > have a 0.0.0.0 forwarding address. > > >An ABR for an NSSA does not generate type 4 > summaries for > >ASBRs within the NSSA. > > This is because all type 5 LSA translations of type > 7 LSAs are > originated by NSSA ABRs, not NSSA ASBRs. > > >Hence a forwarding address is > >required to compute the best path to the prefix > >advertised in the translated LSA. > > If the NSSA's ABR translators used a 0.0.0.0 > forwarding > address in their Type 5 LSA translations, these Type > 5 LSA > translations would cause packets to be forwarded > directly > through their originating ABR rather than via a > potentially > more preferred path through a different NSSA ABR. > Note that > this is always the case when type 7 ranges aggregate > Type 7 > LSAs into a Type 5 LSA with a 0.0.0.0 forwarding > address. > > Pat __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 9 01:18:16 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07454 for ; Fri, 9 Aug 2002 01:18:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006C8B72@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 1:19:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 84394 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 9 Aug 2002 01:19:28 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 9 Aug 2002 01:19:28 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 01:19:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 9 Aug 2002 01:21:56 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Venkata, I will try drawing a simple parallel with the current ASBR mechanism. An ASBR advertizes AS-External LSA's into the OSPF domain. It sets the E-bit in the router LSA. Whenever we are processing AS-External LSA's from the ASBR, we do try and check as a precautionary measure whether the ASBR is still reachable or not, and only if it is, do we process the AS-External LSA's. We do not leave it to the smart administrator to make ASBR reachable at all times. I am not averse to your idea at all, however I thought I would bring forward the similarities I saw. Tell me what you think? Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 9 01:28:02 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07694 for ; Fri, 9 Aug 2002 01:28:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.006C8AFF@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 1:29:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 84393 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 9 Aug 2002 01:29:15 -0400 Received: from 205.158.62.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 9 Aug 2002 01:19:14 -0400 Received: (qmail 4848 invoked by uid 1001); 9 Aug 2002 04:09:47 -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 ws1-11.us4.outblaze.com with http for arms@yours.com; Thu, 08 Aug 2002 23:09:47 -0500 X-Originating-Ip: 203.197.138.194 X-Originating-Server: ws1-11.us4.outblaze.com Message-ID: <20020809040947.4847.qmail@iname.com> Date: Thu, 8 Aug 2002 23:09:47 -0500 Reply-To: Mailing List Sender: Mailing List From: armstrong mathiayalagan Subject: Re: basic DR/BDR question! To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mani and Vijay, The router which is started first in the broadcast IP network always becomes a DR ( if it is eligible ) , the second router becomes BDR.. ( After waiting timer expires, if no DR is found it declares itself as a DR, Waiting timer will expire first for the first started router !!), In case if BDR fails ( waiting timer will not play any role), so the proper election takes place considering priority and Rtr ID. Regards, Armstrong ----- Original Message ----- From: Manikantan Srinivasan Date: Thu, 8 Aug 2002 09:58:00 -0700 To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: basic DR/BDR question! > Hello Vijaya Bhaskar > > The Router priority is important in the DR/BDR election. > > Second if there is more than one router in a network > with same priority then the Router with highest > Router ID becomes DR/BDR. > > Detailed information is available in sections 7.3, 7.4 and 9.4 > in RFC 2328. > > regards > mani > > -----Original Message----- > From: Mailing List [mailto:OSPF@discuss.microsoft.com]On Behalf Of > Vijaya Bhaskar > Sent: Thursday, August 08, 2002 9:08 AM > To: OSPF@discuss.microsoft.com > Subject: basic DR/BDR question! > > > On what basis an OSPF router on a particular interface declares itself as > DR or BDR? > > -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 9 03:53:04 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19135 for ; Fri, 9 Aug 2002 03:53:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.006C8EF7@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 3:54:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 84747 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 9 Aug 2002 03:54:10 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 9 Aug 2002 03:54:10 -0400 Received: from cisco.com (ppsenak-isdn-home.cisco.com [10.49.2.254]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g797sA718899 for ; Fri, 9 Aug 2002 09:54:11 +0200 (CEST) X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <39469E08BD83D411A3D900204840EC557632CE@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D537521.98BAD421@cisco.com> Date: Fri, 9 Aug 2002 09:54:09 +0200 Reply-To: Mailing List Sender: Mailing List From: Peter Psenak Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Venkata, "Naidu, Venkata" wrote: > > Vishwas, > > -> Can you tell me what problems you see with this? I did not > -> understand ur proposal either. > > I don't see any problem with your ASBR option for PCS. > (except some extra Type 4 LSAs extra processing in ABR etc, > which are tolerable). By doing so we get lot of advantages > as explained by you and Acee. > > -> Its about dynamically learning the existence of PCS by PCC > > I am suggesting a very simple change. Don't *mandate* > the PCS to be an ASBR. Just *suggest* that making an ASBR > will make PCC to learn about PCS *dynamically*. > > If the administrator is willing to do so, then he makes > PCS an ASBR. If he doesn't (for his own reasons) he > always has the option of making the PCS a non-ASBR. All > the risk is administrator's (because he wanted the PCS to > be a non-ASBR for his own reasons). > > I am just suggesting you a flexibility. Just don't take > it so hard :) Again, your ASBR option is fine - but > an intelligent administrator knows what he can do to > make PCS reachable at all times. > > I am just giving you a suggestion with out losing > functionality. I would like to know your thoughts - > "why you want to make PCS always ASBR without giving > flexibility to administrator ?". > > Please let me know your thoughts - Acee, Parker ? We use Opaque LSAs to transport some application specific information, where OSPF is purely a transport mechanism. My feeling is that we should not use OSPF to keep track of the reachability of the Opaque LSA source. It's the application that should take care of the cases where the source becomes unreachable. my 2c, Peter > > -- > Venkata From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 9 08:23:20 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24553 for ; Fri, 9 Aug 2002 08:23:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006C900D@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 8:24:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 85700 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 9 Aug 2002 08:24:32 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 9 Aug 2002 08:24:31 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 08:24:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 9 Aug 2002 08:26:58 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Peter, > We use Opaque LSAs to transport some application specific information, > where OSPF is purely a transport mechanism. My feeling is that we should > not use OSPF to keep track of the reachability of the Opaque LSA source. > It's the application that should take care of the cases where the source > becomes unreachable. The contents of the Opaque LSA's are still transparent to us i.e. we do not look at the information carried by the opaque LSA. We only check the opaque type, which has to be done for all other kinds of Opaque LSA's too(as not all opaque LSA's are sent to external applications), and check the existence of the originator in case its a PCSD, which can be done with no change to the base protocol at all. I am wondering why we would not like to use a mechanism in the transport when it can be easily done there and burden the application? One reason I could come across was it probably cannot be done the same way in ISIS(though I haven't read the ISIS draft) However I do agree it is not so much of an issue at all, even if its not advertized as ASBR's and left as is in the draft(just some extra lag time on retries and choosing a different PCS in case of failure to get a response). We have had a fairly comprehensive and fruitful discussion on the topic already and I guess, we all know the merits and demerits, so it is more of a question of the tradeoffs, either ways. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 9 10:09:02 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27736 for ; Fri, 9 Aug 2002 10:09:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006C9390@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 10:09:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 86024 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 9 Aug 2002 10:09:56 -0400 Received: from 66.21.69.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 9 Aug 2002 10:09:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 9 Aug 2002 09:56:42 -0400 Reply-To: Mailing List Sender: Mailing List From: Vijaya Bhaskar Subject: Re: basic DR/BDR question! To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I got the answer as follows, correct me if I am wrong. When a routers comes up 1. If it is the only router on a broadcast network, it declares itself as DR after wait timer is expired. 2. If it doe not receive any hellos(even though there may be neibhors on the network) till its wait times expires, it declares itself as DR. 3. If the DR field is 0.0.0.0 in all the hellos it has received from neighbors, and no DR is elected after wait timer is expires(i.e after DR/BDR election is over), it declares itself as DR. 4. If all the other routers on the network are ineligible to become DR/BDR(i.e router priority zero), it declares itself as DR after DR/BDR election is over. 5. If a DR already exists on the network, it just accepts the same as DR irrespective of router priority or router ID. There may be other possible cases! -----Original Message----- From: armstrong mathiayalagan [mailto:arms@YOURS.COM] Sent: Friday, August 09, 2002 12:10 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: basic DR/BDR question! Mani and Vijay, The router which is started first in the broadcast IP network always becomes a DR ( if it is eligible ) , the second router becomes BDR.. ( After waiting timer expires, if no DR is found it declares itself as a DR, Waiting timer will expire first for the first started router !!), In case if BDR fails ( waiting timer will not play any role), so the proper election takes place considering priority and Rtr ID. Regards, Armstrong ----- Original Message ----- From: Manikantan Srinivasan Date: Thu, 8 Aug 2002 09:58:00 -0700 To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: basic DR/BDR question! > Hello Vijaya Bhaskar > > The Router priority is important in the DR/BDR election. > > Second if there is more than one router in a network > with same priority then the Router with highest > Router ID becomes DR/BDR. > > Detailed information is available in sections 7.3, 7.4 and 9.4 > in RFC 2328. > > regards > mani > > -----Original Message----- > From: Mailing List [mailto:OSPF@discuss.microsoft.com]On Behalf Of > Vijaya Bhaskar > Sent: Thursday, August 08, 2002 9:08 AM > To: OSPF@discuss.microsoft.com > Subject: basic DR/BDR question! > > > On what basis an OSPF router on a particular interface declares itself as > DR or BDR? > > -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 9 10:37:12 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28413 for ; Fri, 9 Aug 2002 10:37:12 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006C9523@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 10:38:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 86148 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 9 Aug 2002 10:38:24 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 9 Aug 2002 10:38:23 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 40C1E1DCC66 for ; Fri, 9 Aug 2002 07:38:24 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 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: <3D53D41A.3080101@redback.com> Date: Fri, 9 Aug 2002 10:39:22 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vishwas, Peter, Venkata, Here is my take: If it is acceptable for the Path-Comp-Clients to retry until they find a reachable and operational Path-Comp-Server from the alternatives then this is probably the best option. This keeps the selection of the Path-Comp-Server entirely within the path computation application. If this isn't operationally acceptable, then I'd vote for the Path-Comp-Server setting its E bit and having OSPF in the Path-Comp-Clients prune the list of Path-Comp-Servers to those that are reachable. While this is a bit of a hack it has it benefits (as discussed previously) and may be applicable to future opaque LSA applications. My least favorite alternative is allowing the setting of the E bit to be optional since it requires implementation of the Path-Comp-Server reachability checking in both OSPF and the the Path-Comp-Clients. Thanks, Acee Manral, Vishwas wrote: > Hi Peter, > > >>We use Opaque LSAs to transport some application specific information, >>where OSPF is purely a transport mechanism. My feeling is that we should >>not use OSPF to keep track of the reachability of the Opaque LSA source. >>It's the application that should take care of the cases where the source >>becomes unreachable. >> > > The contents of the Opaque LSA's are still transparent to us i.e. we do not > look at the information carried by the opaque LSA. We only check the opaque > type, which has to be done for all other kinds of Opaque LSA's too(as not > all opaque LSA's are sent to external applications), and check the existence > of the originator in case its a PCSD, which can be done with no change to > the base protocol at all. > > I am wondering why we would not like to use a mechanism in the transport > when it can be easily done there and burden the application? One reason I > could come across was it probably cannot be done the same way in ISIS(though > I haven't read the ISIS draft) > > However I do agree it is not so much of an issue at all, even if its not > advertized as ASBR's and left as is in the draft(just some extra lag time on > retries and choosing a different PCS in case of failure to get a response). > > We have had a fairly comprehensive and fruitful discussion on the topic > already and I guess, we all know the merits and demerits, so it is more of a > question of the tradeoffs, either ways. > > Thanks, > Vishwas > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 9 10:55:41 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28968 for ; Fri, 9 Aug 2002 10:55:40 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006C95D8@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 10:56:54 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 86261 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 9 Aug 2002 10:56:52 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 9 Aug 2002 10:56:52 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006C9500@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 10:56:53 -0400 Message-ID: Date: Fri, 9 Aug 2002 10:56:51 -0400 Reply-To: Mailing List Sender: Mailing List From: "Kwiatkowski, Jacek" Subject: Re: LSAs with Reserved flooding scope To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Subhash, You are right. However, the same issue can happen in OSPFv2 if the LS type of a received LSA is unknown. In both versions of OSPF, receiving of such an LSA in DD packets indicates that one of OSPF routers is broken. Jacek On Thu, 8 Aug 2002 20:38:17 -0700, Subhash wrote: >Hi, > >I was going over rfc 2740 section 3.5.1(3) - if the flooding scope of a >received LSA is set to reserved, discard it. Is such a check required >when a database description packet is received? > >The reason why I am asking is because if a router doesnt make such a >check upon receiving the DD, & sends a request for such an LSA, its >request list will never become empty, as per rfc 2328. Am I right? > >Thanks for your feedback. >-Subhash > > >__________________________________________________ >Do You Yahoo!? >HotJobs - Search Thousands of New Jobs >http://www.hotjobs.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 9 11:28:30 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29906 for ; Fri, 9 Aug 2002 11:28:30 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006C95A3@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 11:29:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 86350 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 9 Aug 2002 11:29:41 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 9 Aug 2002 11:29:41 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18963 for ; Fri, 9 Aug 2002 11:29:41 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA28164 for ; Fri, 9 Aug 2002 11:29:43 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W99S2K5>; Fri, 9 Aug 2002 11:29:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557632D4@vie-msgusr-01.dc.fore.com> Date: Fri, 9 Aug 2002 11:29:41 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: draft-vasseur-mpls-ospf-pcsd-discovery-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Acee, -> My least favorite alternative is allowing the setting of the -> E bit to be optional since it requires implementation of the -> Path-Comp-Server reachability checking in both OSPF and the -> the Path-Comp-Clients. Your take is "do or don't" but not in between option, fine :) From my access networks experience I would like to make a suggestion. There is no application level checking about reachability of any address (look at any transport level protocol, for that matter any distributed applications, for example, MGC-MG communication in MEGACO etc etc) Applications never bother about internal workings of lower layers (ie whether address is dynamic reachable or not) PCC application does one of the following: 1. Limited number of retries with exponential backoff 2. Unlimited number of retries till manual intervention 3. Alternative retries between primary and backup (if there is a backup-PCS configured) Practically there won't be any *reachability checking* in PCC or PCS. Guys, I think the problem is a very simple one. We have had very fruitful discussion. Take is authors. I give up :) -- Venkata From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 9 12:44:38 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02800 for ; Fri, 9 Aug 2002 12:44:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.006C98D4@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 12:45:52 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 86853 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 9 Aug 2002 12:45:49 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 9 Aug 2002 12:35:49 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006C9963@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 12:35:51 -0400 Message-ID: Date: Fri, 9 Aug 2002 12:35:47 -0400 Reply-To: Mailing List Sender: Mailing List From: Bin Liu Subject: Can area routing reduce the routing traffic in OSPF? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hello there, Even though area routing is proposed to reduce the routing traffic, I quite doubt its effect. OSPF is mainly applied for for transit AS in term of its ability to accommodate a large number of external routes. However, as we know, each AS external LSA floods throughout the whole network transparently. So when the majority of LSAs in the database of OSPF router are AS external LSAs, which dominate the amount of link bandwidth consumed by OSPF traffic [OSPF protocol analysis], the benefit of reducing routing traffic by dividing network into areas is seriously undermined. If my inference is right, then 1. What is the benefit of area routing, which makes routing not flexible. 2. Does that the longer update period in OSPF (i.e., 30 minutes between the origination of LSAs) accomplish the work, i.e., reduce routing traffic. Many thanks and looking forward to seeing reply. yours Bin Liu ps. Relevent information In 1991, the number of external LSAs in 15 router NASA Science Internet (NSI) is 496, in another 14 router BARRNet, the number is 1816 [experience with OSPF, RFC 1246]. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 9 12:52:54 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03067 for ; Fri, 9 Aug 2002 12:52:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.006C99C5@cherry.ease.lsoft.com>; Fri, 9 Aug 2002 12:54:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 86983 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 9 Aug 2002 12:54:03 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 9 Aug 2002 12:54:03 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 142E7CAB79 for ; Fri, 9 Aug 2002 09:54:05 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20020809043247.87573.qmail@web40308.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D53F3E6.5000403@redback.com> Date: Fri, 9 Aug 2002 12:55:02 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: NSSA Problem To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Amit Srivastava wrote: > Hi Pat and Acee, > See even if the forwarding address is not set in > the originating AS-external LSA(in the NSSA) the ABR > can know about the router which has originated the LSA > by its router id. So why they are imphasising on > setting of the forwarding address!! > I am still in the same state of confision plz help!! Amit, If the NSSA has multiple ABRs and there is no forwarding address, routers outside the NSSA will always go through the translating ABR independent of whether or not it is the shortest path. Thanks, Acee > Regards > Amit > > > --- "Pat Murphy - (650)329-4044" > wrote: > >>Amit, >> >> >>> I can understand the point mentioned in >>>RFC 2328 about the forwarding address but in this >>> >>case >> >>>I am not able to appreciate the MUST condition the >>>RFC(with Exception when u start aggregating >>> >>multiple >> >>>routes). >>> >>It is true that type 7 LSAs that are aggregated into >>a single >>Type 5 LSA with a 0.0.0.0 forwarding address do not >>need a >>computed forwarding address. But usually an NSSA's >>ASBR has no >>way of knowing whether or not its self-originated >>Type-7 LSAs >>are aggregated by the NSSA's ABRs during >>translation. Without >>providing configuration to the contrary, the NSSA's >>ASBRs MUST >>assume their Type 7 LSAs (with the P-bit set) will >>not be >>aggregated during translation and therefore MUST >>compute a >>non-zero forwarding address. >> >>I don't see much value in complicating the NSSA spec >>by >>softening this requirement for Type 7 range >>aggregations or >>for the case of an NSSA with just a single ABR. Its >>hard to >>imagine any IPv4 application where the forwarding >>address >>cannot be set (IPv6ers care to jump in???). Note >>that when the >>P-bit is clear, the new NSSA spec does allow a Type >>7 LSA to >>have a 0.0.0.0 forwarding address. >> >> >>>An ABR for an NSSA does not generate type 4 >>> >>summaries for >> >>>ASBRs within the NSSA. >>> >>This is because all type 5 LSA translations of type >>7 LSAs are >>originated by NSSA ABRs, not NSSA ASBRs. >> >> >>>Hence a forwarding address is >>>required to compute the best path to the prefix >>>advertised in the translated LSA. >>> >>If the NSSA's ABR translators used a 0.0.0.0 >>forwarding >>address in their Type 5 LSA translations, these Type >>5 LSA >>translations would cause packets to be forwarded >>directly >>through their originating ABR rather than via a >>potentially >>more preferred path through a different NSSA ABR. >>Note that >>this is always the case when type 7 ranges aggregate >>Type 7 >>LSAs into a Type 5 LSA with a 0.0.0.0 forwarding >>address. >> >>Pat >> > > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sat Aug 10 07:03:22 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06647 for ; Sat, 10 Aug 2002 07:03:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.006CB3B0@cherry.ease.lsoft.com>; Sat, 10 Aug 2002 6:30:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 90123 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 10 Aug 2002 06:30:21 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 10 Aug 2002 06:30:21 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Sat, 10 Aug 2002 05:42:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sat, 10 Aug 2002 05:45:03 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Can area routing reduce the routing traffic in OSPF? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Bin, I will try to answer to ur questions. In order for heirarchical routing to scale the amount of information between domains is kept at the minimum. Not all information from EGP is injected to IGP and vice versa. Here is something from one of the mails I had exchanged: - " It seems to be an error to encourage redistribution from other protocols into IGP's. It has been observed every now and again that due to some policy errors that pumping in routes from EGP to IGP causes the entire EGP routing table to be redistributed, which causes instability in the IGP domain. Also unconstrained redistribution from IGP to EGP could cause unwanted exposure of internal domains topology. It is therefore suggested that the primary mechanism to redistribute routes from and to IGP should be by manually configured prefix lists." Yes, area boundaries do not prevent the excess AS-External LSA's, which are flooded as vectors thru out the OSPF domain, however areas do modularize the OSPF domain into smaller units, and prevents flooding of other types(besides type-5 and type-11) of LSA's across these units. There are also some areas The refresh period for OSPF is 30 minutes, we can randomize refresh and can disperse the routing traffic caused by refreshes. Thanks, Vishwas -----Original Message----- From: Bin Liu [mailto:binl@EEE-FS7.BHAM.AC.UK] Sent: Friday, August 09, 2002 10:06 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Can area routing reduce the routing traffic in OSPF? Hello there, Even though area routing is proposed to reduce the routing traffic, I quite doubt its effect. OSPF is mainly applied for for transit AS in term of its ability to accommodate a large number of external routes. However, as we know, each AS external LSA floods throughout the whole network transparently. So when the majority of LSAs in the database of OSPF router are AS external LSAs, which dominate the amount of link bandwidth consumed by OSPF traffic [OSPF protocol analysis], the benefit of reducing routing traffic by dividing network into areas is seriously undermined. If my inference is right, then 1. What is the benefit of area routing, which makes routing not flexible. 2. Does that the longer update period in OSPF (i.e., 30 minutes between the origination of LSAs) accomplish the work, i.e., reduce routing traffic. Many thanks and looking forward to seeing reply. yours Bin Liu ps. Relevent information In 1991, the number of external LSAs in 15 router NASA Science Internet (NSI) is 496, in another 14 router BARRNet, the number is 1816 [experience with OSPF, RFC 1246]. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Aug 12 00:10:45 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29617 for ; Mon, 12 Aug 2002 00:10:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.006CDF95@cherry.ease.lsoft.com>; Mon, 12 Aug 2002 0:11:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 94608 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 12 Aug 2002 00:11:47 -0400 Received: from 66.218.78.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 12 Aug 2002 00:11:47 -0400 Received: from [203.200.20.226] by web40304.mail.yahoo.com via HTTP; Sun, 11 Aug 2002 21:11:46 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020812041146.57827.qmail@web40304.mail.yahoo.com> Date: Sun, 11 Aug 2002 21:11:46 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: NSSA Problem To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3D53F3E6.5000403@redback.com> Precedence: list Hi Acee, I am sorry but i would not agree to your comment See when multiple ABRs are there each of them would have given router LSA in both the Area and when it gets an AS-External LSA it can simply send the LSA to other Area and will also give summary LSA(Type 4) for the LSA. Now the router who will receive this LSA would just do the SPF calculate the shortest ABR and forward the packet to that ABR. That is why i am not able to appriciate the Must condition of having forwarding address in the type 7 LSAs. Regards Amit --- Acee Lindem wrote: > Amit Srivastava wrote: > > > Hi Pat and Acee, > > See even if the forwarding address is not > set in > > the originating AS-external LSA(in the NSSA) the > ABR > > can know about the router which has originated the > LSA > > by its router id. So why they are imphasising on > > setting of the forwarding address!! > > I am still in the same state of confision plz > help!! > > > Amit, > > If the NSSA has multiple ABRs and there is no > forwarding > address, routers outside the NSSA will always go > through > the translating ABR independent of whether or not it > is the shortest path. > > Thanks, > Acee > > > > Regards > > Amit > > > > > > --- "Pat Murphy - (650)329-4044" > > wrote: > > > >>Amit, > >> > >> > >>> I can understand the point mentioned > in > >>>RFC 2328 about the forwarding address but in this > >>> > >>case > >> > >>>I am not able to appreciate the MUST condition > the > >>>RFC(with Exception when u start aggregating > >>> > >>multiple > >> > >>>routes). > >>> > >>It is true that type 7 LSAs that are aggregated > into > >>a single > >>Type 5 LSA with a 0.0.0.0 forwarding address do > not > >>need a > >>computed forwarding address. But usually an NSSA's > >>ASBR has no > >>way of knowing whether or not its self-originated > >>Type-7 LSAs > >>are aggregated by the NSSA's ABRs during > >>translation. Without > >>providing configuration to the contrary, the > NSSA's > >>ASBRs MUST > >>assume their Type 7 LSAs (with the P-bit set) will > >>not be > >>aggregated during translation and therefore MUST > >>compute a > >>non-zero forwarding address. > >> > >>I don't see much value in complicating the NSSA > spec > >>by > >>softening this requirement for Type 7 range > >>aggregations or > >>for the case of an NSSA with just a single ABR. > Its > >>hard to > >>imagine any IPv4 application where the forwarding > >>address > >>cannot be set (IPv6ers care to jump in???). Note > >>that when the > >>P-bit is clear, the new NSSA spec does allow a > Type > >>7 LSA to > >>have a 0.0.0.0 forwarding address. > >> > >> > >>>An ABR for an NSSA does not generate type 4 > >>> > >>summaries for > >> > >>>ASBRs within the NSSA. > >>> > >>This is because all type 5 LSA translations of > type > >>7 LSAs are > >>originated by NSSA ABRs, not NSSA ASBRs. > >> > >> > >>>Hence a forwarding address is > >>>required to compute the best path to the prefix > >>>advertised in the translated LSA. > >>> > >>If the NSSA's ABR translators used a 0.0.0.0 > >>forwarding > >>address in their Type 5 LSA translations, these > Type > >>5 LSA > >>translations would cause packets to be forwarded > >>directly > >>through their originating ABR rather than via a > >>potentially > >>more preferred path through a different NSSA ABR. > >>Note that > >>this is always the case when type 7 ranges > aggregate > >>Type 7 > >>LSAs into a Type 5 LSA with a 0.0.0.0 forwarding > >>address. > >> > >>Pat > >> > > > > > > __________________________________________________ > > Do You Yahoo!? > > HotJobs - Search Thousands of New Jobs > > http://www.hotjobs.com > > > > > > > -- > Acee __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 13 07:42:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08280 for ; Tue, 13 Aug 2002 07:42:08 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.006D12B8@cherry.ease.lsoft.com>; Tue, 13 Aug 2002 7:43:21 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 101759 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 Aug 2002 07:43:20 -0400 Received: from 66.218.78.81 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 13 Aug 2002 07:43:19 -0400 Received: from [203.200.20.226] by web40302.mail.yahoo.com via HTTP; Tue, 13 Aug 2002 04:43:19 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020813114319.27157.qmail@web40302.mail.yahoo.com> Date: Tue, 13 Aug 2002 04:43:19 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Database Overflow problem To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020812041146.57827.qmail@web40304.mail.yahoo.com> Precedence: list Hi All, I have a major doubt regarding the database overflow. If i follow the same approach as mentioned by the RFC 1765 is it becomes necessary that my database will be identical in all the routers(i.e same LSAs in all the router within the AS). Actually i came across a scenario where your database may not be identical even if you have the same ospfExtLsdbLimit variable in all your router. I don't know if it is a bug or is it a normal working condition. If any one know about it plz help Regards Amit __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 13 14:15:06 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12195 for ; Tue, 13 Aug 2002 14:15:06 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.006D2050@cherry.ease.lsoft.com>; Tue, 13 Aug 2002 14:16:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 102793 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 Aug 2002 14:16:18 -0400 Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 13 Aug 2002 14:06:18 -0400 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA00261 for ; Tue, 13 Aug 2002 11:06:22 -0700 (MST)] Received: [from ma07exm03.corp.isg.mot.com (ma07exm03.corp.isg.mot.com [134.33.90.50]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA28718 for ; Tue, 13 Aug 2002 11:06:21 -0700 (MST)] Received: by ma07exm03.corp.isg.mot.com with Internet Mail Service (5.5.2654.52) id ; Tue, 13 Aug 2002 14:06:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C242F4.1A941140" Message-ID: <05F679A54DF3D51188100008C7919756D38AED@ma07exm03.corp.isg.mot.com> Date: Tue, 13 Aug 2002 14:06:10 -0400 Reply-To: Mailing List Sender: Mailing List From: Eastlake III Donald-LDE008 Subject: OSPF cryptographic authentication keying To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C242F4.1A941140 Content-Type: text/plain; charset="iso-8859-1" Hi, I have a couple of questions about how keying is established for OSPF cryptographic authentication: First of all, which may be a stupid questions, I have the impression the keying is essentially on a pairwise basis, rather than a key being shared among all the entities in an area. Is that correct? Second, how are these keys normally established in today's operational world? I realize this is a bit outside of the scope of OSPF, but do people use manual entry, SNMP, some negotiation framework like ISAKMP, or what? Thanks, Donald Donald E. Eastlake 3rd, +1-508-851-8280 (voice), +1-508-851-8507 (fax) Motorola, MS: M2-450, 20 Cabot Boulevard, Mansfield, MA 02048 USA ------_=_NextPart_000_01C242F4.1A941140 Content-Type: application/octet-stream; name="Eastlake Donald-LDE008.vcf" Content-Disposition: attachment; filename="Eastlake Donald-LDE008.vcf" BEGIN:VCARD VERSION:2.1 N:Eastlake;Donald FN:Eastlake Donald-LDE008 NOTE:MA07 - ADR;WORK:;Mansfield LABEL;WORK:Mansfield EMAIL;PREF;INTERNET:Donald.Eastlake@motorola.com REV:20000427T143309Z END:VCARD ------_=_NextPart_000_01C242F4.1A941140-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 13 14:43:38 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13249 for ; Tue, 13 Aug 2002 14:43:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006D2157@cherry.ease.lsoft.com>; Tue, 13 Aug 2002 14:44:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 102874 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 13 Aug 2002 14:44:50 -0400 Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 13 Aug 2002 14:44:50 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA27732 for ; Tue, 13 Aug 2002 11:44:54 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7DIirk16884 for ; Tue, 13 Aug 2002 11:44:53 -0700 X-mProtect: <200208131844> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.19.66.85, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrBUrYb; Tue, 13 Aug 2002 11:44:51 PDT X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <05F679A54DF3D51188100008C7919756D38AED@ma07exm03.corp.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D5953A3.5064A4BF@iprg.nokia.com> Date: Tue, 13 Aug 2002 11:44:51 -0700 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Organization: Nokia Subject: Re: OSPF cryptographic authentication keying To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit > I have a couple of questions about how keying is established for OSPF > cryptographic authentication: I am assuming that you are talking about OSPFv2. > First of all, which may be a stupid questions, I have the impression the > keying is essentially on a pairwise basis, rather than a key being shared > among all the entities in an area. Is that correct? To my knowledge, No. It is not correct. The keys are shared between all the entities in an area and they are not on a pairwise basis. Using pairwise keys in the multicast environment will not work. > Second, how are these keys normally established in today's operational > world? I realize this is a bit outside of the scope of OSPF, but do people > use manual entry, SNMP, some negotiation framework like ISAKMP, or what? I think, most of the implementations use manual entry. ISAKMP wouldn't be easy to use in the multicast environment OSPF uses. Key negotiation mechanisms for multicast are still being explored. regards Mukesh -- ****************************************************************** Work fascinates me. I can look at it for hours ! ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 14 04:51:31 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01166 for ; Wed, 14 Aug 2002 04:51:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.006D3540@cherry.ease.lsoft.com>; Wed, 14 Aug 2002 4:52:47 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 104392 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 Aug 2002 04:52:38 -0400 Received: from 205.158.62.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 14 Aug 2002 04:52:36 -0400 Received: (qmail 96791 invoked by uid 1001); 14 Aug 2002 08:50:42 -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 [129.187.254.13] by ws1-3.us4.outblaze.com with http for beatriz_hargrave@mail.com; Wed, 14 Aug 2002 03:50:42 -0500 X-Originating-Ip: 129.187.254.13 X-Originating-Server: ws1-3.us4.outblaze.com Message-ID: <20020814085042.96790.qmail@mail.com> Date: Wed, 14 Aug 2002 03:50:42 -0500 Reply-To: Mailing List Sender: Mailing List From: Beatriz Silva Subject: new LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi everybody ! I would like to know if it is possible (in OSPF v2) to identify, just by examining the LSA, what is the change the LSA is signaling. I want to identify if for example an router LSA was sent because the cost of one of the links was changed, or if it was because one of the links went down .... This, without having the previous LSAs, just by looking at the newly received LSA. Is it possible ? How ? Thank you very much, Beatriz -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 14 09:49:09 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08988 for ; Wed, 14 Aug 2002 09:49:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.006D3A40@cherry.ease.lsoft.com>; Wed, 14 Aug 2002 9:50:20 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 106618 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 Aug 2002 09:50:17 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 14 Aug 2002 09:50:15 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 579F11DCC72 for ; Wed, 14 Aug 2002 06:50:14 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20020812041146.57827.qmail@web40304.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D5A600F.9000508@redback.com> Date: Wed, 14 Aug 2002 09:50:07 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: NSSA Problem To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Amit Srivastava wrote: > Hi Acee, > I am sorry but i would not agree to your comment > See when multiple ABRs are there each of them would > have given router LSA in both the Area and when it > gets an AS-External LSA it can simply send the LSA to > other Area and will also give summary LSA(Type 4) for > the LSA. Amit, But an ABR for an NSSA does not generate type 4 summaries for ASBRs originating type 7 LSAs within the NSSA. This is clarified in section 2.3 of draft-ietf-ospf-nssa-update-11.txt. This design point is consistent with the goal of isolating the NSSA from the rest of the OSPF routing domain. Thanks, ACee > Now the router who will receive this LSA > would just do the SPF calculate the shortest ABR and > forward the packet to that ABR. > That is why i am not able to appriciate the > Must condition of having forwarding address in the > type 7 LSAs. > Regards > Amit > > --- Acee Lindem wrote: > >>Amit Srivastava wrote: >> >> >>>Hi Pat and Acee, >>> See even if the forwarding address is not >>> >>set in >> >>>the originating AS-external LSA(in the NSSA) the >>> >>ABR >> >>>can know about the router which has originated the >>> >>LSA >> >>>by its router id. So why they are imphasising on >>>setting of the forwarding address!! >>>I am still in the same state of confision plz >>> >>help!! >> >> >>Amit, >> >>If the NSSA has multiple ABRs and there is no >>forwarding >>address, routers outside the NSSA will always go >>through >>the translating ABR independent of whether or not it >>is the shortest path. >> >>Thanks, >>Acee >> >> >> >>>Regards >>>Amit >>> >>> >>>--- "Pat Murphy - (650)329-4044" >>> wrote: >>> >>> >>>>Amit, >>>> >>>> >>>> >>>>> I can understand the point mentioned >>>>> >>in >> >>>>>RFC 2328 about the forwarding address but in this >>>>> >>>>> >>>>case >>>> >>>> >>>>>I am not able to appreciate the MUST condition >>>>> >>the >> >>>>>RFC(with Exception when u start aggregating >>>>> >>>>> >>>>multiple >>>> >>>> >>>>>routes). >>>>> >>>>> >>>>It is true that type 7 LSAs that are aggregated >>>> >>into >> >>>>a single >>>>Type 5 LSA with a 0.0.0.0 forwarding address do >>>> >>not >> >>>>need a >>>>computed forwarding address. But usually an NSSA's >>>>ASBR has no >>>>way of knowing whether or not its self-originated >>>>Type-7 LSAs >>>>are aggregated by the NSSA's ABRs during >>>>translation. Without >>>>providing configuration to the contrary, the >>>> >>NSSA's >> >>>>ASBRs MUST >>>>assume their Type 7 LSAs (with the P-bit set) will >>>>not be >>>>aggregated during translation and therefore MUST >>>>compute a >>>>non-zero forwarding address. >>>> >>>>I don't see much value in complicating the NSSA >>>> >>spec >> >>>>by >>>>softening this requirement for Type 7 range >>>>aggregations or >>>>for the case of an NSSA with just a single ABR. >>>> >>Its >> >>>>hard to >>>>imagine any IPv4 application where the forwarding >>>>address >>>>cannot be set (IPv6ers care to jump in???). Note >>>>that when the >>>>P-bit is clear, the new NSSA spec does allow a >>>> >>Type >> >>>>7 LSA to >>>>have a 0.0.0.0 forwarding address. >>>> >>>> >>>> >>>>>An ABR for an NSSA does not generate type 4 >>>>> >>>>> >>>>summaries for >>>> >>>> >>>>>ASBRs within the NSSA. >>>>> >>>>> >>>>This is because all type 5 LSA translations of >>>> >>type >> >>>>7 LSAs are >>>>originated by NSSA ABRs, not NSSA ASBRs. >>>> >>>> >>>> >>>>>Hence a forwarding address is >>>>>required to compute the best path to the prefix >>>>>advertised in the translated LSA. >>>>> >>>>> >>>>If the NSSA's ABR translators used a 0.0.0.0 >>>>forwarding >>>>address in their Type 5 LSA translations, these >>>> >>Type >> >>>>5 LSA >>>>translations would cause packets to be forwarded >>>>directly >>>>through their originating ABR rather than via a >>>>potentially >>>>more preferred path through a different NSSA ABR. >>>>Note that >>>>this is always the case when type 7 ranges >>>> >>aggregate >> >>>>Type 7 >>>>LSAs into a Type 5 LSA with a 0.0.0.0 forwarding >>>>address. >>>> >>>>Pat >>>> >>>> >>> >>>__________________________________________________ >>>Do You Yahoo!? >>>HotJobs - Search Thousands of New Jobs >>>http://www.hotjobs.com >>> >>> >>> >> >>-- >>Acee >> > > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 14 10:10:57 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09770 for ; Wed, 14 Aug 2002 10:10:57 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006D3A93@cherry.ease.lsoft.com>; Wed, 14 Aug 2002 10:12:14 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 106665 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 Aug 2002 10:12:10 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 14 Aug 2002 10:12:09 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id C0D571DCC72 for ; Wed, 14 Aug 2002 07:12:07 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <05F679A54DF3D51188100008C7919756D38AED@ma07exm03.corp.isg.mot.com> <3D5953A3.5064A4BF@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D5A6530.8020102@redback.com> Date: Wed, 14 Aug 2002 10:12:00 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF cryptographic authentication keying To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mukesh Gupta wrote: >>I have a couple of questions about how keying is established for OSPF >>cryptographic authentication: >> > > I am assuming that you are talking about OSPFv2. > > >>First of all, which may be a stupid questions, I have the impression the >>keying is essentially on a pairwise basis, rather than a key being shared >>among all the entities in an area. Is that correct? >> > > To my knowledge, No. It is not correct. The keys are shared between all the > entities in an area and they are not on a pairwise basis. Mukesh, Keys need only be shared on a per-interface basis. The specification of authentication type per interface (as opposed to per area) was introduced between RFCs 1583 and 2178. Thanks, Acee > Using pairwise keys > in the multicast environment will not work. > > >>Second, how are these keys normally established in today's operational >>world? I realize this is a bit outside of the scope of OSPF, but do people >>use manual entry, SNMP, some negotiation framework like ISAKMP, or what? >> > > I think, most of the implementations use manual entry. ISAKMP wouldn't be easy > to use in the multicast environment OSPF uses. Key negotiation mechanisms for > multicast are still being explored. > > regards > Mukesh > > -- > ****************************************************************** > Work fascinates me. I can look at it for hours ! > ****************************************************************** > Mukesh Gupta > Phone: (650) 625-2264 > Cell : (650) 868-9111 > http://www.iprg.nokia.com/~mgupta > ****************************************************************** > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 14 10:20:59 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10355 for ; Wed, 14 Aug 2002 10:20:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.006D3BB1@cherry.ease.lsoft.com>; Wed, 14 Aug 2002 10:22:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 106746 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 Aug 2002 10:22:13 -0400 Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 14 Aug 2002 10:22:12 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA17834 for ; Wed, 14 Aug 2002 07:22:11 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7EEMAg17330 for ; Wed, 14 Aug 2002 07:22:10 -0700 X-mProtect: <200208141422> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.7.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0fHV4A; Wed, 14 Aug 2002 07:22:08 PDT X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <05F679A54DF3D51188100008C7919756D38AED@ma07exm03.corp.isg.mot.com> <3D5953A3.5064A4BF@iprg.nokia.com> <3D5A6530.8020102@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D5A67B9.95058DD1@iprg.nokia.com> Date: Wed, 14 Aug 2002 07:22:49 -0700 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Organization: Nokia IPRG Subject: Re: OSPF cryptographic authentication keying To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit > Keys need only be shared on a per-interface basis. The specification of > authentication type per interface (as opposed to per area) was introduced > between RFCs 1583 and 2178. Oops !! my bad. I was focussing on the keys being shared between multiple neighbours and made a wrong statement. Yeah, the keys are shared on a per-interface basis. Thanks for correcting me. regards Mukesh From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 14 10:21:59 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10373 for ; Wed, 14 Aug 2002 10:21:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.006D3C29@cherry.ease.lsoft.com>; Wed, 14 Aug 2002 10:23:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 106763 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 Aug 2002 10:23:15 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 14 Aug 2002 10:23:15 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id C32B839B5AD for ; Wed, 14 Aug 2002 07:23:13 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20020813114319.27157.qmail@web40302.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D5A67CA.2000508@redback.com> Date: Wed, 14 Aug 2002 10:23:06 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Database Overflow problem To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Amit Srivastava wrote: > Hi All, > I have a major doubt regarding the database > overflow. > If i follow the same approach as mentioned by the RFC > 1765 is it becomes necessary that my database will be > identical in all the routers(i.e same LSAs in all the > router within the AS). > Actually i came across a scenario where your database > may not be identical even if you have the same > ospfExtLsdbLimit variable in all your router. > I don't know if it is a bug or is it a normal working > condition. > If any one know about it plz help Amit, Sounds like a bug to me. Make sure you're not acknowledging any LSAs that you drop due to reaching ospfExtLsdbLimit. Good Luck, Acee > Regards > Amit > > > __________________________________________________ > Do You Yahoo!? > HotJobs - Search Thousands of New Jobs > http://www.hotjobs.com > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 14 11:05:52 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12580 for ; Wed, 14 Aug 2002 11:05:52 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.006D3D42@cherry.ease.lsoft.com>; Wed, 14 Aug 2002 11:07:10 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 106839 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 Aug 2002 11:07:07 -0400 Received: from 144.189.100.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 14 Aug 2002 11:07:06 -0400 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id IAA23501 for ; Wed, 14 Aug 2002 08:07:05 -0700 (MST)] Received: [from ma07exm03.corp.isg.mot.com (ma07exm03.corp.isg.mot.com [134.33.90.50]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id IAA01902 for ; Wed, 14 Aug 2002 08:07:05 -0700 (MST)] Received: by ma07exm03.corp.isg.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 14 Aug 2002 11:07:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <05F679A54DF3D51188100008C7919756D38AF4@ma07exm03.corp.isg.mot.com> Date: Wed, 14 Aug 2002 11:07:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Eastlake III Donald-LDE008 Subject: Re: OSPF cryptographic authentication keying To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Mukesh, Yes, I was talking about OSPFv2. Thanks for your response but, given that in today's world the shared key is usually set up "manually", what method is most commonly used? SSH or Secure Telnet to a Command Line Interface? SNMP? TLS to a web interface? Do routers usually have two or three ways it can be done? As I say, I realize this isn't strictly part of the OSPFv2 protocol but would appreciate any information people can provide. Thanks, Donald Date: Tue, 13 Aug 2002 14:06:10 -0400 From: Eastlake III Donald-LDE008 Subject: OSPF cryptographic authentication keying Hi, I have a couple of questions about how keying is established for OSPF cryptographic authentication: First of all, which may be a stupid questions, I have the impression the keying is essentially on a pairwise basis, rather than a key being shared among all the entities in an area. Is that correct? Second, how are these keys normally established in today's operational world? I realize this is a bit outside of the scope of OSPF, but do people use manual entry, SNMP, some negotiation framework like ISAKMP, or what? Thanks, Donald Donald E. Eastlake 3rd, +1-508-851-8280 (voice), +1-508-851-8507 (fax) Motorola, MS: M2-450, 20 Cabot Boulevard, Mansfield, MA 02048 USA ------------------------------ Date: Tue, 13 Aug 2002 11:44:51 -0700 From: Mukesh Gupta Subject: Re: OSPF cryptographic authentication keying > I have a couple of questions about how keying is established for OSPF > cryptographic authentication: I am assuming that you are talking about OSPFv2. > First of all, which may be a stupid questions, I have the impression the > keying is essentially on a pairwise basis, rather than a key being shared > among all the entities in an area. Is that correct? To my knowledge, No. It is not correct. The keys are shared between all the entities in an area and they are not on a pairwise basis. Using pairwise keys in the multicast environment will not work. > Second, how are these keys normally established in today's operational > world? I realize this is a bit outside of the scope of OSPF, but do people > use manual entry, SNMP, some negotiation framework like ISAKMP, or what? I think, most of the implementations use manual entry. ISAKMP wouldn't be easy to use in the multicast environment OSPF uses. Key negotiation mechanisms for multicast are still being explored. regards Mukesh -- ****************************************************************** Work fascinates me. I can look at it for hours ! ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 14 12:29:51 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15814 for ; Wed, 14 Aug 2002 12:29:49 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.006D4003@cherry.ease.lsoft.com>; Wed, 14 Aug 2002 12:31:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 106997 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 Aug 2002 12:31:06 -0400 Received: from 147.188.128.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 14 Aug 2002 12:31:06 -0400 Received: from bham.ac.uk ([147.188.128.127]) by mailer3.bham.ac.uk with esmtp (Exim 3.16 #2) id 17f133-00074c-00 for OSPF@discuss.microsoft.com; Wed, 14 Aug 2002 17:31:05 +0100 Received: from eee-fs7.bham.ac.uk ([147.188.145.131] helo=bham-eee-fs7.bham.ac.uk) by bham.ac.uk with esmtp (Exim 3.16 #3) id 17f133-0002Jy-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 Aug 2002 17:31:05 +0100 Received: by BHAM-EEE-FS7 with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Aug 2002 17:31:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 14 Aug 2002 17:31:04 +0100 Reply-To: Mailing List Sender: Mailing List From: "Liu B." Subject: Re: Can area routing reduce the routing traffic in OSPF? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Thanks, Vishwas. So, can I conclude as this: a low routing cost in OSPF mainly depends on manually configured prefix lists (to limit redistribution of AS external LSAs) and long refresh period. In other words, in a dynamic network environment (not OPSF domain itself, i.e., AS external LSAs are highly frequently generated), OSPF routing protocol is not suitable in term of its not negligible routing cost in that case. Any experience on how to control routing cost in real network administration is more than appreciated, as well as literatures. Thanks again for everybody's time and help. yours Bin -----Original Message----- From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] Sent: 10 August 2002 10:45 To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Can area routing reduce the routing traffic in OSPF? Hi Bin, I will try to answer to ur questions. In order for heirarchical routing to scale the amount of information between domains is kept at the minimum. Not all information from EGP is injected to IGP and vice versa. Here is something from one of the mails I had exchanged: - " It seems to be an error to encourage redistribution from other protocols into IGP's. It has been observed every now and again that due to some policy errors that pumping in routes from EGP to IGP causes the entire EGP routing table to be redistributed, which causes instability in the IGP domain. Also unconstrained redistribution from IGP to EGP could cause unwanted exposure of internal domains topology. It is therefore suggested that the primary mechanism to redistribute routes from and to IGP should be by manually configured prefix lists." Yes, area boundaries do not prevent the excess AS-External LSA's, which are flooded as vectors thru out the OSPF domain, however areas do modularize the OSPF domain into smaller units, and prevents flooding of other types(besides type-5 and type-11) of LSA's across these units. There are also some areas The refresh period for OSPF is 30 minutes, we can randomize refresh and can disperse the routing traffic caused by refreshes. Thanks, Vishwas -----Original Message----- From: Bin Liu [mailto:binl@EEE-FS7.BHAM.AC.UK] Sent: Friday, August 09, 2002 10:06 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Can area routing reduce the routing traffic in OSPF? Hello there, Even though area routing is proposed to reduce the routing traffic, I quite doubt its effect. OSPF is mainly applied for for transit AS in term of its ability to accommodate a large number of external routes. However, as we know, each AS external LSA floods throughout the whole network transparently. So when the majority of LSAs in the database of OSPF router are AS external LSAs, which dominate the amount of link bandwidth consumed by OSPF traffic [OSPF protocol analysis], the benefit of reducing routing traffic by dividing network into areas is seriously undermined. If my inference is right, then 1. What is the benefit of area routing, which makes routing not flexible. 2. Does that the longer update period in OSPF (i.e., 30 minutes between the origination of LSAs) accomplish the work, i.e., reduce routing traffic. Many thanks and looking forward to seeing reply. yours Bin Liu ps. Relevent information In 1991, the number of external LSAs in 15 router NASA Science Internet (NSI) is 496, in another 14 router BARRNet, the number is 1816 [experience with OSPF, RFC 1246]. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 14 12:45:41 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16441 for ; Wed, 14 Aug 2002 12:45:40 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006D4005@cherry.ease.lsoft.com>; Wed, 14 Aug 2002 12:46:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 107036 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 Aug 2002 12:46:59 -0400 Received: from 147.188.128.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 14 Aug 2002 12:46:59 -0400 Received: from bham.ac.uk ([147.188.128.127]) by mailer3.bham.ac.uk with esmtp (Exim 3.16 #2) id 17f1IQ-00009W-00 for OSPF@discuss.microsoft.com; Wed, 14 Aug 2002 17:46:58 +0100 Received: from eee-fs7.bham.ac.uk ([147.188.145.131] helo=bham-eee-fs7.bham.ac.uk) by bham.ac.uk with esmtp (Exim 3.16 #3) id 17f1IQ-0005x3-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 Aug 2002 17:46:58 +0100 Received: by BHAM-EEE-FS7 with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Aug 2002 17:46:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 14 Aug 2002 17:46:57 +0100 Reply-To: Mailing List Sender: Mailing List From: "Liu B." Subject: Why recalculation from scratch? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hello there, I noticed that in "The New Routing Algorithm for the ARPANET" [John M. McQuillan], lots of work had been done on how to avoid recalculation from scratch in link state routing. Why OSPF does recalculate from scratch? Does it mean that CPU cost is negligible? Many thanks. Bin From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 14 23:03:39 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02402 for ; Wed, 14 Aug 2002 23:03:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.006D5797@cherry.ease.lsoft.com>; Wed, 14 Aug 2002 23:04:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 108475 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 Aug 2002 23:04:52 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 14 Aug 2002 23:04:52 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.006D585D@cherry.ease.lsoft.com>; Wed, 14 Aug 2002 23:04:57 -0400 Message-ID: Date: Wed, 14 Aug 2002 23:04:52 -0400 Reply-To: Mailing List Sender: Mailing List From: Jing Shen Subject: Re: Why recalculation from scratch? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Bin Liu, The first, router does not maintains all information as human does. the second, each router computes its routing table on its view of network. When state of some links varies, the logical view of network changes and the shortest path tree of the graph may become a totally new one; the third, as link state propagates by relaying hop by hop, it can not be expected that every router update their routing table simulataneously, so each time a new link state is received the routing table must be recomputed to guarantee the convergence. Of course, in a network with thousands of prefix such computing need a lot of CPU time but it's just one of the key reasons. IMO, Route flapping and looping is the factors attracting more attention. Cheers Jing Shen From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 14 23:28:45 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02927 for ; Wed, 14 Aug 2002 23:28:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006D585A@cherry.ease.lsoft.com>; Wed, 14 Aug 2002 23:30:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 108537 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 Aug 2002 23:30:01 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 14 Aug 2002 23:30:01 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 6CE601DCC66 for ; Wed, 14 Aug 2002 20:30:00 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20020814085042.96790.qmail@mail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D5B2086.9000906@redback.com> Date: Wed, 14 Aug 2002 23:31:18 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: new LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Beatriz Silva wrote: > Hi everybody ! > > I would like to know if it is possible (in OSPF v2) to identify, just by examining the LSA, what is the change the LSA is signaling. I want to identify if for example an router LSA was sent because the cost of one of the links was changed, or if it was because one of the links went down .... This, without having the previous LSAs, just by looking at the newly received LSA. Is it possible ? How ? > Beatriz, AFAIK, there is no way to determine what has changed without a previous version of the LSA. > Thank you very much, > Beatriz > > -- > __________________________________________________________ > Sign-up for your own FREE Personalized E-mail at Mail.com > http://www.mail.com/?sr=signup > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 02:15:02 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14504 for ; Thu, 15 Aug 2002 02:15:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.006D5EDE@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 2:16:19 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 108926 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 02:16:17 -0400 Received: from 207.217.120.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 02:16:17 -0400 Received: from user-2ivfj2i.dialup.mindspring.com ([165.247.204.82] helo=earthlink.net) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fDvd-0003Cn-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 14 Aug 2002 23:16:17 -0700 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: <20020814085042.96790.qmail@mail.com> <3D5B2086.9000906@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D5B49F8.A518DA7@earthlink.net> Date: Wed, 14 Aug 2002 23:28:08 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: new LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, Lets assume that we modify the LSA comparison code sections and we keep the older LSA versions for a short time assuming we have the memory available. What would you say we can now do with this additional information? Mitchell Erblich =================== Acee Lindem wrote: > > Beatriz Silva wrote: > > > Hi everybody ! > > > > I would like to know if it is possible (in OSPF v2) to identify, just by examining the LSA, what is the change the LSA is signaling. I want to identify if for example an router LSA was sent because the cost of one of the links was changed, or if it was because one of the links went down .... This, without having the previous LSAs, just by looking at the newly received LSA. Is it possible ? How ? > > > > Beatriz, > > AFAIK, there is no way to determine what has changed without a previous version > of the LSA. > > > Thank you very much, > > Beatriz > > > > -- > > __________________________________________________________ > > Sign-up for your own FREE Personalized E-mail at Mail.com > > http://www.mail.com/?sr=signup > > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 02:26:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14775 for ; Thu, 15 Aug 2002 02:26:32 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006D5DF4@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 2:27:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 108958 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 02:27:49 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 02:27:48 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id DF1C01DCC77 for ; Wed, 14 Aug 2002 23:27:48 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20020814085042.96790.qmail@mail.com> <3D5B2086.9000906@redback.com> <3D5B49F8.A518DA7@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D5B4A31.4050901@redback.com> Date: Thu, 15 Aug 2002 02:29:05 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: new LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > Acee, > > Lets assume that we modify the LSA comparison code sections > and we keep the older LSA versions for a short time assuming > we have the memory available. Mitchell, Wasn't the original question whether this could be done without the previous LSA? > > What would you say we can now do with this additional information? If you had the previous LSA you could definitely determine what had changed between the two versions. > > Mitchell Erblich > =================== > > > Acee Lindem wrote: > >>Beatriz Silva wrote: >> >> >>>Hi everybody ! >>> >>>I would like to know if it is possible (in OSPF v2) to identify, just by examining the LSA, what is the change the LSA is signaling. I want to identify if for example an router LSA was sent because the cost of one of the links was changed, or if it was because one of the links went down .... This, without having the previous LSAs, just by looking at the newly received LSA. Is it possible ? How ? >>> >>> >>Beatriz, >> >>AFAIK, there is no way to determine what has changed without a previous version >>of the LSA. >> >> >>>Thank you very much, >>>Beatriz >>> >>>-- >>>__________________________________________________________ >>>Sign-up for your own FREE Personalized E-mail at Mail.com >>>http://www.mail.com/?sr=signup >>> >>> >>> >>-- >>Acee >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 02:33:42 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14966 for ; Thu, 15 Aug 2002 02:33:42 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006D5EB9@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 2:34:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 108989 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 02:34:55 -0400 Received: from 129.188.136.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 02:34:55 -0400 Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id XAA23757 for ; Wed, 14 Aug 2002 23:34:57 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id XAA25932 for ; Wed, 14 Aug 2002 23:34:50 -0700 (MST)] Received: from arc.corp.mot.com (arthurd.arc.corp.mot.com [10.238.80.59]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g7F6Yn7C006114 for ; Thu, 15 Aug 2002 16:34:49 +1000 (EST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D5B4B88.215EA127@arc.corp.mot.com> Date: Thu, 15 Aug 2002 16:34:49 +1000 Reply-To: Mailing List Sender: Mailing List From: Arthur Dimitrelis Subject: Routing IPv4 with OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Greetings, I'm interested in people's opinions and experiences in using OSPFv3 (aka OSPF for IPv6) for routing IPv4. My understanding from reading the OSPFv3 specification (RFC2740) is that OSPFv3 is designed with a degree of protocol independence. By this I mean that you could, in principle, use OSPFv3 to route any protocol family you chose, just so long as you were able to map addressing information to the topology (and of course your OSPF code knew how to set up the correct forwarding state for your given protocol family). The topology-to-address mapping for IPv6 is done using OSPFv3's Intra-area-prefix-LSAs, but the spec makes no mention of how you might map IPv4 addressing information to a network topology. So, my questions are: - Regarding OSPFv3 - is the bulk of it protocol agnostic, or is it just my imagination? Was it the intention of the protocol authors to create a protocol that could easily route multiple protocol families, or just IPv6? - Is there any interest out there in using OSPFv3 to route IPv4? - Do people think it is a good idea in general to have a single protocol route both v4 and v6? (I'm guessing that there are those out there who think that OSPFv2 works just fine so why would you want to change it . . . ) And while I'm at it, are there any such things as Opaque LSAs for OSPFv3? cheers, Arthur From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 03:06:38 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15484 for ; Thu, 15 Aug 2002 03:06:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006D5E56@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 3:07:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109077 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 03:07:54 -0400 Received: from 207.217.120.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 03:07:54 -0400 Received: from user-2ivfj2i.dialup.mindspring.com ([165.247.204.82] helo=earthlink.net) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fEjb-00026T-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 00:07:55 -0700 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: <20020814085042.96790.qmail@mail.com> <3D5B2086.9000906@redback.com> <3D5B49F8.A518DA7@earthlink.net> <3D5B4A31.4050901@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D5B5612.D3F43030@earthlink.net> Date: Thu, 15 Aug 2002 00:19:46 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: new LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, Then what would / could you do with this information? Could it be useful in anyway? Have you ever heard of anyone really interested in this type of information? Mitchell Erblich ====================== Acee Lindem wrote: > > Erblichs wrote: > > > Acee, > > > > Lets assume that we modify the LSA comparison code sections > > and we keep the older LSA versions for a short time assuming > > we have the memory available. > > Mitchell, > > Wasn't the original question whether this could be done without the > previous LSA? > > > > > What would you say we can now do with this additional information? > > If you had the previous LSA you could definitely determine what had > changed between the two versions. > > > > > Mitchell Erblich > > =================== > > > > > > Acee Lindem wrote: > > > >>Beatriz Silva wrote: > >> > >> > >>>Hi everybody ! > >>> > >>>I would like to know if it is possible (in OSPF v2) to identify, just by examining the LSA, what is the change the LSA is signaling. I want to identify if for example an router LSA was sent because the cost of one of the links was changed, or if it was because one of the links went down .... This, without having the previous LSAs, just by looking at the newly received LSA. Is it possible ? How ? > >>> > >>> > >>Beatriz, > >> > >>AFAIK, there is no way to determine what has changed without a previous version > >>of the LSA. > >> > >> > >>>Thank you very much, > >>>Beatriz > >>> > >>>-- > >>>__________________________________________________________ > >>>Sign-up for your own FREE Personalized E-mail at Mail.com > >>>http://www.mail.com/?sr=signup > >>> > >>> > >>> > >>-- > >>Acee > >> > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 03:29:37 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15831 for ; Thu, 15 Aug 2002 03:29:37 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006D5E67@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 3:30:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109154 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 03:30:53 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 03:30:53 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id F06355D019; Thu, 15 Aug 2002 16:29:49 +0900 (JST) References: X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020815.162132.64931757.yasu@sfc.wide.ad.jp> Date: Thu, 15 Aug 2002 16:21:32 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Why recalculation from scratch? Comments: To: jshen@CAD.ZJU.EDU.CN To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi, Related to this, I wonder why the congestion-control draft saying "do not do incremental SPF when congested" (in 4.2.2.4 Reduce the Rate of SPF Computation). Could you give me some more explanation or a reference pointer, authors ? IMHO simply we're just negative to have a lot of state informations, though there are some ways to avoid recalculation from scratch (i.e. incremental SPF calculation). regards. yasu jshen> Bin Liu, jshen> jshen> The first, router does not maintains all information as human does. jshen> the second, each router computes its routing table on its view of network. jshen> When state of some links varies, the logical view of network changes jshen> and the shortest path tree of the graph may become a totally new one; jshen> the third, as link state propagates by relaying hop by hop, it can not jshen> be expected that every router update their routing table simulataneously, jshen> so each time a new link state is received the routing table must be jshen> recomputed jshen> to guarantee the convergence. jshen> jshen> Of course, in a network with thousands of prefix such computing need a lot jshen> of jshen> CPU time but it's just one of the key reasons. IMO, Route flapping and jshen> looping is jshen> the factors attracting more attention. jshen> jshen> Cheers jshen> jshen> Jing Shen From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 03:34:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15907 for ; Thu, 15 Aug 2002 03:34:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.006D6023@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 3:35:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109183 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 03:35:25 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 03:35:25 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 50826F2C58; Thu, 15 Aug 2002 00:35:27 -0700 (PDT) Message-ID: <20020815073527.50826F2C58@prattle.redback.com> Date: Thu, 15 Aug 2002 00:35:27 -0700 Reply-To: Mailing List Sender: Mailing List From: Naiming Shen Subject: Re: new LSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Mail from Erblichs dated Thu, 15 Aug 2002 00:19:46 PDT <3D5B5612.D3F43030@earthlink.net> Precedence: list I can think of some ways to use this info. For example, if we know there is a link down from that new LSA, then we may want to trigger an immediate calculation for the fast convergence purpose; if we know there is an interface IP address change, who cares, data usually are not forwarded to a backbone link anyway, we'll run the spf when we have spare time; if we know A to B has two ECMP links and one of them is up/down, there is nothing needs to be done, since even we re-run the calculation, the results are got to be the same. Now whether if people want to take such an "active" approach is up to the implementors. we can argue either ways to the pros and cons. cheers. ] Acee, ] ] Then what would / could you do with this information? Could it ] be useful in anyway? Have you ever heard of anyone really ] interested in this type of information? ] ] Mitchell Erblich ] ====================== ] ] ] Acee Lindem wrote: ] > ] > Erblichs wrote: ] > ] > > Acee, ] > > ] > > Lets assume that we modify the LSA comparison code sections ] > > and we keep the older LSA versions for a short time assuming ] > > we have the memory available. ] > ] > Mitchell, ] > ] > Wasn't the original question whether this could be done without the ] > previous LSA? ] > ] > > ] > > What would you say we can now do with this additional informatio n? ] > ] > If you had the previous LSA you could definitely determine what had ] > changed between the two versions. ] > ] > > ] > > Mitchell Erblich ] > > =================== ] > > ] > > ] > > Acee Lindem wrote: ] > > ] > >>Beatriz Silva wrote: ] > >> ] > >> ] > >>>Hi everybody ! ] > >>> ] > >>>I would like to know if it is possible (in OSPF v2) to identify, just b y examining the LSA, what is the change the LSA is signaling. I want to identif y if for example an router LSA was sent because the cost of one of the links wa s changed, or if it was because one of the links went down .... This, without h aving the previous LSAs, just by looking at the newly received LSA. Is it possi ble ? How ? ] > >>> ] > >>> ] > >>Beatriz, ] > >> ] > >>AFAIK, there is no way to determine what has changed without a previous version ] > >>of the LSA. ] > >> ] > >> ] > >>>Thank you very much, ] > >>>Beatriz ] > >>> ] > >>>-- ] > >>>__________________________________________________________ ] > >>>Sign-up for your own FREE Personalized E-mail at Mail.com ] > >>>http://www.mail.com/?sr=signup ] > >>> ] > >>> ] > >>> ] > >>-- ] > >>Acee ] > >> ] > > ] > ] > -- ] > Acee - Naiming From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 03:43:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16184 for ; Thu, 15 Aug 2002 03:43:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.006D5E6D@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 3:45:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109212 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 03:45:02 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 03:45:01 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Aug 2002 03:45:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 15 Aug 2002 03:47:27 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Why recalculation from scratch? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Yasu, The idea is this. When we are under high-congestion, we are in a state where the topology information on the router is incomplete/out of date, doing incremental SPF only further loads the CPU. So instead of doing incremental SPF with every change, we instead club changes and do the entire SPF after a longer period of time, which anyway is best effort(because of databse discrepancies). Also check ISO10589, it states that the CPU load for two incremental SPF's can be as much as a single SPF, I dont remember the section though(probably in the Annex somewhere). However I remember conflicting numbers being presented at NANOG. Thanks, Vishwas -----Original Message----- From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] Sent: Thursday, August 15, 2002 12:52 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Why recalculation from scratch? Hi, Related to this, I wonder why the congestion-control draft saying "do not do incremental SPF when congested" (in 4.2.2.4 Reduce the Rate of SPF Computation). Could you give me some more explanation or a reference pointer, authors ? IMHO simply we're just negative to have a lot of state informations, though there are some ways to avoid recalculation from scratch (i.e. incremental SPF calculation). regards. yasu jshen> Bin Liu, jshen> jshen> The first, router does not maintains all information as human does. jshen> the second, each router computes its routing table on its view of network. jshen> When state of some links varies, the logical view of network changes jshen> and the shortest path tree of the graph may become a totally new one; jshen> the third, as link state propagates by relaying hop by hop, it can not jshen> be expected that every router update their routing table simulataneously, jshen> so each time a new link state is received the routing table must be jshen> recomputed jshen> to guarantee the convergence. jshen> jshen> Of course, in a network with thousands of prefix such computing need a lot jshen> of jshen> CPU time but it's just one of the key reasons. IMO, Route flapping and jshen> looping is jshen> the factors attracting more attention. jshen> jshen> Cheers jshen> jshen> Jing Shen From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 03:44:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16213 for ; Thu, 15 Aug 2002 03:44:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006D5E9C@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 3:46:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109236 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 03:46:02 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 03:46:01 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Aug 2002 03:46:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 15 Aug 2002 03:48:05 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Can area routing reduce the routing traffic in OSPF? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Bin, As I said earlier, the extract from the mail about reducing EGP <-->IGP injection that I sent you, was for for IGP in general. Not the entire BGP routing table is injected into OSPF, only a small agregated subset of it is. Besides BGP damps flaps. With these precautions in place OSPF works well with external information injected. Thanks, Vishwas -----Original Message----- From: Liu B. [mailto:binl@EEE-FS7.BHAM.AC.UK] Sent: Wednesday, August 14, 2002 10:01 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Can area routing reduce the routing traffic in OSPF? Thanks, Vishwas. So, can I conclude as this: a low routing cost in OSPF mainly depends on manually configured prefix lists (to limit redistribution of AS external LSAs) and long refresh period. In other words, in a dynamic network environment (not OPSF domain itself, i.e., AS external LSAs are highly frequently generated), OSPF routing protocol is not suitable in term of its not negligible routing cost in that case. Any experience on how to control routing cost in real network administration is more than appreciated, as well as literatures. Thanks again for everybody's time and help. yours Bin -----Original Message----- From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] Sent: 10 August 2002 10:45 To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Can area routing reduce the routing traffic in OSPF? Hi Bin, I will try to answer to ur questions. In order for heirarchical routing to scale the amount of information between domains is kept at the minimum. Not all information from EGP is injected to IGP and vice versa. Here is something from one of the mails I had exchanged: - " It seems to be an error to encourage redistribution from other protocols into IGP's. It has been observed every now and again that due to some policy errors that pumping in routes from EGP to IGP causes the entire EGP routing table to be redistributed, which causes instability in the IGP domain. Also unconstrained redistribution from IGP to EGP could cause unwanted exposure of internal domains topology. It is therefore suggested that the primary mechanism to redistribute routes from and to IGP should be by manually configured prefix lists." Yes, area boundaries do not prevent the excess AS-External LSA's, which are flooded as vectors thru out the OSPF domain, however areas do modularize the OSPF domain into smaller units, and prevents flooding of other types(besides type-5 and type-11) of LSA's across these units. There are also some areas The refresh period for OSPF is 30 minutes, we can randomize refresh and can disperse the routing traffic caused by refreshes. Thanks, Vishwas -----Original Message----- From: Bin Liu [mailto:binl@EEE-FS7.BHAM.AC.UK] Sent: Friday, August 09, 2002 10:06 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Can area routing reduce the routing traffic in OSPF? Hello there, Even though area routing is proposed to reduce the routing traffic, I quite doubt its effect. OSPF is mainly applied for for transit AS in term of its ability to accommodate a large number of external routes. However, as we know, each AS external LSA floods throughout the whole network transparently. So when the majority of LSAs in the database of OSPF router are AS external LSAs, which dominate the amount of link bandwidth consumed by OSPF traffic [OSPF protocol analysis], the benefit of reducing routing traffic by dividing network into areas is seriously undermined. If my inference is right, then 1. What is the benefit of area routing, which makes routing not flexible. 2. Does that the longer update period in OSPF (i.e., 30 minutes between the origination of LSAs) accomplish the work, i.e., reduce routing traffic. Many thanks and looking forward to seeing reply. yours Bin Liu ps. Relevent information In 1991, the number of external LSAs in 15 router NASA Science Internet (NSI) is 496, in another 14 router BARRNet, the number is 1816 [experience with OSPF, RFC 1246]. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 03:56:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16436 for ; Thu, 15 Aug 2002 03:56:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.006D5F02@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 3:58:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109314 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 03:58:03 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 03:58:03 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Aug 2002 03:58:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 15 Aug 2002 04:00:15 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: new LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Mitchell, You are confusing things. The question was simply whether there was a way to figure out a change just by seeing the current version of the LSA alone. To which Acee correctly replied in the negative. When a new LSA comes in, we need to compare the two version LSA's before we decide to drop either. By comparing the two versions, we could figure out the differences and use the information for optimizing purposes. For example if we could figure out that the only change in the router LSA was a stub link, we would rather just add/delete/update the stub link alone without doing the full SPF. Thanks, Vishwas -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Thursday, August 15, 2002 12:50 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: new LSA Acee, Then what would / could you do with this information? Could it be useful in anyway? Have you ever heard of anyone really interested in this type of information? Mitchell Erblich ====================== Acee Lindem wrote: > > Erblichs wrote: > > > Acee, > > > > Lets assume that we modify the LSA comparison code sections > > and we keep the older LSA versions for a short time assuming > > we have the memory available. > > Mitchell, > > Wasn't the original question whether this could be done without the > previous LSA? > > > > > What would you say we can now do with this additional information? > > If you had the previous LSA you could definitely determine what had > changed between the two versions. > > > > > Mitchell Erblich > > =================== > > > > > > Acee Lindem wrote: > > > >>Beatriz Silva wrote: > >> > >> > >>>Hi everybody ! > >>> > >>>I would like to know if it is possible (in OSPF v2) to identify, just by examining the LSA, what is the change the LSA is signaling. I want to identify if for example an router LSA was sent because the cost of one of the links was changed, or if it was because one of the links went down .... This, without having the previous LSAs, just by looking at the newly received LSA. Is it possible ? How ? > >>> > >>> > >>Beatriz, > >> > >>AFAIK, there is no way to determine what has changed without a previous version > >>of the LSA. > >> > >> > >>>Thank you very much, > >>>Beatriz > >>Acee > >> > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 04:17:11 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16879 for ; Thu, 15 Aug 2002 04:17:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.006D5F14@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 4:18:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109353 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 04:18:24 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 04:18:24 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id DB27D5D019; Thu, 15 Aug 2002 17:18:25 +0900 (JST) References: <3D5B4B88.215EA127@arc.corp.mot.com> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020815.171008.123934010.yasu@sfc.wide.ad.jp> Date: Thu, 15 Aug 2002 17:10:08 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Routing IPv4 with OSPFv3 Comments: To: arthurd@ARC.CORP.MOT.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3D5B4B88.215EA127@arc.corp.mot.com> Precedence: list Content-Transfer-Encoding: 7bit Hi. arthurd> Greetings, arthurd> arthurd> I'm interested in people's opinions and experiences in using arthurd> OSPFv3 (aka OSPF for IPv6) for routing IPv4. arthurd> arthurd> My understanding from reading the OSPFv3 specification arthurd> (RFC2740) is that OSPFv3 is designed with a degree of arthurd> protocol independence. By this I mean that you could, in arthurd> principle, use OSPFv3 to route any protocol family you chose, arthurd> just so long as you were able to map addressing information arthurd> to the topology (and of course your OSPF code knew how to set arthurd> up the correct forwarding state for your given protocol arthurd> family). The topology-to-address mapping for IPv6 is done arthurd> using OSPFv3's Intra-area-prefix-LSAs, but the spec makes no arthurd> mention of how you might map IPv4 addressing information to a arthurd> network topology. If you care only about IPv4, it is possible without involving protocol issue, since there are IPv4-mapped address in IPv6 address architecture (specification). You can simply advertise IPv4 prefix in IPv6 "IPv4-mapped" format, then the receiver of the advertisement can install the prefix in IPv4 route table. I agree that OSPFv3 can be adopted to any Network Address Family, by defining new LSAs corresponds to Prefix-LSAs including Link-LSA. arthurd> So, my questions are: arthurd> - Regarding OSPFv3 - is the bulk of it protocol agnostic, or arthurd> is it just my imagination? Was it the intention of the arthurd> protocol authors to create a protocol that could easily route arthurd> multiple protocol families, or just IPv6? I guess it was the authors intention (I read John Moy's interview somewhere mentioning it). But there's no "protocol family specifier" field in the LSA, so we must indicate protocol family (address family) implicitly by LSA type. arthurd> - Is there any interest out there in using OSPFv3 to route arthurd> IPv4? I can't understand the merit of IPv4 routing by OSPFv3. I admit that we can easily route IPv4 by OSPFv3. arthurd> - Do people think it is a good idea in general to have a arthurd> single protocol route both v4 and v6? (I'm guessing that arthurd> there are those out there who think that OSPFv2 works just arthurd> fine so why would you want to change it ... ) This will lead to "ships-in-the-night" discussion. IMHO I think it is better to caluculate route individually in each address family. I am happy with two independent routing running, as I can debug IPv6 routing using IPv4 remote login, and even also I can debug IPv4 routing using IPv6 remote login ! [* ships-in-the-night is mentioned in 6.2.5 of the book "Routing in the Internet"] arthurd> And while I'm at it, are there any such things as Opaque LSAs for arthurd> OSPFv3? It is built-in feature of OSPFv3. regards. yasu From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 04:18:16 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16905 for ; Thu, 15 Aug 2002 04:18:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006D5E8D@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 4:19:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109346 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 04:19:32 -0400 Received: from 216.136.226.167 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 04:09:31 -0400 Received: from [12.235.194.197] by web20609.mail.yahoo.com via HTTP; Thu, 15 Aug 2002 01:09:34 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020815080934.58242.qmail@web20609.mail.yahoo.com> Date: Thu, 15 Aug 2002 01:09:34 -0700 Reply-To: Mailing List Sender: Mailing List From: satish dattatri Subject: Re: Why recalculation from scratch? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list The spirit of the words in ISO10589 is just meant to say that multiple changes and incremental SPF may be the same as the complete SPF. Also, remember when the original doc was written. The ball and string model paper I guess has proof to say that the worst case is no more worse than a full SPF. Depending on how the spf data structures are setup and the architecture the mileage will vary (as usual). Without more simulation/ hard data maybe leaving that statement out of the draft is probably more accurate. Thanks, Satish --- "Manral, Vishwas" wrote: > Hi Yasu, > > The idea is this. When we are under high-congestion, we are > in a state where > the topology information on the router is incomplete/out of > date, doing > incremental SPF only further loads the CPU. So instead of > doing incremental > SPF with every change, we instead club changes and do the > entire SPF after a > longer period of time, which anyway is best effort(because > of databse > discrepancies). > > Also check ISO10589, it states that the CPU load for two > incremental SPF's > can be as much as a single SPF, I dont remember the section > though(probably > in the Annex somewhere). However I remember conflicting > numbers being > presented at NANOG. > > Thanks, > Vishwas > > -----Original Message----- > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > Sent: Thursday, August 15, 2002 12:52 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Why recalculation from scratch? > > > Hi, > > Related to this, I wonder why the congestion-control draft > saying "do > not do incremental SPF when congested" (in 4.2.2.4 Reduce > the Rate of > SPF Computation). Could you give me some more explanation > or a > reference pointer, authors ? > > IMHO simply we're just negative to have a lot of state > informations, > though there are some ways to avoid recalculation from > scratch > (i.e. incremental SPF calculation). > > regards. > yasu > > jshen> Bin Liu, > jshen> > jshen> The first, router does not maintains all information > as human does. > jshen> the second, each router computes its routing table > on its view of > network. > jshen> When state of some links varies, the logical view of > network changes > jshen> and the shortest path tree of the graph may become a > totally new one; > jshen> the third, as link state propagates by relaying hop > by hop, it can > not > jshen> be expected that every router update their routing > table > simulataneously, > jshen> so each time a new link state is received the > routing table must be > jshen> recomputed > jshen> to guarantee the convergence. > jshen> > jshen> Of course, in a network with thousands of prefix > such computing need > a lot > jshen> of > jshen> CPU time but it's just one of the key reasons. IMO, > Route flapping > and > jshen> looping is > jshen> the factors attracting more attention. > jshen> > jshen> Cheers > jshen> > jshen> Jing Shen __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 04:45:54 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17734 for ; Thu, 15 Aug 2002 04:45:54 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.006D60F3@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 4:46:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109471 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 04:46:32 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 04:46:31 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id CCD985D019; Thu, 15 Aug 2002 17:45:28 +0900 (JST) References: X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020815.173711.103390783.yasu@sfc.wide.ad.jp> Date: Thu, 15 Aug 2002 17:37:11 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Why recalculation from scratch? Comments: To: VishwasM@NETPLANE.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit VishwasM> Hi Yasu, Hi. VishwasM> The idea is this. When we are under high-congestion, we are VishwasM> in a state where the topology information on the router is VishwasM> incomplete/out of date, doing incremental SPF only further VishwasM> loads the CPU. So instead of doing incremental SPF with VishwasM> every change, we instead club changes and do the entire SPF VishwasM> after a longer period of time, which anyway is best VishwasM> effort(because of databse discrepancies). OK. I understand that SPFs from scratch in a long interval is more prefered than incremental SPFs for each changes. But still wondering if there's any further reason of prefering "SPF from scratch in a long interval" than "incremental SPF *in a long interval*" ... VishwasM> Also check ISO10589, it states that the CPU load for two VishwasM> incremental SPF's can be as much as a single SPF, I dont VishwasM> remember the section though(probably in the Annex VishwasM> somewhere). However I remember conflicting numbers being VishwasM> presented at NANOG. Thank you. I will check RFC1195 (it seems the same as ISO10589). regards. yasu From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 05:47:40 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19210 for ; Thu, 15 Aug 2002 05:47:40 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.006D618E@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 5:48:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109621 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 05:48:54 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 05:48:54 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Aug 2002 05:48:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 15 Aug 2002 05:51:01 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Why recalculation from scratch? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Satish, As I said the main reason why we do not want incremental SPF in the high congestion case is because we are overloaded and probably do not have the full topology. Section 2 of the draft talks about "Failure Experience and Analysis" the following was analysed as a cause of the problem Route computation based on incomplete topology recovery, causing routes to be generated based on transient, asynchronous topology information and then in need of frequent re-computation. The latest version ISO10589v2-2001-07-04 of the doc I have in Annex C.2 states: - "studies suggest that with a very small number of link changes (perhaps two) the expected computation complexity of the incremental update exceeds the complete recalculation." I however agree that the complexity would depend on the kind of change(ABR/ASBR) as well as the implementation details. I guess a better way could be to explain the exact problem, and perhaps leave it to the implementor. Agree?? Yasu, 10589 and the RFC1195, are totally different, RFC1142 is the ASCII version of ISO10589. Thanks, Vishwas -----Original Message----- From: satish dattatri [mailto:satish_dattatri@YAHOO.COM] Sent: Thursday, August 15, 2002 1:40 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Why recalculation from scratch? The spirit of the words in ISO10589 is just meant to say that multiple changes and incremental SPF may be the same as the complete SPF. Also, remember when the original doc was written. The ball and string model paper I guess has proof to say that the worst case is no more worse than a full SPF. Depending on how the spf data structures are setup and the architecture the mileage will vary (as usual). Without more simulation/ hard data maybe leaving that statement out of the draft is probably more accurate. Thanks, Satish --- "Manral, Vishwas" wrote: > Hi Yasu, > > The idea is this. When we are under high-congestion, we are > in a state where > the topology information on the router is incomplete/out of > date, doing > incremental SPF only further loads the CPU. So instead of > doing incremental > SPF with every change, we instead club changes and do the > entire SPF after a > longer period of time, which anyway is best effort(because > of databse > discrepancies). > > Also check ISO10589, it states that the CPU load for two > incremental SPF's > can be as much as a single SPF, I dont remember the section > though(probably > in the Annex somewhere). However I remember conflicting > numbers being > presented at NANOG. > > Thanks, > Vishwas > > -----Original Message----- > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > Sent: Thursday, August 15, 2002 12:52 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Why recalculation from scratch? > > > Hi, > > Related to this, I wonder why the congestion-control draft > saying "do > not do incremental SPF when congested" (in 4.2.2.4 Reduce > the Rate of > SPF Computation). Could you give me some more explanation > or a > reference pointer, authors ? > > IMHO simply we're just negative to have a lot of state > informations, > though there are some ways to avoid recalculation from > scratch > (i.e. incremental SPF calculation). > > regards. > yasu > > jshen> Bin Liu, > jshen> > jshen> The first, router does not maintains all information > as human does. > jshen> the second, each router computes its routing table > on its view of > network. > jshen> When state of some links varies, the logical view of > network changes > jshen> and the shortest path tree of the graph may become a > totally new one; > jshen> the third, as link state propagates by relaying hop > by hop, it can > not > jshen> be expected that every router update their routing > table > simulataneously, > jshen> so each time a new link state is received the > routing table must be > jshen> recomputed > jshen> to guarantee the convergence. > jshen> > jshen> Of course, in a network with thousands of prefix > such computing need > a lot > jshen> of > jshen> CPU time but it's just one of the key reasons. IMO, > Route flapping > and > jshen> looping is > jshen> the factors attracting more attention. > jshen> > jshen> Cheers > jshen> > jshen> Jing Shen From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 06:55:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20310 for ; Thu, 15 Aug 2002 06:55:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006D6456@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 6:57:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 110569 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 06:57:00 -0400 Received: from 147.188.128.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 06:57:00 -0400 Received: from bham.ac.uk ([147.188.128.127]) by mailer3.bham.ac.uk with esmtp (Exim 3.16 #2) id 17fIJM-00034k-00 for OSPF@discuss.microsoft.com; Thu, 15 Aug 2002 11:57:04 +0100 Received: from eee-fs7.bham.ac.uk ([147.188.145.131] helo=bham-eee-fs7.bham.ac.uk) by bham.ac.uk with esmtp (Exim 3.16 #3) id 17fIJM-0002uL-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 11:57:04 +0100 Received: by BHAM-EEE-FS7 with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Aug 2002 11:57:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 15 Aug 2002 11:57:03 +0100 Reply-To: Mailing List Sender: Mailing List From: "Liu B." Subject: Re: Why recalculation from scratch? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hello there, In page 159, RFC2328 (OSPF version 2), it said that "The routing table is built again from scratch", which does not say whether the routing table rebuilding process is done in a long interval, or for each change. (Actually, can we not rebuild routing table for any change?) Vishwas, as you said (chapter 2 of which draft? Is it RFC) that "the main reason for full SPF is not having full topology in each node", also that "route comuptation based on incomplete topology ... causes the need of frequent re-computation..." How can we prove the performance of full SPF is better than that of incremental SPF in respects of accuracy and CPU cost, when recomputation happens frequently? "studies suggest that with a very small number of link changes (perhaps two)the expected computation complexity of the incremental update exceeds the complete recalculation." Does it mean that in the case of two link changes, the cost of full SPF is less than that of incremental SPF? I don't see how, because the incremental SPF is designed to save cost ...... Does it imply that full SPF is done only once upon two changes? But upon which? My feeling is that using full SPF to rebuild routing table from scratch is to sacrifice some "unrarely"(?) resources (i.e., CPU power) to simplify problem, in order to improve protocol stability. Meanwhile, it does not cause significant negative effect on routing performance (e.g., longer convergence time and bandwith cost). I am reading RFC1195 and 1142 (the latest version ISO10589v2-2001-07-04?) now and hopefully, I can find some quantified performance comparation between the full SPF and the incremental one. Satish, would you please tell me where can I find the ball and string model paper you mentioned? Thanks all and best wishes Bin -----Original Message----- From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] Sent: 15 August 2002 10:51 To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Why recalculation from scratch? Hi Satish, As I said the main reason why we do not want incremental SPF in the high congestion case is because we are overloaded and probably do not have the full topology. Section 2 of the draft talks about "Failure Experience and Analysis" the following was analysed as a cause of the problem Route computation based on incomplete topology recovery, causing routes to be generated based on transient, asynchronous topology information and then in need of frequent re-computation. The latest version ISO10589v2-2001-07-04 of the doc I have in Annex C.2 states: - "studies suggest that with a very small number of link changes (perhaps two) the expected computation complexity of the incremental update exceeds the complete recalculation." I however agree that the complexity would depend on the kind of change(ABR/ASBR) as well as the implementation details. I guess a better way could be to explain the exact problem, and perhaps leave it to the implementor. Agree?? Yasu, 10589 and the RFC1195, are totally different, RFC1142 is the ASCII version of ISO10589. Thanks, Vishwas -----Original Message----- From: satish dattatri [mailto:satish_dattatri@YAHOO.COM] Sent: Thursday, August 15, 2002 1:40 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Why recalculation from scratch? The spirit of the words in ISO10589 is just meant to say that multiple changes and incremental SPF may be the same as the complete SPF. Also, remember when the original doc was written. The ball and string model paper I guess has proof to say that the worst case is no more worse than a full SPF. Depending on how the spf data structures are setup and the architecture the mileage will vary (as usual). Without more simulation/ hard data maybe leaving that statement out of the draft is probably more accurate. Thanks, Satish -----Original Message----- From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] Sent: 15 August 2002 09:37 To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Why recalculation from scratch? VishwasM> Hi Yasu, Hi. VishwasM> The idea is this. When we are under high-congestion, we are VishwasM> in a state where the topology information on the router is VishwasM> incomplete/out of date, doing incremental SPF only further VishwasM> loads the CPU. So instead of doing incremental SPF with VishwasM> every change, we instead club changes and do the entire SPF VishwasM> after a longer period of time, which anyway is best VishwasM> effort(because of databse discrepancies). OK. I understand that SPFs from scratch in a long interval is more prefered than incremental SPFs for each changes. But still wondering if there's any further reason of prefering "SPF from scratch in a long interval" than "incremental SPF *in a long interval*" ... VishwasM> Also check ISO10589, it states that the CPU load for two VishwasM> incremental SPF's can be as much as a single SPF, I dont VishwasM> remember the section though(probably in the Annex VishwasM> somewhere). However I remember conflicting numbers being VishwasM> presented at NANOG. Thank you. I will check RFC1195 (it seems the same as ISO10589). regards. yasu --- "Manral, Vishwas" wrote: > Hi Yasu, > > The idea is this. When we are under high-congestion, we are > in a state where > the topology information on the router is incomplete/out of > date, doing > incremental SPF only further loads the CPU. So instead of > doing incremental > SPF with every change, we instead club changes and do the > entire SPF after a > longer period of time, which anyway is best effort(because > of databse > discrepancies). > > Also check ISO10589, it states that the CPU load for two > incremental SPF's > can be as much as a single SPF, I dont remember the section > though(probably > in the Annex somewhere). However I remember conflicting > numbers being > presented at NANOG. > > Thanks, > Vishwas > > -----Original Message----- > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > Sent: Thursday, August 15, 2002 12:52 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Why recalculation from scratch? > > > Hi, > > Related to this, I wonder why the congestion-control draft > saying "do > not do incremental SPF when congested" (in 4.2.2.4 Reduce > the Rate of > SPF Computation). Could you give me some more explanation > or a > reference pointer, authors ? > > IMHO simply we're just negative to have a lot of state > informations, > though there are some ways to avoid recalculation from > scratch > (i.e. incremental SPF calculation). > > regards. > yasu > > jshen> Bin Liu, > jshen> > jshen> The first, router does not maintains all information > as human does. > jshen> the second, each router computes its routing table > on its view of > network. > jshen> When state of some links varies, the logical view of > network changes > jshen> and the shortest path tree of the graph may become a > totally new one; > jshen> the third, as link state propagates by relaying hop > by hop, it can > not > jshen> be expected that every router update their routing > table > simulataneously, > jshen> so each time a new link state is received the > routing table must be > jshen> recomputed > jshen> to guarantee the convergence. > jshen> > jshen> Of course, in a network with thousands of prefix > such computing need > a lot > jshen> of > jshen> CPU time but it's just one of the key reasons. IMO, > Route flapping > and > jshen> looping is > jshen> the factors attracting more attention. > jshen> > jshen> Cheers > jshen> > jshen> Jing Shen From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 09:23:23 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25060 for ; Thu, 15 Aug 2002 09:23:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.006D659C@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 9:24:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 111011 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 09:24:40 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 09:24:39 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 56EF82848BD for ; Thu, 15 Aug 2002 06:24:39 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20020814085042.96790.qmail@mail.com> <3D5B2086.9000906@redback.com> <3D5B49F8.A518DA7@earthlink.net> <3D5B4A31.4050901@redback.com> <3D5B5612.D3F43030@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D5BABE0.3080202@redback.com> Date: Thu, 15 Aug 2002 09:25:52 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: new LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > Acee, > > Then what would / could you do with this information? Could it > be useful in anyway? Mitchell, Both the reasons that Naiming (adjusting SPF delay based on change type) and Vishwas (doing an incremental SPF for stub networks) noted are reasonable. > Have you ever heard of anyone really > interested in this type of information? I can't say that I ever worked on an implementation that processed different types of changes to individual LSAs differently. > > Mitchell Erblich > ====================== > > > Acee Lindem wrote: > >>Erblichs wrote: >> >> >>>Acee, >>> >>> Lets assume that we modify the LSA comparison code sections >>> and we keep the older LSA versions for a short time assuming >>> we have the memory available. >>> >>Mitchell, >> >>Wasn't the original question whether this could be done without the >>previous LSA? >> >> >>> What would you say we can now do with this additional information? >>> >>If you had the previous LSA you could definitely determine what had >>changed between the two versions. >> >> >>> Mitchell Erblich >>> =================== >>> >>> >>>Acee Lindem wrote: >>> >>> >>>>Beatriz Silva wrote: >>>> >>>> >>>> >>>>>Hi everybody ! >>>>> >>>>>I would like to know if it is possible (in OSPF v2) to identify, just by examining the LSA, what is the change the LSA is signaling. I want to identify if for example an router LSA was sent because the cost of one of the links was changed, or if it was because one of the links went down .... This, without having the previous LSAs, just by looking at the newly received LSA. Is it possible ? How ? >>>>> >>>>> >>>>> >>>>Beatriz, >>>> >>>>AFAIK, there is no way to determine what has changed without a previous version >>>>of the LSA. >>>> >>>> >>>> >>>>>Thank you very much, >>>>>Beatriz >>>>> >>>>>-- >>>>>__________________________________________________________ >>>>>Sign-up for your own FREE Personalized E-mail at Mail.com >>>>>http://www.mail.com/?sr=signup >>>>> >>>>> >>>>> >>>>> >>>>-- >>>>Acee >>>> >>>> >>-- >>Acee >> > -- Acee From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@DISCUSS.MICROSOFT.COM Thu Aug 15 11:45:08 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01439 for ; Thu, 15 Aug 2002 11:45:07 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006D6AE4@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 11:46:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 111436 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 11:46:22 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 11:46:17 -0400 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7FFkJm04171 for ; Thu, 15 Aug 2002 08:46:19 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g7FFkJR68983; Thu, 15 Aug 2002 08:46:19 -0700 (PDT) (envelope-from dkatz@cirrus.juniper.net) References: <20020814085042.96790.qmail@mail.com> <3D5B2086.9000906@redback.com> <3D5B49F8.A518DA7@earthlink.net> Message-ID: <200208151546.g7FFkJR68983@cirrus.juniper.net> Date: Thu, 15 Aug 2002 08:46:19 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: new LSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3D5B49F8.A518DA7@earthlink.net> (message from Erblichs on Wed, 14 Aug 2002 23:28:08 -0700) Precedence: list Lets assume that we modify the LSA comparison code sections and we keep the older LSA versions for a short time assuming we have the memory available. What would you say we can now do with this additional information? Not a whole lot, since you cannot rely upon hearing every version of every LSA, only the latest one. There are a number of scenarios in which an LSA being flooded can be overtaken by a newer version, and thus the older one may not be delivered to everyone. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 12:01:52 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02469 for ; Thu, 15 Aug 2002 12:01:51 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006D6AF3@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 12:03:10 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 111509 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 12:03:08 -0400 Received: from 204.127.202.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 12:03:07 -0400 Received: from c1052242a ([12.235.2.53]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020815160310.YQOS13899.sccrmhc02.attbi.com@c1052242a> for ; Thu, 15 Aug 2002 16:03:10 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: Date: Thu, 15 Aug 2002 09:09:33 -0700 Reply-To: Mailing List Sender: Mailing List From: Manohar Naidu Ellanti Subject: L2TP/OSPF To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Can some one explain: There are multiple remote machines connected via seperate NAS-LCS to a hub node (server) all using L2TP. First on the hub node , do we treat each tunnel as a seperate interface? Since L2TP uses UDP, every LCS would send L2TP packets to server's L2TP single UDP address. I am assuming then the reciver on the hub would get tunneled traffic from all remote machines - This would be a variation of the case where LNS would get multiple tunnels from a single LCS. If we were to run OSPF on the hub node and remote machines - do we treat this as NBMA case with one interface on the hub and multiple neighbors? If someone cane provide experience with L2TP/OSPF I would appreciate. -ellanti From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 12:18:49 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03267 for ; Thu, 15 Aug 2002 12:18:49 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.006D6B52@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 12:20:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 111558 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 12:20:03 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 12:20:03 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Aug 2002 12:20:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 15 Aug 2002 12:22:18 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: new LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Dave, > Not a whole lot, since you cannot rely upon hearing > every version of every LSA, only the latest one. > There are a number of scenarios in which an LSA being > flooded can be overtaken by a newer version, and thus > the older one may not be delivered to everyone. I am sorry I did not understand correctly. Wouldn't it be the same for any router, if the LSA changed from A to B and finally to C, or if it changed from A directly to C, for the routing table, in the sense of incremental SPF? I guess I have misunderstood. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 12:30:35 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03796 for ; Thu, 15 Aug 2002 12:30:34 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.006D6BAA@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 12:31:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 111619 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 12:31:51 -0400 Received: from 205.158.62.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 12:31:50 -0400 Received: (qmail 4213 invoked by uid 1001); 15 Aug 2002 16:31:53 -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 [129.187.254.13] by ws1-6.us4.outblaze.com with http for beatriz_hargrave@mail.com; Thu, 15 Aug 2002 11:31:53 -0500 X-Originating-Ip: 129.187.254.13 X-Originating-Server: ws1-6.us4.outblaze.com Message-ID: <20020815163153.4212.qmail@mail.com> Date: Thu, 15 Aug 2002 11:31:53 -0500 Reply-To: Mailing List Sender: Mailing List From: Beatriz Silva Subject: How many changes can be in one LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi everybody! Thanks for the answer about the topic "new LSA". But I also want to know the following: If more than one change occurs in a router for instance: one link changes cost and another link goes down simutaneously, will this two changes be signalled in one LSA or two LSAs will be generated for that ? I mean, is the LSA limited to one change at a time ? Thanks, Beatriz -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 12:52:20 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04512 for ; Thu, 15 Aug 2002 12:52:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006D6AE7@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 12:53:36 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 111675 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 12:53:33 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 12:53:32 -0400 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7FGrZm08745 for ; Thu, 15 Aug 2002 09:53:35 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g7FGrZD69118; Thu, 15 Aug 2002 09:53:35 -0700 (PDT) (envelope-from dkatz@cirrus.juniper.net) References: Message-ID: <200208151653.g7FGrZD69118@cirrus.juniper.net> Date: Thu, 15 Aug 2002 09:53:35 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: new LSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: (VishwasM@NETPLANE.COM) Precedence: list My point was that you cannot rely on seeing all versions of each LSA, so there are practical limits to what you can do globally by looking at deltas. Most routers already do local optimizations at some level by examining LSA changes, so I thought the question was broader than that. I guess maybe I misunderstood the original question. --Dave I am sorry I did not understand correctly. Wouldn't it be the same for any router, if the LSA changed from A to B and finally to C, or if it changed from A directly to C, for the routing table, in the sense of incremental SPF? From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 12:55:39 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04588 for ; Thu, 15 Aug 2002 12:55:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006D6BD5@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 12:56:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 111723 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 12:56:54 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 12:56:54 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 31F6D1DCC60; Thu, 15 Aug 2002 09:56:57 -0700 (PDT) Message-ID: <20020815165657.31F6D1DCC60@prattle.redback.com> Date: Thu, 15 Aug 2002 09:56:57 -0700 Reply-To: Mailing List Sender: Mailing List From: Naiming Shen Subject: Re: new LSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Mail from Dave Katz dated Thu, 15 Aug 2002 08:46:19 PDT <200208151546.g7FFkJR68983@cirrus.juniper.net> Precedence: list ] Lets assume that we modify the LSA comparison code sections ] and we keep the older LSA versions for a short time assuming ] we have the memory available. ] ] What would you say we can now do with this additional information? ] ] Not a whole lot, since you cannot rely upon hearing every version of ] every LSA, only the latest one. There are a number of scenarios ] in which an LSA being flooded can be overtaken by a newer version, ] and thus the older one may not be delivered to everyone. If router X received LSAs from router A with version a, b, c and d; router Y only received a and d. If both X and Y decide to do version/ content comparison, it just means X is going to do 3 times, and Y is going to do one time only. But the end result should be the same since they all get the finally version of d. Unless the version/ content comparison code has problem. thanks. - Naiming From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 17:28:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16739 for ; Thu, 15 Aug 2002 17:28:24 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.006D72E1@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 15:08:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 112273 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 15:08:00 -0400 Received: from 207.217.120.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 15:08:00 -0400 Received: from user-2ivfj2h.dialup.mindspring.com ([165.247.204.81] helo=earthlink.net) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17fPyV-00025Q-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 12:08:04 -0700 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: <3D5B6AA0.707B06D4@earthlink.net> Date: Thu, 15 Aug 2002 01:47:28 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: new LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I think I got it right.. Beatriz had a thought and I just wanted to get a census to verify that someone could achieve some positive results with a different approach when two LSAs are compared. The goal was to reach the "what is the change the LSA is signaling" answer and what useful features could then be done with this information. And with the replies, it seems that there are a few possible features that could be implemented. Thanks, Mitchell Erblich ------------------- "Manral, Vishwas" wrote: > > Mitchell, > > You are confusing things. The question was simply whether there was a way to > figure out a change just by seeing the current version of the LSA alone. To > which Acee correctly replied in the negative. > > When a new LSA comes in, we need to compare the two version LSA's before we > decide to drop either. By comparing the two versions, we could figure out > the differences and use the information for optimizing purposes. For example > if we could figure out that the only change in the router LSA was a stub > link, we would rather just add/delete/update the stub link alone without > doing the full SPF. > > Thanks, > Vishwas > > -----Original Message----- > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > Sent: Thursday, August 15, 2002 12:50 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: new LSA > > Acee, > > Then what would / could you do with this information? Could it > be useful in anyway? Have you ever heard of anyone really > interested in this type of information? > > Mitchell Erblich > ====================== > > Acee Lindem wrote: > > > > Erblichs wrote: > > > > > Acee, > > > > > > Lets assume that we modify the LSA comparison code sections > > > and we keep the older LSA versions for a short time assuming > > > we have the memory available. > > > > Mitchell, > > > > Wasn't the original question whether this could be done without the > > previous LSA? > > > > > > > > What would you say we can now do with this additional > information? > > > > If you had the previous LSA you could definitely determine what had > > changed between the two versions. > > > > > > > > Mitchell Erblich > > > =================== > > > > > > > > > Acee Lindem wrote: > > > > > >>Beatriz Silva wrote: > > >> > > >> > > >>>Hi everybody ! > > >>> > > >>>I would like to know if it is possible (in OSPF v2) to identify, just > by examining the LSA, what is the change the LSA is signaling. I want to > identify if for example an router LSA was sent because the cost of one of > the links was changed, or if it was because one of the links went down .... > This, without having the previous LSAs, just by looking at the newly > received LSA. Is it possible ? How ? > > >>> > > >>> > > >>Beatriz, > > >> > > >>AFAIK, there is no way to determine what has changed without a previous > version > > >>of the LSA. > > >> > > >> > > >>>Thank you very much, > > >>>Beatriz > > >>Acee > > >> > > > > > > > -- > > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 18:21:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18187 for ; Thu, 15 Aug 2002 18:21:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006D7869@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 18:22:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 112675 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 18:22:27 -0400 Received: from 216.136.226.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 18:22:27 -0400 Received: from [12.235.194.197] by web20603.mail.yahoo.com via HTTP; Thu, 15 Aug 2002 15:22:27 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020815222227.45526.qmail@web20603.mail.yahoo.com> Date: Thu, 15 Aug 2002 15:22:27 -0700 Reply-To: Mailing List Sender: Mailing List From: satish dattatri Subject: Re: Why recalculation from scratch? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list > I am reading RFC1195 and 1142 (the latest version > ISO10589v2-2001-07-04?) > now and hopefully, I can find some quantified performance > comparation > between the full SPF and the incremental one. Satish, would > you please tell > me where can I find the ball and string model paper you > mentioned? > http://perth.mit.edu/~pnarvaez/mypapers/paper7_tech.pdf Also, see for some other info , field experiment data . http://www.packetdesign.com/Documents/qwest.pdf __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 18:35:23 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18643 for ; Thu, 15 Aug 2002 18:35:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.006D78D6@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 18:36:21 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 112730 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 18:36:19 -0400 Received: from 216.136.226.165 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 18:36:19 -0400 Received: from [12.235.194.197] by web20607.mail.yahoo.com via HTTP; Thu, 15 Aug 2002 15:36:19 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020815223619.12888.qmail@web20607.mail.yahoo.com> Date: Thu, 15 Aug 2002 15:36:19 -0700 Reply-To: Mailing List Sender: Mailing List From: satish dattatri Subject: Re: Why recalculation from scratch? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Vishwas, Please see inline thanks, satish --- "Manral, Vishwas" wrote: > Hi Satish, > > As I said the main reason why we do not want incremental > SPF in the high > congestion case is because we are overloaded and probably > do not have the > full topology. > Why not delay the SPF, if that makes sense among other things.. Please note that a incremental SPF or FULL SPF will have to be done on the amount of information in our LSDB. Let us leave it to the creative implementor ... > Section 2 of the draft talks about "Failure Experience and > Analysis" the > following was analysed as a cause of the problem > > Route computation based on incomplete topology > recovery, causing > routes to be generated based on transient, > asynchronous topology > information and then in need of frequent > re-computation. > > The latest version ISO10589v2-2001-07-04 of the doc I have > in Annex C.2 > states: - > > "studies suggest that with a very small number of link > changes (perhaps two) > the expected computation complexity of the incremental > update exceeds the > complete recalculation." > That part of the document is just carried from the 1992 edition. Please, let us not take that verbatim. > I however agree that the complexity would depend on the > kind of > change(ABR/ASBR) as well as the implementation details. I > guess a better way > could be to explain the exact problem, and perhaps leave it > to the > implementor. Agree?? > I agree, that is the best choice. > Yasu, 10589 and the RFC1195, are totally different, RFC1142 > is the ASCII > version of ISO10589. > RFC1142 is a copy of ISO10589-1990 draft not the 1992 approved version. But anyways please use the latest draft available free ;-), as you referred. > Thanks, > Vishwas > > -----Original Message----- > From: satish dattatri [mailto:satish_dattatri@YAHOO.COM] > Sent: Thursday, August 15, 2002 1:40 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Why recalculation from scratch? > > > > The spirit of the words in ISO10589 is just meant to say > that multiple changes and incremental SPF may be the same > as the complete SPF. Also, remember when the original doc > was > written. The ball and string model paper I guess > has proof to say that the worst case is no more worse than > a > full SPF. Depending on how the spf data structures are > setup > and the architecture the mileage will vary (as usual). > > Without more simulation/ hard data maybe leaving that > statement out of the draft is probably more accurate. > > Thanks, > Satish > > --- "Manral, Vishwas" wrote: > > Hi Yasu, > > > > The idea is this. When we are under high-congestion, we > are > > in a state where > > the topology information on the router is incomplete/out > of > > date, doing > > incremental SPF only further loads the CPU. So instead of > > doing incremental > > SPF with every change, we instead club changes and do the > > entire SPF after a > > longer period of time, which anyway is best > effort(because > > of databse > > discrepancies). > > > > Also check ISO10589, it states that the CPU load for two > > incremental SPF's > > can be as much as a single SPF, I dont remember the > section > > though(probably > > in the Annex somewhere). However I remember conflicting > > numbers being > > presented at NANOG. > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > > Sent: Thursday, August 15, 2002 12:52 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: Why recalculation from scratch? > > > > > > Hi, > > > > Related to this, I wonder why the congestion-control > draft > > saying "do > > not do incremental SPF when congested" (in 4.2.2.4 Reduce > > the Rate of > > SPF Computation). Could you give me some more explanation > > or a > > reference pointer, authors ? > > > > IMHO simply we're just negative to have a lot of state > > informations, > > though there are some ways to avoid recalculation from > > scratch > > (i.e. incremental SPF calculation). > > > > regards. > > yasu > > > > jshen> Bin Liu, > > jshen> > > jshen> The first, router does not maintains all > information > > as human does. > > jshen> the second, each router computes its routing table > > on its view of > > network. > > jshen> When state of some links varies, the logical view > of > > network changes > > jshen> and the shortest path tree of the graph may become > a > > totally new one; > > jshen> the third, as link state propagates by relaying > hop > > by hop, it can > > not > > jshen> be expected that every router update their routing > > table > > simulataneously, > > jshen> so each time a new link state is received the > > routing table must be > > jshen> recomputed > > jshen> to guarantee the convergence. > > jshen> > > jshen> Of course, in a network with thousands of prefix > > such computing need > > a lot > > jshen> of > > jshen> CPU time but it's just one of the key reasons. > IMO, > > Route flapping > > and > > jshen> looping is > > jshen> the factors attracting more attention. > > jshen> > > jshen> Cheers > > jshen> > > jshen> Jing Shen __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Aug 15 20:51:44 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21605 for ; Thu, 15 Aug 2002 20:51:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.006D7C14@cherry.ease.lsoft.com>; Thu, 15 Aug 2002 20:53:01 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 113134 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 20:52:58 -0400 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 15 Aug 2002 20:52:58 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01KLC38WC0QE8WYIGB@omega7.wr.usgs.gov> for OSPF@DISCUSS.MICROSOFT.COM; Thu, 15 Aug 2002 17:52:59 -0700 (PDT) X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM X-VMS-Cc: PMURPHY,ospfisfun@YAHOO.COM MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01KLC38WC1O88WYIGB@omega7.wr.usgs.gov> Date: Thu, 15 Aug 2002 17:52:59 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: NSSA Problem Comments: cc: OSPFISFUN@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Amit, Sorry to be slow late with this posting. I have been unavailable lately due to USGS security concerns. Consider the following example. A0, B0, C0 are area 0 routers. A0 and B0 are ABRs for NSSA 1, both of which translate Type 7 LSAs into Type 5 LSAs. D1 is an ASBR for NSSA 1 which learns an external route for N1 from E1, an EIGRP peer. C0 . . . . 10Mbps . . T1 . Area 0 . . . A0 - - - - - B0 . . . NSSA 1 . 128Kbps . . T1 ISDN . . backup . . D1 . . . E1 . . N1 If D1 sets a 0.0.0.0 forwarding address for N1 in its type 7 LSA, A0 and B0 would have to do the same in the Type 5 translation of this LSA. Thus C0 would see, via the Type 5 LSA translation, the 10Mbps path through A0 as the shortest path to N1. If D1 sets a non-zero forwarding addess, C0 correctly computes the shortest path to N1 as the T1 link through B0. Note that even if both A0 and B0 originated a type 4 summary link for D1, the same logic would still hold, as the type 5 LSA advertisement for N1 originates from A0 and B0, not D1. Pat From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 16 00:18:33 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26038 for ; Fri, 16 Aug 2002 00:18:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.006D8581@cherry.ease.lsoft.com>; Fri, 16 Aug 2002 0:19:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 113640 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 16 Aug 2002 00:19:49 -0400 Received: from 66.218.78.88 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 16 Aug 2002 00:19:49 -0400 Received: from [203.200.20.226] by web40309.mail.yahoo.com via HTTP; Thu, 15 Aug 2002 21:19:48 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020816041948.32584.qmail@web40309.mail.yahoo.com> Date: Thu, 15 Aug 2002 21:19:48 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: NSSA Problem To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <01KLC38WC1O88WYIGB@omega7.wr.usgs.gov> Precedence: list Hi Pat and Acee, Thanks a lot for your help i really understood the concept. Regards Amit --- "Pat Murphy - (650)329-4044" wrote: > Amit, > > Sorry to be slow late with this posting. I have been > unavailable lately due to USGS security concerns. > > Consider the following example. A0, B0, C0 are area > 0 > routers. A0 and B0 are ABRs for NSSA 1, both of > which > translate Type 7 LSAs into Type 5 LSAs. D1 is an > ASBR for > NSSA 1 which learns an external route for N1 from > E1, an > EIGRP peer. > > C0 > . . > . . > 10Mbps . . T1 > . Area 0 . > . . > A0 - - - - - B0 > . . > . NSSA 1 . > 128Kbps . . T1 > ISDN . . > backup . . > D1 > . > . > . > E1 > . > . > N1 > > If D1 sets a 0.0.0.0 forwarding address for N1 in > its type > 7 LSA, A0 and B0 would have to do the same in the > Type 5 > translation of this LSA. Thus C0 would see, via the > Type 5 > LSA translation, the 10Mbps path through A0 as the > shortest > path to N1. If D1 sets a non-zero forwarding addess, > C0 > correctly computes the shortest path to N1 as the T1 > link > through B0. > > Note that even if both A0 and B0 originated a type 4 > summary link for D1, the same logic would still > hold, as > the type 5 LSA advertisement for N1 originates from > A0 and > B0, not D1. > > Pat __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 16 00:57:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26848 for ; Fri, 16 Aug 2002 00:57:52 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006D855F@cherry.ease.lsoft.com>; Fri, 16 Aug 2002 0:59:12 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 113762 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 16 Aug 2002 00:59:11 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 16 Aug 2002 00:59:11 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 48F581B8EF9 for ; Thu, 15 Aug 2002 21:59:11 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20020815163153.4212.qmail@mail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D5C86F0.8000103@redback.com> Date: Fri, 16 Aug 2002 01:00:32 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: How many changes can be in one LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Beatriz Silva wrote: > Hi everybody! > > Thanks for the answer about the topic "new LSA". > > But I also want to know the following: > If more than one change occurs in a router for instance: one link changes cost and another link goes down simutaneously, will this two changes be signalled in one LSA or two LSAs will be generated for that ? I mean, is the LSA limited to one change at a time ? Hello Beatriz, This is somewhat implementation dependent but in general simultaneous events should result in a single router LSA re-origination. There is no limit to the number of changes that can be contained in a single LSA. > > Thanks, > Beatriz > > -- > __________________________________________________________ > Sign-up for your own FREE Personalized E-mail at Mail.com > http://www.mail.com/?sr=signup > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 16 11:09:58 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18353 for ; Fri, 16 Aug 2002 11:09:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006DA251@cherry.ease.lsoft.com>; Fri, 16 Aug 2002 11:11:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 116359 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 16 Aug 2002 11:11:14 -0400 Received: from 66.113.136.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 16 Aug 2002 11:11:14 -0400 Received: from crows.siteprotect.com (IDENT:sitemail@localhost [127.0.0.1]) by crows.siteprotect.com (8.9.3/8.9.3) with ESMTP id KAA29113 for ; Fri, 16 Aug 2002 10:11:15 -0500 Message-ID: <200208161511.KAA29113@crows.siteprotect.com> Date: Fri, 16 Aug 2002 10:11:15 -0500 Reply-To: Mailing List Sender: Mailing List From: SUBSCRIBE OSPF Anonymous To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Before I start my question, my Thanks to all, who did listen to my earlier question and trying to get back to me with ideas! I really appreciate all your time and effort. Well, I have one more question when OSPF establish adjacency with its neighbors. During that period, I try to act my Simulator as Master and let OSPF Route be slave and while trying to establish an adjacency with OSPF Router, I am trying to send the below mentioned packet during DD packet exchange. But, for some reason, OSPF router could not form an adjacency when I send these packets and stops at exChange state i.e. OSPF Router and Simulator understands Master Slave relationship OSPF Router sends DD packet with master sequence number and also sends LSA Header for (routerLSA) I have few questions and any suggestions from your end is welcome and will be a big relief. * While looking at the packets, I am not sure how to calculate the checksum for LSA Header. I was under the impression that I should exclude Link State Age while performing checksum, but still not sure what I am missing here ... * Even though, LSA Header only contains 20 bytes, I noticed we always try to specify Packet Length has 36 bytes. Any reasons!? * Also, when I monitor my network, I notice for the packets only information upto Data Description and don't see LSA Header info. Thanks and have a wonderful evening! - G Data Description Packet Information: // ----- OSPF DD Ack Packet ----- // // // ----- Ethernet II ----- // define ospf [ 00 20 9c 23 bc 70 08 00 20 ac 9d d5 08 00 // // ----- Internet Protocol ----- // ----- 20 bytes ----- 45 00 00 34 // Total Length 5a a0 // Identification 00 // Flags 00 // Frame Offset 40 // TTL 59 // Protocol (OSPF) 00 00 // Checksum 0a 65 01 43 // Source 0a 65 01 41 // Destination // // ----- OSPF Header ----- // 02 // OSPF Version 02 // OSPF Packet Type (Hello Pkt) 00 34 // Packet Length 0a 65 01 43 // Source OSPF Router ID 0a 65 01 40 // Area ID 00 00 // Packet Checksum 00 00 // Auth Type (None) 00 00 00 00 // Auth Date (None) 00 00 00 00 // // ----- OSPF Data Description Info ----- // 05 dc // Interface MTU 02 // OSPF Version 00 // Master 00 00 00 02 // DD Sequence // // ----- OSPF DD w/ LSA Header -------- 64 BYTES // 01 88 // LS Age 392 seconds 02 // Options 01 // Router LSA 0a 65 01 43 // Link State ID 0a 65 01 43 // Adv. Router 00 00 01 00 // LS Sequence Number 0a 02 // Checksum 00 24 // Length ]; xsum ospf[24] 14 20; xsum ospf[46] 34 52; // -xsum ospf[82] 66 28; - Checksum for LSA Header send ospf; From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 16 16:44:13 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00721 for ; Fri, 16 Aug 2002 16:44:13 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006DAB3B@cherry.ease.lsoft.com>; Fri, 16 Aug 2002 16:45:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 117364 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 16 Aug 2002 16:45:25 -0400 Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 16 Aug 2002 16:45:25 -0400 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA24822 for ; Fri, 16 Aug 2002 13:45:24 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7GKjO026214 for ; Fri, 16 Aug 2002 13:45:24 -0700 X-mProtect: <200208162045> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.19.69.81, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnPQUCo; Fri, 16 Aug 2002 13:45:22 PDT X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <05F679A54DF3D51188100008C7919756D38AF4@ma07exm03.corp.isg.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D5D6461.390D6CEF@iprg.nokia.com> Date: Fri, 16 Aug 2002 13:45:21 -0700 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Organization: Nokia Subject: Re: OSPF cryptographic authentication keying To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Donald, You are right that your question has absolutely nothing to do with OSPF. It is really related to the security of generic configuration infrastructure of vendors. Generally vendors have multiple interfaces to the systems. Talking about our systems, we have CLI after accessing the system using direct console access, normal telnet in a secure environment, SSH and web access with HTTP and HTTPS. regards Mukesh Eastlake III Donald-LDE008 wrote: > Mukesh, > > Yes, I was talking about OSPFv2. > > Thanks for your response but, given that in today's world the shared key is > usually set up "manually", what method is most commonly used? SSH or Secure > Telnet to a Command Line Interface? SNMP? TLS to a web interface? Do routers > usually have two or three ways it can be done? > > As I say, I realize this isn't strictly part of the OSPFv2 protocol but > would appreciate any information people can provide. > > Thanks, > Donald > > Date: Tue, 13 Aug 2002 14:06:10 -0400 > From: Eastlake III Donald-LDE008 > Subject: OSPF cryptographic authentication keying > > Hi, > > I have a couple of questions about how keying is established for OSPF > cryptographic authentication: > > First of all, which may be a stupid questions, I have the impression the > keying is essentially on a pairwise basis, rather than a key being shared > among all the entities in an area. Is that correct? > > Second, how are these keys normally established in today's operational > world? I realize this is a bit outside of the scope of OSPF, but do people > use manual entry, SNMP, some negotiation framework like ISAKMP, or what? > > Thanks, > Donald > > Donald E. Eastlake 3rd, +1-508-851-8280 (voice), +1-508-851-8507 (fax) > Motorola, MS: M2-450, 20 Cabot Boulevard, Mansfield, MA 02048 USA > > ------------------------------ > > Date: Tue, 13 Aug 2002 11:44:51 -0700 > From: Mukesh Gupta > Subject: Re: OSPF cryptographic authentication keying > > > I have a couple of questions about how keying is established for OSPF > > cryptographic authentication: > > I am assuming that you are talking about OSPFv2. > > > First of all, which may be a stupid questions, I have the impression the > > keying is essentially on a pairwise basis, rather than a key being shared > > among all the entities in an area. Is that correct? > > To my knowledge, No. It is not correct. The keys are shared between all the > entities in an area and they are not on a pairwise basis. Using pairwise > keys > in the multicast environment will not work. > > > Second, how are these keys normally established in today's operational > > world? I realize this is a bit outside of the scope of OSPF, but do people > > use manual entry, SNMP, some negotiation framework like ISAKMP, or what? > > I think, most of the implementations use manual entry. ISAKMP wouldn't be > easy > to use in the multicast environment OSPF uses. Key negotiation mechanisms > for > multicast are still being explored. > > regards > Mukesh > > -- > ****************************************************************** > Work fascinates me. I can look at it for hours ! > ****************************************************************** > Mukesh Gupta > Phone: (650) 625-2264 > Cell : (650) 868-9111 > http://www.iprg.nokia.com/~mgupta > ****************************************************************** -- ****************************************************************** This Would Be Really Funny If It Weren't Happening To Me. ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** From owner-ospf@DISCUSS.MICROSOFT.COM Fri Aug 16 18:44:44 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03119 for ; Fri, 16 Aug 2002 18:44:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006DAF88@cherry.ease.lsoft.com>; Fri, 16 Aug 2002 18:46:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 117624 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 16 Aug 2002 18:46:01 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 16 Aug 2002 18:46:01 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17fpr0-000KAv-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 16 Aug 2002 15:46:02 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <20020815163153.4212.qmail@mail.com> <3D5C86F0.8000103@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <31844444.20020816154432@psg.com> Date: Fri, 16 Aug 2002 15:44:32 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: How many changes can be in one LSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3D5C86F0.8000103@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Thursday, August 15, 2002, 10:00:32 PM, Acee Lindem wrote: >> If more than one change occurs in a router for instance: one link changes cost >> and another link goes down simutaneously, will this two changes be signalled in >> one LSA or two LSAs will be generated for that ? I mean, is the LSA limited to >> one change at a time ? > Hello Beatriz, > This is somewhat implementation dependent but in general simultaneous > events should result in a single router LSA re-origination. There is > no limit to the number of changes that can be contained in a single > LSA. Right, and the reason for this is that LSAs do not contain _changes_, they contain a snapshot of the router's curren state (the link state in the router-LSA case.) Just making sure we all are on the same page. Alex From owner-ospf@DISCUSS.MICROSOFT.COM Mon Aug 19 05:54:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26713 for ; Mon, 19 Aug 2002 05:54:32 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.006DEBEA@cherry.ease.lsoft.com>; Mon, 19 Aug 2002 5:55:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 124833 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 19 Aug 2002 05:55:46 -0400 Received: from 212.234.238.114 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 19 Aug 2002 05:45:46 -0400 Received: from intranet.6wind.com (intranet.6wind.com [10.0.0.113]) by givenchy.6wind.com (Postfix) with ESMTP id 46D47862 for ; Mon, 19 Aug 2002 11:54:38 +0200 (CEST) Received: from 6wind.com (intranet.6wind.com [10.0.0.113]) by intranet.6wind.com (Postfix) with ESMTP id 0B6E3B4FA for ; Mon, 19 Aug 2002 11:45:39 +0200 (CEST) X-Mailer: Mozilla 4.72 [fr] (X11; U; Linux 2.2.14-6.1.1smp i686) X-Accept-Language: fr, en MIME-Version: 1.0 References: <3D5B4B88.215EA127@arc.corp.mot.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3D60BE42.2B403ECD@6wind.com> Date: Mon, 19 Aug 2002 11:45:39 +0200 Reply-To: Mailing List Sender: Mailing List From: Vincent Jardin Organization: http://www.6WIND.net Subject: Re: Routing IPv4 with OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Arthur Dimitrelis a écrit : > > Greetings, > > I'm interested in people's opinions and experiences in using OSPFv3 (aka > OSPF for IPv6) for routing IPv4. > > My understanding from reading the OSPFv3 specification (RFC2740) is that > OSPFv3 is designed with a degree of protocol independence. By this I > mean that you could, in principle, use OSPFv3 to route any protocol > family you chose, just so long as you were able to map addressing > information to the topology (and of course your OSPF code knew how to > set up the correct forwarding state for your given protocol family). The > topology-to-address mapping for IPv6 is done using OSPFv3's > Intra-area-prefix-LSAs, but the spec makes no mention of how you might > map IPv4 addressing information to a network topology. > > So, my questions are: > - Regarding OSPFv3 - is the bulk of it protocol agnostic, or is it just > my imagination? Was it the intention of the protocol authors to create a > protocol that could easily route multiple protocol families, or just > IPv6? > - Is there any interest out there in using OSPFv3 to route IPv4? According to me, if there is a single routing protocol for both IPv4 and IPv6, the routers that support only an IPvX could be detected. Some tunnels could be used to route through them. The endpoints of these tunnels could be the routers that support both IPv4 and IPv6. My understanding of the section 3.8 of the Integrated IS-IS RFC-1195 is that IS-IS supports this kind of feature that is described by the ISO/10589. However, who needs this repairing function ? Regards, Vincent From owner-ospf@DISCUSS.MICROSOFT.COM Mon Aug 19 12:45:30 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08957 for ; Mon, 19 Aug 2002 12:45:30 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.006DF796@cherry.ease.lsoft.com>; Mon, 19 Aug 2002 12:46:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 127232 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 19 Aug 2002 12:46:47 -0400 Received: from 205.158.62.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 19 Aug 2002 12:46:47 -0400 Received: (qmail 59966 invoked by uid 1001); 19 Aug 2002 16:45:43 -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 [129.187.254.13] by ws1-4.us4.outblaze.com with http for beatriz_hargrave@mail.com; Mon, 19 Aug 2002 11:45:42 -0500 X-Originating-Ip: 129.187.254.13 X-Originating-Server: ws1-4.us4.outblaze.com Message-ID: <20020819164543.59965.qmail@mail.com> Date: Mon, 19 Aug 2002 11:45:42 -0500 Reply-To: Mailing List Sender: Mailing List From: Beatriz Silva Subject: Which LSA is generate first To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello everybody ! Thanks again ! I would like to know the following: If a link of a router goes down and this link is part of a Broadcast network, whose Designated Router is the same that the link went down. Which LSA will be generated first, the router LSA or the network LSA saying that the network contains now less routers than it used to have. Who generates the network LSA is the new DR for the network ? Thanks, Beatriz -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup From owner-ospf@DISCUSS.MICROSOFT.COM Mon Aug 19 13:45:42 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10756 for ; Mon, 19 Aug 2002 13:45:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.006DFA28@cherry.ease.lsoft.com>; Mon, 19 Aug 2002 13:47:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 127535 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 19 Aug 2002 13:46:58 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 19 Aug 2002 13:46:57 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 0A9A839B5A6; Mon, 19 Aug 2002 10:47:00 -0700 (PDT) Message-ID: <20020819174700.0A9A839B5A6@prattle.redback.com> Date: Mon, 19 Aug 2002 10:46:59 -0700 Reply-To: Mailing List Sender: Mailing List From: Naiming Shen Subject: Re: Routing IPv4 with OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Mail from Vincent Jardin dated Mon, 19 Aug 2002 11:45:39 +0200 <3D60BE42.2B403ECD@6wind.com> Precedence: list ] Arthur Dimitrelis a écrit : ] > ] > Greetings, ] > ] > I'm interested in people's opinions and experiences in using OSPFv3 (aka ] > OSPF for IPv6) for routing IPv4. ] > ] > My understanding from reading the OSPFv3 specification (RFC2740) is that ] > OSPFv3 is designed with a degree of protocol independence. By this I ] > mean that you could, in principle, use OSPFv3 to route any protocol ] > family you chose, just so long as you were able to map addressing ] > information to the topology (and of course your OSPF code knew how to ] > set up the correct forwarding state for your given protocol family). The ] > topology-to-address mapping for IPv6 is done using OSPFv3's ] > Intra-area-prefix-LSAs, but the spec makes no mention of how you might ] > map IPv4 addressing information to a network topology. ] > ] > So, my questions are: ] > - Regarding OSPFv3 - is the bulk of it protocol agnostic, or is it just ] > my imagination? Was it the intention of the protocol authors to create a ] > protocol that could easily route multiple protocol families, or just ] > IPv6? ] > - Is there any interest out there in using OSPFv3 to route IPv4? ] ] According to me, if there is a single routing protocol for both IPv4 and ] IPv6, the routers that support only an IPvX could be detected. Some ] tunnels could be used to route through them. The endpoints of these ] tunnels could be the routers that support both IPv4 and IPv6. You probably can detect the both ends of the link support IPv4 and IPv6, but thats usually not enough. You need to know if this is a IPv6 only link or not. It's ok to tunnel IPv6 to bridge islands, but it's not ok to also forward IPv4 traffic through the tunnel(assume the tunnel is for IPv6). ] ] My understanding of the section 3.8 of the Integrated IS-IS RFC-1195 is ] that IS-IS supports this kind of feature that is described by the ] ISO/10589. I don't think current IS-IS spec/implementations support automatic encapsulation stuff. A "dual" router in ISIS must set the "protocols supported" field to be identical on every link of the router. In other words you can not have a router with some links to be v4 only, some to be v6 only and others are dual. One proposal to solve this problem is to use "multi topology" of IS-IS, see draft: http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-04.txt thanks. ] ] However, who needs this repairing function ? ] ] Regards, ] Vincent - Naiming From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 20 09:40:48 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14042 for ; Tue, 20 Aug 2002 09:40:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006E16BB@cherry.ease.lsoft.com>; Tue, 20 Aug 2002 9:42:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 131566 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 20 Aug 2002 09:42:03 -0400 Received: from 192.128.166.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 20 Aug 2002 09:42:03 -0400 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g7KBwceh012466 for ; Tue, 20 Aug 2002 09:42:03 -0400 (EDT) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (6.5.019) id 3CE519BE02B7C471; Tue, 20 Aug 2002 09:42:00 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Congestion Avoidance & Control for OSPF Networks Thread-Index: AcI+PWTykLPX1gOTRMWPTUGEE8gzwwKDpgkA Message-ID: <28F05913385EAC43AF019413F674A0170167B11E@OCCLUST04EVS1.ugd.att.com> Date: Tue, 20 Aug 2002 09:42:00 -0400 Reply-To: Mailing List Sender: Mailing List From: "Ash, Gerald R (Jerry), ALASO" Subject: Re: Congestion Avoidance & Control for OSPF Networks Comments: To: Chaoping Wu To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA14042 Dear Chaoping, Thank you very much again for your comments, see responses below. Regards, Jerry Ash > >> 1. Outbound Congestion Notification > >> This I-D suggests this notification not required in some way > >> (section 4.2.1). But I think this notification is important and may > >> complement the whole mechanism in the following way: > >> A. Identifying source of congestion. > >> In OSPF network types NBMA, P-TO-P, P-T--MP, Virtual links, OSPF > >> packets may go through some kind of transit networks which may > >> be congested for some reason. In this scenario, the receiving > >> OSPF router can tell if the originating router experiences > >> congestion or not. > >> > >> B. Faster notification is possible if outbound congestion notification > >> is performed. It should be sent immediately once detected. > >Though what you say is true, if I have understood you correctly, we have > >tried to avoid signaling both for our own congestion as well as congestion > >at the other end(which is also harder to predict). We have gone with the > >assumption that if the congestion occurs at the other end, then the > >congested router will notify about it. This fact has been put forward in > >Section 4.2.1, maybe we can clarify that further. > This particular comment was about outband congestion at a local router > only, rather than any congestion at a remote side as you implied in the > reply (I agree with you that remote end congestion is harder to predict, > but this is not the point I was trying to make above). > > The question is what should the local OSPF router do if it detects > outband congestion? > > In section 4.2.1, the ID says > "Detecting outbound congestion in some way > does not require notification, since we should assume the adjacent > router will detect this congestion on its own." > > While this is true, but it loses the some benefits, such as the points > in 1.A & 1.B as I mentioned above. So, instead, I think we should > promote the usage of explicit outband congestion notification in > this ID. I agree that we should only be dealing with detecting 'outbound' congestion at a router, and not trying to detect congestion at some neighbor router. I think the quote above from Section 4.2.1 is misleading, and needs to be clarified in the next revision to say something like: "Detecting outbound congestion requires immediate notification to all neighboring routers". > Also another related note is the triggering time of Hello messages > that contain LLS congestion signaling. It was not clear from the ID if > this signaling should be sent immediately once congestion is detected, > or wait until the traditional Hello timer expire. Although this may be > somewhat implementation dependent, but I think we should probably > promote the better way: immediate notification. Agreed, and it should be made explicit in the next revision. > >> 2. State of Congestion > >> This I-D specifies 3 states MUST be defined (section 4.2.1) but it > >> has not specified a consistent way of defining the states. > >> > >> In networks mixed with different vendor routers, if a "high congestion > >> state" in one router is equivalent to "low congestion state" of its > >> neighboring router that is made by a different vendor using different > >> definitions of congestion state, the resulted congestion measures in > >> this network may not be as desired, isn't it? > >Though what you say would be desired, however, there can be no perfect way > >to exactly classify it, on different routers/vendors/etc. We have however > >given some suggestions in the beginning of the section, we can try to make > >the classifications more precise. > Agreed on "no perfect way to exactly classify it". But if we have a > desire to explore ideas to make it better, we may find other ways. > More on this point in the near future. I think you raised a good point, that is, to be more precise in defining congestion state. I think it would be important for interoperability, and that we should go further in defining congestion states in the next revision. Your further suggestions would be appreciated. > >> 3. Adding A Congestion Prediction Concept > >> What about incorporating a congestion prediction concept into this > >> I-D? Preventive congestion measures should be very used for network > >> administrators to get alerted about when they should start consider > >> optimize their networks. Potential congestion may be simply another > >> congestion state. > >As the actual signaling of congestion and measure of levels of congestion > >has been left to the implementation, an implementation could always signal > >low congestion, when it can predict it is going into congestion. The exact > >prediction methods are left to the local router itself, and as Jerry pointed > >out it may be hard to predict it. > This ID does provide a good mechanism on congestion prevention. > But if you go one step further to introduce the concept of congestion > prevention in the ID, I believe it would open another > door of useful capabilities. > > Congestion prediction has been implemented in networking equipment. > It may be easier than you think. If there's enough interest, I'll > make some suggestions later. Is there any reference to where 'congestion prediction has been implemented in networking equipment'? Again, your further suggestions are appreciated. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Aug 20 15:30:43 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23103 for ; Tue, 20 Aug 2002 15:30:42 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.006E20B2@cherry.ease.lsoft.com>; Tue, 20 Aug 2002 15:32:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 133487 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 20 Aug 2002 15:32:00 -0400 Received: from 134.56.3.107 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 20 Aug 2002 15:21:59 -0400 Received: from unet.net.com (fremont-ns2.net.com [134.56.112.30]) by relay1.net.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14150 for ; Tue, 20 Aug 2002 12:18:04 -0700 (PDT) Received: from west-mail.net.com by unet.net.com (8.9.3/SMI-SVR4) id MAA09120; Tue, 20 Aug 2002 12:22:49 -0700 (PDT) Received: from net.com ([134.56.24.21]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA372A; Tue, 20 Aug 2002 12:21:58 -0700 X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D6296D4.82D856CE@net.com> Date: Tue, 20 Aug 2002 12:21:56 -0700 Reply-To: Mailing List Sender: Mailing List From: Mani Devarajan Organization: N.E.T. http://www.net.com Subject: Question about injecting default route by ASBR Comments: cc: manid@net.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi all, How important is for ASBR to inject a default route into AS. Is it MUST/OPTIONAL. RFC 2328 doesnt say its MUST or NOT. Does live network needs this option. And whether it make any difference in reducing the traffic with in AS. Thanks & Regards, ; Tue, 20 Aug 2002 18:12:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.006E265B@cherry.ease.lsoft.com>; Tue, 20 Aug 2002 18:13:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 76903 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 20 Aug 2002 18:13:31 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 20 Aug 2002 18:13:31 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 48EC04BA217 for ; Tue, 20 Aug 2002 15:13:29 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <3D6296D4.82D856CE@net.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D62BF1C.80600@redback.com> Date: Tue, 20 Aug 2002 18:13:48 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question about injecting default route by ASBR To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mani Devarajan wrote: > Hi all, > > How important is for ASBR to inject a default route into > AS. Is it MUST/OPTIONAL. RFC 2328 doesnt say its MUST > or NOT. Hello Mani, In general, RFC 2328 doesn't deal with origination of external defaults or the redistribution (aka, import) of routes from other protocols. However, it does describe the composition of an OSPF AS external LSA for a default route. Most OSPF implementations provide the capability to originate a default route under configuration control. > > Does live network needs this option. And whether it make > any difference in reducing the traffic with in AS. It depends on the situation. In any case, this should be a configurable option. > > Thanks & Regards, > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 21 07:38:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06802 for ; Wed, 21 Aug 2002 07:38:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006E367F@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 7:40:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 79904 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 21 Aug 2002 07:40:06 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 21 Aug 2002 07:40:06 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Aug 2002 07:40:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 21 Aug 2002 07:42:12 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Which LSA is generate first To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Beatriz, Please have a look at RFC2328, you can get answers to most of ur questions there. http://www.ietf.org/rfc/rfc2328.txt You could also try to have a look at the archives at http://discuss.microsoft.com/archives/ospf.html However for ur question, the DR originates the network LSA, and there is no strict ordering requirement of the order in which LSA's are to be generated. Thanks, Vishwas -----Original Message----- From: Beatriz Silva [mailto:beatriz_hargrave@MAIL.COM] Sent: Monday, August 19, 2002 10:16 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Which LSA is generate first Hello everybody ! Thanks again ! I would like to know the following: If a link of a router goes down and this link is part of a Broadcast network, whose Designated Router is the same that the link went down. Which LSA will be generated first, the router LSA or the network LSA saying that the network contains now less routers than it used to have. Who generates the network LSA is the new DR for the network ? Thanks, Beatriz From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 21 11:43:02 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13971 for ; Wed, 21 Aug 2002 11:43:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.006E3C8E@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 11:44:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 81058 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 21 Aug 2002 11:44:23 -0400 Received: from 217.32.166.20 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 21 Aug 2002 11:34:20 -0400 Received: from cbibipnt03.HC.BT.COM ([147.149.196.180]) by relhubc02-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 21 Aug 2002 16:32:29 +0100 Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 21 Aug 2002 16:26:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain X-OriginalArrivalTime: 21 Aug 2002 15:32:29.0282 (UTC) FILETIME=[F5996C20:01C24927] Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB216C27BA3@mbtlipnt02.btlabs.bt.co.uk> Date: Wed, 21 Aug 2002 16:21:25 +0100 Reply-To: Mailing List Sender: Mailing List From: Ben Niven-Jenkins Subject: OSPF-TE link parameters To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list draft-katz-yeung-ospf-traffic describes a Link TLV that contains various TE parameters such Resource colour & TE metric. I would like to know if there is a current MIB that can be used to extract this information from a router/LSR using SNMP? If a MIB doesn't already exist is any work being done on a MIB that will contain this information. Thanks Ben From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 21 12:04:14 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14683 for ; Wed, 21 Aug 2002 12:04:13 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006E3C74@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 12:05:36 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 81232 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 21 Aug 2002 12:05:35 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 21 Aug 2002 12:05:35 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 4D677F2C4A for ; Wed, 21 Aug 2002 09:05:34 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <5104D4DBC598D211B5FE0000F8FE7EB216C27BA3@mbtlipnt02.btlabs.bt.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D63BA57.4060405@redback.com> Date: Wed, 21 Aug 2002 12:05:43 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF-TE link parameters To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Ben Niven-Jenkins wrote: > draft-katz-yeung-ospf-traffic describes a Link TLV that contains various TE > parameters such Resource colour & TE metric. I would like to know if there > is a current MIB that can be used to extract this information from a > router/LSR using SNMP? > > If a MIB doesn't already exist is any work being done on a MIB that will > contain this information. Ben, The update to the OSPF MIB (draft-ietf-ospf-mib-update-05.txt) supports the retrieval of opaque LSAs. An application would need to parse ospfLsdbAdvertisement to exact the TE TLVs. Has anyone implemented this MIB update? > > Thanks > Ben > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 21 12:21:21 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15046 for ; Wed, 21 Aug 2002 12:21:21 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.006E3D35@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 12:22:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 81315 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 21 Aug 2002 12:22:43 -0400 Received: from 217.32.166.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 21 Aug 2002 12:22:43 -0400 Received: from cbibipnt02.HC.BT.COM ([147.149.196.178]) by relhubc01-ukbr.tcrelay.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 21 Aug 2002 17:20:51 +0100 Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Wed, 21 Aug 2002 17:22:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain X-OriginalArrivalTime: 21 Aug 2002 16:20:51.0916 (UTC) FILETIME=[B7B438C0:01C2492E] Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB216C27C25@mbtlipnt02.btlabs.bt.co.uk> Date: Wed, 21 Aug 2002 17:17:43 +0100 Reply-To: Mailing List Sender: Mailing List From: Ben Niven-Jenkins Subject: Re: OSPF-TE link parameters To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Acee, Thanks for your prompt response. I will investigate the draft you mention. This might be slightly off topic for this list, but anyway: As I see it (this maybe implementation specific), the additional TE parameters have to be configured on the router and associated with an interface. These additional parameters are then advertised through OSPF. Assuming that the router is not running OSPF at all or the router is only running vanilla OSPF not OSPF-TE, but the TE parameters are still configured. Is there a MIB that can be used to extract the general TE parameters without resorting to an OSPF specific MIB. If not, assuming I would like to extract the TE parameters from routers running OSPF and ISIS, is my only alternative to have one piece of code to extract them from the OSPF MIB and another to extract them from the ISIS MIB? > -----Original Message----- > From: Acee Lindem [SMTP:acee@redback.com] > Sent: 21 August 2002 17:06 > To: Mailing List > Subject: Re: OSPF-TE link parameters > > Ben Niven-Jenkins wrote: > > > draft-katz-yeung-ospf-traffic describes a Link TLV that contains various > TE > > parameters such Resource colour & TE metric. I would like to know if > there > > is a current MIB that can be used to extract this information from a > > router/LSR using SNMP? > > > > If a MIB doesn't already exist is any work being done on a MIB that will > > contain this information. > > > Ben, > > The update to the OSPF MIB (draft-ietf-ospf-mib-update-05.txt) > supports the retrieval of opaque LSAs. An application would need > to parse ospfLsdbAdvertisement to exact the TE TLVs. > > Has anyone implemented this MIB update? > > > > > > Thanks > > Ben > > > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 21 12:30:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15285 for ; Wed, 21 Aug 2002 12:30:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006E3C7F@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 12:31:39 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 81374 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 21 Aug 2002 12:31:39 -0400 Received: from 192.11.226.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 21 Aug 2002 12:31:39 -0400 Received: from ma8117exch001p.wins.lucent.com (h152-148-89-177.lucent.com [152.148.89.177]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7LGVc904885 for ; Wed, 21 Aug 2002 12:31:38 -0400 (EDT) Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Aug 2002 12:31:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Message-ID: Date: Wed, 21 Aug 2002 12:31:36 -0400 Reply-To: Mailing List Sender: Mailing List From: "Joyal, Daniel R (Daniel)" Subject: Re: OSPF-TE link parameters To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Ben, Acee, Since the TE Opaque LSAs are of area scope, I think the RFC1850 MIB should work as Acee describes. The MIB update does not invent a new area LSDB table for opaque LSAs. It just specifies a textual identifier for type-10s in the existing Area LSDB table so that management systems or MIB browsers can translate the type number 10 to "type-10" for display. Type-11s go in the extLSDB table. The update does define a new LSDB table for type-9s, though, because the other two tables don't have a link/interface index component. -Dan -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Wednesday, August 21, 2002 12:06 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF-TE link parameters Ben Niven-Jenkins wrote: > draft-katz-yeung-ospf-traffic describes a Link TLV that contains various TE > parameters such Resource colour & TE metric. I would like to know if there > is a current MIB that can be used to extract this information from a > router/LSR using SNMP? > > If a MIB doesn't already exist is any work being done on a MIB that will > contain this information. Ben, The update to the OSPF MIB (draft-ietf-ospf-mib-update-05.txt) supports the retrieval of opaque LSAs. An application would need to parse ospfLsdbAdvertisement to exact the TE TLVs. Has anyone implemented this MIB update? > > Thanks > Ben > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 21 12:45:06 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15885 for ; Wed, 21 Aug 2002 12:45:06 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006E3BD0@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 12:46:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 81449 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 21 Aug 2002 12:46:28 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 21 Aug 2002 12:46:25 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id CF9F9449A2D for ; Wed, 21 Aug 2002 09:46:23 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 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: <3D63C3E8.9050609@redback.com> Date: Wed, 21 Aug 2002 12:46:32 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF-TE link parameters To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Joyal, Daniel R (Daniel) wrote: > Ben, Acee, > > Since the TE Opaque LSAs are of area scope, I think the > RFC1850 MIB should work as Acee describes. The MIB update > does not invent a new area LSDB table for opaque LSAs. It > just specifies a textual identifier for type-10s in the existing > Area LSDB table so that management systems or MIB browsers can > translate the type number 10 to "type-10" for display. Type-11s go > in the extLSDB table. The update does define a new LSDB table for > type-9s, though, because the other two tables don't have > a link/interface index component. Dan, RFC 1850 doesn't include the area scoped opaque LSA type in the ospfLsdbType enumeration (although it could be possible that some implementations support it anyway). ospfLsdbType OBJECT-TYPE SYNTAX INTEGER { routerLink (1), networkLink (2), summaryLink (3), asSummaryLink (4), asExternalLink (5), -- but see ospfExtLsdbTable multicastLink (6), nssaExternalLink (7) } Thanks, Acee > > -Dan > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Wednesday, August 21, 2002 12:06 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPF-TE link parameters > > > Ben Niven-Jenkins wrote: > > >>draft-katz-yeung-ospf-traffic describes a Link TLV that contains various >> > TE > >>parameters such Resource colour & TE metric. I would like to know if >> > there > >>is a current MIB that can be used to extract this information from a >>router/LSR using SNMP? >> >>If a MIB doesn't already exist is any work being done on a MIB that will >>contain this information. >> > > > Ben, > > The update to the OSPF MIB (draft-ietf-ospf-mib-update-05.txt) > supports the retrieval of opaque LSAs. An application would need > to parse ospfLsdbAdvertisement to exact the TE TLVs. > > Has anyone implemented this MIB update? > > > >>Thanks >>Ben >> >> >> > > > -- > Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 21 12:59:31 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16665 for ; Wed, 21 Aug 2002 12:59:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006E3E93@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 13:00:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 81520 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 21 Aug 2002 13:00:53 -0400 Received: from 192.11.226.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 21 Aug 2002 13:00:53 -0400 Received: from ma8117exch001p.wins.lucent.com (h152-148-89-177.lucent.com [152.148.89.177]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7LH0q303527 for ; Wed, 21 Aug 2002 13:00:52 -0400 (EDT) Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Aug 2002 13:00:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Message-ID: Date: Wed, 21 Aug 2002 13:00:51 -0400 Reply-To: Mailing List Sender: Mailing List From: "Joyal, Daniel R (Daniel)" Subject: Re: OSPF-TE link parameters To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Acee, That's correct. I don't believe the enumeration is necessary for implementations to support the TE-LSAs. -Dan -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Wednesday, August 21, 2002 12:47 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF-TE link parameters Joyal, Daniel R (Daniel) wrote: > Ben, Acee, > > Since the TE Opaque LSAs are of area scope, I think the > RFC1850 MIB should work as Acee describes. The MIB update > does not invent a new area LSDB table for opaque LSAs. It > just specifies a textual identifier for type-10s in the existing > Area LSDB table so that management systems or MIB browsers can > translate the type number 10 to "type-10" for display. Type-11s go > in the extLSDB table. The update does define a new LSDB table for > type-9s, though, because the other two tables don't have > a link/interface index component. Dan, RFC 1850 doesn't include the area scoped opaque LSA type in the ospfLsdbType enumeration (although it could be possible that some implementations support it anyway). ospfLsdbType OBJECT-TYPE SYNTAX INTEGER { routerLink (1), networkLink (2), summaryLink (3), asSummaryLink (4), asExternalLink (5), -- but see ospfExtLsdbTable multicastLink (6), nssaExternalLink (7) } Thanks, Acee > > -Dan > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Wednesday, August 21, 2002 12:06 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPF-TE link parameters > > > Ben Niven-Jenkins wrote: > > >>draft-katz-yeung-ospf-traffic describes a Link TLV that contains various >> > TE > >>parameters such Resource colour & TE metric. I would like to know if >> > there > >>is a current MIB that can be used to extract this information from a >>router/LSR using SNMP? >> >>If a MIB doesn't already exist is any work being done on a MIB that will >>contain this information. >> > > > Ben, > > The update to the OSPF MIB (draft-ietf-ospf-mib-update-05.txt) > supports the retrieval of opaque LSAs. An application would need > to parse ospfLsdbAdvertisement to exact the TE TLVs. > > Has anyone implemented this MIB update? > > > >>Thanks >>Ben >> >> >> > > > -- > Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Aug 21 14:30:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20569 for ; Wed, 21 Aug 2002 14:30:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.006E3F62@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 14:31:39 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 81902 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 21 Aug 2002 14:31:39 -0400 Received: from 134.56.3.108 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 21 Aug 2002 14:21:38 -0400 Received: from isis.net.com (fremont-ns1.net.com [134.56.112.20]) by relay2.net.com (8.11.3/8.9.3) with ESMTP id g7LIMM009169 for ; Wed, 21 Aug 2002 11:22:22 -0700 (PDT) Received: from west-mail.net.com by isis.net.com (8.9.3/SMI-SVR4) id LAA04205; Wed, 21 Aug 2002 11:22:21 -0700 (PDT) Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA1305 for ; Wed, 21 Aug 2002 11:21:30 -0700 X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D63DA29.E06CECDF@net.com> Date: Wed, 21 Aug 2002 11:21:29 -0700 Reply-To: Mailing List Sender: Mailing List From: Mani Devarajan Organization: N.E.T. http://www.net.com Subject: Question about Type2 redistribution in to OSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit RFC 2328: ========= Section - 12.4.4. AS-external-LSAs Type 2 metrics are assumed to be larger than the cost of any intra-AS path. In one other document I read ,it says that for type 2 it will be always external cost irrespective of inter area cost. type 2 ----- ----- ----- | | | | | | | R1 | | R2 | |ASBR | | | | | | | ----- ----- ----- |10 | |10 | | ----- ------ ----| | External Network | If ASBR redistributes route for external network at a cost of 5, R1 will have a route to external network with cost == 5 or cost > 10. Thanks in advance, ; Wed, 21 Aug 2002 16:25:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006E40A1@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 16:27:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 82290 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 21 Aug 2002 16:27:13 -0400 Received: from 65.192.41.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 21 Aug 2002 16:17:13 -0400 Received: from dhcp-168-0-85.packetdesign.com (dhcp-168-0-85.packetdesign.com [192.168.0.85]) by mailman.packetdesign.com (8.11.6/8.11.6) with ESMTP id g7LKHBx92443 for ; Wed, 21 Aug 2002 13:17:11 -0700 (PDT) (envelope-from nikhil@packetdesign.com) References: <3D63DA29.E06CECDF@net.com> Content-Type: multipart/alternative; boundary="=-OJLVQclZ4rLqyTaW7PHk" X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Mime-Version: 1.0 Message-ID: <1029961010.1459.85.camel@dhcp-168-0-85.packetdesign.com> Date: Wed, 21 Aug 2002 13:16:49 -0700 Reply-To: Mailing List Sender: Mailing List From: Nikhil Sama Subject: Re: Question about Type2 redistribution in to OSPF To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3D63DA29.E06CECDF@net.com> Precedence: list --=-OJLVQclZ4rLqyTaW7PHk Content-Type: text/plain Content-Transfer-Encoding: 7bit R1 will have a cost of 5 to the type-2 external route mentioned. The reason is, as you mentioned .. "Type 2 metrics are assumed to be larger than the cost of any intra-AS path." If there was another type-2 external route available to the same destination prefix via another internal ASBR/Next-Hop, then your decision on which route to pick should be independent of your cost to the different internal next-hop's but based solely on the type 2 metrics. This would not "necessarily" be the case had you added the internal cost(of getting to the next-hop) to the type-2 metric. Hope this helps ! /ns On Wed, 2002-08-21 at 11:21, Mani Devarajan wrote: RFC 2328: ========= Section - 12.4.4. AS-external-LSAs Type 2 metrics are assumed to be larger than the cost of any intra-AS path. In one other document I read ,it says that for type 2 it will be always external cost irrespective of inter area cost. type 2 ----- ----- ----- | | | | | | | R1 | | R2 | |ASBR | | | | | | | ----- ----- ----- |10 | |10 | | ----- ------ ----| | External Network | If ASBR redistributes route for external network at a cost of 5, R1 will have a route to external network with cost == 5 or cost > 10. Thanks in advance,
R1 will have a cost of 5 to the type-2 external route mentioned.

The reason is, as you mentioned ..
"Type 2 metrics are assumed to be larger than the cost of any intra-AS path." 

If there was another type-2 external route available to the same destination prefix via another internal ASBR/Next-Hop, then your decision on which route to pick should be independent of your cost to the different internal next-hop's but based solely on the type 2 metrics.
This would not "necessarily" be the case had you added the internal cost(of getting to the next-hop) to the type-2 metric.

Hope this helps !
/ns

On Wed, 2002-08-21 at 11:21, Mani Devarajan wrote: 
RFC 2328:
=========
Section - 12.4.4.  AS-external-LSAs

Type 2 metrics are assumed to be larger than
the cost of any intra-AS path.

In one other document I read ,it says that for type 2
it will be always external cost irrespective of inter
area cost.

                          type 2
      -----     -----     -----
     |     |   |     |   |     |
     | R1  |   | R2  |   |ASBR |
     |     |   |     |   |     |
      -----     -----     -----
          |10   |   |10    |  |
           -----     ------    ----|
                                   | External Network
                                   |
If ASBR redistributes route for external network at a
cost of 5, R1 will have a route to external network
with cost == 5 or cost > 10.

Thanks in advance,
<Mani










--=-OJLVQclZ4rLqyTaW7PHk--


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 21 16:30:16 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24510
	for ; Wed, 21 Aug 2002 16:30:16 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006E4331@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 16:31:40 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 82306 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 21 Aug 2002 16:31:40 -0400
Received: from 65.192.41.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 21 Aug 2002 16:21:39 -0400
Received: from dhcp-168-0-85.packetdesign.com (dhcp-168-0-85.packetdesign.com
          [192.168.0.85]) by mailman.packetdesign.com (8.11.6/8.11.6) with
          ESMTP id g7LKLcx92644 for ; Wed, 21 Aug
          2002 13:21:38 -0700 (PDT) (envelope-from nikhil@packetdesign.com)
References:  <3D63DA29.E06CECDF@net.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6)
Mime-Version: 1.0
Message-ID:  <1029961277.1459.89.camel@dhcp-168-0-85.packetdesign.com>
Date:         Wed, 21 Aug 2002 13:21:16 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Nikhil Sama 
Subject: Re: Question about Type2 redistribution in to OSPF
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D63DA29.E06CECDF@net.com>
Precedence: list
Content-Transfer-Encoding: 7bit

R1 will have a cost of 5 to the type-2 external route mentioned.

The reason is, as you mentioned ..
"Type 2 metrics are assumed to be larger than the cost of any intra-AS
path."

If there was another type-2 external route available to the same
destination prefix via another internal ASBR/Next-Hop, then your
decision on which route to pick should be independent of your cost to
the different internal next-hop's but based solely on the type 2
metrics.
This would not "necessarily" be the case had you added the internal
cost(of getting to the next-hop) to the type-2 metric.

Hope this helps !
/ns

On Wed, 2002-08-21 at 11:21, Mani Devarajan wrote:
> RFC 2328:
> =========
> Section - 12.4.4.  AS-external-LSAs
>
> Type 2 metrics are assumed to be larger than
> the cost of any intra-AS path.
>
> In one other document I read ,it says that for type 2
> it will be always external cost irrespective of inter
> area cost.
>
>                           type 2
>       -----     -----     -----
>      |     |   |     |   |     |
>      | R1  |   | R2  |   |ASBR |
>      |     |   |     |   |     |
>       -----     -----     -----
>           |10   |   |10    |  |
>            -----     ------    ----|
>                                    | External Network
>                                    |
> If ASBR redistributes route for external network at a
> cost of 5, R1 will have a route to external network
> with cost == 5 or cost > 10.
>
> Thanks in advance,
> 


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 21 16:41:01 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24989
	for ; Wed, 21 Aug 2002 16:41:01 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006E41E8@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 16:42:25 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 82412 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 21 Aug 2002 16:42:25 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 21 Aug 2002 16:42:25 -0400
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7LKgOm89368 for
          ; Wed, 21 Aug 2002 13:42:24 -0700 (PDT)
          (envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost) by kummer.juniper.net
          (8.11.6/8.9.3) with ESMTP id g7LKgOv83076 for
          ; Wed, 21 Aug 2002 13:42:24 -0700 (PDT)
          (envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <20020821133217.D82949-100000@kummer.juniper.net>
Date:         Wed, 21 Aug 2002 13:42:24 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Kireeti Kompella 
Subject: ospf te doc
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi All,

Here's what the updated section 2.2 of the ospf te doc
(draft-katz-yeung-ospf-traffic-07.txt) looks like:

2.2. LSA ID

   The LSA ID of an Opaque LSA is defined as having eight bits of type
   and 24 bits of type-specific data.  The Traffic Engineering LSA uses
   type 1.  The remaining 24 bits are broken up into eight bits of
   reserved space (which SHOULD be zero on transmission and ignored on
   receipt) and sixteen bits of instance:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       1       |    Reserved   |           Instance            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Instance field is an arbitrary value used to maintain multiple
   Traffic Engineering LSAs.  A maximum of 65536 Traffic Engineering
   LSAs may be sourced by a single system.  The LSA ID has no
   topological significance.

The issues are
a) what should the wording regarding the "Reserved" field be?
b) how should TE LSAs received with "illegal" values be treated?
   (for example in the wording as above, how should a TE LSA with
   a non-zero Reserved field be treated)?

One suggestion is to require the "Reserved" field to be zero, much
as John Moy requires the Opaque ID to be zero in a Grace LSA.  A
TE LSA received with a non-zero Reserved field is to be treated as
an unknown Opaque LSA (how are unknown Opaque LSAs treated?  Dropped?
Flooded?).

Thoughts?  Other suggestions?

Kireeti.


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 21 16:41:54 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25062
	for ; Wed, 21 Aug 2002 16:41:53 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006E428E@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 16:43:18 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 82429 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 21 Aug 2002 16:43:18 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 21 Aug 2002 16:43:18 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id 3227D4483E6 for
          ; Wed, 21 Aug 2002 13:43:16 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D63DA29.E06CECDF@net.com>
            <1029961277.1459.89.camel@dhcp-168-0-85.packetdesign.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D63FB6A.2030807@redback.com>
Date:         Wed, 21 Aug 2002 16:43:22 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: Question about Type2 redistribution in to OSPF
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Nikhil Sama wrote:

> R1 will have a cost of 5 to the type-2 external route mentioned.
>
> The reason is, as you mentioned ..
> "Type 2 metrics are assumed to be larger than the cost of any intra-AS
> path."
>
> If there was another type-2 external route available to the same
> destination prefix via another internal ASBR/Next-Hop, then your
> decision on which route to pick should be independent of your cost to
> the different internal next-hop's but based solely on the type 2
> metrics.


This is true as long as the type-2 metrics from the two ASBRs differ.
When they are equal then the OSPF cost to the ASBR/forwarding address is
considered. Refer to section 16.4 in RFC 2328 for the details.


> This would not "necessarily" be the case had you added the internal
> cost(of getting to the next-hop) to the type-2 metric.
>
> Hope this helps !
> /ns
>
> On Wed, 2002-08-21 at 11:21, Mani Devarajan wrote:
>
>>RFC 2328:
>>=========
>>Section - 12.4.4.  AS-external-LSAs
>>
>>Type 2 metrics are assumed to be larger than
>>the cost of any intra-AS path.
>>
>>In one other document I read ,it says that for type 2
>>it will be always external cost irrespective of inter
>>area cost.
>>
>>                          type 2
>>      -----     -----     -----
>>     |     |   |     |   |     |
>>     | R1  |   | R2  |   |ASBR |
>>     |     |   |     |   |     |
>>      -----     -----     -----
>>          |10   |   |10    |  |
>>           -----     ------    ----|
>>                                   | External Network
>>                                   |
>>If ASBR redistributes route for external network at a
>>cost of 5, R1 will have a route to external network
>>with cost == 5 or cost > 10.
>>
>>Thanks in advance,
>>>
>>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 21 16:59:16 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25780
	for ; Wed, 21 Aug 2002 16:59:16 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.006E44C1@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 17:00:40 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 82481 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 21 Aug 2002 17:00:40 -0400
Received: from 65.205.166.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 21 Aug 2002 16:50:40 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Thread-Topic: ospf te doc
Thread-Index: AcJJU0NHtYsQpWNWRTqmXwK0MRIQvgAAHKyQ
Message-ID:  <9BBB98592D94084DB7118F889CFD3EC50A88D7@atlntex01.movaz.com>
Date:         Wed, 21 Aug 2002 16:50:37 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Dovolsky, Dan" 
Subject: Re: ospf te doc
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA25780

I think, the Reserved field should not be checked at all on receive. All 32 bits of LSA ID should be treated as LSA ID. This allows more flexibility for backward compatibility for future reuse of Reserve field.

Dan Dovolsky
Movaz Networks.

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@JUNIPER.NET]
Sent: Wednesday, August 21, 2002 4:42 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: ospf te doc


Hi All,

Here's what the updated section 2.2 of the ospf te doc
(draft-katz-yeung-ospf-traffic-07.txt) looks like:

2.2. LSA ID

   The LSA ID of an Opaque LSA is defined as having eight bits of type
   and 24 bits of type-specific data.  The Traffic Engineering LSA uses
   type 1.  The remaining 24 bits are broken up into eight bits of
   reserved space (which SHOULD be zero on transmission and ignored on
   receipt) and sixteen bits of instance:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       1       |    Reserved   |           Instance            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Instance field is an arbitrary value used to maintain multiple
   Traffic Engineering LSAs.  A maximum of 65536 Traffic Engineering
   LSAs may be sourced by a single system.  The LSA ID has no
   topological significance.

The issues are
a) what should the wording regarding the "Reserved" field be?
b) how should TE LSAs received with "illegal" values be treated?
   (for example in the wording as above, how should a TE LSA with
   a non-zero Reserved field be treated)?

One suggestion is to require the "Reserved" field to be zero, much
as John Moy requires the Opaque ID to be zero in a Grace LSA.  A
TE LSA received with a non-zero Reserved field is to be treated as
an unknown Opaque LSA (how are unknown Opaque LSAs treated?  Dropped?
Flooded?).

Thoughts?  Other suggestions?

Kireeti.


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 21 19:22:32 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29242
	for ; Wed, 21 Aug 2002 19:22:32 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006E454C@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 19:23:50 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 83017 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 21 Aug 2002 19:23:50 -0400
Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 21 Aug 2002 19:23:50 -0400
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by
          merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g7LNNnm05287 for
          ; Wed, 21 Aug 2002 16:23:49 -0700 (PDT)
          (envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost) by kummer.juniper.net
          (8.11.6/8.9.3) with ESMTP id g7LNNnC83680 for
          ; Wed, 21 Aug 2002 16:23:49 -0700 (PDT)
          (envelope-from kireeti@juniper.net)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <20020821162303.F83576-100000@kummer.juniper.net>
Date:         Wed, 21 Aug 2002 16:23:49 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Kireeti Kompella 
Subject: Re: ospf te doc
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <9BBB98592D94084DB7118F889CFD3EC50A88D7@atlntex01.movaz.com>
Precedence: list

Hi Dan,

On Wed, 21 Aug 2002, Dovolsky, Dan wrote:

> I think, the Reserved field should not be checked at all on receive. All 32 bits of LSA ID should be treated as LSA ID. This allows more flexibility for backward compatibility for future reuse of Reserve field.

Will making the Instance field 24 bits (i.e., the full Opaque ID) work
for you?

Kireeti.


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 21 19:40:27 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29608
	for ; Wed, 21 Aug 2002 19:40:27 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.006E477B@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 19:41:50 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 83071 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 21 Aug 2002 19:41:50 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 21 Aug 2002 19:41:49 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id 738F62848A5 for
          ; Wed, 21 Aug 2002 16:41:47 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <20020821162303.F83576-100000@kummer.juniper.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D642540.8010804@redback.com>
Date:         Wed, 21 Aug 2002 19:41:52 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: ospf te doc
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

  Kompella wrote:

> Hi Dan,
>
> On Wed, 21 Aug 2002, Dovolsky, Dan wrote:
>
>
>>I think, the Reserved field should not be checked at all on receive. All 32 bits of LSA ID should be treated as LSA ID. This allows more flexibility for backward compatibility for future reuse of Reserve field.
>>
>
> Will making the Instance field 24 bits (i.e., the full Opaque ID) work
> for you?


Kireeti,

I'd put in a vote for this. In fact, this is how my implementation
interprets the TE opaque LSA ID today.


>
> Kireeti.
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 21 22:15:37 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02536
	for ; Wed, 21 Aug 2002 22:15:37 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006E4AE3@cherry.ease.lsoft.com>; Wed, 21 Aug 2002 22:17:00 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 83531 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 21 Aug 2002 22:17:00 -0400
Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 21 Aug 2002 22:17:00 -0400
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp
          (Exim 3.36 #1) id 17hhWs-000HAL-00 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 21 Aug 2002 19:16:58 -0700
X-Mailer: The Bat! (v1.51) Personal
X-Priority: 3 (Normal)
References: <20020821162303.F83576-100000@kummer.juniper.net>
            <3D642540.8010804@redback.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <11290005461.20020821191527@psg.com>
Date:         Wed, 21 Aug 2002 19:15:27 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Alex Zinin 
Subject: Re: ospf te doc
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D642540.8010804@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Since this is about one of my AD-review comments, I thought
I would speak up...

I'd like to encourage people to share what their implementations
do with this field in the OSPF LSDB and in the TE DB. (Drop me
a message unicast if you don't feel comfortable speaking up on
the list.)

Thanks.

--
Alex

Wednesday, August 21, 2002, 4:41:52 PM, Acee Lindem wrote:
>   Kompella wrote:

>> Hi Dan,
>>
>> On Wed, 21 Aug 2002, Dovolsky, Dan wrote:
>>
>>
>>>I think, the Reserved field should not be checked at all on receive. All 32 bits of LSA ID should be treated as LSA ID. This allows more flexibility for backward compatibility for future reuse of
>>>Reserve field.
>>>
>>
>> Will making the Instance field 24 bits (i.e., the full Opaque ID) work
>> for you?


> Kireeti,

> I'd put in a vote for this. In fact, this is how my implementation
> interprets the TE opaque LSA ID today.


>>
>> Kireeti.
>>
>>


> --
> Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 22 06:04:35 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20293
	for ; Thu, 22 Aug 2002 06:04:35 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006E5766@cherry.ease.lsoft.com>; Thu, 22 Aug 2002 6:05:59 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 86040 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 22 Aug 2002 06:05:59 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 22 Aug 2002 06:05:58 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Thu, 22 Aug 2002 06:05:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Thu, 22 Aug 2002 06:07:59 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: ospf te doc
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Kireeti,

My views/answers on the questions you raised: -

a) I would prefer the suggestion to require the "Reserved" field to be 0 for
TE-LSA's and a value of non-zero should be treated as a non-TE LSA(unknown).
(as in the case of Grace-LSA)

If we left the meaning of the text as it is, it could create problems. Two
LSA's with different "Reserved" values but same "Instance" would be treated
as different LSA's by the OSPF process, however for the TE application
because the "Instance" would be the same it would be the same instance
although the contents could well be different.

Besides, the number of "Instance" values are probably sufficient even for
future requirements(every router can originate 65536 TE LSA's). By imposing
the above condition I specified we could use different values of "Reserved"
bits for future uses.

Another less preferable option could be to have all 24 bits as "Instance".

b) A non-zero value of reserved should be treated as a non-TE LSA.

c) Unknown opaque LSA's are flooded(not dropped) further depending on the
flooding scope of the LSA.

Thanks,
Vishwas

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@JUNIPER.NET]
Sent: Thursday, August 22, 2002 2:12 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: ospf te doc


Hi All,

Here's what the updated section 2.2 of the ospf te doc
(draft-katz-yeung-ospf-traffic-07.txt) looks like:

2.2. LSA ID

   The LSA ID of an Opaque LSA is defined as having eight bits of type
   and 24 bits of type-specific data.  The Traffic Engineering LSA uses
   type 1.  The remaining 24 bits are broken up into eight bits of
   reserved space (which SHOULD be zero on transmission and ignored on
   receipt) and sixteen bits of instance:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       1       |    Reserved   |           Instance            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Instance field is an arbitrary value used to maintain multiple
   Traffic Engineering LSAs.  A maximum of 65536 Traffic Engineering
   LSAs may be sourced by a single system.  The LSA ID has no
   topological significance.

The issues are
a) what should the wording regarding the "Reserved" field be?
b) how should TE LSAs received with "illegal" values be treated?
   (for example in the wording as above, how should a TE LSA with
   a non-zero Reserved field be treated)?

One suggestion is to require the "Reserved" field to be zero, much
as John Moy requires the Opaque ID to be zero in a Grace LSA.  A
TE LSA received with a non-zero Reserved field is to be treated as
an unknown Opaque LSA (how are unknown Opaque LSAs treated?  Dropped?
Flooded?).

Thoughts?  Other suggestions?

Kireeti.


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 22 09:13:28 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24478
	for ; Thu, 22 Aug 2002 09:13:28 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.006E58C6@cherry.ease.lsoft.com>; Thu, 22 Aug 2002 9:14:51 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 86720 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 22 Aug 2002 09:14:51 -0400
Received: from 157.181.151.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 22 Aug 2002 09:04:51 -0400
Received: from pandora.inf.elte.hu (pandora.inf.elte.hu [157.181.161.17]) by
          mx2.elte.hu (Postfix) with ESMTP id 09828483A7 for
          ; Thu, 22 Aug 2002 15:04:50 +0200 (CEST)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  
Date:         Thu, 22 Aug 2002 15:04:50 +0200
Reply-To: Mailing List 
Sender: Mailing List 
From: Nohl Attila Rajmund 
Subject: Status of "alternative ABR implementations" draft?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hello!

I would like to know the current status of the
draft-ietf-ospf-abr-alt-04.txt document. It is listed on the workgroup's
homepage at http://www.ietf.org/html.charters/ospf-charter.html but
according to its header, it expired last September.

From the draft it looks like that some vendors already implemented this
draft. I know, that in the GNU zebra routing software, one can configure
the router to use one of the techniques specified in the document. Do
you have any information about how widespread is the implementation of
this draft among the router vendors?

                                Bye,NAR


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 22 09:44:35 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25660
	for ; Thu, 22 Aug 2002 09:44:35 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.006E59B1@cherry.ease.lsoft.com>; Thu, 22 Aug 2002 9:45:59 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 86865 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 22 Aug 2002 09:45:58 -0400
Received: from 65.205.166.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 22 Aug 2002 09:45:58 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Thread-Topic: ospf te doc
Thread-Index: AcJJadBc2kx5K6AvT26AIlW0ePOhVAAdLiRQ
Message-ID:  <9BBB98592D94084DB7118F889CFD3EC50A88D8@atlntex01.movaz.com>
Date:         Thu, 22 Aug 2002 09:45:57 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Dovolsky, Dan" 
Subject: Re: ospf te doc
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA25660

Hi Kireeti,

Having Instance field 24 bits is 100% fine to me. (That's the way our OSPF is treat it).

BTW, 16 bits Instance field it's not so large as it seems.

Let's take as an example application, where multiple TE resources advertised per each TE Link. Suppose, some new TE Resource LSA is used for this purpose. Then, it's much more easy to application to manage sepate TE Resource LSA instance indexes per TE Link rather keep one global TE LSA instance indexing. At least, it allows fast database lookup operation.
In this case 16 bits allows to only have very limited instance number of such a resource TE LSAs per TE Link.

Dan.

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@JUNIPER.NET]
Sent: Wednesday, August 21, 2002 7:24 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: ospf te doc


Hi Dan,

On Wed, 21 Aug 2002, Dovolsky, Dan wrote:

> I think, the Reserved field should not be checked at all on receive. All 32 bits of LSA ID should be treated as LSA ID. This allows more flexibility for backward compatibility for future reuse of Reserve field.

Will making the Instance field 24 bits (i.e., the full Opaque ID) work
for you?

Kireeti.


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 22 10:06:01 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26300
	for ; Thu, 22 Aug 2002 10:06:01 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.006E5A1D@cherry.ease.lsoft.com>; Thu, 22 Aug 2002 10:07:25 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 86988 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 22 Aug 2002 10:07:25 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 22 Aug 2002 10:07:24 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id 8E46D473CCE for
          ; Thu, 22 Aug 2002 07:07:23 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
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:  <3D64F018.30704@redback.com>
Date:         Thu, 22 Aug 2002 10:07:20 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: Status of "alternative ABR implementations" draft?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Nohl Attila Rajmund wrote:

> Hello!


Hello NAR,


>
> I would like to know the current status of the
> draft-ietf-ospf-abr-alt-04.txt document. It is listed on the workgroup's
> homepage at http://www.ietf.org/html.charters/ospf-charter.html but
> according to its header, it expired last September.


I believe the draft is going to be published as an informational RFC. I'll
ping Alex to see where we stand with the last set of comments.

>
>>From the draft it looks like that some vendors already implemented this
> draft. I know, that in the GNU zebra routing software, one can configure
> the router to use one of the techniques specified in the document. Do
> you have any information about how widespread is the implementation of
> this draft among the router vendors?


Note that this is an informational RFC (vis-a-vis, a standards track RFC).
A properly designed OSPF network would not require the behavior described
in the draft. As a co-author, my primary motivation for implementing the
alternate ABR behavior was a satisfy a strong customer requirement.

In answer to your question, I'm not sure how many router vendors (other
than the ones listed in the draft) have implemented it.


>
>                                 Bye,NAR
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 22 10:19:05 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26773
	for ; Thu, 22 Aug 2002 10:19:04 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006E5B67@cherry.ease.lsoft.com>; Thu, 22 Aug 2002 10:20:28 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 87110 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 22 Aug 2002 10:20:26 -0400
Received: from 147.188.128.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 22 Aug 2002 10:20:26 -0400
Received: from bham.ac.uk ([147.188.128.127]) by mailer3.bham.ac.uk with esmtp
          (Exim 3.16 #2) id 17hsp0-00054R-00 for OSPF@discuss.microsoft.com;
          Thu, 22 Aug 2002 15:20:26 +0100
Received: from eee-fs7.bham.ac.uk ([147.188.145.131]
          helo=bham-eee-fs7.bham.ac.uk) by bham.ac.uk with esmtp (Exim 3.16 #3)
          id 17hsp0-0000nv-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 22 Aug 2002
          15:20:26 +0100
Received: by eee-fs7.bham.ac.uk with Internet Mail Service (5.5.2653.19) id
          ; Thu, 22 Aug 2002 15:20:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Thu, 22 Aug 2002 15:20:18 +0100
Reply-To: Mailing List 
Sender: Mailing List 
From: "Liu B." 
Subject: what is the fundamental difference between OSPF and IS-IS?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hello everyone,

Thanks for answering my previous questions. I am reading RFC 1142 (OSI IS-IS
Intra-domain Routing Protocol), in order to compare OSPF with IS-IS. There
are so many common things between two of them, such as area routing, virtual
link, designated router ... what is the fundamental difference (or
improvement?) between OSPF and IS-IS?

Thanks again for all your helps.

Bin Liu


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 22 11:43:29 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29745
	for ; Thu, 22 Aug 2002 11:43:28 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006E5C82@cherry.ease.lsoft.com>; Thu, 22 Aug 2002 11:44:51 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 87553 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 22 Aug 2002 11:44:51 -0400
Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 22 Aug 2002 11:44:51 -0400
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp
          (Exim 3.36 #1) id 17hu8g-000LU8-00; Thu, 22 Aug 2002 08:44:50 -0700
X-Mailer: The Bat! (v1.51) Personal
X-Priority: 3 (Normal)
References: 
            <3D64F018.30704@redback.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <154138479513.20020822084321@psg.com>
Date:         Thu, 22 Aug 2002 08:43:21 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Alex Zinin 
Subject: Re: Status of "alternative ABR implementations" draft?
Comments: To: Acee Lindem 
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D64F018.30704@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Acee,

>> I would like to know the current status of the
>> draft-ietf-ospf-abr-alt-04.txt document. It is listed on the workgroup's
>> homepage at http://www.ietf.org/html.charters/ospf-charter.html but
>> according to its header, it expired last September.

> I believe the draft is going to be published as an informational RFC. I'll
> ping Alex to see where we stand with the last set of comments.

I think I have all comments from the AD-review round incorporated
in my latest version. Let me double check it and I will resubmit
the final revision of the draft.

Alex


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 22 12:09:43 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00800
	for ; Thu, 22 Aug 2002 12:09:42 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006E5C2C@cherry.ease.lsoft.com>; Thu, 22 Aug 2002 12:11:05 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 87692 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 22 Aug 2002 12:11:04 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 22 Aug 2002 12:11:04 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Thu, 22 Aug 2002 12:11:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Thu, 22 Aug 2002 12:13:07 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: ospf te doc
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi folks,

If it is felt that the value of TE LSA's per area/per router can exceed
65,536,  in that case using 24-bit value would be a clean approach.(However
I am not so sure about the above assumption and stability of the routing
domain incase we had a few tens of such routers!!!)

Also mind you fragmenting information into smaller LSA's though helps in
case of change by only flooding relevent information, fragmenting into too
many LSA's may not help in case of flooding/adjacency formation/refreshing
etc.

Thanks,
Vishwas

-----Original Message-----
From: Dovolsky, Dan [mailto:ddovolsky@MOVAZ.COM]
Sent: Thursday, August 22, 2002 7:16 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: ospf te doc


Hi Kireeti,

Having Instance field 24 bits is 100% fine to me. (That's the way our OSPF
is treat it).

BTW, 16 bits Instance field it's not so large as it seems.

Let's take as an example application, where multiple TE resources advertised
per each TE Link. Suppose, some new TE Resource LSA is used for this
purpose. Then, it's much more easy to application to manage sepate TE
Resource LSA instance indexes per TE Link rather keep one global TE LSA
instance indexing. At least, it allows fast database lookup operation.
In this case 16 bits allows to only have very limited instance number of
such a resource TE LSAs per TE Link.

Dan.

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@JUNIPER.NET]
Sent: Wednesday, August 21, 2002 7:24 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: ospf te doc


Hi Dan,

On Wed, 21 Aug 2002, Dovolsky, Dan wrote:

> I think, the Reserved field should not be checked at all on receive. All
32 bits of LSA ID should be treated as LSA ID. This allows more flexibility
for backward compatibility for future reuse of Reserve field.

Will making the Instance field 24 bits (i.e., the full Opaque ID) work
for you?

Kireeti.


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 22 12:20:24 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01381
	for ; Thu, 22 Aug 2002 12:20:24 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006E5DF0@cherry.ease.lsoft.com>; Thu, 22 Aug 2002 12:21:49 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 87757 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 22 Aug 2002 12:21:48 -0400
Received: from 65.205.166.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 22 Aug 2002 12:21:48 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Thread-Topic: ospf te doc
Thread-Index: AcJJ9oa3LNq3jFT1RDGKnunhwJy0AAAAM0Gw
Message-ID:  <9BBB98592D94084DB7118F889CFD3EC57FC55C@atlntex01.movaz.com>
Date:         Thu, 22 Aug 2002 12:21:48 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Dovolsky, Dan" 
Subject: Re: ospf te doc
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA01381

Hi,

Having 24-bit value doesn't directly mean having more than 65,536 TE LSAs.
It just allows more efficient way of instance indexing.

"flooding/adjacency formation/refreshing" issues might be resolved very easy. (but it out of discussion scope).

Dan.

-----Original Message-----
From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM]
Sent: Thursday, August 22, 2002 12:13 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: ospf te doc


Hi folks,

If it is felt that the value of TE LSA's per area/per router can exceed
65,536,  in that case using 24-bit value would be a clean approach.(However
I am not so sure about the above assumption and stability of the routing
domain incase we had a few tens of such routers!!!)

Also mind you fragmenting information into smaller LSA's though helps in
case of change by only flooding relevent information, fragmenting into too
many LSA's may not help in case of flooding/adjacency formation/refreshing
etc.

Thanks,
Vishwas

-----Original Message-----
From: Dovolsky, Dan [mailto:ddovolsky@MOVAZ.COM]
Sent: Thursday, August 22, 2002 7:16 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: ospf te doc


Hi Kireeti,

Having Instance field 24 bits is 100% fine to me. (That's the way our OSPF
is treat it).

BTW, 16 bits Instance field it's not so large as it seems.

Let's take as an example application, where multiple TE resources advertised
per each TE Link. Suppose, some new TE Resource LSA is used for this
purpose. Then, it's much more easy to application to manage sepate TE
Resource LSA instance indexes per TE Link rather keep one global TE LSA
instance indexing. At least, it allows fast database lookup operation.
In this case 16 bits allows to only have very limited instance number of
such a resource TE LSAs per TE Link.

Dan.

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@JUNIPER.NET]
Sent: Wednesday, August 21, 2002 7:24 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: ospf te doc


Hi Dan,

On Wed, 21 Aug 2002, Dovolsky, Dan wrote:

> I think, the Reserved field should not be checked at all on receive. All
32 bits of LSA ID should be treated as LSA ID. This allows more flexibility
for backward compatibility for future reuse of Reserve field.

Will making the Instance field 24 bits (i.e., the full Opaque ID) work
for you?

Kireeti.


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 22 19:32:21 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13826
	for ; Thu, 22 Aug 2002 19:32:21 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.006E699B@cherry.ease.lsoft.com>; Thu, 22 Aug 2002 19:33:16 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 89866 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 22 Aug 2002 19:33:16 -0400
Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 22 Aug 2002 19:33:16 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <23.006E6980@cherry.ease.lsoft.com>;
          Thu, 22 Aug 2002 19:33:16 -0400
Message-ID:  
Date:         Thu, 22 Aug 2002 19:33:16 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Chaoping Wu 
Subject: Re: Congestion Avoidance & Control for OSPF Networks
         
Comments: To: "Ash, Gerald R (Jerry), NNAD" 
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hello Jerry,

Sorry for not providing any further information about this subject
recently, as I've been busy with another IETF draft. Let's focus on the
state of congestion in this mail. I'll send a separate email to you soon on
other topics when I have more time.

If we take a deep look at the congestion state in the draft, we can find
that it is consisted of two parts actually:
1. Entering (or detection of) congestion state
2. severity of the congestion

The draft does state several possible ways to detect congestion, which is
related to part 1. But it is just a little short in standardizing the
detection methods. The draft also states low/high congestion states, which
is related to part 2. But the draft does not provide any specification on
what conditions make a low or high congestion. Interoperability would be a
concern here.

I'd like to propose the following suggestions to improve the above two
parts for better interoperability and I believe they are not difficult to
implement.
1. Congestion Detection
Assign standard values to congestion detection methods and signaling the
value in the choke LSA/LLS signaling mentioned in the draft.
For Example, the detection value could be
 1= method based percentage of consumed, internal work queues exceeding a
thresh-hold percentage
 2= Missing some percentage of hellos;
 3= Frequent retransmissions are required.
 15= other method

This is analogous to some other protocols that signals some algorithms
selected for current use and provides a cause code when certain events
occur.

2. Severity of Congestion
Measure severity of congestion with time, since all equipment has timers
implemented inside. Something similar to chronic or acute congestion.
Prolonged congestion requires serious measures to overcome.
For example,
Prolonged congestion = high state
Short congestion = low state
The time-based congestion severity measurement can be used along with the
internal congestion interval timer that is stated in the draft. With some
modification, they should complement each other pretty well.

So much for now, hope this would help.

Regards,
Chaoping

==================================================================


On Tue, 20 Aug 2002 09:42:00 -0400, Ash, Gerald R (Jerry), ALASO
 wrote:

>Dear Chaoping,
>
>Thank you very much again for your comments, see responses below.
>
>Regards,
>Jerry Ash
>
>> >> 1. Outbound Congestion Notification
>> >>    This I-D suggests this notification not required in some way
>> >>    (section 4.2.1). But I think this notification is important and may
>> >>    complement the whole mechanism in the following way:
>> >>    A. Identifying source of congestion.
>> >>       In OSPF network types NBMA, P-TO-P, P-T--MP, Virtual links, OSPF
>> >>         packets may go through some kind of transit networks which may
>> >>         be congested for some reason. In this scenario, the receiving
>> >>         OSPF router can tell if the originating router experiences
>> >>         congestion or not.
>> >>
>> >>   B. Faster notification is possible if outbound congestion
notification
>> >>      is performed. It should be sent immediately once detected.
>
>> >Though what you say is true, if I have understood you correctly, we have
>> >tried to avoid signaling both for our own congestion as well as
congestion
>> >at the other end(which is also harder to predict). We have gone with the
>> >assumption that if the congestion occurs at the other end, then the
>> >congested router will notify about it. This fact has been put forward in
>> >Section 4.2.1, maybe we can clarify that further.
>
>> This particular comment was about outband congestion at a local router
>> only, rather than any congestion at a remote side as you implied in the
>> reply (I agree with you that remote end congestion is harder to predict,
>> but this is not the point I was trying to make above).
>>
>> The question is what should the local OSPF router do if it detects
>> outband congestion?
>>
>> In section 4.2.1, the ID says
>> "Detecting outbound congestion in some way
>> does not require notification, since we should assume the adjacent
>> router will detect this congestion on its own."
>>
>> While this is true, but it loses the some benefits, such as the points
>> in 1.A & 1.B as I mentioned above. So, instead, I think we should
>> promote the usage of explicit outband congestion notification in
>> this ID.
>
>I agree that we should only be dealing with detecting 'outbound'
congestion at a router, and not trying to detect congestion at some
neighbor router.  I think the quote above from Section 4.2.1 is misleading,
and needs to be clarified in the next revision to say something like:
>"Detecting outbound congestion requires immediate notification to all
neighboring routers".
>
>> Also another related note is the triggering time of Hello messages
>> that contain LLS congestion signaling. It was not clear from the ID if
>> this signaling should be sent immediately once congestion is detected,
>> or wait until the traditional Hello timer expire. Although this may be
>> somewhat implementation dependent, but I think we should probably
>> promote the better way: immediate notification.
>
>Agreed, and it should be made explicit in the next revision.
>
>> >> 2. State of Congestion
>> >>   This I-D specifies 3 states MUST be defined (section 4.2.1) but it
>> >>   has not specified a consistent way of defining the states.
>> >>
>> >>   In networks mixed with different vendor routers, if a "high
congestion
>> >>   state" in one router is equivalent to "low congestion state" of its
>> >>   neighboring router that is made by a different vendor using
different
>> >>   definitions of congestion state, the resulted congestion measures in
>> >>   this network may not be as desired, isn't it?
>
>> >Though what you say would be desired, however, there can be no perfect
way
>> >to exactly classify it, on different routers/vendors/etc. We have
however
>> >given some suggestions in the beginning of the section, we can try to
make
>> >the classifications more precise.
>
>> Agreed on "no perfect way to exactly classify it". But if we have a
>> desire to explore ideas to make it better, we may find other ways.
>> More on this point in the near future.
>
>I think you raised a good point, that is, to be more precise in defining
congestion state.  I think it would be important for interoperability, and
that we should go further in defining congestion states in the next
revision.  Your further suggestions would be appreciated.
>
>> >> 3. Adding A Congestion Prediction Concept
>> >>   What about incorporating a congestion prediction concept into this
>> >>   I-D? Preventive congestion measures should be very used for network
>> >>   administrators to get alerted about when they should start consider
>> >>   optimize their networks. Potential congestion may be simply another
>> >>   congestion state.
>
>> >As the actual signaling of congestion and measure of levels of
congestion
>> >has been left to the implementation, an implementation could always
signal
>> >low congestion, when it can predict it is going into congestion. The
exact
>> >prediction methods are left to the local router itself, and as Jerry
pointed
>> >out it may be hard to predict it.
>
>> This ID does provide a good mechanism on congestion prevention.
>> But if you go one step further to introduce the concept of congestion
>> prevention in the ID, I believe it would open another
>> door of useful capabilities.
>>
>> Congestion prediction has been implemented in networking equipment.
>> It may be easier than you think. If there's enough interest, I'll
>> make some suggestions later.
>
>Is there any reference to where 'congestion prediction has been
implemented in networking equipment'?  Again, your further suggestions are
appreciated.


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 22 20:08:32 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14286
	for ; Thu, 22 Aug 2002 20:08:32 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.006E69D8@cherry.ease.lsoft.com>; Thu, 22 Aug 2002 20:09:56 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 89969 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 22 Aug 2002 20:09:56 -0400
Received: from 144.189.100.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 22 Aug 2002 20:09:55 -0400
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by
          motgate4.mot.com (motgate4 2.1) with ESMTP id RAA17628 for
          ; Thu, 22 Aug 2002 17:09:54 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38])
          by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id RAA28907 for
          ; Thu, 22 Aug 2002 17:09:52 -0700 (MST)]
Received: from arc.corp.mot.com (arthurd.arc.corp.mot.com [10.238.80.59]) by
          homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g7N09o7C026347
          for ; Fri, 23 Aug 2002 10:09:50 +1000
          (EST)
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D657D4D.852EE417@arc.corp.mot.com>
Date:         Fri, 23 Aug 2002 10:09:49 +1000
Reply-To: Mailing List 
Sender: Mailing List 
From: Arthur Dimitrelis 
Subject: Re: what is the fundamental difference between OSPF and IS-IS?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi,

there is a paper by Radia Perlman that answers your question, entitled "A
Comparison Between Two Routing Protocols: OSPF and IS-IS". It appeared in the
September 1991 issue of the IEEE Network Magazine. Contact me off list if you
need help finding it (it's freely available in electronic form).

cheers,
Arthur

"Liu B." wrote:

> Hello everyone,
>
> Thanks for answering my previous questions. I am reading RFC 1142 (OSI IS-IS
> Intra-domain Routing Protocol), in order to compare OSPF with IS-IS. There
> are so many common things between two of them, such as area routing, virtual
> link, designated router ... what is the fundamental difference (or
> improvement?) between OSPF and IS-IS?
>
> Thanks again for all your helps.
>
> Bin Liu


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 22 20:47:50 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14847
	for ; Thu, 22 Aug 2002 20:47:50 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006E6B3E@cherry.ease.lsoft.com>; Thu, 22 Aug 2002 20:49:13 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 90058 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 22 Aug 2002 20:49:14 -0400
Received: from 144.189.100.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 22 Aug 2002 20:49:13 -0400
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by
          motgate4.mot.com (motgate4 2.1) with ESMTP id RAA01878 for
          ; Thu, 22 Aug 2002 17:49:09 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38])
          by mothost.mot.com (MOT-pobox 2.0) with ESMTP id RAA12281 for
          ; Thu, 22 Aug 2002 17:49:32 -0700 (MST)]
Received: from arc.corp.mot.com (arthurd.arc.corp.mot.com [10.238.80.59]) by
          homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g7N0n37C000041
          for ; Fri, 23 Aug 2002 10:49:03 +1000
          (EST)
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <3D657D4D.852EE417@arc.corp.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D65867E.F0B387F@arc.corp.mot.com>
Date:         Fri, 23 Aug 2002 10:49:02 +1000
Reply-To: Mailing List 
Sender: Mailing List 
From: Arthur Dimitrelis 
Subject: Re: what is the fundamental difference between OSPF and IS-IS?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Sorry, I take that last point back. The said paper is available in electronic
form, but I have no idea if it's free (in a monetary sense) or not.

arthur

Arthur Dimitrelis wrote:

> Hi,
>
> there is a paper by Radia Perlman that answers your question, entitled "A
> Comparison Between Two Routing Protocols: OSPF and IS-IS". It appeared in the
> September 1991 issue of the IEEE Network Magazine. Contact me off list if you
> need help finding it (it's freely available in electronic form).
>
> cheers,
> Arthur
>
> "Liu B." wrote:
>
> > Hello everyone,
> >
> > Thanks for answering my previous questions. I am reading RFC 1142 (OSI IS-IS
> > Intra-domain Routing Protocol), in order to compare OSPF with IS-IS. There
> > are so many common things between two of them, such as area routing, virtual
> > link, designated router ... what is the fundamental difference (or
> > improvement?) between OSPF and IS-IS?
> >
> > Thanks again for all your helps.
> >
> > Bin Liu


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 22 22:23:34 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16391
	for ; Thu, 22 Aug 2002 22:23:34 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006E6C11@cherry.ease.lsoft.com>; Thu, 22 Aug 2002 22:24:58 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 90323 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 22 Aug 2002 22:24:58 -0400
Received: from 63.251.100.14 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 22 Aug 2002 22:14:57 -0400
Received: from mailhost.foundrynet.com (mailhost [63.251.100.20]) by
          smtp.foundrynet.com (8.11.6/FoundryNetworks) with ESMTP id
          g7N2EuM24146 for ; Thu, 22 Aug 2002
          19:14:56 -0700
Received: from mailhost.foundrynet.com (localhost [127.0.0.1]) by
          mailhost.foundrynet.com (8.11.6/FoundryNetworks) with ESMTP id
          g7N2EuF21934 for ; Thu, 22 Aug 2002
          19:14:56 -0700
Received: from flin (ns100corpdmz.foundrynet.com [63.251.100.1]) by
          mailhost.foundrynet.com (8.11.6/FoundryNetworks) with SMTP id
          g7N2Euh21928 for ; Thu, 22 Aug 2002
          19:14:56 -0700
References:         
            <3D657D4D.852EE417@arc.corp.mot.com> 
            <3D65867E.F0B387F@arc.corp.mot.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID:  <007601c24a4b$b1d62800$4002a8c0@foundrynet.com>
Date:         Thu, 22 Aug 2002 19:20:48 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Felix Lin 
Subject: Re: what is the fundamental difference between OSPF and IS-IS?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Arthur,

I tried searching for this paper on Internet but was unsuccessful. Is it
available publicly? How do I find it?

Thx
Felix
----- Original Message -----
From: "Arthur Dimitrelis" 
To: 
Sent: Thursday, August 22, 2002 5:49 PM
Subject: Re: what is the fundamental difference between OSPF and IS-IS?


> Sorry, I take that last point back. The said paper is available in
electronic
> form, but I have no idea if it's free (in a monetary sense) or not.
>
> arthur
>
> Arthur Dimitrelis wrote:
>
> > Hi,
> >
> > there is a paper by Radia Perlman that answers your question, entitled
"A
> > Comparison Between Two Routing Protocols: OSPF and IS-IS". It appeared
in the
> > September 1991 issue of the IEEE Network Magazine. Contact me off list
if you
> > need help finding it (it's freely available in electronic form).
> >
> > cheers,
> > Arthur
> >
> > "Liu B." wrote:
> >
> > > Hello everyone,
> > >
> > > Thanks for answering my previous questions. I am reading RFC 1142 (OSI
IS-IS
> > > Intra-domain Routing Protocol), in order to compare OSPF with IS-IS.
There
> > > are so many common things between two of them, such as area routing,
virtual
> > > link, designated router ... what is the fundamental difference (or
> > > improvement?) between OSPF and IS-IS?
> > >
> > > Thanks again for all your helps.
> > >
> > > Bin Liu
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Aug 23 00:20:07 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18206
	for ; Fri, 23 Aug 2002 00:20:06 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006E71AA@cherry.ease.lsoft.com>; Fri, 23 Aug 2002 0:21:31 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 90689 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 23 Aug 2002 00:21:31 -0400
Received: from 171.69.24.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 23 Aug 2002 00:21:31 -0400
Received: from friedman-u5.cisco.com (friedman-u5.cisco.com [128.107.162.252])
          by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id
          g7N4LUmk008252 for ; Thu, 22 Aug 2002
          21:21:30 -0700 (PDT)
Received: (friedman@localhost) by friedman-u5.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id VAA18281 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 22 Aug 2002 21:21:30 -0700 (PDT)
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Message-ID:  <20020823042129.GA18267@friedman-u5.cisco.com>
Date:         Thu, 22 Aug 2002 21:21:30 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Barry Friedman 
Subject: Re: what is the fundamental difference between OSPF and IS-IS?
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list

There's not much fundamental difference, but plenty of divergence
in the details:

http://www.nanog.org/mtg-0006/katz.html

Regards,
Barry

Liu B. [binl@EEE-FS7.BHAM.AC.UK] wrote:
> Hello everyone,
>
> Thanks for answering my previous questions. I am reading RFC 1142 (OSI IS-IS
> Intra-domain Routing Protocol), in order to compare OSPF with IS-IS. There
> are so many common things between two of them, such as area routing, virtual
> link, designated router ... what is the fundamental difference (or
> improvement?) between OSPF and IS-IS?
>
> Thanks again for all your helps.
>
> Bin Liu

--
Barry Friedman
Cisco Systems Inc.  mailto:friedman@cisco.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Aug 23 02:07:46 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24685
	for ; Fri, 23 Aug 2002 02:07:46 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006E7639@cherry.ease.lsoft.com>; Fri, 23 Aug 2002 2:09:09 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 91127 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 23 Aug 2002 02:09:08 -0400
Received: from 136.182.1.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 23 Aug 2002 02:09:08 -0400
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by
          motgate2.mot.com (motgate2 2.1) with ESMTP id XAA20247 for
          ; Thu, 22 Aug 2002 23:09:15 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38])
          by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id XAA04169 for
          ; Thu, 22 Aug 2002 23:09:05 -0700 (MST)]
Received: from arc.corp.mot.com (arthurd.arc.corp.mot.com [10.238.80.59]) by
          homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g7N68w7C029110
          for ; Fri, 23 Aug 2002 16:08:58 +1000
          (EST)
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <3D657D4D.852EE417@arc.corp.mot.com>
            <3D65867E.F0B387F@arc.corp.mot.com>
            <007601c24a4b$b1d62800$4002a8c0@foundrynet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D65D17A.E0CDD630@arc.corp.mot.com>
Date:         Fri, 23 Aug 2002 16:08:58 +1000
Reply-To: Mailing List 
Sender: Mailing List 
From: Arthur Dimitrelis 
Subject: Re: what is the fundamental difference between OSPF and IS-IS?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Felix,

it is publicly available, but as far as I can tell, you will need an IEEE
subscription in order to download it, from IEEE Xplore at least.

Those who have the necessary IEEE subscription can go to:
http://ieeexplore.ieee.org

Failing this, I'd expect to find a hard copy at a university library.

cheers,
Arthur

Felix Lin wrote:

> Arthur,
>
> I tried searching for this paper on Internet but was unsuccessful. Is it
> available publicly? How do I find it?
>
> Thx
> Felix
> ----- Original Message -----
> From: "Arthur Dimitrelis" 
> To: 
> Sent: Thursday, August 22, 2002 5:49 PM
> Subject: Re: what is the fundamental difference between OSPF and IS-IS?
>
> > Sorry, I take that last point back. The said paper is available in
> electronic
> > form, but I have no idea if it's free (in a monetary sense) or not.
> >
> > arthur
> >
> > Arthur Dimitrelis wrote:
> >
> > > Hi,
> > >
> > > there is a paper by Radia Perlman that answers your question, entitled
> "A
> > > Comparison Between Two Routing Protocols: OSPF and IS-IS". It appeared
> in the
> > > September 1991 issue of the IEEE Network Magazine. Contact me off list
> if you
> > > need help finding it (it's freely available in electronic form).
> > >
> > > cheers,
> > > Arthur
> > >
> > > "Liu B." wrote:
> > >
> > > > Hello everyone,
> > > >
> > > > Thanks for answering my previous questions. I am reading RFC 1142 (OSI
> IS-IS
> > > > Intra-domain Routing Protocol), in order to compare OSPF with IS-IS.
> There
> > > > are so many common things between two of them, such as area routing,
> virtual
> > > > link, designated router ... what is the fundamental difference (or
> > > > improvement?) between OSPF and IS-IS?
> > > >
> > > > Thanks again for all your helps.
> > > >
> > > > Bin Liu
> >


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Aug 23 12:35:54 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11355
	for ; Fri, 23 Aug 2002 12:35:54 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.006E810A@cherry.ease.lsoft.com>; Fri, 23 Aug 2002 12:37:13 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 77974 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 23 Aug 2002 12:37:12 -0400
Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Fri, 23 Aug 2002 12:37:12 -0400
Received: from user-38lc07s.dialup.mindspring.com ([209.86.0.252]
          helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim
          3.33 #1) id 17iHQt-0004xs-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 23
          Aug 2002 09:37:11 -0700
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:  <3D666788.A236BA2D@earthlink.net>
Date:         Fri, 23 Aug 2002 09:49:12 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: Re: what is the fundamental difference between OSPF and IS-IS?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Bin Liu,

        I will assume that

        The two biggest differences in my opinion are:

        1)  IS-IS is a pure SPF computation based LS protocol.

           IS-IS : Routes computed between L2 to L2 routes in
           IS-IS are link-state / SPF computations. L1 routers
           have no direct outside area connection. L2 routers
           have that direct connection. Yes, a router can be
           a L1/L2 router.

            OSPF : Like routes (non-local) within OSPF are distance
            vector computation.

        2)  Neighbor to adjacency formation process.

           OSPF : Uses a heavy weight process to initially synchronize
           its link state databases for adjacencies. Then it uses
           flooding to keep them synchronized.

           IS-IS : Uses complete and partial link-state protocol data
           units which describe every LSP in the database and are
           periodicly multicasted.


        Mitchell Erblich
        Ex-Extreme Networks IS-IS Software Developer.
        =============================================


"Liu B." wrote:
>
> Hello everyone,
>
> Thanks for answering my previous questions. I am reading RFC 1142 (OSI IS-IS
> Intra-domain Routing Protocol), in order to compare OSPF with IS-IS. There
> are so many common things between two of them, such as area routing, virtual
> link, designated router ... what is the fundamental difference (or
> improvement?) between OSPF and IS-IS?
>
> Thanks again for all your helps.
>
> Bin Liu


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Aug 23 14:44:26 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14210
	for ; Fri, 23 Aug 2002 14:44:25 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.006E857C@cherry.ease.lsoft.com>; Fri, 23 Aug 2002 14:45:49 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 78738 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 23 Aug 2002 14:45:48 -0400
Received: from 207.217.120.232 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Fri, 23 Aug 2002 14:45:48 -0400
Received: from user-38lc04q.dialup.mindspring.com ([209.86.0.154]
          helo=earthlink.net) by flamingo.mail.pas.earthlink.net with esmtp
          (Exim 3.33 #1) id 17iJRJ-0003Bj-00 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 23 Aug 2002 11:45:46 -0700
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:  <3D6685AA.31AC74A@earthlink.net>
Date:         Fri, 23 Aug 2002 11:57:46 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: Re: Congestion Avoidance & Control for OSPF
         Networks
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

        Could I suggest in addition to:
        "2= Missing some percentage of hellos;"

        Missing x number of consecutive hellos...

        Mitchell Erblich
        =====================

Chaoping Wu wrote:
>
> Hello Jerry,
>
> Sorry for not providing any further information about this subject
> recently, as I've been busy with another IETF draft. Let's focus on the
> state of congestion in this mail. I'll send a separate email to you soon on
> other topics when I have more time.
>
> If we take a deep look at the congestion state in the draft, we can find
> that it is consisted of two parts actually:
> 1. Entering (or detection of) congestion state
> 2. severity of the congestion
>
> The draft does state several possible ways to detect congestion, which is
> related to part 1. But it is just a little short in standardizing the
> detection methods. The draft also states low/high congestion states, which
> is related to part 2. But the draft does not provide any specification on
> what conditions make a low or high congestion. Interoperability would be a
> concern here.
>
> I'd like to propose the following suggestions to improve the above two
> parts for better interoperability and I believe they are not difficult to
> implement.
> 1. Congestion Detection
> Assign standard values to congestion detection methods and signaling the
> value in the choke LSA/LLS signaling mentioned in the draft.
> For Example, the detection value could be
>  1= method based percentage of consumed, internal work queues exceeding a
> thresh-hold percentage
>  2= Missing some percentage of hellos;
>  3= Frequent retransmissions are required.
>  15= other method
>
> This is analogous to some other protocols that signals some algorithms
> selected for current use and provides a cause code when certain events
> occur.
>
> 2. Severity of Congestion
> Measure severity of congestion with time, since all equipment has timers
> implemented inside. Something similar to chronic or acute congestion.
> Prolonged congestion requires serious measures to overcome.
> For example,
> Prolonged congestion = high state
> Short congestion = low state
> The time-based congestion severity measurement can be used along with the
> internal congestion interval timer that is stated in the draft. With some
> modification, they should complement each other pretty well.
>
> So much for now, hope this would help.
>
> Regards,
> Chaoping
>
> ==================================================================
>
> On Tue, 20 Aug 2002 09:42:00 -0400, Ash, Gerald R (Jerry), ALASO
>  wrote:
>
> >Dear Chaoping,
> >
> >Thank you very much again for your comments, see responses below.
> >
> >Regards,
> >Jerry Ash
> >
> >> >> 1. Outbound Congestion Notification
> >> >>    This I-D suggests this notification not required in some way
> >> >>    (section 4.2.1). But I think this notification is important and may
> >> >>    complement the whole mechanism in the following way:
> >> >>    A. Identifying source of congestion.
> >> >>       In OSPF network types NBMA, P-TO-P, P-T--MP, Virtual links, OSPF
> >> >>         packets may go through some kind of transit networks which may
> >> >>         be congested for some reason. In this scenario, the receiving
> >> >>         OSPF router can tell if the originating router experiences
> >> >>         congestion or not.
> >> >>
> >> >>   B. Faster notification is possible if outbound congestion
> notification
> >> >>      is performed. It should be sent immediately once detected.
> >
> >> >Though what you say is true, if I have understood you correctly, we have
> >> >tried to avoid signaling both for our own congestion as well as
> congestion
> >> >at the other end(which is also harder to predict). We have gone with the
> >> >assumption that if the congestion occurs at the other end, then the
> >> >congested router will notify about it. This fact has been put forward in
> >> >Section 4.2.1, maybe we can clarify that further.
> >
> >> This particular comment was about outband congestion at a local router
> >> only, rather than any congestion at a remote side as you implied in the
> >> reply (I agree with you that remote end congestion is harder to predict,
> >> but this is not the point I was trying to make above).
> >>
> >> The question is what should the local OSPF router do if it detects
> >> outband congestion?
> >>
> >> In section 4.2.1, the ID says
> >> "Detecting outbound congestion in some way
> >> does not require notification, since we should assume the adjacent
> >> router will detect this congestion on its own."
> >>
> >> While this is true, but it loses the some benefits, such as the points
> >> in 1.A & 1.B as I mentioned above. So, instead, I think we should
> >> promote the usage of explicit outband congestion notification in
> >> this ID.
> >
> >I agree that we should only be dealing with detecting 'outbound'
> congestion at a router, and not trying to detect congestion at some
> neighbor router.  I think the quote above from Section 4.2.1 is misleading,
> and needs to be clarified in the next revision to say something like:
> >"Detecting outbound congestion requires immediate notification to all
> neighboring routers".
> >
> >> Also another related note is the triggering time of Hello messages
> >> that contain LLS congestion signaling. It was not clear from the ID if
> >> this signaling should be sent immediately once congestion is detected,
> >> or wait until the traditional Hello timer expire. Although this may be
> >> somewhat implementation dependent, but I think we should probably
> >> promote the better way: immediate notification.
> >
> >Agreed, and it should be made explicit in the next revision.
> >
> >> >> 2. State of Congestion
> >> >>   This I-D specifies 3 states MUST be defined (section 4.2.1) but it
> >> >>   has not specified a consistent way of defining the states.
> >> >>
> >> >>   In networks mixed with different vendor routers, if a "high
> congestion
> >> >>   state" in one router is equivalent to "low congestion state" of its
> >> >>   neighboring router that is made by a different vendor using
> different
> >> >>   definitions of congestion state, the resulted congestion measures in
> >> >>   this network may not be as desired, isn't it?
> >
> >> >Though what you say would be desired, however, there can be no perfect
> way
> >> >to exactly classify it, on different routers/vendors/etc. We have
> however
> >> >given some suggestions in the beginning of the section, we can try to
> make
> >> >the classifications more precise.
> >
> >> Agreed on "no perfect way to exactly classify it". But if we have a
> >> desire to explore ideas to make it better, we may find other ways.
> >> More on this point in the near future.
> >
> >I think you raised a good point, that is, to be more precise in defining
> congestion state.  I think it would be important for interoperability, and
> that we should go further in defining congestion states in the next
> revision.  Your further suggestions would be appreciated.
> >
> >> >> 3. Adding A Congestion Prediction Concept
> >> >>   What about incorporating a congestion prediction concept into this
> >> >>   I-D? Preventive congestion measures should be very used for network
> >> >>   administrators to get alerted about when they should start consider
> >> >>   optimize their networks. Potential congestion may be simply another
> >> >>   congestion state.
> >
> >> >As the actual signaling of congestion and measure of levels of
> congestion
> >> >has been left to the implementation, an implementation could always
> signal
> >> >low congestion, when it can predict it is going into congestion. The
> exact
> >> >prediction methods are left to the local router itself, and as Jerry
> pointed
> >> >out it may be hard to predict it.
> >
> >> This ID does provide a good mechanism on congestion prevention.
> >> But if you go one step further to introduce the concept of congestion
> >> prevention in the ID, I believe it would open another
> >> door of useful capabilities.
> >>
> >> Congestion prediction has been implemented in networking equipment.
> >> It may be easier than you think. If there's enough interest, I'll
> >> make some suggestions later.
> >
> >Is there any reference to where 'congestion prediction has been
> implemented in networking equipment'?  Again, your further suggestions are
> appreciated.


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Aug 23 15:38:59 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15540
	for ; Fri, 23 Aug 2002 15:38:58 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.006E8474@cherry.ease.lsoft.com>; Fri, 23 Aug 2002 15:40:22 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 78946 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 23 Aug 2002 15:40:22 -0400
Received: from 192.128.166.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Fri, 23 Aug 2002 15:40:22 -0400
Received: from attrh0i.attrh.att.com ([135.37.94.54]) by almso2.proxy.att.com
          (AT&T IPNS/MSO-4.0) with ESMTP id g7NGwPJG028160 for
          ; Fri, 23 Aug 2002 15:40:20 -0400 (EDT)
Received: from occlust04evs1.ugd.att.com (135.71.164.13) by
          attrh0i.attrh.att.com (6.5.019) id 3CE53F4A02B59DC9; Fri, 23 Aug 2002
          15:40:19 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Thread-Topic:      Re: Congestion Avoidance & Control for OSPF Networks        
                   
Thread-Index: AcJKNE1ued4CR5D8QzynyHTj3YdiLQApwK6Q
Message-ID:  <28F05913385EAC43AF019413F674A0170167B135@OCCLUST04EVS1.ugd.att.com>
Date:         Fri, 23 Aug 2002 15:40:18 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Ash, Gerald R (Jerry), ALASO" 
Subject: Re: Congestion Avoidance & Control for OSPF Networks
         
Comments: To: Chaoping Wu 
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA15540

Hi Chaoping,
 
> If we take a deep look at the congestion state in the draft, we can find
> that it is consisted of two parts actually:
> 1. Entering (or detection of) congestion state
> 2. severity of the congestion
> 
> The draft does state several possible ways to detect congestion, which is
> related to part 1. But it is just a little short in standardizing the
> detection methods. The draft also states low/high congestion states, which
> is related to part 2. But the draft does not provide any specification on
> what conditions make a low or high congestion. Interoperability would be a
> concern here.

Agreed.

> I'd like to propose the following suggestions to improve the above two
> parts for better interoperability and I believe they are not difficult to
> implement.
> 1. Congestion Detection
> Assign standard values to congestion detection methods and signaling the
> value in the choke LSA/LLS signaling mentioned in the draft.
> For Example, the detection value could be
>  1= method based percentage of consumed, internal work queues exceeding a
> thresh-hold percentage
>  2= Missing some percentage of hellos;
>  3= Frequent retransmissions are required.
>  15= other method
> 
> This is analogous to some other protocols that signals some algorithms
> selected for current use and provides a cause code when certain events
> occur.
> 
> 2. Severity of Congestion
> Measure severity of congestion with time, since all equipment has timers
> implemented inside. Something similar to chronic or acute congestion.
> Prolonged congestion requires serious measures to overcome.
> For example,
> Prolonged congestion = high state
> Short congestion = low state
> The time-based congestion severity measurement can be used along with the
> internal congestion interval timer that is stated in the draft. With some
> modification, they should complement each other pretty well.

Your ideas are very good here.  Both the degree and duration of congestion should be considered in defining congestion state.  We'll plan to incorporate along these lines in the next rev. of the draft.

Thanks,
Regards,
Jerry


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Aug 23 18:00:05 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18686
	for ; Fri, 23 Aug 2002 18:00:04 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.006E89B1@cherry.ease.lsoft.com>; Fri, 23 Aug 2002 18:01:29 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 79474 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 23 Aug 2002 18:01:29 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 23 Aug 2002 18:01:29 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Fri, 23 Aug 2002 18:01:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Fri, 23 Aug 2002 01:05:53 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: ospf te doc
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi,

But isn't it proprietary the way you want to "index"?

"flooding/adjacency formation/refreshing" issues effect the stability of the
domain when the number of LSA's is so large and that is why I raised the
issue.

In a different context, if you feel these are very easy issues to be
resolved, please contact me in private(I have been working on flooding
optimizations/congestion control for quite sometime and haven't got to
something very acceptable even now for the flooding)

Thanks,
Vishwas

-----Original Message-----
From: Dovolsky, Dan [mailto:ddovolsky@MOVAZ.COM]
Sent: Thursday, August 22, 2002 9:52 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: ospf te doc


Hi,

Having 24-bit value doesn't directly mean having more than 65,536 TE LSAs.
It just allows more efficient way of instance indexing.

"flooding/adjacency formation/refreshing" issues might be resolved very
easy. (but it out of discussion scope).

Dan.

-----Original Message-----
From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM]
Sent: Thursday, August 22, 2002 12:13 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: ospf te doc


Hi folks,

If it is felt that the value of TE LSA's per area/per router can exceed
65,536,  in that case using 24-bit value would be a clean approach.(However
I am not so sure about the above assumption and stability of the routing
domain incase we had a few tens of such routers!!!)

Also mind you fragmenting information into smaller LSA's though helps in
case of change by only flooding relevent information, fragmenting into too
many LSA's may not help in case of flooding/adjacency formation/refreshing
etc.

Thanks,
Vishwas

-----Original Message-----
From: Dovolsky, Dan [mailto:ddovolsky@MOVAZ.COM]
Sent: Thursday, August 22, 2002 7:16 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: ospf te doc


Hi Kireeti,

Having Instance field 24 bits is 100% fine to me. (That's the way our OSPF
is treat it).

BTW, 16 bits Instance field it's not so large as it seems.

Let's take as an example application, where multiple TE resources advertised
per each TE Link. Suppose, some new TE Resource LSA is used for this
purpose. Then, it's much more easy to application to manage sepate TE
Resource LSA instance indexes per TE Link rather keep one global TE LSA
instance indexing. At least, it allows fast database lookup operation.
In this case 16 bits allows to only have very limited instance number of
such a resource TE LSAs per TE Link.

Dan.

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@JUNIPER.NET]
Sent: Wednesday, August 21, 2002 7:24 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: ospf te doc


Hi Dan,

On Wed, 21 Aug 2002, Dovolsky, Dan wrote:

> I think, the Reserved field should not be checked at all on receive. All
32 bits of LSA ID should be treated as LSA ID. This allows more flexibility
for backward compatibility for future reuse of Reserve field.

Will making the Instance field 24 bits (i.e., the full Opaque ID) work
for you?

Kireeti.


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Aug 26 05:55:35 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04948
	for ; Mon, 26 Aug 2002 05:55:35 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006EC93D@cherry.ease.lsoft.com>; Mon, 26 Aug 2002 5:56:53 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 91632 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 26 Aug 2002 05:56:53 -0400
Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 26 Aug 2002 05:56:53 -0400
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by
          motgate.mot.com (motgate 2.1) with ESMTP id CAA05633 for
          ; Mon, 26 Aug 2002 02:56:52 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38])
          by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id CAA09629 for
          ; Mon, 26 Aug 2002 02:56:50 -0700 (MST)]
Received: from arc.corp.mot.com (arthurd.arc.corp.mot.com [10.238.80.59]) by
          homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g7Q9uk7C012889
          for ; Mon, 26 Aug 2002 19:56:48 +1000
          (EST)
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D69FB5F.94EE1AEC@arc.corp.mot.com>
Date:         Mon, 26 Aug 2002 19:56:47 +1000
Reply-To: Mailing List 
Sender: Mailing List 
From: Arthur Dimitrelis 
Subject: OSPFv3 query (link LSAs & link local addresses)
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi everyone,

I've got a query regarding OSPF for IPv6. With reference to RFC2740,
section 2.5 discusses how IPv6 link local addresses are used as the
source addresses in PDU exchanges between OSPFv3 speakers (including
HELLO packets), and goes on to state that an OSPFv3 router will learn
the link-local addresses of all other routers attached to its links. No
problems with all that.

Now, appendix A.4.8 defines the packet format of a link LSA, which
includes the link local address of its originating router. The
commentary in this section explains that one of the purposes of a link
LSA is to allow all routers on the link to learn the link-local address
of the LSA's originator. Could this information not have been deduced
from the Advertising Router ID field in the LSA's header (along with the
information gleaned from previously seen HELLO packets, ie from those
neighbors a router considers to be in the '2-way' state) ?

Anybody know about or have any ideas on this apparent (to me)
redundancy?

cheers,
arthur


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 28 03:46:05 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19739
	for ; Wed, 28 Aug 2002 03:46:04 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006F14A0@cherry.ease.lsoft.com>; Wed, 28 Aug 2002 3:47:31 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 103417 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 28 Aug 2002 03:47:31 -0400
Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 28 Aug 2002 03:37:31 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <5.006F144A@cherry.ease.lsoft.com>;
          Wed, 28 Aug 2002 3:37:30 -0400
Message-ID:  
Date:         Wed, 28 Aug 2002 03:37:31 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Darshan Purohit 
Subject: Multiple Router LSAs in OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi,

RFC 2740 says that in presence of multiple router lsas from a router,
"The Options field and the router type bits (bits W, V, E and B) should
always be taken from the fragment with the smallest link state id".

So if there is a virtual link configured and it comes up, the router will
always have to reoriginate a new instance of its router LSA with the least
Link state id, with the 'V' bit set, in order for the "TransitCapability"
of the area to be set to TRUE, even if it chooses to generate a separate
router LSA for the virtual link.

Is the above statement true.

Is there a particular reason why the LSA with smallest LSID is chosen and
not , say, the last generated router LSA or the logical OR of the fields of
all router LSAs.

Please correct me if there are any flaws in my observation.

Thanks.
Darshan


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 28 08:07:49 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25965
	for ; Wed, 28 Aug 2002 08:07:49 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.006F1888@cherry.ease.lsoft.com>; Wed, 28 Aug 2002 8:09:15 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 105685 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 28 Aug 2002 08:09:15 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 28 Aug 2002 07:59:15 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id HAA25040; Wed, 28 Aug 2002 07:57:45
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200208281157.HAA25040@ietf.org>
Date:         Wed, 28 Aug 2002 07:57:45 -0400
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-katz-yeung-ospf-traffic-07.txt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.

        Title           : Traffic Engineering Extensions to OSPF Version 2
        Author(s)       : D. Katz, D. Yeung, K. Kompella
        Filename        : draft-katz-yeung-ospf-traffic-07.txt
        Pages           : 14
        Date            : 2002-8-27

This document describes extensions to the OSPF protocol version 2 to
support intra-area Traffic Engineering, using Opaque Link State
Advertisements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-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-katz-yeung-ospf-traffic-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-katz-yeung-ospf-traffic-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:     <2002-8-27144846.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-katz-yeung-ospf-traffic-07.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-katz-yeung-ospf-traffic-07.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2002-8-27144846.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 28 10:38:54 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02088
	for ; Wed, 28 Aug 2002 10:38:53 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.006F1ED0@cherry.ease.lsoft.com>; Wed, 28 Aug 2002 10:40:22 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 106219 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 28 Aug 2002 10:40:22 -0400
Received: from 143.107.253.153 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 28 Aug 2002 10:30:20 -0400
Received: (qmail 1524178 invoked from network); 28 Aug 2002 11:30:19 -0300
Received: from noc10.cce.usp.br (HELO usp.br) (143.107.30.10) by
          email.uspnet.usp.br with SMTP; 28 Aug 2002 11:30:19 -0300
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b)
            Gecko/20020721
X-Accept-Language: en-us, en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D6CDF16.90003@usp.br>
Date:         Wed, 28 Aug 2002 11:32:54 -0300
Reply-To: Mailing List 
Sender: Mailing List 
From: Giuliano Cardozo Medalha 
Subject: OSFP Project
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi,

I am in an OSPF project using cisco 3620 series with Fast Ethernet and
ATM E3 interfaces (besides other devices) and I have some questions
about design.

The following picture describes the topology:


          Public AS  Public AS   Public AS
             |         |          |
           7000       7000       7000     14 x 2511
            A1         A2        A3          A4
         Campus 1   Campus 2   Campus 3   Campus 4
              ()       ()        ()          ()
               |       |         |            |
               |       |         |            |
               |_______|_________|____________|  ATM / FR cloud - FRF8
                             0
                             0  ATM
                             0
                          Cisco 3620
                             0
                             0   Fast Ethernet
                             0
                             0
                             0 BI 1 - A6
  Public AS <---###---------### -----### - Big Iron 2 A7
             Net Iron        |  \
                             |    \
                             |      \
                            ### -----### - Big Iron 3 A8
                           BI 4 A9


The picture tries to explain the following environment:

We have 5 major campi for a university. Campus 1 is bigger than others
and has 6 devices: 4 foundry big iron, 1 foundry net iron and 1 cisco
3620. The autonomous system of the entire university is private and the
path to the public internet is made by the Public AS described above
(Net Iron - running BGP4).
All this 6 devices runs OSPF, creating the backbone area - Area 0
Besides, each big iron has another area configured (A6, A7, A8 and A9).
Each area has only one agregated group of IPv4 adresses that we can
summarize.

Cisco 3620 is used to connect all other 4 campi to the major campus.
Each campus has its own network infraestructure and its own ospf area
(A1, A2, A3 and A4) with another agregated group of IPv4 adresses.

These campi are connected to the 3620 router by Frame Relay cloud with
the FRF8 schema - (FR / ATM).

Cisco 3620 has one ATM interface for an E3 link to provide access to
these campi. Campus 1,2 and 3 has another path to the public internet by
Nortel Shasta devices. The FR link is used only for backup.

I would like to implement this architecture and need some help. Could I
extend the Area 0 to the border router on each campi, or the limit will
be the 3620 router ?

There is some architecture where we could put more than one area for
border router ?

Thanks a lot

Giuliano


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 28 13:06:12 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09452
	for ; Wed, 28 Aug 2002 13:06:12 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.006F22C6@cherry.ease.lsoft.com>; Wed, 28 Aug 2002 13:07:39 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 106894 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 28 Aug 2002 13:07:39 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 28 Aug 2002 13:07:38 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id 764AF4F41AA for
          ; Wed, 28 Aug 2002 10:07:37 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D69FB5F.94EE1AEC@arc.corp.mot.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D6D0305.3000006@redback.com>
Date:         Wed, 28 Aug 2002 13:06:13 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: OSPFv3 query (link LSAs & link local addresses)
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Arthur Dimitrelis wrote:

> Hi everyone,
>
> I've got a query regarding OSPF for IPv6. With reference to RFC2740,
> section 2.5 discusses how IPv6 link local addresses are used as the
> source addresses in PDU exchanges between OSPFv3 speakers (including
> HELLO packets), and goes on to state that an OSPFv3 router will learn
> the link-local addresses of all other routers attached to its links. No
> problems with all that.
>
> Now, appendix A.4.8 defines the packet format of a link LSA, which
> includes the link local address of its originating router. The
> commentary in this section explains that one of the purposes of a link
> LSA is to allow all routers on the link to learn the link-local address
> of the LSA's originator. Could this information not have been deduced
> from the Advertising Router ID field in the LSA's header (along with the
> information gleaned from previously seen HELLO packets, ie from those
> neighbors a router considers to be in the '2-way' state) ?
>
> Anybody know about or have any ideas on this apparent (to me)
> redundancy?


Arthur,

Look at section 3.8.1.1 in RFC 2740. The link local address in the
Link LSA to calculate the next-hop on NBMA networks. Independent
of NBMA networks, I think it is conveinent to have it in the Link LSA
with the IPv6 prefixes.


>
> cheers,
> arthur
>
>

Thanks,
--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 28 13:30:42 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10506
	for ; Wed, 28 Aug 2002 13:30:42 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.006F2187@cherry.ease.lsoft.com>; Wed, 28 Aug 2002 13:32:10 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 107146 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 28 Aug 2002 13:32:09 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 28 Aug 2002 13:32:09 -0400
Received: from redback.com (login004.redback.com [155.53.12.57]) by
          prattle.redback.com (Postfix) with ESMTP id 2C506FC059 for
          ; Wed, 28 Aug 2002 10:32:08 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
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:  <3D6D08C4.8060302@redback.com>
Date:         Wed, 28 Aug 2002 13:30:44 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: Multiple Router LSAs in OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Darshan Purohit wrote:

> Hi,
>
> RFC 2740 says that in presence of multiple router lsas from a router,
> "The Options field and the router type bits (bits W, V, E and B) should
> always be taken from the fragment with the smallest link state id".
>
> So if there is a virtual link configured and it comes up, the router will
> always have to reoriginate a new instance of its router LSA with the least
> Link state id, with the 'V' bit set, in order for the "TransitCapability"
> of the area to be set to TRUE, even if it chooses to generate a separate
> router LSA for the virtual link.
>
> Is the above statement true.
>
> Is there a particular reason why the LSA with smallest LSID is chosen and
> not , say, the last generated router LSA or the logical OR of the fields of
> all router LSAs.
>
> Please correct me if there are any flaws in my observation.


Hi Darshan,

I think you are basically correct. However, the other methods (OR'ing the
options in all router LSA instances or using the last generated router
LSA instance's option) each have their own inefficiencies. IMHO, the simple
approach of putting the definitive router LSA options in the first or only
router LSA is a good engineering choice.

>
> Thanks.
> Darshan
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 28 13:58:25 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11983
	for ; Wed, 28 Aug 2002 13:58:25 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.006F22DF@cherry.ease.lsoft.com>; Wed, 28 Aug 2002 13:59:53 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 107435 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 28 Aug 2002 13:59:53 -0400
Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 28 Aug 2002 13:59:53 -0400
Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by
          shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 92F305D00D; Thu, 29 Aug
          2002 02:59:51 +0900 (JST)
References: 
            <3D6D08C4.8060302@redback.com>
X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <20020829.025113.36497339.yasu@sfc.wide.ad.jp>
Date:         Thu, 29 Aug 2002 02:51:13 +0900
Reply-To: Mailing List 
Sender: Mailing List 
From: Yasuhiro Ohara 
Subject: Re: Multiple Router LSAs in OSPFv3
Comments: To: acee@REDBACK.COM
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D6D08C4.8060302@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Following.

acee> Hi Darshan,
acee>
acee> I think you are basically correct. However, the other methods
acee> (OR'ing the options in all router LSA instances or using the
acee> last generated router LSA instance's option) each have their own
acee> inefficiencies. IMHO, the simple approach of putting the
acee> definitive router LSA options in the first or only
acee> router LSA is a good engineering choice.

Basically, when Router-LSA changes a OSPF router must re-calculate his
SPF tree from scratch. In this case, a router must find (and look
into) all route-lsa eventually, so I guess we can say there'll be no
extra tasks in either way.

If we can calculate SPF incrementally, OR'ing will be not good because
a calculating router must check all Router-LSAs of a changing router.
Last LSA (i.e. the LSA having the most high Link-State-ID) technique
will be not better in comparison with the first Router-LSA technique,
because we know the first is "0", but we don't know what is the last
(most high) Link-State-ID value.

regards,
yasu


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Aug 28 14:16:25 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12693
	for ; Wed, 28 Aug 2002 14:16:24 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.006F237E@cherry.ease.lsoft.com>; Wed, 28 Aug 2002 14:17:52 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 107598 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 28 Aug 2002 14:17:52 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 28 Aug 2002 14:17:52 -0400
Received: from redback.com (login004.redback.com [155.53.12.57]) by
          prattle.redback.com (Postfix) with ESMTP id 9B2E3262811; Wed, 28 Aug
          2002 11:17:49 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: 
            <3D6D08C4.8060302@redback.com>
            <20020829.025113.36497339.yasu@sfc.wide.ad.jp>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D6D1379.6030801@redback.com>
Date:         Wed, 28 Aug 2002 14:16:25 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: Multiple Router LSAs in OSPFv3
Comments: To: Yasuhiro Ohara 
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Yasuhiro Ohara wrote:

> Following.
>
> acee> Hi Darshan,
> acee>
> acee> I think you are basically correct. However, the other methods
> acee> (OR'ing the options in all router LSA instances or using the
> acee> last generated router LSA instance's option) each have their own
> acee> inefficiencies. IMHO, the simple approach of putting the
> acee> definitive router LSA options in the first or only
> acee> router LSA is a good engineering choice.
>
> Basically, when Router-LSA changes a OSPF router must re-calculate his
> SPF tree from scratch. In this case, a router must find (and look
> into) all route-lsa eventually, so I guess we can say there'll be no
> extra tasks in either way.
>
> If we can calculate SPF incrementally, OR'ing will be not good because
> a calculating router must check all Router-LSAs of a changing router.
> Last LSA (i.e. the LSA having the most high Link-State-ID) technique
> will be not better in comparison with the first Router-LSA technique,
> because we know the first is "0", but we don't know what is the last
> (most high) Link-State-ID value.
>
> regards,



Yasu,

I was thinking more of the maintenance of the options from the
originating router's standpoint. One could come up
with a scheme of OR'ing the options and assuring a given
option is only set in one router LSA instance but I don't think it is
worth the complexity versus the benefit.

Thanks,
Acee


>
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 29 02:06:59 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04613
	for ; Thu, 29 Aug 2002 02:06:58 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.006F3A32@cherry.ease.lsoft.com>; Thu, 29 Aug 2002 2:08:19 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 110048 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 29 Aug 2002 02:08:19 -0400
Received: from 66.218.78.81 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 29 Aug 2002 02:08:19 -0400
Received: from [203.200.20.226] by web40302.mail.yahoo.com via HTTP; Wed, 28
          Aug 2002 23:08:19 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020829060819.18749.qmail@web40302.mail.yahoo.com>
Date:         Wed, 28 Aug 2002 23:08:19 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: OSPF-TE Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D6D1379.6030801@redback.com>
Precedence: list

Hi All,
    I was going through the Traffic Engineering
Extentions to OSPF
draft-katz-yeung-ospf-traffic-06.txt, in this draft
section 2.2 shows instance field.
                  I want to know what for this field
is used for. Actually my percepsion is that it is used
for if multiple instance of TE is running over OSPF.
But i am not sure about this. If anyone of you and
could help.
Regards
Amit

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 29 02:40:00 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11839
	for ; Thu, 29 Aug 2002 02:40:00 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006F3A09@cherry.ease.lsoft.com>; Thu, 29 Aug 2002 2:41:28 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 110113 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 29 Aug 2002 02:41:28 -0400
Received: from 195.58.103.125 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 29 Aug 2002 02:31:28 -0400
Received: from utfors.se (nat-sto.utfors.se [212.73.0.237]) by
          blooper.utfors.se (8.12.6/8.12.6) with ESMTP id g7T6VQtA018469; Thu,
          29 Aug 2002 08:31:26 +0200 (MEST)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1)
            Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-MIME-Autoconverted: from 8bit to quoted-printable by blooper.utfors.se id
                      g7T6VQtA018469
Message-ID:  <3D6DBFBE.4050603@utfors.se>
Date:         Thu, 29 Aug 2002 08:31:26 +0200
Reply-To: Mailing List 
Sender: Mailing List 
From: Loa Andersson 
Subject: LAst Call: draft-ietf-mpls-bundle-04.txt
Comments: To: isis-wg 
Comments: cc: MPLS wg 
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA11839

OSPF and IS-IS working groups, (mpls wg for info)

the iesg has started the review of the mpls working group draft
draft-ietf-mpls-bundle-04.txt. The immediate response from the iesg
is that the draft contains OSPF and ISIS related details (see
the included mail). After discussing with the wg chairs for ospf
and is-is working groups, there is a feeling that the two weeks
the iesg allocated for this last call might not be enough, since the
draft has not been widely circulated in the routing working groups.

Therefore:

This is to initiate a last call for the



by the ospf and is-is working groups.
The last call ends September 22nd at 12PM CET


Please include the mpls mailing list (mpls@uu.net) in your responses.

/Loa (co-chair of the mpls wg)

-------- Original Message --------
Subject: draft-ietf-mpls-bundle-04.txt
Date: Tue, 27 Aug 2002 15:06:48 -0400 (EDT)
From: Scott Bradner
To: loa.andersson@utfors.se, swallow@cisco.com


The IESG discussed this ID last week during its teleconference
one issue was raised during the discussion

"the draft contains OSPF & ISIS
related details and I don't remember it being LC'ed or reviewed
in the corresponding WGs."

can you start a 2 week last call on the IS-IS and OSPF mailing
lists for this document?

Scott

-- 
     Loa Andersson
     Chief Architect,
     Utfors Research, Architecture and Future Lab (URAX)
     Utfors AB
     Råsundavägen 12
     Box 525, 169 29 Solna
     Office          +46 8 5270 2000
     Office direct   +46 8 5270 5038
     Mobile          +46 70 848 5038
     Email           loa.andersson@utfors.se
     WWW             www.utfors.se


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 29 03:12:09 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12314
	for ; Thu, 29 Aug 2002 03:12:08 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.006F3975@cherry.ease.lsoft.com>; Thu, 29 Aug 2002 3:13:37 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 110256 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 29 Aug 2002 03:13:37 -0400
Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 29 Aug 2002 03:13:36 -0400
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com
          (iPlanet Messaging Server 5.1 (built Sep  5 2001)) id
          <0H1L00701G8Z5I@mailout1.samsung.com> for ospf@dISCUSS.MICROSOFT.COM;
          Thu, 29 Aug 2002 16:17:23 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet
          Messaging Server 5.1 (built Sep  5 2001)) with ESMTP id
          <0H1L00C2ZG8YG5@mailout1.samsung.com> for ospf@dISCUSS.MICROSOFT.COM;
          Thu, 29 Aug 2002 16:17:22 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging
          Server 5.1 (built Sep  5 2001)) with ESMTPA id
          <0H1L009CJG9IC1@mmp2.samsung.com> for ospf@dISCUSS.MICROSOFT.COM;
          Thu, 29 Aug 2002 16:17:44 +0900 (KST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <200208281157.HAA25040@ietf.org>
Message-ID:  <006c01c24f2b$a35f1220$b4036c6b@sisodomain.com>
Date:         Thu, 29 Aug 2002 12:43:54 +0530
Reply-To: Mailing List 
Sender: Mailing List 
From: Manav Bhatia 
Subject: draft-katz-yeung-ospf-traffic-07.txt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7BIT

Hi,
I guess that if a router is advertising TE LSAs and if it is also
advertising BGP routes with the next hop set to its BGP router ID (which is
the usual practise) then it must put the same Router ID in Router Address
TLV as the BGP Router ID.

Can this be mentioned explicitly as it has been done for IS-IS in section
2.4.1?

Regards,
Manav


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 29 09:45:45 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21936
	for ; Thu, 29 Aug 2002 09:45:45 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.006F4151@cherry.ease.lsoft.com>; Thu, 29 Aug 2002 9:47:13 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 112181 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 29 Aug 2002 09:47:12 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 29 Aug 2002 09:47:10 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id 9961C449A30 for
          ; Thu, 29 Aug 2002 06:47:08 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <20020829060819.18749.qmail@web40302.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D6E257D.7050205@redback.com>
Date:         Thu, 29 Aug 2002 09:45:33 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: OSPF-TE Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Amit Srivastava wrote:

> Hi All,
>     I was going through the Traffic Engineering
> Extentions to OSPF
> draft-katz-yeung-ospf-traffic-06.txt, in this draft
> section 2.2 shows instance field.
>                   I want to know what for this field
> is used for. Actually my percepsion is that it is used
> for if multiple instance of TE is running over OSPF.


Nope. Since a single OSPF router will originate multiple
TE LSAs it is required for a unique LSA ID. OSPF routers
supporting the TE extensions are required to originate
one LSA for each OSPF interface considered in traffic
engineered paths (section 2.4.2).


> But i am not sure about this. If anyone of you and
> could help.

> Regards
> Amit
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 29 13:42:20 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03468
	for ; Thu, 29 Aug 2002 13:42:19 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006F4921@cherry.ease.lsoft.com>; Thu, 29 Aug 2002 13:43:49 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 113611 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 29 Aug 2002 13:43:49 -0400
Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 29 Aug 2002 13:33:49 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <2.006F49F9@cherry.ease.lsoft.com>;
          Thu, 29 Aug 2002 13:33:48 -0400
Message-ID:  
Date:         Thu, 29 Aug 2002 13:33:48 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Shreayas Becker 
Subject: Data Description Exchange
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi,

I have few questions regarding DD exchange to understand what we can
implement/others implemented while trying form an adjacency.

Question:

Before changing into FULL state, I would like to know whether we need to
send LSA header information in DD packets.

If so, how we are going to calculate checksum for this LSA header (i.e.
just omit LS Age Information) and

What length one has to specify while mentioning its packet length (i.e.
even though, we are just going to send LSA Header, do we need to say Full
LSA packet size!)

Also, during exStart->exChange->Full transition, is it possible to form an
adjacency without sending LSA Header info in its DD packets.

Any Suggestions or comments are welcome!

Thanks and looking forward to all your replies!

- SB


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 29 14:10:04 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05125
	for ; Thu, 29 Aug 2002 14:10:04 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.006F49E8@cherry.ease.lsoft.com>; Thu, 29 Aug 2002 14:11:33 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 113751 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 29 Aug 2002 14:11:32 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 29 Aug 2002 14:11:32 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id 523CB1DCC75 for
          ; Thu, 29 Aug 2002 11:11:31 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
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:  <3D6E6371.6050400@redback.com>
Date:         Thu, 29 Aug 2002 14:09:53 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: Data Description Exchange
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Shreayas Becker wrote:

> Hi,


Hi Shreayas,


>
> I have few questions regarding DD exchange to understand what we can
> implement/others implemented while trying form an adjacency.
>
> Question:
>
> Before changing into FULL state, I would like to know whether we need to
> send LSA header information in DD packets.


Yes. You need to synchronize databases to reach FULL state.


>
> If so, how we are going to calculate checksum for this LSA header (i.e.
> just omit LS Age Information) and


No. The LSA checksum unmodified (i.e., for the entire LSA) is sent
in the LSA header in the DD packets.


>
> What length one has to specify while mentioning its packet length (i.e.
> even though, we are just going to send LSA Header, do we need to say Full
> LSA packet size!)


You always specify the real OSPF packet length in the OSPF packet header.
In other words, you specify only take into account the 20 byte LSA header
since that is what you actually put in the packet.


>
> Also, during exStart->exChange->Full transition, is it possible to form an
> adjacency without sending LSA Header info in its DD packets.

No. You'd always have at least your router LSA.

>
> Any Suggestions or comments are welcome!

You might want to re-read the first 4 sections of RFC 2328 and then
consult the details as necessary.

Good Luck,
Acee

>
> Thanks and looking forward to all your replies!
>
> - SB
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Aug 29 19:09:33 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14741
	for ; Thu, 29 Aug 2002 19:09:33 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.006F5367@cherry.ease.lsoft.com>; Thu, 29 Aug 2002 19:11:02 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 115038 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 29 Aug 2002 19:11:02 -0400
Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 29 Aug 2002 19:11:01 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id TAA04117; Thu, 29 Aug 2002 19:10:27 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA18561;
          Thu, 29 Aug 2002 19:10:21 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id ; Thu, 29 Aug 2002 19:10:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <39469E08BD83D411A3D900204840EC55763306@vie-msgusr-01.dc.fore.com>
Date:         Thu, 29 Aug 2002 19:10:18 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Naidu, Venkata" 
Subject: Re: LAst Call: draft-ietf-mpls-bundle-04.txt
Comments: To: Loa Andersson ,
          isis-wg 
Comments: cc: MPLS wg 
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Link Bundling comments:

-> This is to initiate a last call for the
->
-> 


   All component links in a bundle must begin and end on the same pair
   of LSRs, have the same Link Type (i.e., point-to-point or multi-
   access), the same Traffic Engineering metric, and the same set of
   resource classes at each end of the links.

   A Forwarding Adjacency may be a component link; in fact, a bundle can
   consist of a mix of point-to-point links and FAs.

Link Types Restriction
----------------------
*** Only beginning & ending of the link types are restricted or
*** all the links along the path (from beginning router to end router)
*** are restricted to the same link type?

*** I didn't not understand why we need same link type at the
*** beginning and at the end of the link? Link Type TLV will cover
*** whatever link type at the advertising router side of the link.
*** I didn't see any issue if we have different link types at each
*** side of the link.

*** I request to elaborate these restriction a little bit with
*** a single appropriate diagram (if possible).

*** The use of bundling has very large scope. For example, one can
*** bundle all the VCs in a VP (where each VC is viewed as a different
*** link with its own resources). All such VPs can be bundled/unbundled
*** (depending on the requirements). Still all those VPs will have
*** a same risk-factor (i.e. SRLG). I think, it will be
*** better to mention few example of such uses of link bundling.


Metric Restriction
------------------
*** Why is the same metric restriction? Can a router have
*** the flexibility to decide a different metric for the bundled
*** link (may be independent of all the component links)?

*** For example, a router chooses the largest metric of all
*** component links (just like OSPF area aggregation). Just a
*** a matter of flexibility. If the metrics are different and
*** if we bundle those links did you see any problem?

*** Let is explain an example scenario, where router starts
*** advertising the largest of all links metric as bundled
*** link metric. One the largest component link resources (bw)
*** are completely consumed (crossed some threshold ) then
*** bundled link metric will become the next highest component
*** link metric.


Link Protection consideration
-----------------------------
*** There is no mention about link protection type of the bundled
*** link when component links are of different type?


SRLG consideration
------------------
*** There is no mention about SRLGs of bundled link w.r.t component
*** links. In some situations, failure of one component link may or
*** may not affect other component links. I think, it will be better
*** to mention something about SRLG - that is, all component links
*** in bundled link must have same SRLG (in order to benefit most
*** from bundling). Even if the component links risk factor is independent
*** from each other (ie. different SRLGs) still we can use bundling.
*** Please mention something like that...


Switching Capability consideration
----------------------------------
*** I think the switching capability should be same for all component
*** links in order to use bundling?! Please mention.


DiffServ consideration
----------------------
*** There is no mention about BCs and TE Classes applicability
*** to Link bundling? Do you see any issues w.r.t to the recent
*** diffserv draft (esp interpretation of unserverved bws etc)?

  Thank You.

--
Venkata.


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Aug 30 00:15:52 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22756
	for ; Fri, 30 Aug 2002 00:15:52 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006F5EEF@cherry.ease.lsoft.com>; Fri, 30 Aug 2002 0:17:21 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 115993 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 30 Aug 2002 00:17:20 -0400
Received: from 66.218.78.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 30 Aug 2002 00:17:20 -0400
Received: from [203.200.20.226] by web40305.mail.yahoo.com via HTTP; Thu, 29
          Aug 2002 21:17:19 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020830041719.48797.qmail@web40305.mail.yahoo.com>
Date:         Thu, 29 Aug 2002 21:17:19 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: OSPF-TE Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D6E257D.7050205@redback.com>
Precedence: list

Hi Accee,
      Thanks for the help.
Regards
Amit
--- Acee Lindem  wrote:
> Amit Srivastava wrote:
>
> > Hi All,
> >     I was going through the Traffic Engineering
> > Extentions to OSPF
> > draft-katz-yeung-ospf-traffic-06.txt, in this
> draft
> > section 2.2 shows instance field.
> >                   I want to know what for this
> field
> > is used for. Actually my percepsion is that it is
> used
> > for if multiple instance of TE is running over
> OSPF.
>
>
> Nope. Since a single OSPF router will originate
> multiple
> TE LSAs it is required for a unique LSA ID. OSPF
> routers
> supporting the TE extensions are required to
> originate
> one LSA for each OSPF interface considered in
> traffic
> engineered paths (section 2.4.2).
>
>
> > But i am not sure about this. If anyone of you and
> > could help.
>
> > Regards
> > Amit
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Finance - Get real-time stock quotes
> > http://finance.yahoo.com
> >
> >
>
>
> --
> Acee


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Aug 30 06:16:17 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09913
	for ; Fri, 30 Aug 2002 06:16:16 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006F634D@cherry.ease.lsoft.com>; Fri, 30 Aug 2002 6:17:45 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 117382 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 30 Aug 2002 06:17:44 -0400
Received: from 192.11.223.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Fri, 30 Aug 2002 06:17:44 -0400
Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com
          [135.252.18.18]) by auemail1.firewall.lucent.com
          (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7UAHgV14788 for
          ; Fri, 30 Aug 2002 06:17:43 -0400 (EDT)
Received: by CI0026EXCH001U with Internet Mail Service (5.5.2653.19) id
          ; Fri, 30 Aug 2002 18:17:41 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Message-ID:  <31C0F08B0D18D511ACC800508BAE7B4702B9D03C@CI0026EXCH001U>
Date:         Fri, 30 Aug 2002 18:17:40 +0800
Reply-To: Mailing List 
Sender: Mailing List 
From: "Li, Ke Qin (Peter)" 
Subject: Re: Routing IPv4 with OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi,

What do you mean by "built-in" feature? RFC2740 does not describe Opaque
LSA.

Keqin Li

> -----Original Message-----
> From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP]
> Sent: Thursday, August 15, 2002 4:10 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: Routing IPv4 with OSPFv3
>
>
>
>
> arthurd> And while I'm at it, are there any such things as
> Opaque LSAs for  OSPFv3?
>
> It is built-in feature of OSPFv3.
>
> regards.
> yasu
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Aug 30 06:21:10 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09986
	for ; Fri, 30 Aug 2002 06:21:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006F643F@cherry.ease.lsoft.com>; Fri, 30 Aug 2002 6:22:41 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 117415 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 30 Aug 2002 06:22:40 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 30 Aug 2002 06:22:40 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Fri, 30 Aug 2002 06:22:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Fri, 30 Aug 2002 06:24:57 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: Routing IPv4 with OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Keqin Li,

Section 2.9 talks about Handling Unknown LSA's, the IPv4 behaviour of
discarding unknown types is unsupported.

Thanks,
Vishwas

-----Original Message-----
From: Li, Ke Qin (Peter) [mailto:keqinli@LUCENT.COM]
Sent: Friday, August 30, 2002 3:48 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: Routing IPv4 with OSPFv3


Hi,

What do you mean by "built-in" feature? RFC2740 does not describe Opaque
LSA.

Keqin Li

> -----Original Message-----
> From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP]
> Sent: Thursday, August 15, 2002 4:10 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: Routing IPv4 with OSPFv3
>
>
>
>
> arthurd> And while I'm at it, are there any such things as
> Opaque LSAs for  OSPFv3?
>
> It is built-in feature of OSPFv3.
>
> regards.
> yasu
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Aug 30 09:37:04 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16556
	for ; Fri, 30 Aug 2002 09:37:03 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.006F69B5@cherry.ease.lsoft.com>; Fri, 30 Aug 2002 9:38:32 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 117850 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 30 Aug 2002 09:38:31 -0400
Received: from 216.136.227.58 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Fri, 30 Aug 2002 09:38:31 -0400
Received: from [158.101.164.157] by web21004.mail.yahoo.com via HTTP; Fri, 30
          Aug 2002 06:38:30 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020830133830.93143.qmail@web21004.mail.yahoo.com>
Date:         Fri, 30 Aug 2002 06:38:30 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Shreyas 
Subject: Re: Data Description Exchange
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D6E6371.6050400@redback.com>
Precedence: list

Thanks for your reply Acee.

But, I have one more question regarding the packet
exchange during exStart/exChange period.

During that transition phase, I am trying to send DD
packets like as I mentioned in this mail. But when I
sniff the network or looking at my OSPF router, I can
see it did not understand the packet properly and
network analyser only shows packet information upto
Data Description and simply ignores LSA Header. (I
know it may be due to checksum in LSA Header).

Any Idea/thoughts on this is really appreciated! In
other words, how I can include LSA header information
in this packet!


Thanks!
- SB

//
// ----- Ethernet II -----
//

define ospf [ 00 20 9c 23 73 e8
        08 00 20 ac 9d d5
        08 00

//
// ----- Internet Protocol -----
// ----- 20 bytes -----
//

45
00
00 34                     // Total Length
5a a0                     // Identification
00                        // Flags
00                        // Frame Offset
40                        // TTL
59                        // Protocol (OSPF)
00 00                     // Checksum
0a 65 01 43               // Source
0a 65 01 41               // Destination

//
// ----- OSPF Header -----
//

02                        // OSPF Version
02                        // OSPF Packet Type (Hello
Pkt)
00 20                     // Packet Length
0a 65 01 43                       // Source OSPF Router ID
0a 65 01 40                       // Area ID
00 00                     // Packet Checksum
00 00                     // Auth Type (None)
00 00 00 00               // Auth Date (None)
00 00 00 00

//
// ----- OSPF Data Description Info -----
//

05 dc                     // Interface MTU
02                        // OSPF Version
00                        // Master
00 00 00 02                       // DD Sequence

// ------- LSA Header Information ------
//

00 01                   // LS Age
02                      // Options
01                      // Router LSA
0a 65 01 43             // Link State ID
0a 65 01 43             // Adv. Router
0a 00 00 00             // LS Sequence
00 00                   // Checksum
00 14                   // Length
];

xsum ospf[24] 14 20;
xsum ospf[46] 34 32;
xsum ospf[82] 68 20;

send ospf;



--- Acee Lindem  wrote:
> Shreayas Becker wrote:
>
> > Hi,
>
>
> Hi Shreayas,
>
>
> >
> > I have few questions regarding DD exchange to
> understand what we can
> > implement/others implemented while trying form an
> adjacency.
> >
> > Question:
> >
> > Before changing into FULL state, I would like to
> know whether we need to
> > send LSA header information in DD packets.
>
>
> Yes. You need to synchronize databases to reach FULL
> state.
>
>
> >
> > If so, how we are going to calculate checksum for
> this LSA header (i.e.
> > just omit LS Age Information) and
>
>
> No. The LSA checksum unmodified (i.e., for the
> entire LSA) is sent
> in the LSA header in the DD packets.
>
>
> >
> > What length one has to specify while mentioning
> its packet length (i.e.
> > even though, we are just going to send LSA Header,
> do we need to say Full
> > LSA packet size!)
>
>
> You always specify the real OSPF packet length in
> the OSPF packet header.
> In other words, you specify only take into account
> the 20 byte LSA header
> since that is what you actually put in the packet.
>
>
> >
> > Also, during exStart->exChange->Full transition,
> is it possible to form an
> > adjacency without sending LSA Header info in its
> DD packets.
>
> No. You'd always have at least your router LSA.
>
> >
> > Any Suggestions or comments are welcome!
>
> You might want to re-read the first 4 sections of
> RFC 2328 and then
> consult the details as necessary.
>
> Good Luck,
> Acee
>
> >
> > Thanks and looking forward to all your replies!
> >
> > - SB
> >
> >
>
>
> --
> Acee


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Aug 30 10:17:40 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18355
	for ; Fri, 30 Aug 2002 10:17:39 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.006F6A17@cherry.ease.lsoft.com>; Fri, 30 Aug 2002 10:19:08 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 118049 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 30 Aug 2002 10:19:08 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 30 Aug 2002 10:19:08 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id C2CA61DCC79 for
          ; Fri, 30 Aug 2002 07:19:06 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <20020830133830.93143.qmail@web21004.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D6F7E6E.6050302@redback.com>
Date:         Fri, 30 Aug 2002 10:17:18 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: Data Description Exchange
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Shreyas wrote:

> Thanks for your reply Acee.
>
> But, I have one more question regarding the packet
> exchange during exStart/exChange period.
>
> During that transition phase, I am trying to send DD
> packets like as I mentioned in this mail. But when I
> sniff the network or looking at my OSPF router, I can
> see it did not understand the packet properly and
> network analyser only shows packet information upto
> Data Description and simply ignores LSA Header. (I
> know it may be due to checksum in LSA Header).


Shreyas,

Actually, the receiver of a DD packet should only use
the LSA header checksum to determine whether the received
LSA is more recent than the database copy.

Right off hand, it looks like you have a problem
with OSPF packet length (0x20). Having said that, I
don't think this is the proper forum to try and debug
your manually built packets. If you really want to do
this, a better tack would be to turn on debug on the
router you're trying to communicate with and address
any packet problems one at a time.


>
> Any Idea/thoughts on this is really appreciated! In
> other words, how I can include LSA header information
> in this packet!
>
>
> Thanks!
> - SB
>
> //
> // ----- Ethernet II -----
> //
>
> define ospf [ 00 20 9c 23 73 e8
>         08 00 20 ac 9d d5
>         08 00
>
> //
> // ----- Internet Protocol -----
> // ----- 20 bytes -----
> //
>
> 45
> 00
> 00 34                     // Total Length
> 5a a0                     // Identification
> 00                        // Flags
> 00                        // Frame Offset
> 40                        // TTL
> 59                        // Protocol (OSPF)
> 00 00                     // Checksum
> 0a 65 01 43               // Source
> 0a 65 01 41               // Destination
>
> //
> // ----- OSPF Header -----
> //
>
> 02                        // OSPF Version
> 02                        // OSPF Packet Type (Hello
> Pkt)
> 00 20                     // Packet Length
> 0a 65 01 43                       // Source OSPF Router ID
> 0a 65 01 40                       // Area ID
> 00 00                     // Packet Checksum
> 00 00                     // Auth Type (None)
> 00 00 00 00               // Auth Date (None)
> 00 00 00 00
>
> //
> // ----- OSPF Data Description Info -----
> //
>
> 05 dc                     // Interface MTU
> 02                        // OSPF Version
> 00                        // Master
> 00 00 00 02                       // DD Sequence
>
> // ------- LSA Header Information ------
> //
>
> 00 01                   // LS Age
> 02                      // Options
> 01                      // Router LSA
> 0a 65 01 43             // Link State ID
> 0a 65 01 43             // Adv. Router
> 0a 00 00 00             // LS Sequence
> 00 00                   // Checksum
> 00 14                   // Length
> ];
>
> xsum ospf[24] 14 20;
> xsum ospf[46] 34 32;
> xsum ospf[82] 68 20;
>
> send ospf;
>
>
>
> --- Acee Lindem  wrote:
>
>>Shreayas Becker wrote:
>>
>>
>>>Hi,
>>>
>>
>>Hi Shreayas,
>>
>>
>>
>>>I have few questions regarding DD exchange to
>>>
>>understand what we can
>>
>>>implement/others implemented while trying form an
>>>
>>adjacency.
>>
>>>Question:
>>>
>>>Before changing into FULL state, I would like to
>>>
>>know whether we need to
>>
>>>send LSA header information in DD packets.
>>>
>>
>>Yes. You need to synchronize databases to reach FULL
>>state.
>>
>>
>>
>>>If so, how we are going to calculate checksum for
>>>
>>this LSA header (i.e.
>>
>>>just omit LS Age Information) and
>>>
>>
>>No. The LSA checksum unmodified (i.e., for the
>>entire LSA) is sent
>>in the LSA header in the DD packets.
>>
>>
>>
>>>What length one has to specify while mentioning
>>>
>>its packet length (i.e.
>>
>>>even though, we are just going to send LSA Header,
>>>
>>do we need to say Full
>>
>>>LSA packet size!)
>>>
>>
>>You always specify the real OSPF packet length in
>>the OSPF packet header.
>>In other words, you specify only take into account
>>the 20 byte LSA header
>>since that is what you actually put in the packet.
>>
>>
>>
>>>Also, during exStart->exChange->Full transition,
>>>
>>is it possible to form an
>>
>>>adjacency without sending LSA Header info in its
>>>
>>DD packets.
>>
>>No. You'd always have at least your router LSA.
>>
>>
>>>Any Suggestions or comments are welcome!
>>>
>>You might want to re-read the first 4 sections of
>>RFC 2328 and then
>>consult the details as necessary.
>>
>>Good Luck,
>>Acee
>>
>>
>>>Thanks and looking forward to all your replies!
>>>
>>>- SB
>>>
>>>
>>>
>>
>>--
>>Acee
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Aug 30 10:43:23 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19497
	for ; Fri, 30 Aug 2002 10:43:22 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006F6B44@cherry.ease.lsoft.com>; Fri, 30 Aug 2002 10:44:52 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 118106 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 30 Aug 2002 10:44:51 -0400
Received: from 128.2.209.197 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 30 Aug 2002 10:34:51 -0400
Received: from ux10.sp.cs.cmu.edu ([128.2.209.197]) by ux10.sp.cs.cmu.edu id
          aa03456; 30 Aug 2002 10:34 EDT
X-X-Sender:  
MMDF-Warning:  Parse error in original version of preceding line at
               ux10.sp.cs.cmu.edu
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  
Date:         Fri, 30 Aug 2002 10:34:25 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Keng 
Subject: Re: Data Description Exchange
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <20020830133830.93143.qmail@web21004.mail.yahoo.com>
Precedence: list

> --- Acee Lindem  wrote:
> >Also, during exStart->exChange->Full transition,
> > is it possible to form an
> > > adjacency without sending LSA Header info in its
> > DD packets.
> >
>  No. You'd always have at least your router LSA.

Acee,

with regards to your comment above,
if a master router has more DD packets to send than the slave and the
slave has already sent its entire db, doesn't the slave just ack with DD
packets that have no lsa headers (I=0, M=0)?

thanks,
Keng.


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Aug 30 10:54:18 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20001
	for ; Fri, 30 Aug 2002 10:54:18 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006F6C29@cherry.ease.lsoft.com>; Fri, 30 Aug 2002 10:55:47 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 118174 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 30 Aug 2002 10:55:47 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 30 Aug 2002 10:55:47 -0400
Received: from redback.com (login005.redback.com [155.53.12.60]) by
          prattle.redback.com (Postfix) with ESMTP id A01892CDB41 for
          ; Fri, 30 Aug 2002 07:55:45 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
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:  <3D6F8704.6080005@redback.com>
Date:         Fri, 30 Aug 2002 10:53:56 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: Data Description Exchange
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Keng wrote:

>>--- Acee Lindem  wrote:
>>
>>>Also, during exStart->exChange->Full transition,
>>>is it possible to form an
>>>
>>>>adjacency without sending LSA Header info in its
>>>>
>>>DD packets.
>>>
>>>
>> No. You'd always have at least your router LSA.
>>
>
> Acee,
>
> with regards to your comment above,
> if a master router has more DD packets to send than the slave and the
> slave has already sent its entire db, doesn't the slave just ack with DD
> packets that have no lsa headers (I=0, M=0)?


Hi Keng,

You are correct. I was speaking in terms of the database exchange process
and the first DD packet sent in the exchange.



>
> thanks,
> Keng.
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Sat Aug 31 22:12:55 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17119
	for ; Sat, 31 Aug 2002 22:12:55 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.006F9D72@cherry.ease.lsoft.com>; 1 Sep 2002 22:14:19 +2000
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 126253 for OSPF@DISCUSS.MICROSOFT.COM;
          Sat, 31 Aug 2002 22:14:18 -0400
Received: from 192.18.42.14 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Sat, 31 Aug 2002 22:04:18 -0400
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com
          (8.9.3+Sun/8.9.3) with ESMTP id TAA10594 for
          ; Sat, 31 Aug 2002 19:04:17 -0700 (PDT)
Received: from labeast (labeast [129.148.75.22]) by sydney.East.Sun.COM
          (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id g8124GL14223 for
          ; Sat, 31 Aug 2002 22:04:16 -0400 (EDT)
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: mO/dF8mLUGRz/jnAeDHmGQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc
Message-ID:  <200209010204.g8124GL14223@sydney.East.Sun.COM>
Date:         Sat, 31 Aug 2002 22:04:15 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Radia Perlman - Boston Center for Networking              
Subject: Re: what is the fundamental difference between OSPF and IS-IS?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

        From: "Liu B." 
>>what is the fundamental difference (or
>>improvement?) between OSPF and IS-IS?

>>Bin Liu

Several people mentioned my paper from 1991, and since it will
probably be hard to get (I don't have a copy, and haven't seen
it in years), I thought I'd mention it's probably not worth
worrying about. I'd be surprised if it would
be too helpful today.  Both protocols have changed since then, so I'd think
the paper would be mostly interesting, if at all, for historical reasons.

So back to "what is the difference between OSPF and IS-IS?"...

This sort of question should be asked more often, especially where there
are "foo" vs "bar" debates. As I said in my "Miss Manners meets the IETF"
talk, unfortunately such questions often lead to err..nontechnical
responses. I'm glad that all the responses to this note have been
thoughtful and technical.

And since people will periodically wonder about the real technical
differences between foo and bar, it is useful to write the stuff down.

This particular question (differences between IS-IS and OSPF)
is a topic that is asked about sufficiently often that it would
probably be worth writing an updated paper, based on the most recent
versions of the two protocols. My book (Interconnections) discusses
some more differences, and Dave Katz's presentation is also
helpful. But I think it would be nice to have some set of people
carefully compare both specs, and
calmly write down the differences and the pros and cons of the differences.
And given that it seems like both protocols will persist, if there
are cases where one scheme is significantly
better, it ought to be folded into the
other protocol if possible.

As people on the list have pointed out, there is a lot of similarity between
OSPF and IS-IS. To understand why there are two protocols, it helps
to know some of the history.

Basically, the first link state protocol was for the ARPANET. It
introduced the idea of link state protocols, with the major
ideas being:
   . flood link state information to everyone
   . use Dijkstra's algorithm on the link state database to
     compute paths
   . an algorithm for incrementally updating the Dijkstra tree
     when there are just a few link changes.

The improvements (that I can think of off the top of my head)
introduced by IS-IS were:
  a) making link state distribution robust (the ARPANET had an amusing
     failure mode)
  b) efficient incorporation of LANs, including the concept of Designated
     Routers, LANs as pseudonodes, and link state syncronization over
     a LAN using CSNPs. (ARPANET was just point-to-point links)
  c) exchange of parameter information (such as how long to wait before
     declaring neighbor down), so that parameters can be set independently
     and differently, and still interwork

IS-IS was originally designed for CLNP, which had two forms of routing:
       . exact match of bottom 6 bytes, or
       . shortest prefix of top part
That's where the "two levels" came about, though the "area routing"
stuff could in theory be multilevel. IP only has one type of routing, which
is like the shortest prefix, area routing in CLNP.
IS-IS would have looked a little different if it had originally
been designed for IP.

OSPF was designed specifically for IP and was loosely based
on IS-IS. At the time OSPF was beginning
to be designed, it didn't occur to anyone that IS-IS could be easily
adapted to route
IP. Ross Callon noticed that once a routing algorithm existed, it was
a mere detail to add reachability information for a different data
packet format, and he wrote RFC 1195. (Interestingly, the concept
of integrated routing wasn't a new idea. I realized years later, when
looking at RIP's packet format, that RIP, deployed years before
integrated IS-IS was conceived, was designed for routing multiple
address families).

Perhaps if the idea of using IS-IS for IP was thought of before
work on OSPF had started, there wouldn't be two protocols. But once
a group starts on something it's hard to stop. So there wound up
being two protocols.

NLSP was a version of IS-IS for IPX, and introduced some improvements,
my favorite being DR election (see below).

Differences I can remember (off the top of my head).

a) Designated Router election: it's "deterministic" in IS-IS, which means,
   given the same set of routers, the same router will be elected. It's
   "sticky" in OSPF, meaning that once you get to be DR, you stay DR.
   This makes things more stable...if the highest priority router is
   flaky in IS-IS, every time it goes up it takes over, only to crash again.
   But I was told when designing IS-IS that determinism was important, which
   requires the behavior in IS-IS.

   For DR election, if I had to choose between OSPF's way and IS-IS's
   way, I'd choose OSPF's way, but NLSP (IS-IS for IPX plus
   some improvements) had a method
   that gave the best of both worlds.
   It has nodes change their priority after becoming DR,
   which allows you through astute priority settings, to
   choose deterministic or sticky behavior, or anything
   in between.

b) LSP distribution on a LAN: IS-IS does it with CSNP's. OSPF with
   explicit acks. I believe both ways are just fine.

c) Originally IS-IS passed no upper layer information into areas, and
   you just exited via the nearest level 2 router, whereas OSPF always
   fed all information into the area so you could choose the optimal
   exit point. Both have now been modified so you can choose any
   point on the tradeoff between extra routing info and optimal routing.

d) parameter synchronization: IS-IS allows neighbors to have different
   values for things like Hello Timer, and still interwork.


So anyway, there are a bunch of little nerdy differences, some of
which might matter and some of which are just different because different
groups did them. For the ones that matter, mostly the protocols have
evolved to take advantages of features in the other protocol.

I assume if there was an updated IS-IS vs OSPF document, someone would
have mentioned it in response to Bin Liu's post. So assuming there
isn't such, if someone wanted to try to do it, I (and I'm sure lots
of other people) would be happy to help.

Radia