From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 03:40:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01339 for ; Tue, 1 Oct 2002 03:40:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.007496E7@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 3:12:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 229143 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 03:12:11 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 03:12:11 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) id <0H3A00F05K91GU@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Tue, 01 Oct 2002 16:17:25 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H3A00FA2K8V3W@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Tue, 01 Oct 2002 16:17:19 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0H3A00MORK9QBL@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Tue, 01 Oct 2002 16:17:51 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200210010028.RAA09446@shah.iprg.nokia.com> Message-ID: <065401c26919$bb3c8640$b4036c6b@sisodomain.com> Date: Tue, 1 Oct 2002 12:41:13 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: when to run in NBMA or P2MP mode? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Dhaval, Let me give it a shot! As i understand, you want to clarify the following - Why the restriction of being able to reach all neighbors directly is placed in order to run in NBMA mode when we always send unicasts to our neighbors? - When would we like to run as p2mp - How can one determine which mode to run in? The reason why we want all the neighbors to be reached directly is because we want to use mechanisms similar to those used in the broadcast subnets. This helps making the NBMA segments more efficient in terms of : - neighbor maintenance - database synchronization - database representation - reducing the O(n^2) relationships to O(n) Emulating NBMA as a normal broadcast network helps the representation of an NBMA subnet within OSPF LSDB as indistinguishable from the representation of a broadcast subnet. However, NBMA segments can fail when the two attached neighbors are not able to communicate directly with each other.If, for example, a PVC fails or is misconfigured or if an SVC cannot be established, due to capacity or policy reasons, routing over NBMA will fail! When to use point-to-multipoint mode? Used if the nonbroadcast subnets cannot support a large number of routers in complete mesh. To connect 200 routers in a full mesh over a Frame Relay/ATM subnet, one would require (200)(200-1)/2 = 19,900 PVCs! Even when SVCs are used, capacity limitations may prohibit pairwise connectivity. One cant thus use the NBMA model as each router cant now communicate directly with the every other router! The only alternative thus left is p2mp. The problem comes when operating a full mesh FR/ATM network in p2mp mode because now the work involved in neighbor maintenance, flooding and database representation increases as O(n^2), where n is the nos. of routers attached to the subnet, instead of O(n) that can be achieved with the NBMA model. For the final question i guess the answer is that if you cant provide full mesh support then its better to model the network as p2mp. Regards, Manav ----- Original Message ----- From: "Dhaval Shah" To: Sent: Tuesday, October 01, 2002 5:58 AM Subject: when to run in NBMA or P2MP mode? | Hi | According to RFC 2328, Ospf can run in one of the two modes on a | non-broadcast networks, NBMA or P2MP. RFC says that you can run in NBMA mode | if all routers attached to the network can communicate directly and you should | run in P2MP mode if thats not possible. | However, while sending hellos out on non-broadcast networks, irrespective of | which mode you run on, you always send them unicast to your neighbors. | The essential difference between NBMA and P2MP is only that there is DR/BDR | election and Network LSA generation in NBMA mode and not in P2MP mode. | So why is the need for the restriction that one MUST be able to reach all | neighbors directly in order to run in NBMA mode? What are some of the example | physical networks where one would like to run in P2MP mode and not in NBMA | mode? How can one determine which mode to run when? | | thanks | Dhaval. | | From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 06:07:46 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05498 for ; Tue, 1 Oct 2002 06:07:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0074974E@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 6:09:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 230892 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 06:09:42 -0400 Received: from 216.136.173.133 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 06:09:42 -0400 Received: from [203.200.20.226] by web12406.mail.yahoo.com via HTTP; Tue, 01 Oct 2002 03:09:41 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20021001100941.7809.qmail@web12406.mail.yahoo.com> Date: Tue, 1 Oct 2002 03:09:41 -0700 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: Re: when to run in NBMA or P2MP mode? Comments: cc: manav@samsung.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Good explanation but tell me that if p2mp can be effectively used without the full mesh of ospf routers then why dont we always use this. Why should we then use NBMA model at all? TIA --Rohit ----- Original Message ----- From: "Manav Bhatia" To: Sent: Tuesday, October 01, 2002 12:41 PM Subject: Re: when to run in NBMA or P2MP mode? | Dhaval, | Let me give it a shot! | | As i understand, you want to clarify the following | - Why the restriction of being able to reach all neighbors directly is | placed in order to run in NBMA mode when we always send unicasts to our | neighbors? | - When would we like to run as p2mp | - How can one determine which mode to run in? | | The reason why we want all the neighbors to be reached directly is because | we want to use mechanisms similar to those used in the broadcast subnets. | This helps making the NBMA segments more efficient in terms of : | - neighbor maintenance | - database synchronization | - database representation | - reducing the O(n^2) relationships to O(n) | | Emulating NBMA as a normal broadcast network helps the representation of an | NBMA subnet within OSPF LSDB as indistinguishable from the representation | of a broadcast subnet. | However, NBMA segments can fail when the two attached neighbors are not | able to communicate directly with each other.If, for example, a PVC fails | or is misconfigured or if an SVC cannot be established, due to capacity or | policy reasons, routing over NBMA will fail! | | When to use point-to-multipoint mode? | | Used if the nonbroadcast subnets cannot support a large number of routers | in complete mesh. | | To connect 200 routers in a full mesh over a Frame Relay/ATM subnet, one | would require (200)(200-1)/2 = 19,900 PVCs! Even when SVCs are used, | capacity limitations may prohibit pairwise connectivity. One cant thus use | the NBMA model as each router cant now communicate directly with the every | other router! The only alternative thus left is p2mp. | The problem comes when operating a full mesh FR/ATM network in p2mp mode | because now the work involved in neighbor maintenance, flooding and | database representation increases as O(n^2), where n is the nos. of routers | attached to the subnet, instead of O(n) that can be achieved with the NBMA | model. | | For the final question i guess the answer is that if you cant provide full | mesh support then its better to model the network as p2mp. | | Regards, | Manav __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 11:37:19 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22764 for ; Tue, 1 Oct 2002 11:37:18 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00749D8E@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 11:39:14 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 231773 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 11:39:14 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 11:39:14 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3CA6>; Tue, 1 Oct 2002 11:39:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 1 Oct 2002 08:35:04 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: when to run in NBMA or P2MP mode? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Dhaval, Section 2.1.1 answers almost all ur questions of ur questions. I guess in NBMA case we elect a DR, and as the DR is expected to be able to talk to all routers on the subnet(if this is not possible it could lead to problems where multiple DR's are elected for the same sub-interface etc leading to problems) we have the "MUST" restriction. Thanks, Vishwas -----Original Message----- From: Dhaval Shah [mailto:dshah@IPRG.NOKIA.COM] Sent: Tuesday, October 01, 2002 5:58 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: when to run in NBMA or P2MP mode? Hi According to RFC 2328, Ospf can run in one of the two modes on a non-broadcast networks, NBMA or P2MP. RFC says that you can run in NBMA mode if all routers attached to the network can communicate directly and you should run in P2MP mode if thats not possible. However, while sending hellos out on non-broadcast networks, irrespective of which mode you run on, you always send them unicast to your neighbors. The essential difference between NBMA and P2MP is only that there is DR/BDR election and Network LSA generation in NBMA mode and not in P2MP mode. So why is the need for the restriction that one MUST be able to reach all neighbors directly in order to run in NBMA mode? What are some of the example physical networks where one would like to run in P2MP mode and not in NBMA mode? How can one determine which mode to run when? thanks Dhaval. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 11:37:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22783 for ; Tue, 1 Oct 2002 11:37:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00749C75@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 11:39:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 231785 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 11:39:24 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 11:39:24 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3CA9>; Tue, 1 Oct 2002 11:39:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 1 Oct 2002 08:46:55 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Flooding AS-external LSAs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Vince, Flooding is done over adjacencies and not over interfaces(if there was a doubt there ;-)). Yes, all interfaces on a router are eligible, and for each eligible interface we perform the steps in the same section. For the simplest case "An implementation shall flood via all qualified interfaces" to neighbors. However if an implementation can determine that the neighbor router already has the same version of the LSA in its database(in which case flooding wouldn't be of any use) it could decide not to flood it. Thanks, Vishwas -----Original Message----- From: Vince [mailto:vmontoya@NMSU.EDU] Sent: Tuesday, October 01, 2002 4:03 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Flooding AS-external LSAs Regarding section 13.3 Next step in flooding procedure: AS-external-LSA's - "The eligible interfaces are all the router's interfaces ..." This states what links are qualified to be flooded but does it imply that an implemenation shall flood AS-external-LSAs via all qualified interfaces? Vince From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 11:56:15 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23627 for ; Tue, 1 Oct 2002 11:56:14 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00749E8A@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 11:58:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 231830 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 11:58:11 -0400 Received: from 65.86.17.254 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 11:48:11 -0400 Received: from subdimension.com ([192.168.0.4]) by subdimension.com ; Fri, 27 Sep 2002 03:07:40 -0400 X-Mailer: WebMAIL to Mail Gateway v3.0h X-DSMTPFooter: true Message-ID: <3d9402e3.77fb.1804289383@subdimension.com> Date: Fri, 27 Sep 2002 07:04:03 GMT Reply-To: Mailing List Sender: Mailing List From: Paul Jak Subject: Re: Paper comparing OSPF and ISIS Comments: cc: manav@samsung.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Manav, In your paper you said that keeping the metrics as 6 bits (as specified in ISO 10589) wide in ISIS helps in SPF optimization. Can you elaborate a little on how this is achieved? Moreover with the adoption of larger path costs (wide metrics) in ISIS this optimization goes away .. right? Thanks, Paul P.S. I understand that this question is not related to OSPF but since this paper was not posted on the ISIS WG (why?) i had to ask this here! _____________________________________________________________________ // free anonymous email || forums \\ subZINE || anonymous browsing subDIMENSION -- http://www.subdimension.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 11:59:02 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23777 for ; Tue, 1 Oct 2002 11:59:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00749F99@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 12:00:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 231891 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 12:00:59 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 12:00:58 -0400 Received: from redback.com (jagged.redback.com [155.53.36.195]) by prattle.redback.com (Postfix) with ESMTP id EBD291B8EE3 for ; Tue, 1 Oct 2002 09:00:57 -0700 (PDT) X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 References: <20021001100941.7809.qmail@web12406.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D99C6B9.1CD156E@redback.com> Date: Tue, 1 Oct 2002 09:00:57 -0700 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Organization: Redback Networks, Inc Subject: Re: when to run in NBMA or P2MP mode? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Rohit Gupta wrote: > > Hi, > Good explanation but tell me that if p2mp can be > effectively used without the full mesh of ospf routers > then why dont we always use this. Why should we then > use NBMA model at all? Rohit, NBMA should not be used if you don't have a full mesh. If you do have a full mesh using NBMA can significantly reduce your OSPF neighbor adjacencies and flooding overhead. Let's say that you have a full mesh attached to an NBMA subnet with N OSPF routers. You'll require N (N - 1) adjacencies in the case of P2MP and 2 (N - 1) in the case of NBMA. Thanks, > > TIA > > --Rohit > > ----- Original Message ----- > From: "Manav Bhatia" > To: > Sent: Tuesday, October 01, 2002 12:41 PM > Subject: Re: when to run in NBMA or P2MP mode? > > | Dhaval, > | Let me give it a shot! > | > | As i understand, you want to clarify the following > | - Why the restriction of being able to reach all > neighbors directly is > | placed in order to run in NBMA mode when we always > send unicasts to our > | neighbors? > | - When would we like to run as p2mp > | - How can one determine which mode to run in? > | > | The reason why we want all the neighbors to be > reached directly is because > | we want to use mechanisms similar to those used in > the broadcast subnets. > | This helps making the NBMA segments more efficient > in terms of : > | - neighbor maintenance > | - database synchronization > | - database representation > | - reducing the O(n^2) relationships to O(n) > | > | Emulating NBMA as a normal broadcast network helps > the representation of an > | NBMA subnet within OSPF LSDB as indistinguishable > from the representation > | of a broadcast subnet. > | However, NBMA segments can fail when the two > attached neighbors are not > | able to communicate directly with each other.If, for > example, a PVC fails > | or is misconfigured or if an SVC cannot be > established, due to capacity or > | policy reasons, routing over NBMA will fail! > | > | When to use point-to-multipoint mode? > | > | Used if the nonbroadcast subnets cannot support a > large number of routers > | in complete mesh. > | > | To connect 200 routers in a full mesh over a Frame > Relay/ATM subnet, one > | would require (200)(200-1)/2 = 19,900 PVCs! Even > when SVCs are used, > | capacity limitations may prohibit pairwise > connectivity. One cant thus use > | the NBMA model as each router cant now communicate > directly with the every > | other router! The only alternative thus left is > p2mp. > | The problem comes when operating a full mesh FR/ATM > network in p2mp mode > | because now the work involved in neighbor > maintenance, flooding and > | database representation increases as O(n^2), where n > is the nos. of routers > | attached to the subnet, instead of O(n) that can be > achieved with the NBMA > | model. > | > | For the final question i guess the answer is that if > you cant provide full > | mesh support then its better to model the network as > p2mp. > | > | Regards, > | Manav > > __________________________________________________ > Do you Yahoo!? > New DSL Internet Access from SBC & Yahoo! > http://sbc.yahoo.com -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 12:00:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23826 for ; Tue, 1 Oct 2002 12:00:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00749F25@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 12:02:14 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 231911 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 12:02:14 -0400 Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 12:02:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 1 Oct 2002 12:02:11 -0400 Reply-To: Mailing List Sender: Mailing List From: Jeff Parker Subject: Re: Paper comparing OSPF and ISIS To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > Manav, > In your paper you said that keeping the metrics as 6 bits > (as specified in ISO 10589) wide in ISIS helps in SPF > optimization. Can you elaborate a little on how this is > achieved? > > Moreover with the adoption of larger path costs (wide > metrics) in ISIS this optimization goes away .. right? > > Thanks, > Paul Paul - You can use a priority queue to select the next cheapest router during the main loop of the SPF computation. Having a small finite number of possible metrics allows you to implement a very efficient priority queue as an array of linked lists. With a larger metric, this array becomes prohibitively large. Insertion is O(1), and deletion can be made quite fast as well. - jeff parker - axiowave networks From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 12:15:14 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24892 for ; Tue, 1 Oct 2002 12:15:14 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00749F7A@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 12:17:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 231981 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 12:17:11 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 12:17:10 -0400 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g91GHAm65754 for ; Tue, 1 Oct 2002 09:17:10 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g91GHAM17414; Tue, 1 Oct 2002 09:17:10 -0700 (PDT) (envelope-from dkatz@cirrus.juniper.net) References: <200210010028.RAA09446@shah.iprg.nokia.com> <065401c26919$bb3c8640$b4036c6b@sisodomain.com> Message-ID: <200210011617.g91GHAM17414@cirrus.juniper.net> Date: Tue, 1 Oct 2002 09:17:10 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: when to run in NBMA or P2MP mode? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <065401c26919$bb3c8640$b4036c6b@sisodomain.com> (message from Manav Bhatia on Tue, 1 Oct 2002 12:41:13 +0530) Precedence: list I'd go further than that. NBMA mode should be avoided like the plague, because the network will break if you lose connectivity between the DR and any other router (a single failed VC is all it takes.) It is a much more natural fit to model an NBMA network as a collection of point-to-point links, since then link failures are treated like they would be in any point-to-point network, namely, as long as the network is not partitioned, routing will be correct. P2MP mode is, for the most part, a hack to get around router o/s's that didn't allow the configuration of point-to-point subinterfaces (since P2MP is effectively a simulation of P2P subinterfaces within OSPF.) There may be reasons that P2MP is more desirable than P2P (if subinterfaces are very expensive in your o/s, or if you didn't feel link renumbering your single-subnet NBMA network.) On the other hand, if you use P2P mode you could run your NBMA network unnumbered if you so desired. The theoretical advantages of the pseudo-LAN model (complexity reduction) are unlikely to be meaningful in practice. The largest NBMA networks I've seen (hundreds of routers) have typically been fully meshed but used pure point-to-point mode in the IGP. These days the links and CPUs are fast enough so that networks of practical size are not limited by the performance of the protocol. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 12:15:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24954 for ; Tue, 1 Oct 2002 12:15:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00749F7E@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 12:17:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 232000 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 12:17:50 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 12:17:49 -0400 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g91GHnm65814 for ; Tue, 1 Oct 2002 09:17:49 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g91GHnZ17421; Tue, 1 Oct 2002 09:17:49 -0700 (PDT) (envelope-from dkatz@cirrus.juniper.net) References: <20021001100941.7809.qmail@web12406.mail.yahoo.com> Message-ID: <200210011617.g91GHnZ17421@cirrus.juniper.net> Date: Tue, 1 Oct 2002 09:17:49 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: when to run in NBMA or P2MP mode? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021001100941.7809.qmail@web12406.mail.yahoo.com> (message from Rohit Gupta on Tue, 1 Oct 2002 03:09:41 -0700) Precedence: list Good explanation but tell me that if p2mp can be effectively used without the full mesh of ospf routers then why dont we always use this. Why should we then use NBMA model at all? Exactly. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 12:35:29 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25869 for ; Tue, 1 Oct 2002 12:35:29 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0074A080@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 12:37:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 232061 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 12:37:26 -0400 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 12:37:24 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01KN59MLNBW68X02SD@omega7.wr.usgs.gov> for OSPF@DISCUSS.MICROSOFT.COM; Tue, 01 Oct 2002 09:37:19 -0700 (PDT) X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM X-VMS-Cc: pmurphy MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01KN59MLNBW88X02SD@omega7.wr.usgs.gov> Date: Tue, 1 Oct 2002 09:37:19 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: when to run in NBMA or P2MP mode? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I have had some bad experiences using NBMA. A full mesh may exist when the topology is stable but can easily be lost due to outages. If an outage does not effect the links between the DR/BDR and the remaining routers in the mesh, then the SPF calculation of all the routers in an NBMA mesh will build routing table as if the full mesh still existed. This creates blackholes in domain. If P2MP is used, a legitimate fault tolerant routing table would still be built during these outages, although what was once only a single hop, may now be multiple hops. I only use NBMA when my full mesh is 99.99% stable or, when it breaks, simply partitions. Choosing between NBMA and P2MP is always a trade off between fault tolerance and flooding optimization. I believe it is possible to engineer a fault tolerant MPLS environment where NBMA could effectively be used. Pat From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 12:38:34 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26015 for ; Tue, 1 Oct 2002 12:38:34 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00749DF6@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 12:40:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 232086 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 12:40:31 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 12:40:31 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA18280 for ; Tue, 1 Oct 2002 12:40:29 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27528 for ; Tue, 1 Oct 2002 12:40:29 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Oct 2002 12:40:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763390@vie-msgusr-01.dc.fore.com> Date: Tue, 1 Oct 2002 12:40:28 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Paper comparing OSPF and ISIS To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Jeff, -> > Manav, -> > In your paper you said that keeping the metrics as 6 bits -> > (as specified in ISO 10589) wide in ISIS helps in SPF -> > optimization. Can you elaborate a little on how this is -> > achieved? -> > -> > Moreover with the adoption of larger path costs (wide -> > metrics) in ISIS this optimization goes away .. right? -> > -> > Thanks, -> > Paul -> -> Paul - -> You can use a priority queue to select the next cheapest -> router during the main loop of the SPF computation. Having a -> small finite number of possible metrics allows you to implement -> a very efficient priority queue as an array of linked lists. -> With a larger metric, this array becomes prohibitively large. -> Insertion is O(1), and deletion can be made quite fast as well. The algorithmic growth function or polynomial degree will not increase whether the metric sizes (input) are small or large (esp in the above case). The effect of increasing number of metrics does have an affect on the constants in the run-time performance, but on the growth function. In any case, whether you use small size fixed number of metrics or large size fixed number of metrics, the performance difference w.r.t insertion/deleting is very small (at least with the current day machines). Finally, I am not convinced by your answer w.r.t the 6-bits metric vs large 32-bit metric _and_ the relation to arrays and performance. Can you elaborate more ? -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 13:49:07 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28361 for ; Tue, 1 Oct 2002 13:49:07 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0074A237@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 13:51:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 232320 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 13:51:04 -0400 Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 13:51:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 1 Oct 2002 13:51:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Jeff Parker Subject: Re: Paper comparing OSPF and ISIS To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > -> Paul - > -> You can use a priority queue to select the next cheapest > -> router during the main loop of the SPF computation. Having a > -> small finite number of possible metrics allows you to implement > -> a very efficient priority queue as an array of linked lists. > -> With a larger metric, this array becomes prohibitively large. > -> Insertion is O(1), and deletion can be made quite fast as well. > > The algorithmic growth function or polynomial degree will > not increase whether the metric sizes (input) are small or > large (esp in the above case). The effect of increasing number > of metrics does have an affect on the constants in the run-time > performance, but on the growth function. > > In any case, whether you use small size fixed number of > metrics or large size fixed number of metrics, the > performance difference w.r.t insertion/deleting is very small > (at least with the current day machines). > > Finally, I am not convinced by your answer w.r.t the 6-bits > metric vs large 32-bit metric _and_ the relation to arrays > and performance. Can you elaborate more ? > > Venkata. Venkata - There are fast Priority Queue implementations that can deal with arbitrary costs. But Heaps, Fibonacci Heaps, skew heaps, leftist heaps, etc. have log(n) insertion and/or deletion cost. With metrics in the range [0..2^8-1], you can implement a Priority Queue as an array of 256 queues or stacks, and insert in constant time. Since you remove items in ascending order, you can delete in O(1) time as well by simply keeping track of where your last deletion was. Building an array of 2^32 links is prohibitive, so while it is possible to do the same in theory, in practice it doesn't scale. Note that O(2^8) is O(1), while O(2^32) is O(1) in theory only. As you know, the difference between N * O(1) and N * O(log(N)) is significant in practice. So I am probably missing what you want elaboration on. - jeff parker From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 14:10:20 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29178 for ; Tue, 1 Oct 2002 14:10:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0074A215@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 14:12:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 232377 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 14:12:18 -0400 Received: from 207.217.120.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 14:12:18 -0400 Received: from user-2ivfnbt.dialup.mindspring.com ([165.247.221.125] helo=earthlink.net) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17wRVI-0003li-00 for ospf@discuss.microsoft.com; Tue, 01 Oct 2002 11:12:16 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D99DF62.87092338@earthlink.net> Date: Tue, 1 Oct 2002 10:46:10 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: another appoach to OOB LSDB Resynchronization?? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, I haven't seen whether last year's RFC on Out-of-band LSDB Resynchronization draft had been formalized into a standardized RFC. So these comments may be way late, with this different approach to perform LSDB Resynchronization. I haven't tried this .... but in my mind this method could accomplish the same thing with legacy routers and remove the need for a option bit which is becoming a scarse thing in version 2. And be a lightweight mechanism. Since the neighbor field in a hello PDU is the normal indicator of 2-way communication, why not just temporarily drop the neighbor field of the adjacency that you wish to re-establish? Yes, I am assuming that based on your internal request to perform this operation you reset your neighbor state machine and set a internal "OOB request neighbor field flag". At best you can re-establish the link on average of 1/2 hello interval and at worst you will have to wait router-dead-interval timeframe before you re-acknowledge the arrival of hellos from the neighbor that you wish resync the adjacency. (or wait before you resend hellos?) The preference is to just with-hold the neighbor from the neighbor field. This would allow the OOB requester to remain as a DR or BDR if that was his orignal router OSPF type. This would remove any necessary overhead of elections, adjacency reformations, and substantial SPF calculations. Then the question is how to utilize the flag to make sure that you don't deallocate any neighbor data structures and whether you increment the sequence number of your orignated LSAs, keep them the same, or set MAXAGE and then resend. More than likely you will also have to withold flooding to the neighbor or acks back to the neighbor from his flooding of LSAs. If LSAs were recv'ed from the neighbor during flooding, I would probably incorporate them into my LSDB. Independent of how you deal with the above issues, you then must re-attempt to synchronize the LSDB. Assuming that their were more than two OSPF speaking routers in your area, your previous interaction should have minimal effects on your neighbor. More than likely, he had kept your earlier originated LSAs in his database. And you just resync, upon reaching full state again with the neighbor, you clear your internal "OOB request neighbor field flag". Is there a dual-behaviour (one who wants to redo the initial LSDB synchronization and one who keeps the established adj) achieved by establishing a adjacency and then removing the neighbor specified in the hello field that really requires the OOB requestor in the scenario to cycle into a period of router-dead-interval before sending out new hellos AND ... ???? Flames now allowed.... Mitchell Erblich ========================== From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 14:30:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00453 for ; Tue, 1 Oct 2002 14:30:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0074A178@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 14:32:47 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 232493 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 14:32:47 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 14:32:47 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25504 for ; Tue, 1 Oct 2002 14:32:45 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA18454 for ; Tue, 1 Oct 2002 14:32:46 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Oct 2002 14:32:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763391@vie-msgusr-01.dc.fore.com> Date: Tue, 1 Oct 2002 14:32:44 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Paper comparing OSPF and ISIS To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Jeff, -> So I am probably missing what you want elaboration on. No. you didn't miss my point. You explained it right. You are right there! Please see comments inline. -> Venkata - -> There are fast Priority Queue implementations that -> can deal with arbitrary costs. But Heaps, Fibonacci Heaps, -> skew heaps, leftist heaps, etc. have log(n) insertion and/or -> deletion cost. -> -> With metrics in the range [0..2^8-1], you can implement -> a Priority Queue as an array of 256 queues or stacks, and -> insert in constant time. Since you remove items in ascending -> order, you can delete in O(1) time as well by simply keeping -> track of where your last deletion was. I got your point. Since you have small metrics, you have the freedom of maintaining an array. As you know, the memory consumption (in-place algorithms) and run-time cost of algorithms are not the same. There are algorithms which are in-place and can run linear time (not necessary *comparison based algos* you described above). -> Building an array of 2^32 links is prohibitive, so -> while it is possible to do the same in theory, in practice -> it doesn't scale. Yes! if the metrics sizes are more, I am prohibited to use an array (preferably, I don't want to use all the virtual memory I have - definitely I can't use the physical available memory :)). -> Note that O(2^8) is O(1), while O(2^32) is O(1) in theory -> only. Exactly. But, the number O(2^32) comes when I prefer to use 2^32 array. If I go for an hash based, radix or Patricia based algos then the constant will be much less than O(2^32) - no wonder even if it is less than O(2^8). But as you said, the growth rate may not be same (depending on the algo - may be O(logN) or even more). But all my assertion is simple - the performance gain you get by using algos which are not linear over simple/small sets is not much. Insertion sort with O(n^2) also perfectly suits well if the number of metrics are less (again, the size of the metrics have very little effect - total count will effect). -> As you know, the difference between N * O(1) and -> N * O(log(N)) is significant in practice. As you know, difference between N * O(2^8) and c * O(N) is significant in practice, if c and N are relatively small. For example, quick sorts performance is O(N^2) and merge/heap sort is O(log N). That doesn't mean that quick sort is a bad choice. Research showed that over some probabilistic distributions (or even random generators), quick sort outperforms merge/heap sort. If my input is very small, I don't bother much about algo. Again - IMHO, the performance gain you get by using small set of metrics is very very less. After all, this is my observation/opinion :) -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 1 15:29:29 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02341 for ; Tue, 1 Oct 2002 15:29:29 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0074A3A8@cherry.ease.lsoft.com>; Tue, 1 Oct 2002 15:31:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 232760 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Oct 2002 15:31:27 -0400 Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 1 Oct 2002 15:31:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 1 Oct 2002 15:31:14 -0400 Reply-To: Mailing List Sender: Mailing List From: Jeff Parker Subject: Running time for SPF in ISIS To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I have changed the title, but will try not to post any more follow-ups to this thread. > For example, quick sorts performance is O(N^2) and > merge/heap sort is O(log N). This is way out of scope for the OSPF list, but quicksort is only O(N^2) in theory. > That doesn't mean that quick sort > is a bad choice. Research showed that over some > probabilistic distributions (or even random generators), > quick sort outperforms merge/heap sort. because Quicksort is O(N log(N)) with reasonable assumptions and smart implementations, and has far less overhead, as it moves things towards their final resting spot from the start. Search for Quicksort and Sedgewick. > If my input is very small, I don't bother much about algo. > Again - IMHO, the performance gain you get by using small > set of metrics is very very less. > After all, this is my observation/opinion :) > > Venkata So I'm not sure what we are left with. If you have small networks, the SPF performance is not an issue. If you are using incremental SPF, or good data structures, SPF is not an issue. There is a good, simple, cheap implementation for SPF in the old narrow ISIS metric. It is not enough of a reason to prefer ISIS to OSPF, and it doesn't apply to the wide metrics. It is really just a historical note. - jeff parker - axiowave networks From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 2 03:06:34 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11176 for ; Wed, 2 Oct 2002 03:06:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0074BF38@cherry.ease.lsoft.com>; Wed, 2 Oct 2002 3:08:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 234272 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Oct 2002 03:08:27 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 2 Oct 2002 03:08:27 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3C0Z>; Wed, 2 Oct 2002 03:08:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 2 Oct 2002 03:10:34 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: another appoach to OOB LSDB Resynchronization?? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Mitchell, The draft is an individual submission and is located at http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-01.txt I am however not too sure how you intend to achieve LSDB resynch without changing the topology view of the network, because when we get a 1-way received event we clear all the LS Retransmit List, DB summary list and Link state request list and goto "Init" state. Are you saying we dont handle the 1-way received event at all? How will the neighbor know when its doing LSDB resynch and when its not? I would be averse to any change in the FSM though. A much simpler way to force an LSDB synch however would be to simply start DB exchange by sending DBD packets with the init bit set(SeqNumberMismatch event). This would bring the adjacencies to Exstart state(and not to Init as it would in case of 1-way received), however the topology data would change. We could as well not change topology if we get SeqNumberMismatch in all cases for the SeqNumberMismatch event, however I think it would be a major deviation from the OSPF protocol. Thanks, Vishwas -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Tuesday, October 01, 2002 11:16 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: another appoach to OOB LSDB Resynchronization?? Group, I haven't seen whether last year's RFC on Out-of-band LSDB Resynchronization draft had been formalized into a standardized RFC. So these comments may be way late, with this different approach to perform LSDB Resynchronization. I haven't tried this .... but in my mind this method could accomplish the same thing with legacy routers and remove the need for a option bit which is becoming a scarse thing in version 2. And be a lightweight mechanism. Since the neighbor field in a hello PDU is the normal indicator of 2-way communication, why not just temporarily drop the neighbor field of the adjacency that you wish to re-establish? Yes, I am assuming that based on your internal request to perform this operation you reset your neighbor state machine and set a internal "OOB request neighbor field flag". At best you can re-establish the link on average of 1/2 hello interval and at worst you will have to wait router-dead-interval timeframe before you re-acknowledge the arrival of hellos from the neighbor that you wish resync the adjacency. (or wait before you resend hellos?) The preference is to just with-hold the neighbor from the neighbor field. This would allow the OOB requester to remain as a DR or BDR if that was his orignal router OSPF type. This would remove any necessary overhead of elections, adjacency reformations, and substantial SPF calculations. Then the question is how to utilize the flag to make sure that you don't deallocate any neighbor data structures and whether you increment the sequence number of your orignated LSAs, keep them the same, or set MAXAGE and then resend. More than likely you will also have to withold flooding to the neighbor or acks back to the neighbor from his flooding of LSAs. If LSAs were recv'ed from the neighbor during flooding, I would probably incorporate them into my LSDB. Independent of how you deal with the above issues, you then must re-attempt to synchronize the LSDB. Assuming that their were more than two OSPF speaking routers in your area, your previous interaction should have minimal effects on your neighbor. More than likely, he had kept your earlier originated LSAs in his database. And you just resync, upon reaching full state again with the neighbor, you clear your internal "OOB request neighbor field flag". Is there a dual-behaviour (one who wants to redo the initial LSDB synchronization and one who keeps the established adj) achieved by establishing a adjacency and then removing the neighbor specified in the hello field that really requires the OOB requestor in the scenario to cycle into a period of router-dead-interval before sending out new hellos AND ... ???? Flames now allowed.... Mitchell Erblich ========================== From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 2 04:58:34 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12823 for ; Wed, 2 Oct 2002 04:58:34 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0074BEFE@cherry.ease.lsoft.com>; Wed, 2 Oct 2002 5:00:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 234554 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Oct 2002 05:00:24 -0400 Received: from 144.254.98.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 2 Oct 2002 04:50:24 -0400 Received: from mshand-w2k.cisco.com (ams-clip-vpn-dhcp4163.cisco.com [10.50.16.66]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA02665; Wed, 2 Oct 2002 09:50:18 +0100 (BST) X-Sender: mshand@jaws.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20021002094102.02854bf0@jaws.cisco.com> Date: Wed, 2 Oct 2002 09:49:13 +0100 Reply-To: Mailing List Sender: Mailing List From: mike shand Subject: Re: Running time for SPF in ISIS To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list At 15:31 01/10/2002 -0400, Jeff Parker wrote: >There is a good, simple, cheap implementation >for SPF in the old narrow ISIS metric. It is >not enough of a reason to prefer ISIS to OSPF, >and it doesn't apply to the wide metrics. >It is really just a historical note. Absolutely. When IS-IS was designed, processors were so slow (and networks were so large, even then) that this was thought to be a significant issue. This is why the original IS-IS design was limited to 6 bit metrics. But times have changed. Processors are orders of magnitude faster, and nobody builds REALLY big networks (areas), so there is really no advantage in the optimization, and people like using wide metric ranges. There ARE efficient algorithms for queue management which give something like O (loglogN) (I forget exactly what). But these tend to be fiendishly complicated and just aren't worth the trouble for SPFs in communication networks. However in other applications where it is desired to run an SPF with (say) millions of nodes, then the use of these algorithms may become important. Mike From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 2 07:30:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15349 for ; Wed, 2 Oct 2002 07:30:35 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0074C2FB@cherry.ease.lsoft.com>; Wed, 2 Oct 2002 7:32:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 236069 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Oct 2002 07:32:32 -0400 Received: from 203.199.83.38 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 2 Oct 2002 07:22:32 -0400 Received: (qmail 16086 invoked by uid 510); 2 Oct 2002 11:27:23 -0000 Received: from unknown (164.164.86.66) by rediffmail.com via HTTP; 02 Oct 2002 11:27:23 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20021002112723.16085.qmail@webmail28.rediffmail.com> Date: Wed, 2 Oct 2002 11:27:23 -0000 Reply-To: Mailing List Sender: Mailing List From: Ashaunti canton Subject: LSDB size To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I am not sure if this is the right list to post on. But can anybody give me an idea of the size of OSPF LSDB in large scale ISP networks, in terms of number of LSAs in the backbone area? I need to get an idea of typical LSDB sizes in large scale networks. Thanks, Ashaunti __________________________________________________________ Give your Company an email address like ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! Know more. http://www.rediffmailpro.com/signup/ From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 2 10:21:12 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22027 for ; Wed, 2 Oct 2002 10:21:12 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0074C786@cherry.ease.lsoft.com>; Wed, 2 Oct 2002 10:23:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 236644 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Oct 2002 10:23:09 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 2 Oct 2002 10:23:09 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04874 for ; Wed, 2 Oct 2002 10:22:47 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13438 for ; Wed, 2 Oct 2002 10:22:17 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Oct 2002 10:22:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763394@vie-msgusr-01.dc.fore.com> Date: Wed, 2 Oct 2002 10:22:13 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Running time for SPF in ISIS To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -> This is why the original IS-IS design was limited to 6 bit -> metrics. But -> times have changed. Processors are orders of magnitude -> faster, and nobody -> builds REALLY big networks (areas), so there is really no -> advantage in the -> optimization, and people like using wide metric ranges. Addition to what mike said - using wide metrics became necessity. Times have changed - today, links over which traditional routing protocols can run ranges from DCs to OCxxx. So the representation of link characteristics in a limited space [0, 2^6] is unreasonable. RIP suffered a lot because of its metric size (of course that was the tradeoff between how fast RIP can reach the infinity vs how well link can be represented etc etc). -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 2 23:58:48 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16340 for ; Wed, 2 Oct 2002 23:58:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0074E729@cherry.ease.lsoft.com>; Thu, 3 Oct 2002 0:00:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 238465 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Oct 2002 00:00:46 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 3 Oct 2002 00:00:25 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) id <0H3E008010PFC0@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Thu, 03 Oct 2002 13:05:39 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H3E0080X0PFA7@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Thu, 03 Oct 2002 13:05:39 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0H3E0008T0QA82@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Thu, 03 Oct 2002 13:06:12 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3d9402e3.77fb.1804289383@subdimension.com> Message-ID: <07d301c26a91$44700770$b4036c6b@sisodomain.com> Date: Thu, 3 Oct 2002 09:29:25 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Paper comparing OSPF and ISIS To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Paul, set T = set of vertices under consideration Computation time of SPF algo = O(LlogN) where L is nos of links and N, the nos. of nodes. The logN factor results when selecting the next best router during the main loop of SPF algo from the elements of set T. These elements in set T are presorted by cost to avoid the need for linear search in selecting the element with the lowest cost. The processing time required by the binary search mechanism used in sorting T while inserting new entries introduces the logN factor. By using a finite path cost based on 6 bit field, it was possible to further optimize and reduce the order of complexity to just O(N) eliminating the logN factor. This was achieved using quick array sort data structures, which sorts nodes by hashing them according to path cost rather than logical distance. Unfortunately, over time, the 6 bits have proven insufficient for providing flexibility in designing ISIS networks, as well as in other applications of ISIS routing (e.g. MPLS TE) And yes, the adoption of larger path costs (wide metrics) in ISIS takes away the optimization opportunity with small finite path costs (narrow metrics) but then CPU are really fast these days and nobody builds really very big networks anyway. Regards, Manav ----- Original Message ----- From: "Paul Jak" To: Sent: Friday, September 27, 2002 12:34 PM Subject: Re: Paper comparing OSPF and ISIS | Manav, | In your paper you said that keeping the metrics as 6 bits | (as specified in ISO 10589) wide in ISIS helps in SPF | optimization. Can you elaborate a little on how this is | achieved? | | Moreover with the adoption of larger path costs (wide | metrics) in ISIS this optimization goes away .. right? | | Thanks, | Paul | | P.S. | I understand that this question is not related to OSPF but | since this paper was not posted on the ISIS WG (why?) i had | to ask this here! | _____________________________________________________________________ | // free anonymous email || forums \\ subZINE || anonymous browsing | subDIMENSION -- http://www.subdimension.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 3 05:01:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29770 for ; Thu, 3 Oct 2002 05:01:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0074EEEE@cherry.ease.lsoft.com>; Thu, 3 Oct 2002 5:03:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 238908 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Oct 2002 05:03:43 -0400 Received: from 193.71.199.94 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 3 Oct 2002 05:03:43 -0400 Received: from [10.9.9.110] (helo=snoopy.runbox.com) by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1) id 17x1tV-00012i-00; Thu, 03 Oct 2002 11:03:41 +0200 Received: from [203.200.20.226] (helo=Manav) (Authenticated Sender=dovek) by snoopy.runbox.com with asmtp (Exim 3.35 #1) id 17x1tK-0003Xq-00; Thu, 03 Oct 2002 11:03:30 +0200 References: <200210010028.RAA09446@shah.iprg.nokia.com> <065401c26919$bb3c8640$b4036c6b@sisodomain.com> <200210011617.g91GHAM17414@cirrus.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <096701c26abb$9f8928b0$b4036c6b@sisodomain.com> Date: Thu, 3 Oct 2002 14:32:24 +0530 Reply-To: Mailing List Sender: Mailing List From: Misha Dovek Subject: Re: when to run in NBMA or P2MP mode? Comments: cc: Dave Katz To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit > P2MP mode is, for the most part, a hack to get around router o/s's that > didn't allow the configuration of point-to-point subinterfaces (since > P2MP is effectively a simulation of P2P subinterfaces within OSPF.) There > may be reasons that P2MP is more desirable than P2P (if subinterfaces are > very expensive in your o/s, or if you didn't feel link renumbering your > single-subnet NBMA network.) On the other hand, if you use P2P mode you > could run your NBMA network unnumbered if you so desired. what exactly is the difference between p2p interfaces and p2p subinterfaces. I tried searching for that in google but couldnt find any information. I come across this term a lot of times and would be glad if somebody could explain me about it. Misha From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 3 12:50:33 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24133 for ; Thu, 3 Oct 2002 12:50:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00751BA1@cherry.ease.lsoft.com>; Thu, 3 Oct 2002 12:52:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 242113 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Oct 2002 12:52:32 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 3 Oct 2002 12:52:32 -0400 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g93GqVm41012; Thu, 3 Oct 2002 09:52:31 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g93GqIm23408; Thu, 3 Oct 2002 09:52:18 -0700 (PDT) (envelope-from dkatz@cirrus.juniper.net) References: <200210010028.RAA09446@shah.iprg.nokia.com> <065401c26919$bb3c8640$b4036c6b@sisodomain.com> <200210011617.g91GHAM17414@cirrus.juniper.net> <096701c26abb$9f8928b0$b4036c6b@sisodomain.com> Message-ID: <200210031652.g93GqIm23408@cirrus.juniper.net> Date: Thu, 3 Oct 2002 09:52:18 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: when to run in NBMA or P2MP mode? Comments: To: dovek@runbox.com To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <096701c26abb$9f8928b0$b4036c6b@sisodomain.com> (dovek@runbox.com) Precedence: list what exactly is the difference between p2p interfaces and p2p subinterfaces. I tried searching for that in google but couldnt find any information. I come across this term a lot of times and would be glad if somebody could explain me about it. A subinterface (or logical interface) is a way of subdividing a physical interface into multiple logical interfaces. NBMA interface are often treated this way--one or more PVCs is treated as a logical interface. If only one PVC is bound to a logical interface, that logical interface can appear to the rest of the system as a standard point-to-point interface. You can also bind multiple PVCs and treat it as a multipoint interface, but this is rarely done in practice. Subinterfaces are often used with other media, such as VLANs--each VLAN is treated as a separate multipoint subinterface. From the point of view of router applications (such as OSPF), there is no difference between a true P2P interface and a P2P subinterface, which of course is the whole point fo the exercise. --Dave From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 3 13:26:01 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26366 for ; Thu, 3 Oct 2002 13:26:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00751D3F@cherry.ease.lsoft.com>; Thu, 3 Oct 2002 13:28:01 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 242194 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Oct 2002 13:28:01 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 3 Oct 2002 13:28:01 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12567 for ; Thu, 3 Oct 2002 13:27:59 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA00227 for ; Thu, 3 Oct 2002 13:28:00 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Oct 2002 13:27:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC5576339A@vie-msgusr-01.dc.fore.com> Date: Thu, 3 Oct 2002 13:27:59 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: when to run in NBMA or P2MP mode? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Dave, -> From: Dave Katz [mailto:dkatz@JUNIPER.NET] -> Sent: Thursday, October 03, 2002 12:52 PM -> -> what exactly is the difference between p2p interfaces and -> p2p subinterfaces. -> I tried searching for that in google but couldnt find any -> information. I -> come across this term a lot of times and would be glad if -> somebody could -> explain me about it. -> -> A subinterface (or logical interface) is a way of subdividing a -> physical interface into multiple logical interfaces. Is this same as *multi-netting* ? I think there is a small difference between *multi-netting* and *subinterfaces*. Multi-netting can be applicable to BCs also (not only NBMAs)?!? -> NBMA interface -> are often treated this way--one or more PVCs is treated as a logical -> interface. If only one PVC is bound to a logical interface, that -> logical interface can appear to the rest of the system as a standard -> point-to-point interface. You can also bind multiple PVCs and treat -> it as a multipoint interface, but this is rarely done in practice. -> Subinterfaces are often used with other media, such as VLANs--each -> VLAN is treated as a separate multipoint subinterface. -> -> From the point of view of router applications (such as -> OSPF), there is -> no difference between a true P2P interface and a P2P subinterface, -> which of course is the whole point fo the exercise. -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 3 13:37:49 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27028 for ; Thu, 3 Oct 2002 13:37:49 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00751D0E@cherry.ease.lsoft.com>; Thu, 3 Oct 2002 13:39:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 242241 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Oct 2002 13:39:48 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 3 Oct 2002 13:39:48 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA13294 for ; Thu, 3 Oct 2002 13:39:33 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02565 for ; Thu, 3 Oct 2002 13:39:10 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Oct 2002 13:39:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC5576339B@vie-msgusr-01.dc.fore.com> Date: Thu, 3 Oct 2002 13:39:09 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: when to run in NBMA or P2MP mode? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -> -> A subinterface (or logical interface) is a way of subdividing a -> -> physical interface into multiple logical interfaces. -> -> Is this same as *multi-netting* ? I think there is a small -> difference between *multi-netting* and *subinterfaces*. -> Multi-netting can be applicable to BCs also (not only NBMAs)?!? For the benefit of the community - Operating Systems developers use the term "interface aliasing" for the same purpose. Router vendors use the term *subinterfaces*. -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 3 15:50:26 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02899 for ; Thu, 3 Oct 2002 15:50:21 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00752225@cherry.ease.lsoft.com>; Thu, 3 Oct 2002 15:52:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 242563 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Oct 2002 15:52:09 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 3 Oct 2002 15:52:09 -0400 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g93Jq8m58337 for ; Thu, 3 Oct 2002 12:52:08 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g93Jq8g23946; Thu, 3 Oct 2002 12:52:08 -0700 (PDT) (envelope-from dkatz@cirrus.juniper.net) References: <39469E08BD83D411A3D900204840EC5576339A@vie-msgusr-01.dc.fore.com> Message-ID: <200210031952.g93Jq8g23946@cirrus.juniper.net> Date: Thu, 3 Oct 2002 12:52:08 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: when to run in NBMA or P2MP mode? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC5576339A@vie-msgusr-01.dc.fore.com> (Venkata.Naidu@MARCONI.COM) Precedence: list Is this same as *multi-netting* ? I think there is a small difference between *multi-netting* and *subinterfaces*. Multi-netting can be applicable to BCs also (not only NBMAs)?!? If by "multi-netting" you mean assigning multiple subnets to a physical interface, this isn't necessarily the same. The key to subinterfaces is that an incoming packet must have sufficient information to be able to demultiplex to the proper subinterface. You can't assign multiple subnets to an Ethernet, for instance, using subinterfaces, because you can't tell by looking at an incoming packet the interface with which it is associated. (But you can if you are using VLANs by looking at the VLAN ID, or on ATM or FR by looking at the VC information.) From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 3 16:07:57 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03327 for ; Thu, 3 Oct 2002 16:07:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.007525F1@cherry.ease.lsoft.com>; Thu, 3 Oct 2002 16:09:52 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 242675 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Oct 2002 16:09:52 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 3 Oct 2002 16:09:50 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA23509 for ; Thu, 3 Oct 2002 16:09:41 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA03469 for ; Thu, 3 Oct 2002 16:09:42 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Oct 2002 16:09:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC5576339E@vie-msgusr-01.dc.fore.com> Date: Thu, 3 Oct 2002 16:09:41 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: when to run in NBMA or P2MP mode? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Dave, -> because you can't tell by looking at an incoming packet -> the interface with which it is associated. (But you can if you are -> using VLANs by looking at the VLAN ID, or on ATM or FR by looking at -> the VC information.) Got your point. Then, *interface aliasing* is same as *multi-netting*. *subinterfaces* is a special case. Thanks! -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 3 21:14:38 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10099 for ; Thu, 3 Oct 2002 21:14:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00753C48@cherry.ease.lsoft.com>; Thu, 3 Oct 2002 21:16:36 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 243977 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Oct 2002 21:16:36 -0400 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 3 Oct 2002 21:16:36 -0400 Received: from user-2ivfju1.dialup.mindspring.com ([165.247.207.193] helo=earthlink.net) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 17xH4z-0006nu-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 03 Oct 2002 18:16:33 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D9CEF1F.B4CBC42D@earthlink.net> Date: Thu, 3 Oct 2002 18:30:07 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: another appoach to OOB LSDB Resynchronization?? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vishwas, Vishwas, I think there is significantly more work in your implimentation than doing what I suggested. *** My approach is to fit within the understanding of the OSPF protocol. And was a "clean slate appoach". The temporarily dropping the neighbor field and moving to 1-way suggestion is to fit into the original concept of the neighbor state machine. This is a neighbor state machine event. Once that particular hello PDU is sent, the next hello would then include the "missing neighbor field". This again is another neighbor state machine event. Due to the fact, that I have assumed that full adjacency has already been reached, then the retransmit and the requests lists should be empty. Yes, the neighbor timers will restart, etc.. However, any neighbor state other than full state should be applicable for this type of change. Via the state machine, we should then be able to exchange Database Description packets. We then can build whatever lists that are then required via our normal process to re-synch the our LSDBs. *** All of this was to suggest there is no reason to consume a option bit for the reason of the draft RFC. One reason why might want to resync?? Lets say we have one or more DNA LSAs that were originated by someone else. I have seen corruption on one or more of these LSAs and don't want to wait until the removed LSAs could possilby be re-flooded. Mitchell Erblich =============== "Manral, Vishwas" wrote: > > Hi Mitchell, > > The draft is an individual submission and is located at > http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-01.txt > > I am however not too sure how you intend to achieve LSDB resynch without > changing the topology view of the network, because when we get a 1-way > received event we clear all the LS Retransmit List, DB summary list and Link > state request list and goto "Init" state. Are you saying we dont handle the > 1-way received event at all? How will the neighbor know when its doing LSDB > resynch and when its not? I would be averse to any change in the FSM though. > > A much simpler way to force an LSDB synch however would be to simply start > DB exchange by sending DBD packets with the init bit set(SeqNumberMismatch > event). This would bring the adjacencies to Exstart state(and not to Init as > it would in case of 1-way received), however the topology data would change. > We could as well not change topology if we get SeqNumberMismatch in all > cases for the SeqNumberMismatch event, however I think it would be a major > deviation from the OSPF protocol. > > Thanks, > Vishwas > > -----Original Message----- > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > Sent: Tuesday, October 01, 2002 11:16 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: another appoach to OOB LSDB Resynchronization?? > > Group, > > I haven't seen whether last year's RFC on Out-of-band > LSDB Resynchronization draft had been formalized into a > standardized RFC. > > So these comments may be way late, with this > different approach to perform LSDB Resynchronization. > > I haven't tried this .... but in my mind this > method could accomplish the same thing with > legacy routers and remove the need for a > option bit which is becoming a scarse thing > in version 2. And be a lightweight mechanism. > > Since the neighbor field in a hello PDU is the > normal indicator of 2-way communication, why > not just temporarily drop the neighbor field > of the adjacency that you wish to re-establish? > > Yes, I am assuming that based on your internal > request to perform this operation you reset > your neighbor state machine and set a internal > "OOB request neighbor field flag". > > At best you can re-establish the link on average > of 1/2 hello interval and at worst you will have > to wait router-dead-interval timeframe before > you re-acknowledge the arrival of hellos from > the neighbor that you wish resync the adjacency. > (or wait before you resend hellos?) > > The preference is to just with-hold the neighbor > from the neighbor field. This would allow the > OOB requester to remain as a DR or BDR if that > was his orignal router OSPF type. This would > remove any necessary overhead of elections, > adjacency reformations, and substantial SPF > calculations. > > Then the question is how to utilize the flag > to make sure that you don't deallocate any > neighbor data structures and whether you increment > the sequence number of your orignated LSAs, > keep them the same, or set MAXAGE and then resend. > More than likely you will also have to withold > flooding to the neighbor or acks back to the > neighbor from his flooding of LSAs. If LSAs were > recv'ed from the neighbor during flooding, I would > probably incorporate them into my LSDB. > > Independent of how you deal with the above issues, > you then must re-attempt to synchronize the LSDB. > Assuming that their were more than two OSPF speaking > routers in your area, your previous interaction should > have minimal effects on your neighbor. More than > likely, he had kept your earlier originated LSAs > in his database. And you just resync, upon reaching > full state again with the neighbor, you clear your > internal "OOB request neighbor field flag". > > Is there a dual-behaviour (one who wants to redo the > initial LSDB synchronization and one who keeps the > established adj) achieved by establishing > a adjacency and then removing the neighbor specified > in the hello field that really requires the > OOB requestor in the scenario to cycle into a > period of router-dead-interval before sending out > new hellos AND ... ???? > > Flames now allowed.... > > Mitchell Erblich > ========================== From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 3 21:27:13 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10287 for ; Thu, 3 Oct 2002 21:27:13 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00753D3F@cherry.ease.lsoft.com>; Thu, 3 Oct 2002 21:29:12 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 244028 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Oct 2002 21:29:12 -0400 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 3 Oct 2002 21:29:11 -0400 Received: from user-2ivfju1.dialup.mindspring.com ([165.247.207.193] helo=earthlink.net) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 17xHHC-00079z-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 03 Oct 2002 18:29:11 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <20021002112723.16085.qmail@webmail28.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D9CF215.2FC5C123@earthlink.net> Date: Thu, 3 Oct 2002 18:42:45 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: LSDB size To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Ashaunti, My assumption would be from 50k to 200k on average. Mitchell Erblich ======================= Ashaunti canton wrote: > > Hi, > > I am not sure if this is the right list to post on. But can > anybody give me an idea of the size of OSPF LSDB in large scale > ISP networks, in terms of number of LSAs in the backbone area? > > I need to get an idea of typical LSDB sizes in large scale > networks. > > Thanks, > Ashaunti > __________________________________________________________ > Give your Company an email address like > ravi @ ravi-exports.com. Sign up for Rediffmail Pro today! > Know more. http://www.rediffmailpro.com/signup/ From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 4 02:11:01 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24043 for ; Fri, 4 Oct 2002 02:11:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.007547F9@cherry.ease.lsoft.com>; Fri, 4 Oct 2002 2:13:01 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 244673 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Oct 2002 02:13:00 -0400 Received: from 193.71.199.94 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 4 Oct 2002 02:12:59 -0400 Received: from [10.9.9.110] (helo=snoopy.runbox.com) by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1) id 17xLhr-0003XN-00 for OSPF@discuss.microsoft.com; Fri, 04 Oct 2002 08:12:59 +0200 Received: from [203.200.20.226] (helo=Manav) (Authenticated Sender=dovek) by snoopy.runbox.com with asmtp (Exim 3.35 #1) id 17xLhS-0000gd-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 04 Oct 2002 08:12:35 +0200 References: <200210010028.RAA09446@shah.iprg.nokia.com> <065401c26919$bb3c8640$b4036c6b@sisodomain.com> <200210011617.g91GHAM17414@cirrus.juniper.net> <096701c26abb$9f8928b0$b4036c6b@sisodomain.com> <200210031652.g93GqIm23408@cirrus.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <143101c26b6c$e82d0620$b4036c6b@sisodomain.com> Date: Fri, 4 Oct 2002 11:41:36 +0530 Reply-To: Mailing List Sender: Mailing List From: Misha Dovek Subject: p2p subinterfaces - why ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, Can anyone please give me real life usages of p2p subinterfaces? Misha From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 4 04:10:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25655 for ; Fri, 4 Oct 2002 04:10:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00754913@cherry.ease.lsoft.com>; Fri, 4 Oct 2002 4:12:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 244883 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Oct 2002 04:12:22 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 4 Oct 2002 04:12:21 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) id <0H3G0020171LXJ@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Fri, 04 Oct 2002 17:17:45 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H3G0029Z71LIX@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Fri, 04 Oct 2002 17:17:45 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0H3G00DC172G6K@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Fri, 04 Oct 2002 17:18:17 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200210010028.RAA09446@shah.iprg.nokia.com> <065401c26919$bb3c8640$b4036c6b@sisodomain.com> <200210011617.g91GHAM17414@cirrus.juniper.net> <096701c26abb$9f8928b0$b4036c6b@sisodomain.com> <200210031652.g93GqIm23408@cirrus.juniper.net> <143101c26b6c$e82d0620$b4036c6b@sisodomain.com> Message-ID: <154801c26b7d$a30edee0$b4036c6b@sisodomain.com> Date: Fri, 4 Oct 2002 13:41:25 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: p2p subinterfaces - why ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Misha, Certain protocols cannot be supported on partially meshed networks because they require "split horizon," in which a packet received on an interface cannot be transmitted out the same interface even if the packet is received and transmitted on different VCs. Configuring subinterfaces ensures that a single physical interface is treated as multiple virtual interfaces (as pointed out by Dave). This capability allows us to overcome split horizon rules. Packets received on one virtual interface can now be forwarded out another virtual interface, even if they are configured on the same physical interface. Subinterfaces address the limitations of Frame Relay networks by providing a way to subdivide a partially meshed Frame Relay network into a number of smaller, fully meshed (or p2p) subnetworks. Each subnetwork is assigned its own network number and appears to the protocols as if it is reachable through a separate interface. Hope this helps. Regards, Manav ----- Original Message ----- From: "Misha Dovek" To: Sent: Friday, October 04, 2002 11:41 AM Subject: p2p subinterfaces - why ? | Hi, | Can anyone please give me real life usages of p2p subinterfaces? | | Misha From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 4 07:26:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28789 for ; Fri, 4 Oct 2002 07:26:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00754B6A@cherry.ease.lsoft.com>; Fri, 4 Oct 2002 7:28:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 245921 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Oct 2002 07:28:42 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 4 Oct 2002 07:28:42 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3G9T>; Fri, 4 Oct 2002 07:28:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 4 Oct 2002 07:30:50 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: another appoach to OOB LSDB Resynchronization?? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Mitchell, ;-) Well all you require, in what i said, was a SeqNumberMismatch event generated at our end and every thing else proceeds as normal. You start sending DBD's and adjacencies form. Besides the SeqNumbermismatch would not occur during normal processing(unlike the 1-way event), only during error conditions(I guess !!!). In ur case how would you manage the case if the hello u sent without the neighbor was actually dropped. There are many many cases I can think of you would need to take care of(DR election etc). Anyways I feel signalling a bit is the best/cleanest approach to do it. That way we do not change anything during normal processing of the protocol, and only when we know for sure we want an OOB resynch we do as in the draft. Thanks, Vishwas -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Friday, October 04, 2002 7:00 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: another appoach to OOB LSDB Resynchronization?? Vishwas, Vishwas, I think there is significantly more work in your implimentation than doing what I suggested. *** My approach is to fit within the understanding of the OSPF protocol. And was a "clean slate appoach". The temporarily dropping the neighbor field and moving to 1-way suggestion is to fit into the original concept of the neighbor state machine. This is a neighbor state machine event. Once that particular hello PDU is sent, the next hello would then include the "missing neighbor field". This again is another neighbor state machine event. Due to the fact, that I have assumed that full adjacency has already been reached, then the retransmit and the requests lists should be empty. Yes, the neighbor timers will restart, etc.. However, any neighbor state other than full state should be applicable for this type of change. Via the state machine, we should then be able to exchange Database Description packets. We then can build whatever lists that are then required via our normal process to re-synch the our LSDBs. *** All of this was to suggest there is no reason to consume a option bit for the reason of the draft RFC. One reason why might want to resync?? Lets say we have one or more DNA LSAs that were originated by someone else. I have seen corruption on one or more of these LSAs and don't want to wait until the removed LSAs could possilby be re-flooded. Mitchell Erblich =============== "Manral, Vishwas" wrote: > > Hi Mitchell, > > The draft is an individual submission and is located at > http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-01.txt > > I am however not too sure how you intend to achieve LSDB resynch without > changing the topology view of the network, because when we get a 1-way > received event we clear all the LS Retransmit List, DB summary list and Link > state request list and goto "Init" state. Are you saying we dont handle the > 1-way received event at all? How will the neighbor know when its doing LSDB > resynch and when its not? I would be averse to any change in the FSM though. > > A much simpler way to force an LSDB synch however would be to simply start > DB exchange by sending DBD packets with the init bit set(SeqNumberMismatch > event). This would bring the adjacencies to Exstart state(and not to Init as > it would in case of 1-way received), however the topology data would change. > We could as well not change topology if we get SeqNumberMismatch in all > cases for the SeqNumberMismatch event, however I think it would be a major > deviation from the OSPF protocol. > > Thanks, > Vishwas > > -----Original Message----- > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > Sent: Tuesday, October 01, 2002 11:16 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: another appoach to OOB LSDB Resynchronization?? > > Group, > > I haven't seen whether last year's RFC on Out-of-band > LSDB Resynchronization draft had been formalized into a > standardized RFC. > > So these comments may be way late, with this > different approach to perform LSDB Resynchronization. > > I haven't tried this .... but in my mind this > method could accomplish the same thing with > legacy routers and remove the need for a > option bit which is becoming a scarse thing > in version 2. And be a lightweight mechanism. > > Since the neighbor field in a hello PDU is the > normal indicator of 2-way communication, why > not just temporarily drop the neighbor field > of the adjacency that you wish to re-establish? > > Yes, I am assuming that based on your internal > request to perform this operation you reset > your neighbor state machine and set a internal > "OOB request neighbor field flag". > > At best you can re-establish the link on average > of 1/2 hello interval and at worst you will have > to wait router-dead-interval timeframe before > you re-acknowledge the arrival of hellos from > the neighbor that you wish resync the adjacency. > (or wait before you resend hellos?) > > The preference is to just with-hold the neighbor > from the neighbor field. This would allow the > OOB requester to remain as a DR or BDR if that > was his orignal router OSPF type. This would > remove any necessary overhead of elections, > adjacency reformations, and substantial SPF > calculations. > > Then the question is how to utilize the flag > to make sure that you don't deallocate any > neighbor data structures and whether you increment > the sequence number of your orignated LSAs, > keep them the same, or set MAXAGE and then resend. > More than likely you will also have to withold > flooding to the neighbor or acks back to the > neighbor from his flooding of LSAs. If LSAs were > recv'ed from the neighbor during flooding, I would > probably incorporate them into my LSDB. > > Independent of how you deal with the above issues, > you then must re-attempt to synchronize the LSDB. > Assuming that their were more than two OSPF speaking > routers in your area, your previous interaction should > have minimal effects on your neighbor. More than > likely, he had kept your earlier originated LSAs > in his database. And you just resync, upon reaching > full state again with the neighbor, you clear your > internal "OOB request neighbor field flag". > > Is there a dual-behaviour (one who wants to redo the > initial LSDB synchronization and one who keeps the > established adj) achieved by establishing > a adjacency and then removing the neighbor specified > in the hello field that really requires the > OOB requestor in the scenario to cycle into a > period of router-dead-interval before sending out > new hellos AND ... ???? > > Flames now allowed.... > > Mitchell Erblich > ========================== From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 4 09:21:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02782 for ; Fri, 4 Oct 2002 09:21:32 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00755299@cherry.ease.lsoft.com>; Fri, 4 Oct 2002 9:23:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 246290 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Oct 2002 09:23:29 -0400 Received: from 216.136.173.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 4 Oct 2002 09:23:29 -0400 Received: from [203.200.20.226] by web12404.mail.yahoo.com via HTTP; Fri, 04 Oct 2002 06:23:30 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20021004132330.53489.qmail@web12404.mail.yahoo.com> Date: Fri, 4 Oct 2002 06:23:30 -0700 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: Re: p2p subinterfaces - why ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list | smaller, fully meshed (or p2p) subnetworks. Each subnetwork is assigned its | own network number and appears to the protocols as if it is reachable | through a separate interface. Does this imply that we generate same LSAs for each separate subinterface? -- Rohit __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 4 12:26:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11792 for ; Fri, 4 Oct 2002 12:26:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00755C1A@cherry.ease.lsoft.com>; Fri, 4 Oct 2002 12:28:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 246852 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Oct 2002 12:28:06 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 4 Oct 2002 12:28:06 -0400 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g94GS5m24268 for ; Fri, 4 Oct 2002 09:28:06 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id g94GS5p26862; Fri, 4 Oct 2002 09:28:05 -0700 (PDT) (envelope-from dkatz@cirrus.juniper.net) References: <200210010028.RAA09446@shah.iprg.nokia.com> <065401c26919$bb3c8640$b4036c6b@sisodomain.com> <200210011617.g91GHAM17414@cirrus.juniper.net> <096701c26abb$9f8928b0$b4036c6b@sisodomain.com> <200210031652.g93GqIm23408@cirrus.juniper.net> <143101c26b6c$e82d0620$b4036c6b@sisodomain.com> Message-ID: <200210041628.g94GS5p26862@cirrus.juniper.net> Date: Fri, 4 Oct 2002 09:28:05 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: p2p subinterfaces - why ? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <143101c26b6c$e82d0620$b4036c6b@sisodomain.com> (message from Misha Dovek on Fri, 4 Oct 2002 11:41:36 +0530) Precedence: list Every large ISP that I know of uses them. Hi, Can anyone please give me real life usages of p2p subinterfaces? Misha From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 4 17:23:18 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22803 for ; Fri, 4 Oct 2002 17:23:18 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00756795@cherry.ease.lsoft.com>; Fri, 4 Oct 2002 17:25:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 247571 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Oct 2002 17:25:17 -0400 Received: from 207.217.120.232 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 4 Oct 2002 17:25:17 -0400 Received: from user-2ivfm5f.dialup.mindspring.com ([165.247.216.175] helo=earthlink.net) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17xZwf-0000Np-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 04 Oct 2002 14:25:13 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D9E0A67.233F7D93@earthlink.net> Date: Fri, 4 Oct 2002 14:38:47 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: another appoach to OOB LSDB Resynchronization?? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vishwas, If he drops the hello then it still works, because.. Is your DD being sent a one time or on a periodic basis? By the local router transiting back to 2-way, then I will be sending a DD packet if that neighbor should form a FULL adjacency. The local router will by its normal algorithms will determine whether a adj should be formed. The amount of code to implement this feature is less than 10 lines other than the CLI interface. And it works with less than 1 hour of work. The logic to stay as a DR or BDR is that it would assert its past declaration If a router booted up subsequently with a higher priority, a priority boost could be enabled. What interface or neighbor event specific allows you to just send a DD packet? What state would you be in to send your DD packet? How do you legally/ via the OSPF RFC get into this state? What happens if you are in the down state? Mitchell Erblich ========================= "Manral, Vishwas" wrote: > > Hi Mitchell, > > ;-) Well all you require, in what i said, was a SeqNumberMismatch event > generated at our end and every thing else proceeds as normal. You start > sending DBD's and adjacencies form. Besides the SeqNumbermismatch would not > occur during normal processing(unlike the 1-way event), only during error > conditions(I guess !!!). > > In ur case how would you manage the case if the hello u sent without the > neighbor was actually dropped. There are many many cases I can think of you > would need to take care of(DR election etc). > > Anyways I feel signalling a bit is the best/cleanest approach to do it. That > way we do not change anything during normal processing of the protocol, and > only when we know for sure we want an OOB resynch we do as in the draft. > > Thanks, > Vishwas > > -----Original Message----- > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > Sent: Friday, October 04, 2002 7:00 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: another appoach to OOB LSDB Resynchronization?? > > Vishwas, > > Vishwas, I think there is significantly more work in your > implimentation than doing what I suggested. > > *** My approach is to fit within the > understanding of the OSPF protocol. > > And was a "clean slate appoach". > > The temporarily dropping the neighbor field > and moving to 1-way suggestion is to fit into > the original concept of the neighbor state > machine. > > This is a neighbor state machine event. > > Once that particular hello PDU is sent, the > next hello would then include the "missing > neighbor field". > > This again is another neighbor state machine > event. > > Due to the fact, that I have assumed that full > adjacency has already been reached, then the > retransmit and the requests lists should be > empty. Yes, the neighbor timers will restart, etc.. > > However, any neighbor state other than full > state should be applicable for this type of > change. > > Via the state machine, we should then be able > to exchange Database Description packets. We then > can build whatever lists that are then required > via our normal process to re-synch the our > LSDBs. > > *** All of this was to suggest > there is no reason to consume a option bit for > the reason of the draft RFC. > > One reason why might want to resync?? Lets say > we have one or more DNA LSAs that were originated > by someone else. I have seen corruption on > one or more of these LSAs and don't want to wait > until the removed LSAs could possilby be re-flooded. > > Mitchell Erblich > =============== > > "Manral, Vishwas" wrote: > > > > Hi Mitchell, > > > > The draft is an individual submission and is located at > > http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-01.txt > > > > I am however not too sure how you intend to achieve LSDB resynch without > > changing the topology view of the network, because when we get a 1-way > > received event we clear all the LS Retransmit List, DB summary list and > Link > > state request list and goto "Init" state. Are you saying we dont handle > the > > 1-way received event at all? How will the neighbor know when its doing > LSDB > > resynch and when its not? I would be averse to any change in the FSM > though. > > > > A much simpler way to force an LSDB synch however would be to simply start > > DB exchange by sending DBD packets with the init bit set(SeqNumberMismatch > > event). This would bring the adjacencies to Exstart state(and not to Init > as > > it would in case of 1-way received), however the topology data would > change. > > We could as well not change topology if we get SeqNumberMismatch in all > > cases for the SeqNumberMismatch event, however I think it would be a major > > deviation from the OSPF protocol. > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > > Sent: Tuesday, October 01, 2002 11:16 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: another appoach to OOB LSDB Resynchronization?? > > > > Group, > > > > I haven't seen whether last year's RFC on Out-of-band > > LSDB Resynchronization draft had been formalized into a > > standardized RFC. > > > > So these comments may be way late, with this > > different approach to perform LSDB Resynchronization. > > > > I haven't tried this .... but in my mind this > > method could accomplish the same thing with > > legacy routers and remove the need for a > > option bit which is becoming a scarse thing > > in version 2. And be a lightweight mechanism. > > > > Since the neighbor field in a hello PDU is the > > normal indicator of 2-way communication, why > > not just temporarily drop the neighbor field > > of the adjacency that you wish to re-establish? > > > > Yes, I am assuming that based on your internal > > request to perform this operation you reset > > your neighbor state machine and set a internal > > "OOB request neighbor field flag". > > > > At best you can re-establish the link on average > > of 1/2 hello interval and at worst you will have > > to wait router-dead-interval timeframe before > > you re-acknowledge the arrival of hellos from > > the neighbor that you wish resync the adjacency. > > (or wait before you resend hellos?) > > > > The preference is to just with-hold the neighbor > > from the neighbor field. This would allow the > > OOB requester to remain as a DR or BDR if that > > was his orignal router OSPF type. This would > > remove any necessary overhead of elections, > > adjacency reformations, and substantial SPF > > calculations. > > > > Then the question is how to utilize the flag > > to make sure that you don't deallocate any > > neighbor data structures and whether you increment > > the sequence number of your orignated LSAs, > > keep them the same, or set MAXAGE and then resend. > > More than likely you will also have to withold > > flooding to the neighbor or acks back to the > > neighbor from his flooding of LSAs. If LSAs were > > recv'ed from the neighbor during flooding, I would > > probably incorporate them into my LSDB. > > > > Independent of how you deal with the above issues, > > you then must re-attempt to synchronize the LSDB. > > Assuming that their were more than two OSPF speaking > > routers in your area, your previous interaction should > > have minimal effects on your neighbor. More than > > likely, he had kept your earlier originated LSAs > > in his database. And you just resync, upon reaching > > full state again with the neighbor, you clear your > > internal "OOB request neighbor field flag". > > > > Is there a dual-behaviour (one who wants to redo the > > initial LSDB synchronization and one who keeps the > > established adj) achieved by establishing > > a adjacency and then removing the neighbor specified > > in the hello field that really requires the > > OOB requestor in the scenario to cycle into a > > period of router-dead-interval before sending out > > new hellos AND ... ???? > > > > Flames now allowed.... > > > > Mitchell Erblich > > ========================== From owner-ospf@DISCUSS.MICROSOFT.COM Sat Oct 5 02:33:02 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10666 for ; Sat, 5 Oct 2002 02:33:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00757838@cherry.ease.lsoft.com>; Sat, 5 Oct 2002 2:35:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 248783 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 5 Oct 2002 02:35:01 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 5 Oct 2002 02:35:01 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H321V>; Sat, 5 Oct 2002 02:35:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sat, 5 Oct 2002 02:36:45 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: another appoach to OOB LSDB Resynchronization?? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Mitchell, If u generate the SeqNumberMismatch event at ur end DB description packet is sent from ur end as usual and retransmissions etc happen as usual, you dont require any special mechanism for that. Also the event only occurs in case of error, so it could be interpreted to mean an OOB synch. If something can be done without sending hellos as you said(even if hellos were dropped it would still work), then why send it(wrong hello) at all. ;-) Anyway I guess the discussion isn't of much value to others, so let us stop it here. However if u have doubts you can mail me in private. Thanks, Vishwas -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Saturday, October 05, 2002 3:09 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: another appoach to OOB LSDB Resynchronization?? Vishwas, If he drops the hello then it still works, because.. Is your DD being sent a one time or on a periodic basis? By the local router transiting back to 2-way, then I will be sending a DD packet if that neighbor should form a FULL adjacency. The local router will by its normal algorithms will determine whether a adj should be formed. The amount of code to implement this feature is less than 10 lines other than the CLI interface. And it works with less than 1 hour of work. The logic to stay as a DR or BDR is that it would assert its past declaration If a router booted up subsequently with a higher priority, a priority boost could be enabled. What interface or neighbor event specific allows you to just send a DD packet? What state would you be in to send your DD packet? How do you legally/ via the OSPF RFC get into this state? What happens if you are in the down state? Mitchell Erblich ========================= "Manral, Vishwas" wrote: > > Hi Mitchell, > > ;-) Well all you require, in what i said, was a SeqNumberMismatch event > generated at our end and every thing else proceeds as normal. You start > sending DBD's and adjacencies form. Besides the SeqNumbermismatch would not > occur during normal processing(unlike the 1-way event), only during error > conditions(I guess !!!). > > In ur case how would you manage the case if the hello u sent without the > neighbor was actually dropped. There are many many cases I can think of you > would need to take care of(DR election etc). > > Anyways I feel signalling a bit is the best/cleanest approach to do it. That > way we do not change anything during normal processing of the protocol, and > only when we know for sure we want an OOB resynch we do as in the draft. > > Thanks, > Vishwas > > -----Original Message----- > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > Sent: Friday, October 04, 2002 7:00 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: another appoach to OOB LSDB Resynchronization?? > > Vishwas, > > Vishwas, I think there is significantly more work in your > implimentation than doing what I suggested. > > *** My approach is to fit within the > understanding of the OSPF protocol. > > And was a "clean slate appoach". > > The temporarily dropping the neighbor field > and moving to 1-way suggestion is to fit into > the original concept of the neighbor state > machine. > > This is a neighbor state machine event. > > Once that particular hello PDU is sent, the > next hello would then include the "missing > neighbor field". > > This again is another neighbor state machine > event. > > Due to the fact, that I have assumed that full > adjacency has already been reached, then the > retransmit and the requests lists should be > empty. Yes, the neighbor timers will restart, etc.. > > However, any neighbor state other than full > state should be applicable for this type of > change. > > Via the state machine, we should then be able > to exchange Database Description packets. We then > can build whatever lists that are then required > via our normal process to re-synch the our > LSDBs. > > *** All of this was to suggest > there is no reason to consume a option bit for > the reason of the draft RFC. > > One reason why might want to resync?? Lets say > we have one or more DNA LSAs that were originated > by someone else. I have seen corruption on > one or more of these LSAs and don't want to wait > until the removed LSAs could possilby be re-flooded. > > Mitchell Erblich > =============== > > "Manral, Vishwas" wrote: > > > > Hi Mitchell, > > > > The draft is an individual submission and is located at > > http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-01.txt > > > > I am however not too sure how you intend to achieve LSDB resynch without > > changing the topology view of the network, because when we get a 1-way > > received event we clear all the LS Retransmit List, DB summary list and > Link > > state request list and goto "Init" state. Are you saying we dont handle > the > > 1-way received event at all? How will the neighbor know when its doing > LSDB > > resynch and when its not? I would be averse to any change in the FSM > though. > > > > A much simpler way to force an LSDB synch however would be to simply start > > DB exchange by sending DBD packets with the init bit set(SeqNumberMismatch > > event). This would bring the adjacencies to Exstart state(and not to Init > as > > it would in case of 1-way received), however the topology data would > change. > > We could as well not change topology if we get SeqNumberMismatch in all > > cases for the SeqNumberMismatch event, however I think it would be a major > > deviation from the OSPF protocol. > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > > Sent: Tuesday, October 01, 2002 11:16 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: another appoach to OOB LSDB Resynchronization?? > > > > Group, > > > > I haven't seen whether last year's RFC on Out-of-band > > LSDB Resynchronization draft had been formalized into a > > standardized RFC. > > > > So these comments may be way late, with this > > different approach to perform LSDB Resynchronization. > > > > I haven't tried this .... but in my mind this > > method could accomplish the same thing with > > legacy routers and remove the need for a > > option bit which is becoming a scarse thing > > in version 2. And be a lightweight mechanism. > > > > Since the neighbor field in a hello PDU is the > > normal indicator of 2-way communication, why > > not just temporarily drop the neighbor field > > of the adjacency that you wish to re-establish? > > > > Yes, I am assuming that based on your internal > > request to perform this operation you reset > > your neighbor state machine and set a internal > > "OOB request neighbor field flag". > > > > At best you can re-establish the link on average > > of 1/2 hello interval and at worst you will have > > to wait router-dead-interval timeframe before > > you re-acknowledge the arrival of hellos from > > the neighbor that you wish resync the adjacency. > > (or wait before you resend hellos?) > > > > The preference is to just with-hold the neighbor > > from the neighbor field. This would allow the > > OOB requester to remain as a DR or BDR if that > > was his orignal router OSPF type. This would > > remove any necessary overhead of elections, > > adjacency reformations, and substantial SPF > > calculations. > > > > Then the question is how to utilize the flag > > to make sure that you don't deallocate any > > neighbor data structures and whether you increment > > the sequence number of your orignated LSAs, > > keep them the same, or set MAXAGE and then resend. > > More than likely you will also have to withold > > flooding to the neighbor or acks back to the > > neighbor from his flooding of LSAs. If LSAs were > > recv'ed from the neighbor during flooding, I would > > probably incorporate them into my LSDB. > > > > Independent of how you deal with the above issues, > > you then must re-attempt to synchronize the LSDB. > > Assuming that their were more than two OSPF speaking > > routers in your area, your previous interaction should > > have minimal effects on your neighbor. More than > > likely, he had kept your earlier originated LSAs > > in his database. And you just resync, upon reaching > > full state again with the neighbor, you clear your > > internal "OOB request neighbor field flag". > > > > Is there a dual-behaviour (one who wants to redo the > > initial LSDB synchronization and one who keeps the > > established adj) achieved by establishing > > a adjacency and then removing the neighbor specified > > in the hello field that really requires the > > OOB requestor in the scenario to cycle into a > > period of router-dead-interval before sending out > > new hellos AND ... ???? > > > > Flames now allowed.... > > > > Mitchell Erblich > > ========================== From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 7 20:16:06 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10907 for ; Mon, 7 Oct 2002 20:16:06 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0075D2AA@cherry.ease.lsoft.com>; Mon, 7 Oct 2002 20:18:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 257732 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Oct 2002 20:18:04 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 7 Oct 2002 20:18:03 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g980I3m32579 for ; Mon, 7 Oct 2002 17:18:03 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g980I3Z97797 for ospf@discuss.microsoft.com; Mon, 7 Oct 2002 17:18:03 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210080018.g980I3Z97797@kummer.juniper.net> Date: Mon, 7 Oct 2002 17:18:03 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi All, I've just posted draft-kompella-ospf-opaquev2-00.txt that takes six pages to say "if you see an OSPF v3 LSA with Function Code 10, treat it as you would an OSPF v2 Opaque LSA". Comments actively solicited, at least until the negative ones roll in :-) The main goal is code reuse between v2 and v3; if that isn't achieved, I'd be interested in knowing why, and how it might be fixed. Kireeti. ------- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 7 21:12:42 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12356 for ; Mon, 7 Oct 2002 21:12:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0075D334@cherry.ease.lsoft.com>; Mon, 7 Oct 2002 21:14:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 257921 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Oct 2002 21:14:43 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 7 Oct 2002 21:14:43 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17yixO-0003PT-00; Mon, 07 Oct 2002 18:14:42 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <200210080018.g980I3Z97797@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <198381275605.20021007181234@psg.com> Date: Mon, 7 Oct 2002 18:12:34 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: Kireeti Kompella To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210080018.g980I3Z97797@kummer.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Kireeti, Hard to talk without seeing the draft, but what problem is it trying to address? I mean, we already have a more generic "opaque"-like mechanism in OSPFv3, why is it not enough? -- Alex Monday, October 07, 2002, 5:18:03 PM, Kireeti Kompella wrote: > Hi All, > I've just posted draft-kompella-ospf-opaquev2-00.txt that takes > six pages to say "if you see an OSPF v3 LSA with Function Code 10, > treat it as you would an OSPF v2 Opaque LSA". > Comments actively solicited, at least until the negative ones roll in :-) > The main goal is code reuse between v2 and v3; if that isn't achieved, > I'd be interested in knowing why, and how it might be fixed. > Kireeti. > ------- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 7 21:30:46 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12711 for ; Mon, 7 Oct 2002 21:30:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0075D23B@cherry.ease.lsoft.com>; Mon, 7 Oct 2002 21:32:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 257986 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Oct 2002 21:32:48 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 7 Oct 2002 21:32:47 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g981Wim37618; Mon, 7 Oct 2002 18:32:44 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g981WiB98065; Mon, 7 Oct 2002 18:32:44 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210080132.g981WiB98065@kummer.juniper.net> Date: Mon, 7 Oct 2002 18:32:44 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: zinin@psg.com To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <198381275605.20021007181234@psg.com> Precedence: list Hi Alex, > Hard to talk without seeing the draft, but what problem > is it trying to address? I mean, we already have a more > generic "opaque"-like mechanism in OSPFv3, why is it not > enough? True, we have a generic opaque mechanism in OSPF v3. However, if I want to do TE in OSPF v3, what do I put in the packet to let you know that this is a TE LSA? In particular, what function code do I put in the LSA? Should there be a new function code for each 'legacy' Opaque LSA? Etc. The draft (see below, sorry all for the spam) just grabs a single LSA function code for 'OSPF v2 Opaque LSAs', but otherwise keeps everything mostly the same. Take a look -- fortunately, it shouldn't take more than a couple of minutes :-) Kireeti. ------- Network Working Group K. Kompella Internet Draft Juniper Networks Updates: 2740 October 2002 Category: Standards Track Expires: April 2003 OSPFv2 Opaque LSAs in OSPFv3 draft-kompella-ospf-opaquev2-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo specifies how OSPF version 2 Opaque Link State Advertisements can be carried in OSPF version 3. Kompella Standards Track [Page 1] Internet Draft OSPFv2 Opaque LSAs in OSPFv3 October 2002 1. Introduction RFC 2370 [OPAQUE] describes the notion of an "opaque" Link State Advertisement (LSA) -- as the RFC says, an LSA that provides "a generalized mechanism to allow for the future extensibility of OSPF". This has certainly proved useful, for example in defining Grace LSAs [HITLESS] and OSPF v2 Traffic Engineering LSAs [OSPF-TE]. RFC 2370 also defines the format that opaque LSAs take in OSPF version 2 [OSPFv2], and defines three flooding scopes for such LSAs: link-local, area-local and Autonomous System (AS)-wide. OSPF version 3 [OSPFv3] inherently supports the notion of opaque LSAs in that the flooding scope of an LSA is explicitly stated in the LSA header. OSPF v3 also specifies how LSAs with unrecognized function codes are to be handled. This memo specifies how OSPF version 2 opaque LSAs can be carried in OSPF version 3. This allows the reuse of the specifications of OSPF v2 Opaque LSAs, as well as the code to support them, in OSPF v3. In a nutshell, an OSPF v3 LS Function Code is defined to indicate that the LSA is of type OSPF v2 Opaque LSAs; the OSPF v3 Link State ID is formatted the same as in the OSPF v2 Opaque LSA; and the body of the OSPF v3 LSA is identical to the body of the OSPF v2 Opaque LSA. 2. Opaque LSAs An Opaque LSA in OSPF v2 is formatted as follows [OPAQUE, A.2]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | LS Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Opaque Information | + + | ... | Kompella Standards Track [Page 2] Internet Draft OSPFv2 Opaque LSAs in OSPFv3 October 2002 The LS Type is 9, 10, or 11 depending on whether the Opaque LSA's flooding scope is link-local, area-local or AS-wide (respectively). The above OSPF v2 Opaque LSA is formatted as follows as an OSPF v3 LSA: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |1|X|Y| OSPFv2 Opaque LSA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Opaque Information | + + | ... | The U bit in the LS Type is set to 1. The LS Function Code is set to 10 [to be ratified by the OSPF WG], indicating that the LSA type is 'OSPF v2 Opaque LSA'. The XY bits are set to reflect the flooding scope: OSPFv2 Opaque LSA of LS Type X Y -------------- --- 9 0 0 10 0 1 11 1 0 The OSPF v3 LSA's Link State ID is formatted as one octet of Opaque Type, and 3 octets of Opaque ID (i.e., exactly as the Link State ID of the OSPF v2 Opaque LSA). The body of the OSPF v3 LSA is octet-for-octet identical to the OSPF v2 Opaque Information. Kompella Standards Track [Page 3] Internet Draft OSPFv2 Opaque LSAs in OSPFv3 October 2002 2.1. Processing OSPF v2 Opaque LSAs An OSPF v3 implementation encountering an LSA of type 'OSPF v2 Opaque LSA' MUST follow the rules regarding handling and flooding as defined by the U and XY bits, as defined in [OSPFv3]. In addition, an OSPF v3 implementation MAY further process an OSPF v2 Opaque LSA as an OSPF v2 implementation would, e.g., it might use a Grace-LSA to accomplish (or assist in) hitless restart of OSPF v3; or it might build a Traffic Engineering database using the opaque TE LSAs. It is the intent of this memo to maximize code (and specification) reuse between OSPF v2 and OSPF v3 in this regard. Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998 [OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998 [OSPFv3] Coltun, R., D. Ferguson, and J. Moy, "OSPF for IPv6", RFC 2740, December 1999 Informative References [HITLESS] Moy, J., "Hitless OSPF Restart", work in progress [OSPF-TE] Katz, D., D. Yeung, and K. Kompella, "Traffic Engineering Extensions to OSPF Version 2", work in progress Security Considerations The flooding and handling of LSAs has already been specified in the [OSPFv3]; this memo only defines a new LS Function Code, and the format of the LS body. The OSPF v3 security mechanisms to prevent tampering and spoofing of LSAs suffice. Kompella Standards Track [Page 4] Internet Draft OSPFv2 Opaque LSAs in OSPFv3 October 2002 Acknowledgments Many thanks to Quaizar Vohra, with whom much of this was discussed. Authors' Addresses Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave Sunnyvale, CA 94089 Email: kireeti@juniper.net IPR Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Kompella Standards Track [Page 5] Internet Draft OSPFv2 Opaque LSAs in OSPFv3 October 2002 Full Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kompella Standards Track [Page 6] From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 7 22:14:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14071 for ; Mon, 7 Oct 2002 22:14:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0075D49C@cherry.ease.lsoft.com>; Mon, 7 Oct 2002 22:16:12 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 258127 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Oct 2002 22:16:11 -0400 Received: from 65.223.109.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 7 Oct 2002 22:16:11 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id WAA01896 for ; Mon, 7 Oct 2002 22:19:28 -0400 References: <198381275605.20021007181234@psg.com> <200210080132.g981WiB98065@kummer.juniper.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Mon, 7 Oct 2002 19:19:28 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210080132.g981WiB98065@kummer.juniper.net> Precedence: list >True, we have a generic opaque mechanism in OSPF v3. However, >if I want to do TE in OSPF v3, what do I put in the packet to let >you know that this is a TE LSA? In particular, what function code >do I put in the LSA? Should there be a new function code for each >'legacy' Opaque LSA? Etc. > >The draft (see below, sorry all for the spam) just grabs a single >LSA function code for 'OSPF v2 Opaque LSAs', but otherwise keeps >everything mostly the same. I'm resending thie mail...I send from wrong from address....so you may receive two mail. BTW I haven't submitted the draft but I prepared TE extensions to OSPFv3. I just define a new LS type for TE then use OSPFv3 built in flooding mechanism. I believe this is straight forward way to do it. -- Kunihiro Ishiguro Network Working Group K. Ishiguro Internet Draft IP Infusion Inc. Expiration Date: May 2003 T. Takada IP Infusion Inc. October 2002 Traffic Engineering Extensions to OSPF version 3 draft-ishiguro-ospf-ospfv3-traffic-00.txt ... 2. Applicability OSPFv3 has a very flexible mechanism for adding new LS type. Even the implementation does not know the LS types, the LSA is properly flooded by LS type field. This document add a new LSA type Traffic Engineering LSA to OSPFv3. 3. Traffic-Engineering-LSA New LSA Traffic-Engineering-LSA is introduced. 3.1 LS Type Traffic-Engineering-LSA is defined as Area scope LSA. LSA function code LS Type Description -------------------------------------------------------------------- 10 0x2000a Traffic-Engineering-LSA 3.2 LSA Format Overview This is LSA header format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |0|0|1| 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3 TLV Header The LSA payload consists of one or more nested Type/Length/Value .... From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 7 22:56:29 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15777 for ; Mon, 7 Oct 2002 22:56:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0075D749@cherry.ease.lsoft.com>; Mon, 7 Oct 2002 22:58:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 258241 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Oct 2002 22:58:31 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 7 Oct 2002 22:58:30 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g982wUm43538 for ; Mon, 7 Oct 2002 19:58:30 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g982wUg98298 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Oct 2002 19:58:30 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210080258.g982wUg98298@kummer.juniper.net> Date: Mon, 7 Oct 2002 19:58:30 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi Kunihiro, > BTW I haven't submitted the draft but I prepared TE extensions to > OSPFv3. I just define a new LS type for TE then use OSPFv3 built in > flooding mechanism. I believe this is straight forward way to do it. The draft I submitted also uses the OSPFv3 built in flooding. It is the only way to do it. > LSA function code LS Type Description > -------------------------------------------------------------------- > 10 0x2000a Traffic-Engineering-LSA Do you plan to have a different Function Code for each OSPFv2 Opaque LSA Type? It seems to me to be much easier to have a single code point for all OSPFv2 Opaque LSAs. This way, all defined OSPFv2 Opaque LSAs get automatically defined in v3; moreover, if a new Opaque LSA seems to be useful for both v2 and v3, it can be defined as an OSPFv2 Opaque LSA. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 7 23:16:57 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16249 for ; Mon, 7 Oct 2002 23:16:57 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0075DC60@cherry.ease.lsoft.com>; Mon, 7 Oct 2002 23:19:01 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 258402 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Oct 2002 23:19:00 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 7 Oct 2002 23:19:00 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 4FA364BA216 for ; Mon, 7 Oct 2002 20:18:59 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210080258.g982wUg98298@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA24EB1.6040800@redback.com> Date: Mon, 7 Oct 2002 23:19:13 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kireeti Kompella wrote: > Hi Kunihiro, > > >>BTW I haven't submitted the draft but I prepared TE extensions to >>OSPFv3. I just define a new LS type for TE then use OSPFv3 built in >>flooding mechanism. I believe this is straight forward way to do it. >> > > The draft I submitted also uses the OSPFv3 built in flooding. It is the > only way to do it. > > >> LSA function code LS Type Description >> -------------------------------------------------------------------- >> 10 0x2000a Traffic-Engineering-LSA Kunihiro, Believe you mean 0x200a. >> > > Do you plan to have a different Function Code for each OSPFv2 Opaque LSA > Type? Kiretti, If you take into account changes to the LS type for OSPFv3, the code points are compatible. For OSPFv3, the LS Type is 16 bits (versus 8 for OSPFv2) and it contains the flooding scope and a bit indicating what to do with unrecognized types. There are no LS type collisions pervent use of the same function codes. OSPFv2 OSPFv3 Link Scoped Opaque LSAs 0x09 0x0009 Area Scoped Opaque LSAs 0x0a 0x200a AS Scoped Opaque LSAs 0x0b 0x400b One could argue that the functions types for area and AS scoped opaque LSAs should be 0xa00a and 0xc00b as well. This would indicate that a router that does not recognize the type should store and flood it anyway. Any strong feelings on this? Thanks, Acee > > It seems to me to be much easier to have a single code point for all > OSPFv2 Opaque LSAs. This way, all defined OSPFv2 Opaque LSAs get > automatically defined in v3; moreover, if a new Opaque LSA seems to be > useful for both v2 and v3, it can be defined as an OSPFv2 Opaque LSA. > > Kireeti. > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 7 23:28:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16511 for ; Mon, 7 Oct 2002 23:28:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0075DD4E@cherry.ease.lsoft.com>; Mon, 7 Oct 2002 23:30:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 258471 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Oct 2002 23:30:27 -0400 Received: from 64.139.11.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 7 Oct 2002 23:30:27 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id XAA00728; Mon, 7 Oct 2002 23:33:41 -0400 References: <200210080258.g982wUg98298@kummer.juniper.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Mon, 7 Oct 2002 20:33:41 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: Kireeti Kompella To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210080258.g982wUg98298@kummer.juniper.net> Precedence: list >The draft I submitted also uses the OSPFv3 built in flooding. It is the >only way to do it. Exactly. My point is opaque capability is already provided in OSPFv3. So there is no benefit to export OSPFv2 opaque capability in OSPFv3. >Do you plan to have a different Function Code for each OSPFv2 Opaque LSA >Type? Yes. IHMO, it should be. For example TE case, we can't apply OSPFv2 TE as it is in OSPFv3. For Local interface IP address and Remote interface IP address should be treated IPv6 address not IPv4 address. So I have in my draft (sorry for referring non published draft...): 3 - Local interface IP address (16N octets) 4 - Remote interface IP address (16N octets) You can easily imagine there are some difference between OSPFv2 TE and OSPFv3 TE. And if we mask U,S2,S1 bit, LSA Function Code 9 is alredy assingned to Intra-Area-Prefix-LSA.... This is another concern... >It seems to me to be much easier to have a single code point for all >OSPFv2 Opaque LSAs. This way, all defined OSPFv2 Opaque LSAs get >automatically defined in v3; moreover, if a new Opaque LSA seems to be >useful for both v2 and v3, it can be defined as an OSPFv2 Opaque LSA. I think it is not realistic that applying OSPFv2 Opaque LSA to OSPFv3 verbatim. We should define each LS type and it's packet format. When OSPFv2 Opaque LSA can be introduced to OSPFv3 without any change, let's just define type code. It is not a big effort. -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 03:28:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02558 for ; Tue, 8 Oct 2002 03:28:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0075E6C9@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 3:30:49 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 259123 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 03:30:48 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 03:30:48 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g987Umm53943 for ; Tue, 8 Oct 2002 00:30:48 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g987UmD98894 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 00:30:48 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210080730.g987UmD98894@kummer.juniper.net> Date: Tue, 8 Oct 2002 00:30:48 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DA24EB1.6040800@redback.com> Precedence: list > If you take into account changes to the LS type for OSPFv3, the code points > are compatible. For OSPFv3, the LS Type is 16 bits (versus 8 for OSPFv2) and it > contains the flooding scope and a bit indicating what to do with unrecognized > types. No kidding! > There are no LS type collisions pervent use of the same function codes. I beg to differ. > OSPFv2 OSPFv3 > Link Scoped Opaque LSAs 0x09 0x0009 > > Area Scoped Opaque LSAs 0x0a 0x200a > > AS Scoped Opaque LSAs 0x0b 0x400b Where did you read this? I see in rfc 2740: LSA function code LS Type Description ---------------------------------------------------- 1 0x2001 Router-LSA 2 0x2002 Network-LSA 3 0x2003 Inter-Area-Prefix-LSA 4 0x2004 Inter-Area-Router-LSA 5 0x4005 AS-External-LSA 6 0x2006 Group-membership-LSA 7 0x2007 Type-7-LSA 8 0x0008 Link-LSA 9 0x2009 Intra-Area-Prefix-LSA which says that function code 9 represents Intra-Area Prefix LSAs; it doesn't define a function code 10 or 11. Since Function Codes are independent of flooding scope in v3, the LS types 0009, 4009 and 6009 should be interpreted as link local, AS-wide and ?? Intra-Area-Prefix LSAs, i.e., mostly nonsense. The same applies to 0001, 4001 and 6001, etc. Using the value 0009 for Link Local Opaque LSAs (i.e., requiring that the function code be interpreted *in the context of the flooding scope*) negates the entire point of separating LS function and flooding scope. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 04:36:01 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03521 for ; Tue, 8 Oct 2002 04:36:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0075E564@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 4:38:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 259300 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 04:38:03 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 04:38:03 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3L3L>; Tue, 8 Oct 2002 04:38:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 8 Oct 2002 04:40:13 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee, I would prefer we do not reuse the function code 0x9. I am wondering why we require three different function codes for OSPFv2 Opaque LSA's itself. Why can't we have one for OSPFv2 Opaque LSA's a value of 0xa instead? The flooding scope of the OSPFv2 Opaque LSA contained in such an LSA should be the same as the flooding scope of OSPFv3 LSA. So LSA type would be OSPFv2 OSPFv3 Link Scoped Opaque LSAs 0x09 0x000a Area Scoped Opaque LSAs 0x0a 0x200a AS Scoped Opaque LSAs 0x0b 0x400a Besides although setting the U-bit to 0, helps in flooding optimizations as we will not be flooding opaque LSA's across non-joint TE parts within an areas if there are some routers which do not understand this type of LSA. It may break assumption of flooding of Opaque LSA's thru out the flooding scope routers. Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Tuesday, October 08, 2002 8:49 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella wrote: > Hi Kunihiro, > > >>BTW I haven't submitted the draft but I prepared TE extensions to >>OSPFv3. I just define a new LS type for TE then use OSPFv3 built in >>flooding mechanism. I believe this is straight forward way to do it. >> > > The draft I submitted also uses the OSPFv3 built in flooding. It is the > only way to do it. > > >> LSA function code LS Type Description >> -------------------------------------------------------------------- >> 10 0x2000a Traffic-Engineering-LSA Kunihiro, Believe you mean 0x200a. >> > > Do you plan to have a different Function Code for each OSPFv2 Opaque LSA > Type? Kiretti, If you take into account changes to the LS type for OSPFv3, the code points are compatible. For OSPFv3, the LS Type is 16 bits (versus 8 for OSPFv2) and it contains the flooding scope and a bit indicating what to do with unrecognized types. There are no LS type collisions pervent use of the same function codes. OSPFv2 OSPFv3 Link Scoped Opaque LSAs 0x09 0x0009 Area Scoped Opaque LSAs 0x0a 0x200a AS Scoped Opaque LSAs 0x0b 0x400b One could argue that the functions types for area and AS scoped opaque LSAs should be 0xa00a and 0xc00b as well. This would indicate that a router that does not recognize the type should store and flood it anyway. Any strong feelings on this? Thanks, Acee > > It seems to me to be much easier to have a single code point for all > OSPFv2 Opaque LSAs. This way, all defined OSPFv2 Opaque LSAs get > automatically defined in v3; moreover, if a new Opaque LSA seems to be > useful for both v2 and v3, it can be defined as an OSPFv2 Opaque LSA. > > Kireeti. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 06:18:22 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05084 for ; Tue, 8 Oct 2002 06:18:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0075E873@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 6:20:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 259694 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 06:20:24 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 06:20:24 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3LRZ>; Tue, 8 Oct 2002 06:20:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 8 Oct 2002 06:22:36 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Kireeti, Though I agree the approach you suggest does minimize the amount of effort for the working group to get similar functionality in OSPFv3 as OSPFv2, by simply ignoring the OSPFv2 header(i.e. first 20 bytes of the payload). I prefer a cleaner approach from the protocol implementations point of view. Probably giving an LSA type to Area Scope TE LSA's and using the Link ID as instance id. I guess Spencer had tried a similar approach in the draft http://www.watersprings.org/links/mlr/id/draft-giacalone-te-optical-next-02. txt . Thanks, Vishwas -----Original Message----- From: Kireeti Kompella [mailto:kireeti@JUNIPER.NET] Sent: Tuesday, October 08, 2002 1:01 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 > If you take into account changes to the LS type for OSPFv3, the code points > are compatible. For OSPFv3, the LS Type is 16 bits (versus 8 for OSPFv2) and it > contains the flooding scope and a bit indicating what to do with unrecognized > types. No kidding! > There are no LS type collisions pervent use of the same function codes. I beg to differ. > OSPFv2 OSPFv3 > Link Scoped Opaque LSAs 0x09 0x0009 > > Area Scoped Opaque LSAs 0x0a 0x200a > > AS Scoped Opaque LSAs 0x0b 0x400b Where did you read this? I see in rfc 2740: LSA function code LS Type Description ---------------------------------------------------- 1 0x2001 Router-LSA 2 0x2002 Network-LSA 3 0x2003 Inter-Area-Prefix-LSA 4 0x2004 Inter-Area-Router-LSA 5 0x4005 AS-External-LSA 6 0x2006 Group-membership-LSA 7 0x2007 Type-7-LSA 8 0x0008 Link-LSA 9 0x2009 Intra-Area-Prefix-LSA which says that function code 9 represents Intra-Area Prefix LSAs; it doesn't define a function code 10 or 11. Since Function Codes are independent of flooding scope in v3, the LS types 0009, 4009 and 6009 should be interpreted as link local, AS-wide and ?? Intra-Area-Prefix LSAs, i.e., mostly nonsense. The same applies to 0001, 4001 and 6001, etc. Using the value 0009 for Link Local Opaque LSAs (i.e., requiring that the function code be interpreted *in the context of the flooding scope*) negates the entire point of separating LS function and flooding scope. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 10:16:05 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14492 for ; Tue, 8 Oct 2002 10:16:05 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0075EF02@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 10:17:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 260450 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 10:17:44 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 10:17:43 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id B3E534F41A9 for ; Tue, 8 Oct 2002 07:17:42 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210080730.g987UmD98894@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA2E90E.4060800@redback.com> Date: Tue, 8 Oct 2002 10:17:50 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kireeti Kompella wrote: >>If you take into account changes to the LS type for OSPFv3, the code points >>are compatible. For OSPFv3, the LS Type is 16 bits (versus 8 for OSPFv2) and it >>contains the flooding scope and a bit indicating what to do with unrecognized >>types. >> > > No kidding! > > >>There are no LS type collisions pervent use of the same function codes. >> > > I beg to differ. The collision is at different flooding scopes. Hence, the LS type is unambiguous. Since the application of the opaque LSA is specified by the Opaque type (in the first 8 bits of the link-state ID) I can't imagine how the reuse of 0x09 at different flooding scopes would pose a problem. > > >> OSPFv2 OSPFv3 >> Link Scoped Opaque LSAs 0x09 0x0009 >> >> Area Scoped Opaque LSAs 0x0a 0x200a >> >> AS Scoped Opaque LSAs 0x0b 0x400b >> > > Where did you read this? I see in rfc 2740: It was simply an extension of RFC 2370. As Vishwas proposed, OSPFv3 opaque LSAs can be implemented with a single function code. This seems to be the best solution given that the only reason for 3 types in OSPFv2 was to support different flooding scope. It also removes the collision between function codes. OSPFv2 OSPFv3 Link Scoped Opaque LSAs 0x09 0x000a Area Scoped Opaque LSAs 0x0a 0x200a AS Scoped Opaque LSAs 0x0b 0x400a As for the setting of the U bit, I think this could stand some discussion. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 10:43:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15990 for ; Tue, 8 Oct 2002 10:43:49 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0075EEFD@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 10:45:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 260559 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 10:45:44 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 10:45:44 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 594DD4BA215 for ; Tue, 8 Oct 2002 07:45:39 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA2EF9B.4010302@redback.com> Date: Tue, 8 Oct 2002 10:45:47 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: > Hi Acee, > > I would prefer we do not reuse the function code 0x9. > > I am wondering why we require three different function codes for OSPFv2 > Opaque LSA's itself. Why can't we have one for OSPFv2 Opaque LSA's a value > of 0xa instead? The flooding scope of the OSPFv2 Opaque LSA contained in > such an LSA should be the same as the flooding scope of OSPFv3 LSA. > > So LSA type would be > OSPFv2 OSPFv3 > Link Scoped Opaque LSAs 0x09 0x000a > > Area Scoped Opaque LSAs 0x0a 0x200a > > AS Scoped Opaque LSAs 0x0b 0x400a Vishwas, Completely agree. Could you put this in draft form? This is at least the second time the question of opaque LSAs and OSPFv3 has been raised. > > Besides although setting the U-bit to 0, helps in flooding optimizations as > we will not be flooding opaque LSA's across non-joint TE parts within an > areas if there are some routers which do not understand this type of LSA. It > may break assumption of flooding of Opaque LSA's thru out the flooding scope > routers. Since opaque LSA's are meant to be used for many applications and the setting of the U bit is based solely on the function code, I'm not sure that a TE specific argument is a good reason for not setting the U bit. > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, October 08, 2002 8:49 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 > > > Kireeti Kompella wrote: > > >>Hi Kunihiro, >> >> >> >>>BTW I haven't submitted the draft but I prepared TE extensions to >>>OSPFv3. I just define a new LS type for TE then use OSPFv3 built in >>>flooding mechanism. I believe this is straight forward way to do it. >>> >>> >>The draft I submitted also uses the OSPFv3 built in flooding. It is the >>only way to do it. >> >> >> >>>LSA function code LS Type Description >>>-------------------------------------------------------------------- >>>10 0x2000a Traffic-Engineering-LSA >>> > > > > Kunihiro, > > Believe you mean 0x200a. > > > > >>Do you plan to have a different Function Code for each OSPFv2 Opaque LSA >>Type? >> > > > Kiretti, > > If you take into account changes to the LS type for OSPFv3, the code points > are compatible. For OSPFv3, the LS Type is 16 bits (versus 8 for OSPFv2) and > it > contains the flooding scope and a bit indicating what to do with > unrecognized > types. There are no LS type collisions pervent use of the same function > codes. > > > OSPFv2 OSPFv3 > Link Scoped Opaque LSAs 0x09 0x0009 > > Area Scoped Opaque LSAs 0x0a 0x200a > > AS Scoped Opaque LSAs 0x0b 0x400b > > One could argue that the functions types for area and AS scoped opaque LSAs > should be 0xa00a and 0xc00b as well. This would indicate that a router that > does not recognize the type should store and flood it anyway. Any strong > feelings > on this? > > Thanks, > Acee > >>It seems to me to be much easier to have a single code point for all >>OSPFv2 Opaque LSAs. This way, all defined OSPFv2 Opaque LSAs get >>automatically defined in v3; moreover, if a new Opaque LSA seems to be >>useful for both v2 and v3, it can be defined as an OSPFv2 Opaque LSA. >> >>Kireeti. >> > -- > Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 11:00:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16985 for ; Tue, 8 Oct 2002 11:00:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0075EF86@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 10:59:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 260610 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 10:59:25 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 10:59:25 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g98ExOm75614; Tue, 8 Oct 2002 07:59:24 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g98ExOn00252; Tue, 8 Oct 2002 07:59:24 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210081459.g98ExOn00252@kummer.juniper.net> Date: Tue, 8 Oct 2002 07:59:24 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: kunihiro@zebra.org To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list > >Do you plan to have a different Function Code for each OSPFv2 Opaque LSA > >Type? > > Yes. IHMO, it should be. For example TE case, we can't apply OSPFv2 > TE as it is in OSPFv3. For Local interface IP address and Remote > interface IP address should be treated IPv6 address not IPv4 address. > > So I have in my draft (sorry for referring non published draft...): > > 3 - Local interface IP address (16N octets) > 4 - Remote interface IP address (16N octets) This approach is flawed (IMO) for a couple of reasons: a) OSPF v3 should deal with IPv4 as well as IPv6 addresses. b) The fact that a couple of simple TLVs are needed is not a good reason to reinvent the entire TE LSA. A better approach seems to be to add a couple of *new* TLVs to the v2 TE LSA for IPv6 addresses -- I suggested this to Yakov some time ago, and this will hopefully be in a forthcoming version of the GMPLS OSPF TE draft. I suspect (without seeing your draft) that you have essentially cut-and-paste the OSPF v2 TE draft. I believe that to be a flawed approach as well: it's better to copy by reference rather than by value whenever you can. The OSPFv2 TE document is constantly undergoing changes; the GMPLS extensions are one example; DiffServ TE is another; others (such as extensions for SONET and G.709) are in the works. The approach that maps OSPFv2 TE LSAs directly into OSPFv3 seems much more scalable and pragmatic -- each such extension is automatically inherited into OSPF v3 both spec-wise and code-wise. > you can easily imagine there are some difference between OSPFv2 TE and > OSPFv3 TE. I can far more readily imagine that there is a vast overlap :-) Note that the above applies equally to the Grace LSA. If you add an IPv6 TLV to the Grace LSA, it can be used pretty much as is in OSPF v3; ask Padma Pillay-Esnault for details. > And if we mask U,S2,S1 bit, LSA Function Code 9 is alredy assingned to > Intra-Area-Prefix-LSA.... This is another concern... Where in my draft do you see the use of function code 9? > I think it is not realistic that applying OSPFv2 Opaque LSA to OSPFv3 > verbatim. We should define each LS type and it's packet format. I guess we just have different viewpoints. I do not like to generate new work just for the fun of it. *Not* changing the packet format is so much more pragmatic. Note that the two approaches are not incompatible. Go ahead and define a new LS function code for OSPF v3 TE; change the packet formats; add any new TLVs you find useful; remove any TLVs you think that OSPF v3 doesn't need; move bits and bytes around. Then we'll let the market decide :-) Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 11:00:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16987 for ; Tue, 8 Oct 2002 11:00:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0075EECD@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 11:01:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 260618 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 11:01:32 -0400 Received: from 64.139.11.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 11:01:32 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id LAA00772 for ; Tue, 8 Oct 2002 11:04:19 -0400 References: <3DA2EF9B.4010302@redback.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Tue, 8 Oct 2002 08:04:19 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DA2EF9B.4010302@redback.com> Precedence: list >> Besides although setting the U-bit to 0, helps in flooding optimizations as >> we will not be flooding opaque LSA's across non-joint TE parts within an >> areas if there are some routers which do not understand this type of LSA. It >> may break assumption of flooding of Opaque LSA's thru out the flooding scope >> routers. > >Since opaque LSA's are meant to be used for many applications and the setting >of the U bit is based solely on the function code, I'm not sure that a >TE specific argument is a good reason for not setting the U bit. BTW, I still have big doubt about how many OSPFv2 Opaque LSA can be exported to OSPFv3 without any change. Almost cases, at least IPv4 address should be changed to IPv6 address. TE draft said router-id is really reachable address. But this assumption is wrong in case of IPv6 network. Before we think about exporting OSPFv2 Opaque LSA to OSPFv3, we should think about it's applicability. I've tried it both specification and implementation stand point...but from my experience unfortunately the applicability is very low... -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 11:00:11 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17003 for ; Tue, 8 Oct 2002 11:00:11 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0075EFB0@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 11:02:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 260629 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 11:02:02 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 11:02:01 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g98F21m75970 for ; Tue, 8 Oct 2002 08:02:01 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g98F21A00272 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 08:02:01 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210081502.g98F21A00272@kummer.juniper.net> Date: Tue, 8 Oct 2002 08:02:01 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi Vishwas, > So LSA type would be > OSPFv2 OSPFv3 > Link Scoped Opaque LSAs 0x09 0x000a > > Area Scoped Opaque LSAs 0x0a 0x200a > > AS Scoped Opaque LSAs 0x0b 0x400a You've just summarized my draft :-) Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 11:13:38 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17603 for ; Tue, 8 Oct 2002 11:13:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0075EF8D@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 11:15:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 260735 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 11:15:42 -0400 Received: from 64.139.11.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 11:15:41 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id LAA00791; Tue, 8 Oct 2002 11:18:56 -0400 References: <200210081459.g98ExOn00252@kummer.juniper.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Tue, 8 Oct 2002 08:18:55 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: Kireeti Kompella To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210081459.g98ExOn00252@kummer.juniper.net> Precedence: list >This approach is flawed (IMO) for a couple of reasons: >a) OSPF v3 should deal with IPv4 as well as IPv6 addresses. >b) The fact that a couple of simple TLVs are needed is not a good > reason to reinvent the entire TE LSA. > >A better approach seems to be to add a couple of *new* TLVs to the v2 >TE LSA for IPv6 addresses -- I suggested this to Yakov some time ago, >and this will hopefully be in a forthcoming version of the GMPLS OSPF >TE draft. > >I suspect (without seeing your draft) that you have essentially >cut-and-paste the OSPF v2 TE draft. I believe that to be a flawed >approach as well: it's better to copy by reference rather than by value >whenever you can. The OSPFv2 TE document is constantly undergoing >changes; the GMPLS extensions are one example; DiffServ TE is another; >others (such as extensions for SONET and G.709) are in the works. The >approach that maps OSPFv2 TE LSAs directly into OSPFv3 seems much more >scalable and pragmatic -- each such extension is automatically inherited >into OSPF v3 both spec-wise and code-wise. That is fine. At least we have to clearly define each extension's applicability to OSPFv3. My draft is for that. It is not a easy task. Contrary defining LS type is not a big deal. I believe OSPFv2's Opaque LSA is a inevitable way to introduce new LS type. Because OSPFv2 has very static definition of flooding scope. In OSPFv3 we addressed it with intoroducing generic flooding mechanism. Why are we going to introduce legacy idea from OSPFv2 into OSPFv3? Let's make it clean and simple. -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 11:17:30 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17721 for ; Tue, 8 Oct 2002 11:17:30 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0075F00A@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 11:19:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 260787 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 11:19:33 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 11:19:32 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g98FJWm77142 for ; Tue, 8 Oct 2002 08:19:32 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g98FJW300359 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 08:19:32 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210081519.g98FJW300359@kummer.juniper.net> Date: Tue, 8 Oct 2002 08:19:32 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi Vishwas, > Though I agree the approach you suggest does minimize the amount of effort > for the working group to get similar functionality in OSPFv3 as OSPFv2, by > simply ignoring the OSPFv2 header(i.e. first 20 bytes of the payload). Not entirely accurate: the OSPFv2 header (if you mean the LSA header) is almost identical; the LS type field is the only thing that changes. > I prefer a cleaner approach from the protocol implementations point of view. > Probably giving an LSA type to Area Scope TE LSA's and using the Link ID as > instance id. If you were to add "and keep the LSA body identical between OSPFv2 TE LSA and the new OSPFv3 TE LSA", I'd be inclined to agree with you. However, having gone that far, why not import all OSPFv2 Opaque LSAs into v3 in one go? For example, you get Grace LSAs for free; if tomorrow someone were to invent yet another OSPFv2 Opaque LSA, you get that for free too, should you desire it. Apropos of nothing, it's amusing that the only instance of an OSPF v3 LSA that really fully uses the separation of flooding scope and LS function code is the 'OSPFv2 Opaque LSA' -- all other function codes have pre-defined flooding scopes. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 11:25:30 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17956 for ; Tue, 8 Oct 2002 11:25:29 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0075F1E7@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 11:27:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 260838 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 11:27:33 -0400 Received: from 207.217.120.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 11:27:33 -0400 Received: from user-38lc11b.dialup.mindspring.com ([209.86.4.43] helo=earthlink.net) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ywGh-0003PV-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 08 Oct 2002 08:27:31 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <200210010028.RAA09446@shah.iprg.nokia.com> <065401c26919$bb3c8640$b4036c6b@sisodomain.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3DA2FC8C.C84924E4@earthlink.net> Date: Tue, 8 Oct 2002 08:41:00 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: when to run in NBMA or P2MP mode? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, First, I would like to say that this is a very good explanation. I would like to add just one item to this. With a DR / BDR in a BMA or a NBMA environment, the number of neighbors that can simultaneously perform database exchange (exchange start to full) should also be considered when chosing between your two network configuration modes. A high value should decrease the amount of time to achieve initial database synchronization vs P2MP mode. Thus, if the capabilities of your routing nodes differ and you implement one of the MA modes, then the nodes with the higher capacities should probably be elected as the DR and the BDR. Mitchell Erblich ==================== Manav Bhatia wrote: > > Dhaval, > Let me give it a shot! > > As i understand, you want to clarify the following > - Why the restriction of being able to reach all neighbors directly is > placed in order to run in NBMA mode when we always send unicasts to our > neighbors? > - When would we like to run as p2mp > - How can one determine which mode to run in? > > The reason why we want all the neighbors to be reached directly is because > we want to use mechanisms similar to those used in the broadcast subnets. > This helps making the NBMA segments more efficient in terms of : > - neighbor maintenance > - database synchronization > - database representation > - reducing the O(n^2) relationships to O(n) > > Emulating NBMA as a normal broadcast network helps the representation of an > NBMA subnet within OSPF LSDB as indistinguishable from the representation > of a broadcast subnet. > However, NBMA segments can fail when the two attached neighbors are not > able to communicate directly with each other.If, for example, a PVC fails > or is misconfigured or if an SVC cannot be established, due to capacity or > policy reasons, routing over NBMA will fail! > > When to use point-to-multipoint mode? > > Used if the nonbroadcast subnets cannot support a large number of routers > in complete mesh. > > To connect 200 routers in a full mesh over a Frame Relay/ATM subnet, one > would require (200)(200-1)/2 = 19,900 PVCs! Even when SVCs are used, > capacity limitations may prohibit pairwise connectivity. One cant thus use > the NBMA model as each router cant now communicate directly with the every > other router! The only alternative thus left is p2mp. > The problem comes when operating a full mesh FR/ATM network in p2mp mode > because now the work involved in neighbor maintenance, flooding and > database representation increases as O(n^2), where n is the nos. of routers > attached to the subnet, instead of O(n) that can be achieved with the NBMA > model. > > For the final question i guess the answer is that if you cant provide full > mesh support then its better to model the network as p2mp. > > Regards, > Manav > > ----- Original Message ----- > From: "Dhaval Shah" > To: > Sent: Tuesday, October 01, 2002 5:58 AM > Subject: when to run in NBMA or P2MP mode? > > | Hi > | According to RFC 2328, Ospf can run in one of the two modes on a > | non-broadcast networks, NBMA or P2MP. RFC says that you can run in NBMA > mode > | if all routers attached to the network can communicate directly and you > should > | run in P2MP mode if thats not possible. > | However, while sending hellos out on non-broadcast networks, > irrespective of > | which mode you run on, you always send them unicast to your neighbors. > | The essential difference between NBMA and P2MP is only that there > is DR/BDR > | election and Network LSA generation in NBMA mode and not in P2MP mode. > | So why is the need for the restriction that one MUST be able to > reach all > | neighbors directly in order to run in NBMA mode? What are some of the > example > | physical networks where one would like to run in P2MP mode and not in > NBMA > | mode? How can one determine which mode to run when? > | > | thanks > | Dhaval. > | > | From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 11:33:41 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18589 for ; Tue, 8 Oct 2002 11:33:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0075F119@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 11:35:45 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 260902 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 11:35:45 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 11:35:45 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g98FZim78398; Tue, 8 Oct 2002 08:35:44 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g98FZiA00446; Tue, 8 Oct 2002 08:35:44 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210081535.g98FZiA00446@kummer.juniper.net> Date: Tue, 8 Oct 2002 08:35:44 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: kunihiro@zebra.org To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list > I believe OSPFv2's Opaque LSA is a inevitable way to introduce new LS > type. Because OSPFv2 has very static definition of flooding scope. Is it so hard to understand the following table from the draft? OSPFv2 Opaque LSA of LS Type X Y -------------- --- 9 0 0 10 0 1 11 1 0 I guess I should replace it with Vishwas's table ... Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 12:36:04 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20958 for ; Tue, 8 Oct 2002 12:36:04 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0075F3AB@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 12:38:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 261257 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 12:38:07 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 12:38:07 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3MG3>; Tue, 8 Oct 2002 12:38:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 8 Oct 2002 12:40:23 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Kireeti, >> Though I agree the approach you suggest does minimize the amount of effort >> for the working group to get similar functionality in OSPFv3 as OSPFv2, by >> simply ignoring the OSPFv2 header(i.e. first 20 bytes of the payload). > Not entirely accurate: the OSPFv2 header (if you mean the LSA header) is > almost identical; the LS type field is the only thing that changes. Ok. I thought you meant you were copying the entire OSPFv2 LSA and not just the payload. So agree that the Opaque OSPFv2 for OSPFv3 LSA we would have the same value of Opaque type etc too. >> I prefer a cleaner approach from the protocol implementations point of view. >> Probably giving an LSA type to Area Scope TE LSA's and using the Link ID as >> instance id. >If you were to add "and keep the LSA body identical between OSPFv2 TE >LSA and the new OSPFv3 TE LSA", I'd be inclined to agree with you. That is exactly what I meant earlier(however changed views, for simplicity and work overload for the group). The use of TLV's themselves could be the same as that of the v2 Opaque LSA's. I think that is what you mean in the draft Section 2. ;-) > However, having gone that far, why not import all OSPFv2 Opaque LSAs > into v3 in one go? For example, you get Grace LSAs for free; if > tomorrow someone were to invent yet another OSPFv2 Opaque LSA, you get > that for free too, should you desire it. Agreed it would be far simpler. > Apropos of nothing, it's amusing that the only instance of an OSPF v3 > LSA that really fully uses the separation of flooding scope and LS > function code is the 'OSPFv2 Opaque LSA' -- all other function codes > have pre-defined flooding scopes. I agree. As the LSA function codes of the RFC2740 LSA's themselves tell the flooding scope (i.e. LSA in any other flooding scope would not make sense). Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 12:37:28 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20983 for ; Tue, 8 Oct 2002 12:37:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0075F405@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 12:39:30 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 261294 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 12:39:30 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 12:39:29 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 6FB271DCC69 for ; Tue, 8 Oct 2002 09:39:28 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210081535.g98FZiA00446@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA30A47.7000501@redback.com> Date: Tue, 8 Oct 2002 12:39:35 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kireeti Kompella wrote: >>I believe OSPFv2's Opaque LSA is a inevitable way to introduce new LS >>type. Because OSPFv2 has very static definition of flooding scope. >> > > Is it so hard to understand the following table from the draft? > > OSPFv2 Opaque > LSA of LS Type X Y > -------------- --- > 9 0 0 > 10 0 1 > 11 1 0 > > I guess I should replace it with Vishwas's table ... Kireeti, At initial glance, I missed that you are proposing to use a single function code (you said to only spend a couple minutes ;^). Note that RFC 2370 doesn't mandate that opaque LSAs must be in TLV format. Luckily, all the OSPFv2 opaque LSAs in common use today are composed of TLVs. I think TLV format should be mandated for OSPFv3 opaque LSAs. I agree that migrating the existing link-state types and opaque LSAs TLVs makes sense. Since the addressing semantics of IPv6 and IPv4 are different, I don't think you can say that the bodies of the respective LSAs will be identical. Also, there may be applications which require additional TLVs for OSPFv3. Hence, I don't think opaque LSAs with TLVs containing addresses can be migrated to OSPFv3 without at least definition of the new TLV and IPv6 addressing semantics (e.g., IPv6 address scope). Hence, I think the paragraph below needs to be expanded to cover what can and cannot be migrated in tact. This memo specifies how OSPF version 2 opaque LSAs can be carried in OSPF version 3. This allows the reuse of the specifications of OSPF v2 Opaque LSAs, as well as the code to support them, in OSPF v3. In a nutshell, an OSPF v3 LS Function Code is defined to indicate that the LSA is of type OSPF v2 Opaque LSAs; the OSPF v3 Link State ID is formatted the same as in the OSPF v2 Opaque LSA; and the body of the OSPF v3 LSA is identical to the body of the OSPF v2 Opaque LSA. Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 13:07:24 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22327 for ; Tue, 8 Oct 2002 13:07:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0075F5C6@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 13:09:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 261390 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 13:09:27 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 13:09:27 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3M2B>; Tue, 8 Oct 2002 13:09:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 8 Oct 2002 13:11:28 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee, > Completely agree. Could you put this in draft form? This is at least > the second time the question of opaque LSAs and OSPFv3 has been raised. Agreed, may be asked more often than that. I could put it in a draft for sure. > Since opaque LSA's are meant to be used for many applications and the setting > of the U bit is based solely on the function code, I'm not sure that a > TE specific argument is a good reason for not setting the U bit. I think the advantage of flooding optimizations(during migration - which is how we would want it, not flood TE LSA's(which would be many in number) between disjoint TE domains within an area) could easily be got if we had a different code for generic opaque LSA's and TE LSA's and that is what I was thinking of earlier. Besides we may want to define some v3 specific TLV's(as Kunihiro pointed out). However if we intend to go in for a generic mechanism(as in kireeti's draft) we should instead set the U-bit. I can think of the OSPF-PCSD draft where we may want the U-bit set. Thanks, Vishwas > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, October 08, 2002 8:49 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 > > > Kireeti Kompella wrote: > > >>Hi Kunihiro, >> >> >> >>>BTW I haven't submitted the draft but I prepared TE extensions to >>>OSPFv3. I just define a new LS type for TE then use OSPFv3 built in >>>flooding mechanism. I believe this is straight forward way to do it. >>> >>> >>The draft I submitted also uses the OSPFv3 built in flooding. It is the >>only way to do it. >> >> >> >>>LSA function code LS Type Description >>>-------------------------------------------------------------------- >>>10 0x2000a Traffic-Engineering-LSA >>> > > > > Kunihiro, > > Believe you mean 0x200a. > > > > >>Do you plan to have a different Function Code for each OSPFv2 Opaque LSA >>Type? >> > > > Kiretti, > > If you take into account changes to the LS type for OSPFv3, the code points > are compatible. For OSPFv3, the LS Type is 16 bits (versus 8 for OSPFv2) and > it > contains the flooding scope and a bit indicating what to do with > unrecognized > types. There are no LS type collisions pervent use of the same function > codes. > > > OSPFv2 OSPFv3 > Link Scoped Opaque LSAs 0x09 0x0009 > > Area Scoped Opaque LSAs 0x0a 0x200a > > AS Scoped Opaque LSAs 0x0b 0x400b > > One could argue that the functions types for area and AS scoped opaque LSAs > should be 0xa00a and 0xc00b as well. This would indicate that a router that > does not recognize the type should store and flood it anyway. Any strong > feelings > on this? > > Thanks, > Acee > >>It seems to me to be much easier to have a single code point for all >>OSPFv2 Opaque LSAs. This way, all defined OSPFv2 Opaque LSAs get >>automatically defined in v3; moreover, if a new Opaque LSA seems to be >>useful for both v2 and v3, it can be defined as an OSPFv2 Opaque LSA. >> >>Kireeti. >> > -- > Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 13:59:29 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24062 for ; Tue, 8 Oct 2002 13:59:29 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0075F8D1@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 14:01:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 261672 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 14:01:33 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 14:01:32 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g98I1Wm91320 for ; Tue, 8 Oct 2002 11:01:32 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g98I1Wr00996 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 11:01:32 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210081801.g98I1Wr00996@kummer.juniper.net> Date: Tue, 8 Oct 2002 11:01:32 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DA30A47.7000501@redback.com> Precedence: list Hi Acee, > At initial glance, I missed that you are proposing to use a single > function code (you said to only spend a couple minutes ;^). Mea culpa :-) > Since the addressing semantics of IPv6 and IPv4 > are different, I don't think you can say that the bodies of the respective > LSAs will be identical. Bad wording. Let me try again: the bodies of the respective LSAs are *formated* identically. The actual contents may be different, as you say, but the parsing should be the same. This memo specifies how OSPF version 2 opaque LSAs can be carried in OSPF version 3. This allows the reuse of the specifications of OSPF v2 Opaque LSAs, as well as the code to support them, in OSPF v3. In a nutshell, an OSPF v3 LS Function Code is defined to indicate that the LSA is of type OSPF v2 Opaque LSAs; the OSPF v3 Link State ID is formatted the same as in the OSPF v2 Opaque LSA; and the body of the < OSPF v3 LSA is identical to the body of the OSPF v2 Opaque LSA. > OSPF v3 LSA is formated identically to the body of the OSPF v2 Opaque LSA. Does that help? This should address your issue that OSPFv2 Opaque LSAs are not in TLV format. E.g., if a new Opaque LSA was defined to have a fixed portion followed by TLVs, the OSPFv3 version would look the same. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 17:31:02 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01496 for ; Tue, 8 Oct 2002 17:31:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0075FDA5@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 17:33:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 258779 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 17:33:05 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 17:33:05 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0075FCFB@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 17:26:27 -0400 Message-ID: Date: Tue, 8 Oct 2002 17:26:27 -0400 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: Kireeti Kompella To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Kireeti, et al Sorry for the delay. If I understand Kireeti's idea correctly, the suggestion is to "map" the Opaque LSA mechanism in v2 to the generic scoped flooding mechanism in v3; and it is primarily driven by the desire to get TE extensions to v3 faster. Below is my view on this. It seems to me that such a mapping would introduce the under- specification problem and thus may affect interoperability. Here's why. What is being said is essentially "whatever Opaque LSAs have been introduced in the past or will be introduced in the future in v2 now also make sense in v3". It's not that easy though. Opaques LSAs used in v2 may affect protocol mechanisms that are specific to v2 and are not applicable in v3, or they may contain information that makes sense in the IPv4 world only. Just saying that we now have this stuff in v3 is not enough, one has to go and specify how this info is interpreted there. In other words, when one wants to have a feature in v3 that is supported in v2 using Opaque LSAs, two things need to be specified: how required information is carried around, and how this information is interpreted. Suggested mapping solves the first part, which is a non-issue btw, but creates a problem in the second. Bottom line: I think there is a problem in the suggested approach and believe that bringing the features based on/contents of Opaque LSAs to v3 should be done on a case-by-case basis with proper specification of IPv6 and v3-related details. Regards. -- Alex From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 19:12:33 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03189 for ; Tue, 8 Oct 2002 19:12:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.007601BA@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 19:14:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 259190 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 19:14:37 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 19:14:36 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g98NEZm19662; Tue, 8 Oct 2002 16:14:35 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g98NEZS02106; Tue, 8 Oct 2002 16:14:35 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210082314.g98NEZS02106@kummer.juniper.net> Date: Tue, 8 Oct 2002 16:14:35 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: zinin@PSG.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi Alex, > If I understand Kireeti's idea correctly, the suggestion is to "map" > the Opaque LSA mechanism in v2 to the generic scoped flooding > mechanism in v3; and it is primarily driven by the desire to get TE > extensions to v3 faster. Below is my view on this. Pretty good summary. Small change: "faster, with maximal code reuse" > Opaques LSAs used > in v2 may affect protocol mechanisms that are specific to v2 and are > not applicable in v3, or they may contain information that makes > sense in the IPv4 world only. Just saying that we now have this stuff > in v3 is not enough, one has to go and specify how this info is > interpreted there. There are (at least) four ways to get a spec from v2 into v3 (where a "spec" defines a specific Opaque LSA type, such as TE or Grace LSA): a) redo the spec and the code, clean it up, tailor it to v3 and IPv6; b) map the spec and code wholesale into v3; c) map the spec on a section-by-section (or TLV-by-TLV) basis from v2 to v3; d) map the entire notion of v2 Opaque LSAs into v3. (a) would be wonderful. Unfortunately, things aren't always as nice as they could be; code, deadlines, migration, etc. get in the way. This is not to say that this approach is wrong -- in fact, it is the only correct approach. Fortunately, there is no conflict: one can do (a) in parallel with (b) (c) or (d). (b) is the approach, as near as I understand it, that Vishwas was suggesting. Close in spirit with (d) below. (c) is, if I understand you correctly, the approach you are suggesting. Would be a strong requirement if there were lots of pre-existing Opaque LSAs; however, there are only a couple or so. Also, see below. (d) is the approach that I was foolish enough to propose. Quick and dirty, easy, maximizes code reuse. So, let's see where we are. There are two Opaque LSA types that I am familiar with: TE LSAs and Grace LSAs. Both of these migrate in a very straightforward manner to v3. So, we don't have a huge "legacy" problem. The simple thing to do is to mandate that when new OSPFv2 Opaque LSAs are defined, the authors state on a per TLV/section/spec/... basis what migrates to v3 and what is v2-only. This is probably a Good Thing to do anyway, and minimizes the need for (c). Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 21:04:06 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05523 for ; Tue, 8 Oct 2002 21:04:05 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00760573@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 21:06:08 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 261233 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 21:06:08 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 21:06:08 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17z5Ic-000CJO-00; Tue, 08 Oct 2002 18:06:06 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <200210082314.g98NEZS02106@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <197467164316.20021008180403@psg.com> Date: Tue, 8 Oct 2002 18:04:03 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: Kireeti Kompella To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210082314.g98NEZS02106@kummer.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Thanks for your response, Kireeti. See below, please. >> If I understand Kireeti's idea correctly, the suggestion is to "map" >> the Opaque LSA mechanism in v2 to the generic scoped flooding >> mechanism in v3; and it is primarily driven by the desire to get TE >> extensions to v3 faster. Below is my view on this. > Pretty good summary. Small change: "faster, with maximal code reuse" Accepted :) >> Opaques LSAs used >> in v2 may affect protocol mechanisms that are specific to v2 and are >> not applicable in v3, or they may contain information that makes >> sense in the IPv4 world only. Just saying that we now have this stuff >> in v3 is not enough, one has to go and specify how this info is >> interpreted there. > There are (at least) four ways to get a spec from v2 into v3 (where > a "spec" defines a specific Opaque LSA type, such as TE or Grace LSA): > a) redo the spec and the code, clean it up, tailor it to v3 and IPv6; > b) map the spec and code wholesale into v3; > c) map the spec on a section-by-section (or TLV-by-TLV) basis from > v2 to v3; > d) map the entire notion of v2 Opaque LSAs into v3. > (a) would be wonderful. Unfortunately, things aren't always as nice > as they could be; code, deadlines, migration, etc. get in the way. > This is not to say that this approach is wrong -- in fact, it is > the only correct approach. Fortunately, there is no conflict: > one can do (a) in parallel with (b) (c) or (d). > (b) is the approach, as near as I understand it, that Vishwas was > suggesting. Close in spirit with (d) below. > (c) is, if I understand you correctly, the approach you are suggesting. Not necessarily on a section-by-section/TLV-by-TLV basis as you mentioned above. Instead, if, for example, we need to get the TE extensions into v3, we would come up with a draft-ospf-ospfv3-katz-yueng and specify the LS Type for TE LSAs, refer to katz-yueng for things like body formatting, enumerate TLVs (by reference, not value) that are IP-version independent and are valid for v3, and then go and address the IPv6 specific details. This way we make sure that we have good code reuse, and things are properly specified at the same time. If things are so similar that nothing needs to be changed (e.g., I finally write an Apr 1 draft on DNS over BGP, together with a BCP on redistributing this DNS info into IGPs using v2 Opaque LSAs and v3 LSA foo), the document is really small and says "here's the LSA function code, the rest is as there". I'm afraid, however, that this is not the common case and there will be IPv6/OSPFv3 specific details... > Would be a strong requirement if there were lots of pre-existing > Opaque LSAs; however, there are only a couple or so. Also, see below. > (d) is the approach that I was foolish enough to propose. Quick and > dirty, easy, maximizes code reuse. It could be a brilliant hack, I have to give you that. > So, let's see where we are. There are two Opaque LSA types that I am > familiar with: TE LSAs and Grace LSAs. Both of these migrate in a very > straightforward manner to v3. So, we don't have a huge "legacy" problem. But they don't map directly from v2 to v3 and from IPv4 to IPv6, however. We'd still need to address issues like those Ishi brought up. Besides, while for the GMPLS world OSPFv2 and OSPFv3 might seem like just two very similar transport mechanisms for TE info, it is very different for the protocols themselves. It is perfectly possible, for example, to have an extension to OSPFv2 that uses Opaque LSAs, but that makes not sense at all in OSPFv3. > The simple thing to do is to mandate that when new OSPFv2 Opaque LSAs > are defined, the authors state on a per TLV/section/spec/... basis what > migrates to v3 and what is v2-only. This is probably a Good Thing to do > anyway, and minimizes the need for (c). Given that: a) we will need to go and think carefully about possible implications of moving a specific feature to the IPv6/OSPFv3 environment every time we do that b) those implications will be specific to each feature being "migrated" c) those implications will need to be properly documented and that d) assignment of the LSA function is a non-issue I think that creating the "automatic/implicit specification" back door between the protocols is not warranted. In fact, I am really worried that this implicitness will result in inadequate specification. Thanks. Alex From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 21:22:15 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05844 for ; Tue, 8 Oct 2002 21:22:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0076066E@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 21:24:20 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 261884 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 21:24:20 -0400 Received: from 65.223.109.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 21:24:19 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id VAA07699; Tue, 8 Oct 2002 21:27:36 -0400 References: <200210082314.g98NEZS02106@kummer.juniper.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Tue, 8 Oct 2002 18:27:36 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: Kireeti Kompella To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210082314.g98NEZS02106@kummer.juniper.net> Precedence: list >So, let's see where we are. There are two Opaque LSA types that I am >familiar with: TE LSAs and Grace LSAs. Both of these migrate in a very >straightforward manner to v3. So, we don't have a huge "legacy" problem. Grace LSAs has IP interface address (Type=3, length=4) which assumes IPv4. We'll need IPv6 interface address (new TLV). Sorry for saying this kind of things again and again... But this is a good opportunity to aware current extensions can't be applicable to IPv6 without change or adding new TLV type. >The simple thing to do is to mandate that when new OSPFv2 Opaque LSAs >are defined, the authors state on a per TLV/section/spec/... basis what >migrates to v3 and what is v2-only. This is probably a Good Thing to do >anyway, and minimizes the need for (c). I agree with it. When we define a new extension to OSPF it is good to have both OSPFv2 and OSPFv3 at the same time. TLV should be common both two protocol. We should be careful to avoid implicit assumption about IP address (it can be IPv4 or IPv6). And we can't assume that router-id 4 octet value is reachable as real IP address... OSPF new extension X 1. Description of the new extension X 2. TLV definitions which aware IPv4 and IPv6. Apendix A. Packet format in OSPFv2 Description of Opaque LSA format and Opaque code... Apendix B. Pakcet format in OSPFv3 Just Define LS type code ;-). (This is my preference but if we think exporting Opaque LSA is better, it is doable). Kireeti, how do you think about this? If you think this is same idea you are thinking about, I'm going to work on revising existing OSPF extensions draft such as TE, diffserv, restart, GMPLS to make it sure it can be applicable to IPv6 network. -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 22:26:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07137 for ; Tue, 8 Oct 2002 22:26:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0076074F@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 22:28:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 263651 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 22:28:27 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 22:28:27 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g992SRm32176; Tue, 8 Oct 2002 19:28:27 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g992SRl11982; Tue, 8 Oct 2002 19:28:27 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210090228.g992SRl11982@garnet.juniper.net> Date: Tue, 8 Oct 2002 19:28:26 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: from "Kunihiro Ishiguro" at Oct 08, 2002 06:27:36 PM Precedence: list Content-Transfer-Encoding: 7bit Please see my comment below : > > >So, let's see where we are. There are two Opaque LSA types that I am > >familiar with: TE LSAs and Grace LSAs. Both of these migrate in a very > >straightforward manner to v3. So, we don't have a huge "legacy" problem. > > Grace LSAs has IP interface address (Type=3, length=4) which assumes > IPv4. We'll need IPv6 interface address (new TLV). Sorry for saying > this kind of things again and again... But this is a good opportunity > to aware current extensions can't be applicable to IPv6 without change > or adding new TLV type. > This TLV is optional and more over the purpose of this TLV is to identify the neighbor from its interface address. In OSPF V3 this is done by using the Router-id which is also a 32 bit - hence could fit in here. I am actually submitting a draft regarding the use of this TLV in OSPFv3 and it will actually carry the router-id in a new TLV. I think that the best approach would be to have different TLV that are either OSPFv2 or OSPFv3 specific regarding ipv4/ipv6. My preference would be to have those TLVs to have the same suffix for example : TLV 3 - ipv4 TLV 1003 - ipv6 Padma > >The simple thing to do is to mandate that when new OSPFv2 Opaque LSAs > >are defined, the authors state on a per TLV/section/spec/... basis what > >migrates to v3 and what is v2-only. This is probably a Good Thing to do > >anyway, and minimizes the need for (c). > > I agree with it. When we define a new extension to OSPF it is good to > have both OSPFv2 and OSPFv3 at the same time. TLV should be common > both two protocol. We should be careful to avoid implicit assumption > about IP address (it can be IPv4 or IPv6). And we can't assume that > router-id 4 octet value is reachable as real IP address... > > OSPF new extension X > > 1. Description of the new extension X > > 2. TLV definitions which aware IPv4 and IPv6. > > Apendix A. Packet format in OSPFv2 > > Description of Opaque LSA format and Opaque code... > > Apendix B. Pakcet format in OSPFv3 > > Just Define LS type code ;-). > > (This is my preference but if we think exporting Opaque LSA is better, > it is doable). > > Kireeti, how do you think about this? If you think this is same idea > you are thinking about, I'm going to work on revising existing OSPF > extensions draft such as TE, diffserv, restart, GMPLS to make it sure > it can be applicable to IPv6 network. > -- > Kunihiro Ishiguro > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 8 23:05:24 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07957 for ; Tue, 8 Oct 2002 23:05:24 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00760C3A@cherry.ease.lsoft.com>; Tue, 8 Oct 2002 23:07:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 264991 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Oct 2002 23:07:27 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 8 Oct 2002 23:07:27 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9937Qm33924; Tue, 8 Oct 2002 20:07:26 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g9937Qd03084; Tue, 8 Oct 2002 20:07:26 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210090307.g9937Qd03084@kummer.juniper.net> Date: Tue, 8 Oct 2002 20:07:26 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: kunihiro@zebra.org To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list > Kireeti, how do you think about this? It's not like I'm given much choice by the AD. Plan B: write a short draft that basically grabs an LS function code for TE, defines that the LSA body format remains the same and states that all current TLVs "just work" (since they do). Also, define *new* sub-TLVs for local and remote IPv6 addresses. Finally, state how Instances are identified. If you're doing this, I have two requests: a) Please avoid redefining sub-TLVs 1-16 of the Link TLV; b) Make the new sub-TLVs applicable to both OSPFv2 and v3. BTW, diffserv TE and GMPLS are just subcases of TE. I'd suggest that draft-katz-yeung-ospf-traffic-08.txt, draft-ietf-tewg-diff-te-proto-01.txt and draft-ietf-ccamp-ospf-gmpls-extensions-08.txt be cited normatively in your draft. I don't know if a new v6 Router Address TLV is needed: you may want to research that. Good luck! Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 01:35:59 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10854 for ; Wed, 9 Oct 2002 01:35:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.007610BF@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 1:38:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 268473 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 01:38:02 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 01:38:02 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3NF8>; Wed, 9 Oct 2002 01:38:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 9 Oct 2002 01:40:05 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi folks, To summarize the discussion I guess Kireeti's approach helps in reducing the workload for the working group and getting the specs out faster(especially TE). I do not think "mapping" can cause problems as long as in each draft using opaque LSA's we give information for both v2 and v3. However the code reuse can still be done if we use the same TLV values for v3 as v2 even when we have seperate drafts. If the working group is ready to take in the additional work, I think we can replicate and have seperate drafts for TE which do help in clarity of the specs. However I have a few clarification to make if we do decide to work on each draft seperately: - a) How would we want to go ahead with docs like "Graceful Restart" which are still in draft state and haven't gone LC etc? We could as well have v3 additions in the existing drafts. b) How would we want to have drafts in the future for a particular feature? Different drafts or the same one defining for both OSPFv2 and v3? For both the questions I would prefer an integrated approach for the drafts. Thanks, Vishwas -----Original Message----- From: Alex Zinin [mailto:zinin@PSG.COM] Sent: Wednesday, October 09, 2002 2:56 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti, et al Sorry for the delay. If I understand Kireeti's idea correctly, the suggestion is to "map" the Opaque LSA mechanism in v2 to the generic scoped flooding mechanism in v3; and it is primarily driven by the desire to get TE extensions to v3 faster. Below is my view on this. It seems to me that such a mapping would introduce the under- specification problem and thus may affect interoperability. Here's why. What is being said is essentially "whatever Opaque LSAs have been introduced in the past or will be introduced in the future in v2 now also make sense in v3". It's not that easy though. Opaques LSAs used in v2 may affect protocol mechanisms that are specific to v2 and are not applicable in v3, or they may contain information that makes sense in the IPv4 world only. Just saying that we now have this stuff in v3 is not enough, one has to go and specify how this info is interpreted there. In other words, when one wants to have a feature in v3 that is supported in v2 using Opaque LSAs, two things need to be specified: how required information is carried around, and how this information is interpreted. Suggested mapping solves the first part, which is a non-issue btw, but creates a problem in the second. Bottom line: I think there is a problem in the suggested approach and believe that bringing the features based on/contents of Opaque LSAs to v3 should be done on a case-by-case basis with proper specification of IPv6 and v3-related details. Regards. -- Alex From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 06:08:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08414 for ; Wed, 9 Oct 2002 06:08:36 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.007616DC@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 6:10:39 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 270431 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 06:10:39 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 06:10:38 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3NN8>; Wed, 9 Oct 2002 06:10:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 9 Oct 2002 06:12:36 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee/folks, > Completely agree. Could you put this in draft form? This is at least > the second time the question of opaque LSAs and OSPFv3 has been raised. Ok just to start to get the ball rolling, I am attaching a rip-off of the Katz Yeung draft for OSPFv3. The main points are : - a) New LSA type defined b) U-bit set to 0 c) Whereever IP address was used, has been changed. I guess we can do with reference to the Katz-yeung draft and other TE drafts. However for now I have left stuff as it is. Kireeti/Kunihiro or anyone else willing to help please let me know. Thanks, Vishwas ========================================================= Network Working Group Vishwas Manral Internet Draft Netplane Systems Category: Standards Track October 2002 Expires: March 2003 draft-manral-ospfv3-traffic-00.txt Traffic Engineering Extensions to OSPF Version 3 *** Draft *** Status This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes extensions to the OSPF protocol version 3 to support intra-area Traffic Engineering, using a new OSPFv3 [RFC2740] LSA type called Intra-Area-TE-LSA. 1. Introduction This document specifies a method of adding traffic engineering capabilities to OSPF Version 3 [1]. The architecture of traffic engineering is described in [2]. The semantic content of the extensions is essentially identical to the corresponding extensions to IS-IS and OSPFv2[katz-yeung-draft]. It is expected that the traffic engineering extensions to OSPFv3 will continue to mirror those in OSPFv2. The extensions provide a way of describing the traffic engineering topology (including bandwidth and administrative constraints) and distributing this information within a given OSPFv3 area. This topology does not necessarily match the regular routed topology, though this proposal depends on Network LSAs to describe multi-access links. 1.1. Applicability Many of the extensions specified in this document are in response to the requirements stated in [2], and thus are referred to as "traffic engineering extensions", and are also commonly associated with MPLS Traffic Engineering. A more accurate (albeit bland) designation is "extended link attributes", as what is proposed is simply to add more attributes to links in OSPFv3 advertisements. The information made available by these extensions can be used to build an extended link state database just as router LSAs are used to build a "regular" link state database; the difference is that the extended link state database (referred to below as the traffic engineering database) has additional link attributes. Uses of the traffic engineering database include: o monitoring the extended link attributes; o local constraint-based source routing; and o global traffic engineering. For example, an OSPFv3-speaking device can participate in an OSPFv3 area, build a traffic engineering database, and thereby report on the reservation state of links in that area. In "local constraint-based source routing", a router R can compute a path from a source node A to a destination node B; typically, A is R itself, and B is specified by a "router address" (see below). This path may be subject to various constraints on the attributes of the links and nodes that the path traverses, e.g., use green links that have unreserved bandwidth of at least 10Mbps. This path could then be used to carry some subset of the traffic from A to B, forming a simple but effective means of traffic engineering. How the subset of traffic is determined, and how the path is instantiated is beyond the scope of this document; suffice it to say that one means of defining the subset of traffic is "those packets whose IP destinations were learned from B", and one means of instantiating paths is using MPLS tunnels. As an aside, note that constraint-based routing can be NP- hard, or even unsolvable, depending on the nature of the attributes and constraints and thus many implementations will use heuristics. Consequently, we don't attempt to sketch an algorithm here. Finally, for "global traffic engineering", a device can build a traffic engineering database, input a traffic matrix and an optimization function, crunch on the information, and thus compute optimal or near-optimal routing for the entire network. The device can subsequently monitor the traffic engineering topology and react to changes by recomputing the optimal routes. 1.2. Limitations As mentioned above, this document specifies extensions and procedures for intra-area distribution of Traffic Engineering information. Methods for inter-area and inter-AS (Autonomous System) are not discussed here. The extensions specified in this document capture the reservation state of point-to-point links. The reservation state of multiaccess links is not accurately reflected, except in the special case that there are only two devices in the multiaccess subnetwork. This document also does not support unnumbered links. This deficiency is addressed in [4]; see also [5] and [6]. 1.3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7]. 2. LSA Format 2.1. LSA type This extension makes use of a new OSPFv3 LSA type called Intra-Area-TE-LSA. The LSA function code of which is 10 and the LSA type value is 0x200a. The U-bit of the LSA has been set to 0. This helps prevent flooding of Intra-Area-TE-LSA's to other routers within the area which do not support the LSA type. 2.2. LSA ID The LSA ID field is used to identify different Intra-Area-TE-LSA's. A maximum of 4294967296 Traffic Engineering LSAs may be sourced by a single system. The LSA ID has no topological significance. 2.3. LSA Format Overview 2.3.1. LSA Header The Traffic Engineering LSA starts with the standard LSA header. The values of the fields of significance in the header have been defined above. 2.3.2. TLV Header The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets for extensibility. The format of each TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. Unrecognized types are ignored. This memo defines Types 1 and 2. See the IANA Considerations section for allocation of new Types. 2.4. LSA payload details An LSA contains one top-level TLV. There are two top-level TLVs defined: 1 - Router Address 2 - Link 2.4.1. Router Address TLV The Router Address TLV specifies a stable IP address of the advertising router that is always reachable if there is any connectivity to it. This is typically implemented as a "loopback address"; the key attribute is that the address does not become unusable if an interface is down. In other protocols this is known as the "router ID," but for obvious reasons this nomenclature is avoided here. If a router advertises BGP routes with the BGP next hop attribute set to the BGP router ID, then the Router Address SHOULD be the same as the BGP router ID. If IS-IS is also active in the domain, this address can also be used to compute the mapping between the OSPFv3 and IS-IS topologies. For example, suppose a router R is advertising both IS-IS and OSPF Traffic Engineering LSAs, and suppose further that some router S is building a single Traffic Engineering Database (TED) based on both IS-IS and OSPFv3 TE information. R may then appear as two separate nodes in S's TED; however, if both the IS-IS and OSPFv3 LSAs generated by R contain the same Router Address, then S can determine that the IS-IS TE LSA and the OSPFv3 TE LSA from R are indeed from a single router. The router address TLV is type 1, and has a length of 16, and the value is the sixteen octet IPv6 address. It must appear in exactly one Traffic Engineering LSA originated by a router. The address used cannot be a link-local address. 2.4.2. Link TLV The Link TLV describes a single link. It is constructed of a set of sub-TLVs. There are no ordering requirements for the sub-TLVs. Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology. The Link TLV is type 2, and the length is variable. The following sub-TLVs are defined: 1 - Link type (1 octet) 2 - Link ID (variable octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets) 103 - Local interface IP address (16N octets) 104 - Remote interface IP address (16N octets) This memo defines sub-Types for OSPFv3. See the IANA Considerations section for allocation of new sub-Types. The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear exactly once. All other sub-TLVs defined here may occur at most once. These restrictions need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored. Various values below use the (32 bit) IEEE Floating Point format. For quick reference, this format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Exponent | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where S is the sign; Exponent is the exponent base 2 in "excess 127" notation; and Fraction is the mantissa - 1, with an implied binary point in front of it. Thus the above represents the value (-1)**(S) * 2**(Exponent-127) * (1 + Fraction) For more details, refer to [9]. 2.5. Sub-TLV Details 2.5.1. Link Type The Link Type sub-TLV defines the type of the link: 1 - Point-to-point 2 - Multiaccess The Link Type sub-TLV is TLV type 1, and is one octet in length. 2.5.2. Link ID The Link ID sub-TLV identifies the other end of the link. For point- to-point links, this is the Router ID of the neighbor. For multiaccess links, this is the interface ID of the designated router. The Link ID sub-TLV is TLV type 2, and is four or 16 octets octets in Length, depending on the link type. 2.5.3. Local Interface IP Address The Local Interface IP Address sub-TLV specifies the IP address(es) of the interface corresponding to this link. If there are multiple local addresses on the link, they are all listed in this sub-TLV. Are we required to advertise the Link-local-Addresses too.(I guess not) The Local Interface IP Address sub-TLV is TLV type 3, and is 16N octets in length, where N is the number of local addresses. 2.5.4. Remote Interface IP Address The Remote Interface IP Address sub-TLV specifies the IP address(es) of the neighbor's interface corresponding to this link. This and the local address are used to discern multiple parallel links between systems. If the Link Type of the link is Multiaccess, the Remote Interface IP Addess is set to 0.0.0.0 . The Remote Interface IP Address sub-TLV is TLV type 4, and is 16N octets in length, where N is the number of neighbor IPv6 addresses. 2.5.5. Traffic Engineering Metric The Traffic Engineering Metric sub-TLV specifies the link metric for traffic engineering purposes. This metric may be different than the standard OSPF link metric. Typically, this metric is assigned by a network admistrator. The Traffic Engineering Metric sub-TLV is TLV type 5, and is four octets in length. 2.5.6. Maximum Bandwidth The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that can be used on this link in this direction (from the system originating the LSA to its neighbor), in IEEE floating point format. This is the true link capacity. The units are bytes per second. The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in 2.5.7. Maximum Reservable Bandwidth The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). This SHOULD be user-configurable; the default value should be the Maximum Bandwidth. The units are bytes per second. The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four octets in length. 2.5.8. Unreserved Bandwidth The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels, in IEEE floating point format. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub- TLV, and priority 7 at the end of the sub-TLV. The initial values (before any bandwidth is reserved) are all set to the Maximum Reservable Bandwidth. Each value will be less than or equal to the Maximum Reservable Bandwidth. The units are bytes per second. The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in length. 2.5.9. Administrative Group The Administrative Group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface. A link may belong to multiple groups. By convention the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'. The Administrative Group is also called Resource Class/Color [2]. The Administrative Group sub-TLV is TLV type 9, and is four octets in length. 3. Elements of Procedure Routers shall originate Traffic Engineering LSAs whenever the LSA contents change, and whenever otherwise required by OSPF (an LSA refresh, for example). Note that this does not mean that every change must be flooded immediately; an implementation MAY set thresholds (for example, a bandwidth change threshold) that trigger immediate flooding, and initiate flooding of other changes after a short time interval. In any case, the origination of Traffic Engineering LSAs SHOULD be rate-limited to at most one every MinLSInterval [1]. Upon receipt of a changed Traffic Engineering LSA or Network LSA (since these are used in traffic engineering calculations), the router should update its traffic engineering database. No SPF or other route calculations are necessary. 4. Compatibility Issues There should be no interoperability issues with routers that do not implement these extensions. OSPFv3 [RFC2740] already defines ways to handle unknown LSA types. As the U-bit is not set the LSA is treated as a Link-Local LSA by a router which does not understand the LSA type. The result of having routers that do not implement these extensions is that the traffic engineering topology will be missing pieces; however, if the topology is connected, TE paths can still be calculated and ought to work. 5. Normative References 6. Informative References 7. Security Considerations This document specifies the contents of Intr-Area-TE LSAs in OSPFv3. As the LSA's are not used for SPF computation or normal routing, the extensions specified here have no affect on IP routing. Tampering with TE LSAs may have an effect on traffic engineering computations, however, and it is suggested that whatever mechanisms are used for securing the transmission of normal OSPFv3 LSAs be applied equally to all TE LSA's. 8. IANA Considerations 9. Authors' Addresses Vishwas Manral Netplane Systems, 189, Prashasan Nagar, Road Number 72, Jubilee Hills, Hyderabad - 33 INDIA 10. IPR Notices 11. Full Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 06:19:04 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08666 for ; Wed, 9 Oct 2002 06:19:03 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0076166F@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 6:21:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 270463 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 06:21:07 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 06:21:07 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3N31>; Wed, 9 Oct 2002 06:21:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 9 Oct 2002 06:23:23 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list One small correction Link-ID sub TLV length would always be 4-bytes i.e. Interface ID or Router Id of neigbor. Thanks, Vishwas -----Original Message----- From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] Sent: Wednesday, October 09, 2002 3:43 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Hi Acee/folks, > Completely agree. Could you put this in draft form? This is at least > the second time the question of opaque LSAs and OSPFv3 has been raised. Ok just to start to get the ball rolling, I am attaching a rip-off of the Katz Yeung draft for OSPFv3. The main points are : - a) New LSA type defined b) U-bit set to 0 c) Whereever IP address was used, has been changed. I guess we can do with reference to the Katz-yeung draft and other TE drafts. However for now I have left stuff as it is. Kireeti/Kunihiro or anyone else willing to help please let me know. Thanks, Vishwas ========================================================= Network Working Group Vishwas Manral Internet Draft Netplane Systems Category: Standards Track October 2002 Expires: March 2003 draft-manral-ospfv3-traffic-00.txt Traffic Engineering Extensions to OSPF Version 3 *** Draft *** Status This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes extensions to the OSPF protocol version 3 to support intra-area Traffic Engineering, using a new OSPFv3 [RFC2740] LSA type called Intra-Area-TE-LSA. 1. Introduction This document specifies a method of adding traffic engineering capabilities to OSPF Version 3 [1]. The architecture of traffic engineering is described in [2]. The semantic content of the extensions is essentially identical to the corresponding extensions to IS-IS and OSPFv2[katz-yeung-draft]. It is expected that the traffic engineering extensions to OSPFv3 will continue to mirror those in OSPFv2. The extensions provide a way of describing the traffic engineering topology (including bandwidth and administrative constraints) and distributing this information within a given OSPFv3 area. This topology does not necessarily match the regular routed topology, though this proposal depends on Network LSAs to describe multi-access links. 1.1. Applicability Many of the extensions specified in this document are in response to the requirements stated in [2], and thus are referred to as "traffic engineering extensions", and are also commonly associated with MPLS Traffic Engineering. A more accurate (albeit bland) designation is "extended link attributes", as what is proposed is simply to add more attributes to links in OSPFv3 advertisements. The information made available by these extensions can be used to build an extended link state database just as router LSAs are used to build a "regular" link state database; the difference is that the extended link state database (referred to below as the traffic engineering database) has additional link attributes. Uses of the traffic engineering database include: o monitoring the extended link attributes; o local constraint-based source routing; and o global traffic engineering. For example, an OSPFv3-speaking device can participate in an OSPFv3 area, build a traffic engineering database, and thereby report on the reservation state of links in that area. In "local constraint-based source routing", a router R can compute a path from a source node A to a destination node B; typically, A is R itself, and B is specified by a "router address" (see below). This path may be subject to various constraints on the attributes of the links and nodes that the path traverses, e.g., use green links that have unreserved bandwidth of at least 10Mbps. This path could then be used to carry some subset of the traffic from A to B, forming a simple but effective means of traffic engineering. How the subset of traffic is determined, and how the path is instantiated is beyond the scope of this document; suffice it to say that one means of defining the subset of traffic is "those packets whose IP destinations were learned from B", and one means of instantiating paths is using MPLS tunnels. As an aside, note that constraint-based routing can be NP- hard, or even unsolvable, depending on the nature of the attributes and constraints and thus many implementations will use heuristics. Consequently, we don't attempt to sketch an algorithm here. Finally, for "global traffic engineering", a device can build a traffic engineering database, input a traffic matrix and an optimization function, crunch on the information, and thus compute optimal or near-optimal routing for the entire network. The device can subsequently monitor the traffic engineering topology and react to changes by recomputing the optimal routes. 1.2. Limitations As mentioned above, this document specifies extensions and procedures for intra-area distribution of Traffic Engineering information. Methods for inter-area and inter-AS (Autonomous System) are not discussed here. The extensions specified in this document capture the reservation state of point-to-point links. The reservation state of multiaccess links is not accurately reflected, except in the special case that there are only two devices in the multiaccess subnetwork. This document also does not support unnumbered links. This deficiency is addressed in [4]; see also [5] and [6]. 1.3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7]. 2. LSA Format 2.1. LSA type This extension makes use of a new OSPFv3 LSA type called Intra-Area-TE-LSA. The LSA function code of which is 10 and the LSA type value is 0x200a. The U-bit of the LSA has been set to 0. This helps prevent flooding of Intra-Area-TE-LSA's to other routers within the area which do not support the LSA type. 2.2. LSA ID The LSA ID field is used to identify different Intra-Area-TE-LSA's. A maximum of 4294967296 Traffic Engineering LSAs may be sourced by a single system. The LSA ID has no topological significance. 2.3. LSA Format Overview 2.3.1. LSA Header The Traffic Engineering LSA starts with the standard LSA header. The values of the fields of significance in the header have been defined above. 2.3.2. TLV Header The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets for extensibility. The format of each TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. Unrecognized types are ignored. This memo defines Types 1 and 2. See the IANA Considerations section for allocation of new Types. 2.4. LSA payload details An LSA contains one top-level TLV. There are two top-level TLVs defined: 1 - Router Address 2 - Link 2.4.1. Router Address TLV The Router Address TLV specifies a stable IP address of the advertising router that is always reachable if there is any connectivity to it. This is typically implemented as a "loopback address"; the key attribute is that the address does not become unusable if an interface is down. In other protocols this is known as the "router ID," but for obvious reasons this nomenclature is avoided here. If a router advertises BGP routes with the BGP next hop attribute set to the BGP router ID, then the Router Address SHOULD be the same as the BGP router ID. If IS-IS is also active in the domain, this address can also be used to compute the mapping between the OSPFv3 and IS-IS topologies. For example, suppose a router R is advertising both IS-IS and OSPF Traffic Engineering LSAs, and suppose further that some router S is building a single Traffic Engineering Database (TED) based on both IS-IS and OSPFv3 TE information. R may then appear as two separate nodes in S's TED; however, if both the IS-IS and OSPFv3 LSAs generated by R contain the same Router Address, then S can determine that the IS-IS TE LSA and the OSPFv3 TE LSA from R are indeed from a single router. The router address TLV is type 1, and has a length of 16, and the value is the sixteen octet IPv6 address. It must appear in exactly one Traffic Engineering LSA originated by a router. The address used cannot be a link-local address. 2.4.2. Link TLV The Link TLV describes a single link. It is constructed of a set of sub-TLVs. There are no ordering requirements for the sub-TLVs. Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology. The Link TLV is type 2, and the length is variable. The following sub-TLVs are defined: 1 - Link type (1 octet) 2 - Link ID (variable octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets) 103 - Local interface IP address (16N octets) 104 - Remote interface IP address (16N octets) This memo defines sub-Types for OSPFv3. See the IANA Considerations section for allocation of new sub-Types. The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear exactly once. All other sub-TLVs defined here may occur at most once. These restrictions need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored. Various values below use the (32 bit) IEEE Floating Point format. For quick reference, this format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Exponent | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where S is the sign; Exponent is the exponent base 2 in "excess 127" notation; and Fraction is the mantissa - 1, with an implied binary point in front of it. Thus the above represents the value (-1)**(S) * 2**(Exponent-127) * (1 + Fraction) For more details, refer to [9]. 2.5. Sub-TLV Details 2.5.1. Link Type The Link Type sub-TLV defines the type of the link: 1 - Point-to-point 2 - Multiaccess The Link Type sub-TLV is TLV type 1, and is one octet in length. 2.5.2. Link ID The Link ID sub-TLV identifies the other end of the link. For point- to-point links, this is the Router ID of the neighbor. For multiaccess links, this is the interface ID of the designated router. The Link ID sub-TLV is TLV type 2, and is four or 16 octets octets in Length, depending on the link type. 2.5.3. Local Interface IP Address The Local Interface IP Address sub-TLV specifies the IP address(es) of the interface corresponding to this link. If there are multiple local addresses on the link, they are all listed in this sub-TLV. Are we required to advertise the Link-local-Addresses too.(I guess not) The Local Interface IP Address sub-TLV is TLV type 3, and is 16N octets in length, where N is the number of local addresses. 2.5.4. Remote Interface IP Address The Remote Interface IP Address sub-TLV specifies the IP address(es) of the neighbor's interface corresponding to this link. This and the local address are used to discern multiple parallel links between systems. If the Link Type of the link is Multiaccess, the Remote Interface IP Addess is set to 0.0.0.0 . The Remote Interface IP Address sub-TLV is TLV type 4, and is 16N octets in length, where N is the number of neighbor IPv6 addresses. 2.5.5. Traffic Engineering Metric The Traffic Engineering Metric sub-TLV specifies the link metric for traffic engineering purposes. This metric may be different than the standard OSPF link metric. Typically, this metric is assigned by a network admistrator. The Traffic Engineering Metric sub-TLV is TLV type 5, and is four octets in length. 2.5.6. Maximum Bandwidth The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that can be used on this link in this direction (from the system originating the LSA to its neighbor), in IEEE floating point format. This is the true link capacity. The units are bytes per second. The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in 2.5.7. Maximum Reservable Bandwidth The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). This SHOULD be user-configurable; the default value should be the Maximum Bandwidth. The units are bytes per second. The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four octets in length. 2.5.8. Unreserved Bandwidth The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels, in IEEE floating point format. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub- TLV, and priority 7 at the end of the sub-TLV. The initial values (before any bandwidth is reserved) are all set to the Maximum Reservable Bandwidth. Each value will be less than or equal to the Maximum Reservable Bandwidth. The units are bytes per second. The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in length. 2.5.9. Administrative Group The Administrative Group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface. A link may belong to multiple groups. By convention the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'. The Administrative Group is also called Resource Class/Color [2]. The Administrative Group sub-TLV is TLV type 9, and is four octets in length. 3. Elements of Procedure Routers shall originate Traffic Engineering LSAs whenever the LSA contents change, and whenever otherwise required by OSPF (an LSA refresh, for example). Note that this does not mean that every change must be flooded immediately; an implementation MAY set thresholds (for example, a bandwidth change threshold) that trigger immediate flooding, and initiate flooding of other changes after a short time interval. In any case, the origination of Traffic Engineering LSAs SHOULD be rate-limited to at most one every MinLSInterval [1]. Upon receipt of a changed Traffic Engineering LSA or Network LSA (since these are used in traffic engineering calculations), the router should update its traffic engineering database. No SPF or other route calculations are necessary. 4. Compatibility Issues There should be no interoperability issues with routers that do not implement these extensions. OSPFv3 [RFC2740] already defines ways to handle unknown LSA types. As the U-bit is not set the LSA is treated as a Link-Local LSA by a router which does not understand the LSA type. The result of having routers that do not implement these extensions is that the traffic engineering topology will be missing pieces; however, if the topology is connected, TE paths can still be calculated and ought to work. 5. Normative References 6. Informative References 7. Security Considerations This document specifies the contents of Intr-Area-TE LSAs in OSPFv3. As the LSA's are not used for SPF computation or normal routing, the extensions specified here have no affect on IP routing. Tampering with TE LSAs may have an effect on traffic engineering computations, however, and it is suggested that whatever mechanisms are used for securing the transmission of normal OSPFv3 LSAs be applied equally to all TE LSA's. 8. IANA Considerations 9. Authors' Addresses Vishwas Manral Netplane Systems, 189, Prashasan Nagar, Road Number 72, Jubilee Hills, Hyderabad - 33 INDIA 10. IPR Notices 11. Full Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 09:51:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16983 for ; Wed, 9 Oct 2002 09:51:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00761C45@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 9:53:21 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 270991 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 09:53:21 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 09:53:21 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00761DB0@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 9:53:21 -0400 Message-ID: Date: Wed, 9 Oct 2002 09:53:21 -0400 Reply-To: Mailing List Sender: Mailing List From: Katrien Scharre Subject: Summary-LSA section 12.4.3 of RFC2328 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list In section 12.4.3 of the rfc, i would like to refer to bullet 7 : 'Else, the Destination type is network. If this is an inter-area route, .... ' In this section, nothing is mentioned on condensation of the information by means of the configured list of address ranges like described under bullet8. Is this explicilty forbidden or do there exists some routers which handles inter-area and intra-area routes like described in bullet 8 ? From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 10:34:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19758 for ; Wed, 9 Oct 2002 10:34:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00761E5F@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 10:36:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 271155 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 10:36:32 -0400 Received: from 12.236.104.233 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 10:36:32 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id KAA00711; Wed, 9 Oct 2002 10:38:44 -0400 References: User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Wed, 9 Oct 2002 07:38:43 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: "Manral, Vishwas" To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list >One small correction Link-ID sub TLV length would always be 4-bytes i.e. >Interface ID or Router Id of neigbor. Interface ID or Router Id is not enough to identify Network-LSA in OSPFv3. Would you mind to check my draft draft-ishiguro-ospf-ospfv3-traffic-00.txt? I've submitted it last night. Hopefully it will be accepted soon. 3.1 Neighbor ID In OSPFv2, Link ID is unique key to identify Network LSA. In OSPFv3 to identify Network LSA, the combination of Neighbor Interface ID and Neighbor Router ID is needed. So new sub-TLV Neighbor ID is defined. The Neighbor ID sub-TLV is TLV type 9, and is 8 octets in length. It contains 4 octet Neighbor Interface ID following 4 octet Neighbor Router ID. Neighbor Interface ID and Neighbor Router ID value is same as described in [OSPFV3] A.4.3 Router-LSAs. -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 10:40:40 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20048 for ; Wed, 9 Oct 2002 10:40:40 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00761DD7@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 10:42:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 271190 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 10:42:45 -0400 Received: from 12.236.104.233 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 10:42:45 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id KAA00737; Wed, 9 Oct 2002 10:46:01 -0400 References: <200210090307.g9937Qd03084@kummer.juniper.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Wed, 9 Oct 2002 07:46:00 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: Kireeti Kompella To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210090307.g9937Qd03084@kummer.juniper.net> Precedence: list >If you're doing this, I have two requests: >a) Please avoid redefining sub-TLVs 1-16 of the Link TLV; OK. I've used 9,10,11 in OSPFv3 TE draft. I'll change it. >b) Make the new sub-TLVs applicable to both OSPFv2 and v3. > >BTW, diffserv TE and GMPLS are just subcases of TE. I'd suggest that > draft-katz-yeung-ospf-traffic-08.txt, > draft-ietf-tewg-diff-te-proto-01.txt and > draft-ietf-ccamp-ospf-gmpls-extensions-08.txt >be cited normatively in your draft. So far I have below point to make it applicable OSPFv2 extensions to OSPFv3. 1. IPv4 address Whe the draft refer IPv4 address, IPv6 address support should be there. 2. IPv6 address When draft flood IP address to no local flooding scope, link-local address should not be flooded. It is not valid address outside link local. 3. Router Address TLV for Router ID When draft use Router Address TLV for referring Router ID. That is realy Router ID in OSPFv3 and the address may not be reachable. 4. Identification key for Network-LSA Identification key for Network-LSA (there is a case we have to map LSA to Network-LSA) is not same as in OSPFv2. In OSPFv3 Neighbor Interface ID and Neighbor Router ID is needed. -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 10:43:19 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20168 for ; Wed, 9 Oct 2002 10:43:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00761E0A@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 10:45:22 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 271224 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 10:45:22 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 10:45:22 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3NZK>; Wed, 9 Oct 2002 10:45:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 9 Oct 2002 10:47:37 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: Kunihiro Ishiguro To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Kunihiro Ishiguro, The Link-Id is supposed to identify the other end of the link not just Network LSA(which is originated only for multiaccess links). So for Point-to-Point links it would be the router-ID alone(4-bytes). While for multiaccess links it would be the router-ID and the Interface-Id(8-bytes). Isnt that the case? Thanks for the comment. Please let me know if you have any other comments on the draft I have posted. Thanks, Vishwas -----Original Message----- From: Kunihiro Ishiguro [mailto:kunihiro@zebra.org] Sent: Wednesday, October 09, 2002 8:09 PM To: Manral, Vishwas Cc: Mailing List Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 >One small correction Link-ID sub TLV length would always be 4-bytes i.e. >Interface ID or Router Id of neigbor. Interface ID or Router Id is not enough to identify Network-LSA in OSPFv3. Would you mind to check my draft draft-ishiguro-ospf-ospfv3-traffic-00.txt? I've submitted it last night. Hopefully it will be accepted soon. 3.1 Neighbor ID In OSPFv2, Link ID is unique key to identify Network LSA. In OSPFv3 to identify Network LSA, the combination of Neighbor Interface ID and Neighbor Router ID is needed. So new sub-TLV Neighbor ID is defined. The Neighbor ID sub-TLV is TLV type 9, and is 8 octets in length. It contains 4 octet Neighbor Interface ID following 4 octet Neighbor Router ID. Neighbor Interface ID and Neighbor Router ID value is same as described in [OSPFV3] A.4.3 Router-LSAs. -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 10:46:33 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20301 for ; Wed, 9 Oct 2002 10:46:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00761E14@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 10:48:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 271272 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 10:48:37 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 10:48:36 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id A3AEC1B8EEE for ; Wed, 9 Oct 2002 07:48:35 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA441BE.5080708@redback.com> Date: Wed, 9 Oct 2002 10:48:30 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Summary-LSA section 12.4.3 of RFC2328 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Katrien Scharre wrote: > In section 12.4.3 of the rfc, i would like to refer to bullet 7 : 'Else, the > Destination type is network. If this is an inter-area route, .... ' > > > In this section, nothing is mentioned on condensation of the information by > means of the configured list of address ranges like described under bullet8. Address ranges are for condensing intra-area routes which are advertised by an ABR into other areas. They do not apply to the advertisement of inter-area routes into attached areas. > > Is this explicilty forbidden or do there exists some routers which handles > inter-area and intra-area routes like described in bullet 8 ? In answer to your questions, I don't know of any OSPF implementation that provides a proprietary mechanism to condense type 3 LSAs using a range-like configuration. There are implementations that allow type 3 LSAs to filtered filtered when advertised into an area. I'm not a big fan of these since I really think the mechanisms provided by the protocol are enough and their use limits interoperability between ABRs. > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 11:40:22 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22353 for ; Wed, 9 Oct 2002 11:40:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0076215A@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 11:42:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 271580 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 11:42:25 -0400 Received: from 216.136.173.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 11:42:25 -0400 Received: from [192.25.240.225] by web12705.mail.yahoo.com via HTTP; Wed, 09 Oct 2002 08:42:24 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20021009154224.13357.qmail@web12705.mail.yahoo.com> Date: Wed, 9 Oct 2002 08:42:24 -0700 Reply-To: Mailing List Sender: Mailing List From: Suvani Kaura Subject: OSPFv3 Intra area prefix LSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi All, Is it legal for an Intra Area Prefix LSA to be advertised with zero prefixes? Case in point: if a router with a single interface running OSPFv3 is DR but there is no active router on that link, it originates an intra area prefix lsa referencing its router LSA. Subsequently another router (DR-other) comes up on that link, & therefore the DR originates a Network LSA & moves the prefix information to the intra area prefix lsa referencing the network LSA. Should it now withdraw its old intra area prefix lsa referencing the router LSA or should it re-advertise it with zero prefixes? Thanks for your input, Suvani __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 13:24:24 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26344 for ; Wed, 9 Oct 2002 13:24:24 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00762434@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 13:26:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 272017 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 13:26:28 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 13:26:28 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g99HQSm74801; Wed, 9 Oct 2002 10:26:28 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g99HQS505227; Wed, 9 Oct 2002 10:26:28 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210091726.g99HQS505227@kummer.juniper.net> Date: Wed, 9 Oct 2002 10:26:28 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: kunihiro@zebra.org To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list > OK. I've used 9,10,11 in OSPFv3 TE draft. I'll change it. Thanks! > 1. IPv4 address > > Whe the draft refer IPv4 address, IPv6 address support should be > there. My point is that there is no reason in principle that the v2 draft should not carry IPv6 addresses, or that the v3 draft should not carry IPv4 addresses. In fact, if TE is used to set up RSVP LSPs, then it is worth noting that RSVP/IPv4 can signal tunnels addressed by IPv6. So, I would prefer that document say explicitly that the new TLVs for IPv6 addresses can be used in both v2 TE and v3 TE. If that's what you've done (I'm still waiting for your draft to post), great! > 2. IPv6 address > > When draft flood IP address to no local flooding scope, link-local > address should not be flooded. It is not valid address outside link > local. If you mean there's no use flooding link local IPv6 addresses, agreed. Note that unnumbered support is already there (see the GMPLS draft). > 4. Identification key for Network-LSA > > Identification key for Network-LSA (there is a case we have to map LSA > to Network-LSA) is not same as in OSPFv2. In OSPFv3 Neighbor > Interface ID and Neighbor Router ID is needed. Okay. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 13:37:55 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26804 for ; Wed, 9 Oct 2002 13:37:55 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00762494@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 13:39:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 272218 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 13:39:59 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 13:39:59 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17zKoQ-000HMR-00; Wed, 09 Oct 2002 10:39:58 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <183526806157.20021009103805@psg.com> Date: Wed, 9 Oct 2002 10:38:05 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Welcome new WG co-chairs Comments: cc: Bill Fenner , Acee Lindem , Rohit Dube To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Folks- As you know, Bill and I have been working on finding the co-chairs for the OSPF WG. We're happy to inform the WG that the process has been completed. Acee Lindem and Rohit Dube were selected as the co-chairs. John will continue to be a co-chair and will be helping Acee and Rohit with their new role. Please welcome Acee and Rohit. Thank you. Alex and Bill From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 13:55:20 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27337 for ; Wed, 9 Oct 2002 13:55:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00762618@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 13:57:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 272427 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 13:57:25 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 13:57:25 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g99HvOm77393 for ; Wed, 9 Oct 2002 10:57:24 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g99HvOd05387 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 10:57:24 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210091757.g99HvOd05387@kummer.juniper.net> Date: Wed, 9 Oct 2002 10:57:24 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list > To summarize the discussion I guess Kireeti's approach helps in reducing the > workload for the working group and getting the specs out faster(especially > TE). I do not think "mapping" can cause problems as long as in each draft > using opaque LSA's we give information for both v2 and v3. You'll make yourself pretty unpopular with the AD if you keep that up :-) > a) How would we want to go ahead with docs like "Graceful Restart" which are > still in draft state and haven't gone LC etc? We could as well have v3 > additions in the existing drafts. Actually, all the TE-related work is also in draft stage. The base TE doc is pretty far along, though, and I would prefer not to pull it back at this point. That is why I suggested putting the IPv6 TLVs in the GMPLS doc (which I view as an update to the TE doc). That way, the v3 doc only needs to define an LS Function Code, map Instances to LS IDs, and "ratify" that all TE TLVs/sub-TLVs work in v3. Consider for example a network with an IPv4 control plane and IPv6 data plane. RSVP-TE already has support for signaling in IPv4 an ERO with IPv6 addresses; all it needs is a TE database with IPv6. So making the new TLVs v3-only is unnecessary and unhelpful. This can of course be taken care of with careful wording in the v3 TE draft. Since we're already on the path of maximal work, why don't you and Kunihiro get together and bash out one TE draft instead of two? Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 14:49:15 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29341 for ; Wed, 9 Oct 2002 14:49:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0076272B@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 14:51:20 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 272723 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 14:51:20 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 14:50:16 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 91F935D021; Thu, 10 Oct 2002 03:50:14 +0900 (JST) References: <20021009154224.13357.qmail@web12705.mail.yahoo.com> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021010.035004.12342476.yasu@sfc.wide.ad.jp> Date: Thu, 10 Oct 2002 03:50:04 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: OSPFv3 Intra area prefix LSA Comments: To: bg24096@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021009154224.13357.qmail@web12705.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Hi. My view is "legal, but should be avoided". I guess it can be thought as a inefficiency of the implementation. I get a similar feeling from the implementation that generates multiple AS-External LSAs for a single prefix... The answer should be "withdraw rather than re-advertise". regards, yasu bg24096> Hi All, bg24096> bg24096> Is it legal for an Intra Area Prefix LSA to be advertised with zero bg24096> prefixes? bg24096> bg24096> Case in point: if a router with a single interface running OSPFv3 is bg24096> DR but there is no active router on that link, it originates an intra bg24096> area prefix lsa referencing its router LSA. Subsequently another bg24096> router (DR-other) comes up on that link, & therefore the DR bg24096> originates a Network LSA & moves the prefix information to the intra bg24096> area prefix lsa referencing the network LSA. Should it now withdraw bg24096> its old intra area prefix lsa referencing the router LSA or should it bg24096> re-advertise it with zero prefixes? bg24096> bg24096> Thanks for your input, bg24096> Suvani bg24096> bg24096> __________________________________________________ bg24096> Do you Yahoo!? bg24096> Faith Hill - Exclusive Performances, Videos & More bg24096> http://faith.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 18:00:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06048 for ; Wed, 9 Oct 2002 18:00:36 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00763074@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 18:02:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 273261 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 18:02:40 -0400 Received: from 63.165.80.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 18:02:39 -0400 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Oct 2002 12:09:41 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8AC36D3167EED41184C800508BD954050320B7EB@apollo.adtech-inc.com> Date: Wed, 9 Oct 2002 12:09:32 -1000 Reply-To: Mailing List Sender: Mailing List From: "Singh, Gurpreet" Subject: Padding for OSPF packets in the OSPF implementations To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi OSPF spec RFC 2328 does not allow any padding field for extra bytes for the OSPF pakcets. Consider the following situation. <<...OLE_Obj...>> The IP packet length in the IP header covers the Junk bytes. But the OSPF header does not. If such a OSPF packet is received should the implementations accept this packet as a valid packet or ignore it ? I know this is a implementation specific question but what would be the correct implementation according to the protocol specification. Thanks Gurpreet From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 18:09:13 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06211 for ; Wed, 9 Oct 2002 18:09:13 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00763038@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 18:11:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 273328 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 18:11:18 -0400 Received: from 63.165.80.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 18:11:18 -0400 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Oct 2002 12:18:21 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8AC36D3167EED41184C800508BD954050320B7EC@apollo.adtech-inc.com> Date: Wed, 9 Oct 2002 12:18:20 -1000 Reply-To: Mailing List Sender: Mailing List From: "Singh, Gurpreet" Subject: Padding for OSPF packets in the OSPF implementations To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi OSPF spec RFC 2328 does not allow any padding field for extra bytes for the OSPF pakcets. Consider the following situation. ________________________________________________________________________ | IP Header | OSPF Header | OSPF Payload | Junk bytes | | | | | | ________________________________________________________________________ |-----------------------------------------IP Header Length-----------------------------------| |-----------------------OSPF Packet Length ---------------------------------| The IP packet length in the IP header covers the Junk bytes. But the OSPF header does not. If such a OSPF packet is received should the implementations accept this packet as a valid packet or ignore it ? I know this is a implementation specific question but what would be the correct implementation according to the protocol specification. Thanks Gurpreet From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 18:25:05 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06461 for ; Wed, 9 Oct 2002 18:25:04 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00762F9C@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 18:27:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 273388 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 18:27:09 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 18:27:09 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 3CC49406240 for ; Wed, 9 Oct 2002 15:27:07 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <8AC36D3167EED41184C800508BD954050320B7EC@apollo.adtech-inc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA4AD31.90107@redback.com> Date: Wed, 9 Oct 2002 18:26:57 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Padding for OSPF packets in the OSPF implementations To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Gurpreet, How does one find the start of the OSPF header if there are junk bytes between the IPv4 header and the OSPF header? This doesn't seem valid to me. On a related topic, I feel packets with padding on the end should be accepted. This is in the spirit of RFC 1958 suggesting to be tolerant when accepting and conservative when sending (I believe this comes from an earliar Jon Postal quote). Note that draft-nguyen-ospf-lls-01.txt depends on packets with a longer IP length being accepted for backward compatibility. Singh, Gurpreet wrote: > Hi > > OSPF spec RFC 2328 does not allow any padding field for extra bytes for the > OSPF pakcets. > > Consider the following situation. > > > ________________________________________________________________________ > | IP Header | OSPF Header | OSPF Payload > | Junk bytes | > | | | > | | > ________________________________________________________________________ > > > |-----------------------------------------IP Header > Length-----------------------------------| > |-----------------------OSPF Packet Length > ---------------------------------| > > > > The IP packet length in the IP header covers the Junk bytes. But the OSPF > header does not. > > If such a OSPF packet is received should the implementations accept this > packet as a valid packet or ignore it ? > > I know this is a implementation specific question but what would be the > correct implementation according to the protocol specification. > > Thanks > > Gurpreet > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 18:27:58 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06497 for ; Wed, 9 Oct 2002 18:27:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00762EEC@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 18:30:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 273412 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 18:30:03 -0400 Received: from 63.165.80.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 18:30:01 -0400 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Oct 2002 12:37:04 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8AC36D3167EED41184C800508BD954050320B7ED@apollo.adtech-inc.com> Date: Wed, 9 Oct 2002 12:36:58 -1000 Reply-To: Mailing List Sender: Mailing List From: "Singh, Gurpreet" Subject: Re: Padding for OSPF packets in the OSPF implementations To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Thanks Acee. I think the picture was not very clear in the e-mail. I was refering to the padding at the end itself. Gurpreet -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Wednesday, October 09, 2002 6:27 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Padding for OSPF packets in the OSPF implementations Gurpreet, How does one find the start of the OSPF header if there are junk bytes between the IPv4 header and the OSPF header? This doesn't seem valid to me. On a related topic, I feel packets with padding on the end should be accepted. This is in the spirit of RFC 1958 suggesting to be tolerant when accepting and conservative when sending (I believe this comes from an earliar Jon Postal quote). Note that draft-nguyen-ospf-lls-01.txt depends on packets with a longer IP length being accepted for backward compatibility. Singh, Gurpreet wrote: > Hi > > OSPF spec RFC 2328 does not allow any padding field for extra bytes for the > OSPF pakcets. > > Consider the following situation. > > > ________________________________________________________________________ > | IP Header | OSPF Header | OSPF Payload > | Junk bytes | > | | | > | | > ________________________________________________________________________ > > > |-----------------------------------------IP Header > Length-----------------------------------| > |-----------------------OSPF Packet Length > ---------------------------------| > > > > The IP packet length in the IP header covers the Junk bytes. But the OSPF > header does not. > > If such a OSPF packet is received should the implementations accept this > packet as a valid packet or ignore it ? > > I know this is a implementation specific question but what would be the > correct implementation according to the protocol specification. > > Thanks > > Gurpreet > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 18:33:33 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06591 for ; Wed, 9 Oct 2002 18:33:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00763083@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 18:35:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 273441 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 18:35:38 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 18:35:38 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl133-19.cisco.com [144.254.54.214]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g99MZa025845 for ; Wed, 9 Oct 2002 15:35:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Wed, 9 Oct 2002 15:35:37 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPFv3 Intra area prefix LSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021009154224.13357.qmail@web12705.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Suvani To add to what Yasu already said, re-advertising with zero prefix behavior could further not work in all cases ( so not a generic solution ) for example when you your router has some prefix with AL bit set ( /128) then those prefixes are Not added to intra-area prefix referencing network LSA and you have to keep it in intra-area prefix referncing a Router LSA, therefore you have to maxage only some prefixes but not all of them .. Sina > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of > Suvani Kaura > Sent: Wednesday, October 09, 2002 8:42 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: OSPFv3 Intra area prefix LSA > > > Hi All, > > Is it legal for an Intra Area Prefix LSA to be advertised with zero > prefixes? > > Case in point: if a router with a single interface running OSPFv3 is > DR but there is no active router on that link, it originates an intra > area prefix lsa referencing its router LSA. Subsequently another > router (DR-other) comes up on that link, & therefore the DR > originates a Network LSA & moves the prefix information to the intra > area prefix lsa referencing the network LSA. Should it now withdraw > its old intra area prefix lsa referencing the router LSA or should it > re-advertise it with zero prefixes? > > Thanks for your input, > Suvani > > __________________________________________________ > Do you Yahoo!? > Faith Hill - Exclusive Performances, Videos & More > http://faith.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 18:43:19 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06774 for ; Wed, 9 Oct 2002 18:43:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00763160@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 18:45:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 273477 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 18:45:23 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 18:45:23 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA20241 for ; Wed, 9 Oct 2002 18:45:20 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA12902 for ; Wed, 9 Oct 2002 18:45:22 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4QY91VZ4>; Wed, 9 Oct 2002 18:45:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557633BE@vie-msgusr-01.dc.fore.com> Date: Wed, 9 Oct 2002 18:45:20 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Padding for OSPF packets in the OSPF implementations To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -> The IP packet length in the IP header covers the Junk bytes. -> But the OSPF header does not. There are some situation even in RFC2328 (example MD5 message digest) some data is written past OSPF packet but not counted as OSPF packet length. RFC2328 page 232 reads: (d) The MD5 digest is written over the OSPF key (i.e., appended to the original OSPF packet). The digest is not counted in the OSPF packet's length field, but is included in the packet's IP length field. Any trailing pad or length fields beyond the digest are not counted or transmitted. -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 20:45:42 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08952 for ; Wed, 9 Oct 2002 20:45:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00763420@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 20:47:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 273632 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 20:47:43 -0400 Received: from 134.56.3.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 20:37:42 -0400 Received: from mx02-int.net.com (mx02-int.net.com [134.56.112.14]) by mx01.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id g9A0VeL20314 for ; Wed, 9 Oct 2002 17:31:40 -0700 (PDT) Received: from west-mail.net.com (west-mail.net.com [134.56.112.40]) by mx02-int.net.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9A0aZl28910 for ; Wed, 9 Oct 2002 17:36:35 -0700 (PDT) Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA394E for ; Wed, 9 Oct 2002 17:37:46 -0700 X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3DA4CBD8.E19C35F4@net.com> Date: Wed, 9 Oct 2002 17:37:44 -0700 Reply-To: Mailing List Sender: Mailing List From: Mani Devarajan Organization: N.E.T. http://www.net.com Subject: Question wrt to default route generated by stub-ABR: To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi all, ASBR ----- ------ ----- ------- | | | | | | | | | R1 | | R2 | | R3 | | R5 | | | | | | | | | ----- ------ ----- ------- | |I1 I2| | |I4 I5| |I6 I9| | RIP--- ----- | ------ ----- | AREA1 | AREA 0 AREA2 | |I3 |I10 | ----- | | I7| |I8 | -----| R4 |------- AREA0 | | AREA2 ----- * AREA2 is configured for Stub In the above scenario, both ABR's(R4,R3) of Area2 generates a default route. If R5 considers the default route through R4 to reach the external network and if I bring down the I7 interface on R4, I observed that R4 flushes the summary LSA's it generated in Area2 except for the default-summary-LSA. Is it correct behaviour. My doubt is, as R4 is not an ABR anymore (it is just an internal router in Area2 after setting I7 down) is it correct to have the default-summary-LSA genereated by R4 in Area2 database instead of flushing it. Thanks in advance, -Mani From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 9 22:20:38 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10900 for ; Wed, 9 Oct 2002 22:20:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0076381D@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 22:22:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 274027 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 22:22:37 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 22:22:37 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id EC1BA4BA213 for ; Wed, 9 Oct 2002 19:22:34 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <3DA4CBD8.E19C35F4@net.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA4E45F.1070109@redback.com> Date: Wed, 9 Oct 2002 22:22:23 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question wrt to default route generated by stub-ABR: To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mani, You are correct, R4 should purge it's default summary advertisement since it is no longer an ABR. Thanks, Acee Mani Devarajan wrote: > Hi all, > > > ASBR > ----- ------ ----- ------- > | | | | | | | | > | R1 | | R2 | | R3 | | R5 | > | | | | | | | | > ----- ------ ----- ------- > | |I1 I2| | |I4 I5| |I6 I9| | > RIP--- ----- | ------ ----- | > AREA1 | AREA 0 AREA2 | > |I3 |I10 > | ----- | > | I7| |I8 | > -----| R4 |------- > AREA0 | | AREA2 > ----- > > * AREA2 is configured for Stub > > In the above scenario, both ABR's(R4,R3) of Area2 > generates a default route. If R5 considers the default > route through R4 to reach the external network and > if I bring down the I7 interface on R4, I observed > that R4 flushes the summary LSA's it generated in > Area2 except for the default-summary-LSA. Is it > correct behaviour. > > My doubt is, as R4 is not an ABR anymore (it is > just an internal router in Area2 after setting I7 > down) is it correct to have the default-summary-LSA > genereated by R4 in Area2 database instead of flushing > it. > > Thanks in advance, > -Mani > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 10 03:31:08 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24680 for ; Thu, 10 Oct 2002 03:31:08 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.007643BF@cherry.ease.lsoft.com>; Thu, 10 Oct 2002 3:33:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 275237 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Oct 2002 03:33:13 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 10 Oct 2002 03:33:13 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3PB5>; Thu, 10 Oct 2002 03:33:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 10 Oct 2002 03:35:31 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Kireeti, >> To summarize the discussion I guess Kireeti's approach helps in reducing the >> workload for the working group and getting the specs out faster(especially >> TE). I do not think "mapping" can cause problems as long as in each draft >> using opaque LSA's we give information for both v2 and v3. >You'll make yourself pretty unpopular with the AD if you keep that up :-) I guess I m just voicing my opinion and the AD's understand that.;-) >> a) How would we want to go ahead with docs like "Graceful Restart" which are >> still in draft state and haven't gone LC etc? We could as well have v3 >> additions in the existing drafts. > Consider for example a network with an IPv4 control plane and IPv6 > data plane. RSVP-TE already has support for signaling in IPv4 an ERO > with IPv6 addresses; all it needs is a TE database with IPv6. So > making the new TLVs v3-only is unnecessary and unhelpful. This can > of course be taken care of with careful wording in the v3 TE draft. Ok will do that. > Since we're already on the path of maximal work, why don't you and > Kunihiro get together and bash out one TE draft instead of two? I am ok with merging the two drafts to prevent any duplication of work. Kunihiro? Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 10 07:03:33 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28040 for ; Thu, 10 Oct 2002 07:03:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0076458D@cherry.ease.lsoft.com>; Thu, 10 Oct 2002 7:05:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 276417 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Oct 2002 07:05:37 -0400 Received: from 66.218.78.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 10 Oct 2002 07:05:37 -0400 Received: from [203.200.20.226] by web40305.mail.yahoo.com via HTTP; Thu, 10 Oct 2002 04:05:36 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20021010110536.71082.qmail@web40305.mail.yahoo.com> Date: Thu, 10 Oct 2002 04:05:36 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Database Over Flow Query!! To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi All, Actually i was going through the RFC 1765 where in it states that when the timer expires the router leaves OverflowState and begins originating non-default AS-external-LSAs again. SO does it mean that it need to reoriginate all the flushed self originated As-External LSAs again or it means that it is not mandatory to originate all the flushed self originated non-defualt As-External LSAs but from now on we can originate any new self originated LSA. Please Answer if anyone know the solution. Regards Amit __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 10 09:45:09 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03808 for ; Thu, 10 Oct 2002 09:45:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.007649F5@cherry.ease.lsoft.com>; Thu, 10 Oct 2002 9:47:14 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 276880 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Oct 2002 09:47:14 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 10 Oct 2002 09:47:14 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl133-19.cisco.com [144.254.54.214]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9ADl7018789 for ; Thu, 10 Oct 2002 06:47:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Thu, 10 Oct 2002 06:47:07 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Database Over Flow Query!! To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021010110536.71082.qmail@web40305.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Amit > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Amit > Srivastava > Sent: Thursday, October 10, 2002 4:06 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Database Over Flow Query!! > > > Hi All, > Actually i was going through the RFC 1765 where in > it states that when the timer expires the router > leaves > OverflowState and begins originating non-default > AS-external-LSAs again. SO does it mean that it need > to reoriginate all the flushed self originated > As-External LSAs again or it means that it is not > mandatory to originate all the flushed self originated > non-defualt As-External LSAs but from now on we can > originate any new self originated LSA. what do you mean by 'new self originated LSA'? since all non-default type 5 LSA have been flushed out whatever type 5 the router generates can be considered as 'new instance' when the router leaves OverflowState after ospfExitOverflowInterval it will simply reoriginate / originate whatever type 5 it needs to generate, given that it remains below ospfExtLsdbLimit Sina > Please Answer if anyone know the solution. > Regards > Amit > > __________________________________________________ > Do you Yahoo!? > Faith Hill - Exclusive Performances, Videos & More > http://faith.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 10 12:09:57 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13182 for ; Thu, 10 Oct 2002 12:09:57 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.007652B0@cherry.ease.lsoft.com>; Thu, 10 Oct 2002 12:12:01 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 277568 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Oct 2002 12:12:00 -0400 Received: from 64.139.11.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 10 Oct 2002 12:12:00 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id LAA00932; Thu, 10 Oct 2002 11:45:45 -0400 References: User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Thu, 10 Oct 2002 08:45:45 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: "Manral, Vishwas" To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list >I am ok with merging the two drafts to prevent any duplication of work. >Kunihiro? Sure. -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 10 13:03:38 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15214 for ; Thu, 10 Oct 2002 13:03:37 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.007655D8@cherry.ease.lsoft.com>; Thu, 10 Oct 2002 13:05:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 277674 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Oct 2002 13:05:42 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 10 Oct 2002 13:05:42 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA24886 for ; Thu, 10 Oct 2002 13:05:40 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12633 for ; Thu, 10 Oct 2002 13:05:41 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4QY9FQ0S>; Thu, 10 Oct 2002 13:05:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557633BF@vie-msgusr-01.dc.fore.com> Date: Thu, 10 Oct 2002 13:05:39 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Kireeti & Alex, I am late into the field - please excuse and consider my points. -> > (c) is, if I understand you correctly, the approach you -> are suggesting. -> -> Not necessarily on a section-by-section/TLV-by-TLV basis as you -> mentioned above. Instead, if, for example, we need to get the TE -> extensions into v3, we would come up with a -> draft-ospf-ospfv3-katz-yueng -> and specify the LS Type for TE LSAs, refer to katz-yueng for things -> like body formatting, enumerate TLVs (by reference, not value) that -> are IP-version independent and are valid for v3, and then go and -> address the IPv6 specific details. Kireeti has a very valid point here. Alex's point is independent of what we (MPLS folks) have to do at this point of time. I view MPLS-TE a "service user" of OSPF (v2 or v3) "a service provider" for flooding the information transparently to other side of MPLS-TE layer. If, by chance, OSPFv3 is running in the topology, and If the application (here, for example, still MPLS-TE for IPv4) would like to pass the info (OSPF should not care about what the information is) to the other side, then it should. *Application* (for example MPLS-TE for IPv4) knows what is the info - here it is still IPv4 - for the reasons mentioned by Kireeti. Alex, let me put it in other way - define a LS Type in OSPF v3 and call it "User defined LS Type" and reserve *one* (just one) for OSPF v2 Opaque LSAs. Now with very minimal changes, all the IPv4 applications which used OSPF v2 Opaque LSAs can be flooded even when OSPF v3 is running in the network. Alex's point is valid when MPLS-TE for IPv6 (which is different application when compared to MPLS-TE for IPv4) is used in the network. For this, any way, we need a clear draft which considers IPv6 requirements, etc etc. Alex, there are almost nearly 20 different IPv4 applications using OSPF v2 Opaque LSAs (MPLS-TE is just one of them). So please consider the fact that, all those applications must work if the version of OSPF is changed from v2 to v3 with minimal work. Bottom Line: It is the application who decides whether to write a new draft for IPv6 or not by taking the new requirements for IPv6 (if there are any). A service provider (here OSPF) should not ask applications to change their behavior or information when it's own operation/version changes. What it should possible do is, provide a transport mechanism (a SAP) to all those previous applications, so that the information is flooded intact. Please don't think otherwise - kindly interrupt me if I am not in the same page :) -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 10 14:52:19 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19548 for ; Thu, 10 Oct 2002 14:52:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0076571F@cherry.ease.lsoft.com>; Thu, 10 Oct 2002 14:54:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 277988 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Oct 2002 14:54:24 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 10 Oct 2002 14:54:24 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9AIsNm89382 for ; Thu, 10 Oct 2002 11:54:23 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g9AIsNu09615 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Oct 2002 11:54:23 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210101854.g9AIsNu09615@kummer.juniper.net> Date: Thu, 10 Oct 2002 11:54:23 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC557633BF@vie-msgusr-01.dc.fore.com> Precedence: list Thanks for your support, Venkata! One thing I would like to reiterate: there are a *small* number of currently defined Opaque LSAs -- TE, Grace LSA, and perhaps one more. If we analyse the applicability of those LSAs to OSPF v3, and mandate that any future definition of an OSPFv2 Opaque LSA MUST have a similar analysis, that seems to me to address the "backdoor" problem. The "backdoor" issue is an excellent example of a *theoretical* problem that has little *practical* relevance, given the above mandate. As a consequence, we have at least two independent efforts to migrate just the TE document to v3, when in fact it should be really simple. Then we do it again for Grace LSAs. And possibly again in the future. And then we hear that the IETF is overloaded, and the IESG overburdened. Oh, well ... Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 10 14:54:21 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19661 for ; Thu, 10 Oct 2002 14:54:21 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0076573B@cherry.ease.lsoft.com>; Thu, 10 Oct 2002 14:56:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 277957 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Oct 2002 14:56:26 -0400 Received: from 134.56.3.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 10 Oct 2002 14:46:22 -0400 Received: from mx01-int.net.com (mx01-int.net.com [134.56.112.13]) by mx01.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id g9AIeIp26922 for ; Thu, 10 Oct 2002 11:40:18 -0700 (PDT) Received: from west-mail.net.com (west-mail.net.com [134.56.112.40]) by mx01-int.net.com (Switch-2.2.4/Switch-2.2.0) with ESMTP id g9AIXdr16107 for ; Thu, 10 Oct 2002 11:33:39 -0700 (PDT) Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA686C for ; Thu, 10 Oct 2002 11:46:22 -0700 X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 References: <3DA4CBD8.E19C35F4@net.com> <3DA4E45F.1070109@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3DA5CAFD.E06CFE9E@net.com> Date: Thu, 10 Oct 2002 11:46:21 -0700 Reply-To: Mailing List Sender: Mailing List From: Mani Devarajan Organization: N.E.T. http://www.net.com Subject: Re: Question wrt to default route generated by stub-ABR: To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Thanks Acee, and also I just want to correct my question, it is type-7 default LSA that it didnt get flushed and not default-summary-LSA. And also I have one more question wrt same topic, On setting I7 down, R4 has default route through Area2(I8) and R5 has a default route through network on I9 and R3 has a default route through network on I6. But R3 also has a network specific type-5 route to external rip network, so it takes precedence over the default-route. Isnt it routing loop, R3 having a default route through network on the interface I6 and R5 having a default route through network on the interface I9. Acee Lindem wrote: > > Mani, > > You are correct, R4 should purge it's default summary > advertisement since it is no longer an ABR. > > Thanks, > Acee > > Mani Devarajan wrote: > > > Hi all, > > > > > > ASBR > > ----- ------ ----- ------- > > | | | | | | | | > > | R1 | | R2 | | R3 | | R5 | > > | | | | | | | | > > ----- ------ ----- ------- > > | |I1 I2| | |I4 I5| |I6 I9| | > > RIP--- ----- | ------ ----- | > > AREA1 | AREA 0 AREA2 | > > |I3 |I10 > > | ----- | > > | I7| |I8 | > > -----| R4 |------- > > AREA0 | | AREA2 > > ----- > > > > * AREA2 is configured for Stub > > > > In the above scenario, both ABR's(R4,R3) of Area2 > > generates a default route. If R5 considers the default > > route through R4 to reach the external network and > > if I bring down the I7 interface on R4, I observed > > that R4 flushes the summary LSA's it generated in > > Area2 except for the default-summary-LSA. Is it > > correct behaviour. > > > > My doubt is, as R4 is not an ABR anymore (it is > > just an internal router in Area2 after setting I7 > > down) is it correct to have the default-summary-LSA > > genereated by R4 in Area2 database instead of flushing > > it. > > > > Thanks in advance, > > -Mani > > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 10 15:08:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20039 for ; Thu, 10 Oct 2002 15:08:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0076582A@cherry.ease.lsoft.com>; Thu, 10 Oct 2002 15:10:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 278075 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Oct 2002 15:10:22 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 10 Oct 2002 15:10:22 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id DA3FD4F41A3 for ; Thu, 10 Oct 2002 12:10:20 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <3DA4CBD8.E19C35F4@net.com> <3DA4E45F.1070109@redback.com> <3DA5CAFD.E06CFE9E@net.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA5D087.10309@redback.com> Date: Thu, 10 Oct 2002 15:09:59 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question wrt to default route generated by stub-ABR: To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mani Devarajan wrote: > Thanks Acee, and also I just want to correct my > question, it is type-7 default LSA that it didnt > get flushed and not default-summary-LSA. Hello Mani, Ok - in this case it could be either a problem with the OSPF implementation or a configuration problem. If the type 7 is automatically generated by virtue of the fact that it is an NSSA ABR, then the type 7 should be withdrawn when R4 ceases to be an ABR. However, if you have configured R4 to unconditionally originate an external default, then this is a configuration problem. > > And also I have one more question wrt same topic, > On setting I7 down, R4 has default route through Area2(I8) > and R5 has a default route through network on I9 > and R3 has a default route through network on I6. > > But R3 also has a network specific type-5 route > to external rip network, so it takes precedence over the > default-route. > > Isnt it routing loop, R3 having a default route > through network on the interface I6 and R5 having a default > route through network on the interface I9. Yup. > > > Acee Lindem wrote: > >>Mani, >> >>You are correct, R4 should purge it's default summary >>advertisement since it is no longer an ABR. >> >>Thanks, >>Acee >> >>Mani Devarajan wrote: >> >> >>>Hi all, >>> >>> >>> ASBR >>> ----- ------ ----- ------- >>> | | | | | | | | >>> | R1 | | R2 | | R3 | | R5 | >>> | | | | | | | | >>> ----- ------ ----- ------- >>> | |I1 I2| | |I4 I5| |I6 I9| | >>> RIP--- ----- | ------ ----- | >>> AREA1 | AREA 0 AREA2 | >>> |I3 |I10 >>> | ----- | >>> | I7| |I8 | >>> -----| R4 |------- >>> AREA0 | | AREA2 >>> ----- >>> >>> * AREA2 is configured for Stub >>> >>> In the above scenario, both ABR's(R4,R3) of Area2 >>>generates a default route. If R5 considers the default >>>route through R4 to reach the external network and >>>if I bring down the I7 interface on R4, I observed >>>that R4 flushes the summary LSA's it generated in >>>Area2 except for the default-summary-LSA. Is it >>>correct behaviour. >>> >>> My doubt is, as R4 is not an ABR anymore (it is >>>just an internal router in Area2 after setting I7 >>>down) is it correct to have the default-summary-LSA >>>genereated by R4 in Area2 database instead of flushing >>>it. >>> >>>Thanks in advance, >>>-Mani >>> >>> >>> >>-- >>Acee >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 10 22:29:02 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29177 for ; Thu, 10 Oct 2002 22:29:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00766633@cherry.ease.lsoft.com>; Thu, 10 Oct 2002 22:31:08 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 278928 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Oct 2002 22:31:08 -0400 Received: from 192.51.44.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 10 Oct 2002 22:21:08 -0400 Received: from m4.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0205-Fujitsu Gateway) id LAA18980 for ; Fri, 11 Oct 2002 11:21:02 +0900 (JST) (envelope-from takenaga@soft.net.fujitsu.co.jp) Received: from mailhost.soft.net.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.9.3/3.7W-0209-Fujitsu Domain Master) id LAA24138 for ; Fri, 11 Oct 2002 11:21:02 +0900 (JST) (envelope-from takenaga@soft.net.fujitsu.co.jp) Received: from localhost (fire01.soft.net.fujitsu.co.jp [10.22.111.172]) by mailhost.soft.net.fujitsu.co.jp (8.11.6/8.11.6) with ESMTP id g9B2L1H25273; Fri, 11 Oct 2002 11:21:01 +0900 (JST) X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021011.112101.86422822.takenaga@soft.net.fujitsu.co.jp> Date: Fri, 11 Oct 2002 11:21:01 +0900 Reply-To: Mailing List Sender: Mailing List From: TAKENAGA Yoshinobu Subject: Default LSA creation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, I have a question about creation of default lsa into stub areas. (This question may be a FAQ, please suggest the point) Consider this network. area 1 : area 0 (stub) : +--->>(AS extenal path) : | |--R1--| : |--R4--| | |--R2--| | | : | | |--R3--| | |--R6--| : |--R5--| : Here, R2 and R3 are area border router. R4 is AS boundary router. All link have same cost. In such situation, R2 and R3 will create default Type-3 LSA into area 1. R1 will select R2 as nexthop to the AS extenal path through R4. Now, the link state changes to this (R4 lose the link to N1). area 1 : area 0 (stub) : +--->>(AS Extenal path) : N1 | |--R1--| : |XXR4--| | |--R2--| | | : | | |--R3--| | |--R6--| : |--R5--| : In such situation, R2 becomes a blackhole. What is the minimum requirement for R2 to create default Type-3 LSA into stub areas? - having configuration of Area0 - having active interface to Area0 - having "Full" status neighbor in Area0 - other?? # In NSSA with Type7 LSA, same problem will take place. Regards, -- TAKENAGA Yoshinobu, Fujitsu. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 00:14:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01144 for ; Fri, 11 Oct 2002 00:14:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00766A9D@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 0:16:12 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 279219 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 00:16:12 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 00:16:11 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 2D9CE18D3E6 for ; Thu, 10 Oct 2002 21:16:10 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20021011.112101.86422822.takenaga@soft.net.fujitsu.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA65070.3060309@redback.com> Date: Fri, 11 Oct 2002 00:15:44 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Default LSA creation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit TAKENAGA Yoshinobu wrote: > Hi, > > I have a question about creation of default lsa into stub areas. > (This question may be a FAQ, please suggest the point) > > Consider this network. > > area 1 : area 0 > (stub) : +--->>(AS extenal path) > : | > |--R1--| : |--R4--| > | |--R2--| | > | : | > | |--R3--| | > |--R6--| : |--R5--| > : > > Here, R2 and R3 are area border router. > R4 is AS boundary router. > All link have same cost. > > In such situation, R2 and R3 will create default Type-3 LSA into area 1. > R1 will select R2 as nexthop to the AS extenal path through R4. > > Now, the link state changes to this (R4 lose the link to N1). > > area 1 : area 0 > (stub) : +--->>(AS Extenal path) > : N1 | > |--R1--| : |XXR4--| > | |--R2--| | > | : | > | |--R3--| | > |--R6--| : |--R5--| > : > > In such situation, R2 becomes a blackhole. > > What is the minimum requirement for R2 to create default Type-3 LSA > into stub areas? > - having configuration of Area0 > - having active interface to Area0 > - having "Full" status neighbor in Area0 > - other?? Hi Takenaga, The answer is other. The minimum requirement is that the router be an Area Border Router (ABR). Section 3.3 of RFC 2328 defines an ABR as a router that attaches to multiple areas. In the context of RFC 2328, area attachment requires at least one active interface in that area. Some implementations use other definitions of what constitutes an ABR (e.g., refer to draft-ietf-ospf-abr-alt-04.txt). However, using a different ABR definition doesn't handle all situations. Consider R6 and R3 in the figure below: area 1 : area 0 (stub) : +--->>(AS Extenal path) : N1 | |--R1--| : |--R4--| | |--R2--| | | : | | |--R3--| | |--R6--| : |--R5XX| In general, a good OSPF network design will minimize the possibility that the backbone will become partitioned. > > # In NSSA with Type7 LSA, same problem will take place. > > Regards, > > -- > TAKENAGA Yoshinobu, Fujitsu. > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 00:50:11 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01931 for ; Fri, 11 Oct 2002 00:50:11 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00766C2D@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 0:52:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 279291 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 00:52:16 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 00:52:16 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id EAE634BA217 for ; Thu, 10 Oct 2002 21:52:14 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA658E4.7060809@redback.com> Date: Fri, 11 Oct 2002 00:51:48 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: 55th IETF OSPF WG Meeting To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit The OSPF WG will be meeting in Atlanta (although I haven't received confirmation of the date/time yet). Those of you wishing to present at the WG meeting should send a note to Rohit (rohit@xebeo.com) and myself. The WG agenda must be submitted by 11/14. Also note that New I-Ds (the -00 versions) must be sent to internet-drafts@ietf.org by 10/28 and that all updated drafts must be submitted by 11/4. Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 05:13:28 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14778 for ; Fri, 11 Oct 2002 05:13:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.007672EF@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 5:15:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 279861 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 05:15:33 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 05:15:33 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3RAL>; Fri, 11 Oct 2002 05:15:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 11 Oct 2002 05:17:37 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: OSPFv3 TE draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi folks, We are in the process of putting down a document for adding IPv6 TLV's for TE purposes and an LSA type in OSPFv3 for the same. We would want the opinion of the group regarding the setting of the U-bit in the TE-LSA type field. My opinion is that the U-bit should be set to 0, so that any router not recognizing the TE LSA would not forward the LSA any further. This I feel would help in the case where some routers in the area do not recognize the TE LSA while others do. This way redundant TE information would not be flooded in the entire area topology in case only part of the area understands the TE LSA. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 06:06:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15369 for ; Fri, 11 Oct 2002 06:06:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00767305@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 6:08:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 280793 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 06:08:23 -0400 Received: from 192.51.44.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 06:08:23 -0400 Received: from m4.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0205-Fujitsu Gateway) id TAA25137; Fri, 11 Oct 2002 19:08:17 +0900 (JST) (envelope-from takenaga@soft.net.fujitsu.co.jp) Received: from mailhost.soft.net.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.9.3/3.7W-0209-Fujitsu Domain Master) id TAA24456; Fri, 11 Oct 2002 19:08:16 +0900 (JST) (envelope-from takenaga@soft.net.fujitsu.co.jp) Received: from localhost (fire01.soft.net.fujitsu.co.jp [10.22.111.172]) by mailhost.soft.net.fujitsu.co.jp (8.11.6/8.11.6) with ESMTP id g9BA8FH13326; Fri, 11 Oct 2002 19:08:15 +0900 (JST) References: <20021011.112101.86422822.takenaga@soft.net.fujitsu.co.jp> <3DA65070.3060309@redback.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021011.190815.03870603.takenaga@soft.net.fujitsu.co.jp> Date: Fri, 11 Oct 2002 19:08:15 +0900 Reply-To: Mailing List Sender: Mailing List From: TAKENAGA Yoshinobu Subject: Re: Default LSA creation Comments: To: acee@REDBACK.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DA65070.3060309@redback.com> Precedence: list Content-Transfer-Encoding: 7bit From: Acee Lindem Subject: Re: Default LSA creation Date: Fri, 11 Oct 2002 00:15:44 -0400 > TAKENAGA Yoshinobu wrote: > > > Hi, > > > > I have a question about creation of default lsa into stub areas. > > (This question may be a FAQ, please suggest the point) > > > > Consider this network. > > > > area 1 : area 0 > > (stub) : +--->>(AS extenal path) > > : | > > |--R1--| : |--R4--| > > | |--R2--| | > > | : | > > | |--R3--| | > > |--R6--| : |--R5--| > > : > > > > Here, R2 and R3 are area border router. > > R4 is AS boundary router. > > All link have same cost. > > > > In such situation, R2 and R3 will create default Type-3 LSA into area 1. > > R1 will select R2 as nexthop to the AS extenal path through R4. > > > > Now, the link state changes to this (R4 lose the link to N1). > > > > area 1 : area 0 > > (stub) : +--->>(AS Extenal path) > > : N1 | > > |--R1--| : |XXR4--| > > | |--R2--| | > > | : | > > | |--R3--| | > > |--R6--| : |--R5--| > > : > > > > In such situation, R2 becomes a blackhole. > > > > What is the minimum requirement for R2 to create default Type-3 LSA > > into stub areas? > > - having configuration of Area0 > > - having active interface to Area0 > > - having "Full" status neighbor in Area0 > > - other?? > > > Hi Takenaga, > > The answer is other. The minimum requirement is that the > router be an Area Border Router (ABR). Section 3.3 of RFC 2328 defines > an ABR as a router that attaches to multiple areas. In the context of > RFC 2328, area attachment requires at least one active interface in that > area. Some implementations use other definitions of what constitutes > an ABR (e.g., refer to draft-ietf-ospf-abr-alt-04.txt). However, using > a different ABR definition doesn't handle all situations. Consider R6 and > R3 in the figure below: > > > area 1 : area 0 > (stub) : +--->>(AS Extenal path) > : N1 | > |--R1--| : |--R4--| > | |--R2--| | > | : | > | |--R3--| | > |--R6--| : |--R5XX| > > > In general, a good OSPF network design will minimize the possibility > that the backbone will become partitioned. Hi Acee, Thank you for your response. I understand. Some other good solutions(in such IDs) may have confused me. Now my question is cleard with your advice. -- TAKENAGA Yoshinobu, Fujitsu. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 06:34:09 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15768 for ; Fri, 11 Oct 2002 06:34:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00767414@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 6:36:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 280919 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 06:36:16 -0400 Received: from 66.218.78.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 06:36:15 -0400 Received: from [203.200.20.226] by web40307.mail.yahoo.com via HTTP; Fri, 11 Oct 2002 03:36:15 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20021011103615.77057.qmail@web40307.mail.yahoo.com> Date: Fri, 11 Oct 2002 03:36:15 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: Database Over Flow Query!! To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hello Sina, I just wanted to know is it mandatory to re-originate all the flushed non-defualt As-External LSAs after coming out of the overflow state or it is not mandatory. Regards Amit --- Sina Mirtorabi wrote: > Amit > > > -----Original Message----- > > From: Mailing List > [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Amit > > Srivastava > > Sent: Thursday, October 10, 2002 4:06 AM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Database Over Flow Query!! > > > > > > Hi All, > > Actually i was going through the RFC 1765 where > in > > it states that when the timer expires the router > > leaves > > OverflowState and begins originating non-default > > AS-external-LSAs again. SO does it mean that it > need > > to reoriginate all the flushed self originated > > As-External LSAs again or it means that it is not > > mandatory to originate all the flushed self > originated > > non-defualt As-External LSAs but from now on we > can > > originate any new self originated LSA. > > what do you mean by 'new self originated LSA'? since > all non-default type 5 > LSA have been flushed out whatever type 5 the router > generates can be > considered as 'new instance' > > when the router leaves OverflowState after > ospfExitOverflowInterval it will > simply reoriginate / originate whatever type 5 it > needs to generate, given > that it remains below ospfExtLsdbLimit > > Sina > > > > > Please Answer if anyone know the solution. > > Regards > > Amit > > > > __________________________________________________ > > Do you Yahoo!? > > Faith Hill - Exclusive Performances, Videos & More > > http://faith.yahoo.com __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 07:37:22 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17120 for ; Fri, 11 Oct 2002 07:37:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00767625@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 7:39:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 281090 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 07:39:27 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 07:29:27 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16631; Fri, 11 Oct 2002 07:27:20 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200210111127.HAA16631@ietf.org> Date: Fri, 11 Oct 2002 07:27:20 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pillay-esnault-ospf-v3-grace-lsa-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Grace LSA in OSPFv3 Author(s) : P. Pillay-Esnault Filename : draft-pillay-esnault-ospf-v3-grace-lsa-00.txt Pages : 5 Date : 2002-10-10 This memo describes the OSPF version 3 specific Grace LSA TLV for router-id required for broadcast links (equivalent to the TLV 3 in [HITLESS]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pillay-esnault-ospf-v3-grace-lsa-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pillay-esnault-ospf-v3-grace-lsa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-pillay-esnault-ospf-v3-grace-lsa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-10140655.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pillay-esnault-ospf-v3-grace-lsa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-pillay-esnault-ospf-v3-grace-lsa-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-10140655.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 08:17:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18507 for ; Fri, 11 Oct 2002 08:17:35 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00767759@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 8:19:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 281240 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 08:19:41 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 08:19:41 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl133-19.cisco.com [144.254.54.214]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9BCJe012601 for ; Fri, 11 Oct 2002 05:19:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Fri, 11 Oct 2002 05:19:40 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Database Over Flow Query!! To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021011103615.77057.qmail@web40307.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Amit origination of type 5 is a local policy therefore I won't call it mandatory one could start originating prefixes in a progressive manner in order to assure a smooth come back to a normal operation ... Sina > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Amit > Srivastava > Sent: Friday, October 11, 2002 3:36 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Database Over Flow Query!! > > > Hello Sina, > I just wanted to know is it mandatory to > re-originate all the flushed non-defualt As-External > LSAs after coming out of the overflow state or it is > not mandatory. > Regards > Amit > --- Sina Mirtorabi wrote: > > Amit > > > > > -----Original Message----- > > > From: Mailing List > > [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Amit > > > Srivastava > > > Sent: Thursday, October 10, 2002 4:06 AM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Database Over Flow Query!! > > > > > > > > > Hi All, > > > Actually i was going through the RFC 1765 where > > in > > > it states that when the timer expires the router > > > leaves > > > OverflowState and begins originating non-default > > > AS-external-LSAs again. SO does it mean that it > > need > > > to reoriginate all the flushed self originated > > > As-External LSAs again or it means that it is not > > > mandatory to originate all the flushed self > > originated > > > non-defualt As-External LSAs but from now on we > > can > > > originate any new self originated LSA. > > > > what do you mean by 'new self originated LSA'? since > > all non-default type 5 > > LSA have been flushed out whatever type 5 the router > > generates can be > > considered as 'new instance' > > > > when the router leaves OverflowState after > > ospfExitOverflowInterval it will > > simply reoriginate / originate whatever type 5 it > > needs to generate, given > > that it remains below ospfExtLsdbLimit > > > > Sina > > > > > > > > > Please Answer if anyone know the solution. > > > Regards > > > Amit > > > > > > __________________________________________________ > > > Do you Yahoo!? > > > Faith Hill - Exclusive Performances, Videos & More > > > http://faith.yahoo.com > > > __________________________________________________ > Do you Yahoo!? > Faith Hill - Exclusive Performances, Videos & More > http://faith.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 09:15:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20562 for ; Fri, 11 Oct 2002 09:15:36 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.007678B8@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 9:17:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 281382 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 09:17:42 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 09:17:42 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3RJM>; Fri, 11 Oct 2002 09:17:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 11 Oct 2002 09:19:39 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Padma, I am not sure why you require the new TLV. The restarting router sends the Grace LSA, and the LSA already contains the Router-id. Why would we require to send a TLV in the LSA for the same? Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 10:10:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22423 for ; Fri, 11 Oct 2002 10:10:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00767B75@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 10:12:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 281529 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 10:12:53 -0400 Received: from 192.11.223.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 10:12:53 -0400 Received: from ma8117exch001u.wins.lucent.com (h152-148-89-175.lucent.com [152.148.89.175]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9BECpf15673 for ; Fri, 11 Oct 2002 10:12:51 -0400 (EDT) Received: by ma8117exch001u.inse.lucent.com with Internet Mail Service (5.5.2653.19) id <4WL33B3W>; Fri, 11 Oct 2002 10:12:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 11 Oct 2002 10:12:49 -0400 Reply-To: Mailing List Sender: Mailing List From: "Joyal, Daniel R (Daniel)" Subject: Re: OSPFv3 TE draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Does U-bit 0 imply that you now need a TE-capable option bit? -Dan -----Original Message----- From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] Sent: Friday, October 11, 2002 5:18 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPFv3 TE draft Hi folks, We are in the process of putting down a document for adding IPv6 TLV's for TE purposes and an LSA type in OSPFv3 for the same. We would want the opinion of the group regarding the setting of the U-bit in the TE-LSA type field. My opinion is that the U-bit should be set to 0, so that any router not recognizing the TE LSA would not forward the LSA any further. This I feel would help in the case where some routers in the area do not recognize the TE LSA while others do. This way redundant TE information would not be flooded in the entire area topology in case only part of the area understands the TE LSA. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 10:15:58 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22598 for ; Fri, 11 Oct 2002 10:15:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00767BFA@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 10:18:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 281552 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 10:18:04 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 10:18:04 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3RMH>; Fri, 11 Oct 2002 10:18:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 11 Oct 2002 10:20:21 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv3 TE draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Dan, The U bit indicates how the LSA should be handled by a router which does not recognize the LSA's function code. Its values are: U-bit LSA Handling ------------------------------------------------------------- 0 Treat the LSA as if it had link-local flooding scope 1 Store and flood the LSA, as if type understood Thanks, Vishwas -----Original Message----- From: Joyal, Daniel R (Daniel) [mailto:joyal@LUCENT.COM] Sent: Friday, October 11, 2002 7:43 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv3 TE draft Does U-bit 0 imply that you now need a TE-capable option bit? -Dan -----Original Message----- From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] Sent: Friday, October 11, 2002 5:18 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPFv3 TE draft Hi folks, We are in the process of putting down a document for adding IPv6 TLV's for TE purposes and an LSA type in OSPFv3 for the same. We would want the opinion of the group regarding the setting of the U-bit in the TE-LSA type field. My opinion is that the U-bit should be set to 0, so that any router not recognizing the TE LSA would not forward the LSA any further. This I feel would help in the case where some routers in the area do not recognize the TE LSA while others do. This way redundant TE information would not be flooded in the entire area topology in case only part of the area understands the TE LSA. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 10:28:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23142 for ; Fri, 11 Oct 2002 10:28:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00767AA7@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 10:30:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 281572 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 10:30:16 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 10:30:16 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 56766262815 for ; Fri, 11 Oct 2002 07:30:14 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA6E056.2080702@redback.com> Date: Fri, 11 Oct 2002 10:29:42 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 TE draft To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Vishwas, Manral, Vishwas wrote: > Hi folks, > > We are in the process of putting down a document for adding IPv6 TLV's for > TE purposes and an LSA type in OSPFv3 for the same. We would want the > opinion of the group regarding the setting of the U-bit in the TE-LSA type > field. > > My opinion is that the U-bit should be set to 0, so that any router not > recognizing the TE LSA would not forward the LSA any further. This I feel > would help in the case where some routers in the area do not recognize the > TE LSA while others do. This way redundant TE information would not be > flooded in the entire area topology in case only part of the area > understands the TE LSA. My opinion is that the U-bit should be set to 1 in all OSPFv3 opaque LSAs. By doing this, all OSPF implementations that support RFC 2740 will support opaque LSAs. I can appreciate your point on minimizing the flooding of TE opaque LSAs. However, the setting of the U-bit is based solely on the function code in the LS type. Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 11:00:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24602 for ; Fri, 11 Oct 2002 11:00:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00767B8F@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 11:02:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 281651 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 11:02:59 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 11:02:59 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9BF2wm62629 for ; Fri, 11 Oct 2002 08:02:58 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id g9BF2w312655 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 08:02:58 -0700 (PDT) (envelope-from kireeti) Message-ID: <200210111502.g9BF2w312655@kummer.juniper.net> Date: Fri, 11 Oct 2002 08:02:58 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: OSPFv3 TE draft To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi Vishwas, > My opinion is that the U-bit should be set to 0 Consider the following case: ... A ----- B ----- C ... A & B and B & C form OSPF adjacencies and exchange "regular" LSAs. Say A and C are TE-aware and B isn't. A advertises TE properties of the A->B link, and C advertises TE properties of the C->B link. Suppose B did in fact flood A's TE LSA to C and C's TE LSA to A. Anyone other router building a TE database would immediately understand that there isn't a TE path from A to C. Suppose now that there is another direct link A<->C, but no OSPF adjacency over that link. A advertises the A->C link in its TE LSA, and C advertises C->A in its TE LSA. The TE topology would be: ... A ===== C ... This is a situation that is likely to arise in GMPLS, for example. If B doesn't forward A's TE LSA to C (and vice versa), the above TE topology will not be visible to others in the network. So, to summarize: there is no harm is allowing non-TE aware routers to forward TE LSAs, but there may be much to gain. My suggestion: set the U bit to 1. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 11:32:26 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25580 for ; Fri, 11 Oct 2002 11:32:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00767C74@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 11:34:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 281870 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 11:34:32 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 11:34:32 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9BFYVm64830 for ; Fri, 11 Oct 2002 08:34:31 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9BFYVK36071 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 08:34:31 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210111534.g9BFYVK36071@garnet.juniper.net> Date: Fri, 11 Oct 2002 08:34:31 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: from "Manral, Vishwas" at Oct 11, 2002 09:19:39 AM Precedence: list Content-Transfer-Encoding: 7bit Vishwas Consistency. If you dig up the archives, you will see that I wanted to get rid of that TLV (type 3) for OSPFv2. We need to make a decision about both v2 and v3 version of this TLV either get rid of it or translate it for consistency. While, it is still mandatory for v2, I feel we need to be consistent. Padma > > Hi Padma, > > I am not sure why you require the new TLV. The restarting router sends the > Grace LSA, and the LSA already contains the Router-id. Why would we require > to send a TLV in the LSA for the same? > > Thanks, > Vishwas > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 11:40:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25802 for ; Fri, 11 Oct 2002 11:40:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00767D75@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 11:42:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 281899 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 11:42:57 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 11:42:57 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 71D9F449A3B for ; Fri, 11 Oct 2002 08:42:56 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210111534.g9BFYVK36071@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA6F160.8020106@redback.com> Date: Fri, 11 Oct 2002 11:42:24 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Padma, I think you can get rid of it. If I remember correctly, the grace LSA TLV is solely for the identification of neighboring routers on broadcast and NBMA network. In OSPFv3, neighbors are always identified by router ID (RFC 2740, Section 2.2). Padma Pillay-Esnault wrote: > Vishwas > > Consistency. > > If you dig up the archives, you will see that I > wanted to get rid of that TLV (type 3) for OSPFv2. > We need to make a decision about both v2 and v3 > version of this TLV either get rid of it or translate > it for consistency. > > While, it is still mandatory for v2, I feel we need to be > consistent. > > Padma > > >>Hi Padma, >> >>I am not sure why you require the new TLV. The restarting router sends the >>Grace LSA, and the LSA already contains the Router-id. Why would we require >>to send a TLV in the LSA for the same? >> >>Thanks, >>Vishwas >> >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 12:13:55 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27000 for ; Fri, 11 Oct 2002 12:13:55 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00767CE7@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 12:16:01 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 281977 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 12:16:01 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 12:16:01 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9BGG1m68240 for ; Fri, 11 Oct 2002 09:16:01 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9BGG0L49497 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 09:16:00 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210111616.g9BGG0L49497@garnet.juniper.net> Date: Fri, 11 Oct 2002 09:16:00 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DA6F160.8020106@redback.com> from "Acee Lindem" at Oct 11, 2002 11:42:24 AM Precedence: list Content-Transfer-Encoding: 7bit Acee > > Hi Padma, > > I think you can get rid of it. If I remember correctly, > the grace LSA TLV is solely for the identification > of neighboring routers on broadcast and NBMA network. In OSPFv3, We can derive this information without TLV 3. Helpers are only for previously full neighbors - which also means that we know the id/address for each neighbor. (rfc 2328 - section 10) Padma > neighbors are always identified by router ID (RFC 2740, Section > 2.2). > > Padma Pillay-Esnault wrote: > > > Vishwas > > > > Consistency. > > > > If you dig up the archives, you will see that I > > wanted to get rid of that TLV (type 3) for OSPFv2. > > We need to make a decision about both v2 and v3 > > version of this TLV either get rid of it or translate > > it for consistency. > > > > While, it is still mandatory for v2, I feel we need to be > > consistent. > > > > Padma > > > > > >>Hi Padma, > >> > >>I am not sure why you require the new TLV. The restarting router sends the > >>Grace LSA, and the LSA already contains the Router-id. Why would we require > >>to send a TLV in the LSA for the same? > >> > >>Thanks, > >>Vishwas > >> > >> > > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 12:45:10 2002 Received: from grape.ease.lsoft.com (grape.ease.lsoft.com [209.119.1.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27704 for ; Fri, 11 Oct 2002 12:45:10 -0400 (EDT) Received: from walnut (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <0.0031B4E5@grape.ease.lsoft.com>; Fri, 11 Oct 2002 12:47:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 282223 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 12:47:18 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 12:47:18 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id E7586F2C51 for ; Fri, 11 Oct 2002 09:47:16 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210111616.g9BGG0L49497@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA70074.7030300@redback.com> Date: Fri, 11 Oct 2002 12:46:44 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma Pillay-Esnault wrote: > Acee > > >>Hi Padma, >> >>I think you can get rid of it. If I remember correctly, >>the grace LSA TLV is solely for the identification >>of neighboring routers on broadcast and NBMA network. In OSPFv3, >> > > We can derive this information without TLV 3. > Helpers are only for previously full neighbors - which also means > that we know the id/address for each neighbor. > (rfc 2328 - section 10) Padma, In OSPFv2, OSPF runs on a subnet. So if you have multiple subnets on the same link (e.g., giga-ethernet), you need the local IP address to unambiguously identify the neighbor (or you need to preserve it from the IPv4 packet header). Some implementations don't support running OSPF on a secondary address but RFC 2328 allows this and many implementations support it (ours for example). In OSPFv3, OSPF is per-link and neighbors are unambiguously identified by router ID (RFC 2740, section 2.1). Hence, I don't think an IPv6 Interface Address TLV is required. Thanks, Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 13:34:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29647 for ; Fri, 11 Oct 2002 13:34:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00768126@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 13:36:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 282374 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 13:36:55 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 13:36:55 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 22D375D013; Sat, 12 Oct 2002 02:36:54 +0900 (JST) References: <200210111616.g9BGG0L49497@garnet.juniper.net> <3DA70074.7030300@redback.com> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021012.023649.120287407.yasu@sfc.wide.ad.jp> Date: Sat, 12 Oct 2002 02:36:49 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt Comments: To: acee@REDBACK.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DA70074.7030300@redback.com> Precedence: list Content-Transfer-Encoding: 7bit acee> In OSPFv3, OSPF is per-link and neighbors are unambiguously identified acee> by router ID (RFC 2740, section 2.1). Hence, I don't think an acee> IPv6 Interface Address TLV is required. I may be very sassy for saying this without studying about the grace-LSA, but it may not be true. In the network configuration below, only router-ID to identify Neighbor may be ambiguous. Because Ra have distinct "neighbor" data structures of Rb for each link L1, L2. L1 +---+ Ra Rb +---+ L2 It depends on what "the neighbor" is. It means "the data structure to hold adjacency status" sometimes, "The router itself" other times. If we want to identify the former "neighbor", we'll need either side of "Interface-ID" additionally. I imagine that grace-LSA tries to achieve "gracefully restart *adjacencies*", so I wondered "Is the interface-ID really unnecessary to identify neighbor(adjacencies) ?". Sorry if I'm missing the point of this discussion. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 14:02:08 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00669 for ; Fri, 11 Oct 2002 14:02:07 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00767FD5@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 14:04:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 282515 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 14:04:13 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 14:04:12 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 8B39240625C; Fri, 11 Oct 2002 11:04:11 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210111616.g9BGG0L49497@garnet.juniper.net> <3DA70074.7030300@redback.com> <20021012.023649.120287407.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA71279.8080609@redback.com> Date: Fri, 11 Oct 2002 14:03:37 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt Comments: To: Yasuhiro Ohara To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yasuhiro Ohara wrote: > acee> In OSPFv3, OSPF is per-link and neighbors are unambiguously identified > acee> by router ID (RFC 2740, section 2.1). Hence, I don't think an > acee> IPv6 Interface Address TLV is required. > > I may be very sassy for saying this without studying about the > grace-LSA, but it may not be true. > > In the network configuration below, only router-ID to identify > Neighbor may be ambiguous. Because Ra have distinct "neighbor" data > structures of Rb for each link L1, L2. > > L1 > +---+ > Ra Rb > +---+ > L2 > > It depends on what "the neighbor" is. It means "the data structure to > hold adjacency status" sometimes, "The router itself" other times. > If we want to identify the former "neighbor", we'll need either > side of "Interface-ID" additionally. > > I imagine that grace-LSA tries to achieve "gracefully restart > *adjacencies*", so I wondered "Is the interface-ID really unnecessary > to identify neighbor(adjacencies) ?". Hello Yasu, I don't think it is necessary in this case since the the grace LSA is scoped to either L1 or L2. Hence, if Ra is an OSPFv3 router performing graceful restart, it will originate a separate link scoped opaque LSA for L1 and L2. Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 14:14:22 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01024 for ; Fri, 11 Oct 2002 14:14:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00768210@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 14:16:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 282561 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 14:16:28 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 14:16:28 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9BIGRm81079 for ; Fri, 11 Oct 2002 11:16:28 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9BIGRE00959 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 11:16:27 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210111816.g9BIGRE00959@garnet.juniper.net> Date: Fri, 11 Oct 2002 11:16:27 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DA70074.7030300@redback.com> from "Acee Lindem" at Oct 11, 2002 12:46:44 PM Precedence: list Content-Transfer-Encoding: 7bit > > Padma Pillay-Esnault wrote: > > > Acee > > > > > >>Hi Padma, > >> > >>I think you can get rid of it. If I remember correctly, > >>the grace LSA TLV is solely for the identification > >>of neighboring routers on broadcast and NBMA network. In OSPFv3, > >> > > > > We can derive this information without TLV 3. > > Helpers are only for previously full neighbors - which also means > > that we know the id/address for each neighbor. > > (rfc 2328 - section 10) > > > Padma, > > In OSPFv2, OSPF runs on a subnet. So if you have multiple subnets > on the same link (e.g., giga-ethernet), you need the local IP address > to unambiguously identify the neighbor (or you need to preserve it from > the IPv4 packet header). Some implementations don't support running IMHO, if you do not preserve it from the IPV4 source addr then you have a slightly broken implementation ;-) (we do preservation - hence my grunt!) BTW, the draft stipulates that one grace lsa is enough to notify the neighboring helper even if it has multiple links to the restarting router. Thanks Padma > OSPF on a secondary address but RFC 2328 allows this and many > implementations support it (ours for example). > > In OSPFv3, OSPF is per-link and neighbors are unambiguously identified > by router ID (RFC 2740, section 2.1). Hence, I don't think an IPv6 Interface > Address TLV is required. > > Thanks, > > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 14:33:16 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01626 for ; Fri, 11 Oct 2002 14:33:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00768070@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 14:35:22 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 282623 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 14:35:21 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 14:35:21 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 6B1905E45A for ; Fri, 11 Oct 2002 11:35:20 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210111816.g9BIGRE00959@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA719C6.2010904@redback.com> Date: Fri, 11 Oct 2002 14:34:46 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma Pillay-Esnault wrote: >>Padma Pillay-Esnault wrote: >> >> >>>Acee >>> >>> >>> >>>>Hi Padma, >>>> >>>>I think you can get rid of it. If I remember correctly, >>>>the grace LSA TLV is solely for the identification >>>>of neighboring routers on broadcast and NBMA network. In OSPFv3, >>>> >>>> >>>We can derive this information without TLV 3. >>>Helpers are only for previously full neighbors - which also means >>>that we know the id/address for each neighbor. >>>(rfc 2328 - section 10) >>> >> >>Padma, >> >>In OSPFv2, OSPF runs on a subnet. So if you have multiple subnets >>on the same link (e.g., giga-ethernet), you need the local IP address >>to unambiguously identify the neighbor (or you need to preserve it from >>the IPv4 packet header). Some implementations don't support running >> > > IMHO, if you do not preserve it from the IPV4 source addr then you have > a slightly broken implementation ;-) (we do preservation - hence my grunt!) I agree. In the case of a type 9 LSA, you really need to associated it with the interface on which it was received in your Link State database. > > BTW, the draft stipulates that one grace lsa is enough to notify the > neighboring helper even if it has multiple links to the restarting router. I can't find this in the hitless draft right now - can you give me pointer? Thanks, Acee > > Thanks > > Padma > > >>OSPF on a secondary address but RFC 2328 allows this and many >>implementations support it (ours for example). >> >>In OSPFv3, OSPF is per-link and neighbors are unambiguously identified >>by router ID (RFC 2740, section 2.1). Hence, I don't think an IPv6 Interface >>Address TLV is required. >> >>Thanks, >> >>Acee >> >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 14:52:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02217 for ; Fri, 11 Oct 2002 14:52:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00768123@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 14:54:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 282665 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 14:54:16 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 14:54:16 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9BIsFm84858; Fri, 11 Oct 2002 11:54:15 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9BIsFX18173; Fri, 11 Oct 2002 11:54:15 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210111854.g9BIsFX18173@garnet.juniper.net> Date: Fri, 11 Oct 2002 11:54:15 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DA719C6.2010904@redback.com> from "Acee Lindem" at Oct 11, 2002 02:34:46 PM Precedence: list Content-Transfer-Encoding: 7bit > > Padma Pillay-Esnault wrote: > > >>Padma Pillay-Esnault wrote: > >> > >> > >>>Acee > >>> > >>> > >>> > >>>>Hi Padma, > >>>> > >>>>I think you can get rid of it. If I remember correctly, > >>>>the grace LSA TLV is solely for the identification > >>>>of neighboring routers on broadcast and NBMA network. In OSPFv3, > >>>> > >>>> > >>>We can derive this information without TLV 3. > >>>Helpers are only for previously full neighbors - which also means > >>>that we know the id/address for each neighbor. > >>>(rfc 2328 - section 10) > >>> > >> > >>Padma, > >> > >>In OSPFv2, OSPF runs on a subnet. So if you have multiple subnets > >>on the same link (e.g., giga-ethernet), you need the local IP address > >>to unambiguously identify the neighbor (or you need to preserve it from > >>the IPv4 packet header). Some implementations don't support running > >> > > > > IMHO, if you do not preserve it from the IPV4 source addr then you have > > a slightly broken implementation ;-) (we do preservation - hence my grunt!) > > > I agree. In the case of a type 9 LSA, you really need to associated > it with the interface on which it was received in your Link State > database. > > > > > > BTW, the draft stipulates that one grace lsa is enough to notify the > > neighboring helper even if it has multiple links to the restarting router. > > > I can't find this in the hitless draft right now - can you give > me pointer? > Just realized that this has been modified in later draft in draft-ietf-ospf-hitless-restart-00.txt 3.1. Entering helper mode Note that Router Y only needs to receive a single grace-LSA from X, even if X and Y attach to multiple common segments. The data in the first valid grace-LSA received is used to indicate the beginning and the end of the grace period -- all subsequent grace-LSAs received from X are ignored. This first grace-LSA is referred to below as simply "the grace-LSA from X". A single router is allowed to simultaneously serve as a helper for multiple restarting neighbors. later it is said in 02-txt Note that Router Y may be helping X on some network segments, and not on others. However, that circumstance will probably lead to the premature termination of X's hitless restart, as Y will not continue to advertise adjacencies on the segments where it is not helping (see Section 2.2). A single router is allowed to simultaneously serve as a helper for multiple restarting neighbors. Isn't that going to always lead to premature termination and hence defeat the purpose ? What is the idea behind of doing it per segment ? A restarting router will affect all its links in the same way so why differentiate it ? Padma > Thanks, > Acee > > > > > Thanks > > > > Padma > > > > > >>OSPF on a secondary address but RFC 2328 allows this and many > >>implementations support it (ours for example). > >> > >>In OSPFv3, OSPF is per-link and neighbors are unambiguously identified > >>by router ID (RFC 2740, section 2.1). Hence, I don't think an IPv6 Interface > >>Address TLV is required. > >> > >>Thanks, > >> > >>Acee > >> > >> > > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 15:23:06 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03062 for ; Fri, 11 Oct 2002 15:23:05 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.007684FC@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 15:25:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 282720 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 15:25:05 -0400 Received: from 134.56.3.132 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 15:15:05 -0400 Received: from mx02-int.net.com (mx02-int.net.com [134.56.112.14]) by mx02.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id g9BJDR504262 for ; Fri, 11 Oct 2002 12:13:27 -0700 (PDT) Received: from west-mail.net.com (west-mail.net.com [134.56.112.40]) by mx02-int.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id g9BJBrI23094 for ; Fri, 11 Oct 2002 12:11:53 -0700 (PDT) Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA5379 for ; Fri, 11 Oct 2002 12:15:07 -0700 X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 References: <20021011.112101.86422822.takenaga@soft.net.fujitsu.co.jp> <3DA65070.3060309@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3DA7233A.2BA2BD91@net.com> Date: Fri, 11 Oct 2002 12:15:06 -0700 Reply-To: Mailing List Sender: Mailing List From: Mani Devarajan Organization: N.E.T. http://www.net.com Subject: Re: Default LSA creation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ASBR ----- ------ ----- ------- | | | | | | | | | R1 | | R2 | | R3 | | R5 | | | | | | | | | ----- ------ ----- ------- | |I1 I2| | |I4 I5| |I6 I9| | RIP--- ----- | ------ ----- | AREA1 | AREA 0 AREA2 | |I3 |I10 | ----- | | I7| |I8 | -----| R4 |------- AREA0 | | AREA2 ----- * AREA2 is NSSA. Accee, this is question is similar to what Takenaga asked. But still my doubt is not cleared. So if R5 chosses the default route through R4, and If i bring down the I3. R4 is still a NSSA ABR so it will not flush the default-type7 LSA it generated in NSSA-2. Do you mean to say that it is the job of R5 to recalculate it routes through R3 or interface I3 going down should be avoided. -Thanks in advance, Mani Acee Lindem wrote: > > TAKENAGA Yoshinobu wrote: > > > Hi, > > > > I have a question about creation of default lsa into stub areas. > > (This question may be a FAQ, please suggest the point) > > > > Consider this network. > > > > area 1 : area 0 > > (stub) : +--->>(AS extenal path) > > : | > > |--R1--| : |--R4--| > > | |--R2--| | > > | : | > > | |--R3--| | > > |--R6--| : |--R5--| > > : > > > > Here, R2 and R3 are area border router. > > R4 is AS boundary router. > > All link have same cost. > > > > In such situation, R2 and R3 will create default Type-3 LSA into area 1. > > R1 will select R2 as nexthop to the AS extenal path through R4. > > > > Now, the link state changes to this (R4 lose the link to N1). > > > > area 1 : area 0 > > (stub) : +--->>(AS Extenal path) > > : N1 | > > |--R1--| : |XXR4--| > > | |--R2--| | > > | : | > > | |--R3--| | > > |--R6--| : |--R5--| > > : > > > > In such situation, R2 becomes a blackhole. > > > > What is the minimum requirement for R2 to create default Type-3 LSA > > into stub areas? > > - having configuration of Area0 > > - having active interface to Area0 > > - having "Full" status neighbor in Area0 > > - other?? > > Hi Takenaga, > > The answer is other. The minimum requirement is that the > router be an Area Border Router (ABR). Section 3.3 of RFC 2328 defines > an ABR as a router that attaches to multiple areas. In the context of > RFC 2328, area attachment requires at least one active interface in that > area. Some implementations use other definitions of what constitutes > an ABR (e.g., refer to draft-ietf-ospf-abr-alt-04.txt). However, using > a different ABR definition doesn't handle all situations. Consider R6 and > R3 in the figure below: > > area 1 : area 0 > (stub) : +--->>(AS Extenal path) > : N1 | > |--R1--| : |--R4--| > | |--R2--| | > | : | > | |--R3--| | > |--R6--| : |--R5XX| > > In general, a good OSPF network design will minimize the possibility > that the backbone will become partitioned. > > > > > # In NSSA with Type7 LSA, same problem will take place. > > > > Regards, > > > > -- > > TAKENAGA Yoshinobu, Fujitsu. > > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 15:27:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03167 for ; Fri, 11 Oct 2002 15:27:36 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.007684CF@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 15:29:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 282762 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 15:29:43 -0400 Received: from 64.139.11.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 15:19:42 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id PAA00799; Fri, 11 Oct 2002 15:23:03 -0400 References: <200210111502.g9BF2w312655@kummer.juniper.net> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Fri, 11 Oct 2002 12:23:03 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: OSPFv3 TE draft Comments: To: Kireeti Kompella To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210111502.g9BF2w312655@kummer.juniper.net> Precedence: list >This is a situation that is likely to arise in GMPLS, for example. > >If B doesn't forward A's TE LSA to C (and vice versa), the above TE >topology will not be visible to others in the network. > >So, to summarize: there is no harm is allowing non-TE aware routers >to forward TE LSAs, but there may be much to gain. My suggestion: >set the U bit to 1. I agree. Let's keep current draft value (which says U bit to 1). -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 15:34:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03317 for ; Fri, 11 Oct 2002 15:34:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00768414@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 15:36:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 282800 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 15:36:31 -0400 Received: from 64.139.11.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 15:26:30 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id PAA00814; Fri, 11 Oct 2002 15:29:48 -0400 References: <200210111616.g9BGG0L49497@garnet.juniper.net> <3DA70074.7030300@redback.com> <20021012.023649.120287407.yasu@sfc.wide.ad.jp> <3DA71279.8080609@redback.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Fri, 11 Oct 2002 12:29:48 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt Comments: To: Yasuhiro Ohara To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DA71279.8080609@redback.com> Precedence: list >> In the network configuration below, only router-ID to identify >> Neighbor may be ambiguous. Because Ra have distinct "neighbor" data >> structures of Rb for each link L1, L2. >> >> L1 >> +---+ >> Ra Rb >> +---+ >> L2 >> >> It depends on what "the neighbor" is. It means "the data structure to >> hold adjacency status" sometimes, "The router itself" other times. >> If we want to identify the former "neighbor", we'll need either >> side of "Interface-ID" additionally. >> >> I imagine that grace-LSA tries to achieve "gracefully restart >> *adjacencies*", so I wondered "Is the interface-ID really unnecessary >> to identify neighbor(adjacencies) ?". > > > >Hello Yasu, > >I don't think it is necessary in this case since the the grace LSA >is scoped to either L1 or L2. Hence, if Ra is an OSPFv3 router performing >graceful restart, it will originate a separate link scoped opaque LSA for >L1 and L2. I think so too. Since scope is link local and neighbor is identified. We are ok with it. -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 15:38:42 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03382 for ; Fri, 11 Oct 2002 15:38:42 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.007684CC@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 15:40:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 282860 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 15:40:48 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 15:40:48 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 4A6BF473CC3 for ; Fri, 11 Oct 2002 12:40:47 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210111854.g9BIsFX18173@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA7291C.9050702@redback.com> Date: Fri, 11 Oct 2002 15:40:12 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma Pillay-Esnault wrote: >>>BTW, the draft stipulates that one grace lsa is enough to notify the >>>neighboring helper even if it has multiple links to the restarting router. >>> >> >>I can't find this in the hitless draft right now - can you give >>me pointer? >> >> > > Just realized that this has been modified in later draft > in draft-ietf-ospf-hitless-restart-00.txt > > 3.1. Entering helper mode > > > Note that Router Y only needs to receive a single grace-LSA from > X, even if X and Y attach to multiple common segments. The data > in the first valid grace-LSA received is used to indicate the > beginning and the end of the grace period -- all subsequent > grace-LSAs received from X are ignored. This first grace-LSA is > referred to below as simply "the grace-LSA from X". > > A single router is allowed to simultaneously serve as a helper > for multiple restarting neighbors. > > later it is said in 02-txt > > Note that Router Y may be helping X on some network segments, > and not on others. However, that circumstance will probably lead > to the premature termination of X's hitless restart, as Y will > not continue to advertise adjacencies on the segments where it > is not helping (see Section 2.2). > A single router is allowed to simultaneously serve as a helper > for multiple restarting neighbors. > > Isn't that going to always lead to premature termination and hence defeat the > purpose ? > What is the idea behind of doing it per segment ? > A restarting router will affect all its links in the same way so why > differentiate it ? > I think don't think it makes sense that a full neighbor would help on some network segments and not others. I agree this would leas to premature termination. I do think it simplifies things if a restarting router originates the grace LSAs on all it's interfaces (or at least all with full neighbor adjacencies if it a planned restart). Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 15:48:16 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03564 for ; Fri, 11 Oct 2002 15:48:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00768620@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 15:50:22 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 282907 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 15:50:22 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 15:50:22 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9BJoMm92087 for ; Fri, 11 Oct 2002 12:50:22 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9BJoMI39150 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 12:50:22 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210111950.g9BJoMI39150@garnet.juniper.net> Date: Fri, 11 Oct 2002 12:50:21 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DA7291C.9050702@redback.com> from "Acee Lindem" at Oct 11, 2002 03:40:12 PM Precedence: list Content-Transfer-Encoding: 7bit > > Padma Pillay-Esnault wrote: > > > > > >>>BTW, the draft stipulates that one grace lsa is enough to notify the > >>>neighboring helper even if it has multiple links to the restarting router. > >>> > >> > >>I can't find this in the hitless draft right now - can you give > >>me pointer? > >> > >> > > > > Just realized that this has been modified in later draft > > in draft-ietf-ospf-hitless-restart-00.txt > > > > 3.1. Entering helper mode > > > > > > Note that Router Y only needs to receive a single grace-LSA from > > X, even if X and Y attach to multiple common segments. The data > > in the first valid grace-LSA received is used to indicate the > > beginning and the end of the grace period -- all subsequent > > grace-LSAs received from X are ignored. This first grace-LSA is > > referred to below as simply "the grace-LSA from X". > > > > A single router is allowed to simultaneously serve as a helper > > for multiple restarting neighbors. > > > > later it is said in 02-txt > > > > Note that Router Y may be helping X on some network segments, > > and not on others. However, that circumstance will probably lead > > to the premature termination of X's hitless restart, as Y will > > not continue to advertise adjacencies on the segments where it > > is not helping (see Section 2.2). > > A single router is allowed to simultaneously serve as a helper > > for multiple restarting neighbors. > > > > Isn't that going to always lead to premature termination and hence defeat the > > purpose ? > > What is the idea behind of doing it per segment ? > > A restarting router will affect all its links in the same way so why > > differentiate it ? > > > > > I think don't think it makes sense that a full neighbor would help on > > some network segments and not others. I agree this would leas to premature > termination. > Ok. we are on the same wavelength. > I do think it simplifies things if a restarting router originates the grace LSAs > on all it's interfaces (or at least all with full neighbor > adjacencies if it a planned restart). > I also agree with you .. that's what I do - the restarting router sends grace lsa over all interfaces. But from a Helping router perspective we should do as in 00-txt. It simplifies the helper code. It also prevents corner cases where we might not help all adjacencies (when we should). Padma > > Thanks, > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 16:04:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03819 for ; Fri, 11 Oct 2002 16:04:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00768582@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 16:06:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 282961 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 16:06:31 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 16:06:31 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 61A165D013; Sat, 12 Oct 2002 05:06:30 +0900 (JST) References: <3DA70074.7030300@redback.com> <20021012.023649.120287407.yasu@sfc.wide.ad.jp> <3DA71279.8080609@redback.com> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021012.050626.90777186.yasu@sfc.wide.ad.jp> Date: Sat, 12 Oct 2002 05:06:26 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt Comments: To: acee@REDBACK.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DA71279.8080609@redback.com> Precedence: list Content-Transfer-Encoding: 7bit acee> I don't think it is necessary in this case since the the grace LSA acee> is scoped to either L1 or L2. Hence, if Ra is an OSPFv3 router performing acee> graceful restart, it will originate a separate link scoped opaque LSA for acee> L1 and L2. Thank you for your kind correction. I was wrong. Sorry for my interruption. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 16:11:48 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04074 for ; Fri, 11 Oct 2002 16:11:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00768631@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 16:13:54 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 283008 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 16:13:54 -0400 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 16:13:53 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01KNJG4GW42K8X0BX4@omega7.wr.usgs.gov> for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 13:13:50 -0700 (PDT) X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM X-VMS-Cc: PMURPHY,mani_devarajan@net.com,acee@redback.com MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01KNJG4GW42M8X0BX4@omega7.wr.usgs.gov> Date: Fri, 11 Oct 2002 13:13:50 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: Question wrt to default route generated by stub-ABR: Comments: cc: MANI_DEVARAJAN@NET.COM, ACEE@REDBACK.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Mani, Acee, >> Thanks Acee, and also I just want to correct my >> question, it is type-7 default LSA that it didnt >> get flushed and not default-summary-LSA. >However, if >you have configured R4 to unconditionally originate an >external default, then this is a configuration problem. I would say it is a configuration issue and not necessarily a configuration problem. A type-7 default LSA may be originated by any NSSA router. Just because R4 loses its ABR status does not necessarily invalidate a potential directly connected external default path. However, it sounds like Mani intends that the default Type 7 LSA is automatically originated by R4 as he has not indicated R4 has a true directly connected external default path. In this case failure to withdraw is an implementation problem. Pat From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 16:16:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04197 for ; Fri, 11 Oct 2002 16:16:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00768527@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 16:18:54 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 283041 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 16:18:53 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 16:18:53 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id D4956FC04C for ; Fri, 11 Oct 2002 13:18:46 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <3DA70074.7030300@redback.com> <20021012.023649.120287407.yasu@sfc.wide.ad.jp> <3DA71279.8080609@redback.com> <20021012.050626.90777186.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA73203.8030209@redback.com> Date: Fri, 11 Oct 2002 16:18:11 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-pillay-esnault-ospf-v3-grace-lsa-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yasuhiro Ohara wrote: > acee> I don't think it is necessary in this case since the the grace LSA > acee> is scoped to either L1 or L2. Hence, if Ra is an OSPFv3 router performing > acee> graceful restart, it will originate a separate link scoped opaque LSA for > acee> L1 and L2. > > Thank you for your kind correction. I was wrong. > Sorry for my interruption. No need for apologies on this list - OSPF is complex enough that discusion and questions help us all understand better. > > regards, > yasu > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 16:32:42 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04591 for ; Fri, 11 Oct 2002 16:32:42 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00768540@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 16:34:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 283076 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 16:34:48 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 16:34:47 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id B3A0C473CC3 for ; Fri, 11 Oct 2002 13:34:46 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20021011.112101.86422822.takenaga@soft.net.fujitsu.co.jp> <3DA65070.3060309@redback.com> <3DA7233A.2BA2BD91@net.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DA735C3.4040703@redback.com> Date: Fri, 11 Oct 2002 16:34:11 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Default LSA creation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mani Devarajan wrote: > ASBR > ----- ------ ----- ------- > | | | | | | | | > | R1 | | R2 | | R3 | | R5 | > | | | | | | | | > ----- ------ ----- ------- > | |I1 I2| | |I4 I5| |I6 I9| | > RIP--- ----- | ------ ----- | > AREA1 | AREA 0 AREA2 | > |I3 |I10 > | ----- | > | I7| |I8 | > -----| R4 |------- > AREA0 | | AREA2 > ----- > * AREA2 is NSSA. > > Accee, this is question is similar to what Takenaga > asked. But still my doubt is not cleared. > > So if R5 chosses the default route through R4, and > If i bring down the I3. R4 is still a NSSA ABR so > it will not flush the default-type7 LSA it generated > in NSSA-2. > > Do you mean to say that it is the job of R5 to > recalculate it routes through R3 or interface I3 > going down should be avoided. Nope. Assuming I7 is still up (even though I3 is down), R4 still is an ABR and should be originating an NSSA type 7 default. In this situation you may want to inhibit automatic origination of the NSSA type 7 default or take steps to reduce the possibility that your backbone will become partitioned. > > > -Thanks in advance, > Mani > > > > > Acee Lindem wrote: > >>TAKENAGA Yoshinobu wrote: >> >> >>>Hi, >>> >>>I have a question about creation of default lsa into stub areas. >>>(This question may be a FAQ, please suggest the point) >>> >>>Consider this network. >>> >>> area 1 : area 0 >>> (stub) : +--->>(AS extenal path) >>> : | >>> |--R1--| : |--R4--| >>> | |--R2--| | >>> | : | >>> | |--R3--| | >>> |--R6--| : |--R5--| >>> : >>> >>>Here, R2 and R3 are area border router. >>>R4 is AS boundary router. >>>All link have same cost. >>> >>>In such situation, R2 and R3 will create default Type-3 LSA into area 1. >>>R1 will select R2 as nexthop to the AS extenal path through R4. >>> >>>Now, the link state changes to this (R4 lose the link to N1). >>> >>> area 1 : area 0 >>> (stub) : +--->>(AS Extenal path) >>> : N1 | >>> |--R1--| : |XXR4--| >>> | |--R2--| | >>> | : | >>> | |--R3--| | >>> |--R6--| : |--R5--| >>> : >>> >>>In such situation, R2 becomes a blackhole. >>> >>>What is the minimum requirement for R2 to create default Type-3 LSA >>>into stub areas? >>> - having configuration of Area0 >>> - having active interface to Area0 >>> - having "Full" status neighbor in Area0 >>> - other?? >>> >>Hi Takenaga, >> >>The answer is other. The minimum requirement is that the >>router be an Area Border Router (ABR). Section 3.3 of RFC 2328 defines >>an ABR as a router that attaches to multiple areas. In the context of >>RFC 2328, area attachment requires at least one active interface in that >>area. Some implementations use other definitions of what constitutes >>an ABR (e.g., refer to draft-ietf-ospf-abr-alt-04.txt). However, using >>a different ABR definition doesn't handle all situations. Consider R6 and >>R3 in the figure below: >> >> area 1 : area 0 >> (stub) : +--->>(AS Extenal path) >> : N1 | >> |--R1--| : |--R4--| >> | |--R2--| | >> | : | >> | |--R3--| | >> |--R6--| : |--R5XX| >> >>In general, a good OSPF network design will minimize the possibility >>that the backbone will become partitioned. >> >> >>># In NSSA with Type7 LSA, same problem will take place. >>> >>>Regards, >>> >>>-- >>>TAKENAGA Yoshinobu, Fujitsu. >>> >>> >>> >>-- >>Acee >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 16:48:44 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04904 for ; Fri, 11 Oct 2002 16:48:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00768659@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 16:50:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 283115 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 16:50:51 -0400 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 16:50:50 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01KNJHEBHITY8X0BX4@omega7.wr.usgs.gov> for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 13:50:48 -0700 (PDT) X-VMS-To: OSPF@DISCUSS.MICROSOFT.COM X-VMS-Cc: pmurphy,mani_devarajan@NET.COM MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01KNJHEBHIU08X0BX4@omega7.wr.usgs.gov> Date: Fri, 11 Oct 2002 13:50:48 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: Default LSA creation Comments: cc: MANI_DEVARAJAN@NET.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Mani, >So if R5 chosses the default route through R4, and >If i bring down the I3. R4 is still a NSSA ABR so >it will not flush the default-type7 LSA it generated >in NSSA-2. This is a configuration issue. The scenario you descibe indicates Area 0 has partitioned with R4 all by itself. When area 0 partitions routes break regardless how small. For standard topologies, virtual links may be used to repair the break. NSSAs and Stub areas do not have that luxury/cluge. An area 0 secondary link across Area 2 would also work provided you have an implementation of draft-ietf-ospf-mlinks-03.txt, which I hope to repost one of these days with some corrections that others have noted. Pat From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 19:53:43 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07419 for ; Fri, 11 Oct 2002 19:53:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00768D00@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 19:55:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 283565 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 19:55:48 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 19:55:48 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 1809d9-0009L0-00; Fri, 11 Oct 2002 16:55:43 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <39469E08BD83D411A3D900204840EC557633BF@vie-msgusr-01.dc.fore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <11112946746.20021011165312@psg.com> Date: Fri, 11 Oct 2002 16:53:12 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: "Naidu, Venkata" To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC557633BF@vie-msgusr-01.dc.fore.com> Precedence: list Content-Transfer-Encoding: 7bit Venkata, There's no problem in OSPFv3 providing transport-like services to non-OSPF "applications", this concept is just already in the protocol, we don't have to specify anything extra here. My objection is against the idea of mapping/linking/shortcutting all Opaque-LSA-based *extensions* to OSPFv3. This idea is based on the assumption that migration of those extensions from IPv4 to IPv6 or from OSPFv2 to OSPFv3 environment will generally not require any additional specification. While this may be true for some specific "applications", I don't believe we can safely assume this as a general case. We are here to make sure independent interoperable implementations can be developed, which means that things need to be properly specified. My standing in this discussion is to ensure that we do not make a mistake that will create the underspecification problem. Thank you. -- Alex Thursday, October 10, 2002, 10:05:39 AM, Naidu, Venkata wrote: > Kireeti & Alex, > I am late into the field - please excuse and consider > my points. ->> > (c) is, if I understand you correctly, the approach you ->> are suggesting. ->> ->> Not necessarily on a section-by-section/TLV-by-TLV basis as you ->> mentioned above. Instead, if, for example, we need to get the TE ->> extensions into v3, we would come up with a ->> draft-ospf-ospfv3-katz-yueng ->> and specify the LS Type for TE LSAs, refer to katz-yueng for things ->> like body formatting, enumerate TLVs (by reference, not value) that ->> are IP-version independent and are valid for v3, and then go and ->> address the IPv6 specific details. > Kireeti has a very valid point here. Alex's point is independent > of what we (MPLS folks) have to do at this point of time. > I view MPLS-TE a "service user" of OSPF (v2 or v3) "a service > provider" for flooding the information transparently to other > side of MPLS-TE layer. > If, by chance, OSPFv3 is running in the topology, and If the > application (here, for example, still MPLS-TE for IPv4) would > like to pass the info (OSPF should not care about what the > information is) to the other side, then it should. *Application* > (for example MPLS-TE for IPv4) knows what is the info - here it > is still IPv4 - for the reasons mentioned by Kireeti. > Alex, let me put it in other way - define a LS Type in OSPF v3 > and call it "User defined LS Type" and reserve *one* (just one) > for OSPF v2 Opaque LSAs. Now with very minimal changes, all the > IPv4 applications which used OSPF v2 Opaque LSAs can be flooded > even when OSPF v3 is running in the network. > Alex's point is valid when MPLS-TE for IPv6 (which is different > application when compared to MPLS-TE for IPv4) is used in the > network. For this, any way, we need a clear draft which considers > IPv6 requirements, etc etc. > Alex, there are almost nearly 20 different IPv4 applications > using OSPF v2 Opaque LSAs (MPLS-TE is just one of them). So please > consider the fact that, all those applications must work if the > version of OSPF is changed from v2 to v3 with minimal work. > Bottom Line: It is the application who decides whether to write > a new draft for IPv6 or not by taking the new requirements for IPv6 > (if there are any). A service provider (here OSPF) should not ask > applications to change their behavior or information when it's own > operation/version changes. What it should possible do is, provide > a transport mechanism (a SAP) to all those previous applications, > so that the information is flooded intact. > Please don't think otherwise - kindly interrupt me if I am not > in the same page :) > -- > Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 11 21:10:59 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08496 for ; Fri, 11 Oct 2002 21:10:59 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00768CC9@cherry.ease.lsoft.com>; Fri, 11 Oct 2002 21:13:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 283680 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Oct 2002 21:13:02 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 11 Oct 2002 21:13:02 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 180Apx-000BOl-00; Fri, 11 Oct 2002 18:13:01 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <200210101854.g9AIsNu09615@kummer.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4417570605.20021011181015@psg.com> Date: Fri, 11 Oct 2002 18:10:15 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: Kireeti Kompella To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210101854.g9AIsNu09615@kummer.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Thursday, October 10, 2002, 11:54:23 AM, Kireeti Kompella wrote: > Thanks for your support, Venkata! > One thing I would like to reiterate: there are a *small* number of > currently defined Opaque LSAs -- TE, Grace LSA, and perhaps one more. > If we analyse the applicability of those LSAs to OSPF v3, and mandate > that any future definition of an OSPFv2 Opaque LSA MUST have a similar > analysis, that seems to me to address the "backdoor" problem. > The "backdoor" issue is an excellent example of a *theoretical* > problem that has little *practical* relevance, given the above mandate. It's an excellent example of the type of hidden problems that ADs have to think about and that to them has a very practical relevance. > As a consequence, we have at least two independent efforts to migrate > just the TE document to v3, when in fact it should be really simple. > Then we do it again for Grace LSAs. And possibly again in the future. OSPFv3- and IPv6-related issues should be considered and specified for each feature independently, because OSPFv? are not just two versions of a transport mechanism, they are two different routing protocols providing connectivity for different types of environment. > And then we hear that the IETF is overloaded, and the IESG overburdened. > Oh, well ... Thanks for thinking about the IESG. I can assure you that it will be much less controversial (and hence faster) for the IESG to deal with drafts explicitly specifying IPv6/OSPFv3 considerations for specific features, than it will be to waste time arguing about a draft that collectively migrates all present and future OSPFv2-based features and "applications" to the IPv6/OSPFv3 environment. Alex From owner-ospf@DISCUSS.MICROSOFT.COM Sat Oct 12 19:26:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02268 for ; Sat, 12 Oct 2002 19:26:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0076B5E6@cherry.ease.lsoft.com>; Sat, 12 Oct 2002 19:28:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 286594 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 12 Oct 2002 19:28:59 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 12 Oct 2002 19:18:58 -0400 Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9CNIwm59784 for ; Sat, 12 Oct 2002 16:18:58 -0700 (PDT) (envelope-from dennis@juniper.net) X-Mailer: exmh version 2.0.2 2/24/98 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210122318.g9CNIwm59784@merlot.juniper.net> Date: Sat, 12 Oct 2002 16:18:58 -0700 Reply-To: Mailing List Sender: Mailing List From: Dennis Ferguson Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Your message of "Fri, 11 Oct 2002 18:10:15 PDT." <4417570605.20021011181015@psg.com> Precedence: list Alex, > > As a consequence, we have at least two independent efforts to migrate > > just the TE document to v3, when in fact it should be really simple. > > Then we do it again for Grace LSAs. And possibly again in the future. > > OSPFv3- and IPv6-related issues should be considered and specified for > each feature independently, because OSPFv? are not just two versions > of a transport mechanism, they are two different routing protocols > providing connectivity for different types of environment. Here's the problem I have with this. OSPFv3 was in fact designed to be network-protocol agnostic, like IS-IS, except retaining OSPF's style of adjacency synchronization and many-LSA information distribution. This is why address information was entirely separated from adjacency maintenance packets and topology description LSAs, why there's a "v6" option bit (so you could have a v4-only router running the protocol), is one of the reasons for the instance ID (if you really needed to deal with multiply-addressed v4 links), and is why the LSAs which do carry address information only carry address information, and nothing else. While it has not been specified yet, making OSPFv3 route IPv4 may not be much more difficult than finding all the LSA types which carry IPv6 addresses in the current protocol (I think there are 4 of them) and inventing equivalents to carry IPv4 addresses. The reason I think you really want to plan for this is that networks which support IPv6 will almost certainly continue to support IPv4 just about forever, in Internet years. Support for both protocols won't be a transition strategy, it will be a permanent operational state. As such (and while at least one of the authors of the OSPFv3 RFC might disagree), I don't think running two IGPs over the same topology is a practical plan to address this. Not only does it substantially increase configuration, debugging and other operational complexity, but it also unnecessarily duplicates the mechanisms which often dominate the cost of running a link state protocol and most severely limit its scalability, i.e. adjacency maintenance. Having one IGP carry twice the number of addresses is much cheaper, more maintainable and more scalable then running two IGPs. So we're in this state where OSPFv3 should be a dual-network-protocol routing protocol, but isn't yet, and you are talking about importing several functions from OSPFv2 which, if well done, seem like they should have very little dependence on a particular network protocol. Given what OSPFv3 may become I think it would be a big mistake to allow gratuitous IPv6 dependencies to creep into these (in fact I also think it is a mistake if the authors of the OSPFv2 versions let gratuitous IPv4 dependencies creep into those) because if you do you may be painting yourself into a corner where you might not want to be in future. This leaves the practical problem of ensuring that functionality is specified in a way which makes sense in a multi-network-protocol environment when OSPFv3 doesn't (yet) operate in an environment like that. While one could attempt to do this in theory, I'd just point out that if you could manage to import the functionality from OSPFv2 without changes you'd have some practical assurance that what you had actually would make sense for IPv4 as well as IPv6. While I'll admit that OSPFv3 is a somewhat different routing protocol than OSPFv2, I don't think I'd reject the direct copy based on a generic "different types of environment" argument since those environments may become a lot more similar in future. > > And then we hear that the IETF is overloaded, and the IESG overburdened. > > Oh, well ... > > Thanks for thinking about the IESG. I can assure you that it will be > much less controversial (and hence faster) for the IESG to deal with > drafts explicitly specifying IPv6/OSPFv3 considerations for specific > features, than it will be to waste time arguing about a draft that > collectively migrates all present and future OSPFv2-based features and > "applications" to the IPv6/OSPFv3 environment. If the IESG thinks of "OSPFv3" as exclusively "IPv6" I think they might be missing some of the bigger picture with respect to future operational requirements for an IGP. Perhaps there needs to be a draft to keep people reminded of this, however. Dennis Ferguson From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 14 10:20:56 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21474 for ; Mon, 14 Oct 2002 10:20:56 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0076EB00@cherry.ease.lsoft.com>; Mon, 14 Oct 2002 10:11:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 290936 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Oct 2002 10:11:25 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 14 Oct 2002 10:11:25 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08616 for ; Mon, 14 Oct 2002 10:10:52 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10802 for ; Mon, 14 Oct 2002 10:10:03 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4W8J4VGF>; Mon, 14 Oct 2002 10:10:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557633DC@vie-msgusr-01.dc.fore.com> Date: Mon, 14 Oct 2002 10:09:59 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Dennis, -> If the IESG thinks of "OSPFv3" as exclusively "IPv6" I think -> they might be missing some of the bigger picture with respect -> to future operational requirements for an IGP. One of my recent mail to another list strongly supports these points. FYI - -----Original Message----- From: Naidu, Venkata [mailto:Venkata.Naidu@marconi.com] Subject: RE: [diff-ospf-isis] Points from 1991 paper -> However it is just as easy to add IPv4 support for OSPFv3 ... -> .... ;-) Though no-one would attempt it backwards. There are lot of advantages if one does IPv4 support for OSPFv3. That is what is my recent mail in OSPF-WG, but unfortunately AD rejected my attempt to convince :) Everyone thinks that OSPFv3 is for IPv6 - that is very wrong. In a layered architecture, one can (at least in *theory*) remove each layer an replace it with something new, enhanced protocol with out disturbing the lower/upper layer protocols. That is the beauty of layering. If one does the way suggested, then all the "IPv4 applications" of OSPF (I should say IGPs) performance will increase tremendously. In other words, OSPFv3 is designed such a way that all the "good experience" we got from OSPFv2 are rectified/beautified/improved. (I know that because the OSPFv3 is created in the same group I am working right now). That view of looking at IGPs as just "hop-by-hop routing protocols" should go away. Now with the new opened doors in Optical networking, Advanced (diffserv) TE enhancements, VPNs, those good old IGPs became like transport protocols. The applicability of these IGPs for transportation of transparent data will increase in future years. May be, we (IGP guys) should get a big picture of how/why/what TSVWG is doing for new requirement in transport protocols (such as SCTP etc etc). How can we do the same stuff with minimal changes in IGPs for the benefit of our "IGPs applications" ? Finally, the % of code in IGPs used for SPF and hop-by-hop routing table calculations is decreased. That % is grabbed by other purposes. IGPs are no more self-driven, rather dictated by some new applications requirements. If we fail to tune our IGPs for all such applications then, new protocols will emerge (for example, LDP). Those new XXX protocols will look exactly like "stripped OSPF" - in 1000ft view. PS: I know, LDP does more than "tailored OSPF" for label distribution. I just gave an example :-) -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 14 13:39:21 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27361 for ; Mon, 14 Oct 2002 13:39:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0076F199@cherry.ease.lsoft.com>; Mon, 14 Oct 2002 13:41:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 292477 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Oct 2002 13:41:29 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 14 Oct 2002 13:41:29 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H34WF>; Mon, 14 Oct 2002 13:41:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 14 Oct 2002 13:43:31 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Dennis, I guess it is clear that OSPFv3 is protocol agnostic and that we should be able to carry both IPV4 and IPv6 TLV's in both OSPFv2-Opaque's and OSPFv3. However are you also suggesting we have Inter-Area-Prefix-LSA, Intra-Area-Prefix-LSA and Link LSA equivalents for IPv4 in OSPFv3? Or is it just for the transport part(e.g Opaque LSA's) you feel that we have to be able to carry both protocol TLV's. Thanks, Vishwas -----Original Message----- From: Dennis Ferguson [mailto:dennis@JUNIPER.NET] Sent: Sunday, October 13, 2002 4:49 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Alex, > > As a consequence, we have at least two independent efforts to migrate > > just the TE document to v3, when in fact it should be really simple. > > Then we do it again for Grace LSAs. And possibly again in the future. > > OSPFv3- and IPv6-related issues should be considered and specified for > each feature independently, because OSPFv? are not just two versions > of a transport mechanism, they are two different routing protocols > providing connectivity for different types of environment. Here's the problem I have with this. OSPFv3 was in fact designed to be network-protocol agnostic, like IS-IS, except retaining OSPF's style of adjacency synchronization and many-LSA information distribution. This is why address information was entirely separated from adjacency maintenance packets and topology description LSAs, why there's a "v6" option bit (so you could have a v4-only router running the protocol), is one of the reasons for the instance ID (if you really needed to deal with multiply-addressed v4 links), and is why the LSAs which do carry address information only carry address information, and nothing else. While it has not been specified yet, making OSPFv3 route IPv4 may not be much more difficult than finding all the LSA types which carry IPv6 addresses in the current protocol (I think there are 4 of them) and inventing equivalents to carry IPv4 addresses. The reason I think you really want to plan for this is that networks which support IPv6 will almost certainly continue to support IPv4 just about forever, in Internet years. Support for both protocols won't be a transition strategy, it will be a permanent operational state. As such (and while at least one of the authors of the OSPFv3 RFC might disagree), I don't think running two IGPs over the same topology is a practical plan to address this. Not only does it substantially increase configuration, debugging and other operational complexity, but it also unnecessarily duplicates the mechanisms which often dominate the cost of running a link state protocol and most severely limit its scalability, i.e. adjacency maintenance. Having one IGP carry twice the number of addresses is much cheaper, more maintainable and more scalable then running two IGPs. So we're in this state where OSPFv3 should be a dual-network-protocol routing protocol, but isn't yet, and you are talking about importing several functions from OSPFv2 which, if well done, seem like they should have very little dependence on a particular network protocol. Given what OSPFv3 may become I think it would be a big mistake to allow gratuitous IPv6 dependencies to creep into these (in fact I also think it is a mistake if the authors of the OSPFv2 versions let gratuitous IPv4 dependencies creep into those) because if you do you may be painting yourself into a corner where you might not want to be in future. This leaves the practical problem of ensuring that functionality is specified in a way which makes sense in a multi-network-protocol environment when OSPFv3 doesn't (yet) operate in an environment like that. While one could attempt to do this in theory, I'd just point out that if you could manage to import the functionality from OSPFv2 without changes you'd have some practical assurance that what you had actually would make sense for IPv4 as well as IPv6. While I'll admit that OSPFv3 is a somewhat different routing protocol than OSPFv2, I don't think I'd reject the direct copy based on a generic "different types of environment" argument since those environments may become a lot more similar in future. > > And then we hear that the IETF is overloaded, and the IESG overburdened. > > Oh, well ... > > Thanks for thinking about the IESG. I can assure you that it will be > much less controversial (and hence faster) for the IESG to deal with > drafts explicitly specifying IPv6/OSPFv3 considerations for specific > features, than it will be to waste time arguing about a draft that > collectively migrates all present and future OSPFv2-based features and > "applications" to the IPv6/OSPFv3 environment. If the IESG thinks of "OSPFv3" as exclusively "IPv6" I think they might be missing some of the bigger picture with respect to future operational requirements for an IGP. Perhaps there needs to be a draft to keep people reminded of this, however. Dennis Ferguson From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 14 13:44:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27553 for ; Mon, 14 Oct 2002 13:44:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0076F1B4@cherry.ease.lsoft.com>; Mon, 14 Oct 2002 13:46:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 292550 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Oct 2002 13:46:55 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 14 Oct 2002 13:46:54 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 1819Iq-0001ju-00; Mon, 14 Oct 2002 10:46:52 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <200210122318.g9CNIwm59784@merlot.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <5371708531.20021014104454@psg.com> Date: Mon, 14 Oct 2002 10:44:54 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: Dennis Ferguson To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210122318.g9CNIwm59784@merlot.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Dennis, Thanks for your note. I don't think the key point of the argument is about how separated are the flooding and reachibility announcement mechanisms in OSPFv3--they definitely are, nor I think it is about whether OSPFv3 can be extended to support IPv4 routing--it definitely can be. It is about whether "legalizing" all v2's Opaque-LSAs in v3 (as opposed to copying the features) makes sense or not. As you said, OSPFv2 and OSPFv3 are somewhat different routing protocols, also OSPFv3, as it stands today, is an IPv6 routing protocol. Given these two combined with my paranoid worry about insufficient specification, I don't think it is a good idea. Regards. -- Alex Saturday, October 12, 2002, 4:18:58 PM, Dennis Ferguson wrote: > Alex, >> > As a consequence, we have at least two independent efforts to migrate >> > just the TE document to v3, when in fact it should be really simple. >> > Then we do it again for Grace LSAs. And possibly again in the future. >> >> OSPFv3- and IPv6-related issues should be considered and specified for >> each feature independently, because OSPFv? are not just two versions >> of a transport mechanism, they are two different routing protocols >> providing connectivity for different types of environment. > Here's the problem I have with this. OSPFv3 was in fact designed to > be network-protocol agnostic, like IS-IS, except retaining OSPF's > style of adjacency synchronization and many-LSA information distribution. > This is why address information was entirely separated from adjacency > maintenance packets and topology description LSAs, why there's a "v6" > option bit (so you could have a v4-only router running the protocol), is > one of the reasons for the instance ID (if you really needed to deal > with multiply-addressed v4 links), and is why the LSAs which do carry > address information only carry address information, and nothing else. > While it has not been specified yet, making OSPFv3 route IPv4 may not > be much more difficult than finding all the LSA types which carry IPv6 > addresses in the current protocol (I think there are 4 of them) and > inventing equivalents to carry IPv4 addresses. > The reason I think you really want to plan for this is that networks > which support IPv6 will almost certainly continue to support IPv4 just > about forever, in Internet years. Support for both protocols won't be > a transition strategy, it will be a permanent operational state. As > such (and while at least one of the authors of the OSPFv3 RFC might > disagree), I don't think running two IGPs over the same topology is a > practical plan to address this. Not only does it substantially > increase configuration, debugging and other operational complexity, but > it also unnecessarily duplicates the mechanisms which often dominate the > cost of running a link state protocol and most severely limit its scalability, > i.e. adjacency maintenance. Having one IGP carry twice the number of > addresses is much cheaper, more maintainable and more scalable then running > two IGPs. > So we're in this state where OSPFv3 should be a dual-network-protocol > routing protocol, but isn't yet, and you are talking about importing several > functions from OSPFv2 which, if well done, seem like they should have > very little dependence on a particular network protocol. Given what OSPFv3 > may become I think it would be a big mistake to allow gratuitous IPv6 > dependencies to creep into these (in fact I also think it is a mistake > if the authors of the OSPFv2 versions let gratuitous IPv4 dependencies > creep into those) because if you do you may be painting yourself into > a corner where you might not want to be in future. > This leaves the practical problem of ensuring that functionality is > specified in a way which makes sense in a multi-network-protocol > environment when OSPFv3 doesn't (yet) operate in an environment like > that. While one could attempt to do this in theory, I'd just point > out that if you could manage to import the functionality from OSPFv2 > without changes you'd have some practical assurance that what you had > actually would make sense for IPv4 as well as IPv6. While I'll admit > that OSPFv3 is a somewhat different routing protocol than OSPFv2, I don't > think I'd reject the direct copy based on a generic "different types of > environment" argument since those environments may become a lot more > similar in future. >> > And then we hear that the IETF is overloaded, and the IESG overburdened. >> > Oh, well ... >> >> Thanks for thinking about the IESG. I can assure you that it will be >> much less controversial (and hence faster) for the IESG to deal with >> drafts explicitly specifying IPv6/OSPFv3 considerations for specific >> features, than it will be to waste time arguing about a draft that >> collectively migrates all present and future OSPFv2-based features and >> "applications" to the IPv6/OSPFv3 environment. > If the IESG thinks of "OSPFv3" as exclusively "IPv6" I think they might > be missing some of the bigger picture with respect to future operational > requirements for an IGP. Perhaps there needs to be a draft to keep > people reminded of this, however. > Dennis Ferguson From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 14 13:55:44 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27941 for ; Mon, 14 Oct 2002 13:55:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0076F28A@cherry.ease.lsoft.com>; Mon, 14 Oct 2002 13:57:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 292598 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Oct 2002 13:57:53 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 14 Oct 2002 13:57:53 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 1819TT-000220-00; Mon, 14 Oct 2002 10:57:51 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <39469E08BD83D411A3D900204840EC557633DC@vie-msgusr-01.dc.fore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4472366557.20021014105552@psg.com> Date: Mon, 14 Oct 2002 10:55:52 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: To: "Naidu, Venkata" To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC557633DC@vie-msgusr-01.dc.fore.com> Precedence: list Content-Transfer-Encoding: 7bit Venkata, Monday, October 14, 2002, 7:09:59 AM, Naidu, Venkata wrote: ... > That view of looking at IGPs as just "hop-by-hop routing protocols" > should go away. Now with the new opened doors in Optical networking, > Advanced (diffserv) TE enhancements, VPNs, those good old IGPs became > like transport protocols. The applicability of these IGPs for > transportation of transparent data will increase in future years. > May be, we (IGP guys) should get a big picture of how/why/what TSVWG > is doing for new requirement in transport protocols (such as SCTP > etc etc). How can we do the same stuff with minimal changes in IGPs > for the benefit of our "IGPs applications" ? IGPs (and EGPs for that matter) are _routing_ protocols, they are _not_ a universal transport system. > Finally, the % of code in IGPs used for SPF and hop-by-hop routing > table calculations is decreased. That % is grabbed by other > purposes. IGPs are no more self-driven, rather dictated by some new > applications requirements. > If we fail to tune our IGPs for all such applications then, new > protocols will emerge (for example, LDP). Those new XXX protocols > will look exactly like "stripped OSPF" - in 1000ft view. And this is the right thing to do. There are reasons we don't distribute DNS records through routing. Unfortunately, we keep forgetting these reasons and concentrate on reusing existing packet parsing code... Alex From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 15 04:18:44 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23542 for ; Tue, 15 Oct 2002 04:18:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00770DE1@cherry.ease.lsoft.com>; Tue, 15 Oct 2002 4:20:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 294309 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Oct 2002 04:20:50 -0400 Received: from 64.139.11.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 15 Oct 2002 04:20:49 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id EAA01137 for ; Tue, 15 Oct 2002 04:24:16 -0400 User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.91 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Tue, 15 Oct 2002 01:24:16 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Link TLV's sub-TLVs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Here is a current Link TLV's sub-TLVs list ;-) which is referred in various drafts. With this TLVs I think we are pretty much ok (hopefully...). I'll submit updated draft. Traffic Engineering Link TLV (type 2) sub-TLVs Traffic Engineering sub-TLVs ============================ 1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4N octets) 4 - Remote interface IP address (4N octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets) GMPLS sub-TLVs ============== 11 - Link Local/Remote Identifiers (8 octets) 14 - Link Protection Type (4 octets) 15 - Interface Switching Capability Descriptor (variable) 16 - Shared Risk Link Group (variable) IPv6 sub-TLVs ============= 17 - Neighbor ID (8 octets) 18 - Local Interface IPv6 Address (16N octets) 19 - Remote Interface IPv6 Address (16N octets) Diffserv aware MPLS sub-TLVs ============================ TBD - Bandwidth Constraint Model Id (1 octet) Bandwidth Constraints (4N octets) TBD - Local Overbooking Multiplier (2N octets) 10,12,13 are not used by historical reason. Reference ========= draft-katz-yeung-ospf-traffic-08.txt draft-ietf-ccamp-ospf-gmpls-extensions-08.txt draft-ishiguro-ospf-ospfv3-traffic-01.txt draft-ietf-tewg-diff-te-proto-01.txt -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 15 15:51:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13519 for ; Tue, 15 Oct 2002 15:51:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.007723CA@cherry.ease.lsoft.com>; Tue, 15 Oct 2002 15:53:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 297198 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Oct 2002 15:53:24 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 15 Oct 2002 15:43:24 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00772352@cherry.ease.lsoft.com>; Tue, 15 Oct 2002 15:43:24 -0400 Message-ID: Date: Tue, 15 Oct 2002 15:43:23 -0400 Reply-To: Mailing List Sender: Mailing List From: Jeff Subject: Loopback address in Multiple Areas? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hello, I have an application which requires a node loopback address to be advertised in the Router LSA of every active area. I believe this violates the practice of assigning each interface (including loopback interfaces) to an individual area? Is this done by anyone? Could this cause potential problems (beyond extra summary lsas)? Thanks in advance Jeff From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 15 16:04:08 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13988 for ; Tue, 15 Oct 2002 16:04:08 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00772408@cherry.ease.lsoft.com>; Tue, 15 Oct 2002 16:06:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 297291 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Oct 2002 16:06:16 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 15 Oct 2002 16:06:16 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 176BD5E442 for ; Tue, 15 Oct 2002 13:06:15 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DAC7550.6050101@redback.com> Date: Tue, 15 Oct 2002 16:06:40 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Loopback address in Multiple Areas? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello Jeff, Jeff wrote: > Hello, > > I have an application which requires a node loopback address to be > advertised in the Router LSA of every active area. Out of curiosity - Why do you require it to be explicitly advertised in the router LSA in every area? > I believe this violates > the practice of assigning each interface (including loopback interfaces) to > an individual area? Yes. > Is this done by anyone? I've seen implementations that do this with a loopback corresponding to the router ID. > Could this cause potential > problems (beyond extra summary lsas)? In general, implementations do not expect it. If an ABR has implemented a more elaborate incremental SPF computation which does individual areas incrementally, it may oscillate the route path between areas. > > Thanks in advance > Jeff > > Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 15 16:26:13 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14693 for ; Tue, 15 Oct 2002 16:26:12 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.007724ED@cherry.ease.lsoft.com>; Tue, 15 Oct 2002 16:28:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 297417 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Oct 2002 16:28:22 -0400 Received: from 64.12.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 15 Oct 2002 16:28:22 -0400 Received: from Routingguy@aol.com by imo-m04.mx.aol.com (mail_out_v34.13.) id 7.ba.2d9c7dfa (4328) for ; Tue, 15 Oct 2002 16:28:09 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 7.0 for Windows US sub 10634 Message-ID: Date: Tue, 15 Oct 2002 16:28:08 EDT Reply-To: Mailing List Sender: Mailing List From: Jeff Subject: Re: Loopback address in Multiple Areas? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, Thanks for your reply. My application scans all Router LSAs in each area for one or more reachable addresses of remote routers. For that node to be declared 'reachable', in that area, it must have an address advertised in the Router LSA. Jeff From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 15 17:14:11 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16164 for ; Tue, 15 Oct 2002 17:14:11 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00772617@cherry.ease.lsoft.com>; Tue, 15 Oct 2002 17:16:20 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 297596 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Oct 2002 17:16:20 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 15 Oct 2002 17:16:19 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 7D49D39B5AD for ; Tue, 15 Oct 2002 14:16:18 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DAC85BB.1050706@redback.com> Date: Tue, 15 Oct 2002 17:16:43 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Loopback address in Multiple Areas? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Jeff wrote: > Acee, > > Thanks for your reply. > > My application scans all Router LSAs in each area for one or more reachable > addresses of remote routers. For that node to be declared 'reachable', in > that area, it must have an address advertised in the Router LSA. Jeff, I'm not sure at what level your application is running but I think you're better off to use your the route table to determine reachability. If you still want to use the OSPF Link State database for discovery you could either use a different loopback in each area or mandate that each router's router ID be a routable loopback address. Thanks, Acee P.S. Let's take this off list since it is more an application discussion. > > Jeff > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 15 19:58:16 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19402 for ; Tue, 15 Oct 2002 19:58:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00772BC5@cherry.ease.lsoft.com>; Tue, 15 Oct 2002 20:00:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 297881 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Oct 2002 20:00:25 -0400 Received: from 63.78.179.216 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 15 Oct 2002 19:50:25 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9FNp3x10593 for ; Tue, 15 Oct 2002 18:51:03 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 15 Oct 2002 18:50:22 -0500 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 18:49:20 -0500 Received: from nokia.com ([172.19.66.85]) by daebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 18:49:19 -0500 X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Oct 2002 23:49:19.0667 (UTC) FILETIME=[7AB17030:01C274A5] Message-ID: <3DACA97F.F1B84461@nokia.com> Date: Tue, 15 Oct 2002 16:49:19 -0700 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Organization: Nokia Networks Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit The list server rejected this mail because of a minor change in my email address. -------- Original Message -------- Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt Date: Tue, 15 Oct 2002 15:55:41 -0700 From: Mukesh Gupta Organization: Nokia Networks To: Stephen Kent CC: Mukesh Gupta ,Jean-Mickael Guerin ,ipsec@lists.tislabs.com, nmelam@iprg.nokia.com,OSPF@DISCUSS.MICROSOFT.COM References: <3D91A3BE.2070904@6wind.com> <3D924D4D.35EBF621@iprg.nokia.com> > The new text on how to demux SAs, that appeared in the revised ESP > and AH IDs several months ago, does not appear to be consistent with > what appears above, nor does that text appear to be consistent with > the old demuxing text. > > What we used to say was that one used the destination IP address, > security protocol (AH or ESP) and the SPI to select an SA. We > realized that, except for multicast addresses, the destination > address is not relevant to the demuxing, and that the security > protocol was generally not needed, since the 32-bit SA is big enough > to provide lots of SAs without using the protocol field. So, the > revised text now says that one looks only at the SPI for unicast > traffic, and at the SPI and destination IP address for multicast > traffic. > > There is no notion of per-interface SAD entries, only per-interface > SPD entries. The text above seems to imply that the same SPI might be > used for two different SAs, that are distinguished by the interfaces > via which packets arrive. That is not consistent with the old or > revised IPsec specs. Only if each interface has its own IPsec > implementation would the description above seem to be consistent. Third paragraph of section 4.4 in RFC2401 says .. "Each interface for which IPsec is enabled requires nominally separate inbound vs. outbound databases (SAD and SPD), because of the directionality of many of the fields that are used as selectors." Doesn't this mean that we have separate SAD *and* SPD for each interface ?? With that assumption, our text is consistent with RFC2401. The implementation can use the interface index to select the right SAD and then the protocol type and SPI can be used to locate a unique SA within that SAD. If there is no notion of per-interface SAD, SPI needs to be a unique identifier to locate the SA because of the proposed sharing of SAs among all the OSPF neighbours. Please note: ** No modifications in the way SAs are demuxed are required to provide security to OSPFv3. ** We are not proposing any modifications to the standard IPsec processing. As long as the SPD has the rules specified in section 9, things will work with the current demuxing scheme (using protocol, SPI and destination addr) as well as the future scheme (using just SPI). In the first version, we didn't have section 9 (IPsec rules). Section 7 was written to explain what selectors will be needed in the SPD but looks like it is creating some confusion. Now as section 9 clearly dictates all the SPD rules required, I think, we can replace section 7 with the following text. (we are removing the text about the selectors and elaborating on the granularity) ==== 7. SA Granularity The user MUST be given a choice to share the same SA among multiple interfaces or using unique SA per interface. ==== Comments ??? regards Mukesh From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 15 19:58:33 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19423 for ; Tue, 15 Oct 2002 19:58:32 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00772B86@cherry.ease.lsoft.com>; Tue, 15 Oct 2002 20:00:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 297882 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Oct 2002 20:00:40 -0400 Received: from 63.78.179.216 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 15 Oct 2002 19:50:39 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9FNpIx10625 for ; Tue, 15 Oct 2002 18:51:18 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 15 Oct 2002 18:50:23 -0500 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 18:50:04 -0500 Received: from nokia.com ([172.19.66.85]) by daebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 18:50:04 -0500 X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Oct 2002 23:50:04.0418 (UTC) FILETIME=[955DE620:01C274A5] Message-ID: <3DACA9AC.85B4221@nokia.com> Date: Tue, 15 Oct 2002 16:50:04 -0700 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Organization: Nokia Networks Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit and here is Steve's reply to the previous mail. -------- Original Message -------- Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt Date: Tue, 15 Oct 2002 19:16:03 -0400 From: "ext Stephen Kent" To: Mukesh Gupta CC: ipsec@lists.tislabs.com References: <3D91A3BE.2070904@6wind.com><3D924D4D.35EBF621@iprg.nokia.com> <3DAC9CED.F791A488@nokia.com> At 3:55 PM -0700 10/15/02, Mukesh Gupta wrote: > > The new text on how to demux SAs, that appeared in the revised ESP >> and AH IDs several months ago, does not appear to be consistent with >> what appears above, nor does that text appear to be consistent with >> the old demuxing text. >> >> What we used to say was that one used the destination IP address, >> security protocol (AH or ESP) and the SPI to select an SA. We >> realized that, except for multicast addresses, the destination >> address is not relevant to the demuxing, and that the security >> protocol was generally not needed, since the 32-bit SA is big enough >> to provide lots of SAs without using the protocol field. So, the >> revised text now says that one looks only at the SPI for unicast >> traffic, and at the SPI and destination IP address for multicast >> traffic. >> >> There is no notion of per-interface SAD entries, only per-interface >> SPD entries. The text above seems to imply that the same SPI might be >> used for two different SAs, that are distinguished by the interfaces >> via which packets arrive. That is not consistent with the old or >> revised IPsec specs. Only if each interface has its own IPsec >> implementation would the description above seem to be consistent. > >Third paragraph of section 4.4 in RFC2401 says .. > >"Each interface for which IPsec is enabled requires nominally separate inbound >vs. outbound databases (SAD and SPD), because of the directionality of many of >the fields that are used as selectors." Another list member pointed this out to me and I have to admit that this text does suggest that. However, the rest of the discussion of the SAD does not support this interpretation. The discussion of the SPI in 2401 and in the AH and ESP specs makes it pretty clear that the SPI must be generated on a device-unique basis, which is not consistent with the per-interface SAD interpretation. I'm sorry the text above was mislesding. > >Doesn't this mean that we have separate SAD *and* SPD for each >interface ?? With >that assumption, our text is consistent with RFC2401. The >implementation can use >the interface index to select the right SAD and then the protocol type and SPI >can be used to locate a unique SA within that SAD. > >If there is no notion of per-interface SAD, SPI needs to be a unique >identifier >to locate the SA because of the proposed sharing of SAs among all the OSPF >neighbours. Right, unless each interface was a complete IPsec implementation, as I suggested. Certainly if each line card, for example, has its own IPsec chip and software, there would be coordination among them and SPIs might well be duplicated. So, there is a notion of an IPsec "device" and SPIs are unique per device. If the device supports multiple interfaces, the the SPIs are unique across all of those interfaces. > >Please note: >** No modifications in the way SAs are demuxed are required to >provide security >to OSPFv3. ** > >We are not proposing any modifications to the standard IPsec >processing. As long >as the SPD has the rules specified in section 9, things will work with the >current demuxing scheme (using protocol, SPI and destination addr) >as well as the >future scheme (using just SPI). OK. >In the first version, we didn't have section 9 (IPsec rules). Section 7 was >written to explain what selectors will be needed in the SPD but >looks like it is >creating some confusion. Now as section 9 clearly dictates all the SPD rules >required, I think, we can replace section 7 with the following text. (we are >removing the text about the selectors and elaborating on the granularity) > >==== >7. SA Granularity > >The user MUST be given a choice to share the same SA among multiple >interfaces or >using unique SA per interface. >==== > >Comments ??? In the process if revising 2401, we are trying to better address the issues of when routing is done relative to SA lookup and how interfaces or virtual interfaces fit into the processing model. As for the text immediately above (section 7) if you want per-interface SAs, then you have to determine how they are different in terms that IPsec cares about. One model we have discussed is to invoke an abstract routing/forwarding function before the SPD lookup and have it return the ID of a virtual interface. then that ID would be used to select the appropriate SPD (which we all agree is per-interface) for SA selection. That, I think, would meet your requirements. Steve From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 15 20:49:22 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20114 for ; Tue, 15 Oct 2002 20:49:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00772CC1@cherry.ease.lsoft.com>; Tue, 15 Oct 2002 20:51:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 298006 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Oct 2002 20:51:32 -0400 Received: from 63.78.179.217 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 15 Oct 2002 20:51:32 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9G0qFM18835 for ; Tue, 15 Oct 2002 19:52:15 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Oct 2002 19:51:31 -0500 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 19:50:24 -0500 Received: from nokia.com ([172.19.66.85]) by daebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 19:50:23 -0500 X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3D91A3BE.2070904@6wind.com> <3D924D4D.35EBF621@iprg.nokia.com> <3DAC9CED.F791A488@nokia.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2002 00:50:23.0714 (UTC) FILETIME=[02A2A420:01C274AE] Message-ID: <3DACB7CF.1F04C00A@nokia.com> Date: Tue, 15 Oct 2002 17:50:23 -0700 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Organization: Nokia Networks Subject: Re: draft-gupta-ospf-ospfv3-auth-01.txt Comments: To: ext Stephen Kent Comments: cc: ipsec@lists.tislabs.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit > In the process if revising 2401, we are trying to better address the > issues of when routing is done relative to SA lookup and how > interfaces or virtual interfaces fit into the processing model. > > As for the text immediately above (section 7) if you want > per-interface SAs, then you have to determine how they are different > in terms that IPsec cares about. One model we have discussed is to > invoke an abstract routing/forwarding function before the SPD lookup > and have it return the ID of a virtual interface. then that ID would > be used to select the appropriate SPD (which we all agree is > per-interface) for SA selection. That, I think, would meet your > requirements. Looks like it would. We were thinking that it was the responsibility of underlying layers to mark the packets with the virtual interface ID. This again goes to the generic IPsec implementation details. So, I would not like to mention this in this draft. I will modify section 7 of the draft to the new text in the next revision. Thanks... regards Mukesh From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 15 23:50:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23014 for ; Tue, 15 Oct 2002 23:50:32 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0077337D@cherry.ease.lsoft.com>; Tue, 15 Oct 2002 23:52:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 298373 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Oct 2002 23:52:41 -0400 Received: from 135.207.30.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 15 Oct 2002 23:52:41 -0400 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id D69A64CF6B for ; Tue, 15 Oct 2002 23:52:40 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id XAA10695 for ; Tue, 15 Oct 2002 23:52:40 -0400 (EDT) Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id UAA19886; Tue, 15 Oct 2002 20:52:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Versions: dmail (solaris) 2.5a/makemail 2.9d Message-ID: <200210160352.UAA19886@windsor.research.att.com> Date: Tue, 15 Oct 2002 20:52:38 -0700 Reply-To: Mailing List Sender: Mailing List From: Bill Fenner Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list To avoid misunderstandings: although I am contributing to this discussion because I am an AD, this message is a technical contribution, not a ruling from on high. I'd like to actually have the discussion, not make a mandate, so please treat this like you would treat a technical contribution from anyone else. Kireeti says: >there are a *small* number of >currently defined Opaque LSAs -- TE, Grace LSA, and perhaps one more. >If we analyse the applicability of those LSAs to OSPF v3, and mandate >that any future definition of an OSPFv2 Opaque LSA MUST have a similar >analysis, that seems to me to address the "backdoor" problem. Let's step back half a step and look at this solution -- documenting the v3 applicability of the existing Opaque LSAs and requiring documentation of same on future LSAs -- vs. allocating a new OSPFv3 LSA type for each OSPFv2 Opqaue LSA type. Boiling it down to the basics, OSPFv2 Opaque LSAs have a flooding scope (type 9, 10 or 11), an 8-bit type and a 24-bit LS [Opaque] ID. All OSPFv3 LSAs have a flooding scope (the top 2 bits of the LS Type), a 14-bit type and a 32-bit LS ID. Given this, why is it better to allocate a single OSPFv3 type for this purpose? Presumably, the real place that code reuse comes into play is in parsing the contents of the LSA, not the header; the OSPFv2 and OSPFv3 headers are only subtly different but different enough that you're not going to use the same code to parse both of them anyway. Using the native OSPFv3 LSA format instead of a copied Opaque format gives you more bits in the type space and more bits in the LS ID. It also gives you the flexibility to standardize independently; you may want to standardize an OSPFv2 Opaque LSA before the implications of that type on OSPFv3 is fully understood. With a shared space, and your suggestion of analyzing the OSPFv3 implications of any Opaque LSA, that wouldn't be allowed. Finally, it also allows a proposal to utilize the OSPFv3 U bit, if the non-global behavior is desired. Perhaps I'm missing something, but it seems that saying "OSPFv2 type-10 LSA opaque type #4, OSPFv3 type-0xa014, LSA contents ____" is not significantly different than saying "OSPFv2 type-10 LSA, OSPFv3 type-(whatever 10 maps to) LSA, opaque type #4, LSA contents ____". Bill From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 16 06:26:34 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23858 for ; Wed, 16 Oct 2002 06:26:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0077403D@cherry.ease.lsoft.com>; Wed, 16 Oct 2002 6:28:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 299712 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Oct 2002 06:28:41 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 16 Oct 2002 06:18:41 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00773F19@cherry.ease.lsoft.com>; Wed, 16 Oct 2002 6:18:41 -0400 Message-ID: Date: Wed, 16 Oct 2002 06:18:41 -0400 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Running time for SPF in ISIS To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list >There ARE efficient algorithms for queue management which give something >like O (loglogN) (I forget exactly what). yes, fibonacci heaps are real good given you have >1E6 nodes to do SPFs on. > But these tend to be fiendishly >complicated and just aren't worth the trouble for SPFs in communication >networks. However in other applications where it is desired to run an SPF >with (say) millions of nodes, then the use of these algorithms may become >important. yes, same experience From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 16 10:02:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29565 for ; Wed, 16 Oct 2002 10:02:26 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00774333@cherry.ease.lsoft.com>; Wed, 16 Oct 2002 10:04:36 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 300202 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Oct 2002 10:04:37 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 16 Oct 2002 10:04:36 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 66B85F2C42 for ; Wed, 16 Oct 2002 07:04:35 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DAD7202.2070804@redback.com> Date: Wed, 16 Oct 2002 10:04:50 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: WG Last Call for To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit This is a Working Group Last Call for the I-D "Detecting Inactive Neighbors over OSPF Deamnd Circuits" . This I-D describes a neighbor probing technique for detecting inactive neighbors on demand circuits [RFC1793]. We are requesting that this protocol specification be labeled a Proposed Standard. Please submit comments on the I-D to the authors and/or ospf@discuss.microsoft.com by Wednesday, October 30th. The abstract of the I-D reads as follows: OSPF [RFC2328] is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits is optimized in [RFC1793] to minimize the amount of overhead traffic. A part of OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect a OSPF-inactive neighbor over such a link. This memo addresses the above problem by the neighbor probing mechanism. Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 16 11:15:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02710 for ; Wed, 16 Oct 2002 11:15:36 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00774650@cherry.ease.lsoft.com>; Wed, 16 Oct 2002 11:17:45 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 300450 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Oct 2002 11:17:45 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 16 Oct 2002 11:17:45 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 5786F5E446 for ; Wed, 16 Oct 2002 08:17:43 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210160352.UAA19886@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DAD8326.6000505@redback.com> Date: Wed, 16 Oct 2002 11:17:58 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I originally thought that we'd simply define an opaque LSA type for OSPFv3. However, after hearing all the arguments, I think that defining a new LSA type for each OSPFv3 application is the right direction. In addition to Bill's points, I think that defining unique LSA types will lend itself to a more natural implementation and user interface for handling application specific LSAs. Bill Fenner wrote: > To avoid misunderstandings: although I am contributing to this discussion > because I am an AD, this message is a technical contribution, not a ruling > from on high. I'd like to actually have the discussion, not make a mandate, > so please treat this like you would treat a technical contribution from > anyone else. > > Kireeti says: > >>there are a *small* number of >>currently defined Opaque LSAs -- TE, Grace LSA, and perhaps one more. >>If we analyse the applicability of those LSAs to OSPF v3, and mandate >>that any future definition of an OSPFv2 Opaque LSA MUST have a similar >>analysis, that seems to me to address the "backdoor" problem. >> > > Let's step back half a step and look at this solution -- documenting > the v3 applicability of the existing Opaque LSAs and requiring documentation > of same on future LSAs -- vs. allocating a new OSPFv3 LSA type for each > OSPFv2 Opqaue LSA type. > > Boiling it down to the basics, OSPFv2 Opaque LSAs have a flooding > scope (type 9, 10 or 11), an 8-bit type and a 24-bit LS [Opaque] ID. > All OSPFv3 LSAs have a flooding scope (the top 2 bits of the LS Type), > a 14-bit type and a 32-bit LS ID. > > Given this, why is it better to allocate a single OSPFv3 type for > this purpose? Presumably, the real place that code reuse comes into > play is in parsing the contents of the LSA, not the header; the OSPFv2 > and OSPFv3 headers are only subtly different but different enough that > you're not going to use the same code to parse both of them anyway. > > Using the native OSPFv3 LSA format instead of a copied Opaque format > gives you more bits in the type space and more bits in the LS ID. > It also gives you the flexibility to standardize independently; > you may want to standardize an OSPFv2 Opaque LSA before the implications > of that type on OSPFv3 is fully understood. With a shared space, > and your suggestion of analyzing the OSPFv3 implications of any Opaque > LSA, that wouldn't be allowed. Finally, it also allows a proposal to > utilize the OSPFv3 U bit, if the non-global behavior is desired. > > Perhaps I'm missing something, but it seems that saying "OSPFv2 > type-10 LSA opaque type #4, OSPFv3 type-0xa014, LSA contents ____" is > not significantly different than saying "OSPFv2 type-10 LSA, OSPFv3 > type-(whatever 10 maps to) LSA, opaque type #4, LSA contents ____". > > Bill > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 16 12:26:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04893 for ; Wed, 16 Oct 2002 12:26:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.007749FE@cherry.ease.lsoft.com>; Wed, 16 Oct 2002 12:28:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 300989 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Oct 2002 12:28:18 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 16 Oct 2002 12:28:18 -0400 Received: (qmail 31818 invoked from network); 16 Oct 2002 16:28:18 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 16 Oct 2002 16:28:18 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id MAA11941 for ; Wed, 16 Oct 2002 12:28:17 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210161628.MAA11941@bigbird.xebeo.com> Date: Wed, 16 Oct 2002 12:28:17 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from Acee Lindem of "Wed, 16 Oct 2002 11:17:58 EDT." <3DAD8326.6000505@redback.com> Precedence: list On Wed, 16 Oct 2002 11:17:58 -0400 Acee Lindem writes: =>I originally thought that we'd simply define an opaque LSA type =>for OSPFv3. However, after hearing all the arguments, I think that defining =>a new LSA type for each OSPFv3 application is the right direction. In =>addition to Bill's points, I think that defining unique LSA types =>will lend itself to a more natural implementation and user interface =>for handling application specific LSAs. Having gone back and forth on this a couple times, I come out the same way : (most) code should still be reusable even as new protocol objects have a better chance of being well specified with this approach. Regards, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 16 14:01:01 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07542 for ; Wed, 16 Oct 2002 14:01:00 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00774DA8@cherry.ease.lsoft.com>; Wed, 16 Oct 2002 14:03:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 301321 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Oct 2002 14:03:06 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 16 Oct 2002 14:03:05 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl133-19.cisco.com [144.254.54.214]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9GI34009118 for ; Wed, 16 Oct 2002 11:03:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-eAcceleration: FMT=1;FLAGS=0 Message-ID: Date: Wed, 16 Oct 2002 09:56:09 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210160352.UAA19886@windsor.research.att.com> Precedence: list Content-Transfer-Encoding: 7bit Bill, > Kireeti says: > >there are a *small* number of > >currently defined Opaque LSAs -- TE, Grace LSA, and perhaps one more. > >If we analyse the applicability of those LSAs to OSPF v3, and mandate > >that any future definition of an OSPFv2 Opaque LSA MUST have a similar > >analysis, that seems to me to address the "backdoor" problem. > > Let's step back half a step and look at this solution -- documenting > the v3 applicability of the existing Opaque LSAs and requiring > documentation > of same on future LSAs -- vs. allocating a new OSPFv3 LSA type for each > OSPFv2 Opqaue LSA type. > if you want to allocate a new LSA type for each opaque type ( or better say for each new LSA introduced ) then we won't need to call this opaque LSA, you basically want to go to the idea of 'introducing a new LSA type' for each 'new LSA defined' and we will end up with many, many LSA type which I am not sure is a clean way ... > Boiling it down to the basics, OSPFv2 Opaque LSAs have a flooding > scope (type 9, 10 or 11), an 8-bit type and a 24-bit LS [Opaque] ID. > All OSPFv3 LSAs have a flooding scope (the top 2 bits of the LS Type), > a 14-bit type and a 32-bit LS ID. I believe it is better to have opaque LSA as it was introduced in v2 that is, use LSID to break it down to Opaque type and instance, if you are concerned about 'bit shortcoming' for those fields we could always add more Functional code in LS type to handle this. since flooding is now explicitly coded, we could allocate a range say 10-20 for opaque LSA so if we are done with FC = 10 as it was introduced in Kireeti draft and used all the bits for opaque type in LS ID we will use FC = 11 etc that way we honor the name opaque LSA ;-) and won't introduce a new LSA type every time we need to define a LSA also it is not because we define opaque in v3 the same way as in v2 ( that is, using LS ID for opaque type and instance ) that we have to sync completely between v2 and v3, ospfv3 could have its own opaque type to be defined / standardized independently ... Sina Outgoing messages scanned and certified safe by Stop-Sign, the Personal Alarm Service. http://defender.veloz.com/dlp_ban/?n=tl&sp=08.out002 From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 16 16:58:04 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12158 for ; Wed, 16 Oct 2002 16:58:03 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0077565E@cherry.ease.lsoft.com>; Wed, 16 Oct 2002 17:00:08 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 302035 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Oct 2002 17:00:08 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 16 Oct 2002 17:00:07 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id C5C73FC04E for ; Wed, 16 Oct 2002 14:00:05 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DADD361.3020109@redback.com> Date: Wed, 16 Oct 2002 17:00:17 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF ASBR Path Selection To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit As a piece of unfinished business, Alex Zinin asked that I review a question regarding ASBR path selection when an external prefix is advertised through an ASBR accessible via multiple areas. The crux of the issue is whether RFC 2328 section 16.2(6) and section 16.4.1 conflict with one another and can result in a routing loop. A link to one of the E-mails on the subject is included below: Excerpted from RFC 16.2 (6) Else, if the paths present in the table are intra-area paths, do nothing with the LSA (intra-area paths are always preferred). Excerpted from RFC 16.4.1 When multiple intra-AS paths are available to ASBRs/forwarding addresses, the following rules indicate which paths are preferred. These rules apply when the same ASBR is reachable through multiple areas, or when trying to decide which of several AS-external-LSAs should be preferred. In the former case the paths all terminate at the same ASBR, while in the latter the paths terminate at separate ASBRs/forwarding addresses. In either case, each path is represented by a separate routing table entry as defined in Section 11. This section only applies when RFC1583Compatibility is set to "disabled". The path preference rules, stated from highest to lowest preference, are as follows. Note that as a result of these rules, there may still be multiple paths of the highest preference. In this case, the path to use must be determined based on cost, as described in Section 16.4. o Intra-area paths using non-backbone areas are always the most preferred. o The other paths, intra-area backbone paths and inter- area paths, are of equal preference. I've looked at this and my opinion is that while RFC 2328 could be more explicit, there is no problem. The reason is that section 16.2 (5) explicitly specifies that for a router route you must look up the routing table entry associated with the area whose summaries you are examining. Hence, the rule in (6) only applies to an intra-area path through the same area as the inter-area path. Excerpted from RFC 2328 Section 16.2: (5) Next, look up the routing table entry for the destination N. (If N is an AS boundary router, look up the "router" routing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ table entry associated with Area A). If no entry exists for ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ N or if the entry's path type is "type 1 external" or "type 2 external", then install the inter-area path to N, with associated area Area A, cost IAC, next hop equal to the list of next hops to router BR, and Advertising router equal to BR. Are there any implementations that calculate a single ASBR route (vis-a-vis one per area) and strictly prefer an intra-area path over an inter-area path (independent of the corresponding areas)? Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 01:57:13 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22187 for ; Thu, 17 Oct 2002 01:57:13 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.007772F4@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 1:59:22 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 303940 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 01:59:22 -0400 Received: from 192.51.44.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 01:59:21 -0400 Received: from m6.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0205-Fujitsu Gateway) id OAA25235 for ; Thu, 17 Oct 2002 14:59:16 +0900 (JST) (envelope-from kashima@nd.net.fujitsu.co.jp) Received: from chisato.nd.net.fujitsu.co.jp by m6.gw.fujitsu.co.jp (8.9.3/3.7W-0209-Fujitsu Domain Master) id OAA27562 for ; Thu, 17 Oct 2002 14:59:16 +0900 (envelope-from kashima@nd.net.fujitsu.co.jp) Received: from localhost (debian.nd.net.fujitsu.co.jp [10.22.113.42]) by chisato.nd.net.fujitsu.co.jp (8.11.6+3.4W/3.7W-chisato-02072615) with ESMTP id g9H5xBV06728 for ; Thu, 17 Oct 2002 14:59:11 +0900 (JST) X-Mailer: Mew version 1.94.2 on Emacs 20.5 / Mule 4.0 (HANANOEN) X-PGP-fingerprint: 2D EB DA CB 42 DE F6 02 10 BC AA 5E CB 35 57 D4 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 9 Message-ID: <20021017145911K.kashima@debian.nd.net.fujitsu.co.jp> Date: Thu, 17 Oct 2002 14:59:11 +0900 Reply-To: Mailing List Sender: Mailing List From: KASHIMA Hiroaki Subject: MD5 interoperability To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi. Does anyone know Cisco's MD5 connects with other implements? I'm implementing MD5 for my daemon, which can connect with gated-3.6 and zebra-0.91a, but cannot connect with cisco 12.2(2)T1. -- KASHIMA, Hiroaki Software Development Deptartment-II, IP Systems Division, Network System Group From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 03:32:24 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02940 for ; Thu, 17 Oct 2002 03:32:24 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.007775F8@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 3:34:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 304155 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 03:34:34 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 03:34:33 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZB83QJ>; Thu, 17 Oct 2002 13:04:20 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06A766D8@haritha.hclt.com> Date: Thu, 17 Oct 2002 13:06:43 +0530 Reply-To: Mailing List Sender: Mailing List From: "Sudharsana V - CTD, Chennai." Subject: Re: OSPF ASBR Path Selection To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee, With respect to an ABR with backbone connectivity the summary LSAs used for calculation in 16.2 will belong to backbone. Hence, -interpretation of 16.2 (5) is to see if the ASBR(destination N described by the summary LSA) is reachable through backbone intra-area paths. -interpretation of 16.2 (6) is to prefer backbone intra-area paths over inter-area paths Will such an interpretation not conflict with the preference rules of 16.4.1 ? ------------------------------- | bkbone | | 12(cost) | R1..............ASBR.... |\ | ! | \...............R2...! | 5(cost) |3(cost) | | | | non-bkbone ------------------------- | R1 and R2 are ABRs. R1's intra-area (backbone) path cost to ASBR is 12. R1's intra-area (backbone) path cost to R2 is 5. R2's intra-area (non-backbone) path cost to ASBR is 3. By following 16.2 verbatim, will R1 not choose the intra-area path of cost 12? while applying 16.4.1 would have resulted in selection of inter-area path (of cost 8) through R2. I am unable to understand how you feel that there is no problem. Am I missing something? Regards, Sudharsana -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Thursday, October 17, 2002 2:30 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF ASBR Path Selection As a piece of unfinished business, Alex Zinin asked that I review a question regarding ASBR path selection when an external prefix is advertised through an ASBR accessible via multiple areas. The crux of the issue is whether RFC 2328 section 16.2(6) and section 16.4.1 conflict with one another and can result in a routing loop. A link to one of the E-mails on the subject is included below: Excerpted from RFC 16.2 (6) Else, if the paths present in the table are intra-area paths, do nothing with the LSA (intra-area paths are always preferred). Excerpted from RFC 16.4.1 When multiple intra-AS paths are available to ASBRs/forwarding addresses, the following rules indicate which paths are preferred. These rules apply when the same ASBR is reachable through multiple areas, or when trying to decide which of several AS-external-LSAs should be preferred. In the former case the paths all terminate at the same ASBR, while in the latter the paths terminate at separate ASBRs/forwarding addresses. In either case, each path is represented by a separate routing table entry as defined in Section 11. This section only applies when RFC1583Compatibility is set to "disabled". The path preference rules, stated from highest to lowest preference, are as follows. Note that as a result of these rules, there may still be multiple paths of the highest preference. In this case, the path to use must be determined based on cost, as described in Section 16.4. o Intra-area paths using non-backbone areas are always the most preferred. o The other paths, intra-area backbone paths and inter- area paths, are of equal preference. I've looked at this and my opinion is that while RFC 2328 could be more explicit, there is no problem. The reason is that section 16.2 (5) explicitly specifies that for a router route you must look up the routing table entry associated with the area whose summaries you are examining. Hence, the rule in (6) only applies to an intra-area path through the same area as the inter-area path. Excerpted from RFC 2328 Section 16.2: (5) Next, look up the routing table entry for the destination N. (If N is an AS boundary router, look up the "router" routing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ table entry associated with Area A). If no entry exists for ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ N or if the entry's path type is "type 1 external" or "type 2 external", then install the inter-area path to N, with associated area Area A, cost IAC, next hop equal to the list of next hops to router BR, and Advertising router equal to BR. Are there any implementations that calculate a single ASBR route (vis-a-vis one per area) and strictly prefer an intra-area path over an inter-area path (independent of the corresponding areas)? Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 03:40:38 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03025 for ; Thu, 17 Oct 2002 03:40:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00777693@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 3:42:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 304192 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 03:42:48 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 03:42:47 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZB83TJ>; Thu, 17 Oct 2002 13:12:36 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06A766FB@haritha.hclt.com> Date: Thu, 17 Oct 2002 13:14:59 +0530 Reply-To: Mailing List Sender: Mailing List From: "Sudharsana V - CTD, Chennai." Subject: FW: OSPF ASBR Path Selection To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -----Original Message----- From: Sudharsana V - CTD, Chennai. Sent: Thursday, October 17, 2002 1:14 PM To: Sudharsana V - CTD, Chennai. Subject: RE: OSPF ASBR Path Selection Sorry! the figure is not proper in the previous mail. ------------------------------- | bkbone | | 12(cost) | R1..............ASBR.... |\ | ! | \...............R2...! | 5(cost) |3(cost) | | | | non-bkbone ------------------------- | -----Original Message----- From: Sudharsana V - CTD, Chennai. [mailto:vsudharsana@CTD.HCLTECH.COM] Sent: Thursday, October 17, 2002 1:07 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF ASBR Path Selection Hi Acee, With respect to an ABR with backbone connectivity the summary LSAs used for calculation in 16.2 will belong to backbone. Hence, -interpretation of 16.2 (5) is to see if the ASBR(destination N described by the summary LSA) is reachable through backbone intra-area paths. -interpretation of 16.2 (6) is to prefer backbone intra-area paths over inter-area paths Will such an interpretation not conflict with the preference rules of 16.4.1 ? ------------------------------- | bkbone | | 12(cost) | R1..............ASBR.... |\ | ! | \...............R2...! | 5(cost) |3(cost) | | | | non-bkbone ------------------------- | R1 and R2 are ABRs. R1's intra-area (backbone) path cost to ASBR is 12. R1's intra-area (backbone) path cost to R2 is 5. R2's intra-area (non-backbone) path cost to ASBR is 3. By following 16.2 verbatim, will R1 not choose the intra-area path of cost 12? while applying 16.4.1 would have resulted in selection of inter-area path (of cost 8) through R2. I am unable to understand how you feel that there is no problem. Am I missing something? Regards, Sudharsana -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Thursday, October 17, 2002 2:30 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF ASBR Path Selection As a piece of unfinished business, Alex Zinin asked that I review a question regarding ASBR path selection when an external prefix is advertised through an ASBR accessible via multiple areas. The crux of the issue is whether RFC 2328 section 16.2(6) and section 16.4.1 conflict with one another and can result in a routing loop. A link to one of the E-mails on the subject is included below: Excerpted from RFC 16.2 (6) Else, if the paths present in the table are intra-area paths, do nothing with the LSA (intra-area paths are always preferred). Excerpted from RFC 16.4.1 When multiple intra-AS paths are available to ASBRs/forwarding addresses, the following rules indicate which paths are preferred. These rules apply when the same ASBR is reachable through multiple areas, or when trying to decide which of several AS-external-LSAs should be preferred. In the former case the paths all terminate at the same ASBR, while in the latter the paths terminate at separate ASBRs/forwarding addresses. In either case, each path is represented by a separate routing table entry as defined in Section 11. This section only applies when RFC1583Compatibility is set to "disabled". The path preference rules, stated from highest to lowest preference, are as follows. Note that as a result of these rules, there may still be multiple paths of the highest preference. In this case, the path to use must be determined based on cost, as described in Section 16.4. o Intra-area paths using non-backbone areas are always the most preferred. o The other paths, intra-area backbone paths and inter- area paths, are of equal preference. I've looked at this and my opinion is that while RFC 2328 could be more explicit, there is no problem. The reason is that section 16.2 (5) explicitly specifies that for a router route you must look up the routing table entry associated with the area whose summaries you are examining. Hence, the rule in (6) only applies to an intra-area path through the same area as the inter-area path. Excerpted from RFC 2328 Section 16.2: (5) Next, look up the routing table entry for the destination N. (If N is an AS boundary router, look up the "router" routing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ table entry associated with Area A). If no entry exists for ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ N or if the entry's path type is "type 1 external" or "type 2 external", then install the inter-area path to N, with associated area Area A, cost IAC, next hop equal to the list of next hops to router BR, and Advertising router equal to BR. Are there any implementations that calculate a single ASBR route (vis-a-vis one per area) and strictly prefer an intra-area path over an inter-area path (independent of the corresponding areas)? Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 04:14:01 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03468 for ; Thu, 17 Oct 2002 04:14:00 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00777628@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 4:16:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 304260 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 04:16:11 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 04:16:11 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZB8PK5>; Thu, 17 Oct 2002 13:45:58 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06A76740@haritha.hclt.com> Date: Thu, 17 Oct 2002 13:48:21 +0530 Reply-To: Mailing List Sender: Mailing List From: "Sudharsana V - CTD, Chennai." Subject: FW: OSPF ASBR Path Selection To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -----Original Message----- From: Sudharsana V - CTD, Chennai. Sent: Thursday, October 17, 2002 1:41 PM To: 'sudharsh_venk@yahoo.com' Subject: RE: OSPF ASBR Path Selection Sorry again. Hope this reaches properly ......................................................... . Area 0 . area 1 . +----+ 12 ( cost ) +----+ | R1 | -----------------|Asbr|_______ | | | | | +----+ +----+ | \ . | \ . | \ . |3(cost) \ +----+ | \______________ | R2 |-------| 5(cost) | | +----+ . . .......................................................... -----Original Message----- From: Sudharsana V - CTD, Chennai. [mailto:vsudharsana@CTD.HCLTECH.COM] Sent: Thursday, October 17, 2002 1:15 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: FW: OSPF ASBR Path Selection -----Original Message----- From: Sudharsana V - CTD, Chennai. Sent: Thursday, October 17, 2002 1:14 PM To: Sudharsana V - CTD, Chennai. Subject: RE: OSPF ASBR Path Selection Sorry! the figure is not proper in the previous mail. ------------------------------- | bkbone | | 12(cost) | R1..............ASBR.... |\ | ! | \...............R2...! | 5(cost) |3(cost) | | | | non-bkbone ------------------------- | -----Original Message----- From: Sudharsana V - CTD, Chennai. [mailto:vsudharsana@CTD.HCLTECH.COM] Sent: Thursday, October 17, 2002 1:07 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF ASBR Path Selection Hi Acee, With respect to an ABR with backbone connectivity the summary LSAs used for calculation in 16.2 will belong to backbone. Hence, -interpretation of 16.2 (5) is to see if the ASBR(destination N described by the summary LSA) is reachable through backbone intra-area paths. -interpretation of 16.2 (6) is to prefer backbone intra-area paths over inter-area paths Will such an interpretation not conflict with the preference rules of 16.4.1 ? ------------------------------- | bkbone | | 12(cost) | R1..............ASBR.... |\ | ! | \...............R2...! | 5(cost) |3(cost) | | | | non-bkbone ------------------------- | R1 and R2 are ABRs. R1's intra-area (backbone) path cost to ASBR is 12. R1's intra-area (backbone) path cost to R2 is 5. R2's intra-area (non-backbone) path cost to ASBR is 3. By following 16.2 verbatim, will R1 not choose the intra-area path of cost 12? while applying 16.4.1 would have resulted in selection of inter-area path (of cost 8) through R2. I am unable to understand how you feel that there is no problem. Am I missing something? Regards, Sudharsana -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Thursday, October 17, 2002 2:30 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF ASBR Path Selection As a piece of unfinished business, Alex Zinin asked that I review a question regarding ASBR path selection when an external prefix is advertised through an ASBR accessible via multiple areas. The crux of the issue is whether RFC 2328 section 16.2(6) and section 16.4.1 conflict with one another and can result in a routing loop. A link to one of the E-mails on the subject is included below: Excerpted from RFC 16.2 (6) Else, if the paths present in the table are intra-area paths, do nothing with the LSA (intra-area paths are always preferred). Excerpted from RFC 16.4.1 When multiple intra-AS paths are available to ASBRs/forwarding addresses, the following rules indicate which paths are preferred. These rules apply when the same ASBR is reachable through multiple areas, or when trying to decide which of several AS-external-LSAs should be preferred. In the former case the paths all terminate at the same ASBR, while in the latter the paths terminate at separate ASBRs/forwarding addresses. In either case, each path is represented by a separate routing table entry as defined in Section 11. This section only applies when RFC1583Compatibility is set to "disabled". The path preference rules, stated from highest to lowest preference, are as follows. Note that as a result of these rules, there may still be multiple paths of the highest preference. In this case, the path to use must be determined based on cost, as described in Section 16.4. o Intra-area paths using non-backbone areas are always the most preferred. o The other paths, intra-area backbone paths and inter- area paths, are of equal preference. I've looked at this and my opinion is that while RFC 2328 could be more explicit, there is no problem. The reason is that section 16.2 (5) explicitly specifies that for a router route you must look up the routing table entry associated with the area whose summaries you are examining. Hence, the rule in (6) only applies to an intra-area path through the same area as the inter-area path. Excerpted from RFC 2328 Section 16.2: (5) Next, look up the routing table entry for the destination N. (If N is an AS boundary router, look up the "router" routing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ table entry associated with Area A). If no entry exists for ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ N or if the entry's path type is "type 1 external" or "type 2 external", then install the inter-area path to N, with associated area Area A, cost IAC, next hop equal to the list of next hops to router BR, and Advertising router equal to BR. Are there any implementations that calculate a single ASBR route (vis-a-vis one per area) and strictly prefer an intra-area path over an inter-area path (independent of the corresponding areas)? Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 09:27:58 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10263 for ; Thu, 17 Oct 2002 09:27:57 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00778055@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 9:30:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 305782 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 09:30:07 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 09:30:07 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 685221DCC7D for ; Thu, 17 Oct 2002 06:30:05 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <55E277B99171E041ABF5F4B1C6DDCA06A76740@haritha.hclt.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DAEBB60.7090707@redback.com> Date: Thu, 17 Oct 2002 09:30:08 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: FW: OSPF ASBR Path Selection To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sudharsana V - CTD, Chennai. wrote: > -----Original Message----- > From: Sudharsana V - CTD, Chennai. > Sent: Thursday, October 17, 2002 1:41 PM > To: 'sudharsh_venk@yahoo.com' > Subject: RE: OSPF ASBR Path Selection > > > Sorry again. Hope this reaches properly Hi Sudharsana, Picture looks good. See response below. > ......................................................... > . > Area 0 . area 1 > . > +----+ 12 ( cost ) +----+ > | R1 | -----------------|Asbr|_______ > | | | | | > +----+ +----+ | > \ . | > \ . | > \ . |3(cost) > \ +----+ | > \______________ | R2 |-------| > 5(cost) | | > +----+ > . > > Hi Acee, > With respect to an ABR with backbone connectivity the summary LSAs used for > calculation in 16.2 will belong to backbone. Hence, > -interpretation of 16.2 (5) is to see if the ASBR(destination N described by > the summary LSA) is reachable through backbone intra-area paths. > -interpretation of 16.2 (6) is to prefer backbone intra-area paths over > inter-area paths > Will such an interpretation not conflict with the preference rules > of 16.4.1? > In this situation R1 is an internal router for the area 0. During its SPF calculation for area 0 it will compute an intra-area ASBR route. This path will not be overridden during the summary calculation. When AS external routes are computed in section 16.4, there are not multiple paths to the ASBR so section so the path selection 16.4.1 is not available. Refer to section G.2 is RFC 2328 for a description of the situation section 16.4.1 was added to cover. > > > ------------------------------- > | bkbone | > | 12(cost) | > R1..............ASBR.... > |\ | ! > | \...............R2...! > | 5(cost) |3(cost) > | | > | | non-bkbone > ------------------------- > | > > > > R1 and R2 are ABRs. > R1's intra-area (backbone) path cost to ASBR is 12. > R1's intra-area (backbone) path cost to R2 is 5. > R2's intra-area (non-backbone) path cost to ASBR is 3. > By following 16.2 verbatim, will R1 not choose the intra-area path of cost > 12? while applying 16.4.1 would have resulted > in selection of inter-area path (of cost 8) through R2. > I am unable to understand how you feel that there is no problem. Am I > missing something? > Regards, > Sudharsana > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Thursday, October 17, 2002 2:30 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: OSPF ASBR Path Selection > > > As a piece of unfinished business, Alex Zinin asked that I > review a question regarding ASBR path selection when an external prefix > is advertised through an ASBR accessible via multiple areas. The crux of > the issue is whether RFC 2328 section 16.2(6) and section 16.4.1 conflict > with one another and can result in a routing loop. A link to > one of the E-mails on the subject is included below: > > =-3> > > Excerpted from RFC 16.2 > > (6) Else, if the paths present in the table are intra-area > paths, do nothing with the LSA (intra-area paths are always > preferred). > > Excerpted from RFC 16.4.1 > > When multiple intra-AS paths are available to > ASBRs/forwarding addresses, the following rules indicate > which paths are preferred. These rules apply when the same > ASBR is reachable through multiple areas, or when trying to > decide which of several AS-external-LSAs should be > preferred. In the former case the paths all terminate at the > same ASBR, while in the latter the paths terminate at > separate ASBRs/forwarding addresses. In either case, each > path is represented by a separate routing table entry as > defined in Section 11. > > This section only applies when RFC1583Compatibility is set > to "disabled". > > The path preference rules, stated from highest to lowest > preference, are as follows. Note that as a result of these > rules, there may still be multiple paths of the highest > preference. In this case, the path to use must be determined > based on cost, as described in Section 16.4. > > o Intra-area paths using non-backbone areas are always the > most preferred. > > o The other paths, intra-area backbone paths and inter- > area paths, are of equal preference. > > > I've looked at this and my opinion is that while RFC 2328 > could be more explicit, there is no problem. The reason is that > section 16.2 (5) explicitly specifies that for a router route you must > look up the routing table entry associated with the area whose summaries > you are examining. Hence, the rule in (6) only applies to an intra-area > path through the same area as the inter-area path. > > Excerpted from RFC 2328 Section 16.2: > > (5) Next, look up the routing table entry for the destination N. > (If N is an AS boundary router, look up the "router" routing > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > table entry associated with Area A). If no entry exists for > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > N or if the entry's path type is "type 1 external" or "type > 2 external", then install the inter-area path to N, with > associated area Area A, cost IAC, next hop equal to the list > of next hops to router BR, and Advertising router equal to > BR. > > Are there any implementations that calculate a single ASBR route (vis-a-vis > one per area) and strictly prefer an intra-area path over an inter-area path > (independent of the corresponding areas)? > > Thanks, > -- > Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 10:14:42 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12167 for ; Thu, 17 Oct 2002 10:14:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00778279@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 10:16:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 305872 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 10:16:50 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 10:06:49 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZB8YG9>; Thu, 17 Oct 2002 19:36:36 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <55E277B99171E041ABF5F4B1C6DDCA069AE755@haritha.hclt.com> Date: Thu, 17 Oct 2002 19:39:00 +0530 Reply-To: Mailing List Sender: Mailing List From: "Jeyanath Minto J - CTD, Chennai." Subject: Re: OSPF ASBR Path Selection To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee , it seems we never have both inter-area path and intra-area backbone path to a ASBR. so below rule is unnecessary. Excerpted from RFC 16.4.1 " o The other paths, intra-area backbone paths and inter- area paths, are of equal preference. " Minto -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Thursday, October 17, 2002 2:30 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF ASBR Path Selection As a piece of unfinished business, Alex Zinin asked that I review a question regarding ASBR path selection when an external prefix is advertised through an ASBR accessible via multiple areas. The crux of the issue is whether RFC 2328 section 16.2(6) and section 16.4.1 conflict with one another and can result in a routing loop. A link to one of the E-mails on the subject is included below: Excerpted from RFC 16.2 (6) Else, if the paths present in the table are intra-area paths, do nothing with the LSA (intra-area paths are always preferred). Excerpted from RFC 16.4.1 When multiple intra-AS paths are available to ASBRs/forwarding addresses, the following rules indicate which paths are preferred. These rules apply when the same ASBR is reachable through multiple areas, or when trying to decide which of several AS-external-LSAs should be preferred. In the former case the paths all terminate at the same ASBR, while in the latter the paths terminate at separate ASBRs/forwarding addresses. In either case, each path is represented by a separate routing table entry as defined in Section 11. This section only applies when RFC1583Compatibility is set to "disabled". The path preference rules, stated from highest to lowest preference, are as follows. Note that as a result of these rules, there may still be multiple paths of the highest preference. In this case, the path to use must be determined based on cost, as described in Section 16.4. o Intra-area paths using non-backbone areas are always the most preferred. o The other paths, intra-area backbone paths and inter- area paths, are of equal preference. I've looked at this and my opinion is that while RFC 2328 could be more explicit, there is no problem. The reason is that section 16.2 (5) explicitly specifies that for a router route you must look up the routing table entry associated with the area whose summaries you are examining. Hence, the rule in (6) only applies to an intra-area path through the same area as the inter-area path. Excerpted from RFC 2328 Section 16.2: (5) Next, look up the routing table entry for the destination N. (If N is an AS boundary router, look up the "router" routing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ table entry associated with Area A). If no entry exists for ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ N or if the entry's path type is "type 1 external" or "type 2 external", then install the inter-area path to N, with associated area Area A, cost IAC, next hop equal to the list of next hops to router BR, and Advertising router equal to BR. Are there any implementations that calculate a single ASBR route (vis-a-vis one per area) and strictly prefer an intra-area path over an inter-area path (independent of the corresponding areas)? Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 11:10:19 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14199 for ; Thu, 17 Oct 2002 11:10:18 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0077844E@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 11:12:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 306109 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 11:12:29 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 11:12:29 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id D7350F2C4B for ; Thu, 17 Oct 2002 08:12:27 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <55E277B99171E041ABF5F4B1C6DDCA069AE755@haritha.hclt.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DAED35D.2020605@redback.com> Date: Thu, 17 Oct 2002 11:12:29 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF ASBR Path Selection To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Jeyanath Minto J - CTD, Chennai. wrote: > Hi Acee , > > it seems we never have both inter-area path and intra-area backbone > path to a ASBR. > so below rule is unnecessary. > > Excerpted from RFC 16.4.1 > > " > o The other paths, intra-area backbone paths and inter- > area paths, are of equal preference. > " > Hi Minto, You are correct for a single ASBR. However, the same prefix may be advertisd by multiple ABRs. RFC 2178 (obsoleted by RFC 2328) contains the best description of the problem (excerpted below): G.7 Advertising same external route from multiple areas This document fixes routing loops which can occur in RFC 1583 when the same external destination is advertised by AS boundary routers in separate areas. There are two manifestations of this problem. The first, discovered by Dennis Ferguson, occurs when an aggregated forwarding address is in use. In this case, the desirability of the forwarding address can change for the worse as a packet crosses an area aggregation boundary on the way to the forwarding address, which in turn can cause the preference of AS-external-LSAs to change, resulting in a routing loop. The second manifestation was discovered by Richard Woundy. It is caused by an incomplete application of OSPF's preference of intra- area routes over inter-area routes: paths to any given ASBR/forwarding address are selected first based on intra-area preference, while the comparison between separate ASBRs/forwarding addresses is driven only by cost, ignoring intra-area preference. His example is replicated in Figure 19. Both router A3 and router B3 are originating an AS-external-LSA for 10.0.0.0/8, with the same type 2 metric. Router A1 selects B1 as its next hop towards 10.0.0.0/8, based on shorter cost to ASBR B3 (via B1->B2->B3). However, the shorter route to B3 is not available to B1, due to B1's preference for the (higher cost) intra-area route to B3 through Area A. This leads B1 to select A1 as its next hop to 10.0.0.0/8, resulting in a routing loop. The following two changes have been made to prevent these routing loops: o When originating a type 3 summary-LSA for a configured area address range, the cost of the summary-LSA is now set to the maximum cost of the range's component networks (instead of the previous algorithm which set the cost to the minimum component cost). This change affects Sections 3.5 and 12.4.3, Figures 7 and 8, and Tables 6 and 13. o The preference rules for choosing among multiple AS- external-LSAs have been changed. Where previously cost was the only determining factor, now the preference is driven first by type of path (intra-area or inter-area, through non-backbone area or through backbone) to the ASBR/forwarding address, using cost only to break ties. This change affects Sections 16.4 and 16.4.1. After implementing this change, the example in Figure 19 is modified as follows. Router A1 now chooses A3 as the next 10.0.0.0/8 ---------- | +----+ | XX | +----+ RIP / \ RIP --------------------- -------------------- ! ! ! ! +----+ +----+ 1 +----+......+----+.... | A3 |------| A1 |---------------| B1 |------| B3 | . +----+ 6 +----+ +----+ 8 +----+ . 1| . / . OSPF backbone | . / . +----+ 2 / . | B2 |------- Area A. +----+................ Figure 19: Example routing loop when the same external route is advertised from multiple areas hop to 10.0.0.0/8, while B1 chooses B3 as next hop. The reason for both choices is that ASBRs/forwarding addresses are now chosen based first on intra-area preference, and then by cost. Unfortunately, this change is not backward compatible. While the change prevents routing loops when all routers run the new preference rules, it can actually create routing loops when some routers are running the new preference rules and other routers implement RFC 1583. For this reason, a new configuration parameter has been added: RFC1583Compatibility. Only when RFC1583Compatibility is set to "disabled" will the new preference rules take effect. See Appendix C for more details. > > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Thursday, October 17, 2002 2:30 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: OSPF ASBR Path Selection > > > As a piece of unfinished business, Alex Zinin asked that I > review a question regarding ASBR path selection when an external prefix > is advertised through an ASBR accessible via multiple areas. The crux of > the issue is whether RFC 2328 section 16.2(6) and section 16.4.1 conflict > with one another and can result in a routing loop. A link to > one of the E-mails on the subject is included below: > > =-3> > > Excerpted from RFC 16.2 > > (6) Else, if the paths present in the table are intra-area > paths, do nothing with the LSA (intra-area paths are always > preferred). > > Excerpted from RFC 16.4.1 > > When multiple intra-AS paths are available to > ASBRs/forwarding addresses, the following rules indicate > which paths are preferred. These rules apply when the same > ASBR is reachable through multiple areas, or when trying to > decide which of several AS-external-LSAs should be > preferred. In the former case the paths all terminate at the > same ASBR, while in the latter the paths terminate at > separate ASBRs/forwarding addresses. In either case, each > path is represented by a separate routing table entry as > defined in Section 11. > > This section only applies when RFC1583Compatibility is set > to "disabled". > > The path preference rules, stated from highest to lowest > preference, are as follows. Note that as a result of these > rules, there may still be multiple paths of the highest > preference. In this case, the path to use must be determined > based on cost, as described in Section 16.4. > > o Intra-area paths using non-backbone areas are always the > most preferred. > > o The other paths, intra-area backbone paths and inter- > area paths, are of equal preference. > > > I've looked at this and my opinion is that while RFC 2328 > could be more explicit, there is no problem. The reason is that > section 16.2 (5) explicitly specifies that for a router route you must > look up the routing table entry associated with the area whose summaries > you are examining. Hence, the rule in (6) only applies to an intra-area > path through the same area as the inter-area path. > > Excerpted from RFC 2328 Section 16.2: > > (5) Next, look up the routing table entry for the destination N. > (If N is an AS boundary router, look up the "router" routing > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > table entry associated with Area A). If no entry exists for > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > N or if the entry's path type is "type 1 external" or "type > 2 external", then install the inter-area path to N, with > associated area Area A, cost IAC, next hop equal to the list > of next hops to router BR, and Advertising router equal to > BR. > > Are there any implementations that calculate a single ASBR route (vis-a-vis > one per area) and strictly prefer an intra-area path over an inter-area path > (independent of the corresponding areas)? > > Thanks, > -- > Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 12:36:48 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16885 for ; Thu, 17 Oct 2002 12:36:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0077890B@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 12:38:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 306574 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 12:38:47 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 12:38:47 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl133-19.cisco.com [144.254.54.214]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9HGcj027330 for ; Thu, 17 Oct 2002 09:38:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-eAcceleration: FMT=1;FLAGS=0 Message-ID: Date: Thu, 17 Oct 2002 09:38:34 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPF ASBR Path Selection To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <55E277B99171E041ABF5F4B1C6DDCA06A766D8@haritha.hclt.com> Precedence: list Content-Transfer-Encoding: 7bit Sudharsana, > > > Hi Acee, > With respect to an ABR with backbone connectivity the summary > LSAs used for > calculation in 16.2 will belong to backbone. Hence, > -interpretation of 16.2 (5) is to see if the ASBR(destination N > described by > the summary LSA) is reachable through backbone intra-area paths. > -interpretation of 16.2 (6) is to prefer backbone intra-area paths over > inter-area paths > Will such an interpretation not conflict with the preference > rules of 16.4.1 > ? > you are correct, for backbone routers, Inter-area path to ASBR belongs to the backbone and therefore could be compared to backbone intra-area path in other word 16.2(6) and 16.4.1 are conflicting, although it could be argued that 16.2 describe the 'general' steps and 16.4.1 explicitly describe 'external path preference' therefore over writing the general behavior ... Sina > > ------------------------------- > | bkbone | > | 12(cost) | > R1..............ASBR.... > |\ | ! > | \...............R2...! > | 5(cost) |3(cost) > | | > | | non-bkbone > ------------------------- > | > > > > R1 and R2 are ABRs. > R1's intra-area (backbone) path cost to ASBR is 12. > R1's intra-area (backbone) path cost to R2 is 5. > R2's intra-area (non-backbone) path cost to ASBR is 3. > By following 16.2 verbatim, will R1 not choose the intra-area path of cost > 12? while applying 16.4.1 would have resulted > in selection of inter-area path (of cost 8) through R2. > I am unable to understand how you feel that there is no problem. Am I > missing something? > Regards, > Sudharsana > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Thursday, October 17, 2002 2:30 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: OSPF ASBR Path Selection > > > As a piece of unfinished business, Alex Zinin asked that I > review a question regarding ASBR path selection when an external prefix > is advertised through an ASBR accessible via multiple areas. The crux of > the issue is whether RFC 2328 section 16.2(6) and section 16.4.1 conflict > with one another and can result in a routing loop. A link to > one of the E-mails on the subject is included below: > > &P=R3674&I > =-3> > > Excerpted from RFC 16.2 > > (6) Else, if the paths present in the table are intra-area > paths, do nothing with the LSA (intra-area paths are always > preferred). > > Excerpted from RFC 16.4.1 > > When multiple intra-AS paths are available to > ASBRs/forwarding addresses, the following rules indicate > which paths are preferred. These rules apply when the same > ASBR is reachable through multiple areas, or when trying to > decide which of several AS-external-LSAs should be > preferred. In the former case the paths all terminate at the > same ASBR, while in the latter the paths terminate at > separate ASBRs/forwarding addresses. In either case, each > path is represented by a separate routing table entry as > defined in Section 11. > > This section only applies when RFC1583Compatibility is set > to "disabled". > > The path preference rules, stated from highest to lowest > preference, are as follows. Note that as a result of these > rules, there may still be multiple paths of the highest > preference. In this case, the path to use must be determined > based on cost, as described in Section 16.4. > > o Intra-area paths using non-backbone areas are always the > most preferred. > > o The other paths, intra-area backbone paths and inter- > area paths, are of equal preference. > > > I've looked at this and my opinion is that while RFC 2328 > could be more explicit, there is no problem. The reason is that > section 16.2 (5) explicitly specifies that for a router route you must > look up the routing table entry associated with the area whose summaries > you are examining. Hence, the rule in (6) only applies to an intra-area > path through the same area as the inter-area path. > > Excerpted from RFC 2328 Section 16.2: > > (5) Next, look up the routing table entry for the destination N. > (If N is an AS boundary router, look up the "router" routing > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > table entry associated with Area A). If no entry exists for > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > N or if the entry's path type is "type 1 external" or "type > 2 external", then install the inter-area path to N, with > associated area Area A, cost IAC, next hop equal to the list > of next hops to router BR, and Advertising router equal to > BR. > > Are there any implementations that calculate a single ASBR route > (vis-a-vis > one per area) and strictly prefer an intra-area path over an > inter-area path > (independent of the corresponding areas)? > > Thanks, > -- > Acee > Outgoing messages scanned and certified safe by Stop-Sign, the Personal Alarm Service. http://defender.veloz.com/dlp_ban/?n=tl&sp=08.out002 From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 13:27:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18796 for ; Thu, 17 Oct 2002 13:27:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00778B93@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 13:30:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 306812 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 13:30:02 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 13:30:02 -0400 Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9HHTwm17092 for ; Thu, 17 Oct 2002 10:29:58 -0700 (PDT) (envelope-from dennis@juniper.net) X-Mailer: exmh version 2.0.2 2/24/98 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210171729.g9HHTwm17092@merlot.juniper.net> Date: Thu, 17 Oct 2002 10:29:58 -0700 Reply-To: Mailing List Sender: Mailing List From: Dennis Ferguson Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Your message of "Wed, 16 Oct 2002 09:56:09 PDT." Precedence: list Sina, > if you want to allocate a new LSA type for each opaque type ( or better say > for each new LSA introduced ) then we won't need to call this opaque LSA, > you basically want to go to the idea of 'introducing a new LSA type' for > each 'new LSA defined' and we will end up with many, many LSA type which I > am not sure is a clean way ... Why is having "many, many LSA types" any less clean than having many, many opaque LSA types? What difference does it make whether you need to look at the LSA type or the opaque LSA's internal type to determine if you recognize it? Note that if you don't recognize the LSA type OSPFv3 already forces you to implement the procedures both to handle any number of unrecognized LSAs and to flood them properly in any case, so why would you want to add yet more code to the implementation to do the same thing a different way? If there's anything unclean about this it would be adding a second way to provide functionality which already exists, and must be implemented, in the protocol. To be clear, I think the proper way to handle moving functionality from OSPFv2 Opaque LSAs to OSPFv3 is to take the LSA-type+Opaque-type and map it to an OSPFv3 LSA-type+flooding-scope. I am still concerned that there be a way to specify the contents of the OSPFv2 LSA-type+Opaque-type, or an equivalent OSPFv3 LSA-type+flooding-scope, in a single document, but adding Opaque LSAs themselves to OSPFv3 (as opposed to mapping the contents of a particular OSPFv2 opaque LSA type to an OSPFv3 LSA type) is an orthogonal issue which adds no new functionality to the protocol, but requires that every write code to support a second way to do the same thing. This doesn't seem to make much sense. If there was some advantage to Opaque LSAs over OSPFv3's generic LSA flooding procedures I think the time to point this out was the 3 years between 1996, when OSPFv3's flooding procedures were first proposed, and 1999, when the document became an RFC, so that the generic procedures could be removed (like OSPFv2) and Opaque LSAs added instead. No matter how it is done there needs to be only one way to do it, and OSPFv3 already has a way. > that way we honor the name opaque LSA ;-) and won't introduce a new LSA type > every time we need to define a LSA But you've still not pointed out what is wrong with introducing a new LSA type every time you need one. OSPFv3 makes everyone write code to handle this, so what is wrong with making use of that code? > also it is not because we define opaque in v3 the same way as in v2 ( that > is, using LS ID for opaque type and instance ) that we have to sync > completely between v2 and v3, ospfv3 could have its own opaque type to be > defined / standardized independently ... But OSPFv3 has already has its own opaque type. It is an LSA type you don't understand with a flooding scope that you do understand. What's the use of having another one? Dennis Ferguson From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 13:49:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19666 for ; Thu, 17 Oct 2002 13:49:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00778D34@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 13:51:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 306874 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 13:51:37 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 13:51:37 -0400 Received: (qmail 26983 invoked from network); 17 Oct 2002 17:51:36 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 17 Oct 2002 17:51:36 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200210171729.g9HHTwm17092@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DAF75F4.50401@xebeo.com> Date: Thu, 17 Oct 2002 19:46:12 -0700 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Comments: cc: Acee Lindem , Rohit Dube To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Dennis Ferguson wrote: >Sina, > >>if you want to allocate a new LSA type for each opaque type ( or better say >>for each new LSA introduced ) then we won't need to call this opaque LSA, >>you basically want to go to the idea of 'introducing a new LSA type' for >>each 'new LSA defined' and we will end up with many, many LSA type which I >>am not sure is a clean way ... >> > >Why is having "many, many LSA types" any less clean than having many, many >opaque LSA types? What difference does it make whether you need to look at >the LSA type or the opaque LSA's internal type to determine if you recognize >it? Note that if you don't recognize the LSA type OSPFv3 already forces you >to implement the procedures both to handle any number of unrecognized LSAs >and to flood them properly in any case, so why would you want to add yet >more code to the implementation to do the same thing a different way? If >there's anything unclean about this it would be adding a second way to >provide functionality which already exists, and must be implemented, >in the protocol. > Dennis, I suspect it's connected to certain IAB's members' recent hysteria as to 'opaque LSAs are a big security problem and de-facto allow vendors to do non-interoperable things under the cloak of IETF by using non-documented opaques'. Not much sense in it but that's what goes around ... -- tony From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 14:08:59 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20326 for ; Thu, 17 Oct 2002 14:08:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00778D06@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 14:11:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 307000 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 14:11:09 -0400 Received: from 193.71.199.94 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 14:11:09 -0400 Received: from [10.9.9.110] (helo=snoopy.runbox.com) by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1) id 182F6y-0000Zk-00 for OSPF@discuss.microsoft.com; Thu, 17 Oct 2002 20:11:08 +0200 Received: from [203.200.20.226] (helo=Manav) (Authenticated Sender=dovek) by snoopy.runbox.com with asmtp (Exim 3.35 #1) id 182F6r-0006BY-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 20:11:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <041c01c27608$5c4f44f0$b4036c6b@sisodomain.com> Date: Thu, 17 Oct 2002 23:39:35 +0530 Reply-To: Mailing List Sender: Mailing List From: Misha Dovek Subject: Gating for MaxAge LSA in ospfv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, Do we apply any gating for MaxAge LSAs in OSPF v3. There is this MinLSAInterval timer which is applied to all LSA originations in OSPF v2. Does this hold true in OSPF v3 also? And specially for the Max Age LSAs. Dont we have this concept of "Bad news fast .. Good news slow" here. Misha. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 14:42:00 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21978 for ; Thu, 17 Oct 2002 14:42:00 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00778D86@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 14:44:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 307198 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 14:44:11 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 14:44:10 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl133-19.cisco.com [144.254.54.214]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9HIi9002064 for ; Thu, 17 Oct 2002 11:44:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-eAcceleration: FMT=1;FLAGS=0 Message-ID: Date: Thu, 17 Oct 2002 11:44:03 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210171729.g9HHTwm17092@merlot.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Dennis, > > Sina, > > > if you want to allocate a new LSA type for each opaque type ( > or better say > > for each new LSA introduced ) then we won't need to call this > opaque LSA, > > you basically want to go to the idea of 'introducing a new LSA type' for > > each 'new LSA defined' and we will end up with many, many LSA > type which I > > am not sure is a clean way ... > > Why is having "many, many LSA types" any less clean than having many, many > opaque LSA types? What difference does it make whether you need > to look at > the LSA type or the opaque LSA's internal type to determine if > you recognize > it? not much, however I guess opaque LSA was introduced in order to not define a new LSA type for each LSA needed therefore staying on the same logic for v3 looked to me natural ( but see more below ) > Note that if you don't recognize the LSA type OSPFv3 already > forces you > to implement the procedures both to handle any number of unrecognized LSAs > and to flood them properly in any case, so why would you want to add yet > more code to the implementation to do the same thing a different way? If > there's anything unclean about this it would be adding a second way to > provide functionality which already exists, and must be implemented, > in the protocol. agree, however we could still define all the opaque type having the same flooding scope on a given FC. therefore by setting the flooding scope bit of this FC we won't need to add more code ... > > To be clear, I think the proper way to handle moving functionality from > OSPFv2 Opaque LSAs to OSPFv3 is to take the LSA-type+Opaque-type and map > it to an OSPFv3 LSA-type+flooding-scope. I am still concerned that there > be a way to specify the contents of the OSPFv2 LSA-type+Opaque-type, or > an equivalent OSPFv3 LSA-type+flooding-scope, in a single document, but > adding Opaque LSAs themselves to OSPFv3 (as opposed to mapping > the contents > of a particular OSPFv2 opaque LSA type to an OSPFv3 LSA type) is > an orthogonal > issue which adds no new functionality to the protocol, but requires that > every write code to support a second way to do the same thing. > This doesn't > seem to make much sense. I think maping directly might not always work, imagine we have a opaque type between 1-9 that could conflict with FC 1-9 that are already defined... so we would probably have to define a new LSA type and could not simply use / or map ( at least direct mapping ) the opaque ID in v2 already defined (or will be defined) to v3 given that those opaque could be used in v3 although the content might be different > > If there was some advantage to Opaque LSAs over OSPFv3's generic > LSA flooding > procedures I think the time to point this out was the 3 years between > 1996, when OSPFv3's flooding procedures were first proposed, and 1999, > when the document became an RFC, so that the generic procedures could be > removed (like OSPFv2) and Opaque LSAs added instead. No matter how it is > done there needs to be only one way to do it, and OSPFv3 already > has a way. I am not arguing about flooding scope definition in v3 versus v2 way of flooding scope (through opaque) just that having the same opaque ID as for v2 could accelerate defining same functionality in v3 by using the same opaque ID number ( when applicable) > > > that way we honor the name opaque LSA ;-) and won't introduce a > new LSA type > > every time we need to define a LSA > > But you've still not pointed out what is wrong with introducing a new LSA > type every time you need one. OSPFv3 makes everyone write code to handle > this, so what is wrong with making use of that code? > we could use the same opaque ID already defined in v2 which apply also to v3 for example PCSD LSA already define address type so if we have the opaque ID we won't need to wait to allocate a new LSA type as far as flooding scope and code, as I mentioned above we could define all the opaque type that requires the same flooding scope in a given FC and use that FC flooding bit to handle flooding correctly Please note that I am Not saying to define flooding for each FC, each FC has already 'flooding scope' bit but simply put those opaque ID that requires the same flooding in a given FC and set the flooding bit of that FC > > also it is not because we define opaque in v3 the same way as > in v2 ( that > > is, using LS ID for opaque type and instance ) that we have to sync > > completely between v2 and v3, ospfv3 could have its own opaque > type to be > > defined / standardized independently ... > > But OSPFv3 has already has its own opaque type. It is an LSA > type you don't > understand with a flooding scope that you do understand. What's the use > of having another one? I understand both opaque type and flooding scope, honestly there is not much technical advantage of one over the other in one case opaque ID of v2 could be used in order to accelerate Opaque ID definition in v3 in other case I guess a correct mapping could do the same thing at the end it is a personal preference .... Sina > > Dennis Ferguson > Outgoing messages scanned and certified safe by Stop-Sign, the Personal Alarm Service. http://defender.veloz.com/dlp_ban/?n=tl&sp=08.out002 From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 16:00:07 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24407 for ; Thu, 17 Oct 2002 16:00:07 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.007791CE@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 16:02:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 307545 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 16:02:18 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 16:02:17 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 660F01DCC60; Thu, 17 Oct 2002 13:02:16 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DAF1747.9060504@redback.com> Date: Thu, 17 Oct 2002 16:02:15 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Comments on draft-katz-yeung-traffic-08.txt Comments: To: IETF Traffic Engineering WG To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Comments: - The LSA Header Diagram in section 2.3.1 does not reflect the fact that the instance has been extended to 24 bits. - Section 2.4.1 - Replace "but for obvious reasons this..." with "but this nomenclature is avoid here since the OSPF router ID is not necessarily a routable address." - Section 2.5.4 - Why 0.0.0.0 for the remote address for multiaccess links? It seems the TLV should either be omitted or set to the single neighbor address (since section 1.2 limits traffic engineering to multiaccess networks with 2 devices). Suggestion: - Include "Implications on Graceful Restart" section similar to draft-ietf-ccamp-ospf-gmpls-extensions-08.txt. Explicitly state that the goal is to maintain existing traffic engineered paths while discouraging any new ones until reservation state is obtained. Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 16:17:24 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24679 for ; Thu, 17 Oct 2002 16:17:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00779570@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 16:19:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 307632 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 16:19:34 -0400 Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 16:09:34 -0400 Received: from misspiggy.mail.pas.earthlink.net ([207.217.120.246] helo=misspiggy.psp.pas.earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 182GxZ-0001NX-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 13:09:33 -0700 Received: (from nobody@localhost) by misspiggy.psp.pas.earthlink.net (8.10.2+Sun/8.10.2) id g9HK9Ww04127 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 13:09:32 -0700 (PDT) X-Originating-IP: 208.243.162.188 Message-ID: Date: Thu, 17 Oct 2002 13:09:32 -0700 Reply-To: Mailing List Sender: Mailing List From: Kerpal Abdar Subject: OSPF Adjacencies To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi All, I am looking to understand what are the reason in which an OSPF adjacency may be torn down (aside from physical layer issues and RouterDeadInterval). More specific, would not receiving an acknowledgement for a LSU result in an adjacency to be torn down? thanks Kerpal From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 16:34:14 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25161 for ; Thu, 17 Oct 2002 16:34:14 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0077951F@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 16:36:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 307738 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 16:36:24 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 16:36:24 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9HKaOm34992 for ; Thu, 17 Oct 2002 13:36:24 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g9HKaNR38052 for ; Thu, 17 Oct 2002 13:36:23 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20021017131430.M37850-100000@kummer.juniper.net> Date: Thu, 17 Oct 2002 13:36:23 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DAF1747.9060504@redback.com> Precedence: list Hi Acee, On Thu, 17 Oct 2002, Acee Lindem wrote: > Comments: > > - The LSA Header Diagram in section 2.3.1 does not reflect > the fact that the instance has been extended to 24 bits. Thanks. Someone else also pointed this out. > - Section 2.4.1 - Replace "but for obvious reasons this..." > with "but this nomenclature is avoid here since the > OSPF router ID is not necessarily a routable address." Any objections? If not, I will make this change. > - Section 2.5.4 - Why 0.0.0.0 for the remote address for > multiaccess links? It seems the TLV should either be > omitted or set to the single neighbor address (since > section 1.2 limits traffic engineering to multiaccess > networks with 2 devices). While this document doesn't work ideally for multipoint links with more that 2 devices, it is used. Also, this has been implemented and is running code, so changing the spec to omitting this TLV at this point would cause more problems than it would solve. > Suggestion: > > - Include "Implications on Graceful Restart" section > similar to draft-ietf-ccamp-ospf-gmpls-extensions-08.txt. > Explicitly state that the goal is to maintain > existing traffic engineered paths while discouraging > any new ones until reservation state is obtained. Instead, how about specifying explicitly in the ospf gmpls draft that the text there applies to the base TE doc as well as the GMPLS extensions? Otherwise, draft-katz-yeung-traffic-08.txt will need the graceful restart doc as a normative reference. Note that the TE doc has been around for many years, with interoperable implementations etc., while graceful restart for OSPF much more recent. BTW, can we start to progress the graceful restart (aka hitless restart) document? There are interoperable implementations now, and while this doc is not as mature as TE, it certainly seems ready .... Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 16:41:22 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25509 for ; Thu, 17 Oct 2002 16:41:21 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.007794DB@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 16:43:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 307784 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 16:43:33 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 16:43:33 -0400 Received: (qmail 7708 invoked from network); 17 Oct 2002 20:43:32 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 17 Oct 2002 20:43:32 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id QAA17193 for ; Thu, 17 Oct 2002 16:43:32 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210172043.QAA17193@bigbird.xebeo.com> Date: Thu, 17 Oct 2002 16:43:32 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from Kireeti Kompella of "Thu, 17 Oct 2002 13:36:23 PDT." <20021017131430.M37850-100000@kummer.juniper.net> Precedence: list Kireeti, On Thu, 17 Oct 2002 13:36:23 -0700 Kireeti Kompella writes: [snip] => =>> - Section 2.5.4 - Why 0.0.0.0 for the remote address for =>> multiaccess links? It seems the TLV should either be =>> omitted or set to the single neighbor address (since =>> section 1.2 limits traffic engineering to multiaccess =>> networks with 2 devices). => =>While this document doesn't work ideally for multipoint links with =>more that 2 devices, it is used. Also, this has been implemented =>and is running code, so changing the spec to omitting this TLV at =>this point would cause more problems than it would solve. One major commercial implementation that I am aware of does omit this TLV. Another commercial implementation sets it to the originating routers IP address. IMHO, this point could use a cleanup along the lines that Acee suggested to further interoperability. Best, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 18:22:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27918 for ; Thu, 17 Oct 2002 18:22:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00779C48@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 18:25:01 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 308289 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 18:25:01 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 18:25:01 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl133-19.cisco.com [144.254.54.214]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9HMOx005011 for ; Thu, 17 Oct 2002 15:24:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Thu, 17 Oct 2002 15:24:59 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPF Adjacencies To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Kerpal, > Hi All, > > I am looking to understand what are the reason in which an OSPF > adjacency > may be torn down (aside from physical layer issues and > RouterDeadInterval). > those are actually the main one, receiving a 1 one way Hello also tear down an adj > More specific, would not receiving an acknowledgement for a LSU > result in an > adjacency to be torn down? some implementation tear down the adj after N number of retransmission for update or DBD packet RFC actually states that if ack is not received, retransmission will re-occur until adj is destroyed by Hello. mostly this condition would be enough for non-DC link but might not be in some very rare cases for example if Hello packet make it through and not the update ( say because of the packet size the packet gets corrupted on lower layer etc ) .... Sina > > > thanks > > Kerpal From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 21:15:43 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01901 for ; Thu, 17 Oct 2002 21:15:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0077A939@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 21:17:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 308942 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 21:17:53 -0400 Received: from 207.217.120.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 21:17:53 -0400 Received: from user-0cal4eu.cable.mindspring.com ([24.170.145.222] helo=abdgar) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 182Llw-0002bz-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 18:17:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Message-ID: Date: Thu, 17 Oct 2002 21:17:52 -0400 Reply-To: Mailing List Sender: Mailing List From: "Kerpal.Abdar" Subject: Re: OSPF Adjacencies To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Gotcha. After I had sent the question, I found the section in the RFC that speaks about this (page 88). However, I was unable to find where it states that if ack is not received, retransmission will re-occur until adj is destroyed by Hello. Could you point me to this? In addition, does the "lack of not receiving an ack and retransmitting the update until adj is destroy by hello" then tell me that the adjacency is not actually brought down by the lack off acks but by the lack of a hello. Is this correct? Is it mandatory for ALL updates to be ack? Is it that common to see implementations of OSPF tear down the adj after N number of retransmission for update or DBD packet? Do you know which vendors actually do this? Thank you! Kerpal -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Sina Mirtorabi Sent: Thursday, October 17, 2002 6:25 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF Adjacencies Kerpal, > Hi All, > > I am looking to understand what are the reason in which an OSPF > adjacency > may be torn down (aside from physical layer issues and > RouterDeadInterval). > those are actually the main one, receiving a 1 one way Hello also tear down an adj > More specific, would not receiving an acknowledgement for a LSU > result in an > adjacency to be torn down? some implementation tear down the adj after N number of retransmission for update or DBD packet RFC actually states that if ack is not received, retransmission will re-occur until adj is destroyed by Hello. mostly this condition would be enough for non-DC link but might not be in some very rare cases for example if Hello packet make it through and not the update ( say because of the packet size the packet gets corrupted on lower layer etc ) .... Sina > > > thanks > > Kerpal From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 22:08:14 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03138 for ; Thu, 17 Oct 2002 22:08:14 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0077AEFE@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 22:10:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 309249 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 22:10:24 -0400 Received: from 207.159.120.58 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 22:10:24 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 36BB729A62; Thu, 17 Oct 2002 22:10:20 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe23.nwk.excite.com via HTTP; Thu, 17 Oct 2002 22:10:20 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20021018021020.36BB729A62@xmxpita.excite.com> Date: Thu, 17 Oct 2002 22:10:20 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: OSPF Adjacencies To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kerpal, Not all adjacencies are "destroyed" in the same way. Some are deletions due to a lack of hello message over the dead interval, or an lower-level interface goes down. Some are transitions to the Init (or OneWay) state when a hello packet with no neighbors is received from a previously full adjacency. Finally, some are resynch transitions due to a sequence # mismatch, etc. where the state transitions back to ExchangeStart. All of these and more are covered in section 10.3 of RFC 2328. -don --- On Thu 10/17, Kerpal.Abdar wrote: From: Kerpal.Abdar [mailto: kerpal.abdar@EARTHLINK.NET] To: OSPF@DISCUSS.MICROSOFT.COM Date: Thu, 17 Oct 2002 21:17:52 -0400 Subject: Re: OSPF Adjacencies > Gotcha. After I had sent the question, I found the section in the RFC > that > speaks about this (page 88). However, I was unable to find where it > states > that if ack is not received, retransmission will re-occur until adj is > destroyed by Hello. Could you point me to this? > > In addition, does the "lack of not receiving an ack and > retransmitting the > update until adj is destroy by hello" then tell me that the > adjacency is > not actually brought down by the lack off acks but by the lack of a > hello. > Is this correct? > > Is it mandatory for ALL updates to be ack? > > Is it that common to see implementations of OSPF tear down the adj after > N > number of retransmission for update or DBD packet? Do you know which > vendors > actually do this? > > Thank you! > > > Kerpal > > > > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Sina > Mirtorabi > Sent: Thursday, October 17, 2002 6:25 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPF Adjacencies > > > Kerpal, > > > Hi All, > > > > I am looking to understand what are the reason in which an OSPF > > adjacency > > may be torn down (aside from physical layer issues and > > RouterDeadInterval). > > > > those are actually the main one, receiving a 1 one way Hello also tear > down > an adj > > > > More specific, would not receiving an acknowledgement for a LSU > > result in an > > adjacency to be torn down? > > some implementation tear down the adj after N number of retransmission > for > update or DBD packet > RFC actually states that if ack is not received, retransmission will > re-occur until adj is destroyed by Hello. mostly this condition would be > enough for non-DC link but might not be in some very rare cases for > example > if Hello packet make it through and not the update ( say because of the > packet size the packet gets corrupted on lower layer etc ) .... > > > Sina > > > > > > > > thanks > > > > Kerpal > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 17 22:18:01 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03329 for ; Thu, 17 Oct 2002 22:18:00 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0077B1F6@cherry.ease.lsoft.com>; Thu, 17 Oct 2002 22:20:10 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 309338 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 22:20:10 -0400 Received: from 207.217.120.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 17 Oct 2002 22:20:10 -0400 Received: from user-0cal4eu.cable.mindspring.com ([24.170.145.222] helo=abdgar) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 182MkD-0001FQ-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 19:20:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Message-ID: Date: Thu, 17 Oct 2002 22:20:09 -0400 Reply-To: Mailing List Sender: Mailing List From: "Kerpal.Abdar" Subject: Re: OSPF Adjacencies To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021018021020.36BB729A62@xmxpita.excite.com> Precedence: list Content-Transfer-Encoding: 7bit Thank you. I understand that lack of hello's can cause a transition. I was more particularly conserned that about the lack off acks for a LSUpdate and whether it could cause a change in state. Kerpal -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Don Goodspeed Sent: Thursday, October 17, 2002 10:10 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF Adjacencies Kerpal, Not all adjacencies are "destroyed" in the same way. Some are deletions due to a lack of hello message over the dead interval, or an lower-level interface goes down. Some are transitions to the Init (or OneWay) state when a hello packet with no neighbors is received from a previously full adjacency. Finally, some are resynch transitions due to a sequence # mismatch, etc. where the state transitions back to ExchangeStart. All of these and more are covered in section 10.3 of RFC 2328. -don --- On Thu 10/17, Kerpal.Abdar wrote: From: Kerpal.Abdar [mailto: kerpal.abdar@EARTHLINK.NET] To: OSPF@DISCUSS.MICROSOFT.COM Date: Thu, 17 Oct 2002 21:17:52 -0400 Subject: Re: OSPF Adjacencies > Gotcha. After I had sent the question, I found the section in the RFC > that > speaks about this (page 88). However, I was unable to find where it > states > that if ack is not received, retransmission will re-occur until adj is > destroyed by Hello. Could you point me to this? > > In addition, does the "lack of not receiving an ack and > retransmitting the > update until adj is destroy by hello" then tell me that the > adjacency is > not actually brought down by the lack off acks but by the lack of a > hello. > Is this correct? > > Is it mandatory for ALL updates to be ack? > > Is it that common to see implementations of OSPF tear down the adj after > N > number of retransmission for update or DBD packet? Do you know which > vendors > actually do this? > > Thank you! > > > Kerpal > > > > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Sina > Mirtorabi > Sent: Thursday, October 17, 2002 6:25 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPF Adjacencies > > > Kerpal, > > > Hi All, > > > > I am looking to understand what are the reason in which an OSPF > > adjacency > > may be torn down (aside from physical layer issues and > > RouterDeadInterval). > > > > those are actually the main one, receiving a 1 one way Hello also tear > down > an adj > > > > More specific, would not receiving an acknowledgement for a LSU > > result in an > > adjacency to be torn down? > > some implementation tear down the adj after N number of retransmission > for > update or DBD packet > RFC actually states that if ack is not received, retransmission will > re-occur until adj is destroyed by Hello. mostly this condition would be > enough for non-DC link but might not be in some very rare cases for > example > if Hello packet make it through and not the update ( say because of the > packet size the packet gets corrupted on lower layer etc ) .... > > > Sina > > > > > > > > thanks > > > > Kerpal > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 00:12:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05676 for ; Fri, 18 Oct 2002 00:12:52 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0077BC3D@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 0:12:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 309840 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 00:12:16 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 00:12:15 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id BE5401DCC6C for ; Thu, 17 Oct 2002 21:12:14 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20021017131430.M37850-100000@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DAF8A19.5030900@redback.com> Date: Fri, 18 Oct 2002 00:12:09 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Kireeti, Kireeti Kompella wrote: > Hi Acee, > > On Thu, 17 Oct 2002, Acee Lindem wrote: > > >>Comments: >> >> - The LSA Header Diagram in section 2.3.1 does not reflect >> the fact that the instance has been extended to 24 bits. >> > > Thanks. Someone else also pointed this out. > > >> - Section 2.4.1 - Replace "but for obvious reasons this..." >> with "but this nomenclature is avoid here since the >> OSPF router ID is not necessarily a routable address." >> > > Any objections? If not, I will make this change. > > >> - Section 2.5.4 - Why 0.0.0.0 for the remote address for >> multiaccess links? It seems the TLV should either be >> omitted or set to the single neighbor address (since >> section 1.2 limits traffic engineering to multiaccess >> networks with 2 devices). >> > > While this document doesn't work ideally for multipoint links with > more that 2 devices, it is used. Should a router withdraw it's TE LSA for the link if it detects > 2 routers on a multi-access network? > Also, this has been implemented > and is running code, so changing the spec to omitting this TLV at > this point would cause more problems than it would solve. I don't see how there could be any problems since the all zeros address can't be of much use and section 2.4.2 says only the Link Type and Link ID TLVs are mandatory. > > >>Suggestion: >> >> - Include "Implications on Graceful Restart" section >> similar to draft-ietf-ccamp-ospf-gmpls-extensions-08.txt. >> Explicitly state that the goal is to maintain >> existing traffic engineered paths while discouraging >> any new ones until reservation state is obtained. >> > > Instead, how about specifying explicitly in the ospf gmpls draft > that the text there applies to the base TE doc as well as the GMPLS > extensions? Otherwise, draft-katz-yeung-traffic-08.txt will need > the graceful restart doc as a normative reference. Note that the > TE doc has been around for many years, with interoperable > implementations etc., while graceful restart for OSPF much more recent. That sounds like a great idea. I still think it should be explicitly stated that the goal is to maintain existing traffic engineered paths while discouraging any new ones until reservation state is obtained. > > BTW, can we start to progress the graceful restart (aka hitless > restart) document? There are interoperable implementations now, and > while this doc is not as mature as TE, it certainly seems ready .... We're working towards that goal. Thanks, > > Kireeti. > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 00:36:20 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05972 for ; Fri, 18 Oct 2002 00:36:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0077BDB1@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 0:38:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 309882 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 00:38:30 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 00:38:30 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9I4cUm66669; Thu, 17 Oct 2002 21:38:30 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9I4cUg74223; Thu, 17 Oct 2002 21:38:30 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210180438.g9I4cUg74223@garnet.juniper.net> Date: Thu, 17 Oct 2002 21:38:30 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: OSPF Adjacencies To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: from "Kerpal.Abdar" at Oct 17, 2002 10:20:09 PM Precedence: list Content-Transfer-Encoding: 7bit Kerpal > > > > In addition, does the "lack of not receiving an ack and > > retransmitting the > > update until adj is destroy by hello" then tell me that the > > adjacency is > > not actually brought down by the lack off acks but by the lack of a > > hello. > > Is this correct? > > Yes - according to spec. > > Is it mandatory for ALL updates to be ack? > > > > Is it that common to see implementations of OSPF tear down the adj after > > N > > number of retransmission for update or DBD packet? Do you know which > > vendors > > actually do this? > > It is not common, AFAIK the only implementation that does this is Cisco's for over DC. Derek Yeung and I came up with this to solve problem of the detection of neighbors that died over a DC circuit after being FULL. This was later documented in a draft. Padma > > Thank you! > > > > > > Kerpal > > > > > > > > -----Original Message----- > > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Sina > > Mirtorabi > > Sent: Thursday, October 17, 2002 6:25 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: OSPF Adjacencies > > > > > > Kerpal, > > > > > Hi All, > > > > > > I am looking to understand what are the reason in which an OSPF > > > adjacency > > > may be torn down (aside from physical layer issues and > > > RouterDeadInterval). > > > > > > > those are actually the main one, receiving a 1 one way Hello also tear > > down > > an adj > > > > > > > More specific, would not receiving an acknowledgement for a LSU > > > result in an > > > adjacency to be torn down? > > > > some implementation tear down the adj after N number of retransmission > > for > > update or DBD packet > > RFC actually states that if ack is not received, retransmission will > > re-occur until adj is destroyed by Hello. mostly this condition would be > > enough for non-DC link but might not be in some very rare cases for > > example > > if Hello packet make it through and not the update ( say because of the > > packet size the packet gets corrupted on lower layer etc ) .... > > > > > > Sina > > > > > > > > > > > > > thanks > > > > > > Kerpal > > > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 01:16:31 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06693 for ; Fri, 18 Oct 2002 01:16:30 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0077BF92@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 1:18:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 310050 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 01:18:41 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 01:18:40 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9I5Iem67855 for ; Thu, 17 Oct 2002 22:18:40 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9I5IeV86411 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Oct 2002 22:18:40 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210180518.g9I5IeV86411@garnet.juniper.net> Date: Thu, 17 Oct 2002 22:18:40 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210111950.g9BJoMI39150@garnet.juniper.net> from "Padma Pillay-Esnault" at Oct 11, 2002 12:50:21 PM Precedence: list Content-Transfer-Encoding: 7bit Acee > > > > > > Just realized that this has been modified in later draft > > > in draft-ietf-ospf-hitless-restart-00.txt > > > > > > 3.1. Entering helper mode > > > > > > > > > Note that Router Y only needs to receive a single grace-LSA from > > > X, even if X and Y attach to multiple common segments. The data > > > in the first valid grace-LSA received is used to indicate the > > > beginning and the end of the grace period -- all subsequent > > > grace-LSAs received from X are ignored. This first grace-LSA is > > > referred to below as simply "the grace-LSA from X". > > > > > > A single router is allowed to simultaneously serve as a helper > > > for multiple restarting neighbors. > > > > > > later it is said in 02-txt > > > > > > Note that Router Y may be helping X on some network segments, > > > and not on others. However, that circumstance will probably lead > > > to the premature termination of X's hitless restart, as Y will > > > not continue to advertise adjacencies on the segments where it > > > is not helping (see Section 2.2). > > > A single router is allowed to simultaneously serve as a helper > > > for multiple restarting neighbors. > > > > > > Isn't that going to always lead to premature termination and hence defeat the > > > purpose ? > > > What is the idea behind of doing it per segment ? > > > A restarting router will affect all its links in the same way so why > > > differentiate it ? > > > > > > > > > I think don't think it makes sense that a full neighbor would help on > > > > some network segments and not others. I agree this would leas to premature > > termination. > > > Ok. we are on the same wavelength. > > > I do think it simplifies things if a restarting router originates the grace LSAs > > on all it's interfaces (or at least all with full neighbor > > adjacencies if it a planned restart). > > > > I also agree with you .. that's what I do - the restarting router sends > grace lsa over all interfaces. But from a Helping router perspective > we should do as in 00-txt. It simplifies the helper code. > It also prevents corner cases where we might not help all adjacencies > (when we should). > > Padma I haven't heard anyone object to why the 00-txt. If we are all clear on this, I propose to modify the draft to have the original text as in -00-txt. Padma From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 01:35:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07088 for ; Fri, 18 Oct 2002 01:35:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0077C0AB@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 1:38:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 310138 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 01:38:05 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 01:38:04 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 80DA0449A2F for ; Thu, 17 Oct 2002 22:38:03 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210180518.g9I5IeV86411@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DAF9E35.7080200@redback.com> Date: Fri, 18 Oct 2002 01:37:57 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma Pillay-Esnault wrote: > Acee Hi Padma, > > > > >>>>Just realized that this has been modified in later draft >>>>in draft-ietf-ospf-hitless-restart-00.txt >>>> >>>> 3.1. Entering helper mode >>>> >>>> >>>> Note that Router Y only needs to receive a single grace-LSA from >>>> X, even if X and Y attach to multiple common segments. The data >>>> in the first valid grace-LSA received is used to indicate the >>>> beginning and the end of the grace period -- all subsequent >>>> grace-LSAs received from X are ignored. This first grace-LSA is >>>> referred to below as simply "the grace-LSA from X". >>>> >>>> A single router is allowed to simultaneously serve as a helper >>>> for multiple restarting neighbors. >>>> >>>>later it is said in 02-txt >>>> >>>> Note that Router Y may be helping X on some network segments, >>>> and not on others. However, that circumstance will probably lead >>>> to the premature termination of X's hitless restart, as Y will >>>> not continue to advertise adjacencies on the segments where it >>>> is not helping (see Section 2.2). >>>> A single router is allowed to simultaneously serve as a helper >>>> for multiple restarting neighbors. >>>> >>>>Isn't that going to always lead to premature termination and hence defeat the >>>>purpose ? >>>>What is the idea behind of doing it per segment ? >>>>A restarting router will affect all its links in the same way so why >>>>differentiate it ? >>>> >>>> >>> >>>I think don't think it makes sense that a full neighbor would help on >>> >>>some network segments and not others. I agree this would leas to premature >>>termination. >>> >>> >>Ok. we are on the same wavelength. >> >> >>>I do think it simplifies things if a restarting router originates the grace LSAs >>>on all it's interfaces (or at least all with full neighbor >>>adjacencies if it a planned restart). >>> >>> >>I also agree with you .. that's what I do - the restarting router sends >>grace lsa over all interfaces. But from a Helping router perspective >>we should do as in 00-txt. It simplifies the helper code. >>It also prevents corner cases where we might not help all adjacencies >>(when we should). >> >>Padma >> > > > I haven't heard anyone object to why the 00-txt. I will - I specifically agree with: Note that Router Y only needs to receive a single grace-LSA from X, even if X and Y attach to multiple common segments. I don't like using an LSA with link local scope to enter/terminate helper mode for neighbors on different interfaces. It is better if the link local grace LSA only applies to that link. > > If we are all clear on this, I propose to modify the draft to have the > original text as in -00-txt. The draft implies one could define local policy to determine when it will or will not act as a helper. This is where the situation arises where you can help on some segments and not others. I don't necessarily think this is a good idea since I don't see the requirement and, as the test in -00.txt states, it could lead to premature termination of graceful restart. However, the scope and extent of local policy is not explicitly specified. > > > Padma > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 01:44:01 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07194 for ; Fri, 18 Oct 2002 01:44:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0077C102@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 1:46:12 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 310231 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 01:46:12 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 01:46:12 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 38BB51DCC6A for ; Thu, 17 Oct 2002 22:46:11 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <041c01c27608$5c4f44f0$b4036c6b@sisodomain.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DAFA01B.7090301@redback.com> Date: Fri, 18 Oct 2002 01:46:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Gating for MaxAge LSA in ospfv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello Misha, Misha Dovek wrote: > Hi, > Do we apply any gating for MaxAge LSAs in OSPF v3. There is this > MinLSAInterval timer which is applied to all LSA originations in OSPF v2. > Does this hold true in OSPF v3 also? And specially for the Max Age LSAs. The MinLSAInterval delay is retained from OSPF v2. > > Dont we have this concept of "Bad news fast .. Good news slow" here. With respect to LSA origination, MinLSAInterval is applied equally to re-originations and purging. > > Misha. > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 06:50:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20715 for ; Fri, 18 Oct 2002 06:50:52 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0077DC6C@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 6:53:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 312043 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 06:53:02 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 06:53:02 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 14A045D0C9; Fri, 18 Oct 2002 19:53:01 +0900 (JST) References: <041c01c27608$5c4f44f0$b4036c6b@sisodomain.com> <3DAFA01B.7090301@redback.com> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021018.195300.129199384.yasu@sfc.wide.ad.jp> Date: Fri, 18 Oct 2002 19:53:00 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Gating for MaxAge LSA in ospfv3 Comments: To: acee@REDBACK.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DAFA01B.7090301@redback.com> Precedence: list Content-Transfer-Encoding: 7bit acee> > Do we apply any gating for MaxAge LSAs in OSPF v3. There is this acee> > MinLSAInterval timer which is applied to all LSA originations in OSPF v2. acee> > Does this hold true in OSPF v3 also? And specially for the Max Age LSAs. acee> acee> The MinLSAInterval delay is retained from OSPF v2. acee> acee> > Dont we have this concept of "Bad news fast .. Good news slow" here. acee> acee> With respect to LSA origination, MinLSAInterval is applied acee> equally to re-originations and purging. Actually, RFC 2328 is ambiguous about it. Because it does not mention about it, I think that MinLSInterval should not be applied to premature agings, as it lengthen the convergence time ... I think we should take the concept "Bad new fast". regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 07:45:45 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22049 for ; Fri, 18 Oct 2002 07:45:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0077E0BB@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 7:47:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 312252 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 07:47:56 -0400 Received: from 192.193.196.254 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 07:37:56 -0400 Received: from myrtle1.citicorp.com (imta.citicorp.com [192.193.195.186]) by citicorp.com (8.9.3/8.9.3) with ESMTP id HAA09701 for ; Fri, 18 Oct 2002 07:36:03 -0400 (EDT) Received: from x400prod2.cgin.us-md.citicorp.com (localhost [127.0.0.1]) by myrtle1.citicorp.com (8.11.6/8.11.6) with ESMTP id g9IBbnf21704 for ; Fri, 18 Oct 2002 07:37:50 -0400 (EDT) Received: from ganymedelan1.email.citicorp.com (root@ganymedelan1.email.citicorp.com [169.165.194.36]) by x400prod2.cgin.us-md.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id HAA03000 Fri, 18 Oct 2002 07:37:41 -0400 (EDT) Received: from localhost (root@localhost) by ganymedelan1.email.citicorp.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id RAA15782 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 17:07:28 +0530 (IST) X-OpenMail-Hops: 1 Priority: Urgent Importance: High MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=openmail-part-1b298985-00000002 Message-ID: Date: Fri, 18 Oct 2002 13:40:31 +0530 Reply-To: Mailing List Sender: Mailing List From: Maneesh Sharma Subject: Re: OSPF Adjacencies To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --openmail-part-1b298985-00000002 Content-Type: text/plain; charset=ISO-8859-1; name="BDY.RTF" Content-Disposition: inline; filename="BDY.RTF" Content-Transfer-Encoding: 8bit Padma, Hello is instrumental in making up and breaking of OSPF adjaciencies. ACK transmission or reception is dependent upon adjacency being formed, which in turn relies on Hello. Hello is like a lower layer protocol which signals to upper layers whether or not updates can be sent or acked. In the event of no acks being received for sent updates, the dead interval timer has to fire before a neighbor can be pronounced dead. Regards Maneesh -----Original Message----- From: padma [mailto:padma@JUNIPER.NET] Sent: Friday, October 18, 2002 5:39 AM To: OSPF Cc: padma Subject: Re: OSPF Adjacencies Kerpal > > > > In addition, does the "lack of not receiving an ack and > > retransmitting the > > update until adj is destroy by hello" then tell me that the > > adjacency is > > not actually brought down by the lack off acks but by the lack of a > > hello. > > Is this correct? > > Yes - according to spec. > > Is it mandatory for ALL updates to be ack? > > > > Is it that common to see implementations of OSPF tear down the adj after > > N > > number of retransmission for update or DBD packet? Do you know which > > vendors > > actually do this? > > It is not common, AFAIK the only implementation that does this is Cisco's for over DC. Derek Yeung and I came up with this to solve problem of the detection of neighbors that died over a DC circuit after being FULL. This was later documented in a draft. Padma > > Thank you! > > > > > > Kerpal > > > > > > > > -----Original Message----- > > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Sina > > Mirtorabi > > Sent: Thursday, October 17, 2002 6:25 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: OSPF Adjacencies > > > > > > Kerpal, > > > > > Hi All, > > > > > > I am looking to understand what are the reason in which an OSPF > > > adjacency > > > may be torn down (aside from physical layer issues and > > > RouterDeadInterval). > > > > > > > those are actually the main one, receiving a 1 one way Hello also tear > > down > > an adj > > > > > > > More specific, would not receiving an acknowledgement for a LSU > > > result in an > > > adjacency to be torn down? > > > > some implementation tear down the adj after N number of retransmission > > for > > update or DBD packet > > RFC actually states that if ack is not received, retransmission will > > re-occur until adj is destroyed by Hello. mostly this condition would be > > enough for non-DC link but might not be in some very rare cases for > > example > > if Hello packet make it through and not the update ( say because of the > > packet size the packet gets corrupted on lower layer etc ) .... > > > > > > Sina > > > > > > > > > > > > > thanks > > > > > > Kerpal > > > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > --openmail-part-1b298985-00000002 Content-Type: application/rtf; name="BDY.RTF" Content-Disposition: attachment; filename="BDY.RTF" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250dGJsDQp7XGYw XGZzd2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmls XGZjaGFyc2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5l dzt9fQ0Ke1xjb2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1 NTt9DQpcdWMxXHBhcmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwIFBhZG1hLFxwYXINClxw YXINCkhlbGxvIGlzIGluc3RydW1lbnRhbCBpbiBtYWtpbmcgdXAgYW5kIGJyZWFraW5nIG9m IE9TUEYgYWRqYWNpZW5jaWVzLiBBQ0sgdHJhbnNtaXNzaW9uIG9yICByZWNlcHRpb24gaXMg ZGVwZW5kZW50IHVwb24gYWRqYWNlbmN5IGJlaW5nIGZvcm1lZCwgd2hpY2ggaW4gdHVybiBy ZWxpZXMgb24gSGVsbG8uIEhlbGxvIGlzIGxpa2UgYSBsb3dlciBsYXllciBwcm90b2NvbCB3 aGljaCBzaWduYWxzIHRvIHVwcGVyIGxheWVycyB3aGV0aGVyIG9yIG5vdCB1cGRhdGVzIGNh biBiZSBzZW50IG9yIGFja2VkLiBJbiB0aGUgZXZlbnQgb2Ygbm8gYWNrcyBiZWluZyByZWNl aXZlZCBmb3Igc2VudCB1cGRhdGVzLCB0aGUgZGVhZCBpbnRlcnZhbCB0aW1lciBoYXMgdG8g ZmlyZSBiZWZvcmUgYSBuZWlnaGJvciBjYW4gYmUgcHJvbm91bmNlZCBkZWFkLlxwYXINClxw YXINClJlZ2FyZHNccGFyDQpccGFyDQpNYW5lZXNoXHBhcg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS1ccGFyDQpGcm9tOiBwYWRtYSBbbWFpbHRvOnBhZG1hQEpVTklQRVIuTkVUXVxw YXINClNlbnQ6IEZyaWRheSwgT2N0b2JlciAxOCwgMjAwMiA1OjM5IEFNXHBhcg0KVG86IE9T UEZccGFyDQpDYzogcGFkbWFccGFyDQpTdWJqZWN0OiBSZTogT1NQRiBBZGphY2VuY2llc1xw YXINClxwYXINClxwYXINCktlcnBhbFxwYXINClxwYXINCjxTbmlwPlxwYXINClxwYXINCj4g PlxwYXINCj4gPiBJbiBhZGRpdGlvbiwgZG9lcyB0aGUgImxhY2sgb2Ygbm90IHJlY2Vpdmlu ZyBhbiBhY2sgYW5kXHBhcg0KPiA+IHJldHJhbnNtaXR0aW5nIHRoZVxwYXINCj4gPiB1cGRh dGUgdW50aWwgYWRqIGlzIGRlc3Ryb3kgYnkgaGVsbG8iICB0aGVuIHRlbGwgbWUgdGhhdCB0 aGVccGFyDQo+ID4gYWRqYWNlbmN5IGlzXHBhcg0KPiA+IG5vdCBhY3R1YWxseSBicm91Z2h0 IGRvd24gYnkgdGhlIGxhY2sgb2ZmIGFja3MgYnV0IGJ5IHRoZSBsYWNrIG9mIGFccGFyDQo+ ID4gaGVsbG8uXHBhcg0KPiA+IElzIHRoaXMgY29ycmVjdD9ccGFyDQo+ID5ccGFyDQpccGFy DQpZZXMgLSBhY2NvcmRpbmcgdG8gc3BlYy5ccGFyDQpccGFyDQo+ID4gSXMgaXQgbWFuZGF0 b3J5IGZvciBBTEwgdXBkYXRlcyB0byBiZSBhY2s/XHBhcg0KPiA+XHBhcg0KPiA+IElzIGl0 IHRoYXQgY29tbW9uIHRvIHNlZSBpbXBsZW1lbnRhdGlvbnMgb2YgT1NQRiB0ZWFyIGRvd24g dGhlIGFkaiBhZnRlclxwYXINCj4gPiBOXHBhcg0KPiA+IG51bWJlciBvZiByZXRyYW5zbWlz c2lvbiBmb3IgdXBkYXRlIG9yIERCRCBwYWNrZXQ/IERvIHlvdSBrbm93IHdoaWNoXHBhcg0K PiA+IHZlbmRvcnNccGFyDQo+ID4gYWN0dWFsbHkgZG8gdGhpcz9ccGFyDQo+ID5ccGFyDQpc cGFyDQpJdCBpcyBub3QgY29tbW9uLCBBRkFJSyB0aGUgb25seSBpbXBsZW1lbnRhdGlvbiB0 aGF0IGRvZXMgdGhpcyBpcyBDaXNjbydzXHBhcg0KZm9yIG92ZXIgREMuIERlcmVrIFlldW5n IGFuZCBJIGNhbWUgdXAgd2l0aCB0aGlzIHRvIHNvbHZlIHByb2JsZW0gb2YgdGhlXHBhcg0K ZGV0ZWN0aW9uIG9mIG5laWdoYm9ycyB0aGF0IGRpZWQgb3ZlciBhIERDIGNpcmN1aXQgYWZ0 ZXIgYmVpbmcgRlVMTC5ccGFyDQpUaGlzIHdhcyBsYXRlciBkb2N1bWVudGVkIGluIGEgZHJh ZnQuXHBhcg0KXHBhcg0KUGFkbWFccGFyDQpccGFyDQpccGFyDQo+ID4gVGhhbmsgeW91IVxw YXINCj4gPlxwYXINCj4gPlxwYXINCj4gPiBLZXJwYWxccGFyDQo+ID5ccGFyDQo+ID5ccGFy DQo+ID5ccGFyDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS1ccGFyDQo+ID4gRnJv bTogTWFpbGluZyBMaXN0IFttYWlsdG86T1NQRkBESVNDVVNTLk1JQ1JPU09GVC5DT01dT24g QmVoYWxmIE9mIFNpbmFccGFyDQo+ID4gTWlydG9yYWJpXHBhcg0KPiA+IFNlbnQ6IFRodXJz ZGF5LCBPY3RvYmVyIDE3LCAyMDAyIDY6MjUgUE1ccGFyDQo+ID4gVG86IE9TUEZARElTQ1VT Uy5NSUNST1NPRlQuQ09NXHBhcg0KPiA+IFN1YmplY3Q6IFJlOiBPU1BGIEFkamFjZW5jaWVz XHBhcg0KPiA+XHBhcg0KPiA+XHBhcg0KPiA+IEtlcnBhbCxccGFyDQo+ID5ccGFyDQo+ID4g PiBIaSBBbGwsXHBhcg0KPiA+ID5ccGFyDQo+ID4gPiAgIEkgYW0gbG9va2luZyB0byB1bmRl cnN0YW5kIHdoYXQgYXJlIHRoZSByZWFzb24gaW4gd2hpY2ggYW4gT1NQRlxwYXINCj4gPiA+ IGFkamFjZW5jeVxwYXINCj4gPiA+IG1heSBiZSB0b3JuIGRvd24gKGFzaWRlIGZyb20gcGh5 c2ljYWwgbGF5ZXIgaXNzdWVzIGFuZFxwYXINCj4gPiA+IFJvdXRlckRlYWRJbnRlcnZhbCku XHBhcg0KPiA+ID5ccGFyDQo+ID5ccGFyDQo+ID4gdGhvc2UgYXJlIGFjdHVhbGx5IHRoZSBt YWluIG9uZSwgcmVjZWl2aW5nIGEgMSBvbmUgd2F5IEhlbGxvIGFsc28gdGVhclxwYXINCj4g PiBkb3duXHBhcg0KPiA+IGFuIGFkalxwYXINCj4gPlxwYXINCj4gPlxwYXINCj4gPiA+IE1v cmUgc3BlY2lmaWMsIHdvdWxkIG5vdCByZWNlaXZpbmcgYW4gYWNrbm93bGVkZ2VtZW50IGZv ciBhIExTVVxwYXINCj4gPiA+IHJlc3VsdCBpbiBhblxwYXINCj4gPiA+IGFkamFjZW5jeSB0 byBiZSB0b3JuIGRvd24/XHBhcg0KPiA+XHBhcg0KPiA+IHNvbWUgaW1wbGVtZW50YXRpb24g dGVhciBkb3duIHRoZSBhZGogYWZ0ZXIgTiBudW1iZXIgb2YgcmV0cmFuc21pc3Npb25ccGFy DQo+ID4gZm9yXHBhcg0KPiA+IHVwZGF0ZSBvciBEQkQgcGFja2V0XHBhcg0KPiA+IFJGQyBh Y3R1YWxseSBzdGF0ZXMgdGhhdCBpZiBhY2sgaXMgbm90IHJlY2VpdmVkLCByZXRyYW5zbWlz c2lvbiB3aWxsXHBhcg0KPiA+IHJlLW9jY3VyIHVudGlsIGFkaiBpcyBkZXN0cm95ZWQgYnkg SGVsbG8uIG1vc3RseSB0aGlzIGNvbmRpdGlvbiB3b3VsZCBiZVxwYXINCj4gPiBlbm91Z2gg Zm9yIG5vbi1EQyBsaW5rIGJ1dCBtaWdodCBub3QgYmUgaW4gc29tZSB2ZXJ5IHJhcmUgY2Fz ZXMgZm9yXHBhcg0KPiA+IGV4YW1wbGVccGFyDQo+ID4gaWYgSGVsbG8gcGFja2V0IG1ha2Ug aXQgdGhyb3VnaCBhbmQgbm90IHRoZSB1cGRhdGUgKCBzYXkgYmVjYXVzZSBvZiB0aGVccGFy DQo+ID4gcGFja2V0IHNpemUgdGhlIHBhY2tldCBnZXRzIGNvcnJ1cHRlZCBvbiBsb3dlciBs YXllciBldGMgKSAuLi4uXHBhcg0KPiA+XHBhcg0KPiA+XHBhcg0KPiA+IFNpbmFccGFyDQo+ ID5ccGFyDQo+ID5ccGFyDQo+ID4gPlxwYXINCj4gPiA+XHBhcg0KPiA+ID4gdGhhbmtzXHBh cg0KPiA+ID5ccGFyDQo+ID4gPiBLZXJwYWxccGFyDQo+ID5ccGFyDQo+XHBhcg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1xwYXINCj4gSm9p biBFeGNpdGUhIC0gaHR0cDovL3d3dy5leGNpdGUuY29tXHBhcg0KPiBUaGUgbW9zdCBwZXJz b25hbGl6ZWQgcG9ydGFsIG9uIHRoZSBXZWIhXHBhcg0KPlxwYXINCn0= --openmail-part-1b298985-00000002-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 08:09:12 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22555 for ; Fri, 18 Oct 2002 08:09:11 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0077E0CD@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 8:11:20 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 312370 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 08:11:19 -0400 Received: from 207.217.120.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 08:11:19 -0400 Received: from kermit.mail.pas.earthlink.net ([207.217.120.241] helo=kermit.psp.pas.earthlink.net) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 182VyI-0002cV-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 05:11:18 -0700 Received: (from nobody@localhost) by kermit.psp.pas.earthlink.net (8.10.2+Sun/8.10.2) id g9ICBIC03425 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 05:11:18 -0700 (PDT) X-Originating-IP: 208.243.162.188 Message-ID: Date: Fri, 18 Oct 2002 05:11:18 -0700 Reply-To: Mailing List Sender: Mailing List From: Kerpal Subject: Re: OSPF Adjacencies To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Almost there....And by "DC" you mean Directly Connected? How many lack of acks does Cisco's implementation define N as being before the adj is brought down? Kerpal On Thu, 17 Oct 2002 21:38:30 -0700 Padma Pillay-Esnault wrote: > Kerpal > > > > > > > > > In addition, does the "lack of not > receiving an ack and > > > retransmitting the > > > update until adj is destroy by hello" then > tell me that the > > > adjacency is > > > not actually brought down by the lack off > acks but by the lack of a > > > hello. > > > Is this correct? > > > > > Yes - according to spec. > > > > Is it mandatory for ALL updates to be ack? > > > > > > Is it that common to see implementations of > OSPF tear down the adj after > > > N > > > number of retransmission for update or DBD > packet? Do you know which > > > vendors > > > actually do this? > > > > > It is not common, AFAIK the only implementation > that does this is Cisco's > for over DC. Derek Yeung and I came up with > this to solve problem of the > detection of neighbors that died over a DC > circuit after being FULL. > This was later documented in a draft. > > Padma > > > > > Thank you! > > > > > > > > > Kerpal > > > > > > > > > > > > -----Original Message----- > > > From: Mailing List > [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of > Sina > > > Mirtorabi > > > Sent: Thursday, October 17, 2002 6:25 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: OSPF Adjacencies > > > > > > > > > Kerpal, > > > > > > > Hi All, > > > > > > > > I am looking to understand what are the > reason in which an OSPF > > > > adjacency > > > > may be torn down (aside from physical > layer issues and > > > > RouterDeadInterval). > > > > > > > > > > those are actually the main one, receiving > a 1 one way Hello also tear > > > down > > > an adj > > > > > > > > > > More specific, would not receiving an > acknowledgement for a LSU > > > > result in an > > > > adjacency to be torn down? > > > > > > some implementation tear down the adj after > N number of retransmission > > > for > > > update or DBD packet > > > RFC actually states that if ack is not > received, retransmission will > > > re-occur until adj is destroyed by Hello. > mostly this condition would be > > > enough for non-DC link but might not be in > some very rare cases for > > > example > > > if Hello packet make it through and not the > update ( say because of the > > > packet size the packet gets corrupted on > lower layer etc ) .... > > > > > > > > > Sina > > > > > > > > > > > > > > > > > > thanks > > > > > > > > Kerpal > > > > > > > > _______________________________________________ > > Join Excite! - http://www.excite.com > > The most personalized portal on the Web! > > > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 09:28:22 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25388 for ; Fri, 18 Oct 2002 09:28:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0077E649@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 9:30:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 312653 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 09:30:32 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 09:30:32 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9IDUWm86647 for ; Fri, 18 Oct 2002 06:30:32 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9IDUW529795 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 06:30:32 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210181330.g9IDUW529795@garnet.juniper.net> Date: Fri, 18 Oct 2002 06:30:32 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: OSPF Adjacencies To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: from "Maneesh Sharma" at Oct 18, 2002 01:40:31 PM Precedence: list Content-Transfer-Encoding: 7bit > > Padma, > > Hello is instrumental in making up and breaking of OSPF adjaciencies. > ACK transmission or reception is dependent upon adjacency being formed, > which in turn relies on Hello. Hello is like a lower layer protocol > which signals to upper layers whether or not updates can be sent or > acked. In the event of no acks being received for sent updates, the dead > interval timer has to fire before a neighbor can be pronounced dead. We are talking about DC -Demand Circuit here and the hellos are suppressed so precisely you do not have a Dead timer Interval in Demand Circuit > > Regards > > Maneesh > -----Original Message----- > From: padma [mailto:padma@JUNIPER.NET] > Sent: Friday, October 18, 2002 5:39 AM > To: OSPF > Cc: padma > Subject: Re: OSPF Adjacencies > > > Kerpal > > > > > > > > > In addition, does the "lack of not receiving an ack and > > > retransmitting the > > > update until adj is destroy by hello" then tell me that the > > > adjacency is > > > not actually brought down by the lack off acks but by the lack of a > > > hello. > > > Is this correct? > > > > > Yes - according to spec. > > > > Is it mandatory for ALL updates to be ack? > > > > > > Is it that common to see implementations of OSPF tear down the adj > after > > > N > > > number of retransmission for update or DBD packet? Do you know which > > > vendors > > > actually do this? > > > > > It is not common, AFAIK the only implementation that does this is > Cisco's > for over DC. Derek Yeung and I came up with this to solve problem of the > detection of neighbors that died over a DC circuit after being FULL. > This was later documented in a draft. > > Padma > > > > > Thank you! > > > > > > > > > Kerpal > > > > > > > > > > > > -----Original Message----- > > > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of > Sina > > > Mirtorabi > > > Sent: Thursday, October 17, 2002 6:25 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: OSPF Adjacencies > > > > > > > > > Kerpal, > > > > > > > Hi All, > > > > > > > > I am looking to understand what are the reason in which an OSPF > > > > adjacency > > > > may be torn down (aside from physical layer issues and > > > > RouterDeadInterval). > > > > > > > > > > those are actually the main one, receiving a 1 one way Hello also > tear > > > down > > > an adj > > > > > > > > > > More specific, would not receiving an acknowledgement for a LSU > > > > result in an > > > > adjacency to be torn down? > > > > > > some implementation tear down the adj after N number of > retransmission > > > for > > > update or DBD packet > > > RFC actually states that if ack is not received, retransmission will > > > re-occur until adj is destroyed by Hello. mostly this condition > would be > > > enough for non-DC link but might not be in some very rare cases for > > > example > > > if Hello packet make it through and not the update ( say because of > the > > > packet size the packet gets corrupted on lower layer etc ) .... > > > > > > > > > Sina > > > > > > > > > > > > > > > > > > thanks > > > > > > > > Kerpal > > > > > > > _______________________________________________ > > Join Excite! - http://www.excite.com > > The most personalized portal on the Web! > > > > > --openmail-part-1b298985-00000002 > Content-Type: application/rtf; name="BDY.RTF" > Content-Disposition: attachment; filename="BDY.RTF" > Content-Transfer-Encoding: base64 > > e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250dGJsDQp7XGYw > XGZzd2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmllciBOZXc7fQ0Ke1xmMlxmbmls > XGZjaGFyc2V0MiBTeW1ib2w7fQ0Ke1xmM1xmbW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5l > dzt9fQ0Ke1xjb2xvcnRibFxyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1 > NTt9DQpcdWMxXHBhcmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwIFBhZG1hLFxwYXINClxw > YXINCkhlbGxvIGlzIGluc3RydW1lbnRhbCBpbiBtYWtpbmcgdXAgYW5kIGJyZWFraW5nIG9m > IE9TUEYgYWRqYWNpZW5jaWVzLiBBQ0sgdHJhbnNtaXNzaW9uIG9yICByZWNlcHRpb24gaXMg > ZGVwZW5kZW50IHVwb24gYWRqYWNlbmN5IGJlaW5nIGZvcm1lZCwgd2hpY2ggaW4gdHVybiBy > ZWxpZXMgb24gSGVsbG8uIEhlbGxvIGlzIGxpa2UgYSBsb3dlciBsYXllciBwcm90b2NvbCB3 > aGljaCBzaWduYWxzIHRvIHVwcGVyIGxheWVycyB3aGV0aGVyIG9yIG5vdCB1cGRhdGVzIGNh > biBiZSBzZW50IG9yIGFja2VkLiBJbiB0aGUgZXZlbnQgb2Ygbm8gYWNrcyBiZWluZyByZWNl > aXZlZCBmb3Igc2VudCB1cGRhdGVzLCB0aGUgZGVhZCBpbnRlcnZhbCB0aW1lciBoYXMgdG8g > ZmlyZSBiZWZvcmUgYSBuZWlnaGJvciBjYW4gYmUgcHJvbm91bmNlZCBkZWFkLlxwYXINClxw > YXINClJlZ2FyZHNccGFyDQpccGFyDQpNYW5lZXNoXHBhcg0KLS0tLS1PcmlnaW5hbCBNZXNz > YWdlLS0tLS1ccGFyDQpGcm9tOiBwYWRtYSBbbWFpbHRvOnBhZG1hQEpVTklQRVIuTkVUXVxw > YXINClNlbnQ6IEZyaWRheSwgT2N0b2JlciAxOCwgMjAwMiA1OjM5IEFNXHBhcg0KVG86IE9T > UEZccGFyDQpDYzogcGFkbWFccGFyDQpTdWJqZWN0OiBSZTogT1NQRiBBZGphY2VuY2llc1xw > YXINClxwYXINClxwYXINCktlcnBhbFxwYXINClxwYXINCjxTbmlwPlxwYXINClxwYXINCj4g > PlxwYXINCj4gPiBJbiBhZGRpdGlvbiwgZG9lcyB0aGUgImxhY2sgb2Ygbm90IHJlY2Vpdmlu > ZyBhbiBhY2sgYW5kXHBhcg0KPiA+IHJldHJhbnNtaXR0aW5nIHRoZVxwYXINCj4gPiB1cGRh > dGUgdW50aWwgYWRqIGlzIGRlc3Ryb3kgYnkgaGVsbG8iICB0aGVuIHRlbGwgbWUgdGhhdCB0 > aGVccGFyDQo+ID4gYWRqYWNlbmN5IGlzXHBhcg0KPiA+IG5vdCBhY3R1YWxseSBicm91Z2h0 > IGRvd24gYnkgdGhlIGxhY2sgb2ZmIGFja3MgYnV0IGJ5IHRoZSBsYWNrIG9mIGFccGFyDQo+ > ID4gaGVsbG8uXHBhcg0KPiA+IElzIHRoaXMgY29ycmVjdD9ccGFyDQo+ID5ccGFyDQpccGFy > DQpZZXMgLSBhY2NvcmRpbmcgdG8gc3BlYy5ccGFyDQpccGFyDQo+ID4gSXMgaXQgbWFuZGF0 > b3J5IGZvciBBTEwgdXBkYXRlcyB0byBiZSBhY2s/XHBhcg0KPiA+XHBhcg0KPiA+IElzIGl0 > IHRoYXQgY29tbW9uIHRvIHNlZSBpbXBsZW1lbnRhdGlvbnMgb2YgT1NQRiB0ZWFyIGRvd24g > dGhlIGFkaiBhZnRlclxwYXINCj4gPiBOXHBhcg0KPiA+IG51bWJlciBvZiByZXRyYW5zbWlz > c2lvbiBmb3IgdXBkYXRlIG9yIERCRCBwYWNrZXQ/IERvIHlvdSBrbm93IHdoaWNoXHBhcg0K > PiA+IHZlbmRvcnNccGFyDQo+ID4gYWN0dWFsbHkgZG8gdGhpcz9ccGFyDQo+ID5ccGFyDQpc > cGFyDQpJdCBpcyBub3QgY29tbW9uLCBBRkFJSyB0aGUgb25seSBpbXBsZW1lbnRhdGlvbiB0 > aGF0IGRvZXMgdGhpcyBpcyBDaXNjbydzXHBhcg0KZm9yIG92ZXIgREMuIERlcmVrIFlldW5n > IGFuZCBJIGNhbWUgdXAgd2l0aCB0aGlzIHRvIHNvbHZlIHByb2JsZW0gb2YgdGhlXHBhcg0K > ZGV0ZWN0aW9uIG9mIG5laWdoYm9ycyB0aGF0IGRpZWQgb3ZlciBhIERDIGNpcmN1aXQgYWZ0 > ZXIgYmVpbmcgRlVMTC5ccGFyDQpUaGlzIHdhcyBsYXRlciBkb2N1bWVudGVkIGluIGEgZHJh > ZnQuXHBhcg0KXHBhcg0KUGFkbWFccGFyDQpccGFyDQpccGFyDQo+ID4gVGhhbmsgeW91IVxw > YXINCj4gPlxwYXINCj4gPlxwYXINCj4gPiBLZXJwYWxccGFyDQo+ID5ccGFyDQo+ID5ccGFy > DQo+ID5ccGFyDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS1ccGFyDQo+ID4gRnJv > bTogTWFpbGluZyBMaXN0IFttYWlsdG86T1NQRkBESVNDVVNTLk1JQ1JPU09GVC5DT01dT24g > QmVoYWxmIE9mIFNpbmFccGFyDQo+ID4gTWlydG9yYWJpXHBhcg0KPiA+IFNlbnQ6IFRodXJz > ZGF5LCBPY3RvYmVyIDE3LCAyMDAyIDY6MjUgUE1ccGFyDQo+ID4gVG86IE9TUEZARElTQ1VT > Uy5NSUNST1NPRlQuQ09NXHBhcg0KPiA+IFN1YmplY3Q6IFJlOiBPU1BGIEFkamFjZW5jaWVz > XHBhcg0KPiA+XHBhcg0KPiA+XHBhcg0KPiA+IEtlcnBhbCxccGFyDQo+ID5ccGFyDQo+ID4g > PiBIaSBBbGwsXHBhcg0KPiA+ID5ccGFyDQo+ID4gPiAgIEkgYW0gbG9va2luZyB0byB1bmRl > cnN0YW5kIHdoYXQgYXJlIHRoZSByZWFzb24gaW4gd2hpY2ggYW4gT1NQRlxwYXINCj4gPiA+ > IGFkamFjZW5jeVxwYXINCj4gPiA+IG1heSBiZSB0b3JuIGRvd24gKGFzaWRlIGZyb20gcGh5 > c2ljYWwgbGF5ZXIgaXNzdWVzIGFuZFxwYXINCj4gPiA+IFJvdXRlckRlYWRJbnRlcnZhbCku > XHBhcg0KPiA+ID5ccGFyDQo+ID5ccGFyDQo+ID4gdGhvc2UgYXJlIGFjdHVhbGx5IHRoZSBt > YWluIG9uZSwgcmVjZWl2aW5nIGEgMSBvbmUgd2F5IEhlbGxvIGFsc28gdGVhclxwYXINCj4g > PiBkb3duXHBhcg0KPiA+IGFuIGFkalxwYXINCj4gPlxwYXINCj4gPlxwYXINCj4gPiA+IE1v > cmUgc3BlY2lmaWMsIHdvdWxkIG5vdCByZWNlaXZpbmcgYW4gYWNrbm93bGVkZ2VtZW50IGZv > ciBhIExTVVxwYXINCj4gPiA+IHJlc3VsdCBpbiBhblxwYXINCj4gPiA+IGFkamFjZW5jeSB0 > byBiZSB0b3JuIGRvd24/XHBhcg0KPiA+XHBhcg0KPiA+IHNvbWUgaW1wbGVtZW50YXRpb24g > dGVhciBkb3duIHRoZSBhZGogYWZ0ZXIgTiBudW1iZXIgb2YgcmV0cmFuc21pc3Npb25ccGFy > DQo+ID4gZm9yXHBhcg0KPiA+IHVwZGF0ZSBvciBEQkQgcGFja2V0XHBhcg0KPiA+IFJGQyBh > Y3R1YWxseSBzdGF0ZXMgdGhhdCBpZiBhY2sgaXMgbm90IHJlY2VpdmVkLCByZXRyYW5zbWlz > c2lvbiB3aWxsXHBhcg0KPiA+IHJlLW9jY3VyIHVudGlsIGFkaiBpcyBkZXN0cm95ZWQgYnkg > SGVsbG8uIG1vc3RseSB0aGlzIGNvbmRpdGlvbiB3b3VsZCBiZVxwYXINCj4gPiBlbm91Z2gg > Zm9yIG5vbi1EQyBsaW5rIGJ1dCBtaWdodCBub3QgYmUgaW4gc29tZSB2ZXJ5IHJhcmUgY2Fz > ZXMgZm9yXHBhcg0KPiA+IGV4YW1wbGVccGFyDQo+ID4gaWYgSGVsbG8gcGFja2V0IG1ha2Ug > aXQgdGhyb3VnaCBhbmQgbm90IHRoZSB1cGRhdGUgKCBzYXkgYmVjYXVzZSBvZiB0aGVccGFy > DQo+ID4gcGFja2V0IHNpemUgdGhlIHBhY2tldCBnZXRzIGNvcnJ1cHRlZCBvbiBsb3dlciBs > YXllciBldGMgKSAuLi4uXHBhcg0KPiA+XHBhcg0KPiA+XHBhcg0KPiA+IFNpbmFccGFyDQo+ > ID5ccGFyDQo+ID5ccGFyDQo+ID4gPlxwYXINCj4gPiA+XHBhcg0KPiA+ID4gdGhhbmtzXHBh > cg0KPiA+ID5ccGFyDQo+ID4gPiBLZXJwYWxccGFyDQo+ID5ccGFyDQo+XHBhcg0KPiBfX19f > X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX1xwYXINCj4gSm9p > biBFeGNpdGUhIC0gaHR0cDovL3d3dy5leGNpdGUuY29tXHBhcg0KPiBUaGUgbW9zdCBwZXJz > b25hbGl6ZWQgcG9ydGFsIG9uIHRoZSBXZWIhXHBhcg0KPlxwYXINCn0= > > --openmail-part-1b298985-00000002-- > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 09:32:18 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25562 for ; Fri, 18 Oct 2002 09:32:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0077E71C@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 9:34:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 312677 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 09:34:27 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 09:34:26 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9IDYQm86790 for ; Fri, 18 Oct 2002 06:34:26 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9IDYQq30854 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 06:34:26 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210181334.g9IDYQq30854@garnet.juniper.net> Date: Fri, 18 Oct 2002 06:34:26 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: OSPF Adjacencies To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: from "Kerpal" at Oct 18, 2002 05:11:18 AM Precedence: list Content-Transfer-Encoding: 7bit > > Almost there....And by "DC" you mean Directly Connected? > > No. I meant DC - Demand Circuit. (Sorry for my use of an acronym.) In regular cases, the lack of hellos would trigger the Dead Timer Interval and tear the adjacency down. This is sufficient to ensure correct operation of OSPF. > How many lack of acks does Cisco's implementation define N as being before the > adj is brought down? It was 3 retransmissions but could have changed since. Padma > > Kerpal > > > > > On Thu, 17 Oct 2002 21:38:30 -0700 Padma Pillay-Esnault > wrote: > > > Kerpal > > > > > > > > > > > > > > In addition, does the "lack of not > > receiving an ack and > > > > retransmitting the > > > > update until adj is destroy by hello" then > > tell me that the > > > > adjacency is > > > > not actually brought down by the lack off > > acks but by the lack of a > > > > hello. > > > > Is this correct? > > > > > > > > Yes - according to spec. > > > > > > Is it mandatory for ALL updates to be ack? > > > > > > > > Is it that common to see implementations of > > OSPF tear down the adj after > > > > N > > > > number of retransmission for update or DBD > > packet? Do you know which > > > > vendors > > > > actually do this? > > > > > > > > It is not common, AFAIK the only implementation > > that does this is Cisco's > > for over DC. Derek Yeung and I came up with > > this to solve problem of the > > detection of neighbors that died over a DC > > circuit after being FULL. > > This was later documented in a draft. > > > > Padma > > > > > > > > Thank you! > > > > > > > > > > > > Kerpal > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Mailing List > > [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of > > Sina > > > > Mirtorabi > > > > Sent: Thursday, October 17, 2002 6:25 PM > > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > > Subject: Re: OSPF Adjacencies > > > > > > > > > > > > Kerpal, > > > > > > > > > Hi All, > > > > > > > > > > I am looking to understand what are the > > reason in which an OSPF > > > > > adjacency > > > > > may be torn down (aside from physical > > layer issues and > > > > > RouterDeadInterval). > > > > > > > > > > > > > those are actually the main one, receiving > > a 1 one way Hello also tear > > > > down > > > > an adj > > > > > > > > > > > > > More specific, would not receiving an > > acknowledgement for a LSU > > > > > result in an > > > > > adjacency to be torn down? > > > > > > > > some implementation tear down the adj after > > N number of retransmission > > > > for > > > > update or DBD packet > > > > RFC actually states that if ack is not > > received, retransmission will > > > > re-occur until adj is destroyed by Hello. > > mostly this condition would be > > > > enough for non-DC link but might not be in > > some very rare cases for > > > > example > > > > if Hello packet make it through and not the > > update ( say because of the > > > > packet size the packet gets corrupted on > > lower layer etc ) .... > > > > > > > > > > > > Sina > > > > > > > > > > > > > > > > > > > > > > > thanks > > > > > > > > > > Kerpal > > > > > > > > > > > > _______________________________________________ > > > Join Excite! - http://www.excite.com > > > The most personalized portal on the Web! > > > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 10:02:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26906 for ; Fri, 18 Oct 2002 10:02:26 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0077E656@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 10:04:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 312752 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 10:04:38 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 10:04:37 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id DB3BCF6077 for ; Fri, 18 Oct 2002 07:04:36 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <041c01c27608$5c4f44f0$b4036c6b@sisodomain.com> <3DAFA01B.7090301@redback.com> <20021018.195300.129199384.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB014EA.5040104@redback.com> Date: Fri, 18 Oct 2002 10:04:26 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Gating for MaxAge LSA in ospfv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yasuhiro Ohara wrote: > acee> > Do we apply any gating for MaxAge LSAs in OSPF v3. There is this > acee> > MinLSAInterval timer which is applied to all LSA originations in OSPF v2. > acee> > Does this hold true in OSPF v3 also? And specially for the Max Age LSAs. > acee> > acee> The MinLSAInterval delay is retained from OSPF v2. > acee> > acee> > Dont we have this concept of "Bad news fast .. Good news slow" here. > acee> > acee> With respect to LSA origination, MinLSAInterval is applied > acee> equally to re-originations and purging. > > Actually, RFC 2328 is ambiguous about it. Hello Yasu, RFC 2328 does say that say a number of times that the "fundamental mechanisms of OSPF (flooding, DR election, area support, etc) remain unchanged". > Because it does not mention about it, I think that MinLSInterval > should not be applied to premature agings, as it lengthen the > convergence time ... I think we should take the concept "Bad new fast". > > regards, > yasu > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 10:02:31 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26921 for ; Fri, 18 Oct 2002 10:02:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0077E696@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 10:04:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 312766 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 10:04:42 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 10:04:42 -0400 Received: (qmail 29879 invoked from network); 18 Oct 2002 14:04:42 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 18 Oct 2002 14:04:42 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id KAA24438 for ; Fri, 18 Oct 2002 10:04:42 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210181404.KAA24438@bigbird.xebeo.com> Date: Fri, 18 Oct 2002 10:04:42 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from Acee Lindem of "Fri, 18 Oct 2002 00:12:09 EDT." <3DAF8A19.5030900@redback.com> Precedence: list Acee, On Fri, 18 Oct 2002 00:12:09 -0400 Acee Lindem writes: =>> While this document doesn't work ideally for multipoint links with =>> more that 2 devices, it is used. => => =>Should a router withdraw it's TE LSA for the link if it =>detects > 2 routers on a multi-access network? I think this is a good idea as this will prevent non-adjacent nodes from (potentially) getting confused. Best, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 10:08:35 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27128 for ; Fri, 18 Oct 2002 10:08:34 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0077E6A8@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 10:10:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 312810 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 10:10:46 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 10:10:46 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 26BA95D0C4; Fri, 18 Oct 2002 23:10:45 +0900 (JST) References: <3DAFA01B.7090301@redback.com> <20021018.195300.129199384.yasu@sfc.wide.ad.jp> <3DB014EA.5040104@redback.com> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021018.231043.35959799.yasu@sfc.wide.ad.jp> Date: Fri, 18 Oct 2002 23:10:43 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Gating for MaxAge LSA in ospfv3 Comments: To: acee@REDBACK.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DB014EA.5040104@redback.com> Precedence: list Content-Transfer-Encoding: 7bit acee> > acee> > Do we apply any gating for MaxAge LSAs in OSPF v3. There is this acee> > acee> > MinLSAInterval timer which is applied to all LSA originations in OSPF v2. acee> > acee> > Does this hold true in OSPF v3 also? And specially for the Max Age LSAs. acee> > acee> acee> > acee> The MinLSAInterval delay is retained from OSPF v2. acee> > acee> acee> > acee> > Dont we have this concept of "Bad news fast .. Good news slow" here. acee> > acee> acee> > acee> With respect to LSA origination, MinLSAInterval is applied acee> > acee> equally to re-originations and purging. acee> > acee> > Actually, RFC 2328 is ambiguous about it. acee> acee> Hello Yasu, acee> acee> RFC 2328 does say that say a number of times that the "fundamental mechanisms acee> of OSPF (flooding, DR election, area support, etc) remain unchanged". acee> acee> > Because it does not mention about it, I think that MinLSInterval acee> > should not be applied to premature agings, as it lengthen the acee> > convergence time ... I think we should take the concept "Bad new fast". "remain unchanged" from what ? is that sentence from RFC *2740*, isn't it ? What I'm talking about is not the difference between OSPFv2 and OSPFv3. I said "original OSPFv2 (and hence also OSPFv3) specification is ambiguous about whether to apply MinLSInterval when purging of LSA (i.e. premature aging)". Am I missing something ? regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 11:47:20 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01376 for ; Fri, 18 Oct 2002 11:47:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0077EA35@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 11:49:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 313014 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 11:49:29 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 11:49:28 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 24BB41B8EED for ; Fri, 18 Oct 2002 08:49:27 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <3DAFA01B.7090301@redback.com> <20021018.195300.129199384.yasu@sfc.wide.ad.jp> <3DB014EA.5040104@redback.com> <20021018.231043.35959799.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB02D7B.1080301@redback.com> Date: Fri, 18 Oct 2002 11:49:15 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Gating for MaxAge LSA in ospfv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yasuhiro Ohara wrote: > acee> > acee> > Do we apply any gating for MaxAge LSAs in OSPF v3. There is this > acee> > acee> > MinLSAInterval timer which is applied to all LSA originations in OSPF v2. > acee> > acee> > Does this hold true in OSPF v3 also? And specially for the Max Age LSAs. > acee> > acee> > acee> > acee> The MinLSAInterval delay is retained from OSPF v2. > acee> > acee> > acee> > acee> > Dont we have this concept of "Bad news fast .. Good news slow" here. > acee> > acee> > acee> > acee> With respect to LSA origination, MinLSAInterval is applied > acee> > acee> equally to re-originations and purging. > acee> > > acee> > Actually, RFC 2328 is ambiguous about it. > acee> > acee> Hello Yasu, > acee> > acee> RFC 2328 does say that say a number of times that the "fundamental mechanisms > acee> of OSPF (flooding, DR election, area support, etc) remain unchanged". > acee> > acee> > Because it does not mention about it, I think that MinLSInterval > acee> > should not be applied to premature agings, as it lengthen the > acee> > convergence time ... I think we should take the concept "Bad new fast". > > "remain unchanged" from what ? is that sentence from RFC *2740*, isn't > it ? > > What I'm talking about is not the difference between OSPFv2 and > OSPFv3. Sorry, I misread your post. I'll use my morning excuse of not having drunken enough coffee :-) > > I said "original OSPFv2 (and hence also OSPFv3) specification is > ambiguous about whether to apply MinLSInterval when purging of LSA > (i.e. premature aging)". I don't think there is ambiguity in RFC 2328. MinLSInterval is defined as the minimum time between distinct originations of any particular LSA. When you purge an LSA you are definitely re-originating it with a new sequence number and MaxAge. I'm not advocating violating the specification. However is an implementation does flood MaxAge LSAs immediatedly, it better make damn sure that the initial origination is delayed MinLSInterval seconds after a purge. In other words, once an LSA is purged state must be retained to assure that a new origination is at least MinLSInterval seconds later. I'm pretty sure there are a lot of implementations that do not retain state after an LSA is purged and successfully flooded. Thanks, Acee > > Am I missing something ? > > regards, > yasu > > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 12:01:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01845 for ; Fri, 18 Oct 2002 12:01:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0077EA12@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 12:03:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 313063 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 12:03:58 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 12:03:58 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl131-17.cisco.com [144.254.57.148]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9IG3v025648 for ; Fri, 18 Oct 2002 09:03:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Fri, 18 Oct 2002 09:03:56 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPF Adjacencies To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Kerpal > Gotcha. After I had sent the question, I found the section in > the RFC that > speaks about this (page 88). However, I was unable to find where > it states > that if ack is not received, retransmission will re-occur until adj is > destroyed by Hello. Could you point me to this? see end of section 13.6 > > In addition, does the "lack of not receiving an ack and retransmitting the > update until adj is destroy by hello" then tell me that the adjacency is > not actually brought down by the lack off acks but by the lack of a hello. > Is this correct? Padma already answered this > > Is it mandatory for ALL updates to be ack? yes unless it is received less than MinLSArrival > Is it that common to see implementations of OSPF tear down the adj after N > number of retransmission for update or DBD packet? Do you know > which vendors > actually do this? Cisco does it and we do for both DC and non-DC link, further setting N is configurable and can also be disabled through configuration Sina > > Thank you! > > > Kerpal > > > > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Sina > Mirtorabi > Sent: Thursday, October 17, 2002 6:25 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: OSPF Adjacencies > > > Kerpal, > > > Hi All, > > > > I am looking to understand what are the reason in which an OSPF > > adjacency > > may be torn down (aside from physical layer issues and > > RouterDeadInterval). > > > > those are actually the main one, receiving a 1 one way Hello also > tear down > an adj > > > > More specific, would not receiving an acknowledgement for a LSU > > result in an > > adjacency to be torn down? > > some implementation tear down the adj after N number of retransmission for > update or DBD packet > RFC actually states that if ack is not received, retransmission will > re-occur until adj is destroyed by Hello. mostly this condition would be > enough for non-DC link but might not be in some very rare cases > for example > if Hello packet make it through and not the update ( say because of the > packet size the packet gets corrupted on lower layer etc ) .... > > > Sina > > > > > > > > thanks > > > > Kerpal From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 12:10:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02080 for ; Fri, 18 Oct 2002 12:10:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0077EBFF@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 12:12:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 313138 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 12:12:40 -0400 Received: from 207.217.120.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 12:12:40 -0400 Received: from grover.mail.pas.earthlink.net ([207.217.121.249] helo=grover.psp.pas.earthlink.net) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 182Zjq-0005Bl-00; Fri, 18 Oct 2002 09:12:38 -0700 Received: (from nobody@localhost) by grover.psp.pas.earthlink.net (8.10.2+Sun/8.10.2) id g9IGCbN06034; Fri, 18 Oct 2002 09:12:37 -0700 (PDT) X-Originating-IP: 208.243.162.188 Message-ID: Date: Fri, 18 Oct 2002 09:12:37 -0700 Reply-To: Mailing List Sender: Mailing List From: Kerpal Subject: Re: OSPF Adjacencies Comments: To: sina@CISCO.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Do you know what the command is on Cisco to adjust this setting? Kerpal On Fri, 18 Oct 2002 09:03:56 -0700 Sina Mirtorabi wrote: > Kerpal > > > Gotcha. After I had sent the question, I > found the section in > > the RFC that > > speaks about this (page 88). However, I was > unable to find where > > it states > > that if ack is not received, retransmission > will re-occur until adj is > > destroyed by Hello. Could you point me to > this? > > see end of section 13.6 > > > > > In addition, does the "lack of not receiving > an ack and retransmitting the > > update until adj is destroy by hello" then > tell me that the adjacency is > > not actually brought down by the lack off > acks but by the lack of a hello. > > Is this correct? > > Padma already answered this > > > > > Is it mandatory for ALL updates to be ack? > > yes unless it is received less than > MinLSArrival > > > > Is it that common to see implementations of > OSPF tear down the adj after N > > number of retransmission for update or DBD > packet? Do you know > > which vendors > > actually do this? > > Cisco does it and we do for both DC and non-DC > link, further setting N is > configurable and can also be disabled through > configuration > > Sina > > > > > > Thank you! > > > > > > Kerpal > > > > > > > > -----Original Message----- > > From: Mailing List > [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of > Sina > > Mirtorabi > > Sent: Thursday, October 17, 2002 6:25 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: OSPF Adjacencies > > > > > > Kerpal, > > > > > Hi All, > > > > > > I am looking to understand what are the > reason in which an OSPF > > > adjacency > > > may be torn down (aside from physical layer > issues and > > > RouterDeadInterval). > > > > > > > those are actually the main one, receiving a > 1 one way Hello also > > tear down > > an adj > > > > > > > More specific, would not receiving an > acknowledgement for a LSU > > > result in an > > > adjacency to be torn down? > > > > some implementation tear down the adj after N > number of retransmission for > > update or DBD packet > > RFC actually states that if ack is not > received, retransmission will > > re-occur until adj is destroyed by Hello. > mostly this condition would be > > enough for non-DC link but might not be in > some very rare cases > > for example > > if Hello packet make it through and not the > update ( say because of the > > packet size the packet gets corrupted on > lower layer etc ) .... > > > > > > Sina > > > > > > > > > > > > > thanks > > > > > > Kerpal > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 12:15:31 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02215 for ; Fri, 18 Oct 2002 12:15:30 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0077EC10@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 12:17:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 313220 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 12:17:43 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 12:17:43 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl131-17.cisco.com [144.254.57.148]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9IGHf018940; Fri, 18 Oct 2002 09:17:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Fri, 18 Oct 2002 09:17:41 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPF Adjacencies Comments: To: kerpal@earthlink.net To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit > Do you know what the command is on Cisco to adjust this setting? limit retransmissions <[dc <1-255>] [non-dc <1-255>] default is 24 for dc and 12 for non-dc Sina > Kerpal > > On Fri, 18 Oct 2002 09:03:56 -0700 Sina Mirtorabi wrote: > > > Kerpal > > > > > Gotcha. After I had sent the question, I > > found the section in > > > the RFC that > > > speaks about this (page 88). However, I was > > unable to find where > > > it states > > > that if ack is not received, retransmission > > will re-occur until adj is > > > destroyed by Hello. Could you point me to > > this? > > > > see end of section 13.6 > > > > > > > > In addition, does the "lack of not receiving > > an ack and retransmitting the > > > update until adj is destroy by hello" then > > tell me that the adjacency is > > > not actually brought down by the lack off > > acks but by the lack of a hello. > > > Is this correct? > > > > Padma already answered this > > > > > > > > Is it mandatory for ALL updates to be ack? > > > > yes unless it is received less than > > MinLSArrival > > > > > > > Is it that common to see implementations of > > OSPF tear down the adj after N > > > number of retransmission for update or DBD > > packet? Do you know > > > which vendors > > > actually do this? > > > > Cisco does it and we do for both DC and non-DC > > link, further setting N is > > configurable and can also be disabled through > > configuration > > > > Sina > > > > > > > > > > Thank you! > > > > > > > > > Kerpal > > > > > > > > > > > > -----Original Message----- > > > From: Mailing List > > [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of > > Sina > > > Mirtorabi > > > Sent: Thursday, October 17, 2002 6:25 PM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: OSPF Adjacencies > > > > > > > > > Kerpal, > > > > > > > Hi All, > > > > > > > > I am looking to understand what are the > > reason in which an OSPF > > > > adjacency > > > > may be torn down (aside from physical layer > > issues and > > > > RouterDeadInterval). > > > > > > > > > > those are actually the main one, receiving a > > 1 one way Hello also > > > tear down > > > an adj > > > > > > > > > > More specific, would not receiving an > > acknowledgement for a LSU > > > > result in an > > > > adjacency to be torn down? > > > > > > some implementation tear down the adj after N > > number of retransmission for > > > update or DBD packet > > > RFC actually states that if ack is not > > received, retransmission will > > > re-occur until adj is destroyed by Hello. > > mostly this condition would be > > > enough for non-DC link but might not be in > > some very rare cases > > > for example > > > if Hello packet make it through and not the > > update ( say because of the > > > packet size the packet gets corrupted on > > lower layer etc ) .... > > > > > > > > > Sina > > > > > > > > > > > > > > > > > > thanks > > > > > > > > Kerpal > > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 14:33:12 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06301 for ; Fri, 18 Oct 2002 14:33:11 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0077F052@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 14:35:20 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 313606 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 14:35:20 -0400 Received: from 207.159.120.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 14:35:20 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 64146B6DF; Fri, 18 Oct 2002 14:35:15 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe17.nwk.excite.com via HTTP; Fri, 18 Oct 2002 14:35:15 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20021018183515.64146B6DF@xmxpita.excite.com> Date: Fri, 18 Oct 2002 14:35:15 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit All, What would be the implications of stating that all non-DR routers on a multi-access network list the DR, and the DR should list the BDR. Of course, what happens when only one router is DR-eligible? If we went with the scheme below, I assume we would then re-adver- tise the TE LSA when the # of other routers reaches 1 or 0? -don --- On Fri 10/18, Rohit Dube wrote: From: Rohit Dube [mailto: rohit@XEBEO.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Fri, 18 Oct 2002 10:04:42 -0400 Subject: Re: Comments on draft-katz-yeung-traffic-08.txt > Acee, > > On Fri, 18 Oct 2002 00:12:09 -0400 Acee Lindem writes: > =>> While this document doesn't work ideally for multipoint links > with > =>> more that 2 devices, it is used. > => > => > =>Should a router withdraw it's TE LSA for the link if it > =>detects > 2 routers on a multi-access network? > > I think this is a good idea as this will prevent non-adjacent nodes from > (potentially) getting confused. > > Best, > --rohit. > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 16:44:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09552 for ; Fri, 18 Oct 2002 16:44:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0077F7E2@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 16:46:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 313994 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 16:46:56 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 16:46:56 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl131-17.cisco.com [144.254.57.148]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9IKkt003860 for ; Fri, 18 Oct 2002 13:46:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Fri, 18 Oct 2002 13:46:54 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Gating for MaxAge LSA in ospfv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021018.195300.129199384.yasu@sfc.wide.ad.jp> Precedence: list Content-Transfer-Encoding: 7bit Yasu, > Actually, RFC 2328 is ambiguous about it. > Because it does not mention about it, I think that MinLSInterval > should not be applied to premature agings, as it lengthen the > convergence time ... I think we should take the concept "Bad new fast". > although MinLSInterval is an architectural constant, implementations could make this interval configurable ( with backoff algo ) in order to speed up the convergence. now regarding Maxage LSA, it should be noted that although you could make the bad news faster ( say by having a different interval for maxage LSA ) you will not always benefit from it ( type 1 and 2 LSA ) this is because when an adj is broken or a prefix is removed you will simply originate a new version of LSA by making the corresponding change in the content so having a shorter interval for maxage LSA will not help there ... Sina From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 18:51:16 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11692 for ; Fri, 18 Oct 2002 18:51:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0077FCDA@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 18:53:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 314341 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 18:53:25 -0400 Received: from 207.159.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 18:53:25 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 2868EF62C; Fri, 18 Oct 2002 18:53:22 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe3.nwk.excite.com via HTTP; Fri, 18 Oct 2002 18:53:22 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20021018225322.2868EF62C@xmxpita.excite.com> Date: Fri, 18 Oct 2002 18:53:22 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit OK. I've had more time to think about this, and I withdraw my earlier suggestions. Listing the DR would lead to routing loops (between DR and BDR) and/or blackholes (where the DR is not a TE-capable router). I also do not suggest we withdraw the TE LSAs when there are two or more routers on a multi-access network. It's better to just ignore the TE LSAs that do not have a remote IP than to flood, withdraw, flood again, etc. Had anyone ever suggested the concept of a TE-capable DR? It could generate a TE version of a Network LSA listing the TE-capable routers on a link. TE applications would then be able to use the link for non-bandwidth TE uses. Let me know if this has been tried and knocked down... -don --- On Fri 10/18, Acee Lindem wrote: From: Acee Lindem [mailto: acee@REDBACK.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Fri, 18 Oct 2002 00:12:09 -0400 Subject: Re: Comments on draft-katz-yeung-traffic-08.txt > Hi Kireeti, > > Kireeti Kompella wrote: > > > Hi Acee, > > > > On Thu, 17 Oct 2002, Acee Lindem wrote: > > > > > >>Comments: > >> > >> - The LSA Header Diagram in section 2.3.1 does not reflect > >> the fact that the instance has been extended to 24 bits. > >> > > > > Thanks. Someone else also pointed this out. > > > > > >> - Section 2.4.1 - Replace "but for obvious reasons > this..." > >> with "but this nomenclature is avoid here since the > >> OSPF router ID is not necessarily a routable > address." > >> > > > > Any objections? If not, I will make this change. > > > > > >> - Section 2.5.4 - Why 0.0.0.0 for the remote address for > >> multiaccess links? It seems the TLV should either be > >> omitted or set to the single neighbor address (since > >> section 1.2 limits traffic engineering to multiaccess > >> networks with 2 devices). > >> > > > > While this document doesn't work ideally for multipoint links with > > more that 2 devices, it is used. > > > Should a router withdraw it's TE LSA for the link if it > detects > 2 routers on a multi-access network? > > > Also, this has been implemented > > and is running code, so changing the spec to omitting this TLV at > > this point would cause more problems than it would solve. > > > I don't see how there could be any problems since the all zeros > address can't be of much use and section 2.4.2 says only the > Link Type and Link ID TLVs are mandatory. > > > > > > > >>Suggestion: > >> > >> - Include "Implications on Graceful Restart" > section > >> similar to > draft-ietf-ccamp-ospf-gmpls-extensions-08.txt. > >> Explicitly state that the goal is to maintain > >> existing traffic engineered paths while discouraging > >> any new ones until reservation state is obtained. > >> > > > > Instead, how about specifying explicitly in the ospf gmpls draft > > that the text there applies to the base TE doc as well as the GMPLS > > extensions? Otherwise, draft-katz-yeung-traffic-08.txt will need > > the graceful restart doc as a normative reference. Note that the > > TE doc has been around for many years, with interoperable > > implementations etc., while graceful restart for OSPF much more > recent. > > > That sounds like a great idea. I still think it should be explicitly > stated that the goal is to maintain existing traffic engineered paths > while > discouraging any new ones until reservation state is obtained. > > > > > > BTW, can we start to progress the graceful restart (aka hitless > > restart) document? There are interoperable implementations now, and > > while this doc is not as mature as TE, it certainly seems ready .... > > > We're working towards that goal. > > Thanks, > > > > > > Kireeti. > > > > > > > -- > Acee > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 19:33:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12416 for ; Fri, 18 Oct 2002 19:33:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0077FC23@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 19:36:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 314404 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 19:36:03 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 19:36:03 -0400 Received: (qmail 9391 invoked from network); 18 Oct 2002 23:36:01 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 18 Oct 2002 23:36:01 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20021018225322.2868EF62C@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB117FB.2060304@xebeo.com> Date: Sat, 19 Oct 2002 01:29:47 -0700 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Don Goodspeed wrote: >OK. I've had more time to think about this, and I withdraw >my earlier suggestions. Listing the DR would lead to routing >loops (between DR and BDR) and/or blackholes (where the DR is >not a TE-capable router). > >I also do not suggest we withdraw the TE LSAs when there are >two or more routers on a multi-access network. It's better to >just ignore the TE LSAs that do not have a remote IP than to >flood, withdraw, flood again, etc. > >Had anyone ever suggested the concept of a TE-capable DR? >It could generate a TE version of a Network LSA listing the >TE-capable routers on a link. TE applications would then >be able to use the link for non-bandwidth TE uses. > >Let me know if this has been tried and knocked down... > isn't it much easier to just generate a single Network LSA with all routers and then apply a reverse check for the TE capability ? Otherwise you'll probably need a different router priority for TE DR than normal DR, split LANs with 2 different DRs and all such complicated jazz ? -- tony From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 19:35:20 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12452 for ; Fri, 18 Oct 2002 19:35:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0077FBE5@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 19:37:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 314422 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 19:37:30 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 19:37:30 -0400 Received: (qmail 9500 invoked from network); 18 Oct 2002 23:37:30 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 18 Oct 2002 23:37:30 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id TAA27735 for ; Fri, 18 Oct 2002 19:37:30 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210182337.TAA27735@bigbird.xebeo.com> Date: Fri, 18 Oct 2002 19:37:30 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from Don Goodspeed of "Fri, 18 Oct 2002 18:53:22 EDT." <20021018225322.2868EF62C@xmxpita.excite.com> Precedence: list On Fri, 18 Oct 2002 18:53:22 -0400 Don Goodspeed writes: [snip] =>I also do not suggest we withdraw the TE LSAs when there are =>two or more routers on a multi-access network. It's better to =>just ignore the TE LSAs that do not have a remote IP than to =>flood, withdraw, flood again, etc. Don, Unless I misunderstand you completely, one cannot ignore TE LSAs which don't have a remote-ip TLV. This is because there are already implementations out there which don't send the TLV. Withdrawing the TE LSAs if more than one neighbor is detected is not that much work and is beneficial to nodes down/upstream from where this condition is detected. To answer your question from the previous mail, one could disable the link for TE till an operator intervenes or resend the TE LSA when the neighbor count comes back to 1. Either operation would be correct. Best, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 18 22:07:43 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14885 for ; Fri, 18 Oct 2002 22:07:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0077FF7D@cherry.ease.lsoft.com>; Fri, 18 Oct 2002 22:09:54 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 314651 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Oct 2002 22:09:53 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 18 Oct 2002 22:09:53 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA27170 for ; Fri, 18 Oct 2002 22:09:50 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id WAA20930 for ; Fri, 18 Oct 2002 22:09:53 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4W8J577S>; Fri, 18 Oct 2002 22:09:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557633F7@vie-msgusr-01.dc.fore.com> Date: Fri, 18 Oct 2002 22:09:49 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list >Had anyone ever suggested the concept of a TE-capable DR? >It could generate a TE version of a Network LSA listing the >TE-capable routers on a link. TE applications would then >be able to use the link for non-bandwidth TE uses. > >Let me know if this has been tried and knocked down... > -> isn't it much easier to just generate a single Network LSA with -> all routers and then apply a reverse check for the TE capability ? -> Otherwise you'll probably need a different router priority for -> TE DR than normal DR, split LANs with 2 different DRs and all -> such complicated jazz ? Regardless of all these discussions about "Representing a BC network (more specifically shared media nets)" in the control plane and exchanging such information with other routers, the more important and yet unresolved issues are related to QoS in shared media. No one yet resolved how to reserve bw (even worst case of best-effort) in shared media and dynamically adjusting the forwarding plane to scale well for connection oriented or connectionless tunnels. I think the draft is under specified. (Kireeti already knows my concern very well :) - so my take is a strict specification inorder to remove unnecessary future interoperability issues. Finally, forwarding plane requirements should drive representation of control plane. Definitely not other way. May be we can resolve some TE issues by these suggestions but can't guarantee a specific service. It is not a good idea to say that "We can do TE when 2 routers are in the LAN but we can't quarantee anything after that". Instead it is better to say "We will give you a *complete* specification/design when all issues/requirements are clear". Hope you all agree. Thank You! -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Sat Oct 19 02:05:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24919 for ; Sat, 19 Oct 2002 02:05:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0078097A@cherry.ease.lsoft.com>; Sat, 19 Oct 2002 2:07:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 315211 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 19 Oct 2002 02:07:56 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 19 Oct 2002 02:07:56 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id A9489CAB7C; Fri, 18 Oct 2002 23:07:55 -0700 (PDT) Message-ID: <20021019060755.A9489CAB7C@prattle.redback.com> Date: Fri, 18 Oct 2002 23:07:55 -0700 Reply-To: Mailing List Sender: Mailing List From: Naiming Shen Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Mail from Rohit Dube dated Fri, 18 Oct 2002 19:37:30 EDT <200210182337.TAA27735@bigbird.xebeo.com> Precedence: list there is no need to withdraw TE LSAs while more than two routers start to exist on the multi-access network. the TE draft says clearly there will be limitations(verses the p2p link), but this does not at all mean you can not run TE on that multi-access link with multiple-routers. it's perfectly "fine" to setup TE tunnels with multiple routers over the same multi-access link. will this cause problem in terms of congestion? yes, it can. but - even over p2p TE links, we only reserve the bandwidth for the TE links, we can still "overbook" the bandwidth and congest the p2p TE links. - TE is usually used to route traffic for the purpose of saving cost in the long-haul p2p links. those multi-router/multi-access link usually is close to the edge of the network. even there is congestion going on, there probably is not much you can do to route around them. If there is congestion, simple add more bandwith there and the cost should be low. since there will be a need to do TE with multiple routers on a LAN, i think specifying the remote ip of 0.0.0.0 is OK, the draft probably should say "or this TLV can be omitted". specifying a real IP address even in the case of only two routers on the LAN does not sound right. for p2p link, you have to specify the neighbor IP address, since otherwise, in the case of parallel p2p links, there will be no other indication to flag the match at both ends. for LAN, you have the DR interface address to tie them ends together. thanks. ] On Fri, 18 Oct 2002 18:53:22 -0400 Don Goodspeed writes: ] [snip] ] =>I also do not suggest we withdraw the TE LSAs when there are ] =>two or more routers on a multi-access network. It's better to ] =>just ignore the TE LSAs that do not have a remote IP than to ] =>flood, withdraw, flood again, etc. ] ] Don, ] ] Unless I misunderstand you completely, one cannot ignore TE LSAs ] which don't have a remote-ip TLV. This is because there are already ] implementations out there which don't send the TLV. ] ] Withdrawing the TE LSAs if more than one neighbor is detected is ] not that much work and is beneficial to nodes down/upstream from ] where this condition is detected. To answer your question from ] the previous mail, one could disable the link for TE till an operator ] intervenes or resend the TE LSA when the neighbor count comes back to 1. ] Either operation would be correct. ] ] Best, ] --rohit. - Naiming From owner-ospf@DISCUSS.MICROSOFT.COM Sat Oct 19 04:49:29 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28548 for ; Sat, 19 Oct 2002 04:49:29 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00780999@cherry.ease.lsoft.com>; Sat, 19 Oct 2002 4:51:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 315421 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 19 Oct 2002 04:51:40 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 19 Oct 2002 04:51:40 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H38RF>; Sat, 19 Oct 2002 04:51:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sat, 19 Oct 2002 04:53:50 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: draft-ishiguro-ospf-ospfv3-traffic-01.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Kunihiro Ishiguro, I have the following comments: - 1. Section 4. states that "Link State ID of Intra-Area-TE-LSA should be the interface ID of the link". If we are assuming that we have only one top level TLV in each LSA(as in Katz-yeung) we should state the exception in case of such an LSA. 2. If we are using "neighbor-ID TLV" for point-to-point links also, we should not need a Remote-Interface-IPv6 Address TLV, becuase we can easily identify the other end of the link using the Interface ID. Besides it would be nice to state we can support unnumbered links that way in the document. Unlike katz-yeung which states "This document also does not support unnumbered links" Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Sat Oct 19 04:59:29 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28657 for ; Sat, 19 Oct 2002 04:59:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00780ACA@cherry.ease.lsoft.com>; Sat, 19 Oct 2002 5:01:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 315450 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 19 Oct 2002 05:01:40 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 19 Oct 2002 05:01:40 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H38RQ>; Sat, 19 Oct 2002 05:01:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sat, 19 Oct 2002 05:03:38 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Link TLV's sub-TLVs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Kunihiro Ishiguro, Why do we need the TLV 11 - Link Local/Remote Identifiers (8 octets) The Neighbor Id identifies the remote Interface ID. The local Interface ID is the Link ID of the LSA. Thanks, Vishwas -----Original Message----- From: Kunihiro Ishiguro [mailto:kunihiro@IPINFUSION.COM] Sent: Tuesday, October 15, 2002 1:54 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Link TLV's sub-TLVs Here is a current Link TLV's sub-TLVs list ;-) which is referred in various drafts. With this TLVs I think we are pretty much ok (hopefully...). I'll submit updated draft. Traffic Engineering Link TLV (type 2) sub-TLVs Traffic Engineering sub-TLVs ============================ 1 - Link type (1 octet) 2 - Link ID (4 octets) 3 - Local interface IP address (4N octets) 4 - Remote interface IP address (4N octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets) GMPLS sub-TLVs ============== 11 - Link Local/Remote Identifiers (8 octets) 14 - Link Protection Type (4 octets) 15 - Interface Switching Capability Descriptor (variable) 16 - Shared Risk Link Group (variable) IPv6 sub-TLVs ============= 17 - Neighbor ID (8 octets) 18 - Local Interface IPv6 Address (16N octets) 19 - Remote Interface IPv6 Address (16N octets) Diffserv aware MPLS sub-TLVs ============================ TBD - Bandwidth Constraint Model Id (1 octet) Bandwidth Constraints (4N octets) TBD - Local Overbooking Multiplier (2N octets) 10,12,13 are not used by historical reason. Reference ========= draft-katz-yeung-ospf-traffic-08.txt draft-ietf-ccamp-ospf-gmpls-extensions-08.txt draft-ishiguro-ospf-ospfv3-traffic-01.txt draft-ietf-tewg-diff-te-proto-01.txt -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Sat Oct 19 09:26:16 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01995 for ; Sat, 19 Oct 2002 09:26:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00780D80@cherry.ease.lsoft.com>; Sat, 19 Oct 2002 9:28:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 316272 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 19 Oct 2002 09:28:26 -0400 Received: from 64.139.11.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 19 Oct 2002 09:28:26 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id JAA01328; Sat, 19 Oct 2002 09:31:57 -0400 References: User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.91 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Sat, 19 Oct 2002 06:31:57 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: Link TLV's sub-TLVs Comments: To: "Manral, Vishwas" To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list >Why do we need the TLV > >11 - Link Local/Remote Identifiers (8 octets) > >The Neighbor Id identifies the remote Interface ID. The local Interface ID >is the Link ID of the LSA. Please ask to GMPLS draft author. -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Sat Oct 19 10:57:41 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03833 for ; Sat, 19 Oct 2002 10:57:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00780F39@cherry.ease.lsoft.com>; Sat, 19 Oct 2002 10:59:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 316406 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 19 Oct 2002 10:59:51 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 19 Oct 2002 10:59:51 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02071 for ; Sat, 19 Oct 2002 10:59:49 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27121 for ; Sat, 19 Oct 2002 10:59:50 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4W8J6C72>; Sat, 19 Oct 2002 10:59:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557633F8@vie-msgusr-01.dc.fore.com> Date: Sat, 19 Oct 2002 10:59:46 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Link TLV's sub-TLVs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Vishwas, -> Why do we need the TLV -> -> 11 - Link Local/Remote Identifiers (8 octets) -> -> The Neighbor Id identifies the remote Interface ID. -> The local Interface ID is the Link ID of the LSA. sub-TVL 11 is used to represent unnumbered links for TE purposes. Those IF_IDs are not in the same *space* of IP Addresses in a router, but they can coincide with IP addresses. To resolve the issue of this coincidence, for unambiguous identification of parallel unnumbered links this TLV 11 is introduced in GMPLS drafts. Whereas, Link ID and Neighbor ID sub-TLVs identifies mostly a *routing instance* not a specific *interface instance*. -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Sat Oct 19 13:48:48 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05544 for ; Sat, 19 Oct 2002 13:48:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0078105C@cherry.ease.lsoft.com>; Sat, 19 Oct 2002 13:51:01 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 316718 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 19 Oct 2002 13:51:00 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 19 Oct 2002 13:51:00 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03041 for ; Sat, 19 Oct 2002 13:50:57 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06260 for ; Sat, 19 Oct 2002 13:50:59 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4W8J61H3>; Sat, 19 Oct 2002 13:50:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557633F9@vie-msgusr-01.dc.fore.com> Date: Sat, 19 Oct 2002 13:50:56 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Link TLV's sub-TLVs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Kunihiro, -> IPv6 sub-TLVs -> ============= -> 17 - Neighbor ID (8 octets) -> 18 - Local Interface IPv6 Address (16N octets) -> 19 - Remote Interface IPv6 Address (16N octets) One suggestion - draft-ishiguro-ospf-ospfv3-traffic-01.txt reads: -- 3.2 Neighbor ID In OSPFv2, Link ID is a unique key to identify the other end of the link. In OSPFv3 to identify the other end of the link, the combina- tion of Neighbor Interface ID and Neighbor Router ID is needed. So new sub-TLV Neighbor ID is defined. The Neighbor ID sub-TLV is TLV type 17, and is 8 octets in length. It contains 4 octet Neighbor Interface ID and 4 octet Neighbor Router ID. Neighbor Interface ID and Neighbor Router ID value is as same as described in [OSPFV3] A.4.3 Router-LSAs. In OSPFv2, the Neighbor ID sub-TLV should not be sent and ignored upon receipt. -- 1. Is it possible for you to change sub-TLV 17 to "Neighbor Interface ID (4 octets)" instead of "Neighbor ID (8 octets)" ? Because, Neighbor Router ID is anyway available in other sub-TLVs. 2. If there is a strong reason to duplicate "Neighbor Router ID" for IPv6 then it is OK. But, please specify the order in which these IDs encoding/decoding interpretation. That is, in the 8 Octets, "Neighbor Router ID" occupies the first 4 octets or "Neighbor Interface ID" ? Thank you. -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Sat Oct 19 13:59:58 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05638 for ; Sat, 19 Oct 2002 13:59:57 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00781119@cherry.ease.lsoft.com>; Sat, 19 Oct 2002 14:02:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 316759 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 19 Oct 2002 14:02:11 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 19 Oct 2002 14:02:11 -0400 Received: (qmail 12471 invoked from network); 19 Oct 2002 18:02:10 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 19 Oct 2002 18:02:10 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id OAA18430 for ; Sat, 19 Oct 2002 14:02:10 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210191802.OAA18430@bigbird.xebeo.com> Date: Sat, 19 Oct 2002 14:02:10 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from Naiming Shen of "Fri, 18 Oct 2002 23:07:55 PDT." <20021019060755.A9489CAB7C@prattle.redback.com> Precedence: list Hello Naiming, Thanks for your thoughtful comments. There are two ways one can look at TE over multi-access links - a) Only 2 devices are allowed. This was my interpretation based on section 1.2. My take is that if the condition is violated (ie there are more than 2 devices) one needs to spell out how to react to this. b) More than 2 devices are allowed which can work given the limitations you list below. If this is allowed, we need to explicitly say so and indicate any additional procedures in the draft. Either way, I think the item needs to be clarified. Best, --rohit. On Fri, 18 Oct 2002 23:07:55 -0700 Naiming Shen writes: =>there is no need to withdraw TE LSAs while more than two routers =>start to exist on the multi-access network. the TE draft says =>clearly there will be limitations(verses the p2p link), but this =>does not at all mean you can not run TE on that multi-access link =>with multiple-routers. it's perfectly "fine" to setup TE tunnels =>with multiple routers over the same multi-access link. => =>will this cause problem in terms of congestion? yes, it can. but => => - even over p2p TE links, we only reserve the bandwidth for => the TE links, we can still "overbook" the bandwidth and congest => the p2p TE links. => => - TE is usually used to route traffic for the purpose of saving => cost in the long-haul p2p links. those multi-router/multi-access => link usually is close to the edge of the network. even there is => congestion going on, there probably is not much you can do to => route around them. If there is congestion, simple add more => bandwith there and the cost should be low. => =>since there will be a need to do TE with multiple routers on a LAN, =>i think specifying the remote ip of 0.0.0.0 is OK, the draft probably =>should say "or this TLV can be omitted". specifying a real IP address =>even in the case of only two routers on the LAN does not sound right. =>for p2p link, you have to specify the neighbor IP address, since =>otherwise, in the case of parallel p2p links, there will be no =>other indication to flag the match at both ends. for LAN, you have =>the DR interface address to tie them ends together. => =>thanks. From owner-ospf@DISCUSS.MICROSOFT.COM Sat Oct 19 18:34:12 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08525 for ; Sat, 19 Oct 2002 18:34:11 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.007815C7@cherry.ease.lsoft.com>; Sat, 19 Oct 2002 18:36:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 317123 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 19 Oct 2002 18:36:23 -0400 Received: from 64.139.11.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 19 Oct 2002 18:36:23 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id SAA05710; Sat, 19 Oct 2002 18:39:47 -0400 References: <39469E08BD83D411A3D900204840EC557633F9@vie-msgusr-01.dc.fore.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.91 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Sat, 19 Oct 2002 15:39:47 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: Link TLV's sub-TLVs Comments: To: "Naidu, Venkata" To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC557633F9@vie-msgusr-01.dc.fore.com> Precedence: list > 1. Is it possible for you to change sub-TLV 17 to "Neighbor > Interface ID (4 octets)" instead of "Neighbor ID (8 octets)" ? > Because, Neighbor Router ID is anyway available in other sub-TLVs. Do you mean Link ID sub-TLV? > 2. If there is a strong reason to duplicate "Neighbor Router ID" for > IPv6 then it is OK. But, please specify the order in which these > IDs encoding/decoding interpretation. That is, in the 8 Octets, > "Neighbor Router ID" occupies the first 4 octets or "Neighbor > Interface ID" ? Thanks. I'll specify it. Neighbor Interface ID is first. My draft reuse OSPFv3 mechanism to detect the neighbor or the link. Neighbor ID TLV has same format and same value of OSPFv3 Router-LSA. RFC2740 A.4.3 Router-LSAs ========================= 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |0|0|1| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |W|V|E|B| Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ==>| Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ==>| Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ==>| Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ==>| Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | From owner-ospf@DISCUSS.MICROSOFT.COM Sat Oct 19 19:22:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08866 for ; Sat, 19 Oct 2002 19:22:24 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00781668@cherry.ease.lsoft.com>; Sat, 19 Oct 2002 19:24:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 317190 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 19 Oct 2002 19:24:37 -0400 Received: from 64.139.11.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 19 Oct 2002 19:24:37 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id TAA05765; Sat, 19 Oct 2002 19:28:10 -0400 References: User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.91 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Sat, 19 Oct 2002 16:28:10 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: draft-ishiguro-ospf-ospfv3-traffic-01.txt Comments: cc: "Manral, Vishwas" To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list >1. Section 4. states that "Link State ID of Intra-Area-TE-LSA should be the >interface ID of the link". > >If we are assuming that we have only one top level TLV in each LSA(as in >Katz-yeung) we should state the exception in case of such an LSA. draft-katz-yeung-ospf-traffic-08.txt ==================================== 2.4.2. Link TLV The Link TLV describes a single link. It is constructed of a set of sub-TLVs. There are no ordering requirements for the sub-TLVs. Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology. I'm following 'Only one Link TLV shall be carried in each LSA'. Well, I prefer to say it must in OSPFv3 TE... >2. If we are using "neighbor-ID TLV" for point-to-point links also, we >should not need a Remote-Interface-IPv6 Address TLV, becuase we can easily >identify the other end of the link using the Interface ID. Neighbor-ID TLV is used for any type of link. We can map each TE information to each link using Neighbor-ID TLV. CSPF runs on the constraint topology information then generates ERO. Of course to generate ERO, IPv4/IPv6 address information is needed. Interface IPv6 Address information is for that. -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Sun Oct 20 05:32:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24515 for ; Sun, 20 Oct 2002 05:32:36 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00782496@cherry.ease.lsoft.com>; 20 Oct 2002 5:34:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 318053 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 20 Oct 2002 05:34:47 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 20 Oct 2002 05:34:47 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H39LR>; Sun, 20 Oct 2002 05:34:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sun, 20 Oct 2002 05:36:46 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Link TLV's sub-TLVs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Venkata, Then can we state that "Link State ID of Intra-Area-TE-LSA should be the Interface ID of the link.". Will all links advertized in TE topology also have an Interface ID? I thought not and did mail the author about it and got no reply, besides that I did raise the question on the same statement on the other mail to the list. Thanks, Vishwas -----Original Message----- From: Naidu, Venkata [mailto:Venkata.Naidu@MARCONI.COM] Sent: Saturday, October 19, 2002 8:30 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Link TLV's sub-TLVs Vishwas, -> Why do we need the TLV -> -> 11 - Link Local/Remote Identifiers (8 octets) -> -> The Neighbor Id identifies the remote Interface ID. -> The local Interface ID is the Link ID of the LSA. sub-TVL 11 is used to represent unnumbered links for TE purposes. Those IF_IDs are not in the same *space* of IP Addresses in a router, but they can coincide with IP addresses. To resolve the issue of this coincidence, for unambiguous identification of parallel unnumbered links this TLV 11 is introduced in GMPLS drafts. Whereas, Link ID and Neighbor ID sub-TLVs identifies mostly a *routing instance* not a specific *interface instance*. -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Sun Oct 20 18:13:07 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03721 for ; Sun, 20 Oct 2002 18:13:06 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.007833BB@cherry.ease.lsoft.com>; 20 Oct 2002 18:15:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 319703 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 20 Oct 2002 18:15:18 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 20 Oct 2002 18:15:17 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 509925D0B4; Mon, 21 Oct 2002 07:15:16 +0900 (JST) References: <3DB014EA.5040104@redback.com> <20021018.231043.35959799.yasu@sfc.wide.ad.jp> <3DB02D7B.1080301@redback.com> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021021.071515.33657192.yasu@sfc.wide.ad.jp> Date: Mon, 21 Oct 2002 07:15:15 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Gating for MaxAge LSA in ospfv3 Comments: To: acee@REDBACK.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DB02D7B.1080301@redback.com> Precedence: list Content-Transfer-Encoding: 7bit acee> > I said "original OSPFv2 (and hence also OSPFv3) specification is acee> > ambiguous about whether to apply MinLSInterval when purging of LSA acee> > (i.e. premature aging)". acee> acee> I don't think there is ambiguity in RFC 2328. acee> acee> MinLSInterval is defined as the minimum time between distinct acee> originations of any particular LSA. When you purge an LSA you acee> are definitely re-originating it with a new sequence number and acee> MaxAge. I find that you interpret the sentence "while leaving its LS sequence number alone" (RFC2328 14.1) as "with a new sequence number". And it is not described clearly that "premature aging" is "re-originating of LSA". Actually I didn't recognize that the sequence number of LSA going to be premature aged is (in most case) a new one from the view of the premature aging router itself, though I am working on OSPF a few years ... ................. so it's ambiguous ;p) I agree rest of acee's and all of sina's. Just my excuse, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Sun Oct 20 23:05:06 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07603 for ; Sun, 20 Oct 2002 23:05:06 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00783B7C@cherry.ease.lsoft.com>; 20 Oct 2002 23:07:20 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 320088 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 20 Oct 2002 23:07:20 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 20 Oct 2002 23:07:19 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 746001DCC62; Sun, 20 Oct 2002 20:07:18 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <3DB014EA.5040104@redback.com> <20021018.231043.35959799.yasu@sfc.wide.ad.jp> <3DB02D7B.1080301@redback.com> <20021021.071515.33657192.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB36F3A.4020704@redback.com> Date: Sun, 20 Oct 2002 23:06:34 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Gating for MaxAge LSA in ospfv3 Comments: To: Yasuhiro Ohara To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yasuhiro Ohara wrote: > acee> > I said "original OSPFv2 (and hence also OSPFv3) specification is > acee> > ambiguous about whether to apply MinLSInterval when purging of LSA > acee> > (i.e. premature aging)". > acee> > acee> I don't think there is ambiguity in RFC 2328. > acee> > acee> MinLSInterval is defined as the minimum time between distinct > acee> originations of any particular LSA. When you purge an LSA you > acee> are definitely re-originating it with a new sequence number and > acee> MaxAge. > > I find that you interpret the sentence "while leaving its LS sequence > number alone" (RFC2328 14.1) as "with a new sequence number". > And it is not described clearly that "premature aging" is > "re-originating of LSA". Actually I didn't recognize that the sequence > number of LSA going to be premature aged is (in most case) a new one > from the view of the premature aging router itself, > though I am working on OSPF a few years ... > ................. so it's ambiguous ;p) Yasu, I just looked at John Moy's public domain implementation and it doesn't apply the MinLSInterval to prematurely aged LSAs. So your interpretation is correct - premature LSA aging doesn't count as a reorigination. Thanks, Acee > > I agree rest of acee's and all of sina's. > > Just my excuse, > yasu > > > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sun Oct 20 23:10:58 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07660 for ; Sun, 20 Oct 2002 23:10:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00783BB2@cherry.ease.lsoft.com>; 20 Oct 2002 23:13:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 320118 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 20 Oct 2002 23:13:11 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 20 Oct 2002 23:13:11 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) id <0H4B00101AK6WY@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 12:19:18 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H4B0011WAK6VB@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 12:19:18 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0H4B00H2DAL7U1@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 12:19:56 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Message-ID: <004101c278af$92b68400$b4036c6b@sisodomain.com> Date: Mon, 21 Oct 2002 08:41:37 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Gating for MaxAge LSA in ospfv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Sina, We can definitely benefit from originating MaxAge LSA without waiting for the MinLSInterval. Following are some scenarios when this might be useful. 1> A router that was formerly a DR for a network, but is now no longer, needs to flush the network-LSA that it had previously originated. I see no point in waiting for MinLSInterval. 3> If a router is advertising a summary-LSA/AS-External LSA for a destination which becomes unreachable, it needs to flush that LSA from the routing domain by setting its age to MaxAge and reflooding. Why should I wait for 5 secs to do that? ----- Original Message ----- From: "Sina Mirtorabi" To: Sent: Saturday, October 19, 2002 2:16 AM Subject: Re: Gating for MaxAge LSA in ospfv3 > Yasu, > > > Actually, RFC 2328 is ambiguous about it. > > Because it does not mention about it, I think that MinLSInterval > > should not be applied to premature agings, as it lengthen the > > convergence time ... I think we should take the concept "Bad new fast". > > > > > although MinLSInterval is an architectural constant, implementations could > make this interval configurable ( with backoff algo ) in order to speed up > the convergence. > > now regarding Maxage LSA, it should be noted that although you could make > the bad news faster ( say by having a different interval for maxage LSA ) > you will not always benefit from it ( type 1 and 2 LSA ) this is because > when an adj is broken or a prefix is removed you will simply originate a new > version of LSA by making the corresponding change in the content so having a > shorter interval for maxage LSA will not help there ... > > Sina From owner-ospf@DISCUSS.MICROSOFT.COM Sun Oct 20 23:15:49 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07796 for ; Sun, 20 Oct 2002 23:15:49 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00783BD1@cherry.ease.lsoft.com>; 20 Oct 2002 23:18:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 320142 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 20 Oct 2002 23:18:02 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 20 Oct 2002 23:18:02 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) id <0H4B00204ASA4S@mailout1.samsung.com> for ospf@disCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 12:24:10 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H4B0012ZAS9T2@mailout1.samsung.com> for ospf@disCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 12:24:10 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0H4B00H40ATAU1@mmp2.samsung.com> for ospf@disCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 12:24:47 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Message-ID: <005301c278b0$4056c200$b4036c6b@sisodomain.com> Date: Mon, 21 Oct 2002 08:46:29 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Fw: Gating for MaxAge LSA in ospfv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT I'm sorry .. i had not completed this mail and i pressed the send button by mistake. > We can definitely benefit from originating MaxAge LSA without waiting for > the MinLSInterval. > > Following are some scenarios when this might be useful. > > 1> A router that was formerly a DR for a network, but is now no longer, > needs to flush the network-LSA that it had previously originated. I see no > point in waiting for MinLSInterval. > > 2> If a router is advertising a summary-LSA/AS-External LSA for a > destination which becomes unreachable, it needs to flush that LSA from the > routing domain by setting its age to MaxAge and reflooding. Why should I > wait for 5 secs to do that? Moreover - this is the kind of trend is followed in BGP too. We wait for some time before advertising our UPDATEs (reachability information) for better packing and stability issues. But we dont wait for that long before advertising our WITHDRAW messages. Just a thought. Regards, Manav From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 06:23:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22903 for ; Mon, 21 Oct 2002 06:23:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.007842C2@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 6:25:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 321032 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 06:25:31 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 06:25:31 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl133-19.cisco.com [144.254.54.214]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9LAPU004321 for ; Mon, 21 Oct 2002 03:25:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Mon, 21 Oct 2002 03:25:30 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Gating for MaxAge LSA in ospfv3 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <004101c278af$92b68400$b4036c6b@sisodomain.com> Precedence: list Content-Transfer-Encoding: 7bit Manav, > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Manav > Bhatia > Sent: Sunday, October 20, 2002 8:12 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Gating for MaxAge LSA in ospfv3 > > > Sina, > We can definitely benefit from originating MaxAge LSA without waiting for > the MinLSInterval. > what you call _benefit_ ? we were talking about _fast convergence_ and announcing bad news fast > Following are some scenarios when this might be useful. > > 1> A router that was formerly a DR for a network, but is now no longer, > needs to flush the network-LSA that it had previously originated. > I see no > point in waiting for MinLSInterval. > I do not see how convergence is faster if the old DR Maxage its old network LSA faster than MinLSInterval ? even if the router is unable to maxage ( it is down ) it will remain for maxage time in the database BUT the convergence is not impacted > 3> If a router is advertising a summary-LSA/AS-External LSA for a > destination which becomes unreachable, it needs to flush that LSA from the > routing domain by setting its age to MaxAge and reflooding. Why should I > wait for 5 secs to do that? if you read my e-mail one more time ;-) you will see that I mentioned for "type 1 and type 2". for summary / external, sure you could maxage right away ... also in the case of summary origination the SPF needs to be scheduled in order to originate / maxage summary LSA therefore your LSA will be anyway delayed ( throttled ) so there might not be a need for extra interval time Sina > > > > > ----- Original Message ----- > From: "Sina Mirtorabi" > To: > Sent: Saturday, October 19, 2002 2:16 AM > Subject: Re: Gating for MaxAge LSA in ospfv3 > > > > Yasu, > > > > > Actually, RFC 2328 is ambiguous about it. > > > Because it does not mention about it, I think that MinLSInterval > > > should not be applied to premature agings, as it lengthen the > > > convergence time ... I think we should take the concept "Bad > new fast". > > > > > > > > > although MinLSInterval is an architectural constant, implementations > could > > make this interval configurable ( with backoff algo ) in order to speed > up > > the convergence. > > > > now regarding Maxage LSA, it should be noted that although you > could make > > the bad news faster ( say by having a different interval for > maxage LSA ) > > you will not always benefit from it ( type 1 and 2 LSA ) this is because > > when an adj is broken or a prefix is removed you will simply originate a > new > > version of LSA by making the corresponding change in the content so > having a > > shorter interval for maxage LSA will not help there ... > > > > Sina From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 09:48:14 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28627 for ; Mon, 21 Oct 2002 09:48:13 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.007847D4@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 9:50:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 321448 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 09:50:27 -0400 Received: from 198.152.13.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 09:40:27 -0400 Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10984 for ; Mon, 21 Oct 2002 09:38:13 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10973 for ; Mon, 21 Oct 2002 09:38:12 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27907.6838D669" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: overlapping area ranges Thread-Index: AcJ5B1SmPIeOkWwbTcuqzw5kZ/5QrA== Message-ID: Date: Mon, 21 Oct 2002 15:40:24 +0200 Reply-To: Mailing List Sender: Mailing List From: "Kostiner, Assaf (Assaf)" Subject: overlapping area ranges To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C27907.6838D669 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, I'm trying to understand the exact problem with aggregating all subnets = of 10.0.0.0/8 in one area, and having an address 10.2.3.4 in another = area.=20 When trying to find the best-match, we always go to the more specific IP = address anyway, so 10.2.3.4 should always be reachable. no?=20 Why then, in RFC 1583, they prevented this configuration, by preventing = the border router which aggregates the 10.0.0.0 range, from accepting = summaries which fall into this range? Why in the later RFCs, they added the following paragraph (under 11.1): "Before the lookup begins, "discard" routing table entries should be = inserted into the routing table for each of the router's active area = address ranges (see Section 3.5). (An area range is considered "active" = if the range contains one or more networks reachable by intra-area = paths.) The destination of a "discard" entry is the set of addresses = described by its associated active area address range, and the path type = of each "discard" entry is set to "inter-area".[10] " What is its contribution? I would appreciate any help with the above. Thanks in advance, Assaf. ------_=_NextPart_001_01C27907.6838D669 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable overlapping area ranges

Hi,

I'm trying to understand the = exact problem with aggregating all subnets of 10.0.0.0/8 in one area, = and having an address 10.2.3.4 in another area.

When trying to find the = best-match, we always go to the more specific IP address anyway, so = 10.2.3.4 should always be reachable. no?

Why then, in RFC 1583, they = prevented this configuration, by preventing the border router which = aggregates the 10.0.0.0 range, from accepting summaries which fall into = this range?

Why in the later RFCs, they = added the following paragraph (under 11.1):

"Before the lookup begins, = "discard" routing table entries should be inserted into the = routing table for each of the router's active area address ranges (see = Section 3.5). (An area range is considered "active" if the = range contains one or more networks reachable by intra-area paths.) The = destination of a "discard" entry is the set of addresses = described by its associated active area address range, and the path type = of each "discard" entry is set to "inter-area".[10] = "

What is = its contribution?

I would = appreciate any help with the above. Thanks in advance, = Assaf.

------_=_NextPart_001_01C27907.6838D669-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 10:08:20 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29311 for ; Mon, 21 Oct 2002 10:08:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00784874@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 10:10:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 321533 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 10:10:34 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 10:10:34 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZCAYLR>; Mon, 21 Oct 2002 19:41:01 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Message-ID: <55E277B99171E041ABF5F4B1C6DDCA069AE75E@haritha.hclt.com> Date: Mon, 21 Oct 2002 19:42:36 +0530 Reply-To: Mailing List Sender: Mailing List From: "Jeyanath Minto J - CTD, Chennai." Subject: Re: overlapping area ranges To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list hi Kostiner, otherwise we end up with routing Loop. assume that two routers are advertise same 10/8 route. both the routers think others having route to unreachable destination( like 10.2.4/24 ) and forward to each other . discard route solve this problem by " if we dont have the exact match and the route entry is discard entry then drop it " Minto -----Original Message----- From: Kostiner, Assaf (Assaf) [mailto:akostine@AVAYA.COM] Sent: Monday, October 21, 2002 7:10 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: overlapping area ranges Hi, I'm trying to understand the exact problem with aggregating all subnets of 10.0.0.0/8 in one area, and having an address 10.2.3.4 in another area. When trying to find the best-match, we always go to the more specific IP address anyway, so 10.2.3.4 should always be reachable. no? Why then, in RFC 1583, they prevented this configuration, by preventing the border router which aggregates the 10.0.0.0 range, from accepting summaries which fall into this range? Why in the later RFCs, they added the following paragraph (under 11.1): "Before the lookup begins, "discard" routing table entries should be inserted into the routing table for each of the router's active area address ranges (see Section 3.5). (An area range is considered "active" if the range contains one or more networks reachable by intra-area paths.) The destination of a "discard" entry is the set of addresses described by its associated active area address range, and the path type of each "discard" entry is set to "inter-area".[10] " What is its contribution? I would appreciate any help with the above. Thanks in advance, Assaf. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 13:55:41 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08097 for ; Mon, 21 Oct 2002 13:55:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00784F84@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 13:57:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 322165 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 13:57:54 -0400 Received: from 66.218.78.166 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 13:57:54 -0400 Received: from [63.103.225.22] by web40709.mail.yahoo.com via HTTP; Mon, 21 Oct 2002 10:57:49 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-944810506-1035223069=:86008" Message-ID: <20021021175749.86194.qmail@web40709.mail.yahoo.com> Date: Mon, 21 Oct 2002 10:57:49 -0700 Reply-To: Mailing List Sender: Mailing List From: Vinay Ravuri Subject: OSPF Question To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --0-944810506-1035223069=:86008 Content-Type: text/plain; charset=us-ascii Hi, Consider the following topology. A --------B----------C | | | | | | D E F Where A, B, C, D, E, F are routers and A, B, C have interfaces out to each other and to D, E, F respectivley. If I wanted to keep the interfaces between A, B, C private to routers A, B, C. That is, I do not want D, E, F to know about the interfaces that exist between A, B, C but still have D, E, F to reach each other some how. How could I accomplish this with OSPF? One thought I had was perhaps run 2 instances of OSPF on A, B, C. First instance runs between iterfaces on A, B, C and second between A->D, B->E, C->F and advertise the reachability to D, E, F via the interfaces A, B, C and keep the interfaces between A, B, C hidden. Does doing something like this make sense or is there a better to accomplish this. Also, with OSPF how does one differentiate between interfaces on a another node inorder to selectively leak routes? -Vinay --------------------------------- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site --0-944810506-1035223069=:86008 Content-Type: text/html; charset=us-ascii

Hi,

   Consider the following topology.


    A --------B----------C
    |         |             |
    |         |             |
    D        E          F

Where A, B, C, D, E, F are routers and A, B, C have interfaces out to each other and to D, E, F respectivley. 

If I wanted to keep the interfaces between A, B, C private to routers A, B, C.  That is, I do not want D, E, F to know about the interfaces that exist between A, B, C but still have D, E, F to reach each other some how.  How could I accomplish this with OSPF?

One thought I had was perhaps run 2 instances of OSPF on A, B, C.  First instance runs between iterfaces on A, B, C and second between A->D, B->E, C->F and advertise the reachability to D, E, F via the interfaces A, B, C and keep the interfaces between A, B, C hidden.  Does doing something like this make sense or is there a better to accomplish this.  Also, with OSPF how does one differentiate between interfaces on a another node inorder to selectively leak routes?

-Vinay


Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site --0-944810506-1035223069=:86008-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 13:55:44 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08131 for ; Mon, 21 Oct 2002 13:55:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.007850E9@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 13:57:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 322179 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 13:57:58 -0400 Received: from 66.218.78.168 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 13:57:58 -0400 Received: from [63.103.225.22] by web40711.mail.yahoo.com via HTTP; Mon, 21 Oct 2002 10:57:58 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-142809093-1035223078=:41065" Message-ID: <20021021175758.41924.qmail@web40711.mail.yahoo.com> Date: Mon, 21 Oct 2002 10:57:58 -0700 Reply-To: Mailing List Sender: Mailing List From: Vinay Ravuri Subject: OSPF Question To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --0-142809093-1035223078=:41065 Content-Type: text/plain; charset=us-ascii Hi, Consider the following topology. A --------B----------C | | | | | | D E F Where A, B, C, D, E, F are routers and A, B, C have interfaces out to each other and to D, E, F respectivley. If I wanted to keep the interfaces between A, B, C private to routers A, B, C. That is, I do not want D, E, F to know about the interfaces that exist between A, B, C but still have D, E, F to reach each other some how. How could I accomplish this with OSPF? One thought I had was perhaps run 2 instances of OSPF on A, B, C. First instance runs between iterfaces on A, B, C and second between A->D, B->E, C->F and advertise the reachability to D, E, F via the interfaces A, B, C and keep the interfaces between A, B, C hidden. Does doing something like this make sense or is there a better to accomplish this. Also, with OSPF how does one differentiate between interfaces on a another node inorder to selectively leak routes? -Vinay --------------------------------- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site --0-142809093-1035223078=:41065 Content-Type: text/html; charset=us-ascii

Hi,

   Consider the following topology.


    A --------B----------C
    |         |             |
    |         |             |
    D        E          F

Where A, B, C, D, E, F are routers and A, B, C have interfaces out to each other and to D, E, F respectivley. 

If I wanted to keep the interfaces between A, B, C private to routers A, B, C.  That is, I do not want D, E, F to know about the interfaces that exist between A, B, C but still have D, E, F to reach each other some how.  How could I accomplish this with OSPF?

One thought I had was perhaps run 2 instances of OSPF on A, B, C.  First instance runs between iterfaces on A, B, C and second between A->D, B->E, C->F and advertise the reachability to D, E, F via the interfaces A, B, C and keep the interfaces between A, B, C hidden.  Does doing something like this make sense or is there a better to accomplish this.  Also, with OSPF how does one differentiate between interfaces on a another node inorder to selectively leak routes?

-Vinay


Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site --0-142809093-1035223078=:41065-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 13:56:19 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08166 for ; Mon, 21 Oct 2002 13:56:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.007850FA@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 13:58:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 322152 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 13:58:33 -0400 Received: from 198.178.8.81 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 13:48:33 -0400 Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id g9LHfhB6026545 for ; Mon, 21 Oct 2002 11:48:31 -0600 (MDT) Received: from 147.191.89.203 by mms02-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Mon, 21 Oct 2002 11:45:16 -0600 X-Server-Uuid: 327424A5-C000-4071-A863-154BD49E0E91 Received: by entexchimc01.tci.com with Internet Mail Service ( 5.5.2653.19) id <4XX045YJ>; Mon, 21 Oct 2002 11:47:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 11AAE2A6949269-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <9496EA69116CD4119EE800508B72D03E0168824F@coexch01.broadband.att.com> Date: Mon, 21 Oct 2002 11:48:25 -0600 Reply-To: Mailing List Sender: Mailing List From: "Field, Brian" Subject: re-using the same sub-area number To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Is there any issue from an OSPF protocol perspective with re-using a sub-area number multiple times? In the design I'm looking at, each physical location is connected to area 0 via one or more ABRs. I've got lots of different physical locations, and in order to simplify configs, tools, and operations, would like to avoid having to track a different sub-area number for each location. Any issue with this from an OSPF perspective? Other reasons not to do this? If it makes a difference, the sub-area would likely be configured as NSSAs. Apologies is this sort of question is outside the scope of the list. If so, let me know. Thanks Brian From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 14:18:02 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09064 for ; Mon, 21 Oct 2002 14:18:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00784FAC@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 14:20:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 322294 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 14:20:16 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 14:20:16 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 4DB751531D6 for ; Mon, 21 Oct 2002 11:20:12 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB44526.7000705@redback.com> Date: Mon, 21 Oct 2002 14:19:18 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: overlapping area ranges To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kostiner, Assaf (Assaf) wrote: > Hi, > > I'm trying to understand the exact problem with aggregating all subnets > of 10.0.0.0/8 in one area, and having an address 10.2.3.4 in another area. > > When trying to find the best-match, we always go to the more specific IP > address anyway, so 10.2.3.4 should always be reachable. no? > > Why then, in RFC 1583, they prevented this configuration, by preventing > the border router which aggregates the 10.0.0.0 range, from accepting > summaries which fall into this range? > > Why in the later RFCs, they added the following paragraph (under 11.1): > > "Before the lookup begins, "discard" routing table entries should be > inserted into the routing table for each of the router's active area > address ranges (see Section 3.5). (An area range is considered "active" > if the range contains one or more networks reachable by intra-area > paths.) The destination of a "discard" entry is the set of addresses > described by its associated active area address range, and the path type > of each "discard" entry is set to "inter-area".[10] " > > What is its contribution? > > I would appreciate any help with the above. Thanks in advance, Assaf. > Assaf, Overlapping subnet ranges are supported by the OSPF. As you noted, this was added between RFC 1587 and RFC 2178. In RFC 2328, this case is covered by footnote [11] on page 180. Thanks, ---- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 14:24:31 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09344 for ; Mon, 21 Oct 2002 14:24:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00784F95@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 14:26:45 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 322325 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 14:26:45 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 14:26:45 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl133-19.cisco.com [144.254.54.214]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9LIQh017607 for ; Mon, 21 Oct 2002 11:26:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Mon, 21 Oct 2002 11:26:43 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210191802.OAA18430@bigbird.xebeo.com> Precedence: list Content-Transfer-Encoding: 7bit Rohit, > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Rohit > Dube > Sent: Saturday, October 19, 2002 11:02 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Comments on draft-katz-yeung-traffic-08.txt > > > Hello Naiming, > > Thanks for your thoughtful comments. There are two ways one can > look at TE over multi-access links - > > a) Only 2 devices are allowed. This was my interpretation based > on section 1.2. My take is that if the condition is violated > (ie there are more than 2 devices) one needs to spell out > how to react to this. this is not how I would interpret. section 1.2 of the draft states: "The extensions specified in this document capture the reservation state of point-to-point links. The reservation state of multiaccess links is not accurately _reflected_, except in the special case that there are only two devices in the multiaccess subnetwork." > b) More than 2 devices are allowed which can work given the > limitations you list below. If this is allowed, we need > to explicitly say so and indicate any additional procedures > in the draft. > yes this is how I would read the draft... as far as for additional procedure, what else is needed to define a TE over multi-acess link having more than two attached routers? ( given the limitation for reservation state ) since 'Maximum Reservable Bandwidth' is configurable it is up to the operator to set a value that reflect a bit better the number of routers attached to the multi-acess network for example if there are N routers attached and we do not want to oversubscribe one could set Maximum Reservable Bandwidth <= Maximum Bandwidth / ( N-1 ) where N is the number of routers attached to multi-acess link Sina > Either way, I think the item needs to be clarified. > > Best, > --rohit. > > On Fri, 18 Oct 2002 23:07:55 -0700 Naiming Shen writes: > =>there is no need to withdraw TE LSAs while more than two routers > =>start to exist on the multi-access network. the TE draft says > =>clearly there will be limitations(verses the p2p link), but this > =>does not at all mean you can not run TE on that multi-access link > =>with multiple-routers. it's perfectly "fine" to setup TE tunnels > =>with multiple routers over the same multi-access link. > => > =>will this cause problem in terms of congestion? yes, it can. but > => > => - even over p2p TE links, we only reserve the bandwidth for > => the TE links, we can still "overbook" the bandwidth and congest > => the p2p TE links. > => > => - TE is usually used to route traffic for the purpose of saving > => cost in the long-haul p2p links. those multi-router/multi-access > => link usually is close to the edge of the network. even there is > => congestion going on, there probably is not much you can do to > => route around them. If there is congestion, simple add more > => bandwith there and the cost should be low. > => > =>since there will be a need to do TE with multiple routers on a LAN, > =>i think specifying the remote ip of 0.0.0.0 is OK, the draft probably > =>should say "or this TLV can be omitted". specifying a real IP address > =>even in the case of only two routers on the LAN does not sound right. > =>for p2p link, you have to specify the neighbor IP address, since > =>otherwise, in the case of parallel p2p links, there will be no > =>other indication to flag the match at both ends. for LAN, you have > =>the DR interface address to tie them ends together. > => > =>thanks. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 15:33:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12654 for ; Mon, 21 Oct 2002 15:33:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0078525F@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 15:36:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 322492 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 15:36:07 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 15:36:07 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id E2019262814 for ; Mon, 21 Oct 2002 12:36:05 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <9496EA69116CD4119EE800508B72D03E0168824F@coexch01.broadband.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB456F1.4070107@redback.com> Date: Mon, 21 Oct 2002 15:35:13 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: re-using the same sub-area number To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Field, Brian wrote: > Is there any issue from an OSPF protocol perspective with re-using > a sub-area number multiple times? > > In the design I'm looking at, each physical location is connected > to area 0 via one or more ABRs. I've got lots of different > physical locations, and in order to simplify configs, tools, > and operations, would like to avoid having to track a different > sub-area number for each location. > > Any issue with this from an OSPF perspective? Brian, The routing should work since OSPF will repair partitioned non-backbone areas over the backbone. However, I disagree with your premise that this will simplify things. You're giving up your ability to debug and manage each area separately just to avoid unique area specification. It doesn't sound like a very good trade-off to me. Thanks, Acee > > Other reasons not to do this? > > If it makes a difference, the sub-area would likely be configured > as NSSAs. > > Apologies is this sort of question is outside the scope of the > list. If so, let me know. > > Thanks > Brian > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 16:50:46 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15110 for ; Mon, 21 Oct 2002 16:50:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0078545B@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 16:53:00 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 322597 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 16:52:59 -0400 Received: from 65.174.124.29 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 16:42:58 -0400 Received: (from rv@localhost) by tennali (8.11.6/8.11.6) id g9LKfwr01378; Mon, 21 Oct 2002 13:41:58 -0700 X-Authentication-Warning: tennali: rv set sender to rv@procket.com using -f References: <200210180518.g9I5IeV86411@garnet.juniper.net> <3DAF9E35.7080200@redback.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Mime-Version: 1.0 Message-ID: <1035232857.1320.83.camel@tennali> Date: Mon, 21 Oct 2002 13:40:57 -0700 Reply-To: Mailing List Sender: Mailing List From: Rajesh Varadarajan Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DAF9E35.7080200@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Acee, Padma, Comments inline.... On Thu, 2002-10-17 at 22:37, Acee Lindem wrote: > Padma Pillay-Esnault wrote: > > > Acee > > > Hi Padma, > > > > > > > > > > > >>>>Just realized that this has been modified in later draft > >>>>in draft-ietf-ospf-hitless-restart-00.txt > >>>> > >>>> 3.1. Entering helper mode > >>>> > >>>> > >>>> Note that Router Y only needs to receive a single grace-LSA from > >>>> X, even if X and Y attach to multiple common segments. The data > >>>> in the first valid grace-LSA received is used to indicate the > >>>> beginning and the end of the grace period -- all subsequent > >>>> grace-LSAs received from X are ignored. This first grace-LSA is > >>>> referred to below as simply "the grace-LSA from X". > >>>> > >>>> A single router is allowed to simultaneously serve as a helper > >>>> for multiple restarting neighbors. > >>>> > >>>>later it is said in 02-txt > >>>> > >>>> Note that Router Y may be helping X on some network segments, > >>>> and not on others. However, that circumstance will probably lead > >>>> to the premature termination of X's hitless restart, as Y will > >>>> not continue to advertise adjacencies on the segments where it > >>>> is not helping (see Section 2.2). > >>>> A single router is allowed to simultaneously serve as a helper > >>>> for multiple restarting neighbors. > >>>> > >>>>Isn't that going to always lead to premature termination and hence defeat the > >>>>purpose ? > >>>>What is the idea behind of doing it per segment ? > >>>>A restarting router will affect all its links in the same way so why > >>>>differentiate it ? > >>>> > >>>> > >>> > >>>I think don't think it makes sense that a full neighbor would help on > >>> > >>>some network segments and not others. I agree this would leas to premature > >>>termination. > >>> > >>> > >>Ok. we are on the same wavelength. > >> > >> > >>>I do think it simplifies things if a restarting router originates the grace LSAs > >>>on all it's interfaces (or at least all with full neighbor > >>>adjacencies if it a planned restart). > >>> > >>> The above statement seems to imply (my reading) that a restarting router can only send Grace LSA's out of some (not all) of its interfaces. The spec however requires the router to send the grace-lsa out of all interfaces on which it has full neigbhors. Failure to do so would always result in its helper mode being terminated by others. A -- B --- C --- D --+ | | +--------------------+ If 1. A sent the grace LSA only to B. 2. B would help A and not change it router LSA after A's dead timer fires. 3. However D would change its router LSA after A's dead timer fires and flood back to B thru C. 4. When B receives the changed LSA from D, its going to terminate helping A. Therefore, in any network with any redundant connectivity, sending a grace LSA on every interface is required for hitless restart to work. The 00-txt (no longer in 02-txt) seems to be a corner-case optimization which solves the case when the same routers are adjacent on multiple interfaces, no other routers exist in those interfaces and one is restarted. > >>I also agree with you .. that's what I do - the restarting router sends > >>grace lsa over all interfaces. But from a Helping router perspective > >>we should do as in 00-txt. It simplifies the helper code. > >>It also prevents corner cases where we might not help all adjacencies > >>(when we should). > >> > >>Padma > >> > > > > > > I haven't heard anyone object to why the 00-txt. > > > I will - I specifically agree with: > > Note that Router Y only needs to receive a single grace-LSA from > X, even if X and Y attach to multiple common segments. > > I don't like using an LSA with link local scope to enter/terminate > helper mode for neighbors on different interfaces. It is better if the > link local grace LSA only applies to that link. > Given the behavior above, I think the each neighbor should be considered independently on a segment by segment basis. thanks, rajesh From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 17:13:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15762 for ; Mon, 21 Oct 2002 17:13:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0078552D@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 17:16:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 322720 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 17:16:05 -0400 Received: from 128.123.15.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 17:16:05 -0400 Received: from nmsu.edu ([128.123.15.221]) by mail.psl.nmsu.edu with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Oct 2002 15:16:04 -0600 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20021021175749.86194.qmail@web40709.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2002 21:16:04.0810 (UTC) FILETIME=[109C1AA0:01C27947] Message-ID: <3DB46EC2.6090207@nmsu.edu> Date: Mon, 21 Oct 2002 15:16:50 -0600 Reply-To: Mailing List Sender: Mailing List From: Vincent Subject: Highly Connected Network Topologies To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I installed John T Moy's OSPF simulation app and would like to model and simulate "highly connected network topologies", unfortunetly I do not have much real-world OSPF/Networking experience to know what topologies would be practical. I would appreciate it greatly if someone could send me a few examples (please identify rtrs w/ ext routes) or an URL that would have some 'real-world' examples. Vince From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 17:15:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15841 for ; Mon, 21 Oct 2002 17:15:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00785609@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 17:17:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 322744 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 17:17:25 -0400 Received: from 207.159.120.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 17:17:25 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id BD3F8133C7; Mon, 21 Oct 2002 17:17:22 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe5.nwk.excite.com via HTTP; Mon, 21 Oct 2002 17:17:22 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20021021211722.BD3F8133C7@xmxpita.excite.com> Date: Mon, 21 Oct 2002 17:17:22 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: 55th IETF OSPF WG Meeting To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit The current Hitless Restart draft (-02) has expired. Will there be a new version submitted in time for IETF? Also, is the NSSA update up for LastCall? -don --- On Fri 10/11, Acee Lindem wrote: From: Acee Lindem [mailto: acee@REDBACK.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Fri, 11 Oct 2002 00:51:48 -0400 Subject: 55th IETF OSPF WG Meeting > The OSPF WG will be meeting in Atlanta (although I haven't received > confirmation of the date/time yet). > > Those of you wishing to present at the WG meeting should send a > note to Rohit (rohit@xebeo.com) and myself. The WG agenda must be > submitted by 11/14. > > Also note that New I-Ds (the -00 versions) must be sent to > internet-drafts@ietf.org by 10/28 and that all updated drafts > must be submitted by 11/4. > > > Thanks, > -- > Acee > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 17:21:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16010 for ; Mon, 21 Oct 2002 17:21:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.007855D5@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 17:24:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 322797 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 17:24:02 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 17:24:02 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id F36DA1531D7 for ; Mon, 21 Oct 2002 14:24:00 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20021021211722.BD3F8133C7@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB4703B.6050809@redback.com> Date: Mon, 21 Oct 2002 17:23:07 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: 55th IETF OSPF WG Meeting To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Don Goodspeed wrote: > The current Hitless Restart draft (-02) has expired. Will there be > a new version submitted in time for IETF? Yes. > Also, is the NSSA update up for LastCall? The -09 version went through working group last call a while back. Several comments have been ironed out since then and the -11 version has gone thought IETF last call. See link below. > > -don > > --- On Fri 10/11, Acee Lindem wrote: > From: Acee Lindem [mailto: acee@REDBACK.COM] > To: OSPF@DISCUSS.MICROSOFT.COM > Date: Fri, 11 Oct 2002 00:51:48 -0400 > Subject: 55th IETF OSPF WG Meeting > > >>The OSPF WG will be meeting in Atlanta (although I haven't received >>confirmation of the date/time yet). >> >>Those of you wishing to present at the WG meeting should send a >>note to Rohit (rohit@xebeo.com) and myself. The WG agenda must be >>submitted by 11/14. >> >>Also note that New I-Ds (the -00 versions) must be sent to >>internet-drafts@ietf.org by 10/28 and that all updated drafts >>must be submitted by 11/4. >> >> >>Thanks, >>-- >>Acee >> >> > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 17:45:59 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16507 for ; Mon, 21 Oct 2002 17:45:59 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00785674@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 17:48:14 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 322878 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 17:48:14 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 17:48:14 -0400 Received: from padma-bsd.juniper.net (padma-bsd.juniper.net [172.17.12.219]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9LLmDm85434 for ; Mon, 21 Oct 2002 14:48:13 -0700 (PDT) (envelope-from padma@juniper.net) Received: from juniper.net (localhost [127.0.0.1]) by padma-bsd.juniper.net (8.11.6/8.9.3) with ESMTP id g9LLmDo00145 for ; Mon, 21 Oct 2002 14:48:13 -0700 (PDT) (envelope-from padma@juniper.net) User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210180518.g9I5IeV86411@garnet.juniper.net> <3DAF9E35.7080200@redback.com> <1035232857.1320.83.camel@tennali> Content-Type: multipart/alternative; boundary="------------090108050103050202040106" Message-ID: <3DB4761D.5010504@juniper.net> Date: Mon, 21 Oct 2002 14:48:13 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Organization: Juniper Networks Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --------------090108050103050202040106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Rajesh Rajesh Varadarajan wrote: >Acee, Padma, > >>>>>I do think it simplifies things if a restarting router originates the grace LSAs >>>>>on all it's interfaces (or at least all with full neighbor >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>> >>>>>adjacencies if it a planned restart). >>>>> >>>>> >>>>> >>>>> > >The above statement seems to imply (my reading) that a restarting router > >can only send Grace LSA's out of some (not all) of its interfaces. The > It doesn't imply that - clearly we send to all our neighbors. Padma > >spec however requires the router to send the grace-lsa out of all >interfaces on which it has full neigbhors. Failure to do so would always >result in its helper mode being terminated by others. > >>>>I also agree with you .. that's what I do - the restarting router sends >>>>grace lsa over all interfaces. But from a Helping router perspective >>>>we should do as in 00-txt. It simplifies the helper code. >>>>It also prevents corner cases where we might not help all adjacencies >>>>(when we should). >>>> >>>>Padma >>>> >>> >>>I haven't heard anyone object to why the 00-txt. >>> >> >>I will - I specifically agree with >> >> >> >> Note that Router Y only needs to receive a single grace-LSA from >> X, even if X and Y attach to multiple common segments. >> >>I don't like using an LSA with link local scope to enter/terminate >>helper mode for neighbors on different interfaces. It is better if the >>link local grace LSA only applies to that link. >> > >Given the behavior above, I think the each neighbor should be considered >independently on a segment by segment basis. > > >thanks, >rajesh > > --------------090108050103050202040106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Rajesh


Rajesh Varadarajan wrote:
Acee, Padma,


<snip>
I do think it simplifies things if a restarting router originates the grace LSAs
on all it's interfaces (or at least all with full neighbor
                                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^

adjacencies if it a planned restart).





The above statement seems to imply (my reading) that a restarting router
can only send Grace LSA's out of some (not all) of its interfaces. The
It doesn't imply that - clearly we send to all our neighbors.

Padma

spec however requires the router to send the grace-lsa out of all
interfaces on which it has full neigbhors. Failure to do so would always
result in its helper mode being terminated by others.
<snip>
I also agree with you .. that's what I do - the restarting router sends
grace lsa over all interfaces. But from a Helping router perspective
we should do as in 00-txt. It simplifies the helper code.
It also prevents corner cases where we might not help all adjacencies
(when we should).

Padma


I haven't heard anyone object to why the 00-txt.

I will - I specifically agree with


         Note that Router Y only needs to receive a single grace-LSA from
         X, even if X and Y attach to multiple common segments.

I don't like using an LSA with link local scope to enter/terminate
helper mode for neighbors on different interfaces. It is better if the
link local grace LSA only applies to that link.


Given the behavior above, I think the each neighbor should be considered
independently on a segment by segment basis.

thanks,
rajesh



--------------090108050103050202040106-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 18:08:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17026 for ; Mon, 21 Oct 2002 18:08:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00785A4C@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 18:11:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 322986 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 18:11:06 -0400 Received: from 207.159.120.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 18:11:06 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 4F631133EC; Mon, 21 Oct 2002 18:11:03 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe5.nwk.excite.com via HTTP; Mon, 21 Oct 2002 18:11:03 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20021021221103.4F631133EC@xmxpita.excite.com> Date: Mon, 21 Oct 2002 18:11:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: 55th IETF OSPF WG Meeting Comments: cc: acee@REDBACK.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Thanks Acee. Is the new hitless restart draft still being done by John, or have you and/or others taken over as authors? Is there a link that can be added to the IETF OSPF WG page that lists the status of each draft, or can this be added after each document link on the WG page? -don --- On Mon 10/21, Acee Lindem wrote: From: Acee Lindem [mailto: acee@REDBACK.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Mon, 21 Oct 2002 17:23:07 -0400 Subject: Re: 55th IETF OSPF WG Meeting > Don Goodspeed wrote: > > > The current Hitless Restart draft (-02) has expired. Will there be > > a new version submitted in time for IETF? > > > Yes. > > > > Also, is the NSSA update up for LastCall? > > > The -09 version went through working group last call a while back. > Several comments have been ironed out since then and the -11 version > has gone thought IETF last call. See link below. > > > > > > > > > > -don > > > > --- On Fri 10/11, Acee Lindem wrote: > > From: Acee Lindem [mailto: acee@REDBACK.COM] > > To: OSPF@DISCUSS.MICROSOFT.COM > > Date: Fri, 11 Oct 2002 00:51:48 -0400 > > Subject: 55th IETF OSPF WG Meeting > > > > > >>The OSPF WG will be meeting in Atlanta (although I haven't > received > >>confirmation of the date/time yet). > >> > >>Those of you wishing to present at the WG meeting should send a > >>note to Rohit (rohit@xebeo.com) and myself. The WG agenda must be > >>submitted by 11/14. > >> > >>Also note that New I-Ds (the -00 versions) must be sent to > >>internet-drafts@ietf.org by 10/28 and that all updated drafts > >>must be submitted by 11/4. > >> > >> > >>Thanks, > >>-- > >>Acee > >> > >> > > > > _______________________________________________ > > Join Excite! - http://www.excite.com > > The most personalized portal on the Web! > > > > > > > -- > Acee > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 18:15:34 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17140 for ; Mon, 21 Oct 2002 18:15:34 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00785805@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 18:17:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 323015 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 18:17:48 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 18:17:48 -0400 Received: (qmail 19341 invoked from network); 21 Oct 2002 22:17:47 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 21 Oct 2002 22:17:47 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id SAA11690 for ; Mon, 21 Oct 2002 18:17:47 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210212217.SAA11690@bigbird.xebeo.com> Date: Mon, 21 Oct 2002 18:17:47 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from Sina Mirtorabi of "Mon, 21 Oct 2002 11:26:43 PDT." Precedence: list Hi Sina, Some comments inline [..] On Mon, 21 Oct 2002 11:26:43 -0700 Sina Mirtorabi writes: =>Rohit, => =>> -----Original Message----- =>> From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Rohit =>> Dube =>> Sent: Saturday, October 19, 2002 11:02 AM =>> To: OSPF@DISCUSS.MICROSOFT.COM =>> Subject: Re: Comments on draft-katz-yeung-traffic-08.txt =>> =>> =>> Hello Naiming, =>> =>> Thanks for your thoughtful comments. There are two ways one can =>> look at TE over multi-access links - =>> =>> a) Only 2 devices are allowed. This was my interpretation based =>> on section 1.2. My take is that if the condition is violated =>> (ie there are more than 2 devices) one needs to spell out =>> how to react to this. => =>this is not how I would interpret. =>section 1.2 of the draft states: => =>"The extensions specified in this document capture the reservation state of =>point-to-point links. The reservation state of multiaccess links is not =>accurately _reflected_, except in the special case that there are only two =>devices in the multiaccess subnetwork." Fair enough. However when I read the draft the first time, my conclusion was "since reservation state is not accurately reflected for more than two nodes, it would be dangerous to use more than two nodes on a multi-access networl". Some other folks that I know interpreted it similarly. => => =>> b) More than 2 devices are allowed which can work given the =>> limitations you list below. If this is allowed, we need =>> to explicitly say so and indicate any additional procedures =>> in the draft. =>> => =>yes this is how I would read the draft... =>as far as for additional procedure, what else is needed to define a TE over =>multi-acess link having more than two attached routers? ( given the =>limitation for reservation state ) => =>since 'Maximum Reservable Bandwidth' is configurable it is up to the =>operator to set a value that reflect a bit better the number of routers =>attached to the multi-acess network for example if there are N routers =>attached and we do not want to oversubscribe one could set => =>Maximum Reservable Bandwidth <= Maximum Bandwidth / ( N-1 ) =>where N is the number of routers attached to multi-acess link [snip] This will not require defining anything new, but it does require being a bit more verbose in dealing with multi-access networks. If the draft says nothing more, some implementors will likely force two nodes and others will allow more than two. The two types of implementations in the same network will provide surprising and undocumented results. Adding a small section on the topic is a small price to pay to avoid such problems down the road. Regards, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 18:19:00 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17251 for ; Mon, 21 Oct 2002 18:19:00 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0078597B@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 18:21:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 323047 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 18:21:13 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 18:21:13 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl131-17.cisco.com [144.254.57.148]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9LMLC020652 for ; Mon, 21 Oct 2002 15:21:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B6_01C27915.7D4B0DA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Mon, 21 Oct 2002 15:21:12 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPF Question To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021021175758.41924.qmail@web40711.mail.yahoo.com> Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_00B6_01C27915.7D4B0DA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Vinay by " not knowing about interface that exist" , do you mean topology wise or even not knowing IP reachability regarding those interface ? some option that you have depending on what really you are looking for .... a) make link A-B & B-C in area 0 and each other link in a different area if you don't want IP information of A-B and B-C to be advertised you can b) filter on A / B / C the corresponding prefixes belonging to area 0 ( given that you can do type 3 filtering ) c) make the non-backbone areas totally stub in order to just have a default route on D, E, F d) run different process and redistribute as you pointed out but it can be tricky if there are some back door link between D/E/F Sina -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay Ravuri Sent: Monday, October 21, 2002 10:58 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF Question Hi, Consider the following topology. A --------B----------C | | | | | | D E F Where A, B, C, D, E, F are routers and A, B, C have interfaces out to each other and to D, E, F respectivley. If I wanted to keep the interfaces between A, B, C private to routers A, B, C. That is, I do not want D, E, F to know about the interfaces that exist between A, B, C but still have D, E, F to reach each other some how. How could I accomplish this with OSPF? One thought I had was perhaps run 2 instances of OSPF on A, B, C. First instance runs between iterfaces on A, B, C and second between A->D, B->E, C->F and advertise the reachability to D, E, F via the interfaces A, B, C and keep the interfaces between A, B, C hidden. Does doing something like this make sense or is there a better to accomplish this. Also, with OSPF how does one differentiate between interfaces on a another node inorder to selectively leak routes? -Vinay ---------------------------------------------------------------------------- -- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site ------=_NextPart_000_00B6_01C27915.7D4B0DA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Vinay
 
by " = not knowing=20 about interface that exist" , do you mean topology wise or even not knowing IP = reachability=20 regarding those interface ?
 
some = option that you=20 have depending on what really you are looking for = ....
 
a) = make link A-B=20 & B-C in area 0 and each other link in a different = area
 
if you = don't want IP=20 information of A-B and B-C to be advertised you can
 
b) = filter on A / B /=20 C the corresponding prefixes belonging to area 0 ( given that you can do = type 3=20 filtering )
c) = make the=20 non-backbone areas totally stub in order to just have a default route on = D, E,=20 F
 
d) run = different=20 process and redistribute as you pointed out but it can be tricky if = there are=20 some back door link between D/E/F
 
Sina
-----Original Message-----
From: Mailing List=20 [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay=20 Ravuri
Sent: Monday, October 21, 2002 10:58 AM
To: = OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF=20 Question

Hi,

   Consider the following topology.


    A --------B----------C
    = |        =20 |            =20 |
    = |        =20 = |            = =20 |
   =20 = D        E    = ;     =20 F

Where A, B, C, D, E, F are routers and A, B, C have interfaces out = to each=20 other and to D, E, F respectivley. 

If I wanted to keep the interfaces between A, B, C private to = routers A, B,=20 C.  That is, I do not want D, E, F to know about the interfaces = that=20 exist between A, B, C but still have D, E, F to reach each other some=20 how.  How could I accomplish this with OSPF?

One thought I had was perhaps run 2 instances of OSPF on A, B, = C. =20 First instance runs between iterfaces on A, B, C and = second between=20 A->D, B->E, C->F and advertise the reachability to = D, E, F=20 via the interfaces A, B, C and keep the interfaces between A, B, C=20 hidden.  Does doing something like this make sense or is there a = better=20 to accomplish this.  Also, with OSPF how does one differentiate = between=20 interfaces on a another node inorder to selectively leak routes?

-Vinay


Do you Yahoo!?
Y! Web = Hosting -=20 Let the expert host your web site ------=_NextPart_000_00B6_01C27915.7D4B0DA0-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 18:55:54 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18277 for ; Mon, 21 Oct 2002 18:55:54 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00785CD8@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 18:58:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 323211 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 18:58:07 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 18:58:07 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl131-17.cisco.com [144.254.57.148]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9LMw5002019 for ; Mon, 21 Oct 2002 15:58:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Mon, 21 Oct 2002 15:58:06 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210212217.SAA11690@bigbird.xebeo.com> Precedence: list Content-Transfer-Encoding: 7bit Rohit, > > This will not require defining anything new, but it does require > being a bit more verbose in dealing with multi-access networks. > If the draft says nothing more, some implementors will likely force two > nodes and others will allow more than two. The two types of > implementations > in the same network will provide surprising and undocumented results. > Adding a small section on the topic is a small price to pay to avoid such > problems down the road. > thanks for the comments, personally I do not see any text in the draft stating that more than two routers on the multi-access network is not allowed as the draft just talk about " reflecting reservation state ". If you think that this need to be explicitly mentioned probably section 2.1 could be rephrased in order to state that TE over multi-access link having more than two attached routers, does not require any additional information to the described document however the reservation state of multi-access links will not be accurately reflected. thanks Sina > > Regards, > --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 19:11:57 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18679 for ; Mon, 21 Oct 2002 19:11:57 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00785CA5@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 19:14:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 323265 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 19:14:10 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 19:14:10 -0400 Received: (qmail 23957 invoked from network); 21 Oct 2002 23:14:10 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 21 Oct 2002 23:14:10 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id TAA26019 for ; Mon, 21 Oct 2002 19:14:10 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210212314.TAA26019@bigbird.xebeo.com> Date: Mon, 21 Oct 2002 19:14:10 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from Sina Mirtorabi of "Mon, 21 Oct 2002 15:58:06 PDT." Precedence: list Hi Sina, Just to clarify a bit more, there are two points here - a) Should more than 2 nodes be allowed on multi-access links or not. b) Be clear about the decision in (a) and reflect it appropriately in the document. WRT (a), I am fine with either approach but prefer the former (at max 2 nodes) as TE with > 2 nodes on the same multi-access links seems a bit un-natural when compared to the two node case. The two node case is well understood and known to work. Have you (or others) implemented OSPF-TE with more than two nodes? Any experiences to share? --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 20:58:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20628 for ; Mon, 21 Oct 2002 20:58:24 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00786160@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 21:00:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 323417 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 21:00:37 -0400 Received: from 66.218.78.159 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 21:00:37 -0400 Received: from [63.103.225.22] by web40702.mail.yahoo.com via HTTP; Mon, 21 Oct 2002 18:00:37 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1880959489-1035248437=:24814" Message-ID: <20021022010037.24875.qmail@web40702.mail.yahoo.com> Date: Mon, 21 Oct 2002 18:00:37 -0700 Reply-To: Mailing List Sender: Mailing List From: Vinay Ravuri Subject: Re: OSPF Question To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list --0-1880959489-1035248437=:24814 Content-Type: text/plain; charset=us-ascii Sina, Thanks you for your reply. I do not want IP reachability between A-B, B-C to be advertised to anyone outside of A, B, C. Your b), is the stub area between A-B, B-C links and advertise default routes out on A-D, B-E, C-F links to reach A, B, C? If so, I think this approach should work. Your c), there will likely be links between D, E, F - Where do you see a problem here? If I am only advertising reachability to A, B, C on A-D, B-E, C-F links. -Viinay Sina Mirtorabi wrote:Vinay by " not knowing about interface that exist" , do you mean topology wise or even not knowing IP reachability regarding those interface ? some option that you have depending on what really you are looking for .... a) make link A-B & B-C in area 0 and each other link in a different area if you don't want IP information of A-B and B-C to be advertised you can b) filter on A / B / C the corresponding prefixes belonging to area 0 ( given that you can do type 3 filtering )c) make the non-backbone areas totally stub in order to just have a default route on D, E, F d) run different process and redistribute as you pointed out but it can be tricky if there are some back door link between D/E/F Sina-----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay Ravuri Sent: Monday, October 21, 2002 10:58 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF Question Hi, Consider the following topology. A --------B----------C | | | | | | D E F Where A, B, C, D, E, F are routers and A, B, C have interfaces out to each other and to D, E, F respectivley. If I wanted to keep the interfaces between A, B, C private to routers A, B, C. That is, I do not want D, E, F to know about the interfaces that exist between A, B, C but still have D, E, F to reach each other some how. How could I accomplish this with OSPF? One thought I had was perhaps run 2 instances of OSPF on A, B, C. First instance runs between iterfaces on A, B, C and second between A->D, B->E, C->F and advertise the reachability to D, E, F via the interfaces A, B, C and keep the interfaces between A, B, C hidden. Does doing something like this make sense or is there a better to accomplish this. Also, with OSPF how does one differentiate between interfaces on a another node inorder to selectively leak routes? -Vinay --------------------------------- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site --------------------------------- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site --0-1880959489-1035248437=:24814 Content-Type: text/html; charset=us-ascii

Sina,

     Thanks you for your reply.  I do not want IP reachability between A-B, B-C to be advertised to anyone outside of A, B, C.  

Your b),  is the stub area between A-B, B-C links and advertise default routes out on A-D, B-E, C-F links to reach A, B, C?  If so, I think this approach should work.

Your c), there will likely be links between D, E, F - Where do you see a problem here?  If I am only advertising reachability to A, B, C on A-D, B-E, C-F links.

-Viinay

 Sina Mirtorabi <sina@CISCO.COM> wrote:

Vinay
 
by " not knowing about interface that exist" , do you mean topology wise or even not knowing IP reachability regarding those interface ?
 
some option that you have depending on what really you are looking for ....
 
a) make link A-B & B-C in area 0 and each other link in a different area
 
if you don't want IP information of A-B and B-C to be advertised you can
 
b) filter on A / B / C the corresponding prefixes belonging to area 0 ( given that you can do type 3 filtering )
c) make the non-backbone areas totally stub in order to just have a default route on D, E, F
 
d) run different process and redistribute as you pointed out but it can be tricky if there are some back door link between D/E/F
 
Sina
-----Original Message-----
From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay Ravuri
Sent: Monday, October 21, 2002 10:58 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF Question

Hi,

   Consider the following topology.


    A --------B----------C
    |         |             |
    |         |             |
    D        E          F

Where A, B, C, D, E, F are routers and A, B, C have interfaces out to each other and to D, E, F respectivley. 

If I wanted to keep the interfaces between A, B, C private to routers A, B, C.  That is, I do not want D, E, F to know about the interfaces that exist between A, B, C but still have D, E, F to reach each other some how.  How could I accomplish this with OSPF?

One thought I had was perhaps run 2 instances of OSPF on A, B, C.  First instance runs between iterfaces on A, B, C and second between A->D, B->E, C->F and advertise the reachability to D, E, F via the interfaces A, B, C and keep the interfaces between A, B, C hidden.  Does doing something like this make sense or is there a better to accomplish this.  Also, with OSPF how does one differentiate between interfaces on a another node inorder to selectively leak routes?

-Vinay


Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site


Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site --0-1880959489-1035248437=:24814-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 22:20:04 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22065 for ; Mon, 21 Oct 2002 22:20:04 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00786516@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 22:22:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 323610 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 22:22:17 -0400 Received: from 192.11.222.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 22:22:17 -0400 Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com [135.252.18.18]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9M2M6E24771 for ; Mon, 21 Oct 2002 22:22:07 -0400 (EDT) Received: by CI0026EXCH001U with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Oct 2002 10:22:04 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Message-ID: <31C0F08B0D18D511ACC800508BAE7B4702B9D0AD@CI0026EXCH001U> Date: Tue, 22 Oct 2002 10:21:55 +0800 Reply-To: Mailing List Sender: Mailing List From: "Li, Ke Qin (Peter)" Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, In my opinion, when there are more than 2 routers on a multi-access link, it is difficult (if not impossible) to define and update Maximum bandwidth, Maximum reservable bandwidth and Unreserved bandwidth between each pair of routers. At the same time, the main concern of MPLS, which is the user of TE LSDB, is point-to-point link. Thus, I think more than 2 nodes on multi-access link should not be allowed. Or even multi-access link should not be described in TE LSAs. Keqin Li > -----Original Message----- > From: Rohit Dube [mailto:rohit@XEBEO.COM] > Sent: Tuesday, October 22, 2002 7:14 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Comments on draft-katz-yeung-traffic-08.txt > > > Hi Sina, > > Just to clarify a bit more, there are two points here - > a) Should more than 2 nodes be allowed on multi-access links or > not. > b) Be clear about the decision in (a) and reflect it appropriately > in the document. > > WRT (a), I am fine with either approach but prefer the former (at max > 2 nodes) as TE with > 2 nodes on the same multi-access links seems > a bit un-natural when compared to the two node case. The two node > case is well understood and known to work. > > Have you (or others) implemented OSPF-TE with more than two nodes? > Any experiences to share? > > --rohit. > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 22:24:34 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22102 for ; Mon, 21 Oct 2002 22:24:34 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00786522@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 22:26:49 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 323639 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 22:26:49 -0400 Received: from 192.11.222.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 22:26:49 -0400 Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com [135.252.18.18]) by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9M2QlE26077 for ; Mon, 21 Oct 2002 22:26:48 -0400 (EDT) Received: by CI0026EXCH001U with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Oct 2002 10:26:46 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="gb2312" Message-ID: <31C0F08B0D18D511ACC800508BAE7B4702B9D0AE@CI0026EXCH001U> Date: Tue, 22 Oct 2002 10:26:39 +0800 Reply-To: Mailing List Sender: Mailing List From: "Li, Ke Qin (Peter)" Subject: Frequency of LS Update Packet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Is there any data about the frequency of LS Update Packet arrival at a OSPF router in an operating network? Thank you. Keqin Li Bell Labs Research China Tel: 86-010-68748088-8438 From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 21 22:57:59 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22735 for ; Mon, 21 Oct 2002 22:57:59 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00786514@cherry.ease.lsoft.com>; Mon, 21 Oct 2002 23:00:14 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 323687 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Oct 2002 23:00:13 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 21 Oct 2002 23:00:13 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl131-17.cisco.com [144.254.57.148]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9M30C006582 for ; Mon, 21 Oct 2002 20:00:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C9_01C2793C.76B187E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Mon, 21 Oct 2002 20:00:11 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPF Question To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021022010037.24875.qmail@web40702.mail.yahoo.com> Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_00C9_01C2793C.76B187E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Vinay Vinay> Your b), is the stub area between A-B, B-C links and advertise default routes out on A-D, B-E, C-F links to reach A, B, C? Vinay> If so, I think this approach should work. I guess you mean c) and not b) , yes totally stub will satisfy your requirement .... Vinay> Your c), there will likely be links between D, E, F - Where do you see a problem here? Vinay> If I am only advertising reachability to A, B, C on A-D, B-E, C-F links you mean d) and not c), if there is a backdoor and D/E/F can exchange reachability without going through A/B/C then you do not need any redistribution. I don't know exactly your topology / requirement but if you are redistributing between multiple process in more than one point you need to be careful, I can send you a paper that I wrote on that.... Sina Sina Mirtorabi wrote: Vinay by " not knowing about interface that exist" , do you mean topology wise or even not knowing IP reachability regarding those interface ? some option that you have depending on what really you are looking for .... a) make link A-B & B-C in area 0 and each other link in a different area if you don't want IP information of A-B and B-C to be advertised you can b) filter on A / B / C the corresponding prefixes belonging to area 0 ( given that you can do type 3 filtering ) c) make the non-backbone areas totally stub in order to just have a default route on D, E, F d) run different process and redistribute as you pointed out but it can be tricky if there are some back door link between D/E/F Sina -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay Ravuri Sent: Monday, October 21, 2002 10:58 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF Question Hi, Consider the following topology. A --------B----------C | | | | | | D E F Where A, B, C, D, E, F are routers and A, B, C have interfaces out to each other and to D, E, F respectivley. If I wanted to keep the interfaces between A, B, C private to routers A, B, C. That is, I do not want D, E, F to know about the interfaces that exist between A, B, C but still have D, E, F to reach each other some how. How could I accomplish this with OSPF? One thought I had was perhaps run 2 instances of OSPF on A, B, C. First instance runs between iterfaces on A, B, C and second between A->D, B->E, C->F and advertise the reachability to D, E, F via the interfaces A, B, C and keep the interfaces between A, B, C hidden. Does doing something like this make sense or is there a better to accomplish this. Also, with OSPF how does one differentiate between interfaces on a another node inorder to selectively leak routes? -Vinay -------------------------------------------------------------------------- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site ---------------------------------------------------------------------------- -- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site ------=_NextPart_000_00C9_01C2793C.76B187E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Vinay
 
Vinay> Your b),  is the stub area between = A-B, B-C=20 links and advertise default routes out on A-D, B-E, C-F links to reach = A, B,=20 C? 
Vinay> If so, I think this approach should = work.=20
 
I = guess you=20 mean c) and not b) , yes totally stub will satisfy your=20 requirement ....
 
Vinay> Your c), there will likely be links between D, E, F - Where do = you see a=20 problem here? 
Vinay> If I am only = advertising=20 reachability to A, B, C on A-D, B-E, C-F = links
 
you=20 mean d) and not c),  if there is a backdoor and D/E/F can exchange = reachability without=20 going through A/B/C then you do not need any=20 redistribution.
 
I don't know = exactly your=20 topology / requirement but if you are redistributing between multiple = process in=20 more than one point you need to be careful, I can send you a paper that = I wrote=20 on that....
 
Sina

 Sina Mirtorabi <sina@CISCO.COM> wrote:=20

Vinay
 
by = " not knowing=20 about interface that exist" , do you mean = topology wise=20 or even not knowing IP reachability regarding those interface=20 ?
 
some option that=20 you have depending on what really you are looking for=20 ....
 
a) = make link A-B=20 & B-C in area 0 and each other link in a different=20 area
 
if = you don't=20 want IP information of A-B and B-C to be advertised you=20 can
 
b) = filter on A /=20 B / C the corresponding prefixes belonging to area 0 ( given that = you can do=20 type 3 filtering )
c) = make the=20 non-backbone areas totally stub in order to just have a default = route on D,=20 E, F
 
d) = run different=20 process and redistribute as you pointed out but it can be tricky if = there=20 are some back door link between D/E/F
 
Sina
-----Original Message-----
From: Mailing List=20 [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay=20 Ravuri
Sent: Monday, October 21, 2002 10:58 = AM
To:=20 OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF=20 Question

Hi,

   Consider the following topology.


    A = --------B----------C
   =20 |        =20 |           =  =20 |
    = |        =20 = |            = =20 |
   =20 = D        E    = ;     =20 F

Where A, B, C, D, E, F are routers and A, B, C have interfaces = out to=20 each other and to D, E, F respectivley. 

If I wanted to keep the interfaces between A, B, C private to = routers=20 A, B, C.  That is, I do not want D, E, F to know about the = interfaces=20 that exist between A, B, C but still have D, E, F to reach each = other some=20 how.  How could I accomplish this with OSPF?

One thought I had was perhaps run 2 instances of OSPF on A, B, = C. =20 First instance runs between iterfaces on A, B, C and = second between=20 A->D, B->E, C->F and advertise the reachability = to D,=20 E, F via the interfaces A, B, C and keep the interfaces between A, = B, C=20 hidden.  Does doing something like this make sense or is = there a=20 better to accomplish this.  Also, with OSPF how does one=20 differentiate between interfaces on a another node inorder to = selectively=20 leak routes?

-Vinay


Do you Yahoo!?
Y! Web=20 Hosting - Let the expert host your web = site


Do you Yahoo!?
Y! Web = Hosting -=20 Let the expert host your web site ------=_NextPart_000_00C9_01C2793C.76B187E0-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 02:27:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06946 for ; Tue, 22 Oct 2002 02:27:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00786BCE@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 2:30:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 324213 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 02:30:03 -0400 Received: from 192.51.44.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 02:30:03 -0400 Received: from m4.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0205-Fujitsu Gateway) id PAA29389 for ; Tue, 22 Oct 2002 15:30:01 +0900 (JST) (envelope-from kashima@nd.net.fujitsu.co.jp) Received: from chisato.nd.net.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.9.3/3.7W-0210-Fujitsu Domain Master) id PAA22247 for ; Tue, 22 Oct 2002 15:30:01 +0900 (JST) (envelope-from kashima@nd.net.fujitsu.co.jp) Received: from localhost (debian.nd.net.fujitsu.co.jp [10.22.113.42]) by chisato.nd.net.fujitsu.co.jp (8.11.6+3.4W/3.7W-chisato-02072615) with ESMTP id g9M6U0V48108 for ; Tue, 22 Oct 2002 15:30:00 +0900 (JST) References: <20021017145911K.kashima@debian.nd.net.fujitsu.co.jp> X-Mailer: Mew version 1.94.2 on Emacs 20.5 / Mule 4.0 (HANANOEN) X-PGP-fingerprint: 2D EB DA CB 42 DE F6 02 10 BC AA 5E CB 35 57 D4 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 31 Message-ID: <20021022153000A.kashima@debian.nd.net.fujitsu.co.jp> Date: Tue, 22 Oct 2002 15:30:00 +0900 Reply-To: Mailing List Sender: Mailing List From: KASHIMA Hiroaki Subject: Re: MD5 interoperability To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021017145911K.kashima@debian.nd.net.fujitsu.co.jp> Precedence: list Content-Transfer-Encoding: 7bit I misconfigured Cisco. I've typed below. Cisco(config-if)# ip ospf message-digest-key 1 md5 hoge ? Cisco(config-if)# ip ospf message-digest-key 1 md5 hoge (ret) This means md5-key "hoge " which includes the tailor space. Below enables authentication. Cisco(config-if)# ip ospf message-digest-key 1 md5 hoge(ret) Thanks. -- KASHIMA, Hiroaki Software Development Deptartment-II, IP Systems Division, Network System Group Subject: MD5 interoperability KASHIMA Hiroaki Said: > Hi. > > Does anyone know Cisco's MD5 connects with other implements? > I'm implementing MD5 for my daemon, which can connect with gated-3.6 > and zebra-0.91a, but cannot connect with cisco 12.2(2)T1. > -- > KASHIMA, Hiroaki > Software Development Deptartment-II, > IP Systems Division, Network System Group From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 08:01:01 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12975 for ; Tue, 22 Oct 2002 08:01:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0078711B@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 8:03:15 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 325348 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 08:03:14 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 08:03:14 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZCBTGA>; Tue, 22 Oct 2002 17:33:35 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06AD133D@haritha.hclt.com> Date: Tue, 22 Oct 2002 17:35:20 +0530 Reply-To: Mailing List Sender: Mailing List From: "Sudharsana V - CTD, Chennai." Subject: Unnumbered To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0002&L=OSPF&D=0&I=-3&P =5059 From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 08:06:29 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13101 for ; Tue, 22 Oct 2002 08:06:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.007870FB@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 8:08:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 325372 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 08:08:43 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 08:08:42 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZCBTJ6>; Tue, 22 Oct 2002 17:39:09 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06AD135E@haritha.hclt.com> Date: Tue, 22 Oct 2002 17:40:54 +0530 Reply-To: Mailing List Sender: Mailing List From: "Sudharsana V - CTD, Chennai." Subject: Sorry -ignore previous mail To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Sorry -ignore previous mail - got sent by mistake. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 09:29:21 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16218 for ; Tue, 22 Oct 2002 09:29:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0078739D@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 9:31:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 325760 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 09:31:35 -0400 Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 09:31:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Message-ID: Date: Tue, 22 Oct 2002 09:31:32 -0400 Reply-To: Mailing List Sender: Mailing List From: Jeff Parker Subject: Re: Frequency of LS Update Packet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > Hi, > > Is there any data about the frequency of LS Update Packet > arrival at a OSPF > router in an operating network? Thank you. > > Keqin Li > Bell Labs Research China > Tel: 86-010-68748088-8438 The English have a pithy saying: "How long is a piece of string?" This is a way of saying "the answer to your question depends on information you haven't provided." How stable are your links? How many links are there? Are you sending TE information? How often is that information updated? - jeff parker - axiowave networks From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 09:44:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17056 for ; Tue, 22 Oct 2002 09:44:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0078736A@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 9:47:08 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 325816 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 09:47:07 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 09:47:07 -0400 Received: from SMIRTORAW2K (par-ilm-dhcp1-vl133-9.cisco.com [144.254.54.204]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g9MDl6000870 for ; Tue, 22 Oct 2002 06:47:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Message-ID: Date: Tue, 22 Oct 2002 06:47:05 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210212314.TAA26019@bigbird.xebeo.com> Precedence: list Content-Transfer-Encoding: 7bit Rohit, > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Rohit > Dube > Sent: Monday, October 21, 2002 4:14 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Comments on draft-katz-yeung-traffic-08.txt > > > Hi Sina, > > Just to clarify a bit more, there are two points here - > a) Should more than 2 nodes be allowed on multi-access links or > not. > b) Be clear about the decision in (a) and reflect it appropriately > in the document. > > WRT (a), I am fine with either approach but prefer the former (at max > 2 nodes) as TE with > 2 nodes on the same multi-access links seems > a bit un-natural when compared to the two node case. The two node > case is well understood and known to work. The current draft does Not prevent TE operation for having more than two routers on multi-acess link. I believe that the accuracy of 'reservation state' on multi-acess link Does Not justify to disallow TE operation in case of more than two routers. when you have a A-B-C-D path and say A-B path goes over multi-acess link, what is un-natural if we have more than two routers attached on A-B or just two ? a link or segment is defined when you connect two point together, so I don't see what is un-natural of course as stated before, it is up to operator to maximize reservation state in order to better reflect the number of attached router on the link. > > Have you (or others) implemented OSPF-TE with more than two nodes? > Any experiences to share? I had a chat with Robert Raszuk and I quote below his thought -- "Yes I agree with both your & Naming's observations and comments to the list. Today it is very often that people start to use TE without any reservations (for one to replace LDP, for second to apply just FRR with not reservations). Also multiaccess topologies are very common in POPs a usual place for the TE heads. Therefor I would highly vote not to tear any TE LSPs when two router multiaccess turns into N router one." -- Sina > > --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 09:46:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17200 for ; Tue, 22 Oct 2002 09:46:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0078746F@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 9:48:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 325836 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 09:48:25 -0400 Received: from 147.188.128.145 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 09:48:25 -0400 Received: from [147.188.128.127] (helo=bham.ac.uk) by sun13.bham.ac.uk with esmtp (Exim 4.10) id 183zOS-0001pw-00 for OSPF@discuss.microsoft.com; Tue, 22 Oct 2002 14:48:24 +0100 Received: from eee-fs7.bham.ac.uk ([147.188.145.131] helo=bham-eee-fs7.bham.ac.uk) by bham.ac.uk with esmtp (Exim 3.36 #1) id 183zOS-00004o-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 14:48:24 +0100 Received: by eee-fs7.bham.ac.uk with Internet Mail Service (5.5.2653.19) id <4D0GFWQJ>; Tue, 22 Oct 2002 14:48:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Message-ID: Date: Tue, 22 Oct 2002 14:48:24 +0100 Reply-To: Mailing List Sender: Mailing List From: "Liu B." Subject: How to partition a routing domain into areas in the first place? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Understanding that the area routing is used in OSPF for better routing performance (e.g., reduce routing cost). But given a large-scale network, how to do partitioning according to the topology of network in the first place? As the topology of most part of the Internet is irregular or mesh, my question, more specifically, is -- how to do partitioning in a given large-scale mesh network? Thanks in advance for any answer, reference or thought. Bin From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 10:10:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18177 for ; Tue, 22 Oct 2002 10:10:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.007874FC@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 10:12:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 325881 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 10:12:40 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 10:12:40 -0400 Received: (qmail 1770 invoked from network); 22 Oct 2002 14:12:39 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 22 Oct 2002 14:12:39 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id KAA23038 for ; Tue, 22 Oct 2002 10:12:39 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210221412.KAA23038@bigbird.xebeo.com> Date: Tue, 22 Oct 2002 10:12:39 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from Sina Mirtorabi of "Tue, 22 Oct 2002 06:47:05 PDT." Precedence: list Sina, On Tue, 22 Oct 2002 06:47:05 -0700 Sina Mirtorabi writes: [snip] =>The current draft does Not prevent TE operation for having more than two =>routers on multi-acess link. It doesn't say it is supported either. =>I believe that the accuracy of 'reservation state' on multi-acess link Does =>Not justify to disallow TE operation in case of more than two routers. Correct. However the operational complexity (compared to just 2 nodes) is adequate reason to consider the cost-benefit trade off allowing this. => =>when you have a A-B-C-D path and say A-B path goes over multi-acess link, =>what is un-natural if we have more than two routers attached on A-B or just =>two ? =>a link or segment is defined when you connect two point together, so I don't =>see what is un-natural Ok let me rephrase. It is not as "straight forward" as the 2 node case. => =>of course as stated before, it is up to operator to maximize reservation =>state in order to better reflect the number of attached router on the link. Correct. And in case it didn't get across before - I am not neccessarily saying this shouldn't be allowed. I am saying (a) there should be adequate justification for this to be allowed and (b) if it is allowed, the operation has to be adequately documented. TE operation over multi-access links with more than 2 nodes is not obvious. So I would rather not leave the part about how nodes are supposed to behave in this case undocumented. => => =>> =>> Have you (or others) implemented OSPF-TE with more than two nodes? =>> Any experiences to share? => => =>I had a chat with Robert Raszuk and I quote below his thought => =>-- =>"Yes I agree with both your & Naming's observations and comments to the =>list. Today it is very often that people start to use TE without any =>reservations (for one to replace LDP, for second to apply just FRR with =>not reservations). Also multiaccess topologies are very common in POPs a =>usual place for the TE heads. Therefor I would highly vote not to tear =>any TE LSPs when two router multiaccess turns into N router one." =>-- This is useful. Thanks for forwarding it. => => =>Sina => =>> =>> --rohit. ___ --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 10:31:52 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19084 for ; Tue, 22 Oct 2002 10:31:52 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.007873FE@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 10:34:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 325971 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 10:34:07 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 10:34:06 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27286 for ; Tue, 22 Oct 2002 10:34:04 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12855 for ; Tue, 22 Oct 2002 10:34:04 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4W8J8NXG>; Tue, 22 Oct 2002 10:34:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763403@vie-msgusr-01.dc.fore.com> Date: Tue, 22 Oct 2002 10:34:03 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Sina, -> when you have a A-B-C-D path and say A-B path goes over -> multi-acess link, what is un-natural if we have more than -> two routers attached on A-B or just two ? very unnatural. MPLS-TE as it stands now considers links characteristics (mostly bw) to do source routing. If you want to do TE without considering any reservations, how are you planning to signal the source computed path ? RSVP-TE as it stands now, is not tailored to run on non-p2p shared medias (neither the label distribution not label signaling are specified in RSVP-TE when more than 2 router are in the LAN). At least, tell me how are you planning to do TE (fine, without any QoS) once you distributed control plane topology information using OSPF ? How will you signal the path once you got the topology info for all the routers (> 2) in broadcast net ? please don't tell me you will do static TE, manual tunnels after all :) We are trying to specify things in routing protocols where there is no support in other modules. Maybe, we are trying to do backward engineering - first specify topology in OSPF-TE then research on how to computer path using CSPF then kludge TE (without QoS, without mapping qos bits to layer 2 headers) then think about how to distribute labels using signaling protocols then think about problems in forwarding plane etc etc - every thing is backward-engineered :) -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 10:50:37 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20285 for ; Tue, 22 Oct 2002 10:50:37 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0078763D@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 10:52:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 326048 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 10:52:53 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 10:52:52 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 2B344F2C43 for ; Tue, 22 Oct 2002 07:52:51 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210180518.g9I5IeV86411@garnet.juniper.net> <3DAF9E35.7080200@redback.com> <1035232857.1320.83.camel@tennali> <3DB4761D.5010504@juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB56603.7030306@redback.com> Date: Tue, 22 Oct 2002 10:51:47 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit All, I think we have a "rough concensus" that the restarting router should NOT try to optimize flooding of grace LSAs. I've only had one vote for this and I believe the vote was more for flooding optimizations in general than this particular scenario. Padma, I don't think it simplifies the helper code (or specification) to apply the grace LSA to all neighbor instances of restarting router. Here are my reasons: 1. Conceptually, I don't think it is right to apply the link local grace LSA to neighbors that are not on the link. 2. There are simply more corner cases - - When you receive a second grace LSA from the restarting router, do you update the reason and grace period for all neighbor instances or only ones on that segment? - When do exit helper mode? Is it when the first grace LSA is withdrawn or all the grace LSAs? I certainly don't think there should be disconnect between entering and exiting helper mode. I do agree that it is somewhat more robust for the case where you are adjacent with the same router on more than one link. However, I don't see this as a real big gain. Has anyone else implemented this draft? Thanks, Acee Padma Pillay-Esnault wrote: > Rajesh > > > Rajesh Varadarajan wrote: > >>Acee, Padma, >> > > > >>>>>>I do think it simplifies things if a restarting router originates the grace LSAs >>>>>>on all it's interfaces (or at least all with full neighbor >>>>>> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>>>>> >>>>>>adjacencies if it a planned restart). >>>>>> > >>>>>> >>>>>> >>>>>> >> >>The above statement seems to imply (my reading) that a restarting router >> >>can only send Grace LSA's out of some (not all) of its interfaces. The >> > It doesn't imply that - clearly we send to all our neighbors. > > Padma > >> >>spec however requires the router to send the grace-lsa out of all >>interfaces on which it has full neigbhors. Failure to do so would always >>result in its helper mode being terminated by others. >> > > >>>>>I also agree with you .. that's what I do - the restarting router sends >>>>>grace lsa over all interfaces. But from a Helping router perspective >>>>>we should do as in 00-txt. It simplifies the helper code. >>>>>It also prevents corner cases where we might not help all adjacencies >>>>>(when we should). >>>>> >>>>>Padma >>>>> >>>> >>>>I haven't heard anyone object to why the 00-txt. >>>> >>> >>>I will - I specifically agree with >>> >>> >>> >>> Note that Router Y only needs to receive a single grace-LSA from >>> X, even if X and Y attach to multiple common segments. >>> >>>I don't like using an LSA with link local scope to enter/terminate >>>helper mode for neighbors on different interfaces. It is better if the >>>link local grace LSA only applies to that link. >>> >> >>Given the behavior above, I think the each neighbor should be considered >>independently on a segment by segment basis. >> >> >>thanks, >>rajesh >> >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 11:18:08 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21476 for ; Tue, 22 Oct 2002 11:18:07 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0078748E@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 11:20:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 326194 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 11:20:23 -0400 Received: from 128.123.15.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 11:20:22 -0400 Received: from nmsu.edu ([128.123.15.221]) by mail.psl.nmsu.edu with Microsoft SMTPSVC(5.0.2195.5329); Tue, 22 Oct 2002 09:20:20 -0600 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2002 15:20:20.0750 (UTC) FILETIME=[88F8C2E0:01C279DE] Message-ID: <3DB56CE1.2030908@nmsu.edu> Date: Tue, 22 Oct 2002 09:21:05 -0600 Reply-To: Mailing List Sender: Mailing List From: Vincent Subject: Re: Highly Connected Network Topologies Comments: To: rfiutem@ix.netcom.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Richard Fiutem wrote: >Vince: > >Where did you obtain John T Moy's OSPF simulation application? If you provide >me with this information, I can forward to you various Cisco OSPF Router >configurations from multimedia enterprise networks. > >Sincerely, > > > >On Mon, 21 Oct 2002 15:16:50 -0600 Vincent wrote: > > > >>I installed John T Moy's OSPF simulation app >>and would like to model >>and simulate "highly connected network >>topologies", unfortunetly I do >>not have much real-world OSPF/Networking >>experience to know what >>topologies would be practical. I would >>appreciate it greatly if someone >>could send me a few examples (please identify >>rtrs w/ ext routes) or an >>URL that would have some 'real-world' examples. >> >>Vince >> >> >> > > > >Richard Fiutem >Harrison Technology, Inc. >Engineering Excellence in Multimedia Enterprise Networking >(v) 513-367-6186 >(f) 513-367-5059 >(p) 800-906-9655 >www.network-diagnosis.net > > > http://www.ospf.org/ From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 12:16:07 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24489 for ; Tue, 22 Oct 2002 12:16:07 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.007878B1@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 12:18:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 326321 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 12:18:23 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 12:18:23 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9MGIMm44233 for ; Tue, 22 Oct 2002 09:18:22 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9MGIMM69156 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 09:18:22 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210221618.g9MGIMM69156@garnet.juniper.net> Date: Tue, 22 Oct 2002 09:18:22 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DB56603.7030306@redback.com> from "Acee Lindem" at Oct 22, 2002 10:51:47 AM Precedence: list Content-Transfer-Encoding: 7bit Acee, > Padma, > > I don't think it simplifies the helper code (or specification) > to apply the grace LSA to all neighbor instances of restarting > router. Here are my reasons: > > 1. Conceptually, I don't think it is right to apply the link > local grace LSA to neighbors that are not on the link. Let's be more precise - we are talking about adjacencies of the restarting router. A grace lsa from router X is received by router Y who has n adjacencies to router X. One grace lsa should apply to the n adjacencies. I beg to differ. Conceptually, the grace lsa is used to signal that a *router* is restarting to its neighbors. The only reason, why we use a link-local lsa is that we have *no* other way to just prevent the lsa from being flooded further by these neighbors. I need to stress again that event being processed is a *router* restart *not* a link restart. Why the need to process that the router X is restarting n times ? By analogy, if one gets 10 copies this email should one answer it 10 times ? ;-) > 2. There are simply more corner cases - > > - When you receive a second grace LSA from the restarting > router, do you update the reason and grace period for > all neighbor instances or only ones on that segment? > The second and consequent ones grace lsas are acknowledged but I do not update the grace period/reason for the simple reason that the restarting router (planned or unplanned) do not change those parameters on the fly. > - When do exit helper mode? Is it when the first grace > LSA is withdrawn or all the grace LSAs? I certainly don't > think there should be disconnect between entering and > exiting helper mode. The first maxaged grace lsa will cause the helper to exit. > > I do agree that it is somewhat more robust for the case where > you are adjacent with the same router on more than one link. > However, I don't see this as a real big gain. Has anyone > else implemented this draft? The big gain ? I think that we expose ourselves to more timing dependencies corner cases by considering a grace lsa per link processing on the helper side. This unnecessary added complexity (per interface) will simply not scale. Thanks Padma > > Thanks, > Acee > > > > Padma Pillay-Esnault wrote: > > > Rajesh > > > > > > Rajesh Varadarajan wrote: > > > >>Acee, Padma, > >> > > > > > > > >>>>>>I do think it simplifies things if a restarting router originates the grace LSAs > >>>>>>on all it's interfaces (or at least all with full neighbor > >>>>>> > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >>>>>> > >>>>>>adjacencies if it a planned restart). > >>>>>> > > > >>>>>> > >>>>>> > >>>>>> > >> > >>The above statement seems to imply (my reading) that a restarting router > >> > >>can only send Grace LSA's out of some (not all) of its interfaces. The > >> > > It doesn't imply that - clearly we send to all our neighbors. > > > > Padma > > > >> > >>spec however requires the router to send the grace-lsa out of all > >>interfaces on which it has full neigbhors. Failure to do so would always > >>result in its helper mode being terminated by others. > >> > > > > > >>>>>I also agree with you .. that's what I do - the restarting router sends > >>>>>grace lsa over all interfaces. But from a Helping router perspective > >>>>>we should do as in 00-txt. It simplifies the helper code. > >>>>>It also prevents corner cases where we might not help all adjacencies > >>>>>(when we should). > >>>>> > >>>>>Padma > >>>>> > >>>> > >>>>I haven't heard anyone object to why the 00-txt. > >>>> > >>> > >>>I will - I specifically agree with > >>> > >>> > >>> > >>> Note that Router Y only needs to receive a single grace-LSA from > >>> X, even if X and Y attach to multiple common segments. > >>> > >>>I don't like using an LSA with link local scope to enter/terminate > >>>helper mode for neighbors on different interfaces. It is better if the > >>>link local grace LSA only applies to that link. > >>> > >> > >>Given the behavior above, I think the each neighbor should be considered > >>independently on a segment by segment basis. > >> > >> > >>thanks, > >>rajesh > >> > >> > > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 13:43:46 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27926 for ; Tue, 22 Oct 2002 13:43:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00787C16@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 13:45:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 326812 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 13:45:59 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 13:45:59 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HPCFY>; Tue, 22 Oct 2002 13:45:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 22 Oct 2002 13:48:14 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee, I agree to Padma's statement that we are using link-local LSA to signal hitless-restart, because we would not want the LSA to be flooded by the neighbors into the area. We are signalling router parameters in the link local LSA. Regarding 2. - I think we should update the grace-period/reason only when we have a change in content of the Grace LSA from the neighbor to the restarting router on any interface. So if we get a different value of grace-period/restart reason we update and restart the grace period on the helper else we do not. This would be in keeping with Section 3 of the draft. - I think the first grace LSA withdrawn would cause the router to exit hitless restart mode for that neighbor. Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Tuesday, October 22, 2002 8:22 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Hitless restart All, I think we have a "rough concensus" that the restarting router should NOT try to optimize flooding of grace LSAs. I've only had one vote for this and I believe the vote was more for flooding optimizations in general than this particular scenario. Padma, I don't think it simplifies the helper code (or specification) to apply the grace LSA to all neighbor instances of restarting router. Here are my reasons: 1. Conceptually, I don't think it is right to apply the link local grace LSA to neighbors that are not on the link. 2. There are simply more corner cases - - When you receive a second grace LSA from the restarting router, do you update the reason and grace period for all neighbor instances or only ones on that segment? - When do exit helper mode? Is it when the first grace LSA is withdrawn or all the grace LSAs? I certainly don't think there should be disconnect between entering and exiting helper mode. I do agree that it is somewhat more robust for the case where you are adjacent with the same router on more than one link. However, I don't see this as a real big gain. Has anyone else implemented this draft? Thanks, Acee Padma Pillay-Esnault wrote: > Rajesh > > > Rajesh Varadarajan wrote: > >>Acee, Padma, >> > > > >>>>>>I do think it simplifies things if a restarting router originates the grace LSAs >>>>>>on all it's interfaces (or at least all with full neighbor >>>>>> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >>>>>> >>>>>>adjacencies if it a planned restart). >>>>>> > >>>>>> >>>>>> >>>>>> >> >>The above statement seems to imply (my reading) that a restarting router >> >>can only send Grace LSA's out of some (not all) of its interfaces. The >> > It doesn't imply that - clearly we send to all our neighbors. > > Padma > >> >>spec however requires the router to send the grace-lsa out of all >>interfaces on which it has full neigbhors. Failure to do so would always >>result in its helper mode being terminated by others. >> > > >>>>>I also agree with you .. that's what I do - the restarting router sends >>>>>grace lsa over all interfaces. But from a Helping router perspective >>>>>we should do as in 00-txt. It simplifies the helper code. >>>>>It also prevents corner cases where we might not help all adjacencies >>>>>(when we should). >>>>> >>>>>Padma >>>>> >>>> >>>>I haven't heard anyone object to why the 00-txt. >>>> >>> >>>I will - I specifically agree with >>> >>> >>> >>> Note that Router Y only needs to receive a single grace-LSA from >>> X, even if X and Y attach to multiple common segments. >>> >>>I don't like using an LSA with link local scope to enter/terminate >>>helper mode for neighbors on different interfaces. It is better if the >>>link local grace LSA only applies to that link. >>> >> >>Given the behavior above, I think the each neighbor should be considered >>independently on a segment by segment basis. >> >> >>thanks, >>rajesh >> >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 14:42:11 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29919 for ; Tue, 22 Oct 2002 14:42:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.007880A1@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 14:44:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 327063 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 14:44:24 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 14:44:24 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 572E2F2C42 for ; Tue, 22 Oct 2002 11:44:21 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210221618.g9MGIMM69156@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB59C43.2010703@redback.com> Date: Tue, 22 Oct 2002 14:43:15 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma, Let's see what others have to say. I can certainly write write/test running code faster than these protracted E-mail discussions but I'd like to see some real support prior to changing the existing specification. Also I don't agree with some of your arguments - especially the one relating to scaling - comments inline. Padma Pillay-Esnault wrote: > Acee, > > >>Padma, >> >>I don't think it simplifies the helper code (or specification) >>to apply the grace LSA to all neighbor instances of restarting >>router. Here are my reasons: >> >> 1. Conceptually, I don't think it is right to apply the link >> local grace LSA to neighbors that are not on the link. >> > > Let's be more precise - we are talking about adjacencies of the restarting > router. A grace lsa from router X is received by router Y who has n > adjacencies to router X. One grace lsa should apply to the n adjacencies. > > I beg to differ. Conceptually, the grace lsa is used to signal that > a *router* is restarting to its neighbors. The only reason, why we use > a link-local lsa is that we have *no* other way to just prevent the lsa > from being flooded further by these neighbors. > > I need to stress again that event being processed is a *router* restart > *not* a link restart. > > Why the need to process that the router X is restarting n times ? > By analogy, if one gets 10 copies this email should one answer > it 10 times ? ;-) Poor analogy. These are, in fact, different LSAs which will even have different contents on some links. > > >> 2. There are simply more corner cases - >> >> - When you receive a second grace LSA from the restarting >> router, do you update the reason and grace period for >> all neighbor instances or only ones on that segment? >> >> > > The second and consequent ones grace lsas are acknowledged but I do not > update the grace period/reason for the simple reason that the restarting > router (planned or unplanned) do not change those parameters on the fly. I think if we do go this way, we should use the latest information. Did you consider the case there is a stale link local LSA? > > > >> - When do exit helper mode? Is it when the first grace >> LSA is withdrawn or all the grace LSAs? I certainly don't >> think there should be disconnect between entering and >> exiting helper mode. >> > > The first maxaged grace lsa will cause the helper to exit. > > >>I do agree that it is somewhat more robust for the case where >>you are adjacent with the same router on more than one link. >>However, I don't see this as a real big gain. Has anyone >>else implemented this draft? >> > > The big gain ? > > I think that we expose ourselves to more timing dependencies corner cases > by considering a grace lsa per link processing on the helper side. Can you be more precise? > > This unnecessary added complexity (per interface) will simply not scale. Don't buy this argument. If anything, processing helper adjacencies incrementally as the existing draft recommends is more scalable. Additionally, the helper only has to search through the neighbor adjacencies on the link versus the potentially thousands associated with the routing domain. > > > Thanks > > Padma > > >>Thanks, >>Acee >> >> >> >>Padma Pillay-Esnault wrote: >> >> >>>Rajesh >>> >>> >>>Rajesh Varadarajan wrote: >>> >>> >>>>Acee, Padma, >>>> >>>> >>> >>> >>>>>>>>I do think it simplifies things if a restarting router originates the grace LSAs >>>>>>>>on all it's interfaces (or at least all with full neighbor >>>>>>>> >>>>>>>> >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> >>>>>>>>adjacencies if it a planned restart). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>The above statement seems to imply (my reading) that a restarting router >>>> >>>>can only send Grace LSA's out of some (not all) of its interfaces. The >>>> >>>> >>>It doesn't imply that - clearly we send to all our neighbors. >>> >>>Padma >>> >>> >>>>spec however requires the router to send the grace-lsa out of all >>>>interfaces on which it has full neigbhors. Failure to do so would always >>>>result in its helper mode being terminated by others. >>>> >>>> >>> >>> >>>>>>>I also agree with you .. that's what I do - the restarting router sends >>>>>>>grace lsa over all interfaces. But from a Helping router perspective >>>>>>>we should do as in 00-txt. It simplifies the helper code. >>>>>>>It also prevents corner cases where we might not help all adjacencies >>>>>>>(when we should). >>>>>>> >>>>>>>Padma >>>>>>> >>>>>>> >>>>>>I haven't heard anyone object to why the 00-txt. >>>>>> >>>>>> >>>>>I will - I specifically agree with >>>>> >>>>> >>>>> >>>>> Note that Router Y only needs to receive a single grace-LSA from >>>>> X, even if X and Y attach to multiple common segments. >>>>> >>>>>I don't like using an LSA with link local scope to enter/terminate >>>>>helper mode for neighbors on different interfaces. It is better if the >>>>>link local grace LSA only applies to that link. >>>>> >>>>> >>>>Given the behavior above, I think the each neighbor should be considered >>>>independently on a segment by segment basis. >>>> >>>> >>>>thanks, >>>>rajesh >>>> >>>> >>>> >> >>-- >>Acee >> >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 14:48:29 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00164 for ; Tue, 22 Oct 2002 14:48:29 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.007881CC@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 14:50:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 327199 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 14:50:44 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 14:50:44 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id AB232F2C42 for ; Tue, 22 Oct 2002 11:50:42 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB59DC1.6030608@redback.com> Date: Tue, 22 Oct 2002 14:49:37 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: > Hi Acee, > > I agree to Padma's statement that we are using link-local LSA to signal > hitless-restart, because we would not want the LSA to be flooded by the > neighbors into the area. We are signalling router parameters in the link > local LSA. > > Regarding 2. > - I think we should update the grace-period/reason only when we have a > change in content of the Grace LSA from the neighbor to the restarting > router on any interface. So if we get a different value of > grace-period/restart reason we update and restart the grace period on the > helper else we do not. This would be in keeping with Section 3 of the draft. Vishwas, I agree that if we do agree to change the existing specification than we should, in fact, honor changes to the grace-period/restart-reason. One of my concerns with this approach is the added complexity (consider determining which of multiple link local LSAs received on different links is more recent). Thanks, Acee > - I think the first grace LSA withdrawn would cause the router to exit > hitless restart mode for that neighbor. > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, October 22, 2002 8:22 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Hitless restart > > > All, > > I think we have a "rough concensus" that the restarting router > should NOT try to optimize flooding of grace LSAs. I've > only had one vote for this and I believe the vote was more > for flooding optimizations in general than this particular > scenario. > > > Padma, > > I don't think it simplifies the helper code (or specification) > to apply the grace LSA to all neighbor instances of restarting > router. Here are my reasons: > > 1. Conceptually, I don't think it is right to apply the link > local grace LSA to neighbors that are not on the link. > > 2. There are simply more corner cases - > > - When you receive a second grace LSA from the restarting > router, do you update the reason and grace period for > all neighbor instances or only ones on that segment? > > - When do exit helper mode? Is it when the first grace > LSA is withdrawn or all the grace LSAs? I certainly don't > think there should be disconnect between entering and > exiting helper mode. > > I do agree that it is somewhat more robust for the case where > you are adjacent with the same router on more than one link. > However, I don't see this as a real big gain. Has anyone > else implemented this draft? > > Thanks, > Acee > > > > Padma Pillay-Esnault wrote: > > >>Rajesh >> >> >>Rajesh Varadarajan wrote: >> >> >>>Acee, Padma, >>> >>> >> >> >>>>>>>I do think it simplifies things if a restarting router originates the >>>>>>> > grace LSAs > >>>>>>>on all it's interfaces (or at least all with full neighbor >>>>>>> >>>>>>> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >>>>>>>adjacencies if it a planned restart). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>The above statement seems to imply (my reading) that a restarting router >>> >>>can only send Grace LSA's out of some (not all) of its interfaces. The >>> >>> >>It doesn't imply that - clearly we send to all our neighbors. >> >>Padma >> >> >>>spec however requires the router to send the grace-lsa out of all >>>interfaces on which it has full neigbhors. Failure to do so would always >>>result in its helper mode being terminated by others. >>> >>> >> >> >>>>>>I also agree with you .. that's what I do - the restarting router sends >>>>>>grace lsa over all interfaces. But from a Helping router perspective >>>>>>we should do as in 00-txt. It simplifies the helper code. >>>>>>It also prevents corner cases where we might not help all adjacencies >>>>>>(when we should). >>>>>> >>>>>>Padma >>>>>> >>>>>> >>>>>I haven't heard anyone object to why the 00-txt. >>>>> >>>>> >>>>I will - I specifically agree with >>>> >>>> >>>> >>>> Note that Router Y only needs to receive a single grace-LSA from >>>> X, even if X and Y attach to multiple common segments. >>>> >>>>I don't like using an LSA with link local scope to enter/terminate >>>>helper mode for neighbors on different interfaces. It is better if the >>>>link local grace LSA only applies to that link. >>>> >>>> >>>Given the behavior above, I think the each neighbor should be considered >>>independently on a segment by segment basis. >>> >>> >>>thanks, >>>rajesh >>> >>> >>> > > > -- > Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 15:00:56 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00716 for ; Tue, 22 Oct 2002 15:00:56 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.007884D4@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 15:03:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 327219 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 15:03:11 -0400 Received: from 147.11.1.11 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 14:53:10 -0400 Received: from YOWDKECSKEM (dkecskem.wrs.com [10.34.2.8]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id LAA28798 for ; Tue, 22 Oct 2002 11:52:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Tue, 22 Oct 2002 14:51:21 -0400 Reply-To: Mailing List Sender: Mailing List From: Delia Kecskemeti Subject: DR / BDR election on different links configured as on same subnet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, I need to find out how is OSPF supposed to act in this particular case: Link between routers R1 and R2 and link between R2 and R3 are configured to be on the same subnet, say: a.b.c.x / 24 In my understanding, the DR / BDR mechanism is applied on one broadcast link to which several routers attach, to minimize number of adjacencies and network burden on that link. Should DR and BDR mechanism be also applied to this scenario, that is R1, R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. Therefore if R1 and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to both links, in order to reach both DR and BDR? In my opinion it should not. I am told that it should, as this would be a particular case of OSPF support for layer 2 switching. Is there some specification in an RFC about this? R1-----------R2-----------R3 Thank you very much and have a nice day, Delia From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 15:46:43 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02093 for ; Tue, 22 Oct 2002 15:46:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.007889E8@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 15:48:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 327828 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 15:48:57 -0400 Received: from 207.159.120.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 15:48:57 -0400 Received: by xprdmailfe27.nwk.excite.com (Postfix, from userid 110) id 4345C3A24; Tue, 22 Oct 2002 15:48:53 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe27.nwk.excite.com via HTTP; Tue, 22 Oct 2002 15:48:53 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20021022194853.4345C3A24@xprdmailfe27.nwk.excite.com> Date: Tue, 22 Oct 2002 15:48:53 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: DR / BDR election on different links configured as on same subnet Comments: cc: delia.kecskemeti@WINDRIVER.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Box B should not allow the same subnet to be configured on two different links. However, since DR election is on a per-interface basis, not on a strictly per-subnet basis, DR election would be done independantly on each link (aka interface). LSA flooding, etc. would be done as if the interfaces were on two different subnets. SPF calculations are another matter entirely, and as such, routing will not occur between the two links. If Box B is really a Layer-2 switch that has an OSPF interface on it's "VLAN" that both ports are assigned to, well that's a different scenario that you did not describe in your picture. Let us know if that's the case. -don --- On Tue 10/22, Delia Kecskemeti wrote: From: Delia Kecskemeti [mailto: delia.kecskemeti@WINDRIVER.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Tue, 22 Oct 2002 14:51:21 -0400 Subject: DR / BDR election on different links configured as on same subnet > Hi, > > I need to find out how is OSPF supposed to act in this particular case: > Link between routers R1 and R2 and link between R2 and R3 are configured > to > be on the same subnet, say: > a.b.c.x / 24 > In my understanding, the DR / BDR mechanism is applied on one broadcast > link > to which several routers attach, to minimize number of adjacencies and > network burden on that link. > > Should DR and BDR mechanism be also applied to this scenario, that is R1, > R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. Therefore if > R1 > and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to > both > links, in order to reach both DR and BDR? In my opinion it should not. I > am > told that it should, as this would be a particular case of OSPF support > for > layer 2 switching. Is there some specification in an RFC about this? > > R1-----------R2-----------R3 > > Thank you very much and have a nice day, > Delia > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 16:08:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02590 for ; Tue, 22 Oct 2002 16:08:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.007889AC@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 16:11:08 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 328102 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 16:11:08 -0400 Received: from 207.159.120.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 16:11:08 -0400 Received: by xprdmailfe27.nwk.excite.com (Postfix, from userid 110) id 9402639FA; Tue, 22 Oct 2002 16:11:03 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe27.nwk.excite.com via HTTP; Tue, 22 Oct 2002 16:11:03 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20021022201103.9402639FA@xprdmailfe27.nwk.excite.com> Date: Tue, 22 Oct 2002 16:11:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: DR / BDR election on different links configured as on same subnet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Box B being the R2 in the diagram. Doing it by memory, I labelled them A--B--C. -don --- On Tue 10/22, Don Goodspeed wrote: From: Don Goodspeed [mailto: dgoodspe@EXCITE.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Tue, 22 Oct 2002 15:48:53 -0400 Subject: Re: DR / BDR election on different links configured as on same subnet > Box B should not allow the same subnet to be configured on two > different links. However, since DR election is on a per-interface > basis, not on a strictly per-subnet basis, DR election would > be done independantly on each link (aka interface). LSA flooding, > etc. would be done as if the interfaces were on two different > subnets. SPF calculations are another matter entirely, and > as such, routing will not occur between the two links. > > If Box B is really a Layer-2 switch that has an OSPF interface > on it's "VLAN" that both ports are assigned to, well that's > a different scenario that you did not describe in your picture. > Let us know if that's the case. > > -don > > --- On Tue 10/22, Delia Kecskemeti wrote: > From: Delia Kecskemeti [mailto: delia.kecskemeti@WINDRIVER.COM] > To: OSPF@DISCUSS.MICROSOFT.COM > Date: Tue, 22 Oct 2002 14:51:21 -0400 > Subject: DR / BDR election on different links configured as on same > subnet > > > Hi, > > > > I need to find out how is OSPF supposed to act in this particular > case: > > Link between routers R1 and R2 and link between R2 and R3 are > configured > > to > > be on the same subnet, say: > > a.b.c.x / 24 > > In my understanding, the DR / BDR mechanism is applied on one > broadcast > > link > > to which several routers attach, to minimize number of adjacencies > and > > network burden on that link. > > > > Should DR and BDR mechanism be also applied to this scenario, that is > R1, > > R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. Therefore > if > > R1 > > and R3 are the DR and BDR, then R2 would duplicate sending of PDUs > to > > both > > links, in order to reach both DR and BDR? In my opinion it should > not. I > > am > > told that it should, as this would be a particular case of OSPF > support > > for > > layer 2 switching. Is there some specification in an RFC about this? > > > > R1-----------R2-----------R3 > > > > Thank you very much and have a nice day, > > Delia > > > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 16:27:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03325 for ; Tue, 22 Oct 2002 16:27:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00788A7E@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 16:29:47 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 328222 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 16:29:47 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 16:29:47 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 43E2D449A2C; Tue, 22 Oct 2002 13:29:45 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20021017131430.M37850-100000@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB5B4F6.9060409@redback.com> Date: Tue, 22 Oct 2002 16:28:38 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-katz-yeung-traffic-08.txt Comments: To: IETF CCAMP WG To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kireeti, Can we close on the remaining issues? 1. With respect to the Remote Interface IP Addres TLV, is there really any reason to include it with a value of 0.0.0.0 for a multi-access link? I can't see how there could be a compatibility issue since the rough count on the list revealed more implementations that omitted the TLV altogether. 2. With respect to more than two routers on a multi-access network, it seems there is considerable support for allowing this even though it is not fully specified. Could you add something along these lines to the second paragraph of the limitations section: "Operation over multiaccess links with more than two devices is not specifically prohibited. TE operation and the use of reservation state is a matter for further study". Thanks, Acee Kireeti Kompella wrote: > Hi Acee, > > On Thu, 17 Oct 2002, Acee Lindem wrote: > > >>Comments: >> >> - The LSA Header Diagram in section 2.3.1 does not reflect >> the fact that the instance has been extended to 24 bits. >> > > Thanks. Someone else also pointed this out. > > >> - Section 2.4.1 - Replace "but for obvious reasons this..." >> with "but this nomenclature is avoid here since the >> OSPF router ID is not necessarily a routable address." >> > > Any objections? If not, I will make this change. > > >> - Section 2.5.4 - Why 0.0.0.0 for the remote address for >> multiaccess links? It seems the TLV should either be >> omitted or set to the single neighbor address (since >> section 1.2 limits traffic engineering to multiaccess >> networks with 2 devices). >> > > While this document doesn't work ideally for multipoint links with > more that 2 devices, it is used. Also, this has been implemented > and is running code, so changing the spec to omitting this TLV at > this point would cause more problems than it would solve. > > >>Suggestion: >> >> - Include "Implications on Graceful Restart" section >> similar to draft-ietf-ccamp-ospf-gmpls-extensions-08.txt. >> Explicitly state that the goal is to maintain >> existing traffic engineered paths while discouraging >> any new ones until reservation state is obtained. >> > > Instead, how about specifying explicitly in the ospf gmpls draft > that the text there applies to the base TE doc as well as the GMPLS > extensions? Otherwise, draft-katz-yeung-traffic-08.txt will need > the graceful restart doc as a normative reference. Note that the > TE doc has been around for many years, with interoperable > implementations etc., while graceful restart for OSPF much more recent. > > BTW, can we start to progress the graceful restart (aka hitless > restart) document? There are interoperable implementations now, and > while this doc is not as mature as TE, it certainly seems ready .... > > Kireeti. > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 17:08:18 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04635 for ; Tue, 22 Oct 2002 17:08:18 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00788FE1@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 17:10:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 328543 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 17:10:31 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 17:10:31 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9MLAUm74366 for ; Tue, 22 Oct 2002 14:10:30 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g9MLAUe57861 for ; Tue, 22 Oct 2002 14:10:30 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20021022134012.V57745-100000@kummer.juniper.net> Date: Tue, 22 Oct 2002 14:10:30 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DB5B4F6.9060409@redback.com> Precedence: list Hi Acee, On Tue, 22 Oct 2002, Acee Lindem wrote: > Can we close on the remaining issues? I have a question. Last Call (for the nth time) finished on Oct 14. Is there ever an end to this process? > 1. With respect to the Remote Interface IP Addres TLV, is > there really any reason to include it with a value of 0.0.0.0 > for a multi-access link? I can't see how there could be > a compatibility issue since the rough count on the list > revealed more implementations that omitted the TLV > altogether. This is a nitpick. Is there a real problem being solved here? It's been specified, perhaps not optimally, but wasting 4 bytes is not a burning issue. Besides, the memo doesn't say that the Remote Address TLV is mandatory. As you say, some implementations use this, some skip this, and they all interoperate. I really would prefer not to make any changes here unless there is a good reason. > 2. With respect to more than two routers on a multi-access > network, it seems there is considerable support for > allowing this even though it is not fully specified. > Could you add something along these lines to the second > paragraph of the limitations section: > > "Operation over multiaccess links with more than two > devices is not specifically prohibited. TE operation > and the use of reservation state is a matter for > further study". Another nitpick. The current text states that "The reservation state of multiaccess links is not accurately reflected" ... what the new wording accomplish? The current text does not prohibit use if there are more than two devices; it states the limitations. However, if you think that the new wording is preferable, I will change this to "Operation over multiaccess links with more than two devices is not specifically prohibited. More accurate description of the reservation state of multi-access networks is for further study." The change I'll make for sure is updating the figure in 2.3.1. Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 17:32:23 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05360 for ; Tue, 22 Oct 2002 17:32:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0078909B@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 17:34:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 328626 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 17:34:39 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 17:34:38 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id A84F31DCC74 for ; Tue, 22 Oct 2002 14:34:36 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20021022134012.V57745-100000@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB5C429.9000100@redback.com> Date: Tue, 22 Oct 2002 17:33:29 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kireeti Kompella wrote: > Hi Acee, Hi Kireeti, > > On Tue, 22 Oct 2002, Acee Lindem wrote: > > >>Can we close on the remaining issues? >> > > I have a question. Last Call (for the nth time) finished on Oct 14. > Is there ever an end to this process? I don't expect to have any comments on IETF wide last call. > > >> 1. With respect to the Remote Interface IP Addres TLV, is >> there really any reason to include it with a value of 0.0.0.0 >> for a multi-access link? I can't see how there could be >> a compatibility issue since the rough count on the list >> revealed more implementations that omitted the TLV >> altogether. >> > > This is a nitpick. Have you ever met a programmer who didn't? > Is there a real problem being solved here? It's > been specified, perhaps not optimally, but wasting 4 bytes is not a > burning issue. Besides, the memo doesn't say that the Remote Address > TLV is mandatory. As you say, some implementations use this, some skip > this, and they all interoperate. > > I really would prefer not to make any changes here unless there is a > good reason. I was just thinking that a document going to proposed standard would be better served with a single way of handling multi-access links. If I'm the only one with this concern then I'll relent. > > >> 2. With respect to more than two routers on a multi-access >> network, it seems there is considerable support for >> allowing this even though it is not fully specified. >> Could you add something along these lines to the second >> paragraph of the limitations section: >> >> "Operation over multiaccess links with more than two >> devices is not specifically prohibited. TE operation >> and the use of reservation state is a matter for >> further study". >> > > Another nitpick. The current text states that "The reservation > state of multiaccess links is not accurately reflected" ... what > the new wording accomplish? The current text does not prohibit > use if there are more than two devices; it states the limitations. > > However, if you think that the new wording is preferable, I will > change this to "Operation over multiaccess links with more than two > devices is not specifically prohibited. More accurate description of > the reservation state of multi-access networks is for further study." There was considerable discussion on this topic and I believe this a good addition. > > The change I'll make for sure is updating the figure in 2.3.1. > > Kireeti. > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 17:43:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05676 for ; Tue, 22 Oct 2002 17:43:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00788EDC@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 17:45:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 328662 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 17:45:34 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 17:45:34 -0400 Received: (qmail 11533 invoked from network); 22 Oct 2002 21:45:33 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 22 Oct 2002 21:45:33 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id RAA26461 for ; Tue, 22 Oct 2002 17:45:33 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210222145.RAA26461@bigbird.xebeo.com> Date: Tue, 22 Oct 2002 17:45:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from Acee Lindem of "Tue, 22 Oct 2002 17:33:29 EDT." <3DB5C429.9000100@redback.com> Precedence: list Kireeti, On Tue, 22 Oct 2002 17:33:29 -0400 Acee Lindem writes: =>>> 1. With respect to the Remote Interface IP Addres TLV, is =>>> there really any reason to include it with a value of 0.0.0.0 =>>> for a multi-access link? I can't see how there could be =>>> a compatibility issue since the rough count on the list =>>> revealed more implementations that omitted the TLV =>>> altogether. =>>> =>> =>> This is a nitpick. => => =>Have you ever met a programmer who didn't? => =>> Is there a real problem being solved here? It's =>> been specified, perhaps not optimally, but wasting 4 bytes is not a =>> burning issue. Besides, the memo doesn't say that the Remote Address =>> TLV is mandatory. As you say, some implementations use this, some skip =>> this, and they all interoperate. =>> =>> I really would prefer not to make any changes here unless there is a =>> good reason. => => =>I was just thinking that a document going to proposed standard would =>be better served with a single way of handling multi-access links. If =>I'm the only one with this concern then I'll relent. [snip] I think the clarification is worth making - it is a small addition in terms of the actual edit but it serves to warn an implementor to be "liberal" in accepting this TLV. Something like "For multi-access networks, the remote-ip TLV can be omitted or the remote-ip set to 0.0.0.0". (This was previously suggested on the mailing list). Regards, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 22 23:41:56 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13931 for ; Tue, 22 Oct 2002 23:41:56 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00789AA7@cherry.ease.lsoft.com>; Tue, 22 Oct 2002 23:44:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 329643 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 22 Oct 2002 23:44:10 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 22 Oct 2002 23:44:10 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) id <0H4F00M011BYFE@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 12:50:22 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H4F00L7F1BYYQ@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 12:50:22 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0H4F00G8H1D05L@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 12:51:02 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=windows-1255 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Message-ID: <022301c27a46$3940e990$b4036c6b@sisodomain.com> Date: Wed, 23 Oct 2002 09:12:33 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: How to partition a routing domain into areas in the first place? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Liu, OSPF has 2 level hierarchy (core and areas hanging off the core) while the networks have 3 level (core, distribution and access) so there can be some confusion in mapping OSPF onto real live networks. There is this book "Advanced IP Network Design" by Alvaro Retana, Don Slice and Russ White (ISBN 1-57870-097-3 - Cisco Press) which discusses OSPF Network Design in some detail by considering ways to divide the network into areas, points where summarization can be done, issues with dial backup and ways to handle dial-in-clients/external connections to the network, etc. It may help you in clarifying some of your doubts. Regards, Manav ----- Original Message ----- From: "Liu B." To: Sent: Tuesday, October 22, 2002 7:18 PM Subject: How to partition a routing domain into areas in the first place? > Hi, > > Understanding that the area routing is used in OSPF for better routing > performance (e.g., reduce routing cost). But given a large-scale network, > how to do partitioning according to the topology of network in the first > place? As the topology of most part of the Internet is irregular or mesh, my > question, more specifically, is -- how to do partitioning in a given > large-scale mesh network? > > Thanks in advance for any answer, reference or thought. > > Bin From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 03:14:38 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10265 for ; Wed, 23 Oct 2002 03:14:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0078A2ED@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 3:16:52 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330065 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 03:16:51 -0400 Received: from 192.11.226.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 03:16:51 -0400 Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com [135.252.18.18]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9N7Gos05013 for ; Wed, 23 Oct 2002 03:16:50 -0400 (EDT) Received: by CI0026EXCH001U with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Oct 2002 15:16:46 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="gb2312" Message-ID: <31C0F08B0D18D511ACC800508BAE7B4702B9D0B7@CI0026EXCH001U> Date: Wed, 23 Oct 2002 15:16:45 +0800 Reply-To: Mailing List Sender: Mailing List From: "Li, Ke Qin (Peter)" Subject: Re: Frequency of LS Update Packet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I know the answer of my question depends on these and some other information, such as, the scale of network. And all these information depends on specific network. So, the goal of asking this question is to acquire these information in a (typical? common?) network in operation. Keqin Li > -----Original Message----- > From: Jeff Parker [mailto:jparker@AXIOWAVE.COM] > Sent: Tuesday, October 22, 2002 9:32 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Frequency of LS Update Packet > > > > Hi, > > > > Is there any data about the frequency of LS Update Packet > > arrival at a OSPF > > router in an operating network? Thank you. > > > > Keqin Li > > Bell Labs Research China > > Tel: 86-010-68748088-8438 > > The English have a pithy saying: > > "How long is a piece of string?" > > This is a way of saying "the answer > to your question depends on information > you haven't provided." > > How stable are your links? How many links > are there? Are you sending TE information? > How often is that information updated? > > - jeff parker > - axiowave networks > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 03:27:30 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10375 for ; Wed, 23 Oct 2002 03:27:30 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0078A310@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 3:29:45 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330143 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 03:29:45 -0400 Received: from 198.152.13.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 03:29:45 -0400 Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20319 for ; Wed, 23 Oct 2002 03:27:32 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20309 for ; Wed, 23 Oct 2002 03:27:31 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27A65.F40B3386" Thread-Topic: area-border router's behaviour Thread-Index: AcJ6ZeDeCCVnL7UhQrKc6H8UtUI6FA== Message-ID: Date: Wed, 23 Oct 2002 09:29:42 +0200 Reply-To: Mailing List Sender: Mailing List From: "Kostiner, Assaf (Assaf)" Subject: area-border router's behaviour To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C27A65.F40B3386 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, There are couple of issues i can't understand: 1. In RFC an area-border router (ABR) is defined as one that is attached = to multiple areas, while Cisco and IBM defined later ABR as one that is = physically or virtually connected to the backbone. I understand theire = reason for changing the RFC definition. What i don't understand, is why = does the RFC allows a router which is connected for example only to = areas 1 and 2, to be an ABR, and to advertise summaries from one to the = other. This router is allowed to use only summaries received from area = 0, when running SPF, so what's the point? 2. Overlapping area ranges - in RFC 1583, an ABR which aggregates all = subnets of 10.0.0.0/8 ignores summaries which fall into this range, like = 8.3.0.0/16. That's why, any such subnet outside the aggregated area will = become unreachable. Why does the ABR ignores all such summaries. If it = didn't ignore them, all subnets could be reachable... I would appreciate any help, Assaf.=20 ------_=_NextPart_001_01C27A65.F40B3386 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable area-border router's behaviour

Hi,

There are couple of issues i = can't understand:

1. In RFC an area-border = router (ABR) is defined as one that is attached to multiple areas, while = Cisco and IBM defined later ABR as one that is physically or virtually = connected to the backbone. I understand theire reason for changing the = RFC definition. What i don't understand, is why does the RFC allows a = router which is connected for example only to areas 1 and 2, to be an = ABR, and to advertise summaries from one to the other. This router is = allowed to use only summaries received from area 0, when running SPF, so = what's the point?

2. Overlapping area ranges - = in RFC 1583, an ABR which aggregates all subnets of 10.0.0.0/8 ignores = summaries which fall into this range, like 8.3.0.0/16. That's why, any = such subnet outside the aggregated area will become unreachable. Why = does the ABR ignores all such summaries. If it didn't ignore them, all = subnets could be reachable...

I would appreciate any help, = Assaf.

------_=_NextPart_001_01C27A65.F40B3386-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 05:54:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12425 for ; Wed, 23 Oct 2002 05:54:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0078A30D@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 5:56:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330316 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 05:56:42 -0400 Received: from 211.202.13.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 05:46:42 -0400 Received: from [211.215.120.105] by mp01.hanafos.com (Terrace Internet Messaging Server 3.220) with ESMTP id 2002102318:48:21:225477.24836.1763 for ; Wed, 23 Oct 2002 18:48:21 +0900 (KST) References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <01fb01c27a79$2b04c6c0$02016464@kirans> Date: Wed, 23 Oct 2002 18:47:14 +0900 Reply-To: Mailing List Sender: Mailing List From: Kiran S Subject: Re: DR / BDR election on different links configured as on same subnet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Delia, Your network setup is R1, R2, R3 are in same broadcast domain (eg. in same VLAN and same subnet) and R1 and R3 are connected to the two differnet interfaces/ports of R2 and all belong to the same subnet a.b.c.0 right ? > Should DR and BDR mechanism be also applied to this scenario, that is R1, > R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. A common DR and BDR election can be done only if R2 takes the multicast OSPF packets (eg. hello , DBD, LS packets ) from R1 and forwards to R3 and send to itself. Similiarly all the multicast packets from R3 are send to R1 and to itself. It means to make this a complete broadcast domain of same subnet for the OSPF routers you need to duplicate all the mulitcast OSPF packets at R2. If this is done, a common DR and BDR election is possible. we neednot duplicate the unicast OSPF routing packets It will get routed by L2 or L3 to the correct interface. right ? If we donot do this R3 will have only one neighbour (R2) and R1 will also have only one neighbour (R2). R2 will have two neighbours R1 and R3. And there will be either "two DRs" or "one DR" in this set up. (If R2 advertises as DR then R3 and R1 will be BDR. and if R2 is BDR then R1 and R3 will be DRs.).. > Therefore if R1 > and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to both > links, in order to reach both DR and BDR? In my opinion it should not. I am > told that it should, as this would be a particular case of OSPF support for > layer 2 switching. how can R1 and R3 can become a common DR and BDR without even R2 duplicating the packets from R1 and from R3. ? R2 needs to duplicate the incoming OSPF mulicast routing packets from its interfaces/ports and forward to the other interfaces/ports of same subnet and send a copy to itself. The OSPF routing PDUs from R2 will naturally get forwarded to all the interfaces on the same subnet if it a multicast packet. So there is no need for any new duplication of the packets from R2 itself. Am I right ? > In my opinion it should not. I am > told that it should, as this would be a particular case of OSPF support for > layer 2 switching. Please let me know if you have a method to accomplish the common DR/BDR election without duplicating the packets at R2. Or do you feel there is no need for it ? > Is there some specification in an RFC about this? I also don't find any RFC saying about this. If some body knows, it will be helpful. Thanks Cheers Kiran ----- Original Message ----- From: "Delia Kecskemeti" To: Sent: Wednesday, October 23, 2002 3:51 AM Subject: DR / BDR election on different links configured as on same subnet > Hi, > > I need to find out how is OSPF supposed to act in this particular case: > Link between routers R1 and R2 and link between R2 and R3 are configured to > be on the same subnet, say: > a.b.c.x / 24 > In my understanding, the DR / BDR mechanism is applied on one broadcast link > to which several routers attach, to minimize number of adjacencies and > network burden on that link. > > Should DR and BDR mechanism be also applied to this scenario, that is R1, > R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. Therefore if R1 > and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to both > links, in order to reach both DR and BDR? In my opinion it should not. I am > told that it should, as this would be a particular case of OSPF support for > layer 2 switching. Is there some specification in an RFC about this? > > R1-----------R2-----------R3 > > Thank you very much and have a nice day, > Delia From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 08:23:38 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15381 for ; Wed, 23 Oct 2002 08:23:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0078A5A3@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 8:25:47 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330866 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 08:25:47 -0400 Received: from 147.188.128.145 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 08:25:47 -0400 Received: from [147.188.128.127] (helo=bham.ac.uk) by sun13.bham.ac.uk with esmtp (Exim 4.10) id 184Ka2-00003s-00 for OSPF@discuss.microsoft.com; Wed, 23 Oct 2002 13:25:46 +0100 Received: from eee-fs7.bham.ac.uk ([147.188.145.131] helo=bham-eee-fs7.bham.ac.uk) by bham.ac.uk with esmtp (Exim 3.36 #1) id 184Ka2-0004ed-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 13:25:46 +0100 Received: by eee-fs7.bham.ac.uk with Internet Mail Service (5.5.2653.19) id <4D0GFXQ8>; Wed, 23 Oct 2002 13:25:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Message-ID: Date: Wed, 23 Oct 2002 13:25:45 +0100 Reply-To: Mailing List Sender: Mailing List From: "Liu B." Subject: Re: How to partition a routing domain into areas in the first pla ce? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA15381 Dear Manav, Thanks for your information. I've found that book in Amazon, which costs about £43, a bit too much to a student :-( I've done the search in IEEEXplore by the authors, but no lucky so far :-(( Is there any paper you would like to recomment about how to design the hierrarchy (i.e., how to divide the network into areas), especially for large-scale networks? Thank you very much, as well as other people's information in advance. Bin Liu -----Original Message----- From: Manav Bhatia [mailto:manav@SAMSUNG.COM] Sent: Wednesday, October 23, 2002 4:43 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: How to partition a routing domain into areas in the first place? Liu, OSPF has 2 level hierarchy (core and areas hanging off the core) while the networks have 3 level (core, distribution and access) so there can be some confusion in mapping OSPF onto real live networks. There is this book "Advanced IP Network Design" by Alvaro Retana, Don Slice and Russ White (ISBN 1-57870-097-3 - Cisco Press) which discusses OSPF Network Design in some detail by considering ways to divide the network into areas, points where summarization can be done, issues with dial backup and ways to handle dial-in-clients/external connections to the network, etc. It may help you in clarifying some of your doubts. Regards, Manav ----- Original Message ----- From: "Liu B." To: Sent: Tuesday, October 22, 2002 7:18 PM Subject: How to partition a routing domain into areas in the first place? > Hi, > > Understanding that the area routing is used in OSPF for better routing > performance (e.g., reduce routing cost). But given a large-scale network, > how to do partitioning according to the topology of network in the first > place? As the topology of most part of the Internet is irregular or mesh, my > question, more specifically, is -- how to do partitioning in a given > large-scale mesh network? > > Thanks in advance for any answer, reference or thought. > > Bin From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 08:23:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15396 for ; Wed, 23 Oct 2002 08:23:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0078A4D5@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 8:26:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 330882 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 08:26:05 -0400 Received: from 147.188.128.145 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 08:26:05 -0400 Received: from [147.188.128.127] (helo=bham.ac.uk) by sun13.bham.ac.uk with esmtp (Exim 4.10) id 184KaK-00004P-00 for OSPF@discuss.microsoft.com; Wed, 23 Oct 2002 13:26:04 +0100 Received: from eee-fs7.bham.ac.uk ([147.188.145.131] helo=bham-eee-fs7.bham.ac.uk) by bham.ac.uk with esmtp (Exim 3.36 #1) id 184KaK-0004kl-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 13:26:04 +0100 Received: by eee-fs7.bham.ac.uk with Internet Mail Service (5.5.2653.19) id <4D0GFXQ0>; Wed, 23 Oct 2002 13:26:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27A8F.5A5950B0" Message-ID: Date: Wed, 23 Oct 2002 13:26:03 +0100 Reply-To: Mailing List Sender: Mailing List From: "Liu B." Subject: Re: area-border router's behaviour To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27A8F.5A5950B0 Content-Type: text/plain; charset="windows-1255" Hi, I have a further question ... define the areas vs. choose ABR, which one goes firstly? Thanks Bin -----Original Message----- From: Kostiner, Assaf (Assaf) [mailto:akostine@AVAYA.COM] Sent: Wednesday, October 23, 2002 8:30 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: area-border router's behaviour Hi, There are couple of issues i can't understand: 1. In RFC an area-border router (ABR) is defined as one that is attached to multiple areas, while Cisco and IBM defined later ABR as one that is physically or virtually connected to the backbone. I understand theire reason for changing the RFC definition. What i don't understand, is why does the RFC allows a router which is connected for example only to areas 1 and 2, to be an ABR, and to advertise summaries from one to the other. This router is allowed to use only summaries received from area 0, when running SPF, so what's the point? 2. Overlapping area ranges - in RFC 1583, an ABR which aggregates all subnets of 10.0.0.0/8 ignores summaries which fall into this range, like 8.3.0.0/16. That's why, any such subnet outside the aggregated area will become unreachable. Why does the ABR ignores all such summaries. If it didn't ignore them, all subnets could be reachable... I would appreciate any help, Assaf. ------_=_NextPart_001_01C27A8F.5A5950B0 Content-Type: text/html; charset="windows-1255" area-border router's behaviour
Hi,
 
I have a further question ... define the areas vs. choose ABR, which one goes firstly?
 
Thanks 
 
Bin 
-----Original Message-----
From: Kostiner, Assaf (Assaf) [mailto:akostine@AVAYA.COM]
Sent: Wednesday, October 23, 2002 8:30 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: area-border router's behaviour

Hi,

There are couple of issues i can't understand:

1. In RFC an area-border router (ABR) is defined as one that is attached to multiple areas, while Cisco and IBM defined later ABR as one that is physically or virtually connected to the backbone. I understand theire reason for changing the RFC definition. What i don't understand, is why does the RFC allows a router which is connected for example only to areas 1 and 2, to be an ABR, and to advertise summaries from one to the other. This router is allowed to use only summaries received from area 0, when running SPF, so what's the point?

2. Overlapping area ranges - in RFC 1583, an ABR which aggregates all subnets of 10.0.0.0/8 ignores summaries which fall into this range, like 8.3.0.0/16. That's why, any such subnet outside the aggregated area will become unreachable. Why does the ABR ignores all such summaries. If it didn't ignore them, all subnets could be reachable...

I would appreciate any help, Assaf.

------_=_NextPart_001_01C27A8F.5A5950B0-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 09:47:46 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26746 for ; Wed, 23 Oct 2002 09:47:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0078A930@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 9:50:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 331143 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 09:50:00 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 09:50:00 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 737E5F2C4D for ; Wed, 23 Oct 2002 06:50:00 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB6A8BC.3070506@redback.com> Date: Wed, 23 Oct 2002 09:48:44 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: area-border router's behaviour To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kostiner, Assaf (Assaf) wrote: > Hi, > > There are couple of issues i can't understand: > > 1. In RFC an area-border router (ABR) is defined as one that is attached > to multiple areas, while Cisco and IBM defined later ABR as one that is > physically or virtually connected to the backbone. I understand theire > reason for changing the RFC definition. What i don't understand, is why > does the RFC allows a router which is connected for example only to > areas 1 and 2, to be an ABR, and to advertise summaries from one to the > other. This router is allowed to use only summaries received from area > 0, when running SPF, so what's the point? Hi Assaf, Routers internal to area 1 and 2 will use the summaries advertised into their respective areas. They will be able to reach other even though their ABR is not connected to the backbone. However, you would not want to design a network without a backbone area or ABRs without backbone interfaces. > > 2. Overlapping area ranges - in RFC 1583, an ABR which aggregates all > subnets of 10.0.0.0/8 ignores summaries which fall into this range, like > 8.3.0.0/16. That's why, any such subnet outside the aggregated area will > become unreachable. Why does the ABR ignores all such summaries. If it > didn't ignore them, all subnets could be reachable... In RFC 2328 (the current OSPF specification), overlapping subnet ranges are supported. If you have an ABR that ignores overlapping summaries then it doesn't properly support RFC 2328. > > I would appreciate any help, Assaf. > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 09:49:40 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27117 for ; Wed, 23 Oct 2002 09:49:40 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0078A963@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 9:51:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 331163 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 09:51:54 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 09:51:54 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HPDPQ>; Wed, 23 Oct 2002 09:51:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 23 Oct 2002 09:53:49 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee, However if we can go by the assumption that the value would not be changed while in the process of a restart, it can simplify the case as only the first Grace LSA from a neighbor would be considered. I guess a change to section 3 of the draft would be required then. Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Wednesday, October 23, 2002 12:20 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Hitless restart Manral, Vishwas wrote: > Hi Acee, > > I agree to Padma's statement that we are using link-local LSA to signal > hitless-restart, because we would not want the LSA to be flooded by the > neighbors into the area. We are signalling router parameters in the link > local LSA. > > Regarding 2. > - I think we should update the grace-period/reason only when we have a > change in content of the Grace LSA from the neighbor to the restarting > router on any interface. So if we get a different value of > grace-period/restart reason we update and restart the grace period on the > helper else we do not. This would be in keeping with Section 3 of the draft. Vishwas, I agree that if we do agree to change the existing specification than we should, in fact, honor changes to the grace-period/restart-reason. One of my concerns with this approach is the added complexity (consider determining which of multiple link local LSAs received on different links is more recent). Thanks, Acee > - I think the first grace LSA withdrawn would cause the router to exit > hitless restart mode for that neighbor. > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, October 22, 2002 8:22 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Hitless restart > > > All, > > I think we have a "rough concensus" that the restarting router > should NOT try to optimize flooding of grace LSAs. I've > only had one vote for this and I believe the vote was more > for flooding optimizations in general than this particular > scenario. > > > Padma, > > I don't think it simplifies the helper code (or specification) > to apply the grace LSA to all neighbor instances of restarting > router. Here are my reasons: > > 1. Conceptually, I don't think it is right to apply the link > local grace LSA to neighbors that are not on the link. > > 2. There are simply more corner cases - > > - When you receive a second grace LSA from the restarting > router, do you update the reason and grace period for > all neighbor instances or only ones on that segment? > > - When do exit helper mode? Is it when the first grace > LSA is withdrawn or all the grace LSAs? I certainly don't > think there should be disconnect between entering and > exiting helper mode. > > I do agree that it is somewhat more robust for the case where > you are adjacent with the same router on more than one link. > However, I don't see this as a real big gain. Has anyone > else implemented this draft? > > Thanks, > Acee > > > > Padma Pillay-Esnault wrote: > > >>Rajesh >> >> >>Rajesh Varadarajan wrote: >> >> >>>Acee, Padma, >>> >>> >> >> >>>>>>>I do think it simplifies things if a restarting router originates the >>>>>>> > grace LSAs > >>>>>>>on all it's interfaces (or at least all with full neighbor >>>>>>> >>>>>>> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >>>>>>>adjacencies if it a planned restart). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>The above statement seems to imply (my reading) that a restarting router >>> >>>can only send Grace LSA's out of some (not all) of its interfaces. The >>> >>> >>It doesn't imply that - clearly we send to all our neighbors. >> >>Padma >> >> >>>spec however requires the router to send the grace-lsa out of all >>>interfaces on which it has full neigbhors. Failure to do so would always >>>result in its helper mode being terminated by others. >>> >>> >> >> >>>>>>I also agree with you .. that's what I do - the restarting router sends >>>>>>grace lsa over all interfaces. But from a Helping router perspective >>>>>>we should do as in 00-txt. It simplifies the helper code. >>>>>>It also prevents corner cases where we might not help all adjacencies >>>>>>(when we should). >>>>>> >>>>>>Padma >>>>>> >>>>>> >>>>>I haven't heard anyone object to why the 00-txt. >>>>> >>>>> >>>>I will - I specifically agree with >>>> >>>> >>>> >>>> Note that Router Y only needs to receive a single grace-LSA from >>>> X, even if X and Y attach to multiple common segments. >>>> >>>>I don't like using an LSA with link local scope to enter/terminate >>>>helper mode for neighbors on different interfaces. It is better if the >>>>link local grace LSA only applies to that link. >>>> >>>> >>>Given the behavior above, I think the each neighbor should be considered >>>independently on a segment by segment basis. >>> >>> >>>thanks, >>>rajesh > -- > Acee -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 10:09:06 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00845 for ; Wed, 23 Oct 2002 10:09:05 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0078AAB6@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 10:11:21 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 331252 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 10:11:20 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 10:11:20 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 653114BA21A for ; Wed, 23 Oct 2002 07:11:19 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <01fb01c27a79$2b04c6c0$02016464@kirans> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB6ADBB.50104@redback.com> Date: Wed, 23 Oct 2002 10:10:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: DR / BDR election on different links configured as on same subnet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kiran, Delia, The reason that this setup is not described anywhere is that it is non-standard. It is uncommon for a router to support multiple interfaces on the same subnet. If a router does support multiple interfaces on the same subnet and the topology is broadcast then the network (not R2) would need to assure that a broadcast/multicast packet sent by R1 would be received by R3. The forwarding discussed below is not expected (unless R2 is bridging). Thanks, Acee Kiran S wrote: > Hi Delia, > > Your network setup is R1, R2, R3 are in same broadcast domain (eg. in same > VLAN and same subnet) and R1 and R3 are connected to the two differnet > interfaces/ports of R2 and all belong to the same subnet a.b.c.0 right ? > >>Should DR and BDR mechanism be also applied to this scenario, that is R1, >>R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. >> > > A common DR and BDR election can be done only if R2 takes the multicast OSPF > packets (eg. hello , DBD, LS packets ) from R1 and forwards to R3 and send > to itself. Similiarly all the multicast packets from R3 are send to R1 and > to itself. It means to make this a complete broadcast domain of same subnet > for the OSPF routers you need to duplicate all the mulitcast OSPF packets at > R2. If this is done, a common DR and BDR election is possible. > we neednot duplicate the unicast OSPF routing packets It will get routed by > L2 or L3 to the correct interface. right ? > If we donot do this R3 will have only one neighbour (R2) and R1 will also > have only one neighbour (R2). R2 will have two neighbours R1 and R3. And > there will be either "two DRs" or "one DR" in this set up. (If R2 advertises > as DR then R3 and R1 will be BDR. and if R2 is BDR then R1 and R3 will be > DRs.).. > > >>Therefore if R1 >>and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to both >>links, in order to reach both DR and BDR? In my opinion it should not. I >> > am > >>told that it should, as this would be a particular case of OSPF support >> > for > >>layer 2 switching. >> > > how can R1 and R3 can become a common DR and BDR without even R2 duplicating > the packets from R1 and from R3. ? R2 needs to duplicate the incoming OSPF > mulicast routing packets from its interfaces/ports and forward to the other > interfaces/ports of same subnet and send a copy to itself. The OSPF routing > PDUs from R2 will naturally get forwarded to all the interfaces on the same > subnet if it a multicast packet. So there is no need for any new duplication > of the packets from R2 itself. > Am I right ? > > >>In my opinion it should not. I am >>told that it should, as this would be a particular case of OSPF support >> > for > >>layer 2 switching. >> > > Please let me know if you have a method to accomplish the common DR/BDR > election without duplicating the packets at R2. Or do you feel there is no > need for it ? > > >>Is there some specification in an RFC about this? >> > > I also don't find any RFC saying about this. If some body knows, it will be > helpful. > > Thanks > > Cheers > Kiran > > > ----- Original Message ----- > From: "Delia Kecskemeti" > To: > Sent: Wednesday, October 23, 2002 3:51 AM > Subject: DR / BDR election on different links configured as on same subnet > > > >>Hi, >> >>I need to find out how is OSPF supposed to act in this particular case: >>Link between routers R1 and R2 and link between R2 and R3 are configured >> > to > >>be on the same subnet, say: >>a.b.c.x / 24 >>In my understanding, the DR / BDR mechanism is applied on one broadcast >> > link > >>to which several routers attach, to minimize number of adjacencies and >>network burden on that link. >> >>Should DR and BDR mechanism be also applied to this scenario, that is R1, >>R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. Therefore if >> > R1 > >>and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to both >>links, in order to reach both DR and BDR? In my opinion it should not. I >> > am > >>told that it should, as this would be a particular case of OSPF support >> > for > >>layer 2 switching. Is there some specification in an RFC about this? >> >>R1-----------R2-----------R3 >> >>Thank you very much and have a nice day, >>Delia >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 10:19:18 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02878 for ; Wed, 23 Oct 2002 10:19:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0078AB11@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 10:21:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 331289 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 10:21:32 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 10:21:31 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 621FF2848A7 for ; Wed, 23 Oct 2002 07:21:31 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB6B01F.6080908@redback.com> Date: Wed, 23 Oct 2002 10:20:15 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: > Hi Acee, > > However if we can go by the assumption that the value would not be changed > while in the process of a restart, it can simplify the case as only the > first Grace LSA from a neighbor would be considered. I guess a change to > section 3 of the draft would be required then. Hi Vishwas, The only problem I see here is that a stale grace LSA could prevent new values from being honored. For example, consider the case where you have a planned restart that crashes followed immediately by an unplanned restart. Maybe this is remote enough that it can be ignored. Thanks, Acee > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Wednesday, October 23, 2002 12:20 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Hitless restart > > > Manral, Vishwas wrote: > > >>Hi Acee, >> >>I agree to Padma's statement that we are using link-local LSA to signal >>hitless-restart, because we would not want the LSA to be flooded by the >>neighbors into the area. We are signalling router parameters in the link >>local LSA. >> >>Regarding 2. >>- I think we should update the grace-period/reason only when we have a >>change in content of the Grace LSA from the neighbor to the restarting >>router on any interface. So if we get a different value of >>grace-period/restart reason we update and restart the grace period on the >>helper else we do not. This would be in keeping with Section 3 of the >> > draft. > > > Vishwas, > > I agree that if we do agree to change the existing specification than we > should, in fact, honor changes to the grace-period/restart-reason. One > of my concerns with this approach is the added complexity (consider > determining which of multiple link local LSAs received on different > links is more recent). > > Thanks, > > Acee > > > >>- I think the first grace LSA withdrawn would cause the router to exit >>hitless restart mode for that neighbor. >> >>Thanks, >>Vishwas >> >>-----Original Message----- >>From: Acee Lindem [mailto:acee@REDBACK.COM] >>Sent: Tuesday, October 22, 2002 8:22 PM >>To: OSPF@DISCUSS.MICROSOFT.COM >>Subject: Re: Hitless restart >> >> >>All, >> >>I think we have a "rough concensus" that the restarting router >>should NOT try to optimize flooding of grace LSAs. I've >>only had one vote for this and I believe the vote was more >>for flooding optimizations in general than this particular >>scenario. >> >> >>Padma, >> >>I don't think it simplifies the helper code (or specification) >>to apply the grace LSA to all neighbor instances of restarting >>router. Here are my reasons: >> >> 1. Conceptually, I don't think it is right to apply the link >> local grace LSA to neighbors that are not on the link. >> >> 2. There are simply more corner cases - >> >> - When you receive a second grace LSA from the restarting >> router, do you update the reason and grace period for >> all neighbor instances or only ones on that segment? >> >> - When do exit helper mode? Is it when the first grace >> LSA is withdrawn or all the grace LSAs? I certainly don't >> think there should be disconnect between entering and >> exiting helper mode. >> >>I do agree that it is somewhat more robust for the case where >>you are adjacent with the same router on more than one link. >>However, I don't see this as a real big gain. Has anyone >>else implemented this draft? >> >>Thanks, >>Acee >> >> >> >>Padma Pillay-Esnault wrote: >> >> >> >>>Rajesh >>> >>> >>>Rajesh Varadarajan wrote: >>> >>> >>> >>>>Acee, Padma, >>>> >>>> >>>> >>> >>> >>>>>>>>I do think it simplifies things if a restarting router originates the >>>>>>>> >>>>>>>> >>grace LSAs >> >> >>>>>>>>on all it's interfaces (or at least all with full neighbor >>>>>>>> >>>>>>>> >>>>>>>> >>>^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> >>> >>>>>>>>adjacencies if it a planned restart). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>The above statement seems to imply (my reading) that a restarting router >>>> >>>>can only send Grace LSA's out of some (not all) of its interfaces. The >>>> >>>> >>>> >>>It doesn't imply that - clearly we send to all our neighbors. >>> >>>Padma >>> >>> >>> >>>>spec however requires the router to send the grace-lsa out of all >>>>interfaces on which it has full neigbhors. Failure to do so would always >>>>result in its helper mode being terminated by others. >>>> >>>> >>>> >>> >>> >>>>>>>I also agree with you .. that's what I do - the restarting router >>>>>>> > sends > >>>>>>>grace lsa over all interfaces. But from a Helping router perspective >>>>>>>we should do as in 00-txt. It simplifies the helper code. >>>>>>>It also prevents corner cases where we might not help all adjacencies >>>>>>>(when we should). >>>>>>> >>>>>>>Padma >>>>>>> >>>>>>> >>>>>>> >>>>>>I haven't heard anyone object to why the 00-txt. >>>>>> >>>>>> >>>>>> >>>>>I will - I specifically agree with >>>>> >>>>> >>>>> >>>>> Note that Router Y only needs to receive a single grace-LSA from >>>>> X, even if X and Y attach to multiple common segments. >>>>> >>>>>I don't like using an LSA with link local scope to enter/terminate >>>>>helper mode for neighbors on different interfaces. It is better if the >>>>>link local grace LSA only applies to that link. >>>>> >>>>> >>>>> >>>>Given the behavior above, I think the each neighbor should be considered >>>>independently on a segment by segment basis. >>>> >>>> >>>>thanks, >>>>rajesh >>>> >>-- >>Acee >> > -- > Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 11:04:14 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11188 for ; Wed, 23 Oct 2002 11:04:13 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0078ACD8@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 11:06:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 331513 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 11:06:25 -0400 Received: from 211.202.13.162 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 11:06:25 -0400 Received: from [211.117.20.85] by mp02.hanafos.com (Terrace Internet Messaging Server 3.220) with ESMTP id 2002102400:08:38:577756.2078.3781 for ; Thu, 24 Oct 2002 00:08:38 +0900 (KST) References: <01fb01c27a79$2b04c6c0$02016464@kirans> <3DB6ADBB.50104@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <02b001c27aa5$d5f83040$02016464@kirans> Date: Thu, 24 Oct 2002 00:06:59 +0900 Reply-To: Mailing List Sender: Mailing List From: Kiran S Subject: Re: DR / BDR election on different links configured as on same subnet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acce, > The reason that this setup is not described anywhere is that it is > non-standard. It is uncommon for a router to support multiple > interfaces on the same subnet. I donot know whether you misunderstood by the way I used the term "interface". The interface which was desribed is not the logical interface at IP. It is the hardware port. In the case of forming a VLAN , many hardware ports can join a single VLAN and this VLAN can have a single subnet. This VLAN is mapped to the logical interface at IP, the interface you are specifying. This logical IP interface is in a subnet. So, R1 , R2 , R3 belong to the same subnet and broadcast domain. I have seen a typical example in metro ethernet network. It is similiar to the network shown by Delia. R1 and R2 was in a location and it was in back bone area. R3 is located in a different location. They need to connect R3 to the back bone area by connecting it to the GBIC port of the R2 using optical fibre cable. R2's GBIC port and R3's GBIC port join same VLAN and has this VLAN belong to the same subnet. In this case R3 cannot find R1 as a neighbour and R1 cannot find R3 as neigbour, if R2 doesnot duplicate the OSPF packets and forward to R3 and R1 ports. Thanks Cheers Kiran ----- Original Message ----- From: "Acee Lindem" To: Sent: Wednesday, October 23, 2002 11:10 PM Subject: Re: DR / BDR election on different links configured as on same subnet > Kiran, Delia, > > The reason that this setup is not described anywhere is that it is > non-standard. It is uncommon for a router to support multiple > interfaces on the same subnet. If a router does support multiple > interfaces on the same subnet and the topology is broadcast then > the network (not R2) would need to assure that a broadcast/multicast > packet sent by R1 would be received by R3. The forwarding discussed > below is not expected (unless R2 is bridging). > > Thanks, > Acee > > Kiran S wrote: > > > Hi Delia, > > > > Your network setup is R1, R2, R3 are in same broadcast domain (eg. in same > > VLAN and same subnet) and R1 and R3 are connected to the two differnet > > interfaces/ports of R2 and all belong to the same subnet a.b.c.0 right ? > > > > >>Should DR and BDR mechanism be also applied to this scenario, that is R1, > >>R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. > >> > > > > A common DR and BDR election can be done only if R2 takes the multicast OSPF > > packets (eg. hello , DBD, LS packets ) from R1 and forwards to R3 and send > > to itself. Similiarly all the multicast packets from R3 are send to R1 and > > to itself. It means to make this a complete broadcast domain of same subnet > > for the OSPF routers you need to duplicate all the mulitcast OSPF packets at > > R2. If this is done, a common DR and BDR election is possible. > > we neednot duplicate the unicast OSPF routing packets It will get routed by > > L2 or L3 to the correct interface. right ? > > If we donot do this R3 will have only one neighbour (R2) and R1 will also > > have only one neighbour (R2). R2 will have two neighbours R1 and R3. And > > there will be either "two DRs" or "one DR" in this set up. (If R2 advertises > > as DR then R3 and R1 will be BDR. and if R2 is BDR then R1 and R3 will be > > DRs.).. > > > > > >>Therefore if R1 > >>and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to both > >>links, in order to reach both DR and BDR? In my opinion it should not. I > >> > > am > > > >>told that it should, as this would be a particular case of OSPF support > >> > > for > > > >>layer 2 switching. > >> > > > > how can R1 and R3 can become a common DR and BDR without even R2 duplicating > > the packets from R1 and from R3. ? R2 needs to duplicate the incoming OSPF > > mulicast routing packets from its interfaces/ports and forward to the other > > interfaces/ports of same subnet and send a copy to itself. The OSPF routing > > PDUs from R2 will naturally get forwarded to all the interfaces on the same > > subnet if it a multicast packet. So there is no need for any new duplication > > of the packets from R2 itself. > > Am I right ? > > > > > >>In my opinion it should not. I am > >>told that it should, as this would be a particular case of OSPF support > >> > > for > > > >>layer 2 switching. > >> > > > > Please let me know if you have a method to accomplish the common DR/BDR > > election without duplicating the packets at R2. Or do you feel there is no > > need for it ? > > > > > >>Is there some specification in an RFC about this? > >> > > > > I also don't find any RFC saying about this. If some body knows, it will be > > helpful. > > > > Thanks > > > > Cheers > > Kiran > > > > > > ----- Original Message ----- > > From: "Delia Kecskemeti" > > To: > > Sent: Wednesday, October 23, 2002 3:51 AM > > Subject: DR / BDR election on different links configured as on same subnet > > > > > > > >>Hi, > >> > >>I need to find out how is OSPF supposed to act in this particular case: > >>Link between routers R1 and R2 and link between R2 and R3 are configured > >> > > to > > > >>be on the same subnet, say: > >>a.b.c.x / 24 > >>In my understanding, the DR / BDR mechanism is applied on one broadcast > >> > > link > > > >>to which several routers attach, to minimize number of adjacencies and > >>network burden on that link. > >> > >>Should DR and BDR mechanism be also applied to this scenario, that is R1, > >>R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. Therefore if > >> > > R1 > > > >>and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to both > >>links, in order to reach both DR and BDR? In my opinion it should not. I > >> > > am > > > >>told that it should, as this would be a particular case of OSPF support > >> > > for > > > >>layer 2 switching. Is there some specification in an RFC about this? > >> > >>R1-----------R2-----------R3 > >> > >>Thank you very much and have a nice day, > >>Delia > >> > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 12:06:21 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23335 for ; Wed, 23 Oct 2002 12:06:21 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0078ADE4@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 12:08:36 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 332028 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 12:08:35 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 12:08:35 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id E8B904BA21A for ; Wed, 23 Oct 2002 09:08:34 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <01fb01c27a79$2b04c6c0$02016464@kirans> <3DB6ADBB.50104@redback.com> <02b001c27aa5$d5f83040$02016464@kirans> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB6C935.4010103@redback.com> Date: Wed, 23 Oct 2002 12:07:17 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: DR / BDR election on different links configured as on same subnet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kiran, What you are describing is one way of bridging and routing on the same port. I'm sure there are a number of vendors that support this but people shouldn't be confused into to thinking that this is normal router forwarding. Kiran S wrote: > Acce, > > >>The reason that this setup is not described anywhere is that it is >>non-standard. It is uncommon for a router to support multiple >>interfaces on the same subnet. >> > > I donot know whether you misunderstood by the way I used the term > "interface". The interface which was desribed is not the logical interface > at IP. It is the hardware port. In the case of forming a VLAN , many > hardware ports can join a single VLAN and this VLAN can have a single > subnet. This VLAN is mapped to the logical interface at IP, the interface > you are specifying. This logical IP interface is in a subnet. > So, R1 , R2 , R3 belong to the same subnet and broadcast domain. > > I have seen a typical example in metro ethernet network. > It is similiar to the network shown by Delia. R1 and R2 was in a location > and it was in back bone area. R3 is located in a different location. They > need to connect R3 to the back bone area by connecting it to the GBIC port > of the R2 using optical fibre cable. R2's GBIC port and R3's GBIC port join > same VLAN and has this VLAN belong to the same subnet. In this case R3 > cannot find R1 as a neighbour and R1 cannot find R3 as neigbour, if R2 > doesnot duplicate the OSPF packets and forward to R3 and R1 ports. > > > Thanks > > Cheers > Kiran > > > ----- Original Message ----- > From: "Acee Lindem" > To: > Sent: Wednesday, October 23, 2002 11:10 PM > Subject: Re: DR / BDR election on different links configured as on same > subnet > > > >>Kiran, Delia, >> >>The reason that this setup is not described anywhere is that it is >>non-standard. It is uncommon for a router to support multiple >>interfaces on the same subnet. If a router does support multiple >>interfaces on the same subnet and the topology is broadcast then >>the network (not R2) would need to assure that a broadcast/multicast >>packet sent by R1 would be received by R3. The forwarding discussed >>below is not expected (unless R2 is bridging). >> >>Thanks, >>Acee >> >>Kiran S wrote: >> >> >>>Hi Delia, >>> >>> Your network setup is R1, R2, R3 are in same broadcast domain (eg. in >>> > same > >>>VLAN and same subnet) and R1 and R3 are connected to the two differnet >>>interfaces/ports of R2 and all belong to the same subnet a.b.c.0 right >>> > ? > >>>>Should DR and BDR mechanism be also applied to this scenario, that is >>>> > R1, > >>>>R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. >>>> >>>> >>>A common DR and BDR election can be done only if R2 takes the multicast >>> > OSPF > >>>packets (eg. hello , DBD, LS packets ) from R1 and forwards to R3 and >>> > send > >>>to itself. Similiarly all the multicast packets from R3 are send to R1 >>> > and > >>>to itself. It means to make this a complete broadcast domain of same >>> > subnet > >>>for the OSPF routers you need to duplicate all the mulitcast OSPF >>> > packets at > >>>R2. If this is done, a common DR and BDR election is possible. >>>we neednot duplicate the unicast OSPF routing packets It will get >>> > routed by > >>>L2 or L3 to the correct interface. right ? >>>If we donot do this R3 will have only one neighbour (R2) and R1 will >>> > also > >>>have only one neighbour (R2). R2 will have two neighbours R1 and R3. And >>>there will be either "two DRs" or "one DR" in this set up. (If R2 >>> > advertises > >>>as DR then R3 and R1 will be BDR. and if R2 is BDR then R1 and R3 will >>> > be > >>>DRs.).. >>> >>> >>> >>>>Therefore if R1 >>>>and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to >>>> > both > >>>>links, in order to reach both DR and BDR? In my opinion it should not. I >>>> >>>> >>>am >>> >>> >>>>told that it should, as this would be a particular case of OSPF support >>>> >>>> >>>for >>> >>> >>>>layer 2 switching. >>>> >>>> >>>how can R1 and R3 can become a common DR and BDR without even R2 >>> > duplicating > >>>the packets from R1 and from R3. ? R2 needs to duplicate the incoming >>> > OSPF > >>>mulicast routing packets from its interfaces/ports and forward to the >>> > other > >>>interfaces/ports of same subnet and send a copy to itself. The OSPF >>> > routing > >>>PDUs from R2 will naturally get forwarded to all the interfaces on the >>> > same > >>>subnet if it a multicast packet. So there is no need for any new >>> > duplication > >>>of the packets from R2 itself. >>>Am I right ? >>> >>> >>> >>>>In my opinion it should not. I am >>>>told that it should, as this would be a particular case of OSPF support >>>> >>>> >>>for >>> >>> >>>>layer 2 switching. >>>> >>>> >>>Please let me know if you have a method to accomplish the common DR/BDR >>>election without duplicating the packets at R2. Or do you feel there is >>> > no > >>>need for it ? >>> >>> >>> >>>>Is there some specification in an RFC about this? >>>> >>>> >>>I also don't find any RFC saying about this. If some body knows, it will >>> > be > >>>helpful. >>> >>>Thanks >>> >>>Cheers >>>Kiran >>> >>> >>>----- Original Message ----- >>>From: "Delia Kecskemeti" >>>To: >>>Sent: Wednesday, October 23, 2002 3:51 AM >>>Subject: DR / BDR election on different links configured as on same >>> > subnet > >>> >>> >>>>Hi, >>>> >>>>I need to find out how is OSPF supposed to act in this particular case: >>>>Link between routers R1 and R2 and link between R2 and R3 are configured >>>> >>>> >>>to >>> >>> >>>>be on the same subnet, say: >>>>a.b.c.x / 24 >>>>In my understanding, the DR / BDR mechanism is applied on one broadcast >>>> >>>> >>>link >>> >>> >>>>to which several routers attach, to minimize number of adjacencies and >>>>network burden on that link. >>>> >>>>Should DR and BDR mechanism be also applied to this scenario, that is >>>> > R1, > >>>>R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. Therefore if >>>> >>>> >>>R1 >>> >>> >>>>and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to >>>> > both > >>>>links, in order to reach both DR and BDR? In my opinion it should not. I >>>> >>>> >>>am >>> >>> >>>>told that it should, as this would be a particular case of OSPF support >>>> >>>> >>>for >>> >>> >>>>layer 2 switching. Is there some specification in an RFC about this? >>>> >>>>R1-----------R2-----------R3 >>>> >>>>Thank you very much and have a nice day, >>>>Delia >>>> >>>> >> >>-- >>Acee >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 12:40:05 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24946 for ; Wed, 23 Oct 2002 12:40:04 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0078B0AC@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 12:42:21 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 332122 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 12:42:20 -0400 Received: from 66.218.78.162 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 12:42:19 -0400 Received: from [63.103.225.22] by web40705.mail.yahoo.com via HTTP; Wed, 23 Oct 2002 09:42:20 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-361376338-1035391340=:46021" Message-ID: <20021023164220.46323.qmail@web40705.mail.yahoo.com> Date: Wed, 23 Oct 2002 09:42:20 -0700 Reply-To: Mailing List Sender: Mailing List From: Vinay Ravuri Subject: Re: OSPF Question To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list --0-361376338-1035391340=:46021 Content-Type: text/plain; charset=us-ascii Sina, I would be interested in reading your paper. Please send it to vinay_ravuri@yahoo.com Cheer, Vinay Sina Mirtorabi wrote:Vinay Vinay> Your b), is the stub area between A-B, B-C links and advertise default routes out on A-D, B-E, C-F links to reach A, B, C? Vinay> If so, I think this approach should work. I guess you mean c) and not b) , yes totally stub will satisfy your requirement .... Vinay> Your c), there will likely be links between D, E, F - Where do you see a problem here? Vinay> If I am only advertising reachability to A, B, C on A-D, B-E, C-F links you mean d) and not c), if there is a backdoor and D/E/F can exchange reachability without going through A/B/C then you do not need any redistribution. I don't know exactly your topology / requirement but if you are redistributing between multiple process in more than one point you need to be careful, I can send you a paper that I wrote on that.... Sina Sina Mirtorabi wrote: Vinay by " not knowing about interface that exist" , do you mean topology wise or even not knowing IP reachability regarding those interface ? some option that you have depending on what really you are looking for .... a) make link A-B & B-C in area 0 and each other link in a different area if you don't want IP information of A-B and B-C to be advertised you can b) filter on A / B / C the corresponding prefixes belonging to area 0 ( given that you can do type 3 filtering )c) make the non-backbone areas totally stub in order to just have a default route on D, E, F d) run different process and redistribute as you pointed out but it can be tricky if there are some back door link between D/E/F Sina-----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay Ravuri Sent: Monday, October 21, 2002 10:58 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF Question Hi, Consider the following topology. A --------B----------C | | | | | | D E F Where A, B, C, D, E, F are routers and A, B, C have interfaces out to each other and to D, E, F respectivley. If I wanted to keep the interfaces between A, B, C private to routers A, B, C. That is, I do not want D, E, F to know about the interfaces that exist between A, B, C but still have D, E, F to reach each other some how. How could I accomplish this with OSPF? One thought I had was perhaps run 2 instances of OSPF on A, B, C. First instance runs between iterfaces on A, B, C and second between A->D, B->E, C->F and advertise the reachability to D, E, F via the interfaces A, B, C and keep the interfaces between A, B, C hidden. Does doing something like this make sense or is there a better to accomplish this. Also, with OSPF how does one differentiate between interfaces on a another node inorder to selectively leak routes? -Vinay --------------------------------- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site --------------------------------- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site --------------------------------- Do you Yahoo!? Y! Web Hosting - Let the expert host your web site --0-361376338-1035391340=:46021 Content-Type: text/html; charset=us-ascii

Sina,

       I would be interested in reading your paper.  Please send it to vinay_ravuri@yahoo.com

Cheer,

Vinay

 Sina Mirtorabi <sina@CISCO.COM> wrote:

Vinay
 
Vinay> Your b),  is the stub area between A-B, B-C links and advertise default routes out on A-D, B-E, C-F links to reach A, B, C? 
Vinay> If so, I think this approach should work.
 
I guess you mean c) and not b) , yes totally stub will satisfy your requirement ....
 
Vinay> Your c), there will likely be links between D, E, F - Where do you see a problem here? 
Vinay> If I am only advertising reachability to A, B, C on A-D, B-E, C-F links
 
you mean d) and not c),  if there is a backdoor and D/E/F can exchange reachability without going through A/B/C then you do not need any redistribution.
 
I don't know exactly your topology / requirement but if you are redistributing between multiple process in more than one point you need to be careful, I can send you a paper that I wrote on that....
 
Sina

 Sina Mirtorabi <sina@CISCO.COM> wrote:

Vinay
 
by " not knowing about interface that exist" , do you mean topology wise or even not knowing IP reachability regarding those interface ?
 
some option that you have depending on what really you are looking for ....
 
a) make link A-B & B-C in area 0 and each other link in a different area
 
if you don't want IP information of A-B and B-C to be advertised you can
 
b) filter on A / B / C the corresponding prefixes belonging to area 0 ( given that you can do type 3 filtering )
c) make the non-backbone areas totally stub in order to just have a default route on D, E, F
 
d) run different process and redistribute as you pointed out but it can be tricky if there are some back door link between D/E/F
 
Sina
-----Original Message-----
From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay Ravuri
Sent: Monday, October 21, 2002 10:58 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF Question

Hi,

   Consider the following topology.


    A --------B----------C
    |         |             |
    |         |             |
    D        E          F

Where A, B, C, D, E, F are routers and A, B, C have interfaces out to each other and to D, E, F respectivley. 

If I wanted to keep the interfaces between A, B, C private to routers A, B, C.  That is, I do not want D, E, F to know about the interfaces that exist between A, B, C but still have D, E, F to reach each other some how.  How could I accomplish this with OSPF?

One thought I had was perhaps run 2 instances of OSPF on A, B, C.  First instance runs between iterfaces on A, B, C and second between A->D, B->E, C->F and advertise the reachability to D, E, F via the interfaces A, B, C and keep the interfaces between A, B, C hidden.  Does doing something like this make sense or is there a better to accomplish this.  Also, with OSPF how does one differentiate between interfaces on a another node inorder to selectively leak routes?

-Vinay


Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site


Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site


Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site --0-361376338-1035391340=:46021-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 14:17:35 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28106 for ; Wed, 23 Oct 2002 14:17:34 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0078B0F0@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 14:19:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 332419 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 14:19:48 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 14:19:48 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9NIJnm45775 for ; Wed, 23 Oct 2002 11:19:49 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id g9NIJn861494 for ; Wed, 23 Oct 2002 11:19:49 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20021023104523.W61245-100000@kummer.juniper.net> Date: Wed, 23 Oct 2002 11:19:49 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DB5C429.9000100@redback.com> Precedence: list Hi Acee, On Tue, 22 Oct 2002, Acee Lindem wrote: > I don't expect to have any comments on IETF wide last call. Can I hold you to that? :-) > > This is a nitpick. > > Have you ever met a programmer who didn't? None that I respect :-) > I was just thinking that a document going to proposed standard would > be better served with a single way of handling multi-access links. If > I'm the only one with this concern then I'll relent. It wouldn't be better served changing something *that works and interoperates* at the last minute. New wording (the part after the semicolon is new): | If the Link Type of the link is Multiaccess, the Remote | Interface IP Addess is set to 0.0.0.0; alternatively, an implementation | MAY choose not to send this sub-TLV. > > However, if you think that the new wording is preferable, I will > > change this to "Operation over multiaccess links with more than two > > devices is not specifically prohibited. More accurate description of > > the reservation state of multi-access networks is for further study." > > > There was considerable discussion on this topic and I believe > this a good addition. Done. New wording: | The reservation state of multiaccess | links may not be accurately reflected, except in the special case that | there are only two devices in the multiaccess subnetwork. Operation | over multiaccess networks with more than two devices is not specifically | prohibited. More accurate description of the reservation state of | multi-access networks is for further study. Note one other minor change: "reservation state ... is not ..." to "reservation state ... may not be ..." Can we ship this out now? Kireeti. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 14:21:45 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28280 for ; Wed, 23 Oct 2002 14:21:45 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0078B123@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 14:24:00 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 332442 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 14:23:58 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 14:23:58 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 3DD94428F22 for ; Wed, 23 Oct 2002 11:23:58 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20021023104523.W61245-100000@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB6E8EF.1070108@redback.com> Date: Wed, 23 Oct 2002 14:22:39 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sounds good to me. Kireeti Kompella wrote: > Hi Acee, > > On Tue, 22 Oct 2002, Acee Lindem wrote: > > >>I don't expect to have any comments on IETF wide last call. >> > > Can I hold you to that? :-) > > >>>This is a nitpick. >>> >>Have you ever met a programmer who didn't? >> > > None that I respect :-) > > >>I was just thinking that a document going to proposed standard would >>be better served with a single way of handling multi-access links. If >>I'm the only one with this concern then I'll relent. >> > > It wouldn't be better served changing something *that works and > interoperates* at the last minute. > > New wording (the part after the semicolon is new): > > | If the Link Type of the link is Multiaccess, the Remote > | Interface IP Addess is set to 0.0.0.0; alternatively, an implementation > | MAY choose not to send this sub-TLV. > > >>>However, if you think that the new wording is preferable, I will >>>change this to "Operation over multiaccess links with more than two >>>devices is not specifically prohibited. More accurate description of >>>the reservation state of multi-access networks is for further study." >>> >> >>There was considerable discussion on this topic and I believe >>this a good addition. >> > > Done. New wording: > > | The reservation state of multiaccess > | links may not be accurately reflected, except in the special case that > | there are only two devices in the multiaccess subnetwork. Operation > | over multiaccess networks with more than two devices is not specifically > | prohibited. More accurate description of the reservation state of > | multi-access networks is for further study. > > Note one other minor change: "reservation state ... is not ..." to > "reservation state ... may not be ..." > > Can we ship this out now? > > Kireeti. > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 14:49:58 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29603 for ; Wed, 23 Oct 2002 14:49:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0078B348@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 14:52:12 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 332520 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 14:52:11 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 14:52:10 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 99B71473CC6 for ; Wed, 23 Oct 2002 11:52:10 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20021021221103.4F631133EC@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB6EF8B.1040007@redback.com> Date: Wed, 23 Oct 2002 14:50:51 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: 55th IETF OSPF WG Meeting To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Don Goodspeed wrote: > Thanks Acee. > > Is the new hitless restart draft still being done by > John, or have you and/or others taken over as authors? Don, The tentative plan is to refresh the draft in pretty much it's current form with Padma and myself as co-authors. As available, John will be consulted. This makes sense since Juniper and Redback both have deployed implemenations of the hitless restart draft. Hopefully, in 2 - 3 weeks we can iron out any difference as well as go through list archives to see if there are comments that need to be addressed. If all goes well, we'll reissue the draft and request a WG last call. Thanks, > > Is there a link that can be added to the IETF OSPF WG page > that lists the status of each draft, or can this be added > after each document link on the WG page? > > -don > > --- On Mon 10/21, Acee Lindem wrote: > From: Acee Lindem [mailto: acee@REDBACK.COM] > To: OSPF@DISCUSS.MICROSOFT.COM > Date: Mon, 21 Oct 2002 17:23:07 -0400 > Subject: Re: 55th IETF OSPF WG Meeting > > >>Don Goodspeed wrote: >> >> >>>The current Hitless Restart draft (-02) has expired. Will there be >>>a new version submitted in time for IETF? >>> >> >>Yes. >> >> >> >>>Also, is the NSSA update up for LastCall? >>> >> >>The -09 version went through working group last call a while back. >>Several comments have been ironed out since then and the -11 version >>has gone thought IETF last call. See link below. >> >> >> >> >> >> >> >>>-don >>> >>> --- On Fri 10/11, Acee Lindem wrote: >>>From: Acee Lindem [mailto: acee@REDBACK.COM] >>>To: OSPF@DISCUSS.MICROSOFT.COM >>>Date: Fri, 11 Oct 2002 00:51:48 -0400 >>>Subject: 55th IETF OSPF WG Meeting >>> >>> >>> >>>>The OSPF WG will be meeting in Atlanta (although I haven't >>>> >>received >> >>>>confirmation of the date/time yet). >>>> >>>>Those of you wishing to present at the WG meeting should send a >>>>note to Rohit (rohit@xebeo.com) and myself. The WG agenda must be >>>>submitted by 11/14. >>>> >>>>Also note that New I-Ds (the -00 versions) must be sent to >>>>internet-drafts@ietf.org by 10/28 and that all updated drafts >>>>must be submitted by 11/4. >>>> >>>> >>>>Thanks, >>>>-- >>>>Acee >>>> >>>> >>>> >>>_______________________________________________ >>>Join Excite! - http://www.excite.com >>>The most personalized portal on the Web! >>> >>> >>> >> >>-- >>Acee >> >> > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 14:51:14 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29666 for ; Wed, 23 Oct 2002 14:51:14 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0078B1E3@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 14:53:30 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 332558 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 14:53:28 -0400 Received: from 207.159.120.58 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 14:53:28 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id E5E1F29A3B; Wed, 23 Oct 2002 14:53:26 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe23.nwk.excite.com via HTTP; Wed, 23 Oct 2002 14:53:26 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20021023185326.E5E1F29A3B@xmxpita.excite.com> Date: Wed, 23 Oct 2002 14:53:26 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit With these changes, I have no further issues. Looks good!. -don --- On Wed 10/23, Acee Lindem wrote: From: Acee Lindem [mailto: acee@REDBACK.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Wed, 23 Oct 2002 14:22:39 -0400 Subject: Re: Comments on draft-katz-yeung-traffic-08.txt > Sounds good to me. > > Kireeti Kompella wrote: > > > Hi Acee, > > > > On Tue, 22 Oct 2002, Acee Lindem wrote: > > > > > >>I don't expect to have any comments on IETF wide last call. > >> > > > > Can I hold you to that? :-) > > > > > >>>This is a nitpick. > >>> > >>Have you ever met a programmer who didn't? > >> > > > > None that I respect :-) > > > > > >>I was just thinking that a document going to proposed standard > would > >>be better served with a single way of handling multi-access links. > If > >>I'm the only one with this concern then I'll relent. > >> > > > > It wouldn't be better served changing something *that works and > > interoperates* at the last minute. > > > > New wording (the part after the semicolon is new): > > > > | If the Link Type of the link is Multiaccess, the Remote > > | Interface IP Addess is set to 0.0.0.0; alternatively, an > implementation > > | MAY choose not to send this sub-TLV. > > > > > >>>However, if you think that the new wording is preferable, I > will > >>>change this to "Operation over multiaccess links with > more than two > >>>devices is not specifically prohibited. More accurate > description of > >>>the reservation state of multi-access networks is for further > study." > >>> > >> > >>There was considerable discussion on this topic and I believe > >>this a good addition. > >> > > > > Done. New wording: > > > > | The reservation state of multiaccess > > | links may not be accurately reflected, except in the special case > that > > | there are only two devices in the multiaccess subnetwork. > Operation > > | over multiaccess networks with more than two devices is not > specifically > > | prohibited. More accurate description of the reservation state of > > | multi-access networks is for further study. > > > > Note one other minor change: "reservation state ... is not > ..." to > > "reservation state ... may not be ..." > > > > Can we ship this out now? > > > > Kireeti. > > > > > > > -- > Acee > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 16:42:20 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04732 for ; Wed, 23 Oct 2002 16:42:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0078B5D3@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 16:44:36 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 333005 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 16:44:36 -0400 Received: from 207.159.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 16:44:36 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id D709C3DEC; Wed, 23 Oct 2002 16:44:33 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe11.nwk.excite.com via HTTP; Wed, 23 Oct 2002 16:44:33 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20021023204433.D709C3DEC@xmxpita.excite.com> Date: Wed, 23 Oct 2002 16:44:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, On the issue of updating the grace period, I would only update in case the reason code changed, and changed to a value of unknown (and/or we could add a new "unplanned restart" reason code). Also, I remember a while back a discussion on the list between yourself, Padma, and John regarding the IP address field in the Grace LSA. I cannot remember the specific issue, but I assume there's been a resolution (or at least an understanding)? Finally, there was also a previous discussion I was involved in regarding contraining the grace period to a max value of MaxAge (3600). Is this being included in the new draft? Thanks, Don --- On Tue 10/22, Acee Lindem wrote: From: Acee Lindem [mailto: acee@REDBACK.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Tue, 22 Oct 2002 14:49:37 -0400 Subject: Re: Hitless restart > Manral, Vishwas wrote: > > > Hi Acee, > > > > I agree to Padma's statement that we are using link-local LSA to > signal > > hitless-restart, because we would not want the LSA to be flooded by > the > > neighbors into the area. We are signalling router parameters in the > link > > local LSA. > > > > Regarding 2. > > - I think we should update the grace-period/reason only when we have > a > > change in content of the Grace LSA from the neighbor to the > restarting > > router on any interface. So if we get a different value of > > grace-period/restart reason we update and restart the grace period on > the > > helper else we do not. This would be in keeping with Section 3 of the > draft. > > > Vishwas, > > I agree that if we do agree to change the existing specification than we > should, in fact, honor changes to the grace-period/restart-reason. One > of my concerns with this approach is the added complexity (consider > determining which of multiple link local LSAs received on different > links is more recent). > > Thanks, > > Acee > > > > - I think the first grace LSA withdrawn would cause the router to > exit > > hitless restart mode for that neighbor. > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Acee Lindem [mailto:acee@REDBACK.COM] > > Sent: Tuesday, October 22, 2002 8:22 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: Hitless restart > > > > > > All, > > > > I think we have a "rough concensus" that the restarting > router > > should NOT try to optimize flooding of grace LSAs. I've > > only had one vote for this and I believe the vote was more > > for flooding optimizations in general than this particular > > scenario. > > > > > > Padma, > > > > I don't think it simplifies the helper code (or specification) > > to apply the grace LSA to all neighbor instances of restarting > > router. Here are my reasons: > > > > 1. Conceptually, I don't think it is right to apply the link > > local grace LSA to neighbors that are not on the link. > > > > 2. There are simply more corner cases - > > > > - When you receive a second grace LSA from the restarting > > router, do you update the reason and grace period for > > all neighbor instances or only ones on that segment? > > > > - When do exit helper mode? Is it when the first grace > > LSA is withdrawn or all the grace LSAs? I certainly don't > > think there should be disconnect between entering and > > exiting helper mode. > > > > I do agree that it is somewhat more robust for the case where > > you are adjacent with the same router on more than one link. > > However, I don't see this as a real big gain. Has anyone > > else implemented this draft? > > > > Thanks, > > Acee > > > > > > > > Padma Pillay-Esnault wrote: > > > > > >>Rajesh > >> > >> > >>Rajesh Varadarajan wrote: > >> > >> > >>>Acee, Padma, > >>> > >>> > >> > >> > >>>>>>>I do think it simplifies things if a > restarting router originates the > >>>>>>> > > grace LSAs > > > >>>>>>>on all it's interfaces (or at least all with > full neighbor > >>>>>>> > >>>>>>> > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > >> > >>>>>>>adjacencies if it a planned restart). > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>The above statement seems to imply (my reading) that a > restarting router > >>> > >>>can only send Grace LSA's out of some (not all) of its > interfaces. The > >>> > >>> > >>It doesn't imply that - clearly we send to all our neighbors. > >> > >>Padma > >> > >> > >>>spec however requires the router to send the grace-lsa out of > all > >>>interfaces on which it has full neigbhors. Failure to do so > would always > >>>result in its helper mode being terminated by others. > >>> > >>> > >> > >> > >>>>>>I also agree with you .. that's what I do - the > restarting router sends > >>>>>>grace lsa over all interfaces. But from a Helping > router perspective > >>>>>>we should do as in 00-txt. It simplifies the > helper code. > >>>>>>It also prevents corner cases where we might not > help all adjacencies > >>>>>>(when we should). > >>>>>> > >>>>>>Padma > >>>>>> > >>>>>> > >>>>>I haven't heard anyone object to why the 00-txt. > >>>>> > >>>>> > >>>>I will - I specifically agree with > >>>> > >>>> > >>>> > >>>> Note that Router Y only needs to receive a single > grace-LSA from > >>>> X, even if X and Y attach to multiple common > segments. > >>>> > >>>>I don't like using an LSA with link local scope to > enter/terminate > >>>>helper mode for neighbors on different interfaces. It is > better if the > >>>>link local grace LSA only applies to that link. > >>>> > >>>> > >>>Given the behavior above, I think the each neighbor should be > considered > >>>independently on a segment by segment basis. > >>> > >>> > >>>thanks, > >>>rajesh > >>> > >>> > >>> > > > > > > -- > > Acee > > > > > > > -- > Acee > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 23:19:31 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15230 for ; Wed, 23 Oct 2002 23:19:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0078C6AE@cherry.ease.lsoft.com>; Wed, 23 Oct 2002 23:21:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 333828 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Oct 2002 23:21:46 -0400 Received: from 192.75.23.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 23 Oct 2002 23:11:45 -0400 Received: (qmail 21102 invoked from network); 24 Oct 2002 03:17:00 -0000 Received: (ofmipd 138.120.118.71); 24 Oct 2002 03:16:38 -0000 Received: from alcatel.com ([138.120.250.22]) by kanmail01.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA3648; Wed, 23 Oct 2002 23:11:43 -0400 X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <01fb01c27a79$2b04c6c0$02016464@kirans> <3DB6ADBB.50104@redback.com> <02b001c27aa5$d5f83040$02016464@kirans> <3DB6C935.4010103@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3DB764A0.21E12FE4@alcatel.com> Date: Wed, 23 Oct 2002 23:10:24 -0400 Reply-To: Mailing List Sender: Mailing List From: Cheng-Yin Lee Subject: Re: DR / BDR election on different links configured as on same subnet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kiran,Delia, Why don't you view this as routers (R1,R2,R3) peering over a VLAN? I think it's cleaner to view it this way. regards cheng-yin Acee Lindem wrote: > > Kiran, > > What you are describing is one way of bridging and routing on > the same port. I'm sure there are a number of vendors that > support this but people shouldn't be confused into to thinking > that this is normal router forwarding. > > Kiran S wrote: > > > Acce, > > > > > >>The reason that this setup is not described anywhere is that it is > >>non-standard. It is uncommon for a router to support multiple > >>interfaces on the same subnet. > >> > > > > I donot know whether you misunderstood by the way I used the term > > "interface". The interface which was desribed is not the logical interface > > at IP. It is the hardware port. In the case of forming a VLAN , many > > hardware ports can join a single VLAN and this VLAN can have a single > > subnet. This VLAN is mapped to the logical interface at IP, the interface > > you are specifying. This logical IP interface is in a subnet. > > So, R1 , R2 , R3 belong to the same subnet and broadcast domain. > > > > I have seen a typical example in metro ethernet network. > > It is similiar to the network shown by Delia. R1 and R2 was in a location > > and it was in back bone area. R3 is located in a different location. They > > need to connect R3 to the back bone area by connecting it to the GBIC port > > of the R2 using optical fibre cable. R2's GBIC port and R3's GBIC port join > > same VLAN and has this VLAN belong to the same subnet. In this case R3 > > cannot find R1 as a neighbour and R1 cannot find R3 as neigbour, if R2 > > doesnot duplicate the OSPF packets and forward to R3 and R1 ports. > > > > > > Thanks > > > > Cheers > > Kiran > > > > > > ----- Original Message ----- > > From: "Acee Lindem" > > To: > > Sent: Wednesday, October 23, 2002 11:10 PM > > Subject: Re: DR / BDR election on different links configured as on same > > subnet > > > > > > > >>Kiran, Delia, > >> > >>The reason that this setup is not described anywhere is that it is > >>non-standard. It is uncommon for a router to support multiple > >>interfaces on the same subnet. If a router does support multiple > >>interfaces on the same subnet and the topology is broadcast then > >>the network (not R2) would need to assure that a broadcast/multicast > >>packet sent by R1 would be received by R3. The forwarding discussed > >>below is not expected (unless R2 is bridging). > >> > >>Thanks, > >>Acee > >> > >>Kiran S wrote: > >> > >> > >>>Hi Delia, > >>> > >>> Your network setup is R1, R2, R3 are in same broadcast domain (eg. in > >>> > > same > > > >>>VLAN and same subnet) and R1 and R3 are connected to the two differnet > >>>interfaces/ports of R2 and all belong to the same subnet a.b.c.0 right > >>> > > ? > > > >>>>Should DR and BDR mechanism be also applied to this scenario, that is > >>>> > > R1, > > > >>>>R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. > >>>> > >>>> > >>>A common DR and BDR election can be done only if R2 takes the multicast > >>> > > OSPF > > > >>>packets (eg. hello , DBD, LS packets ) from R1 and forwards to R3 and > >>> > > send > > > >>>to itself. Similiarly all the multicast packets from R3 are send to R1 > >>> > > and > > > >>>to itself. It means to make this a complete broadcast domain of same > >>> > > subnet > > > >>>for the OSPF routers you need to duplicate all the mulitcast OSPF > >>> > > packets at > > > >>>R2. If this is done, a common DR and BDR election is possible. > >>>we neednot duplicate the unicast OSPF routing packets It will get > >>> > > routed by > > > >>>L2 or L3 to the correct interface. right ? > >>>If we donot do this R3 will have only one neighbour (R2) and R1 will > >>> > > also > > > >>>have only one neighbour (R2). R2 will have two neighbours R1 and R3. And > >>>there will be either "two DRs" or "one DR" in this set up. (If R2 > >>> > > advertises > > > >>>as DR then R3 and R1 will be BDR. and if R2 is BDR then R1 and R3 will > >>> > > be > > > >>>DRs.).. > >>> > >>> > >>> > >>>>Therefore if R1 > >>>>and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to > >>>> > > both > > > >>>>links, in order to reach both DR and BDR? In my opinion it should not. I > >>>> > >>>> > >>>am > >>> > >>> > >>>>told that it should, as this would be a particular case of OSPF support > >>>> > >>>> > >>>for > >>> > >>> > >>>>layer 2 switching. > >>>> > >>>> > >>>how can R1 and R3 can become a common DR and BDR without even R2 > >>> > > duplicating > > > >>>the packets from R1 and from R3. ? R2 needs to duplicate the incoming > >>> > > OSPF > > > >>>mulicast routing packets from its interfaces/ports and forward to the > >>> > > other > > > >>>interfaces/ports of same subnet and send a copy to itself. The OSPF > >>> > > routing > > > >>>PDUs from R2 will naturally get forwarded to all the interfaces on the > >>> > > same > > > >>>subnet if it a multicast packet. So there is no need for any new > >>> > > duplication > > > >>>of the packets from R2 itself. > >>>Am I right ? > >>> > >>> > >>> > >>>>In my opinion it should not. I am > >>>>told that it should, as this would be a particular case of OSPF support > >>>> > >>>> > >>>for > >>> > >>> > >>>>layer 2 switching. > >>>> > >>>> > >>>Please let me know if you have a method to accomplish the common DR/BDR > >>>election without duplicating the packets at R2. Or do you feel there is > >>> > > no > > > >>>need for it ? > >>> > >>> > >>> > >>>>Is there some specification in an RFC about this? > >>>> > >>>> > >>>I also don't find any RFC saying about this. If some body knows, it will > >>> > > be > > > >>>helpful. > >>> > >>>Thanks > >>> > >>>Cheers > >>>Kiran > >>> > >>> > >>>----- Original Message ----- > >>>From: "Delia Kecskemeti" > >>>To: > >>>Sent: Wednesday, October 23, 2002 3:51 AM > >>>Subject: DR / BDR election on different links configured as on same > >>> > > subnet > > > >>> > >>> > >>>>Hi, > >>>> > >>>>I need to find out how is OSPF supposed to act in this particular case: > >>>>Link between routers R1 and R2 and link between R2 and R3 are configured > >>>> > >>>> > >>>to > >>> > >>> > >>>>be on the same subnet, say: > >>>>a.b.c.x / 24 > >>>>In my understanding, the DR / BDR mechanism is applied on one broadcast > >>>> > >>>> > >>>link > >>> > >>> > >>>>to which several routers attach, to minimize number of adjacencies and > >>>>network burden on that link. > >>>> > >>>>Should DR and BDR mechanism be also applied to this scenario, that is > >>>> > > R1, > > > >>>>R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. Therefore if > >>>> > >>>> > >>>R1 > >>> > >>> > >>>>and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to > >>>> > > both > > > >>>>links, in order to reach both DR and BDR? In my opinion it should not. I > >>>> > >>>> > >>>am > >>> > >>> > >>>>told that it should, as this would be a particular case of OSPF support > >>>> > >>>> > >>>for > >>> > >>> > >>>>layer 2 switching. Is there some specification in an RFC about this? > >>>> > >>>>R1-----------R2-----------R3 > >>>> > >>>>Thank you very much and have a nice day, > >>>>Delia > >>>> > >>>> > >> > >>-- > >>Acee > >> > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 23 23:59:51 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16210 for ; Wed, 23 Oct 2002 23:59:51 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0078C878@cherry.ease.lsoft.com>; Thu, 24 Oct 2002 0:02:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 333969 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 24 Oct 2002 00:02:08 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 24 Oct 2002 00:02:07 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 056021DCC79 for ; Wed, 23 Oct 2002 21:02:05 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <20021023204433.D709C3DEC@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB77069.4080708@redback.com> Date: Thu, 24 Oct 2002 00:00:41 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Don, Don Goodspeed wrote: > Acee, > > On the issue of updating the grace period, I would only > update in case the reason code changed, and changed to > a value of unknown (and/or we could add a new "unplanned > restart" reason code). I'm not sure there is any difference between unknown and unplanned. > > Also, I remember a while back a discussion on the list > between yourself, Padma, and John regarding the IP address > field in the Grace LSA. I cannot remember the specific issue, > but I assume there's been a resolution (or at least an > understanding)? This was the comment that Padma made that the IP interface address TLV is not necessary to identify the restarting neighbor on multi-access (broadcast and NBMA) links. I pointed out that it wasn't really necessary since the grace LSA was already scoped to an OSPF interface and there could only be one neighbor adjacency corresponding to the router ID (even if one was running OSPF on more than one subnet). John pointed out that OSPFv2 always uses the IP interface address to identify neighboring routers on multi-access networks so it should included to be consistent with the RFC 2328 (numerous sections). I tend to agree with this and would vote to leave it in. However, it is not needed for OSPFv3 since here neighboring routers are always identified by router ID. > > Finally, there was also a previous discussion I was involved > in regarding contraining the grace period to a max value of > MaxAge (3600). Is this being included in the new draft? That could be documented. > > Thanks, > Don > > --- On Tue 10/22, Acee Lindem wrote: > From: Acee Lindem [mailto: acee@REDBACK.COM] > To: OSPF@DISCUSS.MICROSOFT.COM > Date: Tue, 22 Oct 2002 14:49:37 -0400 > Subject: Re: Hitless restart > > >>Manral, Vishwas wrote: >> >> >>>Hi Acee, >>> >>>I agree to Padma's statement that we are using link-local LSA to >>> >>signal >> >>>hitless-restart, because we would not want the LSA to be flooded by >>> >>the >> >>>neighbors into the area. We are signalling router parameters in the >>> >>link >> >>>local LSA. >>> >>>Regarding 2. >>>- I think we should update the grace-period/reason only when we have >>> >>a >> >>>change in content of the Grace LSA from the neighbor to the >>> >>restarting >> >>>router on any interface. So if we get a different value of >>>grace-period/restart reason we update and restart the grace period on >>> >>the >> >>>helper else we do not. This would be in keeping with Section 3 of the >>> >>draft. >> >> >>Vishwas, >> >>I agree that if we do agree to change the existing specification than we >>should, in fact, honor changes to the grace-period/restart-reason. One >>of my concerns with this approach is the added complexity (consider >>determining which of multiple link local LSAs received on different >>links is more recent). >> >>Thanks, >> >>Acee >> >> >> >>>- I think the first grace LSA withdrawn would cause the router to >>> >>exit >> >>>hitless restart mode for that neighbor. >>> >>>Thanks, >>>Vishwas >>> >>>-----Original Message----- >>>From: Acee Lindem [mailto:acee@REDBACK.COM] >>>Sent: Tuesday, October 22, 2002 8:22 PM >>>To: OSPF@DISCUSS.MICROSOFT.COM >>>Subject: Re: Hitless restart >>> >>> >>>All, >>> >>>I think we have a "rough concensus" that the restarting >>> >>router >> >>>should NOT try to optimize flooding of grace LSAs. I've >>>only had one vote for this and I believe the vote was more >>>for flooding optimizations in general than this particular >>>scenario. >>> >>> >>>Padma, >>> >>>I don't think it simplifies the helper code (or specification) >>>to apply the grace LSA to all neighbor instances of restarting >>>router. Here are my reasons: >>> >>> 1. Conceptually, I don't think it is right to apply the link >>> local grace LSA to neighbors that are not on the link. >>> >>> 2. There are simply more corner cases - >>> >>> - When you receive a second grace LSA from the restarting >>> router, do you update the reason and grace period for >>> all neighbor instances or only ones on that segment? >>> >>> - When do exit helper mode? Is it when the first grace >>> LSA is withdrawn or all the grace LSAs? I certainly don't >>> think there should be disconnect between entering and >>> exiting helper mode. >>> >>>I do agree that it is somewhat more robust for the case where >>>you are adjacent with the same router on more than one link. >>>However, I don't see this as a real big gain. Has anyone >>>else implemented this draft? >>> >>>Thanks, >>>Acee >>> >>> >>> >>>Padma Pillay-Esnault wrote: >>> >>> >>> >>>>Rajesh >>>> >>>> >>>>Rajesh Varadarajan wrote: >>>> >>>> >>>> >>>>>Acee, Padma, >>>>> >>>>> >>>>> >>>> >>>>>>>>>I do think it simplifies things if a >>>>>>>>> >>restarting router originates the >> >>>grace LSAs >>> >>> >>>>>>>>>on all it's interfaces (or at least all with >>>>>>>>> >>full neighbor >> >>>>>>>>> >>>>^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> >>>> >>>> >>>>>>>>>adjacencies if it a planned restart). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>The above statement seems to imply (my reading) that a >>>>> >>restarting router >> >>>>>can only send Grace LSA's out of some (not all) of its >>>>> >>interfaces. The >> >>>>> >>>>It doesn't imply that - clearly we send to all our neighbors. >>>> >>>>Padma >>>> >>>> >>>> >>>>>spec however requires the router to send the grace-lsa out of >>>>> >>all >> >>>>>interfaces on which it has full neigbhors. Failure to do so >>>>> >>would always >> >>>>>result in its helper mode being terminated by others. >>>>> >>>>> >>>>> >>>> >>>>>>>>I also agree with you .. that's what I do - the >>>>>>>> >>restarting router sends >> >>>>>>>>grace lsa over all interfaces. But from a Helping >>>>>>>> >>router perspective >> >>>>>>>>we should do as in 00-txt. It simplifies the >>>>>>>> >>helper code. >> >>>>>>>>It also prevents corner cases where we might not >>>>>>>> >>help all adjacencies >> >>>>>>>>(when we should). >>>>>>>> >>>>>>>>Padma >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>I haven't heard anyone object to why the 00-txt. >>>>>>> >>>>>>> >>>>>>> >>>>>>I will - I specifically agree with >>>>>> >>>>>> >>>>>> >>>>>> Note that Router Y only needs to receive a single >>>>>> >>grace-LSA from >> >>>>>> X, even if X and Y attach to multiple common >>>>>> >>segments. >> >>>>>>I don't like using an LSA with link local scope to >>>>>> >>enter/terminate >> >>>>>>helper mode for neighbors on different interfaces. It is >>>>>> >>better if the >> >>>>>>link local grace LSA only applies to that link. >>>>>> >>>>>> >>>>>> >>>>>Given the behavior above, I think the each neighbor should be >>>>> >>considered >> >>>>>independently on a segment by segment basis. >>>>> >>>>> >>>>>thanks, >>>>>rajesh >>>>> >>>>> >>>>> >>>>> >>> >>>-- >>>Acee >>> >>> >>> >> >>-- >>Acee >> >> > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 24 00:07:07 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16324 for ; Thu, 24 Oct 2002 00:07:06 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0078C84C@cherry.ease.lsoft.com>; Thu, 24 Oct 2002 0:09:20 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 334009 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 24 Oct 2002 00:09:20 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 24 Oct 2002 00:09:20 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) id <0H4G00L01X5Z89@mailout1.samsung.com> for ospf@dISCUSS.MICROSOFT.COM; Thu, 24 Oct 2002 13:15:35 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H4G00K6ZX5YV2@mailout1.samsung.com> for ospf@dISCUSS.MICROSOFT.COM; Thu, 24 Oct 2002 13:15:35 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0H4G0057LX6Z5B@mmp2.samsung.com> for ospf@dISCUSS.MICROSOFT.COM; Thu, 24 Oct 2002 13:16:13 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 X-Priority: 3 X-MSMail-priority: Normal Message-ID: <00b401c27b12$e5d78610$b4036c6b@sisodomain.com> Date: Thu, 24 Oct 2002 09:37:39 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: How to partition a routing domain into areas in the first place? Comments: cc: binl@EEE-FS7.BHAM.AC.UK To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id AAA16324 Liu, Are you looking into - ways to divide areas at the core/distribution boundary - doing summarizations at core (i dont recommend that) - ways to reduce flooding in an area caused by dial-in users - etc. You could either put your core routers as ABRs or your distribution layer routers as ABRs. There are advantages and disadvantages in both of these techniques. Can you tell me as to what exactly is that you want to know? Lets not spam this mailing list. You can mail me offline. Regards, Manav ----- Original Message ----- From: "Liu B." To: Sent: Wednesday, October 23, 2002 5:55 PM Subject: Re: How to partition a routing domain into areas in the first pla ce? Dear Manav, Thanks for your information. I've found that book in Amazon, which costs about £43, a bit too much to a student :-( I've done the search in IEEEXplore by the authors, but no lucky so far :-(( Is there any paper you would like to recomment about how to design the hierrarchy (i.e., how to divide the network into areas), especially for large-scale networks? Thank you very much, as well as other people's information in advance. Bin Liu -----Original Message----- From: Manav Bhatia [mailto:manav@SAMSUNG.COM] Sent: Wednesday, October 23, 2002 4:43 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: How to partition a routing domain into areas in the first place? Liu, OSPF has 2 level hierarchy (core and areas hanging off the core) while the networks have 3 level (core, distribution and access) so there can be some confusion in mapping OSPF onto real live networks. There is this book "Advanced IP Network Design" by Alvaro Retana, Don Slice and Russ White (ISBN 1-57870-097-3 - Cisco Press) which discusses OSPF Network Design in some detail by considering ways to divide the network into areas, points where summarization can be done, issues with dial backup and ways to handle dial-in-clients/external connections to the network, etc. It may help you in clarifying some of your doubts. Regards, Manav ----- Original Message ----- From: "Liu B." To: Sent: Tuesday, October 22, 2002 7:18 PM Subject: How to partition a routing domain into areas in the first place? > Hi, > > Understanding that the area routing is used in OSPF for better routing > performance (e.g., reduce routing cost). But given a large-scale network, > how to do partitioning according to the topology of network in the first > place? As the topology of most part of the Internet is irregular or mesh, my > question, more specifically, is -- how to do partitioning in a given > large-scale mesh network? > > Thanks in advance for any answer, reference or thought. > > Bin -- Never argue with idiots. They drag you down to their level, then beat you with experience. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 24 02:11:26 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27493 for ; Thu, 24 Oct 2002 02:11:26 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0078CE0F@cherry.ease.lsoft.com>; Thu, 24 Oct 2002 2:13:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 334216 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 24 Oct 2002 02:13:42 -0400 Received: from 211.202.13.143 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 24 Oct 2002 02:13:42 -0400 Received: from [211.215.120.77] by mo01.hanafos.com (Terrace Internet Messaging Server 3.220) with ESMTP id 2002102415:12:31:056163.20598.2711 for ; Thu, 24 Oct 2002 15:12:30 +0900 (KST) References: <01fb01c27a79$2b04c6c0$02016464@kirans> <3DB6ADBB.50104@redback.com> <02b001c27aa5$d5f83040$02016464@kirans> <3DB6C935.4010103@redback.com> <3DB764A0.21E12FE4@alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <045501c27b24$965b4c40$02016464@kirans> Date: Thu, 24 Oct 2002 15:14:18 +0900 Reply-To: Mailing List Sender: Mailing List From: Kiran S Subject: Re: DR / BDR election on different links configured as on same subnet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Cheng-yin, Yep... It is R1, R2, R3 peering over a same VLAN and subnet. The setup will be more clear if we connect all these OSPF routers to a L2 switch or hub. In this case there will be a common DR/BDR election. But now the physical connection R1---R2---R3 and all belong to same subnet. This is a typical network connection, and this network looks logical. Any RFCs/standard stating how well we can handle this situation ? Thanks. ! Cheers Kiran ----- Original Message ----- From: "Cheng-Yin Lee" To: Sent: Thursday, October 24, 2002 12:10 PM Subject: Re: DR / BDR election on different links configured as on same subnet > Kiran,Delia, > Why don't you view this as routers (R1,R2,R3) peering over a VLAN? I > think it's cleaner to view it this way. > > regards > cheng-yin > > Acee Lindem wrote: > > > > Kiran, > > > > What you are describing is one way of bridging and routing on > > the same port. I'm sure there are a number of vendors that > > support this but people shouldn't be confused into to thinking > > that this is normal router forwarding. > > > > Kiran S wrote: > > > > > Acce, > > > > > > > > >>The reason that this setup is not described anywhere is that it is > > >>non-standard. It is uncommon for a router to support multiple > > >>interfaces on the same subnet. > > >> > > > > > > I donot know whether you misunderstood by the way I used the term > > > "interface". The interface which was desribed is not the logical interface > > > at IP. It is the hardware port. In the case of forming a VLAN , many > > > hardware ports can join a single VLAN and this VLAN can have a single > > > subnet. This VLAN is mapped to the logical interface at IP, the interface > > > you are specifying. This logical IP interface is in a subnet. > > > So, R1 , R2 , R3 belong to the same subnet and broadcast domain. > > > > > > I have seen a typical example in metro ethernet network. > > > It is similiar to the network shown by Delia. R1 and R2 was in a location > > > and it was in back bone area. R3 is located in a different location. They > > > need to connect R3 to the back bone area by connecting it to the GBIC port > > > of the R2 using optical fibre cable. R2's GBIC port and R3's GBIC port join > > > same VLAN and has this VLAN belong to the same subnet. In this case R3 > > > cannot find R1 as a neighbour and R1 cannot find R3 as neigbour, if R2 > > > doesnot duplicate the OSPF packets and forward to R3 and R1 ports. > > > > > > > > > Thanks > > > > > > Cheers > > > Kiran > > > > > > > > > ----- Original Message ----- > > > From: "Acee Lindem" > > > To: > > > Sent: Wednesday, October 23, 2002 11:10 PM > > > Subject: Re: DR / BDR election on different links configured as on same > > > subnet > > > > > > > > > > > >>Kiran, Delia, > > >> > > >>The reason that this setup is not described anywhere is that it is > > >>non-standard. It is uncommon for a router to support multiple > > >>interfaces on the same subnet. If a router does support multiple > > >>interfaces on the same subnet and the topology is broadcast then > > >>the network (not R2) would need to assure that a broadcast/multicast > > >>packet sent by R1 would be received by R3. The forwarding discussed > > >>below is not expected (unless R2 is bridging). > > >> > > >>Thanks, > > >>Acee > > >> > > >>Kiran S wrote: > > >> > > >> > > >>>Hi Delia, > > >>> > > >>> Your network setup is R1, R2, R3 are in same broadcast domain (eg. in > > >>> > > > same > > > > > >>>VLAN and same subnet) and R1 and R3 are connected to the two differnet > > >>>interfaces/ports of R2 and all belong to the same subnet a.b.c.0 right > > >>> > > > ? > > > > > >>>>Should DR and BDR mechanism be also applied to this scenario, that is > > >>>> > > > R1, > > > > > >>>>R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. > > >>>> > > >>>> > > >>>A common DR and BDR election can be done only if R2 takes the multicast > > >>> > > > OSPF > > > > > >>>packets (eg. hello , DBD, LS packets ) from R1 and forwards to R3 and > > >>> > > > send > > > > > >>>to itself. Similiarly all the multicast packets from R3 are send to R1 > > >>> > > > and > > > > > >>>to itself. It means to make this a complete broadcast domain of same > > >>> > > > subnet > > > > > >>>for the OSPF routers you need to duplicate all the mulitcast OSPF > > >>> > > > packets at > > > > > >>>R2. If this is done, a common DR and BDR election is possible. > > >>>we neednot duplicate the unicast OSPF routing packets It will get > > >>> > > > routed by > > > > > >>>L2 or L3 to the correct interface. right ? > > >>>If we donot do this R3 will have only one neighbour (R2) and R1 will > > >>> > > > also > > > > > >>>have only one neighbour (R2). R2 will have two neighbours R1 and R3. And > > >>>there will be either "two DRs" or "one DR" in this set up. (If R2 > > >>> > > > advertises > > > > > >>>as DR then R3 and R1 will be BDR. and if R2 is BDR then R1 and R3 will > > >>> > > > be > > > > > >>>DRs.).. > > >>> > > >>> > > >>> > > >>>>Therefore if R1 > > >>>>and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to > > >>>> > > > both > > > > > >>>>links, in order to reach both DR and BDR? In my opinion it should not. I > > >>>> > > >>>> > > >>>am > > >>> > > >>> > > >>>>told that it should, as this would be a particular case of OSPF support > > >>>> > > >>>> > > >>>for > > >>> > > >>> > > >>>>layer 2 switching. > > >>>> > > >>>> > > >>>how can R1 and R3 can become a common DR and BDR without even R2 > > >>> > > > duplicating > > > > > >>>the packets from R1 and from R3. ? R2 needs to duplicate the incoming > > >>> > > > OSPF > > > > > >>>mulicast routing packets from its interfaces/ports and forward to the > > >>> > > > other > > > > > >>>interfaces/ports of same subnet and send a copy to itself. The OSPF > > >>> > > > routing > > > > > >>>PDUs from R2 will naturally get forwarded to all the interfaces on the > > >>> > > > same > > > > > >>>subnet if it a multicast packet. So there is no need for any new > > >>> > > > duplication > > > > > >>>of the packets from R2 itself. > > >>>Am I right ? > > >>> > > >>> > > >>> > > >>>>In my opinion it should not. I am > > >>>>told that it should, as this would be a particular case of OSPF support > > >>>> > > >>>> > > >>>for > > >>> > > >>> > > >>>>layer 2 switching. > > >>>> > > >>>> > > >>>Please let me know if you have a method to accomplish the common DR/BDR > > >>>election without duplicating the packets at R2. Or do you feel there is > > >>> > > > no > > > > > >>>need for it ? > > >>> > > >>> > > >>> > > >>>>Is there some specification in an RFC about this? > > >>>> > > >>>> > > >>>I also don't find any RFC saying about this. If some body knows, it will > > >>> > > > be > > > > > >>>helpful. > > >>> > > >>>Thanks > > >>> > > >>>Cheers > > >>>Kiran > > >>> > > >>> > > >>>----- Original Message ----- > > >>>From: "Delia Kecskemeti" > > >>>To: > > >>>Sent: Wednesday, October 23, 2002 3:51 AM > > >>>Subject: DR / BDR election on different links configured as on same > > >>> > > > subnet > > > > > >>> > > >>> > > >>>>Hi, > > >>>> > > >>>>I need to find out how is OSPF supposed to act in this particular case: > > >>>>Link between routers R1 and R2 and link between R2 and R3 are configured > > >>>> > > >>>> > > >>>to > > >>> > > >>> > > >>>>be on the same subnet, say: > > >>>>a.b.c.x / 24 > > >>>>In my understanding, the DR / BDR mechanism is applied on one broadcast > > >>>> > > >>>> > > >>>link > > >>> > > >>> > > >>>>to which several routers attach, to minimize number of adjacencies and > > >>>>network burden on that link. > > >>>> > > >>>>Should DR and BDR mechanism be also applied to this scenario, that is > > >>>> > > > R1, > > > > > >>>>R2, R3 would elect a DR and BDR for that subnet a.b.c.0/24. Therefore if > > >>>> > > >>>> > > >>>R1 > > >>> > > >>> > > >>>>and R3 are the DR and BDR, then R2 would duplicate sending of PDUs to > > >>>> > > > both > > > > > >>>>links, in order to reach both DR and BDR? In my opinion it should not. I > > >>>> > > >>>> > > >>>am > > >>> > > >>> > > >>>>told that it should, as this would be a particular case of OSPF support > > >>>> > > >>>> > > >>>for > > >>> > > >>> > > >>>>layer 2 switching. Is there some specification in an RFC about this? > > >>>> > > >>>>R1-----------R2-----------R3 > > >>>> > > >>>>Thank you very much and have a nice day, > > >>>>Delia > > >>>> > > >>>> > > >> > > >>-- > > >>Acee > > >> > > > > > > > -- > > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 24 04:02:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28750 for ; Thu, 24 Oct 2002 04:02:32 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0078CE9C@cherry.ease.lsoft.com>; Thu, 24 Oct 2002 4:04:47 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 334365 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 24 Oct 2002 04:04:46 -0400 Received: from 64.139.11.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 24 Oct 2002 04:04:45 -0400 Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id EAA00907; Thu, 24 Oct 2002 04:08:24 -0400 References: <20021023204433.D709C3DEC@xmxpita.excite.com> <3DB77069.4080708@redback.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.91 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Message-ID: Date: Thu, 24 Oct 2002 01:08:24 -0700 Reply-To: Mailing List Sender: Mailing List From: Kunihiro Ishiguro Subject: Re: Hitless restart Comments: To: Acee Lindem To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DB77069.4080708@redback.com> Precedence: list >> Also, I remember a while back a discussion on the list >> between yourself, Padma, and John regarding the IP address >> field in the Grace LSA. I cannot remember the specific issue, >> but I assume there's been a resolution (or at least an >> understanding)? > > >This was the comment that Padma made that the IP interface >address TLV is not necessary to identify the restarting >neighbor on multi-access (broadcast and NBMA) links. I pointed out >that it wasn't really necessary since the grace LSA was already >scoped to an OSPF interface and there could only be one >neighbor adjacency corresponding to the router ID (even if >one was running OSPF on more than one subnet). John pointed >out that OSPFv2 always uses the IP interface address to identify >neighboring routers on multi-access networks so it should >included to be consistent with the RFC 2328 (numerous sections). >I tend to agree with this and would vote to leave it in. > >However, it is not needed for OSPFv3 since here neighboring >routers are always identified by router ID. Well, yes in OSPFv3 it is not needed...so I would like to say it should not be included in OSPFv3 Grace-LSA. IHMO it is consistent with the RFC2740. -- Kunihiro Ishiguro From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 24 04:36:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29316 for ; Thu, 24 Oct 2002 04:36:49 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0078CFC3@cherry.ease.lsoft.com>; Thu, 24 Oct 2002 4:39:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 334433 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 24 Oct 2002 04:39:05 -0400 Received: from 193.180.251.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 24 Oct 2002 04:39:05 -0400 Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9O8d2KV010709 for ; Thu, 24 Oct 2002 10:39:03 +0200 (MEST) Received: from marleau.eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id KAA14041; Thu, 24 Oct 2002 10:39:00 +0200 (MET DST) Received: from localhost (tmpser@localhost) by marleau.eth.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id KAA14228 for ; Thu, 24 Oct 2002 10:38:59 +0200 (MET DST) X-Authentication-Warning: marleau.eth.ericsson.se: tmpser owned process doing -bs X-Sender: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 24 Oct 2002 10:38:59 +0200 Reply-To: Mailing List Sender: Mailing List From: Sandor Ecker Subject: Re: Highly Connected Network Topologies To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DB46EC2.6090207@nmsu.edu> Precedence: list Hi! Could someone tell me how can I use this simulation app (I downloaded from www.ospf.org)? Some examples please! I compiled it, but I don't konw what to do and how... Thanks! Sandor On Mon, 21 Oct 2002, Vincent wrote: > I installed John T Moy's OSPF simulation app and would like to model > and simulate "highly connected network topologies", unfortunetly I do > not have much real-world OSPF/Networking experience to know what > topologies would be practical. I would appreciate it greatly if someone > could send me a few examples (please identify rtrs w/ ext routes) or an > URL that would have some 'real-world' examples. > > Vince > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 24 07:22:04 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01854 for ; Thu, 24 Oct 2002 07:22:04 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0078D2F9@cherry.ease.lsoft.com>; Thu, 24 Oct 2002 7:24:20 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 335166 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 24 Oct 2002 07:24:20 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 24 Oct 2002 07:24:20 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HPFDK>; Thu, 24 Oct 2002 07:24:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 24 Oct 2002 07:26:21 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee/Don, > Finally, there was also a previous discussion I was involved > in regarding contraining the grace period to a max value of > MaxAge (3600). Is this being included in the new draft? I think MaxAge is a best case value. An LSA originated x minutes before restart would be MaxAged after (MaxAge - x) time. As the maximum value of x can be RefreshInterval, an ideal value would be closer to lesser than (MaxAge - RefreshInterval), otherwise there would be large chances of the hitless restart being a normal restart. (The MaxAgeDiff value would cancel out.) I think to make the graceful-restart spec match existing implementations, we should allow an option of a "non-strict check" for the helper deciding to exit restart. Besides in the strict check case we could add the http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0203&L=ospf&T=0&F=&S=& P=1902 Also as the only change to the draft for OSPFv3 part would be defining a new LSA type, do we intend to describe it here in this draft itself? Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Thursday, October 24, 2002 9:31 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Hitless restart Hi Don, Don Goodspeed wrote: > Acee, > > On the issue of updating the grace period, I would only > update in case the reason code changed, and changed to > a value of unknown (and/or we could add a new "unplanned > restart" reason code). I'm not sure there is any difference between unknown and unplanned. > > Also, I remember a while back a discussion on the list > between yourself, Padma, and John regarding the IP address > field in the Grace LSA. I cannot remember the specific issue, > but I assume there's been a resolution (or at least an > understanding)? This was the comment that Padma made that the IP interface address TLV is not necessary to identify the restarting neighbor on multi-access (broadcast and NBMA) links. I pointed out that it wasn't really necessary since the grace LSA was already scoped to an OSPF interface and there could only be one neighbor adjacency corresponding to the router ID (even if one was running OSPF on more than one subnet). John pointed out that OSPFv2 always uses the IP interface address to identify neighboring routers on multi-access networks so it should included to be consistent with the RFC 2328 (numerous sections). I tend to agree with this and would vote to leave it in. However, it is not needed for OSPFv3 since here neighboring routers are always identified by router ID. > > Finally, there was also a previous discussion I was involved > in regarding contraining the grace period to a max value of > MaxAge (3600). Is this being included in the new draft? That could be documented. > > Thanks, > Don > > --- On Tue 10/22, Acee Lindem wrote: > From: Acee Lindem [mailto: acee@REDBACK.COM] > To: OSPF@DISCUSS.MICROSOFT.COM > Date: Tue, 22 Oct 2002 14:49:37 -0400 > Subject: Re: Hitless restart > > >>Manral, Vishwas wrote: >> >> >>>Hi Acee, >>> >>>I agree to Padma's statement that we are using link-local LSA to >>> >>signal >> >>>hitless-restart, because we would not want the LSA to be flooded by >>> >>the >> >>>neighbors into the area. We are signalling router parameters in the >>> >>link >> >>>local LSA. >>> >>>Regarding 2. >>>- I think we should update the grace-period/reason only when we have >>> >>a >> >>>change in content of the Grace LSA from the neighbor to the >>> >>restarting >> >>>router on any interface. So if we get a different value of >>>grace-period/restart reason we update and restart the grace period on >>> >>the >> >>>helper else we do not. This would be in keeping with Section 3 of the >>> >>draft. >> >> >>Vishwas, >> >>I agree that if we do agree to change the existing specification than we >>should, in fact, honor changes to the grace-period/restart-reason. One >>of my concerns with this approach is the added complexity (consider >>determining which of multiple link local LSAs received on different >>links is more recent). >> >>Thanks, >> >>Acee >> >> >> >>>- I think the first grace LSA withdrawn would cause the router to >>> >>exit >> >>>hitless restart mode for that neighbor. >>> >>>Thanks, >>>Vishwas >>> >>>-----Original Message----- >>>From: Acee Lindem [mailto:acee@REDBACK.COM] >>>Sent: Tuesday, October 22, 2002 8:22 PM >>>To: OSPF@DISCUSS.MICROSOFT.COM >>>Subject: Re: Hitless restart >>> >>> >>>All, >>> >>>I think we have a "rough concensus" that the restarting >>> >>router >> >>>should NOT try to optimize flooding of grace LSAs. I've >>>only had one vote for this and I believe the vote was more >>>for flooding optimizations in general than this particular >>>scenario. >>> >>> >>>Padma, >>> >>>I don't think it simplifies the helper code (or specification) >>>to apply the grace LSA to all neighbor instances of restarting >>>router. Here are my reasons: >>> >>> 1. Conceptually, I don't think it is right to apply the link >>> local grace LSA to neighbors that are not on the link. >>> >>> 2. There are simply more corner cases - >>> >>> - When you receive a second grace LSA from the restarting >>> router, do you update the reason and grace period for >>> all neighbor instances or only ones on that segment? >>> >>> - When do exit helper mode? Is it when the first grace >>> LSA is withdrawn or all the grace LSAs? I certainly don't >>> think there should be disconnect between entering and >>> exiting helper mode. >>> >>>I do agree that it is somewhat more robust for the case where >>>you are adjacent with the same router on more than one link. >>>However, I don't see this as a real big gain. Has anyone >>>else implemented this draft? >>> >>>Thanks, >>>Acee >>> >>> >>> >>>Padma Pillay-Esnault wrote: >>> >>> >>> >>>>Rajesh >>>> >>>> >>>>Rajesh Varadarajan wrote: >>>> >>>> >>>> >>>>>Acee, Padma, >>>>> >>>>> >>>>> >>>> >>>>>>>>>I do think it simplifies things if a >>>>>>>>> >>restarting router originates the >> >>>grace LSAs >>> >>> >>>>>>>>>on all it's interfaces (or at least all with >>>>>>>>> >>full neighbor >> >>>>>>>>> >>>>^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>> >>>> >>>> >>>>>>>>>adjacencies if it a planned restart). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>The above statement seems to imply (my reading) that a >>>>> >>restarting router >> >>>>>can only send Grace LSA's out of some (not all) of its >>>>> >>interfaces. The >> >>>>> >>>>It doesn't imply that - clearly we send to all our neighbors. >>>> >>>>Padma >>>> >>>> >>>> >>>>>spec however requires the router to send the grace-lsa out of >>>>> >>all >> >>>>>interfaces on which it has full neigbhors. Failure to do so >>>>> >>would always >> >>>>>result in its helper mode being terminated by others. >>>>> >>>>> >>>>> >>>> >>>>>>>>I also agree with you .. that's what I do - the >>>>>>>> >>restarting router sends >> >>>>>>>>grace lsa over all interfaces. But from a Helping >>>>>>>> >>router perspective >> >>>>>>>>we should do as in 00-txt. It simplifies the >>>>>>>> >>helper code. >> >>>>>>>>It also prevents corner cases where we might not >>>>>>>> >>help all adjacencies >> >>>>>>>>(when we should). >>>>>>>> >>>>>>>>Padma >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>I haven't heard anyone object to why the 00-txt. >>>>>>> >>>>>>> >>>>>>> >>>>>>I will - I specifically agree with >>>>>> >>>>>> >>>>>> >>>>>> Note that Router Y only needs to receive a single >>>>>> >>grace-LSA from >> >>>>>> X, even if X and Y attach to multiple common >>>>>> >>segments. >> >>>>>>I don't like using an LSA with link local scope to >>>>>> >>enter/terminate >> >>>>>>helper mode for neighbors on different interfaces. It is >>>>>> >>better if the >> >>>>>>link local grace LSA only applies to that link. >>>>>> >>>>>> >>>>>> >>>>>Given the behavior above, I think the each neighbor should be >>>>> >>considered >> >>>>>independently on a segment by segment basis. >>>>> >>>>> >>>>>thanks, >>>>>rajesh >>>-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 24 07:45:42 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02747 for ; Thu, 24 Oct 2002 07:45:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0078D46D@cherry.ease.lsoft.com>; Thu, 24 Oct 2002 7:47:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 335222 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 24 Oct 2002 07:47:58 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 24 Oct 2002 07:37:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02403; Thu, 24 Oct 2002 07:35:39 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200210241135.HAA02403@ietf.org> Date: Thu, 24 Oct 2002 07:35:38 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-katz-yeung-ospf-traffic-09.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Traffic Engineering Extensions to OSPF Version 2 Author(s) : D. Katz, D. Yeung, K. Kompella Filename : draft-katz-yeung-ospf-traffic-09.txt Pages : 14 Date : 2002-10-23 This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering, using Opaque Link State Advertisements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-katz-yeung-ospf-traffic-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-katz-yeung-ospf-traffic-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-23150005.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-katz-yeung-ospf-traffic-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-katz-yeung-ospf-traffic-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-23150005.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 24 12:47:06 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15332 for ; Thu, 24 Oct 2002 12:47:06 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0078DEA2@cherry.ease.lsoft.com>; Thu, 24 Oct 2002 12:49:20 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 336228 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 24 Oct 2002 12:49:20 -0400 Received: from 128.123.15.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 24 Oct 2002 12:49:20 -0400 Received: from nmsu.edu ([128.123.15.221]) by mail.psl.nmsu.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 24 Oct 2002 10:48:34 -0600 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 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: 24 Oct 2002 16:48:34.0984 (UTC) FILETIME=[31684280:01C27B7D] Message-ID: <3DB8248C.90608@nmsu.edu> Date: Thu, 24 Oct 2002 10:49:16 -0600 Reply-To: Mailing List Sender: Mailing List From: Vincent Subject: Re: Highly Connected Network Topologies Comments: cc: Sandor.Ecker@eth.ericsson.se To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sandor Ecker wrote: >Hi! > >Could someone tell me how can I use this simulation app (I downloaded from >www.ospf.org)? Some examples please! I compiled it, but I don't konw what >to do and how... > >Thanks! >Sandor > >On Mon, 21 Oct 2002, Vincent wrote: > > > >>I installed John T Moy's OSPF simulation app and would like to model >>and simulate "highly connected network topologies", unfortunetly I do >>not have much real-world OSPF/Networking experience to know what >>topologies would be practical. I would appreciate it greatly if someone >>could send me a few examples (please identify rtrs w/ ext routes) or an >>URL that would have some 'real-world' examples. >> >>Vince >> >> >> > > > You can run the default example by simply executing 'ospf_sim'. If you want to see the contents of the 'default configuration' then go to File->Save As. Or if your in the trouble shooting mode you can run 'ospf_sim sample.cfg'. 'sample.cfg' is located in /ospfd/ospf_sim. This is probably not the proper forum to discuss Moy's OSPF implementation so until a mailing list for it opens its doors you can email me directly and I'll try to answer what I've learn thus far. Does anybody have some 'real world' examples of "highly connected network topologies" to share. I would like to persue one of the ospf charters goals and attempt to develop a mechanism to reduce ospf flooding traffic in such topologies. Richard Fiutem (since you said you would)? Anybody Else? Vince From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 24 18:06:58 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25434 for ; Thu, 24 Oct 2002 18:06:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0078EB62@cherry.ease.lsoft.com>; Thu, 24 Oct 2002 18:09:14 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 337512 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 24 Oct 2002 18:09:14 -0400 Received: from 207.159.120.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 24 Oct 2002 18:09:14 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 5E0F03DEF; Thu, 24 Oct 2002 18:09:11 -0400 (EDT) Received: from [66.245.53.58] by xprdmailfe6.nwk.excite.com via HTTP; Thu, 24 Oct 2002 18:09:11 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = 5a0d576de9aa5a9bd97ca92d6f5a1e8d MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20021024220911.5E0F03DEF@xmxpita.excite.com> Date: Thu, 24 Oct 2002 18:09:11 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: DR / BDR election on different links configured as on same subnet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kiran, As for the IP network: R1 R2 R3 | | | | | | --------------- which maps to the physical network: R1----R2----R3 Please separate L2 switching (bridging, etc.) of packets from the L3 or IP/OSPF processing of the packets when looking at this situation. L2 switches or bridges will flood to all ports (with limited expections) ALL multicast, broadcast, and unknown packets, and will forward all "learned" packets to their destination ports. In other words, if R2 is doing it's job as a switch or bridge properly, R1, R2, and R3 will see all of each others packets when they are on the same subnet. Therefore, R1, R2, and R3 process packets at the IP/OSPF level as if they were all connected into the same "hub" or shared media access network, aka a broadcast network in OSPF. Therefore, RFC2328 takes care of what to do on a broadcast network in terms of sending and receiving packets. Cheers, Don --- On Thu 10/24, Kiran S wrote: From: Kiran S [mailto: kirans@NETSCIENCE.CC] To: OSPF@DISCUSS.MICROSOFT.COM Date: Thu, 24 Oct 2002 15:14:18 +0900 Subject: Re: DR / BDR election on different links configured as on same subnet > Cheng-yin, > > Yep... It is R1, R2, R3 peering over a same VLAN and subnet. > The setup will be more clear if we connect all these OSPF routers to a L2 > switch or hub. > In this case there will be a common DR/BDR election. > But now the physical connection R1---R2---R3 and all belong to same > subnet. > > This is a typical network connection, and this network looks logical. > Any RFCs/standard stating how well we can handle this situation ? > Thanks. ! > > Cheers > Kiran > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 24 18:23:49 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25698 for ; Thu, 24 Oct 2002 18:23:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0078EB81@cherry.ease.lsoft.com>; Thu, 24 Oct 2002 18:26:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 337573 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 24 Oct 2002 18:26:04 -0400 Received: from 207.159.120.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 24 Oct 2002 18:26:04 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 854F23DF7; Thu, 24 Oct 2002 18:26:01 -0400 (EDT) Received: from [66.245.53.58] by xprdmailfe6.nwk.excite.com via HTTP; Thu, 24 Oct 2002 18:26:01 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = 5a0d576de9aa5a9bd97ca92d6f5a1e8d MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20021024222601.854F23DF7@xmxpita.excite.com> Date: Thu, 24 Oct 2002 18:26:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Comment in-line. -don --- On Thu 10/24, Acee Lindem wrote: From: Acee Lindem [mailto: acee@REDBACK.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Thu, 24 Oct 2002 00:00:41 -0400 Subject: Re: Hitless restart > Hi Don, > > Don Goodspeed wrote: > > > Acee, > > (snip) > > Also, I remember a while back a discussion on the list > > between yourself, Padma, and John regarding the IP address > > field in the Grace LSA. I cannot remember the specific issue, > > but I assume there's been a resolution (or at least an > > understanding)? > > > This was the comment that Padma made that the IP interface > address TLV is not necessary to identify the restarting > neighbor on multi-access (broadcast and NBMA) links. I pointed out > that it wasn't really necessary since the grace LSA was already > scoped to an OSPF interface and there could only be one > neighbor adjacency corresponding to the router ID (even if > one was running OSPF on more than one subnet). John pointed > out that OSPFv2 always uses the IP interface address to identify > neighboring routers on multi-access networks so it should > included to be consistent with the RFC 2328 (numerous sections). > I tend to agree with this and would vote to leave it in. > > However, it is not needed for OSPFv3 since here neighboring > routers are always identified by router ID. > DG: So this TLV is mandatory then for OSPFv2? If so, this needs to be added to the text in the draft (This TLV must always appear in a grace-LSA.). And in the OSPFv3 draft, it should NOT appear. > (snip) _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@DISCUSS.MICROSOFT.COM Fri Oct 25 07:19:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19453 for ; Fri, 25 Oct 2002 07:19:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0078FFC0@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 7:21:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 339372 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 07:21:43 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 07:21:43 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HPHG4>; Fri, 25 Oct 2002 07:21:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 25 Oct 2002 07:23:58 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee/Padma, I have the following comments on the latest draft besides the earlier comments: - 1. We could specify the Destination address to be used for packets to in case of an unplanned hitless restart. I guess we should send packets to all AllSPFRouters multicast address in case of broadcast links(we dont know the interface state DR/BDR/nonDR). This would be different from whats specified in the base RFC and hence may need to be put it down in the document. 2. "Robusness variable" would also mean we delay the sending of hellos, for sending the Grace LSA after sending a hello would not help. I think we should send the LSA in MinLSArrival a few times before we start sending hellos. May be that could be clarified, we may be violating the MinLSInterval in this case. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 07:37:55 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20814 for ; Fri, 25 Oct 2002 07:37:54 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00790142@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 7:40:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 339391 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 07:40:07 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 07:30:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19866; Fri, 25 Oct 2002 07:27:47 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200210251127.HAA19866@ietf.org> Date: Fri, 25 Oct 2002 07:27:47 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-pillay-esnault-ospf-v3-grace-lsa-01.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Grace LSA in OSPFv3 Author(s) : P. Pillay-Esnault Filename : draft-pillay-esnault-ospf-v3-grace-lsa-01.txt Pages : 5 Date : 2002-10-24 This memo describes the OSPF version 3 specific Grace Link State Advertisement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pillay-esnault-ospf-v3-grace-lsa-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pillay-esnault-ospf-v3-grace-lsa-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-pillay-esnault-ospf-v3-grace-lsa-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-24142111.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-pillay-esnault-ospf-v3-grace-lsa-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-pillay-esnault-ospf-v3-grace-lsa-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-24142111.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 07:39:19 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20877 for ; Fri, 25 Oct 2002 07:39:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00790072@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 7:41:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 339392 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 07:41:37 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 07:31:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20310; Fri, 25 Oct 2002 07:29:17 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200210251129.HAA20310@ietf.org> Date: Fri, 25 Oct 2002 07:29:16 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-abr-alt-05.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Alternative OSPF ABR Implementations Author(s) : A. Zinin, A. Lindem, D. Yeung Filename : draft-ietf-ospf-abr-alt-05.txt Pages : 10 Date : 2002-10-24 OSPF is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-abr-alt-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-abr-alt-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-abr-alt-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-24142400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-abr-alt-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-abr-alt-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-24142400.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 07:39:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20891 for ; Fri, 25 Oct 2002 07:39:24 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.007900BC@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 7:41:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 339393 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 07:41:42 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 07:31:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20330; Fri, 25 Oct 2002 07:29:22 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200210251129.HAA20330@ietf.org> Date: Fri, 25 Oct 2002 07:29:22 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Hitless OSPF Restart Author(s) : J. Moy et al. Filename : draft-ietf-ospf-hitless-restart-03.txt Pages : 13 Date : 2002-10-24 This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called 'hitless restart' or 'non-stop forwarding'. A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a hitless restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-hitless-restart-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-hitless-restart-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-24142410.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-hitless-restart-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-hitless-restart-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-24142410.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 10:13:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25839 for ; Fri, 25 Oct 2002 10:13:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.007902C8@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 10:16:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 339887 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 10:16:04 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 10:16:04 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 415CF2CDB50 for ; Fri, 25 Oct 2002 07:16:03 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB951BD.3000607@redback.com> Date: Fri, 25 Oct 2002 10:14:21 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: > Hi Acee/Padma, > > I have the following comments on the latest draft besides the earlier > comments: - > > 1. We could specify the Destination address to be used for packets to in > case of an unplanned hitless restart. I guess we should send packets to all > AllSPFRouters multicast address in case of broadcast links(we dont know the > interface state DR/BDR/nonDR). This would be different from whats specified > in the base RFC and hence may need to be put it down in the document. Hi Manral, Good catch. If the restarting router is DR then this is absolutely necessary for unplanned restart. > > 2. "Robusness variable" would also mean we delay the sending of hellos, for > sending the Grace LSA after sending a hello would not help. I think we > should send the LSA in MinLSArrival a few times before we start sending > hellos. May be that could be clarified, we may be violating the > MinLSInterval in this case. Ok. The only consequence of re-flooding the LSA sooner is that the routers that previously received the LSA will ignore it. My concern is that I'd hate to delay the business of sync'ing up the databases. In practice, the neighbor adjacencies are re-established very quickly (even with thousands of LSAs). Am I missing something? > > Thanks, > Vishwas > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 12:49:28 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01690 for ; Fri, 25 Oct 2002 12:49:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00790AFC@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 12:51:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 340625 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 12:51:40 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 12:51:40 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9PGpcm08854; Fri, 25 Oct 2002 09:51:38 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9PGpc150220; Fri, 25 Oct 2002 09:51:38 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210251651.g9PGpc150220@garnet.juniper.net> Date: Fri, 25 Oct 2002 09:51:38 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DB951BD.3000607@redback.com> from "Acee Lindem" at Oct 25, 2002 10:14:21 AM Precedence: list Content-Transfer-Encoding: 7bit > > Manral, Vishwas wrote: > > > Hi Acee/Padma, > > > > I have the following comments on the latest draft besides the earlier > > comments: - > > > > 1. We could specify the Destination address to be used for packets to in > > case of an unplanned hitless restart. I guess we should send packets to all > > AllSPFRouters multicast address in case of broadcast links(we dont know the > > interface state DR/BDR/nonDR). This would be different from whats specified > > in the base RFC and hence may need to be put it down in the document. > > > Hi Manral, > > Good catch. If the restarting router is DR then this is absolutely > necessary for unplanned restart. > Actually this is what our implementation does .. I'd even go further to say that this is what we should always do even in a planned restart. > > > > > 2. "Robusness variable" would also mean we delay the sending of hellos, for > > sending the Grace LSA after sending a hello would not help. I think we > > should send the LSA in MinLSArrival a few times before we start sending > > hellos. May be that could be clarified, we may be violating the > > MinLSInterval in this case. > > > Ok. The only consequence of re-flooding the LSA sooner is that the > routers that previously received the LSA will ignore it. > My concern is that I'd hate to delay the business of sync'ing up the > databases. In practice, the neighbor adjacencies are re-established very > quickly (even with thousands of LSAs). Am I missing something? > I think that flooding a few times before sending the hellos is fine and we do not really need to delay the hellos. The interval between resending the grace lsa is something like 2 secs in our implementation. The grace lsa are scheduled to be retransmitted at least twice before unblocking sending the hellos. Padma > > > > > Thanks, > > Vishwas > > > > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 13:07:23 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02444 for ; Fri, 25 Oct 2002 13:07:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00790C34@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 13:09:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 340674 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 13:09:41 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 13:09:40 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id D34A44F41BA for ; Fri, 25 Oct 2002 10:09:38 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210251651.g9PGpc150220@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB97A6B.8090007@redback.com> Date: Fri, 25 Oct 2002 13:07:55 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma Pillay-Esnault wrote: >>Manral, Vishwas wrote: >> >> >>>Hi Acee/Padma, >>> >>>I have the following comments on the latest draft besides the earlier >>>comments: - >>> >>>1. We could specify the Destination address to be used for packets to in >>>case of an unplanned hitless restart. I guess we should send packets to all >>>AllSPFRouters multicast address in case of broadcast links(we dont know the >>>interface state DR/BDR/nonDR). This would be different from whats specified >>>in the base RFC and hence may need to be put it down in the document. >>> >> >>Hi Manral, >> >>Good catch. If the restarting router is DR then this is absolutely >>necessary for unplanned restart. >> >> > > Actually this is what our implementation does .. > I'd even go further to say that this is what we should always do even > in a planned restart. Why would you send to AllSPFRouters if you know your DR state (which would be the case in a planned restart) and you're not DR? > > >>>2. "Robusness variable" would also mean we delay the sending of hellos, for >>>sending the Grace LSA after sending a hello would not help. I think we >>>should send the LSA in MinLSArrival a few times before we start sending >>>hellos. May be that could be clarified, we may be violating the >>>MinLSInterval in this case. >>> >> >>Ok. The only consequence of re-flooding the LSA sooner is that the >>routers that previously received the LSA will ignore it. >>My concern is that I'd hate to delay the business of sync'ing up the >>databases. In practice, the neighbor adjacencies are re-established very >>quickly (even with thousands of LSAs). Am I missing something? >> >> > > I think that flooding a few times before sending the hellos is fine and we do > not really need to delay the hellos. > The interval between resending the grace lsa is something like 2 secs in > our implementation. The grace lsa are scheduled to be retransmitted > at least twice before unblocking sending the hellos. I agree here - I just don't want to wait N * MinLSInterval seconds (where N is the number of retransmissions). > > Padma > > >>>Thanks, >>>Vishwas >>> >>> >>> >> >>-- >>Acee >> >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 13:20:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03127 for ; Fri, 25 Oct 2002 13:20:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00790CD4@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 13:22:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 340708 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 13:22:34 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 13:22:34 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HPHX2>; Fri, 25 Oct 2002 13:22:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 25 Oct 2002 13:24:49 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Padma/Acee, > I think that flooding a few times before sending the hellos is fine > and we do not really need to delay the hellos. Dont we need to delay hellos till we send the LSA a few times as you have stated. > The interval between resending the grace lsa is something like 2 secs > in our implementation. The grace lsa are scheduled to be retransmitted > at least twice before unblocking sending the hellos. We may need to clarify it further. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 13:25:33 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03254 for ; Fri, 25 Oct 2002 13:25:32 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00790BE2@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 13:27:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 340727 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 13:27:51 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 13:27:51 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9PHRnm12113 for ; Fri, 25 Oct 2002 10:27:49 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9PHRnX63807 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 10:27:49 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210251727.g9PHRnX63807@garnet.juniper.net> Date: Fri, 25 Oct 2002 10:27:49 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: from "Manral, Vishwas" at Oct 25, 2002 01:24:49 PM Precedence: list Content-Transfer-Encoding: 7bit > > Hi Padma/Acee, > > > I think that flooding a few times before sending the hellos is fine > > and we do not really need to delay the hellos. > Dont we need to delay hellos till we send the LSA a few times as you have > stated. Yes. This is essential for unplanned restart. Padma > > > The interval between resending the grace lsa is something like 2 secs > > in our implementation. The grace lsa are scheduled to be retransmitted > > at least twice before unblocking sending the hellos. > We may need to clarify it further. > > Thanks, > Vishwas > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 13:31:15 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03477 for ; Fri, 25 Oct 2002 13:31:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00790D55@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 13:33:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 340765 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 13:33:33 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 13:33:32 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9PHXVm12675; Fri, 25 Oct 2002 10:33:31 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9PHXVn65923; Fri, 25 Oct 2002 10:33:31 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210251733.g9PHXVn65923@garnet.juniper.net> Date: Fri, 25 Oct 2002 10:33:31 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DB97A6B.8090007@redback.com> from "Acee Lindem" at Oct 25, 2002 01:07:55 PM Precedence: list Content-Transfer-Encoding: 7bit > >> Acee > > > Why would you send to AllSPFRouters if you know your DR > state (which would be the case in a planned restart) and > you're not DR? > > Why not ? The goal is to notify everyone on the BCAST segment. If they have a full adjacency with the restarting router DR or not we need them as helpers. Padma From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 13:32:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03502 for ; Fri, 25 Oct 2002 13:32:26 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00790E03@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 13:34:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 340785 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 13:34:43 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 13:34:43 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id D9C37F2C59 for ; Fri, 25 Oct 2002 10:34:41 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB98049.4090907@redback.com> Date: Fri, 25 Oct 2002 13:32:57 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: > Hi Padma/Acee, > > >>I think that flooding a few times before sending the hellos is fine >>and we do not really need to delay the hellos. >> > Dont we need to delay hellos till we send the LSA a few times as you have > stated. I don't think we want to mandate how many times - once you send a hello you can cause a neighbor to go down prior to entering helper mode. > > >>The interval between resending the grace lsa is something like 2 secs >>in our implementation. The grace lsa are scheduled to be retransmitted >>at least twice before unblocking sending the hellos. >> > We may need to clarify it further. > > Thanks, > Vishwas > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 13:34:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03565 for ; Fri, 25 Oct 2002 13:34:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00790CC0@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 13:36:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 340805 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 13:36:29 -0400 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 13:36:29 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HPHYG>; Fri, 25 Oct 2002 13:36:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 25 Oct 2002 13:38:43 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Padma, The normal flooding can achieve the purpose, I don't see any reason why we need to change in the planned restart case. Thanks, Vishwas -----Original Message----- From: Padma Pillay-Esnault [mailto:padma@JUNIPER.NET] Sent: Friday, October 25, 2002 11:04 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: draft-ietf-ospf-hitless-restart-03.txt > >> Acee > > > Why would you send to AllSPFRouters if you know your DR > state (which would be the case in a planned restart) and > you're not DR? > > Why not ? The goal is to notify everyone on the BCAST segment. If they have a full adjacency with the restarting router DR or not we need them as helpers. Padma From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 13:36:32 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03664 for ; Fri, 25 Oct 2002 13:36:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00790D03@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 13:38:49 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 340825 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 13:38:49 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 13:38:49 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 0EF055E44F for ; Fri, 25 Oct 2002 10:38:48 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210251733.g9PHXVn65923@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB9813F.9020304@redback.com> Date: Fri, 25 Oct 2002 13:37:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma Pillay-Esnault wrote: > Acee > > >> >>Why would you send to AllSPFRouters if you know your DR >>state (which would be the case in a planned restart) and >>you're not DR? >> >> >> > > Why not ? The goal is to notify everyone on the BCAST segment. > If they have a full adjacency with the restarting router > DR or not we need them as helpers. Would you argue the same for all flooding on a broadcast segment? The fact is we shouldn't need to change base flooding if it is a planned restart and we are not DR. > > Padma > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 13:38:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03819 for ; Fri, 25 Oct 2002 13:38:35 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00790E0B@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 13:40:52 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 340843 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 13:40:52 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 13:40:52 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9PHepm13268 for ; Fri, 25 Oct 2002 10:40:51 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9PHepD69024 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 10:40:51 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210251740.g9PHepD69024@garnet.juniper.net> Date: Fri, 25 Oct 2002 10:40:51 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: from "Manral, Vishwas" at Oct 25, 2002 01:38:43 PM Precedence: list Content-Transfer-Encoding: 7bit Vishwas I was thinking about additionnal delays introduced and did not want to have a race condition where the DR/BDR is slow in flooding. Retransmission can be long in OSPF. It doesn't break anything to sent it to allSPFRouters. I think we should let that to implementation choice. Padma > > Hi Padma, > > The normal flooding can achieve the purpose, I don't see any reason why we > need to change in the planned restart case. > > Thanks, > Vishwas > > -----Original Message----- > From: Padma Pillay-Esnault [mailto:padma@JUNIPER.NET] > Sent: Friday, October 25, 2002 11:04 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: draft-ietf-ospf-hitless-restart-03.txt > > > > >> > Acee > > > > > > > Why would you send to AllSPFRouters if you know your DR > > state (which would be the case in a planned restart) and > > you're not DR? > > > > > > Why not ? The goal is to notify everyone on the BCAST segment. > If they have a full adjacency with the restarting router > DR or not we need them as helpers. > > Padma > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 13:46:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04239 for ; Fri, 25 Oct 2002 13:46:26 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00790EC4@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 13:48:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 340909 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 13:48:44 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 13:48:44 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g9PHmhm13998 for ; Fri, 25 Oct 2002 10:48:43 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id g9PHmhf71920 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 10:48:43 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200210251748.g9PHmhf71920@garnet.juniper.net> Date: Fri, 25 Oct 2002 10:48:43 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DB9813F.9020304@redback.com> from "Acee Lindem" at Oct 25, 2002 01:37:03 PM Precedence: list Content-Transfer-Encoding: 7bit > > Padma Pillay-Esnault wrote: > > > Acee > > > > > >> > >>Why would you send to AllSPFRouters if you know your DR > >>state (which would be the case in a planned restart) and > >>you're not DR? > >> > >> > >> > > > > Why not ? The goal is to notify everyone on the BCAST segment. > > If they have a full adjacency with the restarting router > > DR or not we need them as helpers. > > > Would you argue the same for all flooding on a broadcast > segment? The fact is we shouldn't need to change base > flooding if it is a planned restart and we are not > DR. I understand your point. But I think of grace lsa as a signal. Padma > > > > > > > Padma > > > > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 13:47:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04278 for ; Fri, 25 Oct 2002 13:47:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00790DEE@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 13:49:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 340927 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 13:49:35 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 13:49:35 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 9A1344BA200 for ; Fri, 25 Oct 2002 10:49:33 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <200210251740.g9PHepD69024@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB983C5.8020504@redback.com> Date: Fri, 25 Oct 2002 13:47:49 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-hitless-restart-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma Pillay-Esnault wrote: > Vishwas > > I was thinking about additionnal delays introduced and did not want > to have a race condition where the DR/BDR is slow in flooding. > Retransmission can be long in OSPF. > > It doesn't break anything to sent it to allSPFRouters. > I think we should let that to implementation choice. The implementation can chose but this should not be added to the spec without a good reason. > > Padma > >>Hi Padma, >> >>The normal flooding can achieve the purpose, I don't see any reason why we >>need to change in the planned restart case. >> >>Thanks, >>Vishwas >> >>-----Original Message----- >>From: Padma Pillay-Esnault [mailto:padma@JUNIPER.NET] >>Sent: Friday, October 25, 2002 11:04 PM >>To: OSPF@DISCUSS.MICROSOFT.COM >>Subject: Re: draft-ietf-ospf-hitless-restart-03.txt >> >> >> >>Acee >> >> >>> >>>Why would you send to AllSPFRouters if you know your DR >>>state (which would be the case in a planned restart) and >>>you're not DR? >>> >>> >>> >>Why not ? The goal is to notify everyone on the BCAST segment. >>If they have a full adjacency with the restarting router >>DR or not we need them as helpers. >> >>Padma >> >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 14:59:10 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06777 for ; Fri, 25 Oct 2002 14:59:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00791044@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 15:01:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 341079 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 15:01:27 -0400 Received: from 62.241.160.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 15:01:26 -0400 Received: from tom3 (usercq38.uk.uudial.com [62.188.156.166]) by colossus.systems.pipex.net (Postfix) with SMTP id CBE15160001B8 for ; Fri, 25 Oct 2002 20:01:23 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <002401c27c58$70216c00$0301a8c0@tom3> Date: Fri, 25 Oct 2002 19:53:54 +0100 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Before the multi-access issue is declared closed I believe there should be an agreed definition of what multi-access means in this context. Because in an OSPF context ie RFC2328 (which is where I am coming from), the term multi-access has now largely disappeared. The terminology is either 'Broadcast' or 'Non-Broadcast MultiAccess' and both are defined as (p.9) ' Networks supporting many (more than two) attached routers' So what is a two router only multi-access network? Nothing to do with OSPF :-( And this is a can of worms because RFC2328 seems not to allow a DR on two router networks while certain manufacturers of routers do (and I even see LSA with a DR when there is only one of those manufacturers' routers active!). Here, by implication, from the TLV definition in this draft, multiaccess means a network with a DR. And then there are other nasties like NBMA networks which lose full connectivity and so should stop having a DR! Tom Petch -----Original Message----- From: Acee Lindem To: OSPF@DISCUSS.MICROSOFT.COM Date: 22 October 2002 21:30 Subject: Re: Comments on draft-katz-yeung-traffic-08.txt >Kireeti, > >Can we close on the remaining issues? > > 1. With respect to the Remote Interface IP Addres TLV, is > there really any reason to include it with a value of 0.0.0.0 > for a multi-access link? I can't see how there could be > a compatibility issue since the rough count on the list > revealed more implementations that omitted the TLV > altogether. > > 2. With respect to more than two routers on a multi-access > network, it seems there is considerable support for > allowing this even though it is not fully specified. > Could you add something along these lines to the second > paragraph of the limitations section: > > "Operation over multiaccess links with more than two > devices is not specifically prohibited. TE operation > and the use of reservation state is a matter for > further study". > > >Thanks, >Acee > > > > >Kireeti Kompella wrote: > >> Hi Acee, >> >> On Thu, 17 Oct 2002, Acee Lindem wrote: >> >> >>>Comments: >>> >>> - The LSA Header Diagram in section 2.3.1 does not reflect >>> the fact that the instance has been extended to 24 bits. >>> >> >> Thanks. Someone else also pointed this out. >> >> >>> - Section 2.4.1 - Replace "but for obvious reasons this..." >>> with "but this nomenclature is avoid here since the >>> OSPF router ID is not necessarily a routable address." >>> >> >> Any objections? If not, I will make this change. >> >> >>> - Section 2.5.4 - Why 0.0.0.0 for the remote address for >>> multiaccess links? It seems the TLV should either be >>> omitted or set to the single neighbor address (since >>> section 1.2 limits traffic engineering to multiaccess >>> networks with 2 devices). >>> >> >> While this document doesn't work ideally for multipoint links with >> more that 2 devices, it is used. Also, this has been implemented >> and is running code, so changing the spec to omitting this TLV at >> this point would cause more problems than it would solve. >> >> >>>Suggestion: >>> >>> - Include "Implications on Graceful Restart" section >>> similar to draft-ietf-ccamp-ospf-gmpls-extensions-08.txt. >>> Explicitly state that the goal is to maintain >>> existing traffic engineered paths while discouraging >>> any new ones until reservation state is obtained. >>> >> >> Instead, how about specifying explicitly in the ospf gmpls draft >> that the text there applies to the base TE doc as well as the GMPLS >> extensions? Otherwise, draft-katz-yeung-traffic-08.txt will need >> the graceful restart doc as a normative reference. Note that the >> TE doc has been around for many years, with interoperable >> implementations etc., while graceful restart for OSPF much more recent. >> >> BTW, can we start to progress the graceful restart (aka hitless >> restart) document? There are interoperable implementations now, and >> while this doc is not as mature as TE, it certainly seems ready .... >> >> Kireeti. >> >> > > >-- >Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 16:03:22 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09379 for ; Fri, 25 Oct 2002 16:03:21 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.007911D9@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 16:05:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 341323 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 16:05:40 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 16:05:40 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 008AC26281F for ; Fri, 25 Oct 2002 13:05:37 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <002401c27c58$70216c00$0301a8c0@tom3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DB9A3A8.3010704@redback.com> Date: Fri, 25 Oct 2002 16:03:52 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Tom Petch wrote: > Before the multi-access issue is declared closed I believe there > should be an agreed definition of what multi-access means in this > context. Because in an OSPF context ie RFC2328 (which is where I am > coming from), the term multi-access has now largely disappeared. The > terminology is either 'Broadcast' or 'Non-Broadcast MultiAccess' and > both are defined as (p.9) Hi Tom, Muli-access encompasses both these types. > > ' Networks supporting many (more than two) attached routers' > > So what is a two router only multi-access network? Nothing to do with > OSPF :-( > > And this is a can of worms because RFC2328 seems not to allow a DR on > two router networks while certain manufacturers of routers do (and I > even see LSA with a DR when there is only one of those manufacturers' > routers active!). Assuming the routers are eligible (priority != 0), RFC 2328 does specify DR (and BDR) election on a 2 router broadcast or NBMA network. In fact, a router will become a DR on a 1 router network - it just won't originate a network LSA. > > Here, by implication, from the TLV definition in this draft, > multiaccess means a network with a DR. And then there are other > nasties like NBMA networks which lose full connectivity and so should > stop having a DR! > > Tom Petch > > -----Original Message----- > From: Acee Lindem > To: OSPF@DISCUSS.MICROSOFT.COM > Date: 22 October 2002 21:30 > Subject: Re: Comments on draft-katz-yeung-traffic-08.txt > > > >>Kireeti, >> >>Can we close on the remaining issues? >> >> 1. With respect to the Remote Interface IP Addres TLV, is >> there really any reason to include it with a value of 0.0.0.0 >> for a multi-access link? I can't see how there could be >> a compatibility issue since the rough count on the list >> revealed more implementations that omitted the TLV >> altogether. >> >> 2. With respect to more than two routers on a multi-access >> network, it seems there is considerable support for >> allowing this even though it is not fully specified. >> Could you add something along these lines to the second >> paragraph of the limitations section: >> >> "Operation over multiaccess links with more than two >> devices is not specifically prohibited. TE operation >> and the use of reservation state is a matter for >> further study". >> >> >>Thanks, >>Acee >> >> >> >> >>Kireeti Kompella wrote: >> >> >>>Hi Acee, >>> >>>On Thu, 17 Oct 2002, Acee Lindem wrote: >>> >>> >>> >>>>Comments: >>>> >>>> - The LSA Header Diagram in section 2.3.1 does not reflect >>>> the fact that the instance has been extended to 24 bits. >>>> >>>> >>>Thanks. Someone else also pointed this out. >>> >>> >>> >>>> - Section 2.4.1 - Replace "but for obvious reasons this..." >>>> with "but this nomenclature is avoid here since the >>>> OSPF router ID is not necessarily a routable address." >>>> >>>> >>>Any objections? If not, I will make this change. >>> >>> >>> >>>> - Section 2.5.4 - Why 0.0.0.0 for the remote address for >>>> multiaccess links? It seems the TLV should either be >>>> omitted or set to the single neighbor address (since >>>> section 1.2 limits traffic engineering to multiaccess >>>> networks with 2 devices). >>>> >>>> >>>While this document doesn't work ideally for multipoint links with >>>more that 2 devices, it is used. Also, this has been implemented >>>and is running code, so changing the spec to omitting this TLV at >>>this point would cause more problems than it would solve. >>> >>> >>> >>>>Suggestion: >>>> >>>> - Include "Implications on Graceful Restart" section >>>> similar to draft-ietf-ccamp-ospf-gmpls-extensions-08.txt. >>>> Explicitly state that the goal is to maintain >>>> existing traffic engineered paths while discouraging >>>> any new ones until reservation state is obtained. >>>> >>>> >>>Instead, how about specifying explicitly in the ospf gmpls draft >>>that the text there applies to the base TE doc as well as the GMPLS >>>extensions? Otherwise, draft-katz-yeung-traffic-08.txt will need >>>the graceful restart doc as a normative reference. Note that the >>>TE doc has been around for many years, with interoperable >>>implementations etc., while graceful restart for OSPF much more >>> > recent. > >>>BTW, can we start to progress the graceful restart (aka hitless >>>restart) document? There are interoperable implementations now, >>> > and > >>>while this doc is not as mature as TE, it certainly seems ready >>> > .... > >>>Kireeti. >>> >>> >>> >> >>-- >>Acee >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Oct 25 17:10:50 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12105 for ; Fri, 25 Oct 2002 17:10:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.007915E8@cherry.ease.lsoft.com>; Fri, 25 Oct 2002 17:13:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 341665 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 25 Oct 2002 17:13:07 -0400 Received: from 62.241.160.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 25 Oct 2002 17:13:07 -0400 Received: from tom3 (userai59.uk.uudial.com [62.188.133.89]) by colossus.systems.pipex.net (Postfix) with SMTP id 17EAE16000332 for ; Fri, 25 Oct 2002 22:13:04 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Message-ID: <001f01c27c6a$d4fca560$0301a8c0@tom3> Date: Fri, 25 Oct 2002 22:08:14 +0100 Reply-To: Mailing List Sender: Mailing List From: Tom Petch Subject: Re: Comments on draft-katz-yeung-traffic-08.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Comment in line. -----Original Message----- From: Acee Lindem To: OSPF@DISCUSS.MICROSOFT.COM Date: 25 October 2002 21:05 Subject: Re: Comments on draft-katz-yeung-traffic-08.txt >Tom Petch wrote: > >> Before the multi-access issue is declared closed I believe there >> should be an agreed definition of what multi-access means in this >> context. Because in an OSPF context ie RFC2328 (which is where I am >> coming from), the term multi-access has now largely disappeared. The >> terminology is either 'Broadcast' or 'Non-Broadcast MultiAccess' and >> both are defined as (p.9) > > >Hi Tom, > >Muli-access encompasses both these types. Then say so! To quote RFC2178 'References to "multi-access" networks have been deleted' ie OSPF abandoned the term multi-access in July 1997 so if you are going to re-introduce it in 2002, you need to define it so that when this RFC-to-be is read by people (unlike like you and me) whose experience does not span the previous decade, they are clear what you mean. > > >> >> ' Networks supporting many (more than two) attached routers' >> >> So what is a two router only multi-access network? Nothing to do with >> OSPF :-( >> >> And this is a can of worms because RFC2328 seems not to allow a DR on >> two router networks while certain manufacturers of routers do (and I >> even see LSA with a DR when there is only one of those manufacturers' >> routers active!). > > >Assuming the routers are eligible (priority != 0), RFC 2328 does >specify DR (and BDR) election on a 2 router broadcast or NBMA network. >In fact, a router will become a DR on a 1 router network - it just >won't originate a network LSA. > > >> >> Here, by implication, from the TLV definition in this draft, >> multiaccess means a network with a DR. And then there are other >> nasties like NBMA networks which lose full connectivity and so should >> stop having a DR! >> >> Tom Petch >> >> -----Original Message----- >> From: Acee Lindem >> To: OSPF@DISCUSS.MICROSOFT.COM >> Date: 22 October 2002 21:30 >> Subject: Re: Comments on draft-katz-yeung-traffic-08.txt >> >> >> >>>Kireeti, >>> >>>Can we close on the remaining issues? >>> >>> 1. With respect to the Remote Interface IP Addres TLV, is >>> there really any reason to include it with a value of 0.0.0.0 >>> for a multi-access link? I can't see how there could be >>> a compatibility issue since the rough count on the list >>> revealed more implementations that omitted the TLV >>> altogether. >>> >>> 2. With respect to more than two routers on a multi-access >>> network, it seems there is considerable support for >>> allowing this even though it is not fully specified. >>> Could you add something along these lines to the second >>> paragraph of the limitations section: >>> >>> "Operation over multiaccess links with more than two >>> devices is not specifically prohibited. TE operation >>> and the use of reservation state is a matter for >>> further study". >>> >>> >>>Thanks, >>>Acee >>> >>> >>> >>> >>>Kireeti Kompella wrote: >>> >>> >>>>Hi Acee, >>>> >>>>On Thu, 17 Oct 2002, Acee Lindem wrote: >>>> >>>> >>>> >>>>>Comments: >>>>> >>>>> - The LSA Header Diagram in section 2.3.1 does not reflect >>>>> the fact that the instance has been extended to 24 bits. >>>>> >>>>> >>>>Thanks. Someone else also pointed this out. >>>> >>>> >>>> >>>>> - Section 2.4.1 - Replace "but for obvious reasons this..." >>>>> with "but this nomenclature is avoid here since the >>>>> OSPF router ID is not necessarily a routable address." >>>>> >>>>> >>>>Any objections? If not, I will make this change. >>>> >>>> >>>> >>>>> - Section 2.5.4 - Why 0.0.0.0 for the remote address for >>>>> multiaccess links? It seems the TLV should either be >>>>> omitted or set to the single neighbor address (since >>>>> section 1.2 limits traffic engineering to multiaccess >>>>> networks with 2 devices). >>>>> >>>>> >>>>While this document doesn't work ideally for multipoint links with >>>>more that 2 devices, it is used. Also, this has been implemented >>>>and is running code, so changing the spec to omitting this TLV at >>>>this point would cause more problems than it would solve. >>>> >>>> >>>> >>>>>Suggestion: >>>>> >>>>> - Include "Implications on Graceful Restart" section >>>>> similar to draft-ietf-ccamp-ospf-gmpls-extensions-08.txt. >>>>> Explicitly state that the goal is to maintain >>>>> existing traffic engineered paths while discouraging >>>>> any new ones until reservation state is obtained. >>>>> >>>>> >>>>Instead, how about specifying explicitly in the ospf gmpls draft >>>>that the text there applies to the base TE doc as well as the GMPLS >>>>extensions? Otherwise, draft-katz-yeung-traffic-08.txt will need >>>>the graceful restart doc as a normative reference. Note that the >>>>TE doc has been around for many years, with interoperable >>>>implementations etc., while graceful restart for OSPF much more >>>> >> recent. >> >>>>BTW, can we start to progress the graceful restart (aka hitless >>>>restart) document? There are interoperable implementations now, >>>> >> and >> >>>>while this doc is not as mature as TE, it certainly seems ready >>>> >> .... >> >>>>Kireeti. >>>> >>>> >>>> >>> >>>-- >>>Acee >>> >> > > >-- >Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sat Oct 26 18:56:19 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13545 for ; Sat, 26 Oct 2002 18:56:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00793D49@cherry.ease.lsoft.com>; Sat, 26 Oct 2002 18:58:36 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 344708 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 26 Oct 2002 18:58:36 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 26 Oct 2002 18:58:35 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id C312D1DCC60 for ; Sat, 26 Oct 2002 15:58:33 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DBB1DA1.406@redback.com> Date: Sat, 26 Oct 2002 18:56:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: > Hi Acee/Don, Hi Vishwas, > > >>Finally, there was also a previous discussion I was involved >>in regarding contraining the grace period to a max value of >>MaxAge (3600). Is this being included in the new draft? >> > > I think MaxAge is a best case value. An LSA originated x minutes before > restart would be MaxAged after (MaxAge - x) time. As the maximum value of x > can be RefreshInterval, an ideal value would be closer to lesser than > (MaxAge - RefreshInterval), otherwise there would be large chances of the > hitless restart being a normal restart. (The MaxAgeDiff value would cancel > out.) I agree - LSRefreshTime seems like a good upper bound. An implementation could refresh its pre-start LSAs in process of graceful restart but I don't think this makes sense. 30 minutes should be more than enough time for a graceful restart. > > I think to make the graceful-restart spec match existing implementations, we > should allow an option of a "non-strict check" for the helper deciding to > exit restart. > > Besides in the strict check case we could add the > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0203&L=ospf&T=0&F=&S=& > P=1902 I'd like to remain true to John's original specification which minimizes the likelihood of a graceful restart resulting in a routing loop or blackholed traffic. We could possibly document alternatives in a separate section. If the mechanism you describe acheives the same goals with respect to minimizing routing loops/blackholing using less a conservative criteria for terminating graceful restart then maybe it warrents a separate draft. Although there have been a lot of good comments and suggestions, my goal is to submit the proven specification (backed by serveral deployed implemenations) to the IESG without major modifications (unless something is broken). > > Also as the only change to the draft for OSPFv3 part would be defining a new > LSA type, do we intend to describe it here in this draft itself? This document is on a different schedule so I'd like it to remain separate. Thanks, Acee > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Thursday, October 24, 2002 9:31 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Hitless restart > > > Hi Don, > > Don Goodspeed wrote: > > >>Acee, >> >>On the issue of updating the grace period, I would only >>update in case the reason code changed, and changed to >>a value of unknown (and/or we could add a new "unplanned >>restart" reason code). >> > > > I'm not sure there is any difference between unknown > and unplanned. > > >>Also, I remember a while back a discussion on the list >>between yourself, Padma, and John regarding the IP address >>field in the Grace LSA. I cannot remember the specific issue, >>but I assume there's been a resolution (or at least an >>understanding)? >> > > > This was the comment that Padma made that the IP interface > address TLV is not necessary to identify the restarting > neighbor on multi-access (broadcast and NBMA) links. I pointed out > that it wasn't really necessary since the grace LSA was already > scoped to an OSPF interface and there could only be one > neighbor adjacency corresponding to the router ID (even if > one was running OSPF on more than one subnet). John pointed > out that OSPFv2 always uses the IP interface address to identify > neighboring routers on multi-access networks so it should > included to be consistent with the RFC 2328 (numerous sections). > I tend to agree with this and would vote to leave it in. > > However, it is not needed for OSPFv3 since here neighboring > routers are always identified by router ID. > > > >>Finally, there was also a previous discussion I was involved >>in regarding contraining the grace period to a max value of >>MaxAge (3600). Is this being included in the new draft? >> > > > That could be documented. > > > >>Thanks, >>Don >> >> --- On Tue 10/22, Acee Lindem wrote: >>From: Acee Lindem [mailto: acee@REDBACK.COM] >>To: OSPF@DISCUSS.MICROSOFT.COM >>Date: Tue, 22 Oct 2002 14:49:37 -0400 >>Subject: Re: Hitless restart >> >> >> >>>Manral, Vishwas wrote: >>> >>> >>> >>>>Hi Acee, >>>> >>>>I agree to Padma's statement that we are using link-local LSA to >>>> >>>> >>>signal >>> >>> >>>>hitless-restart, because we would not want the LSA to be flooded by >>>> >>>> >>>the >>> >>> >>>>neighbors into the area. We are signalling router parameters in the >>>> >>>> >>>link >>> >>> >>>>local LSA. >>>> >>>>Regarding 2. >>>>- I think we should update the grace-period/reason only when we have >>>> >>>> >>>a >>> >>> >>>>change in content of the Grace LSA from the neighbor to the >>>> >>>> >>>restarting >>> >>> >>>>router on any interface. So if we get a different value of >>>>grace-period/restart reason we update and restart the grace period on >>>> >>>> >>>the >>> >>> >>>>helper else we do not. This would be in keeping with Section 3 of the >>>> >>>> >>>draft. >>> >>> >>>Vishwas, >>> >>>I agree that if we do agree to change the existing specification than we >>>should, in fact, honor changes to the grace-period/restart-reason. One >>>of my concerns with this approach is the added complexity (consider >>>determining which of multiple link local LSAs received on different >>>links is more recent). >>> >>>Thanks, >>> >>>Acee >>> >>> >>> >>> >>>>- I think the first grace LSA withdrawn would cause the router to >>>> >>>> >>>exit >>> >>> >>>>hitless restart mode for that neighbor. >>>> >>>>Thanks, >>>>Vishwas >>>> >>>>-----Original Message----- >>>>From: Acee Lindem [mailto:acee@REDBACK.COM] >>>>Sent: Tuesday, October 22, 2002 8:22 PM >>>>To: OSPF@DISCUSS.MICROSOFT.COM >>>>Subject: Re: Hitless restart >>>> >>>> >>>>All, >>>> >>>>I think we have a "rough concensus" that the restarting >>>> >>>> >>>router >>> >>> >>>>should NOT try to optimize flooding of grace LSAs. I've >>>>only had one vote for this and I believe the vote was more >>>>for flooding optimizations in general than this particular >>>>scenario. >>>> >>>> >>>>Padma, >>>> >>>>I don't think it simplifies the helper code (or specification) >>>>to apply the grace LSA to all neighbor instances of restarting >>>>router. Here are my reasons: >>>> >>>> 1. Conceptually, I don't think it is right to apply the link >>>> local grace LSA to neighbors that are not on the link. >>>> >>>> 2. There are simply more corner cases - >>>> >>>> - When you receive a second grace LSA from the restarting >>>> router, do you update the reason and grace period for >>>> all neighbor instances or only ones on that segment? >>>> >>>> - When do exit helper mode? Is it when the first grace >>>> LSA is withdrawn or all the grace LSAs? I certainly don't >>>> think there should be disconnect between entering and >>>> exiting helper mode. >>>> >>>>I do agree that it is somewhat more robust for the case where >>>>you are adjacent with the same router on more than one link. >>>>However, I don't see this as a real big gain. Has anyone >>>>else implemented this draft? >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>>Padma Pillay-Esnault wrote: >>>> >>>> >>>> >>>> >>>>>Rajesh >>>>> >>>>> >>>>>Rajesh Varadarajan wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Acee, Padma, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>>>I do think it simplifies things if a >>>>>>>>>> >>>>>>>>>> >>>restarting router originates the >>> >>> >>>>grace LSAs >>>> >>>> >>>> >>>>>>>>>>on all it's interfaces (or at least all with >>>>>>>>>> >>>>>>>>>> >>>full neighbor >>> >>> >>>>>^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>> >>>>> >>>>> >>>>> >>>>>>>>>>adjacencies if it a planned restart). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>The above statement seems to imply (my reading) that a >>>>>> >>>>>> >>>restarting router >>> >>> >>>>>>can only send Grace LSA's out of some (not all) of its >>>>>> >>>>>> >>>interfaces. The >>> >>> >>>>>It doesn't imply that - clearly we send to all our neighbors. >>>>> >>>>>Padma >>>>> >>>>> >>>>> >>>>> >>>>>>spec however requires the router to send the grace-lsa out of >>>>>> >>>>>> >>>all >>> >>> >>>>>>interfaces on which it has full neigbhors. Failure to do so >>>>>> >>>>>> >>>would always >>> >>> >>>>>>result in its helper mode being terminated by others. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>>I also agree with you .. that's what I do - the >>>>>>>>> >>>>>>>>> >>>restarting router sends >>> >>> >>>>>>>>>grace lsa over all interfaces. But from a Helping >>>>>>>>> >>>>>>>>> >>>router perspective >>> >>> >>>>>>>>>we should do as in 00-txt. It simplifies the >>>>>>>>> >>>>>>>>> >>>helper code. >>> >>> >>>>>>>>>It also prevents corner cases where we might not >>>>>>>>> >>>>>>>>> >>>help all adjacencies >>> >>> >>>>>>>>>(when we should). >>>>>>>>> >>>>>>>>>Padma >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>I haven't heard anyone object to why the 00-txt. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>I will - I specifically agree with >>>>>>> >>>>>>> >>>>>>> >>>>>>> Note that Router Y only needs to receive a single >>>>>>> >>>>>>> >>>grace-LSA from >>> >>> >>>>>>> X, even if X and Y attach to multiple common >>>>>>> >>>>>>> >>>segments. >>> >>> >>>>>>>I don't like using an LSA with link local scope to >>>>>>> >>>>>>> >>>enter/terminate >>> >>> >>>>>>>helper mode for neighbors on different interfaces. It is >>>>>>> >>>>>>> >>>better if the >>> >>> >>>>>>>link local grace LSA only applies to that link. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>Given the behavior above, I think the each neighbor should be >>>>>> >>>>>> >>>considered >>> >>> >>>>>>independently on a segment by segment basis. >>>>>> >>>>>> >>>>>>thanks, >>>>>>rajesh >>>>>> >>>>-- >>>> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sun Oct 27 11:28:41 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06158 for ; Sun, 27 Oct 2002 11:28:41 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00794D48@cherry.ease.lsoft.com>; 27 Oct 2002 11:31:01 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 346783 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 27 Oct 2002 11:31:01 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 27 Oct 2002 11:31:01 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HPJMW>; Sun, 27 Oct 2002 11:31:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sun, 27 Oct 2002 11:32:50 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee, > I agree - LSRefreshTime seems like a good upper bound. An > implementation could refresh its pre-start LSAs in process > of graceful restart but I don't think this makes sense. 30 > minutes should be more than enough time for a graceful > restart. Rite. I dont think so either, however if you are documenting it, 30 minutes would be a more appropriate period. > I'd like to remain true to John's original specification which > minimizes the likelihood of a graceful restart resulting in a routing > loop or blackholed traffic. We could possibly document alternatives > in a separate section. I think it is ok to put in a seperate section. > If the mechanism you describe acheives the same goals with respect > to minimizing routing loops/blackholing using less a conservative > criteria for terminating graceful restart then maybe it warrents a > separate draft. Acee, I had given similar comments earlier, regarding minimizing the case where we exit hitless restart(without completing it) and that was put in the version-02 of the draft. This was just a follow up comment. If/when the working group feels its an important to document it, I will do that. Thanks, Vishwas > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Thursday, October 24, 2002 9:31 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Hitless restart > > > Hi Don, > > Don Goodspeed wrote: > > >>Acee, >> >>On the issue of updating the grace period, I would only >>update in case the reason code changed, and changed to >>a value of unknown (and/or we could add a new "unplanned >>restart" reason code). >> > > > I'm not sure there is any difference between unknown > and unplanned. > > >>Also, I remember a while back a discussion on the list >>between yourself, Padma, and John regarding the IP address >>field in the Grace LSA. I cannot remember the specific issue, >>but I assume there's been a resolution (or at least an >>understanding)? >> > > > This was the comment that Padma made that the IP interface > address TLV is not necessary to identify the restarting > neighbor on multi-access (broadcast and NBMA) links. I pointed out > that it wasn't really necessary since the grace LSA was already > scoped to an OSPF interface and there could only be one > neighbor adjacency corresponding to the router ID (even if > one was running OSPF on more than one subnet). John pointed > out that OSPFv2 always uses the IP interface address to identify > neighboring routers on multi-access networks so it should > included to be consistent with the RFC 2328 (numerous sections). > I tend to agree with this and would vote to leave it in. > > However, it is not needed for OSPFv3 since here neighboring > routers are always identified by router ID. > > > >>Finally, there was also a previous discussion I was involved >>in regarding contraining the grace period to a max value of >>MaxAge (3600). Is this being included in the new draft? >> > > > That could be documented. > > > >>Thanks, >>Don >> >> --- On Tue 10/22, Acee Lindem wrote: >>From: Acee Lindem [mailto: acee@REDBACK.COM] >>To: OSPF@DISCUSS.MICROSOFT.COM >>Date: Tue, 22 Oct 2002 14:49:37 -0400 >>Subject: Re: Hitless restart >> >> >> >>>Manral, Vishwas wrote: >>> >>> >>> >>>>Hi Acee, >>>> >>>>I agree to Padma's statement that we are using link-local LSA to >>>> >>>> >>>signal >>> >>> >>>>hitless-restart, because we would not want the LSA to be flooded by >>>> >>>> >>>the >>> >>> >>>>neighbors into the area. We are signalling router parameters in the >>>> >>>> >>>link >>> >>> >>>>local LSA. >>>> >>>>Regarding 2. >>>>- I think we should update the grace-period/reason only when we have >>>> >>>> >>>a >>> >>> >>>>change in content of the Grace LSA from the neighbor to the >>>> >>>> >>>restarting >>> >>> >>>>router on any interface. So if we get a different value of >>>>grace-period/restart reason we update and restart the grace period on >>>> >>>> >>>the >>> >>> >>>>helper else we do not. This would be in keeping with Section 3 of the >>>> >>>> >>>draft. >>> >>> >>>Vishwas, >>> >>>I agree that if we do agree to change the existing specification than we >>>should, in fact, honor changes to the grace-period/restart-reason. One >>>of my concerns with this approach is the added complexity (consider >>>determining which of multiple link local LSAs received on different >>>links is more recent). >>> >>>Thanks, >>> >>>Acee >>> >>> >>> >>> >>>>- I think the first grace LSA withdrawn would cause the router to >>>> >>>> >>>exit >>> >>> >>>>hitless restart mode for that neighbor. >>>> >>>>Thanks, >>>>Vishwas >>>> >>>>-----Original Message----- >>>>From: Acee Lindem [mailto:acee@REDBACK.COM] >>>>Sent: Tuesday, October 22, 2002 8:22 PM >>>>To: OSPF@DISCUSS.MICROSOFT.COM >>>>Subject: Re: Hitless restart >>>> >>>> >>>>All, >>>> >>>>I think we have a "rough concensus" that the restarting >>>> >>>> >>>router >>> >>> >>>>should NOT try to optimize flooding of grace LSAs. I've >>>>only had one vote for this and I believe the vote was more >>>>for flooding optimizations in general than this particular >>>>scenario. >>>> >>>> >>>>Padma, >>>> >>>>I don't think it simplifies the helper code (or specification) >>>>to apply the grace LSA to all neighbor instances of restarting >>>>router. Here are my reasons: >>>> >>>> 1. Conceptually, I don't think it is right to apply the link >>>> local grace LSA to neighbors that are not on the link. >>>> >>>> 2. There are simply more corner cases - >>>> >>>> - When you receive a second grace LSA from the restarting >>>> router, do you update the reason and grace period for >>>> all neighbor instances or only ones on that segment? >>>> >>>> - When do exit helper mode? Is it when the first grace >>>> LSA is withdrawn or all the grace LSAs? I certainly don't >>>> think there should be disconnect between entering and >>>> exiting helper mode. >>>> >>>>I do agree that it is somewhat more robust for the case where >>>>you are adjacent with the same router on more than one link. >>>>However, I don't see this as a real big gain. Has anyone >>>>else implemented this draft? >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>>Padma Pillay-Esnault wrote: >>>> >>>> >>>> >>>> >>>>>Rajesh >>>>> >>>>> >>>>>Rajesh Varadarajan wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Acee, Padma, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>>>I do think it simplifies things if a >>>>>>>>>> >>>>>>>>>> >>>restarting router originates the >>> >>> >>>>grace LSAs >>>> >>>> >>>> >>>>>>>>>>on all it's interfaces (or at least all with >>>>>>>>>> >>>>>>>>>> >>>full neighbor >>> >>> >>>>>^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>> >>>>> >>>>> >>>>> >>>>>>>>>>adjacencies if it a planned restart). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>The above statement seems to imply (my reading) that a >>>>>> >>>>>> >>>restarting router >>> >>> >>>>>>can only send Grace LSA's out of some (not all) of its >>>>>> >>>>>> >>>interfaces. The >>> >>> >>>>>It doesn't imply that - clearly we send to all our neighbors. >>>>> >>>>>Padma >>>>> >>>>> >>>>> >>>>> >>>>>>spec however requires the router to send the grace-lsa out of >>>>>> >>>>>> >>>all >>> >>> >>>>>>interfaces on which it has full neigbhors. Failure to do so >>>>>> >>>>>> >>>would always >>> >>> >>>>>>result in its helper mode being terminated by others. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>>I also agree with you .. that's what I do - the >>>>>>>>> >>>>>>>>> >>>restarting router sends >>> >>> >>>>>>>>>grace lsa over all interfaces. But from a Helping >>>>>>>>> >>>>>>>>> >>>router perspective >>> >>> >>>>>>>>>we should do as in 00-txt. It simplifies the >>>>>>>>> >>>>>>>>> >>>helper code. >>> >>> >>>>>>>>>It also prevents corner cases where we might not >>>>>>>>> >>>>>>>>> >>>help all adjacencies >>> >>> >>>>>>>>>(when we should). >>>>>>>>> >>>>>>>>>Padma >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>I haven't heard anyone object to why the 00-txt. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>I will - I specifically agree with >>>>>>> >>>>>>> >>>>>>> >>>>>>> Note that Router Y only needs to receive a single >>>>>>> >>>>>>> >>>grace-LSA from >>> >>> >>>>>>> X, even if X and Y attach to multiple common >>>>>>> >>>>>>> >>>segments. >>> >>> >>>>>>>I don't like using an LSA with link local scope to >>>>>>> >>>>>>> >>>enter/terminate >>> >>> >>>>>>>helper mode for neighbors on different interfaces. It is >>>>>>> >>>>>>> >>>better if the >>> >>> >>>>>>>link local grace LSA only applies to that link. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>Given the behavior above, I think the each neighbor should be >>>>>> >>>>>> >>>considered >>> >>> >>>>>>independently on a segment by segment basis. >>>>>> >>>>>> >>>>>>thanks, >>>>>>rajesh >>>>>> >>>>-- >>>> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 28 09:41:25 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11423 for ; Mon, 28 Oct 2002 09:41:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.007969BA@cherry.ease.lsoft.com>; Mon, 28 Oct 2002 9:43:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 349886 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 28 Oct 2002 09:43:41 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 28 Oct 2002 09:43:40 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 3A423473CCC; Mon, 28 Oct 2002 06:43:39 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <001f01c27c6a$d4fca560$0301a8c0@tom3> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DBD4C8D.4040404@redback.com> Date: Mon, 28 Oct 2002 09:41:17 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on draft-katz-yeung-traffic-08.txt Comments: To: Kireeti Kompella To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Tom, Kireeti can keep this on his list of editorial comments to apply prior to publication. This document has been around for years and has been through last call for both the TE and OSPF WGs. Hence, I think the best way to handle it would be with a single statement defining multi-access for the context of the draft. Tom Petch wrote: > Comment in line. > > -----Original Message----- > From: Acee Lindem > To: OSPF@DISCUSS.MICROSOFT.COM > Date: 25 October 2002 21:05 > Subject: Re: Comments on draft-katz-yeung-traffic-08.txt > > > >>Tom Petch wrote: >> >> >>>Before the multi-access issue is declared closed I believe there >>>should be an agreed definition of what multi-access means in this >>>context. Because in an OSPF context ie RFC2328 (which is where I >>> > am > >>>coming from), the term multi-access has now largely disappeared. >>> > The > >>>terminology is either 'Broadcast' or 'Non-Broadcast MultiAccess' >>> > and > >>>both are defined as (p.9) >>> >> >>Hi Tom, >> >>Muli-access encompasses both these types. >> > > > Then say so! To quote RFC2178 > > 'References to "multi-access" networks have been deleted' > > ie OSPF abandoned the term multi-access in July 1997 so if you are > going to re-introduce it in 2002, you need to define it so that when > this RFC-to-be is read by people (unlike like you and me) whose > experience does not span the previous decade, they are clear what you > mean. > > >> >>>' Networks supporting many (more than two) attached routers' >>> >>>So what is a two router only multi-access network? Nothing to do >>> > with > >>>OSPF :-( >>> >>>And this is a can of worms because RFC2328 seems not to allow a DR >>> > on > >>>two router networks while certain manufacturers of routers do (and >>> > I > >>>even see LSA with a DR when there is only one of those >>> > manufacturers' > >>>routers active!). >>> >> >>Assuming the routers are eligible (priority != 0), RFC 2328 does >>specify DR (and BDR) election on a 2 router broadcast or NBMA >> > network. > >>In fact, a router will become a DR on a 1 router network - it just >>won't originate a network LSA. >> >> >> >>>Here, by implication, from the TLV definition in this draft, >>>multiaccess means a network with a DR. And then there are other >>>nasties like NBMA networks which lose full connectivity and so >>> > should > >>>stop having a DR! >>> >>>Tom Petch >>> >>>-----Original Message----- >>>From: Acee Lindem >>>To: OSPF@DISCUSS.MICROSOFT.COM >>>Date: 22 October 2002 21:30 >>>Subject: Re: Comments on draft-katz-yeung-traffic-08.txt >>> >>> >>> >>> >>>>Kireeti, >>>> >>>>Can we close on the remaining issues? >>>> >>>> 1. With respect to the Remote Interface IP Addres TLV, is >>>> there really any reason to include it with a value of 0.0.0.0 >>>> for a multi-access link? I can't see how there could be >>>> a compatibility issue since the rough count on the list >>>> revealed more implementations that omitted the TLV >>>> altogether. >>>> >>>> 2. With respect to more than two routers on a multi-access >>>> network, it seems there is considerable support for >>>> allowing this even though it is not fully specified. >>>> Could you add something along these lines to the second >>>> paragraph of the limitations section: >>>> >>>> "Operation over multiaccess links with more than two >>>> devices is not specifically prohibited. TE operation >>>> and the use of reservation state is a matter for >>>> further study". >>>> >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>>>Kireeti Kompella wrote: >>>> >>>> >>>> >>>>>Hi Acee, >>>>> >>>>>On Thu, 17 Oct 2002, Acee Lindem wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Comments: >>>>>> >>>>>> - The LSA Header Diagram in section 2.3.1 does not reflect >>>>>> the fact that the instance has been extended to 24 bits. >>>>>> >>>>>> >>>>>> >>>>>Thanks. Someone else also pointed this out. >>>>> >>>>> >>>>> >>>>> >>>>>> - Section 2.4.1 - Replace "but for obvious reasons this..." >>>>>> with "but this nomenclature is avoid here since the >>>>>> OSPF router ID is not necessarily a routable address." >>>>>> >>>>>> >>>>>> >>>>>Any objections? If not, I will make this change. >>>>> >>>>> >>>>> >>>>> >>>>>> - Section 2.5.4 - Why 0.0.0.0 for the remote address for >>>>>> multiaccess links? It seems the TLV should either be >>>>>> omitted or set to the single neighbor address (since >>>>>> section 1.2 limits traffic engineering to multiaccess >>>>>> networks with 2 devices). >>>>>> >>>>>> >>>>>> >>>>>While this document doesn't work ideally for multipoint links with >>>>>more that 2 devices, it is used. Also, this has been implemented >>>>>and is running code, so changing the spec to omitting this TLV at >>>>>this point would cause more problems than it would solve. >>>>> >>>>> >>>>> >>>>> >>>>>>Suggestion: >>>>>> >>>>>> - Include "Implications on Graceful Restart" section >>>>>> similar to draft-ietf-ccamp-ospf-gmpls-extensions-08.txt. >>>>>> Explicitly state that the goal is to maintain >>>>>> existing traffic engineered paths while discouraging >>>>>> any new ones until reservation state is obtained. >>>>>> >>>>>> >>>>>> >>>>>Instead, how about specifying explicitly in the ospf gmpls draft >>>>>that the text there applies to the base TE doc as well as the >>>>> > GMPLS > >>>>>extensions? Otherwise, draft-katz-yeung-traffic-08.txt will need >>>>>the graceful restart doc as a normative reference. Note that the >>>>>TE doc has been around for many years, with interoperable >>>>>implementations etc., while graceful restart for OSPF much more >>>>> >>>>> >>>recent. >>> >>> >>>>>BTW, can we start to progress the graceful restart (aka hitless >>>>>restart) document? There are interoperable implementations now, >>>>> >>>>> >>>and >>> >>> >>>>>while this doc is not as mature as TE, it certainly seems ready >>>>> >>>>> >>>.... >>> >>> >>>>>Kireeti. >>>>> >>>>> >>>>> >>>>> >>>>-- >>>>Acee >>>> >>>> >> >>-- >>Acee >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 28 17:52:24 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02814 for ; Mon, 28 Oct 2002 17:52:23 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0079782F@cherry.ease.lsoft.com>; Mon, 28 Oct 2002 17:54:43 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 351570 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 28 Oct 2002 17:54:42 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 28 Oct 2002 17:54:42 -0400 Received: (qmail 3221 invoked from network); 28 Oct 2002 22:54:41 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 28 Oct 2002 22:54:41 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id RAA25514 for ; Mon, 28 Oct 2002 17:54:41 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_13601993610" Message-ID: <200210282254.RAA25514@bigbird.xebeo.com> Date: Mon, 28 Oct 2002 17:54:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multipart MIME message. --==_Exmh_13601993610 Content-Type: text/plain; charset=us-ascii Folks, Here is a strawman of the Charter. Please have a look at and send any comments you may have to me or Acee or to the list. The current charter is largely designed to clear up items that have pending for a while. The charter will be re-visited periodically and new items that come up will be added after discussions with the ADs. Thanks, Rohit and Acee (OSPF WG Co-chairs) --==_Exmh_13601993610 Content-Type: text/plain ; name="charter.txt"; charset=us-ascii Content-Description: charter.txt Content-Disposition: attachment; filename="charter.txt" Goals and Milestones: Done Submit OSPF for IPv6 to IESG for consideration as a Standard. Done Update the OSPF NSSA option specified in RFC 1587 and submit to IESG for consideration as a Proposed Standard. Done+ Develop Traffic Engineering extensions for OSPFv2 and submit it to the IESG as a Proposed Standard. MAR 03 Submit to IESG a document which updates RFC 1793 allowing detection of demand circuit neighbors whose OSPF process has exited. MAR 03 Submit to IESG a BCP advocating that OSPF LSA refreshes be spread out over time MAR 03 Submit to IESG a BCP advocating that OSPF Hellos be given preference over other OSPF control traffic. MAR 03 Document Alternative ABR implementations and submit to IESG as an Informational RFC. MAR 03 Develop a hitless restart mechanism for OSPF and submit it to the IESG as a Proposed Standard. NOV 03 Update OSPFv2 MIB and submit to IESG as a Standard, replacing RFC 1850 NOV 03 Extend the hitless restart mechanism to OSPFv3 and submit it to the IESG as a Proposed Standard. NOV 03 Develop Traffic Engineering extensions for OSPFv3 and submit it to the IESG as a Proposed Standard. NOV 03 Develop OSPF for IPv6 MIB and submit to IESG for consideration as a Proposed Standard. NOV 03 Specify handling of IPv6 site-local address in OSPFv3 and submit to IESG for consideration as a Proposed Standard. NOV 03 Specify IPSEC usage with OSPFv3 and submit to IESG for consideration as a Proposed Standard. Dropped OCT 01 Update MOSPF specification with bug fixes and changes required by RFC 2328. Submit to IESG as Draft Standard JAN 02 Develop pruning support for MOSPF, allowing it to be used in a transit multicast domain and with IGMPv3. Submit to IESG as Proposed Standard JAN 02 Develop mechanisms to reduce OSPF flooding traffic in highly connected network topologies. Submit to IESG as Proposed Standard. [+] Item was submitted to IESG once and is awaiting a resubmission after AD review. $Id: charter.txt,v 1.13 2002/10/28 14:27:41 rohit Exp rohit $ --==_Exmh_13601993610-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 28 18:19:44 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03516 for ; Mon, 28 Oct 2002 18:19:44 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00797A90@cherry.ease.lsoft.com>; Mon, 28 Oct 2002 18:22:05 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 351691 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 28 Oct 2002 18:22:05 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 28 Oct 2002 18:22:04 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA15746 for ; Mon, 28 Oct 2002 18:22:01 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA08746 for ; Mon, 28 Oct 2002 18:22:03 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4W8KGXBJ>; Mon, 28 Oct 2002 18:22:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC5576341D@vie-msgusr-01.dc.fore.com> Date: Mon, 28 Oct 2002 18:22:02 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Rohit/Acee, Some quick comments w.r.t new charter. 1. Can you consider "Flooding Optimizations" into charter ? If not, can you please explain the reason, why we should not ? This is field of its own - we might expect lot of drafts. 2. One of the Alex's work "OSPF Link-local Signaling" will be very imp for future OSPF enhancements. As you know, the options are getting over in OSPF headers. 3. "OSPF TE" and "OSPF Hitless Restart" MIBs must be considered as separate drafts. Recent OSPFv2 MIB only talks about Opaque LSAs - but content carried in those LSAs are not specified in any MIB. I am be willing to write those drafts - what is your opinion, Kireeti/Padma ? 4. "Flooding over Parallel Point-to-Point Links" can be considered as an informational RFC. Thank You. -- Venkata. -> -----Original Message----- -> From: Rohit Dube [mailto:rohit@XEBEO.COM] -> Sent: Monday, October 28, 2002 5:55 PM -> To: OSPF@DISCUSS.MICROSOFT.COM -> Subject: OSPF WG Charter Proposal -> -> -> -> Folks, -> -> Here is a strawman of the Charter. Please have a look at and send -> any comments you may have to me or Acee or to the list. -> -> The current charter is largely designed to clear up items that have -> pending for a while. The charter will be re-visited periodically and -> new items that come up will be added after discussions with the ADs. -> -> Thanks, -> Rohit and Acee -> (OSPF WG Co-chairs) -> -> -> From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 28 18:44:55 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04009 for ; Mon, 28 Oct 2002 18:44:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00797AA4@cherry.ease.lsoft.com>; Mon, 28 Oct 2002 18:47:16 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 351794 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 28 Oct 2002 18:47:16 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 28 Oct 2002 18:47:16 -0400 Received: (qmail 7030 invoked from network); 28 Oct 2002 23:47:16 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 28 Oct 2002 23:47:16 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id SAA03696 for ; Mon, 28 Oct 2002 18:47:16 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210282347.SAA03696@bigbird.xebeo.com> Date: Mon, 28 Oct 2002 18:47:16 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from "Naidu, Venkata" of "Mon, 28 Oct 2002 18:22:02 EST." <39469E08BD83D411A3D900204840EC5576341D@vie-msgusr-01.dc.fore.com> Precedence: list Venkata, Thanks for your comments. Some of my own are inline. A meta comment first - our first goal is to clear the decks by getting done with all the work (drafts + implementation experience) that has accumulated over time. Once enough of this done, it would be a natural point for the WG to expand on the charter. On Mon, 28 Oct 2002 18:22:02 -0500 "Naidu, Venkata" writes: =>Rohit/Acee, => => Some quick comments w.r.t new charter. => => 1. Can you consider "Flooding Optimizations" into charter ? => If not, can you please explain the reason, why we should not ? => This is field of its own - we might expect lot of drafts. We considered this but would like to see some operational requirements before including this in the charter. Is anybody running OSPF networks hitting this problem with no workarounds in sight? It would be a candidate for a future version of the charter once some of the current items clear. => => 2. One of the Alex's work "OSPF Link-local Signaling" will => be very imp for future OSPF enhancements. As you know, => the options are getting over in OSPF headers. => => 3. "OSPF TE" and "OSPF Hitless Restart" MIBs must be => considered as separate drafts. Recent OSPFv2 MIB only => talks about Opaque LSAs - but content carried in those => LSAs are not specified in any MIB. I am be willing => to write those drafts - what is your opinion, Kireeti/Padma ? I was considering reflecting OSPF-TE in a MIB too. And this could be a potential item for this or a future. But is there an operator burning for this stuff? => => 4. "Flooding over Parallel Point-to-Point Links" can be => considered as an informational RFC. What draft are you referring to? => => Thank You. => =>-- =>Venkata. Best, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 28 19:04:43 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04590 for ; Mon, 28 Oct 2002 19:04:43 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.007979E1@cherry.ease.lsoft.com>; Mon, 28 Oct 2002 19:07:05 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 351844 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 28 Oct 2002 19:07:05 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 28 Oct 2002 19:07:05 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA17760 for ; Mon, 28 Oct 2002 19:07:01 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA13331 for ; Mon, 28 Oct 2002 19:07:03 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4W8KGYK4>; Mon, 28 Oct 2002 19:07:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC5576341E@vie-msgusr-01.dc.fore.com> Date: Mon, 28 Oct 2002 19:07:02 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Rohit, -> => 3. "OSPF TE" and "OSPF Hitless Restart" MIBs must be -> => considered as separate drafts. Recent OSPFv2 MIB only -> => talks about Opaque LSAs - but content carried in those -> => LSAs are not specified in any MIB. I am be willing -> => to write those drafts - what is your opinion, Kireeti/Padma ? -> -> I was considering reflecting OSPF-TE in a MIB too. And this could -> be a potential item for this or a future. But is there an operator -> burning for this stuff? Yes :-) there are definite requests I encounter for OSPF-TE MIB. If not Hitless Restart MIB, we do need OSPF-TE mib. As you know, it is potential candidate for deployment in MPLS (apart from VPNs). -> => -> => 4. "Flooding over Parallel Point-to-Point Links" can be -> => considered as an informational RFC. -> -> What draft are you referring to? draft-ietf-ospf-ppp-flood-01.txt -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Oct 28 21:33:36 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07640 for ; Mon, 28 Oct 2002 21:33:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00798103@cherry.ease.lsoft.com>; Mon, 28 Oct 2002 21:35:55 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 352275 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 28 Oct 2002 21:35:55 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 28 Oct 2002 21:35:55 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 5BDE4FC055 for ; Mon, 28 Oct 2002 18:35:53 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <39469E08BD83D411A3D900204840EC5576341E@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DBDF375.6010000@redback.com> Date: Mon, 28 Oct 2002 21:33:25 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Naidu, Venkata wrote: > Rohit, > > -> => 3. "OSPF TE" and "OSPF Hitless Restart" MIBs must be > -> => considered as separate drafts. Recent OSPFv2 MIB only > -> => talks about Opaque LSAs - but content carried in those > -> => LSAs are not specified in any MIB. I am be willing > -> => to write those drafts - what is your opinion, Kireeti/Padma ? > -> > -> I was considering reflecting OSPF-TE in a MIB too. And this could > -> be a potential item for this or a future. But is there an operator > -> burning for this stuff? > > Yes :-) there are definite requests I encounter for OSPF-TE MIB. > If not Hitless Restart MIB, we do need OSPF-TE mib. As you know, > it is potential candidate for deployment in MPLS (apart from VPNs). > > -> => > -> => 4. "Flooding over Parallel Point-to-Point Links" can be > -> => considered as an informational RFC. > -> > -> What draft are you referring to? > > draft-ietf-ospf-ppp-flood-01.txt Venkata, This draft has expired and I don't think there are any plans to re-submit it. > > -- > Venkata. > > Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 29 08:00:44 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01932 for ; Tue, 29 Oct 2002 08:00:44 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00798DBD@cherry.ease.lsoft.com>; Tue, 29 Oct 2002 8:03:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 354446 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Oct 2002 08:03:04 -0500 Received: from 192.122.173.140 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 29 Oct 2002 07:53:03 -0400 Received: from ROJOSEW2K ([10.77.139.146]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id SAA03096 for ; Tue, 29 Oct 2002 18:22:31 +0530 (IST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <242301c27f4a$1c7b5f30$928b4d0a@apac.cisco.com> Date: Tue, 29 Oct 2002 18:22:59 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Query on implementation of SNMP TRAP ospfTxRetransmit To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, The TRAP message ospfTxRetransmit is supposed to contain Lsdb entry details as given in its defenition. When an OSPF packet contains is associated with only one Lsdb, there are no problems. But, when the same OSPF packet like UPDATE, DATABASE DESCRIPTION, etc is associated with more than one Lsdb entry, what can be done? Can we set Lsdb details to zero and send? Anybody knows about some implementations? ospfTxRetransmit NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfIfIpAddress, ospfAddressLessIf, ospfNbrRtrId, -- Destination ospfPacketType, ospfLsdbType, ospfLsdbLsid, ospfLsdbRouterId } STATUS current DESCRIPTION "An ospfTxRetransmit trap signifies than an OSPF packet has been retransmitted on a non- virtual interface. All packets that may be re- transmitted are associated with an LSDB entry. The LS type, LS ID, and Router ID are used to identify the LSDB entry." Thanks, Roy From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 29 08:18:45 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02485 for ; Tue, 29 Oct 2002 08:18:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00799035@cherry.ease.lsoft.com>; Tue, 29 Oct 2002 8:21:05 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 354520 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Oct 2002 08:21:06 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 29 Oct 2002 08:21:05 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HPMJ9>; Tue, 29 Oct 2002 08:21:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 29 Oct 2002 08:22:54 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Rohit/Acee, >Is anybody running OSPF networks hitting this problem with no workarounds in sight? I am not sure about this statement exactly, however I do think it can be helpful in a few cases. A recent paper by Aman Shaikh/Albert Greenberg et.al. about analyzing OSPF for Enterprise is one such case. One of our drafts "Congestion Avoidance and Control for OSPF networks" talks about problems that have been caused by flooding overload in production networks. I think the hitless restart MIB info can go in the OSPFv2/v3 MIB itself. Besides from a previous mail on this list I recollect that Cisco/Juniper already have the MIB in place for OSPF-TE. Regarding the last item in the charter "IPSec usage with OSPFv3", I remember one of the comments on the list was that the mechanism could be generalized for other protocols like RIPng etc, would we pursue this item on this WG? Thanks, Vishwas -----Original Message----- From: Rohit Dube [mailto:rohit@XEBEO.COM] Sent: Tuesday, October 29, 2002 5:17 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF WG Charter Proposal Venkata, Thanks for your comments. Some of my own are inline. A meta comment first - our first goal is to clear the decks by getting done with all the work (drafts + implementation experience) that has accumulated over time. Once enough of this done, it would be a natural point for the WG to expand on the charter. On Mon, 28 Oct 2002 18:22:02 -0500 "Naidu, Venkata" writes: =>Rohit/Acee, => => Some quick comments w.r.t new charter. => => 1. Can you consider "Flooding Optimizations" into charter ? => If not, can you please explain the reason, why we should not ? => This is field of its own - we might expect lot of drafts. We considered this but would like to see some operational requirements before including this in the charter. Is anybody running OSPF networks hitting this problem with no workarounds in sight? It would be a candidate for a future version of the charter once some of the current items clear. => => 2. One of the Alex's work "OSPF Link-local Signaling" will => be very imp for future OSPF enhancements. As you know, => the options are getting over in OSPF headers. => => 3. "OSPF TE" and "OSPF Hitless Restart" MIBs must be => considered as separate drafts. Recent OSPFv2 MIB only => talks about Opaque LSAs - but content carried in those => LSAs are not specified in any MIB. I am be willing => to write those drafts - what is your opinion, Kireeti/Padma ? I was considering reflecting OSPF-TE in a MIB too. And this could be a potential item for this or a future. But is there an operator burning for this stuff? => => 4. "Flooding over Parallel Point-to-Point Links" can be => considered as an informational RFC. What draft are you referring to? => Thank You. =>Venkata. Best, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 29 10:57:54 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10231 for ; Tue, 29 Oct 2002 10:57:54 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.007995CD@cherry.ease.lsoft.com>; Tue, 29 Oct 2002 11:00:13 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 355157 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Oct 2002 11:00:13 -0500 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 29 Oct 2002 10:50:13 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00799566@cherry.ease.lsoft.com>; Tue, 29 Oct 2002 10:50:13 -0500 Message-ID: Date: Tue, 29 Oct 2002 10:50:13 -0500 Reply-To: Mailing List Sender: Mailing List From: Hatem Eyada Subject: Looking For An OSPFv3 book. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I'm looking for a book which explains OSPFv3. I have looked around and so far I found books only for OSPFv2. Any suggestions? Thanks in advance for your help, Hatem From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 29 13:01:49 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16701 for ; Tue, 29 Oct 2002 13:01:48 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00799961@cherry.ease.lsoft.com>; Tue, 29 Oct 2002 13:04:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 355756 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Oct 2002 13:04:10 -0500 Received: from 63.78.179.217 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 29 Oct 2002 13:04:10 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9TI4wX17488 for ; Tue, 29 Oct 2002 12:05:02 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 29 Oct 2002 12:03:58 -0600 Received: from daebe008.NOE.Nokia.com ([172.18.242.238]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 10:03:29 -0800 Received: from nokia.com ([172.19.66.85]) by daebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Oct 2002 12:03:28 -0600 X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Oct 2002 18:03:28.0738 (UTC) FILETIME=[7BF57420:01C27F75] Message-ID: <3DBECD6F.D54F8B48@nokia.com> Date: Tue, 29 Oct 2002 10:03:27 -0800 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Organization: Nokia Networks Subject: Re: OSPF WG Charter Proposal Comments: cc: "Melam Nagavenkata (NET/MtView)" To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit > Regarding the last item in the charter "IPSec usage with OSPFv3", I remember > one of the comments on the list was that the mechanism could be generalized > for other protocols like RIPng etc, would we pursue this item on this WG? There are parts of the proposed draft that are generic and could be used for RIPng as well. But there are some specific things like virtual links that are just for OSPFv3. As this already involves more than one group (IPsec and OSPF), I would suggest keeping it in OSPF WG so that we can focus on it and finish it on time. I think some vendors have already implemented the OSPFv3 security using IPsec and we in Nokia are almost done with it too. It would be good if we could finalize things sooner. regards Mukesh -- ****************************************************************** Life is the biggest bargain. We get it for nothing. ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 29 13:48:47 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19081 for ; Tue, 29 Oct 2002 13:48:47 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.007998FA@cherry.ease.lsoft.com>; Tue, 29 Oct 2002 13:51:09 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 355976 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Oct 2002 13:51:09 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 29 Oct 2002 13:51:09 -0400 Received: (qmail 2444 invoked from network); 29 Oct 2002 18:51:08 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 29 Oct 2002 18:51:08 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id NAA04737 for ; Tue, 29 Oct 2002 13:51:08 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210291851.NAA04737@bigbird.xebeo.com> Date: Tue, 29 Oct 2002 13:51:08 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from "Manral, Vishwas" of "Tue, 29 Oct 2002 08:22:54 EST." Precedence: list On Tue, 29 Oct 2002 08:22:54 -0500 "Manral, Vishwas" writes: =>Hi Rohit/Acee, => =>>Is anybody running OSPF networks hitting this problem with no workarounds =>in sight? =>I am not sure about this statement exactly, however I do think it can be =>helpful in a few cases. A recent paper by Aman Shaikh/Albert Greenberg =>et.al. about analyzing OSPF for Enterprise is one such case. One of our =>drafts "Congestion Avoidance and Control for OSPF networks" talks about =>problems that have been caused by flooding overload in production networks. [snip] Vishwas, I am familiar with Aman's work. The problem identified there was that of (a) sub-optimal network/ospf configuration and (b) broken router. This does not ofcourse justify building new protocol mechanisms, thereby complicating the protocol. I will look at the congestion again to see if/why it concludes otherwise. Regards, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 29 13:53:28 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19298 for ; Tue, 29 Oct 2002 13:53:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0079994C@cherry.ease.lsoft.com>; Tue, 29 Oct 2002 13:55:50 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 356004 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Oct 2002 13:55:50 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 29 Oct 2002 13:55:50 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id DE46A3B7FD6 for ; Tue, 29 Oct 2002 10:55:48 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <3DBECD6F.D54F8B48@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DBED917.7090800@redback.com> Date: Tue, 29 Oct 2002 13:53:11 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mukesh Gupta wrote: >>Regarding the last item in the charter "IPSec usage with OSPFv3", I remember >>one of the comments on the list was that the mechanism could be generalized >>for other protocols like RIPng etc, would we pursue this item on this WG? >> > > There are parts of the proposed draft that are generic and could be used for > RIPng as well. But there are some specific things like virtual links that are > just for OSPFv3. As this already involves more than one group (IPsec and OSPF), > I would suggest keeping it in OSPF WG so that we can focus on it and finish it > on time. > > I think some vendors have already implemented the OSPFv3 security using IPsec > and we in Nokia are almost done with it too. It would be good if we could > finalize things sooner. Rohit and I discussed this and we agree that there are enough differences in the application of IPSec to OSPFv3 to keep the documents separate. Additionally, as Mukesh points out, it will be much easier to get the progress the draft through a single WG. Thanks, Acee > > regards > Mukesh > -- > ****************************************************************** > Life is the biggest bargain. We get it for nothing. > ****************************************************************** > Mukesh Gupta > Phone: (650) 625-2264 > Cell : (650) 868-9111 > http://www.iprg.nokia.com/~mgupta > ****************************************************************** > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 29 13:59:20 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19584 for ; Tue, 29 Oct 2002 13:59:20 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00799972@cherry.ease.lsoft.com>; Tue, 29 Oct 2002 14:01:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 356075 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Oct 2002 14:01:42 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 29 Oct 2002 14:01:42 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 94C00FC04C for ; Tue, 29 Oct 2002 11:01:40 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: <242301c27f4a$1c7b5f30$928b4d0a@apac.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DBEDA77.3030206@redback.com> Date: Tue, 29 Oct 2002 13:59:03 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Query on implementation of SNMP TRAP ospfTxRetransmit To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Roy, I haven't implemented this trap but I'd just use the first LSA in packet. Not speaking as WG co-chair and being completely honest, I can't imagine why anyone would enable this trap in the first place. One of the main causes of retransmissions is congestion and sending this trap would only exacerbate matters. Roy Jose wrote: > Hi, > > The TRAP message ospfTxRetransmit is supposed to contain Lsdb entry > details as given in its defenition. When an OSPF packet contains is > associated with only one Lsdb, there are no problems. But, when the same > OSPF packet like UPDATE, DATABASE DESCRIPTION, etc is associated with more > than one Lsdb entry, what can be done? Can we set Lsdb details to zero and > send? Anybody knows about some implementations? > > ospfTxRetransmit NOTIFICATION-TYPE > OBJECTS { > ospfRouterId, -- The originator of the trap > ospfIfIpAddress, > ospfAddressLessIf, > ospfNbrRtrId, -- Destination > ospfPacketType, > ospfLsdbType, > ospfLsdbLsid, > ospfLsdbRouterId > } > STATUS current > DESCRIPTION > "An ospfTxRetransmit trap signifies than an > OSPF packet has been retransmitted on a non- > virtual interface. All packets that may be re- > transmitted are associated with an LSDB entry. > The LS type, LS ID, and Router ID are used to > identify the LSDB entry." > > Thanks, > Roy > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 29 14:31:42 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21084 for ; Tue, 29 Oct 2002 14:31:41 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00799AA2@cherry.ease.lsoft.com>; Tue, 29 Oct 2002 14:34:01 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 356262 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Oct 2002 14:34:01 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 29 Oct 2002 14:34:01 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22821 for ; Tue, 29 Oct 2002 14:33:58 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15654 for ; Tue, 29 Oct 2002 14:33:59 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Oct 2002 14:33:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC5576341F@vie-msgusr-01.dc.fore.com> Date: Tue, 29 Oct 2002 14:33:56 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Query on implementation of SNMP TRAP ospfTxRetransmit To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Acee, -> I haven't implemented this trap but I'd just use the first LSA in -> packet. My implementation uses the first LSA. -> Not speaking as WG co-chair and being completely -> honest, I can't imagine why anyone would enable this trap in the -> first place. One of the main causes of retransmissions is congestion -> and sending this trap would only exacerbate matters. Frankly, I used this trap to figure out some of the bugs in the past. Traps are sent to network manager and in most of the cases NM is out-of-band signaling. Congestion exacerbating in the data path is nothing to do with sending the trap. For that matter, a packet not reaching the destination may be because of thousands of reasons not necessarily because of congestion. For example, link local LSAs should go on the exact interface it is supposed to go (with out looking at the route tables) - for that we have to enable some of the IP socket options. If not, link local LSAs are keep on retransmitted but never acked back. Until unless admin gets a traps he/she can never figure out why a particular message/packet/LSA is being flapped. (unless he checks the error statistics/RtmsQ explicitly) -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 29 15:08:59 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22641 for ; Tue, 29 Oct 2002 15:08:59 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00799C1C@cherry.ease.lsoft.com>; Tue, 29 Oct 2002 15:11:19 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 356404 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Oct 2002 15:11:19 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 29 Oct 2002 15:11:18 -0400 Received: (qmail 10036 invoked from network); 29 Oct 2002 20:11:18 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 29 Oct 2002 20:11:18 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id PAA00822; Tue, 29 Oct 2002 15:11:18 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210292011.PAA00822@bigbird.xebeo.com> Date: Tue, 29 Oct 2002 15:11:18 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: FW: OSPF WG Charter Proposal Comments: To: "Singh, Ajay" Comments: cc: "Venkata.Naidu@MARCONI.COM" , "acee@REDBACK.COM" To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from "Singh, Ajay" of "Mon, 28 Oct 2002 22:46:31 EST." Precedence: list On Mon, 28 Oct 2002 22:46:31 -0500 "Singh, Ajay" writes: =>Hello Venkata,Acee, Rohit, => With regards to OSPF-TE mib requirements, i would like to differ from what =>venkata has to say. OSPF - TE requirements as is, are not part of OSPF =>protocol requirements/ of any use in OSPF networks. Its only that OSPF acts =>as a transport mechanism to propagate the TE info in the network( which =>quite often would be a superset of OSPF network(TE links and associated =>nodes may not be running OSPF for that matter)). Injection( and hence its =>generation) of this TE info, per se, should not lie in the perview of OSPF =>group, as the requirements are to be dealt with by the users of the =>information( e.g connecting MPLS modules, LMP etc) . Hence, is it right to =>develop the OSPF-TE mib as an OSPF working group item. =>Please let me know disconnects in my understandings. =>Thanks =>Ajay Ajay, Acee and I discussed this. I would agree with you. Any OSPF-TE mib is likely to be equally relevant to ISIS. I would prefer to not get into specifying this here - if at all, the TEWG can specify (perhaps they do already) the contents of the TED to be extracted into a MIB. Regards, --rohit. PS: I am cc'ing the list as well. Hope you don't mind. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 29 15:32:54 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23524 for ; Tue, 29 Oct 2002 15:32:54 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00799E85@cherry.ease.lsoft.com>; Tue, 29 Oct 2002 15:35:14 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 356533 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Oct 2002 15:35:14 -0500 Received: from 207.159.120.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 29 Oct 2002 15:35:13 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 78B9D109EE1; Tue, 29 Oct 2002 15:35:09 -0500 (EST) Received: from [63.104.212.252] by xprdmailfe1.nwk.excite.com via HTTP; Tue, 29 Oct 2002 15:35:09 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20021029203509.78B9D109EE1@xmxpita.excite.com> Date: Tue, 29 Oct 2002 15:35:09 -0500 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: FW: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Rohit and all, In our work on the ISIS MIB update with Jeff Parker, myself, and others, we are keeping the TLV contents in their raw hex form and are not interpreting any of them further, including TE info. We leave it up to the CLI or network manangement system to interpret further (which they'll do better than the MIB can). And it's more extensible since any changes to TLVs do not require a subsequent MIB update in order to support. However, I do feel we can include administrative items in the MIB such as TE support (already in OSPF's mib update), TE metric (either in the ospfIfTable or the ospfIfMetric table), and administrative group. It's the bandwidth reservation stuff that's trickier. -don --- On Tue 10/29, Rohit Dube wrote: From: Rohit Dube [mailto: rohit@XEBEO.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Tue, 29 Oct 2002 15:11:18 -0500 Subject: Re: FW: OSPF WG Charter Proposal > On Mon, 28 Oct 2002 22:46:31 -0500 "Singh, Ajay" writes: > =>Hello Venkata,Acee, Rohit, > => With regards to OSPF-TE mib requirements, i would like to differ > from what > =>venkata has to say. OSPF - TE requirements as is, are not part of > OSPF > =>protocol requirements/ of any use in OSPF networks. Its only that > OSPF acts > =>as a transport mechanism to propagate the TE info in the network( > which > =>quite often would be a superset of OSPF network(TE links and > associated > =>nodes may not be running OSPF for that matter)). Injection( and hence > its > =>generation) of this TE info, per se, should not lie in the perview of > OSPF > =>group, as the requirements are to be dealt with by the users of the > =>information( e.g connecting MPLS modules, LMP etc) . Hence, is it > right to > =>develop the OSPF-TE mib as an OSPF working group item. > =>Please let me know disconnects in my understandings. > =>Thanks > =>Ajay > > Ajay, > > Acee and I discussed this. I would agree with you. Any OSPF-TE mib is > likely to be equally relevant to ISIS. I would prefer to not get into > specifying this here - if at all, the TEWG can specify (perhaps they > do already) the contents of the TED to be extracted into a MIB. > > Regards, > --rohit. > > PS: I am cc'ing the list as well. Hope you don't mind. > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 29 16:03:01 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25221 for ; Tue, 29 Oct 2002 16:03:01 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00799DFC@cherry.ease.lsoft.com>; Tue, 29 Oct 2002 16:05:22 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 356631 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Oct 2002 16:05:22 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 29 Oct 2002 16:05:21 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA02315; Tue, 29 Oct 2002 16:05:17 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA12087; Tue, 29 Oct 2002 16:05:17 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Oct 2002 16:05:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763420@vie-msgusr-01.dc.fore.com> Date: Tue, 29 Oct 2002 16:05:14 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: FW: OSPF WG Charter Proposal Comments: To: Rohit Dube , "Singh, Ajay" Comments: cc: "acee@REDBACK.COM" To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Rohit, -> Acee and I discussed this. I would agree with you. Any OSPF-TE mib is -> likely to be equally relevant to ISIS. I would prefer to not -> get into specifying this here - if at all, the TEWG can specify -> (perhaps they do already) the contents of the TED to be extracted -> into a MIB. Please give consideration - after all are we discussing OSPF WG charter. Please talk to TEWG chairs and discuss all the possibilities. OSPF-TE is given to OSPF-WG, but OSPF diff extensions (as far as I know, Francois is pretty confident with the recent LOM/BC related IGPs update). So, coordinate with TEWG chairs, if they don't have any agenda related to OSPF-TE MIB and/or OSPF-Diff-TE MIBs in their charter, then discuss which is the better WG to have such drafts. May be single draft will suffice for all the OSPF TE related MIBs (OSPF-TE, OSPF-Diff-TE, OSPF-GMPLS, OSPF-FA LSPs etc). As far as I know, TEWG works for requirements and they don't have any such charter for protocol related MIBs. -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Oct 29 16:21:51 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26020 for ; Tue, 29 Oct 2002 16:21:50 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0079A10B@cherry.ease.lsoft.com>; Tue, 29 Oct 2002 16:24:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 356698 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Oct 2002 16:24:10 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 29 Oct 2002 16:24:10 -0400 Received: (qmail 16749 invoked from network); 29 Oct 2002 21:24:09 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 29 Oct 2002 21:24:09 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id QAA14003 for ; Tue, 29 Oct 2002 16:24:09 -0500 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200210292124.QAA14003@bigbird.xebeo.com> Date: Tue, 29 Oct 2002 16:24:09 -0500 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: FW: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from "Naidu, Venkata" of "Tue, 29 Oct 2002 16:05:14 EST." <39469E08BD83D411A3D900204840EC55763420@vie-msgusr-01.dc.fore.com> Precedence: list Hi Venkata, Ofcourse the item is being considered - we are discussing it here right! That said, it is in the working groups interest to (a) keep the focus on a manageable set of issues and (b) take operational requirements into account before expanding the goals. Don's approach is reasonable too in this regard (specify a mechanism to extract the TLVs and Acee and I did discuss this as well) but again, I would prefer the application that interprets the TLVs (here TE) to specify the MIB. Best regards, --rohit. PS: The TEWG lists atleast one MIB on its web page http://www.ietf.org/internet-drafts/draft-ietf-tewg-mib-03.txt so I don't believe it to be inconceivable for the TEWG (or some other) to specify another for the TED. On Tue, 29 Oct 2002 16:05:14 -0500 "Naidu, Venkata" writes: =>Rohit, => =>-> Acee and I discussed this. I would agree with you. Any OSPF-TE mib is =>-> likely to be equally relevant to ISIS. I would prefer to not =>-> get into specifying this here - if at all, the TEWG can specify =>-> (perhaps they do already) the contents of the TED to be extracted =>-> into a MIB. => => Please give consideration - after all are we discussing OSPF WG charter. => Please talk to TEWG chairs and discuss all the possibilities. => => OSPF-TE is given to OSPF-WG, but OSPF diff extensions (as far as => I know, Francois is pretty confident with the recent LOM/BC => related IGPs update). So, coordinate with TEWG chairs, if => they don't have any agenda related to OSPF-TE MIB and/or OSPF-Diff-TE => MIBs in their charter, then discuss which is the better WG to have => such drafts. May be single draft will suffice for all the OSPF TE => related MIBs (OSPF-TE, OSPF-Diff-TE, OSPF-GMPLS, OSPF-FA LSPs etc). => => As far as I know, TEWG works for requirements and they don't => have any such charter for protocol related MIBs. => =>-- =>Venkata. ___ From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 03:13:03 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05270 for ; Wed, 30 Oct 2002 03:13:02 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0079B742@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 3:15:22 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 358028 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 03:15:22 -0500 Received: from 198.152.13.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 03:15:22 -0400 Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15160 for ; Wed, 30 Oct 2002 03:13:07 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15156 for ; Wed, 30 Oct 2002 03:13:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27FEC.7BEC788C" Thread-Topic: discard route, summary of externals and external types Thread-Index: AcJ/7Glp0AKi0nXOSf+fI6kAF0jKUA== Message-ID: Date: Wed, 30 Oct 2002 10:15:18 +0200 Reply-To: Mailing List Sender: Mailing List From: "Kostiner, Assaf (Assaf)" Subject: discard route, summary of externals and external types To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C27FEC.7BEC788C Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, I wonder if anyone knows: 1. Is the command 'summary-address ip-address mask' for summarization of = externals a Cisco proprietary, or do other vendors implement it as well? = 2. Cisco has a command: : [no]discard-route internal / [no] = discard-route external - why would anyone want to prevent a discard = route from forming? 3. Until now, i have always worked with externals type 2. Is there any = good reason to move to type 1? Any special cases? 4. And last... Does anyone knows what opaque LSA is? The RFC which talks = about it, doesn't bring detailed examples of using it, only explains the = ospf changes. Thanks for any help, Assaf. ------_=_NextPart_001_01C27FEC.7BEC788C Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable discard route, summary of externals and external types

Hi,

I wonder if anyone = knows:

1. Is the command 'summary-address ip-address mask' for summarization of = externals a Cisco proprietary, or do other vendors implement it = as well?

2. = Cisco has a command: : [no]discard-route internal / [no] discard-route = external - why would anyone want to prevent a discard route from = forming?

3. = Until now, i have always worked with externals type 2. Is there any good = reason to move to type 1? Any special cases?

4. And = last... Does anyone knows what opaque LSA is? The RFC which talks about = it, doesn't bring detailed examples of using it, only explains the ospf = changes.

Thanks = for any help, Assaf.

------_=_NextPart_001_01C27FEC.7BEC788C-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 06:48:48 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10369 for ; Wed, 30 Oct 2002 06:48:48 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0079BD03@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 6:51:09 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 358947 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 06:51:09 -0500 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 06:51:09 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id BA5315D09F for ; Wed, 30 Oct 2002 20:51:07 +0900 (JST) X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20021030.205107.05507938.yasu@sfc.wide.ad.jp> Date: Wed, 30 Oct 2002 20:51:07 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: How to set the link costs ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Is there any way to calculate/produce the link cost, if topology is given ? I know that depends on the topology and how the network administrators want traffic to go through, but I think there should be some generic guidance, to realize the policy if one is given. (I mean "how traffic go through" by "policy".) Is there any related work, tools or papers ? How do you parameterize the costs on your network ? I know the type of the link is a way. I want another if there's. Waiting for your reply. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 06:56:33 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10554 for ; Wed, 30 Oct 2002 06:56:33 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0079BC87@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 6:58:55 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 358980 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 06:58:55 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 06:58:55 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HP3H1>; Wed, 30 Oct 2002 06:58:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 30 Oct 2002 07:01:08 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: How to set the link costs ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Yasu, A formula used to find cost of a link can be cost = 10 ^ 8 /(bandwidth in bps), which is used by implementations. Thanks, Vishwas -----Original Message----- From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] Sent: Wednesday, October 30, 2002 5:21 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: How to set the link costs ? Is there any way to calculate/produce the link cost, if topology is given ? I know that depends on the topology and how the network administrators want traffic to go through, but I think there should be some generic guidance, to realize the policy if one is given. (I mean "how traffic go through" by "policy".) Is there any related work, tools or papers ? How do you parameterize the costs on your network ? I know the type of the link is a way. I want another if there's. Waiting for your reply. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 07:08:09 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10875 for ; Wed, 30 Oct 2002 07:08:08 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0079BBA2@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 7:10:30 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 359012 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 07:10:30 -0500 Received: from 164.107.115.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 07:10:30 -0400 Received: from theta.cis.ohio-state.edu (daemon@theta.cis.ohio-state.edu [164.107.112.63]) by cis.ohio-state.edu (8.11.6/8.11.6) with ESMTP id g9UCATE21645 for ; Wed, 30 Oct 2002 07:10:30 -0500 (EST) Received: from localhost (mukul@localhost) by theta.cis.ohio-state.edu (8.11.6/8.11.6) with ESMTP id g9UCAT514158 for ; Wed, 30 Oct 2002 07:10:29 -0500 (EST) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 30 Oct 2002 07:10:29 -0500 Reply-To: Mailing List Sender: Mailing List From: mukul goyal Subject: Re: How to set the link costs ? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20021030.205107.05507938.yasu@sfc.wide.ad.jp> Precedence: list Mikkel Thorup of AT&T Research has looked into the issue: www.research.att.com/~mthorup/PAPERS/papers.html Thanks, Mukul On Wed, 30 Oct 2002, Yasuhiro Ohara wrote: > Is there any way to calculate/produce the link cost, if topology is > given ? I know that depends on the topology and how the network > administrators want traffic to go through, but I think there should be > some generic guidance, to realize the policy if one is given. (I mean > "how traffic go through" by "policy".) > > Is there any related work, tools or papers ? > How do you parameterize the costs on your network ? > > I know the type of the link is a way. > I want another if there's. > > Waiting for your reply. > > regards, > yasu > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 07:52:57 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12616 for ; Wed, 30 Oct 2002 07:52:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0079BC5D@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 7:55:18 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 359115 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 07:55:19 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 07:55:19 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HP3JT>; Wed, 30 Oct 2002 07:55:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 30 Oct 2002 07:57:18 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Rohit, I am not claiming that with flooding optimizations the network meltdowns/failures, which the paper observes "could" be typical(its been some time since I read the paper though), would be solved, not optimizing aggravates the problem further. The same is true about our draft. Though flooding optimizations by themselves wont suffice they do help solve part of the problem. I think if "flooding optimizations" can be achieved without cluttering up the spec/code, it would be helpful, besides from the two documents I refer to it could mean the problem has been seen by the operators too(though I am not sure of the no workarounds in site part of it). Thanks, Vishwas -----Original Message----- From: Rohit Dube [mailto:rohit@XEBEO.COM] Sent: Wednesday, October 30, 2002 12:21 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPF WG Charter Proposal On Tue, 29 Oct 2002 08:22:54 -0500 "Manral, Vishwas" writes: =>Hi Rohit/Acee, => =>>Is anybody running OSPF networks hitting this problem with no workarounds =>in sight? =>I am not sure about this statement exactly, however I do think it can be =>helpful in a few cases. A recent paper by Aman Shaikh/Albert Greenberg =>et.al. about analyzing OSPF for Enterprise is one such case. One of our =>drafts "Congestion Avoidance and Control for OSPF networks" talks about =>problems that have been caused by flooding overload in production networks. [snip] Vishwas, I am familiar with Aman's work. The problem identified there was that of (a) sub-optimal network/ospf configuration and (b) broken router. This does not ofcourse justify building new protocol mechanisms, thereby complicating the protocol. I will look at the congestion again to see if/why it concludes otherwise. Regards, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 08:17:48 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13517 for ; Wed, 30 Oct 2002 08:17:47 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0079BC65@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 8:20:09 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 359181 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 08:20:08 -0500 Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 08:20:08 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0HP3LD>; Wed, 30 Oct 2002 08:20:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 30 Oct 2002 08:22:07 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: FW: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Rohit, I was part of the "others" that Don mentioned in his other mail. Jeff P. correct me(I may have interpreted it wrongly), but I think we chose the TLV approach in ISIS as we could have probs because of "small SNMP buffer size and the lack of a defined way to fragment payload". In short an SNMP agent may not be able to fulfill the request for an LSP of large size(255 bytes??). In OSPF we anyway send the entire LSA as OCTET string. If we are not interpreting the TLV's, we could as well send the entire LSA itself as OCTET string. An OSPF-v2 TE LSA by the way would contain just one top-level TLV anyway. We could have a seperate table for TE LSA's though in this case. Thanks, Vishwas -----Original Message----- From: Rohit Dube [mailto:rohit@XEBEO.COM] Sent: Wednesday, October 30, 2002 2:54 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: FW: OSPF WG Charter Proposal Hi Venkata, Ofcourse the item is being considered - we are discussing it here right! That said, it is in the working groups interest to (a) keep the focus on a manageable set of issues and (b) take operational requirements into account before expanding the goals. Don's approach is reasonable too in this regard (specify a mechanism to extract the TLVs and Acee and I did discuss this as well) but again, I would prefer the application that interprets the TLVs (here TE) to specify the MIB. Best regards, --rohit. PS: The TEWG lists atleast one MIB on its web page http://www.ietf.org/internet-drafts/draft-ietf-tewg-mib-03.txt so I don't believe it to be inconceivable for the TEWG (or some other) to specify another for the TED. On Tue, 29 Oct 2002 16:05:14 -0500 "Naidu, Venkata" writes: =>Rohit, => =>-> Acee and I discussed this. I would agree with you. Any OSPF-TE mib is =>-> likely to be equally relevant to ISIS. I would prefer to not =>-> get into specifying this here - if at all, the TEWG can specify =>-> (perhaps they do already) the contents of the TED to be extracted =>-> into a MIB. => => Please give consideration - after all are we discussing OSPF WG charter. => Please talk to TEWG chairs and discuss all the possibilities. => => OSPF-TE is given to OSPF-WG, but OSPF diff extensions (as far as => I know, Francois is pretty confident with the recent LOM/BC => related IGPs update). So, coordinate with TEWG chairs, if => they don't have any agenda related to OSPF-TE MIB and/or OSPF-Diff-TE => MIBs in their charter, then discuss which is the better WG to have => such drafts. May be single draft will suffice for all the OSPF TE => related MIBs (OSPF-TE, OSPF-Diff-TE, OSPF-GMPLS, OSPF-FA LSPs etc). => => As far as I know, TEWG works for requirements and they don't => have any such charter for protocol related MIBs. => =>-- =>Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 09:07:09 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15302 for ; Wed, 30 Oct 2002 09:07:08 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0079BED1@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 9:09:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 359256 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 09:09:27 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 09:09:27 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id D8FD5F6075 for ; Wed, 30 Oct 2002 06:09:25 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 References: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3DBFE76E.1000602@redback.com> Date: Wed, 30 Oct 2002 09:06:38 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: discard route, summary of externals and external types To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Assaf, Kostiner, Assaf (Assaf) wrote: > Hi, > > I wonder if anyone knows: > > 1. Is the command 'summary-address ip-address mask' for summarization of > externals a Cisco proprietary, or do other vendors implement it as well? Many vendors have implemented this command or similar functionality. Route redistribution has typically been unspecified by the protocols so every vendors implementation should be considered proprietary. > > 2. Cisco has a command: : [no]discard-route internal / [no] > discard-route external - why would anyone want to prevent a discard > route from forming? I'd guess it is to avoid the discard route overlaying a lower priority (i.e., distance or preference depending on your vendor) route from a different protocol. > > 3. Until now, i have always worked with externals type 2. Is there any > good reason to move to type 1? Any special cases? If you want to run OSPF and another protocol (or another instance of OSPF) and treat the metrics equally. > > 4. And last... Does anyone knows what opaque LSA is? The RFC which talks > about it, doesn't bring detailed examples of using it, only explains the > ospf changes. RFC 2370 does describes the protocol mechanisms. Look at draft-ietf-ospf-hitless-restart-03.txt or draft-katz-yeung-ospf-traffic-09.txt for examples. > > Thanks for any help, Assaf. > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 10:35:01 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20255 for ; Wed, 30 Oct 2002 10:35:01 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0079C1E7@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 10:37:21 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 303707 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 10:37:21 -0500 Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 10:37:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 30 Oct 2002 10:37:18 -0500 Reply-To: Mailing List Sender: Mailing List From: Jeff Parker Subject: Re: FW: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I can't speak for the others, but here are my thoughts. In OSPF, there is no restriction on what a PDU contains, and a router can deal out an arbitrary hand from the LSA in the DB. IS-IS, on the other hand, fixes the contents of a Link State PDU (LSP) at creation time. If one TLV changes in IS-IS, we cannot simply flood the updated TLV: we have to regenerate and reflood the whole LSP. This is all to say that the standard unit of exchange in ISIS is a big honking LSP of 1492 or more bytes. We decided to split this into TLVs (rather than hand back a whole LSP) due to concerns about SNMP limits, not because we thought is was the best thing to do. This is moot in OSPF, as there is no "standard unit" bigger than an LSA, and thus I wouldn't expect the same issue to arise. - jeff parker > Hi Rohit, > > I was part of the "others" that Don mentioned in his other mail. > > Jeff P. correct me(I may have interpreted it wrongly), but I > think we chose > the TLV approach in ISIS as we could have probs because of "small SNMP > buffer size and the lack of a defined way to fragment > payload". In short an > SNMP agent may not be able to fulfill the request for an LSP of large > size(255 bytes??). In OSPF we anyway send the entire LSA as > OCTET string. > > If we are not interpreting the TLV's, we could as well send > the entire LSA > itself as OCTET string. An OSPF-v2 TE LSA by the way would > contain just one > top-level TLV anyway. We could have a seperate table for TE > LSA's though in > this case. > > Thanks, > Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 10:59:19 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21589 for ; Wed, 30 Oct 2002 10:59:18 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0079C673@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 11:01:39 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 303947 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 11:01:39 -0500 Received: from 192.11.223.163 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 11:01:39 -0400 Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com [135.17.42.35]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9UG1bG07468 for ; Wed, 30 Oct 2002 11:01:37 -0500 (EST) Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Oct 2002 11:01:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 30 Oct 2002 11:01:34 -0500 Reply-To: Mailing List Sender: Mailing List From: "Joyal, Daniel R (Daniel)" Subject: Re: FW: OSPF WG Charter Proposal To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list >I can't speak for the others, but here are my thoughts. > >In OSPF, there is no restriction on what a PDU contains, >and a router can deal out an arbitrary hand from the >LSA in the DB. IS-IS, on the other hand, fixes the >contents of a Link State PDU (LSP) at creation time. >If one TLV changes in IS-IS, we cannot simply flood >the updated TLV: we have to regenerate and reflood >the whole LSP. > >This is all to say that the standard unit of exchange >in ISIS is a big honking LSP of 1492 or more bytes. >We decided to split this into TLVs (rather than hand >back a whole LSP) due to concerns about SNMP limits, >not because we thought is was the best thing to do. > >This is moot in OSPF, as there is no "standard unit" >bigger than an LSA, and thus I wouldn't expect the >same issue to arise. Jeff did a good job of laying out the motivation for splitting the LSP database table in the ISIS MIB into LSP header and LSP body. LSA size issues could arise in OSPFv2 (OSPFv3 addresses this), however, with variable size LSAs, such as the router-LSA. In certain topologies, these LSAs could be honking big, though I would venture that this is not the typical case. -Dan > >- jeff parker > > >> Hi Rohit, >> >> I was part of the "others" that Don mentioned in his other mail. >> >> Jeff P. correct me(I may have interpreted it wrongly), but I >> think we chose >> the TLV approach in ISIS as we could have probs because of "small SNMP >> buffer size and the lack of a defined way to fragment >> payload". In short an >> SNMP agent may not be able to fulfill the request for an LSP of large >> size(255 bytes??). In OSPF we anyway send the entire LSA as >> OCTET string. >> >> If we are not interpreting the TLV's, we could as well send >> the entire LSA >> itself as OCTET string. An OSPF-v2 TE LSA by the way would >> contain just one >> top-level TLV anyway. We could have a seperate table for TE >> LSA's though in >> this case. >> >> Thanks, >> Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 15:09:46 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08124 for ; Wed, 30 Oct 2002 15:09:46 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0079CF64@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 15:12:08 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 305214 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 15:12:08 -0500 Received: from 192.18.98.43 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 15:12:07 -0400 Received: from sydney.East.Sun.COM ([129.148.9.16]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09616 for ; Wed, 30 Oct 2002 13:12:06 -0700 (MST) Received: from sr1-ubur-07 (sr1-ubur-07 [129.148.9.88]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id g9UKC5812636 for ; Wed, 30 Oct 2002 15:12:05 -0500 (EST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +noVtBTItcVLaDkknoO8dQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Message-ID: <200210302012.g9UKC5812636@sydney.East.Sun.COM> Date: Wed, 30 Oct 2002 15:12:05 -0500 Reply-To: Mailing List Sender: Mailing List From: Radia Perlman - Boston Center for Networking Subject: Re: How to set the link costs ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list NLSP (designed by Novell, basically support for IPX within IS-IS) had a method of measuring round trip delay and bandwidth upon link startup (pt-to-pt links) and throwing it into a formula to come up with a number. For LANs, they just had a number for the type of link, I believe. At Digital, before I got there (so it was late 70's) there was some tool where you input the traffic matrix and topology it came up with link costs to optimize the traffic flow. I didn't think this was a good idea...how do you know the traffic matrix? What if the topology changes? Would those artificial link costs optimized around a particular topology possibly yield really really horrible routes if a link went down and so it was operating with different topology? Mostly I think link costs aren't a big deal..anything fairly sensible will calculate fairly sensible paths. Radia MIME-Version: 1.0 From: mukul goyal Subject: Re: How to set the link costs ? To: OSPF@DISCUSS.MICROSOFT.COM Mikkel Thorup of AT&T Research has looked into the issue: www.research.att.com/~mthorup/PAPERS/papers.html Thanks, Mukul On Wed, 30 Oct 2002, Yasuhiro Ohara wrote: > Is there any way to calculate/produce the link cost, if topology is > given ? I know that depends on the topology and how the network > administrators want traffic to go through, but I think there should be > some generic guidance, to realize the policy if one is given. (I mean > "how traffic go through" by "policy".) > > Is there any related work, tools or papers ? > How do you parameterize the costs on your network ? > > I know the type of the link is a way. > I want another if there's. > > Waiting for your reply. > > regards, > yasu > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 15:12:03 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08243 for ; Wed, 30 Oct 2002 15:12:02 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0079CFAA@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 15:14:25 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 305233 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 15:14:25 -0500 Received: from 216.32.171.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 15:14:25 -0400 Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id MAA19168; Wed, 30 Oct 2002 12:11:28 -0800 (PST) References: <20021030.205107.05507938.yasu@sfc.wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Message-ID: <20021030121128.H17797@demiurge.exodus.net> Date: Wed, 30 Oct 2002 12:11:28 -0800 Reply-To: Mailing List Sender: Mailing List From: Andrew Lange Subject: Re: How to set the link costs ? Comments: cc: andrewl@cw.net To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: ; from mukul@CIS.OHIO-STATE.EDU on Wed, Oct 30, 2002 at 07:10:29AM -0500 Precedence: list Actaully, there is a variety of work in addition to Fortz & Thorup's excellent paper, for a start, you can also look at, this slide from my Toronto NANOG presentation on this topic: http://www.nanog.org/mtg-0206/ppt/andrew/sld035.htm Also, in this last month's issue of IEEE Communications, Fortz, Rexford and Thorup published a nice paper covering this topic. Andrew On Wed, Oct 30, 2002 at 07:10:29AM -0500, mukul goyal wrote: > Date: Wed, 30 Oct 2002 07:10:29 -0500 > Reply-To: Mailing List > From: mukul goyal > Subject: Re: How to set the link costs ? > To: OSPF@DISCUSS.MICROSOFT.COM > In-Reply-To: <20021030.205107.05507938.yasu@sfc.wide.ad.jp> > Precedence: list > X-Spam-Status: No, hits=0.6 required=6.0 > tests=FORGED_RCVD_TRAIL,IN_REP_TO,QUOTED_EMAIL_TEXT, > SPAM_PHRASE_02_03,USER_AGENT_PINE > version=2.43 > X-OriginalArrivalTime: 30 Oct 2002 12:10:33.0781 (UTC) FILETIME=[591D2E50:01C2800D] > > Mikkel Thorup of AT&T Research has looked into the issue: > www.research.att.com/~mthorup/PAPERS/papers.html > > Thanks, > Mukul > > On Wed, 30 Oct 2002, Yasuhiro Ohara wrote: > > > Is there any way to calculate/produce the link cost, if topology is > > given ? I know that depends on the topology and how the network > > administrators want traffic to go through, but I think there should be > > some generic guidance, to realize the policy if one is given. (I mean > > "how traffic go through" by "policy".) > > > > Is there any related work, tools or papers ? > > How do you parameterize the costs on your network ? > > > > I know the type of the link is a way. > > I want another if there's. > > > > Waiting for your reply. > > > > regards, > > yasu > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 15:24:19 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08990 for ; Wed, 30 Oct 2002 15:24:19 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0079D06D@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 15:26:40 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 305295 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 15:26:39 -0500 Received: from 216.32.171.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 15:26:39 -0400 Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id MAA19320; Wed, 30 Oct 2002 12:23:42 -0800 (PST) References: <200210302012.g9UKC5812636@sydney.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Message-ID: <20021030122342.I17797@demiurge.exodus.net> Date: Wed, 30 Oct 2002 12:23:42 -0800 Reply-To: Mailing List Sender: Mailing List From: Andrew Lange Subject: Re: How to set the link costs ? Comments: cc: andrewl@cw.net To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <200210302012.g9UKC5812636@sydney.East.Sun.COM>; from Radia.Perlman@SUN.COM on Wed, Oct 30, 2002 at 03:12:05PM -0500 Precedence: list Radia, Good points. In an attempt to address them at least partly: How do you know the traffic matrix? You measure it. Specifically you need to differentiate between the traffic matrix and the demand matrix. The former including the next-hop AS, and the latter including the pop-to-pop flows. Having both helps model under failure. Netflow with correlation to BGP tables, both with NEXT_HOP, for the demand matrix, and with the peer as for the traffic matrix will help get this data. Admittedly, in an ISP environment you'll have to sample, but the results should be valid. What if the topology changes? Would those artificial link costs optimized around a particular topology possibly yield really really horrible routes if a link went down and so it was operating with a different topology? Well, the approach we have taken is to model for worst-case single failure. As you have pointed out, modeling for byzantine failure quickly renders the problem unsolveable. You make sure that you are not loading the network such that, even under worst- case single failure, you do not saturate any links. I think you're right in that in an arbitary topology there is a good chance that the failure paths will be awful. But, from some of the work out there, it would appear that in real life ISP topologies at least, IGP Optimization yields good results. Implied question: Is it worth the effort? That would depend on your resources and the costs associated with the bandwidth. In most corporate environments, I wouldn't think it would be worth the trouble. In a big ISP environment, I think it is. Andrew > NLSP (designed by Novell, basically support for IPX within IS-IS) > had a method of measuring round trip delay and bandwidth upon link > startup (pt-to-pt links) and throwing it into a formula to come up > with a number. For LANs, they just had a number for the type of link, > I believe. > > At Digital, before I got there (so it was late 70's) there was some > tool where you input the traffic matrix and topology > it came up with link costs > to optimize the traffic flow. I didn't think this was a good idea...how > do you know the traffic matrix? What if the topology changes? Would > those artificial link costs optimized around a particular topology possibly > yield really really horrible routes if a link went down and so it was > operating with different topology? > > Mostly I think link costs aren't a big deal..anything fairly sensible > will calculate fairly sensible paths. > > Radia > > > MIME-Version: 1.0 > From: mukul goyal > Subject: Re: How to set the link costs ? > To: OSPF@DISCUSS.MICROSOFT.COM > > Mikkel Thorup of AT&T Research has looked into the issue: > www.research.att.com/~mthorup/PAPERS/papers.html > > Thanks, > Mukul > > On Wed, 30 Oct 2002, Yasuhiro Ohara wrote: > > > Is there any way to calculate/produce the link cost, if topology is > > given ? I know that depends on the topology and how the network > > administrators want traffic to go through, but I think there should be > > some generic guidance, to realize the policy if one is given. (I mean > > "how traffic go through" by "policy".) > > > > Is there any related work, tools or papers ? > > How do you parameterize the costs on your network ? > > > > I know the type of the link is a way. > > I want another if there's. > > > > Waiting for your reply. > > > > regards, > > yasu > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 15:40:21 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10066 for ; Wed, 30 Oct 2002 15:40:21 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0079D030@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 15:42:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 305320 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 15:42:42 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 15:32:42 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17332 for ; Wed, 30 Oct 2002 15:32:38 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA12929 for ; Wed, 30 Oct 2002 15:32:40 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Oct 2002 15:32:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55B86423@vie-msgusr-01.dc.fore.com> Date: Wed, 30 Oct 2002 15:32:36 -0500 Reply-To: Mailing List Sender: Mailing List From: "Banerjee, Gargi" Subject: Re: How to set the link costs ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Yasu, Yes, there are a number of papers to compute dynamic link costs based on traffic matrix, importance of source destination end points, congestion etc. Some valuable papers are (published in Infocom): 1. A new approach to routing with dynamic metrics http://citeseer.nj.nec.com/chen98new.html 2. Minimum Interference Routing with Applications to MPLS Traffic Engineering http://citeseer.nj.nec.com/kodialam00minimum.html 3. Internet Traffic Engineering by optimizing OSPF weights http://citeseer.nj.nec.com/fortz00internet.html Hope this helps, Gargi -----Original Message----- From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] Sent: Wednesday, October 30, 2002 6:51 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: How to set the link costs ? Is there any way to calculate/produce the link cost, if topology is given ? I know that depends on the topology and how the network administrators want traffic to go through, but I think there should be some generic guidance, to realize the policy if one is given. (I mean "how traffic go through" by "policy".) Is there any related work, tools or papers ? How do you parameterize the costs on your network ? I know the type of the link is a way. I want another if there's. Waiting for your reply. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 17:44:58 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16936 for ; Wed, 30 Oct 2002 17:44:57 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0079D332@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 17:47:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 305535 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 17:47:16 -0500 Received: from 134.56.3.131 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 17:37:11 -0400 Received: from mx02-int.net.com (mx02-int.net.com [134.56.112.14]) by mx01.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id g9UMc8D11671 for ; Wed, 30 Oct 2002 14:38:08 -0800 (PST) Received: from west-mail.net.com (west-mail.net.com [134.56.112.40]) by mx02-int.net.com (Switch-2.2.4/Switch-2.2.4) with ESMTP id g9UMbxO11166 for ; Wed, 30 Oct 2002 14:38:00 -0800 (PST) Received: from net.com ([134.56.24.3]) by west-mail.net.com (Netscape Messaging Server 3.6) with ESMTP id AAA2AA0 for ; Wed, 30 Oct 2002 14:37:17 -0800 X-Mailer: Mozilla 4.61C-NETv45 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en, en-GB, fr, de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3DC05F1B.78D4B471@net.com> Date: Wed, 30 Oct 2002 14:37:15 -0800 Reply-To: Mailing List Sender: Mailing List From: Mani Devarajan Organization: N.E.T. http://www.net.com Subject: Question on ospfExtLsdbLimit To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi all, Does the ospfExtLsdbLimit needs to be a configurable option or it will be configured to a default value. I need this info bcoz one of the anvl ospf conformance test case requires to limit the ospfExtLsdbLimit, to test the database overflow state. And also I couldnt find any information about ospfExtLsdbLimit in "Architectural Constants" & "Configurable Constants" section in RFC2328. -Thanks in advance, Mani From owner-ospf@DISCUSS.MICROSOFT.COM Wed Oct 30 17:49:14 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17119 for ; Wed, 30 Oct 2002 17:49:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0079D27E@cherry.ease.lsoft.com>; Wed, 30 Oct 2002 17:51:33 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 305555 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Oct 2002 17:51:32 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 30 Oct 2002 17:51:32 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA29075 for ; Wed, 30 Oct 2002 17:51:29 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA10173 for ; Wed, 30 Oct 2002 17:51:31 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Oct 2002 17:51:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55763422@vie-msgusr-01.dc.fore.com> Date: Wed, 30 Oct 2002 17:51:29 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Question on ospfExtLsdbLimit To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -> Hi all, -> Does the ospfExtLsdbLimit needs to be a configurable option -> or it will be configured to a default value. -> -> I need this info bcoz one of the anvl ospf conformance test -> case requires to limit the ospfExtLsdbLimit, to test the -> database overflow state. -> -> And also I couldnt find any information about ospfExtLsdbLimit -> in "Architectural Constants" & "Configurable Constants" section -> in RFC2328. -> -> -Thanks in advance, -> Mani Look at RFC1765 section 2.1 -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 31 05:17:40 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11745 for ; Thu, 31 Oct 2002 05:17:39 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0079EB7F@cherry.ease.lsoft.com>; Thu, 31 Oct 2002 5:20:00 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 307009 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 31 Oct 2002 05:20:00 -0500 Received: from 192.122.173.140 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 31 Oct 2002 05:20:00 -0400 Received: from ROJOSEW2K ([10.77.139.146]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id PAA00659; Thu, 31 Oct 2002 15:49:22 +0530 (IST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <018f01c280c7$0c72c2d0$928b4d0a@apac.cisco.com> Date: Thu, 31 Oct 2002 15:49:51 +0530 Reply-To: Mailing List Sender: Mailing List From: Roy Jose Subject: Re: Query on implementation of SNMP TRAP ospfTxRetransmit Comments: To: Venkata.Naidu@MARCONI.COM, acee@REDBACK.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Venkata, Acee, Thanks for your responses. I think, I will also use the first LSA. The NM station doesn't always sit in the network, where congestion has happened. Thanks, Roy > Acee, > > -> I haven't implemented this trap but I'd just use the first LSA in > -> packet. > > My implementation uses the first LSA. > > -> Not speaking as WG co-chair and being completely > -> honest, I can't imagine why anyone would enable this trap in the > -> first place. One of the main causes of retransmissions is congestion > -> and sending this trap would only exacerbate matters. > > Frankly, I used this trap to figure out some of the > bugs in the past. Traps are sent to network manager > and in most of the cases NM is out-of-band signaling. > Congestion exacerbating in the data path is nothing > to do with sending the trap. > > For that matter, a packet not reaching the destination > may be because of thousands of reasons not necessarily > because of congestion. > > For example, link local LSAs should go on the exact > interface it is supposed to go (with out looking at > the route tables) - for that we have to enable some > of the IP socket options. If not, link local LSAs are > keep on retransmitted but never acked back. Until > unless admin gets a traps he/she can never figure out > why a particular message/packet/LSA is being flapped. > (unless he checks the error statistics/RtmsQ explicitly) > > -- > Venkata. > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Oct 31 15:02:43 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12287 for ; Thu, 31 Oct 2002 15:02:43 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.007A02DC@cherry.ease.lsoft.com>; Thu, 31 Oct 2002 15:05:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 309012 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 31 Oct 2002 15:05:03 -0500 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 31 Oct 2002 15:05:03 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 187LYs-0001RS-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 31 Oct 2002 12:05:02 -0800 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <3DAD7202.2070804@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19629835.20021031120457@psg.com> Date: Thu, 31 Oct 2002 12:04:57 -0800 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: WG Last Call for To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3DAD7202.2070804@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Folks- [wg member hat on] The -05 version of the draft has been published recently. The only changes are removing refs from the abstract to satisfy ID nits and additional text in the Acks section about Padma and Derek's original idea that is used as part of the mechanism in this doc. Thanks. -- Alex Wednesday, October 16, 2002, 6:04:50 AM, Acee Lindem wrote: > This is a Working Group Last Call for the I-D > "Detecting Inactive Neighbors over OSPF Deamnd Circuits" > . This I-D describes a neighbor probing > technique for detecting inactive neighbors on demand circuits [RFC1793]. > We are requesting that this protocol specification be labeled a > Proposed Standard. > Please submit comments on the I-D to the authors and/or > ospf@discuss.microsoft.com by Wednesday, October 30th. > The abstract of the I-D reads as follows: > OSPF [RFC2328] is a link-state intra-domain routing protocol used in > IP networks. OSPF behavior over demand circuits is optimized in > [RFC1793] to minimize the amount of overhead traffic. A part of OSPF > demand circuit extensions is the Hello suppression mechanism. This > technique allows a demand circuit to go down when no interesting > traffic is going through the link. However, it also introduces a > problem, where it becomes impossible to detect a OSPF-inactive > neighbor over such a link. This memo addresses the above problem by > the neighbor probing mechanism. > Thanks, > -- > Acee