From owner-ospf@PEACH.EASE.LSOFT.COM Sat Oct 01 04:12:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELcUI-000544-Co for ospf-archive@megatron.ietf.org; Sat, 01 Oct 2005 04:12:54 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03974 for ; Sat, 1 Oct 2005 04:12:51 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.01100EC3@cherry.ease.lsoft.com>; Sat, 1 Oct 2005 4:12:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 86973243 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 1 Oct 2005 04:12:46 -0400 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 1 Oct 2005 04:12:45 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0INO005UI9V36R@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sat, 01 Oct 2005 16:21:04 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0INO00EXI9V32B@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sat, 01 Oct 2005 16:21:03 +0800 (CST) Received: from dell60 ([10.18.4.100]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0INO00DGD9UWZP@szxml02-in.huawei.com>; Sat, 01 Oct 2005 16:20:57 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="Boundary_(ID_GBPxCKoSbaogoZpxUyCnhg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c5c660$09d7e0f0$6404120a@china.huawei.com> Date: Sat, 1 Oct 2005 13:43:42 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: [Submission]draft : Update to OSPFV2 Graceful Restart procedure Comments: cc: padma@juniper.net, Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: This is a multi-part message in MIME format. --Boundary_(ID_GBPxCKoSbaogoZpxUyCnhg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Dear Members, I have submitted an internet-draft with the following details. Title: Update to OSPF Graceful Restart procedure Author: Ashok C Holla ,Anup Kumar T, Sujay Gupta Date: August 2005 Abstract: This document suggests improvements to OSPF v2 Graceful Restart. The basic protocol working remains as specified in RFC 3623, OSPF Graceful Restart.The draft describes a two pronged approach for improving the current graceful restart mechanism. It improves the restarting router's ability to detect and react to topology changes. It also reduces the conservative behavior of the helper router in reacting to topology changes. URL: http://www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-res tart-00.txt I will like to request for any feedback or comments regarding the above-mentioned draft and will appreciate if there is any. With Best Regards, Sujay etc. My Location; http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085 &t=h&hl=en --Boundary_(ID_GBPxCKoSbaogoZpxUyCnhg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT Message
Dear Members,

I have submitted an internet-draft with the following details.

Title: Update to OSPF Graceful Restart procedure

Author: Ashok C Holla ,Anup Kumar T, Sujay Gupta

Date: August 2005

Abstract:
This document suggests improvements to OSPF v2 Graceful Restart. The  basic protocol working remains as specified in RFC 3623, OSPF Graceful Restart.The draft describes a two pronged approach for improving the current graceful restart mechanism. It improves the restarting router’s ability to detect and react to topology changes. It also reduces the  conservative behavior of the helper router in reacting to topology changes.

URL: http://www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-00.txt

I will like to request for any feedback or comments regarding the above-mentioned draft and will appreciate if there is any.

With Best Regards,

Sujay etc.

My Location;
 
--Boundary_(ID_GBPxCKoSbaogoZpxUyCnhg)-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 03 14:56:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVTk-0002v1-S4 for ospf-archive@megatron.ietf.org; Mon, 03 Oct 2005 14:56:00 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24651 for ; Mon, 3 Oct 2005 14:55:59 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0110335C@cherry.ease.lsoft.com>; Mon, 3 Oct 2005 14:55:51 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87125542 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 3 Oct 2005 14:55:50 -0400 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 3 Oct 2005 14:55:50 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j93ItnBm000527 for ; Mon, 3 Oct 2005 11:55:49 -0700 (PDT) (envelope-from qv@juniper.net) Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j93ItjG09691 for ; Mon, 3 Oct 2005 11:55:49 -0700 (PDT) (envelope-from qv@juniper.net) Received: from fuinar.juniper.net (localhost [127.0.0.1]) by fuinar.juniper.net (8.12.8p1/8.12.3) with ESMTP id j93Itj1i085877 for ; Mon, 3 Oct 2005 11:55:45 -0700 (PDT) (envelope-from qv@fuinar.juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.12.8p1/8.12.3/Submit) id j93ItihZ085874; Mon, 3 Oct 2005 11:55:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <062B922B6EC55149B5A267ECE78E5D440A250706@photon.jnpr.net> <433D766F.4010501@cisco.com> X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid Message-ID: <17217.32432.305147.688956@fuinar.juniper.net> Date: Mon, 3 Oct 2005 11:55:44 -0700 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: OSPF sham link To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <433D766F.4010501@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Acee, What this draft proposes is in contradiction with rfc 2328, section 12.4.1.1. I am not sure if an ietf spec should be imposing unnecessary restrictions. Quaizar > Kalyan Bade wrote: > > >Acee, > > > > > > > >>I recently commented on that this should be clarified in the draft. > >> > >> > >The > > > > > >>reason the sham endpoint should > >>not be redistributed or advertised in OSPF is that sham link endpoint > >>reachability > >>is used to determine whether or not sham link is up. If the sham link > >>endpoint is advertised in OSPF > >>the sham link would provide a viable path and greatly complicate this > >>determination. > >> > >> > > > >Thanks for the response. I understand what you are saying, but isn't a > >purely implementation thing? If we do this, we end up loosing > >connectivity to the loopback from other routers. This might be not > >desirable in some scenarios. Aren't we restricting something just > >because implementations cannot deal with it? Let me know your thoughts. > > > > > draft-ietf-l3vpn-ospf-2547-04.txt several times> > > Hi Kalyan, > > This draft broke new ground since it documented specific mechanisms for > both protocol redistribution and protocol interaction. Prior to the draft, > these topics were pretty much left to the implemenations (at least in > the case of > OSPF). In order to ensure interoperability, these topics needed to be > documented. > Like any problem, there are multiple ways in solve it and different > tradeoffs that > can be made. Given the number of reviews and last calls on the draft, > I'd say > there would need to be a pretty compelling reason in order to change > this now. > > Thanks, > Acee > > >Thanks, > >Kalyan. > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 03 15:22:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMVsy-0006Oa-2D for ospf-archive@megatron.ietf.org; Mon, 03 Oct 2005 15:22:04 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26671 for ; Mon, 3 Oct 2005 15:22:02 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0110345F@cherry.ease.lsoft.com>; Mon, 3 Oct 2005 15:22:02 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87128249 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 3 Oct 2005 15:21:58 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 3 Oct 2005 15:21:58 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j93JLuc19645 for ; Mon, 3 Oct 2005 21:21:57 +0200 (CEST) Received: from cisco.com (ams-clip-vpn-dhcp3.cisco.com [10.61.64.3]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j93JLtC24782 for ; Mon, 3 Oct 2005 21:21:55 +0200 (CEST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <062B922B6EC55149B5A267ECE78E5D440A250706@photon.jnpr.net> <433D766F.4010501@cisco.com> <17217.32432.305147.688956@fuinar.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <434184D2.2040201@cisco.com> Date: Mon, 3 Oct 2005 21:21:54 +0200 Reply-To: Mailing List Sender: Mailing List From: Peter Psenak Subject: Re: OSPF sham link To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Quaizar, where do you think this contradicts 12.4.1.1. Sham-link is advertised as unnumbered p2p link... thanks, Peter Quaizar Vohra wrote: > Acee, > > What this draft proposes is in contradiction with rfc 2328, section > 12.4.1.1. I am not sure if an ietf spec should be imposing unnecessary > restrictions. > > Quaizar > > > > > Kalyan Bade wrote: > > > > >Acee, > > > > > > > > > > > >>I recently commented on that this should be clarified in the draft. > > >> > > >> > > >The > > > > > > > > >>reason the sham endpoint should > > >>not be redistributed or advertised in OSPF is that sham link endpoint > > >>reachability > > >>is used to determine whether or not sham link is up. If the sham link > > >>endpoint is advertised in OSPF > > >>the sham link would provide a viable path and greatly complicate this > > >>determination. > > >> > > >> > > > > > >Thanks for the response. I understand what you are saying, but isn't a > > >purely implementation thing? If we do this, we end up loosing > > >connectivity to the loopback from other routers. This might be not > > >desirable in some scenarios. Aren't we restricting something just > > >because implementations cannot deal with it? Let me know your thoughts. > > > > > > > > > draft-ietf-l3vpn-ospf-2547-04.txt several times> > > > > Hi Kalyan, > > > > This draft broke new ground since it documented specific mechanisms for > > both protocol redistribution and protocol interaction. Prior to the draft, > > these topics were pretty much left to the implemenations (at least in > > the case of > > OSPF). In order to ensure interoperability, these topics needed to be > > documented. > > Like any problem, there are multiple ways in solve it and different > > tradeoffs that > > can be made. Given the number of reviews and last calls on the draft, > > I'd say > > there would need to be a pretty compelling reason in order to change > > this now. > > > > Thanks, > > Acee > > > > >Thanks, > > >Kalyan. > > > > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 03 16:04:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMWYH-0006BR-Cs for ospf-archive@megatron.ietf.org; Mon, 03 Oct 2005 16:04:45 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00453 for ; Mon, 3 Oct 2005 16:04:43 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.011037B2@cherry.ease.lsoft.com>; Mon, 3 Oct 2005 16:04:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87132051 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 3 Oct 2005 16:04:40 -0400 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 3 Oct 2005 16:04:40 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j93K4dBm001475 for ; Mon, 3 Oct 2005 13:04:39 -0700 (PDT) (envelope-from qv@juniper.net) Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j93K4dG22503 for ; Mon, 3 Oct 2005 13:04:39 -0700 (PDT) (envelope-from qv@juniper.net) Received: from fuinar.juniper.net (localhost [127.0.0.1]) by fuinar.juniper.net (8.12.8p1/8.12.3) with ESMTP id j93K4d1i086008 for ; Mon, 3 Oct 2005 13:04:39 -0700 (PDT) (envelope-from qv@fuinar.juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.12.8p1/8.12.3/Submit) id j93K4dEY086005; Mon, 3 Oct 2005 13:04:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <062B922B6EC55149B5A267ECE78E5D440A250706@photon.jnpr.net> <433D766F.4010501@cisco.com> <17217.32432.305147.688956@fuinar.juniper.net> <434184D2.2040201@cisco.com> X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid Message-ID: <17217.36565.596593.894554@fuinar.juniper.net> Date: Mon, 3 Oct 2005 13:04:37 -0700 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: OSPF sham link To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <434184D2.2040201@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Here is part of the text in that section. I am talking of option 1 below. Quaizar o In addition, as long as the state of the interface is "Point-to-Point" (and regardless of the neighboring router state), a Type 3 link (stub network) should be added. There are two forms that this stub link can take: Option 1 Assuming that the neighboring router's IP address is known, set the Link ID of the Type 3 link to the neighbor's IP address, the Link Data to the mask 0xffffffff (indicating a host route), and the cost to the interface's configured output cost.[15] Option 2 If a subnet has been assigned to the point-to- point link, set the Link ID of the Type 3 link to the subnet's IP address, the Link Data to the subnet's mask, and the cost to the interface's configured output cost.[16] > Quaizar, > > where do you think this contradicts 12.4.1.1. Sham-link is advertised as > unnumbered p2p link... > > thanks, > Peter > > Quaizar Vohra wrote: > > Acee, > > > > What this draft proposes is in contradiction with rfc 2328, section > > 12.4.1.1. I am not sure if an ietf spec should be imposing unnecessary > > restrictions. > > > > Quaizar > > > > > > > > > Kalyan Bade wrote: > > > > > > >Acee, > > > > > > > > > > > > > > > >>I recently commented on that this should be clarified in the draft. > > > >> > > > >> > > > >The > > > > > > > > > > > >>reason the sham endpoint should > > > >>not be redistributed or advertised in OSPF is that sham link endpoint > > > >>reachability > > > >>is used to determine whether or not sham link is up. If the sham link > > > >>endpoint is advertised in OSPF > > > >>the sham link would provide a viable path and greatly complicate this > > > >>determination. > > > >> > > > >> > > > > > > > >Thanks for the response. I understand what you are saying, but isn't a > > > >purely implementation thing? If we do this, we end up loosing > > > >connectivity to the loopback from other routers. This might be not > > > >desirable in some scenarios. Aren't we restricting something just > > > >because implementations cannot deal with it? Let me know your thoughts. > > > > > > > > > > > > > draft-ietf-l3vpn-ospf-2547-04.txt several times> > > > > > > Hi Kalyan, > > > > > > This draft broke new ground since it documented specific mechanisms for > > > both protocol redistribution and protocol interaction. Prior to the draft, > > > these topics were pretty much left to the implemenations (at least in > > > the case of > > > OSPF). In order to ensure interoperability, these topics needed to be > > > documented. > > > Like any problem, there are multiple ways in solve it and different > > > tradeoffs that > > > can be made. Given the number of reviews and last calls on the draft, > > > I'd say > > > there would need to be a pretty compelling reason in order to change > > > this now. > > > > > > Thanks, > > > Acee > > > > > > >Thanks, > > > >Kalyan. > > > > > > > > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 03 16:34:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMX11-0001fR-Km for ospf-archive@megatron.ietf.org; Mon, 03 Oct 2005 16:34:27 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12680 for ; Mon, 3 Oct 2005 16:34:25 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.01103798@cherry.ease.lsoft.com>; Mon, 3 Oct 2005 16:34:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87133980 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 3 Oct 2005 16:34:23 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 3 Oct 2005 16:34:23 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j93KYLC23667 for ; Mon, 3 Oct 2005 22:34:21 +0200 (CEST) Received: from cisco.com (ams-clip-vpn-dhcp3.cisco.com [10.61.64.3]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j93KYKC06366 for ; Mon, 3 Oct 2005 22:34:21 +0200 (CEST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <062B922B6EC55149B5A267ECE78E5D440A250706@photon.jnpr.net> <433D766F.4010501@cisco.com> <17217.32432.305147.688956@fuinar.juniper.net> <434184D2.2040201@cisco.com> <17217.36565.596593.894554@fuinar.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <434195CC.6090405@cisco.com> Date: Mon, 3 Oct 2005 22:34:20 +0200 Reply-To: Mailing List Sender: Mailing List From: Peter Psenak Subject: Re: OSPF sham link To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Quaizar, Quaizar Vohra wrote: > Here is part of the text in that section. I am talking of option 1 > below. that is valid for numbered links... anyway, most of the implementations these days use Option 2 for numbered links. thanks, Peter > > Quaizar > > > > o In addition, as long as the state of the interface > is "Point-to-Point" (and regardless of the > neighboring router state), a Type 3 link (stub > network) should be added. There are two forms that > this stub link can take: > > Option 1 > Assuming that the neighboring router's IP > address is known, set the Link ID of the Type 3 > link to the neighbor's IP address, the Link Data > to the mask 0xffffffff (indicating a host > route), and the cost to the interface's > configured output cost.[15] > > Option 2 > If a subnet has been assigned to the point-to- > point link, set the Link ID of the Type 3 link > to the subnet's IP address, the Link Data to the > subnet's mask, and the cost to the interface's > configured output cost.[16] > > > > Quaizar, > > > > where do you think this contradicts 12.4.1.1. Sham-link is advertised as > > unnumbered p2p link... > > > > thanks, > > Peter > > > > Quaizar Vohra wrote: > > > Acee, > > > > > > What this draft proposes is in contradiction with rfc 2328, section > > > 12.4.1.1. I am not sure if an ietf spec should be imposing unnecessary > > > restrictions. > > > > > > Quaizar > > > > > > > > > > > > > Kalyan Bade wrote: > > > > > > > > >Acee, > > > > > > > > > > > > > > > > > > > >>I recently commented on that this should be clarified in the draft. > > > > >> > > > > >> > > > > >The > > > > > > > > > > > > > > >>reason the sham endpoint should > > > > >>not be redistributed or advertised in OSPF is that sham link endpoint > > > > >>reachability > > > > >>is used to determine whether or not sham link is up. If the sham link > > > > >>endpoint is advertised in OSPF > > > > >>the sham link would provide a viable path and greatly complicate this > > > > >>determination. > > > > >> > > > > >> > > > > > > > > > >Thanks for the response. I understand what you are saying, but isn't a > > > > >purely implementation thing? If we do this, we end up loosing > > > > >connectivity to the loopback from other routers. This might be not > > > > >desirable in some scenarios. Aren't we restricting something just > > > > >because implementations cannot deal with it? Let me know your thoughts. > > > > > > > > > > > > > > > > > draft-ietf-l3vpn-ospf-2547-04.txt several times> > > > > > > > > Hi Kalyan, > > > > > > > > This draft broke new ground since it documented specific mechanisms for > > > > both protocol redistribution and protocol interaction. Prior to the draft, > > > > these topics were pretty much left to the implemenations (at least in > > > > the case of > > > > OSPF). In order to ensure interoperability, these topics needed to be > > > > documented. > > > > Like any problem, there are multiple ways in solve it and different > > > > tradeoffs that > > > > can be made. Given the number of reviews and last calls on the draft, > > > > I'd say > > > > there would need to be a pretty compelling reason in order to change > > > > this now. > > > > > > > > Thanks, > > > > Acee > > > > > > > > >Thanks, > > > > >Kalyan. > > > > > > > > > > > > > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 03 17:07:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMXWW-0004Bv-7v for ospf-archive@megatron.ietf.org; Mon, 03 Oct 2005 17:07:00 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14909 for ; Mon, 3 Oct 2005 17:06:57 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.01103862@cherry.ease.lsoft.com>; Mon, 3 Oct 2005 17:06:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87135915 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 3 Oct 2005 17:06:54 -0400 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 3 Oct 2005 17:06:54 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j93L6r933924 for ; Mon, 3 Oct 2005 14:06:53 -0700 (PDT) (envelope-from qv@juniper.net) Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j93L6mG32678 for ; Mon, 3 Oct 2005 14:06:48 -0700 (PDT) (envelope-from qv@juniper.net) Received: from fuinar.juniper.net (localhost [127.0.0.1]) by fuinar.juniper.net (8.12.8p1/8.12.3) with ESMTP id j93L6m1i086141 for ; Mon, 3 Oct 2005 14:06:48 -0700 (PDT) (envelope-from qv@fuinar.juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.12.8p1/8.12.3/Submit) id j93L6mjZ086138; Mon, 3 Oct 2005 14:06:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <062B922B6EC55149B5A267ECE78E5D440A250706@photon.jnpr.net> <433D766F.4010501@cisco.com> <17217.32432.305147.688956@fuinar.juniper.net> <434184D2.2040201@cisco.com> <17217.36565.596593.894554@fuinar.juniper.net> <434195CC.6090405@cisco.com> X-Mailer: VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid Message-ID: <17217.40295.197763.725905@fuinar.juniper.net> Date: Mon, 3 Oct 2005 14:06:47 -0700 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: OSPF sham link To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <434195CC.6090405@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Peter, I don't think option 1 applies to only numberred links. Also option 2 is only valid for subnetted point-to-point links and not to unnumberred or numberred (yet not subnetted) links. Though option 1 itslf is hacky. My point is that not allowing sham-link end-point to be advertised in OSPF seems gratuitous. Quaizar > Quaizar, > > Quaizar Vohra wrote: > > Here is part of the text in that section. I am talking of option 1 > > below. > > that is valid for numbered links... anyway, most of the implementations > these days use Option 2 for numbered links. > > thanks, > Peter > > > > > Quaizar > > > > > > > > o In addition, as long as the state of the interface > > is "Point-to-Point" (and regardless of the > > neighboring router state), a Type 3 link (stub > > network) should be added. There are two forms that > > this stub link can take: > > > > Option 1 > > Assuming that the neighboring router's IP > > address is known, set the Link ID of the Type 3 > > link to the neighbor's IP address, the Link Data > > to the mask 0xffffffff (indicating a host > > route), and the cost to the interface's > > configured output cost.[15] > > > > Option 2 > > If a subnet has been assigned to the point-to- > > point link, set the Link ID of the Type 3 link > > to the subnet's IP address, the Link Data to the > > subnet's mask, and the cost to the interface's > > configured output cost.[16] > > > > > > > Quaizar, > > > > > > where do you think this contradicts 12.4.1.1. Sham-link is advertised as > > > unnumbered p2p link... > > > > > > thanks, > > > Peter > > > > > > Quaizar Vohra wrote: > > > > Acee, > > > > > > > > What this draft proposes is in contradiction with rfc 2328, section > > > > 12.4.1.1. I am not sure if an ietf spec should be imposing unnecessary > > > > restrictions. > > > > > > > > Quaizar > > > > > > > > > > > > > > > > > Kalyan Bade wrote: > > > > > > > > > > >Acee, > > > > > > > > > > > > > > > > > > > > > > > >>I recently commented on that this should be clarified in the draft. > > > > > >> > > > > > >> > > > > > >The > > > > > > > > > > > > > > > > > >>reason the sham endpoint should > > > > > >>not be redistributed or advertised in OSPF is that sham link endpoint > > > > > >>reachability > > > > > >>is used to determine whether or not sham link is up. If the sham link > > > > > >>endpoint is advertised in OSPF > > > > > >>the sham link would provide a viable path and greatly complicate this > > > > > >>determination. > > > > > >> > > > > > >> > > > > > > > > > > > >Thanks for the response. I understand what you are saying, but isn't a > > > > > >purely implementation thing? If we do this, we end up loosing > > > > > >connectivity to the loopback from other routers. This might be not > > > > > >desirable in some scenarios. Aren't we restricting something just > > > > > >because implementations cannot deal with it? Let me know your thoughts. > > > > > > > > > > > > > > > > > > > > > draft-ietf-l3vpn-ospf-2547-04.txt several times> > > > > > > > > > > Hi Kalyan, > > > > > > > > > > This draft broke new ground since it documented specific mechanisms for > > > > > both protocol redistribution and protocol interaction. Prior to the draft, > > > > > these topics were pretty much left to the implemenations (at least in > > > > > the case of > > > > > OSPF). In order to ensure interoperability, these topics needed to be > > > > > documented. > > > > > Like any problem, there are multiple ways in solve it and different > > > > > tradeoffs that > > > > > can be made. Given the number of reviews and last calls on the draft, > > > > > I'd say > > > > > there would need to be a pretty compelling reason in order to change > > > > > this now. > > > > > > > > > > Thanks, > > > > > Acee > > > > > > > > > > >Thanks, > > > > > >Kalyan. > > > > > > > > > > > > > > > > > > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 03 22:46:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMcpK-0008HX-Ss for ospf-archive@megatron.ietf.org; Mon, 03 Oct 2005 22:46:46 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06363 for ; Mon, 3 Oct 2005 22:46:44 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.01103B6A@cherry.ease.lsoft.com>; Mon, 3 Oct 2005 22:46:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87153043 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 3 Oct 2005 22:46:42 -0400 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 3 Oct 2005 22:46:42 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 03 Oct 2005 19:46:41 -0700 X-IronPort-AV: i="3.97,171,1125903600"; d="scan'208"; a="216773604:sNHT28350274" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j942kTus017559 for ; Mon, 3 Oct 2005 19:46:39 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Oct 2005 22:46:37 -0400 Received: from [10.82.242.37] ([10.82.242.37]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Oct 2005 22:46:36 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <062B922B6EC55149B5A267ECE78E5D440A250706@photon.jnpr.net> <433D766F.4010501@cisco.com> <17217.32432.305147.688956@fuinar.juniper.net> <434184D2.2040201@cisco.com> <17217.36565.596593.894554@fuinar.juniper.net> <434195CC.6090405@cisco.com> <17217.40295.197763.725905@fuinar.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2005 02:46:37.0018 (UTC) FILETIME=[D6D563A0:01C5C88D] Message-ID: <4341ED06.8050401@cisco.com> Date: Mon, 3 Oct 2005 22:46:30 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF sham link To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <17217.40295.197763.725905@fuinar.juniper.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Quaizar, Quaizar Vohra wrote: >Peter, > >I don't think option 1 applies to only numberred links. Also >option 2 is only valid for subnetted point-to-point links >and not to unnumberred or numberred (yet not subnetted) links. > > In every implementation I've worked on or written, the stub link has been omitted for unnumbered point-to-point links. You'll note that in the example in 12.4.1.5, RT3's backbone LSA doesn't include a stub link for the unnumbered interface.. However, this isn't the main point of this discussion. >Though option 1 itslf is hacky. My point is that not allowing >sham-link end-point to be advertised in OSPF seems gratuitous. > > I checked to see when the handling of the sham link endpoint address was first documented and it dates back to section 4.2.3 of draft-rosen-vpns-ospf-bgp-mpls-01.txt (February 2001). What is the compelling reason to change it now after this many draft iterations and after multiple WG last calls? Thanks, Acee >Quaizar > > > > Quaizar, > > > > Quaizar Vohra wrote: > > > Here is part of the text in that section. I am talking of option 1 > > > below. > > > > that is valid for numbered links... anyway, most of the implementations > > these days use Option 2 for numbered links. > > > > thanks, > > Peter > > > > > > > > Quaizar > > > > > > > > > > > > o In addition, as long as the state of the interface > > > is "Point-to-Point" (and regardless of the > > > neighboring router state), a Type 3 link (stub > > > network) should be added. There are two forms that > > > this stub link can take: > > > > > > Option 1 > > > Assuming that the neighboring router's IP > > > address is known, set the Link ID of the Type 3 > > > link to the neighbor's IP address, the Link Data > > > to the mask 0xffffffff (indicating a host > > > route), and the cost to the interface's > > > configured output cost.[15] > > > > > > Option 2 > > > If a subnet has been assigned to the point-to- > > > point link, set the Link ID of the Type 3 link > > > to the subnet's IP address, the Link Data to the > > > subnet's mask, and the cost to the interface's > > > configured output cost.[16] > > > > > > > > > > Quaizar, > > > > > > > > where do you think this contradicts 12.4.1.1. Sham-link is advertised as > > > > unnumbered p2p link... > > > > > > > > thanks, > > > > Peter > > > > > > > > Quaizar Vohra wrote: > > > > > Acee, > > > > > > > > > > What this draft proposes is in contradiction with rfc 2328, section > > > > > 12.4.1.1. I am not sure if an ietf spec should be imposing unnecessary > > > > > restrictions. > > > > > > > > > > Quaizar > > > > > > > > > > > > > > > > > > > > > Kalyan Bade wrote: > > > > > > > > > > > > >Acee, > > > > > > > > > > > > > > > > > > > > > > > > > > > >>I recently commented on that this should be clarified in the draft. > > > > > > >> > > > > > > >> > > > > > > >The > > > > > > > > > > > > > > > > > > > > >>reason the sham endpoint should > > > > > > >>not be redistributed or advertised in OSPF is that sham link endpoint > > > > > > >>reachability > > > > > > >>is used to determine whether or not sham link is up. If the sham link > > > > > > >>endpoint is advertised in OSPF > > > > > > >>the sham link would provide a viable path and greatly complicate this > > > > > > >>determination. > > > > > > >> > > > > > > >> > > > > > > > > > > > > > >Thanks for the response. I understand what you are saying, but isn't a > > > > > > >purely implementation thing? If we do this, we end up loosing > > > > > > >connectivity to the loopback from other routers. This might be not > > > > > > >desirable in some scenarios. Aren't we restricting something just > > > > > > >because implementations cannot deal with it? Let me know your thoughts. > > > > > > > > > > > > > > > > > > > > > > > > > draft-ietf-l3vpn-ospf-2547-04.txt several times> > > > > > > > > > > > > Hi Kalyan, > > > > > > > > > > > > This draft broke new ground since it documented specific mechanisms for > > > > > > both protocol redistribution and protocol interaction. Prior to the draft, > > > > > > these topics were pretty much left to the implemenations (at least in > > > > > > the case of > > > > > > OSPF). In order to ensure interoperability, these topics needed to be > > > > > > documented. > > > > > > Like any problem, there are multiple ways in solve it and different > > > > > > tradeoffs that > > > > > > can be made. Given the number of reviews and last calls on the draft, > > > > > > I'd say > > > > > > there would need to be a pretty compelling reason in order to change > > > > > > this now. > > > > > > > > > > > > Thanks, > > > > > > Acee > > > > > > > > > > > > >Thanks, > > > > > > >Kalyan. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 05 16:00:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFQx-0000SW-EX for ospf-archive@megatron.ietf.org; Wed, 05 Oct 2005 16:00:11 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14097 for ; Wed, 5 Oct 2005 16:00:07 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.01105E0D@cherry.ease.lsoft.com>; Wed, 5 Oct 2005 16:00:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87292375 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 5 Oct 2005 16:00:03 -0400 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 5 Oct 2005 15:50:03 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ENFH8-0008W7-Ag; Wed, 05 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Wed, 5 Oct 2005 15:50:02 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-af-alt-02.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: --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 : Support of address families in OSPFv3 Author(s) : S. Mirtorabi, et al. Filename : draft-ietf-ospf-af-alt-02.txt Pages : 8 Date : 2005-10-5 This document describes a mechanism for supporting multiple address families in OSPFv3 using multiple instances. It maps an address family (AF) to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AF's. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-af-alt-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-af-alt-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-af-alt-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-5140358.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-af-alt-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-af-alt-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-5140358.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 06 09:24:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENVj9-0007z0-IW for ospf-archive@megatron.ietf.org; Thu, 06 Oct 2005 09:24:03 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02364 for ; Thu, 6 Oct 2005 09:24:01 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.01106B78@cherry.ease.lsoft.com>; Thu, 6 Oct 2005 9:23:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87352431 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Oct 2005 09:23:53 -0400 Received: from 64.233.184.195 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 6 Oct 2005 09:23:53 -0400 Received: by wproxy.gmail.com with SMTP id i34so179171wra for ; Thu, 06 Oct 2005 06:23:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=HfV4k2P5qUyU3E1oP0BE047eYXVaMAHdm/F/01ZbwLWaLo9eRPzud3TmcCKaF9hEgbC8ioIj+kxihQoyrhJ5bUMxO6yT2301moot3Hf0Cft6jEBLuMCdR5COfeyI5CDFNCZ9Lz3cOjeIxWfv1bQEq6eGLOlYUu4E+Mwqa5Nm1Qg= Received: by 10.54.117.15 with SMTP id p15mr1181599wrc; Thu, 06 Oct 2005 06:23:53 -0700 (PDT) Received: by 10.54.111.16 with HTTP; Thu, 6 Oct 2005 06:23:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3279_19624311.1128605032627" Message-ID: Date: Thu, 6 Oct 2005 18:53:52 +0530 Reply-To: Mailing List Sender: Mailing List From: Santosh Esale Subject: OSPF ECMP To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: ------=_Part_3279_19624311.1128605032627 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Guys, I have a question related to section 16.8 of RFC 2328. 16.8. Equal-cost multipath The OSPF protocol maintains multiple equal-cost routes to all destinations. This can be seen in the steps used above to calculate the routing table, and in the definition of the routing table structure. Each one of the multiple routes will be of the same type (intra-area, inter-area, type 1 external or type 2 external), cost, and will have the same associated area. However, each route may specify a separate next hop and Advertising router. There is no requirement that a router running OSPF keep track of all possible equal-cost routes to a destination. An implementation may choose to keep only a fixed number of routes to any given destination. This does not affect any of the algorithms presented in this specification. it doesn't specify clearly which areas nexthop should be preferred over the other(like highest area id etc). As per section 16.4.1, intra-area path using the non backbone is most preferred for external routes, as backbone paths will be heavly loaded because of inter-area traffic. So should the highest area ids nexthops should be preferred over lower area ids(backbone 0) while calculating ECMPs to intra-area and inter-area routes= . Thanks in advance Santosh ------=_Part_3279_19624311.1128605032627 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Guys,

I have a question related to section 16.8 of RFC 2328.

 16.8.  Equal-cost multipath

        The OSPF protocol maintains mult= iple equal-cost routes to all
        destinations.  This can be = seen in the steps used above to
        calculate the routing table, and= in the definition of the
        routing table structure.

        Each one of the multiple routes = will be of the same type
        (intra-area, inter-area, type 1 = external or type 2 external),
        cost, and will have the same ass= ociated area.  However, each
        route may specify a separate nex= t hop and Advertising router.

        There is no requirement that a r= outer running OSPF keep track of
        all possible equal-cost routes t= o a destination.  An
        implementation may choose to kee= p only a fixed number of routes
        to any given destination.  = This does not affect any of the
        algorithms presented in this spe= cification.



it doesn't specify clearly which areas nexthop should be preferred over the other(like highest area id etc). As per section 16.4.1, intra-area path using the non backbone is most preferred for external routes, as backbone paths will be heavly loaded because of inter-area traffic.

So should the highest area ids nexthops should be preferred over lower area ids(backbone 0)  while calculating ECMPs to intra-area and inter-area routes.

Thanks in advance

Santosh

------=_Part_3279_19624311.1128605032627-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 06 10:41:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWwZ-00078M-C1 for ospf-archive@megatron.ietf.org; Thu, 06 Oct 2005 10:41:59 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07980 for ; Thu, 6 Oct 2005 10:41:56 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.01106B6D@cherry.ease.lsoft.com>; Thu, 6 Oct 2005 10:41:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87356292 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 6 Oct 2005 10:41:55 -0400 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 6 Oct 2005 10:41:55 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 06 Oct 2005 07:41:56 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,182,1125903600"; d="scan'208"; a="12660037:sNHT21463148" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j96Ef8Tg028441 for ; Thu, 6 Oct 2005 10:41:53 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 10:41:51 -0400 Received: from [10.82.242.37] ([10.82.242.37]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 10:41:51 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2005 14:41:51.0317 (UTC) FILETIME=[16934050:01C5CA84] Message-ID: <434537AE.5070700@cisco.com> Date: Thu, 6 Oct 2005 10:41:50 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF ECMP To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Santosh, Santosh Esale wrote: >Hello Guys, > >I have a question related to section 16.8 of RFC 2328. > >16.8. Equal-cost multipath > >The OSPF protocol maintains multiple equal-cost routes to all >destinations. This can be seen in the steps used above to >calculate the routing table, and in the definition of the >routing table structure. > >Each one of the multiple routes will be of the same type >(intra-area, inter-area, type 1 external or type 2 external), >cost, and will have the same associated area. However, each >route may specify a separate next hop and Advertising router. > >There is no requirement that a router running OSPF keep track of >all possible equal-cost routes to a destination. An >implementation may choose to keep only a fixed number of routes >to any given destination. This does not affect any of the >algorithms presented in this specification. > > > >it doesn't specify clearly which areas nexthop should be preferred over the >other(like highest area id etc). As per section 16.4.1, intra-area path >using the non backbone is most preferred for external routes, as backbone >paths will be heavly loaded because of inter-area traffic. > > The assumption of the RFC is that a prefix will only be accessible in a single area. However, there are situations where a prefix or host route is accessible from multiple areas. In fact, I recall one implementation that would look for the a /32 corresponding to the router-id and, if it existed, advertise it as a stub link in all attached areas. >So should the highest area ids nexthops should be preferred over lower area >ids(backbone 0) while calculating ECMPs to intra-area and inter-area routes. > > I know of at least one implementation that prefers the lowest area ID in this situation. Hope this helps, Acee >Thanks in advance > >Santosh > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 07 18:20:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO0Zd-0007Z4-Rz for ospf-archive@megatron.ietf.org; Fri, 07 Oct 2005 18:20:17 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29306 for ; Fri, 7 Oct 2005 18:20:14 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.011083E3@cherry.ease.lsoft.com>; Fri, 7 Oct 2005 18:20:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 87475116 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 7 Oct 2005 18:20:07 -0400 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 7 Oct 2005 18:20:07 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 Oct 2005 18:20:08 -0400 X-IronPort-AV: i="3.97,189,1125892800"; d="scan'208"; a="73338296:sNHT22067332" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j97MK5Ql024927 for ; Fri, 7 Oct 2005 18:20:06 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 18:20:05 -0400 Received: from [10.82.216.196] ([10.82.216.196]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Oct 2005 18:20:05 -0400 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2005 22:20:05.0360 (UTC) FILETIME=[44B70700:01C5CB8D] Message-ID: <4346F494.8070306@cisco.com> Date: Fri, 7 Oct 2005 18:20:04 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF WG Meeting at IETF 64 in Vancouver, BC To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit If you have drafts you'd like to present at the next OSPF WG meeting in Vancouver, please unicast Rohit and myself. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 14 11:50:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQRov-0002x3-22 for ospf-archive@megatron.ietf.org; Fri, 14 Oct 2005 11:50:09 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25355 for ; Fri, 14 Oct 2005 11:50:04 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.011102FF@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 11:50:03 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88025845 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 11:50:01 -0400 Received: from 212.17.55.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 11:50:00 -0400 Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j9EFnt2n027765 for ; Fri, 14 Oct 2005 16:49:59 +0100 X-X-Sender: paul@sheen.jakma.org Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on hibernia.jakma.org X-Virus-Status: Clean Message-ID: Date: Fri, 14 Oct 2005 16:52:16 +0100 Reply-To: Mailing List Sender: Mailing List From: Paul Jakma Subject: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi, Are there any drafts regarding $SUBJECT (aka "fast hellos")? Any plans to formally specify this useful OSPF extension? regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: No house is childproofed unless the little darlings are in straitjackets. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 14 12:11:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQS9f-0003av-JN for ospf-archive@megatron.ietf.org; Fri, 14 Oct 2005 12:11:35 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27052 for ; Fri, 14 Oct 2005 12:11:31 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.011100F7@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 12:11:29 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88027506 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 12:11:27 -0400 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 12:11:27 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 14 Oct 2005 09:11:27 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9EGBPub004784 for ; Fri, 14 Oct 2005 09:11:25 -0700 (PDT) Received: (lhnguyen@localhost) by sjc-cde-011.cisco.com (8.11.2/CISCO.WS.1.2) id j9EGBPR07888 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 09:11:25 -0700 (PDT) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <20051014161125.GK5983@sjc-cde-011.cisco.com> Date: Fri, 14 Oct 2005 09:11:25 -0700 Reply-To: Mailing List Sender: Mailing List From: Liem Nguyen Subject: Re: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Paul, On Fri, Oct 14, 2005 at 04:52:16PM +0100, Paul Jakma wrote: > Hi, > > Are there any drafts regarding $SUBJECT (aka "fast hellos")? Any > plans to formally specify this useful OSPF extension? None planned at the moment. But BFD may be a better general solution. > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > No house is childproofed unless the little darlings are in straitjackets. -- Liem Nguyen From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 14 15:17:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQV3v-0003Of-OM for ospf-archive@megatron.ietf.org; Fri, 14 Oct 2005 15:17:53 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05815 for ; Fri, 14 Oct 2005 15:17:46 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.011108F1@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 15:17:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88042337 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 15:17:46 -0400 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 15:17:46 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j9EJHkBm006969 for ; Fri, 14 Oct 2005 12:17:46 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j9EJHgG07977 for ; Fri, 14 Oct 2005 12:17:46 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v734) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.734) Message-ID: <1C9BDA2C-9C9A-4F15-A8D2-38642FA202AB@juniper.net> Date: Fri, 14 Oct 2005 13:17:41 -0600 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit This seems like a pretty ugly hack, and at the end of the day you're still stuck with a one second detection time. Using BFD as an advisory mechanism to OSPF seems cleaner to me, but then I'm biased. On Oct 14, 2005, at 9:52 AM, Paul Jakma wrote: > Hi, > > Are there any drafts regarding $SUBJECT (aka "fast hellos")? Any > plans to formally specify this useful OSPF extension? > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > No house is childproofed unless the little darlings are in > straitjackets. > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 14 15:48:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVXP-0004rE-A0 for ospf-archive@megatron.ietf.org; Fri, 14 Oct 2005 15:48:19 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07058 for ; Fri, 14 Oct 2005 15:48:13 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.01110A43@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 15:48:17 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88043947 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 15:48:15 -0400 Received: from 207.69.195.68 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 15:48:15 -0400 Received: from h-68-164-88-252.snvacaid.dynamic.covad.net ([68.164.88.252] helo=earthlink.net) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EQVXL-00022T-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 15:48:15 -0400 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: <1C9BDA2C-9C9A-4F15-A8D2-38642FA202AB@juniper.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43500E3E.A43F0FBD@earthlink.net> Date: Fri, 14 Oct 2005 12:59:58 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Dave Katz and group, Even with one sec interval hello intervals, wouldn't a a down connection occur on avg every 0.5 sec. Yes worst case is 1 sec. However, it is possible that consistantly xmit interval of of say 0.5 sec COULD implicitly imply more freq xmits, and that a drop of 1 of these COULD imply a dropped connection. If random drops are possible, then 3 xmits within 0.5 secs (as an example) could be used and again imply either congestion, a dropped connection, or .... AND alternate routing paths should/could be taken for priority realtime data/control traffic. So, bottom line, within the current spec, "fast hellos" COULD be implicitly used, if history is kept that determines that this is being used to more closely monitor router adj status. Mitchell Erblich ---------------- Dave Katz wrote: > > This seems like a pretty ugly hack, and at the end of the day you're > still stuck with a one second detection time. > > Using BFD as an advisory mechanism to OSPF seems cleaner to me, but > then I'm biased. > > On Oct 14, 2005, at 9:52 AM, Paul Jakma wrote: > > > Hi, > > > > Are there any drafts regarding $SUBJECT (aka "fast hellos")? Any > > plans to formally specify this useful OSPF extension? > > > > regards, > > -- > > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > > Fortune: > > No house is childproofed unless the little darlings are in > > straitjackets. > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 14 15:48:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQVXX-0004se-11 for ospf-archive@megatron.ietf.org; Fri, 14 Oct 2005 15:48:27 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07069 for ; Fri, 14 Oct 2005 15:48:21 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.01110AB8@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 15:48:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88043542 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 15:48:23 -0400 Received: from 198.137.194.222 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 15:38:22 -0400 Received: (qmail 2175 invoked by uid 211); 14 Oct 2005 19:38:22 -0000 Received: from challah.msrl.com (HELO ?127.0.0.1?) (vgill@198.137.194.222) by challah.msrl.com with RC4-MD5 encrypted SMTP; 14 Oct 2005 19:38:22 -0000 User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 References: <1C9BDA2C-9C9A-4F15-A8D2-38642FA202AB@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4350092B.6080705@vijaygill.com> Date: Fri, 14 Oct 2005 15:38:19 -0400 Reply-To: Mailing List Sender: Mailing List From: vijay gill Subject: Re: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <1C9BDA2C-9C9A-4F15-A8D2-38642FA202AB@juniper.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Dave Katz wrote: > This seems like a pretty ugly hack, and at the end of the day you're > still stuck with a one second detection time. > > Using BFD as an advisory mechanism to OSPF seems cleaner to me, but then > I'm biased. > As a customer, we are fully behind BFD as the mechanism for fast failure detection, as opposed to tweaking timers in the protocol. /vijay From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 14 16:43:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWOm-0001VJ-8v for ospf-archive@megatron.ietf.org; Fri, 14 Oct 2005 16:43:28 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23545 for ; Fri, 14 Oct 2005 16:43:22 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.01110EAB@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 16:43:25 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88049357 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 16:43:23 -0400 Received: from 64.233.184.199 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 16:43:23 -0400 Received: by wproxy.gmail.com with SMTP id i34so279930wra for ; Fri, 14 Oct 2005 13:43:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=G7gANRv0CsbpHbVXqzntUalxEb61kWXx2gNaBxsg8VbclfLwYZ1pMFzHcbhtHRxOO0XcqMpay24eof6PTPG6CZf7K1KniIlEBI5Qb/vq2ZHWf925pkx8KWfAVtSSZfQdLJkgSetodtDoxtadWoti0QR+Y1drNFIrFzvGmaBksTI= Received: by 10.54.120.13 with SMTP id s13mr1102240wrc; Fri, 14 Oct 2005 13:43:21 -0700 (PDT) Received: by 10.54.83.9 with HTTP; Fri, 14 Oct 2005 13:43:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_30591_4238199.1129322601660" References: <1C9BDA2C-9C9A-4F15-A8D2-38642FA202AB@juniper.net> <4350092B.6080705@vijaygill.com> Message-ID: <8b7d2e170510141343i1dfefc69n520837e312b3fb46@mail.gmail.com> Date: Fri, 14 Oct 2005 13:43:21 -0700 Reply-To: Mailing List Sender: Mailing List From: Scott Whyte Subject: Re: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4350092B.6080705@vijaygill.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: ------=_Part_30591_4238199.1129322601660 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/14/05, vijay gill wrote: > > Dave Katz wrote: > > This seems like a pretty ugly hack, and at the end of the day you're > > still stuck with a one second detection time. > > > > Using BFD as an advisory mechanism to OSPF seems cleaner to me, but the= n > > I'm biased. > > > > As a customer, we are fully behind BFD as the mechanism for fast failure > detection, as opposed to tweaking timers in the protocol. Seconded. OSPF with default timers and BFD doing aggressive failure detection is working very well for us. -Scott /vijay > ------=_Part_30591_4238199.1129322601660 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

On 10/14/05, vijay gill <vgill@vi= jaygill.com> wrote:
Dave Katz wrote:
> This seems like a pretty ugly hack, and at the end= of the day you're
> still stuck with a one second detection time.>
> Using BFD as an advisory mechanism to OSPF seems cleaner to m= e, but then
> I'm biased.
>

As a customer, we are fully behind BFD = as the mechanism for fast failure
detection, as opposed to tweaking time= rs in the protocol.


Seconded.  OSPF with default timers and BFD doing aggressive failure d= etection is working very well for us.

-Scott

/vijay<= br>

------=_Part_30591_4238199.1129322601660-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 14 17:07:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWlp-0000F8-FA for ospf-archive@megatron.ietf.org; Fri, 14 Oct 2005 17:07:17 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25039 for ; Fri, 14 Oct 2005 17:07:12 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.01110F10@cherry.ease.lsoft.com>; Fri, 14 Oct 2005 17:07:15 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88052000 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 14 Oct 2005 17:07:13 -0400 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 14 Oct 2005 17:07:13 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j9EL7DBm007745 for ; Fri, 14 Oct 2005 14:07:13 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j9EL7CG42417 for ; Fri, 14 Oct 2005 14:07:12 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v734) References: <1C9BDA2C-9C9A-4F15-A8D2-38642FA202AB@juniper.net> <43500E3E.A43F0FBD@earthlink.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.734) Message-ID: <15F23A11-0833-4025-A3AA-9DA00585465D@juniper.net> Date: Fri, 14 Oct 2005 15:07:11 -0600 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43500E3E.A43F0FBD@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit On Oct 14, 2005, at 1:59 PM, Erblichs wrote: > Dave Katz and group, > > Even with one sec interval hello intervals, wouldn't a a down > connection occur on avg every 0.5 sec. Yes worst case is > 1 sec. If the dead timer is one sec, then it takes one second from the last hello received to fail a neighbor. The actual detection time for a failure will be between 1 and 1-i, where i is the longest interpacket gap. > > However, it is possible that consistantly xmit interval of > of say 0.5 sec COULD implicitly imply more freq xmits, and > that a drop of 1 of these COULD imply a dropped connection. Giving up the ghost based on the drop of a single packet is exactly the wrong thing to do as you descend into fast detection territory, as the odds of a false negative increase faster than linearly as it is. What you *really* don't want is a bunch of flapping adjacencies. > > If random drops are possible, then 3 xmits within 0.5 secs (as an > example) could be used and again imply either congestion, > a dropped connection, or .... AND alternate routing paths > should/could be taken for priority realtime data/control traffic. > > So, bottom line, within the current spec, "fast hellos" > COULD be implicitly used, if history is kept that determines that > this is being used to more closely monitor router adj > status. Many things are possible, but the set of practical and stable things is rather smaller. What you describe sounds highly dangerous to me. As Milo Medin used to say, "with enough thrust, anything will fly." I have several problems with hacking OSPF. First, if I understand the way some vendors are doing it, the hellos are going out with an advertised dead time of 1 and an advertised interval of 0. This is called "lying." It may have been a dumb idea to force each side to know the other's parameters and require that they match, but that's the way the protocol is defined. Heuristic hacks lead to madness. Second, as you start speeding things up, you really need a mechanism whereby the rate can be slowed down if things get ugly, or you end up with continuous flappage and a network that has gone into protocol fibrillation. It's spectacular and fascinating to watch, in the same way as a train wreck, but it's equally unpleasant. Third, as you start speeding things up, you need to be able to control the rate on a per-neighbor basis. Otherwise, one slower guy can totally hose things, so either everybody has to go slow (suboptimal) or everybody flaps with the guy (really suboptimal.) Fourth, OSPF hellos serve two purposes (liveness and state management.) Once the neighbor comes up, the state information is redundant. It seems wasteful to send all this redundant information at a faster and faster rate. My position for awhile now is that the network as a whole needs to be able to pull its own fat out of the fire if things start to collapse, and OSPF is just too rigid to allow that. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 17 10:10:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERVhH-0000QF-1Y for ospf-archive@megatron.ietf.org; Mon, 17 Oct 2005 10:10:40 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14463 for ; Mon, 17 Oct 2005 10:10:31 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.01114346@cherry.ease.lsoft.com>; Mon, 17 Oct 2005 10:10:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88239905 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 17 Oct 2005 10:10:35 -0400 Received: from 212.17.55.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 17 Oct 2005 10:10:34 -0400 Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j9HEAQMr026483 for ; Mon, 17 Oct 2005 15:10:31 +0100 X-X-Sender: paul@sheen.jakma.org References: <1C9BDA2C-9C9A-4F15-A8D2-38642FA202AB@juniper.net> <43500E3E.A43F0FBD@earthlink.net> <15F23A11-0833-4025-A3AA-9DA00585465D@juniper.net> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on hibernia.jakma.org X-Virus-Status: Clean Message-ID: Date: Mon, 17 Oct 2005 15:13:35 +0100 Reply-To: Mailing List Sender: Mailing List From: Paul Jakma Subject: Re: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <15F23A11-0833-4025-A3AA-9DA00585465D@juniper.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: On Fri, 14 Oct 2005, Dave Katz wrote: > If the dead timer is one sec, then it takes one second from the > last hello received to fail a neighbor. The actual detection time > for a failure will be between 1 and 1-i, where i is the longest > interpacket gap. Surely it'd always be at least 1? > false negative increase faster than linearly as it is. What you > *really* don't want is a bunch of flapping adjacencies. Yep, but that's operational more than anything else, I guess. > I have several problems with hacking OSPF. First, if I understand > the way some vendors are doing it, the hellos are going out with an > advertised dead time of 1 and an advertised interval of 0. This is > called "lying." It may have been a dumb idea to force each side to > know the other's parameters and require that they match, but that's > the way the protocol is defined. Heuristic hacks lead to madness. Indeed. > Second, as you start speeding things up, you really need a > mechanism whereby the rate can be slowed down if things get ugly, > or you end up with continuous flappage and a network that has gone > into protocol fibrillation. It's spectacular and fascinating to > watch, in the same way as a train wreck, but it's equally > unpleasant. > > Third, as you start speeding things up, you need to be able to > control the rate on a per-neighbor basis. Otherwise, one slower > guy can totally hose things, so either everybody has to go slow > (suboptimal) or everybody flaps with the guy (really suboptimal.) This would be because of a monolithic OSPF protocol implementation, unable to service the Hello sub-protocol because it's busy doing something else? Presuming the machine is either fast enough to keep up (even with a monolithic implementation) or seperates the running of Hello from the rest of OSPF (which some implementations do I believe), then things should be ok. In such a case, regular quick failures would still induce protocol "fibrilliation" (excellent term ;) ) wouldn't they, regardless of whether it's BFD or fast Hello or a slow monolithic implementation which indicates failure / causes flaps? I.E. the "fibrillation" problem probably should be examined, even with BFD (if it's even possible to solve it in the protocol).. > Fourth, OSPF hellos serve two purposes (liveness and state > management.) Once the neighbor comes up, the state information is > redundant. It seems wasteful to send all this redundant > information at a faster and faster rate. Hmm, there's maybe 36 bytes of redundant information, not much. Plus, OSPF Hello does multicast, a BFD "full mesh" between a couple of machines on a multi-access network would have far more overhead ;). Ie, Fast-Hello is still quite interesting for multi-access networks, for efficiency, isn't it? How does OSPF Hello compare to BFD here? > My position for awhile now is that the network as a whole needs to > be able to pull its own fat out of the fire if things start to > collapse, and OSPF is just too rigid to allow that. Hmm, interesting thought. What could be done though? I suspect this might be more a combination of implementation + operational issues though, than a problem with OSPF. > --Dave -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "Love is a snowmobile racing across the tundra and then suddenly it flips over, pinning you underneath. At night, the ice weasels come." --Matt Groening From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 18 15:24:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERx4l-0006yn-SD for ospf-archive@megatron.ietf.org; Tue, 18 Oct 2005 15:24:43 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23419 for ; Tue, 18 Oct 2005 15:24:36 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.011160AF@cherry.ease.lsoft.com>; Tue, 18 Oct 2005 15:24:25 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88364926 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 18 Oct 2005 15:11:38 -0400 Received: from 209.119.1.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 18 Oct 2005 15:01:38 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <8.0059DF42@grape.ease.lsoft.com>; Tue, 18 Oct 2005 15:01:38 -0400 Message-ID: Date: Tue, 18 Oct 2005 15:01:16 -0400 Reply-To: Mailing List Sender: Mailing List From: Jeff Endenburg Subject: multiple numbered p2p links with same address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Trying to understand the behaviour of an OSPF routing entity which has multiple numbered P2P links, each of which has the same IP address. The address is the same as the circuitless IP (i.e. /32 mask) that is assigned to the box itself. I can't comment on why it was implemented this way, as it's 3rd-party. It needs to interop with my box across the P2P links though, and mine uses numbered P2P links that have unique addresses. Intuitively, using the same address for multiple interfaces doesn't seem right. However, after reading through the archives here and other information on-line, I haven't found anything specific regarding the addressing of numbered links. The only downside I can think of will be that it won't be possible to reach (e.g. ping) a specific interface on the box. Any help would be appreciated! Apologies if this has been discussed before and I missed it. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 20 12:35:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESdNc-0004vJ-R3 for ospf-archive@megatron.ietf.org; Thu, 20 Oct 2005 12:35:02 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28152 for ; Thu, 20 Oct 2005 12:34:51 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.011189BC@cherry.ease.lsoft.com>; Thu, 20 Oct 2005 12:34:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88530508 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 12:34:47 -0400 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 20 Oct 2005 12:34:46 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j9KGYjBm059682 for ; Thu, 20 Oct 2005 09:34:46 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j9KGYjG07236 for ; Thu, 20 Oct 2005 09:34:45 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v734) References: <1C9BDA2C-9C9A-4F15-A8D2-38642FA202AB@juniper.net> <43500E3E.A43F0FBD@earthlink.net> <15F23A11-0833-4025-A3AA-9DA00585465D@juniper.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.734) Message-ID: <56C74893-19BB-4092-BC4B-FA8BA6C616EA@juniper.net> Date: Thu, 20 Oct 2005 10:34:43 -0600 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit On Oct 17, 2005, at 8:13 AM, Paul Jakma wrote: > On Fri, 14 Oct 2005, Dave Katz wrote: > > >> If the dead timer is one sec, then it takes one second from the >> last hello received to fail a neighbor. The actual detection time >> for a failure will be between 1 and 1-i, where i is the longest >> interpacket gap. >> > > Surely it'd always be at least 1? If we're measuring the time from a failure until the time the dead timer expires, the time is always less than 1 (neglecting latency.) It's one second since the last time we received a hello that the neighbor emitted, so any failure must have come later than that (and thus the interval to declaring neighbor failure is less than that.) > > >> false negative increase faster than linearly as it is. What you >> *really* don't want is a bunch of flapping adjacencies. >> > > Yep, but that's operational more than anything else, I guess. Um, yes, but as far as I know we're building operational networks and not a theoretical testbed. There is ample historical evidence that many OSPF implementations cannot deal with high levels of flappage (including the dominant implementation, unless it has undergone very serious rework in the recent past.) You would be right in saying that a properly implemented system should shrug off flapping as a mere annoyance, but most network operators are at the mercy of multiple vendors of various skill levels, and their networks will suffer. The nature of OSPF is that flaps are propagated throughout the network and *every* implementation has to be able to cope. > >> >> Third, as you start speeding things up, you need to be able to >> control the rate on a per-neighbor basis. Otherwise, one slower >> guy can totally hose things, so either everybody has to go slow >> (suboptimal) or everybody flaps with the guy (really suboptimal.) >> > > This would be because of a monolithic OSPF protocol implementation, > unable to service the Hello sub-protocol because it's busy doing > something else? Doesn't matter why. Maybe the neighbor is an underpowered box that has I/O bandwidth limitations. Not all routers are created equal, and there is always a point where the combination of neighbor count and packet speed will exceed the capabilities of some boxes while being within the realm of reason with others, even with perfect software. > > Presuming the machine is either fast enough to keep up (even with a > monolithic implementation) or seperates the running of Hello from > the rest of OSPF (which some implementations do I believe), then > things should be ok. I happen to know one of those separated impelementations quite well, but I guarantee that if you push it hard enough it will fall over. Once the volume of incoming hellos exceeds the bandwidth (including processing power) of the path, you're SOL. > > In such a case, regular quick failures would still induce protocol > "fibrilliation" (excellent term ;) ) wouldn't they, regardless of > whether it's BFD or fast Hello or a slow monolithic implementation > which indicates failure / causes flaps? I.E. the "fibrillation" > problem probably should be examined, even with BFD (if it's even > possible to solve it in the protocol).. Yes, and this is the one key ingredient of BFD--the timers for a session can be dialled back, in both directions, by unilateral action of one end of the session, without dropping the session. A system has full control over its load (both RX and TX) and thus can autonomously protect itself by setting the load to any arbitrary level (trading off detection time, of course, but I don't think you'll find any operator that would rather have stability.) > > >> Fourth, OSPF hellos serve two purposes (liveness and state >> management.) Once the neighbor comes up, the state information is >> redundant. It seems wasteful to send all this redundant >> information at a faster and faster rate. >> > > Hmm, there's maybe 36 bytes of redundant information, not much. > Plus, OSPF Hello does multicast, a BFD "full mesh" between a couple > of machines on a multi-access network would have far more overhead ;). I'm not concerned about bytes so much as CPU, but yeah, it's a mostly specious argument if you do things properly in the OSPF receive routine (unless you've turned on crypto authentication, in which case you're really hosed.) From the point of view of a single system, the receive load for multicast versus a full mesh is identical (it's the transmit load that goes from O(1) to O(N).) Overall load (TX+RX) as viewed by a single system is doubled in a full mesh. > > Ie, Fast-Hello is still quite interesting for multi-access > networks, for efficiency, isn't it? How does OSPF Hello compare to > BFD here? Network bandwidth efficiency is uninteresting when even the cheapest consumer gear runs at 100 Mbps. The Hello packet load goes from O(N) to O(N^2) as viewed on the subnet, but the load is still an unmeasurable percentage of the capacity of the link on any real network (if you had enough routers on a single subnet to make this number meaningful, you'd have other problems.) Plus, nobody uses truly shared media any more--even the consumer gear keeps traffic off of links where it needn't go. Plus, since it's all unicast, the total load as perceived by any machine only doubles. In exchange for doubling the load you gain the ability to control independently the detection time on a pairwise basis. OSPF is full of complexity in the name of efficiency, which is one of the reasons it's difficult to implement. This stuff might have made sense back in the days of 9600bps links, but it just gets in the way these days. EIGRP is even worse. ISIS is the only protocol I know that uses multicast in a useful way (flooding creates a load independent of neighbor count.) But that's a separate rant. > > >> My position for awhile now is that the network as a whole needs to >> be able to pull its own fat out of the fire if things start to >> collapse, and OSPF is just too rigid to allow that. >> > > Hmm, interesting thought. What could be done though? BFD. That's one of the reasons we did it. Otherwise we'd have to overhaul every protocol that has a detection timer in an incompatible way. > > I suspect this might be more a combination of implementation + > operational issues though, than a problem with OSPF. OSPF has two fundamental problems. First, architecturally it is incapable of detection times of less than two seconds unless you start making hacks (and is incapable of detection times of less than one second unless you start making incredibly egregious hacks.) Secondly, you cannot change the dead time and hello interval without dropping the adjacency. That makes adaptation a non-starter. I'm adamant about this stuff because I've watched networks collapse for years. The simple fact is that *every* major network collapse that I know about in the 20 years I've been in this racket has been ultimately due to fibrillation. It was true for AOL Down for 19 Hours (1995), and the MCI frame relay network that was down for ten days in the late 90s (taking out the Chicago Board of Trade), and the ATT SS7 phone network collapse. (OK, it wasn't true of the NSFnet in 1990 when the 55th router was added, but that's another story.) As networks get even bigger, and even faster, and the demand for shorter detection times grows, it is increasingly imperative that networks be self-repairing. Manually reconfiguring during a network collapse is not practical, particularly when (as in OSPF) it creates even more outages. When BFD was designed, adaptivity was the single biggest requirement (IMHO). --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 20 12:53:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESdfL-00059R-4i for ospf-archive@megatron.ietf.org; Thu, 20 Oct 2005 12:53:19 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29571 for ; Thu, 20 Oct 2005 12:53:09 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.011189CC@cherry.ease.lsoft.com>; Thu, 20 Oct 2005 12:53:17 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88530996 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 12:53:16 -0400 Received: from 64.233.162.193 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 20 Oct 2005 12:43:16 -0400 Received: by zproxy.gmail.com with SMTP id x3so249453nzd for ; Thu, 20 Oct 2005 09:43:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=HEsk3l3tomu5OJQVQpRrDGtQIAhpdqK0NrYZJ7N2KcFVegZUbvDikswMlycHdWo+phaUjS635W/vUE8CQZ4fU2xUy3QTIbm4gsPtDZyt/qNrU0nPjFNjvobFn827rMb1sG5rV4nzQDZEnisaPfnX/Bs4UR7IozrTpx9ud1nS6tc= Received: by 10.37.20.35 with SMTP id x35mr1814252nzi; Thu, 20 Oct 2005 09:43:16 -0700 (PDT) Received: by 10.36.141.8 with HTTP; Thu, 20 Oct 2005 09:43:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5534_2390597.1129826596037" References: <4346F494.8070306@cisco.com> Message-ID: <45f8514d0510200943x1cc7b9f4xe67d838189781bfe@mail.gmail.com> Date: Thu, 20 Oct 2005 09:43:16 -0700 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: OSPF WG Meeting at IETF 64 in Vancouver, BC To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4346F494.8070306@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: ------=_Part_5534_2390597.1129826596037 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi There, Note that my email address has changed : dube.rohit@gmail.com Best Regards, --rohit. On 10/7/05, Acee Lindem wrote: > > If you have drafts you'd like to present at the next OSPF WG meeting in > Vancouver, > please unicast Rohit and myself. > > Thanks, > Acee > ------=_Part_5534_2390597.1129826596037 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi There,

