From ospf-bounces@ietf.org Wed Aug 02 02:39:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8AO7-0002z5-Py; Wed, 02 Aug 2006 02:39:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8AO6-0002y1-8g for ospf@ietf.org; Wed, 02 Aug 2006 02:39:26 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8AO4-0003Ce-Nb for ospf@ietf.org; Wed, 02 Aug 2006 02:39:26 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19YKfwp6ensRifxow+W3A8E7ErSDA8zrkw@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k726d7FZ004973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Aug 2006 07:39:20 +0100 Date: Wed, 2 Aug 2006 07:39:07 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Richard Ogier Subject: Re: [OSPF] Database Exchange Summary List Optimization In-Reply-To: <44B53B00.3030305@earthlink.net> Message-ID: References: <44B53B00.3030305@earthlink.net> Mail-Copies-To: paul@jakma.org Mail-Followup-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1630/Tue Aug 1 16:38:56 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Richard, On Wed, 12 Jul 2006, Richard Ogier wrote: > http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-00.txt > Comments? Excellent idea :). One comment though, with repsect to the suggested modifying text to 2328: " If it does not, or if the database copy is less recent (see Section 13.1), the LSA is put on the Link state request list so that it can be requested (immediately or at some later time) in Link State Request Packets. The router also looks up the LSA in the Database summary list for the neighbor. If the Database summary list contains an instance of the LSA that is the same or less recent than the one listed in the received packet, the LSA is removed from the Database summary list." The second recency comparison with the LSA on the DB-summary list seems superfluous. Additionally, it makes for mildly confusing reading to have "less recent" for one case, and "same or less recent" for the other. It could, perhaps, be better expressed in terms of just that single recency test of the database copy against the received LSA: " If it does not, or if the database copy is less recent (see Section 13.1), the LSA is put on the Link state request list so that it can be requested (immediately or at some later time) in Link State Request Packets. Additionaly, if it does and the dabase copy is the same as or less recent than the received copy, the LSA is also removed from the Database summary list, if a copy still exists on it." Which seems slightly clearer to my mind anyway. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Computer programs expand so as to fill the core available. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Aug 03 15:51:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8jDb-0001T6-2I; Thu, 03 Aug 2006 15:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8jDZ-0001NB-Kx for ospf@ietf.org; Thu, 03 Aug 2006 15:50:53 -0400 Received: from mx4.tellabs.com ([204.154.129.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8jDX-0000wS-DC for ospf@ietf.org; Thu, 03 Aug 2006 15:50:53 -0400 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 03 Aug 2006 19:50:51 +0000 X-SBRS: None X-IronPort-AV: i="4.07,209,1151884800"; d="scan'208"; a="59701053:sNHT16900196" Received: from USPAEX1.tellabs-west.tellabsinc.net ([172.26.6.39]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 3 Aug 2006 14:50:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Aug 2006 12:50:49 -0700 Message-ID: <03B46B096F6ABD4D854385A7B28C2362622A06@USPAEX1.tellabs-west.tellabsinc.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OSPFv3: Clarification on instance ID Thread-Index: AcayUTRxTLO/dUnhQsCLTPcwX2rAlwE4ZxcA From: "Goyal, Manoj" To: "OSPF List" X-OriginalArrivalTime: 03 Aug 2006 19:50:50.0929 (UTC) FILETIME=[1F624A10:01C6B736] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [OSPF] OSPFv3: Clarification on instance ID X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi, The paragraph: "In the context of this document, an OSPF instance is a separate protocol instance complete with its own protocol data structures (e.g., areas, interfaces, neighbors), link state database, protocol state machines, and protocol processes (e.g. SPF calculation)." but in the rest of the document it says that the instance ID has local link significance only and it solely affects the reception of the packets. It can also be used to have one link in more then one area. Also: "Additionally, an instance ID may be configured for virtual links from different protocol instances in order to utilize the same transit area (without requiring different router IDs for demultiplexing)." Lets look at these situations here. There are three OSPF processes running on a system: OSPF instance A : interface-1 inst-ID 10 interface-2 inst-ID 20 OSPF instance B : interface-1 inst-ID 11 interface-2 inst-ID 21 interface-3 inst-ID 31 OSPF instance C : interface-1 inst-ID 12 Area 1 interface-1 inst-ID 13 Area 2 - If the instance ID has local link significance only then all the above configurations should be valid.(??) - But, if the instance ID means that the SPF will be run only on the packets with the same instance ID, essentially mandating that one ospf process(instance) should really have all the interfaces in it assigned the same instance ID, then these configs are invalid. In this case, the same interface can not be used in more then one area of the same instance. What are your views? thanks, Manoj =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Aug 03 18:49:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8m0R-0002LH-9H; Thu, 03 Aug 2006 18:49:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8m0Q-0002L9-AP for ospf@ietf.org; Thu, 03 Aug 2006 18:49:30 -0400 Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8m0P-0002K6-2P for ospf@ietf.org; Thu, 03 Aug 2006 18:49:30 -0400 Received: from dialup-4.243.128.25.dial1.sanfrancisco1.level3.net ([4.243.128.25] helo=earthlink.net) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1G8m0N-00072e-00; Thu, 03 Aug 2006 18:49:27 -0400 Message-ID: <44D27D72.5080104@earthlink.net> Date: Thu, 03 Aug 2006 15:49:22 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Paul Jakma Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B53B00.3030305@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Paul, Thanks for your comment. Yes, I agree that we can do the comparison based on the database copy and avoid looking up the LSA on the summary list (unless it must be removed from the list). (But we still have "less recent" for the first comparison and "same or less recent" for the second comparison.) Richard Paul Jakma wrote: > Hi Richard, > > On Wed, 12 Jul 2006, Richard Ogier wrote: > >> http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-00.txt > > >> Comments? > > > Excellent idea :). > > One comment though, with repsect to the suggested modifying text to 2328: > > " If it does not, or if the database copy is less recent (see Section > 13.1), the LSA is put on the Link state request list so that it can > be requested (immediately or at some later time) in Link State > Request Packets. The router also looks up the LSA in the Database > summary list for the neighbor. If the Database summary list > contains an instance of the LSA that is the same or less recent > than the one listed in the received packet, the LSA is removed from > the Database summary list." > > The second recency comparison with the LSA on the DB-summary list > seems superfluous. Additionally, it makes for mildly confusing reading > to have "less recent" for one case, and "same or less recent" for the > other. > > It could, perhaps, be better expressed in terms of just that single > recency test of the database copy against the received LSA: > > " If it does not, or if the database copy is less recent (see Section > 13.1), the LSA is put on the Link state request list so that it can > be requested (immediately or at some later time) in Link State > Request Packets. Additionaly, if it does and the dabase copy is > the same as or less recent than the received copy, the LSA is > also removed from the Database summary list, if a copy still > exists on it." > > Which seems slightly clearer to my mind anyway. > > regards, _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Aug 04 01:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8rp4-0000Ap-7Y; Fri, 04 Aug 2006 01:02:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8rp2-000057-Ot for ospf@ietf.org; Fri, 04 Aug 2006 01:02:08 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8rp0-0003W9-Gn for ospf@ietf.org; Fri, 04 Aug 2006 01:02:08 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX18bBYmTFwe1XEuql7ADj1SkJG7ySHpGOG0@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7451lR1004615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Aug 2006 06:02:00 +0100 Date: Fri, 4 Aug 2006 06:01:47 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Richard Ogier Subject: Re: [OSPF] Database Exchange Summary List Optimization In-Reply-To: <44D27D72.5080104@earthlink.net> Message-ID: References: <44B53B00.3030305@earthlink.net> <44D27D72.5080104@earthlink.net> Mail-Copies-To: paul@jakma.org Mail-Followup-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1634/Wed Aug 2 23:32:49 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org On Thu, 3 Aug 2006, Richard Ogier wrote: > Hi Paul, > > Thanks for your comment. Yes, I agree that we can do the comparison > based on the database copy and avoid looking up the LSA on the > summary list (unless it must be removed from the list). Potentially anyway. > (But we still have "less recent" for the first comparison and > "same or less recent" for the second comparison.) Yes indeed. :) Sorry, badly worded. I think I meant that it was mildly confusing to have two tests, of two different LSA instances (potentially) against the received LSA, and to figure out exactly how they related to each other. If its the same test of the same two LSA instances, it's more clear, regardless that < and <= remain (to me anyway). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: How much net work could a network work, if a network could net work? _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Aug 08 08:11:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAQPs-0000l6-QM; Tue, 08 Aug 2006 08:10:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAQPs-0000l1-9H for ospf@ietf.org; Tue, 08 Aug 2006 08:10:36 -0400 Received: from mail-3-vl203.pcs-net.net ([217.25.84.26] helo=mail-3.pcs-net.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAQPq-0007of-Vr for ospf@ietf.org; Tue, 08 Aug 2006 08:10:36 -0400 Received: from proxy-ttk.pcs-net.net (meltdown.pcs-net.net [217.25.84.84]) by mail-3.pcs-net.net (Postfix) with ESMTP id 4B2F2A6BFC; Tue, 8 Aug 2006 16:10:16 +0400 (MSD) Date: Tue, 8 Aug 2006 16:10:16 +0400 (MSD) From: "Vladimir S. Blazhkun" To: ospf@ietf.org Message-ID: X-OpenPGP-Fingerprint: D4D7 F850 DDE5 B418 BF21 4600 9F71 80EA 73FA 758E X-OpenPGP-KeyID: 0x73FA758E X-Priority: High MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PCS-MailScanner-Information: Please contact the ISP for more information. X-PCS-MailScanner: Found to be clean X-PCS-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-PCS-MailScanner-From: v.blazhkun@pcs-net.net X-Spam-Score: 1.2 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [OSPF] LS-Update packet question. X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hello, Can anybody explain me briefly: why we need an explicit number of LSAs in LS-Update packet? Why we cannot parse this packet byte-by-byte as DD/LS-Ack packets? -- Vladimir _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Aug 08 11:33:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATa5-0004dL-KU; Tue, 08 Aug 2006 11:33:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATa4-0004dG-8r for ospf@ietf.org; Tue, 08 Aug 2006 11:33:20 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GATa2-0000tE-0r for ospf@ietf.org; Tue, 08 Aug 2006 11:33:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 Aug 2006 08:32:49 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.07,222,1151910000"; d="scan'208"; a="35146898:sNHT26316264" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k78FWnYx018465; Tue, 8 Aug 2006 11:32:49 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k78FWke4016445; Tue, 8 Aug 2006 11:32:49 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 11:32:47 -0400 Received: from [10.82.240.252] ([10.82.240.252]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Aug 2006 11:32:47 -0400 Message-ID: <44D8AE9E.4040903@cisco.com> Date: Tue, 08 Aug 2006 11:32:46 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Vladimir S. Blazhkun" Subject: Re: [OSPF] LS-Update packet question. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Aug 2006 15:32:47.0278 (UTC) FILETIME=[E67964E0:01C6BAFF] DKIM-Signature: a=rsa-sha1; q=dns; l=572; t=1155051169; x=1155915169; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20LS-Update=20packet=20question. |To:=22Vladimir=20S.=20Blazhkun=22=20; X=v=3Dcisco.com=3B=20h=3DzrRrA3908JQa9zzIc2jrVfxm+To=3D; b=ExP6PvmKO+0uOPnyfJ9Hp36E+uUz/yddlzOM9FcTwWu+3ODSZSLT2VwFJsk4CsNag9ksoHPE 5oDO6CKzmB8AAWr+TavZap2OnEqeAVpDL8UVJSRyCsKF8owJR1R+1dt4; Authentication-Results: rtp-dkim-1.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Vladimir S. Blazhkun wrote: > > Hello, > > Can anybody explain me briefly: why we need an explicit number of LSAs in > LS-Update packet? Why we cannot parse this packet byte-by-byte as > DD/LS-Ack > packets? > Hi Vladimir, I believe it is mainly historic. Since router and network LSAs are variable length, someone saw the requirement to ascertain the number of LSAs in an LS update without parsing the packet. However, I can't see a strong requirement for this. In any case, it's not something we're going to change now ;^) Hope this helps, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Aug 09 13:40:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAs2j-0003As-38; Wed, 09 Aug 2006 13:40:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAs2h-0003An-EQ for ospf@ietf.org; Wed, 09 Aug 2006 13:40:31 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAs2g-0006Ks-6N for ospf@ietf.org; Wed, 09 Aug 2006 13:40:31 -0400 Received: from rmailcenter98.comcast.net ([204.127.197.198]) by comcast.net (rwcrmhc11) with SMTP id <20060809174029m1100l4215e>; Wed, 9 Aug 2006 17:40:29 +0000 Received: from [67.176.65.21] by rmailcenter98.comcast.net; Wed, 09 Aug 2006 17:40:28 +0000 From: rickg5524@comcast.net To: ospf@ietf.org Date: Wed, 09 Aug 2006 17:40:28 +0000 Message-Id: <080920061740.24253.44DA1E0C0006269900005EBD2213575333CBCDCACA09050C079D@comcast.net> X-Mailer: AT&T Message Center Version 1 (Apr 11 2006) X-Authenticated-Sender: cmlja2c1NTI0QGNvbWNhc3QubmV0 MIME-Version: 1.0 X-Spam-Score: 1.3 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [OSPF] intra area prefix lsa change requires spf X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1405122749==" Errors-To: ospf-bounces@ietf.org --===============1405122749== Content-Type: multipart/alternative; boundary="NextPart_Webmail_9m3u9jl4l_24253_1155145228_0" --NextPart_Webmail_9m3u9jl4l_24253_1155145228_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit In section 3.5.3, RFC2740 indicates the the entire routing table is recalculated when there's a change to the router,network, intra-area and link LSAs. Why is it that a change to an intra area prefix would require a full SPF? thanks /rg --NextPart_Webmail_9m3u9jl4l_24253_1155145228_0 Content-Type: text/html Content-Transfer-Encoding: 8bit
In section 3.5.3, RFC2740 indicates the the entire routing table is recalculated when there's a change to the router,network, intra-area and link LSAs.  Why is it that a change to an intra area prefix would require a full SPF?
 
thanks
/rg
--NextPart_Webmail_9m3u9jl4l_24253_1155145228_0-- --===============1405122749== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1405122749==-- From ospf-bounces@ietf.org Wed Aug 09 13:57:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAsJQ-0004l8-AT; Wed, 09 Aug 2006 13:57:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAsJO-0004l3-Fc for ospf@ietf.org; Wed, 09 Aug 2006 13:57:46 -0400 Received: from stag.seas.upenn.edu ([158.130.70.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAsJN-0008Tj-5b for ospf@ietf.org; Wed, 09 Aug 2006 13:57:46 -0400 Received: from [158.130.53.77] (M367PC1.cis.upenn.edu [158.130.53.77]) (authenticated bits=0) by stag.seas.upenn.edu (8.13.6/8.13.6) with ESMTP id k79Hvh9F019819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Aug 2006 13:57:43 -0400 Message-ID: <44DA2216.9000608@ee.upenn.edu> Date: Wed, 09 Aug 2006 13:57:42 -0400 From: Roch Guerin User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: ospf@ietf.org Subject: Re: [OSPF] intra area prefix lsa change requires spf References: <080920061740.24253.44DA1E0C0006269900005EBD2213575333CBCDCACA09050C079D@comcast.net> In-Reply-To: <080920061740.24253.44DA1E0C0006269900005EBD2213575333CBCDCACA09050C079D@comcast.net> X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ospf@ietf.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1346091249==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============1346091249== Content-Type: multipart/alternative; boundary="------------040805060602030104090400" This is a multi-part message in MIME format. --------------040805060602030104090400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Rick, Not sure there is a unique explanation, but I would take the statement with a grain of salt as I know of a couple of implementations that do things more intelligently and indeed avoid a Dijkstra recomputation (full SPF) when the change only affects a stub network in an area (in Section 16 of RFC 2328, the intra-area routing table computation is actually broken into two steps, with the second step being dedicated to adding stubs). I think the origin of this statement is that unlike IS-IS where because reachability information is encoded into separate TLVs there is a clean demarcation between running the (full) SPF (Dijkstra) using routers, pseudo-nodes and links connecting them, and what is called the partial route computation (PRC) that involves only the prefixes and not the topology, the situation is a bit murkier in OSPF. In particular, unless you do a detailed parsing of the RouterLSAs and NetworkLSAs to determine what has changed, the receipt of a changed one will often be used as a sufficient trigger to schedule a Dijkstra computation. Now this is again a necessary but not a sufficient condition, and some implementations will perform the additional parsing required to avoid a full SPF (Dijsktra) when it is not needed. hope this helps, roch > In section 3.5.3, RFC2740 indicates the the entire routing table is > recalculated when there's a change to the router,network, intra-area > and link LSAs. Why is it that a change to an intra area prefix would > require a full SPF? > > thanks > /rg > ------------------------------------------------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > --------------040805060602030104090400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Rick,

Not sure there is a unique explanation, but I would take the statement with a grain of salt as I know of a couple of implementations that do things more intelligently and indeed avoid a Dijkstra recomputation (full SPF) when the change only affects a stub network in an area (in Section 16 of RFC 2328, the intra-area routing table computation is actually broken into two steps, with the second step being dedicated to adding stubs).

I think the origin of this statement is that unlike IS-IS where because reachability information is encoded into separate TLVs there is a clean demarcation between running the (full) SPF (Dijkstra) using routers, pseudo-nodes and links connecting them, and what is called the partial route computation (PRC) that involves only the prefixes and not the topology, the situation is a bit murkier in OSPF.  In particular, unless you do a detailed parsing of the RouterLSAs and NetworkLSAs to determine what has changed, the receipt of a changed one will often be used as a sufficient trigger to schedule a Dijkstra computation.

Now this is again a necessary but not a sufficient condition, and some implementations will perform the additional parsing required to avoid a full SPF (Dijsktra) when it is not needed.

hope this helps,

roch
In section 3.5.3, RFC2740 indicates the the entire routing table is recalculated when there's a change to the router,network, intra-area and link LSAs.  Why is it that a change to an intra area prefix would require a full SPF?
 
thanks
/rg

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf

--------------040805060602030104090400-- --===============1346091249== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1346091249==-- From ospf-bounces@ietf.org Wed Aug 09 14:07:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAsT1-00025c-NN; Wed, 09 Aug 2006 14:07:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAsSz-00025W-LL for ospf@ietf.org; Wed, 09 Aug 2006 14:07:42 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAsSy-0000rD-BW for ospf@ietf.org; Wed, 09 Aug 2006 14:07:41 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2006 14:07:40 -0400 X-IronPort-AV: i="4.08,107,1154923200"; d="scan'208"; a="95897925:sNHT26152488" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k79I7ebu031082 for ; Wed, 9 Aug 2006 14:07:40 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k79I7de2012416 for ; Wed, 9 Aug 2006 14:07:39 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 14:07:39 -0400 Received: from [10.82.240.252] ([10.82.240.252]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Aug 2006 14:07:39 -0400 Message-ID: <44DA246A.80303@cisco.com> Date: Wed, 09 Aug 2006 14:07:38 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ospf@ietf.org Subject: Re: [OSPF] intra area prefix lsa change requires spf References: <080920061740.24253.44DA1E0C0006269900005EBD2213575333CBCDCACA09050C079D@comcast.net> <44DA2216.9000608@ee.upenn.edu> In-Reply-To: <44DA2216.9000608@ee.upenn.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2006 18:07:39.0733 (UTC) FILETIME=[B39F4050:01C6BBDE] DKIM-Signature: a=rsa-sha1; q=dns; l=2832; t=1155146860; x=1156010860; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20intra=20area=20prefix=20lsa=20change=20requires=20spf |To:ospf@ietf.org; X=v=3Dcisco.com=3B=20h=3DYw3Fe2M8uTqs7oqmuJHpmzXG6tY=3D; b=iHfpboK7ilmcyqTtYQzPs8/1sNW8toZ5OBicS9DRcZ8HyI0yfZpW6tddKH9jpTcFTc6ta5RT 5HnoD3Btg7tc/28xe3dPHAnOnKbE7W8LUxfNlS1+y4RZsyMvReHCrb47; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Roch, Agree with your explainatoin - rrSee one additional comment below. Roch Guerin wrote: > Rick, > > Not sure there is a unique explanation, but I would take the statement > with a grain of salt as I know of a couple of implementations that do > things more intelligently and indeed avoid a Dijkstra recomputation > (full SPF) when the change only affects a stub network in an area (in > Section 16 of RFC 2328, the intra-area routing table computation is > actually broken into two steps, with the second step being dedicated > to adding stubs). > > I think the origin of this statement is that unlike IS-IS where > because reachability information is encoded into separate TLVs there > is a clean demarcation between running the (full) SPF (Dijkstra) using > routers, pseudo-nodes and links connecting them, and what is called > the partial route computation (PRC) that involves only the prefixes > and not the topology, the situation is a bit murkier in OSPF. In > particular, unless you do a detailed parsing of the RouterLSAs and > NetworkLSAs to determine what has changed, the receipt of a changed > one will often be used as a sufficient trigger to schedule a Dijkstra > computation. > > Now this is again a necessary but not a sufficient condition, and some > implementations will perform the additional parsing required to avoid > a full SPF (Dijsktra) when it is not needed. Exactly, in fact, this is stated explicitly in RFC 2328. The specification does not require that the above two stage method be used to calculate the shortest path tree. However, if another algorithm is used, an identical tree must be produced. For this reason, it is important to note that links between transit vertices must be bidirectional in order to be included in the above tree. It should also be mentioned that more efficient algorithms exist for calculating the tree; for example, the incremental SPF algorithm described in [Ref1]. Thanks, Acee > > hope this helps, > > roch >> In section 3.5.3, RFC2740 indicates the the entire routing table is >> recalculated when there's a change to the router,network, intra-area >> and link LSAs. Why is it that a change to an intra area prefix would >> require a full SPF? >> >> thanks >> /rg >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Aug 09 14:45:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt3H-0008LZ-SG; Wed, 09 Aug 2006 14:45:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAt3G-0008LU-Na for ospf@ietf.org; Wed, 09 Aug 2006 14:45:10 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAt3F-00049i-Ay for ospf@ietf.org; Wed, 09 Aug 2006 14:45:10 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k79Ij81Z054781; Wed, 9 Aug 2006 11:45:08 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k79Ij4g74182; Wed, 9 Aug 2006 11:45:08 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <44DA246A.80303@cisco.com> References: <080920061740.24253.44DA1E0C0006269900005EBD2213575333CBCDCACA09050C079D@comcast.net> <44DA2216.9000608@ee.upenn.edu> <44DA246A.80303@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6960A2D7-14C1-42BE-B0E4-8917F81708E4@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Subject: Re: [OSPF] intra area prefix lsa change requires spf Date: Wed, 9 Aug 2006 12:45:03 -0600 To: Acee Lindem X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org And I'll just throw in my standard rant, which is that I've yet to see an operational network where the computational cost of an SPF was enough of a concern to go to the effort of getting fancy. The costly part is seldom the SPF itself, but rather the side effects of doing it (how you handle updating forwarding tables, interaction with BGP, etc.) Those are the places to spend the effort in optimization, IMHO. --Dave On Aug 9, 2006, at 12:07 PM, Acee Lindem wrote: > Hi Roch, > Agree with your explainatoin - rrSee one additional comment below. > Roch Guerin wrote: >> Rick, >> >> Not sure there is a unique explanation, but I would take the >> statement with a grain of salt as I know of a couple of >> implementations that do things more intelligently and indeed avoid >> a Dijkstra recomputation (full SPF) when the change only affects a >> stub network in an area (in Section 16 of RFC 2328, the intra-area >> routing table computation is actually broken into two steps, with >> the second step being dedicated to adding stubs). >> >> I think the origin of this statement is that unlike IS-IS where >> because reachability information is encoded into separate TLVs >> there is a clean demarcation between running the (full) SPF >> (Dijkstra) using routers, pseudo-nodes and links connecting them, >> and what is called the partial route computation (PRC) that >> involves only the prefixes and not the topology, the situation is >> a bit murkier in OSPF. In particular, unless you do a detailed >> parsing of the RouterLSAs and NetworkLSAs to determine what has >> changed, the receipt of a changed one will often be used as a >> sufficient trigger to schedule a Dijkstra computation. >> >> Now this is again a necessary but not a sufficient condition, and >> some implementations will perform the additional parsing required >> to avoid a full SPF (Dijsktra) when it is not needed. > Exactly, in fact, this is stated explicitly in RFC 2328. > > The specification does not require that the above two stage > method be used to calculate the shortest path tree. > However, if > another algorithm is used, an identical tree must be produced. > For this reason, it is important to note that links between > transit vertices must be bidirectional in order to be included > in the above tree. It should also be mentioned that more > efficient algorithms exist for calculating the tree; for > example, the incremental SPF algorithm described in [Ref1]. > > Thanks, > Acee >> >> hope this helps, >> >> roch >>> In section 3.5.3, RFC2740 indicates the the entire routing table >>> is recalculated when there's a change to the router,network, >>> intra-area and link LSAs. Why is it that a change to an intra >>> area prefix would require a full SPF? >>> thanks >>> /rg >>> -------------------------------------------------------------------- >>> ---- >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ospf >>> >> >> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Aug 09 16:53:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAv3B-0005vl-DD; Wed, 09 Aug 2006 16:53:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAv39-0005vb-P1 for ospf@ietf.org; Wed, 09 Aug 2006 16:53:11 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAv37-0002HL-98 for ospf@ietf.org; Wed, 09 Aug 2006 16:53:11 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VypJN9HbBZzpWwQx96NyTkCKu1I3c7xV06pHcP5jP9OgYGbBjpH9qzxf9BiKrQxB; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.84.9] (helo=earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GAv2q-0007ao-QD; Wed, 09 Aug 2006 16:52:53 -0400 Message-ID: <44DA4A6F.53CB0A96@earthlink.net> Date: Wed, 09 Aug 2006 13:49:51 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Dave Katz Subject: Re: [OSPF] intra area prefix lsa change requires spf References: <080920061740.24253.44DA1E0C0006269900005EBD2213575333CBCDCACA09050C079D@comcast.net> <44DA2216.9000608@ee.upenn.edu> <44DA246A.80303@cisco.com> <6960A2D7-14C1-42BE-B0E4-8917F81708E4@juniper.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec791b7acef50e8334abb8d8321c94ba288b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.84.9 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Group, I am not sure I completely aggree with Mr. Katz.. I am also abit more verbose. Their are times within within large areas, over a period of time, where the number of changing (new) LSAs are significant. With cheaper slow main memory, the size of the SPF routing tables can grow. It is sometimes worth while to minimize the amount of summarization of routes, so the now non summarized routes can be differentiated in their costs. Additionally, a BGP draft is currently looking at increasing the number of redundant/alternate routes that could be advertised. So, these routing tables can grow unbounded with some scaling SPF issues. Some implementations require about 2 dozen main memory lookups just to determine if a LSA is new. During these times, you COULD be trying to minimize the number of repeated SPF calculations. Their are some optimizations that can be done for some types of LSAs, but consume more memory. some of the optimizations allow very fast routing table changes at a fraction of normal time. It is important to at least minimize the local forwarding abnomalies and where fast (10Gb Eth) interfaces are present, where even a short delay can result in longer term disruptions. If a flow was a TCP flow, even a single mis-routed segment, can result in a temporary drop to 50% of the pre-loss bandwidth. TCP with its then congestion avoidance functionally can take 1 round-trip-time per loss of the 50% of in-flight segments to regain its previous bandwidth. Just trying to show some interaction... So, lets continue.. The forwarding tables are rather limited in size due to the additional cost of the forwarding table memory. The cost is their to allow very fast forwarding. This limits the amount of time one can spend changing the forwarding tables. Sometimes the design requires extra cycles to change the forwarding tables versus just making forwarding decisions based on them. Some implementations may use default type routes. One can not change how fast a UPdate OSPF pkt will be recieved and processed by a neighbor which will result in a forwarding change. However if a implementation was smart enough to determine that a recieved LSA would result in a SPF calc trigger, one might want to force a immediate Update that only includes those LSA(s)to the next neighbors. This would prioritize those LSAs to the neighbor, and then after a short time, send the normal age update LSAs.. Mitchell Erblich ---------------------- Dave Katz wrote: > > And I'll just throw in my standard rant, which is that I've yet to > see an operational network where the computational cost of an SPF was > enough of a concern to go to the effort of getting fancy. > > The costly part is seldom the SPF itself, but rather the side effects > of doing it (how you handle updating forwarding tables, interaction > with BGP, etc.) Those are the places to spend the effort in > optimization, IMHO. > > --Dave > > On Aug 9, 2006, at 12:07 PM, Acee Lindem wrote: > > > Hi Roch, > > Agree with your explainatoin - rrSee one additional comment below. > > Roch Guerin wrote: > >> Rick, > >> > >> Not sure there is a unique explanation, but I would take the > >> statement with a grain of salt as I know of a couple of > >> implementations that do things more intelligently and indeed avoid > >> a Dijkstra recomputation (full SPF) when the change only affects a > >> stub network in an area (in Section 16 of RFC 2328, the intra-area > >> routing table computation is actually broken into two steps, with > >> the second step being dedicated to adding stubs). > >> > >> I think the origin of this statement is that unlike IS-IS where > >> because reachability information is encoded into separate TLVs > >> there is a clean demarcation between running the (full) SPF > >> (Dijkstra) using routers, pseudo-nodes and links connecting them, > >> and what is called the partial route computation (PRC) that > >> involves only the prefixes and not the topology, the situation is > >> a bit murkier in OSPF. In particular, unless you do a detailed > >> parsing of the RouterLSAs and NetworkLSAs to determine what has > >> changed, the receipt of a changed one will often be used as a > >> sufficient trigger to schedule a Dijkstra computation. > >> > >> Now this is again a necessary but not a sufficient condition, and > >> some implementations will perform the additional parsing required > >> to avoid a full SPF (Dijsktra) when it is not needed. > > Exactly, in fact, this is stated explicitly in RFC 2328. > > > > The specification does not require that the above two stage > > method be used to calculate the shortest path tree. > > However, if > > another algorithm is used, an identical tree must be produced. > > For this reason, it is important to note that links between > > transit vertices must be bidirectional in order to be included > > in the above tree. It should also be mentioned that more > > efficient algorithms exist for calculating the tree; for > > example, the incremental SPF algorithm described in [Ref1]. > > > > Thanks, > > Acee > >> > >> hope this helps, > >> > >> roch > >>> In section 3.5.3, RFC2740 indicates the the entire routing table > >>> is recalculated when there's a change to the router,network, > >>> intra-area and link LSAs. Why is it that a change to an intra > >>> area prefix would require a full SPF? > >>> thanks > >>> /rg > >>> -------------------------------------------------------------------- > >>> ---- > >>> > >>> _______________________________________________ > >>> OSPF mailing list > >>> OSPF@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ospf > >>> > >> > >> > >> --------------------------------------------------------------------- > >> --- > >> > >> _______________________________________________ > >> OSPF mailing list > >> OSPF@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ospf > >> > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Aug 09 17:08:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvHv-0001VH-Fg; Wed, 09 Aug 2006 17:08:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAvHt-0001V7-Lr for ospf@ietf.org; Wed, 09 Aug 2006 17:08:25 -0400 Received: from stag.seas.upenn.edu ([158.130.70.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAvHs-0003Ph-CT for ospf@ietf.org; Wed, 09 Aug 2006 17:08:25 -0400 Received: from [158.130.53.77] (M367PC1.cis.upenn.edu [158.130.53.77]) (authenticated bits=0) by stag.seas.upenn.edu (8.13.6/8.13.6) with ESMTP id k79L8NsA022305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Aug 2006 17:08:23 -0400 Message-ID: <44DA4EC7.6030407@ee.upenn.edu> Date: Wed, 09 Aug 2006 17:08:23 -0400 From: Roch Guerin User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Erblichs Subject: Re: [OSPF] intra area prefix lsa change requires spf References: <080920061740.24253.44DA1E0C0006269900005EBD2213575333CBCDCACA09050C079D@comcast.net> <44DA2216.9000608@ee.upenn.edu> <44DA246A.80303@cisco.com> <6960A2D7-14C1-42BE-B0E4-8917F81708E4@juniper.net> <44DA4A6F.53CB0A96@earthlink.net> In-Reply-To: <44DA4A6F.53CB0A96@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Mitchell, I think that what Dave was pointing out is that in most (large) networks where one could expect the cost of an SPF to be an issue, it is actually not significant (per instance) compared to the cost of updating the routing/forwarding table and other dependent processes. The case of BGP provides a good example, as the issue is more the impact on the BGP decision process that you will need to rerun and that could involve scanning 250k entries, and that alone will take more time than the SPF itself. And then you have the added cost of updating the forwarding entries of all those BGP prefixes whose Next_Hop just changed because of the SPF change. There is actually a reasonably good discussion of this whole issue and how it is dealt with in two major implementations in a recent book on IS-IS by Gredler and Goralski, Springer, 2005 (no endorsement intended). So in general, I agree with Dave that in most/all reasonably designed networks, the actual SPF cost will pale in comparison to some of the other overheads involved in updating routing tables. Now, you can certainly create situations where the SPF computation does become a bottleneck (I've seen a network with one huge OSPF area - several hundred routers - and thousands of local prefixes, where one flaky router was regularly bringing the network down because of SPF computations), but they should be the exception rather than the rule. Roch > Group, > > I am not sure I completely aggree with Mr. Katz.. > > I am also abit more verbose. > > Their are times within within large areas, over a period of > time, where the number of changing (new) LSAs are significant. > With cheaper slow main memory, the size of the SPF routing tables > can grow. It is sometimes worth while to minimize the amount > of summarization of routes, so the now non summarized routes > can be differentiated in their costs. Additionally, a BGP draft is > currently looking at increasing the number of redundant/alternate > routes that could be advertised. So, these routing tables can > grow unbounded with some scaling SPF issues. Some implementations > require about 2 dozen main memory lookups just to determine if > a LSA is new. > > During these times, you COULD be trying to minimize the number > of repeated SPF calculations. Their are some optimizations that > can be done for some types of LSAs, but consume more memory. some > of the optimizations allow very fast routing table changes at > a fraction of normal time. > > It is important to at least minimize the local forwarding > abnomalies and where fast (10Gb Eth) interfaces are present, > where even a short delay can result in longer term disruptions. > If a flow was a TCP flow, even a single mis-routed segment, > can result in a temporary drop to 50% of the pre-loss bandwidth. > TCP with its then congestion avoidance functionally can take > 1 round-trip-time per loss of the 50% of in-flight segments > to regain its previous bandwidth. > Just trying to show some interaction... > > > So, lets continue.. > The forwarding tables are rather limited in size due to the > additional cost of the forwarding table memory. The cost is > their to allow very fast forwarding. This limits > the amount of time one can spend changing the forwarding tables. > Sometimes the design requires extra cycles to change the > forwarding tables versus just making forwarding decisions based > on them. Some implementations may use default type routes. > > One can not change how fast a UPdate OSPF pkt will be recieved > and processed by a neighbor which will result in a forwarding > change. However if a implementation was smart enough to > determine that a recieved LSA would result in a SPF calc trigger, > one might want to force a immediate Update that only includes > those LSA(s)to the next neighbors. This would prioritize those > LSAs to the neighbor, and then after a short time, send the > normal age update LSAs.. > > Mitchell Erblich > ---------------------- > > > > > Dave Katz wrote: > >> And I'll just throw in my standard rant, which is that I've yet to >> see an operational network where the computational cost of an SPF was >> enough of a concern to go to the effort of getting fancy. >> >> The costly part is seldom the SPF itself, but rather the side effects >> of doing it (how you handle updating forwarding tables, interaction >> with BGP, etc.) Those are the places to spend the effort in >> optimization, IMHO. >> >> --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Aug 09 18:19:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwOj-00056h-B8; Wed, 09 Aug 2006 18:19:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwOi-00056b-47 for ospf@ietf.org; Wed, 09 Aug 2006 18:19:32 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAwOg-00035q-Lb for ospf@ietf.org; Wed, 09 Aug 2006 18:19:32 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=CbiibTI/+By6ert9HxISWkj0Wh/U6f5PKEEMCh67KR3UGnsR1VBXQ1RK19DS3y5x; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.84.9] (helo=earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GAwOf-0000FY-H6; Wed, 09 Aug 2006 18:19:29 -0400 Message-ID: <44DA5DD3.837863A2@earthlink.net> Date: Wed, 09 Aug 2006 15:12:35 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Roch Guerin Subject: Re: [OSPF] intra area prefix lsa change requires spf References: <080920061740.24253.44DA1E0C0006269900005EBD2213575333CBCDCACA09050C079D@comcast.net> <44DA2216.9000608@ee.upenn.edu> <44DA246A.80303@cisco.com> <6960A2D7-14C1-42BE-B0E4-8917F81708E4@juniper.net> <44DA4A6F.53CB0A96@earthlink.net> <44DA4EC7.6030407@ee.upenn.edu> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7977adb0c1ea5f2e00db8b4acf729081ea350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.84.9 X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Roch Guerin, Let me try to be abit more succinct. which restates the below.. If one major component of cost is the time to complete a task. Then the cost or time is significantly greater for the routing table than the forwarding table. The biggest reason for this is because the forwarding tables need faster memory. If we assume that forwarding table memory is 4x faster than routing table memory, then if we complete a forwarding table memory task 2x as fast and keep the other constant, we only have about a 10% speeedup, ' however, if we double the speed of a routing table task, than we can improve by about 40%. Thus, improving the speed of the equiv of SPF processing gives us a decent improvement, which leads to my disagreement. Yes, this is Amdahls Law.. However, if we measure all of the tasks that are needed for a rec'ved LSA over time, most are LSA age updates, which removes the need for SPF calcs, and thus increases the chance that a improvent elsewhere would be more beneficial. Mitchell Erblich ----------------- Roch Guerin wrote: > > Mitchell, > > I think that what Dave was pointing out is that in most (large) networks > where one could expect the cost of an SPF to be an issue, it is actually > not significant (per instance) compared to the cost of updating the > routing/forwarding table and other dependent processes. > > The case of BGP provides a good example, as the issue is more the impact > on the BGP decision process that you will need to rerun and that could > involve scanning 250k entries, and that alone will take more time than > the SPF itself. And then you have the added cost of updating the > forwarding entries of all those BGP prefixes whose Next_Hop just changed > because of the SPF change. There is actually a reasonably good > discussion of this whole issue and how it is dealt with in two major > implementations in a recent book on IS-IS by Gredler and Goralski, > Springer, 2005 (no endorsement intended). > > So in general, I agree with Dave that in most/all reasonably designed > networks, the actual SPF cost will pale in comparison to some of the > other overheads involved in updating routing tables. Now, you can > certainly create situations where the SPF computation does become a > bottleneck (I've seen a network with one huge OSPF area - several > hundred routers - and thousands of local prefixes, where one flaky > router was regularly bringing the network down because of SPF > computations), but they should be the exception rather than the rule. > > Roch > > Group, > > > > I am not sure I completely aggree with Mr. Katz.. > > > > I am also abit more verbose. > > > > Their are times within within large areas, over a period of > > time, where the number of changing (new) LSAs are significant. > > With cheaper slow main memory, the size of the SPF routing tables > > can grow. It is sometimes worth while to minimize the amount > > of summarization of routes, so the now non summarized routes > > can be differentiated in their costs. Additionally, a BGP draft is > > currently looking at increasing the number of redundant/alternate > > routes that could be advertised. So, these routing tables can > > grow unbounded with some scaling SPF issues. Some implementations > > require about 2 dozen main memory lookups just to determine if > > a LSA is new. > > > > During these times, you COULD be trying to minimize the number > > of repeated SPF calculations. Their are some optimizations that > > can be done for some types of LSAs, but consume more memory. some > > of the optimizations allow very fast routing table changes at > > a fraction of normal time. > > > > It is important to at least minimize the local forwarding > > abnomalies and where fast (10Gb Eth) interfaces are present, > > where even a short delay can result in longer term disruptions. > > If a flow was a TCP flow, even a single mis-routed segment, > > can result in a temporary drop to 50% of the pre-loss bandwidth. > > TCP with its then congestion avoidance functionally can take > > 1 round-trip-time per loss of the 50% of in-flight segments > > to regain its previous bandwidth. > > Just trying to show some interaction... > > > > > > So, lets continue.. > > The forwarding tables are rather limited in size due to the > > additional cost of the forwarding table memory. The cost is > > their to allow very fast forwarding. This limits > > the amount of time one can spend changing the forwarding tables. > > Sometimes the design requires extra cycles to change the > > forwarding tables versus just making forwarding decisions based > > on them. Some implementations may use default type routes. > > > > One can not change how fast a UPdate OSPF pkt will be recieved > > and processed by a neighbor which will result in a forwarding > > change. However if a implementation was smart enough to > > determine that a recieved LSA would result in a SPF calc trigger, > > one might want to force a immediate Update that only includes > > those LSA(s)to the next neighbors. This would prioritize those > > LSAs to the neighbor, and then after a short time, send the > > normal age update LSAs.. > > > > Mitchell Erblich > > ---------------------- > > > > > > > > > > Dave Katz wrote: > > > >> And I'll just throw in my standard rant, which is that I've yet to > >> see an operational network where the computational cost of an SPF was > >> enough of a concern to go to the effort of getting fancy. > >> > >> The costly part is seldom the SPF itself, but rather the side effects > >> of doing it (how you handle updating forwarding tables, interaction > >> with BGP, etc.) Those are the places to spend the effort in > >> optimization, IMHO. > >> > >> --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Aug 09 19:54:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAxsK-0008TL-IQ; Wed, 09 Aug 2006 19:54:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAxsJ-0008TF-GW for ospf@ietf.org; Wed, 09 Aug 2006 19:54:11 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAxsI-0006a5-3T for ospf@ietf.org; Wed, 09 Aug 2006 19:54:11 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k79Ns8X38772; Wed, 9 Aug 2006 16:54:08 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k79Ns2g30844; Wed, 9 Aug 2006 16:54:03 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <44DA5DD3.837863A2@earthlink.net> References: <080920061740.24253.44DA1E0C0006269900005EBD2213575333CBCDCACA09050C079D@comcast.net> <44DA2216.9000608@ee.upenn.edu> <44DA246A.80303@cisco.com> <6960A2D7-14C1-42BE-B0E4-8917F81708E4@juniper.net> <44DA4A6F.53CB0A96@earthlink.net> <44DA4EC7.6030407@ee.upenn.edu> <44DA5DD3.837863A2@earthlink.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Subject: Re: [OSPF] intra area prefix lsa change requires spf Date: Wed, 9 Aug 2006 17:54:01 -0600 To: Erblichs X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org On Aug 9, 2006, at 4:12 PM, Erblichs wrote: > Roch Guerin, > > Let me try to be abit more succinct. which restates > the below.. > > If one major component of cost is the time to > complete a task. > > Then the cost or time is significantly greater > for the routing table than the forwarding table. > > The biggest reason for this is because the forwarding > tables need faster memory. If we assume that forwarding > table memory is 4x faster than routing table memory, > > then if we complete a forwarding table memory task 2x as > fast and keep the other constant, we only have about a > 10% speeedup, > > ' however, if we double the speed of a routing table task, > than we can improve by about 40%. This is all *extremely* dependent on hardware architecture, and further makes the assumption that the largest component of time is the memory access speed, which is very unlikely. For the architectures I'm familiar with, updating the forwarding table is *much* more expensive than tinkering with internal OSPF stuff, and that has *nothing* to do with memory speed. > > Thus, improving the speed of the equiv of SPF processing > gives us a decent improvement, which leads to my disagreement. > Yes, this is Amdahls Law.. > > However, if we measure all of the tasks that are needed > for a rec'ved LSA over time, most are LSA age updates, which > removes the need for SPF calcs, and thus increases the > chance that a improvent elsewhere would be more beneficial. You're further making an assumption that reducing the overall instruction count over time is (a) beneficial, and (b) worth adding system complexity for. Both are debatable and lie at the heart of system design. You seem to be making a common mistake, which is looking at a small piece of the puzzle and trying to optimize that, while ignoring the cost of doing so in reliability and stability. Taking your earlier example, where you wish to switch the forwarding table as fast as possible in the face of a failure, you have to take a look at the entire time budget between the event causing the problem (the backhoe cuts the fiber) and the restoral time. The cost of doing a full SPF is likely to be a small fraction of this process, and the gains in optimizing the process will be a small fraction of that small fraction. If you can get the time budget for all the rest of this so that it doesn't overwhelm the cost of a full SPF versus some kind of shortcut, then it's time to start talking about gains in route calcuation. --Dave _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Aug 09 21:49:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAzfe-0001IE-EI; Wed, 09 Aug 2006 21:49:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAzfd-0001I6-4L for ospf@ietf.org; Wed, 09 Aug 2006 21:49:13 -0400 Received: from [69.37.59.173] (helo=workhorse.brookfield.occnc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAzfZ-0006tt-N2 for ospf@ietf.org; Wed, 09 Aug 2006 21:49:13 -0400 Received: from workhorse.brookfield.occnc.com (localhost [127.0.0.1]) by workhorse.brookfield.occnc.com (8.13.4/8.13.4) with ESMTP id k7A1u57Z066032; Wed, 9 Aug 2006 21:56:05 -0400 (EDT) (envelope-from curtis@workhorse.brookfield.occnc.com) Message-Id: <200608100156.k7A1u57Z066032@workhorse.brookfield.occnc.com> To: Erblichs Subject: Re: [OSPF] intra area prefix lsa change requires spf In-reply-to: Your message of "Wed, 09 Aug 2006 15:12:35 PDT." <44DA5DD3.837863A2@earthlink.net> Date: Wed, 09 Aug 2006 21:56:05 -0400 From: Curtis Villamizar X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: curtis@occnc.com List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org In message <44DA5DD3.837863A2@earthlink.net> Erblichs writes: > > > The biggest reason for this is because the forwarding > tables need faster memory. If we assume that forwarding > table memory is 4x faster than routing table memory, Nice try but ... The forwarding memory is on another card in a reasonably big router and therefore the information has to be trasferred from one processor to another and then installed in the forwarding memory. Also the forwarding memory is primarily used for forwarding and in a big busy router not too many cycles are left over for the writes that update the forwarding memory due to the reads that are occurring concurrently. In some architectures this is minimized. For example, some may use memory caching techniques others dual memory banks, etc. But perhaps the biggest factor is that the few hundred or few thousand IGP routes are the basis for BGP next hops so after they are computed the few 100,000 BGP routes and forwarding entries are mapped onto the SPF results. Since there are usually more than 100 times as many BGP routes as IGP routes doubling the speed of the SPF has no effect. In any case, Dave is right. The SPF typically takes far less time than the things that happen as a result of the SPF. Curtis ps - OTOH the speed of the MPLS/TE CSPF is very significant. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Aug 10 16:01:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBGiB-0000fs-9f; Thu, 10 Aug 2006 16:00:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBGiA-0000eE-40 for ospf@ietf.org; Thu, 10 Aug 2006 16:00:58 -0400 Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBGi7-0005Zd-RK for ospf@ietf.org; Thu, 10 Aug 2006 16:00:58 -0400 Received: from dialup-4.243.131.152.dial1.sanfrancisco1.level3.net ([4.243.131.152] helo=earthlink.net) by pop-scotia.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1GBGi6-0003w7-00 for ospf@ietf.org; Thu, 10 Aug 2006 16:00:55 -0400 Message-ID: <44DB9074.8000700@earthlink.net> Date: Thu, 10 Aug 2006 13:00:52 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: OSPF List Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B7E563.3000706@cisco.com> <44B7E6D0.6030304@cisco.com> <44BD1FE6.2030202@earthlink.net> <44CAAB32.4B2A546D@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org I have submitted the following updated draft: http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-01.txt The update incorporates comments of others and some ideas I presented in my post on 7/18/2006. In particular, it describes three options that differ in whether the LSAs must be listed in lexicographical order and whether a router must fully process a received DD packet before sending its next DD packet. To summarize: In Option A, the router is required to fully process a received DD packet before sending the next DD packet in reply. (LSAs are not listed in lexicographical order.) In Option B, the router with the larger DR level performs database exchange as in RFC 2328 without change. The router with the smaller DR level sends only empty DD packets (with no LSA headers) until it has received the entire summary list from its neighbor (indicated by M = 0), and then lists only LSAs that are more recent than those received. I forgot to mention in the draft that Option B applies only to broadcast (or MANET) interfaces. In Option C, the master lists LSAs in lexicographical order and the slave lists LSAs in reverse lexicographical order, as suggested by Mitchell Erblich. Regarding recent comments by Mitchell, I am not yet convinced that there is any benefit to detecting whether a neighbor is nearly in sync and using the optimization (with one of the three options) only if the neighbor is nearly in sync, versus simply employing the optimization. For example, in MANETs, it appears best to simply employ the optimization with Option A. Maybe you can provide a concrete, realistic example. Even if it does help to detect whether a neighbor is nearly in sync, I am not sure that the (informational) document I am working on needs to specify such a detection mechanism. Such a mechanism could be specified in a separate document. Instead, the document I am working on can just state that such a mechanism can be employed if desired. If two routers are performing database exchange, the protocol does not fail if only one of the routers decides to use the optimization, or if one router decides to use Option A while the other decides to use Option B or C. Of course, this optimization was motivated because we wanted to reduce overhead in MANETs, and I would prefer to keep the document as simple as possible. Richard _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From MAILER-DAEMON Fri Aug 11 00:23:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBOYB-00042V-5f for ospf-archive@lists.ietf.org; Fri, 11 Aug 2006 00:23:11 -0400 Received: from omr-m06.mx.aol.com ([64.12.138.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBOY9-0004P4-VB for ospf-archive@lists.ietf.org; Fri, 11 Aug 2006 00:23:11 -0400 Received: from rly-na06.mx.aol.com (rly-na06.mail.aol.com [172.18.151.235]) by omr-m06.mx.aol.com (v107.10) with ESMTP id RELAYIN4-544dc061b23d; Fri, 11 Aug 2006 00:22:51 -0400 Received: from localhost (localhost) by rly-na06.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with internal id AAJ01674; Fri, 11 Aug 2006 00:22:51 -0400 (EDT) Date: Fri, 11 Aug 2006 00:22:51 -0400 (EDT) From: Mail Delivery Subsystem Message-Id: <200608110422.AAJ01674@rly-na06.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="AAJ01674.1155270171/rly-na06.mx.aol.com" Subject: Returned mail: User unknown Auto-Submitted: auto-generated (failure) X-AOL-IP: 172.18.151.235 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 This is a MIME-encapsulated message --AAJ01674.1155270171/rly-na06.mx.aol.com The original message was received at Fri, 11 Aug 2006 00:22:39 -0400 (EDT) from dumy97.panafonet.gr [195.46.1.97] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to air-na02.mail.aol.com.: >>> RCPT To: <<< 550 MAILBOX NOT FOUND 550 ... User unknown --AAJ01674.1155270171/rly-na06.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-na06.mx.aol.com Arrival-Date: Fri, 11 Aug 2006 00:22:39 -0400 (EDT) Final-Recipient: RFC822; johndoe@netscape.net Action: failed Status: 5.1.1 Remote-MTA: DNS; air-na02.mail.aol.com Diagnostic-Code: SMTP; 550 MAILBOX NOT FOUND Last-Attempt-Date: Fri, 11 Aug 2006 00:22:51 -0400 (EDT) --AAJ01674.1155270171/rly-na06.mx.aol.com Content-Type: text/rfc822-headers Received: from lists.ietf.org (dumy97.panafonet.gr [195.46.1.97]) by rly-na06.mx.aol.com (v111.7) with ESMTP id MAILRELAYINNA66-6b044dc06052ea; Fri, 11 Aug 2006 00:22:30 -0400 From: ospf-archive@lists.ietf.org To: johndoe@netscape.net Subject: Rbex Date: Fri, 11 Aug 2006 07:22:05 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_D4965FB8.6D7F2397" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-AOL-IP: 195.46.1.97 X-AOL-SCOLL-SCORE: 0:2:392344856:11005853 X-AOL-SCOLL-URL_COUNT: 0 Message-ID: <200608110022.6b044dc06052ea@rly-na06.mx.aol.com> X-AOL-INRLY: dumy97.panafonet.gr [195.46.1.97] rly-na06 --AAJ01674.1155270171/rly-na06.mx.aol.com-- From ospf-bounces@ietf.org Fri Aug 11 11:54:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBZL0-0001Ui-EP; Fri, 11 Aug 2006 11:54:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBZKz-0001Ud-7p for ospf@ietf.org; Fri, 11 Aug 2006 11:54:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBZKw-0007nh-Vr for ospf@ietf.org; Fri, 11 Aug 2006 11:54:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Aug 2006 08:54:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.08,115,1154934000"; d="scan'208"; a="35707218:sNHT23934140" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7BFs9WV016524; Fri, 11 Aug 2006 11:54:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7BFs6eB024584; Fri, 11 Aug 2006 11:54:09 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 11:54:03 -0400 Received: from [10.82.240.252] ([10.82.240.252]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 11:54:02 -0400 Message-ID: <44DCA819.4000802@cisco.com> Date: Fri, 11 Aug 2006 11:54:01 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: OSPF List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Aug 2006 15:54:02.0680 (UTC) FILETIME=[5DE98B80:01C6BD5E] DKIM-Signature: a=rsa-sha1; q=dns; l=631; t=1155311649; x=1156175649; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:draft-ietf-ccamp-automesh-01.txt |To:OSPF=20List=20; X=v=3Dcisco.com=3B=20h=3DI+69hKI3dlxSqGBxbvQluv6UlHw=3D; b=JjpdxfdyuZnvDIg+ESxDu6RIqLslFydQsRU1ZAFWo/iAJkhMO18ofGyZnU4U9iyU/R8WX3NP jTW6DUpNXlUT+YTpRH5Xmbg1PWVYfYjVC2hqquG9DZGFraTovI/bbYM0; Authentication-Results: rtp-dkim-2.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: David Ward Subject: [OSPF] draft-ietf-ccamp-automesh-01.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org The above draft makes use of the OSPF capabilities LSA. It is my understanding that it has been last called in the ccamp WG. We are now last calling it in the OSPF and ISIS WGs. The last call will start today (August 11, 2006) and end at 12:00 AM on August 26th, 2006. Please copy this list and the document editors (JP Vasseur and JL Leroux) with your comments. You can also copy the ccamp list if you are subscribed (I believe the list is closed though I'm not sure since I am subscribed). Here is a link for you convenience: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-01.txt Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Aug 11 14:06:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbOT-0002q6-4A; Fri, 11 Aug 2006 14:06:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBbOS-0002m0-42 for ospf@ietf.org; Fri, 11 Aug 2006 14:06:00 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBbOP-0001qO-Oe for ospf@ietf.org; Fri, 11 Aug 2006 14:06:00 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k7BI5vI4000788 for ; Fri, 11 Aug 2006 14:05:57 -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 OAA25402 for ; Fri, 11 Aug 2006 14:05:57 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 11 Aug 2006 14:05:56 -0400 Message-ID: <5551AD75D2C0BC459A85A2CEFAE4F80050CAB6@usvissfp01.win.marconi.com> From: "Naidu, Venkata" To: "'ospf@ietf.org'" Subject: RE: [OSPF] intra area prefix lsa change requires spf Date: Fri, 11 Aug 2006 14:05:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0402137756==" Errors-To: ospf-bounces@ietf.org 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. --===============0402137756== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6BD70.CA66504C" 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_01C6BD70.CA66504C Content-Type: text/plain; charset="iso-8859-1" Roch, The question is about OSPFv3 (RFC2740) not about OSPFv2 (RFC2328). OSPFv3 separates topology information from reachability information just like ISIS. I think, the answer to the question is: NO, change to a prefix LSA doesn't need SPF (neither full nor partial). If you arranged your data structures to reflect last SPT, simply locate the node and then update (add/modify/delete) routes using the new prefix LSA. This is not an optimization to SPF. I would say an implementation doing full SPF when a prefix LSA is changed is wasting time because it would get the same SPT anyway. Just because post SPF work (updating FIB etc) is time consuming, wasting time in doing unnecessary (full SPF) is not a good implementation either. Venkata. I think the origin of this statement is that unlike IS-IS where because reachability information is encoded into separate TLVs there is a clean demarcation between running the (full) SPF (Dijkstra) using routers, pseudo-nodes and links connecting them, and what is called the partial route computation (PRC) that involves only the prefixes and not the topology, the situation is a bit murkier in OSPF. In section 3.5.3, RFC2740 indicates the the entire routing table is recalculated when there's a change to the router,network, intra-area and link LSAs. Why is it that a change to an intra area prefix would require a full SPF? ------_=_NextPart_001_01C6BD70.CA66504C Content-Type: text/html; charset="iso-8859-1"
Roch,
 
The question is about OSPFv3 (RFC2740) not about OSPFv2 (RFC2328). OSPFv3 separates topology information from reachability information just like ISIS.
 
I think, the answer to the question is: NO, change to a prefix LSA doesn't need SPF (neither full nor partial).  If you arranged your data structures to reflect
last SPT, simply locate the node and then update (add/modify/delete) routes using the new prefix LSA. This is not an optimization to SPF. I would say an
implementation doing full SPF when a prefix LSA is changed is wasting time because it would get the same SPT anyway. Just because post SPF work
(updating FIB etc) is time consuming, wasting time in doing unnecessary (full SPF) is not a good implementation either.
 
Venkata.
I think the origin of this statement is that unlike IS-IS where because reachability information is encoded into separate TLVs there is a clean demarcation between running the (full) SPF (Dijkstra) using routers, pseudo-nodes and links connecting them, and what is called the partial route computation (PRC) that involves only the prefixes and not the topology, the situation is a bit murkier in OSPF.  
 
 
In section 3.5.3, RFC2740 indicates the the entire routing table is recalculated when there's a change to the router,network, intra-area and link LSAs.  Why is it that a change to an intra area prefix would require a full SPF?
------_=_NextPart_001_01C6BD70.CA66504C-- --===============0402137756== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0402137756==-- From ospf-bounces@ietf.org Fri Aug 11 16:39:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBdmp-0001rR-2U; Fri, 11 Aug 2006 16:39:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBdmn-0001rM-J2 for ospf@ietf.org; Fri, 11 Aug 2006 16:39:17 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBdml-0007K7-4Z for ospf@ietf.org; Fri, 11 Aug 2006 16:39:17 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=CmiKmDDyTSSIqOc2czNJnFuPlxyv906usZOb74A0+DWulaApKZjsr+yKBCX4zOjr; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.88.39] (helo=earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GBdmU-0005Pj-Io; Fri, 11 Aug 2006 16:38:58 -0400 Message-ID: <44DCEB28.A5ADAD8C@earthlink.net> Date: Fri, 11 Aug 2006 13:40:08 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: curtis@occnc.com Subject: Re: [OSPF] intra area prefix lsa change requires spf References: <200608100156.k7A1u57Z066032@workhorse.brookfield.occnc.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7994532b3c637711ee84f17bcb95752d7a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.88.39 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Curtis Villamizar and Mr Katz, First, let me state as I did earlier, I do feel more resources dealing with handling of Updates pkts containing refresh age LSAs WOULD yield a higher benefit. And since we are not able to speed up a REMOTE router's execution of of various tasks, we need to concentrate on our on local tasks to allow US to LOCALLY converge ASAP. But, we are in this forwarding table vs OSPF routing table costs, benefit analysis.. Lets see if we agree on these things. 1) Most LSAs recieved are just age refresh LSAs, thus they have no effect on SPF calcs. 2) Most SPF calcs do not result in a lower cost route or in some implementations a additional equal cost route. 3) Even if a OSPF routing table will yield a better cost route than earlier in time, due to administrative distances that newer cost, may not still be used. Then the forwarding table mods are rarely even done! So, why would you want to spend time to decrease the latency of a operation on such a infrequent event????? If subsec hellos or equivalent operation was used, I would first verify that nbr lookups are efficent.. The freq/repeativeness of a operation, if speeded up, should yield the best results.. So, if we aggregate the number of repeativeness operations, we need to do 1 lookup per recived LSA within our routing table. Most of these will result in age refreshes. So, first, the LSA lookup is stressed the most. Then if we had a extremely fast SPF type calcs based on different LSA types / triggers, we COULD re-run repetive calcs withoout forcing a delay. A delay is standand in our industry. However, if we agree with #2 and #3, then the only reason for the delay is due to slower SPF calcs. I agree some minimal delay is necessary to verify that all new LSAs within a single Update, given that a full ajacency has already been established, should be implemented. Lastly, bringing back up the forwarding table. The table COULD be considered somewhat like a cache. Specific atomic operations are normally implimented because of single change entries. A operation could simply Invalidate an entry. This is a single small amount of data that needs to be transfered and even slow PCI buses are capable of handling a infrequent data with minimal latency. Most of this is done in hardware. Sorry, it is a don't care whether their are multiple readers for a entry if that entry needs to be invalidated or updated. We don't wait for the readers to finish. We need to pre-empt them NOW. Thus, given appropriate resouces, I would creare a set of equal LM Bench micro benchmarks, against the routing table and identify what items are given higher priorities. I would not be surprised if these items had not already been given quite a bit of fine tuning.. The only major issues are the best case versus worse case numbers, and whether those best case numbers can be improved while not increasing the worse case numbers. Lastly, the assumption is whether BGP is in the environment? If it is, IMO TCP would be the limiting factor. TCP will not allow a large burst of data on a periodiclly idle connection. Most implmentations will fall into a slow start methodology. This is the same problem with LDP even when a path has been established with a specified bandwidth. TCP most likely will initially get in the way and only after a sustained number of segments transmitted will it allow the bandwidth to increase 1 segment per round-trip-time (rtt). This is known as the congestion avoidance (CA) phase. Mitchell Erblich ------------------- Curtis Villamizar wrote: > > In message <44DA5DD3.837863A2@earthlink.net> > Erblichs writes: > > > > > > The biggest reason for this is because the forwarding > > tables need faster memory. If we assume that forwarding > > table memory is 4x faster than routing table memory, > > Nice try but ... > > The forwarding memory is on another card in a reasonably big router > and therefore the information has to be trasferred from one processor > to another and then installed in the forwarding memory. > > Also the forwarding memory is primarily used for forwarding and in a > big busy router not too many cycles are left over for the writes that > update the forwarding memory due to the reads that are occurring > concurrently. In some architectures this is minimized. For example, > some may use memory caching techniques others dual memory banks, etc. > > But perhaps the biggest factor is that the few hundred or few thousand > IGP routes are the basis for BGP next hops so after they are computed > the few 100,000 BGP routes and forwarding entries are mapped onto the > SPF results. Since there are usually more than 100 times as many BGP > routes as IGP routes doubling the speed of the SPF has no effect. > > In any case, Dave is right. The SPF typically takes far less time > than the things that happen as a result of the SPF. > > Curtis > > ps - OTOH the speed of the MPLS/TE CSPF is very significant. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Aug 11 18:17:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBfJY-00037l-08; Fri, 11 Aug 2006 18:17:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBfJX-00037g-5Q for ospf@ietf.org; Fri, 11 Aug 2006 18:17:11 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBfJW-0005dw-Id for ospf@ietf.org; Fri, 11 Aug 2006 18:17:11 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k7BMH6X78766; Fri, 11 Aug 2006 15:17:06 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7BMGvg58562; Fri, 11 Aug 2006 15:17:01 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <44DCEB28.A5ADAD8C@earthlink.net> References: <200608100156.k7A1u57Z066032@workhorse.brookfield.occnc.com> <44DCEB28.A5ADAD8C@earthlink.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dave Katz Subject: Re: [OSPF] intra area prefix lsa change requires spf Date: Fri, 11 Aug 2006 16:16:55 -0600 To: Erblichs X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Rather than dragging this on any further, I'll just restate my basic point, and then drop it, which is that optimization must be viewed holistically, at a system-wide (and network-wide) level. The fact is that the folks implementing the most widely-used protocol code choose their optimizations carefully. There is a cost to every optimization, in the time and effort (and money) to do it, and in the additional complexity that inevitably comes with it, which impacts stability and maintainability. There are obvious, easy optimizations (don't run SPF when a leaf node changes, don't run SPF if you know that the LSA contents didn't change, etc.) that everybody does. However, when you get into the more arcane stuff (like partial SPFs and the like) where the code is decidedly nontrivial and the systemic benefits are marginal, it becomes much more murky. In the case of large routers, where the forwarding engine is typically somewhat decoupled from the route engine, the value such optimizations is marginal indeed. I'm happier, and my customers are happier, when I can give them a box that works and is stable and doesn't break when the code gets changed. Could I shave cycles off of the process? Absolutely. Do I care? No, because I'm not in any danger of running out of cycles, and the benefit of shaving those cycles is low, and I worry about optimizing the cases that really *do* matter. This is what's known as "engineering." --Dave On Aug 11, 2006, at 2:40 PM, Erblichs wrote: > Curtis Villamizar and Mr Katz, > > First, let me state as I did earlier, I do feel more resources > dealing with handling of Updates pkts containing refresh age > LSAs WOULD yield a higher benefit. And since we are not able > to speed up a REMOTE router's execution of of various tasks, we > need to concentrate on our on local tasks to allow US to LOCALLY > converge ASAP. > > But, we are in this forwarding table vs OSPF routing table > costs, benefit analysis.. > > Lets see if we agree on these things. > > 1) Most LSAs recieved are just age refresh LSAs, thus they > have no effect on SPF calcs. > > 2) Most SPF calcs do not result in a lower cost route or > in some implementations a additional equal cost route. > > 3) Even if a OSPF routing table will yield a better cost > route than earlier in time, due to administrative > distances that newer cost, may not still be used. > > Then the forwarding table mods are rarely even done! > So, why would you want to spend time to decrease the > latency of a operation on such a infrequent event????? > > If subsec hellos or equivalent operation was used, I would > first verify that nbr lookups are efficent.. > > The freq/repeativeness of a operation, if speeded up, should > yield the best results.. > > So, if we aggregate the number of repeativeness operations, we > need to do 1 lookup per recived LSA within our routing table. > Most of these will result in age refreshes. So, first, the > LSA lookup is stressed the most. > > Then if we had a extremely fast SPF type calcs based on different > LSA types / triggers, we COULD re-run repetive calcs withoout forcing > a delay. A delay is standand in our industry. However, if we agree > with #2 and #3, then the only reason for the delay is due to slower > SPF calcs. I agree some minimal delay is necessary to verify that > all new LSAs within a single Update, given that a full ajacency has > already been established, should be implemented. > > Lastly, bringing back up the forwarding table. The table COULD be > considered somewhat like a cache. Specific atomic operations are > normally > implimented because of single change entries. A operation could > simply Invalidate an entry. This is a single small amount of data > that > needs to be transfered and even slow PCI buses are capable of > handling > a infrequent data with minimal latency. Most of this is done in > hardware. Sorry, it is a don't care whether their are multiple > readers > for a entry if that entry needs to be invalidated or updated. We > don't > wait for the readers to finish. We need to pre-empt them NOW. > > Thus, given appropriate resouces, I would creare a set of equal LM > Bench > micro benchmarks, against the routing table and identify what > items are > given higher priorities. I would not be surprised if these items had > not already been given quite a bit of fine tuning.. > > The only major issues are the best case versus worse case numbers, > and whether those best case numbers can be improved while not > increasing the worse case numbers. > > Lastly, the assumption is whether BGP is in the environment? If it > is, > IMO TCP would be the limiting factor. TCP will not allow a large > burst > of data on a periodiclly idle connection. Most implmentations will > fall > into a slow start methodology. This is the same problem with LDP even > when a path has been established with a specified bandwidth. TCP most > likely will initially get in the way and only after a sustained > number > of segments transmitted will it allow the bandwidth to increase 1 > segment per round-trip-time (rtt). This is known as the congestion > avoidance (CA) phase. > > > Mitchell Erblich > > ------------------- > > > > > > > Curtis Villamizar wrote: >> >> In message <44DA5DD3.837863A2@earthlink.net> >> Erblichs writes: >>> >>> >>> The biggest reason for this is because the forwarding >>> tables need faster memory. If we assume that forwarding >>> table memory is 4x faster than routing table memory, >> >> Nice try but ... >> >> The forwarding memory is on another card in a reasonably big router >> and therefore the information has to be trasferred from one processor >> to another and then installed in the forwarding memory. >> >> Also the forwarding memory is primarily used for forwarding and in a >> big busy router not too many cycles are left over for the writes that >> update the forwarding memory due to the reads that are occurring >> concurrently. In some architectures this is minimized. For example, >> some may use memory caching techniques others dual memory banks, etc. >> >> But perhaps the biggest factor is that the few hundred or few >> thousand >> IGP routes are the basis for BGP next hops so after they are computed >> the few 100,000 BGP routes and forwarding entries are mapped onto the >> SPF results. Since there are usually more than 100 times as many BGP >> routes as IGP routes doubling the speed of the SPF has no effect. >> >> In any case, Dave is right. The SPF typically takes far less time >> than the things that happen as a result of the SPF. >> >> Curtis >> >> ps - OTOH the speed of the MPLS/TE CSPF is very significant. > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Aug 11 18:30:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBfWP-0005sC-SH; Fri, 11 Aug 2006 18:30:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBfWO-0005s6-3S for ospf@ietf.org; Fri, 11 Aug 2006 18:30:28 -0400 Received: from webmail.tropos.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GBfWK-0006Dj-O9 for ospf@ietf.org; Fri, 11 Aug 2006 18:30:28 -0400 Received: (qmail 23762 invoked from network); 11 Aug 2006 22:28:31 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.2 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 11 Aug 2006 22:28:31 -0000 Received: from LIPC ([192.168.1.130]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Aug 2006 15:28:04 -0700 From: "Tony Li" To: "'Dave Katz'" , "'Erblichs'" Subject: RE: [OSPF] intra area prefix lsa change requires spf Date: Fri, 11 Aug 2006 15:28:02 -0700 Message-ID: <006f01c6bd95$6853ffb0$487d14ac@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-index: Aca9k+4mTBsQLRwXRLO5D6FAxV2n2gAAVKpw X-OriginalArrivalTime: 11 Aug 2006 22:28:04.0423 (UTC) FILETIME=[697D3D70:01C6BD95] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org > This is what's known as "engineering." And the converse is known as "pointless micro-optimization". ;-) Tony _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Aug 18 00:29:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDvyN-0007VJ-CF; Fri, 18 Aug 2006 00:28:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDvyM-0007VD-9r for ospf@ietf.org; Fri, 18 Aug 2006 00:28:42 -0400 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDvyL-0007Wg-2A for ospf@ietf.org; Fri, 18 Aug 2006 00:28:42 -0400 Received: by wx-out-0506.google.com with SMTP id h30so720109wxd for ; Thu, 17 Aug 2006 21:28:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=A1SsdknxXnVo9FfLVXUJjViRdiT4ebuHF0r+dKa2D57mPjbf6dBb1Fen0c2LzVybPZOwW8GCGzwQFTeGpgO4DHDGzXsIAgSUA1yn5WYIguM9L2V+lM907NwUiy1exvurTaTkFGW/0hufCLAzK8NW8+nVNs+MQk9B0cEfco4uJ1M= Received: by 10.70.21.4 with SMTP id 4mr4048202wxu; Thu, 17 Aug 2006 21:28:40 -0700 (PDT) Received: by 10.70.33.3 with HTTP; Thu, 17 Aug 2006 21:28:40 -0700 (PDT) Message-ID: <77ead0ec0608172128y25db0cf9s168f880318c7b08@mail.gmail.com> Date: Fri, 18 Aug 2006 09:58:40 +0530 From: "Vishwas Manral" To: ospf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Manav Bhatia Subject: [OSPF] Revised OSPF HMAC SHA Authentication Draft X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi, We have updated the OSPF HMAC-SHA authentication draft with the comments that we received on the list and offline. The updated version has a short section which discusses backwards compatibility, similarities and differences from using MD5 (which is explained in Section 5 of 2328), etc. http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha- 02.txt Please let us know if there are further modifications desired. Cheers, Manav, Vishwas, et al. ----- Original Message ----- From: To: Sent: Friday, August 18, 2006 1:20 AM Subject: I-D ACTION:draft-bhatia-manral-white-ospf-hmac-sha-02.txt > >A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : OSPF HMAC Cryptographic Authentication > > Author(s) : M. Bhatia, et al. > > Filename : draft-bhatia-manral-white-ospf-hmac-sha-02.txt > > Pages : 11 > > Date : 2006-8-17 > > > > This document describes a mechanism for authenticating OSPF packets > > by making use of the HMAC algorithm in conjunction with the SHA > > family of cryptographic hash functions. Because of the way the hash > > functions are used in HMAC construction, the collision attacks > > currently known against SHA-1 do not apply. > > > > This will be done in addition to the already documented > > authentication schemes described in the base specification. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha- 02.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-bhatia-manral-white-ospf-hmac-sha-02.txt". _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Aug 18 14:20:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE8wL-0007cJ-Pc; Fri, 18 Aug 2006 14:19:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GE8wK-0007cB-Fd for ospf@ietf.org; Fri, 18 Aug 2006 14:19:28 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE8wH-00057j-2q for ospf@ietf.org; Fri, 18 Aug 2006 14:19:28 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Q4DhqV0tHUKgGlpimqBZl35WB3D2iZfDrY6DmVPTWEOMGqTpFuWytNI+OsRVChm7; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.88.39] (helo=earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GE8wE-0000Zd-Cs; Fri, 18 Aug 2006 14:19:22 -0400 Message-ID: <44E604FE.25C78187@earthlink.net> Date: Fri, 18 Aug 2006 11:20:46 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Vishwas Manral Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft References: <77ead0ec0608172128y25db0cf9s168f880318c7b08@mail.gmail.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79fde0a95476b974096674f0969b2439b4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.88.39 X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ospf@ietf.org, Manav Bhatia X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Vishwas Manral, et al, RFC 2328 specificly specifies "message digest" in section D3. I am not expert in this field, but wouldn't a section why Type 2 shouldn't then be reserved for MD5? It should ALSO be a simple argument that any type 2 before now was using MD5. Thus it is a defacto standard for the type. And then and a aditional type by allocated for HMAC-SHA auth. Mitchell Erblich ---------------- Vishwas Manral wrote: > > Hi, > > We have updated the OSPF HMAC-SHA authentication draft with the comments > that we received on the list and offline. > > The updated version has a short section which discusses backwards > compatibility, similarities and differences from using MD5 (which is > explained in Section 5 of 2328), etc. > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha- > 02.txt > > Please let us know if there are further modifications desired. > > Cheers, > Manav, Vishwas, et al. > > ----- Original Message ----- > From: > To: > Sent: Friday, August 18, 2006 1:20 AM > Subject: I-D ACTION:draft-bhatia-manral-white-ospf-hmac-sha-02.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : OSPF HMAC Cryptographic Authentication > > > Author(s) : M. Bhatia, et al. > > > Filename : draft-bhatia-manral-white-ospf-hmac-sha-02.txt > > > Pages : 11 > > > Date : 2006-8-17 > > > > > > This document describes a mechanism for authenticating OSPF packets > > > by making use of the HMAC algorithm in conjunction with the SHA > > > family of cryptographic hash functions. Because of the way the hash > > > functions are used in HMAC construction, the collision attacks > > > currently known against SHA-1 do not apply. > > > > > > This will be done in addition to the already documented > > > authentication schemes described in the base specification. > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha- > 02.txt > > > > > > To remove yourself from the I-D Announcement list, send a message to > > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > > the message. > > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > > username "anonymous" and a password of your e-mail address. After > > > logging in, type "cd internet-drafts" and then > > > "get draft-bhatia-manral-white-ospf-hmac-sha-02.txt". > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Aug 18 16:50:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEBGh-0003Zp-PY; Fri, 18 Aug 2006 16:48:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEBGf-0003Yo-Qi for ospf@ietf.org; Fri, 18 Aug 2006 16:48:37 -0400 Received: from web25402.mail.ukl.yahoo.com ([217.12.10.136]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GEBGe-0006Pz-BA for ospf@ietf.org; Fri, 18 Aug 2006 16:48:37 -0400 Received: (qmail 36932 invoked by uid 60001); 18 Aug 2006 20:48:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=xIaAM8UGF0IQxqV+3NRU6jVSgY2O1IKXdid5V9HwhTyvsNpu96t71IikqDBWhVFOHZ0cp+FYkHPRSIm47BkrIlBKi06t0MoP25e1TmtDQBLiBg8Fqx/kdMyVyNgstUvxKRUJk2HVZhNmMfhjkS7FZ3fzjK8w94kL1Q+fsBcAVgo= ; Message-ID: <20060818204824.36930.qmail@web25402.mail.ukl.yahoo.com> Received: from [202.144.106.189] by web25402.mail.ukl.yahoo.com via HTTP; Fri, 18 Aug 2006 20:48:24 GMT Date: Fri, 18 Aug 2006 20:48:24 +0000 (GMT) From: Manav Bhatia Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft To: Erblichs , Vishwas Manral In-Reply-To: <44E604FE.25C78187@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.9 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manav Bhatia List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Mitchell, Type 2 in RFC 2328 is not reserved for MD5, but is instead used to denote some sort of Cryptographic Authentication as opposed to NULL authentication and simple password scheme. Refer to Figure 2 in our draft. It shows the way the authentication data must be filled in the OSPF header if the Authentication Type is set to 2. Cryptographic Authentication (Type 2) as defined in RFC 2328 allows for any auth algorithm to be used without altering the protocol packets. This is done by including the Key ID in the authentication data. Key ID carried in the packet uniquely identifies an OSPF SA and gives the authentication algorithm and the secret key that is used to create the message digest appended to the OSPF packet. If the Key ID maps to a HMAC-SHA algorithm then the HMAC is appended to the OSPF packet instead of the MD5 digest. Cheers, Manav ----- Original Message ---- From: Erblichs To: Vishwas Manral Cc: ospf@ietf.org; Manav Bhatia Sent: Friday, 18 August, 2006 11:50:46 PM Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft Vishwas Manral, et al, RFC 2328 specificly specifies "message digest" in section D3. I am not expert in this field, but wouldn't a section why Type 2 shouldn't then be reserved for MD5? It should ALSO be a simple argument that any type 2 before now was using MD5. Thus it is a defacto standard for the type. And then and a aditional type by allocated for HMAC-SHA auth. Mitchell Erblich ---------------- Vishwas Manral wrote: > > Hi, > > We have updated the OSPF HMAC-SHA authentication draft with the comments > that we received on the list and offline. > > The updated version has a short section which discusses backwards > compatibility, similarities and differences from using MD5 (which is > explained in Section 5 of 2328), etc. > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha- > 02.txt > > Please let us know if there are further modifications desired. > > Cheers, > Manav, Vishwas, et al. > > ----- Original Message ----- > From: > To: > Sent: Friday, August 18, 2006 1:20 AM > Subject: I-D ACTION:draft-bhatia-manral-white-ospf-hmac-sha-02.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : OSPF HMAC Cryptographic Authentication > > > Author(s) : M. Bhatia, et al. > > > Filename : draft-bhatia-manral-white-ospf-hmac-sha-02.txt > > > Pages : 11 > > > Date : 2006-8-17 > > > > > > This document describes a mechanism for authenticating OSPF packets > > > by making use of the HMAC algorithm in conjunction with the SHA > > > family of cryptographic hash functions. Because of the way the hash > > > functions are used in HMAC construction, the collision attacks > > > currently known against SHA-1 do not apply. > > > > > > This will be done in addition to the already documented > > > authentication schemes described in the base specification. > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha- > 02.txt > > > > > > To remove yourself from the I-D Announcement list, send a message to > > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > > the message. > > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > > username "anonymous" and a password of your e-mail address. After > > > logging in, type "cd internet-drafts" and then > > > "get draft-bhatia-manral-white-ospf-hmac-sha-02.txt". > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Fri Aug 18 18:06:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GECTF-0005eH-93; Fri, 18 Aug 2006 18:05:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GECTD-0005eA-K4 for ospf@ietf.org; Fri, 18 Aug 2006 18:05:39 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GECTC-0007vN-48 for ospf@ietf.org; Fri, 18 Aug 2006 18:05:39 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=d7VDvJiBZdFwq94lvCgK0pj2Kf9NIYHRvahikliPsxAYS/ikBgNgsUaeEy673ceM; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.88.39] (helo=earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GECTA-0007hZ-Jg; Fri, 18 Aug 2006 18:05:37 -0400 Message-ID: <44E63935.3804B63C@earthlink.net> Date: Fri, 18 Aug 2006 15:03:33 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Manav Bhatia , ospf@ietf.org Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft References: <20060818204824.36930.qmail@web25402.mail.ukl.yahoo.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec794be579d07b284ad46aa78e42804c7686350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.88.39 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Manav Bhatia, Did you read my email and my arguments. I am only concerned/dealing with interoperability... The Secondly section deals with Key-ID.. Section D3 specifies MD5 as the only auth method. It specificly stated "message digest". 1) Do you agree? In every implementation that I know of type 2 is MD5. That makes it a MD5 "defacto standard" with respect to type 2. 2) Do you agree? Do you know what is meant as a "defacto standard"? Please inform me of at least 1 implmentation does not assume type 2 is MD5 that is not based on this draft. 3) Do you know of even 1 customer released implementation? Until that is the case, I think type 2 should be "reserved" for MD5 to DECREASE the chance of any interoperability concerns. Their is no reason that I know of, that a additional type, say type 3 could not then be used for this RFC's auth method.. 4) Why can't shouldn't a new type be specified? Thus, the point is that if ALL implementations before this draft suggestion used type 2 as MD5, why shouldn't a new type be used for HMAC-SHA? Secondly: I understand that the "Key-ID" from 2328 is supposely to identify the alg and secret key, per "interface". However, I have no knowledge that certain bits within the key-id would IETF uniquely identify MD5 vs HMAC-SHA. Until someone informs me that all key-ids have this global uniqueness. With virtual interfaces and non-interface flooding scope OSPF pkts, I consider this a possible issue that doesn't need to be addressed when their is a simple ANSWER. THEN, since we have additional types available and 100% of implementations use MD5 as type 2, I would hope that some else with more clought would have suggested, the simple approach and officially allocate type 2 as MD5 and allocate a new type for additional auth methods.. I am actually surprised that I saw no-one else suggested this!!!! Mitchell Erblich ------------------ Manav Bhatia wrote: > > Mitchell, > > Type 2 in RFC 2328 is not reserved for MD5, but is instead used to denote some sort of Cryptographic Authentication as opposed to NULL authentication and simple password scheme. > > Refer to Figure 2 in our draft. It shows the way the authentication data must be filled in the OSPF header if the Authentication Type is set to 2. Cryptographic Authentication (Type 2) as defined in RFC 2328 allows for any auth algorithm to be used without altering the protocol packets. This is done by including the Key ID in the authentication data. Key ID carried in the packet uniquely identifies an OSPF SA and gives the authentication algorithm and the secret key that is used to create the message digest appended to the OSPF packet. > > If the Key ID maps to a HMAC-SHA algorithm then the HMAC is appended to the OSPF packet instead of the MD5 digest. > > Cheers, > Manav > > ----- Original Message ---- > From: Erblichs > To: Vishwas Manral > Cc: ospf@ietf.org; Manav Bhatia > Sent: Friday, 18 August, 2006 11:50:46 PM > Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft > > Vishwas Manral, et al, > > RFC 2328 specificly specifies "message digest" in section D3. > > I am not expert in this field, but wouldn't a section > why Type 2 shouldn't then be reserved for MD5? > > It should ALSO be a simple argument that any type 2 before now > was using MD5. Thus it is a defacto standard for the type. > > And then and a aditional type by allocated for HMAC-SHA auth. > > Mitchell Erblich > ---------------- > > Vishwas Manral wrote: > > > > Hi, > > > > We have updated the OSPF HMAC-SHA authentication draft with the comments > > that we received on the list and offline. > > > > The updated version has a short section which discusses backwards > > compatibility, similarities and differences from using MD5 (which is > > explained in Section 5 of 2328), etc. > > > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha- > > 02.txt > > > > Please let us know if there are further modifications desired. > > > > Cheers, > > Manav, Vishwas, et al. > > > > ----- Original Message ----- > > From: > > To: > > Sent: Friday, August 18, 2006 1:20 AM > > Subject: I-D ACTION:draft-bhatia-manral-white-ospf-hmac-sha-02.txt > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > > > > > > > > > Title : OSPF HMAC Cryptographic Authentication > > > > Author(s) : M. Bhatia, et al. > > > > Filename : draft-bhatia-manral-white-ospf-hmac-sha-02.txt > > > > Pages : 11 > > > > Date : 2006-8-17 > > > > > > > > This document describes a mechanism for authenticating OSPF packets > > > > by making use of the HMAC algorithm in conjunction with the SHA > > > > family of cryptographic hash functions. Because of the way the hash > > > > functions are used in HMAC construction, the collision attacks > > > > currently known against SHA-1 do not apply. > > > > > > > > This will be done in addition to the already documented > > > > authentication schemes described in the base specification. > > > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-white-ospf-hmac-sha- > > 02.txt > > > > > > > > To remove yourself from the I-D Announcement list, send a message to > > > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > > > the message. > > > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > > > to change your subscription settings. > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > > > username "anonymous" and a password of your e-mail address. After > > > > logging in, type "cd internet-drafts" and then > > > > "get draft-bhatia-manral-white-ospf-hmac-sha-02.txt". > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sat Aug 19 13:19:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEUS0-0002us-Dt; Sat, 19 Aug 2006 13:17:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEURy-0002ud-OH for ospf@ietf.org; Sat, 19 Aug 2006 13:17:34 -0400 Received: from web25411.mail.ukl.yahoo.com ([217.146.176.229]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GEURu-0007i3-5r for ospf@ietf.org; Sat, 19 Aug 2006 13:17:34 -0400 Received: (qmail 55451 invoked by uid 60001); 19 Aug 2006 17:17:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=56W+dvXcOOGhr1Mx7zU1TfpxqmYGbWSh0GyrTgR+43uyTHYI7dJGazAtQTY5lUqZC9vNlTh4W1m5KQVII41Xope3dHPIOGu6pK7/NqTA1V6sUMGcWwErFVUvqD8sEVlmfjsTEsznvcFPGNMrrbwDPOynfk5DjDUYnY2KOTXw2eg= ; Message-ID: <20060819171729.55449.qmail@web25411.mail.ukl.yahoo.com> Received: from [202.144.106.189] by web25411.mail.ukl.yahoo.com via HTTP; Sat, 19 Aug 2006 17:17:29 GMT Date: Sat, 19 Aug 2006 17:17:29 +0000 (GMT) From: Manav Bhatia Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft To: Erblichs , ospf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.9 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manav Bhatia List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Mitchell, > Section D3 specifies MD5 as the only auth method. It specificly > stated "message digest". > 1) Do you agree? > > In every implementation that I know of type 2 is MD5. That > makes it a MD5 "defacto standard" with respect to type 2. A message digest function is *just* another hash function and the two terms can be almost used interchangeably. Please note that MD5 is not the only "message digest" function; SHA-1 is also a NIST promoted "message digest" function. Essentially a message digest or hash function takes an arbitary sized data, mangles it, and outputs a fixed length hash value. IMO RFC 2328 is referring to any such function here and not MD5 really per se. So for authentication purposes we can concatenate a shared secret K with the message M and use some message digest function x to compute MD (K | M) as the MAC. This scheme can be broken and the HMAC construct was introduced, which at a very top level, works this way: (i) Concatenate the secret to the front of the message, digest the combination. (ii) Concatenate the secret to the front of the digest, and digest the combination again. Thus HMAC also creates a "message digest" - which is what we propose to use in our draft. > 2) Do you agree? Do you know what is meant as a "defacto > standard"? > > Please inform me of at least 1 implmentation does not assume > type 2 is MD5 that is not based on this draft. There is nothing in RFC 2328 which says that type 2 is "MD5" authentication. If you look at D.3 from 2328 then it says very clearly that "The algorithms used to generate and verify the message digest are specified implicitly by the secret key". It goes on to say that this particular specification, i.e. RFC 2328, defines the use of type 2 authentication *when* MD5 authentication is used. 2328 clearly leaves enough room for other "message digest/hash" functions to be used for OSPF. > 3) Do you know of even 1 customer released implementation? > > Until that is the case, I think type 2 should be "reserved" for > MD5 to DECREASE the chance of any interoperability concerns. There will be no interop issues. It will be a simple case of authentication failure and a configuration mismatch. Its no worse than configuring two routers with different keys. > > Their is no reason that I know of, that a additional type, say type > 3 could not then be used for this RFC's auth method.. > 4) Why can't shouldn't a new type be specified? > > Thus, the point is that if ALL implementations before this draft > suggestion used type 2 as MD5, why shouldn't a new type be used If an implementation believes that type 2 only means MD5, then its a gross misinterpretation of the RFC. > for HMAC-SHA? > > Secondly: > I understand that the "Key-ID" from 2328 is supposely to identify the > alg and secret key, per "interface". > However, I have no knowledge that certain bits within the key-id would > IETF uniquely identify MD5 vs HMAC-SHA. Until someone informs me that No it doesnt work this way. > all key-ids have this global uniqueness. With virtual interfaces > and non-interface flooding scope OSPF pkts, I consider this a possible > issue that doesn't need to be addressed when their is a simple ANSWER. Key ID is simply an identifier (or an index) mutually agreed on by the two communicating parties that uniquely identifies the secret key that is used to generate the message digest/hash along with some other details. Its not as simple as this, and i am not getting into the details of key-chains, key distribution, key life time, etc. > THEN, since we have additional types available and 100% of > implementations > use MD5 as type 2, I would hope that some else with more clought would > have suggested, the simple approach and officially allocate type 2 as > MD5 and > allocate a new type for additional auth methods.. I repeat. An implementation that only works by assuming type 2 to mean MD5 only is clearly violating the spirit of RFC 2328. Its after all not a huge effort to change some data structures to map the key ID to different authentication algorithms. Cheers, Manav > I am actually surprised that I saw no-one else suggested this!!!! > > Mitchell Erblich > ------------------ > > > Manav Bhatia wrote: >> >> Mitchell, >> >> Type 2 in RFC 2328 is not reserved for MD5, but is instead used to denote some sort of Cryptographic Authentication as opposed to NULL authentication and simple password scheme. >> >> Refer to Figure 2 in our draft. It shows the way the authentication data must be filled in the OSPF header if the Authentication Type is set to 2. Cryptographic Authentication (Type 2) as defined in RFC 2328 allows for any auth algorithm to be used without altering the protocol packets. This is done by including the Key ID in the authentication data. Key ID carried in the packet uniquely identifies an OSPF SA and gives the authentication algorithm and the secret key that is used to create the message digest appended to the OSPF packet. >> >> If the Key ID maps to a HMAC-SHA algorithm then the HMAC is appended to the OSPF packet instead of the MD5 digest. >> >> Cheers, >> Manav >> >> ----- Original Message ---- >> From: Erblichs >> To: Vishwas Manral >> Cc: ospf@ietf.org; Manav Bhatia >> Sent: Friday, 18 August, 2006 11:50:46 PM >> Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft >> >> Vishwas Manral, et al, >> >> RFC 2328 specificly specifies "message digest" in section D3. >> >> I am not expert in this field, but wouldn't a section >> why Type 2 shouldn't then be reserved for MD5? >> >> It should ALSO be a simple argument that any type 2 before now _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sat Aug 19 21:14:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEbrn-00024a-V6; Sat, 19 Aug 2006 21:12:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEbrn-00024U-Ap for ospf@ietf.org; Sat, 19 Aug 2006 21:12:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEbrm-0002mQ-Va for ospf@ietf.org; Sat, 19 Aug 2006 21:12:43 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GEbel-00076X-To for ospf@ietf.org; Sat, 19 Aug 2006 20:59:17 -0400 Received: by py-out-1112.google.com with SMTP id f25so1736390pyf for ; Sat, 19 Aug 2006 17:59:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gwtV8S9iv1gkjBxJpwasO7BCpjIRzZ7n7evW2nT0l9DoLirNBTeVV8fa93vw9WzA3CLsQMBI22aYJ87hHN2VmuKrpiGGqejxFd5bWVF0O0aDalDYHqiOKyujaeIdyl9l7TXFadI6J17/tAC7TDioGlvbIoWx5AJLeCMWuB4mYyk= Received: by 10.65.59.20 with SMTP id m20mr5212397qbk; Sat, 19 Aug 2006 17:59:15 -0700 (PDT) Received: by 10.65.159.3 with HTTP; Sat, 19 Aug 2006 17:59:15 -0700 (PDT) Message-ID: <6e6ce9380608191759j6cee8034w44b0130d1d98d2e1@mail.gmail.com> Date: Sun, 20 Aug 2006 06:29:15 +0530 From: "Phil Cowburn" To: "Manav Bhatia" Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-Reply-To: <20060819171729.55449.qmail@web25411.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060819171729.55449.qmail@web25411.mail.ukl.yahoo.com> X-Spam-Score: -2.5 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org I strongly agree with Manav here and an implementation must be able to demultiplex using the Key ID in the incoming packet. It is afterall for this very reason that we put the Key ID in the packet. Erblichs point, as i read it is, that most implementations (if not all) currently take type 2 to mean MD5. This may break once this draft becomes a standard, which it would, in some time. My take on this is that even if the WG agrees to Erblichs solution and introduces a new type, say 3 for HMAC-SHA-1 authentication, then somebody else could repeat the same argument and clamour for a new type when we're introducing newer authentication algorithms in the future. Lets move on from this issue. Phil _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Aug 20 17:47:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEv6l-0005GU-9d; Sun, 20 Aug 2006 17:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEv6k-0005FT-7z for ospf@ietf.org; Sun, 20 Aug 2006 17:45:26 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEv6i-0004ds-T5 for ospf@ietf.org; Sun, 20 Aug 2006 17:45:26 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 20 Aug 2006 14:45:25 -0700 X-IronPort-AV: i="4.08,149,1154934000"; d="scan'208"; a="1849062965:sNHT32258372" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7KLjOHi020971; Sun, 20 Aug 2006 14:45:24 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7KLjNw9000779; Sun, 20 Aug 2006 14:45:24 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006 17:45:23 -0400 Received: from [10.82.225.19] ([10.82.225.19]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 Aug 2006 17:45:23 -0400 Message-ID: <44E8D7F2.20606@cisco.com> Date: Sun, 20 Aug 2006 17:45:22 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Phil Cowburn Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft References: <20060819171729.55449.qmail@web25411.mail.ukl.yahoo.com> <6e6ce9380608191759j6cee8034w44b0130d1d98d2e1@mail.gmail.com> In-Reply-To: <6e6ce9380608191759j6cee8034w44b0130d1d98d2e1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Aug 2006 21:45:23.0242 (UTC) FILETIME=[F09FC8A0:01C6C4A1] DKIM-Signature: a=rsa-sha1; q=dns; l=1046; t=1156110324; x=1156974324; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20Revised=20OSPF=20HMAC=20SHA=20Authentication=20Draft; X=v=3Dcisco.com=3B=20h=3DENkKZTy4NElqncPOG8c/IfO5Vnk=3D; b=TXvOJT37qJuv69uisLkJlTWUQrJBbPD/XEuxk+MT2V7aKlLmI6TY5kcw1cpC7nsROCP0zeom PenPoZi6XUfJVklcBsViSaKW3Cg8JVABbaJJcvQKGqBSObd0cqwce8LN; Authentication-Results: sj-dkim-7.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Phil Cowburn wrote: > I strongly agree with Manav here and an implementation must be able to > demultiplex using the Key ID in the incoming packet. It is afterall > for this very reason that we put the Key ID in the packet. > > Erblichs point, as i read it is, that most implementations (if not > all) currently take type 2 to mean MD5. This may break once this draft > becomes a standard, which it would, in some time. > > My take on this is that even if the WG agrees to Erblichs solution and > introduces a new type, say 3 for HMAC-SHA-1 authentication, then > somebody else could repeat the same argument and clamour for a new > type when we're introducing newer authentication algorithms in the > future. Hi Phil, I think RFC 2328 is clear that authentication type 2 applies to all cryptographic authentication types. Thanks, Acee > > Lets move on from this issue. > > Phil > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Sun Aug 20 20:42:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GExrH-0001zx-5T; Sun, 20 Aug 2006 20:41:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GExrF-0001zs-VA for ospf@ietf.org; Sun, 20 Aug 2006 20:41:37 -0400 Received: from nz-out-0102.google.com ([64.233.162.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GExrE-0006ZI-P0 for ospf@ietf.org; Sun, 20 Aug 2006 20:41:37 -0400 Received: by nz-out-0102.google.com with SMTP id i1so616750nzh for ; Sun, 20 Aug 2006 17:41:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=knODv2BtekzUnhOEUv0r36XW6YVFTp5uv1t4ifL5Yvd6lyVkcniCpxRWaD9Q3+8neaDLeBB65JKHY9sEONz0UFgLNM3tA7qfCbpNQy348CINoUZmPq9HdiiPWgup2HFMVKQO9DEKCdXcO3iVDjIHgd6HSqtYLsvnFwj7J7TaXJ0= Received: by 10.64.143.4 with SMTP id q4mr4527285qbd; Sun, 20 Aug 2006 17:41:36 -0700 (PDT) Received: by 10.65.159.3 with HTTP; Sun, 20 Aug 2006 17:41:36 -0700 (PDT) Message-ID: <6e6ce9380608201741o6d90e1afob324624f96408e63@mail.gmail.com> Date: Mon, 21 Aug 2006 06:11:36 +0530 From: "Phil Cowburn" To: "Acee Lindem" Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-Reply-To: <44E8D7F2.20606@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060819171729.55449.qmail@web25411.mail.ukl.yahoo.com> <6e6ce9380608191759j6cee8034w44b0130d1d98d2e1@mail.gmail.com> <44E8D7F2.20606@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hello Acee, > Hi Phil, > I think RFC 2328 is clear that authentication type 2 applies to all > cryptographic authentication types. > Which is exactly what i'm saying. In fact i just gave an argument saying that we must not create a new authentication type for the stuff introduced in this new draft as 2328 is capable of handling different authentication algorithms. Phil _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Aug 21 06:57:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF7RP-0002Zi-9S; Mon, 21 Aug 2006 06:55:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF7RO-0002Zc-Fj for ospf@ietf.org; Mon, 21 Aug 2006 06:55:34 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF7RN-0006rk-7D for ospf@ietf.org; Mon, 21 Aug 2006 06:55:34 -0400 Received: from pc6 (1Cust179.tnt108.lnd4.gbr.da.uu.net [62.188.170.179]) by ranger.systems.pipex.net (Postfix) with SMTP id 34248E000430; Mon, 21 Aug 2006 11:55:20 +0100 (BST) Message-ID: <029f01c6c507$2db33500$0601a8c0@pc6> From: "tom.petch" To: "Phil Cowburn" , "Acee Lindem" References: <20060819171729.55449.qmail@web25411.mail.ukl.yahoo.com><6e6ce9380608191759j6cee8034w44b0130d1d98d2e1@mail.gmail.com><44E8D7F2.20606@cisco.com> <6e6ce9380608201741o6d90e1afob324624f96408e63@mail.gmail.com> Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft Date: Mon, 21 Aug 2006 11:48:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org ---- Original Message ----- From: "Phil Cowburn" To: "Acee Lindem" Cc: Sent: Monday, August 21, 2006 2:41 AM Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft > > > Hi Phil, > > I think RFC 2328 is clear that authentication type 2 applies to all > > cryptographic authentication types. > > > > Which is exactly what i'm saying. > > In fact i just gave an argument saying that we must not create a new > authentication type for the stuff introduced in this new draft as 2328 > is capable of handling different authentication algorithms. > > Phil > Technically correct as almost everyone agrees, and yet and yet ... If you had asked me, before this issue came up, I would have sworn that RFC2328 mandated type 2 as MD5. It has been the only one is use for so long, the only one I ever see, and I thought I knew what RFC2328 said:-( So, I think this will introduce confusion and we should clearly flag the fact that people (like me) with extensive practical experience of OSPF may be surprised to now learn what the existing standard actually is. Tom Petch _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Aug 21 07:20:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF7ph-0001Gt-L2; Mon, 21 Aug 2006 07:20:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GF7pg-0001Go-5m for ospf@ietf.org; Mon, 21 Aug 2006 07:20:40 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF7pe-0002XA-V0 for ospf@ietf.org; Mon, 21 Aug 2006 07:20:40 -0400 Received: by py-out-1112.google.com with SMTP id z59so1182593pyg for ; Mon, 21 Aug 2006 04:20:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p1sp3IM7vT3Z6KeK9YTm8++G/1+Y3zZptLgeHQQ0sOJYq1W/dyFzRxVryAnsmHRAUS0PqYFPqGtn3JxXQ0B3PWgq2pCJUGtvrE+nCYKQic8Owm2eoYo95T4RkOVn2oVrinQm9j0BxzT4lHZCT0W1D5SWAXGEEKlDiJe0/LZyg4U= Received: by 10.35.51.13 with SMTP id d13mr13094167pyk; Mon, 21 Aug 2006 04:20:38 -0700 (PDT) Received: by 10.35.128.2 with HTTP; Mon, 21 Aug 2006 04:20:38 -0700 (PDT) Message-ID: <6ed23a860608210420h19486857i748aa01cf65a91c9@mail.gmail.com> Date: Mon, 21 Aug 2006 16:50:38 +0530 From: "Tom Sanders" To: ospf@ietf.org Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-Reply-To: <6e6ce9380608191759j6cee8034w44b0130d1d98d2e1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060819171729.55449.qmail@web25411.mail.ukl.yahoo.com> <6e6ce9380608191759j6cee8034w44b0130d1d98d2e1@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Folks, Obviously the point that Erblichs is trying to make is that OSPF may be "technically" capable of supporting HMAC-SHA authentication in its current form, but OAM may be an issue and it may become harder to debug an auth mismatch. In the end the operator can always look at the router configurations in case OSPF doesnt come up and would know that the auth algos dont match. This can then be fixed. Yeah ..Yeah .. I understand this! What i miserably fail to understand is the reluctance in the WG to use a new authentication type. We have 16 bits reserved for this field and i dont see this being used up any time in the coming future. Explictly indicating the auth algo details in the header makes, in my view, debugging extremely easy. I understand that we would be eating up type codes that we would have to fill in the OSPF header each time we come up with a new authentication algorithm but given the size of this field i dont think its a point of concern. Is it possible to poll the WG on what they think is the right approach? Chairs, Authors? The poll should be on whether we should proceed as-is in the draft or should we use a new type field for each new authentication scheme that we come out with? On 20/08/06, Phil Cowburn wrote: > I strongly agree with Manav here and an implementation must be able to > demultiplex using the Key ID in the incoming packet. It is afterall > for this very reason that we put the Key ID in the packet. > > Erblichs point, as i read it is, that most implementations (if not > all) currently take type 2 to mean MD5. This may break once this draft > becomes a standard, which it would, in some time. > > My take on this is that even if the WG agrees to Erblichs solution and > introduces a new type, say 3 for HMAC-SHA-1 authentication, then > somebody else could repeat the same argument and clamour for a new > type when we're introducing newer authentication algorithms in the > future. > > Lets move on from this issue. > > Phil -- Toms. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Aug 21 10:29:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFAlO-0007u9-8L; Mon, 21 Aug 2006 10:28:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFAlN-0007pm-2k for ospf@ietf.org; Mon, 21 Aug 2006 10:28:25 -0400 Received: from web25406.mail.ukl.yahoo.com ([217.12.10.140]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFAfY-0005zL-4Z for ospf@ietf.org; Mon, 21 Aug 2006 10:22:25 -0400 Received: (qmail 63914 invoked by uid 60001); 21 Aug 2006 14:22:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=SIl/RgOhH+4ucXwC7FEfUrWBFhowrkYYwxyLQlgu9RX7WizBS+bUJe2ARH6zmTAJnNr4TD1LRdSpAMIz/3P1vnqw0NHIWhDeTsJ0LMe9vYOGZ64apycnyUce87fYn+q/O5WKGt6poYvTY4+bYUNlxTiLBeX5NmNiXpmib1knioQ= ; Message-ID: <20060821142220.63912.qmail@web25406.mail.ukl.yahoo.com> Received: from [202.144.106.189] by web25406.mail.ukl.yahoo.com via HTTP; Mon, 21 Aug 2006 14:22:20 GMT Date: Mon, 21 Aug 2006 14:22:20 +0000 (GMT) From: Manav Bhatia Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft To: Tom Sanders , ospf@ietf.org In-Reply-To: <6ed23a860608210420h19486857i748aa01cf65a91c9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.9 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manav Bhatia List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Tom, [..] > What i miserably fail to understand is the reluctance in the WG to use > a new authentication type. We have 16 bits reserved for this field and > i dont see this being used up any time in the coming future. > > Explictly indicating the auth algo details in the header makes, in my > view, debugging extremely easy. I understand that we would be eating > up type codes that we would have to fill in the OSPF header each time > we come up with a new authentication algorithm but given the size of > this field i dont think its a point of concern. > > The poll should be on whether we should proceed as-is in the draft or > should we use a new type field for each new authentication scheme that > we come out with? We dont need to use a new auth type value for each new authentication scheme that comes up in the future. One can define a new generic auth type 3, which would carry the authentication algorithm details in addition to the Key ID, auth data length and the crypto sequence number. The authentication data for type auth type 3 would be the same as type 2, except that the reserved bytes would get replaced with the authentication algorithm ID. However, i dont think this is required. Cheers, Manav >> On 20/08/06, Phil Cowburn wrote: >> >> I strongly agree with Manav here and an implementation must be able to >> demultiplex using the Key ID in the incoming packet. It is afterall >> for this very reason that we put the Key ID in the packet. >> >> Erblichs point, as i read it is, that most implementations (if not >> all) currently take type 2 to mean MD5. This may break once this draft >> becomes a standard, which it would, in some time. >> >> My take on this is that even if the WG agrees to Erblichs solution and >> introduces a new type, say 3 for HMAC-SHA-1 authentication, then >> somebody else could repeat the same argument and clamour for a new >> type when we're introducing newer authentication algorithms in the >> future. >> _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Aug 21 12:52:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCzs-00053y-0P; Mon, 21 Aug 2006 12:51:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCzr-00053t-Mz for ospf@ietf.org; Mon, 21 Aug 2006 12:51:31 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFCzq-00058t-GF for ospf@ietf.org; Mon, 21 Aug 2006 12:51:31 -0400 Received: by py-out-1112.google.com with SMTP id z59so1274482pyg for ; Mon, 21 Aug 2006 09:51:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ilI78xWTWuFMaa4LfuVfTussBfwvcZzpzmdV2cHbykJCi6bbq39HJkX20I312aX6Go+lvLuyyJr/AFkeHJEd8oMF4KkvddNWZd4IAzBhl7Zz0aGNn4W16ON8CpLxZnMKL0LmUqZ39cbCk4YDn1Hfv9Zb1mJR6cWuL1Io/B8PyNI= Received: by 10.35.63.2 with SMTP id q2mr13630935pyk; Mon, 21 Aug 2006 09:51:29 -0700 (PDT) Received: by 10.35.128.2 with HTTP; Mon, 21 Aug 2006 09:51:29 -0700 (PDT) Message-ID: <6ed23a860608210951m6104514fw16ba3215e45df7eb@mail.gmail.com> Date: Mon, 21 Aug 2006 22:21:29 +0530 From: "Tom Sanders" To: "Manav Bhatia" Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-Reply-To: <20060821142220.63912.qmail@web25406.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6ed23a860608210420h19486857i748aa01cf65a91c9@mail.gmail.com> <20060821142220.63912.qmail@web25406.mail.ukl.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Manav, > We dont need to use a new auth type value for each new authentication scheme > that comes up in the future. > > One can define a new generic auth type 3, which would carry the authentication > algorithm details in addition to the Key ID, auth data length and the crypto > sequence number. The authentication data for type auth type 3 would be the > same as type 2, except that the reserved bytes would get replaced with the > authentication algorithm ID. Excellent, this is much better than our initial guess. Actually one octet is enough for carrying the Algo ID. You are still left with one reserved octet. Go Play! > > However, i dont think this is required. Well, thats something that the WG, and not you and me, have to decide! :) > > Cheers, > Manav > > >> On 20/08/06, Phil Cowburn wrote: > >> > >> I strongly agree with Manav here and an implementation must be able to > >> demultiplex using the Key ID in the incoming packet. It is afterall > >> for this very reason that we put the Key ID in the packet. > >> > >> Erblichs point, as i read it is, that most implementations (if not > >> all) currently take type 2 to mean MD5. This may break once this draft > >> becomes a standard, which it would, in some time. > >> > >> My take on this is that even if the WG agrees to Erblichs solution and > >> introduces a new type, say 3 for HMAC-SHA-1 authentication, then > >> somebody else could repeat the same argument and clamour for a new > >> type when we're introducing newer authentication algorithms in the > >> future. > >> > -- Toms. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Aug 22 15:33:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbzK-00051e-Qz; Tue, 22 Aug 2006 15:32:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFbzK-00051Z-Hv for ospf@ietf.org; Tue, 22 Aug 2006 15:32:38 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFbzH-0003QG-8g for ospf@ietf.org; Tue, 22 Aug 2006 15:32:38 -0400 Received: from sjc-vpn6-661.cisco.com (HELO cisco.com) ([10.21.122.149]) by sj-iport-1.cisco.com with ESMTP; 22 Aug 2006 12:32:34 -0700 Message-ID: <44EB5BD1.2000107@cisco.com> Date: Tue, 22 Aug 2006 12:32:33 -0700 From: Michael J Barnes 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 To: Manav Bhatia Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft References: <20060821142220.63912.qmail@web25406.mail.ukl.yahoo.com> In-Reply-To: <20060821142220.63912.qmail@web25406.mail.ukl.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hello Manav, Manav Bhatia wrote: > Hi Tom, > > [..] >> >>The poll should be on whether we should proceed as-is in the draft or >>should we use a new type field for each new authentication scheme that >>we come out with? > > > We dont need to use a new auth type value for each new authentication > scheme that comes up in the future. > > One can define a new generic auth type 3, which would carry the > authentication algorithm details in addition to the Key ID, auth data > length and the crypto sequence number. The authentication data for type > auth type 3 would be the same as type 2, except that the reserved bytes > would get replaced with the authentication algorithm ID. A concern I have with this is that when a new authentication algorithm is devised we would have to have to wait for a new OSPF RFC to specify the Authentication Algorithm ID before we could implement the algorithm. Generally, I don't think a new OSPF RFC should be required just to make use of a new algorithm. Looking at IPsec, it also does not include a field which indicates which algorithm is used. The IPsec SPI is equivalent to the Key ID we use in OSPF. We are defining an SA similarly to IPsec, which . As in IPsec, the SA indicates which algorithm and key are used. So this draft is in keeping with how IPsec operates. I think it makes sense for OSPF to follow the lead of IPsec in this regard. My $.02 Thanks, Michael > However, i dont think this is required. > > Cheers, > Manav > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Aug 22 15:44:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcB0-0001Ds-I5; Tue, 22 Aug 2006 15:44:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFcAz-0001Dn-Kd for ospf@ietf.org; Tue, 22 Aug 2006 15:44:41 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFcAx-00057b-9I for ospf@ietf.org; Tue, 22 Aug 2006 15:44:41 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 22 Aug 2006 12:44:39 -0700 X-IronPort-AV: i="4.08,156,1154934000"; d="scan'208"; a="312752086:sNHT32244344" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7MJicmF015772; Tue, 22 Aug 2006 12:44:38 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7MJib6a023854; Tue, 22 Aug 2006 12:44:38 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 15:44:36 -0400 Received: from [10.82.225.19] ([10.82.225.19]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Aug 2006 15:44:36 -0400 Message-ID: <44EB5EA3.2030102@cisco.com> Date: Tue, 22 Aug 2006 15:44:35 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Tom Sanders Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft References: <6ed23a860608210420h19486857i748aa01cf65a91c9@mail.gmail.com> <20060821142220.63912.qmail@web25406.mail.ukl.yahoo.com> <6ed23a860608210951m6104514fw16ba3215e45df7eb@mail.gmail.com> In-Reply-To: <6ed23a860608210951m6104514fw16ba3215e45df7eb@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Aug 2006 19:44:36.0415 (UTC) FILETIME=[66013CF0:01C6C623] DKIM-Signature: a=rsa-sha1; q=dns; l=2282; t=1156275878; x=1157139878; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20Revised=20OSPF=20HMAC=20SHA=20Authentication=20Draft; X=v=3Dcisco.com=3B=20h=3D43KKY7RDE6Tb7dPHIa/escbtBpk=3D; b=TUPyQFZ2E0zOK1NGQTiyaQLRoyCeeUGQ+jy/00Bd+afLD9eAQoVOYRPNpxRq//608ak1tbYy k+mRe7UYpebEj2G3bC9K50pt0c3EPGIzsYwhbl6IWCreaEhik2VpKMpz; Authentication-Results: sj-dkim-8.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Tom Sanders wrote: > Manav, > >> We dont need to use a new auth type value for each new authentication >> scheme > that comes up in the future. >> >> One can define a new generic auth type 3, which would carry the >> authentication > algorithm details in addition to the Key ID, auth >> data length and the crypto >> sequence number. The authentication data for type auth type 3 would >> be the >> same as type 2, except that the reserved bytes would get replaced >> with the >> authentication algorithm ID. > > Excellent, this is much better than our initial guess. > > Actually one octet is enough for carrying the Algo ID. You are still > left with one reserved octet. Go Play! > >> >> However, i dont think this is required. > > Well, thats something that the WG, and not you and me, have to decide! :) Hi Tom, I'd also vote against this since the standardized definition of cryptographic authentication (AuType = 2) was designed to accommodate different hash algorithms. Based on the discussion heretofore, it seems that its definition satisfies this requirement. Additionally, I don't see any compatibility problems with implementations unequivocally map AuType 2 to MD5 authentication. As one would expect, authentication will fail (at least with a very high probability :^) if there is a mismatch between configured hash algorithms. Thanks, Acee > >> >> Cheers, >> Manav >> >> >> On 20/08/06, Phil Cowburn wrote: >> >> >> >> I strongly agree with Manav here and an implementation must be >> able to >> >> demultiplex using the Key ID in the incoming packet. It is afterall >> >> for this very reason that we put the Key ID in the packet. >> >> >> >> Erblichs point, as i read it is, that most implementations (if not >> >> all) currently take type 2 to mean MD5. This may break once this >> draft >> >> becomes a standard, which it would, in some time. >> >> >> >> My take on this is that even if the WG agrees to Erblichs solution >> and >> >> introduces a new type, say 3 for HMAC-SHA-1 authentication, then >> >> somebody else could repeat the same argument and clamour for a new >> >> type when we're introducing newer authentication algorithms in the >> >> future. >> >> >> > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Aug 22 19:57:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFg73-0005tL-RJ; Tue, 22 Aug 2006 19:56:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFg73-0005tG-1g for ospf@ietf.org; Tue, 22 Aug 2006 19:56:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFdaL-0004G8-1D for ospf@ietf.org; Tue, 22 Aug 2006 17:14:57 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFdTd-0002mx-8D for ospf@ietf.org; Tue, 22 Aug 2006 17:08:06 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 22 Aug 2006 17:08:01 -0400 X-IronPort-AV: i="4.08,156,1154923200"; d="scan'208"; a="98111261:sNHT29993416" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7ML80B6024023; Tue, 22 Aug 2006 17:08:00 -0400 Received: from [10.82.225.37] (rtp-vpn1-293.cisco.com [10.82.225.37]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7ML7xdM006178; Tue, 22 Aug 2006 17:08:00 -0400 (EDT) Message-ID: <44EB7216.3080008@cisco.com> Date: Tue, 22 Aug 2006 17:07:34 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Acee Lindem Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft References: <6ed23a860608210420h19486857i748aa01cf65a91c9@mail.gmail.com> <20060821142220.63912.qmail@web25406.mail.ukl.yahoo.com> <6ed23a860608210951m6104514fw16ba3215e45df7eb@mail.gmail.com> <44EB5EA3.2030102@cisco.com> In-Reply-To: <44EB5EA3.2030102@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=961; t=1156280880; x=1157144880; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:Russ=20White=20 |Subject:Re=3A=20[OSPF]=20Revised=20OSPF=20HMAC=20SHA=20Authentication=20Draft |To:Acee=20Lindem=20; X=v=3Dcisco.com=3B=20h=3DAqS1vbJlmT3NFer5CGieez00nGs=3D; b=ZSnplwCPS4tdjGzBXEoc43d8jyJXDgUCTQ2JYm73z/Yk08xaUrA/5H33VafNPfH6qcJf/xoW 5Za0Y/LzSziO3zzA+ZGvrqVCvI+tBRAsb0ziuX1wr1iftRx05k8hjoVh; Authentication-Results: rtp-dkim-2.cisco.com; header.From=riw@cisco.com; dkim=pass ( 27 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: -2.3 (--) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I'd also vote against this since the standardized definition of > cryptographic authentication (AuType = 2) was designed to accommodate > different hash algorithms. Based on the discussion heretofore, it > seems that its definition satisfies this requirement. Additionally, I > don't see any compatibility problems with implementations > unequivocally map AuType 2 to MD5 authentication. As one would > expect, authentication will fail (at least with a very high > probability :^) if there is a mismatch between configured hash > algorithms. Agreed--I would agree this is the best way to handle this. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE63IWER27sUhU9OQRAlQ9AKDMTNxCGSlvsYfm13dimdbPkZUBMwCgxLPO kG7cKpSwagLsx+4T2ZjbB+Q= =wtHk -----END PGP SIGNATURE----- _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Aug 23 02:59:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFmh7-0006QM-Pk; Wed, 23 Aug 2006 02:58:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFmh7-0006Nb-8U for ospf@ietf.org; Wed, 23 Aug 2006 02:58:33 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFmh1-0006Is-GQ for ospf@ietf.org; Wed, 23 Aug 2006 02:58:33 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4F006SCVGG9F@szxga01-in.huawei.com> for ospf@ietf.org; Wed, 23 Aug 2006 15:00:17 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4F00EAUVGGQ0@szxga01-in.huawei.com> for ospf@ietf.org; Wed, 23 Aug 2006 15:00:16 +0800 (CST) Received: from dell60 ([10.18.7.146]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4F004BLVVG6K@szxml04-in.huawei.com> for ospf@ietf.org; Wed, 23 Aug 2006 15:09:17 +0800 (CST) Date: Wed, 23 Aug 2006 12:27:05 +0530 From: sujay Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-reply-to: <44EB7216.3080008@cisco.com> To: ospf@ietf.org Message-id: <002901c6c681$5897c4e0$9207120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcbGRxq5RiqzzH8WQpio6aqdIoVLMgAOI3sA X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org I would prefer maintain using Au Type =3D 2 for the new algo's as well. With a thought ; as there is a possibility of more algo's to be added in te same scheme with Au Type =3D 2, and there is some talk about MD5 = being the most used in implementations. Can we have a default algo. concept?? Regds, Sujay G My Location; http://maps.google.com/maps?ll=3D14.626109,76.959229&spn=3D4.724852,7.525= 085&t=3Dh &hl=3Den This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the = sender by phone or email immediately and delete it!=20 -----Original Message----- From: Russ White [mailto:riw@cisco.com]=20 Sent: 2006=C4=EA8=D4=C223=C8=D5 2:38 To: Acee Lindem Cc: ospf@ietf.org Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I'd also vote against this since the standardized definition of=20 > cryptographic authentication (AuType =3D 2) was designed to = accommodate=20 > different hash algorithms. Based on the discussion heretofore, it=20 > seems that its definition satisfies this requirement. Additionally, I=20 > don't see any compatibility problems with implementations=20 > unequivocally map AuType 2 to MD5 authentication. As one would expect, = > authentication will fail (at least with a very high probability :^) if = > there is a mismatch between configured hash algorithms. Agreed--I would agree this is the best way to handle this. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE63IWER27sUhU9OQRAlQ9AKDMTNxCGSlvsYfm13dimdbPkZUBMwCgxLPO kG7cKpSwagLsx+4T2ZjbB+Q=3D =3DwtHk -----END PGP SIGNATURE----- _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Aug 23 03:38:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFnJ1-0004bx-An; Wed, 23 Aug 2006 03:37:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFnJ0-0004bs-9S for ospf@ietf.org; Wed, 23 Aug 2006 03:37:42 -0400 Received: from web25414.mail.ukl.yahoo.com ([217.146.176.232]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFnIy-0004Uv-Tw for ospf@ietf.org; Wed, 23 Aug 2006 03:37:42 -0400 Received: (qmail 49560 invoked by uid 60001); 23 Aug 2006 07:37:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=YtevuCTf7Htd5nETR4EgjnlQR+P4ccufDugV5+kJ1e3sp+uccXS4HjvFGe/T+jKCYM0ozPeec6ZSvR/9Y6A4aYg9m5i290NMsUV4hsL++6csAe258UihAJAHrZVhZVZEG2GKYHoWi/mM+uMVRsmWS3Y8R9PGQd9ZwWk1YZIMSBY= ; Message-ID: <20060823073740.49558.qmail@web25414.mail.ukl.yahoo.com> Received: from [202.144.106.188] by web25414.mail.ukl.yahoo.com via HTTP; Wed, 23 Aug 2006 07:37:40 GMT Date: Wed, 23 Aug 2006 07:37:40 +0000 (GMT) From: Manav Bhatia Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft To: sujay , ospf@ietf.org In-Reply-To: <002901c6c681$5897c4e0$9207120a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.9 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manav Bhatia List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Sujay, > >Can we have a default algo. concept?? > What do you mean by the default algo? Is it one authentication algorithm that all implementations MUST support? Manav _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Aug 23 05:51:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFpNd-0001mE-NZ; Wed, 23 Aug 2006 05:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFpNc-0001m9-4I for ospf@ietf.org; Wed, 23 Aug 2006 05:50:36 -0400 Received: from web25408.mail.ukl.yahoo.com ([217.12.10.142]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFpNS-0003Q5-MN for ospf@ietf.org; Wed, 23 Aug 2006 05:50:36 -0400 Received: (qmail 50392 invoked by uid 60001); 23 Aug 2006 09:23:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=23fgOeNjMAGocWETgANo37UAYfKw6loPdfQeprZAMgu80h0LYD7hUeqFcVBXGdBXA3KPfqU4OaYbr7hQnhLRy1KviExBM7Sx/vJZDKlj/OfGfmoBff/NK9bQiJasOegZdhUJvVrVkyrqdpmXQO2Lt/pi9HPv7RrwdxUW23f5u48= ; Message-ID: <20060823092345.50390.qmail@web25408.mail.ukl.yahoo.com> Received: from [202.144.106.188] by web25408.mail.ukl.yahoo.com via HTTP; Wed, 23 Aug 2006 09:23:45 GMT Date: Wed, 23 Aug 2006 09:23:45 +0000 (GMT) From: Manav Bhatia Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication Draft To: sujayg@huawei.com MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.9 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ospf@ietf.org, vishwas.manral@gmail.com X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Manav Bhatia List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Sujay, =20 OSPF can make use of various cryptographic algorithms in order to authentic= ate its packets. Your concern is wrt interoperability between disparate imp= lementations where a particular implementation may not implement some certa= in mandatory-to-implement algorithms. To ensure this doesn=E2=80=99t happen= , it is necessary to specify a set of mandatory-to-implement algorithms so = that there is at least one algorithm that all implementations will have ava= ilable.=20 =20 We cannot assume this mandatory-to-implement algorithm to be MD5, as this h= as been broken. MD5CRK, was a distributed computing project to break the MD= 5 hash algorithm in a short period of time. The project closed down with th= e publication of their paper by Wang, X. et al., "Collisions for Hash Funct= ions MD4, MD5, HAVAL-128 and RIPEMD", August 2004, http://eprint.iacr.org/2= 004/199 =20 draft-bhatia-manral-crypto-req-ospf-00.txt defines the current set of manda= tory-to-implement algorithms that can be used for the cryptographic authent= ication for OSPF as well as specifies the algorithms that should/must be im= plemented because they may get promoted to mandatory at some future time.= =20 =20 http://tools.ietf.org/wg/ospf/draft-bhatia-manral-crypto-req-ospf-00.txt =20 Cheers, Manav=20 ________________________________ From: sujay [mailto:sujayg@huawei.com]=20 Sent: Wednesday, August 23, 2006 2:36 PM To: 'Manav Bhatia' Cc: 'Mailing List'; ospf@ietf.org Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication Draft =20 =20 Yes, If an authentication fails it could mean the algo's used are different. And if one implementation supports MD5 alone( "which I believe is commonly= used !" ), the others support otherwise, It could be a problem, there is no explicit way we are = converying which algo is being used. The Au Type =3D 2 is overloaded. Now a "MUST" clause is for the WG to decide. Regds, Sujay G My Location; http://maps.google.com/maps?ll=3D14.626109,76.959229&spn=3D4.724852,7.5250= 85&t=3Dh&hl=3Den =20 -- Lucent Technologies =20 =20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Aug 23 06:49:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFqI4-0001Ni-06; Wed, 23 Aug 2006 06:48:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFqI3-0001NR-D7 for ospf@ietf.org; Wed, 23 Aug 2006 06:48:55 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFqHy-00048p-QE for ospf@ietf.org; Wed, 23 Aug 2006 06:48:55 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4G0084C5WRNL@szxga01-in.huawei.com> for ospf@ietf.org; Wed, 23 Aug 2006 18:46:03 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4G008KS5WQUZ@szxga01-in.huawei.com> for ospf@ietf.org; Wed, 23 Aug 2006 18:46:03 +0800 (CST) Received: from dell60 ([10.18.7.146]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4G001735Y23A@szxml03-in.huawei.com> for ospf@ietf.org; Wed, 23 Aug 2006 18:46:51 +0800 (CST) Date: Wed, 23 Aug 2006 16:12:48 +0530 From: sujay Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-reply-to: <20060823092345.50390.qmail@web25408.mail.ukl.yahoo.com> To: 'Manav Bhatia' Message-id: <004301c6c6a0$e3791c70$9207120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: AcbGldo11CpVlgC+RS2UfDPt5l0KPwACiNxg X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ospf@ietf.org, vishwas.manral@gmail.com X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Manav, Agree, mandatory set of algo is a must. Which one falls in this set is unsure. Assuming the requirement of backward compatibility would still hold = good. I believe the network operators on this list will best mandate the = minimal algo required. Regds, Sujay G My Location; http://maps.google.com/maps?ll=3D14.626109,76.959229&spn=3D4.724852,7.525= 085&t=3Dh &hl=3Den This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the = sender by phone or email immediately and delete it!=20 -----Original Message----- From: Manav Bhatia [mailto:manav_bhatia06@yahoo.co.uk]=20 Sent: 2006=C4=EA8=D4=C223=C8=D5 14:54 To: sujayg@huawei.com Cc: ospf@ietf.org; vishwas.manral@gmail.com Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication Draft Sujay, =20 OSPF can make use of various cryptographic algorithms in order to authenticate its packets. Your concern is wrt interoperability between disparate implementations where a particular implementation may not implement some certain mandatory-to-implement algorithms. To ensure this doesn=A1=AFt happen, it is necessary to specify a set of = mandatory-to-implement algorithms so that there is at least one algorithm that all = implementations will have available.=20 =20 We cannot assume this mandatory-to-implement algorithm to be MD5, as = this has been broken. MD5CRK, was a distributed computing project to break = the MD5 hash algorithm in a short period of time. The project closed down = with the publication of their paper by Wang, X. et al., "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD", August 2004, http://eprint.iacr.org/2004/199 =20 draft-bhatia-manral-crypto-req-ospf-00.txt defines the current set of mandatory-to-implement algorithms that can be used for the cryptographic authentication for OSPF as well as specifies the algorithms that = should/must be implemented because they may get promoted to mandatory at some future time.=20 =20 http://tools.ietf.org/wg/ospf/draft-bhatia-manral-crypto-req-ospf-00.txt =20 Cheers, Manav ________________________________ From: sujay [mailto:sujayg@huawei.com] Sent: Wednesday, August 23, 2006 2:36 PM To: 'Manav Bhatia' Cc: 'Mailing List'; ospf@ietf.org Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication Draft =20 =20 Yes, If an authentication fails it could mean the algo's used are different. And if one implementation supports MD5 alone( "which I believe is = commonly used !" ), the others support otherwise, It could be a problem, there is no explicit way we = are converying which algo is being used. The Au Type =3D 2 is overloaded. Now a "MUST" clause is for the WG to decide. Regds, Sujay G My Location; =20 http://maps.google.com/maps?ll=3D14.626109,76.959229&spn=3D4.724852,7.525= 085&t=3Dh &hl=3Den =20 -- Lucent Technologies =20 =20 =20 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Aug 23 07:28:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFqtq-0001kE-UX; Wed, 23 Aug 2006 07:27:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFqtp-0001k8-E5 for ospf@ietf.org; Wed, 23 Aug 2006 07:27:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFp3R-0000ch-Be for ospf@ietf.org; Wed, 23 Aug 2006 05:29:45 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFoos-0002gU-GN for ospf@ietf.org; Wed, 23 Aug 2006 05:14:43 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4G00JOF1G1HW@szxga01-in.huawei.com> for ospf@ietf.org; Wed, 23 Aug 2006 17:09:37 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4G00EFM1G0QK@szxga01-in.huawei.com> for ospf@ietf.org; Wed, 23 Aug 2006 17:09:37 +0800 (CST) Received: from dell60 ([10.18.7.146]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4G00MGJ1HCXF@szxml03-in.huawei.com> for ospf@ietf.org; Wed, 23 Aug 2006 17:10:25 +0800 (CST) Date: Wed, 23 Aug 2006 14:36:27 +0530 From: sujay Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-reply-to: <00cc01c6c686$8dae3740$260218ac@rs.riverstonenet.com> To: 'Manav Bhatia' Message-id: <003801c6c693$6b286760$9207120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbGRxq5RiqzzH8WQpio6aqdIoVLMgAOI3sAAAGpZJAAAzkoEA== X-Spam-Score: -2.3 (--) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: ospf@ietf.org, 'Mailing List' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1249939516==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============1249939516== Content-type: multipart/alternative; boundary="Boundary_(ID_wHvzfg46ONY8rEcuWnpHtw)" This is a multi-part message in MIME format. --Boundary_(ID_wHvzfg46ONY8rEcuWnpHtw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Yes, If an authentication fails it could mean the algo's used are different. And if one implementation supports MD5 alone( "which I believe is = commonly used !" ), the others support otherwise, It could be a problem, there is no explicit way we = are converying which algo is being used. The Au Type =3D 2 is overloaded. Now a "MUST" clause is for the WG to decide. Regds, Sujay G My Location; http://maps.google.com/maps?ll=3D14.626109,76.959229 &spn=3D4.724852,7.525085&t=3Dh&hl=3Den This e-mail and attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the = sender by phone or email immediately and delete it!=20 =20 _____ =20 From: Manav Bhatia [mailto:manav@riverstonenet.com]=20 Sent: 2006=C4=EA8=D4=C223=C8=D5 13:04 To: 'sujay' Cc: 'Mailing List' Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication Draft Sujay,=20 >=20 >Can we have a default algo. concept??=20 >=20 What do you mean by the default algo? Is it one authentication algorithm that all implementations MUST support?=20 Manav=20 --Boundary_(ID_wHvzfg46ONY8rEcuWnpHtw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable RE: [OSPF] Revised OSPF HMAC SHA Authentication = Draft

Yes,

If an authentication fails it could mean the algo's = used are=20 different.

And if one implementation supports MD5 alone( "which I = believe=20 is commonly used !" ), the=20 others

support otherwise, It could be a problem, there is no = explicit=20 way we are converying which algo is being used.

The Au Type = =3D 2 is=20 overloaded.

Now a "MUST" clause is for the WG to = decide.

Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=3D1= 4.626109,76.959229&spn=3D4.724852,7.525085&t=3Dh&hl=3Den<= BR>

This=20 e-mail and attachments contain confidential information from HUAWEI, = which is=20 intended only for the person or entity whose address is listed above. = Any use of=20 the information contained herein in any way (including, but not limited = to,=20 total or partial disclosure, reproduction, or dissemination) by persons = other=20 than the intended recipient's) is prohibited. If you receive this e-mail = in=20 error, please notify the sender by phone or email immediately and delete = it!=20
 

From: Manav Bhatia=20 [mailto:manav@riverstonenet.com]
Sent: = 2006=C4=EA8=D4=C223=C8=D5 13:04
To:=20 'sujay'
Cc: 'Mailing List'
Subject: RE: [OSPF] = Revised OSPF=20 HMAC SHA Authentication Draft

Sujay, =

> =
>Can we have a default algo. = concept??
>

What do you mean by = the default=20 algo? Is it one authentication algorithm that all implementations MUST=20 support?

Manav=20

--Boundary_(ID_wHvzfg46ONY8rEcuWnpHtw)-- --===============1249939516== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1249939516==-- From ospf-bounces@ietf.org Wed Aug 23 11:12:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuOi-0000oG-3B; Wed, 23 Aug 2006 11:12:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuOh-0000oB-AV for ospf@ietf.org; Wed, 23 Aug 2006 11:12:03 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFuOe-0001Ey-09 for ospf@ietf.org; Wed, 23 Aug 2006 11:12:03 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k7NFBq1Z046673; Wed, 23 Aug 2006 08:11:52 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k7NFBkg12039; Wed, 23 Aug 2006 08:11:51 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <003801c6c693$6b286760$9207120a@china.huawei.com> References: <003801c6c693$6b286760$9207120a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <43DD6866-31C7-439A-A140-6BD2C0DE6B82@juniper.net> From: Dave Katz Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft Date: Wed, 23 Aug 2006 09:11:45 -0600 To: sujay X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: 'Mailing List' , ospf@ietf.org X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0390457640==" Errors-To: ospf-bounces@ietf.org --===============0390457640== Content-Type: multipart/alternative; boundary=Apple-Mail-47--202437344 --Apple-Mail-47--202437344 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Sigh. C'mon, folks, there is no problem. View the algorithm as simply part of the shared secret. All =20 authentication is done between consenting adults and there has to be =20 out-of-band and a priori agreement on the parameters or the =20 authentication fails. Nobody is going to be guessing the algorithm =20 in use on a particular session any more than they would be guessing =20 the secret. And if you want to switch algorithms (which is =20 essentially just switching secrets) the key ID mechanism is present. At the end of the day it doesn't matter if the value of 2 or 3 or 42 =20 is used; if there's a mismatch on the the algorithm ID, the =20 algorithm, or the key, the authentication will fail, and if it all =20 matches, it will work. For that matter, I don't think that even the =20 existing algorithm ID is necessary, since the entire thing has to be =20 agreed upon a priori anyhow. For what it's worth, type 2 fits the bill just fine, defined the way =20 that it is. If one box does only MD5 and the other box only does =20 SHA, they cannot talk. If they share an algorithm, it is up to the =20 user to configure the two boxes compatibly, like a thousand other =20 parameters. While having a separate code point for SHA would have =20 marginal debugging utility ("wrong algorithm, dummy!") it's no harder =20= to make sure that this matches on both sides than it is to make sure =20 the shared secret matches. --Dave On Aug 23, 2006, at 3:06 AM, sujay wrote: > Yes, > > If an authentication fails it could mean the algo's used are =20 > different. > > And if one implementation supports MD5 alone( "which I believe is =20 > commonly used !" ), the others > > support otherwise, It could be a problem, there is no explicit way =20 > we are converying which algo is being used. > > The Au Type =3D 2 is overloaded. > > Now a "MUST" clause is for the WG to decide. > > Regds, > Sujay G > My Location; > http://maps.google.com/maps?=20 > ll=3D14.626109,76.959229&spn=3D4.724852,7.525085&t=3Dh&hl=3Den > > > This e-mail and attachments contain confidential information from =20 > HUAWEI, which is intended only for the person or entity whose =20 > address is listed above. Any use of the information contained =20 > herein in any way (including, but not limited to, total or partial =20 > disclosure, reproduction, or dissemination) by persons other than =20 > the intended recipient's) is prohibited. If you receive this e-mail =20= > in error, please notify the sender by phone or email immediately =20 > and delete it! > > > From: Manav Bhatia [mailto:manav@riverstonenet.com] > Sent: 2006=E5=B9=B48=E6=9C=8823=E6=97=A5 13:04 > To: 'sujay' > Cc: 'Mailing List' > Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication Draft > > Sujay, > > > > >Can we have a default algo. concept?? > > > > What do you mean by the default algo? Is it one authentication =20 > algorithm that all implementations MUST support? > > Manav > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf --Apple-Mail-47--202437344 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Sigh.=C2=A0 C'mon, folks, there = is no problem.

View = the algorithm as simply part of the shared secret.=C2=A0 All = authentication is done between consenting adults and there has to be = out-of-band and a priori agreement on the parameters or the = authentication fails.=C2=A0 Nobody is going to be guessing the algorithm = in use on a particular session any more than they would be guessing the = secret.=C2=A0 And if you want to switch algorithms (which is essentially = just switching secrets) the key ID mechanism is present.

At the end of the day it = doesn't matter if the value of 2 or 3 or 42 is used;=C2=A0 if there's a = mismatch on the the algorithm ID, the algorithm, or the key, the = authentication will fail, and if it all matches, it will work.=C2=A0 For = that matter, I don't think that even the existing algorithm ID is = necessary, since the entire thing has to be agreed upon a priori = anyhow.

For = what it's worth, type 2 fits the bill just fine, defined the way that it = is.=C2=A0 If one box does only MD5 and the other box only does SHA, they = cannot talk.=C2=A0 If they share an algorithm, it is up to the user to = configure the two boxes compatibly, like a thousand other parameters.=C2=A0= While having a separate code point for SHA would have marginal = debugging utility ("wrong algorithm, dummy!") it's no harder to make = sure that this matches on both sides than it is to make sure the shared = secret matches.

--Dave


On Aug 23, = 2006, at 3:06 AM, sujay wrote:

Yes,

If an authentication fails it could mean the algo's used are = different.

And if one implementation = supports MD5 alone( "which I believe is commonly used !" ), the others

support otherwise, It could be a problem, there is no = explicit way we are converying which algo is being = used.

The Au Type =3D 2 is overloaded.

Now = a "MUST" clause is for the WG to decide.

Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=3D14.626109,76.95= 9229&spn=3D4.724852,7.525085&t=3Dh&hl=3Den


This= e-mail and attachments contain confidential information from HUAWEI, = which is intended only for the person or entity whose address is listed = above. Any use of the information contained herein in any way = (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended = recipient's) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it! =
=C2=A0

From: Manav Bhatia [mailto:manav@riverstonenet.com= ]
Sent: 2006=E5=B9=B48=E6=9C=8823=E6=97=A5 = 13:04
To: 'sujay'
Cc: 'Mailing = List'
Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication = Draft

Sujay,

> =
>Can we have = a default algo. concept??
>

What do you mean by the = default algo? Is it one authentication algorithm that all = implementations MUST support?

Manav =

OSPF mailing list
=

= --Apple-Mail-47--202437344-- --===============0390457640== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0390457640==-- From ospf-bounces@ietf.org Thu Aug 24 00:11:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG6X6-0007Ay-7j; Thu, 24 Aug 2006 00:09:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG6X4-0007Am-Tz for ospf@ietf.org; Thu, 24 Aug 2006 00:09:30 -0400 Received: from cl-9.dub-01.ie.sixxs.net ([2001:770:100:8::2] helo=hibernia.jakma.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG6X3-0002LE-96 for ospf@ietf.org; Thu, 24 Aug 2006 00:09:30 -0400 Received: from sheen.jakma.org (IDENT:U2FsdGVkX184Q1b0Aukqhj4QfNV4ex7UnXaQCAssvbA@sheen.jakma.org [212.17.55.53]) (authenticated bits=0) by hibernia.jakma.org (8.13.7/8.13.6) with ESMTP id k7O48tB5024040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Aug 2006 05:09:09 +0100 Date: Thu, 24 Aug 2006 05:08:55 +0100 (IST) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Dave Katz Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-Reply-To: <43DD6866-31C7-439A-A140-6BD2C0DE6B82@juniper.net> Message-ID: References: <003801c6c693$6b286760$9207120a@china.huawei.com> <43DD6866-31C7-439A-A140-6BD2C0DE6B82@juniper.net> Mail-Copies-To: paul@jakma.org Mail-Followup-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.3/1721/Thu Aug 24 01:06:46 2006 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ospf@ietf.org, 'Mailing List' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org On Wed, 23 Aug 2006, Dave Katz wrote: > Sigh. C'mon, folks, there is no problem. > At the end of the day it doesn't matter if the value of 2 or 3 or > 42 is used; if there's a mismatch on the the algorithm ID, the > algorithm, or the key, the authentication will fail, and if it all > matches, it will work. Strongly concur. There is though value in defining "MUST support" algos, otherwise poor users could be faced with having routers which all implement OSPF but can be made to interoperate unless authentication is left unconfigured. MD5 at least should be defined as a MUST support. (Despite the pre-image weaknesses, it's still not yet completely insecure in MAC mode) regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: We promise according to our hopes, and perform according to our fears. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Aug 24 00:54:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG7Dn-0003ro-Fp; Thu, 24 Aug 2006 00:53:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG7Dm-0003rj-Dw for ospf@ietf.org; Thu, 24 Aug 2006 00:53:38 -0400 Received: from wx-out-0506.google.com ([66.249.82.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG7Dk-0003kD-6H for ospf@ietf.org; Thu, 24 Aug 2006 00:53:38 -0400 Received: by wx-out-0506.google.com with SMTP id t4so357476wxc for ; Wed, 23 Aug 2006 21:53:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GiPI2LOVcMr6OJ4tq6IV1EUsSfqbLuX9M9VKj4zWkgkkdyVuN7gZh5EcBGKL/6NppAqNpTl/Bd3ioYbLsbsJsX205g0cy3Ltbw3xzi05GcdWdvB9d2raINTNDZME/B426h0Pe6HaxxPcIqEcKYScJNrLucDKeSPGp+3FypeDjy8= Received: by 10.70.51.17 with SMTP id y17mr1836201wxy; Wed, 23 Aug 2006 21:53:35 -0700 (PDT) Received: by 10.70.33.3 with HTTP; Wed, 23 Aug 2006 21:53:35 -0700 (PDT) Message-ID: <77ead0ec0608232153j6eb2add0l42cbc084fe3c4ec3@mail.gmail.com> Date: Thu, 24 Aug 2006 10:23:35 +0530 From: "Vishwas Manral" To: paul@jakma.org Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003801c6c693$6b286760$9207120a@china.huawei.com> <43DD6866-31C7-439A-A140-6BD2C0DE6B82@juniper.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ospf@ietf.org, Mailing List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Paul, > There is though value in defining "MUST support" algos, otherwise > poor users could be faced with having routers which all implement > OSPF but can be made to interoperate unless authentication is left > unconfigured. We have drafts to meet the following exact requirements: http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf-00.txt and http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-00.txt for OSPF and IS-IS respectively. Thanks, Vishwas On 8/24/06, Paul Jakma wrote: > On Wed, 23 Aug 2006, Dave Katz wrote: > > > Sigh. C'mon, folks, there is no problem. > > > At the end of the day it doesn't matter if the value of 2 or 3 or > > 42 is used; if there's a mismatch on the the algorithm ID, the > > algorithm, or the key, the authentication will fail, and if it all > > matches, it will work. > > Strongly concur. > > There is though value in defining "MUST support" algos, otherwise > poor users could be faced with having routers which all implement > OSPF but can be made to interoperate unless authentication is left > unconfigured. > > MD5 at least should be defined as a MUST support. > > (Despite the pre-image weaknesses, it's still not yet completely > insecure in MAC mode) > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Aug 24 01:43:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG7zO-0000Jh-AO; Thu, 24 Aug 2006 01:42:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG7zN-0000DW-5v for ospf@ietf.org; Thu, 24 Aug 2006 01:42:49 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG7zL-0005BF-3y for ospf@ietf.org; Thu, 24 Aug 2006 01:42:49 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4H00CZ1N34P8@szxga02-in.huawei.com> for ospf@ietf.org; Thu, 24 Aug 2006 13:54:41 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4H001MNN34OM@szxga02-in.huawei.com> for ospf@ietf.org; Thu, 24 Aug 2006 13:54:40 +0800 (CST) Received: from dell60 ([10.18.7.146]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4H00CPIMTN4J@szxml04-in.huawei.com> for ospf@ietf.org; Thu, 24 Aug 2006 13:49:00 +0800 (CST) Date: Thu, 24 Aug 2006 11:06:49 +0530 From: sujay Subject: RE: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-reply-to: <77ead0ec0608232153j6eb2add0l42cbc084fe3c4ec3@mail.gmail.com> To: 'Vishwas Manral' , paul@jakma.org Message-id: <001601c6c73f$4c2d44a0$9207120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcbHOXspthwgVQ+TR2utIqxXNqmDIwABEZmw X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ospf@ietf.org, 'Mailing List' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Agree, While a failed authentication could be basically due to configuration issues or Mismatched algo's.Where 'Configuration' can be changed, but a 'not supported algo' may need an Image upgrade. It's my guess image upgrade may not be thoroughly welcome. We do need a 'Must' support algo. clause. Vishwas ; would it be a nice idea to add a section in the current draft, talking about this issue and with cross reference to the below mentioned drafts?? Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h &hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Thursday, August 24, 2006 10:24 AM To: paul@jakma.org Cc: ospf@ietf.org; Mailing List Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft Paul, > There is though value in defining "MUST support" algos, otherwise poor > users could be faced with having routers which all implement OSPF but > can be made to interoperate unless authentication is left > unconfigured. We have drafts to meet the following exact requirements: http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf-00.t xt and http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-00.t xt for OSPF and IS-IS respectively. Thanks, Vishwas On 8/24/06, Paul Jakma wrote: > On Wed, 23 Aug 2006, Dave Katz wrote: > > > Sigh. C'mon, folks, there is no problem. > > > At the end of the day it doesn't matter if the value of 2 or 3 or > > 42 is used; if there's a mismatch on the the algorithm ID, the > > algorithm, or the key, the authentication will fail, and if it all > > matches, it will work. > > Strongly concur. > > There is though value in defining "MUST support" algos, otherwise poor > users could be faced with having routers which all implement OSPF but > can be made to interoperate unless authentication is left > unconfigured. > > MD5 at least should be defined as a MUST support. > > (Despite the pre-image weaknesses, it's still not yet completely > insecure in MAC mode) > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Thu Aug 24 17:43:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGMxM-0001fK-Fo; Thu, 24 Aug 2006 17:41:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGMxK-0001fE-RS for ospf@ietf.org; Thu, 24 Aug 2006 17:41:42 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGMxH-0006RA-Dt for ospf@ietf.org; Thu, 24 Aug 2006 17:41:42 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 24 Aug 2006 14:41:38 -0700 X-IronPort-AV: i="4.08,165,1154934000"; d="scan'208"; a="313758579:sNHT34700492" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7OLfcvt014480 for ; Thu, 24 Aug 2006 14:41:38 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7OLfbw7005487 for ; Thu, 24 Aug 2006 14:41:38 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 17:41:37 -0400 Received: from [10.82.225.19] ([10.82.225.19]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Aug 2006 17:41:36 -0400 Message-ID: <44EE1D00.50502@cisco.com> Date: Thu, 24 Aug 2006 17:41:20 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 CC: OSPF List Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B7E563.3000706@cisco.com> <44B7E6D0.6030304@cisco.com> <44BD1FE6.2030202@earthlink.net> <44CAAB32.4B2A546D@earthlink.net> <44DB9074.8000700@earthlink.net> In-Reply-To: <44DB9074.8000700@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2006 21:41:36.0955 (UTC) FILETIME=[136620B0:01C6C7C6] DKIM-Signature: a=rsa-sha1; q=dns; l=3471; t=1156455698; x=1157319698; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20Database=20Exchange=20Summary=20List=20Optimization; X=v=3Dcisco.com=3B=20h=3DVwI3WZywBXmh7qJ9oTkEHQ724GE=3D; b=D52Qy8N0OOqYNNd7ksx1QApi11zulTA5COp3xNqQBWsK84GXOA4QFHiZMJl/XjoMNpNk1OXb dFW2oY8zvSEybkQVGb9XcfIZ3tN4MlqPPk9dxS79fkKJsZlewCrJvooK; Authentication-Results: sj-dkim-8.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org We had a majority of the attendees in favor of making this a WG document in Montreal. Is there anyone not in favor of adopting it as an informational WG document? I know there are those who feel we shouldn't publish any document that is fully compatible. However, in this case, IMHO, it is worthwhile for the WG to do so since: 1. WG discussion and review will verify with a high probability that this change is, in fact, fully backward compatible. 2. We'd be accepting a document that most people agree is a good thing to do - there is less disagreement on the details then some other proposals. 3. The relatively simple optimization can result in a significant decrease in DB exchange overhead. In fact, I predict option A will some day be in most implementations. Thanks, Acee Richard Ogier wrote: > I have submitted the following updated draft: > http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-01.txt > > The update incorporates comments of others and some ideas I presented > in my post on 7/18/2006. In particular, it describes three options > that differ in whether the LSAs must be listed in lexicographical order > and whether a router must fully process a received DD packet before > sending its next DD packet. To summarize: > > In Option A, the router is required to fully process a received DD > packet before sending the next DD packet in reply. > (LSAs are not listed in lexicographical order.) > > In Option B, the router with the larger DR level performs database > exchange as in RFC 2328 without change. The router with the smaller > DR level sends only empty DD packets (with no LSA headers) until it > has received the entire summary list from its neighbor (indicated > by M = 0), and then lists only LSAs that are more recent than those > received. I forgot to mention in the draft that Option B applies > only to broadcast (or MANET) interfaces. > > In Option C, the master lists LSAs in lexicographical order > and the slave lists LSAs in reverse lexicographical order, > as suggested by Mitchell Erblich. > > Regarding recent comments by Mitchell, I am not yet convinced that > there is any benefit to detecting whether a neighbor is nearly in sync > and using the optimization (with one of the three options) only if > the neighbor is nearly in sync, versus simply employing the > optimization. For example, in MANETs, it appears best to simply > employ the optimization with Option A. > Maybe you can provide a concrete, realistic example. > > Even if it does help to detect whether a neighbor is nearly in sync, > I am not sure that the (informational) document I am working on > needs to specify such a detection mechanism. Such a mechanism > could be specified in a separate document. Instead, the document I > am working on can just state that such a mechanism can be employed > if desired. If two routers are performing database exchange, the > protocol does not fail if only one of the routers decides to use > the optimization, or if one router decides to use Option A while the > other decides to use Option B or C. > > Of course, this optimization was motivated because we wanted > to reduce overhead in MANETs, and I would prefer to keep > the document as simple as possible. > > Richard > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From dict-bounces@fsa-bg.org Sat Aug 26 22:29:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHAOn-0002nT-15 for ospf-archive@lists.ietf.org; Sat, 26 Aug 2006 22:29:21 -0400 Received: from zver.fsa-bg.org ([62.44.101.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHAOk-0001mm-NT for ospf-archive@lists.ietf.org; Sat, 26 Aug 2006 22:29:21 -0400 Received: from zver.fsa-bg.org (localhost [::ffff:127.0.0.1]) by zver with esmtp; Sun, 27 Aug 2006 05:29:01 +0300 id 0000B1DF.44F1036D.00001157 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Dict awaits moderator approval From: dict-bounces@fsa-bg.org To: ospf-archive@lists.ietf.org Message-ID: Date: Sun, 27 Aug 2006 05:28:59 +0300 Precedence: bulk X-BeenThere: dict@fsa-bg.org X-Mailman-Version: 2.1.5 List-Id: Bulgarian translators' team X-List-Administrivia: yes Sender: dict-bounces@fsa-bg.org Errors-To: dict-bounces@fsa-bg.org X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Your mail to 'Dict' with the subject Mail System Error - Returned Mail Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://zver.fsa-bg.org/cgi-bin/mailman/confirm/dict/4ba0a6683f818256b0c95b868546ab63e45dc27b From MAILER-DAEMON Sun Aug 27 07:15:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHIc2-0004h6-7m for ospf-archive@lists.ietf.org; Sun, 27 Aug 2006 07:15:34 -0400 Received: from mail.1001.ru ([212.38.97.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHIc0-0001yX-TO for ospf-archive@lists.ietf.org; Sun, 27 Aug 2006 07:15:34 -0400 Subject: Undeliverable mail: Vjxassya From: MAILER-DAEMON@mail.1001.ru To: Date: Sun, 27 Aug 2006 15:15:24 +0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/report; report-type="delivery-status"; boundary="_===60568260====mail.1001.ru===_" X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --_===60568260====mail.1001.ru===_ Content-Type: text/plain; charset="utf-8" Failed to deliver to 'apollo-dev@ws.apache.org' SMTP module(domain @212.38.97.13:ws.apache.org) reports: message text rejected by asf.osuosl.org: 552 CMD attachments are not accepted here. --_===60568260====mail.1001.ru===_ Content-Type: message/delivery-status Reporting-MTA: dns; mail.1001.ru Original-Recipient: rfc822; Final-Recipient: rfc822; Action: failed Status: 5.0.0 --_===60568260====mail.1001.ru===_ Content-Type: text/rfc822-headers Received: from [172.23.103.13] (HELO varter.lukoil.ru) by mail.1001.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 60568242 for apollo-dev@ws.apache.org; Sun, 27 Aug 2006 15:14:56 +0400 Received: from lists.ietf.org [172.23.103.71] by varter.lukoil.ru [172.23.103.13] with ESMTP; Sun 27 Aug 2006 15:12:21 +0400 From: ospf-archive@lists.ietf.org To: apollo-dev@ws.apache.org Subject: Vjxassya Date: Sun, 27 Aug 2006 15:11:18 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_D474A17D.BF0C0889" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: --_===60568260====mail.1001.ru===_-- From ospf-bounces@ietf.org Mon Aug 28 07:54:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHfg3-0001K0-9l; Mon, 28 Aug 2006 07:53:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHfg2-0001Jh-IF for ospf@ietf.org; Mon, 28 Aug 2006 07:53:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHeNV-0003pk-32 for ospf@ietf.org; Mon, 28 Aug 2006 06:30:01 -0400 Received: from wx-out-0506.google.com ([66.249.82.236]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHeCo-0006wL-04 for ospf@ietf.org; Mon, 28 Aug 2006 06:19:00 -0400 Received: by wx-out-0506.google.com with SMTP id t4so1715484wxc for ; Mon, 28 Aug 2006 03:18:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ze7/ZoWJSspodN65yBiMcJAURgAzE05k9SCZg3AzrpjEZn9PKwD89Bl775wPbEqNNm1lmIX9R6TQ3FxnlvHysKzUFtM7cS2FsGtuE4tNozhCacpikkhxvTYF/zUx7aIHk8dmaFEbS66SW7KazcGrLgrBkqLISVJXBXOkRFU+uHo= Received: by 10.70.14.20 with SMTP id 20mr8988546wxn; Mon, 28 Aug 2006 03:18:57 -0700 (PDT) Received: by 10.70.33.3 with HTTP; Mon, 28 Aug 2006 03:18:56 -0700 (PDT) Message-ID: <77ead0ec0608280318p1b73e218v8bca87253ae30933@mail.gmail.com> Date: Mon, 28 Aug 2006 15:48:56 +0530 From: "Vishwas Manral" To: sujay Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-Reply-To: <001601c6c73f$4c2d44a0$9207120a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0608232153j6eb2add0l42cbc084fe3c4ec3@mail.gmail.com> <001601c6c73f$4c2d44a0$9207120a@china.huawei.com> X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ospf@ietf.org, paul@jakma.org, Mailing List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Sujay, I agree we can include that in the draft. The reason as well as the links to the draft. Thanks, Vishwas On 8/24/06, sujay wrote: > Agree, > While a failed authentication could be basically due to configuration issues > or > Mismatched algo's.Where 'Configuration' can be changed, but a 'not supported > algo' > may need an Image upgrade. It's my guess image upgrade may not be > thoroughly welcome. > We do need a 'Must' support algo. clause. > > Vishwas ; would it be a nice idea to add a section in the current draft, > talking about this issue > and with cross reference to the below mentioned drafts?? > > > Regds, > Sujay G > My Location; > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h > &hl=en > > > This e-mail and attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed > above. Any use of the information contained herein in any way (including, > but not limited to, total or partial disclosure, reproduction, or > dissemination) by persons other than the intended recipient's) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Thursday, August 24, 2006 10:24 AM > To: paul@jakma.org > Cc: ospf@ietf.org; Mailing List > Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft > > Paul, > > > There is though value in defining "MUST support" algos, otherwise poor > > users could be faced with having routers which all implement OSPF but > > can be made to interoperate unless authentication is left > > unconfigured. > We have drafts to meet the following exact requirements: > http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf-00.t > xt > and > http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-00.t > xt > > for OSPF and IS-IS respectively. > > Thanks, > Vishwas > > On 8/24/06, Paul Jakma wrote: > > On Wed, 23 Aug 2006, Dave Katz wrote: > > > > > Sigh. C'mon, folks, there is no problem. > > > > > At the end of the day it doesn't matter if the value of 2 or 3 or > > > 42 is used; if there's a mismatch on the the algorithm ID, the > > > algorithm, or the key, the authentication will fail, and if it all > > > matches, it will work. > > > > Strongly concur. > > > > There is though value in defining "MUST support" algos, otherwise poor > > users could be faced with having routers which all implement OSPF but > > can be made to interoperate unless authentication is left > > unconfigured. > > > > MD5 at least should be defined as a MUST support. > > > > (Despite the pre-image weaknesses, it's still not yet completely > > insecure in MAC mode) > > > > regards, > > -- > > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Mon Aug 28 17:15:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHoQl-0001NV-9c; Mon, 28 Aug 2006 17:14:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHoPz-0000yu-FB for ospf@ietf.org; Mon, 28 Aug 2006 17:13:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHnXZ-0003IL-HN for ospf@ietf.org; Mon, 28 Aug 2006 16:17:01 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHnSP-0007FN-U2 for ospf@ietf.org; Mon, 28 Aug 2006 16:11:44 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=QrrEOovwkrM8PnuYWBq+BYCwbMK8wraVQURhZGOT3HBYelO8QeJHbMSwDSATCBbu; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.91.216] (helo=earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GHnSI-0007QE-TX; Mon, 28 Aug 2006 16:11:35 -0400 Message-ID: <44F34E34.5CFD81A4@earthlink.net> Date: Mon, 28 Aug 2006 13:12:36 -0700 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Vishwas Manral Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft References: <77ead0ec0608232153j6eb2add0l42cbc084fe3c4ec3@mail.gmail.com> <001601c6c73f$4c2d44a0$9207120a@china.huawei.com> <77ead0ec0608280318p1b73e218v8bca87253ae30933@mail.gmail.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79b4fc5b86fdbb9ace153a64c3f263bb67350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.91.216 X-Spam-Score: -1.7 (-) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: ospf@ietf.org, paul@jakma.org, Mailing List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Group, Sometimes a minor opinion.. First. Up to this point, IMO, 99%+ nbr misconfigs could be debuged at 1 local router with review of incoming pkts. With this "work-in-progress", this will NO longer be the case if we overload type 2. What is a 'Must' clause going to achieve? By default ALL implementations support MD5, simple/clear, and NULL auth. The only high probability of a nbr formation is to use one of these three. Yes, MD5 was the defacto standand auth 2 algor. Thus, any algor that super-ceeds one of these auths, at this time, will not guarantee interoperability. However, as pointed out in the draft, the highest common auth is not highly secure, but could be used as a fall back. Yes, the admin would see either before or after a nbr formation attempt that a mismatch exists, and reconfigs the routers to use the fallback. Thus, to support backward compatibility and to secure against SOME attacks, IMO all configs SHOULD/MUST support MD5. If this is the case, would the clause only improve the chance that "MD5" is not removed as newer algors are supported? Or is their a thought for a algor other than MD5 to specified as the MUST algor? Mitchell Erblich ---------------- Vishwas Manral wrote: > > Sujay, > > I agree we can include that in the draft. The reason as well as the > links to the draft. > > Thanks, > Vishwas > > On 8/24/06, sujay wrote: > > Agree, > > While a failed authentication could be basically due to configuration issues > > or > > Mismatched algo's.Where 'Configuration' can be changed, but a 'not supported > > algo' > > may need an Image upgrade. It's my guess image upgrade may not be > > thoroughly welcome. > > We do need a 'Must' support algo. clause. > > > > Vishwas ; would it be a nice idea to add a section in the current draft, > > talking about this issue > > and with cross reference to the below mentioned drafts?? > > > > > > Regds, > > Sujay G > > My Location; > > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h > > &hl=en > > > > > > This e-mail and attachments contain confidential information from HUAWEI, > > which is intended only for the person or entity whose address is listed > > above. Any use of the information contained herein in any way (including, > > but not limited to, total or partial disclosure, reproduction, or > > dissemination) by persons other than the intended recipient's) is > > prohibited. If you receive this e-mail in error, please notify the sender by > > phone or email immediately and delete it! > > -----Original Message----- > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > Sent: Thursday, August 24, 2006 10:24 AM > > To: paul@jakma.org > > Cc: ospf@ietf.org; Mailing List > > Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft > > > > Paul, > > > > > There is though value in defining "MUST support" algos, otherwise poor > > > users could be faced with having routers which all implement OSPF but > > > can be made to interoperate unless authentication is left > > > unconfigured. > > We have drafts to meet the following exact requirements: > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf-00.t > > xt > > and > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-00.t > > xt > > > > for OSPF and IS-IS respectively. > > > > Thanks, > > Vishwas > > > > On 8/24/06, Paul Jakma wrote: > > > On Wed, 23 Aug 2006, Dave Katz wrote: > > > > > > > Sigh. C'mon, folks, there is no problem. > > > > > > > At the end of the day it doesn't matter if the value of 2 or 3 or > > > > 42 is used; if there's a mismatch on the the algorithm ID, the > > > > algorithm, or the key, the authentication will fail, and if it all > > > > matches, it will work. > > > > > > Strongly concur. > > > > > > There is though value in defining "MUST support" algos, otherwise poor > > > users could be faced with having routers which all implement OSPF but > > > can be made to interoperate unless authentication is left > > > unconfigured. > > > > > > MD5 at least should be defined as a MUST support. > > > > > > (Despite the pre-image weaknesses, it's still not yet completely > > > insecure in MAC mode) > > > > > > regards, > > > -- > > > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Aug 29 03:52:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHyNP-00070P-K6; Tue, 29 Aug 2006 03:51:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHyNN-00070A-Lk for ospf@ietf.org; Tue, 29 Aug 2006 03:51:13 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHyNM-0006GF-AX for ospf@ietf.org; Tue, 29 Aug 2006 03:51:13 -0400 Received: by wx-out-0506.google.com with SMTP id t4so2061132wxc for ; Tue, 29 Aug 2006 00:51:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IZZpI9yHunc/Iw0qcMag2SEeIc6J8+t7ljFWt6iBVYvY+Zh1MW8zX2wxUMVVWBJCGbqSbn3/m/LNLYUL1NRr+gC0Ia9+4TLsKAKNi8ftTJslplRmVzw8ZoHymgKvIIE1ERLc9fp4TgBlLy7In7df/xYWpZxxDa1Sz2V0EVDknMQ= Received: by 10.70.100.14 with SMTP id x14mr10913241wxb; Tue, 29 Aug 2006 00:51:11 -0700 (PDT) Received: by 10.70.33.3 with HTTP; Tue, 29 Aug 2006 00:51:11 -0700 (PDT) Message-ID: <77ead0ec0608290051x3610bfc9t9d024711cb5ea58a@mail.gmail.com> Date: Tue, 29 Aug 2006 13:21:11 +0530 From: "Vishwas Manral" To: Erblichs Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-Reply-To: <44F34E34.5CFD81A4@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0608232153j6eb2add0l42cbc084fe3c4ec3@mail.gmail.com> <001601c6c73f$4c2d44a0$9207120a@china.huawei.com> <77ead0ec0608280318p1b73e218v8bca87253ae30933@mail.gmail.com> <44F34E34.5CFD81A4@earthlink.net> X-Spam-Score: 1.9 (+) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: ospf@ietf.org, paul@jakma.org, Mailing List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Erblichs, If you read RFC4305, the implementation requirements have and must be changed. The implementation requirements are compared below: Old Old New Req. RFC(s) Requirement Algorithm (notes) --- ------ ----------- --------- MUST 2406 SHOULD NOT DES-CBC [RFC2405] (1) MUST 2402 2406 MAY HMAC-MD5-96 [RFC2403] MUST 2402 2406 MUST HMAC-SHA1-96 [RFC2404] We expect the same for all protocols utilizing the crypto algorithms. Thanks, Vishwas On 8/29/06, Erblichs wrote: > Group, > > Sometimes a minor opinion.. > > First. Up to this point, IMO, 99%+ nbr misconfigs > could be debuged at 1 local router with review of > incoming pkts. With this "work-in-progress", > this will NO longer be the case if we overload > type 2. > > What is a 'Must' clause going to achieve? > > By default ALL implementations support MD5, simple/clear, > and NULL auth. The only high probability of a nbr > formation is to use one of these three. Yes, MD5 was > the defacto standand auth 2 algor. > > Thus, any algor that super-ceeds one of these auths, > at this time, will not guarantee interoperability. > > However, as pointed out in the draft, the highest > common auth is not highly secure, but could be used > as a fall back. Yes, the admin would see either before > or after a nbr formation attempt that a mismatch > exists, and reconfigs the routers to use the fallback. > > Thus, to support backward compatibility and to secure > against SOME attacks, IMO all configs SHOULD/MUST support > MD5. > > If this is the case, would the clause only improve the > chance that "MD5" is not removed as newer algors are > supported? > > Or is their a thought for a algor other than MD5 to > specified as the MUST algor? > > > Mitchell Erblich > ---------------- > > > > > > Vishwas Manral wrote: > > > > Sujay, > > > > I agree we can include that in the draft. The reason as well as the > > links to the draft. > > > > Thanks, > > Vishwas > > > > On 8/24/06, sujay wrote: > > > Agree, > > > While a failed authentication could be basically due to configuration issues > > > or > > > Mismatched algo's.Where 'Configuration' can be changed, but a 'not supported > > > algo' > > > may need an Image upgrade. It's my guess image upgrade may not be > > > thoroughly welcome. > > > We do need a 'Must' support algo. clause. > > > > > > Vishwas ; would it be a nice idea to add a section in the current draft, > > > talking about this issue > > > and with cross reference to the below mentioned drafts?? > > > > > > > > > Regds, > > > Sujay G > > > My Location; > > > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h > > > &hl=en > > > > > > > > > This e-mail and attachments contain confidential information from HUAWEI, > > > which is intended only for the person or entity whose address is listed > > > above. Any use of the information contained herein in any way (including, > > > but not limited to, total or partial disclosure, reproduction, or > > > dissemination) by persons other than the intended recipient's) is > > > prohibited. If you receive this e-mail in error, please notify the sender by > > > phone or email immediately and delete it! > > > -----Original Message----- > > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > > Sent: Thursday, August 24, 2006 10:24 AM > > > To: paul@jakma.org > > > Cc: ospf@ietf.org; Mailing List > > > Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft > > > > > > Paul, > > > > > > > There is though value in defining "MUST support" algos, otherwise poor > > > > users could be faced with having routers which all implement OSPF but > > > > can be made to interoperate unless authentication is left > > > > unconfigured. > > > We have drafts to meet the following exact requirements: > > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf-00.t > > > xt > > > and > > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-00.t > > > xt > > > > > > for OSPF and IS-IS respectively. > > > > > > Thanks, > > > Vishwas > > > > > > On 8/24/06, Paul Jakma wrote: > > > > On Wed, 23 Aug 2006, Dave Katz wrote: > > > > > > > > > Sigh. C'mon, folks, there is no problem. > > > > > > > > > At the end of the day it doesn't matter if the value of 2 or 3 or > > > > > 42 is used; if there's a mismatch on the the algorithm ID, the > > > > > algorithm, or the key, the authentication will fail, and if it all > > > > > matches, it will work. > > > > > > > > Strongly concur. > > > > > > > > There is though value in defining "MUST support" algos, otherwise poor > > > > users could be faced with having routers which all implement OSPF but > > > > can be made to interoperate unless authentication is left > > > > unconfigured. > > > > > > > > MD5 at least should be defined as a MUST support. > > > > > > > > (Despite the pre-image weaknesses, it's still not yet completely > > > > insecure in MAC mode) > > > > > > > > regards, > > > > -- > > > > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > > > > > > _______________________________________________ > > > OSPF mailing list > > > OSPF@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ospf > > > > > > > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Aug 29 08:25:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI2dL-0002GX-NS; Tue, 29 Aug 2006 08:23:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI2dK-0002GN-Cu for ospf@ietf.org; Tue, 29 Aug 2006 08:23:58 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI2dI-00029X-1q for ospf@ietf.org; Tue, 29 Aug 2006 08:23:58 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 29 Aug 2006 05:23:47 -0700 X-IronPort-AV: i="4.08,180,1154934000"; d="scan'208"; a="315304182:sNHT12988642272" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7TCNkJa015099; Tue, 29 Aug 2006 05:23:46 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k7TCNj6Y010254; Tue, 29 Aug 2006 05:23:45 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 05:23:45 -0700 Received: from [10.21.145.148] ([10.21.145.148]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 05:23:45 -0700 Message-ID: <44F3AB01.3060503@cisco.com> Date: Mon, 28 Aug 2006 22:48:33 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: OSPF List Subject: Re: [OSPF] draft-ietf-ccamp-automesh-01.txt References: <44DCA819.4000802@cisco.com> In-Reply-To: <44DCA819.4000802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2006 12:23:45.0574 (UTC) FILETIME=[F8F77460:01C6CB65] DKIM-Signature: a=rsa-sha1; q=dns; l=872; t=1156854226; x=1157718226; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20draft-ietf-ccamp-automesh-01.txt; X=v=3Dcisco.com=3B=20h=3D8j11J++E6Pa/BZ2WZ4YQIfLMMcE=3D; b=BQ1OSD5KkSK8uRYQCLRyJhHGqlqLiH+PMl+AYiX2RFkz1vQrQf4DsMJa2s5VPyQp4xt+ujMs xnL7oMKL2EuExLjnXnjwoV9B0w7KoseXwEatm4pxB1G0Xim7iK0cauuE; Authentication-Results: sj-dkim-5.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ccamp@ops.ietf.org, David Ward X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org The OSPF WG last call has ended. Thanks, Acee Acee Lindem wrote: > The above draft makes use of the OSPF capabilities LSA. It is my > understanding that it has been last called in the ccamp WG. We are > now last calling it in the OSPF and ISIS WGs. > > The last call will start today (August 11, 2006) and end at 12:00 AM > on August 26th, 2006. Please copy this list and the document editors > (JP Vasseur and JL Leroux) with your comments. You can also copy the > ccamp list if you are subscribed (I believe the list is closed though > I'm not sure since I am subscribed). > > Here is a link for you convenience: > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-01.txt > > Thanks, > Acee > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Aug 29 10:16:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI4MF-0005Xt-GE; Tue, 29 Aug 2006 10:14:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI4ME-0005Xo-RO for ospf@ietf.org; Tue, 29 Aug 2006 10:14:26 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI4M6-0001ja-Mu for ospf@ietf.org; Tue, 29 Aug 2006 10:14:26 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4R001X3JE2QQ@szxga01-in.huawei.com> for ospf@ietf.org; Tue, 29 Aug 2006 22:10:50 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4R00ARQJDYYD@szxga01-in.huawei.com> for ospf@ietf.org; Tue, 29 Aug 2006 22:10:50 +0800 (CST) Received: from dell60 ([10.18.23.153]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4R00KAXJFAKS@szxml03-in.huawei.com> for ospf@ietf.org; Tue, 29 Aug 2006 22:11:38 +0800 (CST) Date: Tue, 29 Aug 2006 19:37:25 +0530 From: sujay To: ospf@ietf.org Message-id: <000f01c6cb74$74e271c0$9917120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_XV72nnM3JKji4fd92hLuFQ)" Thread-index: AcbLdCXvkX5YtOW7TEqTYyDscHwBogAAB9zw X-Spam-Score: 0.0 (/) X-Scan-Signature: d465bee15753def7c258f355435bdf03 Subject: [OSPF] Revision draft on OSPF Graceful Restart: draft-holla-update-ospf-graceful-restart-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_XV72nnM3JKji4fd92hLuFQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Please find attached a revised draft proposing improvements to existing OSPF Version2 graceful restart RFC. The 01 draft version was presented at the 66th meet, some points and feedbacks where also captured. http://www3.ietf.org/proceedings/06jul/slides/ospf-4/sld1.htm Some of which have been incorported ; 1.) It clarifies helper router behaviour on reception of multiple grace lsa's. 2.) Introduction of a "generic" Explicit Signalling from Helper signalling non participation. 3.) Configurable parameters section and certain possible implementation guidelines removed. It was also understood at the meet, that perhaps there is no *immediate* need for this draft. While we partially agree to it, our proposal in brief is; " The suggestions in the draft are just an 'add-on' over the current RFC3623, it in no way changes or requests for change in the current implementations. It is backwardly compatible.The proposals may be implemented in part or whole to achieve a significant improvement in GR convergence. It also resolves certain grey areas for protocol implementors. Hence; we would like to maintain this as an "Informational" document." Request any valuable comments or suggestions. For any queries please reply to sujayg@huawei.com; anupt@cisco.com ashok.chandrashekar@dartmouth.edu; Thanks & Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h &hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_XV72nnM3JKji4fd92hLuFQ) Content-type: text/plain; name=draft-holla-update-ospfv2-graceful-restart-02.txt Content-transfer-encoding: quoted-printable Content-disposition: attachment; filename=draft-holla-update-ospfv2-graceful-restart-02.txt =20 =20 Network Working Group =20 Internet Draft Ashok C. Holla,=20 Dartmouth College.=20 Anup Kumar T,=20 Cisco System.=20 Sujay Gupta,=20 Huawei Technologies.=20 =20 Document: draft-holla-update-ospfv2-graceful- =20 restart-02.txt=20 Expires: February 2007 August 2006=20 =20 =20 draft-holla-update-ospfv2-graceful-restart-02.txt=20 =20 Status of this Memo=20 =20 By submitting this Internet-Draft, each author represents that any=20 applicable patent or other IPR claims of which he or she is aware=20 have been or will be disclosed, and any of which he or she becomes=20 aware will be disclosed, in accordance with Section 6 of BCP 79.=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet-=20 Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt.=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 Copyright Notice=20 =20 Copyright (C) The Internet Society (2006).=20 =20 =20 Abstract=20 =20 This document suggests improvements to OSPF v2 Graceful Restart. The=20 basic protocol working remains as specified in [OSPFGR]. The draft=20 describes a two pronged approach for improving the current graceful=20 restart mechanism. It improves the restarting Router=92s ability to=20 =20 =20 Holla, Kumar & Gupta Expires - February 2007 [Page 1]=20 =0C draft-holla-update-ospfv2-graceful-restart-02.txt August = 2006=20 =20 =20 detect and react to topology changes. It also reduces the=20 conservative behavior of the helper Router in reacting to topology=20 changes. =20 In addition, it adds certain clarifications for interpretation of the = RFC 3623.=20 =20 =20 Conventions used in this document=20 =20 In the text "GR" indicates Graceful Restart.=20 The meaning of =91=91Restarting Router=92=92 and =91=91Helper = Router=92=92 are as per=20 [OSPFGR].=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 document are to be interpreted as described in RFC-2119.=20 =20 =20 Table of Contents=20 =20 1. Introduction...................................................2=20 2. Terminology....................................................3=20 2.1 Topology-Change LSAs.......................................3=20 2.2 Scope of the Topology-Change LSA...........................4=20 3. Enhancements to Graceful Restart mechanism.....................5=20 3.1 Operations of the Helper Router............................5=20 3.2 Operations of the Restarting Router........................7=20 3.3 Explicit feedback mechanism................................8=20 3.4 Mechanism 1: Grace LSA TLV Signaling.......................8=20 3.5 Mechanism 2: Link Local Signaling..........................9=20 3.6 Mechanism 3: One way hello Signaling.......................9=20 3.7 Recommendation............................................10=20 4. Security Considerations.......................................10=20 5. IANA Considerations...........................................10=20 6. Backward Compatibility........................................10=20 7. Special cases and considerations..............................10=20 8. Appendix......................................................11=20 Normative References.............................................13=20 Informative References...........................................13=20 Acknowledgments..................................................13=20 Authors=92 Addresses...............................................13 = Intellectual Property Statement..................................14=20 =20 =20 1. =0D Introduction=20 =20 This document suggests improvements to OSPF v2 Graceful Restart.=20 The basic protocol working remains as specified in [OSPFGR]. =20 =20 =20 =20 Holla, Kumar & Gupta Expires - February 2007 [Page 2]=20 =0C draft-holla-update-ospfv2-graceful-restart-02.txt August = 2006=20 =20 =20 Existing specification for Graceful restart in OSPFv2 has scope for=20 optimization in terms of overall convergence time and avoidance of=20 routing inconsistencies. This draft suggests methods to achieve the=20 same. It also clarifies some helper behavior on reception of multiple = grace LSA=92s.=20 =20 This draft provides mechanisms for the restarting Router to detect=20 and react to topology changes. It reduces the conservative behavior=20 of the helper Router in reacting to topology changes. It also=20 discusses introduction of an explicit mechanism through which a=20 Router can communicate its non participation as a Helper Router.=20 Further, certain clarification on interpreting multiple instances=20 Grace LSA=92s from the restarting router have been added.=20 =20 This document is organized as follows:=20 =20 Section 2 introduces the concept of =91Topology-Change LSA=92.=20 =20 Section 3.1 describes a less conservative approach to be taken by the = helper Router in reacting to topology changes.=20 =20 Section 3.2 describes the additional checks a Router under restart=20 should perform to ensure faster detection of a topology change to=20 facilitate an early exit of Graceful Restart.=20 =20 Section 3.3-7 introduces some explicit mechanisms that can be used by = the helper, to communicate with the restarting router. These=20 mechanisms signify the helper exiting the helper mode.=20 =20 The proposed suggestions are backward compatible with [OSPFGR].=20 =20 =20 2. =0D Terminology=20 2.1 =0D Topology-Change LSAs =20 =20 In [OSPFGR], helper routers detect topology changes by examining=20 =91changed LSAs=92 as prescribed in Section 3.3 [OSPFDC]. However, = this=20 notion of =91changed LSA=92 is very broad and can be reduced in scope = without affecting routing consistency. In this regard, the scope of a = =91Topology-Change LSA=92 is defined. =20 =20 =91Topology-Change LSAs=92 are =91bad news=92 versions of their = existing=20 counterparts in the database. A detailed definition follows in=20 section 2.2.=20 These LSAs definitely imply =91bad news=92 it should cause helper = routers=20 to exit helper mode immediately. Other LSAs may as well trigger a=20 router to exit helper mode. This is discussed in Section 3.1.=20 =20 =20 Holla, Kumar & Gupta Expires - February 2007 [Page 3]=20 =0C draft-holla-update-ospfv2-graceful-restart-02.txt August = 2006=20 =20 =20 =20 2.2 =0D Scope of the Topology-Change LSA =20 =20 For an LSA to qualify as a =91Topology-Change LSA=92, it must satisfy = one=20 of the following two requirements: =20 =20 (a) A Max-Aged LSA received or originated for which there exists a=20 previous database copy MUST be considered as =91Topology-Change = LSA=92=20 =20 (b) A modified LSA received or originated for which there exists a=20 previous database copy MUST be considered as =91Topology-Change = LSA=92=20 =20 All other LSAs received or originated MUST NOT be considered as=20 =91Topology-Change LSA=92. Thus, this class excludes periodic refresh = LSAs and also new LSAs without a previous database copy.=20 =20 In a further attempt to reduce the scope of =91Topology-Change = LSAs=92,=20 an implementation MAY choose to interpret non max-aged modified LSAs=20 {case (b) above} as follows:=20 =20 If any existing information described in the previous database copy=20 is missing or modified in the new LSA, then the new LSA MUST be=20 considered as a =91Topology-Change LSA=92.=20 =20 In this regard, the criteria for an LSA to be considered as=20 =91Topology-Change LSA=92 are:=20 =20 1. For Router LSA:=20 a. Change in the options field or any of the V, E or B bits in = the LSA.=20 b. Absence of any link piece (link ID, link Data tuple)=20 previously present in the database copy.=20 c. Change of the contents of an existing link piece (Ex:=20 metric)=20 =20 2. For Network LSA:=20 a. Change in the options field of the LSA.=20 b. Change in Network mask.=20 c. Absence of any previously attached router.=20 =20 3. Any modification in the summary LSAs should result in=20 considering it as =91Topology-Change LSA=92.=20 =20 4. For External and NSSA LSAs:=20 a. Change in the options field in the LSA.=20 b. Change of the network mask.=20 c. Change in the E bit setting (indicating the type of=20 External metric) or the metric. =20 =20 =20 =20 Holla, Kumar & Gupta Expires - February 2007 [Page 4]=20 =0C draft-holla-update-ospfv2-graceful-restart-02.txt August = 2006=20 =20 =20 A non max-aged changed LSA which does not exhibit any of the=20 modifications listed above, MAY NOT be considered as a =91Topology- Change LSA=92. This implies that if the change in the LSA is the=20 presence of any new information not found in the previous copy (Ex: a = new link piece in a Router LSA, a new attached router in a network=20 LSA etc), the LSA MAY NOT be considered as a =91Topology-Change = LSA=92.=20 =20 =20 3. =0D Enhancements to Graceful Restart mechanism. =20 3.1 =0D Operations of the Helper Router=20 =20 This section describes some modifications to the helper router=20 behavior. The basic protocol behavior remains as specified in Section = 3 of [OSPFGR].=20 =20 Whenever a helper router encounters a non-refresh LSA (section 3.2=20 [OSPFGR]) which has to be flooded to a restarting router, it exits=20 helper mode. This results in the restarting router quitting GR. This=20 constraint is overkill, and can be optimized.=20 =20 =20 3.1.1 =0D Entering Helper mode=20 =20 One of the criteria for a router to enter helper mode (section 3.1=20 [OSPFGR]) requires that all LSAs on the retransmit list on the helper = router for the restarting router, should be periodic refresh LSAs.=20 This criterion is conservative and can be relaxed. =20 In this draft, this has been achieved through an explicit definition=20 of a =91Topology-Change LSA=92 (Section 2.1). This definition reduces = the=20 scope of topology changes that necessitate a router to terminate=20 helper mode.=20 =20 In light of this, the checks that a Router (say Router Y) should=20 perform (Section 3.1 [OSPFGR]) while entering helper mode for a=20 restarting router (say Router X), are modified as follows:=20 On receiving Grace LSA from X, Y should examine the retransmit list=20 for X. If Y finds any =91Topology-Change LSA=92 on the retransmit = list=20 and, Y MUST NOT enter helper mode.=20 =20 Rest of the behavior should be as per section 3.1 [OSPFGR].=20 =20 =20 3.1.2 =0D Refusal to enter Helper mode=20 =20 In certain scenarios, a router may refuse to enter helper mode after=20 receiving Grace LSAs from a restarting router. This could be due to a = local policy configured on the router which prevents it from entering = helper mode for the particular restarting router, or the type of=20 graceful restart (planned/unplanned) or the duration of graceful=20 =20 =20 Holla, Kumar & Gupta Expires - February 2007 [Page 5]=20 =0C draft-holla-update-ospfv2-graceful-restart-02.txt August = 2006=20 =20 =20 restart. A router could refuse being a helper also due to the=20 presence of =91Topology-Change LSAs=92 on the retransmit list for the = restarting router. =20 =20 In such cases, the router SHOULD immediately explicitly signal to the = restarting router indicating its reluctance to enter helper mode. The = possible methods of achieving explicit signaling are explained in=20 Section 3.3.=20 =20 This helps the restarting router in making an informed decision on=20 whether to enter or abandon a Graceful Restart. In the absence of=20 this mechanism, the restarting router will enter a Graceful Restart=20 and later during adjacency formation, on examining the neighbor=92s=20 router/network LSA, it would exit graceful restart. With this=20 mechanism, the restarting router can immediately abandon graceful=20 restart. Therefore minimizing any possible routing inconsistencies=20 and improving the overall convergence time.=20 =20 =20 3.1.3 =0D Exiting Helper mode=20 =20 The existing criteria for exiting helper mode are very conservative.=20 They can be relaxed to ensure that the restarting router is made to=20 exit GR only when it is necessary to prevent routing inconsistencies. = This has been achieved through an explicit definition of =91Topology- Change LSA=92 in Section 2.1.=20 =20 1. Action on receiving or originating a =91Topology-Change LSA=92:=20 =20 If a helper router receives or originates a =91Topology-Change = LSA=92=20 and the LSA has to be flooded to a restarting router, the helper=20 router MUST immediately terminate helper mode for the restarting=20 router.=20 =20 This ensures that the restarting router=92s routing table does not = have any invalid routes. =20 =20 Other LSAs are to be flooded without the helper router exiting=20 helper mode. However, sometimes it may lead to routing holes, to=20 avoid it the helper router must additionally perform the below=20 mentioned check when performing route computation.=20 =20 =20 2. Action on Route Calculation: =20 =20 When a helper runs SPF [OSPF], if a route is added or modified=20 making a restarting router as the next hop, then the helper MUST=20 immediately exit helper mode for that restarting router.=20 =20 =20 Holla, Kumar & Gupta Expires - February 2007 [Page 6]=20 =0C draft-holla-update-ospfv2-graceful-restart-02.txt August = 2006=20 =20 =20 It may be argued that the action on route calculation is=20 sufficient and there is no need for a explicit definition and=20 handling of topology-change LSAs. However, such an approach is=20 suboptimal since routing holes are introduced for short periods.=20 Also, routing holes will be created on the GR router since the SPF = is not run for inter-area and external destinations. As such=20 inconsistencies could last until the completion of GR.=20 =20 Using both the mechanisms together is provably complete and=20 optimal.=20 =20 =20 =20 3.1.4 =0D Operation of Router when acting as Helper=20 =20 The Helper router (say Y) when supporting a graceful restart for a=20 specified router (say X) should additionally maintain the following=20 checks =20 1. If the Helper router receives a new instance of a grace LSA from = the restarting router. It should serve as helper for the new=20 grace period as specified in the new grace LSA, provided the=20 cumulative sum of the grace periods since running as helper for=20 the restarting router(X) is less than LSRefreshTime(1800=20 second)[OSPF]. This is to prevent possibility DOS attack.=20 2. If the Helper router receives a new grace LSA from the=20 restarting router with changed graceful restart reason TLV or IP = interface address [OSPFGR]. The helper should exit helping mode=20 and follow operations as specified in Section 3.1.4.=20 =20 =20 =20 3.1.5 =0D Operation of the Router on Exiting Helper Mode=20 =20 The helper router on exiting helper mode before the grace LSA=92s are = flushed by the restarting router SHOULD, explicitly signal this event = =20 to the restarting router (See Section 3.3), in addition to the=20 operations specified in Section 3.1[OSPFGR].=20 =20 =20 =20 3.2 =0D Operations of the Restarting Router=20 =20 This section describes some modifications to the restarting Router=20 behavior. Some responsibility of detecting topology changes has now=20 been placed on the restarting router. The basic protocol behavior=20 remains as specified in Section 3 [OSPFGR].=20 =20 3.2.1 =0D Exit Graceful Restart=20 =20 =20 =20 Holla, Kumar & Gupta Expires - February 2007 [Page 7]=20 =0C draft-holla-update-ospfv2-graceful-restart-02.txt August = 2006=20 =20 =20 A restarting router SHOULD perform the following actions along with=20 those mentioned in the =91=91Exit Graceful Restart=92=92 in Section = 2.2=20 [OSPFGR].=20 =20 1. If on the restarting router, the inactivity timer fires for a=20 neighbor, or there is a downward transition from 2-way to 1-way with=20 a neighbor, the router SHOULD exit graceful restart. =20 =20 =20 2. The restarting router, on receiving the explicit `exit-helper=92=20 signal (See description in Section 3.3) from the helper must=20 immediately quit GR.=20 =20 =20 3.3 =0D Explicit feedback mechanism.=20 =20 The restarting router learns about a router not supporting helper=20 mode by examining router and network LSAs (section 2.2 [OSPFGR]).=20 This mechanism is sub-optimal, and in some scenarios, ineffectual=20 (Section 8: Case A).=20 This draft proposes some methods for the helper routers to signal=20 events to the restarting router, which will improve the convergence=20 time as well as reduce the possibility of routing holes. The next=20 section discusses three mechanisms which may be used to this effect.=20 =20 =20 3.4 =0D Mechanism 1: Grace LSA TLV Signaling=20 It introduces an additional TLV for the Grace LSA, using which the=20 helper can explicitly signal its non-participation as as a helper=20 router.=20 =20 3.4.1 =0D Sending Grace LSA with the Exit-Grace TLV.=20 =20 The Grace LSA with the Exit-Grace TLV SHOULD be sent as unicast=20 Packets to the restarting router on Broadcast, NBMA and P2MP=20 networks. However, on P2P interfaces, the packet should be sent to=20 AllSPFRouters. [OSPF]=20 When this TLV is included, the mandatory Grace TLV (described in=20 [OSPFGR]) MUST NOT be included in the LSA. =20 The sending of this Exit-Grace TLV MAY be made reliable. =20 =20 3.4.2 =0D Receiving Grace LSA with Exit-Grace TLV. =20 =20 A router, on receiving grace LSA containing the Exit-grace TLV from a = neighbor, MUST acknowledge the LSA. The LSA MUST NOT be stored in the = database or flooded. If the receiving router is under graceful- restart, it must immediately exit graceful restart. If the receiving=20 router is not under Graceful Restart, the TLV will have no impact on=20 the operations of the router.=20 =20 =20 Holla, Kumar & Gupta Expires - February 2007 [Page 8]=20 =0C draft-holla-update-ospfv2-graceful-restart-02.txt August = 2006=20 =20 =20 =20 3.4.3 =0D Format of Exit-Grace LSA TLV=20 =20 (See Appendix for Format)=20 =20 =20 3.5 =0D Mechanism 2: Link Local Signaling=20 This mechanism uses the ideas presented in [OSPFLLS]. It introduces=20 an additional LLS Exit-Grace TLV to indicate the helper=92s non- participation (See Appendix for Format). This LLS TLV should be sent=20 in Hello packets [OSPFLLS].=20 =20 3.5.1 =0D Sending LLS Exit-Grace TLV in the Hello packet.=20 =20 The helper router if LLS capable should append the Exit-Grace TLV to=20 all Hello packets sent out of its interface to the restarting router=20 after exiting helper mode. As signaling using Hello packets is=20 unreliable, an implementation MAY continue signaling until the grace- period expires or the grace-LSA is flushed.=20 =20 3.5.2 =0D Receiving LLS Exit-Grace TLV =20 =20 A router if LLS capable and undergoing graceful restart, on receiving = an LLS Exit-Grace TLV should examine if the Router ID in the TLV=20 matches with its own. If it matches it should immediately exit=20 graceful restart.=20 =20 3.5.3 =0D Format of Exit-Grace LLS TLV=20 =20 (See Appendix for Format)=20 =20 =20 3.6 =0D Mechanism 3: One way hello Signaling=20 The helper router sends a one-way hello to the restarting router=20 indicating its non-participation as a helper.=20 =20 3.6.1 =0D Operation of the Helper on sending one-way hello=20 The helper router should send a one-way hello to the restarting=20 router but in doing so should not change its adjacency relationship=20 with the restarting router. In particular the one way hello should=20 not trigger a one way event. Other operations remain as specified in=20 [OSPF] and [OSPFGR]. The restarting router on receiving a one-way=20 hello should exit GR. This is covered is Section 3.2.1 [1].=20 =20 =20 =0C=20 =20 Holla, Kumar & Gupta Expires - February 2007 [Page 9]=20 =0C draft-holla-update-ospfv2-graceful-restart-02.txt August = 2006=20 =20 =20 3.7 =0D Recommendation=20 =20 Among the above specified mechanisms of explicit signaling it is=20 recommended that the Helper use Mechanism 2 as specified above in=20 Section 3.5.=20 =20 =20 4. =0D Security Considerations=20 =20 This draft raises no new security considerations other than that=20 covered in [OSPFGR] and [OSPF].=20 =20 =20 5. =0D IANA Considerations=20 =20 This document describes a new TLV for Grace LSAs. The TLV type is to=20 be assigned by IANA. The suggested value is 4. (Refer IANA). This=20 document suggests using an Exit Grace LLS TLV. The TLV type for which = is to be assigned by IANA.=20 =20 =20 6. =0D Backward Compatibility=20 =20 The compliance of the feature mentioned here, allows for faster and=20 optimal detection of topology changes and thus faster convergence. If = one or more neighbors do not support Exit-Grace LSA TLV/Exit Grace=20 LLS TLV and/or other features mentioned above and support only RFC=20 3623, the protocol behavior specified in [OSPFGR] remains unimpaired. = =20 However, one anomaly for backward compatibility introduced by this=20 draft is documented in Section 7.=20 =20 =20 7. =0D Special cases and considerations=20 =20 =20 Area 0=20 RT1-----------------X-----------------RT2---------RT3=20 =20 =20 In the above topology RT1, X, RT2 and RT3 are all in area 0 =20 X and RT2 are implementations which are based on this draft. However, = RT1 is based on [OSPFGR] only.=20 Scenario:=20 X having initiated GR has completed adjacency formation with helper=20 RT1, but, is still in the process of forming adjacency with RT2. At=20 this point, RT3 originates a NEW type-5 LSA. Due to the nature of the = modifications proposed in this draft, RT2 will not exit helper mode=20 on receipt of this LSA from RT3 (refer sections 2.1 and 3.1.3).=20 However, since X will flood this LSA to RT1, RT1 will exit helper=20 =20 =20 =0CHolla, Kumar & Gupta Expires - February 2007 [Page 10] = =0C draft-holla-update-ospfv2-graceful-restart-02.txt August = 2006=20 =20 =20 mode. Since, RT1 and X are full with each other, X cannot detect RT1=20 quitting helper mode. Therefore, X continues with GR WITHOUT adding a = route to the destination described by the new LSA, as X does not=20 update its forwarding table during GR. This results in a routing=20 hole. This condition will persist until X exits graceful restart.=20 =20 =20 8. =0D Appendix=20 =20 Format of Exit-Grace LSA TLV:=20 =20 The Exit-Grace LSA TLV is enclosed in the Opaque link-local scoped=20 Grace LSA. The format of the Grace LSA is specified in [OSPFGR].=20 =20 =20 =20 =20 The format of the Exit-Grace TLV is described below.=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Value |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 The type field of the Exit-Grace TLV is assigned an experimental=20 value of 4. The length field, defining the length of the value field=20 in octets, MUST be 4. For non P2P networks, the value MUST be the IP=20 address of the interface through which the helper sends the Grace=20 LSA. For P2P networks, the value MUST be the Router-ID of the helper=20 router.=20 =20 If the above TLV is present in a Grace LSA, it is mandatory for the=20 Grace-Period TLV to be absent. The absence of the Grace-Period TLV=20 ensures the Receiving router dropping the LSA, as the Grace-Period=20 TLV is specified as mandatory in [OSPFGR].In particular this ensures=20 that implementations not supporting the Exit-Grace TLV will not=20 process the LSA.=20 =20 The format of the Grace LSA other than the addition of the above TLV=20 remains same as that mentioned in [OSPFGR].=20 =20 =20 Format of the Exit-Grace LLS TLV:=20 =20 The Exit-Grace LSA TLV is sent in the Hello packet by the helper=20 router.=20 =20 =20 Holla, Kumar & Gupta Expires - February 2007 [Page 11]=20 =0C draft-holla-update-ospfv2-graceful-restart-02.txt August = 2006=20 =20 =20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Type | Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Value |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 The type field of the Exit-LLS TLV is to be assigned a value. The=20 length field, defining the length of the value field in octets, MUST=20 be 4. The value MUST contain Router-ID of the restarting router and=20 not that of the Helper router.=20 =20 =20 =20 Case A=20 =20 Since the protocol [OSPFGR] does not provide a method for a helper=20 router to notify the restarting router, its exit of helper mode after = the adjacency formation is complete, there are possibilities of=20 routing holes existing for a bounded period of time, grace LSA being=20 flushed or grace period expiry.=20 =20 Ex: =20 =20 Area 0=20 RT1-----------------X-----------------RT2---------RT3=20 |=20 Area 1 |=20 |=20 RT4=20 =20 =20 In the above topology RT1, X, RT2 and RT3 are all in area 0; X and=20 RT4 are in Area 1 which is a stub area.=20 =20 Scenario:=20 X having initiated GR has completed adjacency formation with helpers=20 RT1 and RT2 and still in the process of forming adjacency with RT4.=20 At this point, RT3 originates a new type-5 LSA. Due to the nature of=20 the protocol, RT2 and RT1 will exit helper mode on receipt of this=20 LSA from RT3 and X respectively. Since, X will not send this LSA to=20 RT4, RT4 will not exit helper mode. RT1 and RT2 have no mechanism to=20 inform X about their quitting of helper mode (since they are already=20 full with X). Therefore, X continues with GR WITHOUT adding a route=20 to the destination described by the new LSA, as X will not update the = forwarding table during GR. This results in a routing hole being=20 created at X. This condition will persist until X exits GR.=20 =20 =20 Holla, Kumar & Gupta Expires - February 2007 [Page 12]=20 =0C draft-holla-update-ospfv2-graceful-restart-02.txt August = 2006=20 =20 =20 =20 =20 =20 =20 Normative References=20 =20 [OSPFGR] Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF=20 Restart", RFC 3623, November 2003.=20 =20 [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.=20 =20 [OSPFDC] Moy, J., =91=91Extending OSPF to support Demand = Circuits=92=92, RFC=20 1793, April 1995.=20 =20 [OSPFLLS] Zinn A., et.al, =91=91OSPF Link-Local Signalling=92=92, = draft-ietf- ospf-lls-01.txt, June 2006.=20 =20 Informative References=20 =20 [IANA] Kompella.K, =91=91IANA Considerations for OSPF=92=92, = draft-ietf-ospf- iana-01, work in progress.=20 =20 Acknowledgments=20 =20 The authors wish to thank Acce Lindem, Vishwas Manral, Don Goodspeed, = Pradeep Shastry, K.L Srini, Saravanak, Abhay, Abhishek and Sandeep=20 for their insightful comments and suggestions. =20 =20 =20 Authors=92 Addresses=20 =20 Ashok Chandrashekhar Holla=20 Dartmouth College=20 NH, U.S.A=20 ashok.chandrashekar@dartmouth.edu=20 =20 Anup Kumar T=20 Cisco Systems=20 Bangalore,India.=20 anupt@cisco.com=20 =20 =20 Sujay Gupta=20 Huawei Technologies=20 Bangalore,India =20 sujayg@huawei.com=20 =20 =20 =20 =20 Holla, Kumar & Gupta Expires - February 2007 [Page 13]=20 =0C draft-holla-update-ospfv2-graceful-restart-02.txt August = 2006=20 =20 =20 Intellectual Property Statement=20 =20 The IETF takes no position regarding the validity or scope of any=20 Intellectual Property Rights or other rights that might be claimed to = pertain to the implementation or use of the technology described in=20 this document or the extent to which any license under such rights=20 might or might not be available; nor does it represent that it has=20 made any independent effort to identify any such rights. Information = on the procedures with respect to rights in RFC documents can be=20 found in BCP 78 and BCP 79.=20 =20 Copies of IPR disclosures made to the IETF Secretariat and any=20 assurances of licenses to be made available, or the result of an=20 attempt made to obtain a general license or permission for the use of = such proprietary rights by implementers or users of this=20 specification can be obtained from the IETF on-line IPR repository at = http://www.ietf.org/ipr.=20 =20 The IETF invites any interested party to bring to its attention any=20 copyrights, patents or patent applications, or other proprietary=20 rights that may cover technology that may be required to implement=20 this standard. Please address the information to the IETF at ietf- ipr@ietf.org. =20 =20 =20 Disclaimer of Validity=20 =20 This document and the information contained herein are provided on an = "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS = OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=20 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=20 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=20 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 =20 Copyright Statement =20 =20 Copyright (C) The Internet Society (2006). This document is subject=20 to the rights, licenses and restrictions contained in BCP 78, and=20 except as set forth therein, the authors retain all their rights.=20 =20 =20 Acknowledgment=20 =20 Funding for the RFC Editor function is currently provided by the=20 Internet Society.=20 =20 =20 =20 Holla, Kumar & Gupta Expires - February 2007 [Page 14]=20 =0C= --Boundary_(ID_XV72nnM3JKji4fd92hLuFQ) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --Boundary_(ID_XV72nnM3JKji4fd92hLuFQ)-- From ospf-bounces@ietf.org Tue Aug 29 12:00:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI5zJ-0004yX-VQ; Tue, 29 Aug 2006 11:58:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI5zI-0004wJ-4G for ospf@ietf.org; Tue, 29 Aug 2006 11:58:52 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI5zH-0000Ox-P3 for ospf@ietf.org; Tue, 29 Aug 2006 11:58:52 -0400 Received: by py-out-1112.google.com with SMTP id e30so1347166pya for ; Tue, 29 Aug 2006 08:58:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JXI5ojcuXqrk2HGdIlskby9MeH0l462Y4rRsRaovKqgACNR4Saamf3cKNJ8pqLjsAEtKNxP849gGEO17kREeJfJROM49VATFUtGU9wdechxComMJ+pEe5BcOxeeM42UVZfxEcl9w/EhWyGQ0IPZ5W2dC3vuM05Ed6gyZa4aY9VY= Received: by 10.35.127.7 with SMTP id e7mr15176078pyn; Tue, 29 Aug 2006 08:58:51 -0700 (PDT) Received: by 10.35.128.10 with HTTP; Tue, 29 Aug 2006 08:58:51 -0700 (PDT) Message-ID: <6ed23a860608290858g201e84f4pc0a5b757053a5f44@mail.gmail.com> Date: Tue, 29 Aug 2006 21:28:51 +0530 From: "Tom Sanders" To: Erblichs Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-Reply-To: <44F34E34.5CFD81A4@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0608232153j6eb2add0l42cbc084fe3c4ec3@mail.gmail.com> <001601c6c73f$4c2d44a0$9207120a@china.huawei.com> <77ead0ec0608280318p1b73e218v8bca87253ae30933@mail.gmail.com> <44F34E34.5CFD81A4@earthlink.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: ospf@ietf.org, paul@jakma.org, Mailing List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Erblichs, I am not sure if Vishwas addressed your concern. If he did, then i am at fault in understanding your concern. However, let me give it a shot. > First. Up to this point, IMO, 99%+ nbr misconfigs > could be debuged at 1 local router with review of > incoming pkts. With this "work-in-progress", > this will NO longer be the case if we overload > type 2. > > What is a 'Must' clause going to achieve? > > By default ALL implementations support MD5, simple/clear, > and NULL auth. The only high probability of a nbr > formation is to use one of these three. Yes, MD5 was > the defacto standand auth 2 algor. > > Thus, any algor that super-ceeds one of these auths, > at this time, will not guarantee interoperability. > > However, as pointed out in the draft, the highest > common auth is not highly secure, but could be used > as a fall back. Yes, the admin would see either before > or after a nbr formation attempt that a mismatch > exists, and reconfigs the routers to use the fallback. > > Thus, to support backward compatibility and to secure > against SOME attacks, IMO all configs SHOULD/MUST support > MD5. > > If this is the case, would the clause only improve the > chance that "MD5" is not removed as newer algors are > supported? > > Or is their a thought for a algor other than MD5 to > specified as the MUST algor? > > > Mitchell Erblich > ---------------- > > > > > > Vishwas Manral wrote: > > > > Sujay, > > > > I agree we can include that in the draft. The reason as well as the > > links to the draft. > > > > Thanks, > > Vishwas > > > > On 8/24/06, sujay wrote: > > > Agree, > > > While a failed authentication could be basically due to configuration issues > > > or > > > Mismatched algo's.Where 'Configuration' can be changed, but a 'not supported > > > algo' > > > may need an Image upgrade. It's my guess image upgrade may not be > > > thoroughly welcome. > > > We do need a 'Must' support algo. clause. > > > > > > Vishwas ; would it be a nice idea to add a section in the current draft, > > > talking about this issue > > > and with cross reference to the below mentioned drafts?? > > > > > > > > > Regds, > > > Sujay G > > > My Location; > > > http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h > > > &hl=en > > > > > > > > > This e-mail and attachments contain confidential information from HUAWEI, > > > which is intended only for the person or entity whose address is listed > > > above. Any use of the information contained herein in any way (including, > > > but not limited to, total or partial disclosure, reproduction, or > > > dissemination) by persons other than the intended recipient's) is > > > prohibited. If you receive this e-mail in error, please notify the sender by > > > phone or email immediately and delete it! > > > -----Original Message----- > > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > > Sent: Thursday, August 24, 2006 10:24 AM > > > To: paul@jakma.org > > > Cc: ospf@ietf.org; Mailing List > > > Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft > > > > > > Paul, > > > > > > > There is though value in defining "MUST support" algos, otherwise poor > > > > users could be faced with having routers which all implement OSPF but > > > > can be made to interoperate unless authentication is left > > > > unconfigured. > > > We have drafts to meet the following exact requirements: > > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf-00.t > > > xt > > > and > > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-00.t > > > xt > > > > > > for OSPF and IS-IS respectively. > > > > > > Thanks, > > > Vishwas > > > > > > On 8/24/06, Paul Jakma wrote: > > > > On Wed, 23 Aug 2006, Dave Katz wrote: > > > > > > > > > Sigh. C'mon, folks, there is no problem. > > > > > > > > > At the end of the day it doesn't matter if the value of 2 or 3 or > > > > > 42 is used; if there's a mismatch on the the algorithm ID, the > > > > > algorithm, or the key, the authentication will fail, and if it all > > > > > matches, it will work. > > > > > > > > Strongly concur. > > > > > > > > There is though value in defining "MUST support" algos, otherwise poor > > > > users could be faced with having routers which all implement OSPF but > > > > can be made to interoperate unless authentication is left > > > > unconfigured. > > > > > > > > MD5 at least should be defined as a MUST support. > > > > > > > > (Despite the pre-image weaknesses, it's still not yet completely > > > > insecure in MAC mode) > > > > > > > > regards, > > > > -- > > > > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > > > > > > _______________________________________________ > > > OSPF mailing list > > > OSPF@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ospf > > > > > > > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > -- Toms. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Aug 29 12:08:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI688-0003aj-2l; Tue, 29 Aug 2006 12:08:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI686-0003ad-Pg for ospf@ietf.org; Tue, 29 Aug 2006 12:07:58 -0400 Received: from nz-out-0102.google.com ([64.233.162.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI684-0002RI-Hs for ospf@ietf.org; Tue, 29 Aug 2006 12:07:58 -0400 Received: by nz-out-0102.google.com with SMTP id q3so1347643nzb for ; Tue, 29 Aug 2006 09:07:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AUCV31b/z4rQvhKDKkQocJqetbcUZB48jZjrjdnEu0jfbTLbQxCd4HzCwCarwNJ61h6n3bGs2HYezy4Jw2USgGi6uNEQgOJDEEC4Pi347+R+aX1Dd+n2qGrvSS2DOG/C/J/TkINzn69aGfinQnIGNyxgiApd9QS7q4moF16Hdsc= Received: by 10.35.87.8 with SMTP id p8mr15213166pyl; Tue, 29 Aug 2006 09:07:56 -0700 (PDT) Received: by 10.35.128.10 with HTTP; Tue, 29 Aug 2006 09:07:55 -0700 (PDT) Message-ID: <6ed23a860608290907w7c8a118at95341eda10f0debe@mail.gmail.com> Date: Tue, 29 Aug 2006 21:37:55 +0530 From: "Tom Sanders" To: Erblichs Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft In-Reply-To: <6ed23a860608290858g201e84f4pc0a5b757053a5f44@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0608232153j6eb2add0l42cbc084fe3c4ec3@mail.gmail.com> <001601c6c73f$4c2d44a0$9207120a@china.huawei.com> <77ead0ec0608280318p1b73e218v8bca87253ae30933@mail.gmail.com> <44F34E34.5CFD81A4@earthlink.net> <6ed23a860608290858g201e84f4pc0a5b757053a5f44@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ospf@ietf.org, paul@jakma.org, Mailing List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Sorry .. I sent an incomplete mail .. ;) On 29/08/06, Tom Sanders wrote: > Erblichs, > > I am not sure if Vishwas addressed your concern. If he did, then i am > at fault in understanding your concern. However, let me give it a > shot. > > > First. Up to this point, IMO, 99%+ nbr misconfigs > > could be debuged at 1 local router with review of > > incoming pkts. With this "work-in-progress", > > this will NO longer be the case if we overload > > type 2. I assume you are at this point referring to draft-bhatia-manral-white-ospf-hmac-sha-02.txt. Lets not rehash the same discussion regarding overloading Auth 2 here. > > > > What is a 'Must' clause going to achieve? > > > > By default ALL implementations support MD5, simple/clear, > > and NULL auth. The only high probability of a nbr > > formation is to use one of these three. Yes, MD5 was > > the defacto standand auth 2 algor. > > > > Thus, any algor that super-ceeds one of these auths, > > at this time, will not guarantee interoperability. Which is where the draft-bhatia-manral-crypto-req-ospf-00.txt helps. The authors can correct me if i am wrong in my understanding here. > > > > However, as pointed out in the draft, the highest > > common auth is not highly secure, but could be used > > as a fall back. Yes, the admin would see either before > > or after a nbr formation attempt that a mismatch > > exists, and reconfigs the routers to use the fallback. > > > > Thus, to support backward compatibility and to secure > > against SOME attacks, IMO all configs SHOULD/MUST support > > MD5. > > > > If this is the case, would the clause only improve the > > chance that "MD5" is not removed as newer algors are > > supported? > > > > Or is their a thought for a algor other than MD5 to > > specified as the MUST algor? MD5 is MUST- while HMAC-SHA-1 is SHOULD+. I think the definitions in the beginning of the draft would help. Reading those again tells me that we may at some later point deprecate MD5 and mandate support for hmac-sha-1 for all the implementations. hmac-sha-1 would then be a MUST and the other higher variants of hmac-sha SHOULD+. Toms. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Tue Aug 29 13:51:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI7jl-0003wS-R6; Tue, 29 Aug 2006 13:50:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI7jk-0003rO-Ci for ospf@ietf.org; Tue, 29 Aug 2006 13:50:56 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI7bX-00077J-EI for ospf@ietf.org; Tue, 29 Aug 2006 13:42:31 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Aug 2006 10:42:27 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7THgQjN024757; Tue, 29 Aug 2006 10:42:26 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7THgQ1E025907; Tue, 29 Aug 2006 10:42:26 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Aug 2006 10:42:26 -0700 Received: from [171.69.220.49] ([171.69.220.49]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Aug 2006 10:42:26 -0700 Message-ID: <44F47C81.3000904@cisco.com> Date: Tue, 29 Aug 2006 13:42:25 -0400 From: Acee Lindem User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Erblichs Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft References: <77ead0ec0608232153j6eb2add0l42cbc084fe3c4ec3@mail.gmail.com> <001601c6c73f$4c2d44a0$9207120a@china.huawei.com> <77ead0ec0608280318p1b73e218v8bca87253ae30933@mail.gmail.com> <44F34E34.5CFD81A4@earthlink.net> In-Reply-To: <44F34E34.5CFD81A4@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2006 17:42:26.0277 (UTC) FILETIME=[7DCB3150:01C6CB92] DKIM-Signature: a=rsa-sha1; q=dns; l=5461; t=1156873346; x=1157737346; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20 |Subject:Re=3A=20[OSPF]=20Revised=20OSPF=20HMAC=20SHA=20Authentication=20Draft; X=v=3Dcisco.com=3B=20h=3DMeR/SxigpRzFXQLs7M50692+1WQ=3D; b=cUZarq/RvoFnr5hC43O6IDz9n8o9zaIKs9TxUgUFvCwcCfPRkZcQxp1/b779InmzHKR4hQz0 /mVqLKez0cW9zwmRPdEJfuq5hiALRCIup6RbE3XHhtbasjjbZ9SOW18Q; Authentication-Results: sj-dkim-2.cisco.com; header.From=acee@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: ospf@ietf.org, paul@jakma.org, Mailing List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org Hi Mitchell, Erblichs wrote: > Group, > > Sometimes a minor opinion.. > > First. Up to this point, IMO, 99%+ nbr misconfigs > could be debuged at 1 local router with review of > incoming pkts. With this "work-in-progress", > this will NO longer be the case if we overload > type 2. > I believe Dave Katz already made this point. However, let me apply it to your statement. Previously, you could have a key mismatch. With the new draft you can have a key/algorithm mismatch - I don't see that this is that big a change. Thanks, Acee > What is a 'Must' clause going to achieve? > > By default ALL implementations support MD5, simple/clear, > and NULL auth. The only high probability of a nbr > formation is to use one of these three. Yes, MD5 was > the defacto standand auth 2 algor. > > Thus, any algor that super-ceeds one of these auths, > at this time, will not guarantee interoperability. > > However, as pointed out in the draft, the highest > common auth is not highly secure, but could be used > as a fall back. Yes, the admin would see either before > or after a nbr formation attempt that a mismatch > exists, and reconfigs the routers to use the fallback. > > Thus, to support backward compatibility and to secure > against SOME attacks, IMO all configs SHOULD/MUST support > MD5. > > If this is the case, would the clause only improve the > chance that "MD5" is not removed as newer algors are > supported? > > Or is their a thought for a algor other than MD5 to > specified as the MUST algor? > > > Mitchell Erblich > ---------------- > > > > > > Vishwas Manral wrote: > >> Sujay, >> >> I agree we can include that in the draft. The reason as well as the >> links to the draft. >> >> Thanks, >> Vishwas >> >> On 8/24/06, sujay wrote: >> >>> Agree, >>> While a failed authentication could be basically due to configuration issues >>> or >>> Mismatched algo's.Where 'Configuration' can be changed, but a 'not supported >>> algo' >>> may need an Image upgrade. It's my guess image upgrade may not be >>> thoroughly welcome. >>> We do need a 'Must' support algo. clause. >>> >>> Vishwas ; would it be a nice idea to add a section in the current draft, >>> talking about this issue >>> and with cross reference to the below mentioned drafts?? >>> >>> >>> Regds, >>> Sujay G >>> My Location; >>> http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h >>> &hl=en >>> >>> >>> This e-mail and attachments contain confidential information from HUAWEI, >>> which is intended only for the person or entity whose address is listed >>> above. Any use of the information contained herein in any way (including, >>> but not limited to, total or partial disclosure, reproduction, or >>> dissemination) by persons other than the intended recipient's) is >>> prohibited. If you receive this e-mail in error, please notify the sender by >>> phone or email immediately and delete it! >>> -----Original Message----- >>> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >>> Sent: Thursday, August 24, 2006 10:24 AM >>> To: paul@jakma.org >>> Cc: ospf@ietf.org; Mailing List >>> Subject: Re: [OSPF] Revised OSPF HMAC SHA Authentication Draft >>> >>> Paul, >>> >>> >>>> There is though value in defining "MUST support" algos, otherwise poor >>>> users could be faced with having routers which all implement OSPF but >>>> can be made to interoperate unless authentication is left >>>> unconfigured. >>>> >>> We have drafts to meet the following exact requirements: >>> http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-ospf-00.t >>> xt >>> and >>> http://www.ietf.org/internet-drafts/draft-bhatia-manral-crypto-req-isis-00.t >>> xt >>> >>> for OSPF and IS-IS respectively. >>> >>> Thanks, >>> Vishwas >>> >>> On 8/24/06, Paul Jakma wrote: >>> >>>> On Wed, 23 Aug 2006, Dave Katz wrote: >>>> >>>> >>>>> Sigh. C'mon, folks, there is no problem. >>>>> >>>>> At the end of the day it doesn't matter if the value of 2 or 3 or >>>>> 42 is used; if there's a mismatch on the the algorithm ID, the >>>>> algorithm, or the key, the authentication will fail, and if it all >>>>> matches, it will work. >>>>> >>>> Strongly concur. >>>> >>>> There is though value in defining "MUST support" algos, otherwise poor >>>> users could be faced with having routers which all implement OSPF but >>>> can be made to interoperate unless authentication is left >>>> unconfigured. >>>> >>>> MD5 at least should be defined as a MUST support. >>>> >>>> (Despite the pre-image weaknesses, it's still not yet completely >>>> insecure in MAC mode) >>>> >>>> regards, >>>> -- >>>> Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A >>>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ospf >>> >>> >>> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf From ospf-bounces@ietf.org Wed Aug 30 01:29:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIIbn-0002l7-1W; Wed, 30 Aug 2006 01:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIIbm-0002l2-2E for ospf@ietf.org; Wed, 30 Aug 2006 01:27:26 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIIbk-0001V3-Ss for ospf@ietf.org; Wed, 30 Aug 2006 01:27:26 -0400 Received: by wx-out-0506.google.com with SMTP id t4so91137wxc for ; Tue, 29 Aug 2006 22:27:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=mxU2IhrR9Lng8fQ3GourN/N0sblrsxW1IR6iviWUAJQgIZrPsEPtgzANn48D3Kcio9KcklSWXv+HjEP6MOYcBEd5ezZOON1QaLESxbdaLzVL2qyIy1mfjdLFY1XUrYilds5y9R24/IcYWIN+6AOQaZTmPTFUctPjvc01EZ9UJhE= Received: by 10.90.117.11 with SMTP id p11mr52199agc; Tue, 29 Aug 2006 22:27:24 -0700 (PDT) Received: by 10.90.84.11 with HTTP; Tue, 29 Aug 2006 22:27:24 -0700 (PDT) Message-ID: <4fbcb25a0608292227s7409731dm1377d857c1afd383@mail.gmail.com> Date: Wed, 30 Aug 2006 10:57:24 +0530 From: "Navina Balan" To: ospf@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [OSPF] SPF calculation in OSPF X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0355355642==" Errors-To: ospf-bounces@ietf.org --===============0355355642== Content-Type: multipart/alternative; boundary="----=_Part_15935_26557746.1156915644556" ------=_Part_15935_26557746.1156915644556 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I have a doubt in OSPF. Can you let me know, if Nbr Change occurs, do SPF calculation needs to done again. TIA Swapna ------=_Part_15935_26557746.1156915644556 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi all,
 
I have a doubt in OSPF.
 
Can you let me know, if Nbr Change occurs, do SPF calculation needs to done again.
 
TIA
Swapna
------=_Part_15935_26557746.1156915644556-- --===============0355355642== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============0355355642==-- From ospf-bounces@ietf.org Wed Aug 30 04:47:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GILhr-0002p1-NG; Wed, 30 Aug 2006 04:45:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GILhq-0002ov-Bl for ospf@ietf.org; Wed, 30 Aug 2006 04:45:54 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GILho-0004IB-47 for ospf@ietf.org; Wed, 30 Aug 2006 04:45:54 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4S003UGZJ3XO@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 30 Aug 2006 16:57:03 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J4S00HFQZJ29E@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 30 Aug 2006 16:57:03 +0800 (CST) Received: from dell60 ([10.18.23.153]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J4S00MJGZ9GXQ@szxml04-in.huawei.com> for ospf@ietf.org; Wed, 30 Aug 2006 16:51:21 +0800 (CST) Date: Wed, 30 Aug 2006 14:08:59 +0530 From: sujay Subject: RE: [OSPF] SPF calculation in OSPF In-reply-to: <4fbcb25a0608292227s7409731dm1377d857c1afd383@mail.gmail.com> To: 'Navina Balan' , ospf@ietf.org Message-id: <003d01c6cc0f$bddde710$9917120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcbL9cppADwpY9CVSYKE17o1K5BfVgADCZcw X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1369941689==" Errors-To: ospf-bounces@ietf.org This is a multi-part message in MIME format. --===============1369941689== Content-type: multipart/alternative; boundary="Boundary_(ID_26s7I0GvauMbeorg8QYWaA)" This is a multi-part message in MIME format. --Boundary_(ID_26s7I0GvauMbeorg8QYWaA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT In brief , if the Router LSA or Network LSA changes the Intra-SPF must be run. If your Nbr change is causing a Interface State machine change, Intra-SPF should be run as the LSA will be regenerated. See Section 12.4 as to when a Router LSA or Network LSA will be generated/changed. Regds, Sujay G My Location; http://maps.google.com/maps?ll=14.626109,76.959229 &spn=4.724852,7.525085&t=h&hl=en This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: Navina Balan [mailto:navinab@gmail.com] Sent: Wednesday, August 30, 2006 10:57 AM To: ospf@ietf.org Subject: [OSPF] SPF calculation in OSPF Hi all, I have a doubt in OSPF. Can you let me know, if Nbr Change occurs, do SPF calculation needs to done again. TIA Swapna --Boundary_(ID_26s7I0GvauMbeorg8QYWaA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
In brief , if the Router LSA or Network LSA changes
the Intra-SPF must be run.
 
If your Nbr change is causing a Interface State machine change,
Intra-SPF should be run as the LSA will be regenerated.
 
See Section 12.4 as to when a  Router LSA or Network LSA will
be generated/changed.
 
Regds,
Sujay G
My Location;
http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085&t=h&hl=en


This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 

From: Navina Balan [mailto:navinab@gmail.com]
Sent: Wednesday, August 30, 2006 10:57 AM
To: ospf@ietf.org
Subject: [OSPF] SPF calculation in OSPF

Hi all,
 
I have a doubt in OSPF.
 
Can you let me know, if Nbr Change occurs, do SPF calculation needs to done again.
 
TIA
Swapna
--Boundary_(ID_26s7I0GvauMbeorg8QYWaA)-- --===============1369941689== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1369941689==-- From ospf-bounces@ietf.org Wed Aug 30 05:51:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIMiH-0001WK-NI; Wed, 30 Aug 2006 05:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIMiG-0001W9-Fp for ospf@ietf.org; Wed, 30 Aug 2006 05:50:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIMiG-0003To-BP for ospf@ietf.org; Wed, 30 Aug 2006 05:50:24 -0400 Received: from wx-out-0506.google.com ([66.249.82.230]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIMaK-0000Ry-4d for ospf@ietf.org; Wed, 30 Aug 2006 05:42:13 -0400 Received: by wx-out-0506.google.com with SMTP id t4so151877wxc for ; Wed, 30 Aug 2006 02:42:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=i9+spTTR9+UYOxBIVqKXuSD1RtfwdsMit/ssVDsUtDoziXUOIvG5rj6CdtQx69P/P2lSDkxVi9N2JtoQHiatx8ydM0qFx4WbiSR22gdptqLrUQDUsc/d4rp8c//AfMdfcetIghxjDhkjhtg1RvFB9z3z2xncO2tkL1OmvBnJ/O0= Received: by 10.70.70.14 with SMTP id s14mr337110wxa; Wed, 30 Aug 2006 02:42:11 -0700 (PDT) Received: by 10.70.40.8 with HTTP; Wed, 30 Aug 2006 02:42:10 -0700 (PDT) Message-ID: Date: Wed, 30 Aug 2006 15:12:10 +0530 From: "Santosh Esale" To: ospf@ietf.org Subject: Fwd: [OSPF] SPF calculation in OSPF In-Reply-To: MIME-Version: 1.0 References: <4fbcb25a0608292227s7409731dm1377d857c1afd383@mail.gmail.com> X-Spam-Score: -2.4 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1252063131==" Errors-To: ospf-bounces@ietf.org --===============1252063131== Content-Type: multipart/alternative; boundary="----=_Part_28880_22623773.1156930930958" ------=_Part_28880_22623773.1156930930958 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline ---------- Forwarded message ---------- From: Santosh Esale Date: Aug 30, 2006 11:27 AM Subject: Re: [OSPF] SPF calculation in OSPF To: Navina Balan Full spf calclualtion need to run again if there is any change in the topology of area. If neighbour changes from Full to any of the lower state or lower state to full state , Router LSA will be regenerated again for this as well the neighbouring router and DR will regenerate network lsa(in case of boradcast link) which will result in topology change. If summary or external LSAs are withdrawn or added, most of the implementation runs incremental SPF. Thanks Santosh On 8/30/06, Navina Balan wrote: > Hi all, I have a doubt in OSPF. Can you let me know, if Nbr Change occurs, do SPF calculation needs to done again. TIA Swapna _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf ------=_Part_28880_22623773.1156930930958 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
---------- Forwarded message ----------
From: Santosh Esale <s.esale@gmail.com>
Date: Aug 30, 2006 11:27 AM
Subject: Re: [OSPF] SPF calculation in OSPF
To: Navina Balan <navinab@gmail.com>
Full spf calclualtion need to run again if there is any change in the topology of area. If neighbour changes from Full to any of the lower state or lower state to full state , Router LSA will be regenerated again for this as well the neighbouring router and DR will regenerate network lsa(in case of boradcast link) which will result in topology change.
 
If summary or external LSAs are withdrawn or added, most of the implementation runs incremental SPF.
 
Thanks
Santosh   

 
On 8/30/06, Navina Balan < navinab@gmail.com> wrote:
Hi all,
 
I have a doubt in OSPF.
 
Can you let me know, if Nbr Change occurs, do SPF calculation needs to done again.
 
TIA
Swapna

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf



 
------=_Part_28880_22623773.1156930930958-- --===============1252063131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf --===============1252063131==-- From ospf-bounces@ietf.org Thu Aug 31 14:06:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqut-0006gO-5U; Thu, 31 Aug 2006 14:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqur-0006eY-GI for ospf@ietf.org; Thu, 31 Aug 2006 14:05:25 -0400 Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIqur-0008Pe-3s for ospf@ietf.org; Thu, 31 Aug 2006 14:05:25 -0400 Received: from dialup-4.243.128.75.dial1.sanfrancisco1.level3.net ([4.243.128.75] helo=earthlink.net) by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1GIquo-0003YX-00; Thu, 31 Aug 2006 14:05:23 -0400 Message-ID: <44F724CB.50100@earthlink.net> Date: Thu, 31 Aug 2006 11:05:00 -0700 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Acee Lindem Subject: Re: [OSPF] Database Exchange Summary List Optimization References: <44B7E563.3000706@cisco.com> <44B7E6D0.6030304@cisco.com> <44BD1FE6.2030202@earthlink.net> <44CAAB32.4B2A546D@earthlink.net> <44DB9074.8000700@earthlink.net> <44EE1D00.50502@cisco.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: OSPF List X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-bounces@ietf.org I have a few comments and questions regarding the document. It seems clear that Option 1 should remain in the document (as Acee indicated). My comments below suggest that Option 2 is also useful and should also remain in the document. Finally, I discuss the question of whether Option 3 is useful enough to be included in the document. First, I want to mention two advantages of Option 2 (which might not be clear in the draft). Option 2 applies only to broadcast (or MANET) interfaces, and depends on the DR levels of the two routers (DR, BDR, or DR Other). (In a MANET, if both routers have the same DR level, then the tie is broken using Router ID.) For simplicity, let's say the router with larger DR level is a DR, and the router with smaller DR level is a DR Other. (1) With Option 2, the DR always lists all LSAs in its database, while the DR Other lists only LSAs for which it has a more recent instance than the DR. Therefore, even if the two routers are completely out of sync, and assuming the DR has more recent instances (which is more likely), the DR Other will not list any LSAs. In this case, if Option 1 were used, the DR Other would list roughly half of its LSAs on average (i.e., the LSAs that are not first listed by the DR), and the DR would still list all of its LSAs (assuming they are more recent), so Option 2 has an advantage over Option 1 in this case. (2) The second advantage of Option 2 is that the DR Other will list far fewer LSAs (and thus transmit fewer bits) than the DR on average. This may be useful in a MANET, since the DR Other may be less powerful than the DR, and thus have a lower router priority. Therefore, the less powerful router transmits fewer bits, which makes sense. For the above two reasons, I think Option 2 is useful and should remain in the document. The main question I have is whether Option 3 is useful enough to remain in the document. In Option 3, the master lists LSAs in forward lexicographical order, while the slave lists LSAs in reverse order. This reduces the number of LSAs that are listed by both the master and slave, without requiring a router to completely process a received DD packet before sending the next DD packet in response. Acee told me he does not see a great advantage to sending the next DD packet prior to processing the received one, and that this may be a protocol violation since the DD packet sent in reply effectively acks the received one. So one question is whether it is possible to effectively ack a received DD packet without first processing the list of LSA headers in the packet, or at least reading the LSA headers to make sure they are valid. Processing the LSA headers for the purpose of updating the summary list will not take significantly more time than simply reading all the LSA headers, assuming the summary list is ordered lexicographically or is organized as a binary tree. Note also that Option 3 has a disadvantage. For example, if all LSA headers fit into a single DD packet, then both routers will still list all LSAs. So my main question is whether Option 3 is sufficiently useful and advantageous to be included in the document. Also, the same question can be applied to Option 2, considering the advantages I discussed above. One possibility is to include only Option 1 in the document. Richard Acee Lindem wrote: > We had a majority of the attendees in favor of making this a WG > document in Montreal. Is there anyone not in favor of adopting it as > an informational WG document? > > I know there are those who feel we shouldn't publish any document > that is fully compatible. However, in this case, IMHO, it is > worthwhile for > the WG to do so since: > > 1. WG discussion and review will verify with a high probability > that this change is, in fact, fully backward compatible. > 2. We'd be accepting a document that most people agree is a > good thing to do - there is less disagreement on the details > then some other proposals. > 3. The relatively simple optimization can result in a significant > decrease in DB exchange overhead. In fact, I predict option A > will some day be in most implementations. > > Thanks, > Acee > > Richard Ogier wrote: > >> I have submitted the following updated draft: >> http://www.ietf.org/internet-drafts/draft-ogier-ospf-dbex-opt-01.txt >> >> The update incorporates comments of others and some ideas I presented >> in my post on 7/18/2006. In particular, it describes three options >> that differ in whether the LSAs must be listed in lexicographical order >> and whether a router must fully process a received DD packet before >> sending its next DD packet. To summarize: >> >> In Option A, the router is required to fully process a received DD >> packet before sending the next DD packet in reply. >> (LSAs are not listed in lexicographical order.) >> >> In Option B, the router with the larger DR level performs database >> exchange as in RFC 2328 without change. The router with the smaller >> DR level sends only empty DD packets (with no LSA headers) until it >> has received the entire summary list from its neighbor (indicated >> by M = 0), and then lists only LSAs that are more recent than those >> received. I forgot to mention in the draft that Option B applies >> only to broadcast (or MANET) interfaces. >> >> In Option C, the master lists LSAs in lexicographical order >> and the slave lists LSAs in reverse lexicographical order, >> as suggested by Mitchell Erblich. >> >> Regarding recent comments by Mitchell, I am not yet convinced that >> there is any benefit to detecting whether a neighbor is nearly in sync >> and using the optimization (with one of the three options) only if >> the neighbor is nearly in sync, versus simply employing the >> optimization. For example, in MANETs, it appears best to simply >> employ the optimization with Option A. >> Maybe you can provide a concrete, realistic example. >> >> Even if it does help to detect whether a neighbor is nearly in sync, >> I am not sure that the (informational) document I am working on >> needs to specify such a detection mechanism. Such a mechanism >> could be specified in a separate document. Instead, the document I >> am working on can just state that such a mechanism can be employed >> if desired. If two routers are performing database exchange, the >> protocol does not fail if only one of the routers decides to use >> the optimization, or if one router decides to use Option A while the >> other decides to use Option B or C. >> >> Of course, this optimization was motivated because we wanted >> to reduce overhead in MANETs, and I would prefer to keep >> the document as simple as possible. >> >> Richard >> >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www1.ietf.org/mailman/listinfo/ospf >> > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www1.ietf.org/mailman/listinfo/ospf