From owner-ospf@DISCUSS.MICROSOFT.COM Sat Feb 1 17:24:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16767 for ; Sat, 1 Feb 2003 17:24:22 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.008C6A88@cherry.ease.lsoft.com>; Sat, 1 Feb 2003 17:27:55 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 594413 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 1 Feb 2003 17:27:54 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 1 Feb 2003 17:27:54 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id A4BE3457B54 for ; Sat, 1 Feb 2003 14:27:50 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3E39DF3F.5080201@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E3C4982.1000907@redback.com> Date: Sat, 1 Feb 2003 17:26:10 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF IGP Capabilities Draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Abhay Roy wrote: > Acee, Hi Abhay, > > One of the questions raised was, why do we need to advertise these > capabilities? I am glad to see that, there is at least one useful > application (as in PCSD). Yes and I think there will be others in the future. > > I still have those reservations about the usefulness of many other > 'capabilities' this document describes. IMHO, if the receivers of > these capabilities are just going to display it in a 'show' > command, we should NOT specify them in this document. Since these are existing mechanisms we really can't make the receivers have any dependence on them. However, I'm not sure that is a reason not to allow the bits to be advertised with other router capabilities which are dependent on the IGP capabilities mechanism. > > Regards, > -Roy- > > On 01/30/03-0500 at 9:28pm, Acee Lindem writes: > > >>As many of you recall, we've discussed this draft at both >>the Yokohama and Atlanta OSPF WG meetings. I wasn't in Yokohama >>but apparently there were some present who voiced reservations >>with the draft. In Atlanta, there wasn't a lot of discussion (other >>than strong support from the authors ;^). We agreed to discuss this >>draft further on the OSPF list. >> >>Are there still people who have reservations with the draft? >> >>http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt >> >>[Speaking as a WG member] >> >>I think the draft is a natural mechanism for advertising new OSPF >>capabilities now that the LSA option bits have been exhausted. >>We've already extended OSPF to support traffic engineering (TE) >>information and this mechanism is slated to be used for propagating >>an OSPF router's ability to act as an MPLS TE path computation >>server (PCS). >> >>Thanks, >>-- >>Acee >> > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 3 06:53:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03981 for ; Mon, 3 Feb 2003 06:53:50 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.008C90C7@cherry.ease.lsoft.com>; Mon, 3 Feb 2003 6:57:24 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 598103 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 3 Feb 2003 06:57:24 -0500 Received: from 207.68.165.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Feb 2003 06:57:24 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 3 Feb 2003 03:57:23 -0800 Received: from 193.116.20.220 by sea2fd.sea2.hotmail.msn.com with HTTP; Mon, 03 Feb 2003 11:57:23 GMT X-Originating-IP: [193.116.20.220] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 03 Feb 2003 11:57:23.0499 (UTC) FILETIME=[69B9B7B0:01C2CB7B] Message-ID: Date: Mon, 3 Feb 2003 11:57:23 +0000 Reply-To: Mailing List Sender: Mailing List From: gab jones To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, This are to people who have cisco netflow enabled on their network(ospf)routers. Il like to know what netflow analyzers people are currently using. I am currently looking into NetQos report analyzer. Is there anyone currently using this? If they are what do they think of the product? Anyone please just list what product or open source tool they are currently using to analyze netflow data and why? Suggestions on what netflow analyzer are good out there is it better to use open source e.g flow-tools, cflowd I know with the open source they have powerful command line utilities to examine flows thanks regards, gab _________________________________________________________________ Stay in touch with MSN Messenger http://messenger.msn.co.uk From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 3 06:53:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03995 for ; Mon, 3 Feb 2003 06:53:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.008C90C8@cherry.ease.lsoft.com>; Mon, 3 Feb 2003 6:57:33 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 598124 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 3 Feb 2003 06:57:32 -0500 Received: from 207.68.165.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Feb 2003 06:57:32 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 3 Feb 2003 03:57:32 -0800 Received: from 193.116.20.220 by sea2fd.sea2.hotmail.msn.com with HTTP; Mon, 03 Feb 2003 11:57:31 GMT X-Originating-IP: [193.116.20.220] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 03 Feb 2003 11:57:32.0184 (UTC) FILETIME=[6EE6F180:01C2CB7B] Message-ID: Date: Mon, 3 Feb 2003 11:57:31 +0000 Reply-To: Mailing List Sender: Mailing List From: gab jones Subject: Netflow analyzer To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, This are to people who have cisco netflow enabled on their network(ospf)routers. Il like to know what netflow analyzers people are currently using. I am currently looking into NetQos report analyzer. Is there anyone currently using this? If they are what do they think of the product? Anyone please just list what product or open source tool they are currently using to analyze netflow data and why? Suggestions on what netflow analyzer are good out there is it better to use open source e.g flow-tools, cflowd I know with the open source they have powerful command line utilities to examine flows thanks regards, gab _________________________________________________________________ MSN Messenger - fast, easy and FREE! http://messenger.msn.co.uk From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 3 06:54:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04035 for ; Mon, 3 Feb 2003 06:54:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.008C928D@cherry.ease.lsoft.com>; Mon, 3 Feb 2003 6:58:08 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 598076 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 3 Feb 2003 06:58:07 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Feb 2003 06:48:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03466; Mon, 3 Feb 2003 06:44:30 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200302031144.GAA03466@ietf.org> Date: Mon, 3 Feb 2003 06:44:30 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pillay-esnault-ospf-flooding-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPF Refresh and Flooding Reduction in Stable Topologies Author(s) : P. Pillay-Esnault Filename : draft-pillay-esnault-ospf-flooding-04.txt Pages : 6 Date : 2003-1-31 This document describes extension to the OSPF protocol to eliminate or reduce periodic flooding of Link State Advertisements in stable topologies. The current behavior of OSPF requires that all LSAs be refreshed every 30 minutes regardless of the stability of the network except for DoNotAge LSAs. This document proposes to generalize the use of DoNotAge LSAs so as to reduce protocol traffic in stable topologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pillay-esnault-ospf-flooding-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pillay-esnault-ospf-flooding-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-pillay-esnault-ospf-flooding-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-31143003.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pillay-esnault-ospf-flooding-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-pillay-esnault-ospf-flooding-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-31143003.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 3 06:58:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04086 for ; Mon, 3 Feb 2003 06:58:02 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.008C91B6@cherry.ease.lsoft.com>; Mon, 3 Feb 2003 7:01:37 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 598165 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 3 Feb 2003 07:01:37 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Feb 2003 07:01:37 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h13CLCQ28656 for ; Mon, 3 Feb 2003 17:51:12 +0530 Received: from alok ([203.124.140.100]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h13CL8t28649 for ; Mon, 3 Feb 2003 17:51:09 +0530 References: <200302031144.GAA03466@ietf.org> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <070301c2cb7c$4720a460$81c802c0@alok> Date: Mon, 3 Feb 2003 17:33:03 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: I-D ACTION:draft-pillay-esnault-ospf-flooding-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list going the BGP "withdrawn routes" way ?? ----- Original Message ----- From: To: Sent: Monday, February 03, 2003 5:14 PM Subject: I-D ACTION:draft-pillay-esnault-ospf-flooding-04.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. > > Title : OSPF Refresh and Flooding Reduction in Stable > Topologies > Author(s) : P. Pillay-Esnault > Filename : draft-pillay-esnault-ospf-flooding-04.txt > Pages : 6 > Date : 2003-1-31 > > This document describes extension to the OSPF protocol to eliminate > or reduce periodic flooding of Link State Advertisements in stable > topologies. > The current behavior of OSPF requires that all LSAs be refreshed > every 30 minutes regardless of the stability of the network except > for DoNotAge LSAs. This document proposes to generalize the use of > DoNotAge LSAs so as to reduce protocol traffic in stable topologies. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-pillay-esnault-ospf-flooding-04.tx t > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-pillay-esnault-ospf-flooding-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-pillay-esnault-ospf-flooding-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 3 07:20:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05500 for ; Mon, 3 Feb 2003 07:20:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.008C90FE@cherry.ease.lsoft.com>; Mon, 3 Feb 2003 7:23:40 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 598210 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 3 Feb 2003 07:23:40 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Feb 2003 07:23:40 -0500 Received: by XOVER with Internet Mail Service (5.5.2653.19) id <1C0LPPND>; Mon, 3 Feb 2003 07:23:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 3 Feb 2003 07:25:25 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: I-D ACTION:draft-pillay-esnault-ospf-flooding-04.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Alok, I am sorry, the question was a bit confusing to me. Can you elaborate what you meant there? Thanks, Vishwas -----Original Message----- From: alok [mailto:alok.dube@APARA.COM] Sent: Monday, February 03, 2003 5:33 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: I-D ACTION:draft-pillay-esnault-ospf-flooding-04.txt going the BGP "withdrawn routes" way ?? ----- Original Message ----- From: To: Sent: Monday, February 03, 2003 5:14 PM Subject: I-D ACTION:draft-pillay-esnault-ospf-flooding-04.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. > > Title : OSPF Refresh and Flooding Reduction in Stable > Topologies > Author(s) : P. Pillay-Esnault > Filename : draft-pillay-esnault-ospf-flooding-04.txt > Pages : 6 > Date : 2003-1-31 > > This document describes extension to the OSPF protocol to eliminate > or reduce periodic flooding of Link State Advertisements in stable > topologies. > The current behavior of OSPF requires that all LSAs be refreshed > every 30 minutes regardless of the stability of the network except > for DoNotAge LSAs. This document proposes to generalize the use of > DoNotAge LSAs so as to reduce protocol traffic in stable topologies. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-pillay-esnault-ospf-flooding-04.tx t > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-pillay-esnault-ospf-flooding-04.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-pillay-esnault-ospf-flooding-04.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 3 07:35:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05919 for ; Mon, 3 Feb 2003 07:35:09 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.008C926F@cherry.ease.lsoft.com>; Mon, 3 Feb 2003 7:38:44 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 598251 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 3 Feb 2003 07:38:44 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Feb 2003 07:38:44 -0500 Received: by XOVER with Internet Mail Service (5.5.2653.19) id <1C0LPPNS>; Mon, 3 Feb 2003 07:38:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 3 Feb 2003 07:40:42 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPF IGP Capabilities Draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee, The only reservation that I have with the mechanism for OSPF is that it cannot be used as a means to define what LSA's are exchanged/whether adjacencies are to be formed etc., because the LSA's are only exchanged after the decisions have already been made. So capabilities similar to the current Opaque capability/NSSA/Stub capability cannot be exchanged using the LSA's. However if we allow the LSA to be exchanged even before the decision to form adjacencies, we can get over the issue(we would require a change in protocol). It could also help in a case similar to the unplanned hitless restart case, where LSA's are exchanged even before Hello's are exchanged. I however agree that this method is better than allowing a whole lot of LSA's(like the Grace LSA for unplanned restart being used now), to be flooded before the neighbor state, that the protocol allows it. Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Sunday, February 02, 2003 3:56 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF IGP Capabilities Draft Abhay Roy wrote: > Acee, Hi Abhay, > > One of the questions raised was, why do we need to advertise these > capabilities? I am glad to see that, there is at least one useful > application (as in PCSD). Yes and I think there will be others in the future. > > I still have those reservations about the usefulness of many other > 'capabilities' this document describes. IMHO, if the receivers of > these capabilities are just going to display it in a 'show' > command, we should NOT specify them in this document. Since these are existing mechanisms we really can't make the receivers have any dependence on them. However, I'm not sure that is a reason not to allow the bits to be advertised with other router capabilities which are dependent on the IGP capabilities mechanism. > > Regards, > -Roy- > > On 01/30/03-0500 at 9:28pm, Acee Lindem writes: > > >>As many of you recall, we've discussed this draft at both >>the Yokohama and Atlanta OSPF WG meetings. I wasn't in Yokohama >>but apparently there were some present who voiced reservations >>with the draft. In Atlanta, there wasn't a lot of discussion (other >>than strong support from the authors ;^). We agreed to discuss this >>draft further on the OSPF list. >> >>Are there still people who have reservations with the draft? >> >>http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt >> >>[Speaking as a WG member] >> >>I think the draft is a natural mechanism for advertising new OSPF >>capabilities now that the LSA option bits have been exhausted. >>We've already extended OSPF to support traffic engineering (TE) >>information and this mechanism is slated to be used for propagating >>an OSPF router's ability to act as an MPLS TE path computation >>server (PCS). >> >>Thanks, >>-- >>Acee > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 3 17:27:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23817 for ; Mon, 3 Feb 2003 17:27:08 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.008CA282@cherry.ease.lsoft.com>; Mon, 3 Feb 2003 17:30:44 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 599776 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 3 Feb 2003 17:30:44 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Feb 2003 17:30:44 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA26533 for ; Mon, 3 Feb 2003 17:30:41 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA28707 for ; Mon, 3 Feb 2003 17:30:44 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Feb 2003 17:30:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55B8651E@vie-msgusr-01.dc.fore.com> Date: Mon, 3 Feb 2003 17:30:41 -0500 Reply-To: Mailing List Sender: Mailing List From: "Banerjee, Gargi" Subject: Ospf sham link in layer3 vpns To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi all: I had a question on creating ospf adjacency between PE routers over a sham link. In draft-rosen-vpns-ospf-bgp-mpls-05.txt, sham links are introduced to overcome the problem due to backdoor connectivity. The draft says that sham links can be created manually or by automatic configuration. Once created they are advertised by a PE in a type 1 lsa into the area. But, since the sham link is virtual, this type 1 lsa must actually be carried in a MP-iBGP update to reach the other PE- is this understanding correct ? Thanks Gargi From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 3 18:20:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25014 for ; Mon, 3 Feb 2003 18:20:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.008CA3F5@cherry.ease.lsoft.com>; Mon, 3 Feb 2003 18:24:05 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 599927 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 3 Feb 2003 18:24:05 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 3 Feb 2003 18:24:05 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 28DAC2FF85 for ; Mon, 3 Feb 2003 15:24:04 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <39469E08BD83D411A3D900204840EC55B8651E@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E3EF995.20900@redback.com> Date: Mon, 3 Feb 2003 18:21:57 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Ospf sham link in layer3 vpns To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Banerjee, Gargi wrote: > Hi all: > > I had a question on creating ospf adjacency between PE routers over a sham > link. > In draft-rosen-vpns-ospf-bgp-mpls-05.txt, sham links are introduced to > overcome the problem due to backdoor connectivity. > The draft says that sham links can be created manually or by automatic > configuration. > > Once created they are advertised by a PE in a type 1 lsa into the area. > But, since the sham link is virtual, this type 1 lsa must actually be > carried in a MP-iBGP update to reach the other PE- is this understanding > correct ? No. Once the sham link is up (internal signaling is implementation specific and unspecified), you can send any type packet between PE routers. The sham link traffic between the PE routers will be carried over the MPLS LSP (or other tunnel) in the provider's network. Note that draft-rosen-vpns-ospf-bgp-mpls-05.txt is under the auspices of the PPVPN WG. > > Thanks > Gargi > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 4 02:49:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13206 for ; Tue, 4 Feb 2003 02:49:37 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.008CB553@cherry.ease.lsoft.com>; Tue, 4 Feb 2003 2:53:11 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 601005 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Feb 2003 02:53:11 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Feb 2003 02:53:11 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h148CoQ24481 for ; Tue, 4 Feb 2003 13:42:50 +0530 Received: from alok ([203.124.140.100]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h148Ckt24474 for ; Tue, 4 Feb 2003 13:42:47 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <0d3101c2cc22$b8624ec0$81c802c0@alok> Date: Tue, 4 Feb 2003 13:24:44 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: some clarifications.... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi All, what is the default behaviour of OSPF process on a node A when a neighbour B and node A loose DD synhcronization? i mean , i understand the OSPF FSM, but at that point, does it 1. flush all routes which were given by the neighbour and then restart the whoel thing till the FULL state? 2. retain them till FULL state and flush it only when one enters the "FULL" state again? -rgds Alok From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 4 03:06:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13538 for ; Tue, 4 Feb 2003 03:06:23 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.008CB65D@cherry.ease.lsoft.com>; Tue, 4 Feb 2003 3:09:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 601035 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Feb 2003 03:09:59 -0500 Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Feb 2003 03:09:59 -0500 Received: from cisco.com (ppsenak--isdn-home4.cisco.com [10.49.2.221]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h1489wI20911 for ; Tue, 4 Feb 2003 09:09:58 +0100 (CET) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <39469E08BD83D411A3D900204840EC55B8651E@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E3F7556.2030309@cisco.com> Date: Tue, 4 Feb 2003 09:09:58 +0100 Reply-To: Mailing List Sender: Mailing List From: Peter Psenak Subject: Re: Ospf sham link in layer3 vpns To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Gargi, Banerjee, Gargi wrote: > Hi all: > > I had a question on creating ospf adjacency between PE routers over a sham > link. > In draft-rosen-vpns-ospf-bgp-mpls-05.txt, sham links are introduced to > overcome the problem due to backdoor connectivity. > The draft says that sham links can be created manually or by automatic > configuration. > > Once created they are advertised by a PE in a type 1 lsa into the area. > But, since the sham link is virtual, this type 1 lsa must actually be > carried in a MP-iBGP update to reach the other PE- is this understanding > correct ? two endpoints of the sham-link establish OSPF adjacency over the VPN backbone and LSAs are flooded over this adjacency. Peter > > Thanks > Gargi > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 4 05:33:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15416 for ; Tue, 4 Feb 2003 05:33:20 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.008CB7EE@cherry.ease.lsoft.com>; Tue, 4 Feb 2003 5:36:56 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 601460 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Feb 2003 05:36:56 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Feb 2003 05:36:56 -0500 Received: by XOVER with Internet Mail Service (5.5.2653.19) id <1HXT8ZGS>; Tue, 4 Feb 2003 05:36:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 4 Feb 2003 05:38:52 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: some clarifications.... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Alok, > what is the default behaviour of OSPF process on a node A when a neighbour B > and node A loose DD synhcronization? > i mean , i understand the OSPF FSM, but at that point, does it > 1. flush all routes which were given by the neighbour and then restart the > whoel thing till the FULL state? > > 2. retain them till FULL state and flush it only when one enters the "FULL" > state again? You cannot loose DB syncronization, unless you loose your adjacency(as flooding in OSPF is relaible). You may however want to check the draft http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-01.txt. We never flush routes in OSPF, we flush LSA's. When an adjacency is lost/new adjacency gained, a new router/network LSA is generated the SPF algorithm takes care of excluding/including the neighbor from the routing table calculation. Check Section 12, RFC2328. We do not the flush other routers LSA's. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 4 06:00:21 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15777 for ; Tue, 4 Feb 2003 06:00:21 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.008CB7D7@cherry.ease.lsoft.com>; Tue, 4 Feb 2003 6:03:58 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 601745 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Feb 2003 06:03:58 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Feb 2003 06:03:58 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h14BNcQ32707 for ; Tue, 4 Feb 2003 16:53:38 +0530 Received: from alok ([203.124.140.100]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h14BNZt32701 for ; Tue, 4 Feb 2003 16:53:35 +0530 References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <0f1601c2cc3d$5f601940$81c802c0@alok> Date: Tue, 4 Feb 2003 16:35:29 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: some clarifications.... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I think I should restate my question if the adjacencies are to be reestablished..... (well, i basically mean the FSM went back to Exstart state...) example..router-1 suddenly lost adjacency with router-2... we have to start allover from the init/exstart state...and we proceed up the FSM till we get to FULL. at the time of this "lost FULL adjacency", while the DD packets and LSRs and LSUs and LSacks are exchanged: do the OSPF routes already existing in the "RIB" of router 2 which were learnt from router 1 get flushed? what i mean is this: router-1 is responding to hellos, it exists...but the DB is not synchronised. what is the validity of the route on router-2 which was learnt from router-1 by router-2 prior to the loss of adjacency.. is the validity of that old "route" (learnt via some LSA) governed by the aging time of the previous LSA that router-1 originated? is this case the same as what happens when the LSrefresh timer expires? ----- Original Message ----- From: Manral, Vishwas To: Sent: Tuesday, February 04, 2003 4:08 PM Subject: Re: some clarifications.... > Hi Alok, > > > what is the default behaviour of OSPF process on a node A when a neighbour > B > > and node A loose DD synhcronization? > > > i mean , i understand the OSPF FSM, but at that point, does it > > 1. flush all routes which were given by the neighbour and then restart the > > whoel thing till the FULL state? > > > > 2. retain them till FULL state and flush it only when one enters the > "FULL" > > state again? > You cannot loose DB syncronization, unless you loose your adjacency(as > flooding in OSPF is relaible). You may however want to check the draft > http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-01.txt. > > We never flush routes in OSPF, we flush LSA's. When an adjacency is lost/new > adjacency gained, a new router/network LSA is generated the SPF algorithm > takes care of excluding/including the neighbor from the routing table > calculation. Check Section 12, RFC2328. We do not the flush other routers > LSA's. > > Thanks, > Vishwas > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 4 06:55:21 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17799 for ; Tue, 4 Feb 2003 06:55:20 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.008CB98F@cherry.ease.lsoft.com>; Tue, 4 Feb 2003 6:58:51 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 601849 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Feb 2003 06:58:50 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Feb 2003 06:48:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17307; Tue, 4 Feb 2003 06:45:11 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200302041145.GAA17307@ietf.org> Date: Tue, 4 Feb 2003 06:45:10 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-hitless-restart-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Graceful OSPF Restart Author(s) : J. Moy et al. Filename : draft-ietf-ospf-hitless-restart-06.txt Pages : 15 Date : 2003-2-3 This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called 'graceful restart' or 'non-stop forwarding'. A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-hitless-restart-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-hitless-restart-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-3125551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-hitless-restart-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-hitless-restart-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-3125551.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 4 07:07:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18834 for ; Tue, 4 Feb 2003 07:07:58 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.008CB844@cherry.ease.lsoft.com>; Tue, 4 Feb 2003 7:11:34 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 601903 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Feb 2003 07:11:33 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Feb 2003 07:11:33 -0500 Received: by XOVER with Internet Mail Service (5.5.2653.19) id <1HXT8ZL1>; Tue, 4 Feb 2003 07:11:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 4 Feb 2003 07:13:32 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: some clarifications.... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Alok, If after SPF a route gets deleted, it can also be removed from the RIB. Once the "adjacency loss" happens, a router changes its router/network LSA. This in turn causes a change in the routes. The LSA's sent from the "earlier adjacent router" are not considered, and hence the routes learnt do not appear in the SPF calculations. Check Section 12.4, RFC2328. Thanks, Vishwas -----Original Message----- From: alok [mailto:alok.dube@APARA.COM] Sent: Tuesday, February 04, 2003 4:35 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: some clarifications.... Hi, I think I should restate my question if the adjacencies are to be reestablished..... (well, i basically mean the FSM went back to Exstart state...) example..router-1 suddenly lost adjacency with router-2... we have to start allover from the init/exstart state...and we proceed up the FSM till we get to FULL. at the time of this "lost FULL adjacency", while the DD packets and LSRs and LSUs and LSacks are exchanged: do the OSPF routes already existing in the "RIB" of router 2 which were learnt from router 1 get flushed? what i mean is this: router-1 is responding to hellos, it exists...but the DB is not synchronised. what is the validity of the route on router-2 which was learnt from router-1 by router-2 prior to the loss of adjacency.. is the validity of that old "route" (learnt via some LSA) governed by the aging time of the previous LSA that router-1 originated? is this case the same as what happens when the LSrefresh timer expires? ----- Original Message ----- From: Manral, Vishwas To: Sent: Tuesday, February 04, 2003 4:08 PM Subject: Re: some clarifications.... > Hi Alok, > > > what is the default behaviour of OSPF process on a node A when a neighbour > B > > and node A loose DD synhcronization? > > > i mean , i understand the OSPF FSM, but at that point, does it > > 1. flush all routes which were given by the neighbour and then restart the > > whoel thing till the FULL state? > > > > 2. retain them till FULL state and flush it only when one enters the > "FULL" > > state again? > You cannot loose DB syncronization, unless you loose your adjacency(as > flooding in OSPF is relaible). You may however want to check the draft > http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-01.txt. > > We never flush routes in OSPF, we flush LSA's. When an adjacency is lost/new > adjacency gained, a new router/network LSA is generated the SPF algorithm > takes care of excluding/including the neighbor from the routing table > calculation. Check Section 12, RFC2328. We do not the flush other routers > LSA's. > > Thanks, > Vishwas > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 4 10:12:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24649 for ; Tue, 4 Feb 2003 10:12:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.008CBD6D@cherry.ease.lsoft.com>; Tue, 4 Feb 2003 10:16:18 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 602352 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Feb 2003 10:16:18 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Feb 2003 10:16:18 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id D31D41B4DC8 for ; Tue, 4 Feb 2003 07:16:16 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200302041145.GAA17307@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E3FD8B9.9080403@redback.com> Date: Tue, 4 Feb 2003 10:14:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-hitless-restart-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit The only change in this version is that "hitless restart" has been replaced by "graceful restart" (as per our discussion on common graceful restart terminology between protocols). Due to the respin on the draft, I'm extending the WG last call period to February 21st, 2003. Please forward your comments to the OSPF list before this time. Thanks, Acee Internet-Drafts@IETF.ORG wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. > > Title : Graceful OSPF Restart > Author(s) : J. Moy et al. > Filename : draft-ietf-ospf-hitless-restart-06.txt > Pages : 15 > Date : 2003-2-3 > > This memo documents an enhancement to the OSPF routing protocol, > whereby an OSPF router can stay on the forwarding path even as its > OSPF software is restarted. This is called 'graceful restart' or > 'non-stop forwarding'. A restarting router may not be capable of > adjusting its forwarding in a timely manner when the network > topology changes. In order to avoid the possible resulting routing > loops the procedure in this memo automatically reverts to a normal > OSPF restart when such a topology change is detected, or when one or > more of the restarting router's neighbors do not support the > enhancements in this memo. Proper network operation during a > graceful restart makes assumptions upon the operating environment > of the restarting router; these assumptions are also documented. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-06.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ospf-hitless-restart-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ospf-hitless-restart-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 4 15:52:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04051 for ; Tue, 4 Feb 2003 15:52:41 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.008CC5E5@cherry.ease.lsoft.com>; Tue, 4 Feb 2003 15:56:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 602980 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Feb 2003 15:56:17 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Feb 2003 15:56:17 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id A3B882F2FB1 for ; Tue, 4 Feb 2003 12:56:00 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E402856.8060208@redback.com> Date: Tue, 4 Feb 2003 15:53:42 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF IGP Capabilities Draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: > Hi Acee, > > The only reservation that I have with the mechanism for OSPF is that it > cannot be used as a means to define what LSA's are exchanged/whether > adjacencies are to be formed etc., because the LSA's are only exchanged > after the decisions have already been made. So capabilities similar to the > current Opaque capability/NSSA/Stub capability cannot be exchanged using the > LSA's. Hi Vishwas, It is true that it could not be used for determing what or what not to flood or be included in the DB exchange. A given capability could potentially be used to limit flooding over established adjacencies (though each application/capability would need to be addressed separately). > > However if we allow the LSA to be exchanged even before the decision to form > adjacencies, we can get over the issue(we would require a change in > protocol). It could also help in a case similar to the unplanned hitless > restart case, where LSA's are exchanged even before Hello's are exchanged. > > I however agree that this method is better than allowing a whole lot of > LSA's(like the Grace LSA for unplanned restart being used now), to be > flooded before the neighbor state, that the protocol allows it. > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Sunday, February 02, 2003 3:56 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPF IGP Capabilities Draft > > > Abhay Roy wrote: > >>Acee, > > > Hi Abhay, > > >>One of the questions raised was, why do we need to advertise these >>capabilities? I am glad to see that, there is at least one useful >>application (as in PCSD). > > > Yes and I think there will be others in the future. > > >>I still have those reservations about the usefulness of many other >>'capabilities' this document describes. IMHO, if the receivers of >>these capabilities are just going to display it in a 'show' >>command, we should NOT specify them in this document. > > > Since these are existing mechanisms we really can't make the > receivers have any dependence on them. However, I'm not sure > that is a reason not to allow the bits to be advertised with > other router capabilities which are dependent on the > IGP capabilities mechanism. > > >>Regards, >>-Roy- >> >>On 01/30/03-0500 at 9:28pm, Acee Lindem writes: >> >> >> >>>As many of you recall, we've discussed this draft at both >>>the Yokohama and Atlanta OSPF WG meetings. I wasn't in Yokohama >>>but apparently there were some present who voiced reservations >>>with the draft. In Atlanta, there wasn't a lot of discussion (other >>>than strong support from the authors ;^). We agreed to discuss this >>>draft further on the OSPF list. >>> >>>Are there still people who have reservations with the draft? >>> >>>http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt >>> >>>[Speaking as a WG member] >>> >>>I think the draft is a natural mechanism for advertising new OSPF >>>capabilities now that the LSA option bits have been exhausted. >>>We've already extended OSPF to support traffic engineering (TE) >>>information and this mechanism is slated to be used for propagating >>>an OSPF router's ability to act as an MPLS TE path computation >>>server (PCS). >>> >>>Thanks, >>>-- >>>Acee >> > -- > Acee > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 4 23:21:18 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15018 for ; Tue, 4 Feb 2003 23:21:18 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.008CD6F4@cherry.ease.lsoft.com>; Tue, 4 Feb 2003 23:24:55 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 603730 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Feb 2003 23:24:54 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 4 Feb 2003 23:24:54 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 0331F413840 for ; Tue, 4 Feb 2003 20:24:52 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E409185.304@redback.com> Date: Tue, 4 Feb 2003 23:22:29 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: The OSPF Not-So-Stubby Area (NSSA) Option To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit For those of you who are not on the IETF announce list, RFC 3101 has been published. Many thanks to Pat Murphy for all the hard work on this Standards Track document. http://www.ietf.org/rfc/rfc3101.txt -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 5 06:54:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19732 for ; Wed, 5 Feb 2003 06:54:48 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.008CDE7C@cherry.ease.lsoft.com>; Wed, 5 Feb 2003 6:58:25 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 604635 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 5 Feb 2003 06:58:25 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Feb 2003 06:48:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19066; Wed, 5 Feb 2003 06:44:45 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200302051144.GAA19066@ietf.org> Date: Wed, 5 Feb 2003 06:44:45 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-dc-06.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 : Detecting Inactive Neighbors over OSPF Demand Circuits Author(s) : S. Rao, A. Zinin, A. Roy Filename : draft-ietf-ospf-dc-06.txt Pages : 5 Date : 2003-2-4 OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits is optimized in RFC1793 to minimize the amount of overhead traffic. A part of OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect a OSPF-inactive neighbor over such a link. This memo addresses the above problem by the neighbor probing mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-dc-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-dc-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-4134040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-dc-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-dc-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-4134040.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@DISCUSS.MICROSOFT.COM Wed Feb 5 11:15:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29924 for ; Wed, 5 Feb 2003 11:15:09 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.008CE533@cherry.ease.lsoft.com>; Wed, 5 Feb 2003 11:18:46 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 605259 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 5 Feb 2003 11:18:46 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Feb 2003 11:18:46 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01KS2LVZW2PY8WXBGI@omega7.wr.usgs.gov> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 05 Feb 2003 08:18:42 -0700 (PDT) X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM X-VMS-Cc: PMURPHY,fenner@research.att.com,zinin@psg.com MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01KS2LVZW3O88WXBGI@omega7.wr.usgs.gov> Date: Wed, 5 Feb 2003 08:18:42 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: The OSPF Not-So-Stubby Area (NSSA) Option Comments: cc: FENNER@RESEARCH.ATT.COM, ZININ@PSG.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Thank you Acee. I have been intending to send a posting about this new NSSA RFC 3101, but I have been very busy lately. The RFC Editorial process was a real education for me. While the technical content of RFC 3101 has not changed from the original NSSA draft, the RFC Editorial process has made the document read better and clarified some of its subtleties. I would like to thank Acee, Alex, and, in particular, Bill Fenner for sticking with me through this process. Bill reviewed and approved the original draft and later was particular helpful in mediating matters with the RFC Editor. His difference tool made it very easy for me to locate changes the RFC Editors made. I would also like to thank John, who patiently stuck with me over the years through the NSSA draft's evolution and whose leadership helped make this document what it is today. The energy that our WG chairs and ADs put into the IETF standards process deserves recognition. Thank you! Your efforts are greatly appreciated. Pat From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 5 19:23:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16423 for ; Wed, 5 Feb 2003 19:23:51 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.008CF7C8@cherry.ease.lsoft.com>; Wed, 5 Feb 2003 19:27:28 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 606571 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 5 Feb 2003 19:27:28 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 5 Feb 2003 19:27:28 -0500 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18gZt1-000Pnc-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 05 Feb 2003 16:27:27 -0800 X-Mailer: The Bat! (v1.62i) Personal X-Priority: 3 (Normal) References: <200302051144.GAA19066@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <33202862140.20030205162700@psg.com> Date: Wed, 5 Feb 2003 16:27:00 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: I-D ACTION:draft-ietf-ospf-dc-06.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200302051144.GAA19066@ietf.org> Precedence: list Content-Transfer-Encoding: 7bit The diff: o Added the Security Considerations section o Added Appendix A. Configurable Parameters o Specified that refs are normative. Should be ready to fly. -- Alex Wednesday, February 5, 2003, 3:44:45 AM, Internet-Drafts@IETF.ORG wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. > Title : Detecting Inactive Neighbors over OSPF Demand Circuits > Author(s) : S. Rao, A. Zinin, A. Roy > Filename : draft-ietf-ospf-dc-06.txt > Pages : 5 > Date : 2003-2-4 > OSPF is a link-state intra-domain routing protocol used in IP > networks. OSPF behavior over demand circuits is optimized in RFC1793 > to minimize the amount of overhead traffic. A part of OSPF demand > circuit extensions is the Hello suppression mechanism. This technique > allows a demand circuit to go down when no interesting traffic is > going through the link. However, it also introduces a problem, where > it becomes impossible to detect a OSPF-inactive neighbor over such a > link. This memo addresses the above problem by the neighbor probing > mechanism. > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-dc-06.txt > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ospf-dc-06.txt". > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > Internet-Drafts can also be obtained by e-mail. > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ospf-dc-06.txt". > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 6 02:42:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07033 for ; Thu, 6 Feb 2003 02:42:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.008D029A@cherry.ease.lsoft.com>; Thu, 6 Feb 2003 2:46:08 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 607411 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 6 Feb 2003 02:46:08 -0500 Received: from 144.254.74.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 6 Feb 2003 02:46:07 -0500 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h167iW9Z014898; Thu, 6 Feb 2003 08:44:32 +0100 (MET) Received: from JVASSEUR-W2K.cisco.com ([10.49.250.149]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA28370; Thu, 6 Feb 2003 08:46:03 +0100 (MET) X-Sender: jvasseur@paris.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 References: <3E39DF3F.5080201@redback.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_84628729==_.ALT" Message-ID: <4.3.2.7.2.20030206024057.039e82c0@paris.cisco.com> Date: Thu, 6 Feb 2003 02:46:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Jean Philippe Vasseur Subject: Re: OSPF IGP Capabilities Draft Comments: To: akr@cisco.com Comments: cc: acee Lindem To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E3C4982.1000907@redback.com> Precedence: list --=====================_84628729==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Abbay, See in line, At 17:26 01/02/2003 -0500, Acee Lindem wrote: >Abhay Roy wrote: >>Acee, > >Hi Abhay, > >> >>One of the questions raised was, why do we need to advertise these >>capabilities? I am glad to see that, there is at least one useful >>application (as in PCSD). > >Yes and I think there will be others in the future. Right, just to mention another one (also related to TE): the mesh-group ID, used to determine to set of LSRs belonging to a common TE mesh. See http://www.ietf.org/internet-drafts/draft-vasseur-mpls-ospf-te-cap-00.txt 3.2 Mesh-group TLV As of today, there are different approaches in deploying MPLS Traffic Engineering: (1) the systematic approach consisting of setting up a full mesh of tunnels between P or PE routers, with the objective of optimizing the bandwidth usage in the core, (2) the "by exception" approach where a set TE LSPs are set up on hot spots to alleviate a congestion resulting in an unexpected traffic growth in some part of the network. The systematic approach requires setting up a full mesh of TE LSPs, which implies the configuration of a large number of tunnels on every Hean-End LSR (P or PE LSR). A full TE mesh of n LSRs requires the set up of O(n^2) TE LSPs. Furthermore, the addition of any new LSR in the mesh implies to configure n TE LSPs on the new LSR and to add a new TE LSP on every LSR ending to this new LSR, which gives a total of 2*n TE LSPs. This is not only time consuming but also not a low risk operation for Service Providers. So a more automatic way of setting up full mesh of TE LSP might be desirable. This requires to define a new TE capability TLV (called the Mesh-group TLV) such that an LSR can announce its desire to join a particular TE LSP mesh, identified by a mesh-group number. I'll try to publish a informational draft detailing the applicability. >>I still have those reservations about the usefulness of many other >>'capabilities' this document describes. IMHO, if the receivers of >>these capabilities are just going to display it in a 'show' >>command, we should NOT specify them in this document. > >Since these are existing mechanisms we really can't make the >receivers have any dependence on them. However, I'm not sure >that is a reason not to allow the bits to be advertised with >other router capabilities which are dependent on the >IGP capabilities mechanism. Agree. JP. >>Regards, >>-Roy- >> >>On 01/30/03-0500 at 9:28pm, Acee Lindem writes: >> >> >>>As many of you recall, we've discussed this draft at both >>>the Yokohama and Atlanta OSPF WG meetings. I wasn't in Yokohama >>>but apparently there were some present who voiced reservations >>>with the draft. In Atlanta, there wasn't a lot of discussion (other >>>than strong support from the authors ;^). We agreed to discuss this >>>draft further on the OSPF list. >>> >>>Are there still people who have reservations with the draft? >>> >>>http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt >>> >>>[Speaking as a WG member] >>> >>>I think the draft is a natural mechanism for advertising new OSPF >>>capabilities now that the LSA option bits have been exhausted. >>>We've already extended OSPF to support traffic engineering (TE) >>>information and this mechanism is slated to be used for propagating >>>an OSPF router's ability to act as an MPLS TE path computation >>>server (PCS). >>> >>>Thanks, >>>-- >>>Acee >> > > >-- >Acee --=====================_84628729==_.ALT Content-Type: text/html; charset="us-ascii" Hi Abbay,

See in line,

At 17:26 01/02/2003 -0500, Acee Lindem wrote:
Abhay Roy wrote:
Acee,

Hi Abhay,


One of the questions raised was, why do we need to advertise these
capabilities? I am glad to see that, there is at least one useful
application (as in PCSD).

Yes and I think there will be others in the future.

Right, just to mention another one (also related to TE): the mesh-group ID, used to determine to set of LSRs belonging to a common TE mesh.

See http://www.ietf.org/internet-drafts/draft-vasseur-mpls-ospf-te-cap-00.txt

3.2 Mesh-group TLV
   
   As of today, there are different approaches in deploying MPLS
   Traffic Engineering:
        (1) the systematic approach consisting of setting up a full
        mesh of tunnels between P or PE routers, with the objective of
        optimizing the bandwidth usage in the core,
        (2) the "by exception" approach where a set TE LSPs are set up
        on hot spots to alleviate a congestion resulting in an
        unexpected traffic growth in some part of the network. 
   
   The systematic approach requires setting up a full mesh of TE LSPs,
   which implies the configuration of a large number of tunnels on
   every Hean-End LSR (P or PE LSR). A full TE mesh of n LSRs requires
   the set up of O(n^2) TE LSPs. Furthermore, the addition of any new
   LSR in the mesh implies to configure n TE LSPs on the new LSR and to
   add a new TE LSP on every LSR ending to this new LSR, which gives a
   total of 2*n TE LSPs. This is not only time consuming but also not a
   low risk operation for Service Providers. So a more automatic way of
   setting up full mesh of TE LSP might be desirable. This requires to
   define a new TE capability TLV (called the Mesh-group TLV) such that
   an LSR can announce its desire to join a particular TE LSP mesh,
   identified by a mesh-group number.
 
I'll try to publish a informational draft detailing the applicability.


I still have those reservations about the usefulness of many other
'capabilities' this document describes. IMHO, if the receivers of
these capabilities are just going to display it in a 'show'
command, we should NOT specify them in this document.

Since these are existing mechanisms we really can't make the
receivers have any dependence on them. However, I'm not sure
that is a reason not to allow the bits to be advertised with
other router capabilities which are dependent on the
IGP capabilities mechanism.

Agree.

JP.


Regards,
-Roy-

On 01/30/03-0500 at 9:28pm, Acee Lindem writes:


As many of you recall, we've discussed this draft at both
the Yokohama and Atlanta OSPF WG meetings. I wasn't in Yokohama
but apparently there were some present who voiced reservations
with the draft. In Atlanta, there wasn't a lot of discussion (other
than strong support from the authors ;^). We agreed to discuss this
draft further on the OSPF list.

