From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 1 14:20:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09879 for ; Tue, 1 Jul 2003 14:20:37 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00A3FB32@cherry.ease.lsoft.com>; Tue, 1 Jul 2003 14:20:16 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47251620 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 1 Jul 2003 14:20:14 -0400 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 1 Jul 2003 14:20:14 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01KXQQSCGORQ8X32YF@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 01 Jul 2003 11:20:08 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01KXQQSCGPQ08X32YF@omega7.wr.usgs.gov> Date: Tue, 1 Jul 2003 11:20:08 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: Clarification in NSSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Thank you Vivek for quoting the magic words. Sorry to be so tardy, I have been out of the office. >"If the Type-7 LSA is not contained in any explicitly >configured Type-7 address range and the calculating router has >the highest router ID amongst NSSA translators that have >originated a functionally equivalent Type-5 LSA (i.e. same >destination, cost and non-zero forwarding address) and that >are reachable over area 0 and the NSSA, then a Type-5 LSA >should be generated" This change was a late entry in RFC 3101 that was added shortly before its last call. It was not in RFC 1587. For any folk who are/have upgraded RFC 1587 implementations make sure this is added. RFC 3101 is much more than new feature. It has closed a number of bugs. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 1 15:31:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13747 for ; Tue, 1 Jul 2003 15:31:33 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00A3FFC8@cherry.ease.lsoft.com>; Tue, 1 Jul 2003 15:31:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47257611 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 1 Jul 2003 15:31:31 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 1 Jul 2003 15:31:30 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 6E0E26E328E for ; Tue, 1 Jul 2003 12:31:29 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F01E166.3000301@redback.com> Date: Tue, 1 Jul 2003 15:30:46 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Extensions to OSPF for Advertising Optional Router Capabilities To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I've respun the subject draft with some minor corrections. We've discussed it at the last three IETFs and there has been some (although light) discussion on the OSPF List. There are now at least three proposed applications. Unless there is vehement opposition, we intend to add this as a WG document shortly after the Vienna IETF (when the window for new drafts opens again) Thanks, -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 1 15:53:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14477 for ; Tue, 1 Jul 2003 15:53:33 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00A401E3@cherry.ease.lsoft.com>; Tue, 1 Jul 2003 15:53:33 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47267070 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 1 Jul 2003 15:53:32 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 1 Jul 2003 15:53:32 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id B65B939F4E1 for ; Tue, 1 Jul 2003 12:53:30 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030624160304.6E7A.SASAKI@soft.net.fujitsu.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F01E68F.6050000@redback.com> Date: Tue, 1 Jul 2003 15:52:47 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 Point-to-Point interface To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Taisuke Sasaki wrote: > I have a question about how to advertise its own > point-to-point interface address in its Intra-Area-Prefix-LSAs. > > Suppose that a Router A has a point-to-point link > and IPv6 address 3ffe:1::1/64 is assigned. > > point-to-point > +---+ 3ffe:1::/64 +---+ > | A +---------------+ B | > +---+ ::1 ::2 +---+ > > I saw some OSPFv3 implementations that Router A advertised > its p2p interface address in an Intra-Area-Prefix-LSA as follows: > > PrefixLength = 128 > PrefixOptions = LA-bit > Metric = 0 > Address Prefix = 3ffe:1::1 > > It's no problem from the viewpoint of Routing, > but is this implementation fully compliant with rfc2740 3.4.3.7? > > My opinion is the next: > If IPv6 address 3ffe:1::1/128 is assigned to Router A's p2p > interface, it is OK. > But in this case, IPv6 prefix(/64) is assigned to its p2p > interface, so Router A should advertise its interface prefix > as follows: > > PrefixLength = 64 > PrefixOptions = 0 > Metric = 1 ;interface output cost > Address Prefix = 3ffe:1:: Hi Taisuke Sasaki, I would agree with you the prefix should be advertised with the assigned length and cost. Actually, there is very ambiguous statement in RFC 2740: If the interface type is Point-to-MultiPoint, or the interface is in state Loopback, or the interface connects to a point-to-point link which has not been assigned a prefix, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ then the site-local and global scope IPv6 addresses associated ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ with the interface (if any) are copied into the intra-area- prefix-LSA, setting the LA-bit in the PrefixOptions field, and setting the PrefixLength to 128 and the Metric to 0. It seems to be a contraction to reference site-local and global scope IPv6 addresses associated with a P2P link that doesn't have any prefixes assigned. Any other interpretations? Thanks, Acee > > regards. > > --- > taisuke sasaki > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 1 19:43:27 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20795 for ; Tue, 1 Jul 2003 19:43:27 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00A4057E@cherry.ease.lsoft.com>; Tue, 1 Jul 2003 19:43:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47289091 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 1 Jul 2003 19:43:26 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 1 Jul 2003 19:43:26 -0400 Received: from [147.28.0.62] (helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 4.14) id 19XUmU-000MNe-7B for OSPF@PEACH.EASE.LSOFT.COM; Tue, 01 Jul 2003 23:43:26 +0000 X-Mailer: The Bat! (v1.62i) Personal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38152568141.20030701164258@psg.com> Date: Tue, 1 Jul 2003 16:42:58 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: AD-review comments on draft-ietf-ospf-scalability To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Folks- Please find below my AD-review comments on draft-ietf-ospf-scalability. "Ed" prefix is for editorial comments. Regards -- Alex http://www.psg.com/~zinin/ Ed: Number of authors is quite high. One way to address this would be to leave only the editor on the front page Author's info and move others to the "Contributors" Ed: notice the order of the sections: > Status of this Memo [...] > IPR Notices [...] > Copyright Notice [...] > Abstract "IPR Notices" should be renamed to "Intellectual Property Considerations" and moved to the end of the doc before the refs. Copyright Notice should be the last part of the doc. Abstract should follow the Status. > 1. Introduction > > A large network running OSPF [Ref1] or OSPF-TE [Ref2] protocol may > occasionally experience the simultaneous or near-simultaneous update Ed: This reads like "OSPF-TE" is a separate protocol. ... > (1) Classify all OSPF packets in two classes: a "high priority" > class comprising of OSPF Hello packets and Link State > Acknowledgment packets, and a "low priority" class > comprising of all other packets. The classification is > accomplished by examining the OSPF packet header. While > receiving a packet from a neighbor and while transmitting > a packet to a neighbor, try to process a "high priority" > packet ahead of a "low priority" packet. This suggestion breaks the Crypto Sequence number processing as described in the OSPF spec. The document should probably suggest a STD-compatible way of dealing with this by maintaining separate receive SNs for each class of packets. > (2) If the Recommendation 1 cannot be implemented then reset the > inactivity timer for an adjacency whenever any OSPF unicast > packet or any OSPF packet sent to 224.0.0.5 over a Should "224.0.0.5" be "AllSPFRouters"? Also, why only 224.0.0.5? DR and BDR will receive on 224.0.0.6 too, and seems that the time should be adjusted. No? I would it think it should have been any received valid OSPF packet. > (4) Implicit Congestion Detection and Action Based on That: > If there is control message congestion at a router, its > neighbors do not know about that explicitly. However, they > can implicitly detect it based on the number of unacknowledged > LSAs to this router. If this number exceeds a certain "high > water mark" then the rate at which LSAs are sent to this router > should be reduced. At a future time, if the number of > unacknowledged LSAs to this router falls below a certain "low > water mark" then the normal rate of sending LSAs to this > router should be resumed. An example value for the "high > water mark" may be 20 unacknowledged LSAs and that for the "low > water mark" may be 10 unacknowledged LSAs. An example > value for the rate on exceeding the "high water mark" may be > 50% the normal rate. This recommendation is to be implemented > only for unicast LSAs sent to a neighbor or LSAs sent > to 224.0.0.5 over a point-to-point link. it seems that one step is not enough and something like exp back off should be considered. E.g., if my neighbor can currently process only 50 LSUs per sec, and I step down from 200 to 100, I am still not good enough. > (5) Throttling Adjacencies to be Brought Up Simultaneously: > If a router tries to bring up a large number of adjacencies to > its neighbors simultaneously then that may cause severe > congestion due to database synchronization and LSA flooding > activities. It is recommended that during such a situation > no more than "n" adjacencies should be brought up > simultaneously. Once a subset of adjacencies have been brought > up successfully, newer adjacencies may be brought up as long as > the number of simultaneous adjacencies being brought up does not > exceed "n". The appropriate value of "n" would depend on the > router processing power, link bandwidth and propagation delay. > An example value may be 4. The last sentence almost sounds like n should be a dynamic value (e.g., the number of links would probably matter too.) Should we just drop it? > 3. Security Considerations > > This memo does not create any new security issues for the OSPF > protocol. Not totally true. See my note about crypto seq nums. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 2 04:31:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28439 for ; Wed, 2 Jul 2003 04:31:19 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A413A9@cherry.ease.lsoft.com>; Wed, 2 Jul 2003 4:31:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47323881 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 2 Jul 2003 04:31:17 -0400 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Jul 2003 04:31:16 -0400 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Wed, 02 Jul 2003 14:12:21 +0530 Received: from vivekd (vivekd.future.futsoft.com [10.20.6.77]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h628QI0r014465 for ; Wed, 2 Jul 2003 13:56:19 +0530 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <000001c233b6$2d1042a0$4d06140a@future.futsoft.com> Date: Thu, 25 Jul 2002 14:05:03 +0530 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Extensions to OSPF for Advertising Optional Router Capabilities To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F01E166.3000301@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Acee, "If a type 11 opaque LSA is chosen, the originating router should also advertise type 10 LSA(s) into any attached NSSA/stub area(s). The choice of flooding scope is made by the advertising router and is a matter of local policy." Taking it otherwise, if NSSA ABR or ABR with attached STUB area receives a Type 11 capability LSA (from some other router), should it originate a Type 10 for its attached NSSA/STUB ?? E.g Suppose Router R1(with attached NSSA/STUB) implements a policy "A" and decides to originate Type 11 capability LSA (it will originate Type 10 attached in NSSA/STUB). Another router R2(with no attached NSSA/STUB) in same AS implements same policy "A" and originated Type 11 capability LSA. Now should router R1 on receiving this LSA pass on this information into attached NSSA/STUB areas? Since the policy which decided the scope is same in both routers, isn't capability info is of interest to routers internal to STUB/NSSA. thanks, vivek -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Acee Lindem Sent: Wednesday, 2 July 2003 1:01 AM To: OSPF@peach.ease.lsoft.com Subject: Extensions to OSPF for Advertising Optional Router Capabilities I've respun the subject draft with some minor corrections. We've discussed it at the last three IETFs and there has been some (although light) discussion on the OSPF List. There are now at least three proposed applications. Unless there is vehement opposition, we intend to add this as a WG document shortly after the Vienna IETF (when the window for new drafts opens again) Thanks, -- Acee *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 2 09:39:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17893 for ; Wed, 2 Jul 2003 09:39:56 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A418F8@cherry.ease.lsoft.com>; Wed, 2 Jul 2003 9:39:54 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47364715 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 2 Jul 2003 09:39:52 -0400 Received: from 129.188.136.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Jul 2003 09:39:52 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h62DdG0L006504 for ; Wed, 2 Jul 2003 06:39:16 -0700 (MST) Received: from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h62DdDSR012595 for ; Wed, 2 Jul 2003 08:39:14 -0500 Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jul 2003 09:38:52 -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 Jul 2003 09:40:32 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: AD-review comments on draft-ietf-ospf-scalability To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Alex, We will get back to you on this soon. Thanks, Vishwas -----Original Message----- From: Alex Zinin [mailto:zinin@PSG.COM] Sent: Wednesday, July 02, 2003 05:13 To: OSPF@PEACH.EASE.LSOFT.COM Subject: AD-review comments on draft-ietf-ospf-scalability Folks- Please find below my AD-review comments on draft-ietf-ospf-scalability. "Ed" prefix is for editorial comments. Regards -- Alex http://www.psg.com/~zinin/ Ed: Number of authors is quite high. One way to address this would be to leave only the editor on the front page Author's info and move others to the "Contributors" Ed: notice the order of the sections: > Status of this Memo [...] > IPR Notices [...] > Copyright Notice [...] > Abstract "IPR Notices" should be renamed to "Intellectual Property Considerations" and moved to the end of the doc before the refs. Copyright Notice should be the last part of the doc. Abstract should follow the Status. > 1. Introduction > > A large network running OSPF [Ref1] or OSPF-TE [Ref2] protocol may > occasionally experience the simultaneous or near-simultaneous update Ed: This reads like "OSPF-TE" is a separate protocol. ... > (1) Classify all OSPF packets in two classes: a "high priority" > class comprising of OSPF Hello packets and Link State > Acknowledgment packets, and a "low priority" class > comprising of all other packets. The classification is > accomplished by examining the OSPF packet header. While > receiving a packet from a neighbor and while transmitting > a packet to a neighbor, try to process a "high priority" > packet ahead of a "low priority" packet. This suggestion breaks the Crypto Sequence number processing as described in the OSPF spec. The document should probably suggest a STD-compatible way of dealing with this by maintaining separate receive SNs for each class of packets. > (2) If the Recommendation 1 cannot be implemented then reset the > inactivity timer for an adjacency whenever any OSPF unicast > packet or any OSPF packet sent to 224.0.0.5 over a Should "224.0.0.5" be "AllSPFRouters"? Also, why only 224.0.0.5? DR and BDR will receive on 224.0.0.6 too, and seems that the time should be adjusted. No? I would it think it should have been any received valid OSPF packet. > (4) Implicit Congestion Detection and Action Based on That: > If there is control message congestion at a router, its > neighbors do not know about that explicitly. However, they > can implicitly detect it based on the number of unacknowledged > LSAs to this router. If this number exceeds a certain "high > water mark" then the rate at which LSAs are sent to this router > should be reduced. At a future time, if the number of > unacknowledged LSAs to this router falls below a certain "low > water mark" then the normal rate of sending LSAs to this > router should be resumed. An example value for the "high > water mark" may be 20 unacknowledged LSAs and that for the "low > water mark" may be 10 unacknowledged LSAs. An example > value for the rate on exceeding the "high water mark" may be > 50% the normal rate. This recommendation is to be implemented > only for unicast LSAs sent to a neighbor or LSAs sent > to 224.0.0.5 over a point-to-point link. it seems that one step is not enough and something like exp back off should be considered. E.g., if my neighbor can currently process only 50 LSUs per sec, and I step down from 200 to 100, I am still not good enough. > (5) Throttling Adjacencies to be Brought Up Simultaneously: > If a router tries to bring up a large number of adjacencies to > its neighbors simultaneously then that may cause severe > congestion due to database synchronization and LSA flooding > activities. It is recommended that during such a situation > no more than "n" adjacencies should be brought up > simultaneously. Once a subset of adjacencies have been brought > up successfully, newer adjacencies may be brought up as long as > the number of simultaneous adjacencies being brought up does not > exceed "n". The appropriate value of "n" would depend on the > router processing power, link bandwidth and propagation delay. > An example value may be 4. The last sentence almost sounds like n should be a dynamic value (e.g., the number of links would probably matter too.) Should we just drop it? > 3. Security Considerations > > This memo does not create any new security issues for the OSPF > protocol. Not totally true. See my note about crypto seq nums. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 2 23:15:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12766 for ; Wed, 2 Jul 2003 23:15:04 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00A43A13@cherry.ease.lsoft.com>; Wed, 2 Jul 2003 23:14:58 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47438200 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 2 Jul 2003 23:04:19 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Jul 2003 23:04:19 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 1723713BF66 for ; Wed, 2 Jul 2003 20:04:18 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000001c233b6$2d1042a0$4d06140a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F039CF5.4060203@redback.com> Date: Wed, 2 Jul 2003 23:03:17 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Extensions to OSPF for Advertising Optional Router Capabilities To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vivek Dubey wrote: > Hi Acee, > "If a type 11 opaque LSA > is chosen, the originating router should also advertise type 10 > LSA(s) into any attached NSSA/stub area(s). The choice of flooding > scope is made by the advertising router and is a matter of local > policy." > > Taking it otherwise, if NSSA ABR or ABR with attached STUB area > receives a Type 11 capability LSA (from some other router), should > it originate a Type 10 for its attached NSSA/STUB ?? Hi Vivek, I don't think this type of translation is necessary. Also, it is somewhat counter to the goal of limiting the LSAs advertised into a stub/NSSA area. If a very compelling application comes along then maybe we could consider it in the future. Thanks, Acee > > E.g > Suppose Router R1(with attached NSSA/STUB) implements a policy "A" > and decides to originate Type 11 capability LSA (it will originate Type 10 > attached in NSSA/STUB). > > Another router R2(with no attached NSSA/STUB) in same AS implements > same policy "A" and originated Type 11 capability LSA. > Now should router R1 on receiving this LSA pass on this information > into attached NSSA/STUB areas? > > Since the policy which decided the scope is same in both routers, > isn't capability info is of interest to routers internal to STUB/NSSA. > > thanks, > vivek > > > -----Original Message----- > From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Acee > Lindem > Sent: Wednesday, 2 July 2003 1:01 AM > To: OSPF@peach.ease.lsoft.com > Subject: Extensions to OSPF for Advertising Optional Router Capabilities > > > I've respun the subject draft with some minor corrections. > We've discussed it at the last three IETFs and there has been > some (although light) discussion on the OSPF List. There are now > at least three proposed applications. Unless there is > vehement opposition, we intend to add this as a WG document shortly > after the Vienna IETF (when the window for new drafts opens again) > > > > Thanks, > -- > Acee > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 3 10:55:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14287 for ; Thu, 3 Jul 2003 10:55:50 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00A461A5@cherry.ease.lsoft.com>; Thu, 3 Jul 2003 10:55:49 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47512354 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 3 Jul 2003 10:09:49 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Jul 2003 10:09:49 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 099509C9022; Thu, 3 Jul 2003 07:09:45 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F0438E6.1060305@redback.com> Date: Thu, 3 Jul 2003 10:08:38 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Working Group Last Call for draft-pillay-esnault-ospf-flooding-07.txt Ended Comments: To: iesg-secretary , Bill Fenner , Alex Zinin To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit The Working Group last call for OSPF Refresh and Flooding Reduction in Stable Topologies (draft-pillay-esnault-ospf-flooding-07.txt) ended on Wednesday, July 2, 2003. It is now being forwarded to the Routing Group ADs for final review and the subsequent IETF wide last call. The draft can be found at: http://www.ietf.org/internet-drafts/draft-pillay-esnault-ospf-flooding-07.txt Thanks, -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 3 10:55:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14289 for ; Thu, 3 Jul 2003 10:55:51 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A4606B@cherry.ease.lsoft.com>; Thu, 3 Jul 2003 10:55:50 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47512361 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 3 Jul 2003 10:09:52 -0400 Received: from 132.151.6.20 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Jul 2003 10:09:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y4mV-0005GR-L8 for ospf@peach.ease.lsoft.com; Thu, 03 Jul 2003 10:09:51 -0400 Received: (from nobody@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63E9pC6020237 for ospf@peach.ease.lsoft.com; Thu, 3 Jul 2003 10:09:51 -0400 X-Authentication-Warning: www1.ietf.org: nobody set sender to iesg-secretary@ietf.org using -f X-Loop: WREQ 2 Message-ID: <200307031409.h63E9pC6020237@www1.ietf.org> Date: Thu, 3 Jul 2003 10:09:51 -0400 Reply-To: Mailing List Sender: Mailing List From: Support Online Subject: [iesg-secretary #8561] Working Group Last Call for draft-pillay-esnault-ospf-flooding-07.txt (Autoreply) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Your request of the subject Working Group Last Call for draft-pillay-esnault-ospf-flooding-07.txt has been received. If you have further email on this subject, please retain the subject: line (including the tracking number [ietf-action #xxx]) so that when you respond to ietf-action@ietf.org, the email goes in the same tracking ticket. Thank you. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 3 17:20:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07304 for ; Thu, 3 Jul 2003 17:20:21 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00A4AE13@cherry.ease.lsoft.com>; Thu, 3 Jul 2003 17:19:35 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47524207 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 3 Jul 2003 16:43:11 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Jul 2003 15:36:18 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00A49BBC@cherry.ease.lsoft.com>; Thu, 3 Jul 2003 15:36:18 -0400 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Jul 2003 15:36:17 -0400 Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id h63JaEmX014569 for ; Thu, 3 Jul 2003 12:36:14 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (/) with ESMTP id h63Ja8Q2020876 for ; Thu, 3 Jul 2003 12:36:08 -0700 (PDT) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.9/8.12.9) with ESMTP id h63JP2Dp025812 for ; Thu, 3 Jul 2003 12:25:02 -0700 (PDT) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com (8.12.9/8.12.9) with SMTP id h63JP08C000722 for ; Thu, 3 Jul 2003 12:25:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <002c01c3419b$75dd9ca0$1105f183@b90.tdd.sj.nec.com> Date: Thu, 3 Jul 2003 12:44:04 -0700 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Clarification in changing the router id dynamically!! Comments: To: osPF@discuss.microsoft.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, If the router id of the router R1 is changed on the fly (dynamically), what factor triggers the adjacent router R2 connected to R1 via point to point link, to generate the new Router LSA??? From the RFC i could infer that R1 will flush all his self originated lsas when it's router lsa has been changed. But i couldn't find, how the R2 triggered to generate the new router lsa with the changed router id as is neighbor id in its router lsa?? Thanks in advance, Kamatchi. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 4 02:04:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09153 for ; Fri, 4 Jul 2003 02:04:02 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A4BA58@cherry.ease.lsoft.com>; Fri, 4 Jul 2003 2:03:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47540305 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 4 Jul 2003 02:03:49 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Jul 2003 02:03:48 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id <3BLWFG69>; Fri, 4 Jul 2003 11:33:43 +0530 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 Jul 2003 11:34:03 +0530 Reply-To: Mailing List Sender: Mailing List From: "Jeyanath Minto J - CTD, Chennai." Subject: Re: Clarification in changing the router id dynamically!! To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list hi Kamatchi, old neighbour down event trigger the new lsa origination. ofcourse, its very late origination. u can detect it earlier and originate as soon as possible .This is implementation dependent. Cheers Minto Mascarenhas -----Original Message----- From: kamatchi soundaram [mailto:kamatchi@TDD.SJ.NEC.COM] Sent: Friday, July 04, 2003 1:14 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Clarification in changing the router id dynamically!! Hi, If the router id of the router R1 is changed on the fly (dynamically), what factor triggers the adjacent router R2 connected to R1 via point to point link, to generate the new Router LSA??? From the RFC i could infer that R1 will flush all his self originated lsas when it's router lsa has been changed. But i couldn't find, how the R2 triggered to generate the new router lsa with the changed router id as is neighbor id in its router lsa?? Thanks in advance, Kamatchi. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 4 21:27:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14729 for ; Fri, 4 Jul 2003 21:27:19 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A4CFC8@cherry.ease.lsoft.com>; Fri, 4 Jul 2003 21:27:18 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47605656 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 4 Jul 2003 21:27:17 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Jul 2003 21:27:16 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id B2CB3950AD8 for ; Fri, 4 Jul 2003 18:27:14 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <002c01c3419b$75dd9ca0$1105f183@b90.tdd.sj.nec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F06291C.1070706@redback.com> Date: Fri, 4 Jul 2003 21:25:48 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Clarification in changing the router id dynamically!! To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit kamatchi soundaram wrote: > Hi, > > If the router id of the router R1 is changed on the fly (dynamically), > what factor triggers the adjacent router R2 connected to R1 via point to > point link, to generate the new Router LSA??? > > From the RFC i could infer that R1 will flush all his self originated lsas > when it's router lsa has been changed. > But i couldn't find, how the R2 triggered to generate the new router lsa > with the changed router id as is neighbor id in its router lsa?? Kamatchi, Actually, since neighbors are identified by router ID on P2P links (as per RFC 2338 section 8.2), R2 shouldn't recognize R1 with the new router ID and should bring down the old adjacency with R1 and form a new one. A more interesting question is what would happen on a broadcast or NBMA network (where neighbors are identified by source address). This case isn't explicitly handled by RFC 2328 and there is some variance between implementations. At a minimum, the DR must recognize the change in router ID and originate a new network LSA. I found that one popular implementation required the router with the router ID change to bring its adjacencies down (by sending a hello w/o any neighbor IDs) in order to interoperate. Thanks, Acee > > Thanks in advance, > Kamatchi. > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jul 5 18:30:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18922 for ; Sat, 5 Jul 2003 18:30:28 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00A4FCA7@cherry.ease.lsoft.com>; Sat, 5 Jul 2003 18:30:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47532644 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 5 Jul 2003 18:30:25 -0400 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 5 Jul 2003 18:30:25 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A4FB6E@cherry.ease.lsoft.com>; Sat, 5 Jul 2003 18:30:25 -0400 Message-ID: Date: Sat, 5 Jul 2003 18:30:25 -0400 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: "Purely backboneless" virtual links To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list All, Suppose that a virtual link is configured between R1 and R2 via transit area T. Both R1 and R2 are ABRs, none of them having any non-virtual link in the backbone. Should this virtual link come up? Thanks, Igor From owner-ospf@PEACH.EASE.LSOFT.COM Sat Jul 5 19:12:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19587 for ; Sat, 5 Jul 2003 19:12:02 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00A4FAEB@cherry.ease.lsoft.com>; Sat, 5 Jul 2003 19:12:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47534315 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 5 Jul 2003 19:12:04 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 5 Jul 2003 19:12:04 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 162CC933289 for ; Sat, 5 Jul 2003 16:12:03 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F075AE0.4070508@redback.com> Date: Sat, 5 Jul 2003 19:10:24 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: "Purely backboneless" virtual links To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Igor Miroshnik wrote: > All, > > Suppose that a virtual link is configured between R1 and R2 via transit > area T. Both R1 and R2 are ABRs, none of them having any non-virtual link > in the backbone. Should this virtual link come up? Yes. > > Thanks, > Igor > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 7 10:51:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28273 for ; Mon, 7 Jul 2003 10:51:00 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00A544A5@cherry.ease.lsoft.com>; Mon, 7 Jul 2003 10:50:59 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47678669 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 7 Jul 2003 10:50:58 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 7 Jul 2003 10:50:58 -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 KAA25053 for ; Mon, 7 Jul 2003 10:50:56 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15395 for ; Mon, 7 Jul 2003 10:50:57 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jul 2003 10:50:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55FB6F45@vie-msgusr-01.dc.fore.com> Date: Mon, 7 Jul 2003 10:50:56 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Clarification in changing the router id dynamically!! To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list -> This case isn't explicitly handled by RFC 2328 and there is -> some variance -> between implementations. At a minimum, the DR must recognize -> the change -> in router ID and originate a new network LSA. I found that -> one popular -> implementation required the router with the router ID change -> to bring its -> adjacencies down (by sending a hello w/o any neighbor IDs) -> in order to interoperate. RFC2328 recommends this approach. Page 47 reads: . . . If a router's OSPF Router ID is changed, the router's OSPF software should be restarted before the new Router ID takes effect. . . . Restarting OSPF software is nothing but bringing up adjacencies afresh. Venkata. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 7 19:33:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21506 for ; Mon, 7 Jul 2003 19:33:14 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00A55E93@cherry.ease.lsoft.com>; Mon, 7 Jul 2003 19:33:14 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47713187 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 7 Jul 2003 19:33:13 -0400 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 7 Jul 2003 19:33:13 -0400 Received: (qmail 26034 invoked from network); 7 Jul 2003 23:33:12 -0000 Received: from unknown (HELO bigbird.nj.us.utstar.com) (172.16.36.21) by 172.16.36.12 with SMTP; 7 Jul 2003 23:33:12 -0000 Received: from utstar.com (localhost.localdomain [127.0.0.1]) by bigbird.nj.us.utstar.com (8.9.3/8.9.3) with ESMTP id TAA02483; Mon, 7 Jul 2003 19:33:12 -0400 Message-ID: <200307072333.TAA02483@bigbird.nj.us.utstar.com> Date: Mon, 7 Jul 2003 19:33:12 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: OSPF WG agenda for ietf 57 Comments: To: agenda@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Tuesday July 15 (17:00 - 18:00) =============================== CHAIRS: Rohit Dube Acee Lindem AGENDA: Agenda Bashing 5 Mins IGP Capabilities 10 Mins Jean Philippe Vasseur WG document status 10 Mins Chairs --rohit. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 8 05:10:00 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15295 for ; Tue, 8 Jul 2003 05:09:59 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00A569E1@cherry.ease.lsoft.com>; Tue, 8 Jul 2003 5:09:59 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47747585 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 8 Jul 2003 05:09:58 -0400 Received: from 203.199.83.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Jul 2003 05:09:58 -0400 Received: (qmail 19075 invoked by uid 510); 8 Jul 2003 09:09:15 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 08 jul 2003 09:09:15 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030708090915.19072.qmail@webmail29.rediffmail.com> Date: Tue, 8 Jul 2003 09:09:15 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Incremental SPF calculation To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Is there any standard/non-standard documentation available for incremental SPF calculation. krishna ___________________________________________________ Click below to experience Sooraj R Barjatya's latest offering 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek & Kareena http://www.mpkdh.com From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 8 05:21:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15592 for ; Tue, 8 Jul 2003 05:21:28 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00A56B27@cherry.ease.lsoft.com>; Tue, 8 Jul 2003 5:21:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47747712 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 8 Jul 2003 05:21:26 -0400 Received: from 66.218.93.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Jul 2003 05:21:26 -0400 Received: from [203.200.20.226] by web41801.mail.yahoo.com via HTTP; Tue, 08 Jul 2003 02:21:25 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030708092125.84791.qmail@web41801.mail.yahoo.com> Date: Tue, 8 Jul 2003 02:21:25 -0700 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: Reachability To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, Is it fair to assume that *each* router in one Autonomous System will have reachability to the other via some intermediate routers. Extending this a bit, is it fair to assume that each router in one OSPF Area will be aware of all the other routers in some other area .. or will somehow be able to reach the other one? Thanks for any help, Rohit __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 8 05:26:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15740 for ; Tue, 8 Jul 2003 05:26:44 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00A56B2B@cherry.ease.lsoft.com>; Tue, 8 Jul 2003 5:26:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47747761 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 8 Jul 2003 05:26:44 -0400 Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Jul 2003 05:26:44 -0400 Received: from user-2ivfm5i.dialup.mindspring.com ([165.247.216.178] helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19ZokF-0006nv-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 08 Jul 2003 02:26:43 -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: <20030708090915.19072.qmail@webmail29.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3F0A8E7E.B835E1B2@earthlink.net> Date: Tue, 8 Jul 2003 02:27:26 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Incremental SPF calculation To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Actually what you are looking for is documentation for is a incremental Equal Cost Multipath algorithm. Incremental in its most coarse form could be divided into a ECMP algothihm for each area and then for External LSAs.. Mitchell Erblich Sr Software Engineer ---------------------------- Krishna Rao wrote: > > Is there any standard/non-standard documentation > available for incremental SPF calculation. > > krishna > > ___________________________________________________ > Click below to experience Sooraj R Barjatya's latest offering > 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek > & Kareena http://www.mpkdh.com From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 8 06:21:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16721 for ; Tue, 8 Jul 2003 06:21:56 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00A56E23@cherry.ease.lsoft.com>; Tue, 8 Jul 2003 6:21:57 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47778285 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 8 Jul 2003 06:21:56 -0400 Received: from 203.199.83.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Jul 2003 06:21:55 -0400 Received: (qmail 6511 invoked by uid 510); 8 Jul 2003 10:21:14 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 08 jul 2003 10:21:14 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030708102114.6510.qmail@webmail17.rediffmail.com> Date: Tue, 8 Jul 2003 10:21:14 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Re: Incremental SPF calculation To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Mitchell, What i meant is doing SPF calculation in incremental steps. Reason being if LSDB is containing large number of LSAs going for complete SPF calculation will tie down the processor. Better if LSDB is splitted in parts and each portion is used for incremental calculation. At the same time maintaining the sanity of routing table. thanks, krishna On Tue, 08 Jul 2003 Erblichs wrote : >Actually what you are looking for is documentation for >is a incremental Equal Cost Multipath algorithm. > >Incremental in its most coarse form could be divided >into a ECMP algothihm for each area and then for >External LSAs.. > >Mitchell Erblich >Sr Software Engineer >---------------------------- > >Krishna Rao wrote: > > > > Is there any standard/non-standard documentation > > available for incremental SPF calculation. > > > > krishna > > > > ___________________________________________________ > > Click below to experience Sooraj R Barjatya's latest >offering > > 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek > > & Kareena http://www.mpkdh.com ___________________________________________________ Click below to experience Sooraj R Barjatya's latest offering 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek & Kareena http://www.mpkdh.com From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 8 07:08:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17573 for ; Tue, 8 Jul 2003 07:08:26 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A56ED9@cherry.ease.lsoft.com>; Tue, 8 Jul 2003 7:08:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47781326 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 8 Jul 2003 07:08:27 -0400 Received: from 207.217.120.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Jul 2003 07:08:27 -0400 Received: from user-2ivfm5i.dialup.mindspring.com ([165.247.216.178] helo=earthlink.net) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19ZqKf-0006uW-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 08 Jul 2003 04:08:25 -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: <20030708102114.6510.qmail@webmail17.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3F0AA64E.45B2B36C@earthlink.net> Date: Tue, 8 Jul 2003 04:09:02 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Incremental SPF calculation To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Krishna, Read my lips, the main OSPF RFC specifies ECMP.. If you impliment a SPF algorithm then you are out of OSPF RFC compliance. The SPF algorithm was developed by a mathematician (can't spell his name :-) ) and has some fundamental foundations for the ECMP algorithm. And incremental computations have been around for a few years. Try checking a few university web sites for theoritectical information.. Else, you are going to have to pay a few dollars for a working example.. Mitchell Erblich Sr Software Engineer ------------------------ Krishna Rao wrote: > > Hi Mitchell, > What i meant is doing SPF calculation > in incremental steps. > Reason being if LSDB is containing large > number of LSAs going for complete SPF calculation > will tie down the processor. Better if LSDB > is splitted in parts and each portion is used > for incremental calculation. At the same time maintaining > the sanity of routing table. > > thanks, > krishna > > On Tue, 08 Jul 2003 Erblichs wrote : > >Actually what you are looking for is documentation for > >is a incremental Equal Cost Multipath algorithm. > > > >Incremental in its most coarse form could be divided > >into a ECMP algothihm for each area and then for > >External LSAs.. > > > >Mitchell Erblich > >Sr Software Engineer > >---------------------------- > > > >Krishna Rao wrote: > > > > > > Is there any standard/non-standard documentation > > > available for incremental SPF calculation. > > > > > > krishna > > > > > > ___________________________________________________ > > > Click below to experience Sooraj R Barjatya's latest > >offering > > > 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek > > > & Kareena http://www.mpkdh.com > > ___________________________________________________ > Click below to experience Sooraj R Barjatya's latest offering > 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek > & Kareena http://www.mpkdh.com From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 8 08:45:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19583 for ; Tue, 8 Jul 2003 08:45:28 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00A571CE@cherry.ease.lsoft.com>; Tue, 8 Jul 2003 8:45:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47783116 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 8 Jul 2003 08:45:27 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Jul 2003 08:45:26 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 88B8B99E26D for ; Tue, 8 Jul 2003 05:44:31 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030708090915.19072.qmail@webmail29.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F0ABC2B.7080809@redback.com> Date: Tue, 8 Jul 2003 08:42:19 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Incremental SPF calculation To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Krishna Rao wrote: > Is there any standard/non-standard documentation > available for incremental SPF calculation. The standard documentation is in RFC 2328 sections 16.5 and 16.6. More elaborate techniques can be deployed at the expense of added complexity and saving addtional state. > > krishna > > ___________________________________________________ > Click below to experience Sooraj R Barjatya's latest offering > 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek > & Kareena http://www.mpkdh.com > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 8 09:05:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20382 for ; Tue, 8 Jul 2003 09:05:56 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A570E4@cherry.ease.lsoft.com>; Tue, 8 Jul 2003 9:05:56 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47785919 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 8 Jul 2003 09:05:54 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Jul 2003 09:05:54 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id AF7EE99E270 for ; Tue, 8 Jul 2003 06:05:52 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030708092125.84791.qmail@web41801.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F0AC12C.3040708@redback.com> Date: Tue, 8 Jul 2003 09:03:40 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Reachability To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Rohit, I'm not sure what you are trying to accomplish based on your assumptions. In a well designed OSPF routing domain, all routers will be reachable when things are working. However, one can always hypothesize some failure or combination of failures which will isolate or partition the routing domain. Thanks, Acee Rohit Gupta wrote: > Hi, > > Is it fair to assume that *each* router in one > Autonomous System will have reachability to the other > via some intermediate routers. > > Extending this a bit, is it fair to assume that each > router in one OSPF Area will be aware of all the other > routers in some other area .. or will somehow be able > to reach the other one? > > Thanks for any help, > Rohit > > > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 8 15:08:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05585 for ; Tue, 8 Jul 2003 15:08:56 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00A58411@cherry.ease.lsoft.com>; Tue, 8 Jul 2003 15:08:54 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47810179 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 8 Jul 2003 14:43:44 -0400 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Jul 2003 14:43:43 -0400 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id h68IhfmX000015 for ; Tue, 8 Jul 2003 11:43:41 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (/) with ESMTP id h68IhYrP026987 for ; Tue, 8 Jul 2003 11:43:34 -0700 (PDT) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.9/8.12.9) with ESMTP id h68IWQDp005249 for ; Tue, 8 Jul 2003 11:32:26 -0700 (PDT) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com (8.12.9/8.12.9) with SMTP id h68IWO8C012220 for ; Tue, 8 Jul 2003 11:32:24 -0700 (PDT) References: <002c01c3419b$75dd9ca0$1105f183@b90.tdd.sj.nec.com> <3F06291C.1070706@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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <008601c34581$f61b7c40$1105f183@b90.tdd.sj.nec.com> Date: Tue, 8 Jul 2003 11:51:37 -0700 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Re: Clarification in changing the router id dynamically!! To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Acee, ----- Original Message ----- From: "Acee Lindem" To: Sent: Friday, July 04, 2003 6:25 PM Subject: Re: Clarification in changing the router id dynamically!! > kamatchi soundaram wrote: > > Hi, > > > > If the router id of the router R1 is changed on the fly (dynamically), > > what factor triggers the adjacent router R2 connected to R1 via point to > > point link, to generate the new Router LSA??? > > > > From the RFC i could infer that R1 will flush all his self originated lsas > > when it's router lsa has been changed. > > But i couldn't find, how the R2 triggered to generate the new router lsa > > with the changed router id as is neighbor id in its router lsa?? > > Kamatchi, > > Actually, since neighbors are identified by router ID on P2P links (as per > RFC 2338 section 8.2), R2 shouldn't recognize R1 with the new router ID and > should bring down the old adjacency with R1 and form a new one. A more > interesting question is what would happen on a broadcast or NBMA network > (where neighbors are identified by source address). > This case isn't explicitly handled by RFC 2328 and there is some variance > between implementations. At a minimum, the DR must recognize the change > in router ID and originate a new network LSA. I found that one popular > implementation required the router with the router ID change to bring its > adjacencies down (by sending a hello w/o any neighbor IDs) in order to > interoperate. Does it mean that the R1 (router whose Id has got changed), should reset it's NSM with all its neighbor to down/init state and then send hello without any neighbor ids?? Since, R1 need to flush all it's self originated lsas before to bring down the adjacency and restart again, there needs some ample amount of time to flood and flush the lsas in the routing domain (atleast with the neighbor). So, i cannot send the hello packet (without any neighbors) immedietly after the sending out the max age lsas (to flush the self originated lsas). Because if i do that, then there is a chance that before the self originated lsas are completely flushed out or sent from R1, the NSM may reverted to down state. Which will basically prevent the complete flushing of self oringinated lsas . . correct?? My question is how can be the time between the flushing the lsas and hello's sent without the neighbor ids determined??? Since, if there is no significant amount left between the lsa flushing and new hello without neighbor id, then the entire system will be in bad condition. Thanks, Kamatchi. > > Thanks, > Acee > > > > > Thanks in advance, > > Kamatchi. > > > > > -- > Acee > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 8 15:10:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05739 for ; Tue, 8 Jul 2003 15:10:36 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00A58685@cherry.ease.lsoft.com>; Tue, 8 Jul 2003 15:10:36 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47810245 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 8 Jul 2003 14:45:16 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Jul 2003 14:45:15 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id E6F5469C0C1 for ; Tue, 8 Jul 2003 11:45:14 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000001c33a02$bb6d1660$f2ce7243@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F0B1149.7080303@redback.com> Date: Tue, 8 Jul 2003 14:45:29 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sina, Quaizar, I've thought about this and I don't think one can say one approach is better than the other in all cases. Here are my thoughts: - The multiple address family approach will be more efficient when multiple address families are required and the topologies overlap (i.e., the same set of links will be used for multiple topologies). - The multiple instance approach will be more efficient for topologies where multiple addresses families are not required (let's not forget that an extra address family layer is also going cost memory and CPU). - As for which is better operationally, I think this is more a matter of implemenation than approach. I disagree that the multiple address family approach is obviously better. In fact, in some ways having a separate link state database per address family may be easier to debug. With either approach, one can misconfigure something and I don't see that as major issue. It would be great to get a carrier's perspective here. - The multiple address family approach has precedence in BGP and M-ISIS where people configure things by address family. It appears to me that to do it right in OSPFv3 lots of things (link costs, ranges, redistribution, default origination, et al) have to be configured at the address family level rather than the interface, area, or instance level. - The multiple instance approach has the advantage of not requiring as much new invention (as Quaizar pointed out). The separation of link state databases and configuration is already there (since it each address family has a separate instance). However, it will still require new invention if other address families are to be carried (e.g., IPv4). Thanks, Acee Sina Mirtorabi wrote: > Quaizar, > > I will avoid going through an endless discussion regarding SIN and > integrated approach optimization > > Four comments though > > 1) > An integrated approach optimize the CPU usage, memory and network > bandwidth utilization which apparently is not your concerns. > > 2) > It is interesting how you make a believe that Integrated IS-IS is close > to SIN instance ID rather than our proposal. If ISIS had to implement > different instance (or using different process) for different AF then > how would you compare it to SIN? > > The fact that you are having more information to transport which is a > _result_ of adding AF is irrelevant to the rapprochement that you are > making between ISIS and SIN instance ID of OSPFv3. > > 3) > Any optimization can lead to some degree of code complexity, M-ISIS is > a good example of it. > > Defining and processing two new LSA does not look complex to me, as far > LG election, it is pretty close to DR election algorithm but if that > bothers you that much there are other ways to fix it ( forcing the > router that is AF capable to become DR either manually or the router can > declare itself DR and win DR election ) > > 4) > It is not sufficient to have separate instance ID, if a router does not > understand the reserved value for a AF but has the _same_ instance-ID ( > router downgraded etc ) then how you make sure that the path is not > through this router ? > > > Sina > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 8 16:00:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07771 for ; Tue, 8 Jul 2003 16:00:27 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00A58B00@cherry.ease.lsoft.com>; Tue, 8 Jul 2003 16:00:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47817643 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 8 Jul 2003 16:00:25 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Jul 2003 16:00:25 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 6573BA33A61 for ; Tue, 8 Jul 2003 13:00:24 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <002c01c3419b$75dd9ca0$1105f183@b90.tdd.sj.nec.com> <3F06291C.1070706@redback.com> <008601c34581$f61b7c40$1105f183@b90.tdd.sj.nec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F0B22E6.4000406@redback.com> Date: Tue, 8 Jul 2003 16:00:38 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Clarification in changing the router id dynamically!! To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit kamatchi soundaram wrote: > Hi Acee, > > ----- Original Message ----- > From: "Acee Lindem" > To: > Sent: Friday, July 04, 2003 6:25 PM > Subject: Re: Clarification in changing the router id dynamically!! > > > >>kamatchi soundaram wrote: >> >>>Hi, >>> >>> If the router id of the router R1 is changed on the fly (dynamically), >>>what factor triggers the adjacent router R2 connected to R1 via point to >>>point link, to generate the new Router LSA??? >>> >>> From the RFC i could infer that R1 will flush all his self originated >> > lsas > >>>when it's router lsa has been changed. >>> But i couldn't find, how the R2 triggered to generate the new router >> > lsa > >>>with the changed router id as is neighbor id in its router lsa?? >> >>Kamatchi, >> >>Actually, since neighbors are identified by router ID on P2P links (as per >>RFC 2338 section 8.2), R2 shouldn't recognize R1 with the new router ID > > and > >>should bring down the old adjacency with R1 and form a new one. A more >>interesting question is what would happen on a broadcast or NBMA network >>(where neighbors are identified by source address). >>This case isn't explicitly handled by RFC 2328 and there is some variance >>between implementations. At a minimum, the DR must recognize the change >>in router ID and originate a new network LSA. I found that one popular >>implementation required the router with the router ID change to bring its >>adjacencies down (by sending a hello w/o any neighbor IDs) in order to >>interoperate. Hi Kamatchi, > > > Does it mean that the R1 (router whose Id has got changed), should reset > it's NSM with all its neighbor to down/init state and then send hello > without any neighbor ids?? > > Since, R1 need to flush all it's self originated lsas before to bring down > the adjacency and restart again, there needs some ample amount of time to > flood and flush the lsas in the routing domain (atleast with the neighbor). > So, i cannot send the hello packet (without any neighbors) immedietly after > the sending out the max age lsas (to flush the self originated lsas). I purge self-originated LSAs before sending the empty hello. I do both before the router ID change. I do not add the self-originated LSAs to any retransmission lists and I do not wait for acknowledgements. Some implementations just let their old LSAs time out and without any strong complaints. > > Because if i do that, then there is a chance that before the self > originated lsas are completely flushed out or sent from R1, the NSM may > reverted to down state. Which will basically prevent the complete flushing > of self oringinated lsas . . correct?? Only if your Link State Update packet is dropped. > > My question is how can be the time between the flushing the lsas and > hello's sent without the neighbor ids determined??? > > Since, if there is no significant amount left between the lsa flushing and > new hello without neighbor id, then the entire system will be in bad > condition. > > Thanks, > Kamatchi. > > >>Thanks, >>Acee >> >> >>>Thanks in advance, >>>Kamatchi. >>> >> >> >>-- >>Acee >> > > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 8 22:23:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19511 for ; Tue, 8 Jul 2003 22:23:58 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00A5939A@cherry.ease.lsoft.com>; Tue, 8 Jul 2003 22:23:57 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47844139 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 8 Jul 2003 22:23:56 -0400 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Jul 2003 22:23:56 -0400 Received: from smirtoraw2k03 (sjc-vpn3-144.cisco.com [10.21.64.144]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h692NsT02268 for ; Tue, 8 Jul 2003 19:23:54 -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, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <000001c345c1$24ce2440$f2ce7243@amer.cisco.com> Date: Tue, 8 Jul 2003 19:23:53 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Acee Thanks for the input, please see in line -> ->Sina, Quaizar, -> ->I've thought about this and I don't think one can say one ->approach is better than the other in all cases. Here are my thoughts: -> -> - The multiple address family approach will be more efficient -> when multiple address families are required and the topologies -> overlap (i.e., the same set of links will be used for multiple -> topologies). Yes, the more overlap you have the more would be the gain however in any case even if all topology has no links in common the multiple address family can not be worse than multiple instance id since your LSA header is still common between AF in multiple address family and without even talking about adjacency gain -> -> - The multiple instance approach will be more efficient for -> topologies where multiple addresses families are not -> required (let's not forget that an extra address family layer is -> also going cost memory and CPU). If you use any other AF than IPv6 then multiple instance can not be more efficient even in an extreme case where all topology are completely different If you use only IPv6 AF then there may be some memory / cpu as you indicated for AF layer however we are comparing multiple AF with multiple instance ID as the solution to _multiple_ AF therefore this cannot be counted as an advantage if any -> -> - As for which is better operationally, I think this is more a -> matter of implemenation than approach. I disagree that ->the multiple -> address family approach is obviously better. In fact, ->in some ways -> having a separate link state database per address family may be -> easier to debug. With either approach, one can misconfigure -> something and I don't see that as major issue. It would be great -> to get a carrier's perspective here. ok let's don't count this as advantage/disadvantage -> -> - The multiple address family approach has precedence in BGP and -> M-ISIS where people configure things by address family. ->It appears -> to me that to do it right in OSPFv3 lots of things ->(link costs, ranges, -> redistribution, default origination, et al) have to be ->configured -> at the address family level rather than the interface, area, or -> instance level. Yes, for multiple address family approach, every thing you mentioned will be part of AF and one need simply to indicates which link participate in which AF for instance ID, we are going away from BGP and ISIS concept of address-family and the common configuration, rather we are associating the instance ID with a given AF which will be a new concept for the operator -> -> - The multiple instance approach has the advantage of not ->requiring -> as much new invention (as Quaizar pointed out). The ->separation of -> link state databases and configuration is already there ->(since it -> each address family has a separate instance). However, ->it will still -> require new invention if other address families are to ->be carried (e.g., -> IPv4). Well the extra new invention is actually two new LSAs which are common to all AF. As for introducing other LSAs ( for both multiple AF and multiple instance) this can be avoided as much as possible We published a draft ( which I guess was not announce on the alias ) for multicast AF without introducing any new LSAs http://www.ietf.org/internet-drafts/draft-mirtorabi-ospfv3-multicast-af- 00.txt The same concepts can be used for IPv4 as the length of the prefix are identified in prefix length Thanks Sina -> ->Thanks, ->Acee -> ->Sina Mirtorabi wrote: ->> Quaizar, ->> ->> I will avoid going through an endless discussion regarding SIN and ->> integrated approach optimization ->> ->> Four comments though ->> ->> 1) ->> An integrated approach optimize the CPU usage, memory and network ->> bandwidth utilization which apparently is not your concerns. ->> ->> 2) ->> It is interesting how you make a believe that Integrated IS-IS is ->> close to SIN instance ID rather than our proposal. If ISIS had to ->> implement different instance (or using different process) for ->> different AF then how would you compare it to SIN? ->> ->> The fact that you are having more information to transport ->which is a ->> _result_ of adding AF is irrelevant to the rapprochement ->that you are ->> making between ISIS and SIN instance ID of OSPFv3. ->> ->> 3) ->> Any optimization can lead to some degree of code ->complexity, M-ISIS ->> is a good example of it. ->> ->> Defining and processing two new LSA does not look complex to me, as ->> far LG election, it is pretty close to DR election algorithm but if ->> that bothers you that much there are other ways to fix it ( forcing ->> the router that is AF capable to become DR either manually or the ->> router can declare itself DR and win DR election ) ->> ->> 4) ->> It is not sufficient to have separate instance ID, if a router does ->> not understand the reserved value for a AF but has the _same_ ->> instance-ID ( router downgraded etc ) then how you make ->sure that the ->> path is not through this router ? ->> ->> ->> Sina ->> -> -> ->-- ->Acee -> From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 9 10:29:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02800 for ; Wed, 9 Jul 2003 10:29:29 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00A5B0E9@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 10:29:23 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47906434 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 10:29:22 -0400 Received: from 64.102.124.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 10:29:21 -0400 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h69ETJfq008632 for ; Wed, 9 Jul 2003 10:29:20 -0400 (EDT) Received: from sj-dial-4-102.cisco.com (sj-dial-4-102.cisco.com [10.19.235.230]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA12734 for ; Wed, 9 Jul 2003 10:29:18 -0400 (EDT) X-X-Sender: ruwhite@rwlaptop.local References: <000001c33a02$bb6d1660$f2ce7243@amer.cisco.com> <3F0B1149.7080303@redback.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 9 Jul 2003 10:29:26 -0400 Reply-To: Mailing List Sender: Mailing List From: Russ White Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F0B1149.7080303@redback.com> Precedence: list > - The multiple instance approach has the advantage of not requiring > as much new invention (as Quaizar pointed out). The separation of > link state databases and configuration is already there (since it > each address family has a separate instance). However, it will still > require new invention if other address families are to be carried (e.g., > IPv4). I think this is the strongest argument for address families--the seperate instance approach is going to require you to either: -- create a new version of ospf, and run a seperate instance, finding some way to only exchange that information relevant to the right ospf instance on each neighbor through some means, for wach type of information you'd like to carry -- create new tlv's/ways of carrying information (address families) within the data structures so you can carry then information in a way that it can be sorted out correctly For instance, if you have two routers: A----B Suppose you want to carry ipv6, foo, and ipv4 between these routers. This would mean creating three different versions of ospf for these functions, out of which you can distinguish, in some way, what sort of information a specific peer is going to be passing, along with specific tlv's, etc. If, as in the case of multicast, the information is actually in the same format, you need to arbitrarily change the data format just to differentiate it. So, what you have is address families, anyway. You could argue that ospfv2 and ospfv3 are actually address families as it is, just over different peering sessions. So, it seems to me the question comes down to: "address families over a single adjacency, or address families over independant adjacencies?" The answer to that question seems very clear--address families over a single adjacency is much easier to implement, much easier to configure and maintain, and much more flexible. You're not going to get away from "inventing" new packet formats for each type of data you want to carry, sometimes with arbitrary changes just to differentiate the data type. Why not make the arbitrary change an address family field, and be done with it? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 9 11:57:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07159 for ; Wed, 9 Jul 2003 11:57:03 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00A5B355@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 11:57:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47913076 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 11:57:00 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 11:57:00 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id C78D07EF3F1 for ; Wed, 9 Jul 2003 08:56:25 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000001c33a02$bb6d1660$f2ce7243@amer.cisco.com> <3F0B1149.7080303@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F0C3B2C.5060608@redback.com> Date: Wed, 9 Jul 2003 11:56:28 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Russ, See inline. Russ White wrote: >> - The multiple instance approach has the advantage of not requiring >> as much new invention (as Quaizar pointed out). The separation of >> link state databases and configuration is already there (since it >> each address family has a separate instance). However, it will still >> require new invention if other address families are to be carried (e.g., >> IPv4). > > > I think this is the strongest argument for address families--the seperate > instance approach is going to require you to either: > > -- create a new version of ospf, and run a seperate instance, finding some > way to only exchange that information relevant to the right ospf instance > on each neighbor through some means, for wach type of information you'd > like to carry One thing you are missing is that OSPFv3 already has an instance ID in all the packets that could be used for this. Also all widely deployed OSPF implementations support multiple instances (I'm not sure about OSPFv3 implementations but I'd expect the same). > > -- create new tlv's/ways of carrying information (address families) within > the data structures so you can carry then information in a way that it can > be sorted out correctly > > For instance, if you have two routers: > > A----B > > Suppose you want to carry ipv6, foo, and ipv4 between these routers. This > would mean creating three different versions of ospf for these functions, > out of which you can distinguish, in some way, what sort of information a > specific peer is going to be passing, along with specific tlv's, etc. If, > as in the case of multicast, the information is actually in the same > format, you need to arbitrarily change the data format just to > differentiate it. > > So, what you have is address families, anyway. You could argue that ospfv2 > and ospfv3 are actually address families as it is, just over different > peering sessions. > > So, it seems to me the question comes down to: "address families over a > single adjacency, or address families over independant adjacencies?" The > answer to that question seems very clear--address families over a single > adjacency is much easier to implement, much easier to configure and > maintain, and much more flexible. I'm not sure I'd jump to the same conclusions. Assuming your OSPFv3 implementation supports multiple instances you're adding another level of hierachy to it. This adds an extra level of data structures, et al, to your implementation. As for configuration and maintenance, I'd say this is more influenced by how well the CLI, etc, is implemeneted than the difference between these two approaches. A big question here is "What percentage of OSPFv3 deployments will eventually require multiple AFs?" The higher the percentage, the more multiple AFs makes sense. > > You're not going to get away from "inventing" new packet formats for each > type of data you want to carry, sometimes with arbitrary changes just to > differentiate the data type. Why not make the arbitrary change an address > family field, and be done with it? For address families other than IPv6, you definitely need new LSAs with either approach. Unless we go to OSPFv4, I don't think we can add an address family/len field every place it is needed in the LSA formats (maybe we could leave out virtual links this time :^) > > :-) > > Russ > > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 9 12:43:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09235 for ; Wed, 9 Jul 2003 12:43:08 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00A5B365@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 12:43:10 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47916379 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 12:43:09 -0400 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 12:43:09 -0400 Received: from smirtoraw2k03 (sjc-vpn2-442.cisco.com [10.21.113.186]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h69Gh8T25375 for ; Wed, 9 Jul 2003 09:43:08 -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, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Message-ID: <000a01c34639$2d345370$f2ce7243@amer.cisco.com> Date: Wed, 9 Jul 2003 09:43:07 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F0C3B2C.5060608@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Acee ->A big question here is "What percentage of OSPFv3 deployments ->will eventually require multiple AFs?" The higher the ->percentage, the more multiple AFs makes sense. Although one could argue for the need of carrying IPv4 in OSPFv3 (which eventually I believe customers will ask for it) but multicast IPv6 AF is a good example of the need for multiple AF We are comparing two solutions for _multiple_ address-family ( multiple means any additional AF to unicast IPv6) in OSPFv3 and we know which one is more efficient, now if we do not want to use address-family at all (and keep only unicast IPv6) then there is nothing to compare The fact of not using AF cannot be counted an advantage for multiple instance-id as the solution to AF in OSPFv3 thanks Sina From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 9 13:32:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11319 for ; Wed, 9 Jul 2003 13:32:41 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00A5B4C9@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 13:32:42 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47919609 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 13:32:41 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 13:32:41 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id C13C164C5C5 for ; Wed, 9 Jul 2003 10:32:39 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000a01c34639$2d345370$f2ce7243@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F0C51B9.3080306@redback.com> Date: Wed, 9 Jul 2003 13:32:41 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sina, Sina Mirtorabi wrote: > Acee > > ->A big question here is "What percentage of OSPFv3 deployments > ->will eventually require multiple AFs?" The higher the > ->percentage, the more multiple AFs makes sense. > > Although one could argue for the need of carrying IPv4 in OSPFv3 (which > eventually I believe customers will ask for it) but multicast IPv6 AF > is a good example of the need for multiple AF > > We are comparing two solutions for _multiple_ address-family ( multiple > means any additional AF to unicast IPv6) in OSPFv3 and we know which one > is more efficient, now if we do not want to use address-family at all > (and keep only unicast IPv6) then there is nothing to compare > > The fact of not using AF cannot be counted an advantage for multiple > instance-id as the solution to AF in OSPFv3 Sina, I disagree with you here. Adding a new layer for AF to OSPFv3 requires more base protocol changes as well as the attendant implementation costs and overhead. Any unbiased evaluation has to take this into consideration. Thanks, Acee > > thanks > Sina > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 9 14:10:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12594 for ; Wed, 9 Jul 2003 14:10:42 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A5B733@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 14:10:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47935441 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 14:10:40 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 14:10:39 -0400 Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h69IAdu07058 for ; Wed, 9 Jul 2003 11:10:39 -0700 (PDT) (envelope-from qv@juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h69IAdb95165; Wed, 9 Jul 2003 11:10:39 -0700 (PDT) (envelope-from qv) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <000a01c34639$2d345370$f2ce7243@amer.cisco.com> <3F0C51B9.3080306@redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200307091810.h69IAdb95165@fuinar.juniper.net> Date: Wed, 9 Jul 2003 11:10:39 -0700 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F0C51B9.3080306@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Sina, I very much agree with Acee here. Optimization at the cost of implementation overhead is justified when the optimization results in significant performance gains. The gain with AF approach is less than O(2), in fact much less in almost all cases. Quaizar > Sina, > > Sina Mirtorabi wrote: > > Acee > > > > ->A big question here is "What percentage of OSPFv3 deployments > > ->will eventually require multiple AFs?" The higher the > > ->percentage, the more multiple AFs makes sense. > > > > Although one could argue for the need of carrying IPv4 in OSPFv3 (which > > eventually I believe customers will ask for it) but multicast IPv6 AF > > is a good example of the need for multiple AF > > > > We are comparing two solutions for _multiple_ address-family ( multiple > > means any additional AF to unicast IPv6) in OSPFv3 and we know which one > > is more efficient, now if we do not want to use address-family at all > > (and keep only unicast IPv6) then there is nothing to compare > > > > The fact of not using AF cannot be counted an advantage for multiple > > instance-id as the solution to AF in OSPFv3 > > Sina, > > I disagree with you here. Adding a new layer for AF to OSPFv3 requires > more base protocol changes as well as the attendant implementation > costs and overhead. Any unbiased evaluation has to take this into > consideration. > > Thanks, > Acee > > > > > thanks > > Sina > > > > > -- > Acee From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Wed Jul 9 15:28:40 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17016 for ; Wed, 9 Jul 2003 15:28:40 -0400 (EDT) Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A5B957@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 15:28:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47944350 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 15:28:38 -0400 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 15:28:38 -0400 Received: from smirtoraw2k03 (dhcp-171-69-101-56.cisco.com [171.69.101.56]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h69JSZT18965 for ; Wed, 9 Jul 2003 12:28:35 -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, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Message-ID: <000401c34650$4bfce9e0$386545ab@amer.cisco.com> Date: Wed, 9 Jul 2003 12:28:35 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F0C51B9.3080306@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Acee, ->> The fact of not using AF cannot be counted an advantage for ->multiple ->> instance-id as the solution to AF in OSPFv3 ->Sina, -> ->I disagree with you here. Adding a new layer for AF to OSPFv3 ->requires more base protocol changes as well as the attendant ->implementation costs and overhead. Any unbiased evaluation ->has to take this into consideration. If you do not need to have other AF, you can only have the minimum required in our proposal that is setting the AF bit in the Hello and v6-AF bit in the AdressFamilies field (Disabled mode) Once you want to have additional AF then you have to bother about the additional two new LSA and potentially other new LSAs in other AF (if needed) which even in case of multiple instance you would need to define ways to be backward compatibles, define new LSA for new AF etc Sina -> ->Thanks, ->Acee -> ->> ->> thanks ->> Sina ->> -> -> ->-- ->Acee -> From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 9 15:42:27 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17589 for ; Wed, 9 Jul 2003 15:42:26 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00A5BB3C@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 15:42:26 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47946510 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 15:42:05 -0400 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 15:42:05 -0400 Received: from smirtoraw2k03 (dhcp-171-69-101-56.cisco.com [171.69.101.56]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h69Jg1T25902 for ; Wed, 9 Jul 2003 12:42:01 -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, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Message-ID: <000501c34652$2b1c8da0$386545ab@amer.cisco.com> Date: Wed, 9 Jul 2003 12:42:02 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200307091810.h69IAdb95165@fuinar.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Quaizar -> ->Sina, -> ->I very much agree with Acee here. Optimization at the cost of ->implementation overhead is justified when the optimization ->results in significant performance gains. The gain with AF ->approach is less than O(2), in fact much less in almost all cases. I do not agree to "much less than O(2)" performance gain and let me get an example to clarify that Let's consider the following - a network participating in IPv6 unicast& multicast and IPv4 unicast & multicast - a worse case scenario where there is No overlap between any topologies - we would consider 1450 byte as the limit for generating new fragments for router LSA, prefix LSA - a router have in average 20 adj in each AF (so 80 adj in total as we considered no overlap) You could see that even in worse case scenario our proposal compared to the multiple instance has a Gain O(4) for each Router LSA Gain O(4) for each network LSA Gain O(4) for each prefix LSA Gain O(4) for each link lsa You could see that we are far away from "much less than O(2)" Sina From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 9 16:02:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19197 for ; Wed, 9 Jul 2003 16:02:07 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00A5BCDA@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 16:02:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47947316 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 16:02:04 -0400 Received: from 64.4.9.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 15:52:04 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 9 Jul 2003 12:52:03 -0700 Received: from 202.71.137.194 by lw9fd.law9.hotmail.msn.com with HTTP; Wed, 09 Jul 2003 19:52:03 GMT X-Originating-IP: [202.71.137.194] X-Originating-Email: [dhavalgada@hotmail.com] Mime-Version: 1.0 Content-Type: text/html X-OriginalArrivalTime: 09 Jul 2003 19:52:03.0938 (UTC) FILETIME=[91D4D420:01C34653] Message-ID: Date: Thu, 10 Jul 2003 01:22:03 +0530 Reply-To: Mailing List Sender: Mailing List From: dhaval gada Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list

Please ,

  How do I unsubscribe from the group.



 

>From: Sina Mirtorabi
>Reply-To: Mailing List
>To: OSPF@PEACH.EASE.LSOFT.COM
>Subject: Re: Address Family Support in OSPFv3
>Date: Wed, 9 Jul 2003 12:28:35 -0700
>MIME-Version: 1.0
>Received: from cherry.ease.lsoft.com ([209.119.0.109]) by mc4-f40.law16.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 9 Jul 2003 12:49:49 -0700
>Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00A5BB3E@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 15:28:40 -0400
>Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47944350 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 15:28:38 -0400
>Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 15:28:38 -0400
>Received: from smirtoraw2k03 (dhcp-171-69-101-56.cisco.com [171.69.101.56]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h69JSZT18965 for ; Wed, 9 Jul 2003 12:28:35 -0700 (PDT)
>X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP
>X-Priority: 3 (Normal)
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook, Build 10.0.4024
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
>Importance: Normal
>Message-ID: <000401c34650$4bfce9e0$386545ab@amer.cisco.com>
>Sender: Mailing List
>In-Reply-To: <3F0C51B9.3080306@redback.com>
>Precedence: list
>Return-Path: owner-ospf@PEACH.EASE.LSOFT.COM
>X-OriginalArrivalTime: 09 Jul 2003 19:49:51.0109 (UTC) FILETIME=[42A8BB50:01C34653]
>
>Acee,
>
>->> The fact of not using AF cannot be counted an advantage for
>->multiple
>->> instance-id as the solution to AF in OSPFv3
>
>->Sina,
>->
>->I disagree with you here. Adding a new layer for AF to OSPFv3
>->requires more base protocol changes as well as the attendant
>->implementation costs and overhead. Any unbiased evaluation
>->has to take this into consideration.
>
>If you do not need to have other AF, you can only have the minimum
>required in our proposal that is setting the AF bit in the Hello and
>v6-AF bit in the AdressFamilies field (Disabled mode)
>
>Once you want to have additional AF then you have to bother about the
>additional two new LSA and potentially other new LSAs in other AF (if
>needed) which even in case of multiple instance you would need to define
>ways to be backward compatibles, define new LSA for new AF etc
>
>Sina
>
>
>->
>->Thanks,
>->Acee
>->
>->>
>->> thanks
>->> Sina
>->>
>->
>->
>->--
>->Acee
>->

Watch Hallmark. Enjoy cool movies. Win hot prizes! From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 9 16:07:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19603 for ; Wed, 9 Jul 2003 16:07:19 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A5BD07@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 16:07:16 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47949424 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 16:06:56 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 16:06:56 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 8AF0D7E0193 for ; Wed, 9 Jul 2003 13:05:00 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000401c34650$4bfce9e0$386545ab@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F0C756D.6000308@redback.com> Date: Wed, 9 Jul 2003 16:05:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sina Mirtorabi wrote: > Acee, > > ->> The fact of not using AF cannot be counted an advantage for > ->multiple > ->> instance-id as the solution to AF in OSPFv3 > > ->Sina, > -> > ->I disagree with you here. Adding a new layer for AF to OSPFv3 > ->requires more base protocol changes as well as the attendant > ->implementation costs and overhead. Any unbiased evaluation > ->has to take this into consideration. > > If you do not need to have other AF, you can only have the minimum > required in our proposal that is setting the AF bit in the Hello and > v6-AF bit in the AdressFamilies field (Disabled mode) > > Once you want to have additional AF then you have to bother about the > additional two new LSA and potentially other new LSAs in other AF (if > needed) which even in case of multiple instance you would need to define > ways to be backward compatibles, define new LSA for new AF etc Sina, Let me try and be more clear - What I'm saying is that with multiple instances you already have the separation between the topologies without any protocol changes or an additional AF layer in your implementation. For example, to support the OSPFv3 IPv6 multicast topology with the multi-AF approach one must implement the two drafts you've posted plus deal with all the issues related to the AF layer in configuration and management (i.e., show commands, etc). To do it with multiple instances, all you have to do is configure the address family and default OSPFv3 interface ID at the instance level. I haven't thought about this at great depth but on the surface I can't see why it wouldn't work. There will be no protocol changes and I'll submit to you that the implementation cost is less. At this point, I'm not saying that one approach is obviously better or trying to precisely quantify the relative efficiencies when multiple AFs are used. All I'm saying is that you can't completely discount the associated costs. Thanks, Acee > Sina > > > -> > ->Thanks, > ->Acee > -> > ->> > ->> thanks > ->> Sina > ->> > -> > -> > ->-- > ->Acee > -> > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 9 18:48:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27611 for ; Wed, 9 Jul 2003 18:48:47 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00A5CA4A@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 18:48:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47960741 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 18:48:46 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 18:48:46 -0400 Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h69Mmju33365 for ; Wed, 9 Jul 2003 15:48:45 -0700 (PDT) (envelope-from qv@juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h69Mmjp95707; Wed, 9 Jul 2003 15:48:45 -0700 (PDT) (envelope-from qv) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200307091810.h69IAdb95165@fuinar.juniper.net> <000501c34652$2b1c8da0$386545ab@amer.cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200307092248.h69Mmjp95707@fuinar.juniper.net> Date: Wed, 9 Jul 2003 15:48:45 -0700 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000501c34652$2b1c8da0$386545ab@amer.cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Sina, The example you take picks a small number of adjs. If you go to a larger number of adjs, you will run into logical fragmentation. And once the total adjs grow over 4 logical fragments, the AF approach and SIN approach will result in the same number of LSA fragments. I concede the fact that you could have a large network where each router has only a small number of adjs. Then the gain you mention works. But I doubt that anyone will run IPv4 unicast using OSPFv3 for a very long time. As far as total memory is concerned, both approaches would turn out to be quite equivalent in any topology if the metric values are different across all AFs. Sharing router LSA links for multiple AFs will be painful from the implementation point of view. Also with prefix LSAs you can't share the prefixes between v4 and v6 simply because they are different. So the gain is O(3) even in the best case. Big deal :). This is true whether you talk about the amount of memory or amount of LSAs. I feel that most implementations of the AF approach will end up choosing not to implement overlapping router LSA links for multiple AFs, simply because of the implementation complexity. So you will end up with any gain only in terms of the number of LSAs (not in total memory). Even the later doesn't work if routers have large number of adjacencies. Not worth all the implementation pain :). Quaizar > Quaizar > > -> > ->Sina, > -> > ->I very much agree with Acee here. Optimization at the cost of > ->implementation overhead is justified when the optimization > ->results in significant performance gains. The gain with AF > ->approach is less than O(2), in fact much less in almost all cases. > > I do not agree to "much less than O(2)" performance gain and let me get > an example to clarify that > > Let's consider the following > > - a network participating in IPv6 unicast& multicast and IPv4 unicast & > multicast > - a worse case scenario where there is No overlap between any topologies > - we would consider 1450 byte as the limit for generating new fragments > for router LSA, prefix LSA > - a router have in average 20 adj in each AF (so 80 adj in total as we > considered no overlap) > > You could see that even in worse case scenario our proposal compared to > the multiple instance has a > > Gain O(4) for each Router LSA > Gain O(4) for each network LSA > Gain O(4) for each prefix LSA > Gain O(4) for each link lsa > > You could see that we are far away from "much less than O(2)" > > Sina From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 9 19:55:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29604 for ; Wed, 9 Jul 2003 19:55:46 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A5CAE7@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 19:55:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47964747 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 19:55:44 -0400 Received: from 64.102.124.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 19:55:44 -0400 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h69Ntffq015191 for ; Wed, 9 Jul 2003 19:55:42 -0400 (EDT) Received: from [10.10.2.239] (rtp-vpn2-471.cisco.com [10.82.241.215]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA19073 for ; Wed, 9 Jul 2003 19:55:41 -0400 (EDT) X-X-Sender: ruwhite@rwlaptop.local References: <000401c34650$4bfce9e0$386545ab@amer.cisco.com> <3F0C756D.6000308@redback.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 9 Jul 2003 19:55:50 -0400 Reply-To: Mailing List Sender: Mailing List From: Russ White Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F0C756D.6000308@redback.com> Precedence: list > For example, to support the OSPFv3 IPv6 multicast topology with the > multi-AF approach one must implement the two drafts you've posted plus > deal with all the issues related to the AF layer in configuration and > management (i.e., show commands, etc). To do it with multiple instances, > all you have to do is configure the address family and default OSPFv3 > interface ID at the instance level. I haven't thought about this at great > depth but on the surface I can't see why it wouldn't work. There will be > no protocol changes and I'll submit to you that the implementation cost > is less. > > At this point, I'm not saying that one approach is obviously better or > trying to precisely quantify the relative efficiencies when multiple AFs > are used. All I'm saying is that you can't completely discount the > associated costs. But, if you are carrying something which doesn't necessarily fit into the ipv6 address format, then you need the new instance, and the new tlv's anyway, correct? So, you've now gained the additional complexity on all sides, and gained nothing, it seems to me. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 9 20:37:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00954 for ; Wed, 9 Jul 2003 20:37:48 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00A5CC14@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 20:37:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47968742 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 20:37:47 -0400 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 20:37:47 -0400 Received: from smirtoraw2k03 (sjc-vpn3-59.cisco.com [10.21.64.59]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h6A0biT12267 for ; Wed, 9 Jul 2003 17:37: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, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Message-ID: <000301c3467b$7b4ad790$f2ce7243@amer.cisco.com> Date: Wed, 9 Jul 2003 17:37:44 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200307092248.h69Mmjp95707@fuinar.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Quaizar -> ->Sina, -> ->The example you take picks a small number of adjs. Humm, 80 adj per router is small :) ->If you go ->to a larger number of adjs, you will run into logical ->fragmentation. And once the total adjs grow over 4 logical ->fragments, the AF approach and SIN approach will result in ->the same number of LSA fragments. Do not forget that 20 adj per AF was the worse case scenario which is no link overlap between any AF, if you have some overlap you could grow your number of adj for each AF ( up to a ideal case of 90 ) and still can fit into a single fragment -> ->I concede the fact that you could have a large network ->where each router has only a small number of adjs. Then ->the gain you mention works. Good ;-) I will still argue for the word small adj in a normal case which will have overlap ->But I doubt that anyone ->will run IPv4 unicast using OSPFv3 for a very long time. Well there is no fact to justify that ->As far as total memory is concerned, both approaches would ->turn out to be quite equivalent in any topology if the ->metric values are different across all AFs. Sharing router ->LSA links for multiple AFs will be painful from the ->implementation point of view. But the metric value is not necessarily different, you could have simply incongruent topology. for example if your ocX link cost is C why would you want to change it ? So I do not agree that the amount of memory are the same further do not forget that you have also additional memory to keep for each area data structure, adj etc in case of multiple instance -> ->Also with prefix LSAs you can't share the prefixes between v4 ->and v6 simply because they are different. Why not ? The prefix carry a prefix length so you can code IPv4 in the existing LSAs -> ->So the gain is O(3) even in the best case. Big deal :). Good so we went from "much less than O(2)" to O(3) ;-) ->This ->is true whether you talk about the amount of memory or amount ->of LSAs. I feel that most implementations of the AF approach ->will end up choosing not to implement overlapping router LSA ->links for multiple AFs, simply because of the implementation ->complexity. Well let's the implementations choose but I do not see why you are making the proposal to look so complex If there are some part that you consider complex we are open to suggestions to optimize ->So you will end up with any gain only in terms of ->the number of LSAs (not in total memory). In terms if number of LSA , memory, flooding and adjacency -> Even the later ->doesn't work if routers have large number of adjacencies. 50-80 adj is pretty a good number for the average number of adj, in fact in most of the case ( except hub and spoke) you won't even have that many -> ->Not worth all the implementation pain :). If we talk about other AF than IPv6 then you would have some of the same pain in multiple instance id further if you have ospfv2 today and you want to add V3 you know that it will require more resources, the same apply here for adding 2/3 other AF to OSPFv3. Let's focus on the customer and optimize their cost rather than the extra implementations cost ( although still I do not believe there is a big difference between multiple AF and multiple instance complexity if we count the whole sets of AF and not only multicast IPv6 AF addition) Thanks Sina From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 9 23:38:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03845 for ; Wed, 9 Jul 2003 23:38:18 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00A5D311@cherry.ease.lsoft.com>; Wed, 9 Jul 2003 23:38:17 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47984216 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 9 Jul 2003 23:38:15 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Jul 2003 23:38:14 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 91DD56B8007 for ; Wed, 9 Jul 2003 20:37:00 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000401c34650$4bfce9e0$386545ab@amer.cisco.com> <3F0C756D.6000308@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F0CDF59.3050301@redback.com> Date: Wed, 9 Jul 2003 23:36:57 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Russ White wrote: >>For example, to support the OSPFv3 IPv6 multicast topology with the >>multi-AF approach one must implement the two drafts you've posted plus >>deal with all the issues related to the AF layer in configuration and >>management (i.e., show commands, etc). To do it with multiple instances, >>all you have to do is configure the address family and default OSPFv3 >>interface ID at the instance level. I haven't thought about this at great >>depth but on the surface I can't see why it wouldn't work. There will be >>no protocol changes and I'll submit to you that the implementation cost >>is less. >> >>At this point, I'm not saying that one approach is obviously better or >>trying to precisely quantify the relative efficiencies when multiple AFs >>are used. All I'm saying is that you can't completely discount the >>associated costs. > > > But, if you are carrying something which doesn't necessarily fit into the > ipv6 address format, then you need the new instance, and the new tlv's > anyway, correct? New LSA types will be required to advertise addresses for new address families independent of the approach. > So, you've now gained the additional complexity on all > sides, and gained nothing, it seems to me. I'm not sure how get to this conclusion - the processing of the new LSA types is an incremental cost on top of either approach. > > :-) > > Russ > > __________________________________ > riw@cisco.com CCIE <>< Grace Alone > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 10 14:36:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15880 for ; Thu, 10 Jul 2003 14:36:28 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00A5F548@cherry.ease.lsoft.com>; Thu, 10 Jul 2003 14:36:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48071531 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 10 Jul 2003 14:36:27 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Jul 2003 14:36:27 -0400 Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6AIaQu98457 for ; Thu, 10 Jul 2003 11:36:26 -0700 (PDT) (envelope-from qv@juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h6AIaP398030; Thu, 10 Jul 2003 11:36:25 -0700 (PDT) (envelope-from qv) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <200307092248.h69Mmjp95707@fuinar.juniper.net> <000301c3467b$7b4ad790$f2ce7243@amer.cisco.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200307101836.h6AIaP398030@fuinar.juniper.net> Date: Thu, 10 Jul 2003 11:36:25 -0700 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000301c3467b$7b4ad790$f2ce7243@amer.cisco.com> Precedence: list Content-Transfer-Encoding: 7bit Sina Mirtorabi writes: > > ->As far as total memory is concerned, both approaches would > ->turn out to be quite equivalent in any topology if the > ->metric values are different across all AFs. Sharing router > ->LSA links for multiple AFs will be painful from the > ->implementation point of view. > > But the metric value is not necessarily different, you could have simply > incongruent topology. > for example if your ocX link cost is C why would you want to change it ? > > > So I do not agree that the amount of memory are the same further do not > forget that you have also additional memory to keep for each area data > structure, adj etc in case of multiple instance But then one would go to the extent of running OSPF for multiple AFs only if there is some significant distinction in the topology for each AF, so then you loose some of the gain. > > -> > ->Also with prefix LSAs you can't share the prefixes between v4 > ->and v6 simply because they are different. > > Why not ? The prefix carry a prefix length so you can code IPv4 in the > existing LSAs Yes, I understand that. My point was that you can't share the prefixes as you could share router LSA links. Yes you can put them in the same LSA but your LSA would grow larger. > > -> > ->So the gain is O(3) even in the best case. Big deal :). > > Good so we went from "much less than O(2)" to O(3) ;-) Note the use of "BEST CASE" above. > > ->This > ->is true whether you talk about the amount of memory or amount > ->of LSAs. I feel that most implementations of the AF approach > ->will end up choosing not to implement overlapping router LSA > ->links for multiple AFs, simply because of the implementation > ->complexity. > > Well let's the implementations choose but I do not see why you are > making the proposal to look so complex > If there are some part that you consider complex we are open to > suggestions to optimize > > ->So you will end up with any gain only in terms of > ->the number of LSAs (not in total memory). > > In terms if number of LSA , memory, flooding and adjacency > > -> Even the later > ->doesn't work if routers have large number of adjacencies. > > 50-80 adj is pretty a good number for the average number of adj, in fact > in most of the case ( except hub and spoke) you won't even have that > many > > -> > ->Not worth all the implementation pain :). > > If we talk about other AF than IPv6 then you would have some of the same > pain in multiple instance id No, there is very little change required in implementation as all you would have to do is set a different set of bits in the prefix options, and the right instance-id in the packet header. > > further if you have ospfv2 today and you want to add V3 you know that it > will require more resources, the same apply here for adding 2/3 other AF > to OSPFv3. > > Let's focus on the customer and optimize their cost rather than the > extra implementations cost ( although still I do not believe there is a > big difference between multiple AF and multiple instance complexity if > we count the whole sets of AF and not only multicast IPv6 AF > addition) Let the customer decide on the tradeoff between implementation and maintanence complexity versus efficiency. Thanks, Quaizar > > Thanks > Sina From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 10 14:41:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16016 for ; Thu, 10 Jul 2003 14:41:09 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00A5F556@cherry.ease.lsoft.com>; Thu, 10 Jul 2003 14:41:11 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48072059 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 10 Jul 2003 14:41:10 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Jul 2003 14:41:09 -0400 Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6AIf9u98851 for ; Thu, 10 Jul 2003 11:41:09 -0700 (PDT) (envelope-from qv@juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h6AIf9I98046; Thu, 10 Jul 2003 11:41:09 -0700 (PDT) (envelope-from qv) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <000401c34650$4bfce9e0$386545ab@amer.cisco.com> <3F0C756D.6000308@redback.com> <3F0CDF59.3050301@redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200307101841.h6AIf9I98046@fuinar.juniper.net> Date: Thu, 10 Jul 2003 11:41:09 -0700 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F0CDF59.3050301@redback.com> Precedence: list Content-Transfer-Encoding: 7bit > > But, if you are carrying something which doesn't necessarily fit into the > > ipv6 address format, then you need the new instance, and the new tlv's > > anyway, correct? > > New LSA types will be required to advertise addresses for new address > families independent of the approach. I don't think we would even require new LSA types. The prefix encoding as it stands currently is fairly flexible. I doubt that you would even require extra bits in the prefix options. The clearing of NU bit and the indication of the AF from the instance-id is sufficient to tell you which AF the prefix belongs to. > > > So, you've now gained the additional complexity on all > > sides, and gained nothing, it seems to me. > > I'm not sure how get to this conclusion - the processing of the new LSA > types is an incremental cost on top of either approach. > > > > > :-) > > > > Russ > > > > __________________________________ > > riw@cisco.com CCIE <>< Grace Alone > > > > > -- > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 10 14:56:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16322 for ; Thu, 10 Jul 2003 14:56:02 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A5F4EA@cherry.ease.lsoft.com>; Thu, 10 Jul 2003 14:56:03 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48072657 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 10 Jul 2003 14:56:03 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Jul 2003 14:56:02 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 63028A7EEE5 for ; Thu, 10 Jul 2003 11:55:34 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000401c34650$4bfce9e0$386545ab@amer.cisco.com> <3F0C756D.6000308@redback.com> <3F0CDF59.3050301@redback.com> <200307101841.h6AIf9I98046@fuinar.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F0DB69A.2060706@redback.com> Date: Thu, 10 Jul 2003 14:55:22 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Quaizar Vohra wrote: > > > But, if you are carrying something which doesn't necessarily fit into the > > > ipv6 address format, then you need the new instance, and the new tlv's > > > anyway, correct? > > > > New LSA types will be required to advertise addresses for new address > > families independent of the approach. > > I don't think we would even require new LSA types. The prefix encoding > as it stands currently is fairly flexible. I doubt that you would even > require extra bits in the prefix options. The clearing of NU bit > and the indication of the AF from the instance-id is sufficient to > tell you which AF the prefix belongs to. I haven't thought about it in great depth. I guess if you use solely address family foo prefixes for a address family foo instance it might be possible. > > > > > > > So, you've now gained the additional complexity on all > > > sides, and gained nothing, it seems to me. > > > > I'm not sure how get to this conclusion - the processing of the new LSA > > types is an incremental cost on top of either approach. > > > > > > > > :-) > > > > > > Russ > > > > > > __________________________________ > > > riw@cisco.com CCIE <>< Grace Alone > > > > > > > > > -- > > Acee > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 10 17:53:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23522 for ; Thu, 10 Jul 2003 17:53:30 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00A60A12@cherry.ease.lsoft.com>; Thu, 10 Jul 2003 17:53:30 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48082738 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 10 Jul 2003 17:31:35 -0400 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Jul 2003 17:31:35 -0400 Received: from smirtoraw2k03 (dhcp-171-69-101-56.cisco.com [171.69.101.56]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h6ALVXT10938 for ; Thu, 10 Jul 2003 14:31:33 -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, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <000301c3472a$a22e2ec0$386545ab@amer.cisco.com> Date: Thu, 10 Jul 2003 14:31:33 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200307101836.h6AIaP398030@fuinar.juniper.net> Precedence: list Content-Transfer-Encoding: 7bit Quaizir, ->Let the customer decide on the tradeoff between ->implementation and maintenance complexity versus efficiency. I guess we agree on the fact that - an integrated approach has the advantage of efficiency and optimize number of LSA, memory, flooding, adjacency - instance id approach has the advantage of implementation simplicity I will get the discussion further off line with you guys, I would like however to hear from customers and operator for their preference Thanks Sina From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 10 19:40:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26921 for ; Thu, 10 Jul 2003 19:40:22 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00A60E15@cherry.ease.lsoft.com>; Thu, 10 Jul 2003 19:40:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48091946 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 10 Jul 2003 19:39:51 -0400 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Jul 2003 19:39:51 -0400 Received: from smirtoraw2k03 (sjc-vpn1-5.cisco.com [10.21.96.5]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h6ANdoT00213 for ; Thu, 10 Jul 2003 16:39:50 -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, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <001001c3473c$8ec3c3b0$386545ab@amer.cisco.com> Date: Thu, 10 Jul 2003 16:39:51 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Address Family Support in OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F0DB69A.2060706@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Acee, ->I haven't thought about it in great depth. I guess if you ->use solely address family foo prefixes for a address family ->foo instance it might be possible. Yes as I said previously, since a prefix carry prefix length no new LSA is required to define prefix information for other AF and this is true for either approach Sina From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 11 06:15:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23805 for ; Fri, 11 Jul 2003 06:15:48 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00A624DE@cherry.ease.lsoft.com>; Fri, 11 Jul 2003 6:15:49 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48160413 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 11 Jul 2003 06:15:47 -0400 Received: from 203.199.83.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Jul 2003 06:15:43 -0400 Received: (qmail 13529 invoked by uid 510); 11 Jul 2003 10:14:35 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 11 jul 2003 10:14:35 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030711101435.13528.qmail@webmail29.rediffmail.com> Date: Fri, 11 Jul 2003 10:14:35 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Area Aggregation To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, Is it valid to configure same address range and mask in multiple areas. say one router is connected to area 1, area 2, and backbone area can i configure Area Aggregation in area 1 and area 2 for same address range and mask. if yes then which area address range i should consider while generating summary lsa. regards Krishna ___________________________________________________ Click below to experience Sooraj R Barjatya's latest offering 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek & Kareena http://www.mpkdh.com From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 11 15:24:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12373 for ; Fri, 11 Jul 2003 15:24:25 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A647BF@cherry.ease.lsoft.com>; Fri, 11 Jul 2003 15:24:24 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48199101 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 11 Jul 2003 15:24:23 -0400 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Jul 2003 15:24:23 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h6BJpi112527 for ; Sat, 12 Jul 2003 01:21:44 +0530 Received: from apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with SMTP id h6BJpig12521 for ; Sat, 12 Jul 2003 01:21:44 +0530 Received: from 219.65.136.203 (SquirrelMail authenticated user alok.dube) by mail.apara.com with HTTP; Sat, 12 Jul 2003 01:21:44 +0530 (IST) X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <1731.219.65.136.203.1057953104.squirrel@mail.apara.com> Date: Sat, 12 Jul 2003 01:21:44 +0530 Reply-To: Mailing List Sender: Mailing List From: Alok Dube Subject: summary LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Hi, I have a question regarding the following topology, Router A connects to 2 ABRs, ABR-1 and ABR 2 and is in Area 1. Router B also connects to ABR-1 and ABR-2 and is in Area 2. my questions: 1. is there a problem with the above? 2. if the ABR is shared between multiple areas 1 & 2, can one send summary LSAs of routes in Area 1 into Area 2? I assume the "summarizartion configuration" is per area. 3. In general, is the summary LSA generated by the ABR of the area into which it is flooded and or by the ABR of the area which originates the LSA? If the former, isnt it better from a aggregation view point to do the former? -thanks Alok From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 11 15:49:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14207 for ; Fri, 11 Jul 2003 15:49:02 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A648C0@cherry.ease.lsoft.com>; Fri, 11 Jul 2003 15:48:53 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48201531 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 11 Jul 2003 15:48:48 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Jul 2003 15:48:44 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 3D75F9B8984 for ; Fri, 11 Jul 2003 12:48:43 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <1731.219.65.136.203.1057953104.squirrel@mail.apara.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F0F1481.1010301@redback.com> Date: Fri, 11 Jul 2003 15:48:17 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: summary LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Alok Dube wrote: > Hi, > > I have a question regarding the following topology, > > Router A connects to 2 ABRs, ABR-1 and ABR 2 and is in Area 1. > > Router B also connects to ABR-1 and ABR-2 and is in Area 2. > > my questions: > > 1. is there a problem with the above? No. > > 2. if the ABR is shared between multiple areas 1 & 2, can one send summary > LSAs of routes in Area 1 into Area 2? Yes but replace "can" with "must". > I assume the "summarizartion > configuration" is per area. Yes. > 3. In general, is the summary LSA generated by the ABR of the area into > which it is flooded and or by the ABR of the area which originates the > LSA? The summary for intra-area routes (or a range of routes) is always originated by the ABR connecting the area corresponding to the intra-area routes. For inter-area routes from the backbone areas, ABRs will originate a summary into non-backbone areas. This is all covered in RFC 2328 (although it is articulated much better). > If the former, isnt it better from a aggregation view point to do the > former? > -thanks > Alok > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 14 05:19:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03375 for ; Mon, 14 Jul 2003 05:19:25 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00A6B92B@cherry.ease.lsoft.com>; Mon, 14 Jul 2003 5:19:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48404599 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 14 Jul 2003 05:19:21 -0400 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Jul 2003 05:19:21 -0400 Received: (qmail 28803 invoked from network); 14 Jul 2003 09:19:20 -0000 Received: from bigbird.nj.us.utstar.com (172.16.36.21) by lxmail.nj.us.utstar.com with SMTP; 14 Jul 2003 09:19:20 -0000 Received: from utstar.com (localhost.localdomain [127.0.0.1]) by bigbird.nj.us.utstar.com (8.9.3/8.9.3) with ESMTP id FAA02838 for ; Mon, 14 Jul 2003 05:19:20 -0400 Message-ID: <200307140919.FAA02838@bigbird.nj.us.utstar.com> Date: Mon, 14 Jul 2003 05:19:20 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: updated agenda for vienna (ietf 57) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Sorry for the late post as a couple of messages came in very late. Shouldn't happen too often. --rohit. Tuesday July 15 (17:00 - 18:00) =============================== CHAIRS: Rohit Dube Acee Lindem AGENDA: Agenda Bashing 5 Mins IGP Capabilities 10 Mins Rahul Aggarwal OSPF TE Capability TLVs 10 Mins Jean Philippe Vasseur WG document status 10 Mins Chairs From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 14 13:32:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07165 for ; Mon, 14 Jul 2003 13:32:22 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00A6C8BE@cherry.ease.lsoft.com>; Mon, 14 Jul 2003 13:32:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48473652 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 14 Jul 2003 13:32:21 -0400 Received: from 64.4.15.94 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Jul 2003 13:22:21 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 Jul 2003 10:22:19 -0700 Received: from 4.17.144.62 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 14 Jul 2003 17:22:19 GMT X-Originating-IP: [4.17.144.62] X-Originating-Email: [hprao@hotmail.com] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 14 Jul 2003 17:22:19.0655 (UTC) FILETIME=[7AD8C970:01C34A2C] Message-ID: Date: Mon, 14 Jul 2003 17:22:19 +0000 Reply-To: Mailing List Sender: Mailing List From: Hariprasad Rao Subject: Separate Advertisements for every external LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, RFC 1583 section A.4.5 mentions that a separate advertisement is made for each destination which is external to the AS. But in later versions i.e RFC 2178 and RFC 2328 this line is left out. Does this mean that we can pack more than one external LSA in a LS update packet? What is the reason for having such a restriction in the first place? Would there be a backward compatibility problem if we pack more than one external LSA in a LS update packet? Thanks and Rgds, Hari _________________________________________________________________ Polyphonic ringtones. Latest movie trailors. http://server1.msn.co.in/sp03/gprs/index.asp On your mobile! From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jul 14 13:52:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08595 for ; Mon, 14 Jul 2003 13:52:06 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00A6C97B@cherry.ease.lsoft.com>; Mon, 14 Jul 2003 13:52:06 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48474679 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 14 Jul 2003 13:52:03 -0400 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Jul 2003 13:52:03 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00A6C7C6@cherry.ease.lsoft.com>; Mon, 14 Jul 2003 13:52:03 -0400 Message-ID: Date: Mon, 14 Jul 2003 13:52:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: Separate Advertisements for every external LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list In my humble opinion, RFC 1538 seems to restrict just the format of ASE LSA, not one of the LS Update packet. On Mon, 14 Jul 2003 17:22:19 +0000, Hariprasad Rao wrote: >Hi, > RFC 1583 section A.4.5 mentions that a separate advertisement is made for >each destination which is external to the AS. But in later versions i.e RFC >2178 and RFC 2328 this line is left out. > Does this mean that we can pack more than one external LSA in a LS update >packet? What is the reason for having such a restriction in the first place? >Would there be a backward compatibility problem if we pack more than one >external LSA in a LS update packet? >Thanks and Rgds, >Hari > >_________________________________________________________________ >Polyphonic ringtones. Latest movie trailors. >http://server1.msn.co.in/sp03/gprs/index.asp On your mobile! From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 15 11:49:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24939 for ; Tue, 15 Jul 2003 11:49:49 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00A6FE48@cherry.ease.lsoft.com>; Tue, 15 Jul 2003 11:49:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48345529 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 15 Jul 2003 11:49:50 -0400 Received: from 135.207.24.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 15 Jul 2003 11:49:50 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h6FG4jJh010263 for ; Tue, 15 Jul 2003 12:04:45 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h6FFnaXs023805 for ; Tue, 15 Jul 2003 11:49:37 -0400 (EDT) Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h6FFnhU29826; Tue, 15 Jul 2003 08:49:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Versions: dmail (solaris) 2.5a/makemail 2.9d Message-ID: <200307151549.h6FFnhU29826@windsor.research.att.com> Date: Tue, 15 Jul 2003 08:49:42 -0700 Reply-To: Mailing List Sender: Mailing List From: Bill Fenner Subject: Re: AD-review comments on draft-ietf-ospf-scalability To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Vishwas et al, Apologies for dropping the ball on coordinating with Alex -- I had some comments on this spec too. In the vein of other OSPF specifications, I'd like to see a list of variables and values as an appendix. I think this means K, Rmin, Rmax (in (3)), high water mark and low water mark (in (4)), and n (in (5)). In Appendix C section (2), I'd note that the TOS/Precedence bits have been redefined by Diffserv (RFC 2474). I'm not sure this matters too much, since this is only on a link so the actual values in use only need to be agreed among the systems on the link, but it might be better to refer to the DSCP. Bill From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 15 11:56:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25156 for ; Tue, 15 Jul 2003 11:56:38 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00A6FE62@cherry.ease.lsoft.com>; Tue, 15 Jul 2003 11:56:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48345895 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 15 Jul 2003 11:56:39 -0400 Received: from 12.20.58.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 15 Jul 2003 11:56:31 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h6FFtX8l027177 for ; Tue, 15 Jul 2003 11:56:31 -0400 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C00B29FFA for OSPF@PEACH.EASE.LSOFT.COM; Tue, 15 Jul 2003 11:56:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: AD-review comments on draft-ietf-ospf-scalability Thread-Index: AcNK6NdKZmE+qhlDTSaE5Y8TMjGIdgAAC3Pg Message-ID: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F09E9AA@KCCLUST06EVS1.ugd.att.com> Date: Tue, 15 Jul 2003 10:56:30 -0500 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALABS" Subject: Re: AD-review comments on draft-ietf-ospf-scalability To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Bill, Thanks for your comments and we will address those soon. Gagan Choudhury -----Original Message----- From: Bill Fenner [mailto:fenner@RESEARCH.ATT.COM] Sent: Tuesday, July 15, 2003 11:50 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: AD-review comments on draft-ietf-ospf-scalability Vishwas et al, Apologies for dropping the ball on coordinating with Alex -- I had some comments on this spec too. In the vein of other OSPF specifications, I'd like to see a list of variables and values as an appendix. I think this means K, Rmin, Rmax (in (3)), high water mark and low water mark (in (4)), and n (in (5)). In Appendix C section (2), I'd note that the TOS/Precedence bits have been redefined by Diffserv (RFC 2474). I'm not sure this matters too much, since this is only on a link so the actual values in use only need to be agreed among the systems on the link, but it might be better to refer to the DSCP. Bill From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 16 01:13:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17824 for ; Wed, 16 Jul 2003 01:13:05 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00A73056@cherry.ease.lsoft.com>; Wed, 16 Jul 2003 1:13:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48530614 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Jul 2003 01:13:03 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Jul 2003 01:13:03 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 5BB4732A493; Tue, 15 Jul 2003 22:13:02 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F14DE90.1020100@redback.com> Date: Wed, 16 Jul 2003 01:11:44 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3: Source/dest IP address for virtual link Comments: To: Mukesh Gupta To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Mike, I'm copying Mukesh to assure he sees this and agrees. Mike Fox wrote: > The OSPFv3 RFC says to use the first address with the LA-bit set from a > host's set of intra-area prefix LSAs as the destination address of a > virtual link. > Also, draft-ietf-ospf-ospfv3-auth-01.txt says that for the source address a > host should use its own first address with the LA-bit set from its > intra-area prefix LSAs. > > With hosts possibly originating multiple intra-area prefix LSAs, what's the > mechanism for choosing which intra-area prefix LSA is first? We are > thinking of using the one from the host with the lowest LSID,and if an > eligible address is not found, continuing the search at the next-highest > LSID, etc. We would do the same in picking our virtual link source > address. This is how I'd interpret RFC 2740 and the "Authentication/Confidentiality for OSPFv3" draft. > > But even this has problems. There's no guarantee that LSAs will arrive in > any order, even if they were sent out consecutively. Supposed a host with > a virtual link sends an intra-area prefix LSA with LSID of 1, the virtual > link neighbor picks the first LA-bit address out of it, then one arrives > with an LSID of 0 that also has an eligible address in it? Does the > virtual link get torn down and then rebuilt with the new address? Nope - but virtual link endpoint router originating the changed LSA above will need to modify IPSec rule 2 (as referenced in the "Authentication/Confidentiality for OSPFv3" draft). Similarly, the virtual link endpoint router receiving the changed LSA above will need to modify IPSec rules 5 and 6. > > Also, what about when addresses disappear because of renumbering or are > simply removed? Suppose we choose address A as the virtual link > destination and then at a later time address A is removed from the LSA > database? As above, the intent is that the virtual link endpoint routers will modify their IPSec rules. > > We are considering requiring our customers to configure source addresses > for virtual links. We would then advertise that address in an intra-area > prefix LSA whose LSID is 0. That would be one alternative. However, it seems a bit restrictive and you'd probably have more checking to do in your configuration. > > Mike > ----------------------------------------------------------------------- > Enterprise Network Solutions > ----------------------------------------------------------------------- > Research Triangle Park, NC USA > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 16 01:22:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18115 for ; Wed, 16 Jul 2003 01:22:16 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00A7306B@cherry.ease.lsoft.com>; Wed, 16 Jul 2003 1:22:17 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48530806 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Jul 2003 01:22:14 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Jul 2003 01:22:14 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 78B7C32A49C for ; Tue, 15 Jul 2003 22:20:47 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F14E061.8040206@redback.com> Date: Wed, 16 Jul 2003 01:19:29 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Separate Advertisements for every external LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Igor Miroshnik wrote: > In my humble opinion, RFC 1538 seems to restrict just the format of ASE > LSA, not one of the LS Update packet. Hi Igor, That is correct. In the context of OSPF, the term "advertisement" refers to a link-state advertisement (LSA). Thanks, Acee > > > On Mon, 14 Jul 2003 17:22:19 +0000, Hariprasad Rao > wrote: > > >>Hi, >> RFC 1583 section A.4.5 mentions that a separate advertisement is made for >>each destination which is external to the AS. But in later versions i.e RFC >>2178 and RFC 2328 this line is left out. >> Does this mean that we can pack more than one external LSA in a LS update >>packet? What is the reason for having such a restriction in the first > > place? > >>Would there be a backward compatibility problem if we pack more than one >>external LSA in a LS update packet? >>Thanks and Rgds, >>Hari >> >>_________________________________________________________________ >>Polyphonic ringtones. Latest movie trailors. >>http://server1.msn.co.in/sp03/gprs/index.asp On your mobile! > > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 16 01:41:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18853 for ; Wed, 16 Jul 2003 01:41:01 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00A730DC@cherry.ease.lsoft.com>; Wed, 16 Jul 2003 1:41:02 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48532702 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Jul 2003 01:41:00 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Jul 2003 01:41:00 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id B13A06EB0E0 for ; Tue, 15 Jul 2003 22:40:59 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030711101435.13528.qmail@webmail29.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F14E51D.1070705@redback.com> Date: Wed, 16 Jul 2003 01:39:41 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Area Aggregation To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Krishna, Krishna Rao wrote: > Hi, > Is it valid to configure same address range and mask in > multiple areas. > say one router is connected to area 1, area 2, and backbone area > can i configure Area Aggregation in area 1 and area 2 for > same address range and mask. Since an area is defined as a collection of networks, I don't think this makes a lot of sense. > if yes then which area address range i should consider while > generating > summary lsa. This isn't a supported configuration - if it were, you'd need to consider all the areas with the range. > > regards > Krishna > > > > > ___________________________________________________ > Click below to experience Sooraj R Barjatya's latest offering > 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek > & Kareena http://www.mpkdh.com > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 16 03:37:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18875 for ; Wed, 16 Jul 2003 03:37:19 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A73160@cherry.ease.lsoft.com>; Wed, 16 Jul 2003 3:37:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48535007 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Jul 2003 03:37:12 -0400 Received: from 47.164.128.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Jul 2003 03:27:12 -0400 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6G7RA617882 for ; Wed, 16 Jul 2003 09:27:10 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jul 2003 09:27:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34B6B.A95A3AB4" Message-ID: Date: Wed, 16 Jul 2003 09:27:07 +0200 Reply-To: Mailing List Sender: Mailing List From: Juergen Arlt Subject: Summarization but still unnecessary new LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C34B6B.A95A3AB4 Content-Type: text/plain; charset="iso-8859-1" In a very basic config a router is ABR with one interface in Area 0.0.0.0 and two interfaces in area 0.0.0.1. For those two interfaces I manually configured a summary to get only one LSA Type 3 into the backbone area. (the interfaces are 192.168.1.1/24 and 192.168.2.1/24 with a summarization of 192.168.0.0/16). Now I found that whenever there is a change on those two interfaces (one going down or up) a new summary LSA is generated into the backbone area. It does not contain new information, only the sequence number is incremented. In the worst case (like link flapping) the router would create new LSAs permanently that would be flooded into the backbone area. Although no SPF would be started the number of LSAs to process would force unnecessary CPU load on the backbone devices. I did not find an RFC stating how this summarization should be implemented but the way I found this router working is probably not the best. Can someone point me to a document if there is one? Regards Juergen ------_=_NextPart_001_01C34B6B.A95A3AB4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Summarization but still unnecessary new LSAs

In a = very basic config a router is ABR with one interface in Area 0.0.0.0 = and two interfaces in area 0.0.0.1. For those two interfaces I manually = configured a summary to get only one LSA Type 3 into the backbone area. = (the interfaces are 192.168.1.1/24 and 192.168.2.1/24 with a summarization = of 192.168.0.0/16).

Now I = found that whenever there is a change on those two interfaces (one = going down or up) a new summary LSA is generated into the backbone = area. It does not contain new information, only the sequence number is = incremented.

In the = worst case (like link flapping) the router would create new LSAs = permanently that would be flooded into the backbone area. Although no = SPF would be started the number of LSAs to process would force = unnecessary CPU load on the backbone devices.

I did = not find an RFC stating how this summarization should be implemented = but the way I found this router working is probably not the = best.

Can = someone point me to a document if there is one?

Regards

Juergen =


------_=_NextPart_001_01C34B6B.A95A3AB4-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 16 03:59:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19934 for ; Wed, 16 Jul 2003 03:59:44 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00A73305@cherry.ease.lsoft.com>; Wed, 16 Jul 2003 3:59:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48535819 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Jul 2003 03:59:28 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Jul 2003 03:59:28 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jul 2003 13:29:25 +0530 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, 16 Jul 2003 13:29:25 +0530 Reply-To: Mailing List Sender: Mailing List From: "Jeyanath Minto J - CTD, Chennai." Subject: Re: Summarization but still unnecessary new LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list hi Juergen , u only originate summary LSA , when there is real a change , its including the cost. otherwise no need to originate Summary LSA. Moreover, a unchanged LSA (may be a new instance )into a area , never tirgger the SPF. see section 16.5 of the RFC 2328. Cheers Minto Mascarenhas ********************************************************************** The person who knows "how" will always have a job . The person who knows "why" will always be his boss. ********************************************************************** -----Original Message----- From: Juergen Arlt [mailto:jarlt@NORTELNETWORKS.COM] Sent: Wednesday, July 16, 2003 12:57 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Summarization but still unnecessary new LSAs In a very basic config a router is ABR with one interface in Area 0.0.0.0 and two interfaces in area 0.0.0.1. For those two interfaces I manually configured a summary to get only one LSA Type 3 into the backbone area. (the interfaces are 192.168.1.1/24 and 192.168.2.1/24 with a summarization of 192.168.0.0/16). Now I found that whenever there is a change on those two interfaces (one going down or up) a new summary LSA is generated into the backbone area. It does not contain new information, only the sequence number is incremented. In the worst case (like link flapping) the router would create new LSAs permanently that would be flooded into the backbone area. Although no SPF would be started the number of LSAs to process would force unnecessary CPU load on the backbone devices. I did not find an RFC stating how this summarization should be implemented but the way I found this router working is probably not the best. Can someone point me to a document if there is one? Regards Juergen From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 16 05:15:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22342 for ; Wed, 16 Jul 2003 05:15:24 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A73356@cherry.ease.lsoft.com>; Wed, 16 Jul 2003 5:15:25 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48537155 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Jul 2003 05:15:24 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Jul 2003 05:15:24 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jul 2003 14:45: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: Date: Wed, 16 Jul 2003 14:45:19 +0530 Reply-To: Mailing List Sender: Mailing List From: "Jeyanath Minto J - CTD, Chennai." Subject: Re: Summarization but still unnecessary new LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list hi Juergen , ignore my last mail. Sorry to group. Cheers Minto Mascarenhas ********************************************************************** The person who knows "how" will always have a job . The person who knows "why" will always be his boss. ********************************************************************** -----Original Message----- From: Jeyanath Minto J - CTD, Chennai. [mailto:jeyananthj@CTD.HCLTECH.COM] Sent: Wednesday, July 16, 2003 1:29 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Summarization but still unnecessary new LSAs hi Juergen , u only originate summary LSA , when there is real a change , its including the cost. otherwise no need to originate Summary LSA. Moreover, a unchanged LSA (may be a new instance )into a area , never tirgger the SPF. see section 16.5 of the RFC 2328. Cheers Minto Mascarenhas ********************************************************************** The person who knows "how" will always have a job . The person who knows "why" will always be his boss. ********************************************************************** -----Original Message----- From: Juergen Arlt [mailto:jarlt@NORTELNETWORKS.COM] Sent: Wednesday, July 16, 2003 12:57 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Summarization but still unnecessary new LSAs In a very basic config a router is ABR with one interface in Area 0.0.0.0 and two interfaces in area 0.0.0.1. For those two interfaces I manually configured a summary to get only one LSA Type 3 into the backbone area. (the interfaces are 192.168.1.1/24 and 192.168.2.1/24 with a summarization of 192.168.0.0/16). Now I found that whenever there is a change on those two interfaces (one going down or up) a new summary LSA is generated into the backbone area. It does not contain new information, only the sequence number is incremented. In the worst case (like link flapping) the router would create new LSAs permanently that would be flooded into the backbone area. Although no SPF would be started the number of LSAs to process would force unnecessary CPU load on the backbone devices. I did not find an RFC stating how this summarization should be implemented but the way I found this router working is probably not the best. Can someone point me to a document if there is one? Regards Juergen From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 16 05:57:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23614 for ; Wed, 16 Jul 2003 05:57:48 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00A73490@cherry.ease.lsoft.com>; Wed, 16 Jul 2003 5:57:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48537787 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Jul 2003 05:57:50 -0400 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Jul 2003 05:47:50 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A733D6@cherry.ease.lsoft.com>; Wed, 16 Jul 2003 5:47:50 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Jul 2003 05:47:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23501; Wed, 16 Jul 2003 05:47:40 -0400 (EDT) Message-ID: <200307160947.FAA23501@ietf.org> Date: Wed, 16 Jul 2003 05:47:40 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Protocol Action: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard Comments: cc: RFC Editor , Internet Architecture Board , ospf@discuss.microsoft.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list The IESG has approved the Internet-Draft 'Traffic Engineering Extensions to OSPF Version 2' as a Proposed Standard. This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Bill Fenner and Alex Zinin. Technical Summary The Traffic Engineering Extensions to OSPF Version 2 define a method for describing the traffic engineering topology (including bandwidth and administrative constraints) and distributing this information within a given OSPF area. The traffic engineering topology need not be congruent with the regular routed topology. Working Group Summary There was strong support in the working group for this extension. The working group made several clarifications to the document during Working Group Last Call. Other minor changes, especially to clarify that this extension is only suitable for intra-area Traffic Engineering, were agreed to during IETF Last Call. Protocol Quality Bill Fenner and Alex Zinin reviewed the spec for the IESG. These extensions are widely implemented and deployed. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 16 08:42:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27939 for ; Wed, 16 Jul 2003 08:42:29 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00A73993@cherry.ease.lsoft.com>; Wed, 16 Jul 2003 8:42:30 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48570323 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Jul 2003 08:42:29 -0400 Received: from 146.171.14.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Jul 2003 08:32:28 -0400 Received: from aksmtpmdr3 (unknown [146.171.1.23]) by smtpin.telecom.co.nz (Postfix) with ESMTP id 641F42856 for ; Thu, 17 Jul 2003 00:32:27 +1200 (NZST) Received: from 146.171.227.24 by aksmtpmdr3 with ESMTP (Tumbleweed MMS SMTP Relay (MMS v5.5.2)); Thu, 17 Jul 2003 00:30:16 +1300 Received: from wnmail01.telecom.tcnz.net ([146.171.212.21]) by akextmail01.telecom.tcnz.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 00:32:19 +1200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Thread-Topic: Type-4 LSA Thread-Index: AcNLlkxYcUPWrLWGEdeSNwAJa4Y3Vw== X-OriginalArrivalTime: 16 Jul 2003 12:32:19.0408 (UTC) FILETIME=[4C514D00:01C34B96] X-WSS-ID: 130B9AD2757230-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <4449455F2B7C0E42ADC67912F349DB710210189D@wnmail01.telecom.tcnz.net> Date: Thu, 17 Jul 2003 00:32:19 +1200 Reply-To: Mailing List Sender: Mailing List From: Chris Hellberg Subject: Type-4 LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi, With reference to this message (and yup, it's a long time ago): http://peach.ease.lsoft.com/scripts/wa.exe=3FA2=3Dind9902&L=3Dospf&P=3DR52&I= =3D-3 I'm still trying to figure out the purpose of the Type-4 LSA. From John's = explanation, the type-4 LSA needs to be explicitly created to descibe the = ABSR's presence, and hence there's reachability to the ASBR for other routers= = in other areas with the Type-5 LSAs. I understand that there are separate "namespaces" to keep the types of data = discrete, but wouldn't there be a summary LSA generated by an ABR that = contains the same information as the Type-4 LSA=3F Why not use the fact that = a= summary route has a link-state-id set to the router id of the ABSR and the = its its mask is a /32=3F I'm just curious as to why have the separate LSA if = the information is already there=3F Is it due to the fact the type-3 LSA coul= d= get lost in summarisation, or that the two pieces of information in the = summary LSA aren't absolute-enough information to rely on that summary LSA = being a bona fide type 3 of the type 1 LSA=3F Cheers, Chris ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential.=20 If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------ From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 16 09:36:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29575 for ; Wed, 16 Jul 2003 09:36:54 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00A73A7A@cherry.ease.lsoft.com>; Wed, 16 Jul 2003 9:36:53 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48573629 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Jul 2003 09:36:52 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Jul 2003 09:36:48 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 813A78AD105 for ; Wed, 16 Jul 2003 06:36:47 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F15549C.7070309@redback.com> Date: Wed, 16 Jul 2003 09:35:24 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Summarization but still unnecessary new LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Juergen Arlt wrote: > In a very basic config a router is ABR with one interface in Area > 0.0.0.0 and two interfaces in area 0.0.0.1. For those two interfaces I > manually configured a summary to get only one LSA Type 3 into the > backbone area. (the interfaces are 192.168.1.1/24 and 192.168.2.1/24 > with a summarization of 192.168.0.0/16). > > Now I found that whenever there is a change on those two interfaces (one > going down or up) a new summary LSA is generated into the backbone area. > It does not contain new information, only the sequence number is > incremented. > > In the worst case (like link flapping) the router would create new LSAs > permanently that would be flooded into the backbone area. Although no > SPF would be started the number of LSAs to process would force > unnecessary CPU load on the backbone devices. > > I did not find an RFC stating how this summarization should be > implemented but the way I found this router working is probably not the > best. > > Can someone point me to a document if there is one? Juergen, While an intra-area route change is one of the 10 events listed in section 12.4, a router shouldn't re-originate the summary LSA corresponding to the range unless the contents have changed. Unfortunately, I can't find any place where this is stated explicitly but, IMHO, it is common sense. Thanks, Acee > > Regards > > Juergen > > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 16 09:48:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00067 for ; Wed, 16 Jul 2003 09:48:38 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00A73A0D@cherry.ease.lsoft.com>; Wed, 16 Jul 2003 9:48:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48574378 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Jul 2003 09:48:38 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Jul 2003 09:48:38 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id E5DE58AD10B for ; Wed, 16 Jul 2003 06:48:36 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4449455F2B7C0E42ADC67912F349DB710210189D@wnmail01.telecom.tcnz.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F155761.7010109@redback.com> Date: Wed, 16 Jul 2003 09:47:13 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Type-4 LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Chris Hellberg wrote: > Hi, > > With reference to this message (and yup, it's a long time ago): > > http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind9902&L=ospf&P=R52&I=-3 > > I'm still trying to figure out the purpose of the Type-4 LSA. From John's > explanation, the type-4 LSA needs to be explicitly created to descibe > the ABSR's presence, and hence there's reachability to the ASBR for > other routers in other areas with the Type-5 LSAs. > > I understand that there are separate "namespaces" to keep the types of > data discrete, but wouldn't there be a summary LSA generated by an ABR that > contains the same information as the Type-4 LSA? Why not use the fact > that a summary route has a link-state-id set to the router id of the ABSR > and the its its mask is a /32? I'm just curious as to why have the separate > LSA if the information is already there? Is it due to the fact the type-3 LSA > could get lost in summarisation, or that the two pieces of information in the > summary LSA aren't absolute-enough information to rely on that summary > LSA being a bona fide type 3 of the type 1 LSA? Chris, The only information required in a type 5 or 7 LSA to link it to its advertising router is the router ID. There is nothing to guarentee that a router will advertise a /32 stub link corresponding to it's router LSA. Thanks, Acee P.S. Use /nl occasionally in your message next time :^) > > Cheers, > > Chris > > ------------------------------------------------------------------------------ > "This communication, including any attachments, is confidential. > If you are not the intended recipient, you should not read > it - please contact me immediately, destroy it, and do not > copy or use any part of this communication or disclose > anything about it. Thank you." > ------------------------------------------------------------------------------ > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 16 14:33:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11659 for ; Wed, 16 Jul 2003 14:33:56 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00A7698C@cherry.ease.lsoft.com>; Wed, 16 Jul 2003 14:33:49 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48588580 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Jul 2003 13:07:33 -0400 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Jul 2003 13:07:33 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01KYBMMIGFM88X2X3V@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 16 Jul 2003 10:07:32 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01KYBMMIGHIA8X2X3V@omega7.wr.usgs.gov> Date: Wed, 16 Jul 2003 10:07:32 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: Summarization but still unnecessary new LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Juergen, >RFC 2328, Section 12.4.3 states At most a single Type 3 summary-LSA is originated for each range. The implication of this statement is clear. If the local router has already originated a summary-LSA for a range, subsequent re-originations caused by other networks subsumed by the range should be skipped. As long as the set of networks subsumed by a range is non-empty, the summary-LSA should undergo normal aging. It would have been nice if this had been stated more explicity, but "it is common sense". Pat From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 17 03:49:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21160 for ; Thu, 17 Jul 2003 03:49:45 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00A7B981@cherry.ease.lsoft.com>; Thu, 17 Jul 2003 3:49:44 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48643678 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 17 Jul 2003 03:34:37 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 17 Jul 2003 03:34:36 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jul 2003 13:04:33 +0530 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, 17 Jul 2003 13:04:34 +0530 Reply-To: Mailing List Sender: Mailing List From: "Jeyanath Minto J - CTD, Chennai." Subject: AS scope Opaque LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi , i have few Question regarding AS scope Opaque LSA. 1. Is it possible to originate an AS scope LSA by a non ASBR router. 2. if Opaque LSA supports DNA , Then howcome we remove the Stale DNA Opaque LSA. (This will Happen only, non ASBR router may originate AS scope Opaque LSA) 3. And , is there any As scope Opaque LSA currently used ? Cheers Minto Mascarenhas ********************************************************************** The person who knows "how" will always have a job . The person who knows "why" will always be his boss. ********************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 17 07:52:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01787 for ; Thu, 17 Jul 2003 07:52:12 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A7C5DA@cherry.ease.lsoft.com>; Thu, 17 Jul 2003 7:52:10 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48677970 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 17 Jul 2003 07:52:09 -0400 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 17 Jul 2003 07:52:09 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h6HCLY104790 for ; Thu, 17 Jul 2003 17:51:34 +0530 Received: from apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with SMTP id h6HCLXg04784 for ; Thu, 17 Jul 2003 17:51:33 +0530 Received: from 61.11.33.157 (SquirrelMail authenticated user alok.dube) by mail.apara.com with HTTP; Thu, 17 Jul 2003 17:51:33 +0530 (IST) References: <4449455F2B7C0E42ADC67912F349DB710210189D@wnmail01.telecom.tcnz.net> <3F155761.7010109@redback.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <42885.61.11.33.157.1058444493.squirrel@mail.apara.com> Date: Thu, 17 Jul 2003 17:51:33 +0530 Reply-To: Mailing List Sender: Mailing List From: Alok Dube Subject: Re: Type-4 LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F155761.7010109@redback.com> Precedence: list Content-Transfer-Encoding: 8bit Hi Acee, This has nothing to do with the present way OSPF is implemented, but I would like to know the following inline: >> Hi, >> >> With reference to this message (and yup, it's a long time ago): >> >> http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind9902&L=ospf&P=R52&I=-3 >> >> I'm still trying to figure out the purpose of the Type-4 LSA. From >> John's > > explanation, the type-4 LSA needs to be explicitly created to descibe > > the ABSR's presence, and hence there's reachability to the ASBR for > > other routers in other areas with the Type-5 LSAs. >> >> I understand that there are separate "namespaces" to keep the types of >> data discrete, but wouldn't there be a summary LSA generated by an ABR >> that contains the same information as the Type-4 LSA? Why not use the >> fact that a summary route has a link-state-id set to the router id of >> the ABSR and the its its mask is a /32? I'm just curious as to why >> have the separate LSA if the information is already there? Is it due >> to the fact the type-3 LSA could get lost in summarisation, or that >> the two pieces of information in the > > summary LSA aren't absolute-enough information to rely on that > > summary LSA being a bona fide type 3 of the type 1 LSA? > > Chris, > > The only information required in a type 5 or 7 LSA to link it to its > advertising router is the router ID. There is nothing to guarentee that > a router will advertise a /32 stub link corresponding to it's router > LSA. Can the type-5, when propogated into the rest of the AS not be linked to the "router-id" of the ABR of the area from where the type-5 originated? Within an area, the router-id is the unique identifier of the routes it originates and the ABR in the area will know that "router-id" due to the router-LSA orginated by the ASBR? it would a bit like the present for type-3: next-hop for external routes=ABR; and at ABR, next-hop=path to router-id from where route was learnt? pardon me if I am missing something/have missed something in the RFC. why is it that in network summary type -3 LSAs we rely on ABR to relay the packet to the destination (it modifies the type 3 and tells the area that the path to the destn network is via itself),but for AS external LSAs, we dont rely on ABR to do the same? -thanks Alok From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 17 09:55:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06625 for ; Thu, 17 Jul 2003 09:55:39 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A7C852@cherry.ease.lsoft.com>; Thu, 17 Jul 2003 9:55:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48684405 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 17 Jul 2003 09:55:38 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 17 Jul 2003 09:54:15 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 3900E5FEA86 for ; Thu, 17 Jul 2003 06:54:13 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4449455F2B7C0E42ADC67912F349DB710210189D@wnmail01.telecom.tcnz.net> <3F155761.7010109@redback.com> <42885.61.11.33.157.1058444493.squirrel@mail.apara.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F16AA24.4050703@redback.com> Date: Thu, 17 Jul 2003 09:52:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Type-4 LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Alok Dube wrote: > Hi Acee, > > > This has nothing to do with the present way OSPF is implemented, but I > would like to know the following inline: > > >>>Hi, >>> >>>With reference to this message (and yup, it's a long time ago): >>> >>>http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind9902&L=ospf&P=R52&I=-3 >>> >>>I'm still trying to figure out the purpose of the Type-4 LSA. From >>>John's >>>explanation, the type-4 LSA needs to be explicitly created to descibe >>>the ABSR's presence, and hence there's reachability to the ASBR for >>>other routers in other areas with the Type-5 LSAs. >>> >>>I understand that there are separate "namespaces" to keep the types of >>>data discrete, but wouldn't there be a summary LSA generated by an ABR >>>that contains the same information as the Type-4 LSA? Why not use the >>>fact that a summary route has a link-state-id set to the router id of >>>the ABSR and the its its mask is a /32? I'm just curious as to why >>>have the separate LSA if the information is already there? Is it due >>>to the fact the type-3 LSA could get lost in summarisation, or that >>>the two pieces of information in the >>>summary LSA aren't absolute-enough information to rely on that >>>summary LSA being a bona fide type 3 of the type 1 LSA? >> >>Chris, >> >>The only information required in a type 5 or 7 LSA to link it to its >>advertising router is the router ID. There is nothing to guarentee that >>a router will advertise a /32 stub link corresponding to it's router >>LSA. Hi Alok, > > > > Can the type-5, when propogated into the rest of the AS not be linked to > the "router-id" of the ABR of the area from where the type-5 originated? The ABR of the originating area won't help a non-ABR in a non-backbone area. > Within an area, the router-id is the unique identifier of the routes it > originates and the ABR in the area will know that "router-id" due to the > router-LSA orginated by the ASBR? > it would a bit like the present for type-3: > > next-hop for external routes=ABR; > and at ABR, next-hop=path to router-id from where route was learnt? > > pardon me if I am missing something/have missed something in the RFC. > > why is it that in network summary type -3 LSAs we rely on ABR to relay the > packet to the destination (it modifies the type 3 and tells the area that > the path to the destn network is via itself),but for AS external LSAs, we > dont rely on ABR to do the same? We do rely on the ABRs to generate a type 4 summary LSAs for ASBRs. I'm not sure I get what you are trying to do. > -thanks > Alok > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 17 10:54:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10117 for ; Thu, 17 Jul 2003 10:54:30 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A7C95B@cherry.ease.lsoft.com>; Thu, 17 Jul 2003 10:54:31 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48688959 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 17 Jul 2003 10:54:29 -0400 Received: from 32.97.110.132 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 17 Jul 2003 10:54:29 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6HEsSEh193576 for ; Thu, 17 Jul 2003 10:54:28 -0400 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6HEsDOq187344 for ; Thu, 17 Jul 2003 08:54:13 -0600 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF1|June 9, 2003) at 07/17/2003 08:54:13 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Thu, 17 Jul 2003 10:54:11 -0400 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Question on originating intra-area prefix LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list When a prefix is added to or deleted from a p2p or p2mp link, when is the prefix change supposed to be advertised to the rest of the area in an intra-area prefix LSA? There seems to be a hole in the RFC. RFC 2740 says, in 3.4.3: o A new prefix is added to an attached link, or a prefix is deleted (both through configuration). This causes the router to reoriginate its link-LSA for the link, or, if it is the only router attached to the link, causes the router to reoriginate an intra-area-prefix-LSA. Some observations and questions. Is it really link LSA *or* intra-area prefix LSA? I.e., never both? This paragraph also implies that on p2p and p2mp links with active neighbors, no intra-area prefix LSA is sent when prefixes change, since the intra-area prefix LSA is only reoriginated when this is the ONLY router on the link. The only other way I can see the prefix being advertised for p2p and p2mp is that perhaps the neighbor should advertise the new prefix in an intra-area prefix LSA when it receives the link LSA. But the next paragraph says: o A new link-LSA is received, causing the link's collection of prefixes to change. If the router is Designated Router for the link, it originates a new intra-area-prefix-LSA. Which implies only the DR for a multiaccess link should ever send a new intra-area prefix LSA upon receiving a link LSA, nothing about point to point or point to multipoint is mentioned. Also, if the set of prefixes is changed on the designated router, according to strict reading of this paragraph then the network's intra-area prefix LSA would not get reoriginated since it's on receiving (not sending) a link LSA that the DR sends the new set. To me it boils down the phrase "if it is the only router attached to the link" in the first quoted paragraph above. If that phrase were replaced with "in all cases except when the link is to a broadcast or multiaccess network and this router is not the designated router" then it seems like all the cases would be covered. What am I missing here? Am I just reading the text too strictly? Mike ----------------------------------------------------------------------- Enterprise Network Solutions ----------------------------------------------------------------------- Research Triangle Park, NC USA From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 17 17:34:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23449 for ; Thu, 17 Jul 2003 17:34:22 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00A7E01F@cherry.ease.lsoft.com>; Thu, 17 Jul 2003 17:34:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48705427 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 17 Jul 2003 17:34:20 -0400 Received: from 207.159.120.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 17 Jul 2003 17:34:20 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 93477B6B1; Thu, 17 Jul 2003 17:34:15 -0400 (EDT) Received: from [64.47.48.10] by xprdmailfe17.nwk.excite.com via HTTP; Thu, 17 Jul 2003 17:34:15 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 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: <20030717213415.93477B6B1@xmxpita.excite.com> Date: Thu, 17 Jul 2003 17:34:15 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: AS scope Opaque LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Minto, Since most everyone is probably in Vienna, I'll take a go at responding... 1. Technically, yes, since the opaque LSA RFC does not explicitly state this. While it is tempting to think of an AS-wide opaque LSA as being flooded like an AS External LSA (only by an ASBR, not flooded into stub areas), the same does not apply to an AS-wide opaque LSA as it does not (necessarily) have anything to do with "external route" information that an ASBR is responsible for advertising. 2. I'll let Padma or Acee respond to this one. 3. Not that I am aware of in general OSPF implementations, but there may be something from the newer drafts like Path Computation Server that might use AS-wide opaque LSAs. -don ====================================================== Hi , i have few Question regarding AS scope Opaque LSA. 1. Is it possible to originate an AS scope LSA by a non ASBR router. 2. if Opaque LSA supports DNA , Then howcome we remove the Stale DNA Opaque LSA. (This will Happen only, non ASBR router may originate AS scope Opaque LSA) 3. And , is there any As scope Opaque LSA currently used ? Cheers Minto Mascarenhas _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 17 19:34:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26966 for ; Thu, 17 Jul 2003 19:34:11 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00A7E417@cherry.ease.lsoft.com>; Thu, 17 Jul 2003 19:34:11 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48712271 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 17 Jul 2003 19:34:06 -0400 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 17 Jul 2003 19:34:06 -0400 Received: from smirtoraw2k03 (dhcp-171-69-101-97.cisco.com [171.69.101.97]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h6HNY5T09237 for ; Thu, 17 Jul 2003 16:34: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, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Message-ID: <005501c34cbb$e98f16d0$616545ab@amer.cisco.com> Date: Thu, 17 Jul 2003 16:34:05 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Question on originating intra-area prefix LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Mike The text might be a bit confusing when you try to do a strict reading ;-) Here is what you would do in general 1) whenever there is a change to a link local prefix or global prefix you would re-originate a new link-LSA 2) whenever there is a change to a global prefix you would originate a new intra-area-prefix-lsa if either of the the following is true 2-a) the link type ( I should say interface type connected to the link) is p2p /p2mp 2-b) link type is multi-access and there is no neighbor in state FULL 2-c) link type is multi-access and this router is DR for that link 2-d) independently of the link type the global prefix has a prefix options with LA or NU bit set In other words you would generate a new link-LSA for any prefix change on a link, and you would originate a new intra-area-prefix-lsa for any change to the global prefix only when you are supposed to announce this link's prefix in an intra-area-prefix-lsa ( 2-a or 2-b or 2-c or 2-d) The above means that on a p2p / p2mp link when there is a change to a prefix you would both re-originate a new link-lsa and a new intra-area-prefix-lsa however on a multi-access link ( with at least one FULL neighbor) a non-DR router would only re-originate its link-lsa. Upon reception of this new link-lsa the DR will update its intra-area-prefix-lsa when necessary. Now there could be an optimization when there is no neighbor on a link and you could suppress your link-lsa since there is no neighbor on that link. Thanks Sina ->-----Original Message----- ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On ->Behalf Of Mike Fox ->Sent: Thursday, July 17, 2003 7:54 AM ->To: OSPF@PEACH.EASE.LSOFT.COM ->Subject: Question on originating intra-area prefix LSA -> -> ->When a prefix is added to or deleted from a p2p or p2mp link, ->when is the prefix change supposed to be advertised to the ->rest of the area in an intra-area prefix LSA? There seems to ->be a hole in the RFC. -> -> RFC 2740 says, in 3.4.3: -> -> o A new prefix is added to an attached link, or a prefix ->is deleted -> (both through configuration). This causes the router to -> reoriginate its link-LSA for the link, or, if it is the only -> router attached to the link, causes the router to reoriginate an -> intra-area-prefix-LSA. -> ->Some observations and questions. -> ->Is it really link LSA *or* intra-area prefix LSA? I.e., never both? -> ->This paragraph also implies that on p2p and p2mp links with ->active neighbors, no intra-area prefix LSA is sent when ->prefixes change, since the intra-area prefix LSA is only ->reoriginated when this is the ONLY router on ->the link. The only other way I can see the prefix being ->advertised for ->p2p and p2mp is that perhaps the neighbor should advertise ->the new prefix ->in an intra-area prefix LSA when it receives the link LSA. ->But the next ->paragraph says: -> ->o A new link-LSA is received, causing the link's collection of -> prefixes to change. If the router is Designated Router for the -> link, it originates a new intra-area-prefix-LSA. -> ->Which implies only the DR for a multiaccess link should ever ->send a new intra-area prefix LSA upon receiving a link LSA, ->nothing about point to point or point to multipoint is ->mentioned. Also, if the set of prefixes is changed on the ->designated router, according to strict reading of this ->paragraph then the network's intra-area prefix LSA would not ->get reoriginated since it's on receiving (not sending) a link ->LSA that the DR sends the new set. -> ->To me it boils down the phrase "if it is the only router ->attached to the link" in the first quoted paragraph above. ->If that phrase were replaced with "in all cases except when ->the link is to a broadcast or multiaccess network and this ->router is not the designated router" then it seems like all ->the cases would be covered. -> ->What am I missing here? Am I just reading the text too strictly? -> ->Mike ->-------------------------------------------------------------- ->--------- ->Enterprise Network Solutions ->-------------------------------------------------------------- ->--------- ->Research Triangle Park, NC USA -> From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 18 00:29:54 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03804 for ; Fri, 18 Jul 2003 00:29:53 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00A7EE84@cherry.ease.lsoft.com>; Fri, 18 Jul 2003 0:29:54 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48749508 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 18 Jul 2003 00:29:51 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 18 Jul 2003 00:29:51 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id C0E8743DCA8 for ; Thu, 17 Jul 2003 21:29:50 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030717213415.93477B6B1@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F177756.2040205@redback.com> Date: Fri, 18 Jul 2003 00:28:06 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: AS scope Opaque LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Don, Minto, Don Goodspeed wrote: > Minto, > > Since most everyone is probably in Vienna, I'll take a go at responding... > > 1. Technically, yes, since the opaque LSA RFC does not explicitly > state this. While it is tempting to think of an AS-wide opaque > LSA as being flooded like an AS External LSA (only by an ASBR, > not flooded into stub areas), the same does not apply to an AS-wide > opaque LSA as it does not (necessarily) have anything to do with > "external route" information that an ASBR is responsible for > advertising. Don - Agreed. RFC 2370 doesn't require a router originating an AS scoped opaque LSA to be an ASBR. > > 2. I'll let Padma or Acee respond to this one. Minto - I think you've uncovered a problem here. A router in an area other than the originating router will not have route to the originating router and will purge the stale DoNotAge LSA. From RFC 1793: 2.3. Removing stale DoNotAge LSAs Because LSAs with the DoNotAge bit set are never aged, they can stay in the link state database even when the originator of the LSA no longer exists. To ensure that these LSAs are eventually flushed from the routing domain, and that the size of the link state database doesn't grow without bound, routers are required to flush a DoNotAge LSA if BOTH of the following conditions are met: (1) The LSA has been in the router's database for at least MaxAge seconds. (2) The originator of the LSA has been unreachable (according to the routing calculations specified by Section 16 of [1]) for at least MaxAge seconds. One solution would be for any router announcing any AS scoped LSA to advertise itself as an ASBR (as per its router bit in the router LSA). Other solutions are welcome :^) > > 3. Not that I am aware of in general OSPF implementations, but there > may be something from the newer drafts like Path Computation Server > that might use AS-wide opaque LSAs. The OSPF capabilities draft may utilize an AS scoped opaque LSA. > > -don > > ====================================================== > Hi , > i have few Question regarding AS scope Opaque LSA. > > 1. Is it possible to originate an AS scope LSA by a non ASBR router. > > > 2. if Opaque LSA supports DNA , Then howcome we remove the Stale DNA > Opaque LSA. > (This will Happen only, non ASBR router may originate AS scope > Opaque LSA) > > 3. And , is there any As scope Opaque LSA currently used ? > > Cheers > Minto Mascarenhas > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 22 07:56:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10423 for ; Tue, 22 Jul 2003 07:56:22 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00A8DD4E@cherry.ease.lsoft.com>; Tue, 22 Jul 2003 7:56:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49092722 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 22 Jul 2003 07:56:20 -0400 Received: from 205.158.62.67 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 22 Jul 2003 07:46:20 -0400 Received: from 205-158-62-68.outblaze.com (205-158-62-68.outblaze.com [205.158.62.68]) by spf13.us4.outblaze.com (Postfix) with QMQP id 56A721829D2B for ; Tue, 22 Jul 2003 11:46:19 +0000 (GMT) Received: (qmail 27853 invoked from network); 22 Jul 2003 11:46:19 -0000 Received: from unknown (HELO ws5-2.us4.outblaze.com) (205.158.62.132) by 205-158-62-153.outblaze.com with SMTP; 22 Jul 2003 11:46:19 -0000 Received: (qmail 25706 invoked by uid 1001); 22 Jul 2003 11:46:19 -0000 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [203.197.138.194] by ws5-2.us4.outblaze.com with http for niveda@indiainfo.com; Tue, 22 Jul 2003 17:16:19 +0530 X-Originating-Ip: 203.197.138.194 X-Originating-Server: ws5-2.us4.outblaze.com Message-ID: <20030722114619.25705.qmail@indiainfo.com> Date: Tue, 22 Jul 2003 17:16:19 +0530 Reply-To: Mailing List Sender: Mailing List From: Niveda Monyvannan Subject: Clarification about TE and GMPLS enhancement for OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit As the TE information is propogated as Type 10 Opaque LSA, area in which the information to be flooded is required.. This area information can be derived from the router LSA. If the TE link passed by the external module is present in one of its Router LSA as Type1 or Type2 link, Router LSA's area is chosen for flooding the Type 10 LSA. This approach will not hold for GMPLS extension wherein we have the concept of Forwarding adjacency. For this also, if we enable FA link as ospf passive interface, control packet traffic is avoided whereas the interface might have associated with an area which can be used for flooding the FA TE information . But this approach will not work out for unnumbered FA. Even if we enable FA unnumbered interface as Passive interface, there won't be any entry in router LSA. (As per RFC 2328, Section 12.4.1.1, as this is made as passive, there won't be any adjacenecy. so Type 1 Link will not be there. Type3 is added only when we have some subnet assigned to this link) Should we expect the area id also to be passed from the TE Link management module? I am sorry if this is too implementation specific. Any help on this is appreciated. Regards, Niveda -- ______________________________________________ http://www.indiainfo.com Now with POP3/SMTP access for only US$14.95/yr Powered by Outblaze From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 22 09:31:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12917 for ; Tue, 22 Jul 2003 09:31:19 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A8DE22@cherry.ease.lsoft.com>; Tue, 22 Jul 2003 9:31:18 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49097315 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 22 Jul 2003 09:31:17 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 22 Jul 2003 09:31:17 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 96E2F8180E6 for ; Tue, 22 Jul 2003 06:31:15 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F1D3CF7.8000508@redback.com> Date: Tue, 22 Jul 2003 09:32:39 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: FW: AS scope Opaque LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit From: Manral V-G19459 Sent: Tuesday, July 22, 2003 17:39 To: 'Mailing List' Subject: RE: AS scope Opaque LSA Hi Acee, >> Minto - I think you've uncovered a problem here. A >> router in an area other than the originating router >> will not have route to the originating router and >> will purge the stale DoNotAge LSA. >> > One solution would be for any router announcing any > AS scoped LSA to advertise itself as an ASBR (as per > its router bit in the router LSA). Other solutions > are welcome :^) How about the ABR originating Type-10 opaque LSA's, with router ID's of routers still reachable and originate global scope LSA's, which have reachability to the ABR. It is backward compatibility and will not create problems about multiple LSA's being injected into the domain (in case every router advertizes type-11's :-)). This solution can be made generic for OSPFv3, where we can have unknown LSA types in the future. Sounds reasonable? Thanks, Vishwas From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 22 09:38:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13130 for ; Tue, 22 Jul 2003 09:38:30 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00A8DE63@cherry.ease.lsoft.com>; Tue, 22 Jul 2003 9:38:31 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49097177 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 22 Jul 2003 09:38:30 -0400 Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 22 Jul 2003 09:28:30 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h6MDSSoN022311 for ; Tue, 22 Jul 2003 06:28:28 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h6MDSNDp004072 for ; Tue, 22 Jul 2003 08:28:25 -0500 Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Tue, 22 Jul 2003 18:58:21 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <653138C25D8AD6118292000347080A37055FBCBF@zin05exm02.corp.mot.com> Date: Tue, 22 Jul 2003 18:58:20 +0530 Reply-To: Mailing List Sender: Mailing List From: Manral V-G19459 Subject: Re: AS scope Opaque LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Acee, >> Minto - I think you've uncovered a problem here. A >> router in an area other than the originating router >> will not have route to the originating router and >> will purge the stale DoNotAge LSA. >> > One solution would be for any router announcing any > AS scoped LSA to advertise itself as an ASBR (as per > its router bit in the router LSA). Other solutions > are welcome :^) How about the ABR originating Type-10 opaque LSA's, with router ID's of routers still reachable and originate global scope LSA's, which have reachability to the ABR. It is backward compatibility and will not create problems about multiple LSA's being injected into the domain (in case every router advertizes type-11's :-)). This solution can be made generic for OSPFv3, where we can have unknown LSA types in the future. Sounds reasonable? Thanks, Vishwas From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 22 17:19:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27174 for ; Tue, 22 Jul 2003 17:19:40 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00A8FAE8@cherry.ease.lsoft.com>; Tue, 22 Jul 2003 17:19:40 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49137036 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 22 Jul 2003 17:19:39 -0400 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 22 Jul 2003 17:19:38 -0400 Received: (qmail 945 invoked from network); 22 Jul 2003 21:19:38 -0000 Received: from bigbird.nj.us.utstar.com (172.16.36.21) by lxmail.nj.us.utstar.com with SMTP; 22 Jul 2003 21:19:38 -0000 Received: from utstar.com (localhost.localdomain [127.0.0.1]) by bigbird.nj.us.utstar.com (8.9.3/8.9.3) with ESMTP id RAA06847 for ; Tue, 22 Jul 2003 17:19:37 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_16475350200" Message-ID: <200307222119.RAA06847@bigbird.nj.us.utstar.com> Date: Tue, 22 Jul 2003 17:19:37 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: ietf 57 ospf wg meeting minutes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart MIME message. --==_Exmh_16475350200 Content-Type: text/plain; charset=us-ascii As usual, due to Dimitri. Many thanks to him. --rohit. --==_Exmh_16475350200 Content-Type: text/plain ; name="ietf57-ospf-minutes.txt"; charset=us-ascii Content-Description: ietf57-ospf-minutes.txt Content-Disposition: attachment; filename="ietf57-ospf-minutes.txt" Open Shortest Path First IGP WG (ospf) Tuesday, July 15 at 1700-1800 ============================== REPORTED BY: Dimitri Papadimitriou CHAIRS: Rohit Dube Acee Lindem AGENDA: 1. Agenda Bashing 5 Mins Chairs 2. Administativia and Document Status 10 Mins Chairs 3. IGP Capabilities 10 Mins Rahul Aggarwal 4. Traffic Engineering Capability TLV for OSPF 10 Mins Jean Philippe Vasseur ------------------------------------------------------------------------------- 1. Agenda Bashing (5 Mins) - No change in the proposed agenda ------------------------------------------------------------------------------- 2.1 Administrativia: o Implementation Report for Hitless restart - request issued June 13, 2003 - please respond to Acee (acee@redback.com) o Additional OSPF Page at - with thanks to Bill Fenner! o Routing Area Meeting: - Hall NO - Thursday 1530-1730 2.2 OSPF Document Status o Documents Progressing: - Traffic Engineering Extensions to OSPF Version 2 . IANA section updated . Second IETF Last Call completed . Under IESG evaluation - OSPF Hitless Restart . Comments from WG Last Call incorporated . Under IESG Evaluation . New version forthcoming incorporating initial IESG comments - Detecting Inactive Neighbors over Demand Circuits . New version incorporating IESG comments required - Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance . WG Last call completed . Under AD review - OSPF Refresh and Flooding Reduction in Stable Topologies . WG Last Call and AD review completed . Will be published as informational RFC - Traffic Engineering Extension to OSPF version 3 . Refreshed as WG document . Please review and discuss o Document at Same Status: - OSPF Version 2 Management Information Base . One more update needed prior to WG last call - OSPF Version 3 Management Information Base . Vishwas Manral added as author . Recently refreshed . Please review and discuss on list - Authentication/Confidentiality for OSPFv3 . Refreshed with comments . Please review and discuss Discussions: ----------- - Bill Fenner: Did you receive our comments ? - Rohit Dube: Yes, we've received them from Alex Zinin - Bill Fenner: I will send my comments to the mailing list o New Documents: - Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs . Accepted as WG document . Please review and discuss - Extensions to OSPF for Advertising Optional Router Capabilities . Will be refreshed as WG document o Document Tracker: - http://rtg.ietf.org/ospf/ - Click on "Status of OSPF WG Drafts" - Click on "AD watching and Beyond" ------------------------------------------------------------------------------- 3. IGP Capabilities (10 Mins) - Rahul Aggarwal Summary: ------- o This draft proposes extensions to OSPF for advertising optional router capabilities by proposing a method that overcomes the lack of bits remaining unassigned in the options field of the hello packet. Router Information (RI) opaque LSA is here proposed to advertise new optional router capabilities or MPLS TE capabilities. The existing applications are PCS, Mesh Groups, and iBGP auto-mesh. Discussions: ----------- - Rahul Aggarwal (addressing the working group): any questions ? - Rohit Dube: the draft has a couple of TLV's assigned for drafts not yet officially adopted by an paticular working group - Rahul Aggarwal: the documents are the Path Compuation Server (PCS) and auto-mesh i-d's. Should they be added when they become WG documents? - Rohit Dube: yes (this is the procedure to follow) ------------------------------------------------------------------------------- 4. IGP Traffic Engineering TLV for OSPF (10 Mins) - Jean-Philippe Vasseur Topic: ----- o Definition of the Mesh-Group TLV and the PCSD TLV as OSPF Traffic Engineering capability TLVs to be included in the OSPF Router Information LSA (with Opaque Type of 4, Opaque ID of 0 and Type 10/11 LSA depending on the application) - Scope of the current discussion is first to introduce the applications Summary: ------- o Mesh-Group TLV: . Used by an LSR to indicate its desire to participate to a mesh of TE LSPs (identified by a mesh-group number) . Useful to automate the creation of full meshes of TE LSPs with coloring . Discussion on the structure of the proposed TLV o PCS Discovery (PCSD) TLV: - Allows an LSR to announce its PCS capability to other LSRs within an OSPF area or a routing domain (and thus deliver PCS discovery capability) - PCSD TLV includes several sub-TLVs: . PCS scope . PCS address . PCS capability . AS-domain - Applicability: . situation in inter-area traffic-engineering - reference to the multi- area draft of Kireeti Kompella (scenarios 2, 4 and 5) . situation in inter-AS traffic-engineering Discussions: ----------- - Jean-Philippe Vasseur: scope here is to discuss the applications - Rohit Dube: for now this draft is presented to the OSPF WG for information only - where this particular work can progress has to be discussed on the list. - Rohit Dube: other questions or comments on this topic ? => no reaction from the room Rohit Dube: questions or comments on any other topic ? => no reaction from the room Rohit Dube: meeting is adjourned =============================================================================== --==_Exmh_16475350200-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 22 18:16:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29218 for ; Tue, 22 Jul 2003 18:16:06 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00A8FD51@cherry.ease.lsoft.com>; Tue, 22 Jul 2003 18:16:08 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49140567 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 22 Jul 2003 18:16:07 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 22 Jul 2003 18:16:06 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 99EF7974E4A for ; Tue, 22 Jul 2003 15:15:30 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F1DB7D1.8060609@redback.com> Date: Tue, 22 Jul 2003 18:16:49 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF Graceful Restart Implementation Report To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I sent out the solicitation for vendors to report on thier implementation of draft-ietf-ospf-hitless-restart-08.txt on June 13th, 2003. I know that at least a couple of you have implemented the draft. Please fill out the following form omitting any questions you are uncomfortable answering. Vendor: ________________________ Product(s): ________________________________________ Shipped (yes/no): __________________________________ Largest Deployment _________________________________ This may be very hard to gauge since it is hard to say whether or not a particular customer is using it. Planned Restart (yes/no): ____ Unplanned Restart (yes/no): ____ Interoperability Tested with: ______________________ Strict LSA Checking (yes/no/configurable): _________ By this I mean do you terminate helper mode when there is a change to any router that will be flooded to the restarting router. Additional Extensions: _____________________________ This would include additional delays for route redistribution, BGP convergence, etc. Thanks, --- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 22 18:38:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29619 for ; Tue, 22 Jul 2003 18:38:27 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00A8FC42@cherry.ease.lsoft.com>; Tue, 22 Jul 2003 18:38:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49141159 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 22 Jul 2003 18:38:26 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 22 Jul 2003 18:28:26 -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 SAA08311 for ; Tue, 22 Jul 2003 18:28:23 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA06145 for ; Tue, 22 Jul 2003 18:28:24 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MYQNA>; Tue, 22 Jul 2003 18:28: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: <39469E08BD83D411A3D900204840EC5501067F74@vie-msgusr-01.dc.fore.com> Date: Tue, 22 Jul 2003 18:28:22 -0400 Reply-To: Mailing List Sender: Mailing List From: "Abdallah, Shukri" Subject: Re: OSPF Graceful Restart Implementation Report To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Greg: Would like us to reply to this? Shukri > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, July 22, 2003 6:17 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: OSPF Graceful Restart Implementation Report > > > I sent out the solicitation for vendors to report on thier > implementation of draft-ietf-ospf-hitless-restart-08.txt on > June 13th, 2003. I know that at least a couple of you have > implemented the draft. > > Please fill out the following form omitting any questions you > are uncomfortable answering. > > Vendor: ________________________ > > Product(s): ________________________________________ > > Shipped (yes/no): __________________________________ > > Largest Deployment _________________________________ > > This may be very hard to gauge since it is hard to say whether > or not a particular customer is using it. > > Planned Restart (yes/no): ____ > > Unplanned Restart (yes/no): ____ > > Interoperability Tested with: ______________________ > > Strict LSA Checking (yes/no/configurable): _________ > > By this I mean do you terminate helper mode when there is > a change to any router that will be flooded to the restarting > router. > > Additional Extensions: _____________________________ > > This would include additional delays for route redistribution, > BGP convergence, etc. > > Thanks, > --- > Acee > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 23 01:22:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06026 for ; Wed, 23 Jul 2003 01:22:52 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00A90AB7@cherry.ease.lsoft.com>; Wed, 23 Jul 2003 1:22:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49177034 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 23 Jul 2003 01:22:50 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Jul 2003 01:22:49 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 7131C21EB0F for ; Tue, 22 Jul 2003 22:22:47 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <653138C25D8AD6118292000347080A37055FBCBF@zin05exm02.corp.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F1E1BF2.8070107@redback.com> Date: Wed, 23 Jul 2003 01:24:02 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: AS scope Opaque LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral V-G19459 wrote: > Hi Acee, > > >>>Minto - I think you've uncovered a problem here. A >>>router in an area other than the originating router >>>will not have route to the originating router and >>>will purge the stale DoNotAge LSA. >>> >> >>One solution would be for any router announcing any >>AS scoped LSA to advertise itself as an ASBR (as per >>its router bit in the router LSA). Other solutions >>are welcome :^) > > How about the ABR originating Type-10 opaque LSA's, with > router ID's of routers still reachable and originate > global scope LSA's, which have reachability to the ABR. Hi Vishwas, Are you suggesting that ABRs advertise reachability for all attached routers in a new LSA? If so, I don't think we want a new mechanism. It seems it would be better to just make any router originating a globally scoped LSA an ASBR than invent a new way (other than the type 4 LSA) to advertise router reachability. I may not have understood your suggestion. Thanks, Acee > > It is backward compatibility and will not create problems > about multiple LSA's being injected into the domain (in > case every router advertizes type-11's :-)). This solution > can be made generic for OSPFv3, where we can have unknown > LSA types in the future. > > Sounds reasonable? > > Thanks, > Vishwas > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 23 01:53:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06390 for ; Wed, 23 Jul 2003 01:53:39 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00A90C02@cherry.ease.lsoft.com>; Wed, 23 Jul 2003 1:53:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49178360 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 23 Jul 2003 01:53:38 -0400 Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Jul 2003 01:53:37 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h6N5rboN003782 for ; Tue, 22 Jul 2003 22:53:37 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h6N5rR7W001597 for ; Wed, 23 Jul 2003 00:53:34 -0500 Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Wed, 23 Jul 2003 11:23:26 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Message-ID: <653138C25D8AD6118292000347080A37055FBCC3@zin05exm02.corp.mot.com> Date: Wed, 23 Jul 2003 11:23:25 +0530 Reply-To: Mailing List Sender: Mailing List From: Manral V-G19459 Subject: Re: AS scope Opaque LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Acee, I was thinking along the lines you stated. Incase we were using the DC extensions the ABR would inject the information of all reachable routers to the other area in an Opaque LSA. But are you saying that we have a condition where a Router-originating Global Scope LSA's should also set itself as ASBR, whenever DC-extensions is enabled. Though a new mechanism is not introduced, the number of LSA's injected will be greatly increased. Either ways we would want to state it somewhere. It would have an impact on DC extensions for Refresh Optimizations as the LSA's would get flushed often(if we did not set the router as ASBR). I think its however more an issue with OSPFv3 where the protocol is open to any Global Scope LSA and future extensions. Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Wednesday, July 23, 2003 10:54 To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: AS scope Opaque LSA Manral V-G19459 wrote: > Hi Acee, > > >>>Minto - I think you've uncovered a problem here. A >>>router in an area other than the originating router >>>will not have route to the originating router and >>>will purge the stale DoNotAge LSA. >>> >> >>One solution would be for any router announcing any >>AS scoped LSA to advertise itself as an ASBR (as per >>its router bit in the router LSA). Other solutions >>are welcome :^) > > How about the ABR originating Type-10 opaque LSA's, with > router ID's of routers still reachable and originate > global scope LSA's, which have reachability to the ABR. Hi Vishwas, Are you suggesting that ABRs advertise reachability for all attached routers in a new LSA? If so, I don't think we want a new mechanism. It seems it would be better to just make any router originating a globally scoped LSA an ASBR than invent a new way (other than the type 4 LSA) to advertise router reachability. I may not have understood your suggestion. Thanks, Acee > > It is backward compatibility and will not create problems > about multiple LSA's being injected into the domain (in > case every router advertizes type-11's :-)). This solution > can be made generic for OSPFv3, where we can have unknown > LSA types in the future. > > Sounds reasonable? > > Thanks, > Vishwas > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 23 01:57:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06442 for ; Wed, 23 Jul 2003 01:57:55 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00A90C26@cherry.ease.lsoft.com>; Wed, 23 Jul 2003 1:57:55 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49178484 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 23 Jul 2003 01:57:46 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Jul 2003 01:57:46 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 11:27:42 +0530 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 Jul 2003 11:27:42 +0530 Reply-To: Mailing List Sender: Mailing List From: "Jeyanath Minto J - CTD, Chennai." Subject: Re: AS scope Opaque LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Vishwas, if i understood right, its not very easy to implement. What Acce Suggest is very Easy to Implement (Originate Type 4 LSA). see the issues in your apporach , 1. We Need to chose LSA (Type 10 ) Originating Router ( To avoid duplicate LSA ) 2. Handle the Area Partion. Cheers Minto Mascarenhas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Wednesday, July 23, 2003 10:54 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: AS scope Opaque LSA Manral V-G19459 wrote: > Hi Acee, > > >>>Minto - I think you've uncovered a problem here. A >>>router in an area other than the originating router >>>will not have route to the originating router and >>>will purge the stale DoNotAge LSA. >>> >> >>One solution would be for any router announcing any >>AS scoped LSA to advertise itself as an ASBR (as per >>its router bit in the router LSA). Other solutions >>are welcome :^) > > How about the ABR originating Type-10 opaque LSA's, with > router ID's of routers still reachable and originate > global scope LSA's, which have reachability to the ABR. Hi Vishwas, Are you suggesting that ABRs advertise reachability for all attached routers in a new LSA? If so, I don't think we want a new mechanism. It seems it would be better to just make any router originating a globally scoped LSA an ASBR than invent a new way (other than the type 4 LSA) to advertise router reachability. I may not have understood your suggestion. Thanks, Acee > > It is backward compatibility and will not create problems > about multiple LSA's being injected into the domain (in > case every router advertizes type-11's :-)). This solution > can be made generic for OSPFv3, where we can have unknown > LSA types in the future. > > Sounds reasonable? > > Thanks, > Vishwas > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 23 02:06:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13720 for ; Wed, 23 Jul 2003 02:06:56 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00A90E4D@cherry.ease.lsoft.com>; Wed, 23 Jul 2003 2:06:56 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49178877 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 23 Jul 2003 02:06:55 -0400 Received: from 129.188.136.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Jul 2003 02:06:54 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h6N66sub026519 for ; Tue, 22 Jul 2003 23:06:54 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h6N66n7W009775 for ; Wed, 23 Jul 2003 01:06:51 -0500 Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Wed, 23 Jul 2003 11:36:47 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <653138C25D8AD6118292000347080A37055FBCC6@zin05exm02.corp.mot.com> Date: Wed, 23 Jul 2003 11:36:46 +0530 Reply-To: Mailing List Sender: Mailing List From: Manral V-G19459 Subject: Re: AS scope Opaque LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Minto, > 1. We Need to chose LSA (Type 10 ) Originating Router > (To avoid duplicate LSA ) No reason to avoid duplicates, just like we work with summary LSA's right now. I think that will help in the second case you pointed too. Agree? Thanks, Vishwas -----Original Message----- From: Jeyanath Minto J - CTD, Chennai. [mailto:jeyananthj@CTD.HCLTECH.COM] Sent: Wednesday, July 23, 2003 11:28 To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: AS scope Opaque LSA Hi Vishwas, if i understood right, its not very easy to implement. What Acce Suggest is very Easy to Implement (Originate Type 4 LSA). see the issues in your apporach , 1. We Need to chose LSA (Type 10 ) Originating Router ( To avoid duplicate LSA ) 2. Handle the Area Partion. Cheers Minto Mascarenhas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Wednesday, July 23, 2003 10:54 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: AS scope Opaque LSA Manral V-G19459 wrote: > Hi Acee, > > >>>Minto - I think you've uncovered a problem here. A >>>router in an area other than the originating router >>>will not have route to the originating router and >>>will purge the stale DoNotAge LSA. >>> >> >>One solution would be for any router announcing any >>AS scoped LSA to advertise itself as an ASBR (as per >>its router bit in the router LSA). Other solutions >>are welcome :^) > > How about the ABR originating Type-10 opaque LSA's, with > router ID's of routers still reachable and originate > global scope LSA's, which have reachability to the ABR. Hi Vishwas, Are you suggesting that ABRs advertise reachability for all attached routers in a new LSA? If so, I don't think we want a new mechanism. It seems it would be better to just make any router originating a globally scoped LSA an ASBR than invent a new way (other than the type 4 LSA) to advertise router reachability. I may not have understood your suggestion. Thanks, Acee > > It is backward compatibility and will not create problems > about multiple LSA's being injected into the domain (in > case every router advertizes type-11's :-)). This solution > can be made generic for OSPFv3, where we can have unknown > LSA types in the future. > > Sounds reasonable? > > Thanks, > Vishwas > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 23 02:47:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03704 for ; Wed, 23 Jul 2003 02:47:30 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00A90E44@cherry.ease.lsoft.com>; Wed, 23 Jul 2003 2:47:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49180552 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 23 Jul 2003 02:47:28 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Jul 2003 02:47:28 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 12:17:24 +0530 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 Jul 2003 12:17:24 +0530 Reply-To: Mailing List Sender: Mailing List From: "Jeyanath Minto J - CTD, Chennai." Subject: Re: AS scope Opaque LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Vishwas, >>No reason to avoid duplicates, just like we work with summary LSA's right now. I think that will help in the second case >>you pointed too. >>Agree? Agreed. Sloving Opaque LSA problem by Opaque LSA is nice. but We need one more new bit to indicate the AS scope opaque LSA originator (Like ASBR bit in router LSA). Cheers, Minto >>Thanks, >>Vishwas -----Original Message----- From: Jeyanath Minto J - CTD, Chennai. [mailto:jeyananthj@CTD.HCLTECH.COM] Sent: Wednesday, July 23, 2003 11:28 To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: AS scope Opaque LSA Hi Vishwas, if i understood right, its not very easy to implement. What Acce Suggest is very Easy to Implement (Originate Type 4 LSA). see the issues in your apporach , 1. We Need to chose LSA (Type 10 ) Originating Router ( To avoid duplicate LSA ) 2. Handle the Area Partion. Cheers Minto Mascarenhas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Wednesday, July 23, 2003 10:54 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: AS scope Opaque LSA Manral V-G19459 wrote: > Hi Acee, > > >>>Minto - I think you've uncovered a problem here. A >>>router in an area other than the originating router >>>will not have route to the originating router and >>>will purge the stale DoNotAge LSA. >>> >> >>One solution would be for any router announcing any >>AS scoped LSA to advertise itself as an ASBR (as per >>its router bit in the router LSA). Other solutions >>are welcome :^) > > How about the ABR originating Type-10 opaque LSA's, with > router ID's of routers still reachable and originate > global scope LSA's, which have reachability to the ABR. Hi Vishwas, Are you suggesting that ABRs advertise reachability for all attached routers in a new LSA? If so, I don't think we want a new mechanism. It seems it would be better to just make any router originating a globally scoped LSA an ASBR than invent a new way (other than the type 4 LSA) to advertise router reachability. I may not have understood your suggestion. Thanks, Acee > > It is backward compatibility and will not create problems > about multiple LSA's being injected into the domain (in > case every router advertizes type-11's :-)). This solution > can be made generic for OSPFv3, where we can have unknown > LSA types in the future. > > Sounds reasonable? > > Thanks, > Vishwas > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 23 08:55:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10138 for ; Wed, 23 Jul 2003 08:55:28 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00A91458@cherry.ease.lsoft.com>; Wed, 23 Jul 2003 8:55:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49218567 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 23 Jul 2003 08:55:26 -0400 Received: from 202.3.77.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Jul 2003 08:55:25 -0400 Received: from [218.72.17.156] by web15207.mail.bjs.yahoo.com via HTTP; Wed, 23 Jul 2003 20:55:21 CST MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Message-ID: <20030723125521.55088.qmail@web15207.mail.bjs.yahoo.com> Date: Wed, 23 Jul 2003 20:55:21 +0800 Reply-To: Mailing List Sender: Mailing List From: =?gb2312?q?Jing=20Shen?= Subject: load distribution and smoothing when route flaps Comments: To: end2end-interest@postel.org Comments: cc: routing-discussion@ietf.org, te-wg@ops.ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Hi, (' spamcontrol ') In past days, we talked with someone from one of the main ISP in China. He present us a question as: how to smooth load migration when the primary outgoing link goes down? The network topo. could be abbreviated as: Secondary outgoing link backup link ----- ------ \ / \ / -------------------- | AS (OSPF) | -------------------- | | primary outgoing link | In normal state, about 90% outgoing traffic flows through primary outgoing link, 10% or less on Secondary link.( the bandwidht of primary is times of secondary link, which is more than backup link) The problem comes when primary outgoing link goes down. At this time, they(ISP engineers) have to redirect traffic to backup link and secondary link manually if the other two links are needed to be used, or only secondary link will carry all traffic. When primary link comes up, the phenomenon is: neary all traffic migrates to primary link and load on primary link may reach 100% or so. the questions: 1. How does those ISPs around make full use of outgoing link capacity as well as guaranteeing service quality? 2. Is there any method proposed to smooth traffic migration in either intra-AS or inter-AS situation? How does those ISPs deal with such situation? 3. Although DiffServ has been discussed for years, they do not deploy it. Why should we talk so much about DS-TE ? 4. We've spent a lot time with e2e policy around, but if the traffic delivery method is kept to very simple one, is that skeptible to achive a cost-effective and high performance network without introducing more intellenge into core networks? thanks a lot. regards ===== Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China _________________________________________________________ Do You Yahoo!? ÊîÆÚ´óƬÆë¾ÛÑÅ»¢Í¨ ÍøÂçÉãÏñÍ·+ÑÅ»¢Í¨µ÷ƵÊÕÒô»úµÈÄãÀ´Äà http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.promo.yahoo.com/minisite/messenger1/ From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 23 15:25:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26276 for ; Wed, 23 Jul 2003 15:25:40 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00A921F3@cherry.ease.lsoft.com>; Wed, 23 Jul 2003 15:25:40 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49253121 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 23 Jul 2003 15:25:39 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Jul 2003 15:15:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25444; Wed, 23 Jul 2003 15:15:37 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200307231915.PAA25444@ietf.org> Date: Wed, 23 Jul 2003 15:15:36 -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-ospfv3-mib-07.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Management Information Base for OSPFv3 Author(s) : D. Joyal, V. Manral Filename : draft-ietf-ospf-ospfv3-mib-07.txt Pages : 65 Date : 2003-7-23 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol for IPv6. Please send comments to ospf@discuss.microsoft.com. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-mib-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-mib-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-23151213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-23151213.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 24 18:36:32 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04866 for ; Thu, 24 Jul 2003 18:36:31 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00A96F74@cherry.ease.lsoft.com>; Thu, 24 Jul 2003 18:36:33 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49236995 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Jul 2003 18:11:56 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 24 Jul 2003 18:11:56 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 481213180 for ; Thu, 24 Jul 2003 15:11:55 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F2059DF.50900@redback.com> Date: Thu, 24 Jul 2003 18:12:47 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Authentication/Confidentiality for OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Please review ospf-ietf-ospf-ospfv3-auth-01.txt and send your comments to the list. I took a look at it and the only technical comment I'd have is that perhaps section 9 should describe the requirements on the IPSec implementation. Are there any implementations? We're trying to gauge whether or not this document is ready to progress. Thanks, ---- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 24 18:52:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05088 for ; Thu, 24 Jul 2003 18:52:04 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A97107@cherry.ease.lsoft.com>; Thu, 24 Jul 2003 18:52:07 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49241927 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 24 Jul 2003 18:52:06 -0400 Received: from 63.78.179.217 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 24 Jul 2003 18:52:05 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6OMq5G17318 for ; Thu, 24 Jul 2003 17:52:05 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 24 Jul 2003 17:52:04 -0500 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 24 Jul 2003 17:51:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Authentication/Confidentiality for OSPFv3 thread-index: AcNSNBKybKA/6LuIT2274+Z6FseRqQAAKfKg X-OriginalArrivalTime: 24 Jul 2003 22:51:55.0121 (UTC) FILETIME=[2E12EE10:01C35236] Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABD2C@daebe009.americas.nokia.com> Date: Thu, 24 Jul 2003 17:51:54 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: Authentication/Confidentiality for OSPFv3 Comments: cc: Nagavenkata.Melam@nokia.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee, We had received some editorial comments from Randy Presuhn some time = back. We have been trying to incorporate those comments. Sorry that we = haven't been fast in incorporating the comments but we will soon submit = the next version of the draft. We have also been thinking more about the virtual link section. There = are some more things that we wanted to propose. We will write them in = the draft too. So that people can comment on that. My opinion is that = the virtual link section of the next version needs to be reviewed by = people before we move the draft further. I have a working implementation on our OS IPSO. I haven't implemented = the virtual link part though. What do you mean by "section 9 should describe the requirements on the = IPSec implementation" ?? regards Mukesh > -----Original Message----- > From: ext Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Thursday, July 24, 2003 3:13 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Authentication/Confidentiality for OSPFv3 >=20 >=20 > Please review ospf-ietf-ospf-ospfv3-auth-01.txt and send your > comments to the list. I took a look at it and the only technical > comment I'd have is that perhaps section 9 should describe the > requirements on the IPSec implementation. >=20 > Are there any implementations? We're trying to gauge whether or > not this document is ready to progress. >=20 > Thanks, > ---- > Acee >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 25 15:35:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18249 for ; Fri, 25 Jul 2003 15:35:55 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00A9A1FE@cherry.ease.lsoft.com>; Fri, 25 Jul 2003 15:35:56 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49344509 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 25 Jul 2003 15:35:52 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 25 Jul 2003 15:25:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17180; Fri, 25 Jul 2003 15:25:46 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200307251925.PAA17180@ietf.org> Date: Fri, 25 Jul 2003 15:25:46 -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-bmwg-ospfconv-intraarea-06.txt Comments: cc: bmwg@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : Benchmarking Basic OPSF Single Router Control Plane Convergence Author(s) : V. Manral, R. White, A. Shaikh Filename : draft-ietf-bmwg-ospfconv-intraarea-06.txt Pages : 15 Date : 2003-7-25 This draft establishes standards for measuring OSPF single router control plane convergence [TERM]. Its initial emphasis is on the control plane of single OSPF routers. We do not address forwarding plane performance. NOTE: Within this document, the word convergence relates to single router control plane convergence only. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-intraarea-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-ospfconv-intraarea-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-ospfconv-intraarea-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-25144312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-ospfconv-intraarea-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-ospfconv-intraarea-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-25144312.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 25 15:35:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18251 for ; Fri, 25 Jul 2003 15:35:55 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00A9A2B2@cherry.ease.lsoft.com>; Fri, 25 Jul 2003 15:35:58 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49344511 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 25 Jul 2003 15:35:56 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 25 Jul 2003 15:25:56 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17196; Fri, 25 Jul 2003 15:25:50 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200307251925.PAA17196@ietf.org> Date: Fri, 25 Jul 2003 15:25:50 -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-bmwg-ospfconv-term-05.txt Comments: cc: bmwg@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : OSPF Benchmarking Terminology and Concepts Author(s) : V. Manral, R. White, A. Shaikh Filename : draft-ietf-bmwg-ospfconv-term-05.txt Pages : 8 Date : 2003-7-25 This draft explains the terminology and concepts used in [BENCHMARK] and future OSPF benchmarking drafts, within the context of those drafts. While some of these terms may be defined elsewhere, and we will refer the reader to those definitions in some cases, we also include discussions concerning these terms as they relate specifically to the tasks involved in benchmarking the OSPF protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-term-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-bmwg-ospfconv-term-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-bmwg-ospfconv-term-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-25144345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-ospfconv-term-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-ospfconv-term-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-25144345.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 25 15:38:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18358 for ; Fri, 25 Jul 2003 15:38:30 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00A9A19E@cherry.ease.lsoft.com>; Fri, 25 Jul 2003 15:38:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49344631 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 25 Jul 2003 15:38:32 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 25 Jul 2003 15:28:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17843; Fri, 25 Jul 2003 15:28:26 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200307251928.PAA17843@ietf.org> Date: Fri, 25 Jul 2003 15:28:26 -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-cap-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Extensions to OSPF for Advertising Optional Router Capabilities Author(s) : A. Lindem, N. Shen, R. Aggarwal, S. Shaffer, J. Vasseur Filename : draft-ietf-ospf-cap-00.txt Pages : 8 Date : 2003-7-25 It is useful for routers in an OSPF routing domain to know the capabilities of their neighbors and other routers in the OSPF routing domain. This draft proposes extensions to OSPF for advertising optional router capabilities. A new Router Information (RI) opaque LSA is proposed for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-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-ietf-ospf-cap-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-ietf-ospf-cap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-25152144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-cap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-cap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-25152144.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jul 25 15:38:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18389 for ; Fri, 25 Jul 2003 15:38:36 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00A9A328@cherry.ease.lsoft.com>; Fri, 25 Jul 2003 15:38:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49344638 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 25 Jul 2003 15:38:38 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 25 Jul 2003 15:28:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17874; Fri, 25 Jul 2003 15:28:33 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200307251928.PAA17874@ietf.org> Date: Fri, 25 Jul 2003 15:28:32 -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-08.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Graceful OSPF Restart Author(s) : J. Moy et al. Filename : draft-ietf-ospf-hitless-restart-08.txt Pages : 15 Date : 2003-7-25 This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called 'graceful restart' or 'non-stop forwarding'. A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-08.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-08.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-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-25152158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-hitless-restart-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-hitless-restart-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-25152158.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jul 27 20:15:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29777 for ; Sun, 27 Jul 2003 20:15:19 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00AA1726@cherry.ease.lsoft.com>; 27 Jul 2003 20:15:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49535730 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 27 Jul 2003 20:14:46 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 27 Jul 2003 20:14:46 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 77432822CE2 for ; Sun, 27 Jul 2003 17:14:44 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8D260779A766FB4A9C1739A476F84FA42ABD2C@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F246B00.1020505@redback.com> Date: Sun, 27 Jul 2003 20:14:56 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Authentication/Confidentiality for OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mukesh.Gupta@NOKIA.COM wrote: > Hi Acee, > > We had received some editorial comments from Randy Presuhn some time back. We have been trying to incorporate those comments. Sorry that we haven't been fast in incorporating the comments but we will soon submit the next version of the draft. > > We have also been thinking more about the virtual link section. There are some more things that we wanted to propose. We will write them in the draft too. So that people can comment on that. My opinion is that the virtual link section of the next version needs to be reviewed by people before we move the draft further. > > I have a working implementation on our OS IPSO. I haven't implemented the virtual link part though. > > What do you mean by "section 9 should describe the requirements on the IPSec implementation" ?? Hi Mukesh, I meant something like section 4.4 in RFC 2328 regarding the IPSec API. I must admit I've only read RFC 2401 twice over the last 5 years so please let me know if this comment unreasonable. Thanks, Acee > > regards > Mukesh > > >>-----Original Message----- >>From: ext Acee Lindem [mailto:acee@REDBACK.COM] >>Sent: Thursday, July 24, 2003 3:13 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Authentication/Confidentiality for OSPFv3 >> >> >>Please review ospf-ietf-ospf-ospfv3-auth-01.txt and send your >>comments to the list. I took a look at it and the only technical >>comment I'd have is that perhaps section 9 should describe the >>requirements on the IPSec implementation. >> >>Are there any implementations? We're trying to gauge whether or >>not this document is ready to progress. >> >>Thanks, >>---- >>Acee > > > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 29 12:02:14 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27207 for ; Tue, 29 Jul 2003 12:02:11 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00AA6D3F@cherry.ease.lsoft.com>; Tue, 29 Jul 2003 12:02:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49744683 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Jul 2003 12:02:04 -0400 Received: from 209.119.1.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jul 2003 11:52:04 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <15.00370DEE@grape.ease.lsoft.com>; Tue, 29 Jul 2003 11:52:04 -0400 Message-ID: Date: Tue, 29 Jul 2003 11:52:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Ashok Advani Subject: Clarification on calculating Type 7 AS-external routes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi! I would appreciate some clarification on Section 2.5-(6)(e) in RFC3101. The clause essentially extends the external route computation specified in Section 16.4 of RFC 2328 and states: (e) If the current LSA is functionally the same as an installed LSA (i.e., same destination, cost and non-zero forwarding address) then apply the following priorities in deciding which LSA is preferred: 1. A Type-7 LSA with the P-bit set. 2. A Type-5 LSA. 3. The LSA with the higher router ID. [NSSA] My understanding of this clause is that if there are multiple ABRs between an NSSA area and the backbone, then it prevents the (non-translating) ABR from installing equal cost routes for two LSAs received for the same network, one the result of translation in the backbone area, the other the result of the type 7 LSA received in the NSSA area. However, what would prevent this clause from being invoked when we have 2 ASBRs attached to the same external router on the same network intended for equal cost routing, i.e., if we had the following network [Cloud] | +-----+ | RTX | +-----+ | ------------------------------------- | | +------+ +-------+ |ASBR1 | | ASBR2 | +------+ +-------+ | | | | | +------------+ | ------|Internal Rtr|--- +------------+ In this case, it is conceivable that both ASBRs will advertise "functionally equivalent" LSAs with the same destination, cost and non-zero forwarding address, but it may be desirable to equal-cost route between the 2 ASBRs. Appreciate the clarification thx Ashok From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 29 12:25:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28320 for ; Tue, 29 Jul 2003 12:25:39 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00AA6E1F@cherry.ease.lsoft.com>; Tue, 29 Jul 2003 12:25:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49746672 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Jul 2003 12:25:25 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jul 2003 12:15:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27722; Tue, 29 Jul 2003 12:14:58 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200307291614.MAA27722@ietf.org> Date: Tue, 29 Jul 2003 12:14:58 -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-ospfv3-auth-02.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Authentication/Confidentiality for OSPFv3 Author(s) : M. Gupta, N. Melam Filename : draft-ietf-ospf-ospfv3-auth-02.txt Pages : 8 Date : 2003-7-29 This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-02.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-ospfv3-auth-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-29122730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-auth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-29122730.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 29 13:05:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01021 for ; Tue, 29 Jul 2003 13:05:38 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00AA7017@cherry.ease.lsoft.com>; Tue, 29 Jul 2003 13:05:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49750065 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Jul 2003 13:05:39 -0400 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jul 2003 13:05:39 -0400 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-24 #41392) id <01KYTSCM6RWY8X3NY1@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Jul 2003 10:05:37 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY,advani_ashok@YAHOO.COM MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01KYTSCM6RX08X3NY1@omega7.wr.usgs.gov> Date: Tue, 29 Jul 2003 10:05:37 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: Clarification on calculating Type 7 AS-external routes Comments: cc: ADVANI_ASHOK@YAHOO.COM To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Ashok, Several cases are covered here, but the primary function of the tie breaker rule is to define preference for a Type-7 LSA with the P-bit set over its Type-5 LSA translation. It also prefers the Type-5 LSA when an NSSA's ABR originates both a Type-5 LSA and a Type-7 LSA with the P-bit clear for the same network (See Section 2.4 Par. 2). As for your ?, note that functionally equivalent external LSAs of the same type should be short lived (See RFC 3101 Section 3.2, Step (2) and RFC 2328 Section 12.4.4.1, pg. 141). However, OSPF does compute multiple paths to external destinations when there are multiple paths to an LSA's non-zero forwarding address. Paths to the ASBR are consulted only when the forwarding address is 0. Hence only one LSA need be installed in your example, but it would have two paths. Finally, your assertion is correct, while functionally equivalent external LSAs of the same type should be short lived, router ID can be used by the tie breaker to define preference between two functionally equivalent external LSAs that are of the same type and, when the type is 7, have the same P-bit setting. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 29 13:47:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02183 for ; Tue, 29 Jul 2003 13:47:16 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00AA723E@cherry.ease.lsoft.com>; Tue, 29 Jul 2003 13:47:18 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49754268 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Jul 2003 13:47:16 -0400 Received: from 63.78.179.217 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jul 2003 13:47:15 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6THlGG19430 for ; Tue, 29 Jul 2003 12:47:16 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 29 Jul 2003 12:47:16 -0500 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 29 Jul 2003 12:47:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt thread-index: AcNV7glJeJKOEHgjTaeBjAjVyYN5RQACpuXg X-OriginalArrivalTime: 29 Jul 2003 17:47:05.0427 (UTC) FILETIME=[6CA1DA30:01C355F9] Message-ID: <8D260779A766FB4A9C1739A476F84FA42ABD31@daebe009.americas.nokia.com> Date: Tue, 29 Jul 2003 12:47:05 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt Comments: cc: Nagavenkata.Melam@nokia.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Here is the change log: - Mandate using the "smallest" prefix with "LA-bit" set as=20 the source and destination addresses for the packets=20 exchanged over the virtual links if the security is enabled. - Added IPsec requirements section - References divided in Normative and Informative - Some editorial changes - Some formatting errors corrected=20 regards Mukesh > -----Original Message----- > From: ext Internet-Drafts@IETF.ORG [mailto:Internet-Drafts@IETF.ORG] > Sent: Tuesday, July 29, 2003 9:15 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Open Shortest Path First IGP=20 > Working Group of the IETF. >=20 > Title : Authentication/Confidentiality for OSPFv3 > Author(s) : M. Gupta, N. Melam > Filename : draft-ietf-ospf-ospfv3-auth-02.txt > Pages : 8 > Date : 2003-7-29 >=20 > This document describes means/mechanisms to provide > authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension > Header. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-02.txt >=20 > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body=20 > of the message. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ospf-ospfv3-auth-02.txt". >=20 > 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 >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-02.txt". >=20 > 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=20 > "munpack" or > a MIME-compliant mail reader. Different=20 > MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have=20 > been split > up into multiple messages), so check your local=20 > documentation on > how to manipulate these messages. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 29 16:50:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08772 for ; Tue, 29 Jul 2003 16:50:56 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00AA77DC@cherry.ease.lsoft.com>; Tue, 29 Jul 2003 16:50:59 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49771360 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Jul 2003 16:50:55 -0400 Received: from 24.93.67.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jul 2003 16:50:55 -0400 Received: from redback.com (cpe-024-211-131-228.nc.rr.com [24.211.131.228]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h6TKn393012017 for ; Tue, 29 Jul 2003 16:49:03 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8D260779A766FB4A9C1739A476F84FA42ABD31@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F26DE23.6060200@redback.com> Date: Tue, 29 Jul 2003 16:50:43 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mukesh.Gupta@NOKIA.COM wrote: > Here is the change log: > > - Mandate using the "smallest" prefix with "LA-bit" set as > the source and destination addresses for the packets > exchanged over the virtual links if the security is > enabled. Hi Mukesh, I think choosing the first address with the LA-bit set in the intra-area prefix LSA (router ref-LSA-type) with the numerically lowest Link-State ID is more efficient, easier for both sides to implement, and gives the OSPFv3 implementation greater freedom to influence the choice of a stable address to be used for the Virtual Link endpoint. What are the arguments for making this change? It could be possible that I'm missing something :^) However, I think the dynamics are similar of handling virtual link endpoints are similar with both techniques. Thanks, Acee > > - Added IPsec requirements section > > - References divided in Normative and Informative > > - Some editorial changes > > - Some formatting errors corrected > > regards > Mukesh > > >>-----Original Message----- >>From: ext Internet-Drafts@IETF.ORG [mailto:Internet-Drafts@IETF.ORG] >>Sent: Tuesday, July 29, 2003 9:15 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt >> >> >>A New Internet-Draft is available from the on-line >>Internet-Drafts directories. >>This draft is a work item of the Open Shortest Path First IGP >>Working Group of the IETF. >> >> Title : Authentication/Confidentiality for OSPFv3 >> Author(s) : M. Gupta, N. Melam >> Filename : draft-ietf-ospf-ospfv3-auth-02.txt >> Pages : 8 >> Date : 2003-7-29 >> >>This document describes means/mechanisms to provide >>authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension >>Header. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-02.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-ospfv3-auth-02.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-02.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need >>"munpack" or >> a MIME-compliant mail reader. Different >>MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have >>been split >> up into multiple messages), so check your local >>documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. > > > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 29 21:53:18 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19390 for ; Tue, 29 Jul 2003 21:53:17 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00AA8D63@cherry.ease.lsoft.com>; Tue, 29 Jul 2003 21:52:50 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49792242 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Jul 2003 21:52:42 -0400 Received: from 131.228.20.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jul 2003 21:52:41 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h6U1qfJ13466 for ; Wed, 30 Jul 2003 04:52:41 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 30 Jul 2003 04:52:42 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 30 Jul 2003 04:52:41 +0300 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 29 Jul 2003 20:52:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt thread-index: AcNWEyPGMkKDcdk7Skineujy3j6rSAAKRlMg X-OriginalArrivalTime: 30 Jul 2003 01:52:38.0108 (UTC) FILETIME=[411031C0:01C3563D] Message-ID: <8D260779A766FB4A9C1739A476F84FA476C3A3@daebe009.americas.nokia.com> Date: Tue, 29 Jul 2003 20:52:37 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee, The only thing we need is to have the source and destination addresses = of the virtual link end points be predictable. I was told that the order = of the IP addresses in the intra-area prefix LSA is not predictable. So = choosing the first address will not provide us a deterministic address. = Moreover, the order might change without bringing the virtual link down = in which case the security rule will not match the packets. So we = decided to choose the smallest address instead of the first one. I don't know the intricacies of OSPF. So please correct me if I am = wrong. Are you suggesting that choosing the first address with LA-bit set in = the intra-area prefix LSA "with the numerically lowest Link-State ID" = will be more efficient than "choosing the smallest address with LA-bit = set" ?=20 regards Mukesh > -----Original Message----- > From: ext Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, July 29, 2003 1:51 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt >=20 >=20 > Mukesh.Gupta@NOKIA.COM wrote: > > Here is the change log: > > > > - Mandate using the "smallest" prefix with "LA-bit" set as > > the source and destination addresses for the packets > > exchanged over the virtual links if the security is > > enabled. >=20 > Hi Mukesh, >=20 > I think choosing the first address with the LA-bit set in > the intra-area prefix LSA (router ref-LSA-type) with the > numerically lowest Link-State ID is more efficient, easier for > both sides to implement, and gives the OSPFv3 implementation > greater freedom to influence the choice of a stable address > to be used for the Virtual Link endpoint. >=20 > What are the arguments for making this change? It could be possible > that I'm missing something :^) However, I think the dynamics are > similar of handling virtual link endpoints are similar with > both techniques. >=20 > Thanks, > Acee >=20 > > > > - Added IPsec requirements section > > > > - References divided in Normative and Informative > > > > - Some editorial changes > > > > - Some formatting errors corrected > > > > regards > > Mukesh > > > > > >>-----Original Message----- > >>From: ext Internet-Drafts@IETF.ORG [mailto:Internet-Drafts@IETF.ORG] > >>Sent: Tuesday, July 29, 2003 9:15 AM > >>To: OSPF@PEACH.EASE.LSOFT.COM > >>Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt > >> > >> > >>A New Internet-Draft is available from the on-line > >>Internet-Drafts directories. > >>This draft is a work item of the Open Shortest Path First IGP > >>Working Group of the IETF. > >> > >> Title : Authentication/Confidentiality for OSPFv3 > >> Author(s) : M. Gupta, N. Melam > >> Filename : draft-ietf-ospf-ospfv3-auth-02.txt > >> Pages : 8 > >> Date : 2003-7-29 > >> > >>This document describes means/mechanisms to provide > >>authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension > >>Header. > >> > >>A URL for this Internet-Draft is: > >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-a uth-02.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-ospfv3-auth-02.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-02.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need >>"munpack" or >> a MIME-compliant mail reader. Different >>MIME-compliant mail readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have >>been split >> up into multiple messages), so check your local >>documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. > > > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jul 29 22:58:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20492 for ; Tue, 29 Jul 2003 22:58:09 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00AA9065@cherry.ease.lsoft.com>; Tue, 29 Jul 2003 22:58:10 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49796762 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 29 Jul 2003 22:57:20 -0400 Received: from 12.145.55.23 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Jul 2003 22:57:20 -0400 Received: from wtn10068.opnet.com (wtn10068.opnet.com [172.16.10.68]) by mailserver1.opnet.com (8.12.9/8.12.8) with ESMTP id h6U2vLtG009844 for ; Tue, 29 Jul 2003 22:57:21 -0400 (EDT) X-Sender: azalani@mailserver.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MailScanner: Not scanned: Message-ID: <5.1.0.14.2.20030729222048.0218a630@mailserver.opnet.com> Date: Tue, 29 Jul 2003 22:57:20 -0400 Reply-To: Mailing List Sender: Mailing List From: Ashish Zalani Subject: Unequal cost multi-path routing? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA476C3A3@daebe009.americas.n okia.com> Precedence: list This may sound like a dumb question, but: Why does OSPF not support unequal cost multi-path routing, like EIGRP? Is it because unequal cost multi-path may lead to routing loops or other similar routing problems? -Ashish. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 30 00:33:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22258 for ; Wed, 30 Jul 2003 00:33:46 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00AA93D0@cherry.ease.lsoft.com>; Wed, 30 Jul 2003 0:33:37 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49814841 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Jul 2003 00:33:31 -0400 Received: from 205.158.62.67 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Jul 2003 00:33:31 -0400 Received: from 205-158-62-68.outblaze.com (205-158-62-68.outblaze.com [205.158.62.68]) by spf13.us4.outblaze.com (Postfix) with QMQP id 35C451817D3D for ; Wed, 30 Jul 2003 04:33:33 +0000 (GMT) Received: (qmail 67480 invoked from network); 30 Jul 2003 04:33:32 -0000 Received: from unknown (HELO ws5-8.us4.outblaze.com) (205.158.62.74) by 205-158-62-153.outblaze.com with SMTP; 30 Jul 2003 04:33:32 -0000 Received: (qmail 2956 invoked by uid 1001); 30 Jul 2003 04:34:17 -0000 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [203.197.138.194] by ws5-8.us4.outblaze.com with http for niveda@indiainfo.com; Wed, 30 Jul 2003 10:04:17 +0530 X-Originating-Ip: 203.197.138.194 X-Originating-Server: ws5-8.us4.outblaze.com Message-ID: <20030730043417.2955.qmail@indiainfo.com> Date: Wed, 30 Jul 2003 10:04:17 +0530 Reply-To: Mailing List Sender: Mailing List From: Niveda Monyvannan Subject: GMPLS extension for OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, As per GMPLS concept, in FA (Forwarding adjacency) link, OSPF control packet will not be sent and these are pure data channels. According to the draft draft-ietf-ccamp-ospf-gmpls-extensions-09.txt section 5, it is said that the link local identifier for an unnumbered interface is exchanged between two nodes on the specific unnumbered interface. If the unnumbered Link is a FA, how this is possible? Without Routing adjacency, how Type 9 LSA can be flooded? Am I missing Something? Regards, Niveda -- ______________________________________________ http://www.indiainfo.com Now with POP3/SMTP access for only US$14.95/yr Powered by Outblaze From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 30 01:04:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22740 for ; Wed, 30 Jul 2003 01:04:27 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00AA95DE@cherry.ease.lsoft.com>; Wed, 30 Jul 2003 1:04:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49817048 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Jul 2003 01:03:59 -0400 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Jul 2003 01:03:59 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2003 22:04:02 -0700 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6U53xuG005542 for ; Tue, 29 Jul 2003 22:04:00 -0700 (PDT) Received: from cisco.com (sjc-vpn1-40.cisco.com [10.21.96.40]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AIX77592; Tue, 29 Jul 2003 22:10:07 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8D260779A766FB4A9C1739A476F84FA476C3A3@daebe009.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F2751BD.9040108@cisco.com> Date: Tue, 29 Jul 2003 22:03:57 -0700 Reply-To: Mailing List Sender: Mailing List From: Michael J Barnes Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <8D260779A766FB4A9C1739A476F84FA476C3A3@daebe009.americas.nokia.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Mukesh, Mukesh.Gupta@NOKIA.COM wrote: > Hi Acee, > > The only thing we need is to have the source and destination addresses of the virtual link end points be predictable. I was told that the order of the IP addresses in the intra-area prefix LSA is not predictable. So choosing the first address will not provide us a deterministic address. Moreover, the order might change without bringing the virtual link down in which case the security rule will not match the packets. So we decided to choose the smallest address instead of the first one. > > I don't know the intricacies of OSPF. So please correct me if I am wrong. > > Are you suggesting that choosing the first address with LA-bit set in the intra-area prefix LSA "with the numerically lowest Link-State ID" will be more efficient than "choosing the smallest address with LA-bit set" ? I agree with Acee. To address your concern, a smart implementation will not allow the address to be unnecessarily changed (e.g. the same address with LA-bit set will be put at the beginning of the first intra-area prefix LSA unless there's a good reason to change it), so the virtual link will not flap unnecessarily. Regards, Michael > regards > Mukesh > > >>-----Original Message----- >>From: ext Acee Lindem [mailto:acee@REDBACK.COM] >>Sent: Tuesday, July 29, 2003 1:51 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt >> >> >>Mukesh.Gupta@NOKIA.COM wrote: >> >>>Here is the change log: >>> >>>- Mandate using the "smallest" prefix with "LA-bit" set as >>> the source and destination addresses for the packets >>> exchanged over the virtual links if the security is >>> enabled. >> >>Hi Mukesh, >> >>I think choosing the first address with the LA-bit set in >>the intra-area prefix LSA (router ref-LSA-type) with the >>numerically lowest Link-State ID is more efficient, easier for >>both sides to implement, and gives the OSPFv3 implementation >>greater freedom to influence the choice of a stable address >>to be used for the Virtual Link endpoint. >> >>What are the arguments for making this change? It could be possible >>that I'm missing something :^) However, I think the dynamics are >>similar of handling virtual link endpoints are similar with >>both techniques. >> >>Thanks, >>Acee >> >> >>>- Added IPsec requirements section >>> >>>- References divided in Normative and Informative >>> >>>- Some editorial changes >>> >>>- Some formatting errors corrected >>> >>>regards >>>Mukesh >>> >>> >>> >>>>-----Original Message----- >>>>From: ext Internet-Drafts@IETF.ORG [mailto:Internet-Drafts@IETF.ORG] >>>>Sent: Tuesday, July 29, 2003 9:15 AM >>>>To: OSPF@PEACH.EASE.LSOFT.COM >>>>Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt >>>> >>>> >>>>A New Internet-Draft is available from the on-line >>>>Internet-Drafts directories. >>>>This draft is a work item of the Open Shortest Path First IGP >>>>Working Group of the IETF. >>>> >>>> Title : Authentication/Confidentiality for OSPFv3 >>>> Author(s) : M. Gupta, N. Melam >>>> Filename : draft-ietf-ospf-ospfv3-auth-02.txt >>>> Pages : 8 >>>> Date : 2003-7-29 >>>> >>>>This document describes means/mechanisms to provide >>>>authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension >>>>Header. >>>> >>>>A URL for this Internet-Draft is: >>>>http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-a > > uth-02.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-ospfv3-auth-02.txt". >>> >>>A list of Internet-Drafts directories can be found in >>>http://www.ietf.org/shadow.html >>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>>Internet-Drafts can also be obtained by e-mail. >>> >>>Send a message to: >>> mailserv@ietf.org. >>>In the body type: >>> "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-02.txt". >>> >>>NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need >>>"munpack" or >>> a MIME-compliant mail reader. Different >>>MIME-compliant mail readers >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have >>>been split >>> up into multiple messages), so check your local >>>documentation on >>> how to manipulate these messages. >>> >>> >>>Below is the data which will enable a MIME compliant mail reader >>>implementation to automatically retrieve the ASCII version of the >>>Internet-Draft. >> >> >> > > > -- > Acee > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 30 01:46:40 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23704 for ; Wed, 30 Jul 2003 01:46:40 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00AA9823@cherry.ease.lsoft.com>; Wed, 30 Jul 2003 1:46:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49819913 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Jul 2003 01:45:55 -0400 Received: from 24.93.67.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Jul 2003 01:45:55 -0400 Received: from redback.com (cpe-024-211-131-228.nc.rr.com [24.211.131.228]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h6U5gkqP019126 for ; Wed, 30 Jul 2003 01:42:46 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <8D260779A766FB4A9C1739A476F84FA476C3A3@daebe009.americas.nokia.com> <3F2751BD.9040108@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F275B84.5000908@redback.com> Date: Wed, 30 Jul 2003 01:45:40 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Mukesh and Micheal, Michael J Barnes wrote: > Hi Mukesh, > > Mukesh.Gupta@NOKIA.COM wrote: > >> Hi Acee, >> >> The only thing we need is to have the source and destination addresses >> of the virtual link end points be predictable. I was told that the >> order of the IP addresses in the intra-area prefix LSA is not >> predictable. So choosing the first address will not provide us a >> deterministic address. I think allowing the implementation to select most stable address (for example, always preferring loopbacks) and making the first LA-bit set prefix in the first (or only) intra-area prefix LSA is a better strategy. > Moreover, the order might change without >> bringing the virtual link down in which case the security rule will >> not match the packets. So we decided to choose the smallest address >> instead of the first one. I don't see that this buys that much. An OSPFv3 implementation will need to detect a change in an intra-area prefix LSA. At this time it should also determine whether or not the endpoint LA-bit enabled address changes. The implementation will need to handle the case where it changes no matter what selection algorithm is used. >> >> I don't know the intricacies of OSPF. So please correct me if I am wrong. >> >> Are you suggesting that choosing the first address with LA-bit set in >> the intra-area prefix LSA "with the numerically lowest Link-State ID" >> will be more efficient than "choosing the smallest address with LA-bit >> set" ? Yes. I believe it is easier to parse prefixes in the first LSA and stop when you find one with the LA bit enabled than it is to go through all the prefixes in potentially multiple LSAs looking for the numerically smallest. > > > I agree with Acee. To address your concern, a smart implementation will not > allow the address to be unnecessarily changed (e.g. the same address with > LA-bit set will be put at the beginning of the first intra-area prefix LSA > unless there's a good reason to change it), so the virtual link will not > flap > unnecessarily. Agreed. One more point - I really don't see why the virtual link has to flap as long as the endpoint gets the updated intra-area prefix LSA prior to router dead timeout. > > Regards, > Michael > >> regards >> Mukesh >> >> >>> -----Original Message----- >>> From: ext Acee Lindem [mailto:acee@REDBACK.COM] >>> Sent: Tuesday, July 29, 2003 1:51 PM >>> To: OSPF@PEACH.EASE.LSOFT.COM >>> Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt >>> >>> >>> Mukesh.Gupta@NOKIA.COM wrote: >>> >>>> Here is the change log: >>>> >>>> - Mandate using the "smallest" prefix with "LA-bit" set as >>>> the source and destination addresses for the packets >>>> exchanged over the virtual links if the security is >>>> enabled. >>> >>> >>> Hi Mukesh, >>> >>> I think choosing the first address with the LA-bit set in >>> the intra-area prefix LSA (router ref-LSA-type) with the >>> numerically lowest Link-State ID is more efficient, easier for >>> both sides to implement, and gives the OSPFv3 implementation >>> greater freedom to influence the choice of a stable address >>> to be used for the Virtual Link endpoint. >>> >>> What are the arguments for making this change? It could be possible >>> that I'm missing something :^) However, I think the dynamics are >>> similar of handling virtual link endpoints are similar with >>> both techniques. >>> >>> Thanks, >>> Acee >>> >>> >>>> - Added IPsec requirements section >>>> >>>> - References divided in Normative and Informative >>>> >>>> - Some editorial changes >>>> >>>> - Some formatting errors corrected >>>> >>>> regards >>>> Mukesh >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Internet-Drafts@IETF.ORG [mailto:Internet-Drafts@IETF.ORG] >>>>> Sent: Tuesday, July 29, 2003 9:15 AM >>>>> To: OSPF@PEACH.EASE.LSOFT.COM >>>>> Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-02.txt >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line >>>>> Internet-Drafts directories. >>>>> This draft is a work item of the Open Shortest Path First IGP >>>>> Working Group of the IETF. >>>>> >>>>> Title : Authentication/Confidentiality for OSPFv3 >>>>> Author(s) : M. Gupta, N. Melam >>>>> Filename : draft-ietf-ospf-ospfv3-auth-02.txt >>>>> Pages : 8 >>>>> Date : 2003-7-29 >>>>> >>>>> This document describes means/mechanisms to provide >>>>> authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension >>>>> Header. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-a >>>> >> >> uth-02.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-ospfv3-auth-02.txt". >>>> >>>> A list of Internet-Drafts directories can be found in >>>> http://www.ietf.org/shadow.html >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>>> Internet-Drafts can also be obtained by e-mail. >>>> >>>> Send a message to: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-02.txt". >>>> >>>> NOTE: The mail server at ietf.org can return the document in >>>> MIME-encoded form by using the "mpack" utility. To use this >>>> feature, insert the command "ENCODING mime" before the "FILE" >>>> command. To decode the response(s), you will need >>>> "munpack" or >>>> a MIME-compliant mail reader. Different >>>> MIME-compliant mail readers >>>> exhibit different behavior, especially when dealing with >>>> "multipart" MIME messages (i.e. documents which have >>>> been split >>>> up into multiple messages), so check your local >>>> documentation on >>>> how to manipulate these messages. >>>> >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>> >>> >>> >>> >> >> >> -- >> Acee >> > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 30 09:04:21 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29443 for ; Wed, 30 Jul 2003 09:04:20 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00AAA6BD@cherry.ease.lsoft.com>; Wed, 30 Jul 2003 9:04:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49866210 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Jul 2003 09:04:18 -0400 Received: from 63.102.55.206 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Jul 2003 09:04:18 -0400 Received: by lightwave.chromisys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jul 2003 06:04:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <9D42C6E086250248810DCADA39CE7EFC97268C@nimbus> Date: Wed, 30 Jul 2003 06:04:15 -0700 Reply-To: Mailing List Sender: Mailing List From: John Drake Subject: Re: GMPLS extension for OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list RFC3477 > -----Original Message----- > From: Niveda Monyvannan [mailto:niveda@INDIAINFO.COM] > Sent: Tuesday, July 29, 2003 9:34 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: GMPLS extension for OSPF > > > Hi, > As per GMPLS concept, in FA (Forwarding adjacency) link, OSPF > control packet will not be sent and these are pure data channels. > According to the draft > draft-ietf-ccamp-ospf-gmpls-extensions-09.txt section 5, it > is said that the link local identifier for an unnumbered > interface is exchanged between two nodes on the specific > unnumbered interface. If the unnumbered Link is a FA, how > this is possible? Without Routing adjacency, how Type 9 LSA > can be flooded? > > Am I missing Something? > > Regards, > Niveda > > > -- > ______________________________________________ > http://www.indiainfo.com > Now with POP3/SMTP access for only US$14.95/yr > > Powered by Outblaze > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 30 10:44:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03724 for ; Wed, 30 Jul 2003 10:44:58 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00AAA81D@cherry.ease.lsoft.com>; Wed, 30 Jul 2003 10:45:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49872140 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Jul 2003 10:45:00 -0400 Received: from 208.236.67.13 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Jul 2003 10:44:59 -0400 Received: from excore8.hns.com (excore8.hns.com [139.85.52.126]) by gateway.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6UEiso5016485 for ; Wed, 30 Jul 2003 10:44:54 -0400 (EDT) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore8.hns.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h6UEimjK013054 for ; Wed, 30 Jul 2003 10:44:48 -0400 (EDT) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.12 |February 13, 2003) at 07/30/2003 10:42:50 AM, Serialize complete at 07/30/2003 10:42:50 AM Content-Type: multipart/alternative; boundary="=_alternative 0051185585256D73_=" Message-ID: Date: Wed, 30 Jul 2003 10:44:49 -0400 Reply-To: Mailing List Sender: Mailing List From: ashgoel@HSS.HNS.COM Subject: Re: Unequal cost multi-path routing? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multipart message in MIME format. --=_alternative 0051185585256D73_= Content-Type: text/plain; charset="us-ascii" If you are the Zalani from Jaipur(probably playing for Rajasthan), met me in scouting camp, please reply back!! --=_alternative 0051185585256D73_= Content-Type: text/html; charset="us-ascii"
If you are the Zalani from Jaipur(probably playing for Rajasthan), met me in scouting camp, please reply back!! --=_alternative 0051185585256D73_=-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jul 30 12:45:17 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07762 for ; Wed, 30 Jul 2003 12:45:17 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00AAAB52@cherry.ease.lsoft.com>; Wed, 30 Jul 2003 12:45:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49886062 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 30 Jul 2003 12:45:14 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Jul 2003 12:45:14 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id A0C8A155761; Wed, 30 Jul 2003 09:45:13 -0700 (PDT) Message-ID: <20030730164513.A0C8A155761@prattle.redback.com> Date: Wed, 30 Jul 2003 09:45:13 -0700 Reply-To: Mailing List Sender: Mailing List From: Naiming Shen Subject: Re: GMPLS extension for OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Mail from Niveda Monyvannan dated Wed, 30 Jul 2003 10:04:17 +0530 <20030730043417.2955.qmail@indiainfo.com> Precedence: list unnumbered interface in the IGP context involves a link with adjacency between two nodes, FA has nothing to do with that. FA is one side definition, no protocol packet exchange needed. whatever remote id it wants to put in is a local matter. ] Hi, ] As per GMPLS concept, in FA (Forwarding adjacency) link, OSPF ] control packet will not be sent and these are pure data channels. ] According to the draft draft-ietf-ccamp-ospf-gmpls-extensions-09.txt section 5, it is said that the link local identifier for an unnumbered interfa ce is exchanged between two nodes on the specific unnumbered interface. If the unnumbered Link is a FA, how this is possible? Without Routing adjacency, how T ype 9 LSA can be flooded? ] ] Am I missing Something? ] ] Regards, ] Niveda ] ] ] -- ] ______________________________________________ ] http://www.indiainfo.com ] Now with POP3/SMTP access for only US$14.95/yr ] ] Powered by Outblaze - Naiming From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 31 08:02:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21721 for ; Thu, 31 Jul 2003 08:02:34 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00AAD624@cherry.ease.lsoft.com>; Thu, 31 Jul 2003 8:02:34 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49994429 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 31 Jul 2003 08:02:30 -0400 Received: from 209.119.0.76 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 31 Jul 2003 08:02:30 -0400 Received: from PEACH.EASE.LSOFT.COM (walnut.ease.lsoft.com) by wnt.dc.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.FF37C130@wnt.dc.lsoft.com>; Thu, 31 Jul 2003 8:02:33 -0400 Message-ID: Date: Thu, 31 Jul 2003 08:02:30 -0400 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: ASBR reachable via multiple areas To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list All, RFC 1583 states: "AS boundary router's routing table entry must indicate a set of paths which utilize a single area." (16.1) Why not utilize all equal-cost paths through different areas? Thanks, Igor From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 31 09:31:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24791 for ; Thu, 31 Jul 2003 09:31:08 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00AAD631@cherry.ease.lsoft.com>; Thu, 31 Jul 2003 9:31:09 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49998561 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 31 Jul 2003 09:30:55 -0400 Received: from 203.199.83.28 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 31 Jul 2003 09:30:54 -0400 Received: (qmail 12410 invoked by uid 510); 31 Jul 2003 13:32:08 -0000 Received: from unknown (203.197.138.194) by rediffmail.com via HTTP; 31 jul 2003 13:32:08 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030731133208.12409.qmail@webmail18.rediffmail.com> Date: Thu, 31 Jul 2003 13:32:08 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Clarification in CSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, How the following TLVs are used in CSPF Link Protection TLV - Whether this will be a Path Constraint? How it is used in CSPF? SRLG - Assumption is that during Primary path calculation, we store the SRLG information of the links. In backup path calculation, if any of the new link belongs to SRLG of primary path link, we need to prune this link (SRLG-disjoint). Is this assumption correct or there is an requirement like "during primary path calculation itself, we need to prune the link belonging to specific SRLG (in this case, SRLG becomes one of the path constraint) Regards, Krishna ___________________________________________________ Download the hottest & happening ringtones here! OR SMS: Top tone to 7333 Click here now: http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 31 10:11:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27093 for ; Thu, 31 Jul 2003 10:11:02 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00AAD875@cherry.ease.lsoft.com>; Thu, 31 Jul 2003 10:11:03 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50001702 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 31 Jul 2003 10:10:58 -0400 Received: from 24.93.67.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 31 Jul 2003 10:10:58 -0400 Received: from redback.com (cpe-024-211-140-052.nc.rr.com [24.211.140.52]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h6VE9593002834 for ; Thu, 31 Jul 2003 10:09:05 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F292351.2080706@redback.com> Date: Thu, 31 Jul 2003 10:10:25 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: ASBR reachable via multiple areas To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Igor Miroshnik wrote: > All, > > RFC 1583 states: "AS boundary router's routing table entry must indicate a set of paths which > utilize a single area." (16.1) > Why not utilize all equal-cost paths through different areas? Hi Igor, I believe you can calculate equal cost paths through multiple areas - read section 16.4 and 16.4.1 in RFC 2328 (which obsoletes RFC 2178 which obsoletes RFC 1583). > > Thanks, > Igor > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 31 17:15:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14253 for ; Thu, 31 Jul 2003 17:15:06 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00AAF2DB@cherry.ease.lsoft.com>; Thu, 31 Jul 2003 17:15:06 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50042563 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 31 Jul 2003 17:14:35 -0400 Received: from 216.136.175.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 31 Jul 2003 17:14:35 -0400 Received: from [24.60.60.33] by web13503.mail.yahoo.com via HTTP; Thu, 31 Jul 2003 14:14:37 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030731211437.48158.qmail@web13503.mail.yahoo.com> Date: Thu, 31 Jul 2003 14:14:37 -0700 Reply-To: Mailing List Sender: Mailing List From: ROB PATH Subject: Re: ASBR reachable via multiple areas To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F292351.2080706@redback.com> Precedence: list --- Acee Lindem wrote: > Igor Miroshnik wrote: > > All, > > > > RFC 1583 states: "AS boundary router's routing > table entry must indicate a set of paths which > > utilize a single area." (16.1) > > Why not utilize all equal-cost paths through > different areas? > > Hi Igor, > > I believe you can calculate equal cost paths through > multiple > areas - read section 16.4 and 16.4.1 in RFC 2328 > (which > obsoletes RFC 2178 which obsoletes RFC 1583). > > The section 16.4 in RFC 2328 does not explicitly state that equal cost paths through multiple areas could be utilized (say for load balancing purposes). It rather states that when there are multiple least cost paths available in the routing table, the path whose associated area has the largest OSPF Area ID is chosen. Also section 16.4.1 refers to section 16.4 for choosing a path based on cost, when there are multiple paths of equal highest preferences. So it essentially means that multiple equal cost inter-area paths are not utilized. Thanks, Rob. > > > > > > Thanks, > > Igor > > > > > -- > Acee ===== Rob Path E-Mail : rob_path@yahoo.com __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 31 17:28:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14505 for ; Thu, 31 Jul 2003 17:28:18 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00AAF2E7@cherry.ease.lsoft.com>; Thu, 31 Jul 2003 17:28:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50043530 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 31 Jul 2003 17:28:17 -0400 Received: from 63.251.100.14 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 31 Jul 2003 17:28:16 -0400 Received: from mailhost.foundrynet.com (mailhost.foundrynet.com [63.251.100.20]) by smtp.foundrynet.com (8.12.8/smtp/FoundryNetworks) with ESMTP id h6VLSJ0B026426 for ; Thu, 31 Jul 2003 14:28:19 -0700 Received: from mailhost.foundrynet.com (localhost [127.0.0.1]) by mailhost.foundrynet.com (8.11.6/FoundryNetworks) with ESMTP id h6VLSJo25825 for ; Thu, 31 Jul 2003 14:28:19 -0700 Received: from aspen (ns100corpdmz.foundrynet.com [63.251.100.1]) by mailhost.foundrynet.com (8.11.6/FoundryNetworks) with SMTP id h6VLSHr25816 for ; Thu, 31 Jul 2003 14:28:17 -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.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: Date: Thu, 31 Jul 2003 14:31:13 -0700 Reply-To: Mailing List Sender: Mailing List From: Felix Lin Subject: Age increment on flooding To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F292351.2080706@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Acee, One quick question on section 13.3 (5). When flooding an LSA out, the increment of AGE field should only be on the outgoing packet instead of on the LSA in the database, right? Thanks Felix From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 31 17:47:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14772 for ; Thu, 31 Jul 2003 17:47:07 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00AAF431@cherry.ease.lsoft.com>; Thu, 31 Jul 2003 17:47:09 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50044952 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 31 Jul 2003 17:47:05 -0400 Received: from 24.93.67.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 31 Jul 2003 17:47:05 -0400 Received: from redback.com (cpe-024-211-140-052.nc.rr.com [24.211.140.52]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h6VLhsqP027969 for ; Thu, 31 Jul 2003 17:43:54 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030731211437.48158.qmail@web13503.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F298E33.5010100@redback.com> Date: Thu, 31 Jul 2003 17:46:27 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: ASBR reachable via multiple areas To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Rob, You are correct - I missed that clause in 16.4 (3) when re-reading. I should have checked my implementation before replying. I can't envision why installing an equal-costs routes through multiple areas using the same 16.4.1 selection rules could cause a routing loop or other problem. Thanks, Acee ROB PATH wrote: > --- Acee Lindem wrote: > >>Igor Miroshnik wrote: >> >>>All, >>> >>> RFC 1583 states: "AS boundary router's routing >> >>table entry must indicate a set of paths which >> >>>utilize a single area." (16.1) >>> Why not utilize all equal-cost paths through >> >>different areas? >> >>Hi Igor, >> >>I believe you can calculate equal cost paths through >>multiple >>areas - read section 16.4 and 16.4.1 in RFC 2328 >>(which >>obsoletes RFC 2178 which obsoletes RFC 1583). >> >> > > > The section 16.4 in RFC 2328 does not explicitly state > that equal cost paths through multiple areas could be > utilized (say for load balancing purposes). > > It rather states that when there are multiple > least cost paths available in the routing > table, the path whose associated area has the > largest OSPF Area ID is chosen. > > Also section 16.4.1 refers to section 16.4 for > choosing a path based on cost, when there are > multiple paths of equal highest preferences. > > So it essentially means that multiple equal cost > inter-area paths are not utilized. > > Thanks, > Rob. > > > >> >>> Thanks, >>> Igor >>> >> >> >>-- >>Acee > > > > ===== > Rob Path > E-Mail : rob_path@yahoo.com > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 31 20:08:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19489 for ; Thu, 31 Jul 2003 20:08:09 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00AAF544@cherry.ease.lsoft.com>; Fri, 1 Aug 2003 20:08:08 +2000 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50054081 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 31 Jul 2003 20:08:07 -0400 Received: from 207.217.120.46 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 31 Jul 2003 20:08:07 -0400 Received: from user-2ivfk5n.dialup.mindspring.com ([165.247.208.183] helo=earthlink.net) by grebe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19iNSo-0004R4-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 31 Jul 2003 17:08:06 -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: <3F29AA41.8C114868@earthlink.net> Date: Thu, 31 Jul 2003 16:46:09 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Age increment on flooding To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Felix, The aging of LSAs that do not have the "DNA" Do not age field set in the LSDBs must be done to age out expired LSAs. I consider flooding in two different aspects. Flooding of originated LSAs and the forwarding of non-originated LSAs. When the router first originates the LSA the age is set to 0. A new or original Sequence number is also set. Now, when the router forwards a LSA the age field should be incremented by the Interface Transit Delay field that is normally set to 1. At that time the non originated LSDB LSA age is also incremented Mitchell Erblich Sr Software Engineer ------------------------ Felix Lin wrote: > > Hi Acee, > > One quick question on section 13.3 (5). > > When flooding an LSA out, the increment of AGE field should only be on the > outgoing packet instead of on the LSA in the database, right? > > Thanks > Felix From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jul 31 21:59:14 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21663 for ; Thu, 31 Jul 2003 21:59:14 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00AAF8DC@cherry.ease.lsoft.com>; Fri, 1 Aug 2003 21:58:15 +2000 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50062424 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 31 Jul 2003 21:58:14 -0400 Received: from 24.93.67.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 31 Jul 2003 21:58:13 -0400 Received: from redback.com (cpe-024-211-140-052.nc.rr.com [24.211.140.52]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h711swqP012291 for ; Thu, 31 Jul 2003 21:54:58 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F29C90B.5020907@redback.com> Date: Thu, 31 Jul 2003 21:57:31 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Age increment on flooding To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Felix Lin wrote: > Hi Acee, Hi Felix, > > One quick question on section 13.3 (5). > > When flooding an LSA out, the increment of AGE field should only be on the > outgoing packet instead of on the LSA in the database, right? Conceptually, the LSAs have to age while in your database (refer to Section 14 in RFC 2328). There are many different ways to implement this. As you noted, you should also add IfTransDelay when flooding the LSA. > > Thanks > Felix > -- Acee