Note that my email address has changed : dube.rohit@gmail.com

Best Regards,
--rohit.

On 10/7/05, Acee Lindem <acee@= cisco.com> wrote:
If you have drafts you'd like to present at the next OSPF WG meeting in
= Vancouver,
please unicast Rohit and myself.

Thanks,
Acee

------=_Part_5534_2390597.1129826596037-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 20 15:22:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESfzT-0006rZ-F8 for ospf-archive@megatron.ietf.org; Thu, 20 Oct 2005 15:22:16 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08137 for ; Thu, 20 Oct 2005 15:22:04 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.01118AF2@cherry.ease.lsoft.com>; Thu, 20 Oct 2005 15:22:13 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88544306 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 15:22:11 -0400 Received: from 207.69.195.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 20 Oct 2005 15:22:11 -0400 Received: from h-68-164-86-60.snvacaid.dynamic.covad.net ([68.164.86.60] helo=earthlink.net) by pop-siberian.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1ESfzP-00031E-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 15:22:11 -0400 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: <1C9BDA2C-9C9A-4F15-A8D2-38642FA202AB@juniper.net> <43500E3E.A43F0FBD@earthlink.net> <15F23A11-0833-4025-A3AA-9DA00585465D@juniper.net> <56C74893-19BB-4092-BC4B-FA8BA6C616EA@juniper.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <4357F13E.82941A6D@earthlink.net> Date: Thu, 20 Oct 2005 12:34:22 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Group, I thought this thread had died after I got pulled to do a few things.. However, it seems like it is still alive. Also, sorry, I tend to be verbose.. My long comments are inline and mostly it is not re-inforcing the previous comments. Mitchell Erblich --------------------- Dave Katz wrote: > > On Oct 17, 2005, at 8:13 AM, Paul Jakma wrote: > > > On Fri, 14 Oct 2005, Dave Katz wrote: > > > > > >> If the dead timer is one sec, then it takes one second from the > >> last hello received to fail a neighbor. The actual detection time > >> for a failure will be between 1 and 1-i, where i is the longest > >> interpacket gap. > >> > > > > Surely it'd always be at least 1? > > If we're measuring the time from a failure until the time the dead > timer expires, the time is always less than 1 (neglecting latency.) > It's one second since the last time we received a hello that the > neighbor emitted, so any failure must have come later than that (and > thus the interval to declaring neighbor failure is less than that.) > > > > > > >> false negative increase faster than linearly as it is. What you > >> *really* don't want is a bunch of flapping adjacencies. > >> > > > > Yep, but that's operational more than anything else, I guess. > > Um, yes, but as far as I know we're building operational networks and > not a theoretical testbed. There is ample historical evidence that > many OSPF implementations cannot deal with high levels of flappage > (including the dominant implementation, unless it has undergone very > serious rework in the recent past.) You would be right in saying > that a properly implemented system should shrug off flapping as a > mere annoyance, but most network operators are at the mercy of > multiple vendors of various skill levels, and their networks will > suffer. The nature of OSPF is that flaps are propagated throughout > the network and *every* implementation has to be able to cope. > Implimentations do vary. If a router keeps history of its nbrs MTBF (mean time between failure) of missed one or more hellos. Assuming hellos are used to determine aliveness. IT "CAN THEN" determine * is it a missed / lost recv'd hello, * have we recv'd a OSPF control or data pkt from this "adj nbr", * do we have alternate routes, * do we have immediate data/control pkts to send to this "adj nbr", * do we have any other communication with this router, * do we need to recalc any algorithms, * is this a random or a freq drop of pkts, * IFF we bring down the adj, should we delay our full adj or whatever status with that nbr, * SHOULD we send a OSPF control pkt that SHOULD be acked and start a delay timer as long as we are not losing/delaying any real data. **** etc... IF this router only adds a few elements to out LSDB and the two routers are only out of sync, then the effort to resume COULD be minimal. Thus, adj flapping should be a dead issue with current implimentations.. > > > >> > >> Third, as you start speeding things up, you need to be able to > >> control the rate on a per-neighbor basis. Otherwise, one slower > >> guy can totally hose things, so either everybody has to go slow > >> (suboptimal) or everybody flaps with the guy (really suboptimal.) > >> > > > > This would be because of a monolithic OSPF protocol implementation, > > unable to service the Hello sub-protocol because it's busy doing > > something else? > > Doesn't matter why. Maybe the neighbor is an underpowered box that > has I/O bandwidth limitations. Not all routers are created equal, > and there is always a point where the combination of neighbor count > and packet speed will exceed the capabilities of some boxes while > being within the realm of reason with others, even with perfect > software. > Oh, however, if you prioritize control pkts with a algorithm so you send out hellos or such in a "just in time method" AND the OVERLOAD condition is short lived. Then the non peaks should be able to decrease the queue lengths that were built up at overload time. If the diff between overload and min loading is great enough or the times between two successive OVERLOAD conditions is long enough the queue lengths should return to normal length with normal pkt processing latencies.. > > > > Presuming the machine is either fast enough to keep up (even with a > > monolithic implementation) or seperates the running of Hello from > > the rest of OSPF (which some implementations do I believe), then > > things should be ok. > > I happen to know one of those separated impelementations quite well, > but I guarantee that if you push it hard enough it will fall over. > Once the volume of incoming hellos exceeds the bandwidth (including > processing power) of the path, you're SOL. However, so given my above statement. You either get very large periodic queues, you impliment RED or such, and the pkts are rexmit'ed that were either delayed proc or dropped via RED. Its not like a router SHOULD fall over a play dead because it got overloaded. Overload should be a nice simple condition that can and SHOULD be dealt with in deterministic means. AND as we increase the bandwidth or with normal 10Mb/sec or faster, I can not see how sub sec hellos SHOULD effect adjs in a properly designed router software. If we push it to the extreme with say 1 ms hello interval, a separate input priority queue, identify that 10 of 10 pkts ARE just repeating previous hellos. We then COULD create a special hello update pkt that is just larger than runt size and only deal with JUST a pkt/per/sec processing overhead and remove the extraneous repeative nbr info. This would fit well with Kb wireless type links. NO SOL... > > > > > In such a case, regular quick failures would still induce protocol > > "fibrilliation" (excellent term ;) ) wouldn't they, regardless of > > whether it's BFD or fast Hello or a slow monolithic implementation > > which indicates failure / causes flaps? I.E. the "fibrillation" > > problem probably should be examined, even with BFD (if it's even > > possible to solve it in the protocol).. > > Yes, and this is the one key ingredient of BFD--the timers for a > session can be dialled back, in both directions, by unilateral action > of one end of the session, without dropping the session. A system > has full control over its load (both RX and TX) and thus can > autonomously protect itself by setting the load to any arbitrary > level (trading off detection time, of course, but I don't think > you'll find any operator that would rather have stability.) > I just have not had enough experience with BFD and admins trying to config DYNAMIC loads in a manual way. I don't see how a router in a non MPLS configuration can "control" its load. Its max load is based on the number of live interfaces, the summation of the bandwidth of those interfaces, what percentage of pkts coming in one interface is directed to one or more interfaces, the size of eack pkt, the interpkt gap, the memory allocated for the rcv /xmit queues, the latencies in handling the pkt, AND the percentage of pkts transversing the router (intermediate system). > > > > > >> Fourth, OSPF hellos serve two purposes (liveness and state > >> management.) Once the neighbor comes up, the state information is > >> redundant. It seems wasteful to send all this redundant > >> information at a faster and faster rate. > >> > > > > Hmm, there's maybe 36 bytes of redundant information, not much. > > Plus, OSPF Hello does multicast, a BFD "full mesh" between a couple > > of machines on a multi-access network would have far more overhead ;). > > I'm not concerned about bytes so much as CPU, but yeah, it's a mostly > specious argument if you do things properly in the OSPF receive > routine (unless you've turned on crypto authentication, in which case > you're really hosed.) > > From the point of view of a single system, the receive load for > multicast versus a full mesh is identical (it's the transmit load > that goes from O(1) to O(N).) Overall load (TX+RX) as viewed by a > single system is doubled in a full mesh. > > > > > Ie, Fast-Hello is still quite interesting for multi-access > > networks, for efficiency, isn't it? How does OSPF Hello compare to > > BFD here? > > Network bandwidth efficiency is uninteresting when even the cheapest > consumer gear runs at 100 Mbps. The Hello packet load goes from O(N) > to O(N^2) as viewed on the subnet, but the load is still an > unmeasurable percentage of the capacity of the link on any real > network (if you had enough routers on a single subnet to make this > number meaningful, you'd have other problems.) Plus, nobody uses > truly shared media any more--even the consumer gear keeps traffic off > of links where it needn't go. Plus, since it's all unicast, the > total load as perceived by any machine only doubles. In exchange for > doubling the load you gain the ability to control independently the > detection time on a pairwise basis. > > OSPF is full of complexity in the name of efficiency, which is one of > the reasons it's difficult to implement. This stuff might have made > sense back in the days of 9600bps links, but it just gets in the way > these days. EIGRP is even worse. ISIS is the only protocol I know > that uses multicast in a useful way (flooding creates a load > independent of neighbor count.) But that's a separate rant. > > > > > > >> My position for awhile now is that the network as a whole needs to > >> be able to pull its own fat out of the fire if things start to > >> collapse, and OSPF is just too rigid to allow that. > >> > > > > Hmm, interesting thought. What could be done though? > > BFD. That's one of the reasons we did it. Otherwise we'd have to > overhaul every protocol that has a detection timer in an incompatible > way. > > > > > I suspect this might be more a combination of implementation + > > operational issues though, than a problem with OSPF. > > OSPF has two fundamental problems. First, architecturally it is > incapable of detection times of less than two seconds unless you > start making hacks (and is incapable of detection times of less than > one second unless you start making incredibly egregious hacks.) > Secondly, you cannot change the dead time and hello interval without > dropping the adjacency. That makes adaptation a non-starter. > Wow. Can I say that I COMPLETELY disagree. In many environments, two routers can speak to each other either across more than 1 interface or where 1 interface carries multiple VPN sessions, each doubling of the communciation channel "implictly" halves the detection time between the two routers. Ex: If we approximate the avg of the hello intervals with say 2 channels each having a independently interval of say 2 secs, the avg hello seen by each should be about 1 sec. A very common item was/is to use different auths per channel but if two routers had in common two different auths, then the hellos per auth would have the same effect as decreasing the hello interval. In addition, I don't know what would prevent a router from more freq sending hellos. Can anyone really say that if a OSPF router saw a hello every 1 sec when configured for rec hellos from a nbr every 2 secs, that the extra hello would be dropped and not reset the aliveness timer. And again sorry.. What would be wrong with being able to change the timers before the adj was dropped. Changing the intervals only changes the field maching criteria which should drop the pkt, not the adj. If both routers could be changed approx within the dead time, the adj should be reinforced by the new values. One can simply login to both routers simultaneiously and type the CLI commands on both routers in separate windows and then hit return for both. > I'm adamant about this stuff because I've watched networks collapse > for years. The simple fact is that *every* major network collapse > that I know about in the 20 years I've been in this racket has been > ultimately due to fibrillation. It was true for AOL Down for 19 > Hours (1995), and the MCI frame relay network that was down for ten > days in the late 90s (taking out the Chicago Board of Trade), and the > ATT SS7 phone network collapse. (OK, it wasn't true of the NSFnet in > 1990 when the 55th router was added, but that's another story.) As > networks get even bigger, and even faster, and the demand for shorter > detection times grows, it is increasingly imperative that networks be > self-repairing. Manually reconfiguring during a network collapse is > not practical, particularly when (as in OSPF) it creates even more > outages. When BFD was designed, adaptivity was the single biggest > requirement (IMHO). > > --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 20 19:35:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjwI-00008C-AU for ospf-archive@megatron.ietf.org; Thu, 20 Oct 2005 19:35:14 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09004 for ; Thu, 20 Oct 2005 19:35:03 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.01118F59@cherry.ease.lsoft.com>; Thu, 20 Oct 2005 19:35:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88560866 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 19:35:07 -0400 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 20 Oct 2005 19:35:07 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j9KNZ7Bm063328 for ; Thu, 20 Oct 2005 16:35:07 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j9KNZ6G88057 for ; Thu, 20 Oct 2005 16:35:06 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v734) References: <1C9BDA2C-9C9A-4F15-A8D2-38642FA202AB@juniper.net> <43500E3E.A43F0FBD@earthlink.net> <15F23A11-0833-4025-A3AA-9DA00585465D@juniper.net> <56C74893-19BB-4092-BC4B-FA8BA6C616EA@juniper.net> <4357F13E.82941A6D@earthlink.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.734) Message-ID: <3644C164-1F7A-48D7-9F81-357051BCFF81@juniper.net> Date: Thu, 20 Oct 2005 17:35:05 -0600 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4357F13E.82941A6D@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit On Oct 20, 2005, at 1:34 PM, Erblichs wrote: > > Implimentations do vary. If a router keeps history of its > nbrs MTBF (mean time between failure) of missed one or more > hellos. Assuming hellos are used to determine aliveness. IT > "CAN THEN" determine > * is it a missed / lost recv'd hello, > * have we recv'd a OSPF control or data pkt > from this "adj nbr", > * do we have alternate routes, > * do we have immediate data/control pkts to send to > this "adj nbr", > * do we have any other communication with this > router, > * do we need to recalc any algorithms, > * is this a random or a freq drop of pkts, > * IFF we bring down the adj, should we delay our > full adj or whatever status with that nbr, > > * SHOULD we send a OSPF control pkt that SHOULD > be acked and start a delay timer as long as we > are not losing/delaying any real data. > > **** etc... > > IF this router only adds a few elements to out LSDB and > the two routers are only out of sync, then the effort to > resume COULD be minimal. > > Thus, adj flapping should be a dead issue with current > implimentations.. It is certainly possible to improve the behavior of systems in the face of instability, and even to try to protect the lesser implementations (though it is arguably not in a competitor's best interest to do so.) The fact remains that the reason people want to go to faster detection times is to detect failures (and reroute) more quickly. This requires that the full rerouting mechanisms of OSPF are brought to bear (no dillydallying trying to figure out if things are "really" dead) and it requires that the detection mechanism have a very small probability of detecting false failures. The validity of statistical methods in an application like this (particularly when jitter is being applied) is beyond my capabilities in that area, but I don't think it would be easy to do it well. >> >> Doesn't matter why. Maybe the neighbor is an underpowered box that >> has I/O bandwidth limitations. Not all routers are created equal, >> and there is always a point where the combination of neighbor count >> and packet speed will exceed the capabilities of some boxes while >> being within the realm of reason with others, even with perfect >> software. >> >> > > Oh, however, if you prioritize control pkts with a algorithm > so you send out hellos or such in a "just in time method" AND the > OVERLOAD condition is short lived. Then the non peaks should > be able to decrease the queue lengths that were built up at > overload time. If the diff between overload and min loading is > great enough or the times between two successive OVERLOAD > conditions is long enough the queue lengths should return to > normal length with normal pkt processing latencies.. If overloads are short-lived, life is good (or at least better.) But my experience is that overload creeps up (as more and more stuff gets deployed) or else comes on like a freight train (misconfiguration) and that's when you get metastable collapse states. If there is simply not enough capacity to do the processing, no magic will get you out of it. The only choice is to reduce the load. >> I happen to know one of those separated impelementations quite well, >> but I guarantee that if you push it hard enough it will fall over. >> Once the volume of incoming hellos exceeds the bandwidth (including >> processing power) of the path, you're SOL. >> > > However, so given my above statement. You either get very > large periodic queues, you impliment RED or such, and the > pkts are rexmit'ed that were either delayed proc or > dropped via RED. We're talking about accurate liveness maintenance here, in which neither RED nor retransmission has any place. > > Its not like a router SHOULD fall over a play dead because > it got overloaded. Overload should be a nice simple condition > that can and SHOULD be dealt with in deterministic means. No argument here. > > AND as we increase the bandwidth or with normal 10Mb/sec or > faster, I can not see how sub sec hellos SHOULD effect > adjs in a properly designed router software. If you turn it up high enough, on enough neighbors, it WILL fail, either by sheer load, or by the fact that the aggregate jitter becomes a larger and larger component as the timescale is reduced, eventually overwhelming the detection time. There is pressure to achieve traditional routing failover at MPLS/APS-like rates; we're not talking about 500 msec detections here. > > If we push it to the extreme with say 1 ms hello interval, > a separate input priority queue, identify that 10 of 10 pkts > ARE just repeating previous hellos. We then COULD create a > special hello update pkt that is just larger than runt > size and only deal with JUST a pkt/per/sec processing overhead > and remove the extraneous repeative nbr info. The receive side is easier, since you can play games like this. When the transmit side can't get 'em out fast enough, there's no saving you however. >> >> Yes, and this is the one key ingredient of BFD--the timers for a >> session can be dialled back, in both directions, by unilateral action >> of one end of the session, without dropping the session. A system >> has full control over its load (both RX and TX) and thus can >> autonomously protect itself by setting the load to any arbitrary >> level (trading off detection time, of course, but I don't think >> you'll find any operator that would rather have stability.) >> >> > > I just have not had enough experience with BFD and > admins trying to config DYNAMIC loads in a manual > way. > > I don't see how a router in a non MPLS configuration > can "control" its load. Its max load is based on the > number of live interfaces, the summation of the > bandwidth of those interfaces, what percentage of > pkts coming in one interface is directed to one or > more interfaces, the size of eack pkt, the interpkt gap, > the memory allocated for the rcv /xmit queues, the > latencies in handling the pkt, AND the percentage of > pkts transversing the router (intermediate system). I'm referring to the load created by BFD, and the sensitivity of the system to overall system congestion (separate queues and hardware switching tend to make the data traffic immaterial.) The point is that if you are on the verge of a control protocol collapse, the ability to trade off detection time for stability is an important one (and the only way out of the situation.) >> >> OSPF has two fundamental problems. First, architecturally it is >> incapable of detection times of less than two seconds unless you >> start making hacks (and is incapable of detection times of less than >> one second unless you start making incredibly egregious hacks.) >> Secondly, you cannot change the dead time and hello interval without >> dropping the adjacency. That makes adaptation a non-starter. >> >> > > Wow. Can I say that I COMPLETELY disagree. > > In many environments, two routers can speak to each other > either across more than 1 interface or where 1 interface > carries multiple VPN sessions, each doubling of the > communciation channel "implictly" halves the detection > time between the two routers. > > Ex: If we approximate the avg of the hello intervals > with say 2 channels each having a independently interval > of say 2 secs, the avg hello seen by each should be about > 1 sec. A very common item was/is to use different auths > per channel but if two routers had in common two different > auths, then the hellos per auth would have the same effect > as decreasing the hello interval. I guess I'd put this somewhere between "hack" and "egregious hack." To attempt to achieve, say, 50 msec detection times while staying within the current OSPF spec, I would have to have a one second interval with a two second dead time across 40 separate channels. Further, to enforce my detection time requirement, the neighbor must space those packets in such a way as to guarantee that under normal circumstances that there is never more than 50 msec between two of them (25 is more realistic.) All of this would require mechanisms outside the protocol to achieve, as both sides need to know that this particular game is being played and then play it appropriately. Yes, it can be made to work, but it's ugly. > > In addition, I don't know what would prevent a router > from more freq sending hellos. Can anyone really say > that if a OSPF router saw a hello every 1 sec when > configured for rec hellos from a nbr every 2 secs, that > the extra hello would be dropped and not reset the > aliveness timer. You can always send them more often than you said in your hello; this always happens to some extent with jitter anyhow. But the point is knowing when to declare the neighbor down. > > And again sorry.. > > What would be wrong with being able to change the > timers before the adj was dropped. Changing the > intervals only changes the field maching criteria > which should drop the pkt, not the adj. If both > routers could be changed approx within the dead time, > the adj should be reinforced by the new values. > > One can simply login to both routers simultaneiously > and type the CLI commands on both routers in separate > windows and then hit return for both. You're kidding, right? Even if this made any sense at all, I don't think I could move my mouse between windows and hit a second CR within 50 msec, even if the CLI processing was instantaneous and the latency to each of the routers was identical, neither of which is true. In the situation where my network was melting (assuming I could log in at all because the network was melting) I would want to do this on all of my links. You're missing my point entirely. I see it as a fundamental requirement that the network be able to save itself quickly and efficiently in the face of catastrophic collapse, and the probability of catastrophic collapse grows rapidly as the detection time requirements are tightened. This cannot be done manually, and it cannot be done bilaterally (unless you don't mind flapping every adjacency first.) To do it automatically within the confines of OSPF would require some very interesting (and possibly intractably unstable) heuristics to try to track what the other guy is doing with his announced timer values. My point is that, yes, with enough complexity and heuristics and spec- bending it *might* be possible to make the existing OSPF spec handle arbitrarily small time values. It would also require mechanisms negotiated outside the protocol to achieve, which has interoperability implications. This is an interesting intellectual exercise, but it is not clear that there is any benefit to doing so when there is a mechanism that has been defined (and for which multiple interoperable implementations exist) that is clean, functional, nicely decoupled, requires no changes to the protocol spec, operates identically over six orders of magnitude of time intervals, has broader system-wide benefits, and addresses the problem at hand specifically and in a straightforward way. Perhaps you're an optimist about networks, where all systems operate as they "should" and all developers are as talented as you and I. I'm a pessimist/realist, and all I care about is that the network is stable and functioning, and all experience points to the fact that most software is mediocre and fails miserably when it operates too close to the edge of the cliff. I'd hazard a guess that the operators of networks on this list don't care about "should" very much, except that their network "should" stay up and not suffer catastrophic failure. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 20 20:09:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESkTP-0000hp-U6 for ospf-archive@megatron.ietf.org; Thu, 20 Oct 2005 20:09:28 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11914 for ; Thu, 20 Oct 2005 20:09:17 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.01118FFD@cherry.ease.lsoft.com>; Thu, 20 Oct 2005 20:09:26 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88562121 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 20:09:14 -0400 Received: from 198.137.194.222 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 20 Oct 2005 19:59:13 -0400 Received: (qmail 29920 invoked by uid 211); 20 Oct 2005 23:59:13 -0000 Received: from challah.msrl.com (HELO ?127.0.0.1?) (vgill@198.137.194.222) by challah.msrl.com with RC4-MD5 encrypted SMTP; 20 Oct 2005 23:59:13 -0000 User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) MIME-Version: 1.0 References: <1C9BDA2C-9C9A-4F15-A8D2-38642FA202AB@juniper.net> <43500E3E.A43F0FBD@earthlink.net> <15F23A11-0833-4025-A3AA-9DA00585465D@juniper.net> <56C74893-19BB-4092-BC4B-FA8BA6C616EA@juniper.net> <4357F13E.82941A6D@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <43582F4D.6020907@vijaygill.com> Date: Thu, 20 Oct 2005 19:59:09 -0400 Reply-To: Mailing List Sender: Mailing List From: vijay gill Subject: Re: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4357F13E.82941A6D@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Erblichs wrote: > And again sorry.. > > What would be wrong with being able to change the > timers before the adj was dropped. Changing the > intervals only changes the field maching criteria > which should drop the pkt, not the adj. If both > routers could be changed approx within the dead time, > the adj should be reinforced by the new values. > > One can simply login to both routers simultaneiously > and type the CLI commands on both routers in separate > windows and then hit return for both. > If any vendor came to me and said this, that vendor would be shown the door. Never, ever would this be deployed at any network I have a say in. EVER. /vijay From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 20 22:01:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESmE6-0000hQ-7G for ospf-archive@megatron.ietf.org; Thu, 20 Oct 2005 22:01:46 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17024 for ; Thu, 20 Oct 2005 22:01:34 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.011191A3@cherry.ease.lsoft.com>; Thu, 20 Oct 2005 22:01:43 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88569395 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 22:01:42 -0400 Received: from 207.69.195.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 20 Oct 2005 22:01:42 -0400 Received: from h-68-164-86-60.snvacaid.dynamic.covad.net ([68.164.86.60] helo=earthlink.net) by pop-knobcone.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1ESmE1-0006nt-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 20 Oct 2005 22:01:41 -0400 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: <1C9BDA2C-9C9A-4F15-A8D2-38642FA202AB@juniper.net> <43500E3E.A43F0FBD@earthlink.net> <15F23A11-0833-4025-A3AA-9DA00585465D@juniper.net> <56C74893-19BB-4092-BC4B-FA8BA6C616EA@juniper.net> <4357F13E.82941A6D@earthlink.net> <43582F4D.6020907@vijaygill.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43584A5C.130C4EE9@earthlink.net> Date: Thu, 20 Oct 2005 18:54:36 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit vijay gill, Are you saying that admins SHOULD BE prevented from modifying the timer values once a adj has been established? Do you consider this some type of DOS attack and prevent this without taking down the adj? The assumption is that the admin has a valid reason for doing so and that he has the proper creds for the login. All I am saying is that if the dead router interval is long enough then their is no guaranteed loss of adj. If you put checks into when CLI commands can be executed and changed even by authorized personal, this engineer would be interested. Don't we assume that the admin knows what he is doing? We don't always agree with what he wants, but I tend to give him enough "leeway" and hope.. Mitchell Erblich ---------------------------- vijay gill wrote: > > Erblichs wrote: > > And again sorry.. > > > > What would be wrong with being able to change the > > timers before the adj was dropped. Changing the > > intervals only changes the field maching criteria > > which should drop the pkt, not the adj. If both > > routers could be changed approx within the dead time, > > the adj should be reinforced by the new values. > > > > One can simply login to both routers simultaneiously > > and type the CLI commands on both routers in separate > > windows and then hit return for both. > > > > If any vendor came to me and said this, that vendor would be shown the > door. Never, ever would this be deployed at any network I have a say in. > EVER. > > /vijay From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 21 01:27:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESpRc-0004Qv-K5 for ospf-archive@megatron.ietf.org; Fri, 21 Oct 2005 01:27:56 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27747 for ; Fri, 21 Oct 2005 01:27:45 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.011196F9@cherry.ease.lsoft.com>; Fri, 21 Oct 2005 1:27:52 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88586703 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 21 Oct 2005 01:27:51 -0400 Received: from 212.17.55.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 21 Oct 2005 01:27:51 -0400 Received: from sheen.jakma.org (sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id j9L5RkgD026059 for ; Fri, 21 Oct 2005 06:27:49 +0100 X-X-Sender: paul@sheen.jakma.org References: <1C9BDA2C-9C9A-4F15-A8D2-38642FA202AB@juniper.net> <43500E3E.A43F0FBD@earthlink.net> <15F23A11-0833-4025-A3AA-9DA00585465D@juniper.net> <56C74893-19BB-4092-BC4B-FA8BA6C616EA@juniper.net> <4357F13E.82941A6D@earthlink.net> <3644C164-1F7A-48D7-9F81-357051BCFF81@juniper.net> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on hibernia.jakma.org X-Virus-Status: Clean Message-ID: Date: Fri, 21 Oct 2005 06:31:56 +0100 Reply-To: Mailing List Sender: Mailing List From: Paul Jakma Subject: Re: 1s dead-interval + sub-second hellos To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3644C164-1F7A-48D7-9F81-357051BCFF81@juniper.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: On Thu, 20 Oct 2005, Dave Katz wrote: > I guess I'd put this somewhere between "hack" and "egregious hack." > To attempt to achieve, say, 50 msec detection times while staying > within the current OSPF spec, I would have to have a one second > interval with a two second dead time across 40 separate channels. > Further, to enforce my detection time requirement, the neighbor > must space those packets in such a way as to guarantee that under > normal circumstances that there is never more than 50 msec between > two of them (25 is more realistic.) All of this would require > mechanisms outside the protocol to achieve, as both sides need to > know that this particular game is being played and then play it > appropriately. Yes, it can be made to work, but it's ugly. It could be done in protocol, as we still have 0s dead-time to hang a hat on. 0s dead-interval -> "adaptive hello and dead interval" (say). With such a dead-interval: - advertise number of hellos/s as your hello-interval - on receiving hello: - record the millisec hello/s value for that neighbour - (re)?set neigbour specific dead-timer to hello-interval * (X + Y) where X is an OSPF constant (eg 2, 3 or 4), and Y is at the discretion of the implemention, intended to be adapted according to perceived load. That gets things down to 3ms hello-interval and 6ms or 9ms dead-time within confines of current OSPF Hello packet format (which I suspect is too "real-time" for most implementations to be able to reliably detect or meet). It also allows the hello-interval to be modified unilaterally during operation. But I suspect that would be reinventing BFD poorly.. > My point is that, yes, with enough complexity and heuristics and > spec-bending it *might* be possible to make the existing OSPF spec > handle arbitrarily small time values. It would also require > mechanisms negotiated outside the protocol to achieve, which has > interoperability implications. Wouldn't be that complex, see above ;). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "Wheee! ...ow, I bit my tongue!" --Ralph Wiggum Bart's Inner Child (Episode 1F05) From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 21 16:00:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET33j-0000t6-1a for ospf-archive@megatron.ietf.org; Fri, 21 Oct 2005 16:00:11 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03439 for ; Fri, 21 Oct 2005 15:59:59 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.01119FB2@cherry.ease.lsoft.com>; Fri, 21 Oct 2005 16:00:05 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 88647555 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 21 Oct 2005 16:00:02 -0400 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 21 Oct 2005 15:50:02 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ET2tu-0001EO-3e; Fri, 21 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Fri, 21 Oct 2005 15:50:02 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-traffic-06.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Traffic Engineering Extensions to OSPF version 3 Author(s) : K. Ishiguro, et al. Filename : draft-ietf-ospf-ospfv3-traffic-06.txt Pages : 16 Date : 2005-10-21 This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-traffic-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ospfv3-traffic-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-ospfv3-traffic-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: <2005-10-21140208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-traffic-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-traffic-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21140208.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Wed Oct 26 04:41:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUgqX-0007nW-2E for ospf-archive@megatron.ietf.org; Wed, 26 Oct 2005 04:41:21 -0400 Received: from almond.ease.lsoft.com (almond.ease.lsoft.com [209.119.0.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04076 for ; Wed, 26 Oct 2005 04:41:05 -0400 (EDT) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.0096C103@almond.ease.lsoft.com>; Wed, 26 Oct 2005 4:41:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89020164 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 04:41:19 -0400 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 26 Oct 2005 04:31:15 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOY0042QLF6UK@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 16:40:18 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOY00GS8LF5GH@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 16:40:18 +0800 (CST) Received: from k49110 ([10.110.100.114]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOY005DULKHPH@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 16:43:30 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/alternative; boundary="Boundary_(ID_+RQudD2t35BDqXpw+jTdXQ)" X-Priority: 3 X-MSMail-priority: Normal Message-ID: <00bf01c5da07$ca565950$72646e0a@china.huawei.com> Date: Wed, 26 Oct 2005 16:32:23 +0800 Reply-To: Mailing List Sender: Mailing List From: kouzengjie Subject: accelerating convergence when ospf starting To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: This is a multi-part message in MIME format. --Boundary_(ID_+RQudD2t35BDqXpw+jTdXQ) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 QWxsLA0KICAgIE9TUEYgY29udmVyZ2VuY2UgY29udGFpbnMgbmVpZ2hib3IgZGlzY292ZXJ5IGFu ZCBsaW5rIHN0YXRlIGRhdGFiYXNlIHN5bmNocm9uaXphdGlvbi4NCk5laWdoYm9yIGRpc2NvdmVy eSBpcyBhY2hpZXZlZCBieSBoZWxsbyBwcm90b2NvbC4gRGVmYXVsdCBoZWxsbyBpbnRlcnZhbCBp cyAxMHMuDQpIZWxsbyBwYWNrZXRzIHNlbnQgYnkgbmVpZ2hib3JzIGlzIG5vdCB3b3JrIG9uIGVh Y2ggb3RoZXIuU28sY292ZXJnZW5jZSB0aW1lIGlzIGxvbmdlci4NCklmIGFkb3B0aW5nIGZvbGxv d2luZyBwcm9wb3NpdGlvbix0aGVuIGNvdmVyZ2VuY2UgdGltZSAgaXMgZGVjcmVhc2VkIHZlcnkg bXVjaCBvbiBicm9hZGNhc3QgbmV0d29ya3MuDQoNCiAgICAxLk5laWdoYm9ycyBpbW1lZGlhdGVs eSBzZW5kIGhlbGxvIHBhY2tldCB0byBwZWVyIHdoZW4gdGhleSByZWNlaXZlIGhlbGxvIHBhY2tl dCBmcm9tIHRoZSBwZWVyIHRoYXQgZmlyc3Qgc2VudCB0aGUgaGVsbG8gcGFja2V0Lg0KICAgIDIu QmFzZWQgMSxyb3V0ZXJzKCBtYXJrZWQgWCkgdGhhdCBzZW50IHRoZSBoZWxsbyBwYWNrZXQgd2ls bCByZXBpZGx5IHJlY2VpdmUgdGhlaXIgbmVpZ2hib3JzIGhlbGxvIHBhY2tldCBjYXJyeWluZyB0 aGVpciBwZWVycyhYKSBpbmZvcm1hdGlvbi4NCiAgICAzLkFmdGVyIDIsRFIgd2lsbCBzdGFydCB0 byBiZSBlbGVjdGVko6xidWlsZGluZyB0aGUgcmVsYXRpb24gb2YgYWRqYWNlbmN5IGFuZCBjb21w bGV0aW5nIGxpbmsgc3RhdGUgZGF0YWJhc2Ugc3luY2hyb25pemF0aW9uLg0KICAgIDQuQWZ0ZXIg ZGF0YWJhc2Ugc3luY2hyb25pemF0aW9uLHRoZSBoZWxsbyBwYWNrZXQgd2lsbCBiZSBzZW50IGV2 ZXJ5IHByb3Zpb3VzIGludGVydmFsIGVhY2ggb3RoZXIuDQoNCk90aGVyIGRpc3Bvc2FscyBhYm91 dCBPU1BGIGlzIHRoZSBzYW1lIHRvIFJGQyAyMzI4Lg0KDQpIb3cgYWJvdXQgZG8geW91IHRoaW5r Pw0KDQpiZXN0IHJlZ2FyZHMsDQpLb3U= --Boundary_(ID_+RQudD2t35BDqXpw+jTdXQ) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI3NjkiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5BbGwsPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7T1NQRiBjb252ZXJn ZW5jZSBjb250YWlucyBuZWlnaGJvciANCmRpc2NvdmVyeSBhbmQgbGluayBzdGF0ZSBkYXRhYmFz ZSBzeW5jaHJvbml6YXRpb24uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+TmVpZ2hi b3IgZGlzY292ZXJ5IGlzIGFjaGlldmVkIGJ5IGhlbGxvIHByb3RvY29sLiBEZWZhdWx0IA0KaGVs bG8gaW50ZXJ2YWwgaXMgMTBzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhlbGxv IHBhY2tldHMmbmJzcDtzZW50IGJ5IG5laWdoYm9ycyBpcyBub3Qgd29yayBvbiBlYWNoIA0Kb3Ro ZXIuU28sY292ZXJnZW5jZSB0aW1lIGlzIGxvbmdlci48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj5JZiBhZG9wdGluZyBmb2xsb3dpbmcgcHJvcG9zaXRpb24sdGhlbiBjb3ZlcmdlbmNl IHRpbWUmbmJzcDsgDQppcyBkZWNyZWFzZWQgdmVyeSBtdWNoIG9uIGJyb2FkY2FzdCBuZXR3b3Jr cy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgMS5OZWlnaGJvcnMgaW1tZWRpYXRl bHkgc2VuZCBoZWxsbyBwYWNrZXQgDQp0byBwZWVyJm5ic3A7d2hlbiB0aGV5IHJlY2VpdmUgaGVs bG8gcGFja2V0IGZyb20gdGhlIHBlZXIgdGhhdCBmaXJzdCBzZW50IHRoZSANCmhlbGxvIHBhY2tl dC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgMi5C YXNlZCAxLHJvdXRlcnMoIG1hcmtlZCBYKSB0aGF0IHNlbnQgdGhlIA0KaGVsbG8gcGFja2V0IHdp bGwgcmVwaWRseSByZWNlaXZlIHRoZWlyIG5laWdoYm9ycyBoZWxsbyBwYWNrZXQgDQpjYXJyeWlu ZyZuYnNwO3RoZWlyIHBlZXJzKFgpIGluZm9ybWF0aW9uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyAzLkFmdGVyIDIsRFImbmJzcDt3aWxsIHN0YXJ0 IHRvJm5ic3A7YmUgDQplbGVjdGVko6xidWlsZGluZyB0aGUgcmVsYXRpb24gb2YgYWRqYWNlbmN5 IGFuZCBjb21wbGV0aW5nIGxpbmsgc3RhdGUgZGF0YWJhc2UgDQpzeW5jaHJvbml6YXRpb24uPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQuQWZ0ZXIm bmJzcDtkYXRhYmFzZSBzeW5jaHJvbml6YXRpb24sdGhlIA0KaGVsbG8gcGFja2V0IHdpbGwgYmUg c2VudCBldmVyeSBwcm92aW91cyBpbnRlcnZhbCBlYWNoIG90aGVyLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPk90 aGVyIGRpc3Bvc2FscyBhYm91dCBPU1BGIGlzJm5ic3A7dGhlIHNhbWUgdG8gUkZDIA0KMjMyOC48 L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj5Ib3cmbmJzcDthYm91dCBkbyB5b3UgdGhpbms/PC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ YmVzdCByZWdhcmRzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPktvdTwvRk9OVD48 L0RJVj48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_+RQudD2t35BDqXpw+jTdXQ)-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 26 10:08:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlx2-00023J-Gu for ospf-archive@megatron.ietf.org; Wed, 26 Oct 2005 10:08:24 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22050 for ; Wed, 26 Oct 2005 10:08:09 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0111FA91@cherry.ease.lsoft.com>; Wed, 26 Oct 2005 10:08:22 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89041731 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 10:08:18 -0400 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 26 Oct 2005 10:08:18 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 26 Oct 2005 07:08:17 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9QE8AJl029563 for ; Wed, 26 Oct 2005 07:08:15 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 07:07:36 -0700 Received: from [10.21.145.190] ([10.21.145.190]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 07:07:35 -0700 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <00bf01c5da07$ca565950$72646e0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 X-OriginalArrivalTime: 26 Oct 2005 14:07:35.0941 (UTC) FILETIME=[9DBCC350:01C5DA36] Message-ID: <435F8DA7.4030405@cisco.com> Date: Wed, 26 Oct 2005 10:07:35 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: accelerating convergence when ospf starting To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <00bf01c5da07$ca565950$72646e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA22050 Hi Kou, kouzengjie wrote: >All, > OSPF convergence contains neighbor discovery and link state database= synchronization. >Neighbor discovery is achieved by hello protocol. Default hello interval= is 10s. >Hello packets sent by neighbors is not work on each other.So,covergence = time is longer. >If adopting following proposition,then covergence time is decreased ver= y much on broadcast networks. > > 1.Neighbors immediately send hello packet to peer when they receive = hello packet from the peer that first sent the hello packet. > =20 > This can be done. The previous implementation I worked on unicast a hello back to a new neighbor.. > 2.Based 1,routers( marked X) that sent the hello packet will repidly= receive their neighbors hello packet carrying their peers(X) information. > 3.After 2,DR will start to be elected=A3=ACbuilding the relation of = adjacency and completing link state database synchronization. > =20 > This will not work in all situations - what if both neighbors are just coming up and neither has received a hello from the current DR/ BDR? You need to wait for the BackupSeen or WaitTimer event. A better optimization (at the expense of a greater risk that DR churn will result) would be to allow the wait-timer interval to be configurable to a value (hello-interval <=3D wait-interval <=3D dead-interval). Thanks, Acee > 4.After database synchronization,the hello packet will be sent every= provious interval each other. > >Other disposals about OSPF is the same to RFC 2328. > >How about do you think? > >best regards, >Kou > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 26 14:32:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUq4G-0002Hk-7y for ospf-archive@megatron.ietf.org; Wed, 26 Oct 2005 14:32:08 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12984 for ; Wed, 26 Oct 2005 14:31:53 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0111FF2E@cherry.ease.lsoft.com>; Wed, 26 Oct 2005 14:32:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89068634 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 14:32:03 -0400 Received: from 207.69.195.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 26 Oct 2005 14:32:03 -0400 Received: from h-68-164-86-60.snvacaid.dynamic.covad.net ([68.164.86.60] helo=earthlink.net) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EUq4A-00010K-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 14:32:02 -0400 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: <00bf01c5da07$ca565950$72646e0a@china.huawei.com> <435F8DA7.4030405@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Message-ID: <435FCE7B.610E4063@earthlink.net> Date: Wed, 26 Oct 2005 11:44:11 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: accelerating convergence when ospf starting To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA12984 Group, A faster convergence time may be had, if at least secondary routes are calculated, so when a adj is percieved to go down, a secondary can quickly be used.=20 This is only assuming that the SPF or equiv type calc generates a decent latency AND that their are a group of these types of routers wihin a localized area, so all make the same quicker convergence. Of course, if the passthru data is sporadic in nature and their is a lull in the data while the quicker convergence is done, no benefits would be seen. Mitchell Erblich ------------------ =09 =09 Acee Lindem wrote: >=20 > Hi Kou, >=20 > kouzengjie wrote: >=20 > >All, > > OSPF convergence contains neighbor discovery and link state databa= se synchronization. > >Neighbor discovery is achieved by hello protocol. Default hello interv= al is 10s. > >Hello packets sent by neighbors is not work on each other.So,covergenc= e time is longer. > >If adopting following proposition,then covergence time is decreased v= ery much on broadcast networks. > > > > 1.Neighbors immediately send hello packet to peer when they receiv= e hello packet from the peer that first sent the hello packet. > > > > > This can be done. The previous implementation I worked on unicast a > hello back to > a new neighbor.. >=20 > > 2.Based 1,routers( marked X) that sent the hello packet will repid= ly receive their neighbors hello packet carrying their peers(X) informati= on. > > 3.After 2,DR will start to be elected=A3=ACbuilding the relation o= f adjacency and completing link state database synchronization. > > > > > This will not work in all situations - what if both neighbors are just > coming up and neither has > received a hello from the current DR/ BDR? You need to wait for the > BackupSeen or > WaitTimer event. A better optimization (at the expense of a greater ris= k > that DR churn > will result) would be to allow the wait-timer interval to be > configurable to a value > (hello-interval <=3D wait-interval <=3D dead-interval). >=20 > Thanks, > Acee >=20 > > 4.After database synchronization,the hello packet will be sent eve= ry provious interval each other. > > > >Other disposals about OSPF is the same to RFC 2328. > > > >How about do you think? > > > >best regards, > >Kou > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 26 15:33:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUr1L-000170-3T for ospf-archive@megatron.ietf.org; Wed, 26 Oct 2005 15:33:11 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16922 for ; Wed, 26 Oct 2005 15:32:55 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0111FECA@cherry.ease.lsoft.com>; Wed, 26 Oct 2005 15:33:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89072256 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 15:32:59 -0400 Received: from 64.171.8.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 26 Oct 2005 15:22:59 -0400 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 X-MIMETrack: Serialize by Router on note_back/AcctonUS(Release 5.0.2c |February 2, 2000) at 10/26/2005 12:20:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: quoted-printable Message-ID: Date: Wed, 26 Oct 2005 12:26:17 -0700 Reply-To: Mailing List Sender: Mailing List From: Greg Mirsky Subject: Re: accelerating convergence when ospf starting To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <435FCE7B.610E4063@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable "A faster convergence time may be had, if at least secondary routes are= calculated, so when a adj is percieved to go down, a secondary can quic= kly be used." The benefit of calculating secondary routes is imaginary because some o= f them will be affected by the loss of adjacency that caused the converge= nce in the first place. To make it work you'll need to prepare secondary ro= utes for all possible convergence scenarios. I think that it is obviously do= es not scale. Regards, Greg = =20 Erblichs = =20 cc: = =20 Sent by: Mailing Subject: Re: accelerati= ng convergence when ospf starting =20 List = =20 = =20 = =20 = =20 10/26/2005 11:44 = =20 AM = =20 Please respond to = =20 Mailing List = =20 = =20 Group, A faster convergence time may be had, if at least secondary routes are calculated, so when a adj is percieved to go down, a secondary can quickly be used. This is only assuming that the SPF or equiv type calc generates a decent latency AND that their are a group of these types of routers wihin a localized area, so all make the same quicker convergence. Of course, if the passthru data is sporadic in nature and their is a lull in the data while the quicker convergence is done, no benefits would be seen. Mitchell Erblich ------------------ Acee Lindem wrote: > > Hi Kou, > > kouzengjie wrote: > > >All, > > OSPF convergence contains neighbor discovery and link state data= base synchronization. > >Neighbor discovery is achieved by hello protocol. Default hello inte= rval is 10s. > >Hello packets sent by neighbors is not work on each other.So,coverge= nce time is longer. > >If adopting following proposition,then covergence time is decreased= very much on broadcast networks. > > > > 1.Neighbors immediately send hello packet to peer when they rece= ive hello packet from the peer that first sent the hello packet. > > > > > This can be done. The previous implementation I worked on unicast a > hello back to > a new neighbor.. > > > 2.Based 1,routers( marked X) that sent the hello packet will rep= idly receive their neighbors hello packet carrying their peers(X) informatio= n. > > 3.After 2,DR will start to be elected=A3=ACbuilding the relation= of adjacency and completing link state database synchronization. > > > > > This will not work in all situations - what if both neighbors are jus= t > coming up and neither has > received a hello from the current DR/ BDR? You need to wait for the > BackupSeen or > WaitTimer event. A better optimization (at the expense of a greater r= isk > that DR churn > will result) would be to allow the wait-timer interval to be > configurable to a value > (hello-interval <=3D wait-interval <=3D dead-interval). > > Thanks, > Acee > > > 4.After database synchronization,the hello packet will be sent e= very provious interval each other. > > > >Other disposals about OSPF is the same to RFC 2328. > > > >How about do you think? > > > >best regards, > >Kou > > = From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 26 15:44:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrC7-0002im-4x for ospf-archive@megatron.ietf.org; Wed, 26 Oct 2005 15:44:19 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17523 for ; Wed, 26 Oct 2005 15:44:03 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0111FE83@cherry.ease.lsoft.com>; Wed, 26 Oct 2005 15:44:17 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89074163 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 15:44:15 -0400 Received: from 207.69.195.68 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 26 Oct 2005 15:44:15 -0400 Received: from h-68-164-86-60.snvacaid.dynamic.covad.net ([68.164.86.60] helo=earthlink.net) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EUrC2-000488-00; Wed, 26 Oct 2005 15:44:14 -0400 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=iso-8859-2 Message-ID: <435FDF05.53CA687E@earthlink.net> Date: Wed, 26 Oct 2005 12:54:45 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: accelerating convergence when ospf starting Comments: To: Greg Mirsky To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA17523 Greg, You are assuming that all adj are equal. Some adj are more equal than others in respect to Mb/sec, QOS, etc. On these prioritized adjs, we can improve convergence. =09 Scaling is not a requirement. Only that the faster convergence is better than doing the defacto standard and minimize the loss or mis-direction of data for these "unequal adjs". If you don't do it now, then why not? Mitchell Erblich ----------------- =09 =09 Greg Mirsky wrote: >=20 > "A faster convergence time may be had, if at least secondary routes are > calculated, so when a adj is percieved to go down, a secondary can quic= kly > be used." > The benefit of calculating secondary routes is imaginary because some o= f > them will be affected by the loss of adjacency that caused the converge= nce > in the first place. To make it work you'll need to prepare secondary ro= utes > for all possible convergence scenarios. I think that it is obviously do= es > not scale. >=20 > Regards, > Greg >=20 >=20 > Erblichs > NK.NET> cc: > Sent by: Mailing Subject: Re: accelerati= ng convergence when ospf starting > List > LSOFT.COM> >=20 >=20 > 10/26/2005 11:44 > AM > Please respond to > Mailing List >=20 >=20 > Group, >=20 > A faster convergence time may be had, if at least secondary > routes are calculated, so when a adj is percieved to go > down, a secondary can quickly be used. >=20 > This is only assuming > that the SPF or equiv type calc generates a decent latency > AND that their are a group of these types of routers wihin > a localized area, so all make the same quicker convergence. >=20 > Of course, if the passthru data is sporadic in nature and > their is a lull in the data while the quicker convergence > is done, no benefits would be seen. >=20 > Mitchell Erblich > ------------------ >=20 > Acee Lindem wrote: > > > > Hi Kou, > > > > kouzengjie wrote: > > > > >All, > > > OSPF convergence contains neighbor discovery and link state data= base > synchronization. > > >Neighbor discovery is achieved by hello protocol. Default hello inte= rval > is 10s. > > >Hello packets sent by neighbors is not work on each other.So,coverge= nce > time is longer. > > >If adopting following proposition,then covergence time is decreased > very much on broadcast networks. > > > > > > 1.Neighbors immediately send hello packet to peer when they rece= ive > hello packet from the peer that first sent the hello packet. > > > > > > > > This can be done. The previous implementation I worked on unicast a > > hello back to > > a new neighbor.. > > > > > 2.Based 1,routers( marked X) that sent the hello packet will rep= idly > receive their neighbors hello packet carrying their peers(X) informatio= n. > > > 3.After 2,DR will start to be elected=A3=ACbuilding the relation= of > adjacency and completing link state database synchronization. > > > > > > > > This will not work in all situations - what if both neighbors are jus= t > > coming up and neither has > > received a hello from the current DR/ BDR? You need to wait for the > > BackupSeen or > > WaitTimer event. A better optimization (at the expense of a greater r= isk > > that DR churn > > will result) would be to allow the wait-timer interval to be > > configurable to a value > > (hello-interval <=3D wait-interval <=3D dead-interval). > > > > Thanks, > > Acee > > > > > 4.After database synchronization,the hello packet will be sent e= very > provious interval each other. > > > > > >Other disposals about OSPF is the same to RFC 2328. > > > > > >How about do you think? > > > > > >best regards, > > >Kou > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 26 16:17:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUrhz-0003oF-2q for ospf-archive@megatron.ietf.org; Wed, 26 Oct 2005 16:17:15 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28164 for ; Wed, 26 Oct 2005 16:16:58 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0111FF44@cherry.ease.lsoft.com>; Wed, 26 Oct 2005 16:16:55 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89076262 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 16:16:53 -0400 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 26 Oct 2005 16:16:53 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 26 Oct 2005 13:16:52 -0700 X-IronPort-AV: i="3.97,254,1125903600"; d="scan'208"; a="357162627:sNHT28009652" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9QKGjJl019360 for ; Wed, 26 Oct 2005 13:16:50 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 13:16:48 -0700 Received: from [128.107.177.165] ([128.107.177.165]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 13:16:48 -0700 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <435FDF05.53CA687E@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed X-OriginalArrivalTime: 26 Oct 2005 20:16:48.0447 (UTC) FILETIME=[31A8ECF0:01C5DA6A] Message-ID: <435FE430.9080503@cisco.com> Date: Wed, 26 Oct 2005 16:16:48 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: accelerating convergence when ospf starting To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <435FDF05.53CA687E@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA28164 Erblichs wrote: >Greg, > > You are assuming that all adj are equal. Some adj are > more equal than others in respect to Mb/sec, QOS, etc. > > On these prioritized adjs, we can improve convergence. >=09 > Scaling is not a requirement. Only that the faster > convergence is better than doing the defacto standard > and minimize the loss or mis-direction of data for these > "unequal adjs". > > If you don't do it now, then why not? > > Mitchell Erblich > ----------------- >=09 >=09 > >Greg Mirsky wrote: > =20 > >>"A faster convergence time may be had, if at least secondary routes are >>calculated, so when a adj is percieved to go down, a secondary can quic= kly >>be used." >>The benefit of calculating secondary routes is imaginary because some o= f >>them will be affected by the loss of adjacency that caused the converge= nce >>in the first place. To make it work you'll need to prepare secondary ro= utes >>for all possible convergence scenarios. I think that it is obviously do= es >>not scale. >> >> Regards, >> Greg >> >> >> Erblichs >> > NK.NET> cc: >> Sent by: Mailing Subject: Re: accelerati= ng convergence when ospf starting >> List >> > LSOFT.COM> >> >> >> 10/26/2005 11:44 >> AM >> Please respond to >> Mailing List >> >> >>Group, >> >> A faster convergence time may be had, if at least secondary >> routes are calculated, so when a adj is percieved to go >> down, a secondary can quickly be used. >> >> This is only assuming >> that the SPF or equiv type calc generates a decent latency >> AND that their are a group of these types of routers wihin >> a localized area, so all make the same quicker convergence. >> >> Of course, if the passthru data is sporadic in nature and >> their is a lull in the data while the quicker convergence >> is done, no benefits would be seen. >> =20 >> Actually this is the under the purview of the Routing Area WG (rtwg): http://www.ietf.org/html.charters/rtgwg-charter.html You may want to read their drafts and participate in the attendant=20 discussion. Acee >> Mitchell Erblich >> ------------------ >> >>Acee Lindem wrote: >> =20 >> >>>Hi Kou, >>> >>>kouzengjie wrote: >>> >>> =20 >>> >>>>All, >>>> OSPF convergence contains neighbor discovery and link state databa= se >>>> =20 >>>> >>synchronization. >> =20 >> >>>>Neighbor discovery is achieved by hello protocol. Default hello inter= val >>>> =20 >>>> >>is 10s. >> =20 >> >>>>Hello packets sent by neighbors is not work on each other.So,covergen= ce >>>> =20 >>>> >>time is longer. >> =20 >> >>>>If adopting following proposition,then covergence time is decreased >>>> =20 >>>> >>very much on broadcast networks. >> =20 >> >>>> 1.Neighbors immediately send hello packet to peer when they receiv= e >>>> =20 >>>> >>hello packet from the peer that first sent the hello packet. >> =20 >> >>>> =20 >>>> >>>This can be done. The previous implementation I worked on unicast a >>>hello back to >>>a new neighbor.. >>> >>> =20 >>> >>>> 2.Based 1,routers( marked X) that sent the hello packet will repid= ly >>>> =20 >>>> >>receive their neighbors hello packet carrying their peers(X) informatio= n. >> =20 >> >>>> 3.After 2,DR will start to be elected=A3=ACbuilding the relation o= f >>>> =20 >>>> >>adjacency and completing link state database synchronization. >> =20 >> >>>> =20 >>>> >>>This will not work in all situations - what if both neighbors are just >>>coming up and neither has >>>received a hello from the current DR/ BDR? You need to wait for the >>>BackupSeen or >>>WaitTimer event. A better optimization (at the expense of a greater ri= sk >>>that DR churn >>>will result) would be to allow the wait-timer interval to be >>>configurable to a value >>>(hello-interval <=3D wait-interval <=3D dead-interval). >>> >>>Thanks, >>>Acee >>> >>> =20 >>> >>>> 4.After database synchronization,the hello packet will be sent eve= ry >>>> =20 >>>> >>provious interval each other. >> =20 >> >>>>Other disposals about OSPF is the same to RFC 2328. >>>> >>>>How about do you think? >>>> >>>>best regards, >>>>Kou >>>> >>>> =20 >>>> > > =20 > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 26 21:44:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUwp5-0000Tr-7O for ospf-archive@megatron.ietf.org; Wed, 26 Oct 2005 21:44:55 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14640 for ; Wed, 26 Oct 2005 21:44:39 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.011204BB@cherry.ease.lsoft.com>; Wed, 26 Oct 2005 21:44:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89099926 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 26 Oct 2005 21:44:46 -0400 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 26 Oct 2005 21:44:46 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOZ005YKX9OBT@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 27 Oct 2005 09:53:48 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IOZ005LBX9OS2@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 27 Oct 2005 09:53:48 +0800 (CST) Received: from k49110 ([10.110.100.114]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IOZ00JUVX9HXR@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 27 Oct 2005 09:53:41 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <00bf01c5da07$ca565950$72646e0a@china.huawei.com> <435F8DA7.4030405@cisco.com> Message-ID: <007101c5da98$2b92c3d0$72646e0a@china.huawei.com> Date: Thu, 27 Oct 2005 09:45:54 +0800 Reply-To: Mailing List Sender: Mailing List From: Kouzengjie Subject: Re: accelerating convergence when ospf starting To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: base64 SGkgQWNlZSwNCiAgICBOb3csd2UgYXJlIHN1cmUgb2YgIHRoZSBmYWN0IHRoYXQgZWl0aGVyIG5l aWdoYm9yIHN0YXRlIGJlY29taW5nICIyLXdheSIgc3RhdGUgaXMgZmFzdGVyIHRoYW4gcHJpb3Ig YnkgdGhlIG1lY2hhbmlzbS4NCg0KVGhhbmtzLA0KS291DQogICAgDQoNCi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiQWNlZSBMaW5kZW0iIDxhY2VlQENJU0NPLkNPTT4NClRv OiA8T1NQRkBQRUFDSC5FQVNFLkxTT0ZULkNPTT4NClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAy NiwgMjAwNSAxMDowNyBQTQ0KU3ViamVjdDogUmU6IGFjY2VsZXJhdGluZyBjb252ZXJnZW5jZSB3 aGVuIG9zcGYgc3RhcnRpbmcNCg0KDQo+IEhpIEtvdSwNCj4gDQo+IGtvdXplbmdqaWUgd3JvdGU6 DQo+IA0KPj5BbGwsDQo+PiAgICBPU1BGIGNvbnZlcmdlbmNlIGNvbnRhaW5zIG5laWdoYm9yIGRp c2NvdmVyeSBhbmQgbGluayBzdGF0ZSBkYXRhYmFzZSBzeW5jaHJvbml6YXRpb24uDQo+Pk5laWdo Ym9yIGRpc2NvdmVyeSBpcyBhY2hpZXZlZCBieSBoZWxsbyBwcm90b2NvbC4gRGVmYXVsdCBoZWxs byBpbnRlcnZhbCBpcyAxMHMuDQo+PkhlbGxvIHBhY2tldHMgc2VudCBieSBuZWlnaGJvcnMgaXMg bm90IHdvcmsgb24gZWFjaCBvdGhlci5Tbyxjb3ZlcmdlbmNlIHRpbWUgaXMgbG9uZ2VyLg0KPj5J ZiBhZG9wdGluZyBmb2xsb3dpbmcgcHJvcG9zaXRpb24sdGhlbiBjb3ZlcmdlbmNlIHRpbWUgIGlz IGRlY3JlYXNlZCB2ZXJ5IG11Y2ggb24gYnJvYWRjYXN0IG5ldHdvcmtzLg0KPj4NCj4+ICAgIDEu TmVpZ2hib3JzIGltbWVkaWF0ZWx5IHNlbmQgaGVsbG8gcGFja2V0IHRvIHBlZXIgd2hlbiB0aGV5 IHJlY2VpdmUgaGVsbG8gcGFja2V0IGZyb20gdGhlIHBlZXIgdGhhdCBmaXJzdCBzZW50IHRoZSBo ZWxsbyBwYWNrZXQuDQo+PiAgDQo+Pg0KPiBUaGlzIGNhbiBiZSBkb25lLiBUaGUgcHJldmlvdXMg aW1wbGVtZW50YXRpb24gSSB3b3JrZWQgb24gdW5pY2FzdCBhDQo+IGhlbGxvIGJhY2sgdG8NCj4g YSBuZXcgbmVpZ2hib3IuLg0KPiANCj4gDQo+IA0KPj4gICAgMi5CYXNlZCAxLHJvdXRlcnMoIG1h cmtlZCBYKSB0aGF0IHNlbnQgdGhlIGhlbGxvIHBhY2tldCB3aWxsIHJlcGlkbHkgcmVjZWl2ZSB0 aGVpciBuZWlnaGJvcnMgaGVsbG8gcGFja2V0IGNhcnJ5aW5nIHRoZWlyIHBlZXJzKFgpIGluZm9y bWF0aW9uLg0KPj4gICAgMy5BZnRlciAyLERSIHdpbGwgc3RhcnQgdG8gYmUgZWxlY3RlZKOsYnVp bGRpbmcgdGhlIHJlbGF0aW9uIG9mIGFkamFjZW5jeSBhbmQgY29tcGxldGluZyBsaW5rIHN0YXRl IGRhdGFiYXNlIHN5bmNocm9uaXphdGlvbi4NCj4+ICANCj4+DQo+IFRoaXMgd2lsbCBub3Qgd29y ayBpbiBhbGwgc2l0dWF0aW9ucyAtIHdoYXQgaWYgYm90aCBuZWlnaGJvcnMgYXJlIGp1c3QNCj4g Y29taW5nIHVwIGFuZCBuZWl0aGVyIGhhcw0KPiByZWNlaXZlZCBhIGhlbGxvIGZyb20gdGhlIGN1 cnJlbnQgRFIvIEJEUj8gWW91IG5lZWQgdG8gd2FpdCBmb3IgdGhlDQo+IEJhY2t1cFNlZW4gb3IN Cj4gV2FpdFRpbWVyIGV2ZW50LiBBIGJldHRlciBvcHRpbWl6YXRpb24gKGF0IHRoZSBleHBlbnNl IG9mIGEgZ3JlYXRlciByaXNrDQo+IHRoYXQgRFIgY2h1cm4NCj4gd2lsbCByZXN1bHQpIHdvdWxk IGJlIHRvIGFsbG93IHRoZSB3YWl0LXRpbWVyIGludGVydmFsIHRvIGJlDQo+IGNvbmZpZ3VyYWJs ZSB0byBhIHZhbHVlDQo+IChoZWxsby1pbnRlcnZhbCA8PSB3YWl0LWludGVydmFsIDw9IGRlYWQt aW50ZXJ2YWwpLg0KPiANCj4gVGhhbmtzLA0KPiBBY2VlDQo+IA0KPiANCj4+ICAgIDQuQWZ0ZXIg ZGF0YWJhc2Ugc3luY2hyb25pemF0aW9uLHRoZSBoZWxsbyBwYWNrZXQgd2lsbCBiZSBzZW50IGV2 ZXJ5IHByb3Zpb3VzIGludGVydmFsIGVhY2ggb3RoZXIuDQo+Pg0KPj5PdGhlciBkaXNwb3NhbHMg YWJvdXQgT1NQRiBpcyB0aGUgc2FtZSB0byBSRkMgMjMyOC4NCj4+DQo+PkhvdyBhYm91dCBkbyB5 b3UgdGhpbms/DQo+Pg0KPj5iZXN0IHJlZ2FyZHMsDQo+PktvdQ0KPj4= From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 27 02:08:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV0w6-0005wU-Nn for ospf-archive@megatron.ietf.org; Thu, 27 Oct 2005 02:08:26 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26412 for ; Thu, 27 Oct 2005 02:08:09 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.01120ABD@cherry.ease.lsoft.com>; Thu, 27 Oct 2005 2:08:19 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89115604 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 27 Oct 2005 02:08:15 -0400 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 27 Oct 2005 02:08:15 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 26 Oct 2005 23:08:14 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9R67VvB027643 for ; Wed, 26 Oct 2005 23:08:12 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 23:08:12 -0700 Received: from [10.21.145.147] ([10.21.145.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 23:08:11 -0700 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <00bf01c5da07$ca565950$72646e0a@china.huawei.com> <435F8DA7.4030405@cisco.com> <007101c5da98$2b92c3d0$72646e0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 X-OriginalArrivalTime: 27 Oct 2005 06:08:11.0875 (UTC) FILETIME=[CF6E5B30:01C5DABC] Message-ID: <43606ECA.5040206@cisco.com> Date: Thu, 27 Oct 2005 02:08:10 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: accelerating convergence when ospf starting To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <007101c5da98$2b92c3d0$72646e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA26412 Kouzengjie wrote: >Hi Acee, > Now,we are sure of the fact that either neighbor state becoming "2-= way" state is faster than prior by the mechanism. > =20 > Hi Kou, In some situations, unicasting a hello in response to a newly discovered neighbor will get you to 2-way faster. As I stated earlier, existing implementations use this technique. What is your point? Thanks, Acee >Thanks, >Kou > =20 > >----- Original Message -----=20 >From: "Acee Lindem" >To: >Sent: Wednesday, October 26, 2005 10:07 PM >Subject: Re: accelerating convergence when ospf starting > > > =20 > >>Hi Kou, >> >>kouzengjie wrote: >> >> =20 >> >>>All, >>> OSPF convergence contains neighbor discovery and link state databas= e synchronization. >>>Neighbor discovery is achieved by hello protocol. Default hello interv= al is 10s. >>>Hello packets sent by neighbors is not work on each other.So,covergenc= e time is longer. >>>If adopting following proposition,then covergence time is decreased v= ery much on broadcast networks. >>> >>> 1.Neighbors immediately send hello packet to peer when they receive= hello packet from the peer that first sent the hello packet. >>>=20 >>> >>> =20 >>> >>This can be done. The previous implementation I worked on unicast a >>hello back to >>a new neighbor.. >> >> >> >> =20 >> >>> 2.Based 1,routers( marked X) that sent the hello packet will repidl= y receive their neighbors hello packet carrying their peers(X) informatio= n. >>> 3.After 2,DR will start to be elected=A3=ACbuilding the relation of= adjacency and completing link state database synchronization. >>>=20 >>> >>> =20 >>> >>This will not work in all situations - what if both neighbors are just >>coming up and neither has >>received a hello from the current DR/ BDR? You need to wait for the >>BackupSeen or >>WaitTimer event. A better optimization (at the expense of a greater ris= k >>that DR churn >>will result) would be to allow the wait-timer interval to be >>configurable to a value >>(hello-interval <=3D wait-interval <=3D dead-interval). >> >>Thanks, >>Acee >> >> >> =20 >> >>> 4.After database synchronization,the hello packet will be sent ever= y provious interval each other. >>> >>>Other disposals about OSPF is the same to RFC 2328. >>> >>>How about do you think? >>> >>>best regards, >>>Kou >>> =20 >>> >>> >> From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 27 03:12:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV1wV-0003tx-DM for ospf-archive@megatron.ietf.org; Thu, 27 Oct 2005 03:12:55 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06679 for ; Thu, 27 Oct 2005 03:12:37 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.01120B1A@cherry.ease.lsoft.com>; Thu, 27 Oct 2005 3:12:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89117796 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 27 Oct 2005 03:12:42 -0400 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 27 Oct 2005 03:12:37 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IP000FRBCD6IL@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 27 Oct 2005 15:19:55 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IP0009FKCD6BV@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 27 Oct 2005 15:19:54 +0800 (CST) Received: from k49110 ([10.110.100.114]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IP000BSVCLHTO@szxml01-in.huawei.com>; Thu, 27 Oct 2005 15:24:53 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <00bf01c5da07$ca565950$72646e0a@china.huawei.com> <435F8DA7.4030405@cisco.com> <007101c5da98$2b92c3d0$72646e0a@china.huawei.com> <43606ECA.5040206@cisco.com> Message-ID: <001701c5dac5$f868aff0$72646e0a@china.huawei.com> Date: Thu, 27 Oct 2005 15:13:45 +0800 Reply-To: Mailing List Sender: Mailing List From: Kouzengjie Subject: Re: accelerating convergence when ospf starting Comments: To: acee@CISCO.COM To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: base64 SGksQWNlZQ0KICAgIFllcyxJIHNlZS4NCiAgICANCiAgICBJIGhhdmUgYW4gaWRlYSB0aGF0IEkg d2FudCB0byB3cml0ZSBhIGRyYWZ0IGFib3V0IHRoaXMgdGVjaG5pcXVlIGFuZCBwcm9tb3RlIGl0 IGJvY29tZXMgYSBzdGFuZGFyZCBleHRlbnNpb24gb2YgT1NQRi4NCiAgICBIb3cgZG8geW91IHRo aW5rIGl0Pw0KDQpUaGFua3MsDQpLb3UgIA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IA0KRnJvbTogIkFjZWUgTGluZGVtIiA8YWNlZUBDSVNDTy5DT00+DQpUbzogPE9TUEZAUEVBQ0gu RUFTRS5MU09GVC5DT00+DQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNywgMjAwNSAyOjA4IFBN DQpTdWJqZWN0OiBSZTogYWNjZWxlcmF0aW5nIGNvbnZlcmdlbmNlIHdoZW4gb3NwZiBzdGFydGlu Zw0KDQoNCj4gS291emVuZ2ppZSB3cm90ZToNCj4gDQo+PkhpIEFjZWUsDQo+PiAgICBOb3csd2Ug YXJlIHN1cmUgb2YgIHRoZSBmYWN0IHRoYXQgZWl0aGVyIG5laWdoYm9yIHN0YXRlIGJlY29taW5n ICIyLXdheSIgc3RhdGUgaXMgZmFzdGVyIHRoYW4gcHJpb3IgYnkgdGhlIG1lY2hhbmlzbS4NCj4+ ICANCj4+DQo+IEhpIEtvdSwNCj4gDQo+IEluIHNvbWUgc2l0dWF0aW9ucywgdW5pY2FzdGluZyBh IGhlbGxvIGluIHJlc3BvbnNlIHRvIGEgbmV3bHkgZGlzY292ZXJlZA0KPiBuZWlnaGJvciB3aWxs IGdldA0KPiB5b3UgdG8gMi13YXkgZmFzdGVyLiBBcyBJIHN0YXRlZCBlYXJsaWVyLCBleGlzdGlu ZyBpbXBsZW1lbnRhdGlvbnMgdXNlDQo+IHRoaXMgdGVjaG5pcXVlLiBXaGF0DQo+IGlzIHlvdXIg cG9pbnQ/DQo+IA0KPiBUaGFua3MsDQo+IEFjZWUNCj4gDQo+PlRoYW5rcywNCj4+S291DQo+PiAg ICANCj4+DQo+Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+PkZyb206ICJBY2VlIExp bmRlbSIgPGFjZWVAQ0lTQ08uQ09NPg0KPj5UbzogPE9TUEZAUEVBQ0guRUFTRS5MU09GVC5DT00+ DQo+PlNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAyNiwgMjAwNSAxMDowNyBQTQ0KPj5TdWJqZWN0 OiBSZTogYWNjZWxlcmF0aW5nIGNvbnZlcmdlbmNlIHdoZW4gb3NwZiBzdGFydGluZw0KPj4NCj4+ DQo+PiAgDQo+Pg0KPj4+SGkgS291LA0KPj4+DQo+Pj5rb3V6ZW5namllIHdyb3RlOg0KPj4+DQo+ Pj4gICAgDQo+Pj4NCj4+Pj5BbGwsDQo+Pj4+ICAgT1NQRiBjb252ZXJnZW5jZSBjb250YWlucyBu ZWlnaGJvciBkaXNjb3ZlcnkgYW5kIGxpbmsgc3RhdGUgZGF0YWJhc2Ugc3luY2hyb25pemF0aW9u Lg0KPj4+Pk5laWdoYm9yIGRpc2NvdmVyeSBpcyBhY2hpZXZlZCBieSBoZWxsbyBwcm90b2NvbC4g RGVmYXVsdCBoZWxsbyBpbnRlcnZhbCBpcyAxMHMuDQo+Pj4+SGVsbG8gcGFja2V0cyBzZW50IGJ5 IG5laWdoYm9ycyBpcyBub3Qgd29yayBvbiBlYWNoIG90aGVyLlNvLGNvdmVyZ2VuY2UgdGltZSBp cyBsb25nZXIuDQo+Pj4+SWYgYWRvcHRpbmcgZm9sbG93aW5nIHByb3Bvc2l0aW9uLHRoZW4gY292 ZXJnZW5jZSB0aW1lICBpcyBkZWNyZWFzZWQgdmVyeSBtdWNoIG9uIGJyb2FkY2FzdCBuZXR3b3Jr cy4NCj4+Pj4NCj4+Pj4gICAxLk5laWdoYm9ycyBpbW1lZGlhdGVseSBzZW5kIGhlbGxvIHBhY2tl dCB0byBwZWVyIHdoZW4gdGhleSByZWNlaXZlIGhlbGxvIHBhY2tldCBmcm9tIHRoZSBwZWVyIHRo YXQgZmlyc3Qgc2VudCB0aGUgaGVsbG8gcGFja2V0Lg0KPj4+PiANCj4+Pj4NCj4+Pj4gICAgICAN Cj4+Pj4NCj4+PlRoaXMgY2FuIGJlIGRvbmUuIFRoZSBwcmV2aW91cyBpbXBsZW1lbnRhdGlvbiBJ IHdvcmtlZCBvbiB1bmljYXN0IGENCj4+PmhlbGxvIGJhY2sgdG8NCj4+PmEgbmV3IG5laWdoYm9y Li4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAgICANCj4+Pg0KPj4+PiAgIDIuQmFzZWQgMSxyb3V0ZXJz KCBtYXJrZWQgWCkgdGhhdCBzZW50IHRoZSBoZWxsbyBwYWNrZXQgd2lsbCByZXBpZGx5IHJlY2Vp dmUgdGhlaXIgbmVpZ2hib3JzIGhlbGxvIHBhY2tldCBjYXJyeWluZyB0aGVpciBwZWVycyhYKSBp bmZvcm1hdGlvbi4NCj4+Pj4gICAzLkFmdGVyIDIsRFIgd2lsbCBzdGFydCB0byBiZSBlbGVjdGVk o6xidWlsZGluZyB0aGUgcmVsYXRpb24gb2YgYWRqYWNlbmN5IGFuZCBjb21wbGV0aW5nIGxpbmsg c3RhdGUgZGF0YWJhc2Ugc3luY2hyb25pemF0aW9uLg0KPj4+PiANCj4+Pj4NCj4+Pj4gICAgICAN Cj4+Pj4NCj4+PlRoaXMgd2lsbCBub3Qgd29yayBpbiBhbGwgc2l0dWF0aW9ucyAtIHdoYXQgaWYg Ym90aCBuZWlnaGJvcnMgYXJlIGp1c3QNCj4+PmNvbWluZyB1cCBhbmQgbmVpdGhlciBoYXMNCj4+ PnJlY2VpdmVkIGEgaGVsbG8gZnJvbSB0aGUgY3VycmVudCBEUi8gQkRSPyBZb3UgbmVlZCB0byB3 YWl0IGZvciB0aGUNCj4+PkJhY2t1cFNlZW4gb3INCj4+PldhaXRUaW1lciBldmVudC4gQSBiZXR0 ZXIgb3B0aW1pemF0aW9uIChhdCB0aGUgZXhwZW5zZSBvZiBhIGdyZWF0ZXIgcmlzaw0KPj4+dGhh dCBEUiBjaHVybg0KPj4+d2lsbCByZXN1bHQpIHdvdWxkIGJlIHRvIGFsbG93IHRoZSB3YWl0LXRp bWVyIGludGVydmFsIHRvIGJlDQo+Pj5jb25maWd1cmFibGUgdG8gYSB2YWx1ZQ0KPj4+KGhlbGxv LWludGVydmFsIDw9IHdhaXQtaW50ZXJ2YWwgPD0gZGVhZC1pbnRlcnZhbCkuDQo+Pj4NCj4+PlRo YW5rcywNCj4+PkFjZWUNCj4+Pg0KPj4+DQo+Pj4gICAgDQo+Pj4NCj4+Pj4gICA0LkFmdGVyIGRh dGFiYXNlIHN5bmNocm9uaXphdGlvbix0aGUgaGVsbG8gcGFja2V0IHdpbGwgYmUgc2VudCBldmVy eSBwcm92aW91cyBpbnRlcnZhbCBlYWNoIG90aGVyLg0KPj4+Pg0KPj4+Pk90aGVyIGRpc3Bvc2Fs cyBhYm91dCBPU1BGIGlzIHRoZSBzYW1lIHRvIFJGQyAyMzI4Lg0KPj4+Pg0KPj4+PkhvdyBhYm91 dCBkbyB5b3UgdGhpbms/DQo+Pj4+DQo+Pj4+YmVzdCByZWdhcmRzLA0KPj4+PktvdQ0KPj4+PiAg ICAgIA0KPj4+Pg0KPj4+Pg0KPj4+ From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 27 19:48:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVHUD-0004UJ-IR for ospf-archive@megatron.ietf.org; Thu, 27 Oct 2005 19:48:45 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27858 for ; Thu, 27 Oct 2005 19:48:28 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.011215FF@cherry.ease.lsoft.com>; Thu, 27 Oct 2005 19:48:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89175490 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 27 Oct 2005 19:48:38 -0400 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 27 Oct 2005 19:48:38 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2005 16:48:37 -0700 X-IronPort-AV: i="3.97,259,1125903600"; d="scan'208"; a="669968161:sNHT26376452" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9RNmJup020622 for ; Thu, 27 Oct 2005 16:48:35 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 16:48:34 -0700 Received: from [128.107.176.100] ([128.107.176.100]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 16:48:34 -0700 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <00bf01c5da07$ca565950$72646e0a@china.huawei.com> <435F8DA7.4030405@cisco.com> <007101c5da98$2b92c3d0$72646e0a@china.huawei.com> <43606ECA.5040206@cisco.com> <001701c5dac5$f868aff0$72646e0a@china.huawei.com> Content-Type: text/plain; charset=GB2312 X-OriginalArrivalTime: 27 Oct 2005 23:48:34.0112 (UTC) FILETIME=[F13D4C00:01C5DB50] Message-ID: <43616751.1040102@cisco.com> Date: Thu, 27 Oct 2005 19:48:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: accelerating convergence when ospf starting To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <001701c5dac5$f868aff0$72646e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA27858 Kouzengjie wrote: >Hi,Acee > Yes,I see. > =20 > I have an idea that I want to write a draft about this technique and= promote it bocomes a standard extension of OSPF. > How do you think it? > =20 > Hi Kou, In general, I don't think we should try and optimise standardized mechanisms for specific scenarios without compelling requirements. If you feel there is a strong requirement you are certainly free to make a proposal and attempt to garner support. Thanks, Acee >Thanks, >Kou =20 > >----- Original Message -----=20 >From: "Acee Lindem" >To: >Sent: Thursday, October 27, 2005 2:08 PM >Subject: Re: accelerating convergence when ospf starting > > > =20 > >>Kouzengjie wrote: >> >> =20 >> >>>Hi Acee, >>> Now,we are sure of the fact that either neighbor state becoming "2= -way" state is faster than prior by the mechanism. >>>=20 >>> >>> =20 >>> >>Hi Kou, >> >>In some situations, unicasting a hello in response to a newly discovere= d >>neighbor will get >>you to 2-way faster. As I stated earlier, existing implementations use >>this technique. What >>is your point? >> >>Thanks, >>Acee >> >> =20 >> >>>Thanks, >>>Kou >>> =20 >>> >>>----- Original Message -----=20 >>>From: "Acee Lindem" >>>To: >>>Sent: Wednesday, October 26, 2005 10:07 PM >>>Subject: Re: accelerating convergence when ospf starting >>> >>> >>>=20 >>> >>> =20 >>> >>>>Hi Kou, >>>> >>>>kouzengjie wrote: >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>All, >>>>> OSPF convergence contains neighbor discovery and link state databa= se synchronization. >>>>>Neighbor discovery is achieved by hello protocol. Default hello inte= rval is 10s. >>>>>Hello packets sent by neighbors is not work on each other.So,coverge= nce time is longer. >>>>>If adopting following proposition,then covergence time is decreased= very much on broadcast networks. >>>>> >>>>> 1.Neighbors immediately send hello packet to peer when they receiv= e hello packet from the peer that first sent the hello packet. >>>>> >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>This can be done. The previous implementation I worked on unicast a >>>>hello back to >>>>a new neighbor.. >>>> >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> 2.Based 1,routers( marked X) that sent the hello packet will repid= ly receive their neighbors hello packet carrying their peers(X) informati= on. >>>>> 3.After 2,DR will start to be elected=A3=ACbuilding the relation o= f adjacency and completing link state database synchronization. >>>>> >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>This will not work in all situations - what if both neighbors are jus= t >>>>coming up and neither has >>>>received a hello from the current DR/ BDR? You need to wait for the >>>>BackupSeen or >>>>WaitTimer event. A better optimization (at the expense of a greater r= isk >>>>that DR churn >>>>will result) would be to allow the wait-timer interval to be >>>>configurable to a value >>>>(hello-interval <=3D wait-interval <=3D dead-interval). >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>> 4.After database synchronization,the hello packet will be sent eve= ry provious interval each other. >>>>> >>>>>Other disposals about OSPF is the same to RFC 2328. >>>>> >>>>>How about do you think? >>>>> >>>>>best regards, >>>>>Kou >>>>> =20 >>>>> >>>>> >>>>> =20 >>>>> >>>> >>> From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 28 06:05:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVR6c-0004pL-Uq for ospf-archive@megatron.ietf.org; Fri, 28 Oct 2005 06:05:02 -0400 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05083 for ; Fri, 28 Oct 2005 06:04:45 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.01122003@cherry.ease.lsoft.com>; Fri, 28 Oct 2005 6:04:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 89218422 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 28 Oct 2005 06:04:19 -0400 Received: from 62.241.162.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 28 Oct 2005 06:04:05 -0400 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id E00C0E000346 for ; Fri, 28 Oct 2005 11:04:04 +0100 (BST) Received: from Puppy ([217.158.132.33] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 11:04:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 28 Oct 2005 10:04:04.0356 (UTC) FILETIME=[ED615440:01C5DBA6] Message-ID: <076c01c5dba7$5c032ae0$de849ed9@Puppy> Date: Fri, 28 Oct 2005 11:06:52 +0100 Reply-To: Mailing List Sender: Mailing List From: Adrian Farrel Subject: Fw: RFC 4203 on OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi, I think this announcement should have been shared on the OSPF list. Adrian ----- Original Message ----- From: To: Cc: ; Sent: Friday, October 28, 2005 1:11 AM Subject: RFC 4203 on OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) > > A new Request for Comments is now available in online RFC libraries. > > > RFC 4203 > > Title: OSPF Extensions in Support of > Generalized Multi-Protocol Label Switching (GMPLS) > Author(s): K. Kompella, Ed., Y. Rekhter, Ed. > Status: Standards Track > Date: October 2005 > Mailbox: kireeti@juniper.net, yakov@juniper.net > Pages: 11 > Characters: 23130 > Updates: 3630 > > I-D Tag: draft-ietf-ccamp-ospf-gmpls-extensions-12.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4203.txt > > > This document specifies encoding of extensions to the OSPF routing > protocol in support of Generalized Multi-Protocol Label Switching > (GMPLS). > > This document is a product of the Common Control and Measurement Plane > Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > This document specifies an Internet standards track protocol for > the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the > "Internet Official Protocol Standards" (STD 1) for the > standardization state and status of this protocol. Distribution > of this memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body > help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > Submissions for Requests for Comments should be sent to > RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > Joyce K. Reynolds and Sandy Ginoza > USC/Information Sciences Institute > > ... > > Below is the data which will enable a MIME compliant Mail Reader > implementation to automatically retrieve the ASCII version > of the RFCs. >