Are there still people who have reservations with the draft?

http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt

[Speaking as a WG member]

I think the draft is a natural mechanism for advertising new OSPF
capabilities now that the LSA option bits have been exhausted.
We've already extended OSPF to support traffic engineering (TE)
information and this mechanism is slated to be used for propagating
an OSPF router's ability to act as an MPLS TE path computation
server (PCS).

Thanks,
--
Acee



--
Acee
--=====================_84628729==_.ALT-- From owner-ospf@DISCUSS.MICROSOFT.COM Sat Feb 8 06:31:00 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18708 for ; Sat, 8 Feb 2003 06:31:00 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.008D5EA9@cherry.ease.lsoft.com>; Sat, 8 Feb 2003 6:34:37 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 614566 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 8 Feb 2003 06:34:37 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 8 Feb 2003 06:34:37 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 671CD4EC465 for ; Sat, 8 Feb 2003 03:34:36 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E44EA92.7090905@redback.com> Date: Sat, 8 Feb 2003 06:31:30 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF convergence drafts under consideration in the BMWG WG To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit The Benchmarking Methodology WG (BMWG) is currently reviewing I-Ds that address the benchmarking of OSPF convergence in a lab environment. Interested parties will find the related Internet-Drafts here: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-term-02.txt http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-intraarea-03.txt http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-applicability-01.txt Discussion can be found on the BMWG mailing list and its archive: http://www.ietf.org/mail-archive/working-groups/bmwg/current/maillist.html Your commentary posted to bmwg@ietf.org is welcome. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sat Feb 8 06:33:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18775 for ; Sat, 8 Feb 2003 06:33:01 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.008D5EC4@cherry.ease.lsoft.com>; Sat, 8 Feb 2003 6:36:40 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 614593 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 8 Feb 2003 06:36:40 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 8 Feb 2003 06:36:40 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 0670F4EC466 for ; Sat, 8 Feb 2003 03:36:39 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3E44EA92.7090905@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E44EB0D.2020803@redback.com> Date: Sat, 8 Feb 2003 06:33:33 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF convergence drafts under consideration in the BMWG WG To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Actually I checked the BMWG archives and a WG last call has been issued. The last call period ends February 28th, 2003. Acee Lindem wrote: > The Benchmarking Methodology WG (BMWG) is currently reviewing I-Ds that > address the benchmarking of OSPF convergence in a lab environment. > > Interested parties will find the related Internet-Drafts here: > > http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-term-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-intraarea-03.txt > > http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-applicability-01.txt > > > Discussion can be found on the BMWG mailing list and its archive: > http://www.ietf.org/mail-archive/working-groups/bmwg/current/maillist.html > > Your commentary posted to bmwg@ietf.org is welcome. > > -- > Acee > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sun Feb 9 04:51:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24195 for ; Sun, 9 Feb 2003 04:51:14 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.008D79A5@cherry.ease.lsoft.com>; 9 Feb 2003 4:54:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 616414 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 9 Feb 2003 04:54:49 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Feb 2003 04:54:49 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h19AEqQ18387 for ; Sun, 9 Feb 2003 15:44:52 +0530 Received: from alok (PPP-219-65-135-17.bng.vsnl.net.in [219.65.135.17]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h19AEot18381 for ; Sun, 9 Feb 2003 15:44:50 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <01c901c2d021$8fffcf40$439541db@alok> Date: Sun, 9 Feb 2003 15:26:41 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: TE in OSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list hi, I would like to know if the draft draft-pillay-esnault-ospf-flooding-04.txt is also applicable to OSPF-TE LSAs? (I assume not..) -thanks and rgds Alok From owner-ospf@DISCUSS.MICROSOFT.COM Sun Feb 9 15:24:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05733 for ; Sun, 9 Feb 2003 15:24:48 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.008D840B@cherry.ease.lsoft.com>; 9 Feb 2003 15:28:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 617671 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 9 Feb 2003 15:28:27 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 9 Feb 2003 15:28:26 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id CFC2F170A4F for ; Sun, 9 Feb 2003 12:28:25 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <01c901c2d021$8fffcf40$439541db@alok> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E46B91E.6070808@redback.com> Date: Sun, 9 Feb 2003 15:25:02 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: TE in OSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit alok wrote: > hi, > > I would like to know if the draft draft-pillay-esnault-ospf-flooding-04.txt > is also applicable to OSPF-TE LSAs? (I assume not..) Hi Alok, It is applicable. Note that the draft only suppresses the periodic refresh of LSAs (not reorigination due to actual changes). > > -thanks and rgds > Alok > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 10 01:38:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16847 for ; Mon, 10 Feb 2003 01:38:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.008D952D@cherry.ease.lsoft.com>; Mon, 10 Feb 2003 1:41:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 618609 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Feb 2003 01:41:42 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Feb 2003 01:41:42 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1A71nQ04882 for ; Mon, 10 Feb 2003 12:31:49 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1A71gt04874 for ; Mon, 10 Feb 2003 12:31:44 +0530 References: <01c901c2d021$8fffcf40$439541db@alok> <3E46B91E.6070808@redback.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <014301c2d0cf$be1a5680$81c802c0@alok> Date: Mon, 10 Feb 2003 12:13:07 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: TE in OSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list yup got the idea thanks... ----- Original Message ----- From: Acee Lindem To: Sent: Monday, February 10, 2003 1:55 AM Subject: Re: TE in OSPF > alok wrote: > > hi, > > > > I would like to know if the draft draft-pillay-esnault-ospf-flooding-04.txt > > is also applicable to OSPF-TE LSAs? (I assume not..) > > Hi Alok, > > > It is applicable. Note that the draft only suppresses the periodic refresh > of LSAs (not reorigination due to actual changes). > > > > > -thanks and rgds > > Alok > > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 10 07:08:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05924 for ; Mon, 10 Feb 2003 07:08:31 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.008D95EA@cherry.ease.lsoft.com>; Mon, 10 Feb 2003 7:12:12 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 619364 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Feb 2003 07:12:12 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Feb 2003 07:12:12 -0500 Received: by XOVER with Internet Mail Service (5.5.2653.19) id <1RXVNST4>; Mon, 10 Feb 2003 07:12:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 10 Feb 2003 07:14:09 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPF convergence drafts under consideration in the BMWG WG To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Similar measurement methodology has been used and results have been captured in the paper: - Experience in Black-Box OSPF measurement - Aman Shaikh, Albert Greenberg The paper is located at http://www.research.att.com/~albert/papers/sigcom-imw01/mes-ws01-paper.pdf and the presentation for the same is at http://www.research.att.com/~albert/papers/sigcom-imw01/mes-ws-talk.ppt Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Saturday, February 08, 2003 5:04 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF convergence drafts under consideration in the BMWG WG Actually I checked the BMWG archives and a WG last call has been issued. The last call period ends February 28th, 2003. Acee Lindem wrote: > The Benchmarking Methodology WG (BMWG) is currently reviewing I-Ds that > address the benchmarking of OSPF convergence in a lab environment. > > Interested parties will find the related Internet-Drafts here: > > http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-term-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-intraarea-03.tx t > > http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-applicability-0 1.txt > > > Discussion can be found on the BMWG mailing list and its archive: > http://www.ietf.org/mail-archive/working-groups/bmwg/current/maillist.html > > Your commentary posted to bmwg@ietf.org is welcome. > > -- > Acee > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 10 13:29:14 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19543 for ; Mon, 10 Feb 2003 13:29:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.008DA4D1@cherry.ease.lsoft.com>; Mon, 10 Feb 2003 13:32:54 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 620263 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Feb 2003 13:32:54 -0500 Received: from 212.113.174.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Feb 2003 13:32:54 -0500 Received: from oemcomputer ([213.22.198.229]) by smtp.netcabo.pt with Microsoft SMTPSVC(5.0.2195.5329); Mon, 10 Feb 2003 18:32:07 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C2D132.CC0FE940" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-OriginalArrivalTime: 10 Feb 2003 18:32:07.0250 (UTC) FILETIME=[B73B9320:01C2D132] Message-ID: Date: Mon, 10 Feb 2003 18:32:42 -0000 Reply-To: Mailing List Sender: Mailing List From: "Patricia macedo (NC)" Subject: unsubscribe To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <4.3.2.7.2.20030206024057.039e82c0@paris.cisco.com> Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C2D132.CC0FE940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Jean Philippe Vasseur Sent: quinta-feira, 6 de Fevereiro de 2003 7:46 To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF IGP Capabilities Draft Hi Abbay, See in line, At 17:26 01/02/2003 -0500, Acee Lindem wrote: Abhay Roy wrote: Acee, Hi Abhay, One of the questions raised was, why do we need to advertise these capabilities? I am glad to see that, there is at least one useful application (as in PCSD). Yes and I think there will be others in the future. Right, just to mention another one (also related to TE): the mesh-group ID, used to determine to set of LSRs belonging to a common TE mesh. See http://www.ietf.org/internet-drafts/draft-vasseur-mpls-ospf-te-cap-00.txt 3.2 Mesh-group TLV As of today, there are different approaches in deploying MPLS Traffic Engineering: (1) the systematic approach consisting of setting up a full mesh of tunnels between P or PE routers, with the objective of optimizing the bandwidth usage in the core, (2) the "by exception" approach where a set TE LSPs are set up on hot spots to alleviate a congestion resulting in an unexpected traffic growth in some part of the network. The systematic approach requires setting up a full mesh of TE LSPs, which implies the configuration of a large number of tunnels on every Hean-End LSR (P or PE LSR). A full TE mesh of n LSRs requires the set up of O(n^2) TE LSPs. Furthermore, the addition of any new LSR in the mesh implies to configure n TE LSPs on the new LSR and to add a new TE LSP on every LSR ending to this new LSR, which gives a total of 2*n TE LSPs. This is not only time consuming but also not a low risk operation for Service Providers. So a more automatic way of setting up full mesh of TE LSP might be desirable. This requires to define a new TE capability TLV (called the Mesh-group TLV) such that an LSR can announce its desire to join a particular TE LSP mesh, identified by a mesh-group number. I'll try to publish a informational draft detailing the applicability. I still have those reservations about the usefulness of many other 'capabilities' this document describes. IMHO, if the receivers of these capabilities are just going to display it in a 'show' command, we should NOT specify them in this document. Since these are existing mechanisms we really can't make the receivers have any dependence on them. However, I'm not sure that is a reason not to allow the bits to be advertised with other router capabilities which are dependent on the IGP capabilities mechanism. Agree. JP. Regards, -Roy- On 01/30/03-0500 at 9:28pm, Acee Lindem writes: As many of you recall, we've discussed this draft at both the Yokohama and Atlanta OSPF WG meetings. I wasn't in Yokohama but apparently there were some present who voiced reservations with the draft. In Atlanta, there wasn't a lot of discussion (other than strong support from the authors ;^). We agreed to discuss this draft further on the OSPF list. Are there still people who have reservations with the draft? http://www.ietf.org/internet-drafts/draft-raggarwa-igp-cap-01.txt [Speaking as a WG member] I think the draft is a natural mechanism for advertising new OSPF capabilities now that the LSA option bits have been exhausted. We've already extended OSPF to support traffic engineering (TE) information and this mechanism is slated to be used for propagating an OSPF router's ability to act as an MPLS TE path computation server (PCS). Thanks, -- Acee -- Acee ------=_NextPart_000_000E_01C2D132.CC0FE940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
-----Original Message-----
From: Mailing List=20 [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Jean Philippe=20 Vasseur
Sent: quinta-feira, 6 de Fevereiro de 2003=20 7:46
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: = OSPF IGP=20 Capabilities Draft

Hi Abbay,

See in = line,

At=20 17:26 01/02/2003 -0500, Acee Lindem wrote:
Abhay Roy wrote:
Acee,

Hi = Abhay,


One of the questions raised = was, why=20 do we need to advertise these
capabilities? I am glad to see = that,=20 there is at least one useful
application (as in=20 PCSD).

Yes and I think there will be others in the=20 future.

Right, just to mention another one (also = related=20 to TE): the mesh-group ID, used to determine to set of LSRs belonging = to a=20 common TE mesh.

See http://www.ietf.org/internet-drafts/draft-vasseur-mpls= -ospf-te-cap-00.txt

3.2 Mesh-group TLV =
   =20
   As of today, there are different approaches in = deploying MPLS=20
   Traffic Engineering:=20
        (1) the systematic = approach=20 consisting of setting up a full =
       =20 mesh of tunnels between P or PE routers, with the objective of=20
        optimizing the = bandwidth usage=20 in the core,
        (2) the = "by=20 exception" approach where a set TE LSPs are set up=20
        on hot spots to = alleviate a=20 congestion resulting in an =
       =20 unexpected traffic growth in some part of the network. =20
   
   The systematic approach = requires=20 setting up a full mesh of TE LSPs,
   which implies the=20 configuration of a large number of tunnels on
   every = Hean-End=20 LSR (P or PE LSR). A full TE mesh of n LSRs requires
   = the set=20 up of O(n^2) TE LSPs. Furthermore, the addition of any new =
  =20 LSR in the mesh implies to configure n TE LSPs on the new LSR and to=20
   add a new TE LSP on every LSR ending to this new LSR, = which=20 gives a
   total of 2*n TE LSPs. This is not only time = consuming=20 but also not a
   low risk operation for Service = Providers. So a=20 more automatic way of
   setting up full mesh of TE LSP = might be=20 desirable. This requires to
   define a new TE = capability TLV=20 (called the Mesh-group TLV) such that
   an LSR can = announce its=20 desire to join a particular TE LSP mesh,
   identified = by a=20 mesh-group number.
 
I'll try to publish a = informational draft=20 detailing the applicability.


I still have those reservations = about the=20 usefulness of many other
'capabilities' this document = describes. IMHO,=20 if the receivers of
these capabilities are just going to = display it in=20 a 'show'
command, we should NOT specify them in this=20 document.

Since these are existing mechanisms we = really=20 can't make the
receivers have any dependence on them. However, = I'm not=20 sure
that is a reason not to allow the bits to be advertised=20 with
other router capabilities which are dependent on the
IGP=20 capabilities = mechanism.

Agree.

JP.


Regards,
-Roy-

On = 01/30/03-0500=20 at 9:28pm, Acee Lindem writes:


As many of you recall, we've = discussed=20 this draft at both
the Yokohama and Atlanta OSPF WG meetings. = I=20 wasn't in Yokohama
but apparently there were some present who = voiced=20 reservations
with the draft. In Atlanta, there wasn't a lot = of=20 discussion (other
than strong support from the authors ;^). = We agreed=20 to discuss this
draft further on the OSPF list.

Are = there=20 still people who have reservations with the draft?

http://www.ietf.org/internet-drafts/draft-raggarwa-igp= -cap-01.txt

[Speaking=20 as a WG member]

I think the draft is a natural mechanism = for=20 advertising new OSPF
capabilities now that the LSA option = bits have=20 been exhausted.
We've already extended OSPF to support = traffic=20 engineering (TE)
information and this mechanism is slated to = be used=20 for propagating
an OSPF router's ability to act as an MPLS TE = path=20 computation
server=20 = (PCS).

Thanks,
--
Acee


=
--
Acee
------=_NextPart_000_000E_01C2D132.CC0FE940-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 10 14:57:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22897 for ; Mon, 10 Feb 2003 14:57:29 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.008DAB11@cherry.ease.lsoft.com>; Mon, 10 Feb 2003 15:01:09 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 620628 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Feb 2003 15:01:09 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Feb 2003 15:01:09 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16384 for ; Mon, 10 Feb 2003 15:01:06 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA02818 for ; Mon, 10 Feb 2003 15:01:08 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Feb 2003 15:01:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55E92674@vie-msgusr-01.dc.fore.com> Date: Mon, 10 Feb 2003 15:01:00 -0500 Reply-To: Mailing List Sender: Mailing List From: "Banerjee, Gargi" Subject: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi all: I would like to know the status of the working group draft-ietf-ospf-mib-update-05.txt. The current draft shows an expiry date of May 2001. Is there any plan to update the draft ? Thanks Gargi From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 10 15:01:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23079 for ; Mon, 10 Feb 2003 15:01:01 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.008DA93F@cherry.ease.lsoft.com>; Mon, 10 Feb 2003 15:04:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 620651 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Feb 2003 15:04:42 -0500 Received: from 192.11.222.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Feb 2003 15:04:42 -0500 Received: from ma8117exch001u.wins.lucent.com (h152-148-89-175.lucent.com [152.148.89.175]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h1AK4eg17661 for ; Mon, 10 Feb 2003 15:04:40 -0500 (EST) Received: by ma8117exch001u.inse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Feb 2003 15:04:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 10 Feb 2003 15:04:39 -0500 Reply-To: Mailing List Sender: Mailing List From: "Joyal, Daniel R (Daniel)" Subject: Re: OSPFv2 MIB draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Yes. An update is in the works. -Dan > -----Original Message----- > From: Banerjee, Gargi [mailto:Gargi.Banerjee@MARCONI.COM] > Sent: Monday, February 10, 2003 3:01 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: OSPFv2 MIB draft > > > Hi all: > I would like to know the status of the working group > draft-ietf-ospf-mib-update-05.txt. The current draft shows an > expiry date of > May 2001. > Is there any plan to update the draft ? > > Thanks > Gargi > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 10 20:18:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03484 for ; Mon, 10 Feb 2003 20:18:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.008DBB14@cherry.ease.lsoft.com>; Mon, 10 Feb 2003 20:22:05 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 621561 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10 Feb 2003 20:22:05 -0500 Received: from 134.56.3.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 10 Feb 2003 20:12:05 -0500 Received: from mx01-int.net.com (mx01-int.net.com [134.56.112.13]) by mx01.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id h1B1DLF29106 for ; Mon, 10 Feb 2003 17:13:21 -0800 (PST) Received: from west-mail.net.com (west-mail.net.com [134.56.112.40]) by mx01-int.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id h1B1DLl15643 for ; Mon, 10 Feb 2003 17:13:21 -0800 (PST) Received: from net.com ([134.56.24.58]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA7059 for ; Mon, 10 Feb 2003 17:12:30 -0800 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: <3E484DFD.6DE49E1E@net.com> Date: Mon, 10 Feb 2003 17:12:29 -0800 Reply-To: Mailing List Sender: Mailing List From: Shankar Agarwal Organization: N.E.T. http://www.net.com Subject: About Table 2 Page 23 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, I was trying to figure out why the Routing Table for RT6 has route to Ia as 12 and next hop as RT10 when it is the ip address of its own interface. I am at a loss right now. If someone can help me in solving this mystery i would greatly appreciate it. Thanks Shankar From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 11 03:27:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23403 for ; Tue, 11 Feb 2003 03:27:23 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.008DCA05@cherry.ease.lsoft.com>; Tue, 11 Feb 2003 3:31:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 622281 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Feb 2003 03:31:03 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Feb 2003 03:31:03 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1B8pGQ18177 for ; Tue, 11 Feb 2003 14:21:16 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1B8pEt18171 for ; Tue, 11 Feb 2003 14:21:15 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <020f01c2d1a8$3d553360$81c802c0@alok> Date: Tue, 11 Feb 2003 14:03:06 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: OSPF---out of band To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, As far as I understand, the OSPF protocol always sends LSA on "the links which it advertises and forms adjacencies" there is something referred to as passive, but then one cant form adjacencies over passive links.............. assuming there are 2 links between Node A and Node B one is 64kbps other is 100Mbps... i need to use the 64kbps link to establish OSPF adjacencies and pass the LSA information etc over it. however i want the traffic to use the 100Mbps link... so essentially, i want ospf to do the following: for this 2 node network OSPF should have something like for destination on node B , next-hop is via 100Mbps between node A and B but, the interfaces themseleves are "passive" interfaces.... is there anyway this can be done? in BGP this would be "destn network x.y.z.w" next-hop interface ip of B which is directly connected... so one could run BGP out-of-band over the 64Kbps but still put a next hop to the other interface..... so BGP doesnt even run on the 100Mbps link, it runs on the 64Kbps link.....(signalling is segregated) but the forwarding is still over 100Mbps.... how does one do this in OSPF? another this which is confusing is that if the interface doesnt have an "IP"...(unnumbered P2P) the RFC 2328 says: If the neighboring router is fully adjacent, add a Type 1 link (point-to-point). The Link ID should be set to the Router ID of the neighboring router. For numbered point-to-point networks, the Link Data should specify the IP interface address. For unnumbered point-to-point networks, the Link Data field should specify the interface's MIB-II [Ref8] ifIndex value. The cost should be set to the output cost of the point-to-point interface. so essentially, all i know is that it will be router-id X is next hop over so and so P2P link....or the 64k link?????? how does one segregate the link-ids? so that each link is uniquely identified.... and even if there is a way to "segregate" it out, how does one put that 100Mbps in the forwarding table and not the 64kbps? is there any draft/document i can refer to for the same? -thanks and rgds Alok From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 11 06:55:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29244 for ; Tue, 11 Feb 2003 06:55:36 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.008DCBF1@cherry.ease.lsoft.com>; Tue, 11 Feb 2003 6:59:18 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 623170 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Feb 2003 06:59:17 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Feb 2003 06:49:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28550; Tue, 11 Feb 2003 06:45:31 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200302111145.GAA28550@ietf.org> Date: Tue, 11 Feb 2003 06:45:31 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-srisuresh-ospf-te-05.txt Comments: cc: te-wg@ops.ietf.org To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Traffic Engineering Working Group of the IETF. Title : OSPF-xTE: An experimental extension to OSPF for Traffic Engineering Author(s) : P. Srisuresh, P. Joseph Filename : draft-srisuresh-ospf-te-05.txt Pages : 49 Date : 2003-2-10 This document defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF. New TE LSAs are defined to disseminate TE metrics within an autonomous System (AS) - intra-area as well as inter-area. An Autonomous System may consist of TE and non-TE nodes. Non-TE nodes are uneffected by the distribution of TE LSAs. A stand-alone TE Link State Database (TE-LSDB), separate from the native OSPF LSDB, is generated for the computation of TE circuit paths. OSPF-xTE is also extendible to non-packet networks such as SONET/TDM and optical networks. A transition path is provided for those using [OPQLSA-TE] and wish to adapt OSPF-xTE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-srisuresh-ospf-te-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-srisuresh-ospf-te-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-10132912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-srisuresh-ospf-te-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-srisuresh-ospf-te-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-10132912.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 11 11:44:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10844 for ; Tue, 11 Feb 2003 11:44:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.008DD370@cherry.ease.lsoft.com>; Tue, 11 Feb 2003 11:48:26 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 623861 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Feb 2003 11:48:26 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Feb 2003 11:48:26 -0500 Received: from redback.com (jagged.redback.com [155.53.36.195]) by prattle.redback.com (Postfix) with ESMTP id 6CD62315773 for ; Tue, 11 Feb 2003 08:48:25 -0800 (PST) X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 References: <020f01c2d1a8$3d553360$81c802c0@alok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E492959.CD87C35D@redback.com> Date: Tue, 11 Feb 2003 08:48:25 -0800 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks, Inc Subject: Re: OSPF---out of band To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Alok, alok wrote: > > Hi, > > As far as I understand, the OSPF protocol always sends LSA on "the links > which it advertises and forms adjacencies" > > there is something referred to as passive, but then one cant form > adjacencies over passive links.............. passive interfaces are not part of the base OSPF specification (although they are handled similiar to OSPF hosts). > > assuming there are 2 links between Node A and Node B one is 64kbps other is > 100Mbps... > > i need to use the 64kbps link to establish OSPF adjacencies and pass the LSA > information etc over it. It is can't be done using the vanilla OSPF. There has never been a strong requirement for OSPF to use links other than the ones over which adjacencies are established. > > however i want the traffic to use the 100Mbps link... > > so essentially, i want ospf to do the following: > > for this 2 node network OSPF should have something like > > for destination on node B , next-hop is via 100Mbps between node A and B > but, the interfaces themseleves are "passive" interfaces.... > > is there anyway this can be done? > > in BGP this would be "destn network x.y.z.w" next-hop interface ip of B > which is directly connected... > > so one could run BGP out-of-band over the 64Kbps but still put a next hop to > the other interface..... > so BGP doesnt even run on the 100Mbps link, it runs on the 64Kbps > link.....(signalling is segregated) but the forwarding is still over > 100Mbps.... > how does one do this in OSPF? > > another this which is confusing is that if the interface doesnt have an > "IP"...(unnumbered P2P) the RFC 2328 says: > > If the neighboring router is fully adjacent, add a > Type 1 link (point-to-point). The Link ID should be > set to the Router ID of the neighboring router. For > numbered point-to-point networks, the Link Data > should specify the IP interface address. For > unnumbered point-to-point networks, the Link Data > field should specify the interface's MIB-II [Ref8] > ifIndex value. The cost should be set to the output > cost of the point-to-point interface. > > so essentially, all i know is that it will be router-id X is next hop over > so and so P2P link....or the 64k link?????? > > how does one segregate the link-ids? so that each link is uniquely > identified.... > and even if there is a way to "segregate" it out, how does one put that > 100Mbps in the forwarding table and not the 64kbps? > > is there any draft/document i can refer to for the same? > > -thanks and rgds > Alok -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 11 12:46:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12894 for ; Tue, 11 Feb 2003 12:46:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.008DD546@cherry.ease.lsoft.com>; Tue, 11 Feb 2003 12:50:35 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 624095 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Feb 2003 12:50:35 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Feb 2003 12:50:34 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 006641B598; Wed, 12 Feb 2003 02:50:32 +0900 (JST) References: <020f01c2d1a8$3d553360$81c802c0@alok> <3E492959.CD87C35D@redback.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030212.025032.60512215.yasu@sfc.wide.ad.jp> Date: Wed, 12 Feb 2003 02:50:32 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: OSPF---out of band Comments: To: acee@REDBACK.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E492959.CD87C35D@redback.com> Precedence: list Content-Transfer-Encoding: 7bit > > assuming there are 2 links between Node A and Node B one is 64kbps other is > > 100Mbps... > > > > i need to use the 64kbps link to establish OSPF adjacencies and pass the LSA > > information etc over it. > > It is can't be done using the vanilla OSPF. There has never been a strong > requirement for OSPF to use links other than the ones over which adjacencies > are established. Agree to Acee, and wondered what is the reason that you don't want the OSPF to run on (or to form an adjacency over) the 100Mbps link ? I guess the merit which is that any failures in L3 can be detected is always prefered over the demerit of bandwidth consumption. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 11 13:52:11 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15014 for ; Tue, 11 Feb 2003 13:52:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.008DD72F@cherry.ease.lsoft.com>; Tue, 11 Feb 2003 13:55:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 624281 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Feb 2003 13:55:53 -0500 Received: from 63.150.47.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Feb 2003 13:45:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: OSPF---out of band Thread-Index: AcLRp+uQL58k+HQiRce6BPd8g7K8ugAVa59w Message-ID: Date: Tue, 11 Feb 2003 10:45:51 -0800 Reply-To: Mailing List Sender: Mailing List From: Shanthi Pendyala Subject: Re: OSPF---out of band To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA15014 hi, "assuming there are 2 links between Node A and Node B one is 64kbps other is 100Mbps... i need to use the 64kbps link to establish OSPF adjacencies and pass the LSA information etc over it. however i want the traffic to use the 100Mbps link..." My understanding is that this was prevented in OSPF by design. Using only those links that have valid adjacencies for forwarding ensures the detection of L2 failures over the link (if the control packets can't go over the link so can't the data packets) do you have a specific application in mind which requires this behaviour ? shanthi kiran Luminous networks Cupertino CA From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 11 21:39:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25767 for ; Tue, 11 Feb 2003 21:39:01 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.008DE5A4@cherry.ease.lsoft.com>; Tue, 11 Feb 2003 21:42:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 625454 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11 Feb 2003 21:42:41 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 11 Feb 2003 21:32:40 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25286; Tue, 11 Feb 2003 21:28:53 -0500 (EST) Message-ID: <200302120228.VAA25286@ietf.org> Date: Tue, 11 Feb 2003 21:28:53 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Document Action: Alternative OSPF ABR Implementations to Informational Comments: cc: RFC Editor , Internet Architecture Board To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list The IESG has approved the Internet-Draft 'Alternative OSPF ABR Implementations' as an Informational RFC. This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Bill Fenner and Alex Zinin. RFC Editor Note: Section 1.1 "Introduction", first paragraph OLD: An OSPF routing domain can be split into several subdomains, called areas, which limit the scope of LSA flooding. According to [Ref1] a router having attachments to multiple areas is called an "area border router" (ABR). The primary function of an ABR is to provide its attached areas with Type-3 and Type-4 LSAs (which are used for describing routes and ASBRs in other areas) as well as to perform actual inter-area routing. NEW: An OSPF routing domain can be split into several subdomains, called areas, which limit the scope of LSA flooding. According to [Ref1] a router having attachments to multiple areas is called an "area border router" (ABR). The primary function of an ABR is to provide its attached areas with Type-3 and Type-4 LSAs, which are used for describing routes and AS boundary routers (ASBRs) in other areas, as well as to perform actual inter-area routing. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 01:30:32 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00177 for ; Wed, 12 Feb 2003 01:30:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.008DEF45@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 1:34:15 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 625961 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 01:34:14 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 01:34:14 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1C6sVQ17624 for ; Wed, 12 Feb 2003 12:24:31 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1C6sUt17618 for ; Wed, 12 Feb 2003 12:24:30 +0530 References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <01d701c2d261$12871ae0$81c802c0@alok> Date: Wed, 12 Feb 2003 12:06:11 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: OSPF---out of band To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list just curious...as to how to get signalling out of the path of data..... ----- Original Message ----- From: Shanthi Pendyala To: Sent: Wednesday, February 12, 2003 12:15 AM Subject: Re: OSPF---out of band > hi, > > > "assuming there are 2 links between Node A and Node B one is 64kbps other is > 100Mbps... > > i need to use the 64kbps link to establish OSPF adjacencies and pass the LSA > information etc over it. > > however i want the traffic to use the 100Mbps link..." > > My understanding is that this was prevented in OSPF by design. > Using only those links that have valid adjacencies for forwarding ensures the > detection of L2 failures over the link (if the control > packets can't go over the link so can't the data packets) > > do you have a specific application in mind which requires this behaviour ? > > shanthi kiran > Luminous networks > Cupertino CA > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 01:53:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00473 for ; Wed, 12 Feb 2003 01:53:39 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.008DF059@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 1:57:21 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 625993 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 01:57:21 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 01:57:21 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1C7HcQ18691 for ; Wed, 12 Feb 2003 12:47:38 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1C7Hbt18684 for ; Wed, 12 Feb 2003 12:47:37 +0530 References: <020f01c2d1a8$3d553360$81c802c0@alok> <3E492959.CD87C35D@redback.com> <20030212.025032.60512215.yasu@sfc.wide.ad.jp> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <031001c2d264$4d218480$81c802c0@alok> Date: Wed, 12 Feb 2003 12:29:18 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: OSPF---out of band To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I could still detect link failures and pass them over the 64kbps link? I dont think OSPF is needed to detect "link failures" ..the kernel itself would do it...?..physical link being up/down is kernel's problem... as far as L3 failure goes...can you give me a "specific" example? where you say "L3 is down" but "L2 is up"...(assume unnumbered interfaces)...mismatch in config? fine, as i said that isnt a concern...i have 100Mbps unnumbered (P2P) link and 64kbps P2P link. OSPF hellos mainly would be used to detect "routing node" failures which would anyway be passed over via the other link in this case.. ----- Original Message ----- From: Yasuhiro Ohara To: Sent: Tuesday, February 11, 2003 11:20 PM Subject: Re: OSPF---out of band > > > assuming there are 2 links between Node A and Node B one is 64kbps other is > > > 100Mbps... > > > > > > i need to use the 64kbps link to establish OSPF adjacencies and pass the LSA > > > information etc over it. > > > > It is can't be done using the vanilla OSPF. There has never been a strong > > requirement for OSPF to use links other than the ones over which adjacencies > > are established. > > Agree to Acee, and wondered what is the reason that you don't want > the OSPF to run on (or to form an adjacency over) the 100Mbps link ? > I guess the merit which is that any failures in L3 can be detected > is always prefered over the demerit of bandwidth consumption. > > regards, > yasu > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 01:58:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00519 for ; Wed, 12 Feb 2003 01:58:20 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.008DEEED@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 2:02:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 626008 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 02:02:02 -0500 Received: from 203.254.224.33 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 02:02:02 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HA600A01OTUP9@mailout3.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 16:01:06 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HA600AHBOTUGU@mailout3.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 16:01:06 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HA600FM0PG1K4@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 16:14:27 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <020f01c2d1a8$3d553360$81c802c0@alok> <3E492959.CD87C35D@redback.com> <20030212.025032.60512215.yasu@sfc.wide.ad.jp> <031001c2d264$4d218480$81c802c0@alok> Message-ID: <022e01c2d264$8f3939d0$b4036c6b@sisodomain.com> Date: Wed, 12 Feb 2003 12:31:23 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: OSPF---out of band To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Alok, > > I dont think OSPF is needed to detect "link failures" ..the kernel itself > would do it...?..physical link being up/down is kernel's problem... Kernel will tell you if your own physical link went down. How do you think you will come to know if the link at the other end of your adjaceny went down? -- Manav > > as far as L3 failure goes...can you give me a "specific" example? where you > say "L3 is down" but "L2 is up"...(assume unnumbered interfaces)...mismatch > in config? > > fine, as i said that isnt a concern...i have 100Mbps unnumbered (P2P) link > and 64kbps P2P link. > > OSPF hellos mainly would be used to detect "routing node" failures which > would anyway be passed over via the other link in this case.. > > > ----- Original Message ----- > From: Yasuhiro Ohara > To: > Sent: Tuesday, February 11, 2003 11:20 PM > Subject: Re: OSPF---out of band > > > > > > assuming there are 2 links between Node A and Node B one is 64kbps > other is > > > > 100Mbps... > > > > > > > > i need to use the 64kbps link to establish OSPF adjacencies and pass > the LSA > > > > information etc over it. > > > > > > It is can't be done using the vanilla OSPF. There has never been a > strong > > > requirement for OSPF to use links other than the ones over which > adjacencies > > > are established. > > > > Agree to Acee, and wondered what is the reason that you don't want > > the OSPF to run on (or to form an adjacency over) the 100Mbps link ? > > I guess the merit which is that any failures in L3 can be detected > > is always prefered over the demerit of bandwidth consumption. > > > > regards, > > yasu > > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 02:05:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08334 for ; Wed, 12 Feb 2003 02:05:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.008DEFCE@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 2:09:26 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 626049 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 02:09:25 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 02:09:25 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1C7ThQ19124 for ; Wed, 12 Feb 2003 12:59:43 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1C7Tft19118 for ; Wed, 12 Feb 2003 12:59:41 +0530 References: <020f01c2d1a8$3d553360$81c802c0@alok> <3E492959.CD87C35D@redback.com> <20030212.025032.60512215.yasu@sfc.wide.ad.jp> <031001c2d264$4d218480$81c802c0@alok> <022e01c2d264$8f3939d0$b4036c6b@sisodomain.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <037d01c2d265$fcb75b80$81c802c0@alok> Date: Wed, 12 Feb 2003 12:41:08 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: OSPF---out of band To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > Alok, > > > > I dont think OSPF is needed to detect "link failures" ..the kernel itself > > would do it...?..physical link being up/down is kernel's problem... > > Kernel will tell you if your own physical link went down. How do you think > you will come to know if the link at the other end of your adjaceny went > down? "serial is up, line protocol is down"...... L2 is end to end i guess....or assumed so....mebbe there are cases where this might not be true...cant think of one though (on P2P) eitherways the other end could still signal "his own end is down' over the 64kbps link? if that went down..well thats the only place im supposed to send hello packets via..so OSPF will faill...but I am fine with that... assume that 64k was a DCC channel on an SDH mux? From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 02:09:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10676 for ; Wed, 12 Feb 2003 02:09:22 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.008DEF62@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 2:13:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 626070 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 02:13:04 -0500 Received: from 203.254.224.33 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 02:13:04 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HA600A01PC9ZA@mailout3.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 16:12:09 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HA6004XBPC8FH@mailout3.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 16:12:09 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HA6004H6PYFH8@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 16:25:30 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <020f01c2d1a8$3d553360$81c802c0@alok> <3E492959.CD87C35D@redback.com> <20030212.025032.60512215.yasu@sfc.wide.ad.jp> <031001c2d264$4d218480$81c802c0@alok> Message-ID: <025201c2d266$19f048b0$b4036c6b@sisodomain.com> Date: Wed, 12 Feb 2003 12:42:26 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: OSPF---out of band To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT I think my previous mail was a little ambiguous .. expounding more on it .. Imagine what will happen when your 64kbps link on one end goes down You will be tearing the adjacency and no traffic will flow even though you have your 100Mbps link alive! ----- Original Message ----- From: "alok" To: Sent: Wednesday, February 12, 2003 12:29 PM Subject: Re: OSPF---out of band > I could still detect link failures and pass them over the 64kbps link? > > I dont think OSPF is needed to detect "link failures" ..the kernel itself > would do it...?..physical link being up/down is kernel's problem... > > as far as L3 failure goes...can you give me a "specific" example? where you > say "L3 is down" but "L2 is up"...(assume unnumbered interfaces)...mismatch > in config? > > fine, as i said that isnt a concern...i have 100Mbps unnumbered (P2P) link > and 64kbps P2P link. > > OSPF hellos mainly would be used to detect "routing node" failures which > would anyway be passed over via the other link in this case.. > > > ----- Original Message ----- > From: Yasuhiro Ohara > To: > Sent: Tuesday, February 11, 2003 11:20 PM > Subject: Re: OSPF---out of band > > > > > > assuming there are 2 links between Node A and Node B one is 64kbps > other is > > > > 100Mbps... > > > > > > > > i need to use the 64kbps link to establish OSPF adjacencies and pass > the LSA > > > > information etc over it. > > > > > > It is can't be done using the vanilla OSPF. There has never been a > strong > > > requirement for OSPF to use links other than the ones over which > adjacencies > > > are established. > > > > Agree to Acee, and wondered what is the reason that you don't want > > the OSPF to run on (or to form an adjacency over) the 100Mbps link ? > > I guess the merit which is that any failures in L3 can be detected > > is always prefered over the demerit of bandwidth consumption. > > > > regards, > > yasu > > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 02:24:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22062 for ; Wed, 12 Feb 2003 02:24:41 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.008DF023@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 2:28:22 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 626090 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 02:28:21 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 02:28:21 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1C7mdQ20630 for ; Wed, 12 Feb 2003 13:18:39 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1C7mYt20621 for ; Wed, 12 Feb 2003 13:18:38 +0530 References: <020f01c2d1a8$3d553360$81c802c0@alok> <3E492959.CD87C35D@redback.com> <20030212.025032.60512215.yasu@sfc.wide.ad.jp> <031001c2d264$4d218480$81c802c0@alok> <025201c2d266$19f048b0$b4036c6b@sisodomain.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <03ab01c2d268$a1ce9fa0$81c802c0@alok> Date: Wed, 12 Feb 2003 13:00:15 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: OSPF---out of band To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list i have a box infront of node-a and node -b its basically a mux.... it has a seperate signalling channel/timeslots... the link is provisioned over the mux (okie ill make that 100Mbps to 155Mbps so that you call it oc-3 or STM-1) the link between boxatnodeA and boxatnodeB is STM-1+64k in the link between boxatnodeA and boxatnodeB i want to use the 64k part (muxed out) for signalling..i can tap it out from my mux using some serial cable and put it onto an interface.. essentially, assume that if the 64k is down the link between the 2 boxes is down you might say the last mile on the 64kbps to my router is down too...fine..very rare..its something one can live with... if it flaps..well we had a whole lot of things on hitless restart (which now seems to be called graceful restart)....and we had reduction in LSAs using the "triggered updates" ..making LSA refresh timer as infiinty etc... if I can ensure that 1. if 64k is up, 155Mbps may be up or down (that is possible in my scenario) 2.but if 64k is down 155Mbps is down guaranteed how do i look at this? ----- Original Message ----- From: Manav Bhatia To: Sent: Wednesday, February 12, 2003 12:42 PM Subject: Re: OSPF---out of band > I think my previous mail was a little ambiguous .. expounding more on it .. > > Imagine what will happen when your 64kbps link on one end goes down You > will be tearing the adjacency and no traffic will flow even though you have > your 100Mbps link alive! > > ----- Original Message ----- > From: "alok" > To: > Sent: Wednesday, February 12, 2003 12:29 PM > Subject: Re: OSPF---out of band > > > > I could still detect link failures and pass them over the 64kbps link? > > > > I dont think OSPF is needed to detect "link failures" ..the kernel itself > > would do it...?..physical link being up/down is kernel's problem... > > > > as far as L3 failure goes...can you give me a "specific" example? where > you > > say "L3 is down" but "L2 is up"...(assume unnumbered > interfaces)...mismatch > > in config? > > > > fine, as i said that isnt a concern...i have 100Mbps unnumbered (P2P) > link > > and 64kbps P2P link. > > > > OSPF hellos mainly would be used to detect "routing node" failures which > > would anyway be passed over via the other link in this case.. > > > > > > ----- Original Message ----- > > From: Yasuhiro Ohara > > To: > > Sent: Tuesday, February 11, 2003 11:20 PM > > Subject: Re: OSPF---out of band > > > > > > > > > assuming there are 2 links between Node A and Node B one is 64kbps > > other is > > > > > 100Mbps... > > > > > > > > > > i need to use the 64kbps link to establish OSPF adjacencies and > pass > > the LSA > > > > > information etc over it. > > > > > > > > It is can't be done using the vanilla OSPF. There has never been a > > strong > > > > requirement for OSPF to use links other than the ones over which > > adjacencies > > > > are established. > > > > > > Agree to Acee, and wondered what is the reason that you don't want > > > the OSPF to run on (or to form an adjacency over) the 100Mbps link ? > > > I guess the merit which is that any failures in L3 can be detected > > > is always prefered over the demerit of bandwidth consumption. > > > > > > regards, > > > yasu > > > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 12:50:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10012 for ; Wed, 12 Feb 2003 12:50:37 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.008DFC98@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 12:54:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 627866 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 12:54:17 -0500 Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 12:54:17 -0500 Received: from user-38lc02g.dialup.mindspring.com ([209.86.0.80] helo=earthlink.net) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18j15L-0006UP-00 for ospf@discuss.microsoft.com; Wed, 12 Feb 2003 09:54:16 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E4A8536.43135FC1@earthlink.net> Date: Wed, 12 Feb 2003 09:32:38 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, I guess you could say that I have a dumb question. If a DR wanted to support say 400+ adjs with a standard Ethernet 1.5 MTU, is it acceptable to send out more than 1 hello describing all of its nbrs? Note: each nbr id would consume 4 bytes and thus the length of the 1 pkt would be greater than MTU size. I am assuming that 2 pkts per hello interval would be transmitted. It is that I just don't remember any RFC describing this condition. Pointers please... Thanks, Mitchell Erblich Sr. Software Engineer ` ====================== From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 13:00:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10285 for ; Wed, 12 Feb 2003 13:00:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.008DFB94@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 13:03:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 627900 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 13:03:53 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 13:03:53 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1CIOCQ07321 for ; Wed, 12 Feb 2003 23:54:12 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1CIO9t07315 for ; Wed, 12 Feb 2003 23:54:10 +0530 References: <3E4A8536.43135FC1@earthlink.net> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <04d501c2d2c1$6a33dca0$81c802c0@alok> Date: Wed, 12 Feb 2003 23:35:46 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list ideally, you would have to build flow control on top of OSPF? ----- Original Message ----- From: Erblichs To: Sent: Wednesday, February 12, 2003 11:02 PM Subject: Num of Nbrs and MTU size in hello pkts : OSPFv2 > Group, > > I guess you could say that I have a dumb question. > > If a DR wanted to support say 400+ adjs with a standard > Ethernet 1.5 MTU, is it acceptable to send out more > than 1 hello describing all of its nbrs? > > Note: each nbr id would consume 4 bytes and thus > the length of the 1 pkt would be greater than MTU size. > > I am assuming that 2 pkts per hello interval would > be transmitted. > > It is that I just don't remember any RFC describing > this condition. > > Pointers please... > > Thanks, > > Mitchell Erblich > Sr. Software Engineer > ` ====================== > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 13:02:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10368 for ; Wed, 12 Feb 2003 13:02:02 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.008DFCB3@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 13:05:46 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 627920 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 13:05:46 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 13:05:46 -0500 Received: from redback.com (jagged.redback.com [155.53.36.195]) by prattle.redback.com (Postfix) with ESMTP id 089074F2E88 for ; Wed, 12 Feb 2003 10:05:45 -0800 (PST) X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 References: <3E4A8536.43135FC1@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E4A8CF8.A0A4858E@redback.com> Date: Wed, 12 Feb 2003 10:05:44 -0800 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks, Inc Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > > Group, > > I guess you could say that I have a dumb question. > > If a DR wanted to support say 400+ adjs with a standard > Ethernet 1.5 MTU, is it acceptable to send out more > than 1 hello describing all of its nbrs? > > Note: each nbr id would consume 4 bytes and thus > the length of the 1 pkt would be greater than MTU size. > > I am assuming that 2 pkts per hello interval would > be transmitted. Erblichs, This won't work. Based the neighbor FSM, the neighbors will all go to One-Way state when they receive the hello packet not including them in the hello packet. Better to let the IP stacks fragment and reassemble. > > It is that I just don't remember any RFC describing > this condition. > > Pointers please... > > Thanks, > > Mitchell Erblich > Sr. Software Engineer > ` ====================== -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 13:17:27 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10824 for ; Wed, 12 Feb 2003 13:17:27 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.008DFD24@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 13:21:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 628001 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 13:21:10 -0500 Received: from 134.56.3.132 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 13:11:10 -0500 Received: from mx02-int.net.com (mx02-int.net.com [134.56.112.14]) by mx02.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id h1CICQ229742 for ; Wed, 12 Feb 2003 10:12:26 -0800 (PST) Received: from west-mail.net.com (west-mail.net.com [134.56.112.40]) by mx02-int.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id h1CIA8c23458 for ; Wed, 12 Feb 2003 10:10:08 -0800 (PST) Received: from net.com ([134.56.24.58]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA115 for ; Wed, 12 Feb 2003 10:11:35 -0800 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 References: <3E4A8536.43135FC1@earthlink.net> <04d501c2d2c1$6a33dca0$81c802c0@alok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E4A8E56.60862F24@net.com> Date: Wed, 12 Feb 2003 10:11:34 -0800 Reply-To: Mailing List Sender: Mailing List From: Shankar Agarwal Organization: N.E.T. http://www.net.com Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I am not sure how the different implementations will behave in this case. But as far as RFC is concerned. It says in section 4.3 that each protocol packet can be broken into small protocol packet. But i am not sure in case of Hello. But then we can use Ip Fragmentation for Hello Packet and no one stops us from sending an IP packet greater than then MTU. alok wrote: > > ideally, you would have to build flow control on top of OSPF? > > ----- Original Message ----- > From: Erblichs > To: > Sent: Wednesday, February 12, 2003 11:02 PM > Subject: Num of Nbrs and MTU size in hello pkts : OSPFv2 > > > Group, > > > > I guess you could say that I have a dumb question. > > > > If a DR wanted to support say 400+ adjs with a standard > > Ethernet 1.5 MTU, is it acceptable to send out more > > than 1 hello describing all of its nbrs? > > > > Note: each nbr id would consume 4 bytes and thus > > the length of the 1 pkt would be greater than MTU size. > > > > I am assuming that 2 pkts per hello interval would > > be transmitted. > > > > It is that I just don't remember any RFC describing > > this condition. > > > > Pointers please... > > > > Thanks, > > > > Mitchell Erblich > > Sr. Software Engineer > > ` ====================== > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 14:59:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14046 for ; Wed, 12 Feb 2003 14:59:52 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.008DFEDE@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 15:03:35 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 628098 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 15:03:35 -0500 Received: from 216.136.175.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 14:53:35 -0500 Received: from [66.189.10.145] by web13508.mail.yahoo.com via HTTP; Wed, 12 Feb 2003 11:53:34 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030212195334.45425.qmail@web13508.mail.yahoo.com> Date: Wed, 12 Feb 2003 11:53:34 -0800 Reply-To: Mailing List Sender: Mailing List From: ROBERT PATHFINDER Subject: Re: OSPF---out of band To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <03ab01c2d268$a1ce9fa0$81c802c0@alok> Precedence: list --- alok wrote: > i have a box infront of node-a and node -b > its basically a mux.... > it has a seperate signalling channel/timeslots... > the link is provisioned over the mux (okie ill make > that 100Mbps to 155Mbps > so that you call it oc-3 or STM-1) > the link between boxatnodeA and boxatnodeB is > STM-1+64k > in the link between boxatnodeA and boxatnodeB i want > to use the 64k part > (muxed out) for signalling..i can tap it out from my > mux using some serial > cable and put it onto an interface.. > > essentially, assume that if the 64k is down the link > between the 2 boxes is > down > > you might say the last mile on the 64kbps to my > router is down > too...fine..very rare..its something one can live > with... You may want to look at the proposals of the deleted draft "draft-ietf-ospf-ppp-flood-" which defines parallel point-to-point links between two OSPF routers as equivalent links if they are part of the same OSPF area. Only of the equivalent links is required to be fully adjacent and the others can remain in 2-Way state, thereby preventing database exchanges and LSA flooding over the non-adjacent equivalent links. Also it requires modification of the routing table calculation as it stores any of the equivalent links that have least cost as the interface to reach next hop which is the directly connected neighbor in this case. So if the STM-1 link is assumed to have minimum cost between 64K and STM-1 then SRM-1 link could appear as the interface to reach the neighbor router in the forwarding table and IP datagram traffic forwarding would then happen over the STM-1 link and OSPF DBD, LSA flooding would be restricted over the 64K link. However this requires changing the OSPF protocol operation slightly. > > if it flaps..well we had a whole lot of things on > hitless restart (which now > seems to be called graceful restart)....and we had > reduction in LSAs using > the "triggered updates" ..making LSA refresh timer > as infiinty etc... > > if I can ensure that > 1. if 64k is up, 155Mbps may be up or down (that is > possible in my scenario) > 2.but if 64k is down 155Mbps is down guaranteed > > how do i look at this? > > > > ----- Original Message ----- > From: Manav Bhatia > To: > Sent: Wednesday, February 12, 2003 12:42 PM > Subject: Re: OSPF---out of band > > > > I think my previous mail was a little ambiguous .. > expounding more on it > .. > > > > Imagine what will happen when your 64kbps link on > one end goes down You > > will be tearing the adjacency and no traffic will > flow even though you > have > > your 100Mbps link alive! > > > > ----- Original Message ----- > > From: "alok" > > To: > > Sent: Wednesday, February 12, 2003 12:29 PM > > Subject: Re: OSPF---out of band > > > > > > > I could still detect link failures and pass them > over the 64kbps link? > > > > > > I dont think OSPF is needed to detect "link > failures" ..the kernel > itself > > > would do it...?..physical link being up/down is > kernel's problem... > > > > > > as far as L3 failure goes...can you give me a > "specific" example? where > > you > > > say "L3 is down" but "L2 is up"...(assume > unnumbered > > interfaces)...mismatch > > > in config? > > > > > > fine, as i said that isnt a concern...i have > 100Mbps unnumbered (P2P) > > link > > > and 64kbps P2P link. > > > > > > OSPF hellos mainly would be used to detect > "routing node" failures which > > > would anyway be passed over via the other link > in this case.. > > > > > > > > > ----- Original Message ----- > > > From: Yasuhiro Ohara > > > To: > > > Sent: Tuesday, February 11, 2003 11:20 PM > > > Subject: Re: OSPF---out of band > > > > > > > > > > > > assuming there are 2 links between Node A > and Node B one is 64kbps > > > other is > > > > > > 100Mbps... > > > > > > > > > > > > i need to use the 64kbps link to establish > OSPF adjacencies and > > pass > > > the LSA > > > > > > information etc over it. > > > > > > > > > > It is can't be done using the vanilla OSPF. > There has never been a > > > strong > > > > > requirement for OSPF to use links other than > the ones over which > > > adjacencies > > > > > are established. > > > > > > > > Agree to Acee, and wondered what is the reason > that you don't want > > > > the OSPF to run on (or to form an adjacency > over) the 100Mbps link ? > > > > I guess the merit which is that any failures > in L3 can be detected > > > > is always prefered over the demerit of > bandwidth consumption. > > > > > > > > regards, > > > > yasu > > > > > > > > > ===== Somen Bhattacharya E-Mail : rob_path@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 15:43:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15243 for ; Wed, 12 Feb 2003 15:43:22 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.008DFF53@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 15:47:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 628254 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 15:47:03 -0500 Received: from 216.136.175.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 15:47:03 -0500 Received: from [66.189.10.145] by web13504.mail.yahoo.com via HTTP; Wed, 12 Feb 2003 12:47:02 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030212204702.36742.qmail@web13504.mail.yahoo.com> Date: Wed, 12 Feb 2003 12:47:02 -0800 Reply-To: Mailing List Sender: Mailing List From: SOMEN BHATTACHARYA Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E4A8CF8.A0A4858E@redback.com> Precedence: list --- Acee Lindem wrote: > Erblichs wrote: > > > > Group, > > > > I guess you could say that I have a dumb > question. > > > > If a DR wanted to support say 400+ adjs > with a standard > > Ethernet 1.5 MTU, is it acceptable to send > out more > > than 1 hello describing all of its nbrs? > > > > Note: each nbr id would consume 4 bytes > and thus > > the length of the 1 pkt would be greater > than MTU size. > > > > I am assuming that 2 pkts per hello > interval would > > be transmitted. > > Erblichs, > > This won't work. Based the neighbor FSM, the > neighbors will all go to > One-Way state when they receive the hello packet not > including them in > the hello packet. Better to let the IP stacks > fragment and > reassemble. Does the OSPF Hello packet header include any Multi-Packet indicator (similar to More Flag) ? If so then Neighbor FSM can wait till the last Hello packet (in a multi-packet hello) arrives and then set Neighbor to 1-Way if the receving router itself is not included in any of the fragment hellos. This could be an alternate to the IP fragmentation to transport large OSPF hello packets. > > > > > > It is that I just don't remember any RFC > describing > > this condition. > > > > Pointers please... > > > > Thanks, > > > > Mitchell Erblich > > Sr. Software Engineer > > ` ====================== > > -- > Acee ===== Somen Bhattacharya E-Mail : rob_path@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 16:35:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16535 for ; Wed, 12 Feb 2003 16:35:47 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.008E0287@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 16:39:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 628463 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 16:39:27 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 16:39:26 -0500 Received: from redback.com (jagged.redback.com [155.53.36.195]) by prattle.redback.com (Postfix) with ESMTP id 9507944CEA9 for ; Wed, 12 Feb 2003 13:39:25 -0800 (PST) X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 References: <20030212204702.36742.qmail@web13504.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E4ABF0D.CDB2201E@redback.com> Date: Wed, 12 Feb 2003 13:39:25 -0800 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks, Inc Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit SOMEN BHATTACHARYA wrote: > > --- Acee Lindem wrote: > > Erblichs wrote: > > > > > > Group, > > > > > > I guess you could say that I have a dumb > > question. > > > > > > If a DR wanted to support say 400+ adjs > > with a standard > > > Ethernet 1.5 MTU, is it acceptable to send > > out more > > > than 1 hello describing all of its nbrs? > > > > > > Note: each nbr id would consume 4 bytes > > and thus > > > the length of the 1 pkt would be greater > > than MTU size. > > > > > > I am assuming that 2 pkts per hello > > interval would > > > be transmitted. > > > > Erblichs, > > > > This won't work. Based the neighbor FSM, the > > neighbors will all go to > > One-Way state when they receive the hello packet not > > including them in > > the hello packet. Better to let the IP stacks > > fragment and > > reassemble. > > Does the OSPF Hello packet header include any > Multi-Packet indicator (similar to More Flag) ? Nope - and it really doesn't make sense to talk about modifications to the protocol when IP fragmentation/reassembly solves the problem. > > If so then Neighbor FSM can wait till the last > Hello packet (in a multi-packet hello) arrives > and then set Neighbor to 1-Way if the receving router > itself is not included in any of the fragment hellos. > > This could be an alternate to the IP fragmentation > to transport large OSPF hello packets. > > > > > > > > > > > It is that I just don't remember any RFC > > describing > > > this condition. > > > > > > Pointers please... > > > > > > Thanks, > > > > > > Mitchell Erblich > > > Sr. Software Engineer > > > ` ====================== > > > > -- > > Acee > > ===== > Somen Bhattacharya > E-Mail : rob_path@yahoo.com > > __________________________________________________ > Do you Yahoo!? > Yahoo! Shopping - Send Flowers for Valentine's Day > http://shopping.yahoo.com -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 19:14:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19446 for ; Wed, 12 Feb 2003 19:14:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.008E08DC@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 19:18:13 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 628784 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 19:18:12 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 19:08:12 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.008E095D@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 19:08:12 -0500 Message-ID: Date: Wed, 12 Feb 2003 19:08:12 -0500 Reply-To: Mailing List Sender: Mailing List From: Shankar Agarwal Subject: Re: About Table 2 Page 23 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I am sorry that i forgot to add the RFC number in my message. The RFC number that i was talking about was 2328. The way we seem to be treating the Point to Point link while advertising to other areas is also weird. Any help in this regard would be greatly appreciated. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 20:19:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20617 for ; Wed, 12 Feb 2003 20:19:56 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.008E0AAC@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 20:23:39 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 628861 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 20:23:39 -0500 Received: from 216.136.175.81 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 20:23:39 -0500 Received: from [66.189.10.145] by web13502.mail.yahoo.com via HTTP; Wed, 12 Feb 2003 17:23:38 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030213012338.10150.qmail@web13502.mail.yahoo.com> Date: Wed, 12 Feb 2003 17:23:38 -0800 Reply-To: Mailing List Sender: Mailing List From: SOMEN BHATTACHARYA Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E4ABF0D.CDB2201E@redback.com> Precedence: list --- Acee Lindem wrote: > SOMEN BHATTACHARYA wrote: > > > > --- Acee Lindem wrote: > > > Erblichs wrote: > > > > > > > > Group, > > > > > > > > I guess you could say that I have a > dumb > > > question. > > > > > > > > If a DR wanted to support say 400+ > adjs > > > with a standard > > > > Ethernet 1.5 MTU, is it acceptable to > send > > > out more > > > > than 1 hello describing all of its > nbrs? > > > > > > > > Note: each nbr id would consume 4 > bytes > > > and thus > > > > the length of the 1 pkt would be > greater > > > than MTU size. > > > > > > > > I am assuming that 2 pkts per hello > > > interval would > > > > be transmitted. > > > > > > Erblichs, > > > > > > This won't work. Based the neighbor FSM, the > > > neighbors will all go to > > > One-Way state when they receive the hello packet > not > > > including them in > > > the hello packet. Better to let the IP stacks > > > fragment and > > > reassemble. > > > > Does the OSPF Hello packet header include any > > Multi-Packet indicator (similar to More Flag) ? > > Nope - and it really doesn't make sense to talk > about > modifications to the protocol when IP > fragmentation/reassembly > solves the problem. Does OSPF guarantee that "Don't Fragment" bit will never be set in the IP header ? If not, then large OSPF Hello packet may get dropped by IP forwarder while attempting to send to the neighbor, if IP fragmentation is not permitted for the link. > > > > > If so then Neighbor FSM can wait till the last > > Hello packet (in a multi-packet hello) arrives > > and then set Neighbor to 1-Way if the receving > router > > itself is not included in any of the fragment > hellos. > > > > This could be an alternate to the IP fragmentation > > to transport large OSPF hello packets. > > > > > > > > > > > > > > > > It is that I just don't remember any > RFC > > > describing > > > > this condition. > > > > > > > > Pointers please... > > > > > > > > Thanks, > > > > > > > > Mitchell Erblich > > > > Sr. Software Engineer > > > > ` ====================== > > > > > > -- > > > Acee > > > > ===== > > Somen Bhattacharya > > E-Mail : rob_path@yahoo.com > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Shopping - Send Flowers for Valentine's Day > > http://shopping.yahoo.com > > -- > Acee ===== Somen Bhattacharya E-Mail : rob_path@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 20:44:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21052 for ; Wed, 12 Feb 2003 20:44:54 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.008E0C28@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 20:48:38 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 628898 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 20:48:38 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 20:48:38 -0500 Received: from redback.com (jagged.redback.com [155.53.36.195]) by prattle.redback.com (Postfix) with ESMTP id 2A3462879A6 for ; Wed, 12 Feb 2003 17:48:37 -0800 (PST) X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 References: <20030213012338.10150.qmail@web13502.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E4AF975.6A9B063B@redback.com> Date: Wed, 12 Feb 2003 17:48:37 -0800 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks, Inc Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit SOMEN BHATTACHARYA wrote: > > --- Acee Lindem wrote: > > SOMEN BHATTACHARYA wrote: > > > > > > --- Acee Lindem wrote: > > > > Erblichs wrote: > > > > > > > > > > Group, > > > > > > > > > > I guess you could say that I have a > > dumb > > > > question. > > > > > > > > > > If a DR wanted to support say 400+ > > adjs > > > > with a standard > > > > > Ethernet 1.5 MTU, is it acceptable to > > send > > > > out more > > > > > than 1 hello describing all of its > > nbrs? > > > > > > > > > > Note: each nbr id would consume 4 > > bytes > > > > and thus > > > > > the length of the 1 pkt would be > > greater > > > > than MTU size. > > > > > > > > > > I am assuming that 2 pkts per hello > > > > interval would > > > > > be transmitted. > > > > > > > > Erblichs, > > > > > > > > This won't work. Based the neighbor FSM, the > > > > neighbors will all go to > > > > One-Way state when they receive the hello packet > > not > > > > including them in > > > > the hello packet. Better to let the IP stacks > > > > fragment and > > > > reassemble. > > > > > > Does the OSPF Hello packet header include any > > > Multi-Packet indicator (similar to More Flag) ? > > > > Nope - and it really doesn't make sense to talk > > about > > modifications to the protocol when IP > > fragmentation/reassembly > > solves the problem. > > Does OSPF guarantee that "Don't Fragment" bit will > never be set in the IP header ? Why would an OSPF implementation ever set the DF bit? > > If not, then large OSPF Hello packet may get dropped > by IP forwarder while attempting to send to the > neighbor, if IP fragmentation is not permitted for > the link. > > > > > > > > > If so then Neighbor FSM can wait till the last > > > Hello packet (in a multi-packet hello) arrives > > > and then set Neighbor to 1-Way if the receving > > router > > > itself is not included in any of the fragment > > hellos. > > > > > > This could be an alternate to the IP fragmentation > > > to transport large OSPF hello packets. > > > > > > > > > > > > > > > > > > > > > It is that I just don't remember any > > RFC > > > > describing > > > > > this condition. > > > > > > > > > > Pointers please... > > > > > > > > > > Thanks, > > > > > > > > > > Mitchell Erblich > > > > > Sr. Software Engineer > > > > > ` ====================== > > > > > > > > -- > > > > Acee > > > > > > ===== > > > Somen Bhattacharya > > > E-Mail : rob_path@yahoo.com > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Shopping - Send Flowers for Valentine's Day > > > http://shopping.yahoo.com > > > > -- > > Acee > > ===== > Somen Bhattacharya > E-Mail : rob_path@yahoo.com > > __________________________________________________ > Do you Yahoo!? > Yahoo! Shopping - Send Flowers for Valentine's Day > http://shopping.yahoo.com -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 12 20:53:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21195 for ; Wed, 12 Feb 2003 20:53:15 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.008E0C7E@cherry.ease.lsoft.com>; Wed, 12 Feb 2003 20:56:58 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 628934 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 20:56:58 -0500 Received: from 207.217.120.46 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 12 Feb 2003 20:56:58 -0500 Received: from user-38ldtcn.dialup.mindspring.com ([209.86.245.151] helo=earthlink.net) by grebe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18j8cS-0004Ao-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12 Feb 2003 17:56:57 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <20030212204702.36742.qmail@web13504.mail.yahoo.com> <3E4ABF0D.CDB2201E@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E4AF57F.D40EB830@earthlink.net> Date: Wed, 12 Feb 2003 17:31:43 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Follow-up: Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, Thanks, I was/am concerned about the Don't Fragment bit being set in the IP header. Has anyone run into this large neighbor problem and having packets dropped OR just having packets dropped because of this Don't Fragment bit? This almost seems like a option bit to me. Don't go 1-way if you see a hello packet that doesn't have yourself specified once you were 2-way UNTIL dead-router interval has occurred... Oops, this seems like a mod of the nbr state machine.. Maybe something simpler like a msg generation if a hello is createed beyond a MTU???? Mitchell Erblich ============================ Acee Lindem wrote: > > SOMEN BHATTACHARYA wrote: > > > > --- Acee Lindem wrote: > > > Erblichs wrote: > > > > > > > > Group, > > > > > > > > I guess you could say that I have a dumb > > > question. > > > > > > > > If a DR wanted to support say 400+ adjs > > > with a standard > > > > Ethernet 1.5 MTU, is it acceptable to send > > > out more > > > > than 1 hello describing all of its nbrs? > > > > > > > > Note: each nbr id would consume 4 bytes > > > and thus > > > > the length of the 1 pkt would be greater > > > than MTU size. > > > > > > > > I am assuming that 2 pkts per hello > > > interval would > > > > be transmitted. > > > > > > Erblichs, > > > > > > This won't work. Based the neighbor FSM, the > > > neighbors will all go to > > > One-Way state when they receive the hello packet not > > > including them in > > > the hello packet. Better to let the IP stacks > > > fragment and > > > reassemble. > > > > Does the OSPF Hello packet header include any > > Multi-Packet indicator (similar to More Flag) ? > > Nope - and it really doesn't make sense to talk about > modifications to the protocol when IP fragmentation/reassembly > solves the problem. > > > > > If so then Neighbor FSM can wait till the last > > Hello packet (in a multi-packet hello) arrives > > and then set Neighbor to 1-Way if the receving router > > itself is not included in any of the fragment hellos. > > > > This could be an alternate to the IP fragmentation > > to transport large OSPF hello packets. > > > > > > > > > > > > > > > > It is that I just don't remember any RFC > > > describing > > > > this condition. > > > > > > > > Pointers please... > > > > > > > > Thanks, > > > > > > > > Mitchell Erblich > > > > Sr. Software Engineer > > > > ` ====================== > > > > > > -- > > > Acee > > > > ===== > > Somen Bhattacharya > > E-Mail : rob_path@yahoo.com > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Shopping - Send Flowers for Valentine's Day > > http://shopping.yahoo.com > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 13 00:24:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24886 for ; Thu, 13 Feb 2003 00:24:41 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.008E146D@cherry.ease.lsoft.com>; Thu, 13 Feb 2003 0:28:20 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 629370 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 13 Feb 2003 00:28:20 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 13 Feb 2003 00:28:20 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1D5mfQ20573 for ; Thu, 13 Feb 2003 11:18:41 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1D5met20567 for ; Thu, 13 Feb 2003 11:18:40 +0530 References: <3E4A8536.43135FC1@earthlink.net> <04d501c2d2c1$6a33dca0$81c802c0@alok> <3E4A8E56.60862F24@net.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <056501c2d321$09fc33e0$81c802c0@alok> Date: Thu, 13 Feb 2003 11:00:20 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list hi, incase of a "hello" per se, i dont see how one evens run into MTU issues..the hello packet is not that big (only router specific info) i think may come about in DD and LSUpdates etc...which pass the LSA info.... the issues may come like this: if i have a MPLS- PPVPN from A to B the "label stacking" causes the frame size to grow so we reach an MTU of above 1500 (whatever the value) now if the routing nodes in the core (the LSRs) dont accomodate this ...the edge has no way of knowing that the core has a drop in MTU....right? and Labels in MPLS dont have DF bits :o) so you "cant fragment" there on the "core"..... now what? you have to make sure the MTU accomodates these "labelstacks" in the core ...but even now fragmentation using DF bits in IP header is ruled out ..right? -rgds Alok ----- Original Message ----- From: Shankar Agarwal To: Sent: Wednesday, February 12, 2003 11:41 PM Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 > I am not sure how the different implementations will behave in this > case. But as far as RFC is concerned. It says in section 4.3 that each > protocol packet can be broken into small protocol packet. But i am not > sure in case of Hello. But then we can use Ip Fragmentation for Hello > Packet and no one stops us from sending an IP packet greater than then > MTU. > > alok wrote: > > > > ideally, you would have to build flow control on top of OSPF? > > > > ----- Original Message ----- > > From: Erblichs > > To: > > Sent: Wednesday, February 12, 2003 11:02 PM > > Subject: Num of Nbrs and MTU size in hello pkts : OSPFv2 > > > > > Group, > > > > > > I guess you could say that I have a dumb question. > > > > > > If a DR wanted to support say 400+ adjs with a standard > > > Ethernet 1.5 MTU, is it acceptable to send out more > > > than 1 hello describing all of its nbrs? > > > > > > Note: each nbr id would consume 4 bytes and thus > > > the length of the 1 pkt would be greater than MTU size. > > > > > > I am assuming that 2 pkts per hello interval would > > > be transmitted. > > > > > > It is that I just don't remember any RFC describing > > > this condition. > > > > > > Pointers please... > > > > > > Thanks, > > > > > > Mitchell Erblich > > > Sr. Software Engineer > > > ` ====================== > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 13 00:37:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25159 for ; Thu, 13 Feb 2003 00:37:22 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.008E147F@cherry.ease.lsoft.com>; Thu, 13 Feb 2003 0:41:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 629430 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 13 Feb 2003 00:41:02 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 13 Feb 2003 00:41:02 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1D61OQ21018 for ; Thu, 13 Feb 2003 11:31:24 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1D61Nt21011 for ; Thu, 13 Feb 2003 11:31:23 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <05e001c2d322$d0a7c580$81c802c0@alok> Date: Thu, 13 Feb 2003 11:13:03 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list a slight clarification that DF bit should read as "fragment offset bits" :o) sorry ----- Original Message ----- From: alok To: Sent: Thursday, February 13, 2003 11:00 AM Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 > hi, > > incase of a "hello" per se, i dont see how one evens run into MTU > issues..the hello packet is not that big (only router specific info) > > i think may come about in DD and LSUpdates etc...which pass the LSA info.... > > the issues may come like this: > > if i have a MPLS- PPVPN from A to B > > the "label stacking" causes the frame size to grow > so we reach an MTU of above 1500 (whatever the value) > now if the routing nodes in the core (the LSRs) dont accomodate this ...the > edge has no way of knowing that the core has a drop in MTU....right? > and Labels in MPLS dont have DF bits :o) so you "cant fragment" there on the > "core"..... > > now what? > > you have to make sure the MTU accomodates these "labelstacks" in the core > ...but even now fragmentation using DF bits in IP header is ruled out > ..right? > > -rgds > Alok > ----- Original Message ----- > From: Shankar Agarwal > To: > Sent: Wednesday, February 12, 2003 11:41 PM > Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 > > > > I am not sure how the different implementations will behave in this > > case. But as far as RFC is concerned. It says in section 4.3 that each > > protocol packet can be broken into small protocol packet. But i am not > > sure in case of Hello. But then we can use Ip Fragmentation for Hello > > Packet and no one stops us from sending an IP packet greater than then > > MTU. > > > > alok wrote: > > > > > > ideally, you would have to build flow control on top of OSPF? > > > > > > ----- Original Message ----- > > > From: Erblichs > > > To: > > > Sent: Wednesday, February 12, 2003 11:02 PM > > > Subject: Num of Nbrs and MTU size in hello pkts : OSPFv2 > > > > > > > Group, > > > > > > > > I guess you could say that I have a dumb question. > > > > > > > > If a DR wanted to support say 400+ adjs with a standard > > > > Ethernet 1.5 MTU, is it acceptable to send out more > > > > than 1 hello describing all of its nbrs? > > > > > > > > Note: each nbr id would consume 4 bytes and thus > > > > the length of the 1 pkt would be greater than MTU size. > > > > > > > > I am assuming that 2 pkts per hello interval would > > > > be transmitted. > > > > > > > > It is that I just don't remember any RFC describing > > > > this condition. > > > > > > > > Pointers please... > > > > > > > > Thanks, > > > > > > > > Mitchell Erblich > > > > Sr. Software Engineer > > > > ` ====================== > > > > > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 13 02:43:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06462 for ; Thu, 13 Feb 2003 02:43:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.008E1923@cherry.ease.lsoft.com>; Thu, 13 Feb 2003 2:47:18 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 629588 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 13 Feb 2003 02:47:18 -0500 Received: from 216.136.175.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 13 Feb 2003 02:47:18 -0500 Received: from [66.189.10.145] by web13504.mail.yahoo.com via HTTP; Wed, 12 Feb 2003 23:47:17 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030213074717.19163.qmail@web13504.mail.yahoo.com> Date: Wed, 12 Feb 2003 23:47:17 -0800 Reply-To: Mailing List Sender: Mailing List From: Somen Bhattacharya Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <056501c2d321$09fc33e0$81c802c0@alok> Precedence: list --- alok wrote: > hi, > > incase of a "hello" per se, i dont see how one evens > run into MTU > issues..the hello packet is not that big (only > router specific info) > > i think may come about in DD and LSUpdates > etc...which pass the LSA info.... > > the issues may come like this: > > if i have a MPLS- PPVPN from A to B > > the "label stacking" causes the frame size to grow > so we reach an MTU of above 1500 (whatever the > value) > now if the routing nodes in the core (the LSRs) dont > accomodate this ...the > edge has no way of knowing that the core has a drop > in MTU....right? Before MPLS LSP can be used to transport OSPF messages, LSP setup over hop-by-hop routed path is dependent on OSPF to discover adjacencies and hence on successful OSPF hello exchanges. Even if there were fewer adjacencies initially and hello packet exchange was successful and LSP setup was done, transporting a large OSPF packet over LSP will not require fragmentation of the labeled packet at the directly attached core LSR, as the Ingress-LSR would have done an one time fragmentation based on MTU limit known via "Path MTU Discovery" or via configured Maximum Initially Labeled IP Datagram size. In the case of OSPF, routing messages travel only one hop and hence do not have the concern of fragmentation by core routers except at the sender. In general if a core LSR drops a labeled packet because it exceeds the link layer frame payload size, and the labeled IP packet has 'Dont Fragment' bit set in the IP header, an ICMP Destination Unreachable message (Fragmentation Required and DF set) will be sent to the Edge and so Edge router will know the reason for packet drop. > and Labels in MPLS dont have DF bits :o) so you > "cant fragment" there on the > "core"..... > > now what? > > you have to make sure the MTU accomodates these > "labelstacks" in the core > ...but even now fragmentation using DF bits in IP > header is ruled out > ..right? If fragmentation of a labeled packet is needed at core LSR, then fragmentation is done at the unlabeled IP datagram after removing the label stack and then prepending back the same label stack onto the fragmented IP datagrams. > > -rgds > Alok > ----- Original Message ----- > From: Shankar Agarwal > To: > Sent: Wednesday, February 12, 2003 11:41 PM > Subject: Re: Num of Nbrs and MTU size in hello pkts > : OSPFv2 > > > > I am not sure how the different implementations > will behave in this > > case. But as far as RFC is concerned. It says in > section 4.3 that each > > protocol packet can be broken into small protocol > packet. But i am not > > sure in case of Hello. But then we can use Ip > Fragmentation for Hello > > Packet and no one stops us from sending an IP > packet greater than then > > MTU. > > > > alok wrote: > > > > > > ideally, you would have to build flow control on > top of OSPF? > > > > > > ----- Original Message ----- > > > From: Erblichs > > > To: > > > Sent: Wednesday, February 12, 2003 11:02 PM > > > Subject: Num of Nbrs and MTU size in hello pkts > : OSPFv2 > > > > > > > Group, > > > > > > > > I guess you could say that I have a > dumb question. > > > > > > > > If a DR wanted to support say 400+ > adjs with a standard > > > > Ethernet 1.5 MTU, is it acceptable to > send out more > > > > than 1 hello describing all of its > nbrs? > > > > > > > > Note: each nbr id would consume 4 > bytes and thus > > > > the length of the 1 pkt would be > greater than MTU size. > > > > > > > > I am assuming that 2 pkts per hello > interval would > > > > be transmitted. > > > > > > > > It is that I just don't remember any > RFC describing > > > > this condition. > > > > > > > > Pointers please... > > > > > > > > Thanks, > > > > > > > > Mitchell Erblich > > > > Sr. Software Engineer > > > > ` ====================== > > > > > > ===== Somen Bhattacharya E-Mail : rob_path@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 13 02:54:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06679 for ; Thu, 13 Feb 2003 02:54:07 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.008E1790@cherry.ease.lsoft.com>; Thu, 13 Feb 2003 2:57:51 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 629625 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 13 Feb 2003 02:57:51 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 13 Feb 2003 02:57:51 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1D8IDQ28063 for ; Thu, 13 Feb 2003 13:48:13 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1D8I6t28052 for ; Thu, 13 Feb 2003 13:48:07 +0530 References: <20030213074717.19163.qmail@web13504.mail.yahoo.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <07dd01c2d335$ea0f64c0$81c802c0@alok> Date: Thu, 13 Feb 2003 13:29:42 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list inline.... ----- Original Message ----- From: Somen Bhattacharya To: Sent: Thursday, February 13, 2003 1:17 PM Subject: Re: Num of Nbrs and MTU size in hello pkts : OSPFv2 > --- alok wrote: > > hi, > > > > incase of a "hello" per se, i dont see how one evens > > run into MTU > > issues..the hello packet is not that big (only > > router specific info) > > > > i think may come about in DD and LSUpdates > > etc...which pass the LSA info.... > > > > the issues may come like this: > > > > if i have a MPLS- PPVPN from A to B > > > > the "label stacking" causes the frame size to grow > > so we reach an MTU of above 1500 (whatever the > > value) > > now if the routing nodes in the core (the LSRs) dont > > accomodate this ...the > > edge has no way of knowing that the core has a drop > > in MTU....right? > > Before MPLS LSP can be used to transport OSPF > messages, > LSP setup over hop-by-hop routed path is dependent on > OSPF to discover adjacencies and hence on successful > OSPF hello exchanges. errr no im talking about a topology where i provision a PPVPN to the customer and he runs OSPF over it...across the MPLS infrastrctr in the middle in MPLS LSPs where OSPF is used as the IGP, this wont ever crop up, coz the adjacencies are not "over the LSP" :o)....well FA and all that are there if one reads the GMPLS routing draft but i dont know if they are looking at OSPF as signalling there........... > > Even if there were fewer adjacencies initially and > hello packet exchange was successful and LSP setup > was done, transporting a large OSPF packet over LSP > will not require fragmentation of the labeled packet > at the directly attached core LSR, as the Ingress-LSR > would have done an one time fragmentation based on > MTU limit known via "Path MTU Discovery" or via > configured Maximum Initially Labeled IP Datagram size. > how??? as i said im looking at a PPVPN between A and B, and somewhere in the middle the MTU drops and the LSR is not even aware of whats inside...(the ip part encaped inthe label stack) > In the case of OSPF, routing messages travel only > one hop and hence do not have the concern of > fragmentation by core routers except at the sender. > > In general if a core LSR drops a labeled packet > because it exceeds the link layer frame payload > size, and the labeled IP packet has 'Dont Fragment' > bit set in the IP header, an ICMP Destination > Unreachable message (Fragmentation Required and DF > set) > will be sent to the Edge and so Edge router will > know the reason for packet drop. > > > and Labels in MPLS dont have DF bits :o) so you > > "cant fragment" there on the > > "core"..... > > > > now what? > > > > you have to make sure the MTU accomodates these > > "labelstacks" in the core > > ...but even now fragmentation using DF bits in IP > > header is ruled out > > ..right? > > If fragmentation of a labeled packet is needed at > core LSR, then fragmentation is done at the unlabeled > IP datagram after removing the label stack and then > prepending back the same label stack onto the > fragmented IP datagrams. i am not too sure if i have seen this in *any draft* ...that we shall look into actual payload and decide and put fragments etc...it might work for L3VPN though coz we know payload is IP you might argue.. :o) if i knew it was IP, i might look at L3VPN, right... but if it was a PPVPN (which doesnt assume that its carrying IP) how would the LSR behave? > > > > > -rgds > > Alok > > ----- Original Message ----- > > From: Shankar Agarwal > > To: > > Sent: Wednesday, February 12, 2003 11:41 PM > > Subject: Re: Num of Nbrs and MTU size in hello pkts > > : OSPFv2 > > > > > > > I am not sure how the different implementations > > will behave in this > > > case. But as far as RFC is concerned. It says in > > section 4.3 that each > > > protocol packet can be broken into small protocol > > packet. But i am not > > > sure in case of Hello. But then we can use Ip > > Fragmentation for Hello > > > Packet and no one stops us from sending an IP > > packet greater than then > > > MTU. > > > > > > alok wrote: > > > > > > > > ideally, you would have to build flow control on > > top of OSPF? > > > > > > > > ----- Original Message ----- > > > > From: Erblichs > > > > To: > > > > Sent: Wednesday, February 12, 2003 11:02 PM > > > > Subject: Num of Nbrs and MTU size in hello pkts > > : OSPFv2 > > > > > > > > > Group, > > > > > > > > > > I guess you could say that I have a > > dumb question. > > > > > > > > > > If a DR wanted to support say 400+ > > adjs with a standard > > > > > Ethernet 1.5 MTU, is it acceptable to > > send out more > > > > > than 1 hello describing all of its > > nbrs? > > > > > > > > > > Note: each nbr id would consume 4 > > bytes and thus > > > > > the length of the 1 pkt would be > > greater than MTU size. > > > > > > > > > > I am assuming that 2 pkts per hello > > interval would > > > > > be transmitted. > > > > > > > > > > It is that I just don't remember any > > RFC describing > > > > > this condition. > > > > > > > > > > Pointers please... > > > > > > > > > > Thanks, > > > > > > > > > > Mitchell Erblich > > > > > Sr. Software Engineer > > > > > ` ====================== > > > > > > > > > > > ===== > Somen Bhattacharya > E-Mail : rob_path@yahoo.com > > __________________________________________________ > Do you Yahoo!? > Yahoo! Shopping - Send Flowers for Valentine's Day > http://shopping.yahoo.com > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 18 07:17:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26157 for ; Tue, 18 Feb 2003 07:17:12 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.008EFC57@cherry.ease.lsoft.com>; Tue, 18 Feb 2003 7:20:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 646348 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 18 Feb 2003 07:20:57 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Feb 2003 07:20:57 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 641331FC06 for ; Tue, 18 Feb 2003 21:20:55 +0900 (JST) X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030218.212054.86355733.yasu@sfc.wide.ad.jp> Date: Tue, 18 Feb 2003 21:20:54 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: typo in RFC2740 about link-local unicast address To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit In RFC 2740 section 2.5 "Use of link-local addresses" I might have found a typo ... IPv6 link-local addresses are for use on a single link, for purposes of neighbor discovery, auto-configuration, etc. IPv6 routers do not forward IPv6 datagrams having link-local source addresses [Ref15]. Link-local unicast addresses are assigned from the IPv6 address range FF80/10. Link-local unicast addresses are fe80::/64, aren't they ? E -> F may be typo, but the prefix length may be a consideration. # RFC2373 says that bits from 11th to 54th in link-local unicast address # must be zero. Sorry if it's already pointed out. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 18 07:29:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26463 for ; Tue, 18 Feb 2003 07:29:52 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.008EFDA6@cherry.ease.lsoft.com>; Tue, 18 Feb 2003 7:33:39 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 646377 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 18 Feb 2003 07:33:39 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Feb 2003 07:33:39 -0500 Received: by XOVER with Internet Mail Service (5.5.2653.19) id <1RXV3A91>; Tue, 18 Feb 2003 07:33:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 18 Feb 2003 07:35:33 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: typo in RFC2740 about link-local unicast address To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Yasu, You are right about "FE80" part of it. Good catch !!! However two small corrections in what you said. The 11th to the 64th bit are all 0's(54 bits in all). Besides even in the latest architecture draft http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.txt Link-local unicast is still defined as Link-local unicast 1111111010 FE80::/10 2.5.6 Check section 2.4 Thanks, Vishwas -----Original Message----- From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] Sent: Tuesday, February 18, 2003 5:51 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: typo in RFC2740 about link-local unicast address In RFC 2740 section 2.5 "Use of link-local addresses" I might have found a typo ... IPv6 link-local addresses are for use on a single link, for purposes of neighbor discovery, auto-configuration, etc. IPv6 routers do not forward IPv6 datagrams having link-local source addresses [Ref15]. Link-local unicast addresses are assigned from the IPv6 address range FF80/10. Link-local unicast addresses are fe80::/64, aren't they ? E -> F may be typo, but the prefix length may be a consideration. # RFC2373 says that bits from 11th to 54th in link-local unicast address # must be zero. Sorry if it's already pointed out. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 18 10:55:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00566 for ; Tue, 18 Feb 2003 10:55:50 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.008F00DD@cherry.ease.lsoft.com>; Tue, 18 Feb 2003 10:59:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 646791 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 18 Feb 2003 10:59:35 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 18 Feb 2003 10:59:35 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 7D8481A357A; Tue, 18 Feb 2003 07:59:33 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <15667673960.20030217121443@psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E525947.9010704@redback.com> Date: Tue, 18 Feb 2003 11:03:19 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: draft-ietf-ospf-dc-06.txt - Detecting Inactive Neighbors over OSPF Demand Circuits Comments: To: Bill Fenner Comments: cc: Alex Zinin , Sira Panduranga Rao , Rohit Dube , iesg-secretary@ietf.org, Abhay Roy To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Bill, The OSPF WG wishes to submit draft-ietf-ospf-dc-06.txt, "Detecting Inactive Neighbors over OSPF Demand Circuits", for formal AD review. Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 20 10:37:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18213 for ; Thu, 20 Feb 2003 10:37:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.008F6D88@cherry.ease.lsoft.com>; Thu, 20 Feb 2003 10:41:23 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 655056 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 20 Feb 2003 10:41:23 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Feb 2003 10:41:23 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id E054925184B for ; Thu, 20 Feb 2003 07:41:21 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E54F7E9.7000906@redback.com> Date: Thu, 20 Feb 2003 10:44:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: typo in RFC2740 about link-local unicast address To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I'll keep track of these updates in case we decide to re-spin RFC 2740. Thanks, Acee Manral, Vishwas wrote: > Hi Yasu, > > You are right about "FE80" part of it. Good catch !!! > > However two small corrections in what you said. The 11th to the 64th bit are > all 0's(54 bits in all). Besides even in the latest architecture draft > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.txt > > Link-local unicast is still defined as > > Link-local unicast 1111111010 FE80::/10 2.5.6 > > Check section 2.4 > > Thanks, > Vishwas > > -----Original Message----- > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > Sent: Tuesday, February 18, 2003 5:51 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: typo in RFC2740 about link-local unicast address > > > In RFC 2740 section 2.5 "Use of link-local addresses" I might have > found a typo ... > > IPv6 link-local addresses are for use on a single link, for purposes > of neighbor discovery, auto-configuration, etc. IPv6 routers do not > forward IPv6 datagrams having link-local source addresses [Ref15]. > Link-local unicast addresses are assigned from the IPv6 address range > FF80/10. > > Link-local unicast addresses are fe80::/64, aren't they ? > E -> F may be typo, but the prefix length may be a consideration. > # RFC2373 says that bits from 11th to 54th in link-local unicast address > # must be zero. > > Sorry if it's already pointed out. > > regards, > yasu > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 20 12:34:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22323 for ; Thu, 20 Feb 2003 12:34:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.008F727F@cherry.ease.lsoft.com>; Thu, 20 Feb 2003 12:38:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 655531 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 20 Feb 2003 12:38:03 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 20 Feb 2003 12:38:03 -0500 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18lue1-000CyZ-00; Thu, 20 Feb 2003 09:38:01 -0800 X-Mailer: The Bat! (v1.62i) Personal X-Priority: 3 (Normal) References: <3E54F7E9.7000906@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <1054013166.20030220093750@psg.com> Date: Thu, 20 Feb 2003 09:37:50 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: typo in RFC2740 about link-local unicast address Comments: To: Acee Lindem To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E54F7E9.7000906@redback.com> Precedence: list Content-Transfer-Encoding: 7bit BTW, maybe adding an entry to the RFC errata (http://www.rfc-editor.org/errata.html) would be a good idea? -- Alex Thursday, February 20, 2003, 7:44:41 AM, Acee Lindem wrote: > I'll keep track of these updates in case we decide to re-spin > RFC 2740. > Thanks, > Acee > Manral, Vishwas wrote: >> Hi Yasu, >> >> You are right about "FE80" part of it. Good catch !!! >> >> However two small corrections in what you said. The 11th to the 64th bit are >> all 0's(54 bits in all). Besides even in the latest architecture draft >> http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.txt >> >> Link-local unicast is still defined as >> >> Link-local unicast 1111111010 FE80::/10 2.5.6 >> >> Check section 2.4 >> >> Thanks, >> Vishwas >> From owner-ospf@DISCUSS.MICROSOFT.COM Fri Feb 21 02:17:21 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21686 for ; Fri, 21 Feb 2003 02:17:21 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.008F8FC9@cherry.ease.lsoft.com>; Fri, 21 Feb 2003 2:21:09 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 656914 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 21 Feb 2003 02:21:08 -0500 Received: from 216.136.226.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Feb 2003 02:21:08 -0500 Received: from [210.118.108.254] by web20703.mail.yahoo.com via HTTP; Thu, 20 Feb 2003 23:21:08 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030221072108.38695.qmail@web20703.mail.yahoo.com> Date: Thu, 20 Feb 2003 23:21:08 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: different costs! To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I have a very basic doubt. ------- ------- | R-A | | R-B | ------- ------- | | __|_____________| | | ------ |R-C | ------ In this setup i have 3 routers on an ethernet. From Router C's perspective can i assign different costs to reach R-A and R-B? (I know it can be done in p2p links). For example, can i somehow assign a cost to reach R-A as 3 and R-B as say, 10, thus making all my traffic to choose R-A as long as its up? Any answers please? Regards, Rohit __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Fri Feb 21 03:01:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22437 for ; Fri, 21 Feb 2003 03:01:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.008F9004@cherry.ease.lsoft.com>; Fri, 21 Feb 2003 3:05:20 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 657007 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 21 Feb 2003 03:05:19 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Feb 2003 03:05:19 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1L8QJQ13354 for ; Fri, 21 Feb 2003 13:56:19 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1L8QDt13347 for ; Fri, 21 Feb 2003 13:56:15 +0530 References: <20030221072108.38695.qmail@web20703.mail.yahoo.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <01e701c2d980$4b42b760$81c802c0@alok> Date: Fri, 21 Feb 2003 13:30:13 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: different costs! To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list am not too sure..... but i think if cost for R-B is higher than R-A........ in this case traffic coming back towards R-C will be preferred via R-A (for any router connected further) above R-A and R-B etc... so u can control the downstream towards R-C that way same as P2P in a way actually.... if you give different costs on either side in P2P the same would happen ----- Original Message ----- From: Rohit Gupta To: Sent: Friday, February 21, 2003 12:51 PM Subject: different costs! > Hi, > I have a very basic doubt. > > ------- ------- > | R-A | | R-B | > ------- ------- > | | > __|_____________| > | > | > ------ > |R-C | > ------ > > In this setup i have 3 routers on an ethernet. From > Router C's perspective can i assign different costs to > reach R-A and R-B? (I know it can be done in p2p > links). For example, can i somehow assign a cost to > reach R-A as 3 and R-B as say, 10, thus making all my > traffic to choose R-A as long as its up? > > Any answers please? > > Regards, > Rohit > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Feb 21 03:34:32 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22923 for ; Fri, 21 Feb 2003 03:34:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.008F9157@cherry.ease.lsoft.com>; Fri, 21 Feb 2003 3:38:21 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 657140 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 21 Feb 2003 03:38:21 -0500 Received: from 216.136.226.178 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Feb 2003 03:38:21 -0500 Received: from [210.118.108.254] by web20705.mail.yahoo.com via HTTP; Fri, 21 Feb 2003 00:38:20 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030221083820.23863.qmail@web20705.mail.yahoo.com> Date: Fri, 21 Feb 2003 00:38:20 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: Re: different costs! To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <01e701c2d980$4b42b760$81c802c0@alok> Precedence: list Rite ALok .. but my question is HOW do i set the costs for these routers when both of them are on the same ethernet. I know it can be done on p2p links .. but my doubt is in case of ethernet media where theoretically all the nodes should be reachable with the same cost! Isnt it so? Rohit. --- alok wrote: > am not too sure..... > > but i think if cost for R-B is higher than > R-A........ > > in this case traffic coming back towards R-C will be > preferred via R-A (for > any router connected further) above R-A and R-B > etc... > > so u can control the downstream towards R-C that > way > > same as P2P in a way actually.... if you give > different costs on either side > in P2P the same would happen > > > ----- Original Message ----- > From: Rohit Gupta > To: > Sent: Friday, February 21, 2003 12:51 PM > Subject: different costs! > > > > Hi, > > I have a very basic doubt. > > > > ------- ------- > > | R-A | | R-B | > > ------- ------- > > | | > > __|_____________| > > | > > | > > ------ > > |R-C | > > ------ > > > > In this setup i have 3 routers on an ethernet. > From > > Router C's perspective can i assign different > costs to > > reach R-A and R-B? (I know it can be done in p2p > > links). For example, can i somehow assign a cost > to > > reach R-A as 3 and R-B as say, 10, thus making all > my > > traffic to choose R-A as long as its up? > > > > Any answers please? > > > > Regards, > > Rohit > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ > > __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Fri Feb 21 04:03:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23760 for ; Fri, 21 Feb 2003 04:03:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.008F92CC@cherry.ease.lsoft.com>; Fri, 21 Feb 2003 4:07:02 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 657183 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 21 Feb 2003 04:07:02 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Feb 2003 04:07:02 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1L9S2Q15824 for ; Fri, 21 Feb 2003 14:58:02 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1L9S0t15812 for ; Fri, 21 Feb 2003 14:58:01 +0530 References: <20030221083820.23863.qmail@web20705.mail.yahoo.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <024e01c2d988$eac2a680$81c802c0@alok> Date: Fri, 21 Feb 2003 14:39:02 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: different costs! To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list well... "ip ospf cost" should work on BMA.... and the path computation from one router sees "its cost" not the cost of the other guy.. so u can give different costs manually...whats wrong with it? ----- Original Message ----- From: Rohit Gupta To: Sent: Friday, February 21, 2003 2:08 PM Subject: Re: different costs! > Rite ALok .. but my question is HOW do i set the costs > for these routers when both of them are on the same > ethernet. > > I know it can be done on p2p links .. but my doubt is > in case of ethernet media where theoretically all the > nodes should be reachable with the same cost! > > Isnt it so? > > Rohit. > --- alok wrote: > > am not too sure..... > > > > but i think if cost for R-B is higher than > > R-A........ > > > > in this case traffic coming back towards R-C will be > > preferred via R-A (for > > any router connected further) above R-A and R-B > > etc... > > > > so u can control the downstream towards R-C that > > way > > > > same as P2P in a way actually.... if you give > > different costs on either side > > in P2P the same would happen > > > > > > ----- Original Message ----- > > From: Rohit Gupta > > To: > > Sent: Friday, February 21, 2003 12:51 PM > > Subject: different costs! > > > > > > > Hi, > > > I have a very basic doubt. > > > > > > ------- ------- > > > | R-A | | R-B | > > > ------- ------- > > > | | > > > __|_____________| > > > | > > > | > > > ------ > > > |R-C | > > > ------ > > > > > > In this setup i have 3 routers on an ethernet. > > From > > > Router C's perspective can i assign different > > costs to > > > reach R-A and R-B? (I know it can be done in p2p > > > links). For example, can i somehow assign a cost > > to > > > reach R-A as 3 and R-B as say, 10, thus making all > > my > > > traffic to choose R-A as long as its up? > > > > > > Any answers please? > > > > > > Regards, > > > Rohit > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Tax Center - forms, calculators, tips, more > > > http://taxes.yahoo.com/ > > > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Feb 21 04:14:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23899 for ; Fri, 21 Feb 2003 04:14:16 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.008F9286@cherry.ease.lsoft.com>; Fri, 21 Feb 2003 4:18:06 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 657198 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 21 Feb 2003 04:18:05 -0500 Received: from 216.136.226.179 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Feb 2003 04:18:05 -0500 Received: from [210.118.108.254] by web20706.mail.yahoo.com via HTTP; Fri, 21 Feb 2003 01:18:04 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030221091804.19891.qmail@web20706.mail.yahoo.com> Date: Fri, 21 Feb 2003 01:18:04 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: Re: different costs! To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <024e01c2d988$eac2a680$81c802c0@alok> Precedence: list thanks ! I got it! --- alok wrote: > well... > "ip ospf cost" should work on BMA.... > > and the path computation from one router sees "its > cost" not the cost of the > other guy.. > so u can give different costs manually...whats wrong > with it? > > ----- Original Message ----- > From: Rohit Gupta > To: > Sent: Friday, February 21, 2003 2:08 PM > Subject: Re: different costs! > > > > Rite ALok .. but my question is HOW do i set the > costs > > for these routers when both of them are on the > same > > ethernet. > > > > I know it can be done on p2p links .. but my doubt > is > > in case of ethernet media where theoretically all > the > > nodes should be reachable with the same cost! > > > > Isnt it so? > > > > Rohit. > > --- alok wrote: > > > am not too sure..... > > > > > > but i think if cost for R-B is higher than > > > R-A........ > > > > > > in this case traffic coming back towards R-C > will be > > > preferred via R-A (for > > > any router connected further) above R-A and R-B > > > etc... > > > > > > so u can control the downstream towards R-C > that > > > way > > > > > > same as P2P in a way actually.... if you give > > > different costs on either side > > > in P2P the same would happen > > > > > > > > > ----- Original Message ----- > > > From: Rohit Gupta > > > To: > > > Sent: Friday, February 21, 2003 12:51 PM > > > Subject: different costs! > > > > > > > > > > Hi, > > > > I have a very basic doubt. > > > > > > > > ------- ------- > > > > | R-A | | R-B | > > > > ------- ------- > > > > | | > > > > __|_____________| > > > > | > > > > | > > > > ------ > > > > |R-C | > > > > ------ > > > > > > > > In this setup i have 3 routers on an ethernet. > > > From > > > > Router C's perspective can i assign different > > > costs to > > > > reach R-A and R-B? (I know it can be done in > p2p > > > > links). For example, can i somehow assign a > cost > > > to > > > > reach R-A as 3 and R-B as say, 10, thus making > all > > > my > > > > traffic to choose R-A as long as its up? > > > > > > > > Any answers please? > > > > > > > > Regards, > > > > Rohit > > > > > > > > > __________________________________________________ > > > > Do you Yahoo!? > > > > Yahoo! Tax Center - forms, calculators, tips, > more > > > > http://taxes.yahoo.com/ > > > > > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ > > __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Fri Feb 21 05:23:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25191 for ; Fri, 21 Feb 2003 05:23:47 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.008F92C3@cherry.ease.lsoft.com>; Fri, 21 Feb 2003 5:27:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 657389 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 21 Feb 2003 05:27:36 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Feb 2003 05:27:36 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1LAmaQ18777 for ; Fri, 21 Feb 2003 16:18:36 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1LAmZt18770 for ; Fri, 21 Feb 2003 16:18:35 +0530 References: <20030221091804.19891.qmail@web20706.mail.yahoo.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <02ba01c2d994$2be96b20$81c802c0@alok> Date: Fri, 21 Feb 2003 15:51:45 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: different costs! To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list havent tested it....... has anyone? ----- Original Message ----- From: Rohit Gupta To: Sent: Friday, February 21, 2003 2:48 PM Subject: Re: different costs! > thanks ! > > I got it! > > --- alok wrote: > > well... > > "ip ospf cost" should work on BMA.... > > > > and the path computation from one router sees "its > > cost" not the cost of the > > other guy.. > > so u can give different costs manually...whats wrong > > with it? > > > > ----- Original Message ----- > > From: Rohit Gupta > > To: > > Sent: Friday, February 21, 2003 2:08 PM > > Subject: Re: different costs! > > > > > > > Rite ALok .. but my question is HOW do i set the > > costs > > > for these routers when both of them are on the > > same > > > ethernet. > > > > > > I know it can be done on p2p links .. but my doubt > > is > > > in case of ethernet media where theoretically all > > the > > > nodes should be reachable with the same cost! > > > > > > Isnt it so? > > > > > > Rohit. > > > --- alok wrote: > > > > am not too sure..... > > > > > > > > but i think if cost for R-B is higher than > > > > R-A........ > > > > > > > > in this case traffic coming back towards R-C > > will be > > > > preferred via R-A (for > > > > any router connected further) above R-A and R-B > > > > etc... > > > > > > > > so u can control the downstream towards R-C > > that > > > > way > > > > > > > > same as P2P in a way actually.... if you give > > > > different costs on either side > > > > in P2P the same would happen > > > > > > > > > > > > ----- Original Message ----- > > > > From: Rohit Gupta > > > > To: > > > > Sent: Friday, February 21, 2003 12:51 PM > > > > Subject: different costs! > > > > > > > > > > > > > Hi, > > > > > I have a very basic doubt. > > > > > > > > > > ------- ------- > > > > > | R-A | | R-B | > > > > > ------- ------- > > > > > | | > > > > > __|_____________| > > > > > | > > > > > | > > > > > ------ > > > > > |R-C | > > > > > ------ > > > > > > > > > > In this setup i have 3 routers on an ethernet. > > > > From > > > > > Router C's perspective can i assign different > > > > costs to > > > > > reach R-A and R-B? (I know it can be done in > > p2p > > > > > links). For example, can i somehow assign a > > cost > > > > to > > > > > reach R-A as 3 and R-B as say, 10, thus making > > all > > > > my > > > > > traffic to choose R-A as long as its up? > > > > > > > > > > Any answers please? > > > > > > > > > > Regards, > > > > > Rohit > > > > > > > > > > > > __________________________________________________ > > > > > Do you Yahoo!? > > > > > Yahoo! Tax Center - forms, calculators, tips, > > more > > > > > http://taxes.yahoo.com/ > > > > > > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Tax Center - forms, calculators, tips, more > > > http://taxes.yahoo.com/ > > > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Feb 21 12:47:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08675 for ; Fri, 21 Feb 2003 12:47:04 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.008F9D1A@cherry.ease.lsoft.com>; Fri, 21 Feb 2003 12:50:54 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 650189 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 21 Feb 2003 12:50:54 -0500 Received: from 134.56.3.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Feb 2003 12:50:54 -0500 Received: from mx02-int.net.com (mx02-int.net.com [134.56.112.14]) by mx01.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id h1LHqCF23652 for ; Fri, 21 Feb 2003 09:52:12 -0800 (PST) Received: from west-mail.net.com (west-mail.net.com [134.56.112.40]) by mx02-int.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id h1LHnhH28417 for ; Fri, 21 Feb 2003 09:49:43 -0800 (PST) Received: from net.com ([134.56.24.58]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA4F23 for ; Fri, 21 Feb 2003 09:51:21 -0800 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 References: <20030221083820.23863.qmail@web20705.mail.yahoo.com> <024e01c2d988$eac2a680$81c802c0@alok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E566718.A26041B3@net.com> Date: Fri, 21 Feb 2003 09:51:20 -0800 Reply-To: Mailing List Sender: Mailing List From: Shankar Agarwal Organization: N.E.T. http://www.net.com Subject: Re: different costs! To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I am not sure if i understood you fully. But as far as i know When Router C advertises its Router LSA it gives only one cost to the interface that it connects to broadcast network. So i don't think it is possible to control the traffic just from configuring Router C. We can make it take router A by configuring it so that the routes that A advertises happens to have a lower cost then same routes advertised by B. So Router C will see Router A as the preferred path. alok wrote: > > well... > "ip ospf cost" should work on BMA.... > > and the path computation from one router sees "its cost" not the cost of the > other guy.. > so u can give different costs manually...whats wrong with it? > > ----- Original Message ----- > From: Rohit Gupta > To: > Sent: Friday, February 21, 2003 2:08 PM > Subject: Re: different costs! > > > Rite ALok .. but my question is HOW do i set the costs > > for these routers when both of them are on the same > > ethernet. > > > > I know it can be done on p2p links .. but my doubt is > > in case of ethernet media where theoretically all the > > nodes should be reachable with the same cost! > > > > Isnt it so? > > > > Rohit. > > --- alok wrote: > > > am not too sure..... > > > > > > but i think if cost for R-B is higher than > > > R-A........ > > > > > > in this case traffic coming back towards R-C will be > > > preferred via R-A (for > > > any router connected further) above R-A and R-B > > > etc... > > > > > > so u can control the downstream towards R-C that > > > way > > > > > > same as P2P in a way actually.... if you give > > > different costs on either side > > > in P2P the same would happen > > > > > > > > > ----- Original Message ----- > > > From: Rohit Gupta > > > To: > > > Sent: Friday, February 21, 2003 12:51 PM > > > Subject: different costs! > > > > > > > > > > Hi, > > > > I have a very basic doubt. > > > > > > > > ------- ------- > > > > | R-A | | R-B | > > > > ------- ------- > > > > | | > > > > __|_____________| > > > > | > > > > | > > > > ------ > > > > |R-C | > > > > ------ > > > > > > > > In this setup i have 3 routers on an ethernet. > > > From > > > > Router C's perspective can i assign different > > > costs to > > > > reach R-A and R-B? (I know it can be done in p2p > > > > links). For example, can i somehow assign a cost > > > to > > > > reach R-A as 3 and R-B as say, 10, thus making all > > > my > > > > traffic to choose R-A as long as its up? > > > > > > > > Any answers please? > > > > > > > > Regards, > > > > Rohit > > > > > > > > __________________________________________________ > > > > Do you Yahoo!? > > > > Yahoo! Tax Center - forms, calculators, tips, more > > > > http://taxes.yahoo.com/ > > > > > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ > > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Feb 21 13:05:00 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09381 for ; Fri, 21 Feb 2003 13:05:00 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.008F9DEA@cherry.ease.lsoft.com>; Fri, 21 Feb 2003 13:08:20 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 650253 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 21 Feb 2003 13:08:20 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 21 Feb 2003 13:08:20 -0500 Received: from smirtoraw2k02 (dhcp-171-69-101-89.cisco.com [171.69.101.89]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h1LI8Jr15400 for ; Fri, 21 Feb 2003 10:08:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <007f01c2d9d4$36fadea0$596545ab@amer.cisco.com> Date: Fri, 21 Feb 2003 10:08:19 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: different costs! To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030221072108.38695.qmail@web20703.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Rohit It would depends how your LAN is represented in SPF, so if you use network type broadcast or NBMA there is no way to achieve it ( from RC ) as you will have only one adjacency to the DR and DR's cost to all the attached routers is always 0 If you configure as point-to-multipoint then you can have cost differently set for each neighbor and influence the path on RC Sina > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM] On > Behalf Of Rohit Gupta > Sent: Thursday, February 20, 2003 11:21 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: different costs! > > > Hi, > I have a very basic doubt. > > ------- ------- > | R-A | | R-B | > ------- ------- > | | > __|_____________| > | > | > ------ > |R-C | > ------ > > In this setup i have 3 routers on an ethernet. From > Router C's perspective can i assign different costs to > reach R-A and R-B? (I know it can be done in p2p > links). For example, can i somehow assign a cost to > reach R-A as 3 and R-B as say, 10, thus making all my > traffic to choose R-A as long as its up? > > Any answers please? > > Regards, > Rohit > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Sat Feb 22 06:43:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09257 for ; Sat, 22 Feb 2003 06:43:56 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.008FBA47@cherry.ease.lsoft.com>; Sat, 22 Feb 2003 6:47:43 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 652086 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 22 Feb 2003 06:47:43 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 22 Feb 2003 06:47:43 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id D75B2183531; Sat, 22 Feb 2003 03:47:41 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E57640D.6070907@redback.com> Date: Sat, 22 Feb 2003 06:50:37 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: RFC Errata Addition - RFC 2740, OSPF for IPv6, December 1999 Comments: To: rfc-editor@rfc-editor.org To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit In Section 2.5, the last sentence of the first paragraph reads: Link-local unicast addresses are assigned from the IPv6 address range FF80/10. The IPv6 link-local address range is incorrect and this sentence should read: Link-local unicast addresses are assigned from the IPv6 address range FE80::/10. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sun Feb 23 07:40:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07061 for ; Sun, 23 Feb 2003 07:40:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.008FCEED@cherry.ease.lsoft.com>; 23 Feb 2003 7:44:18 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 653741 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 23 Feb 2003 07:44:18 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 23 Feb 2003 07:44:17 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 8E4D3DE984 for ; Sun, 23 Feb 2003 04:44:16 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E58C2C2.30603@redback.com> Date: Sun, 23 Feb 2003 07:46:58 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: 56th IETF Important Dates To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Here is a list of deadlines for the 56th IETF: February 24, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET February 25, Tuesday - Working Group and BOF scheduling closes at 17:00 ET March 3, Monday - Internet Draft final submission cut-off at 09:00 ET March 7, Friday - Registration and Pre-payment cut-off at 12:00 noon ET March 12, Wednesday - Registration cancellation cut-off at 17:00 ET March 13, Thursday - Working Group agendas due date at 12:00 ET So far, we have the following items on the agenda: - OSPF Document Status Update (WG Chairs) - OSPFv2 MIB Update (Dan Joyal - presented by Acee) - OSPFv3 Address Family support (Sina Mirtorabi, Abhay Roy, or Micheal Barnes) Please send E-mail to Rohit and myself if you have any additions. --- Thanks, Acee and Rohit From owner-ospf@DISCUSS.MICROSOFT.COM Sun Feb 23 22:36:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19895 for ; Sun, 23 Feb 2003 22:36:09 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.008FDD9A@cherry.ease.lsoft.com>; 23 Feb 2003 22:40:01 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 654753 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 23 Feb 2003 22:40:01 -0500 Received: from 66.163.169.153 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 23 Feb 2003 22:40:01 -0500 Received: from [210.118.108.254] by web20712.mail.yahoo.com via HTTP; Sun, 23 Feb 2003 19:40:00 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030224034000.83553.qmail@web20712.mail.yahoo.com> Date: Sun, 23 Feb 2003 19:40:00 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: Timing of MaxAge LSAs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Suppose i am advertising an LSA, say AS-External LSA. Now that route goes off and i advertise the same LSA with age set to MaxAge. Now it again comes up after some time (with interval less than MinLSInterval). I cannot originate a new LSA because of the MinLSInterval gap for which i have to anyway wait. Once this interval is over i will originate a copy of this LSA. But what if it again goes down before my MinLSInterval period expires. Should an implementation 1> Originate a new LSA and then again flush it OR 2> Should i not do anything because i know that the route has anyway gone down. Given the granularity of this timer (and maybe some others too!) isnt it a little difficult to achieve sub-second convergence? Regards, Rohit __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Sun Feb 23 22:53:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20188 for ; Sun, 23 Feb 2003 22:53:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.008FDD3F@cherry.ease.lsoft.com>; 23 Feb 2003 22:57:30 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 654783 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 23 Feb 2003 22:57:30 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 23 Feb 2003 22:57:30 -0500 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 511241F50DB for ; Sun, 23 Feb 2003 19:57:29 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030224034000.83553.qmail@web20712.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E5998C3.8030301@redback.com> Date: Sun, 23 Feb 2003 23:00:03 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Timing of MaxAge LSAs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Rohit Gupta wrote: > Hi, > Suppose i am advertising an LSA, say AS-External LSA. > Now that route goes off and i advertise the same LSA > with age set to MaxAge. Now it again comes up after > some time (with interval less than MinLSInterval). I > cannot originate a new LSA because of the > MinLSInterval gap for which i have to anyway wait. > Once this interval is over i will originate a copy of > this LSA. But what if it again goes down before my > MinLSInterval period expires. > > Should an implementation > 1> Originate a new LSA and then again flush it > OR > 2> Should i not do anything because i know that the > route has anyway gone down. Externally, origination should appear as the latter. However, keep in mind that the only time flooding can be suppressed is if an LSA is MaxAged while waiting MinLSInterval to expire AND the sequence number is the initial sequence number (0x80000001). > > Given the granularity of this timer (and maybe some > others too!) isnt it a little difficult to achieve > sub-second convergence? This OSPF constant can delay convergence but it is more a factor with router LSAs. For external LSAs, I think you want some holddown between originations and I don't think 5 seconds is unreasonable. > > Regards, > Rohit > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sun Feb 23 23:22:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20620 for ; Sun, 23 Feb 2003 23:22:40 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.008FE0BF@cherry.ease.lsoft.com>; 23 Feb 2003 23:26:32 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 654826 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 23 Feb 2003 23:26:32 -0500 Received: from 216.136.226.180 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 23 Feb 2003 23:26:31 -0500 Received: from [210.118.108.254] by web20707.mail.yahoo.com via HTTP; Sun, 23 Feb 2003 20:26:31 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030224042631.90276.qmail@web20707.mail.yahoo.com> Date: Sun, 23 Feb 2003 20:26:31 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: Re: Timing of MaxAge LSAs To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E5998C3.8030301@redback.com> Precedence: list Acee, > > Externally, origination should appear as the latter. > However, keep in mind that the only time flooding > can be suppressed is if an LSA is MaxAged while > waiting MinLSInterval to expire AND the sequence > number is the initial sequence number (0x80000001). And what if its not ISN. In my particular case it wont be! Theoretically i understand that the latter is the desired behaviour but do implementations actually do that when sending a MaxAge LSA (scan thru the Rxmt lists, etc and block the origination!) > > > > > Given the granularity of this timer (and maybe > some > > others too!) isnt it a little difficult to achieve > > sub-second convergence? > > This OSPF constant can delay convergence but it > is more a factor with router LSAs. For external > LSAs, > I think you want some holddown between originations > and I don't think 5 seconds is unreasonable. But this timer is applied for all the LSAs .. including the Router LSA. AS-External-LSA was just an example which i was taking .. Has anyone thought on these lines or is there some work which has been done over this. I for one would certainly be interested in knowing more about it. Regards, Rohit __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Sun Feb 23 23:53:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21182 for ; Sun, 23 Feb 2003 23:53:12 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.008FE209@cherry.ease.lsoft.com>; 23 Feb 2003 23:57:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 654858 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 23 Feb 2003 23:57:02 -0500 Received: from 203.199.83.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 23 Feb 2003 23:57:02 -0500 Received: (qmail 6166 invoked by uid 510); 24 Feb 2003 04:56:35 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 24 feb 2003 04:56:35 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030224045635.6165.qmail@webmail32.rediffmail.com> Date: Mon, 24 Feb 2003 04:56:35 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: NSSA RFC - draft 11 (differences) To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Is there any difference between NSSA draft 11 and NSSA RFC 3101 as per protocol functionality? Or NSSA draft 11 is made into standard RFC 3101?? thanks, krishna On Mon, 24 Feb 2003 Rohit Gupta wrote : >Acee, > > > > Externally, origination should appear as the latter. > > However, keep in mind that the only time flooding > > can be suppressed is if an LSA is MaxAged while > > waiting MinLSInterval to expire AND the sequence > > number is the initial sequence number (0x80000001). > >And what if its not ISN. In my particular case it wont >be! > >Theoretically i understand that the latter is the >desired behaviour but do implementations actually do >that when sending a MaxAge LSA (scan thru the Rxmt >lists, etc and block the origination!) > > > > > > > > > Given the granularity of this timer (and maybe > > some > > > others too!) isnt it a little difficult to achieve > > > sub-second convergence? > > > > This OSPF constant can delay convergence but it > > is more a factor with router LSAs. For external > > LSAs, > > I think you want some holddown between originations > > and I don't think 5 seconds is unreasonable. > >But this timer is applied for all the LSAs .. >including the Router LSA. AS-External-LSA was just an >example which i was taking .. > >Has anyone thought on these lines or is there some >work which has been done over this. > >I for one would certainly be interested in knowing >more about it. > >Regards, >Rohit > > > > > >__________________________________________________ >Do you Yahoo!? >Yahoo! Tax Center - forms, calculators, tips, more >http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 24 01:50:14 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22965 for ; Mon, 24 Feb 2003 01:50:14 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.008FE317@cherry.ease.lsoft.com>; Mon, 24 Feb 2003 1:54:05 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 655083 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 24 Feb 2003 01:54:05 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Feb 2003 01:54:05 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1O7FJQ24613 for ; Mon, 24 Feb 2003 12:45:19 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1O7FHt24606 for ; Mon, 24 Feb 2003 12:45:17 +0530 References: <20030221083820.23863.qmail@web20705.mail.yahoo.com> <024e01c2d988$eac2a680$81c802c0@alok> <3E566718.A26041B3@net.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <035901c2dbd1$cb860140$81c802c0@alok> Date: Mon, 24 Feb 2003 12:25:42 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: different costs! To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list no, i meant the reverse path..the traffic coming back from any router above A and B will take this path ----- Original Message ----- From: Shankar Agarwal To: Sent: Friday, February 21, 2003 11:21 PM Subject: Re: different costs! > I am not sure if i understood you fully. But as far as i know When > Router C advertises its Router LSA it gives only one cost to the > interface that it connects to broadcast network. So i don't think it is > possible to control the traffic just from configuring Router C. We can > make it take router A by configuring it so that the routes that A > advertises happens to have a lower cost then same routes advertised by > B. So Router C will see Router A as the preferred path. > alok wrote: > > > > well... > > "ip ospf cost" should work on BMA.... > > > > and the path computation from one router sees "its cost" not the cost of the > > other guy.. > > so u can give different costs manually...whats wrong with it? > > > > ----- Original Message ----- > > From: Rohit Gupta > > To: > > Sent: Friday, February 21, 2003 2:08 PM > > Subject: Re: different costs! > > > > > Rite ALok .. but my question is HOW do i set the costs > > > for these routers when both of them are on the same > > > ethernet. > > > > > > I know it can be done on p2p links .. but my doubt is > > > in case of ethernet media where theoretically all the > > > nodes should be reachable with the same cost! > > > > > > Isnt it so? > > > > > > Rohit. > > > --- alok wrote: > > > > am not too sure..... > > > > > > > > but i think if cost for R-B is higher than > > > > R-A........ > > > > > > > > in this case traffic coming back towards R-C will be > > > > preferred via R-A (for > > > > any router connected further) above R-A and R-B > > > > etc... > > > > > > > > so u can control the downstream towards R-C that > > > > way > > > > > > > > same as P2P in a way actually.... if you give > > > > different costs on either side > > > > in P2P the same would happen > > > > > > > > > > > > ----- Original Message ----- > > > > From: Rohit Gupta > > > > To: > > > > Sent: Friday, February 21, 2003 12:51 PM > > > > Subject: different costs! > > > > > > > > > > > > > Hi, > > > > > I have a very basic doubt. > > > > > > > > > > ------- ------- > > > > > | R-A | | R-B | > > > > > ------- ------- > > > > > | | > > > > > __|_____________| > > > > > | > > > > > | > > > > > ------ > > > > > |R-C | > > > > > ------ > > > > > > > > > > In this setup i have 3 routers on an ethernet. > > > > From > > > > > Router C's perspective can i assign different > > > > costs to > > > > > reach R-A and R-B? (I know it can be done in p2p > > > > > links). For example, can i somehow assign a cost > > > > to > > > > > reach R-A as 3 and R-B as say, 10, thus making all > > > > my > > > > > traffic to choose R-A as long as its up? > > > > > > > > > > Any answers please? > > > > > > > > > > Regards, > > > > > Rohit > > > > > > > > > > __________________________________________________ > > > > > Do you Yahoo!? > > > > > Yahoo! Tax Center - forms, calculators, tips, more > > > > > http://taxes.yahoo.com/ > > > > > > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Tax Center - forms, calculators, tips, more > > > http://taxes.yahoo.com/ > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Feb 24 17:20:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28519 for ; Mon, 24 Feb 2003 17:20:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.008FF58F@cherry.ease.lsoft.com>; Mon, 24 Feb 2003 17:23:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 656769 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 24 Feb 2003 17:23:57 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 24 Feb 2003 17:23:57 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01KSTI7B0GH68WY0DP@omega7.wr.usgs.gov> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 24 Feb 2003 14:23:54 -0700 (PDT) X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01KSTI7B0HF08WY0DP@omega7.wr.usgs.gov> Date: Mon, 24 Feb 2003 14:23:54 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: NSSA RFC - draft 11 (differences) To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list >Is there any difference between NSSA draft 11 and NSSA RFC 3101 >as per protocol functionality? No. >Or NSSA draft 11 is made into standard RFC 3101?? NSSA draft-ietf-ospf-nssa-update-11.txt was released by the OSPF working group to the IETF review process and, following some minor changes, proceeded through the RFC Editorial process and became NSSA RFC 3101. There are editorial changes, like the renumbering of the TOC, but the protocol functionality is the same. NSSA RFC 3101 reads better than the draft. Pat From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 25 02:54:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19545 for ; Tue, 25 Feb 2003 02:54:20 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0090084D@cherry.ease.lsoft.com>; Tue, 25 Feb 2003 2:58:12 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 658191 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 02:58:12 -0500 Received: from 207.217.120.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Feb 2003 02:58:12 -0500 Received: from user-38lc1ee.dialup.mindspring.com ([209.86.5.206] helo=earthlink.net) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18nZyb-0000sv-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 24 Feb 2003 23:58:10 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E5B191A.5DC2DBD@earthlink.net> Date: Mon, 24 Feb 2003 23:19:54 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: How could OPSFv3 support IPv4 ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit As a way-late two cents added to this discussion.... Why wouldn't you want to have a "single-router" support IPv4 and IPv6 interfaces with respect to OSPF? Thus its IPv4 interface input would be directed to OSPFv2 and v6 to V3.. Just my two cents months late in seeing this discussion thread.. Mitchell Erblich ========================== "Manral, Vishwas" wrote: > > Hi Vincent, > > Actually thinking of it, if we want another bit v4-bit in the router LSA we > can have mixed topology in an area(i.e. some routers supporting IPv4 alone, > some supporting IPv6 alone and some supporting both). In that case we would > have to do seperate SPF per area for each protocol supported. > > Thanks, > Vishwas > > -----Original Message----- > From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] > Sent: Thursday, December 12, 2002 10:44 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: How could OPSFv3 support IPv4 ? > > Hi Vincent, > > I think importing v2 LSA's directly would not be a good idea in this case, > as most of the information other than the IPv4 addresses are already there > in OSPFv3 LSA's. Importing it would make it compulsary for OSPFv3 to > understand OSPFv2 LSA types, besides the entire SPF processing(as well as > LSA generation), would have to change to make use of information contained > in OSPFv2 LSA's. > > Using just the new OSPFv3 LSA's with equivalents for the IPv6 address > containing LSA's, would make the job a lot easier, and we could infact do > the SPF irrespective of protocol, and IPv4/IPv6 address nodes would be added > as stubs on the tree. > > Thanks, > Vishwas > > -----Original Message----- > From: Vincent Jardin [mailto:jardin@6WIND.COM] > Sent: Thursday, December 12, 2002 1:10 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: How could OPSFv3 support IPv4 ? > > Hi Vishwas, > > If we just have some new LSA types instead of the IPv4 mapped IPv6 > address, would it be enough to import the OSPFv2 LSA's within OSPFv3 ? > > Moreover, it could use the scope feature of OSPFv3. > > Vincent > > On Wed, 11 Dec 2002, Acee Lindem wrote: > > > Manral, Vishwas wrote: > > > Hi Yasu, > > > > > > I think you missed "Link-LSA" equivalents. I think they would be > required > > > too !!! > > > > Yup. I think these would be needed too. Also, if we were serious about > this > > I don't think using the IPv4 mapped IPv6 address is the best way to go. It > > would be better to have new LSA types for for IPv4 or with an AF and > generic > > address. > > > > > > > > Thanks, > > > Vishwas > > > > > > -----Original Message----- > > > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > > > Sent: Wednesday, December 11, 2002 7:48 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: How could OPSFv3 support IPv4 ? > > > > > > > > > > > >>I am wondering how OSPFv3 could support IPv4. > > >> > > >>According to the RFC2740, the 24-bit OSPFv3 options field describes the > > >>router capabilities. For example, the R-bit and the V6-bit are used in > > >>order to announce IPv6 forwarding capabilities. However, what's happened > > >>if this V6-bit is clear ? > > > > > > > > > RFC2740's section 2.7 gives the exact answer: > > > > > > V6-bit specializes the R-bit; if the V6-bit is clear an OSPF > > > speaker can participate in OSPF topology distribution without > > > being used to forward IPv6 datagrams. If the R-bit is set and the > > > V6-bit is clear, IPv6 datagrams are not forwarded but diagrams > > > belonging to another protocol family may be forwarded. > > > > > > In routers do not support other protocol family other than IPv6, > > > the router having V6-bit off should be treated as a non-working router > > > from the rest of the network. > > > > > > > > >>If there would be a V4-bit in order to announce the IPv4 capabilities, > > >>how could OSPFv3 be extended in order to support IPv4 like Integrated > > >>ISIS ? > > > > > > > > > You'll need only to define IPv4 version of Intra-Area-Prefix-LSA, > > > Inter-Area-Prefix-LSA, AS-External-LSA. Using IPv6 address holding > > > embedded IPv4 address is another option. I guess IPv4-mapped will be > > > the right choice semantically in that case, but it may not be > > > accepted as I saw someone states "IPv4-mapped address should not > > > appear on the wire" somewhere. I believe it means as IP source or > > > destination, though. > > > > > > regards, > > > yasu > > > > Acee > > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 25 04:29:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21636 for ; Tue, 25 Feb 2003 04:29:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00900B06@cherry.ease.lsoft.com>; Tue, 25 Feb 2003 4:33:38 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 658379 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 04:33:38 -0500 Received: from 194.250.197.211 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Feb 2003 04:33:37 -0500 Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 604055E1 for ; Tue, 25 Feb 2003 10:47:10 +0100 (CET) Received: from 6wind.com (jardin.dev.6wind.com [10.16.0.239]) by intranet.6wind.com (Postfix) with ESMTP id A56F74EC for ; Tue, 25 Feb 2003 10:35:34 +0100 (CET) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en, en-us MIME-Version: 1.0 References: <3E5B191A.5DC2DBD@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E5B39DD.5040604@6wind.com> Date: Tue, 25 Feb 2003 10:39:41 +0100 Reply-To: Mailing List Sender: Mailing List From: Vincent Jardin Organization: http://www.6wind.com/ Subject: Re: How could OPSFv3 support IPv4 ? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E5B191A.5DC2DBD@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Of course, "IPv4 interface input" is directed to OSPFv2 and "IPv6 interface input" is directed to OSPFv3. It is related to the constructor support of IPv4 and IPv6. For example, when a socket API is supported, OSPFv2 and OSPFv3 are using respectively INET and INET6 socket. When you are setting IPv4 and IPv6 routing on a same interface with OSPF, both OSPFv2 and OSPFv3 have to be provisionned because they are 2 different protocols. Regards, Vincent Erblichs wrote: >As a way-late two cents added to this discussion.... > >Why wouldn't you want to have a "single-router" support IPv4 >and IPv6 interfaces with respect to OSPF? Thus its IPv4 >interface input would be directed to OSPFv2 and v6 to V3.. > >Just my two cents months late in seeing this discussion thread.. > >Mitchell Erblich >========================== > >"Manral, Vishwas" wrote: > > >>Hi Vincent, >> >>Actually thinking of it, if we want another bit v4-bit in the router LSA we >>can have mixed topology in an area(i.e. some routers supporting IPv4 alone, >>some supporting IPv6 alone and some supporting both). In that case we would >>have to do seperate SPF per area for each protocol supported. >> >>Thanks, >>Vishwas >> >>-----Original Message----- >>From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] >>Sent: Thursday, December 12, 2002 10:44 AM >>To: OSPF@DISCUSS.MICROSOFT.COM >>Subject: Re: How could OPSFv3 support IPv4 ? >> >>Hi Vincent, >> >>I think importing v2 LSA's directly would not be a good idea in this case, >>as most of the information other than the IPv4 addresses are already there >>in OSPFv3 LSA's. Importing it would make it compulsary for OSPFv3 to >>understand OSPFv2 LSA types, besides the entire SPF processing(as well as >>LSA generation), would have to change to make use of information contained >>in OSPFv2 LSA's. >> >>Using just the new OSPFv3 LSA's with equivalents for the IPv6 address >>containing LSA's, would make the job a lot easier, and we could infact do >>the SPF irrespective of protocol, and IPv4/IPv6 address nodes would be added >>as stubs on the tree. >> >>Thanks, >>Vishwas >> >>-----Original Message----- >>From: Vincent Jardin [mailto:jardin@6WIND.COM] >>Sent: Thursday, December 12, 2002 1:10 AM >>To: OSPF@DISCUSS.MICROSOFT.COM >>Subject: Re: How could OPSFv3 support IPv4 ? >> >>Hi Vishwas, >> >>If we just have some new LSA types instead of the IPv4 mapped IPv6 >>address, would it be enough to import the OSPFv2 LSA's within OSPFv3 ? >> >>Moreover, it could use the scope feature of OSPFv3. >> >>Vincent >> >>On Wed, 11 Dec 2002, Acee Lindem wrote: >> >> >> >>>Manral, Vishwas wrote: >>> >>> >>>>Hi Yasu, >>>> >>>>I think you missed "Link-LSA" equivalents. I think they would be >>>> >>>> >>required >> >> >>>>too !!! >>>> >>>> >>>Yup. I think these would be needed too. Also, if we were serious about >>> >>> >>this >> >> >>>I don't think using the IPv4 mapped IPv6 address is the best way to go. It >>>would be better to have new LSA types for for IPv4 or with an AF and >>> >>> >>generic >> >> >>>address. >>> >>> >>> >>>>Thanks, >>>>Vishwas >>>> >>>>-----Original Message----- >>>>From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] >>>>Sent: Wednesday, December 11, 2002 7:48 PM >>>>To: OSPF@DISCUSS.MICROSOFT.COM >>>>Subject: Re: How could OPSFv3 support IPv4 ? >>>> >>>> >>>> >>>> >>>> >>>>>I am wondering how OSPFv3 could support IPv4. >>>>> >>>>>According to the RFC2740, the 24-bit OSPFv3 options field describes the >>>>>router capabilities. For example, the R-bit and the V6-bit are used in >>>>>order to announce IPv6 forwarding capabilities. However, what's happened >>>>>if this V6-bit is clear ? >>>>> >>>>> >>>>RFC2740's section 2.7 gives the exact answer: >>>> >>>> V6-bit specializes the R-bit; if the V6-bit is clear an OSPF >>>> speaker can participate in OSPF topology distribution without >>>> being used to forward IPv6 datagrams. If the R-bit is set and the >>>> V6-bit is clear, IPv6 datagrams are not forwarded but diagrams >>>> belonging to another protocol family may be forwarded. >>>> >>>>In routers do not support other protocol family other than IPv6, >>>>the router having V6-bit off should be treated as a non-working router >>>>from the rest of the network. >>>> >>>> >>>> >>>> >>>>>If there would be a V4-bit in order to announce the IPv4 capabilities, >>>>>how could OSPFv3 be extended in order to support IPv4 like Integrated >>>>>ISIS ? >>>>> >>>>> >>>>You'll need only to define IPv4 version of Intra-Area-Prefix-LSA, >>>>Inter-Area-Prefix-LSA, AS-External-LSA. Using IPv6 address holding >>>>embedded IPv4 address is another option. I guess IPv4-mapped will be >>>>the right choice semantically in that case, but it may not be >>>>accepted as I saw someone states "IPv4-mapped address should not >>>>appear on the wire" somewhere. I believe it means as IP source or >>>> destination, though. >>>> >>>>regards, >>>>yasu >>>> >>>> >>>Acee >>> >>> >>> From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 25 06:23:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23642 for ; Tue, 25 Feb 2003 06:23:43 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00900E47@cherry.ease.lsoft.com>; Tue, 25 Feb 2003 6:27:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 658799 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 06:27:36 -0500 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Feb 2003 06:27:36 -0500 Received: from user-2ivfntd.dialup.mindspring.com ([165.247.223.173] helo=earthlink.net) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18ndFH-0005Gb-00 for ospf@discuss.microsoft.com; Tue, 25 Feb 2003 03:27:35 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E5B49F2.DD16EB39@earthlink.net> Date: Tue, 25 Feb 2003 02:48:18 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hey guys, I got a request for subsecond timer support in OSPFv2 and V3, that hopefully follows the reasoning that was suggested in the ISIS subsecond timer draft. Thus, I was interested to know whether I have missed an existing experimental or information draft suggesting a possible impliemtation of subsecond timer support within OSPF. Mitchell Erblich Network / OS Software Engineer From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 25 06:47:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25080 for ; Tue, 25 Feb 2003 06:47:20 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00900EE3@cherry.ease.lsoft.com>; Tue, 25 Feb 2003 6:51:12 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 658874 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 06:51:12 -0500 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Feb 2003 06:51:12 -0500 Received: from user-2ivfntd.dialup.mindspring.com ([165.247.223.173] helo=earthlink.net) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18ndc6-0007V7-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 03:51:11 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <3E4A8536.43135FC1@earthlink.net> <3E4A8CF8.A0A4858E@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E5B4F72.80ACC10E@earthlink.net> Date: Tue, 25 Feb 2003 03:11:46 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Update.. Num of Nbrs and MTU size in hello pkts : OSPFv2 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Update, Clarification... Due to belief that the Don't Fragment IP option is set in an environment, has anyone one done a multiple router-id support within a single router within the OSPF environment? This type of mod was done in the ISIS where the ID was a limitation.. This should / could support a subset of router-ids per hello, where each hello pkt xmit'ed from a single interface. Thus, the combination of 2 hellos will cover the sum of adj's if said router were to to become both a DR and the BDR. If three of more separate hellos would be needed, then the virtual router ids should specify a priority that results in non DR / BDR election.. If we were to become a DRother, we should prevent a DR and a BDR from forming adj with multiple virtual router ids. Comments... (and I am ducking :) )... Mitchell Erblich ==================== Acee Lindem wrote: > > Erblichs wrote: > > > > Group, > > > > I guess you could say that I have a dumb question. > > > > If a DR wanted to support say 400+ adjs with a standard > > Ethernet 1.5 MTU, is it acceptable to send out more > > than 1 hello describing all of its nbrs? > > > > Note: each nbr id would consume 4 bytes and thus > > the length of the 1 pkt would be greater than MTU size. > > > > I am assuming that 2 pkts per hello interval would > > be transmitted. > > Erblichs, > > This won't work. Based the neighbor FSM, the neighbors will all go to > One-Way state when they receive the hello packet not including them in > the hello packet. Better to let the IP stacks fragment and > reassemble. > > > > > It is that I just don't remember any RFC describing > > this condition. > > > > Pointers please... > > > > Thanks, > > > > Mitchell Erblich > > Sr. Software Engineer > > ` ====================== > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 25 07:08:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26651 for ; Tue, 25 Feb 2003 07:08:43 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00900DB9@cherry.ease.lsoft.com>; Tue, 25 Feb 2003 7:12:35 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 658908 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 07:12:35 -0500 Received: from 216.136.226.174 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Feb 2003 07:12:35 -0500 Received: from [210.118.108.254] by web20701.mail.yahoo.com via HTTP; Tue, 25 Feb 2003 04:12:05 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030225121205.49852.qmail@web20701.mail.yahoo.com> Date: Tue, 25 Feb 2003 04:12:05 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: cc: erblichs@EARTHLINK.NET To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E5B49F2.DD16EB39@earthlink.net> Precedence: list Erblichs, The reason that the existing timers have been kept in O(secs) is to avoid any instability which may be introduced due to transient perturbations inside the network. If you go and change these timers rightaway then obviously there will be a lot of problems introduced. How we can deal with them is an issue by itself though! BTW has there been any work done on changing these timers to milli-secs and studying OSPF's behaviour? I guess its time the OSPF WG charter did something about it !!! Rohit --- Erblichs wrote: > Hey guys, > > I got a request for subsecond timer support > in OSPFv2 and V3, that > hopefully follows the reasoning that was > suggested in the ISIS > subsecond timer draft. > __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 25 07:34:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27748 for ; Tue, 25 Feb 2003 07:34:26 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00900F1A@cherry.ease.lsoft.com>; Tue, 25 Feb 2003 7:38:18 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 658944 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 07:38:18 -0500 Received: from 164.107.115.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Feb 2003 07:38:18 -0500 Received: from eta.cis.ohio-state.edu (daemon@eta.cis.ohio-state.edu [164.107.112.62]) by cis.ohio-state.edu (8.11.6/8.11.6) with ESMTP id h1PCcHM09688 for ; Tue, 25 Feb 2003 07:38:17 -0500 (EST) Received: from localhost (mukul@localhost) by eta.cis.ohio-state.edu (8.11.6/8.11.6) with ESMTP id h1PCcHE10668 for ; Tue, 25 Feb 2003 07:38:17 -0500 (EST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Tue, 25 Feb 2003 07:38:17 -0500 Reply-To: Mailing List Sender: Mailing List From: mukul goyal Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030225121205.49852.qmail@web20701.mail.yahoo.com> Precedence: list We have studied the impact on OSPF (fast failure detection versus number of false alarms) of reducing the Hello Interval to lower values. This is a simulation based analysis performed on a number of IP backbone topologies. The paper will be published in ICC 2003. Here is a link to one draft of the paper: http://www.cis.ohio-state.edu/~mukul/icc.pdf Thanks, Mukul > BTW has there been any work done on changing these > timers to milli-secs and studying OSPF's behaviour? > > I guess its time the OSPF WG charter did something > about it !!! > > Rohit > --- Erblichs wrote: > > Hey guys, > > > > I got a request for subsecond timer support > > in OSPFv2 and V3, that > > hopefully follows the reasoning that was > > suggested in the ISIS > > subsecond timer draft. > > > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 25 10:31:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03455 for ; Tue, 25 Feb 2003 10:31:16 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00901511@cherry.ease.lsoft.com>; Tue, 25 Feb 2003 10:35:09 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 659316 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 10:35:09 -0500 Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Feb 2003 10:35:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 25 Feb 2003 10:34:57 -0500 Reply-To: Mailing List Sender: Mailing List From: Jeff Parker Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > I got a request for subsecond timer support in OSPFv2 > and V3, that follows the reasoning that was suggested > in the ISIS subsecond timer draft. > > Mitchell Erblich Mitchell - As one of the folks involved in the subsecond timer knobs in IS-IS, let me just point out that the topic is quite controversial. Briefly, if the CPU load goes up, many architectures will not be able to support sub-second dead times, leading to dropped hellos, unneeded drops of adjacencies, LSA churn, added SPF runs, and greater CPU load throughout the network, yada yada yada. We can claim that these implementations are broken, but that will not make the problem go away. Any effort in this direction should be taken with care. I hope you wore your asbestos shorts today. - jeff parker - axiowave networks From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 25 14:16:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11331 for ; Tue, 25 Feb 2003 14:16:37 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00901B72@cherry.ease.lsoft.com>; Tue, 25 Feb 2003 14:20:23 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 660572 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 14:20:23 -0500 Received: from 171.71.163.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Feb 2003 14:10:23 -0500 Received: from cisco.com (erosen-u10.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h1PJAM56025058; Tue, 25 Feb 2003 11:10:22 -0800 (PST) User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: <200302251910.h1PJAM56025058@sj-msg-core-1.cisco.com> Date: Tue, 25 Feb 2003 14:10:22 -0500 Reply-To: Mailing List Sender: Mailing List From: Eric Rosen Subject: draft-rosen-ospf-2547bis-dn-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This draft arose out of some PPVPN work; it proposes to use one of the hitertho unused LSA Options bits for a particular purpose when a number of OSPF network segments are connected together via an L3VPN backbone. Hopefully the draft provides adequate context. Your comments are welcome. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 25 14:38:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12023 for ; Tue, 25 Feb 2003 14:38:06 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00901D6B@cherry.ease.lsoft.com>; Tue, 25 Feb 2003 14:41:58 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 660701 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 14:41:58 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Feb 2003 14:41:58 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 8DB1520250; Wed, 26 Feb 2003 04:41:56 +0900 (JST) References: <3E5998C3.8030301@redback.com> <20030224042631.90276.qmail@web20707.mail.yahoo.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030226.044155.123802670.yasu@sfc.wide.ad.jp> Date: Wed, 26 Feb 2003 04:41:55 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Timing of MaxAge LSAs Comments: To: rohitgupta416@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030224042631.90276.qmail@web20707.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit We have studied the relationship between fixed-timer protocol feature (MinLSInterval, MinLSArrival) and the route flaps. The copy of our paper can be retrieved at: http://www.sfc.wide.ad.jp/~yasu/saint2003.pdf Manav and I submitted the paper to the workshop of Saint2003. The paper is efficient in that the new correlation between OSPF protocol and convergence property was found. I agree that we all knew the fact that fixed-timer can affect adversely to convergence, but I guess we did not know how bad the effect is, at least in the way that we described in our paper. The paper is short in that the situation is rare in reality. The configuration of experiment is not like the real network. And the assumption that our paper implicitly has, which is "There should be multiple paths to the identical destination", may be wrong. regards, yasu From: Rohit Gupta Subject: Re: Timing of MaxAge LSAs Date: Sun, 23 Feb 2003 20:26:31 -0800 > Acee, > > > > Externally, origination should appear as the latter. > > However, keep in mind that the only time flooding > > can be suppressed is if an LSA is MaxAged while > > waiting MinLSInterval to expire AND the sequence > > number is the initial sequence number (0x80000001). > > And what if its not ISN. In my particular case it wont > be! > > Theoretically i understand that the latter is the > desired behaviour but do implementations actually do > that when sending a MaxAge LSA (scan thru the Rxmt > lists, etc and block the origination!) > > > > > > > > > Given the granularity of this timer (and maybe > > some > > > others too!) isnt it a little difficult to achieve > > > sub-second convergence? > > > > This OSPF constant can delay convergence but it > > is more a factor with router LSAs. For external > > LSAs, > > I think you want some holddown between originations > > and I don't think 5 seconds is unreasonable. > > But this timer is applied for all the LSAs .. > including the Router LSA. AS-External-LSA was just an > example which i was taking .. > > Has anyone thought on these lines or is there some > work which has been done over this. > > I for one would certainly be interested in knowing > more about it. > > Regards, > Rohit > > > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 25 15:01:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12989 for ; Tue, 25 Feb 2003 15:01:37 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00901D9A@cherry.ease.lsoft.com>; Tue, 25 Feb 2003 15:05:31 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 660811 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 15:05:31 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Feb 2003 15:05:30 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id EA04F20250; Wed, 26 Feb 2003 05:05:28 +0900 (JST) References: <3E5B49F2.DD16EB39@earthlink.net> <20030225121205.49852.qmail@web20701.mail.yahoo.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030226.050528.103933234.yasu@sfc.wide.ad.jp> Date: Wed, 26 Feb 2003 05:05:28 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: To: rohitgupta416@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030225121205.49852.qmail@web20701.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit > The reason that the existing timers have been kept in > O(secs) is to avoid any instability which may be > introduced due to transient perturbations inside the > network. If you go and change these timers rightaway > then obviously there will be a lot of problems > introduced. How we can deal with them is an issue by > itself though! Hi, my take is that the concepts 'millisecond convergence' and 'stability and robustness' are somewhat opposite things in terms of implementation. We have to receive all the up/down events irrelevant of its interval, and then have to calculate how it affects the stability of network. But I believe we have to achieve both concepts at the same time, at least some day. To achieve this, fixed-timer is not enough I guess, and I'm wondering if the fixed-timer exists now is adequate... Do we allow the flaps if it's interval is more than (say) 5 sec ? Wondering if this's informational, and sorry for duplication ;p) but We have studied the relationship between fixed-timer protocol feature (MinLSInterval, MinLSArrival) and the route flaps. The copy of our paper can be retrieved at: http://www.sfc.wide.ad.jp/~yasu/saint2003.pdf Manav and I submitted the paper to the workshop of Saint2003. The paper is efficient in that the new correlation between OSPF protocol and convergence property was found. I agree that we all knew the fact that fixed-timer can affect adversely to convergence, but I guess we did not know how bad the effect is, at least in the way that we described in our paper. The paper is short in that the situation is rare in reality. The configuration of experiment is not like the real network. And the assumption that our paper implicitly has, which is "There should be multiple paths to the identical destination", may be wrong. regards, yasu From: Rohit Gupta Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Date: Tue, 25 Feb 2003 04:12:05 -0800 > Erblichs, > The reason that the existing timers have been kept in > O(secs) is to avoid any instability which may be > introduced due to transient perturbations inside the > network. If you go and change these timers rightaway > then obviously there will be a lot of problems > introduced. How we can deal with them is an issue by > itself though! > > BTW has there been any work done on changing these > timers to milli-secs and studying OSPF's behaviour? > > I guess its time the OSPF WG charter did something > about it !!! > > Rohit > --- Erblichs wrote: > > Hey guys, > > > > I got a request for subsecond timer support > > in OSPFv2 and V3, that > > hopefully follows the reasoning that was > > suggested in the ISIS > > subsecond timer draft. > > > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 25 21:15:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25416 for ; Tue, 25 Feb 2003 21:15:03 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00902930@cherry.ease.lsoft.com>; Tue, 25 Feb 2003 21:18:56 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 661989 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 21:18:56 -0500 Received: from 207.217.120.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Feb 2003 21:18:56 -0500 Received: from user-2ivfk6l.dialup.mindspring.com ([165.247.208.213] helo=earthlink.net) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18nr9q-0000va-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 18:18:55 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <20030225121205.49852.qmail@web20701.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E5C245C.62D63051@earthlink.net> Date: Tue, 25 Feb 2003 18:20:12 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Rohit, I am extremely familair with the tradeoffs. Simply said, I would like to remove even a few seconds loss of convergence dealing with 1Gb or faster links, if I am able to minimize the negative consequences. On systems with 5 or 6 '9s reliability requirements, even a 1 second hello and a 3 sec dead rtr interval doesn't cut it.. The only way I can understand to really do this is to create a new sub-sec heartbeat packet type while keeping the standard hello packet. This newer packet could be effectively empty to minimze size and processing requirements. Legacy systems could just ignore this newer packet type. Then the systems that support this packet type could set an internal bit and track that they are repeatedly seen and use this as a true heart-beat. Mitchell Erblich Sr. Software Engineer Rohit Gupta wrote: > > Erblichs, > The reason that the existing timers have been kept in > O(secs) is to avoid any instability which may be > introduced due to transient perturbations inside the > network. If you go and change these timers rightaway > then obviously there will be a lot of problems > introduced. How we can deal with them is an issue by > itself though! > > BTW has there been any work done on changing these > timers to milli-secs and studying OSPF's behaviour? > > I guess its time the OSPF WG charter did something > about it !!! > > Rohit > --- Erblichs wrote: > > Hey guys, > > > > I got a request for subsecond timer support > > in OSPFv2 and V3, that > > hopefully follows the reasoning that was > > suggested in the ISIS > > subsecond timer draft. > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Tue Feb 25 22:14:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26253 for ; Tue, 25 Feb 2003 22:14:02 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00902A6F@cherry.ease.lsoft.com>; Tue, 25 Feb 2003 22:17:56 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 662187 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 25 Feb 2003 22:17:55 -0500 Received: from 65.86.17.254 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 25 Feb 2003 22:17:55 -0500 Received: from subdimension.com ([192.168.0.4]) by subdimension.com ; Tue, 25 Feb 2003 22:30:12 -0500 X-Mailer: WebMAIL to Mail Gateway v3.0h Priority: normal X-DSMTPFooter: true X-Rcpt-To: Message-ID: <3e5c3286.1f8.1804289383@subdimension.com> Date: Wed, 26 Feb 2003 03:20:38 GMT Reply-To: Mailing List Sender: Mailing List From: Paul Jak Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > Hi, my take is that the concepts 'millisecond convergence' and > 'stability and robustness' are somewhat opposite things in terms > of implementation. We have to receive all the up/down events > irrelevant of its interval, and then have to calculate > how it affects the stability of network. very true .. > > But I believe we have to achieve both concepts at the same time, > at least some day. To achieve this, fixed-timer is not enough > I guess, and I'm wondering if the fixed-timer exists now is > adequate... Do we allow the flaps if it's interval is more than > (say) 5 sec ? Infact now that you have brought this out let me also sound in my concerns. I have always been wondering as to how we arrived at this sacrosanct figure of 5 secs (MinLSUpdate Interval) for damping any up/down events. The reason i belive it was decided upon this was coz the CPUs in those times were not fast enough and if you had an entity changing @ < 5secs .. you could crash your system with the heavy processing load you would incur by running the SPF each time. I believe things have changed now and if we truly want millisecs convergence then we need to do away with these timers. I found your logic (in your paper) quite good and i think it looks like the only feasible solution wherein if there is an entity which changes too rapidly (wherein the value of "too rapidly" could mean differently to different people) then you somehow suppress that ! But why do you only look for AS-External-LSAs being suppresses. Could this logic not be extended to Router LSAs and other LSAs too? Or has this been kept for future work? > The paper is efficient in that the new correlation between OSPF protocol > and convergence property was found. I agree that we all knew the fact > that fixed-timer can affect adversely to convergence, but I guess > we did not know how bad the effect is, at least in the way that > we described in our paper. > > The paper is short in that the situation is rare in reality. you do have a lot of redundant links in a network so it isnt sooo rare! > The configuration of experiment is not like the real network. > And the assumption that our paper implicitly has, which is > "There should be multiple paths to the identical destination", > may be wrong. Again .. if you have redundant links then you would have multiple paths to an identical destination with one having a better cost than the other one so that its always the preffered one. I think its time that the OSPF ADs look up and draw something in the charter which says something about doing something in OSPF for millisecs convergence! I see a lot of papers coming up on the same but they somehow get lost and nobody seems to know of what happens to them! Just my two cents. Paul _____________________________________________________________________ // free anonymous email || forums \\ subZINE || anonymous browsing subDIMENSION -- http://www.subdimension.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 00:09:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29027 for ; Wed, 26 Feb 2003 00:09:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0090307C@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 0:13:49 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 662656 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 00:13:48 -0500 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 00:13:48 -0500 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Feb 2003 10:43:45 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <60F922ABE8BE9C428E806F43C0EC73680B33C3@HARITHA> Date: Wed, 26 Feb 2003 10:43:43 +0530 Reply-To: Mailing List Sender: Mailing List From: "Jeyanath Minto J - CTD, Chennai." Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list hi Rohit, have a look on this draft. http://www.ietf.org/internet-drafts/draft-kompella-rag-plp-00.txt Cheers Minto -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Wednesday, February 26, 2003 7:50 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Rohit, I am extremely familair with the tradeoffs. Simply said, I would like to remove even a few seconds loss of convergence dealing with 1Gb or faster links, if I am able to minimize the negative consequences. On systems with 5 or 6 '9s reliability requirements, even a 1 second hello and a 3 sec dead rtr interval doesn't cut it.. The only way I can understand to really do this is to create a new sub-sec heartbeat packet type while keeping the standard hello packet. This newer packet could be effectively empty to minimze size and processing requirements. Legacy systems could just ignore this newer packet type. Then the systems that support this packet type could set an internal bit and track that they are repeatedly seen and use this as a true heart-beat. Mitchell Erblich Sr. Software Engineer Rohit Gupta wrote: > > Erblichs, > The reason that the existing timers have been kept in > O(secs) is to avoid any instability which may be > introduced due to transient perturbations inside the > network. If you go and change these timers rightaway > then obviously there will be a lot of problems > introduced. How we can deal with them is an issue by > itself though! > > BTW has there been any work done on changing these > timers to milli-secs and studying OSPF's behaviour? > > I guess its time the OSPF WG charter did something > about it !!! > > Rohit > --- Erblichs wrote: > > Hey guys, > > > > I got a request for subsecond timer support > > in OSPFv2 and V3, that > > hopefully follows the reasoning that was > > suggested in the ISIS > > subsecond timer draft. > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 00:55:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29803 for ; Wed, 26 Feb 2003 00:55:31 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00903283@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 0:59:26 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 662775 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 00:59:25 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 00:59:24 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 92894201D8; Wed, 26 Feb 2003 14:59:23 +0900 (JST) References: <3e5c3286.1f8.1804289383@subdimension.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030226.145922.122328603.yasu@sfc.wide.ad.jp> Date: Wed, 26 Feb 2003 14:59:22 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: To: paul_j1@SUBDIMENSION.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3e5c3286.1f8.1804289383@subdimension.com> Precedence: list Content-Transfer-Encoding: 7bit > But why do you only look for AS-External-LSAs being > suppresses. Could this logic not be extended to Router LSAs > and other LSAs too? Or has this been kept for future work? It has just been kept for the future work ;p) About the origination and acceptance of LSA, Router-LSAs are not an exception. But the flapping of LSA existense for the same Router-LSA/Network-LSA will be done by the granularity of HelloInterval (typically 10 sec), because those includes establishing of adjacencies. I thought that the case Router-LSA or Network-LSA flaps by the rate of subsecond, is more rare case than that case of AS-External-LSA (because origination/flushing of AS-External-LSA can be triggered by L2 link up/down, which is likely to be subsecond). Obviously if we make HelloInterval milliseconds, it is possible that Router-LSA flaps in a second. > Again .. if you have redundant links then you would have > multiple paths to an identical destination with one having a > better cost than the other one so that its always the > preffered one. Agreed, but I meant that it is rare where multiple routers originate LSAs for the same routes. Changing path to a certain link ------------------- is another scenario, similar to the Router-LSA case described above. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 01:15:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00083 for ; Wed, 26 Feb 2003 01:15:16 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.009033BD@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 1:19:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 662807 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 01:19:10 -0500 Received: from 203.254.224.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 01:19:10 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAW00401K5YG9@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 15:17:58 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAW0023HK5XC8@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 15:17:57 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAW00KMYKTLIO@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 15:32:16 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3e5c3286.1f8.1804289383@subdimension.com> <20030226.145922.122328603.yasu@sfc.wide.ad.jp> Message-ID: <0b1401c2dd5e$d06bb860$b4036c6b@sisodomain.com> Date: Wed, 26 Feb 2003 11:47:58 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Adding a little more to what Yasu has already said. > It has just been kept for the future work ;p) This paper in its current state is very generic and takes only an example of an AS-External-LSA which is flapping, but the same techniques can definitely be applied on a Router LSAs/etc. One could also apply damping in cases where there are lost HELLOs because of say, congestion in the link/Overloaded Router. If a router finds that it is periodically timing out HELLOs from one particular router then it can choose to damp that adjaceny. It can start accepting the HELLOs once it finds that the link/Router has now somewhat stablized. These extensions really come into play once when we start envisaging a network will timers of milli-secs granularities/etc. Regards, Manav From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 02:36:18 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27122 for ; Wed, 26 Feb 2003 02:36:18 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0090371E@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 2:40:11 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 662998 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 02:40:11 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 02:40:11 -0500 Received: (qmail 30035 invoked from network); 26 Feb 2003 07:40:10 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 26 Feb 2003 07:40:10 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030225121205.49852.qmail@web20701.mail.yahoo.com> <3E5C245C.62D63051@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E5C6F37.4060306@xebeo.com> Date: Wed, 26 Feb 2003 08:39:35 +0100 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: >Rohit, > > I am extremely familair with the tradeoffs. > > Discussion has been had many times, almost everybody having built those protocols and deployed them in on a larger scale shares the opinion that this is best solved by a link-layer mechanism. Of course it may work on a 3-boxes-in-a-triangle-all-properly-hacked-up scenario but then, OSPF is not your ideal tool to solve the problem and something more light-weight may be needed. thanks - tony > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 03:44:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28346 for ; Wed, 26 Feb 2003 03:44:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00903879@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 3:48:14 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663121 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 03:48:14 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 03:48:13 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 83C5420250; Wed, 26 Feb 2003 17:48:11 +0900 (JST) References: <20030225121205.49852.qmail@web20701.mail.yahoo.com> <3E5C245C.62D63051@earthlink.net> <3E5C6F37.4060306@xebeo.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030226.174811.112777204.yasu@sfc.wide.ad.jp> Date: Wed, 26 Feb 2003 17:48:11 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: To: prz@XEBEO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E5C6F37.4060306@xebeo.com> Precedence: list Content-Transfer-Encoding: 7bit Hi. > Discussion has been had many times, almost everybody having built > those protocols and deployed them in on a larger scale shares the > opinion that this is best solved by a link-layer mechanism. Of course I don't think that this is best solved by a link-layer. Who do you mean by "everybody" ? At least in the OSPF ML there were some objections to that, IIRC. > it may work on a 3-boxes-in-a-triangle-all-properly-hacked-up > scenario but then, OSPF is not your ideal tool to solve the problem > and something more light-weight may be needed. Why do you think L3 scheme is heavy ? L3's flap detection will be done at various point independently. I don't think it's heavy. I believe that there certainly exist the cases where L2 up and L3 down. L3 reachability should be detected in L3, similar way of thinking which is employed in ships-in-the-night. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 04:30:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29124 for ; Wed, 26 Feb 2003 04:30:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009038F8@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 4:34:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663229 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 04:34:17 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 04:34:17 -0500 Received: (qmail 1743 invoked from network); 26 Feb 2003 09:34:16 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 26 Feb 2003 09:34:16 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030225121205.49852.qmail@web20701.mail.yahoo.com> <3E5C245C.62D63051@earthlink.net> <3E5C6F37.4060306@xebeo.com> <20030226.174811.112777204.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E5C89F6.9080900@xebeo.com> Date: Wed, 26 Feb 2003 10:33:42 +0100 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yasuhiro Ohara wrote: >Hi. > > > >>Discussion has been had many times, almost everybody having built >>those protocols and deployed them in on a larger scale shares the >>opinion that this is best solved by a link-layer mechanism. Of course >> >> > >I don't think that this is best solved by a link-layer. > of course you're entitled to your opinios as I am to mine. I don't insist link-layer as in MAC is necessary the absolute solution but e.g. the new Kireeti draft or LMP or things that Russ was showing for ethernet recently could be a possibility. I'm saying OSPF hellos are not the way to achieve what you all seem to desperately seek. > Who do you mean >by "everybody" ? At least in the OSPF ML there were some objections >to that, IIRC. > read the archives of OSPF/IS-IS groups and meeting minutes of presentations, e.g. by Cengiz. And the 'objections' raised on OSPF ML were raised not by people that have significant experience in large scale deployments of OSPF (at least to my knowledge). > > > >>it may work on a 3-boxes-in-a-triangle-all-properly-hacked-up >>scenario but then, OSPF is not your ideal tool to solve the problem >>and something more light-weight may be needed. >> >> > >Why do you think L3 scheme is heavy ? > Because I did it couple times on different processors/different operating systems with different link-speeds and amounts of memory (probably going 10-1000x speedup and size factor during the years) and despite having done it smarter every time (of course, there may be people who did it way better than me but those to step forward then), millisecond link-state timers with reasoanble numbers of adjacencies (dozens) with reasonable load on the control-plane don't work very well in real deployments. Let me give you one example: if you generate every 100msecs a hello for let's say 30 adjacencies, this is 300 hellos per second in each direction and couple of hundreds context switches (if running OSPF process). If you have an SPF going, it means that you either have to implement SPF in a way that does run concurrently to the rest of OSPF, doable but not trivial (pretty soon the locking overhead starts to slow things down considerable and code complexity goes up tremendously) or otherwise make sure that your SPF gives up every 30 msecs or so (to do the timering/helloeing well). Now, 30msecs in control plane starts to smell like trashing. So, you start to 'batch up' the hello processing so you do many helloes in/out every 300msecs for example. But then you defeat the purpose and have to deal with interesting quantization effects. Of course, you can put helloes 'exploded' on the input/output blades but then you need a synchronization mechanims to make sure OSPF on main controller is not letting 'loose i/o blades' live in case it hick-ups. Which just shifts the problem into another synchronization domain (if you do it in OSPF< same problems, otherwise you just invented a 'link-layer-box-internal-protocol' which is what I argue for in first case ;-). And so on ... Now, what's the gain vs. e.g. using the light-out on the fiber or some low-layer keep-alive mechanism (e.g. LCP) to detect the link-down ? See what interesting corner the RSVP people painted themselves into by doing the fast-refreshes (before recent hacks that basically grain up the timer resolution for things to work) and RSVP guts are way simpler than a working OSPF. Arguably, if you consider just OSPF in separation on a discrete-event simulator, probably with time-dilution, things don't look that way but it is unfortunately not the real-product world. So if you find someone to pay for this research, you arguably 'won' and things arguably 'work' and we can agree that we disagree on what 'works' means. I rest my case -- tony From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 04:46:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29279 for ; Wed, 26 Feb 2003 04:46:25 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00903702@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 4:50:19 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663276 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 04:50:19 -0500 Received: from 62.241.160.193 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 04:50:19 -0500 Received: from tom3 (userbm66.uk.uudial.com [62.188.145.18]) by pengo.systems.pipex.net (Postfix) with SMTP id 6DCDF4C00372 for ; Wed, 26 Feb 2003 09:50:17 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <00a201c2dd7c$28590100$0301a8c0@tom3> Date: Wed, 26 Feb 2003 09:36:07 -0000 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I am with Tony on this one, that layer 2 problems should be solved at layer 2; layer 3 may now be faster than when OSPF first appeared but it is still orders of magnitude slower than layer 2 (and in Enterprise networks, the 68000 chipset of a major router manufacturere remains slow:-). Historically, a similar problem appeared when moving from analog to digital circuits so that network operators could and did report outages of O(mS) duration which previously had gone unnoticed or caused a checksum failure and retransmission. Attempts to solve that in layer 3 were a cure worse than disease and the correct solution was to change layer 2 so that 'incidents' were counted but not always acted upon by layer three. We need a better layer 2 algorithm to tell us whether this outage is worth reconfiguring for or not, and yes that has impacts on flow control and buffering (eg my 2G4bit/s link is down for 100uS, do I buffer the data, flag congestion, teminated the sessions etc?). And conversely, because this mailing list contains the world's greatest expertise in OSPF, we should take care not to assume that OSPF is the right answer, what's that question? Tom Petch -----Original Message----- From: Yasuhiro Ohara To: OSPF@DISCUSS.MICROSOFT.COM Date: 26 February 2003 08:48 Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 >Hi. > >> Discussion has been had many times, almost everybody having built >> those protocols and deployed them in on a larger scale shares the >> opinion that this is best solved by a link-layer mechanism. Of course > >I don't think that this is best solved by a link-layer. Who do you mean >by "everybody" ? At least in the OSPF ML there were some objections >to that, IIRC. > >> it may work on a 3-boxes-in-a-triangle-all-properly-hacked-up >> scenario but then, OSPF is not your ideal tool to solve the problem >> and something more light-weight may be needed. > >Why do you think L3 scheme is heavy ? L3's flap detection will be >done at various point independently. I don't think it's heavy. > >I believe that there certainly exist the cases where L2 up and L3 down. >L3 reachability should be detected in L3, similar way of thinking >which is employed in ships-in-the-night. > >regards, >yasu From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 04:48:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29329 for ; Wed, 26 Feb 2003 04:48:39 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0090376D@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 4:52:33 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663295 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 04:52:33 -0500 Received: from 207.217.120.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 04:52:33 -0500 Received: from user-38lc164.dialup.mindspring.com ([209.86.4.196] helo=earthlink.net) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18nyEp-00062M-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 01:52:32 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E5C8DD9.54DBB517@earthlink.net> Date: Wed, 26 Feb 2003 01:50:17 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mukal, THANKS, got it and did a quick read of the paper.. I disagree with the set-up, implimentation, and conclusion of the paper for the following reasons: 1) A proper way to impliment a "sub-second hello interval" is really to suppliment the current second hello protocol with a "heartbeat packet". Why? A) It limits the size of the packet to basicly a echo request / reply (ping) with a OSPF header. Note: failure detection time includes the overhead to process failure detection pkts. (aka hello pkts). B) This removes the requirement to process the nbr list within the hello pkt. B 1-n) Various chksums, authentications, could be optional to reduce overhead processing and prevent the heartbeat from possibly causing congestion due to a hello that could be up to a 9k size jumbo Ethernet frame. C) Legacy systems can ignore the new packet type code. D) Under extended congestion, the hello interval can still be used. E) We are able to specify a rtr dead interval of 4* that would not be a multiple of second units. The suggested values could be anywhere from 1 to 999 millisecs. This in effect is the transmit interval of the heartbeat pkt. F) If our router clocks are synchronized (have the same times), then we are able to identify the latency of the media or whether collisions are occuring within the media and rexmit backoff algorithms need finer granularity, by including a timestamp within the pkt ; ala ping.. 2) Related work. The heartbeat packet can be queued and processed independently. Why? At "dead interval time frames", the quantity of incoming heartbeat packets can be noted and this number of packets processed. Any normally speaking heartbeat rtr that hasn't sent a heartbeat pkt, could minimally be noted as undergoing some form of congestion and longer RxmitIntervals involving this rtr could be employed. If we share information with other protocols (BGP) we may have an alternative route to temporarily decrease the number of pkts transiting this congested rtr. 3) If our time to process a SPF calcualtion for a LSA quantity is a fraction of a second, there is no need to support multiple sec spfDelays and spfHoldTimes. 4) Assuming the the #3 above spf times are kept with their secs default values, if a false alarm occurs within the spfHoldTime, and then clears, resulting in a non- delta change. Then no additional spf calculation will occur. Actually, during the spfHoldTime, nbrs could be marked as questionable and processed as dead nbrs, only if a heartbeat isn't seen. 5) The hello interval and heartbeat is on a per link / circuit and should only be set to sub-second values with known trusted, normally highly reliable systems. These systems by default are less likely to be overcome by congestion. I am assming here that heartbeats control adj teardowns. 6) Lastly for this short email.. The existance of sub-second heartbeat informs destination systems that it is still up and it is not congested... Thus, loss of one or more heartbeats is an indication of some issue within the system that can be tracked and responded to, possibly even before congestion occurs.. 7) Depending on the repetive nature of lossed heartbeats, adj's could still be marked up (we are still recieving at least 1 hello per rtrdeadinterval) but in a degraded state... Mitchell Erblich Sr Network Software Engineer ============= ============= mukul goyal wrote: > > We have studied the impact on OSPF (fast failure detection versus > number of false alarms) of reducing the Hello Interval to lower values. > This is a simulation based analysis performed on a number of IP > backbone topologies. The paper will be published in ICC 2003. Here is a > link to one draft of the paper: > > http://www.cis.ohio-state.edu/~mukul/icc.pdf > > Thanks, > Mukul > > > BTW has there been any work done on changing these > > timers to milli-secs and studying OSPF's behaviour? > > > > I guess its time the OSPF WG charter did something > > about it !!! > > > > Rohit > > --- Erblichs wrote: > > > Hey guys, > > > > > > I got a request for subsecond timer support > > > in OSPFv2 and V3, that > > > hopefully follows the reasoning that was > > > suggested in the ISIS > > > subsecond timer draft. > > > > > > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 05:37:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00256 for ; Wed, 26 Feb 2003 05:37:00 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00903A3C@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 5:40:55 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663383 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 05:40:54 -0500 Received: from 203.254.224.33 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 05:40:54 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAW00K01WA75I@mailout3.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 19:39:43 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAW00E4TWA7TT@mailout3.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 19:39:43 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAW005UVWXZ94@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 19:54:02 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030225121205.49852.qmail@web20701.mail.yahoo.com> <3E5C245C.62D63051@earthlink.net> <3E5C6F37.4060306@xebeo.com> <20030226.174811.112777204.yasu@sfc.wide.ad.jp> <3E5C89F6.9080900@xebeo.com> Message-ID: <0c8f01c2dd83$63b38980$b4036c6b@sisodomain.com> Date: Wed, 26 Feb 2003 16:09:47 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT I believe this thread was initiated in an effort to realize sub-second convergence or milli-secs convergence for OSPF (this could apply easily to IS-IS also!). Current standards call for implementations to support these timers in O(secs). With the ISPs requirements for SLAs increasing aggressively and the current paranoia people have for faster convergence a lot of people think that there should be something done at the IGP level. MinLSUpdate/MinLSArrival/etc timers restrict your convergence timings and people are basically looking for different ways to over come these problems. One is of reducing these to O(ms). Everybody is aware of the problems this could bring in (i will not rehash them here in the list!) and people are trying to look for solutions. Obviously when you bring down these timers to O(ms) we cant just leave the Hello interval hanging in mid air with granularity in secs. This too comes down to O(ms). Now we need to look into how we can mitigate the ill effects of doing this. Nobody is saying that you just bring down your HELLO to O(ms). What we need to remember is that we are trying to bring down all the timers to this fine granularity! How we need to schedule SPF is a different issue though! Am open to flames! :-) Regards, Manav P.S. I personally feel that there is a lot more that can be done in hardware to bring down our convergence timings before we start tinkering around with the IGPs. But that shouldn't put somebody on hold if he/she wants to do something at L3!! ----- Original Message ----- From: "Tom Petch" To: Sent: Wednesday, February 26, 2003 3:06 PM Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 > I am with Tony on this one, that layer 2 problems should be solved at > layer 2; layer 3 may now be faster than when OSPF first appeared but > it is still orders of magnitude slower than layer 2 (and in Enterprise > networks, the 68000 chipset of a major router manufacturere remains > slow:-). Historically, a similar problem appeared when moving from > analog to digital circuits so that network operators could and did > report outages of O(mS) duration which previously had gone unnoticed From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 06:17:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01104 for ; Wed, 26 Feb 2003 06:17:29 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00903B6E@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 6:21:23 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663826 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 06:21:22 -0500 Received: from 62.241.160.193 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 06:21:22 -0500 Received: from tom3 (userbp29.uk.uudial.com [62.188.146.24]) by pengo.systems.pipex.net (Postfix) with SMTP id D79C94C002E3 for ; Wed, 26 Feb 2003 11:21:20 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <000801c2dd88$e0d8f1c0$0301a8c0@tom3> Date: Wed, 26 Feb 2003 11:18:54 -0000 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Two thoughts. We need to be more precise about our timeframes for all relevant factors. And we may need to split the standard into two for enterprise (the primary objective historically?) and for operator. Take an enterprise WAN; 2Mbit/s links, link propagation delay O(10mS), I would expect most outages to be layer 2 failures in the public network, would expect notifications to come from L2 and not Hellos, would ignore a L2 outage under 20mS, think of subsecond as being O(0.3s) (because ChampCar drivers excepted, that is as fast as humans respond) and regard convergence within 5s as ok although 1s might be nice to have. And when I saw in one case that SPF has run over 4000 times in the past month, I heave a sigh of relief that we have a 5s delay. An operator with 2G4bit/s links may see the world as 10 or 100 times faster, but we should still start with a view of what outages there are, how fast they are notified, how they are notified, etc etc Tom Petch nwnetworks@dial.pipex.com -----Original Message----- From: Manav Bhatia To: OSPF@DISCUSS.MICROSOFT.COM Date: 26 February 2003 10:40 Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 I believe this thread was initiated in an effort to realize sub-second convergence or milli-secs convergence for OSPF (this could apply easily to IS-IS also!). Current standards call for implementations to support these timers in O(secs). With the ISPs requirements for SLAs increasing aggressively and the current paranoia people have for faster convergence a lot of people think that there should be something done at the IGP level. MinLSUpdate/MinLSArrival/etc timers restrict your convergence timings and people are basically looking for different ways to over come these problems. One is of reducing these to O(ms). Everybody is aware of the problems this could bring in (i will not rehash them here in the list!) and people are trying to look for solutions. Obviously when you bring down these timers to O(ms) we cant just leave the Hello interval hanging in mid air with granularity in secs. This too comes down to O(ms). Now we need to look into how we can mitigate the ill effects of doing this. Nobody is saying that you just bring down your HELLO to O(ms). What we need to remember is that we are trying to bring down all the timers to this fine granularity! How we need to schedule SPF is a different issue though! Am open to flames! :-) Regards, Manav P.S. I personally feel that there is a lot more that can be done in hardware to bring down our convergence timings before we start tinkering around with the IGPs. But that shouldn't put somebody on hold if he/she wants to do something at L3!! From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 06:52:17 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01710 for ; Wed, 26 Feb 2003 06:52:17 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00903C1A@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 6:56:11 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663887 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 06:56:11 -0500 Received: from 164.107.115.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 06:56:11 -0500 Received: from zeta.cis.ohio-state.edu (daemon@zeta.cis.ohio-state.edu [164.107.112.46]) by cis.ohio-state.edu (8.11.6/8.11.6) with ESMTP id h1QBuAM23874 for ; Wed, 26 Feb 2003 06:56:10 -0500 (EST) Received: from localhost (mukul@localhost) by zeta.cis.ohio-state.edu (8.11.6/8.11.6) with ESMTP id h1QBuAo27574 for ; Wed, 26 Feb 2003 06:56:10 -0500 (EST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 26 Feb 2003 06:56:10 -0500 Reply-To: Mailing List Sender: Mailing List From: mukul goyal Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E5C8DD9.54DBB517@earthlink.net> Precedence: list Mitchell, The paper in question basically says that reducing the HelloInterval arbitrarily to very small values can have significant destabilizing impact on the OSPF operation in the network. Missed Hellos will translate into false breakdowns of adjancencies which along with subsequent reestablishment of the adjacencies increases the OSPF processing loads, possibly cause unnecessary SPFs and even lead to catastrophic situations in some cases. The conclusion of the paper is that the HelloInterval can usually be reduced to a much smaller value than 10s, however, an appropriate value for a particular network depends on a number of factors including the size of the network (i.e. area) and the expected congestion levels on the links. On Wed, 26 Feb 2003, Erblichs wrote: > I disagree with the set-up, implimentation, and conclusion > of the paper for the following reasons: > Please be more specific regarding exactly what are the things you disagree with. > 1) A proper way to impliment a "sub-second hello interval" > is really to suppliment the current second hello protocol > with a "heartbeat packet". > Could you send me a reference for the "second hello protocol" you are talking about? > Why? > A) It limits the size of the packet to basicly a > echo request / reply (ping) with a OSPF header. > Note: failure detection time includes the overhead > to process failure detection pkts. > (aka hello pkts). > > B) This removes the requirement to process the nbr > list within the hello pkt. > > B 1-n) Various chksums, authentications, could be > optional to reduce overhead processing and > prevent the heartbeat from possibly causing > congestion due to a hello that could be up > to a 9k size jumbo Ethernet frame. > > C) Legacy systems can ignore the new packet type code. OK. The "heartbeat" may have a lower processing time than that of a typical LSA. However, my impression (based on the OSPF black box measurement work of Aman Shaikh) is that the per-packet handling times constitute the major portion of the total processing times. I am not sure if not doing the authentications etc. will cause any security concerns. In any case, the heartbeat/Hello processing time is not the real issue. The issue is : As we reduce the hello/heartbeat interval, there is an increased probability that several consecutive heartbeats will be lost due to a congestion on the link or the router will not be able to process a heartbeat before the expiry of the routerdeadinterval (which will also decrease alongwith the HelloInterval). > > D) Under extended congestion, the hello interval can > still be used. > ?? Please clarify. > E) We are able to specify a rtr dead interval of 4* that > would not be a multiple of second units. The suggested > values could be anywhere from 1 to 999 millisecs. This > in effect is the transmit interval of the heartbeat pkt. > If I understand it correctly, you are saying that the router dead interval can be assigned values in the millisecond range based on the heartbeat interval (4 times heartbeat interval). I am not clear how does it influence the problem I mentioned earlier. > > 2) Related work. The heartbeat packet can be queued and processed > independently. > > Why? At "dead interval time frames", the quantity of incoming > heartbeat packets can be noted and this number of packets > processed. Any normally speaking heartbeat rtr that hasn't > sent a heartbeat pkt, could minimally be noted as undergoing > some form of congestion and longer RxmitIntervals involving > this rtr could be employed. If we share information with other > protocols (BGP) we may have an alternative route to temporarily > decrease the number of pkts transiting this congested rtr. How will the heartbeats avoid getting queued behind a whole lot of other packets or getting dropped because of buffer overflows before the router has a chance to know that these are heartbeats? Adjusting the timer values according to the congestion level will definitely make subsecond hellos more acceptable provided that we can achieve a very mature understanding of how this adjustment should be done. I think there are several concerns in this regard. > > 3) If our time to process a SPF calcualtion for a LSA quantity > is a fraction of a second, there is no need to support > multiple sec spfDelays and spfHoldTimes. My understanding is that a major stability related concern is to keep the OSPF processing load within limits. Even if SPF does not take as much time as it used to take earlier, SPF will be a concern especially for large areas. I think spfDelay and spfHoldTime are important for stability. They may be significantly reduced but perhaps should not be eliminated altogether. However, this is a complete problem in itself which needs to be treated separately for now. The bottomline is that there will be one situation or the other where the router will be busy doing other things and won't be able to attend to millisecond Hellos or heartbeats in time to avoid false alarms. > > 4) Assuming the the #3 above spf times are kept with their > secs default values, if a false alarm occurs within > the spfHoldTime, and then clears, resulting in a non- > delta change. Then no additional spf calculation will occur. > Actually, during the spfHoldTime, nbrs could be marked > as questionable and processed as dead nbrs, only if > a heartbeat isn't seen. One of the potentially several reasons why we need large enough spfHoldTime. I do talk about this in the paper. > > 5) The hello interval and heartbeat is on a per link / circuit > and should > only be set to sub-second values with known trusted, > normally highly reliable systems. > These systems by default are less likely to be overcome by > congestion. I am assming here that heartbeats control adj > teardowns. Here, you seem to be agreeing with me that congestion should be a factor in deciding the HelloInterval to be used on the link. > > 6) Lastly for this short email.. > The existance of sub-second heartbeat informs destination systems > that it is still up and it is not congested... Thus, loss of one > or more heartbeats is an indication of some issue within the system > that can be tracked and responded to, possibly even before > congestion > occurs.. Fine. No arguments here. Loss of occasional heartbeat/Hello is not a problem. The problem is, I repeat, that as you increase the heartbeat/Hello frequency and (hence) reduce the routerdeadinterval, there is an increasing likelihood that multiple hearbeats will be dropped or won't get timely processing thus causing frequent false alarms. > > 7) Depending on the repetive nature of lossed heartbeats, adj's could > still be marked up (we are still recieving at least 1 hello per > rtrdeadinterval) but in a degraded state... > OK. My overall impression is that you are simply calling a subsecond Hello as a heartbeat. This does not change the basic concerns about the possibilities of false alarms. Mukul Goyal > Mitchell Erblich > Sr Network Software Engineer > > ============= > ============= > > > > > > mukul goyal wrote: > > > > We have studied the impact on OSPF (fast failure detection versus > > number of false alarms) of reducing the Hello Interval to lower values. > > This is a simulation based analysis performed on a number of IP > > backbone topologies. The paper will be published in ICC 2003. Here is a > > link to one draft of the paper: > > > > http://www.cis.ohio-state.edu/~mukul/icc.pdf > > > > Thanks, > > Mukul > > > > > BTW has there been any work done on changing these > > > timers to milli-secs and studying OSPF's behaviour? > > > > > > I guess its time the OSPF WG charter did something > > > about it !!! > > > > > > Rohit > > > --- Erblichs wrote: > > > > Hey guys, > > > > > > > > I got a request for subsecond timer support > > > > in OSPFv2 and V3, that > > > > hopefully follows the reasoning that was > > > > suggested in the ISIS > > > > subsecond timer draft. > > > > > > > > > > > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Yahoo! Tax Center - forms, calculators, tips, more > > > http://taxes.yahoo.com/ > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 07:24:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02341 for ; Wed, 26 Feb 2003 07:24:16 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00903C19@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 7:28:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663997 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 07:28:10 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 07:28:09 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 79476201D8; Wed, 26 Feb 2003 21:28:08 +0900 (JST) References: <3E5C6F37.4060306@xebeo.com> <20030226.174811.112777204.yasu@sfc.wide.ad.jp> <3E5C89F6.9080900@xebeo.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030226.212807.00986828.yasu@sfc.wide.ad.jp> Date: Wed, 26 Feb 2003 21:28:07 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: To: prz@XEBEO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E5C89F6.9080900@xebeo.com> Precedence: list Content-Transfer-Encoding: 7bit Hi. First thank you for your valuable message. I feel I saw a lot of things from this and I guess I understand your opinion more or less. I admit I'm less experienced, but I'm not convinced yet. First of my consideration is that if we made L2 detection available, the failure detected by L2 only will be sufficient at millisecond level ? I don't know how many percent of failure occuring in the real world can be detected by L2 only. If some failures which can be detected only by L3 exist (sure I believe those exist), then L3 detection at millisecond level will be necessary anyway, isn't it ? It is obvious that if we detect failure by L3 at millisecond level, we'll be able to find all the failure in subsecond. If we fails to detect some of the failure, we get not so robust network. Second is about the control traffic load of Hello. In your example of 100ms hello interval on 30 adjacencies, the load will be 403.2Kbps, even with calculating standard OSPF hello format (which may be somewhat redundant). I guess this cost is worthy to pay, in order to get robust and fast convergence network. I agree the context switching and scheduling of OSPF tasks will be a consideration. But is it already achieved by vendor hardware routers ? I think it more easy way such as "install CPUs as many as necessary", because I'm not hardware engineer ;p) sorry. I don't understand the synchronization problem you're saying. I understand that the control-plane only won't be able to handle huge number of Hellos by itself. I will want "Hello-dedicated Blade" or something. But what is the problem with notifying from hello-dedicated-blade to control-plane, apart from the similar one happens when notifying from L2-detection-box/blade to OSPF router/process ? Is there any particular problem that L3 detection will have but L2 detection will not have, without restricting how they implemented ? Am I totally missing the point ? I will learn about how RSVP and other L2 detection works. I agree L2 detection will be more light and faster than L3. But what we need is L3 failure detection, and it can only be acheived completely by L3 detection. I guess we should take millisecond level L3 detection rather than nanosecond level L2 detection. regards, yasu From: Tony Przygienda Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Date: Wed, 26 Feb 2003 10:33:42 +0100 > Yasuhiro Ohara wrote: > > >Hi. > > > > > > > >>Discussion has been had many times, almost everybody having built > >>those protocols and deployed them in on a larger scale shares the > >>opinion that this is best solved by a link-layer mechanism. Of course > >> > >> > > > >I don't think that this is best solved by a link-layer. > > > of course you're entitled to your opinios as I am to mine. I don't > insist link-layer as in > MAC is necessary the absolute solution but e.g. the new Kireeti draft or > LMP or things > that Russ was showing for ethernet recently could be a possibility. I'm > saying OSPF > hellos are not the way to achieve what you all seem to desperately seek. > > > Who do you mean > >by "everybody" ? At least in the OSPF ML there were some objections > >to that, IIRC. > > > read the archives of OSPF/IS-IS groups and meeting minutes of > presentations, e.g. > by Cengiz. And the 'objections' raised on OSPF ML were raised not by > people that have > significant experience in large scale deployments of OSPF (at least to > my knowledge). > > > > > > > > >>it may work on a 3-boxes-in-a-triangle-all-properly-hacked-up > >>scenario but then, OSPF is not your ideal tool to solve the problem > >>and something more light-weight may be needed. > >> > >> > > > >Why do you think L3 scheme is heavy ? > > > Because I did it couple times on different processors/different > operating systems with different > link-speeds and amounts of memory (probably going 10-1000x speedup and > size factor during the > years) and despite having done it smarter every time (of course, > there may be people who did it way better than me but those to step > forward then), millisecond > link-state timers with reasoanble numbers of adjacencies (dozens) with > reasonable load on > the control-plane don't work very well in real deployments. Let me give > you one example: if you generate every 100msecs a > hello for let's say 30 adjacencies, this is 300 hellos per second in > each direction and couple of > hundreds context switches (if running OSPF process). If you have an SPF > going, it means that > you either have to implement SPF in a way that does run concurrently to > the rest of OSPF, > doable but not trivial (pretty soon the locking overhead starts to slow > things down considerable > and code complexity goes up tremendously) or otherwise make sure that > your SPF gives up > every 30 msecs or so (to do the timering/helloeing well). Now, 30msecs > in control plane starts > to smell like trashing. So, you start to 'batch up' the hello processing > so you do many helloes in/out > every 300msecs for example. But then you defeat the purpose and have to > deal with interesting > quantization effects. Of course, you can put helloes 'exploded' on the > input/output blades but then > you need a synchronization mechanims to make sure OSPF on main > controller is not letting > 'loose i/o blades' live in case it hick-ups. Which just shifts the > problem into another synchronization > domain (if you do it in OSPF< same problems, otherwise you just invented > a 'link-layer-box-internal-protocol' > which is what I argue for in first case ;-). > And so on ... Now, what's the gain vs. e.g. using the light-out on the > fiber or some low-layer > keep-alive mechanism (e.g. LCP) to detect the link-down ? See what > interesting corner the RSVP > people painted themselves into by doing the fast-refreshes (before > recent hacks that basically grain up the > timer resolution for things to work) and RSVP guts are way simpler than > a working OSPF. > > Arguably, if you consider just OSPF in separation on a discrete-event > simulator, probably with time-dilution, > things don't look that way but it is unfortunately not the real-product > world. So if you find someone to > pay for this research, you arguably 'won' and things arguably 'work' and > we can agree that we disagree on > what 'works' means. > > I rest my case > > -- tony From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 07:38:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02580 for ; Wed, 26 Feb 2003 07:38:01 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00903E53@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 7:41:55 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664094 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 07:41:54 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 07:41:54 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1QD3JQ27152 for ; Wed, 26 Feb 2003 18:33:19 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1QD3Ft27146 for ; Wed, 26 Feb 2003 18:33:16 +0530 References: <3E5C6F37.4060306@xebeo.com> <20030226.174811.112777204.yasu@sfc.wide.ad.jp> <3E5C89F6.9080900@xebeo.com> <20030226.212807.00986828.yasu@sfc.wide.ad.jp> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <0a7001c2dd94$bb6ee320$81c802c0@alok> Date: Wed, 26 Feb 2003 18:13:24 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list pardon my interrupting, from a lay man's perspective my 1 cent's worth... > First of my consideration is that if we made L2 detection available, > the failure detected by L2 only will be sufficient at millisecond > level ? I don't know how many percent of failure occuring > in the real world can be detected by L2 only. If some failures which > can be detected only by L3 exist (sure I believe those exist), then > L3 detection at millisecond level will be necessary anyway, isn't it ? > It is obvious that if we detect failure by L3 at millisecond level, > we'll be able to find all the failure in subsecond. If we fails > to detect some of the failure, we get not so robust network. for L2 detection.... i have some questions... how long is it that when an interface goes down, does the kernel report it? is it instantaneous? i mean i lost clock for a microsec and i came back up.. does it filter up immediately?or is there "a delay" to see if its really down there too? if it is instantaneous, could the routing daemon "lag" this by as many seconds rather than send out packets to test it? > > Second is about the control traffic load of Hello. In your example of > 100ms hello interval on 30 adjacencies, the load will be 403.2Kbps, > even with calculating standard OSPF hello format (which may be somewhat > redundant). I guess this cost is worthy to pay, in order to get > robust and fast convergence network. ?????????? err no, ISPs are usually not that accomodating in the developer's favour :-) > > I agree the context switching and scheduling of OSPF tasks will be > a consideration. But is it already achieved by vendor hardware routers ? > I think it more easy way such as "install CPUs as many as necessary", > because I'm not hardware engineer ;p) sorry. > > I don't understand the synchronization problem you're saying. > I understand that the control-plane only won't be able to handle > huge number of Hellos by itself. I will want "Hello-dedicated Blade" > or something. But what is the problem with notifying from > hello-dedicated-blade to control-plane, apart from the similar one > happens when notifying from L2-detection-box/blade > to OSPF router/process ? Is there any particular problem that L3 detection > will have but L2 detection will not have, without restricting > how they implemented ? Am I totally missing the point ? choking up the bandwidth is a good point (are u saying those hellos are out of band)? > > I will learn about how RSVP and other L2 detection works. > I agree L2 detection will be more light and faster than L3. > But what we need is L3 failure detection, and it can only be acheived > completely by L3 detection. I guess we should take millisecond level > L3 detection rather than nanosecond level L2 detection. fine i need faster hellos on BMA networks. why? coz there is multicast happening, the only way i know that a router is out is either if "the arp is out and doesnt come back in" or i miss hellos and there we have "sufficent bandwidth" coz i assume BMA is primarily ethernet...and no one runs ospf on "extended lans" via media convertors...i hope (hell if u have a router put in a serial link) but on P2P, line protocol/PPP down is a good enuf bet to imply the other end is down. why do we need L3 there? From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 08:32:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03900 for ; Wed, 26 Feb 2003 08:32:12 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00903DDD@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 8:36:05 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664192 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 08:36:04 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 08:36:04 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id E976C201D8; Wed, 26 Feb 2003 22:36:02 +0900 (JST) References: <3E5C89F6.9080900@xebeo.com> <20030226.212807.00986828.yasu@sfc.wide.ad.jp> <0a7001c2dd94$bb6ee320$81c802c0@alok> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030226.223602.27612795.yasu@sfc.wide.ad.jp> Date: Wed, 26 Feb 2003 22:36:02 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: To: alok.dube@APARA.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <0a7001c2dd94$bb6ee320$81c802c0@alok> Precedence: list Content-Transfer-Encoding: 7bit > for L2 detection.... > i have some questions... > how long is it that when an interface goes down, does the kernel report it? > is it instantaneous? i mean i lost clock for a microsec and i came back up.. > does it filter up immediately?or is there "a delay" to see if its really > down there too? > if it is instantaneous, could the routing daemon "lag" this by as many > seconds rather than send out packets to test it? I don't know how they intend to do but some kind of flap damping technology as in BGP route flap damping will be necessary, at L2 level. > > Second is about the control traffic load of Hello. In your example of > > 100ms hello interval on 30 adjacencies, the load will be 403.2Kbps, > > even with calculating standard OSPF hello format (which may be somewhat > > redundant). I guess this cost is worthy to pay, in order to get > > robust and fast convergence network. > > ?????????? err no, ISPs are usually not that accomodating in the developer's > favour :-) agreed ;p) > choking up the bandwidth is a good point do you mean the router's backplane by "bandwidth" ? > (are u saying those hellos are out of band)? I mean Hello calculation must not necessarily be done on control-plane. Hello packet will be on the band, as far as I said. and yes, 400K may be too much. But, the size 400K is not caused by the fact that it's on L3, it's caused by the fact that I calculated without changing standard Hello packet. If we make sufficient L2 detection, we need some kind of packet format, which includes some kind of identifier, etc. Obviously detecting the electricity is not enough, because we cascades many LAN switches. > fine i need faster hellos on BMA networks. > why? coz there is multicast happening, the only way i know that a router is > out is either if "the arp is out and doesnt come back in" or i miss hellos > and there we have "sufficent bandwidth" coz i assume BMA is primarily ethernet... you mean most of your failures are L2, isn't it ? that's OK. but how much you have sufficient bandwidth ? don't you have extra 400K bandwidth ? ;p) > and no one runs ospf on "extended lans" via media convertors...i > hope (hell if u have a router put in a serial link) > but on P2P, line protocol/PPP down is a good enuf bet to imply the other end > is down. why do we need L3 there? - L2 detection is not so better than L3 detection, if both made by hardware - L3 detection is (thought you're saying none) a little bit better than L2 deteciton - you must develop a detection method for each of L2 technology (again I don't believe electricity checking is not enough) regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 09:09:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05804 for ; Wed, 26 Feb 2003 09:09:31 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00903FB9@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 9:13:25 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664337 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 09:13:24 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 09:13:24 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1QEYnQ29445 for ; Wed, 26 Feb 2003 20:04:49 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1QEYlt29429 for ; Wed, 26 Feb 2003 20:04:48 +0530 References: <3E5C89F6.9080900@xebeo.com> <20030226.212807.00986828.yasu@sfc.wide.ad.jp> <0a7001c2dd94$bb6ee320$81c802c0@alok> <20030226.223602.27612795.yasu@sfc.wide.ad.jp> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <0d6701c2dda1$838b1ac0$81c802c0@alok> Date: Wed, 26 Feb 2003 19:45:11 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > > fine i need faster hellos on BMA networks. > > why? coz there is multicast happening, the only way i know that a router is > > out is either if "the arp is out and doesnt come back in" or i miss hellos > > and there we have "sufficent bandwidth" coz i assume BMA is primarily ethernet... > > you mean most of your failures are L2, isn't it ? that's OK. > but how much you have sufficient bandwidth ? > don't you have extra 400K bandwidth ? ;p) > > i meant ethernet doesnt cost me money but wan links do. i can do L3 on ethernet..... for that matter that 400k is fine there (with the old hellos and reduced timers) u can reduce the size of those hellos on L3 for WAN stuff...my only doubt is if it is required on WAN links. -rgds Alok serial is up line protocol is down. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Feb 26 17:45:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00342 for ; Wed, 26 Feb 2003 17:45:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00905235@cherry.ease.lsoft.com>; Wed, 26 Feb 2003 17:49:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666416 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26 Feb 2003 17:49:36 -0500 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 26 Feb 2003 17:49:36 -0500 Received: from smirtoraw2k02 (dhcp-171-69-101-89.cisco.com [171.69.101.89]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id h1QMnZr06800 for ; Wed, 26 Feb 2003 14:49:35 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0273_01C2DDA6.4795E270" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Message-ID: <027201c2dde9$55b92270$596545ab@amer.cisco.com> Date: Wed, 26 Feb 2003 14:49:35 -0800 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: I-D ACTION:draft-mirtorabi-ospfv3-af-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0273_01C2DDA6.4795E270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks This draft introduce the support of address-family in OSPFv3, your comments are welcome Thanks Sina --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Support of address families in OSPFv3 Author(s) : S. Mirtorabi, M. Barnes, A. Roy Filename : draft-mirtorabi-ospfv3-af-00.txt Pages : 7 Date : 2003-2-14 This document describes an extensible mechanism to support Address Families in OSPFv3. One undefined field in the Router-LSA is used to define the address-families on a link. A router may participate in multiple address families on different links. This information needs to be advertised so that only applicable link are used in the SPF calculation when building an address family specific shortest path tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mirtorabi-ospfv3-af-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mirtorabi-ospfv3-af-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mirtorabi-ospfv3-af-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0273_01C2DDA6.4795E270 Content-Type: Message/External-body; name="ATT00044.dat" Content-Disposition: attachment; filename="ATT00044.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-2-14105136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mirtorabi-ospfv3-af-00.txt ------=_NextPart_000_0273_01C2DDA6.4795E270 Content-Type: Message/External-body; name="draft-mirtorabi-ospfv3-af-00.txt" Content-Disposition: attachment; filename="draft-mirtorabi-ospfv3-af-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-2-14105136.I-D@ietf.org> ------=_NextPart_000_0273_01C2DDA6.4795E270-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 04:51:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23943 for ; Thu, 27 Feb 2003 04:51:29 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00906808@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 4:55:22 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667735 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 04:55:22 -0500 Received: from 207.217.120.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 04:55:22 -0500 Received: from user-2ivfj3n.dialup.mindspring.com ([165.247.204.119] helo=earthlink.net) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18oKl6-0000nO-00; Thu, 27 Feb 2003 01:55:20 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <60F922ABE8BE9C428E806F43C0EC73680B33C3@HARITHA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E5DDBD1.6EFF3278@earthlink.net> Date: Thu, 27 Feb 2003 01:35:13 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: To: kireeti@juniper.net To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, I think I missed why certain items are obmitted from this draft which is very interesting... Just a few items :) And excuse me if I take them out of order: 1) No Cisco proprietary routing protocols are mentioned in 2.2.1 and thus have no bit positions assigned to them. 2) If the sequence number is monotonically increasing, then why isn't the skippage of a value a secondary use (sect, 2.2.1) to determine that either congestion or something is occuring? 3) If a skipped value is somehow removing a protocol from being monitored, then we have lost that knowledge forever and it in effect will not be removed. Thus, in my opinion certain messages should be acked to verify that that they have been recieved. OR that if only two systems are undergoing a conversation, shouldn't they in turn be increasing this sequence number, which implies that the earlier one was seen. If the value isn't acked via one of the earlier two methods, then it could be resent. 4) Due to the fact that only monitoring is enabled or disabled (turn off and turned on), wouldn't it make sense to be able to be able to report a level of degraded status with a particular protocol? Also, if the above converstaion is done, timestamps could also be used to determine rtt (round trip times). 5) bottom of 2.1.. "prepared to deal with fragmentation and reassembly". Assuming that this occurs, wouldn't it make sense that out-of-order situation to occur that could delay IP from sending up a complete packet until the microsecond timeframe has expired? Assuming H == D. 6) 2.2.1 : specified in microseconds. Wouldn't a third use of sending seccesive packets with say a 1 us time frame with a specified size result in being able to test a links bandwidth capacity, plus buffering capacity to determine the likelyhood of a dropped packet in the future. This could be done on links before the routing protocols are actually brought up. Is this valid without specifying even ONE protocol and without a UP or DOWN notfification? 7) 3.2 3. PlPm then sets a timer T to expire in H microseconds .. Interesting... If the timer goes off and this packet is sent on a half-duplex Ethernet and a collsion occurs, wouldn't a jamm, then a backoff algorthm defer the transmit of the packet possibly beyond the time frame and thus the intended reciver(s) identify one or more protocols as falsely being down? This is assuming that hello interval is approximately equal to dead interval. "caveat within the 3.2 section where "H should be at most D". What is the timeframe for the 1st backoff on say a 1Gb eth link? 7b) Which brings up a point that nowhere will the reciever be notified what the hello interval is being set at. Maybe I am just going blind. If the sender specifies a hello interval, then the reciever could time seccessive hello packets for jitter, etc.. 8) Isn't the amount of possible parsing overhead of this packet larger than intended with a possibly large size? If we push this to the extreme with a 9k jumbo Ethernet frame, sent every microsecond, then the amount of overhead bandwidth consumption becomes excessive. However, if this packet were kept to a fixed size of say 64ytes, and the "Message" + "Extensions" field were simplified to remove their unknown parsing overhead, then I could expect that a multiple protocol subsecond timer could be effective. 9) Just because you specify a "hello type interval", why wouldn't you want to set the timer in "3.2 3. sets a timer T to expire in", to 1/2 or 1/3 of the "dead" interval. Why not send a hello every 10 us with a dead interval of say 100ms? Shouldn't the added knowledge that a link is undergoing some form or problem be beneficial as long as their is a secondary route? 10) Why would't you allow to have the hello interval negotiated? If a sender was sending the above 9k every 1us on a 100Mb eth link, as a reciver, I think I would want to be able to tell the sender to stop or don't even do it in the first place. 10b) What happens if say A the sender and B the reciever differ in their use of H and D? Could 1-way adj be formed on one side while the other side sees is as a 2-way until a full nbr listing in the regular hello packet shows up (OSPF)? I think that this is probably more than enough of feedback. Hopefully, it is taken and each item thought over and maybe some of these items can evolve the draft. Mitchell Erblich Sr Software Engineer ========================= "Jeyanath Minto J - CTD, Chennai." wrote: > > hi Rohit, > have a look on this draft. > http://www.ietf.org/internet-drafts/draft-kompella-rag-plp-00.txt > > Cheers > Minto > > -----Original Message----- > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > Sent: Wednesday, February 26, 2003 7:50 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 > > Rohit, > > I am extremely familair with the tradeoffs. > > Simply said, I would like to remove even > a few seconds loss of convergence dealing > with 1Gb or faster links, if I am able to > minimize the negative consequences. > > On systems with 5 or 6 '9s reliability > requirements, even a 1 second hello and > a 3 sec dead rtr interval doesn't cut it.. > > The only way I can understand to really > do this is to create a new sub-sec heartbeat > packet type while keeping the standard > hello packet. This newer packet could be > effectively empty to minimze size and > processing requirements. > > Legacy systems could just ignore this > newer packet type. > > Then the systems that support this packet > type could set an internal bit and track > that they are repeatedly seen and use > this as a true heart-beat. > > Mitchell Erblich > Sr. Software Engineer > > Rohit Gupta wrote: > > > > Erblichs, > > The reason that the existing timers have been kept in > > O(secs) is to avoid any instability which may be > > introduced due to transient perturbations inside the > > network. If you go and change these timers rightaway > > then obviously there will be a lot of problems > > introduced. How we can deal with them is an issue by > > itself though! > > > > BTW has there been any work done on changing these > > timers to milli-secs and studying OSPF's behaviour? > > > > I guess its time the OSPF WG charter did something > > about it !!! > > > > Rohit > > --- Erblichs wrote: > > > Hey guys, > > > > > > I got a request for subsecond timer support > > > in OSPFv2 and V3, that > > > hopefully follows the reasoning that was > > > suggested in the ISIS > > > subsecond timer draft. > > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, more > > http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 05:30:53 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24589 for ; Thu, 27 Feb 2003 05:30:53 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0090694B@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 5:34:47 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667920 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 05:34:47 -0500 Received: from 207.217.120.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 05:34:47 -0500 Received: from user-2ivfj3n.dialup.mindspring.com ([165.247.204.119] helo=earthlink.net) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18oLNF-0005SZ-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 02:34:46 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <00a201c2dd7c$28590100$0301a8c0@tom3> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E5DE507.8E544B5@earthlink.net> Date: Thu, 27 Feb 2003 02:14:31 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Come on people, Are you guys telling me that your systems can't handle 300 pings per second while your routers are operating? It shouldn't even increase CPU load by most a few percent. This was Tony's number with 30 nbrs and 100ms intervals. Just because it is subsecond it nature doesn't mean it needs to carry the normal nbr list, etc that is normally encountered with a hello packet. Simplify the amount of work that needs to be done, add a sequence number, a timestamp, as optional processing items. The sequence number tells us that we haven't lost a packet. The timestamp can be read and compared with past / future timestamps to determine the amount of variance that is occuring. Why not decrease multiple second convergence timeframes when you can detect failure or congestion within 1 second? What I am not saying is that we need microsec detection at layer 3, but having a protocol that allows the detection time to decrease to "us" timeframes is intreiging.. (spelling) Mitchell Erblich Sr Software Engineer ============================ Tom Petch wrote: > > I am with Tony on this one, that layer 2 problems should be solved at > layer 2; layer 3 may now be faster than when OSPF first appeared but > it is still orders of magnitude slower than layer 2 (and in Enterprise > networks, the 68000 chipset of a major router manufacturere remains > slow:-). Historically, a similar problem appeared when moving from > analog to digital circuits so that network operators could and did > report outages of O(mS) duration which previously had gone unnoticed > or caused a checksum failure and retransmission. Attempts to solve > that in layer 3 were a cure worse than disease and the correct > solution was to change layer 2 so that 'incidents' were counted but > not always acted upon by layer three. > > We need a better layer 2 algorithm to tell us whether this outage is > worth reconfiguring for or not, and yes that has impacts on flow > control and buffering (eg my 2G4bit/s link is down for 100uS, do I > buffer the data, flag congestion, teminated the sessions etc?). > > And conversely, because this mailing list contains the world's > greatest expertise in OSPF, we should take care not to assume that > OSPF > is the right answer, what's that question? > > Tom Petch > > -----Original Message----- > From: Yasuhiro Ohara > To: OSPF@DISCUSS.MICROSOFT.COM > Date: 26 February 2003 08:48 > Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 > > >Hi. > > > >> Discussion has been had many times, almost everybody having built > >> those protocols and deployed them in on a larger scale shares the > >> opinion that this is best solved by a link-layer mechanism. Of > course > > > >I don't think that this is best solved by a link-layer. Who do you > mean > >by "everybody" ? At least in the OSPF ML there were some objections > >to that, IIRC. > > > >> it may work on a 3-boxes-in-a-triangle-all-properly-hacked-up > >> scenario but then, OSPF is not your ideal tool to solve the problem > >> and something more light-weight may be needed. > > > >Why do you think L3 scheme is heavy ? L3's flap detection will be > >done at various point independently. I don't think it's heavy. > > > >I believe that there certainly exist the cases where L2 up and L3 > down. > >L3 reachability should be detected in L3, similar way of thinking > >which is employed in ships-in-the-night. > > > >regards, > >yasu From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 05:51:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24839 for ; Thu, 27 Feb 2003 05:51:31 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00906BBC@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 5:55:25 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668007 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 05:55:25 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 05:55:25 -0500 Received: (qmail 20371 invoked from network); 27 Feb 2003 10:55:24 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 27 Feb 2003 10:55:24 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <00a201c2dd7c$28590100$0301a8c0@tom3> <3E5DE507.8E544B5@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E5DEE7A.8060102@xebeo.com> Date: Thu, 27 Feb 2003 11:54:50 +0100 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: >Come on people, > >Are you guys telling me that your systems can't handle 300 pings >per second while your routers are operating? It shouldn't even >increase CPU load by most a few percent. > talking about pings vs. OSPF helloes you're in a parallel universe ... >Just because it is subsecond it nature doesn't mean it needs >to carry the normal nbr list, etc that is normally encountered >with a hello packet. > So why do you exactly want this thing in OSPF if it is not an OSPF hello beside trying to make it a kitchen-sink ? > >Simplify the amount of work that needs to be done, add a sequence >number, a timestamp, as optional processing items. The sequence >number tells us that we haven't lost a packet. The timestamp >can be read and compared with past / future timestamps to determine >the amount of variance that is occuring. > translates to me into 'build some lower layer keepalive', look at Kireetis draft. --- tony From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 06:11:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25277 for ; Thu, 27 Feb 2003 06:11:19 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00906D3F@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 6:15:13 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668462 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 06:15:13 -0500 Received: from 207.217.120.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 06:15:13 -0500 Received: from user-2ivfj3n.dialup.mindspring.com ([165.247.204.119] helo=earthlink.net) by mallard.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18oM0N-0001iS-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 03:15:12 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <3e5c3286.1f8.1804289383@subdimension.com> <20030226.145922.122328603.yasu@sfc.wide.ad.jp> <0b1401c2dd5e$d06bb860$b4036c6b@sisodomain.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E5DEE79.9E0FD945@earthlink.net> Date: Thu, 27 Feb 2003 02:54:49 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Bhatia, I need to think about this, but do you only hold back originated LSAs or transit LSAs into an area that only has a single edge rtr? If the route specified is the only route to a specified set of network segments, then what is the negative effect of advertising this flapping route? If the route isn't advertised, then the network segments are blackholed? If the route is advertised and the route is really unreachable, then the transit network segments are consuming wasted bandwidth. The packets will eventually be dropped anyway. If the route is advertised and the route flaps back positive, it will take some time longer than 1/2 of a hello interval once a SPF algorithm removed the route, plus your penalty, plus a new SPF run, plus flooding time.. Thus, if there isn't an alternative route THEN maybe just ignore the lost of the route... Stub areas and stub routes may not want to use the penalty. Mitchell Erblich Sr Software Engineer ======================== Manav Bhatia wrote: > > Adding a little more to what Yasu has already said. > > > It has just been kept for the future work ;p) > > This paper in its current state is very generic and takes only an example > of an AS-External-LSA which is flapping, but the same techniques can > definitely be applied on a Router LSAs/etc. One could also apply damping in > cases where there are lost HELLOs because of say, congestion in the > link/Overloaded Router. If a router finds that it is periodically timing > out HELLOs from one particular router then it can choose to damp that > adjaceny. It can start accepting the HELLOs once it finds that the > link/Router has now somewhat stablized. > > These extensions really come into play once when we start envisaging a > network will timers of milli-secs granularities/etc. > > Regards, > Manav From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 06:45:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25836 for ; Thu, 27 Feb 2003 06:45:18 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0090713F@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 6:49:14 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668605 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 06:49:12 -0500 Received: from 203.254.224.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 06:49:12 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HAY00F01U413E@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 20:48:01 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HAY001Z2U40N8@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 20:48:00 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HAY00I43URWKV@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 21:02:22 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3e5c3286.1f8.1804289383@subdimension.com> <20030226.145922.122328603.yasu@sfc.wide.ad.jp> <0b1401c2dd5e$d06bb860$b4036c6b@sisodomain.com> <3E5DEE79.9E0FD945@earthlink.net> Message-ID: <002401c2de56$176eb440$b4036c6b@sisodomain.com> Date: Thu, 27 Feb 2003 17:18:03 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: cc: Erblichs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Erblichs, Thanks for the comments. If you understand the basic philosophy behind the whole thing then most of these questions are answered by themselves! The understanding is that if an entity is flapping then - you waste cycles running SPF with each flap which can in turn can result in more adjacencies breaking and which may (in the worst case) lead to a total network meltdown. - you waste your bandwidth (no need to explain!) - it (the flapping entity) must pay a price for this! It pays in a sense because we don't use it as long as we gain enough confidence in it that it is now going to function properly! Now i will get on to your specific questions .. > I need to think about this, but do you > only hold back originated LSAs or > transit LSAs into an area that only > has a single edge rtr? Currently we are only looking into the self originated ones and i *think* we should only be doing this for the self originated ones or we can have some scenarios of inconsistent database. > > If the route specified is the only > route to a specified set of network > segments, then what is the negative > effect of advertising this flapping > route? you mean what happens currently .. right? we advertise a flapping entity. well to begin with you waste your bandwidth, clog your processors/etc. Things begin to get a little complicated when these IGP derived routes are being used by BGP to recursively resolve the next-hops. Things can really get very nasty if you are running BGP with thousands of routes and if it is using those OSPF resolved next-hops. Moreover it can get worse if an ISP is using its IGP costs to advertise as its MED! > > If the route isn't advertised, then > the network segments are blackholed? This is one price which a flapping entity *has* to pay! It is given enough opportunities to correct itself (depends upon how the damping parameters are configured!) and if it still doesnt do anything about it then yes .. routes will not be advertised even though its up! > > If the route is advertised and the route > is really unreachable, then the > transit network segments are consuming > wasted bandwidth. The packets will > eventually be dropped anyway. > > If the route is advertised and the route > flaps back positive, it will take some what is "flaps back positive"? you mean it "flaps" ? > time longer than 1/2 of a hello interval > once a SPF algorithm removed the route, > plus your penalty, plus a new SPF run, > plus flooding time.. i couldnt get what you mean by this. > > Thus, if there isn't an alternative route > THEN maybe just ignore the lost of the > route... Stub areas and stub routes may > not want to use the penalty. we need to explore on this. Regards, Manav From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 07:10:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26265 for ; Thu, 27 Feb 2003 07:10:01 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0090732E@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 7:13:56 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668778 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 07:13:56 -0500 Received: from 207.217.120.122 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 07:13:55 -0500 Received: from user-2ivfj3n.dialup.mindspring.com ([165.247.204.119] helo=earthlink.net) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18oMvA-0001ZJ-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 04:13:53 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E5DFC28.5627C2FD@earthlink.net> Date: Thu, 27 Feb 2003 03:53:12 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mukul, I'll try to keep this short because a test of mine just finished at 3:30am. I have yet to see a low end system that I work on that is not designed to accept a slow path ping packet at the rate that would be in excess of 300 per sec. I think the amount of overhead need to process a hello with a nbr list of say 100+ nbrs could be overwhelming. However, since I consider this type of information less likely to change we don't need to tell someone about our view of our neighbors more than the current hello default interval. Decreasing the size of the packet reduces bandwidth requirements and only adds a bit to the packet per second processing overhead needed. I saw a 2+yr old doc that stated high end rtrs with pps speeds in the the millions dealing with 40byte short packets. This is a Spirent doc. A 1 to 4 ratio or hello to rtr dead interval isn't needed when you run with a subsecond heartbeat. Think of the heartbeat like a ping. I would think that 100ms heartbeat interval with a 1 sec dead rtr interval should be a conserative starting value. I am investigating 100x ratios (10ms for the deadbeat, and 1sec for the congestion timer) with my at home network setup starting today. Thus a loss of one or two should not result in the loss of an adj/nbr state. Since we could use a monotonically increasing sequence (see Juniper's paper), and a local time field, then we could see if a heartbeat is delayed, lost, whatever. Now, since we still have a hello packet occuring, if we see that someones heartbeat is eratic, we can slow down our exhange process with him, flood him with fewer updates at a time, etc. And then mark him as CONGESTED or transient down until our 40 sec dead interval has occurred. While we are waiting for the default dead interval to occur we could then follow one or more of the suggested operations in a earlier RFC draft that concentrated on congestion. And could you send me a pointer to the Aman Shaikh black box rtr paper for me to understand his slow path pps issues. Mitchell Erblich Sr Software Engineer ========================= mukul goyal wrote: > > Mitchell, > > The paper in question basically says that reducing the HelloInterval > arbitrarily to very small values can have significant destabilizing impact > on the OSPF operation in the network. Missed Hellos will translate into > false breakdowns of adjancencies which along with > subsequent reestablishment of the adjacencies increases the OSPF > processing loads, possibly cause unnecessary SPFs and even lead to > catastrophic situations in some cases. The conclusion of the paper is > that the HelloInterval can usually be reduced to a much smaller value > than 10s, however, an appropriate value for a particular network depends > on a number of factors including the size of the network (i.e. area) and > the expected congestion levels on the links. > > On Wed, 26 Feb 2003, Erblichs wrote: > > I disagree with the set-up, implimentation, and conclusion > > of the paper for the following reasons: > > > > Please be more specific regarding exactly what are the things you disagree with. > > > 1) A proper way to impliment a "sub-second hello interval" > > is really to suppliment the current second hello protocol > > with a "heartbeat packet". > > > > Could you send me a reference for the "second hello protocol" you are > talking about? > > > Why? > > A) It limits the size of the packet to basicly a > > echo request / reply (ping) with a OSPF header. > > Note: failure detection time includes the overhead > > to process failure detection pkts. > > (aka hello pkts). > > > > B) This removes the requirement to process the nbr > > list within the hello pkt. > > > > B 1-n) Various chksums, authentications, could be > > optional to reduce overhead processing and > > prevent the heartbeat from possibly causing > > congestion due to a hello that could be up > > to a 9k size jumbo Ethernet frame. > > > > C) Legacy systems can ignore the new packet type code. > > OK. The "heartbeat" may have a lower processing time than that of a > typical LSA. However, my impression (based on the OSPF black box > measurement work of Aman Shaikh) is that the per-packet handling times > constitute the major portion of the total processing times. I am not sure > if not doing the authentications etc. will cause any security concerns. In > any case, the heartbeat/Hello processing time is not the real issue. > > The issue is : As we reduce the hello/heartbeat interval, there is an > increased probability that several consecutive heartbeats will be lost due > to a congestion on the link or the router will not be able to process a > heartbeat before the expiry of the routerdeadinterval (which will also > decrease alongwith the HelloInterval). > > > > D) Under extended congestion, the hello interval can > > still be used. > > > > ?? Please clarify. > > > E) We are able to specify a rtr dead interval of 4* that > > would not be a multiple of second units. The suggested > > values could be anywhere from 1 to 999 millisecs. This > > in effect is the transmit interval of the heartbeat pkt. > > > > If I understand it correctly, you are saying that the router dead interval > can be assigned values in the millisecond range based on the heartbeat > interval (4 times heartbeat interval). I am not clear how does it > influence the problem I mentioned earlier. > > > > > 2) Related work. The heartbeat packet can be queued and processed > > independently. > > > > Why? At "dead interval time frames", the quantity of incoming > > heartbeat packets can be noted and this number of packets > > processed. Any normally speaking heartbeat rtr that hasn't > > sent a heartbeat pkt, could minimally be noted as undergoing > > some form of congestion and longer RxmitIntervals involving > > this rtr could be employed. If we share information with other > > protocols (BGP) we may have an alternative route to temporarily > > decrease the number of pkts transiting this congested rtr. > > How will the heartbeats avoid getting queued behind a whole lot of other > packets or getting dropped because of buffer overflows before the router > has a chance to know that these are heartbeats? > > Adjusting the timer values according to the congestion level will > definitely make subsecond hellos more acceptable provided that we can > achieve a very mature understanding of how this adjustment should be done. > I think there are several concerns in this regard. > > > > > 3) If our time to process a SPF calcualtion for a LSA quantity > > is a fraction of a second, there is no need to support > > multiple sec spfDelays and spfHoldTimes. > > My understanding is that a major stability related concern is to keep the > OSPF processing load within limits. Even if SPF does not take as much > time as it used to take earlier, SPF will be a concern especially for large > areas. I think spfDelay and spfHoldTime are important for stability. They > may be significantly reduced but perhaps should not be eliminated > altogether. However, this is a complete problem in itself which needs to > be treated separately for now. > > The bottomline is that there will be one situation or the > other where the router will be busy doing other things and won't be able > to attend to millisecond Hellos or heartbeats in time to avoid false > alarms. > > > > > 4) Assuming the the #3 above spf times are kept with their > > secs default values, if a false alarm occurs within > > the spfHoldTime, and then clears, resulting in a non- > > delta change. Then no additional spf calculation will occur. > > Actually, during the spfHoldTime, nbrs could be marked > > as questionable and processed as dead nbrs, only if > > a heartbeat isn't seen. > > One of the potentially several reasons why we need large > enough spfHoldTime. I do talk about this in the paper. > > > > > 5) The hello interval and heartbeat is on a per link / circuit > > and should > > only be set to sub-second values with known trusted, > > normally highly reliable systems. > > These systems by default are less likely to be overcome by > > congestion. I am assming here that heartbeats control adj > > teardowns. > > Here, you seem to be agreeing with me that congestion should be a factor > in deciding the HelloInterval to be used on the link. > > > > > 6) Lastly for this short email.. > > The existance of sub-second heartbeat informs destination systems > > that it is still up and it is not congested... Thus, loss of one > > or more heartbeats is an indication of some issue within the system > > that can be tracked and responded to, possibly even before > > congestion > > occurs.. > > Fine. No arguments here. Loss of occasional heartbeat/Hello is not a > problem. The problem is, I repeat, that as you increase the > heartbeat/Hello frequency and (hence) reduce the routerdeadinterval, > there is an increasing likelihood that multiple hearbeats will be dropped > or won't get timely processing thus causing frequent false alarms. > > > > > 7) Depending on the repetive nature of lossed heartbeats, adj's could > > still be marked up (we are still recieving at least 1 hello per > > rtrdeadinterval) but in a degraded state... > > > > OK. > > My overall impression is that you are simply calling a subsecond Hello as > a heartbeat. This does not change the basic concerns about the > possibilities of false alarms. > > Mukul Goyal > > > Mitchell Erblich > > Sr Network Software Engineer > > > > ============= > > ============= > > > > > > > > > > > > mukul goyal wrote: > > > > > > We have studied the impact on OSPF (fast failure detection versus > > > number of false alarms) of reducing the Hello Interval to lower values. > > > This is a simulation based analysis performed on a number of IP > > > backbone topologies. The paper will be published in ICC 2003. Here is a > > > link to one draft of the paper: > > > > > > http://www.cis.ohio-state.edu/~mukul/icc.pdf > > > > > > Thanks, > > > Mukul > > > > > > > BTW has there been any work done on changing these > > > > timers to milli-secs and studying OSPF's behaviour? > > > > > > > > I guess its time the OSPF WG charter did something > > > > about it !!! > > > > > > > > Rohit > > > > --- Erblichs wrote: > > > > > Hey guys, > > > > > > > > > > I got a request for subsecond timer support > > > > > in OSPFv2 and V3, that > > > > > hopefully follows the reasoning that was > > > > > suggested in the ISIS > > > > > subsecond timer draft. > > > > > > > > > > > > > > > > > > > > > __________________________________________________ > > > > Do you Yahoo!? > > > > Yahoo! Tax Center - forms, calculators, tips, more > > > > http://taxes.yahoo.com/ > > > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 07:30:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26781 for ; Thu, 27 Feb 2003 07:30:44 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0090729A@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 7:34:39 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668843 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 07:34:39 -0500 Received: from 207.217.120.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 07:34:39 -0500 Received: from user-2ivfj3n.dialup.mindspring.com ([165.247.204.119] helo=earthlink.net) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18oNFF-0005fy-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 04:34:38 -0800 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <3E5C6F37.4060306@xebeo.com> <20030226.174811.112777204.yasu@sfc.wide.ad.jp> <3E5C89F6.9080900@xebeo.com> <20030226.212807.00986828.yasu@sfc.wide.ad.jp> <0a7001c2dd94$bb6ee320$81c802c0@alok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E5E0101.54E86F43@earthlink.net> Date: Thu, 27 Feb 2003 04:13:53 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit What 400k... What is 64byte size packet times 300 packets per sec. I think its 19.2KB. Thats 19,200 bytes per second.<------ Does anybody have a problem with this extra consumption bandwidth??? If you have just 1 sec from determining that a rtr is down with a 1Gb link, you save yourself 100+ million bytes... and there is a chance that you can save 10 secs worth of data . Thats 1 billion bytes.. Why do you want the full hello packet in the sub-second interval? Make it simple and small that their is minimal overhead to process the packet and doesn't use bandwidth.. Mitchell Erblich Sr Software Engineer ==================== alok wrote: > > pardon my interrupting, > > from a lay man's perspective my 1 cent's worth... > > > First of my consideration is that if we made L2 detection available, > > the failure detected by L2 only will be sufficient at millisecond > > level ? I don't know how many percent of failure occuring > > in the real world can be detected by L2 only. If some failures which > > can be detected only by L3 exist (sure I believe those exist), then > > L3 detection at millisecond level will be necessary anyway, isn't it ? > > It is obvious that if we detect failure by L3 at millisecond level, > > we'll be able to find all the failure in subsecond. If we fails > > to detect some of the failure, we get not so robust network. > > for L2 detection.... > i have some questions... > how long is it that when an interface goes down, does the kernel report it? > is it instantaneous? i mean i lost clock for a microsec and i came back up.. > does it filter up immediately?or is there "a delay" to see if its really > down there too? > if it is instantaneous, could the routing daemon "lag" this by as many > seconds rather than send out packets to test it? > > > > > Second is about the control traffic load of Hello. In your example of > > 100ms hello interval on 30 adjacencies, the load will be 403.2Kbps, > > even with calculating standard OSPF hello format (which may be somewhat > > redundant). I guess this cost is worthy to pay, in order to get > > robust and fast convergence network. > > ?????????? err no, ISPs are usually not that accomodating in the developer's > favour :-) > > > > I agree the context switching and scheduling of OSPF tasks will be > > a consideration. But is it already achieved by vendor hardware routers ? > > I think it more easy way such as "install CPUs as many as necessary", > > because I'm not hardware engineer ;p) sorry. > > > > I don't understand the synchronization problem you're saying. > > I understand that the control-plane only won't be able to handle > > huge number of Hellos by itself. I will want "Hello-dedicated Blade" > > or something. But what is the problem with notifying from > > hello-dedicated-blade to control-plane, apart from the similar one > > happens when notifying from L2-detection-box/blade > > to OSPF router/process ? Is there any particular problem that L3 detection > > will have but L2 detection will not have, without restricting > > how they implemented ? Am I totally missing the point ? > > choking up the bandwidth is a good point (are u saying those hellos are out > of band)? > > > > I will learn about how RSVP and other L2 detection works. > > I agree L2 detection will be more light and faster than L3. > > But what we need is L3 failure detection, and it can only be acheived > > completely by L3 detection. I guess we should take millisecond level > > L3 detection rather than nanosecond level L2 detection. > > fine i need faster hellos on BMA networks. > why? coz there is multicast happening, the only way i know that a router is > out is either if "the arp is out and doesnt come back in" or i miss hellos > and there we have "sufficent bandwidth" coz i assume BMA is primarily > ethernet...and no one runs ospf on "extended lans" via media convertors...i > hope (hell if u have a router put in a serial link) > but on P2P, line protocol/PPP down is a good enuf bet to imply the other end > is down. why do we need L3 there? From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 07:37:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26907 for ; Thu, 27 Feb 2003 07:37:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00907497@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 7:41:06 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668865 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 07:41:05 -0500 Received: from 216.136.226.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 07:41:05 -0500 Received: from [210.118.108.254] by web20703.mail.yahoo.com via HTTP; Thu, 27 Feb 2003 04:41:05 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030227124105.14605.qmail@web20703.mail.yahoo.com> Date: Thu, 27 Feb 2003 04:41:05 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: New WG Charter (was Re: Subsecond hello) To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hello Everybody, Since so much discussion is taking place and everybody is arguing so much .. why cant we include this in the new OSPF WG charter or maybe make a sub-group which may start working towards this !!! I believe that a lot of people will be interested in this. What do others say? Rohit. ----- Original Message ----- From: "Erblichs" To: Sent: Thursday, February 27, 2003 5:43 PM Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 > What 400k... > > What is 64byte size packet times 300 packets per sec. > I think its 19.2KB. Thats 19,200 bytes per second.<------ > Does anybody have a problem with this extra consumption > bandwidth??? If you have just 1 sec from determining > that a rtr is down with a 1Gb link, you save yourself > 100+ million bytes... > > and there is a chance that you can save 10 secs worth > of data . Thats 1 billion bytes.. > > Why do you want the full hello packet in the sub-second > interval? Make it simple and small that their is > minimal overhead to process the packet and doesn't > use bandwidth.. > __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 07:38:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26941 for ; Thu, 27 Feb 2003 07:38:36 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0090755C@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 7:42:31 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668885 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 07:42:30 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 07:42:30 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1RD40Q04770 for ; Thu, 27 Feb 2003 18:34:00 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1RD3vt04763 for ; Thu, 27 Feb 2003 18:33:57 +0530 References: <3E5C6F37.4060306@xebeo.com> <20030226.174811.112777204.yasu@sfc.wide.ad.jp> <3E5C89F6.9080900@xebeo.com> <20030226.212807.00986828.yasu@sfc.wide.ad.jp> <0a7001c2dd94$bb6ee320$81c802c0@alok> <3E5E0101.54E86F43@earthlink.net> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <000d01c2de5d$f6d56460$81c802c0@alok> Date: Thu, 27 Feb 2003 18:14:07 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list read my next mail on the list... i said yes, you can make is smaller... and u do need it on ethernet my question was if it is needed on P2P....... 192000*8 bites per sec == 1536000 bps (bandwidth is measured in bits i presume) 19.2kbytesps every one second is quite a bit its 1536,000bitsper sec :-) ----- Original Message ----- From: Erblichs To: Sent: Thursday, February 27, 2003 5:43 PM Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 > What 400k... > > What is 64byte size packet times 300 packets per sec. > I think its 19.2KB. Thats 19,200 bytes per second.<------ > Does anybody have a problem with this extra consumption > bandwidth??? If you have just 1 sec from determining > that a rtr is down with a 1Gb link, you save yourself > 100+ million bytes... > > and there is a chance that you can save 10 secs worth > of data . Thats 1 billion bytes.. > > Why do you want the full hello packet in the sub-second > interval? Make it simple and small that their is > minimal overhead to process the packet and doesn't > use bandwidth.. > > Mitchell Erblich > Sr Software Engineer > ==================== > > alok wrote: > > > > pardon my interrupting, > > > > from a lay man's perspective my 1 cent's worth... > > > > > First of my consideration is that if we made L2 detection available, > > > the failure detected by L2 only will be sufficient at millisecond > > > level ? I don't know how many percent of failure occuring > > > in the real world can be detected by L2 only. If some failures which > > > can be detected only by L3 exist (sure I believe those exist), then > > > L3 detection at millisecond level will be necessary anyway, isn't it ? > > > It is obvious that if we detect failure by L3 at millisecond level, > > > we'll be able to find all the failure in subsecond. If we fails > > > to detect some of the failure, we get not so robust network. > > > > for L2 detection.... > > i have some questions... > > how long is it that when an interface goes down, does the kernel report it? > > is it instantaneous? i mean i lost clock for a microsec and i came back up.. > > does it filter up immediately?or is there "a delay" to see if its really > > down there too? > > if it is instantaneous, could the routing daemon "lag" this by as many > > seconds rather than send out packets to test it? > > > > > > > > Second is about the control traffic load of Hello. In your example of > > > 100ms hello interval on 30 adjacencies, the load will be 403.2Kbps, > > > even with calculating standard OSPF hello format (which may be somewhat > > > redundant). I guess this cost is worthy to pay, in order to get > > > robust and fast convergence network. > > > > ?????????? err no, ISPs are usually not that accomodating in the developer's > > favour :-) > > > > > > I agree the context switching and scheduling of OSPF tasks will be > > > a consideration. But is it already achieved by vendor hardware routers ? > > > I think it more easy way such as "install CPUs as many as necessary", > > > because I'm not hardware engineer ;p) sorry. > > > > > > I don't understand the synchronization problem you're saying. > > > I understand that the control-plane only won't be able to handle > > > huge number of Hellos by itself. I will want "Hello-dedicated Blade" > > > or something. But what is the problem with notifying from > > > hello-dedicated-blade to control-plane, apart from the similar one > > > happens when notifying from L2-detection-box/blade > > > to OSPF router/process ? Is there any particular problem that L3 detection > > > will have but L2 detection will not have, without restricting > > > how they implemented ? Am I totally missing the point ? > > > > choking up the bandwidth is a good point (are u saying those hellos are out > > of band)? > > > > > > I will learn about how RSVP and other L2 detection works. > > > I agree L2 detection will be more light and faster than L3. > > > But what we need is L3 failure detection, and it can only be acheived > > > completely by L3 detection. I guess we should take millisecond level > > > L3 detection rather than nanosecond level L2 detection. > > > > fine i need faster hellos on BMA networks. > > why? coz there is multicast happening, the only way i know that a router is > > out is either if "the arp is out and doesnt come back in" or i miss hellos > > and there we have "sufficent bandwidth" coz i assume BMA is primarily > > ethernet...and no one runs ospf on "extended lans" via media convertors...i > > hope (hell if u have a router put in a serial link) > > but on P2P, line protocol/PPP down is a good enuf bet to imply the other end > > is down. why do we need L3 there? > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 07:43:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27212 for ; Thu, 27 Feb 2003 07:43:07 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0090754D@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 7:47:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668917 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 07:47:02 -0500 Received: from 65.86.17.254 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 07:47:02 -0500 Received: from subdimension.com ([192.168.0.4]) by subdimension.com ; Thu, 27 Feb 2003 07:59:22 -0500 X-Mailer: WebMAIL to Mail Gateway v3.0h Priority: normal X-DSMTPFooter: true X-Rcpt-To: Message-ID: <3e5e096d.45ee.1804289383@subdimension.com> Date: Thu, 27 Feb 2003 12:49:49 GMT Reply-To: Mailing List Sender: Mailing List From: Paul Jak Subject: Re: New WG Charter (was Re: Subsecond hello) To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list The world was already burdened with OSPFv2, then came OSPFv3 (for IPv6), somebody popped up MOSPF and now MILLI-OSPF (milli second OSPF !!!) Great !! :-p ----- Original Message ----- From: "Rohit Gupta" To: Sent: Thursday, February 27, 2003 6:11 PM Subject: New WG Charter (was Re: Subsecond hello) > Hello Everybody, > Since so much discussion is taking place and everybody > is arguing so much .. why cant we include this in the > new OSPF WG charter or maybe make a sub-group which > may start working towards this !!! > > I believe that a lot of people will be interested in > this. > > What do others say? > > Rohit. > _____________________________________________________________________ // free anonymous email || forums \\ subZINE || anonymous browsing subDIMENSION -- http://www.subdimension.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 07:51:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28434 for ; Thu, 27 Feb 2003 07:51:37 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0090750E@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 7:55:33 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668946 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 07:55:32 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 07:55:32 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1RDH2Q05314 for ; Thu, 27 Feb 2003 18:47:02 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1RDGxt05302 for ; Thu, 27 Feb 2003 18:47:00 +0530 References: <3E5C6F37.4060306@xebeo.com> <20030226.174811.112777204.yasu@sfc.wide.ad.jp> <3E5C89F6.9080900@xebeo.com> <20030226.212807.00986828.yasu@sfc.wide.ad.jp> <0a7001c2dd94$bb6ee320$81c802c0@alok> <3E5E0101.54E86F43@earthlink.net> <000d01c2de5d$f6d56460$81c802c0@alok> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <003801c2de5f$c8b28fc0$81c802c0@alok> Date: Thu, 27 Feb 2003 18:27:12 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list okie knock off one zero >:o) ----- Original Message ----- From: alok To: Sent: Thursday, February 27, 2003 6:14 PM Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 > read my next mail on the list... > i said yes, you can make is smaller... > and u do need it on ethernet > my question was if it is needed on P2P....... > 192000*8 bites per sec == 1536000 bps (bandwidth is measured in bits i > presume) > 19.2kbytesps every one second is quite a bit > its 1536,000bitsper sec :-) > > ----- Original Message ----- > From: Erblichs > To: > Sent: Thursday, February 27, 2003 5:43 PM > Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 > > > > What 400k... > > > > What is 64byte size packet times 300 packets per sec. > > I think its 19.2KB. Thats 19,200 bytes per second.<------ > > Does anybody have a problem with this extra consumption > > bandwidth??? If you have just 1 sec from determining > > that a rtr is down with a 1Gb link, you save yourself > > 100+ million bytes... > > > > and there is a chance that you can save 10 secs worth > > of data . Thats 1 billion bytes.. > > > > Why do you want the full hello packet in the sub-second > > interval? Make it simple and small that their is > > minimal overhead to process the packet and doesn't > > use bandwidth.. > > > > Mitchell Erblich > > Sr Software Engineer > > ==================== > > > > alok wrote: > > > > > > pardon my interrupting, > > > > > > from a lay man's perspective my 1 cent's worth... > > > > > > > First of my consideration is that if we made L2 detection available, > > > > the failure detected by L2 only will be sufficient at millisecond > > > > level ? I don't know how many percent of failure occuring > > > > in the real world can be detected by L2 only. If some failures which > > > > can be detected only by L3 exist (sure I believe those exist), then > > > > L3 detection at millisecond level will be necessary anyway, isn't it ? > > > > It is obvious that if we detect failure by L3 at millisecond level, > > > > we'll be able to find all the failure in subsecond. If we fails > > > > to detect some of the failure, we get not so robust network. > > > > > > for L2 detection.... > > > i have some questions... > > > how long is it that when an interface goes down, does the kernel report > it? > > > is it instantaneous? i mean i lost clock for a microsec and i came back > up.. > > > does it filter up immediately?or is there "a delay" to see if its really > > > down there too? > > > if it is instantaneous, could the routing daemon "lag" this by as many > > > seconds rather than send out packets to test it? > > > > > > > > > > > Second is about the control traffic load of Hello. In your example of > > > > 100ms hello interval on 30 adjacencies, the load will be 403.2Kbps, > > > > even with calculating standard OSPF hello format (which may be > somewhat > > > > redundant). I guess this cost is worthy to pay, in order to get > > > > robust and fast convergence network. > > > > > > ?????????? err no, ISPs are usually not that accomodating in the > developer's > > > favour :-) > > > > > > > > I agree the context switching and scheduling of OSPF tasks will be > > > > a consideration. But is it already achieved by vendor hardware routers > ? > > > > I think it more easy way such as "install CPUs as many as necessary", > > > > because I'm not hardware engineer ;p) sorry. > > > > > > > > I don't understand the synchronization problem you're saying. > > > > I understand that the control-plane only won't be able to handle > > > > huge number of Hellos by itself. I will want "Hello-dedicated Blade" > > > > or something. But what is the problem with notifying from > > > > hello-dedicated-blade to control-plane, apart from the similar one > > > > happens when notifying from L2-detection-box/blade > > > > to OSPF router/process ? Is there any particular problem that L3 > detection > > > > will have but L2 detection will not have, without restricting > > > > how they implemented ? Am I totally missing the point ? > > > > > > choking up the bandwidth is a good point (are u saying those hellos are > out > > > of band)? > > > > > > > > I will learn about how RSVP and other L2 detection works. > > > > I agree L2 detection will be more light and faster than L3. > > > > But what we need is L3 failure detection, and it can only be acheived > > > > completely by L3 detection. I guess we should take millisecond level > > > > L3 detection rather than nanosecond level L2 detection. > > > > > > fine i need faster hellos on BMA networks. > > > why? coz there is multicast happening, the only way i know that a router > is > > > out is either if "the arp is out and doesnt come back in" or i miss > hellos > > > and there we have "sufficent bandwidth" coz i assume BMA is primarily > > > ethernet...and no one runs ospf on "extended lans" via media > convertors...i > > > hope (hell if u have a router put in a serial link) > > > but on P2P, line protocol/PPP down is a good enuf bet to imply the other > end > > > is down. why do we need L3 there? > > > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 08:25:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00899 for ; Thu, 27 Feb 2003 08:25:36 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.009076C1@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 8:29:31 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 669028 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 08:29:30 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 08:19:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00093; Thu, 27 Feb 2003 08:15:32 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200302271315.IAA00093@ietf.org> Date: Thu, 27 Feb 2003 08:15:32 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mirtorabi-ospfv3-af-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Support of address families in OSPFv3 Author(s) : S. Mirtorabi, M. Barnes, A. Roy Filename : draft-mirtorabi-ospfv3-af-00.txt Pages : 7 Date : 2003-2-14 This document describes an extensible mechanism to support Address Families in OSPFv3. One undefined field in the Router-LSA is used to define the address-families on a link. A router may participate in multiple address families on different links. This information needs to be advertised so that only applicable link are used in the SPF calculation when building an address family specific shortest path tree. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mirtorabi-ospfv3-af-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mirtorabi-ospfv3-af-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mirtorabi-ospfv3-af-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-27083329.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mirtorabi-ospfv3-af-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mirtorabi-ospfv3-af-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-27083329.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 09:28:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05071 for ; Thu, 27 Feb 2003 09:28:49 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00907DBE@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 9:32:43 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 669402 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 09:32:43 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 09:32:42 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 83D4E22D3F; Thu, 27 Feb 2003 23:32:40 +0900 (JST) References: <20030226.212807.00986828.yasu@sfc.wide.ad.jp> <0a7001c2dd94$bb6ee320$81c802c0@alok> <3E5E0101.54E86F43@earthlink.net> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030227.233239.20591689.yasu@sfc.wide.ad.jp> Date: Thu, 27 Feb 2003 23:32:39 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: To: erblichs@EARTHLINK.NET To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E5E0101.54E86F43@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit I did something shameful !! (@_@) I missed my calculation, but not that way you're saying. > What 400k... > > What is 64byte size packet times 300 packets per sec. > I think its 19.2KB. Thats 19,200 bytes per second.<------ > Does anybody have a problem with this extra consumption > bandwidth??? If you have just 1 sec from determining I was talking about the case of standard Hello packets. 44 (byte) + 29 (nbr) * 4 (byte) = 160 (byte) # OSPF Hello size 160 (byte) * 30 (nbr) * 10 (times/sec) = 48000 (byte/sec) 48000 * 8 = 384000 (bit/sec) 384K bps Precisely, not 403.2Kbps, 384K bit/sec is correct. 384K bps = 48K Bps (byte/sec). Not so that big mistake to affect that we've discussed. > that a rtr is down with a 1Gb link, you save yourself > 100+ million bytes... > > and there is a chance that you can save 10 secs worth > of data . Thats 1 billion bytes.. I agree here. > Why do you want the full hello packet in the sub-second > interval? Make it simple and small that their is > minimal overhead to process the packet and doesn't > use bandwidth.. The fact that you can receive from router Ra does not mean that you can talk to Ra. This is why OSPF lists its neighbors. (not to Erblich) One says "L2 detection is enough for me" that's fine but it's not applicable to whole internet users. There surely exist cases where L2 reachable but L3 unreachable. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 09:31:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05267 for ; Thu, 27 Feb 2003 09:31:59 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00907E91@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 9:35:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 669430 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 09:35:53 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 09:35:53 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1REvNQ08159 for ; Thu, 27 Feb 2003 20:27:23 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1REvLt08152 for ; Thu, 27 Feb 2003 20:27:21 +0530 References: <20030226.212807.00986828.yasu@sfc.wide.ad.jp> <0a7001c2dd94$bb6ee320$81c802c0@alok> <3E5E0101.54E86F43@earthlink.net> <20030227.233239.20591689.yasu@sfc.wide.ad.jp> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <011801c2de6d$cd6bf0c0$81c802c0@alok> Date: Thu, 27 Feb 2003 20:07:27 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > > (not to Erblich) > One says "L2 detection is enough for me" that's fine but > it's not applicable to whole internet users. There surely exist > cases where L2 reachable but L3 unreachable. where on P2P??? ospfd going down? From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 09:45:25 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05959 for ; Thu, 27 Feb 2003 09:45:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00907F42@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 9:49:19 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 669515 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 09:49:19 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 09:49:19 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 6310420399; Thu, 27 Feb 2003 23:49:17 +0900 (JST) References: <3E5E0101.54E86F43@earthlink.net> <20030227.233239.20591689.yasu@sfc.wide.ad.jp> <011801c2de6d$cd6bf0c0$81c802c0@alok> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030227.234916.60547801.yasu@sfc.wide.ad.jp> Date: Thu, 27 Feb 2003 23:49:16 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: To: alok.dube@APARA.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <011801c2de6d$cd6bf0c0$81c802c0@alok> Precedence: list Content-Transfer-Encoding: 7bit > where on P2P??? > ospfd going down? YES ! ;p) regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 09:51:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06174 for ; Thu, 27 Feb 2003 09:51:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00907F25@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 9:55:50 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 669560 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 09:55:49 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 09:55:49 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1RFHJQ08566 for ; Thu, 27 Feb 2003 20:47:19 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1RFHHt08560 for ; Thu, 27 Feb 2003 20:47:18 +0530 References: <3E5E0101.54E86F43@earthlink.net> <20030227.233239.20591689.yasu@sfc.wide.ad.jp> <011801c2de6d$cd6bf0c0$81c802c0@alok> <20030227.234916.60547801.yasu@sfc.wide.ad.jp> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <016301c2de70$967d6960$81c802c0@alok> Date: Thu, 27 Feb 2003 20:27:28 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list ----- Original Message ----- From: Yasuhiro Ohara To: Sent: Thursday, February 27, 2003 8:19 PM Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 > > where on P2P??? > > ospfd going down? > > YES ! ;p) > but the router is still up :-o so routing will be fine and mebbe ospfd will come in routerdeadinterval....like "switching REs/RSMs"........... we just did a lot of stuff on this list to reduce LSAs and hellos and get in triggered updates and now u want to add more hellos? what are we trying here? look fine, u wanna do it, go ahead..the point is that if someone doesnt support it, he is justified and these will be his arguments.. 153Kbps is the overhead i get from Mitchell Erblich's example sounds bad on 2Mb links fine his figures were off (so were my zeros :-D)..but why are u undoing the whole thing? what is wrong with L2 detection..? L3 is fine on BMA...thats all i can see.... From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 10:18:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07680 for ; Thu, 27 Feb 2003 10:18:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.009083FA@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 10:22:24 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 669752 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 10:22:24 -0500 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 10:22:23 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 2C6C320417; Fri, 28 Feb 2003 00:22:22 +0900 (JST) References: <011801c2de6d$cd6bf0c0$81c802c0@alok> <20030227.234916.60547801.yasu@sfc.wide.ad.jp> <016301c2de70$967d6960$81c802c0@alok> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030228.002221.31296429.yasu@sfc.wide.ad.jp> Date: Fri, 28 Feb 2003 00:22:21 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: To: alok.dube@APARA.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <016301c2de70$967d6960$81c802c0@alok> Precedence: list Content-Transfer-Encoding: 7bit > > > where on P2P??? > > > ospfd going down? > > > > YES ! ;p) > > but the router is still up :-o so routing will be fine and mebbe ospfd will > come in routerdeadinterval....like "switching REs/RSMs"........... This is what we call blackhole. The routing will not be fine. Don't forward packets to the router suppose to run OSPF but does not. "maybe" may be "may not be" ... regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 10:57:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09111 for ; Thu, 27 Feb 2003 10:57:16 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00908826@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 11:01:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 670140 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 11:01:10 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 11:01:10 -0500 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1RGMeQ10124 for ; Thu, 27 Feb 2003 21:52:40 +0530 Received: from alok ([203.124.140.97]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id h1RGMbt10118; Thu, 27 Feb 2003 21:52:37 +0530 References: <011801c2de6d$cd6bf0c0$81c802c0@alok><20030227.234916.60547801.yasu@sfc.wide.ad.jp><016301c2de70$967d6960$81c802c0@alok> <20030228.002221.31296429.yasu@sfc.wide.ad.jp> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <01dc01c2de79$b6bf61c0$81c802c0@alok> Date: Thu, 27 Feb 2003 21:32:48 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 Comments: To: Yasuhiro Ohara To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > > > > but the router is still up :-o so routing will be fine and mebbe ospfd will > > come in routerdeadinterval....like "switching REs/RSMs"........... > > This is what we call blackhole. The routing will not be fine. > Don't forward packets to the router suppose to run OSPF but does not. > "maybe" may be "may not be" ... then lets not support "graceful restart" . coz its equally "grey" as long as the node is up and the FT is switching packets...whats the problem? From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 14:22:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17795 for ; Thu, 27 Feb 2003 14:22:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00908E1C@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 14:26:01 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 671353 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 14:26:01 -0500 Received: from 62.241.160.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 14:26:01 -0500 Received: from tom3 (unknown [62.188.144.130]) by colossus.systems.pipex.net (Postfix) with SMTP id 7AB3716000168 for ; Thu, 27 Feb 2003 19:25:59 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <013f01c2de95$bae728c0$0301a8c0@tom3> Date: Thu, 27 Feb 2003 19:22:18 -0000 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: New WG Charter (was Re: Subsecond hello) To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit perhaps Operator SPF for those with Gbit links and Mpps routers Tom Petch -----Original Message----- From: Paul Jak To: OSPF@DISCUSS.MICROSOFT.COM Date: 27 February 2003 12:47 Subject: Re: New WG Charter (was Re: Subsecond hello) >The world was already burdened with OSPFv2, then came OSPFv3 >(for IPv6), somebody popped up MOSPF and now MILLI-OSPF >(milli second OSPF !!!) > >Great !! :-p > >----- Original Message ----- >From: "Rohit Gupta" >To: >Sent: Thursday, February 27, 2003 6:11 PM >Subject: New WG Charter (was Re: Subsecond hello) > > >> Hello Everybody, >> Since so much discussion is taking place and everybody >> is arguing so much .. why cant we include this in the >> new OSPF WG charter or maybe make a sub-group which >> may start working towards this !!! >> >> I believe that a lot of people will be interested in >> this. >> >> What do others say? >> >> Rohit. >> > >_____________________________________________________________________ >// free anonymous email || forums \\ subZINE || anonymous browsing > subDIMENSION -- http://www.subdimension.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Feb 27 22:13:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01885 for ; Thu, 27 Feb 2003 22:13:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0090A3E8@cherry.ease.lsoft.com>; Thu, 27 Feb 2003 22:17:25 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 672900 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Feb 2003 22:17:25 -0500 Received: from 203.254.224.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 27 Feb 2003 22:17:24 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HB000M011318P@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Fri, 28 Feb 2003 12:16:13 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HB0001ZZ131N8@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Fri, 28 Feb 2003 12:16:13 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HB000KOU1QZIO@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Fri, 28 Feb 2003 12:30:37 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <011801c2de6d$cd6bf0c0$81c802c0@alok> <20030227.234916.60547801.yasu@sfc.wide.ad.jp> <016301c2de70$967d6960$81c802c0@alok> <20030228.002221.31296429.yasu@sfc.wide.ad.jp> <01dc01c2de79$b6bf61c0$81c802c0@alok> Message-ID: <010e01c2ded7$c1eaa330$b4036c6b@sisodomain.com> Date: Fri, 28 Feb 2003 08:46:15 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT > > This is what we call blackhole. The routing will not be fine. > > Don't forward packets to the router suppose to run OSPF but does not. > > "maybe" may be "may not be" ... > > then lets not support "graceful restart" . coz its equally "grey" I believe there is a subtle difference there. When you support graceful restart you ensure that your FIB stays up even if your control plane is down and hence you keeping forwarding your packets to that router even though you know that his OSPF is down. But we cannot always assume that the FIB will remain updated when OSPF goes down and hence you need to check at the L3 too! > as long as the node is up and the FT is switching packets...whats the > problem? No problem .. but you need to ensure that! From owner-ospf@DISCUSS.MICROSOFT.COM Fri Feb 28 00:34:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04127 for ; Fri, 28 Feb 2003 00:34:03 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0090ABFB@cherry.ease.lsoft.com>; Fri, 28 Feb 2003 0:37:58 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673384 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 28 Feb 2003 00:37:57 -0500 Received: from 64.4.36.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 28 Feb 2003 00:27:57 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 27 Feb 2003 21:27:57 -0800 X-Originating-IP: [66.171.61.231] MIME-Version: 1.0 Content-Type: Multipart/related; type="multipart/alternative"; boundary="------------Boundary-00=_D07012S0000000000000" X-Mailer: IncrediMail 2001 (1750670) References: <010e01c2ded7$c1eaa330$b4036c6b@sisodomain.com> X-FID: BA285063-5BCE-11D4-AF8D-0050DAC67E11 X-BG: X-BGT: repeat X-BGC: #dce0e3 X-BGPX: 0px X-BGPY: 0px X-ASN: ANIM3D00-NONE-0000-0000-000000000000 X-ASNF: 0 X-ASH: ANIM3D00-NONE-0000-0000-000000000000 X-ASHF: 1 X-AN: 6486DDE0-3EFD-11D4-BA3D-0050DAC68030 X-ANF: 0 X-AP: 6486DDE0-3EFD-11D4-BA3D-0050DAC68030 X-APF: 1 X-AD: C3C52140-4147-11D4-BA3D-0050DAC68030 X-ADF: 0 X-AUTO: X-ASN,X-ASH,X-AN,X-AP,X-AD X-CNT: ; X-Priority: 3 X-OriginalArrivalTime: 28 Feb 2003 05:27:57.0439 (UTC) FILETIME=[26CBA8F0:01C2DEEA] Message-ID: <3E5EF27D.000006.01036@manvi> Date: Thu, 27 Feb 2003 21:24:13 -0800 Reply-To: Mailing List Sender: Mailing List From: vishal Subject: Re: Subsecond hello and dead rtr timer support in v2/v3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --------------Boundary-00=_D07012S0000000000000 Content-Type: Multipart/Alternative; boundary="------------Boundary-00=_E070WCW0000000000000" --------------Boundary-00=_E070WCW0000000000000 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Guys,=0D =0D How about experimenting with a MilliOSPF implementation first ( like S-BGP.) Modify some=0D existing OSPF implementation, run some tests on it and then publish the results.=0D If the results are impressive, I am sure other people will follow you footsteps.=0D =0D -Vishal =0D =0D -------Original Message-------=0D =0D From: Mailing List=0D Date: Thursday, February 27, 2003 07:17:30 PM=0D To: OSPF@DISCUSS.MICROSOFT.COM=0D Subject: Re: Subsecond hello and dead rtr timer support in v2/v3=0D =0D > > This is what we call blackhole. The routing will not be fine.=0D > > Don't forward packets to the router suppose to run OSPF but does not.= =0D > > "maybe" may be "may not be" ...=0D >=0D > then lets not support "graceful restart" . coz its equally "grey"=0D =0D I believe there is a subtle difference there. When you support graceful=0D restart you ensure that your FIB stays up even if your control plane is=0D down and hence you keeping forwarding your packets to that router even=0D though you know that his OSPF is down.=0D =0D But we cannot always assume that the FIB will remain updated when OSPF go= es=0D down and hence you need to check at the L3 too!=0D =0D > as long as the node is up and the FT is switching packets...whats the=0D > problem?=0D =0D No problem .. but you need to ensure that! --------------Boundary-00=_E070WCW0000000000000 Content-Type: Text/HTML; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0D =0A
Guys,
 
    How about experimenting with a MilliOSPF=20 implementation first ( like S-BGP.) Modify some
existing OSPF implementation, run some tests on it a= nd then=20 publish the results.
If the results are impressive, I am sure other people=20 will follow you footsteps.
 
-Vishal 
 
-------Original Message-------<= /I>
 
From: Mailing List
Date: Thursd= ay,=20 February 27, 2003 07:17:30 PM
To: OSPF@DISCUSS.MICROSOFT.C= OM
Subject: Re:= Subsecond=20 hello and dead rtr timer support in v2/v3
 
> > This is what we call blackhole. The rout= ing=20 will not be fine.
> > Don't forward packets to the router = suppose=20 to run OSPF but does not.
> > "maybe" may be "may not be"=20 ...
>
> then lets not support "graceful restart" . coz = its=20 equally "grey"

I believe there is a subtle difference there.= When=20 you support graceful
restart you ensure that your FIB stays up e= ven if=20 your control plane is
down and hence you keeping forwarding your= =20 packets to that router even
though you know that his OSPF is=20 down.

But we cannot always assume that the FIB will remain u= pdated=20 when OSPF goes
down and hence you need to check at the L3=20 too!

> as long as the node is up and the FT is switching=20 packets...whats the
> problem?

No problem .. but you n= eed to ensure that!
____________________________________________________
  IncrediMail - Email has finally evolved -=20 Click=20 Here --------------Boundary-00=_E070WCW0000000000000-- --------------Boundary-00=_D07012S0000000000000 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: <5F2C9497-5650-40B2-94D7-16AA311373FE> Content-Transfer-Encoding: base64 R0lGODlhFAAPALMIAP9gAM9gAM8vAM9gL/+QL5AvAGAvAP9gL////wAAAAAAAAAAAAAAAAAAAAAA AAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQJFAAIACwAAAAAFAAPAAAEVRDJSaudJuudrxlEKI6B URlCUYyjKpgYAKSgOBSCDEuGDKgrAtC3Q/R+hkPJEDgYCjpKr5A8WK9OaPFZwHoPqm3366VKyeRt E30tVVRscMHDqV/u+AgAIfkEBWQACAAsAAAAABQADwAABBIQyUmrvTjrzbv/YCiOZGmeaAQAIfkE CRQACAAsAgABABAADQAABEoQIUOrpXIOwrsPxiQUheeRAgUA49YNhbCqK1kS9grQhXGAhsDBUJgZ AL2Dcqkk7ogFpvRAokSn0p4PO6UIuUsQggSmFjKXdAgRAQAh+QQFCgAIACwAAAAAFAAPAAAEEhDJ Sau9OOvNu/9gKI5kaZ5oBAAh+QQJFAAIACwCAAEAEAANAAAEShAhQ6ulcg7Cuw/GJBSF55ECBQDj 1g2FsKorWRL2CtCFcYCGwMFQmBkAvYNyqSTuiAWm9ECiRKfSng87pQi5SxCCBKYWMpd0CBEBACH5 BAVkAAgALAAAAAAUAA8AAAQSEMlJq7046827/2AojmRpnmgEADs= --------------Boundary-00=_D07012S0000000000000 Content-Type: Image/jpeg Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAHbAAAC1gAABZX/2wCEABALCwsMCxAMDBAXDw0PFxsUEBAUGx8XFxcXFx8eFxoaGhoX Hh4jJSclIx4vLzMzLy9AQEBAQEBAQEBAQEBAQEABEQ8PERMRFRISFRQRFBEUGhQWFhQaJhoaHBoa JjAjHh4eHiMwKy4nJycuKzU1MDA1NUBAP0BAQEBAQEBAQEBAQP/CABEIAGUAcwMBIgACEQEDEQH/ xACAAAEBAQEAAAAAAAAAAAAAAAAAAQIGAQEBAAAAAAAAAAAAAAAAAAAAARABAAICAwEAAgMAAAAA AAAAAQARIQIxQRIiQDIQMFARAAICAgIBBAIDAQEAAAAAAAERACExQVFhcYGRobECEsHhMtHxEgEA AAAAAAAAAAAAAAAAAABQ/9oADAMBAAIRAxEAAADtRZYE1ASghQFgUZoCkKSwLmhcllAEqkSkqFAl hUomoAS3IoJqFlDNpFEAQFE1AIVYAWIVKAJRNZpYCwVmmshKACA0CBAUCBYGwf/aAAgBAgABBQD8 B/yP/9oACAEDAAEFAPz6/or8H//aAAgBAQABBQC2+ZeHjbD+saX6hwXeDW1Rg4xLLTa+m7ZiIEsI 1MTiHP1dYpvFADiFM1/X6nq9byuwdPPz5oFofWlEMQ9ULKrWq2ppG9Y2J6INQma9lVTRdlUKgHzX XSEECw1SYu5WsGoJPkisZYpx31GvXZQ/JM3VwShzVTsp1EZbBI8LcaUSih86+s2Zl4Wp6+lAZnVs Dkjdku5m+lJTdXDG2SHM9M2wKX1YxsaZTTwmoVrYnqsMrM652yjs01K0mtbGAz6Y5dpfqNz06qpq 5QNjiIjiZtbhtceNuf0jyeqGgu6rXMvI4omPWbPMYzEfMI+axHnFvOP4/9oACAECAgY/AGP/2gAI AQMCBj8AY//aAAgBAQEGPwB72Yucb1BfIhFEaeZ+xRXFQELN+HEUQdjU0Xn4g9gRCQcpw1yajGYs P/kFvUzvjUBWrIMFHI2OJQNEAjiEEFdTmfG/MTHq5RFOnpTV3kzCBx7x4YOD1AV5uYJvnqMA0hep jfwpYCwC4Bx3q55zeZRBCw9TkoIuHw78RdczSNH2mgqcLpRC+RASAkA3B13mcYd5mR84c/yOx4lW tRAZ6mGDhiP9WgXVyhWA+xDgMOWGMsTg/wBTz8SjjXrP8hHIlX1MZ6mDzgc/cIV/iyN1GBR0MQMK jnEzvvMz8mUkErKlfqU63iV+IKNH7mNZBLFQEpEDeDOV32IVn8WR4caoywqI2p695mbZzNUQIcKf k0bo+0NpCqn7CiQiNGXkdQen1DpjGeZ7WNw3pK+I93maCPc16+Zkf6XxMCsFwAkaiIB57vc/IAhZ /HqZBBbB0ZokAEOGxsYqBgPp8agQBu4VSMJdqx6SwDsGBrTmAR93uZGX6KePowEADAIjoX8gw459 CICaW/MLGvodQfkDW71zBxRHtB3j3jC4PMIYoAgKNfPMCQNN7jCzvlzXPopzhQvNZY3CRya9ZrEF fRE0iCB5mscZuVYfKmAi94uE3Q8qfytQ7xD0svmFcmaxNPI8iMjh3pmF2HbzqeUi+YkiD/MrOl5L mbwPuWVfmXpv3hDH8qAjPpiZHXkRnSd6ZhB53mejzKV6US0K9TCCLyCeIhtETX5MsHBGJkD/ANiF kMCE2qGoCdZ8Q8AMGpYFqEhdhRIYH3CF3d1M/Mexma+4CwdQ2Ddcx0exAlmj04QUQd8QWLB/iB5G xmEg5TENVZqPYzFV8eHAy9T/AEc8a4n3Ov6g/VwvE6lpQ4VNysXzhS8esOO8w/rlF/rypjV3B5H1 Knr8T//Z --------------Boundary-00=_D07012S0000000000000-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Feb 28 10:26:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01565 for ; Fri, 28 Feb 2003 10:26:33 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0090B700@cherry.ease.lsoft.com>; Fri, 28 Feb 2003 10:30:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 675000 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 28 Feb 2003 10:30:27 -0500 Received: from 194.250.197.211 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 28 Feb 2003 10:30:26 -0500 Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 136C14D1 for ; Fri, 28 Feb 2003 16:44:10 +0100 (CET) Received: from 6wind.com (jardin.dev.6wind.com [10.16.0.239]) by intranet.6wind.com (Postfix) with ESMTP id 2FF0D555 for ; Fri, 28 Feb 2003 16:32:33 +0100 (CET) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en, en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E5F8202.7020305@6wind.com> Date: Fri, 28 Feb 2003 16:36:34 +0100 Reply-To: Mailing List Sender: Mailing List From: Vincent Jardin Organization: http://www.6wind.com/ Subject: draft-mirtorabi-ospfv3-af-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I] Section 5: > There is a requirement to have the [Nt|W|V|E|B] octet defined in each > address-family. For example a router may be ABR or ASBR for the IPv6 > address-family without having the same functionality for another AF. > Therefore we define a new LSA type called the AF-Functionality-LSA. If a router supports the AF-capability, which bits should this router keep into the Router-LSA's header ? For example, if IPv4 is supported without beeing ABR, whereas IPv6 is supported and the router is ABR, the LSA 0xA00A would be: 1/ IPv4 Address_Families: V4-AF functionality: x 2/ IPv6 Address_Families: V6-AF functionality: x + B Should B-bit be set into the Router-LSA ? II] However, this document does not describe "some IPv4 LSA" supports with OSPFv3. Is it enough to define an Address Family support in order for to add some new features with OSPFv3 ? III] Moreover, IPv6 is the transport layer of OPSFv3. How could the IPv4 routers support OSPFv3 ? Regards, Vincent From owner-ospf@DISCUSS.MICROSOFT.COM Fri Feb 28 14:23:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09568 for ; Fri, 28 Feb 2003 14:23:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0090CA77@cherry.ease.lsoft.com>; Fri, 28 Feb 2003 14:27:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664398 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 28 Feb 2003 14:27:53 -0500 Received: from 204.127.202.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 28 Feb 2003 14:17:53 -0500 Received: from mjbarnes (12-236-82-150.client.attbi.com[12.236.82.150]) by sccrmhc01.attbi.com (sccrmhc01) with SMTP id <2003022819175200100j61b7e>; Fri, 28 Feb 2003 19:17:53 +0000 X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.31a/31 Message-ID: Date: Fri, 28 Feb 2003 11:17:52 -0800 Reply-To: Mailing List Sender: Mailing List From: Michael Barnes Subject: Re: draft-mirtorabi-ospfv3-af-00.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E5F8202.7020305@6wind.com> Precedence: list Vincent, We're working on a separate document that describes the IPv4 address family. This document's purpose is to add generic support, that can be added to current implimentations such that they will be able to function in an internetwork with routers that will have the IPv4 address family capability. If a router has the address family capability we are defining in this document then it will interoperate correctly with routers that support other address families, even though it doesn't know about that address family. So I guess the answer to your questions is that they will be answered in a document which is being written. Regards, Michael On 02/28/2003 at 04:36 PM, Vincent Jardin said: >I] >Section 5: >> There is a requirement to have the [Nt|W|V|E|B] octet defined in each >> address-family. For example a router may be ABR or ASBR for the IPv6 >> address-family without having the same functionality for another AF. >> Therefore we define a new LSA type called the AF-Functionality-LSA. >If a router supports the AF-capability, which bits should this router >keep into the Router-LSA's header ? >For example, if IPv4 is supported without beeing ABR, whereas IPv6 is >supported and the router is ABR, the LSA 0xA00A would be: >1/ IPv4 >Address_Families: V4-AF >functionality: x >2/ IPv6 >Address_Families: V6-AF >functionality: x + B >Should B-bit be set into the Router-LSA ? >II] >However, this document does not describe "some IPv4 LSA" supports with >OSPFv3. Is it enough to define an Address Family support in order for to >add some new features with OSPFv3 ? >III] >Moreover, IPv6 is the transport layer of OPSFv3. How could the IPv4 >routers support OSPFv3 ? >Regards, > Vincent Help stop spam -- Join SpamCon Foundation, http://www.spamcon.org From owner-ospf@DISCUSS.MICROSOFT.COM Fri Feb 28 14:24:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09632 for ; Fri, 28 Feb 2003 14:24:58 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0090CBB4@cherry.ease.lsoft.com>; Fri, 28 Feb 2003 14:28:55 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664432 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 28 Feb 2003 14:28:55 -0500 Received: from 171.71.163.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 28 Feb 2003 14:28:55 -0500 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h1SJSs6N012018; Fri, 28 Feb 2003 11:28:54 -0800 (PST) Received: from localhost (akr@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA13443; Fri, 28 Feb 2003 11:28:54 -0800 (PST) X-Authentication-Warning: irp-view7.cisco.com: akr owned process doing -bs References: <3E5F8202.7020305@6wind.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 28 Feb 2003 11:28:54 -0800 Reply-To: Mailing List Sender: Mailing List From: Abhay Roy Subject: Re: draft-mirtorabi-ospfv3-af-00.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E5F8202.7020305@6wind.com> Precedence: list > I] > Section 5: > > There is a requirement to have the [Nt|W|V|E|B] octet defined in each > > address-family. For example a router may be ABR or ASBR for the IPv6 > > address-family without having the same functionality for another AF. > > Therefore we define a new LSA type called the AF-Functionality-LSA. The next 2 lines in section 5 perhaps has your answer: AF-Functionality-LSA is not used for IPv6 address-family as Router-LSA already contains this information. > If a router supports the AF-capability, which bits should this router keep > into the Router-LSA's header ? > For example, if IPv4 is supported without beeing ABR, whereas IPv6 is > supported and the router is ABR, the LSA 0xA00A would be: > > 1/ IPv4 > Address_Families: V4-AF > functionality: x > > 2/ IPv6 > Address_Families: V6-AF > functionality: x + B The AF-Functionality-LSA is needed only for AF's other than IPv6 AF. So the no. 2 above isn't necessary. > Should B-bit be set into the Router-LSA ? correct.. > II] > However, this document does not describe "some IPv4 LSA" supports with > OSPFv3. Is it enough to define an Address Family support in order for > to add some new features with OSPFv3 ? The only motive of the document is to be able to turn off a Link from being used for IPv6 AF (on the same lines of turning off V6 bit in Options field, to ignore the node). This will be needed when later other AF's get defined, and need to exclusively use the link. > III] > Moreover, IPv6 is the transport layer of OPSFv3. How could the IPv4 > routers support OSPFv3 ? It's beyond the scope of this document ;) Regards, -Roy- > Regards, > Vincent